Version 5.0.0 generates errors with the AWPCP plugin

Here is the error message. (without specifying the path of our server)

Fatal error: Uncaught Error: Failed opening required ‘/plugins/autodescription/inc/classes/post-data.class.php’ (include_path=’.:/opt/plesk/php/8.0/share/pear’) in
/plugins/autodescription/bootstrap/load.php:207 Stack trace: #0 [internal function]: The_SEO_Framework_autoload_classes() #1 /plugins/another-wordpress-classifieds-plugin/includes/compatibility/class-seo-framework-plugin-integration.php(74): class_exists() #2 /plugins/another-wordpress-classifieds-plugin/includes/compatibility/class-seo-framework-plugin-integration.php(60): AWPCP_SEOFrameworkIntegration->are_required_classes_loaded() #3 /plugins/another-wordpress-classifieds-plugin/includes/compatibility/compatibility.php(49): AWPCP_SEOFrameworkIntegration->setup() #4
/plugins/another-wordpress-classifieds-plugin/includes/compatibility/compatibility.php(19): AWPCP_Compatibility->load_plugin_integration_used_in_frontend_screens() #5 /plugins/another-wordpress-classifieds-plugin/includes/class-awpcp.php(90): AWPCP_Compatibility->load_plugin_integrations() #6
/plugins/another-wordpress-classifieds-plugin/awpcp.php(238): AWPCP->setup() #7
/plugins/another-wordpress-classifieds-plugin/awpcp.php(211): awpcp() #8
/httpdocs/wp-includes/class-wp-hook.php(324): awpcp_load_main_plugin() #9
/httpdocs/wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters() #10
/httpdocs/wp-includes/plugin.php(517): WP_Hook->do_action() #11
/httpdocs/wp-settings.php(506): do_action() #12 /httpdocs/wp-config.php(110): require_once(‘…’) #13
/httpdocs/wp-load.php(50): require_once(‘…’) #14 /httpdocs/wp-blog-header.php(13): require_once(‘…’) #15
/httpdocs/index.php(17): require(‘…’) #16 {main} thrown in /plugins/autodescription/bootstrap/load.php on line 207

Thank you for the error log. I can’t access the plugin since it’s gated behind a paywall, but the log immediately tells me what’s wrong.

If you could be so kind as to forward this issue to their developers, please tell them to look into its use of class_exists(): It has a second parameter that prevents the autoloaders from invoking. Since we updated the class structure, the autoloader will look for a class that no longer exists. Setting the second parameter to false would resolve the issue immediately.

Still, we never advertised the class they check for as part of the public API, so the entire class check should be exchanged for something else. Deducing from the error, they should test for function_exists( 'tsf' ) and work only via that function directly: tsf() has multiple safeguards to prevent fatal errors like the one you’re experiencing via magic methods and something I called Static_Deprecator.

If they want more immediate pointers, they can always contact me via https://tsf.fyi/contact. Thank you!

Hi Sybre,

thanks for the fast response.

We have passed the process on to the developers of AWPCP and will inform you again.

Hi @rolandstumpp

I encounter the same problem. Do you know if AWPCP will correct their plugin or does version 5.0.1 of SEO Framework solve the problem ? I’m keeping version 4.2.8 until a correct update.

Hi spespam,
version 5.0.1 does not solve the problem. The problem is caused by awpcp.

here is the answer from awpcp:

Thanks for getting in touch. We appreciate you bringing this to our attention!

I have been able to replicate this issue and have added it to our bug list to fix for a future release. We don’t yet have an estimate on when this issue will be resolved, so I cannot give you a timeframe for resolution. Are you able to roll back your version of The SEO Framework plugin in the meantime?

I’m very sorry for the inconvenience! Please let me know if you have any other questions or issues, and hopefully, we’ll be able to address this soon.

Sincerely,

Thank you @rolandstumpp

I’ll stick to version 4.2.8 until AWPCP solve the problem. It’s good to know they’re working on it. ??

Hello!

I apologize for the inconvenience; I cannot fix this in TSF. AWPCP uses an improper call to invoke a non-public part of our API that I cannot reintroduce.

I added fail-safes in all public APIs of the plugin so that failures can be handled gracefully. Adding fail-safes to private code would obscure messages helpful to developers or significantly increase our development time.

If you need to roll back until they fix it, here you can learn how to: https://tsf.fyi/kb/common-update-issues#rollback.