PHP Compatibility Checker Error Messages

Hello @lydianas. Since the plugin is performing “local linting” some plugins / themes will time out in some environments as you noted. To help avoid this we recommend you run this plugin in a local version of WP. You can check out localwp.com (free) for a quick way to create a local version of WP.

As for your question on if your site is ready to be upgraded to the latest version of PHP, you can try to run the plugin on a local copy of WP as mentioned above, but at the end of the day this plugin only surfaces PHP linting errors which may be a problem for your site.

You can also ask your host to load a copy of your site onto a server with a current version of PHP to test the copy to see if it works as expected. This plugin can give you clues as to things that might break, but at the end of the day you’ll still need to review / these the site manually when it’s on a server with updated PHP.

BTW, if you’re a WP Engine or Flywheel customer, we give you a few tools to do this testing and our 24×7 support can also help you directly.

Good luck!

So basically you are no help at all to anyone then.

You have a bug in the file wpephpcompat.php. In the function add_directory, when the path is saved to the post content it loses the back slashes so that the path to the folder is then invalid. This causes it to skip those plugins or themes with the above error.

I have corrected it thus:

private function add_directory( $name, $path ) {

$path = str_replace(‘\\’, ‘/’, $path);
$dir = array(
‘post_title’ => $name,
‘post_content’ => $path,
‘post_status’ => ‘publish’,
‘post_author’ => 1,
‘post_type’ => ‘wpephpcompat_jobs’,
);

return wp_insert_post( $dir );
}

A pretty brutal hack I admit but I have a fixed deadline to meet and no time to mess about. I hope this helps someone else. Have a nice day now.

• This reply was modified 4 years, 3 months ago by internationaltyres.

You have another issue with the plugin. I had this message posted to debug_log: [31-Jul-2020 15:09:34 UTC] Uncaught exception: Call to undefined method PHPCompatibility\PHPCSHelper::findStartOfStatement()

Then there is a var_dump of a HUGE object to the log file! This I can’t fix as I have no idea what should be in the missing function. I downloaded this plugin directly from your plugin page. Do you think it is acceptable to release a broken plugin out into the world?

This was first reported in August 2019 here https://github.com/wpengine/phpcompat/issues/245

This still isn’t addressed! Take the plugin down. You are embarrassing yourselves.

I don’t like to jump on a bandwagon, but feel a need to add a comment that I don’t see in the many threads about this issue.

The recommendation in every thread is to run the same code in a different environment, preferably FlyWheel. OK, so what is it about the FlyWheel environment that is configured differently from everything else? If we know what default/modified FlyWheel configuration is the magic saviour to avoid this error then many of us would gladly make that same change wherever we are already running our plugins. But it’s already been reported that a site hosted in FlyWheel DOES still report the same error, so that Hail Mary didn’t score.

Let’s just figure out where to look for an error report, if one has been logged. The WP debug.log? HTTP logs? PHP logs? System logs for CPU or Memory? We have no clue what the fundamental problem is here, only the cryptic message that “the server killed the process” … and I have to wonder at this point if that’s actually an accurate report of whatever is happening.

So again, please WP Engine: you don’t need to fix the problem. Just tell us what it is and we’ll accommodate … Add more RAM to the system? to PHP? to Apache? Run on more CPU threads? Or might this be an issue with wp-cron needing an occasional ping while the process is running?

Thanks.

I presented this issue to the folks at WPMU DEV, where I am a very happy member. Patrick Freitas at WPMU DEV Support took on the challenge and quickly determined that the problem is 100% CPU usage. This eliminates the wondering about whether this is memory or a configuration issue with PHP or Apache.

The one and only suggestion in this forum by WP Engine to use FlyWheel (now owned by WP Engine) to get around this issue, is a sort of red herring. The solution (offered for over a year on this topic) isn’t “FlyWheel”. The solution is to run this otherwise/formerly fine industry-trusted plugin on a system that has a really powerful CPU/GPU. The environment (Docker/vmWare/WAMP) probably doesn’t matter – it’s the hardware/resources allocated to the (virtual/real) machine.

Will multi-core processors work better? Probably not as multi-threaded PHP has always been a challenge. It’s possible that throwing a ton of RAM at the problem (and PHP/Apache config files) might help, if there is something in this plugin that is causing thrashing due to limited memory allocation … but I’m kinda doubting that’s the case. I believe it’s possible to get your system to run specific applications over a GPU rather than the CPU, and I would bet that would show dramatic results with this plugin in WordPress.

In summary, I think one possible solution for people to try is to run this plugin in a system with a very powerful CPU/GPU, where there are no other applications competing for resources. Try that and post comments here for others.

I am having the same problem. I have run a compatibility test on two different plug-ins and each have the same issue.
I get “The plugin/theme was skipped as it was too large to scan before the server killed the process.”
for the following:
Elementor
Elementor Pro
Real Estate Pro
UpdraftPlus – Backup/Restore

And a warning on Photonic “46 | WARNING | Global with anything other than bare variables is discouraged since PHP 7.0. Found ${$mod_key}
683 | WARNING | Global with anything other than bare variables is discouraged since PHP 7.0. Found ${$option}
766 | WARNING | Global with anything other than bare variables is discouraged since PHP 7.0. Found ${$option}”

I am not a developer. Totally new at building a website. But I have been deep into learning how to do it and have been at it for almost 2 months. Now this required update is being given and I have zero idea what to do. My entire site is built with Elementor – so it seems this is an issue.

Thought wordpress is to be beginner friendly. This seems super complicated. Have been reading forums on this issue and it doesn’t seem like there is ever really a solution given.

Hello @starbuck. Thanks for your research and for sharing that information here. We (WPE) have reached some similar conclusions; however, we are trying to isolate the full root cause(s). This issue does not happen with every site, plugin, or even every host so it’s a bit tricky. To your point, throwing CPU at the problem will likely resolve this issue for some users; however, that might no wholly be true.

In many cases the failures seem to tied to environment-specific variables that might be at play with any particular host (e.g. timeout settings, etc.). Perhaps as you pointed out, identifying and documenting what the required CPU, memory, and environment variables are (if those are the true root causes) would be helpful.

In the end, this has been a huge game of whack a mole to find an approach that will resolve the various issues, and some issues (like timeout settings on random hosts) we might not be able to overcome without a major shift in approach. We are exploring all options here including possibly taking a side-linting approach in the future (TBD on what that might look like).

Relative to Local, while we have seen less cases of failures in Local, the recommendation to test with Local in various cases is based on three POV…

1. In general, running linting on your production WP instance is not the best idea. For those without access to staging with their host, Local is free option to do that.

2. If the plugin is experiencing host-specific issues like timeout settings, running in Local (or similar) may resolve the issue for the user.

2. Many users of the plugin are just trying to test their site for PHP X compatibility and don’t really know how to use the plugin (e.g. interpret the results, fix errors in the results, or determine if the errors are critical to the functionality of their website). In some cases, we have recommended folks functionally / visually test their site in a PHP X environment instead of linting with the plugin. For users who don’t have a hosting account that supports PHP X staging for their site, we’ll recommend Local which does support choose-your-own-PHP.

I know the errors are frustrating and the time to address has been excessive. For those who are experiencing these issues, we’re working on figuring out an approach that will hopefully provide a wholistic answer to this issue.

In the meantime, and for the benefit of those experiencing this issue, we’ll publish some recommendations on alternative methods for running linting on your site.

If you have anything else you’d like to share about your research and testing, please do! ??