Another similar threads of the issue was closed with a partial solution that only addressed one plugin that was triggering this core issue:
Expected behavior
When a plugin update is available, you should be able to click on the “View version 2.25.21 details” link, which should load wp-admin/plugin-install.php in a framed popup with the plugin details in it.
Current behavior
Instead of the plugin details the popup window in a blank white screen, and the following 500 Error is logged.
PHP Fatal error: Cannot redeclare plugins_api() (previously declared in …/wp-admin/includes/plugin-install.php:101) in …/wp-admin/includes/plugin-install.php on line 101
Possible solution
This core bug was brought over from the WordPress core (in which it was later fixed). The problem is on line 94 of /wp-admin/includes/class-wp-plugin-install-list-table.php, in in the function prepare_items:
include ABSPATH . ‘wp-admin/includes/plugin-install.php’;
The solution is to change this to an include_once:
include_once ABSPATH . ‘wp-admin/includes/plugin-install.php’;
Hi Viktor,
I am using CP v1.6.0 and I honestly don’t know why it is working for you and not for me. From a coding standpoint alone, this is a valid bug, it may not present in all situations but you can tell it’s poorly coded and prone to failure just by looking at these two lines (93 and 94) of wp-admin/includes/class-wp-plugin-install-list-table.php:
public function prepare_items() {
include ABSPATH . ‘wp-admin/includes/plugin-install.php’;
All that would need to occur to cause a fatal error would be for the prepare_items function to be called more than once, and this would cause the error every time because there are unconditional function definitions in the plugin-install.php file. So, obviously the include needs to be changed to “include_once”, no?
It was causing me problems, as I reported. I have fixed it in my own copy but I also have this formerly handy little cron job on my server that checks core file integrity and replaces modified files with the “correct” versions of the current core file. I have had to disable this feature as I am now wanting to keep a modified core file on my server.
With v2.0 coming out is 1.x going to be completely abandoned or will there still be security updates and bug fixes when needed?
FYI - I prefer 1.x to 2.x and even have a well used site that runs WP v4.9.x (which is a great version and still receives updates from WordPress).
We will provide critical bug fixes and security updates, but that will end eventually.
What’s keeping you from upgrading to 2.0 when it’s out?
Blocks and FSE is gone, so is React and associated JS. Our fork merged WP 6.2 codebase with ClassicPress, so you got improved codebase without all the bloat. Plus, PHP 8.0, 8.1, and later 8.2 support.
I like WP 4.9 and so, by extension, I like CP 1.6.
I will test CP 2.0 but I am skeptical that anything based on WP 6.2 could be “without all the bloat”, and without any errors from all that slicing and dicing of the code… but I guess we’ll see
I am always hesitant to use a new version of WP on any important site for security reasons as well. WP 5.x and 6.x introduced a lot of new security holes that were not always discovered and fixed promptly. I don’t blindly trust that the newest versions are vulnerability-free, but I know 4.9 has been around long enough and received 23 updates with bug fixes and security patches so I have more confidence with the old tried and true. I don’t need PHP8 either so I’m happy to hang back and watch everyone else jump off those cliffs
Thanks for following up on this. I do hope that my bug fix for this issue will make it into the next 1.x update, of which I’m sure there will be at least one more.
I tried CP2 on a live site (because I like to live dangerously, I guess), and it’s been as close to perfect as software gets. The people doing the slicing and dicing at CP obviously know what they’re doing. As soon as we announce it’s ready for primetime, I’ll start converting other sites to CP2, incuding some WP6 sites that require plugins that don’t work with CP1.
The significant changes I saw were because of the jump in jQuery version (required some javascript adjustments here and there), with a few code updates due to changing PHP from 7.x to 8.0.
