I cannot speak to all plugins loading even when disabled, but gravity forms is not designed for heavy usage and could well be contributing significantly to the problem.
I used to work with a large client that used gravity forms and their admin panels ( and submitting forms ) became so slow that eventually they started timing out completely.
I no longer have the details lying around, but the problem with gravity forms at the time was that when a form is submitted, gravity forms does the following:
- Loads every form that has ever been submitted
- Cycles through each one of them until it hits the end
- Uses that last submitted entry and adds one to generate the next unique id
At the time, I created a patch for the client, tested it, applied it, and submitted it to gravity forms … and never heard back. The next few times the client upgraded gravity forms, it had the same problem and I had to re-apply the patch. I finally got them to switch services.
If you are using a lot of plugins that add extra columns to the wordpress admin panels ( e.g. list posts, list pages, etc. ), I’d expect that to be at least part of the problem is that most plugin authors use queries for each item in the system to modify the list rather than modifying the appropriate admin query to include what they seek in the post results.
BIG WARNINGS
- If you are not completely comfortable with php, do not attempt this.
- If at all possible, do this on a staging server first to ensure you don’t break something
- Absolutely be sure to back up any files you are going to edit before editing them … so you can quickly put them back if needed
That being said, the only thing I can think of that could help would be to termporarily hack the wordpress core as follows:
(if running 4.1):
Enable the debug log and disable public display of errors( wp-config.php ):
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
This will create a debug log file in your theme directory.
edit wp-settings.php and find the following in lines 213 to 216:
foreach ( wp_get_active_and_valid_plugins() as $plugin ) {
wp_register_plugin_realpath( $plugin );
include_once( $plugin );
}
change it to the following:
foreach ( wp_get_active_and_valid_plugins() as $plugin ) {
wp_register_plugin_realpath( $plugin );
$start_at = time();
if ( WP_DEBUG_LOG ) {
error_log("Loading plugin {$plugin}\r\n\t Start: {$start_at}");
}
include_once( $plugin );
$end_at = time();
if ( WP_DEBUG_LOG ) {
error_log("\t Finished: {$end_at}");
error_log("\t Total Time: " . $end_at - $start_at . '(s)' );
}
}
That will only tell you if any plugin is doing something bad when first loaded.
You could temporarily do the same thing around the do_action(‘plugins_loaded’) command found in the same file at line 237, but that would only tell you how long it took for all plugins to load.
To tell how long each one takes, you could hook into plugins_loaded at priority 1, read all plugins_loaded hooks, update them all to have different priorities, and then add your own plugins loaded action to log the time stamp between each interval.
e.g.
set up all plugins so the first using plugins loaded loads at 10, the second at 12, etc … and then add your own plugins_loaded action between each one to log the time and maybe the time taken at each step:
9: started
11: 1 second (timestamp nnnnnnnnnn)
13: 0 seconds (timestamp nnnnnnn)
15: 8 seconds (timestamp nnnnnn)
I know this probably isn’t a ton of help, but it might at least let you know what the culprit is.
By using the above debug commands, you can then carefully make some temporary edits to the core wordpress files to log how long things take without having faulty plugins crash the site by showing errors on the front end.