Rename the WP_Background_Process

[vmanthos]

Other plugins, e.g. the GP Premium plugin are using Ashley's Rich WP_Background_Process.

To avoid conflicts with such plugins, it would be best to rename our own version of the background process.

Gravity forms is already doing this: GF_Background_Processing.

Possibly related ticket:
https://secure.helpscout.net/conversation/1003908985/131066?folderId=2135277

[GeekPress]

We will try to fix something which must be fixed by other plugins.

I mean, if other plugins are doing a correct check about if WP_Background_Process is already included, we won't need to do a trick like that.

[vmanthos]

The class we are using is a modified version of the original one. Remy has changed three methods.

This means that other plugins will probably have issues if our version is loaded first.

Also, in the case I'm checking, partial preloading doesn't work and the wp_options table has a lot of entries written from WP Rocket. Although I haven't gotten to the bottom of this yet, it's certain that GP Premium's class is loaded before WP Rocket's and our task() method, and whatever follows, don't run.

Currently, the only solution is to ask the customer to disable the conflicting plugin, which isn't always an option. Renaming the class is relatively easy and will:

• Prevent our customers from having such hard to figure out issues reducing, at the same time, the number of tickets.
• Other plugins won't have conflicts because of WP Rocket.

Of course, @Tabrisrp has the final saying in this.

[remyperona]

We're kinda at a point where we need to re-assess if this library is the right one for the job, and if some new ones developed since might be better. Especially since WP_Background_Process seems to be no longer maintained at all.

Actions Scheduler could be an alternative, especially since it's supported by Automattic now.

[vmanthos]

I have confirmed that the issue I mentioned earlier was due to the common class name.

I'm documenting here what I did.

To troubleshoot this I've installed a WP Rocket version on the website, where I replaced:

• WP_Background_Process with WPR_Background_Process,
• WP_Async_Process with WPR_Async_Process and
• the nonce $query_arg from nonce to wprnonce.

I had to delete_site_transient( 'rocket_partial_preload_process_lock' ) because the process was stuck into a lock state due to the previous failures.

[vmanthos]

There is a PHP library, Mozart, which composes all dependencies as a package.

This could resolve issues such as this one, where the same library is used by other plugins/themes, by having them under our own namespace.

One limitation to consider is that Mozart requires PHP 7.2 or higher in order to run.

[GeekPress]

@hellofromtonya If you have some insights to share about this situation, you are welcome :)