Move updater class to separate library?

[mindctrl]

The wp.org plugin review team is denying a plugin with this client included because of the custom updater class. Would you be willing to move that functionality into a separate library so this client can be used for the other features it contains?

[saiftheboss7]

Yes we're working on a solution for this.

[ChrisWiegman]

Hi @saiftheboss7, is there any chance you have a timetable on this?

[saiftheboss7]

We're currently discussing with the org team is the updater is not in direct conflict with org rules as this is an SDK and by default we give out the code without updater everywhere.

If the the org team doesn't get convinced we'll make the changes asap

[jasonbahl]

Any update here? I have a plugin that's been approved for release on WordPress.org, other than the existence of the Updater.php class (even though I'm not using it)

At the moment my options are:

• Remove Appsero altogether from my plugin (this is what .org is suggesting)
• Have a script that installs the Appsero Composer dependency, then overrides the Updater.php class during the plugin bundle workflow
• Wait for a formal solution from Appsero

If option 3 is coming soon, I'll wait. If there's no ETA (understandable if there's no clear timeline), then I'll probably work on option 2.

Thanks! 🙏🏻

[saiftheboss7]

@jasonbahl Option 3 is coming soon. We've done the initial discussion with org team and planning to remove the update to a separate class. As this is a big change for us we're working on it

[jasonbahl]

@saiftheboss7 Thanks for the update! I'll keep my eyes out for an update. Appreciate it! 🙌🏻

[saiftheboss7]

We've separated the Appsero Updater class to a separate library. Here's the Updater separated. We're going to make the Appsero client without updater class in the next release

@mindctrl @ChrisWiegman @jasonbahl

[saiftheboss7]

Latest update to the client solves this issue with the introduction of a separate Updater repo