Jump to content

Recommended Posts

Hi Jack,

Really nice Add-on, confusing at beginning but after some testing, we can get it how it work...

Really useful... thank you for your wok....

I installed this on a 2.34 pure oscommerce. All working very nice. Installed another add-on..... And something goes wrong which was not your add-on..

So I deleted the shop and re-upload the shop via FTP...

I take a mysql backup and uploaded it... I reinstalled View Counter..

All is working fine again.. The only problem which I didn't see in this thread is when I click on Monitor, all work good but the only problem I see is it not showing the color column like Bot color, green for admin and etc... It show the same color for everybody,  that the only problem I have, The rest, all is ok, having zip error, weird !!!! 

What is the problem ??? 

 

Edited by Jeep_ice

John

--------------------

osCommerce 2.3.4 Bootstrap Edge

Share this post


Link to post
Share on other sites

Thank you for the answer...

Like I said, All is working good except the color not working.. I go in the color and when I chose color or a preconfig color like autumn... 

It will not change.. Nothing.... Very weird... I try to understand why everything work but not the color...


John

--------------------

osCommerce 2.3.4 Bootstrap Edge

Share this post


Link to post
Share on other sites

Forget it, all is working now... I don't know why.... I just played with the color and all is good.... 

Great Add-on....

 


John

--------------------

osCommerce 2.3.4 Bootstrap Edge

Share this post


Link to post
Share on other sites

