Mark Barnes

7.0.3 does seem to have fixed the issues. Thanks for the quick response. (And it’s worthwhile, because the file-based cache is much faster than v6.)

baseos | <redacted>@<redacted>.sgvps.net:~/www/samaritans-purse.org.uk/html$ wp sg purge
Success: SiteGround Optimizer assets folder purged successfully.
Success: File Cache Succesfully Purged.
Success: Dynamic Cache Successfully Purged.
baseos | <redacted>@<redacted>.sgvps.net:~/www/samaritans-purse.org.uk/html$ echo $?
200

Thanks for the response. My site is with SiteGround. You can see the domain name above. There’s a typo in the File Cache “Succesfully” message, by the way.

You’ve got halt(200) commands all over purge_everything() and purge_url().

Thank you for the quick release of 7.0.2. This release partly fixes the issue. The purge command does now work, but with an important caveat. It exits with an exit code of ‘200’. I presume this is supposed to be equivalent to an HTTP status code of 200 OK, but anything other than an exit code of 0 is usually interpreted by bash scripts as an error. The plugin should exit with a code of 0 if the cache was successfully purged.

(In our case, we’re using BitBucket Pipelines, which assumes a build has failed if there isn’t an exit code of 0. I’ve had to write a bash script to check for an error code of 200 and convert it to 0!)

Even when I hack around the above problem, there’s a second issue, this time with Cli_Purge->supercacher->purge_everything(). On my local test environment, that attempts to run the site-tools-client domain-all update id=%s flush_cache=1 path='%s' command, which of course fails. This should presumably be skipped when away from SiteGround servers.

• This reply was modified 3 years, 1 month ago by Mark Barnes.

This new plugin uses the same post metadata as the old one, so you won’t need to re-enter all your URLs.

I had this problem too. To ensure you have all the child pages, you can edit line 28 of the plugin to read:

$the_query = new WP_Query( 'post_type=page&nopaging=true&post_parent='.$post_parent );

It’s the &nopaging=true that will fix the problem.

@igar2k – it’s not the same issue. You can fix permissions by following these instructions: https://www.siteground.com/tutorials/getting-started/admin-tools-for-wordpress/#How_to_reset_the_permissions_of_your_files_and_folders

@wfpeter. Thanks for the reply. We are using Query Monitor on our dev machines, but not on our live site. On our live site, our custom error-checking code captures and logs the database error (our code monitors the $EZSQL_ERROR global).

Elsewhere in WordFence you use ON DUPLICATE KEY UPDATE for this insert statement, so I don’t understand why you can’t use that for all occurrences of the statement. Or use INSERT IGNORE if that suits your purposes better.

It is BugSnag that captures the warning about the deleted file. I’m not sure why it does so when you’re suppressing the error with an @.

That was quick! Thank you.

My apologies. The first steps didn’t look like they had worked because of some super-aggressive caching from my webhost. I’ve cleared that, and the error seems to have gone.

Thanks for the very quick reply. I’ve no custom code, but I did have old plugins and themes (although none of the plugins were active). However, I was very careful to follow the upgrade steps.

I was running version 6.4 because I couldn’t upgrade to 6.5 (see below).

Unfortunately, the problem prevents me from logging into the WP admin, so it’s not easy to test the issue. (I can log in if I rename the simplepress folder and therefore disable the plugin.) With SimplePress activated I did try renaming the sp-resources folder because all the themes etc. in there seemed very old, but that didn’t help.

After deactivating SimplePress I was then able to update it. Reactivating 6.5 did allow me into the admin, though. (Perhaps because I already had a log-on cookie?)

I was then able to update the SP plugins, although I had significant difficulty in doing so as I frequently got the message that the plugin was already at the latest version. I was doing them one at a time to see which might be causing the problem. I discovered that after updating one plugin from update-core.php I had to visit the SimplePress plugins page before I could update another. I then end I gave up doing them one at a time and just did them all together.

However, none of this helped. Nor did visiting the permalinks settings page.

I increased the logging details, and I’ve discovered the search terms that are causing this problem:

index/%5Cthink%5Capp/invokefunction&function=call_user_func_array&vars%5B0%5D=phpinfo&vars%5B1%5D%5B%5D=1

Home/%5Cthink%5Capp/invokefunction&function=call_user_func_array&vars%5B0%5D=phpinfo&vars%5B1%5D%5B%5D=1

/Index/\think\app/invokefunction&function=call_user_func_array&vars[0]=md5&vars[1][]=HelloThinkPHP

I presume these are from bad actors looking for this vulnerability.

I haven’t looked at relevanssi’s code, but perhaps there’s no double-escaping when there should be?

Thanks for the quick reply, Mikko. If I find out more I’ll update the thread.

That triggers the AJAX, which it didn’t before. Thanks for the speedy turnaround. (It’s not returning any data yet, but that might be an issue with my custom post types. What do I need to check in my code to make sure my CPTs will return results?

This was fixed in 0.45.22. Thanks.