Thanks for the report. Can you send me a list of the other plugins that are active on your site including their version numbers please?
@iamonlythird2 The setClassMapAuthoritative() method was introduced in Composer version 1.0, which was released over seven years ago. It appears that something else on your site is using a really ancient autoloader that was created before Composer v1. If you can send over a list of your active plugins and their version numbers I can take a look for you.
@johnbillion I run a variety of platforms and all of which have both custom plugins and third-party ones available on the plugin WP archives.
So I think may be better if you can provide me with what I should be looking for, and maybe I can locate it in the custom plugins? Also, since this is a popular plugin, is there no way to adjust your code so it won’t clash with sites who may have an older autoloader?
And is this fatal error connected with the ones other users reported for the very recent version of this plugin?
I should note that I updated this plugin from 1.13.0 to 1.15.0 on 6 platforms. It had the fatal crash on one of the platforms. I regardless downgraded to 1.14.0 on all sites, just in case.
So I think may be better if you can provide me with what I should be looking for, and maybe I can locate it in the custom plugins?
What I’m looking for is whether one of your plugins (or themes) uses a Composer autoloader that was generated prior to Composer version 1.0. I was planning on looking through your list of plugins, searching for vendor/autoload.php, and then manually checking the corresponding autoloader files.
If that’s not the case then I’d need to figure out what else might be causing your site to be using a Composer autoloader that’s missing the setClassMapAuthoritative() method used by the autoloader in WP Crontrol.
is there no way to adjust your code so it won’t clash with sites who may have an older autoloader?
That’s why I was asking for a list of your plugins so I can a) determine exactly where the problem lies, and b) whether it’s prevalent enough to support. I’ve never seen a WordPress site running a Composer autoloader prior to version 1.0.
If I can reproduce the problem myself then I can have a think about how best to work around it.
And is this fatal error connected with the ones other users reported for the very recent version of this plugin?
Vaguely yes. Every day I learn about a new and fascinating way that people configure their WordPress sites!
I’m seeing the same error message. For the sake of privacy, is there a way of emailing you my plugin list?
-
This reply was modified 3 years, 5 months ago by
Philo22.
I don’t think a list of plugins is something you should consider private, but sure, you can email the list to me at john at johnblackbourn dot com and I’ll take a look.
The Hide Show Comment plugin has been identified as one that bundles an ancient version of the ClassLoader class that ultimately causes this fatal error. I’m looking into ways around this, but there’s no guarantee.
I’ve added a workaround for this in version 1.15.1.
Hi @johnbillion
I’m the author of the Pixel Manager for WooCommerce, and one of its users has run into a similar problem.
Would you mind sharing what workaround you’ve built in?
Thanks
Aleksandar
@alekv I had to resort to making modifications to the Composer generated files in a build script that runs during the deployment. It’s all in here: https://github.com/johnbillion/wp-crontrol/blob/develop/bin/build.sh
@johnbillion Thanks!
I also thought about this but was hoping that there was a better way than filtering the Composer files.
I’ll do the same now.
