No result for large plugins/themes

Hey Rita,

We have some workarounds that might help on our FAQ:

Give this a shot:

Some servers have timeouts to prevent long running queries, this is commonly 60 seconds. This can prevent the checker from being able to process large themes or plugins. You should check with your host to see if this timeout can be temporarily removed. The best way around this timeout issue is to run this plugin on a local copy of your site, or you can use the WP-CLI command.

You can use the filter wpephpcompat_scan_timeout to customize the scan timeout. See this for an example.

Setting the timeout to 0 disables the cron/timeout.

@taylor4484,

Rita is right…this is an issue.

The best way around this timeout issue is to run this plugin on a local copy of your site, or you can use the WP-CLI command…

1. I’m a developer, so asking me to run it on a local copy of my site would be fine, however, that is not something the average user would know how to do. You guys claim this was written for developers, however you fail to realize that your main demographic is average joes, not developers. Asking folks to run this on their local machines is a non-solution for most people.
2. Additionally, it’s likely to be make the issue worse in most cases. Even with a really beefy tower setup, in the vast majority of cases, running PHP (even PHP 7) on a local machine is many times slower than running it on a commercial webserver, and timeouts can still happen. They are vastly different calibers of machines. For most users, this is a terrible solution.
3. WP-CLI command – Again, this is not something that most users will know how to do, only developers. Advising folks to do this… excludes the majority of your plugin’s users, so again, not a real solution.
4. Using a filter – Again, something only us developers would know how to use…so giving this as a response to the majority of your users…is not being user-friendly.
5. You guys need to take responsibility for fixing the code. There are ways around timeouts. You may have to optimize your code, benchmark, debug, break things up into smaller chunks and run in sequence, etc. There are ways to do this. That’s not very friendly to put it on the user to fix.

I agree completely.
I’m not a developer but I have some technical know-how and yes I have a local copy. But the PlugIn is also responding with timeouts there.
After some analysis I’m not willing to spend more time in WP-CLI or other stuff not needed for web design.
I just want to check if website can be migrated to PHP7 to improve performance.
Please consider to solve timeouts.

Hi @ritahoock,

But the PlugIn is also responding with timeouts there.

Exactly. The “use a local copy” response was a bit ignorant IMO.

If you want to check for PHP 7 compatibility, the easiest and quickest way to do so is with XAMPP and WP_DEBUG. (WP_DEBUG is a diagnostic mode built into WordPress.)

If you don’t have PHP 7 on your local machine, then you can install XAMPP – choose the PHP 7 version. (There’s a number of other ways to install locally, but that’s a quick one.) If you already have PHP 7 on your local machine, then skip that step.

The proper way to use WP_DEBUG is the following:

First back up your wp-config.php file, then open it up in a text editor.

Look for the line that says define('WP_DEBUG', false); and replace it with:

/* Turns WordPress debugging on */
define('WP_DEBUG', TRUE);
if ( defined('WP_DEBUG') && TRUE === WP_DEBUG ) {
	/* Tells WordPress to log everything to the /wp-content/debug.log file */
	define('WP_DEBUG_LOG', TRUE);
	/* Doesn't force the PHP 'display_errors' variable to be on */
	define('WP_DEBUG_DISPLAY', FALSE);
	/* Hides errors from being displayed on-screen */
	@ini_set('display_errors', 0);
}

When you’re done debugging, just change define('WP_DEBUG', TRUE); to define('WP_DEBUG', FALSE);. Most people only know about the first line define('WP_DEBUG', TRUE); , but that would turn on visible error display in your site, which is not desirable for a production (or test) site, as you can imagine. Adding the next few lines writes it to a log file instead, so it’s a very clean way to use WP_DEBUG.

Then activate the plugins and themes you want to test and see if there are any errors. Information will be logged to /wp-content/debug.log. The errors will tell you if your site is truly PHP 7 compatible or not. And, it will be 100% accurate, since your tests were run on PHP 7.

• This reply was modified 8 years ago by blackhawkcybersec.
• This reply was modified 8 years ago by blackhawkcybersec.
• This reply was modified 8 years ago by blackhawkcybersec.

tl;dr

basically if you’re not willing to test it locally or if you don’t know what WP-CLI command is, you’re screwed?

I deactivated all but 4 plugins (contact form 7, askimet, php compatibility checker, and wp crontrol) and I’m getting “The plugin/theme was skipped as it was too large to scan before the server killed the process.”

As this issue still exists although it is marked as resolved my solution is not to use this plugin any more.

Yeah I gave up on it too.