I thing I found the problem after some testing. If I change the line at class.jetpack-modules-ist-table.php:4 from
require_once ABSPATH . 'wp-admin/includes/class-wp-list-table.php';
to
require_once ABSPATH . 'wp-admin/includes/admin.php';
it loads and list the modules.
I have learned that you shall never include admin things directly this way, because you loose dependencies. You must load the complete /wp-admin/includes/admin.php to get it right.
Class Jetpack_Admin is completely refactored, it seems. I guess Wp_List_Table now is loaded earlier than before.
Next question is: Why did it fail on just these sites and not the 38 other sites I manage using Jetpack?
I found another plugin using the same include method for the WP_List_Table. Changing that plugin to include wp-admin/includes/admin.php instead makes that one and Jetpack work together.
If either of these plugins include class.wp-list-table.php directly, it fails. So this is not a true plugin conflict, I think. It seems that, if any plugin includes the class directly, and there are at least two of these active, it will fail.
I don’t know how common it is to use WP_List_Table among plugins. If it is, and I am right, it should be many reports. So I may have misunderstood something.
What version of WordPress is running on the sites that failed?
Knut,
Thanks for the report. To confirm, you’re only seeing it when two plugins are both calling class.wp-list-table.php directory, or simply when any plugin does so?
As mindctrl asked, what version of WP and what’s an URL of an impacted site?
I always use WP version field when creating a new thread, so it is 3.9.1.
It seems to fail when two plugins both need the class, he first plugin loads the class directly by including the class file, and the next one only includes a file dependent on whether the class already exists or not. The one who loads it first will miss the dependencies upon global functions, but this plugin may not call any of these itself, so the wrong doing may not be detected when there is not other plugins using the class. Then the class already exists, and the next plugin that uses any of these functions will cause the fatal error.
This comment form Nacin talks about the frontend, but it seems to be relevant even in the admin area.
This is an interesting one, Knut.
What’s the other plugin you’re using to trigger this? I whipped up a quick dummy one and couldn’t duplicate. I’ve started writing up a report for GitHub for deeper dive, but would like to see it myself if possible.
Thanks for the work to nail it down.
The plugin in this case is not a public one, but a large tailor made one, in which the list table is not the core thing.
It used to require_once ABSPATH . 'wp-admin/includes/class-wp-list-table.php'; at plugin include level (global scope) when the WP_List_Table was not previously defined, just as Jetpack does.
I may try to isolate the problem further, using a demo plugin.
