davidvee

Ouch. That sounds like a lot of trouble shooting you’re doing to isolate all that. I’m not hearing of other similar crashes and our deploy processes tested the plugin running in 5.6 and 7.3. That being said, it sounds like PHPComp is running in 5.6 for you and you’re trying to run the linting to see what might break when you’re in 7.3. That being the case, you can disable PHP Comp in your 7.3 environment after you’ve run the linting in 5.6 of course.

That doesn’t help you for future linting with the plugin (e.g. if you want to run it in 7.3 for future 7.4 compatibility), but that approach should get you what you need for now. Sound about right?

I’m also wondering if this is host / environment specific. What host are you using?

The plugin will run in 5.6 and check for 7.3 compatibility. So long as there’s nothing on your server preventing it running, it should be fine.

As an FYI, the plugin is only checking for linting failures so any errors it flags may not mean the site will actually have problems. As another option, you can also just install the site in a 7.3 staging environment and run your normal tests on the site to see if it works. You’ll have to do that even if the site passes the linting ??

BTW, if you end up considering a local development environment in the future, I’d recommend you check out “Local by Flywheel”. It’s free and super easy to use… https://localbyflywheel.com/

The plugin can be used on any platform. It’s not WPE dependent.

FYI, our DevKit solution can also be used for sites intended for any platform. Local by Flywheel is also good for a local dev solution.

In any case, that’s not what you need help with ??

As you pointed out, the plugin causing runaway processes when scanning some plugins is different than “activating” the plugin. That’s actually news to me, but may be a known issue by others here especially if it has been mentioned in other threads.

I’ll surface this with the dev team working on this plugin so they’re aware.

For the sake of clarification, have you tried running it locally? Did you have a similar experience?

Hey @hommealone. The plugin does work in a 7.3 environment, but in some cases some plugins can cause the linting process to stall out. We’re currently investigating a fix for this. In the meantime, and regardless of a fix, we recommend you run the plugin in a non-production environment. Have you tried running it locally? WP Engine’s DevKit would be the best way if you’re on WPE, as that will help make sure the environment variables are the same. I hope that helps ??

Hey @ocee47. Please note that errors on scans are only syntax warnings and may NOT mean that the plugin doesn’t function within any particular PHP version. Have you tried testing the plugin in a PHP 7.3 environment?

Thanks for this feedback. We’re looking at ways to correct this behavior, but it’s a difficult problem to solve due to architectural concerns. Running the scanner in a local dev environment can often help here, so you might try that.

Again, we’re looking into how to improve this in the future, but a running in a local environment should help ??

There has been! We’ve resolved the platform compatibility issues that caused WF to be added to our disallowed list, but now need to remove it from our “reaper” that removes disallowed plugins from our platform. That work may already be complete, but I need to verify that with our engineering group before calling this one done. Almost there!

The team is working on this now. I’m personally checking in on progress and supporting where I can without interfering in their work ??

Sorry again for the delay!

Hola @javierrguez.

I work for WP Engine. I’m sorry that I don’t speak Spanish so I’ll have to reply in English.

The plugin does work with 5.2.1; although, some plugins in the scans can cause the plugin to stall out regardless of versions. I suspect that’s what is happening here.

We have a team working on a fix right now along with adding support for PHP 7.3.

We’re expecting an update for the plugin within weeks and not months.

If you have any other errors to report or questions, please let me know.

?Gracias!
David

Yep. Definitely on the list. Sorry again for the poor maintenance practices here. We’re on it!

Hey @phillipburger it is tested for the current version, but not in the way that would reflect that on .org (obviously). That being said, we’re working on an update now that will fix that along with the scans hanging on certain plugins and support for PHP 7.3. We’ve also shored up our resources to stay ahead of this in the future. We expect the current update to hit in weeks, not months as we have a team doing the work now ??

Hello all. This is David with WP Engine here. We have a team currently working on the hang up issue related to certain plugins as well as adding support for PHP 7.3.

We expect the update in weeks, not months.

Sorry for the delay on this. We’ve shored up our maintenance resources here to keep up with updates, bug fixes, and support tickets more aggressively moving forward.

Thanks for your patience, and please let us know if you have any more questions or comments.

@sleeplessindc thanks for reporting this. We have a team currently working on the hanging plugins issue now and are expecting an update in the coming weeks. Sorry for the delay, but we’re actively working on it now. If you have any other questions or suggestions, please let us know!

Hey @dave333 and @sandbug7. I’m so sorry this ticket has gone unanswered for so long.

We have a team assigned to help resolve the stuck process issue and to complete the addition of 7.3. They’re actively working on these items and we expect an update in weeks, not months.

We’ve also made sure to dedicate additional resources to ensure more prompt maintenance & .org support ticket responses for PHP COMP in the future.

In the mean time, we’re focusing on fixing the cases of runaway processes as well as adding 7.3 in order to get a release out as soon as possible. Sorry again for the trouble.

As a reminder… It’s best to run PHP COMP in a development or non-production environment so that you do not introduce the load of code scanning on your production environment (stuck process or no). Of course, as a ~linting tool PHP COMP is purpose built to be used to vet code before pushing live.

I’m guessing you all likely know that, but I wanted to note it for the thread.

If you have any other questions, please let me know!

Hey MD. We’re actively working on a fix for these types of failures along with adding in 7.3. I don’t have a precise ETA, but it’s weeks away and not months.

In the meantime, and as always, our recommendation is to not run this ~linting plugin inside a production environment, but rather run locally or in another non-production environment (dev / staging copy of your site) prior to pushing to production.

This should help you avoid any server related issues from killed processes (or non-killed ones) and of course, it’s better to tax a non-production environment with the workload of scanning code vs. using your production server for that. Additionally PHP COMP is designed to be a workflow tool to vet PHP compatibility before pushing to production, so it’s best used before you push live.

In any case, I hope that was helpful. We’ll be updating documentation and the support forums when the new version is released with the fixes mentioned above and the addition of 7.3.

I’m sorry to hear that you’re still experiencing the errors, but we’re working now on a fix for these cases. Thanks for letting us know!