Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Basic architectural choices:
Tentative indication of OOP direction this list is still liable to change without notice and is in addition to the existing classes:
Other open issues which may or may not be included in v3:
Actions once 3.0 is finished:
Ideally, we wouldn't need it, but I guess we just need to be able to install just our plugin (no themes, no other plugins) from a GH tag, so it would only need to be a subset of GU, which is why we may just incorporate the credited code we need instead of the whole GU codebase.
Just saw this from WPTavern. This is a great news! Thanks for the improvements!
By the way, Chip Bennett from WP.org commented on the article at WPTavern that you should suggest this plugin as a Featured Plugin which then can be integrated into WP core. If it's done, it will be a great outcome for all developers.
Hope you consider this.
Thanks for amazing script!
@afragen That's good to know. We don't currently intend to raise the minimum PHP version in favour of staying in line with WP core. If TGMPA's minimum would be upped, it would also mean that all themes and plugins using TGMPA would need to up their minimum PHP version and for now, I think that would be a bridge too far.
If it would turn out that we'd need to go down the GHU road, would you be open to a PR making GHU compatible with PHP 5.2 ?
@jrfnl for TGMPA I will create a branch that is PHP 5.2.x compatible if you would require it. GHU has a built-in branch switcher so if a PHP5.2 compatible branch is made, switching back to
Though I understand wanting to maintain core compatibility, core isn't planning to update the requirements until more and more hosts update their versions. By incrementally requiring more current versions of PHP we can encourage hosting companies to upgrade.
I can understand existing plugins like Yoast or EDD that have a paid ecosystem not wanting to raise their requirements but TGMPA isn't a premium product or is it. The fact that it is widely used by premium products is a bonus for pushing hosting companies to upgrade their PHP versions. Honestly, as GHU is primarily used by and for developers, I really didn't think twice about moving to PHP 5.3 so I could add namespacing and autoloading. I did previously use
I actually upped the PHP requirement of my The Events Calendar Category Colors plugin in the .org repo. This plugin has more than 5000+ active installs and over 50,000 downloads and is an add-on for The Events Calendar. After, creating an error message that was more descriptive of why it may not work, only a couple of users reported issues and did get their hosting companies to upgrade.
As TGMPA 3.0 is an entirely new shift, from adding a class to a plugin, it really is the best time to up the requirements. Please reconsider but if not I will make a branch that is PHP 5.2 compatible.
@dovy Thanks for your input.
They will if it's proposed as a feature plugin which is the path we are currently exploring ;-)
Updating bundled plugins and updating from the wp.org repo already works (included in v2.5 which was just released).
Checking for updates from an external repo is a difficult one, but is being considered (#380).
The issue with that is that there is no uniform response format for indicating that there is an update available (unless the external repo spoofs a wp.org type response like the https://github.com/YahnisElsts/wp-update-server/ library in combination with https://github.com/YahnisElsts/plugin-update-checker does).