Hello Jack,  Thank you very much for all your hard work and this addon.  I installed it on my osCommerce BS site and it seems to be working fine.  However, every once in a while my site locks up (I think it occurs when using the View Counter pages on the admin side but I'm not 100%)... I tracked it down to a query that is being made which won't complete and locks up the entire site.  Below is what my hosting gave me (I assume from an error file) with the database name removed.  I tried to find where the query is in the code but I don't see it.  I noticed in admin/database_tables.php that the View Counter tables don't optimize.  Do you have any ideas on how to fix this?

| 607836 | XXX | localhost | XXX | Query | 11596 | Waiting for table metadata lock | optimize table view_counter | 0.000 |
| 607837 | XXX | localhost | XXX | Query | 11596 | Waiting for table level lock | optimize table view_counter | 0.000 |

Share this post


Link to post
Share on other sites

No one has ever reported this problem before and I've not seen it with View Counter so I don't know why it is happening. If you are using a version of oscommerce that lets you convert database tables, please try using the change to UTF option. That will switch the tables to InnoDB, which is not immune to this problem but less likely for it to occur.

View Counter stores a lot of data so if your site is very busy, it could be that this happens during extra busy times. But either way, you can try turning off the flag option and the block country option, if it is enabled, to see if that eliminates the problem.

Share this post


Link to post
Share on other sites

Hi Jack.  Thank you for replying.  I cloned my site and db on a subdomain for testing. I converted all tables to UTF per your suggestion.  I see now where in application_top.php where the optimize query was being made...  To test I removed the if's around each query block so that it would optimize on every admin page reload.  It seems to be working fine!  So, I think conversion to UTF did the trick!  Thank you Jack!

Share this post


Link to post
Share on other sites

It looks like I spoke too soon... It's still doing the same thing... I'm going to dig into it a little more and post what I find.  Thanks.

 

Share this post


Link to post
Share on other sites

Hello jack,

I installed viewcounter (1.7) on my highly modified template website, but it is showing empty page on the monitor page (result Displaying 0 to 0 (of 0 links) ) but it does record the activity i done while i check the database. Any clues for that?

Share this post


Link to post
Share on other sites

I can't think of a reason for that. The display code just reads in the database and displays it, like any other page in admin. It does use code on that page that is not used elsewhere in VC so maybe something is missing. Please check the admins root directory to see if there is an error_log file and, if there is, see what the latest errors are. If there is not such a file, at the top of the admin/view_counter.php file, right after the line with application_top.php in it, add this

  error_reporting(E_ALL);
  ini_set('display_errors','1'); 

Then try refreshing the monitor page and see if it shows any errors. If not, the only other thing I can think of is that I haven't tested it under php 7 so if you are using that, that might be the reason.

Share this post


Link to post
Share on other sites

Hello Jack.

I have installed your contribution on a modified 2.3.4 version and somehow it seems to be working (i.e.: I do not get any errors when I run it). 

I only have a couple of main issues: whenever I enable the contribution, the main (catalog) website gets from lightning fast to extremely slow and the monitor mode on the admin side gets really slow as well, plus it only shows data once every few attempts/clicks. 

Would you know what is actually causing the above issues?

Thank you 

Mendoh

Share this post


Link to post
Share on other sites

On very busy sites, there may be a little slow down but it shouldn't be so visible. I just checked a site that had about 9,000 visits in the last 24 hours (shown in the monitor section) and it is running fine.  Is your count larger than that? You may want to adjust some of the settings. Loading the flags can take a while on some sites so try disabling that one. As well as country blocking and trapping. You should be able to run with them all on but turning them off will help find the problem.

Share this post


Link to post
Share on other sites

Jack, many thanks for your fast reply!

The site in question has recently gone online and is well below 9000 visits in the last 24 hours. I also tried to adjust some of the settings by turning off the flags and country blocking is not even enabled: no way, it stays slower than a turtle...monitor page in admin does not even load and on the catalog side the page loads completely white. Under these conditions, other than turning it off, I would not really know what to do with it...

 

Share this post


Link to post
Share on other sites

A white page means there is a fatal error. Are you sure you uploaded the database file? it isn't included in the addon package.

Take a look in the shops directory and see if there is an error_log file and, if so, see what the errors are.  If the file isn't present, add this line after the error_reporting line in includes/application_top.php

  ini_set('display_errors','1');

If that line is present, make sure it is set to 1. Then refresh the page on the shop side and see if an error is shown. Be sure to change that 1 to a 0 when you are done testing.

If that doesn't help located the problem I can't do much more. It means something is wrong with the installation but without an error to go on, I can't guess at what it might be.

Share this post


Link to post
Share on other sites

Thanks.

I actually downloaded and renamed the DB (i.e.: .BIN file inside the zip) as suggested in your install file, then uploaded the DB file to admin/includes directory: it is almost 600Mb in size. 

After adding the line you mentioned to the includes/application_top.php file, the following error shoots up:

Warning: file_get_contents(http://api.hostip.info/?ip=xx.xxx.xx.xxx): failed to open stream: HTTP request failed! HTTP/1.1 522 Origin Connection Time-out in /xxx/yyy/zzz/kkk/jjj/website/includes/modules/view_counter_country_block.php on line 79

Share this post


Link to post
Share on other sites

That error occurs when one server is waiting on another server to respond and that other server is taking too long. There's nothing in VC that connects to another server except for the version checking and that is only done when clicked on unless you have the auto check version option enabled.  I know you said it works fine with VC off but that error indicates it is something else. it might be that there is a delay with it off but the code in VC is doing a number of checks that increases the delay. All I can suggest is that you try to find the link to the other server and remove it.

Share this post


Link to post
Share on other sites

The bad link was actually inside the view_counter_country_block.php file. Removing the link caused the error to vanish on the catalog side and page loading speed is back to normal. On the admin side, however, the page stucks whenever I click on view counter/monitor: not only I am totally unable to access the monitor data but also I am now getting another type of error which is this: Unable to connect to database server!

I am going crazy...

Share this post


Link to post
Share on other sites

There is something wrong with your installation. Any link in the country blocking code is not used if the country blocking option is off, which you said it was. But the only link I can think of to an external site is if you have the option for checking things set to external. That is known to cause problems since that site is frequently down. It is not recommended.

If that isn't it, then I suggest you remove the addon and make sure your shop is working correctly. Then install it again.

Share this post


Link to post
Share on other sites

Dear Jack,

based on your suggestions, I started investigating the contribution deeply and it did not take me too long to realize my colleague actually installed an old version of your contribution (v1.4) instead of the most recent one. 

Therefore, I downloaded the most recent release, installed it and now everything works as fast as lightning even when "show flags" and "external checks" are on. 

There is, however, a code error which I have found inside the "view_counter_tools.php" file under admin: this error prevents you from successfully creating an .htaccess backup file. As a matter of fact, running the related function under admin/tools/maintenance tools gives you a 404 error. That happens because there are four wrong instances of the file name FILENAME_VIEW_COUNTER_TOOLS (which is correct), while the (wrong) file name in the file shows up as "view_counter-tools.php": it is sufficient to replace the four wrong instances with the correct file name and everything works as it should.

Thanks for your valuable help!

Share this post


Link to post
Share on other sites

I'm glad to hear you got it going. As for the coding problem you discovered, that is a known issue that has been reported here previously. It has been fixed in the new version but that has not been uploaded yet.

Share this post


Link to post
Share on other sites

Hi Jack,

I installed this add-on a few weeks ago, and then all of a sudden my admin slowed down drastically.  All admin pages.  I narrowed down the problem to be here in admin/includes/application_top.php

  /***** Begin View Counter *****/
  if (VIEW_COUNTER_ENABLED == 'true') {
   
      /**** BEGIN FORCE CLEAR THE TABLES ****/  
      if (VIEW_COUNTER_FORCE_RESET > 0) {
          $dateNow = @date("Y-m-d", time() - (VIEW_COUNTER_FORCE_RESET * 86400)) . ' 23:59:59';
          tep_db_query("delete from " . TABLE_VIEW_COUNTER . " where last_date < '" . $dateNow ."' ");  
          tep_db_query("optimize table " . TABLE_VIEW_COUNTER);  
      }
	  
      if (VIEW_COUNTER_FORCE_RESET_STORAGE > 0) {
          $dateNow = @date("Y-m-d", time() - (VIEW_COUNTER_FORCE_RESET_STORAGE * 86400)) . ' 23:59:59';
          tep_db_query("delete from " . TABLE_VIEW_COUNTER_STORAGE . " where last_date < '" . $dateNow ."' ");  
          tep_db_query("optimize table " . TABLE_VIEW_COUNTER_STORAGE);  
      }
      /**** END FORCE CLEAR THE TABLES ****/    
      
      include(DIR_FS_CATALOG . 'includes/modules/' . 'view_counter.php');
  }

Each if block was taking 10 seconds each.

Do you know why this may of just started happening and how I can get it to stop?  (I simply disabled "view_counter" in admin and everything is running fast again)

I'm running OSC 2.3.4 Edge.

Thanks!!

Bill

Share this post


Link to post
Share on other sites

That code is removing entries from the VC tables. I can't think of a reason why it slow anything down. Even if you have the settings set to clear the tables every day,  the time it takes to do that might be a second each, if that. But it could be that the database is corrupted so you might want to run a repair on it.

Share this post


Link to post
Share on other sites
6 hours ago, Jack_mcs said:

That code is removing entries from the VC tables. I can't think of a reason why it slow anything down. Even if you have the settings set to clear the tables every day,  the time it takes to do that might be a second each, if that. But it could be that the database is corrupted so you might want to run a repair on it.

Yea, seemed very odd to me too.  Only thing I can think of is that maybe I had too many days of data being stored so I hit a timeout or something like that.  I have since reduced the amount of time I keep the information and all seems well now with the code back on and activated.  I'll keep you posted if I am able to reproduce it in the future.  Thanks Jack!

Share this post


Link to post
Share on other sites
On 2/11/2018 at 3:20 PM, phi148 said:

Yea, seemed very odd to me too.  Only thing I can think of is that maybe I had too many days of data being stored so I hit a timeout or something like that.  I have since reduced the amount of time I keep the information and all seems well now with the code back on and activated.  I'll keep you posted if I am able to reproduce it in the future.  Thanks Jack!

Well, it happened again.  This is very odd.  I commented out the code, then manually executed the SQL queries and they ran fast as expected.

Then I put the code back in, and the problem is gone again.  I'm willing to bet by tomorrow I see the slowdown creep back in.

Hmmm. 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×