Joshua Fredrickson

And another when accessing the admin area:

implode(): Passing glue string after array is deprecated. Swap the parameters in /***/plugins/wp-analytify/lib/Google/Http/REST.php on line 134

Yep. You’re right. That did the trick. Thanks for the assist!

That doesn’t work either. ?????♂?

Agree. Very not cool.

Version 7.8 is throwing a PHP fatal error on PHP 5.x. Killed at least two client sites running legacy PHP.

It’s super easy to go back to the previous editor… Just install the Classic Editor plugin.

Enjoy!

Adding that filter did the trick.

Although, it seems to make sense that if a script is excluded in the settings that it would automatically be excluded from all AO filters.

Thanks for help!

I’m seeing this issue on another excluded script. It was being successfully excluded up until version 2.4.0.

Rolling back to 2.3.4 resolves the issue.

I’m seeing the same thing as you, @priprod.

get_category_link($id) returns a string with a length of 0. This is with a known valid $id being passed to it.

This worked in 4.8.3 and stopped working immediately after updating to 4.9 on multiple sites.

EDIT: Replacing it with get_term_link($id) worked as expected.

• This reply was modified 7 years, 4 months ago by Joshua Fredrickson.

That same page says WordPress supports PHP 5.2.4. Here’s a suggestion if you’re open to it…

Since WordPress officially supports PHP 5.2.4, it doesn’t make sense that your plugin would trigger fatal errors in that environment. It’d be better if the plugin automatically deactivated or displayed a warning if the server doesn’t meet the plugin’s requirements.

For example, something as simple as:

// Exit gracefully if PHP version is lower than 5.3.2
// @todo remove this when WordPress drops support for PHP version < 5.3.2
if (version_compare(PHP_VERSION, '5.3.2', '<')) { ... }

My two cents. ?? I’ll leave you alone now.

Unfortunately, this is on GoDaddy hosting and I can’t get the client to move off of it.

Not my call. ??

I have a quick fix that’s working for me. Use at your own risk.

Look for this code around line 549 in force-regenerate-thumbnails.php:

if (!(strrpos($thumb, $file_info['filename']) === false)) {

And change it to this:

if (!(strrpos($thumb, $file_info['filename']) === false) && !(strrpos($thumb, '.'.$file_info['extension']) === false)) {

The plugin should now check for both a matching basename and extension before deleting the thumbnails.

Of course, this change will be overwritten if you reinstall or update the plugin.

• This reply was modified 8 years, 1 month ago by Joshua Fredrickson.

+1

This issue makes this plugin unusable for me. Unfortunately, this is one of my go-to plugins but I really can’t use it as is.

That just means he hadn’t refreshed the site within two days of first visiting the page.

More than likely he left the browser tab open, came back several days later and submitted a comment without refreshing the page.

Or he’s exhibiting bad behavior and the request was correctly blocked. ??

@dannidar This bug is fixed in upcoming WP 4.5.1. Good news is that you can manually patch it on any current site running 4.5 by following these steps.