Roadmap TGMPA version 3.0

[jrfnl]

Main aims:

• Multi-site compatibility
• Fix conflicting UI messages for usage in themes / plugins
• Improved UI by having the admin page always in the same location
• Updatability of TGMPA independently of the plugin/theme which ships it
• Show dependencies more clearly
• Provide translations of the TGMPA strings under own text-domain.

  Basic architectural choices:

• Integration of the Plugin Dependencies (PD) plugin which will provide UI for dependency management and cascading deactivate if dependencies are not met.
• Ship as a bootstrap file + zip of the main plugin. The bootstrap will check if TGMPA is installed as a plugin and use that if possible and will fall back on the zipped version if not. By default both TGMPA as well as PD will now become required plugins. We can make the "Known Plugin Dependencies" plugin a low priority recommendation/suggestion.
• Registration of dependencies/recommended plugins should now be done through an activation hook rather than through a call on every (admin) page load. This will make the plugin leaner and will allow us to set a site option with all dependencies which can be read-out for the network admin.
• TGMPA will have it's own top-level admin page for a streamlined experience whether included in a plugin and/or theme.
• The plugin will be split into PSR-4 compliant classes.
• The new v3 version will have as a minimum requirement WP 3.8.5 (or higher if development shows we need that), PHP 5.2.4 (inline with WP minimum requirements) with the PHP SPL extension enabled (for spl_autoload).

Tentative indication of OOP direction this list is still liable to change without notice and is in addition to the existing classes:

• TGMPA_Plugin class which holds the properties passed for one individual plugin, can do property negotiation is both a theme as well as a plugin require/recommend the same plugin, will contain methods such as is_active(), has_update(), requires_update() etc
• TGMPA_Plugins class which holds the instances of all plugins and methods such as is_complete()
• TGMPA_Config class which holds the config properties passed and can do property negotiation for conflicting properties from different sources.
• TGMPA_Notices class which will generate the admin_notices if needed.
• TGMPA_Execute class which will act as a controller for requested (bulk-)actions (install/update/activate).
• TGMPA_Option class which will manage the tgmpa option which will hold the information registered on theme/plugin activate.

  Action list:

• [ ] [PD] Send in PR to Plugin Dependencies to read out theme headers and work on the theme page as well
• [ ] Integrate Plugin Dependencies plugin
• [ ] Rewrite registration of dependencies to use activation hook in combination with option + provide new example
• [ ] Differentiate how certain things work for TGMPA in plugins vs themes (i.e. which hooks to hook into for force-deactivate)
• [ ] #259 Add option for including themes/plugins to provide a rationale for requiring/recommending a plugin and #278 to add tags
• [ ] #199, #267 Allow other advise type, not just required/recommended
• [ ] Write code dealing with conflicting config/plugin info provided by themes/plugins, i.e both a theme and a plugin requiring the same plugin, but for instance, providing different download locations.
• [ ] #228, #247, #252 Refactor admin page code to work with the option and for multisite installs to show on network admin (install) and on site admin (activate)
• [ ] Add information to the admin page on which theme/plugin is requiring/recommending a plugin #199#issuecomment-56191075 - use debug_backtrace() to find the calling parent if TGMPA is not yet called using v3 code
• [ ] Write version management code to deal with v2 versus v3
• [ ] #273 Create bootstrap file
• [ ] #218 Make language strings more flexible / theme/plugin agnostic & create .pot file - make sure no language strings are in the bootstrap file or if they are, teach theme/plugin author about the .po exclude option
• [ ] Extend the (GitHub) readme & gh-pages with clear instructions on how to upgrade existing integrations to v3 (or rather link to a wiki page with those instructions)
• [ ] Create a readme, screenshots and image assets (icon, banner) for the WP repo plugin version
• [ ] Verify that a basic theme with TGMPA v3 will pass the theme check (probably should without issue as most code will be in the zip)

  Other open issues which may or may not be included in v3:

• [ ] Check if issue #276 (plugin activation fails in certain circumstances) is fixed after the refactor - most probably should/can be depending on how we hook into the PD plugin.
• [ ] Look into including #232 - notice to admin on force (re-)activation
• [ ] #274 Look into allowing for a "buy" link - I'd suggest only for recommended plugins though
• [ ] #266 Verify that user is notified of missing required plugins (after install & then manual delete) is covered by using PD (albeit in a slightly different way)
• [ ] #248 #353 Revisit the logic of the dismissable notice
• [ ] #204 Look into forced network activation but only if the required plugin is required by another plugin which is network activated. This does not make sense for themes as "network activating" them only makes them available to child sites.
• [ ] #380 Investigate including possibility of specifying a non-WP update check URL for non-WP repo plugins
• [ ] #186 Check if the angle has been taken out of this discussion by v3

  Actions once 3.0 is finished:

• [ ] Submit TGMPA as a plugin to the WP plugin repo
• [ ] Put renewed gh-pages online

  Post-3.0 roadmap:

• [ ] Set up TGMPA to be able to work with composer & create wiki page with instructions on how to set things up with and without it
• [ ] Add unit tests

[afragen]

Submit TGMPA as a plugin to the WP plugin repo

You might have problems with this. Since TGMPA can install plugins from outside of the repo it may not be allowed. You can always use GitHub Updater.

[GaryJones]

Yes, we've already received feedback that it probably won't be accepted, and utilising the code from GitHub Updater was one of the alternatives.

[afragen]

If you plan on using code from GitHub Updater, is there anything I can add to make integration easier?

[shivapoudel]

+1

[GaryJones]

If you plan on using code from GitHub Updater, is there anything I can add to make integration easier?

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.

[afragen]

It does come along with install code for GitHub, Bitbucket and soon GitLab.

However works best for you Gary.

[rilwis]

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]

@GaryJones just an FYI. PHP >= 5.3 is required for GHU. You may need/want to consider increasing the PHP requirements for TGMPA 3.0.

[jrfnl]

PHP >= 5.3 is required for GHU. You may need/want to consider increasing the PHP requirements for TGMPA 3.0.

@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. I'd rather see WP core raise the minimum requirement to PHP 5.5+ first.

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 ?

[afragen]

@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 master, and PHP 5.3 requirement, should be simple. The same would apply for a switching between a PHP5.3+ compatible version of TGMPA or any branch. Perhaps you could offer both branches as well.

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 spl_autoload_register but found namespacing to be important as well.

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.

[jrfnl]

@afragen Thanks for your offer. Will let you know if we'll need it. :smiley:

[dovy]

WP.org won't allow "frameworks" in the repo anymore. That ship has sailed I fear.

What about integrating updating as well. ;) IE, check for updates from a repo. :)

[jrfnl]

@dovy Thanks for your input.

WP.org won't allow "frameworks" in the repo anymore. That ship has sailed I fear.

They will if it's proposed as a feature plugin which is the path we are currently exploring ;-)

What about integrating updating as well. ;) IE, check for updates from a repo. :)

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).

[Remzi1993]

@jrfnl It's been 4 years already. Is this being worked on? I'm just curious.

[DeoThemes]

Looks like abandoned

[GaryJones]

There's no active development on this.

[drkdw]

Any alternative that does the same but is up to date?

[stefanofattori]

Any update? Can the authors tell us if the project is dead? Any alternative?

[GaryJones]

No active development, and it's highly unlikely to restart. WP core now contains a similar (though currently less mature) implementation that I suspect will improve over time that developers can start moving towards instead.

[stefanofattori]

No active development, and it's highly unlikely to restart. WP core now contains a similar (though currently less mature) implementation that I suspect will improve over time that developers can start moving towards instead.

Thank you so much

[Remzi1993]

No active development, and it's highly unlikely to restart. WP core now contains a similar (though currently less mature) implementation that I suspect will improve over time that developers can start moving towards instead.

Please archive this project on GitHub, this will send a signal that the plugin is no longer maintained. Something I also did for a WP plugin I'm no longer maintaining.

[theamnesic]

No active development, and it's highly unlikely to restart. WP core now contains a similar (though currently less mature) implementation that I suspect will improve over time that developers can start moving towards instead.

"Themes that require plugins are not supported by Plugin Dependencies at this time, and theme authors should continue to use the checks and messaging that they have in place."

😕