Gawain Lynch

@anneleen, I believe that the root of your problem is that StatPress Visitors only triggers its logging during a certain part of the WordPress PHP page load. Since caching plugings try to ‘snapshot’ pages, the logging code is not hit.

TBH, Google Analytics (or similar competitor) is a far better choice as it will filter a lot of the bot traffic from your stats and is executed by a tiny bit of script on the HTML page generated by either WordPress or a cache plugin such as this one.

@ivnus: https://pastebin.com/MNVbNZFZ

Basically just change line 531 from:
wp_register_script( 'bbppt-admin-script', WP_PLUGIN_URL . '/bbpress-post-topics/inc/bbppt-admin.js', array('jquery') );

To:
wp_register_script( 'bbppt-admin-script', plugins_url() . '/bbpress-post-topics/inc/bbppt-admin.js', array('jquery') );

Hi Ron,

I struck the problem a while ago, and I can’t remember the original set of issues, but the most recent one that re-prompted me to upstream was with the calendar plugin from time.ly.

They install a child/sub-theme that uses WP_CONTENT_URL to set the URL path to image file. Swapping out the constant for content_url() obviously then required that content_url() be filtered.

I’ve been running with this in production since August and it Works For Me ™.

I’m using nginx too, in the unlikely event that has bearing.

That as my first thought too Rahul, in my case there were no other physical or virtual robots.txt.

I don’t know if this is of any use to anyone, but I struck this problem also on a domain mapped MS install.

The problem in my case was that the request for robots.txt wasn’t being passed through to WordPress and was being intercepted by Nginx.

Adding this fixed the problem:

location = /robots.txt {
	allow		all;
	log_not_found	off;
	access_log	off;
	try_files $uri $uri/ /index.php?$args;
}

I can’t imagine Apache would be too different.

Well, I don’t want to say you *can’t* go and write your own queries… It’s your site :-D. But messing around in the database backend is a very quick way to destroy your blog unless you know what you’re doing.

Personally I always have a development environment of each blog on a private server to mess around with things like that before trying it in production. So if that all just whistled past you, then yes just ignore the entries until you have the time and inclination to read up on MySQL and friends. Better to subtract 10% from your stats manually that rebuild your entire blog.

Hey inthegap,

The best thing you can do is make sure you keep plugins and themes up to date (and hope the authors of said software are keeping any libraries like this up to date as well).

You’re probably only seeing this now because you’ve been lucky enough to not be hit by these scans before. I used to just do a MySQL query and manually flush these things out of my db.

I was working with Luciole135 on code to ignore requests unless they actually matched a page request, but the logic to do it blew the memory requirements of the plugin out of the water! ??

It looks like a bot scanning your site to find vulnerable versions of TimThumb, of which there are a lot still out there in plugins and themes that haven’t been updated in a long time.

No, I just used another menu… I gave up a couple of days later as I was able to drop in another plugin that worked out of the box (albeit not as sexy as this one).

Awesome ?? Enjoy!

Hmm… I’m wondering…

OK, so what I can gather, logically from the information you’ve provided is that StatPress visitors is experiencing a database error of some type, but when it tries to log that error it is unable to find core WordPress files.

My current guess is around file and directory permissions in the root WordPress directory ‘/home/xxxxx/public_html/’ as the upgrade process was unable to delete .maintenance, it might well have been unable to delete wp-load.php and not upgraded the install properly (possibly the same for other files in that directory).

One option would be to edit wp-load.php and on the second line add something like:
/* This is a comment that I don't want to see */

And then go to the updates screen and tell WordPress to reinstall itelf and see if that text disappears from the file.

Weird.

wp_load_translations_early() is defined in wp-includes/load.php which is included by /wp-settings.php which leads me to suspect that there is something broken in your WordPress install.

Had you made any other changes around the time you updated Statpress?

If you disable all other plugins then enable only statpress-visitors, the last 10 or so lines should have the error and backtrace that has the details we want… You can also paste the whole log (starting from after all plugins are disabled) to pastebin.

Note: some plugins are very noisy in the debug log, so this is why it is useful to disable them before enabling this one. i.e. disable everything, delete the old debug.log file and then enable statpress-visitors

Try adding the following to your wp-config.php

define('WP_DEBUG', true);
define('WP_DEBUG_DISPLAY', false);
define('WP_DEBUG_LOG', true);
define('SCRIPT_DEBUG', true);
define('SAVEQUERIES', true);

The call is failing on a database operation which is in turn trying to call print_error(). The above defines will create a debug.log file in your wp-content directory that will give you/us some clues.

Hi,

This is not straightforward. Basically the table structure has changed a log between StatPress, NewStatPress and StatPress Visitors… It may theoretically be possible to write some PHP or SQL to convert the old data to the new format, but I am not familiar enough with NewStatPress to know for sure… Luciole135 might have a better idea though.

One change we made in the upcoming 1.5 version is to make the table name a global constant, so theoretically you could change the table name for StatPressV in the code and still have your old table there for viewing with NewStatPress. But it might also cause lunar earthquakes, so you’d do that at your own risk ??

As for the inevitable question of when Luciole135 will release 1.5… Soon ??