Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Roadmap TGMPA version 3.0 #394

Open
27 tasks
jrfnl opened this issue May 6, 2015 · 17 comments
Open
27 tasks

Roadmap TGMPA version 3.0 #394

jrfnl opened this issue May 6, 2015 · 17 comments
Assignees
Milestone

Comments

@jrfnl
Copy link
Member

jrfnl commented May 6, 2015

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:

Other open issues which may or may not be included in 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
@jrfnl jrfnl self-assigned this May 6, 2015
@jrfnl jrfnl added this to the 3.0.0 milestone May 6, 2015
@afragen
Copy link

afragen commented May 7, 2015

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
Copy link
Member

GaryJones commented May 7, 2015

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
Copy link

afragen commented May 7, 2015

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

@shivapoudel
Copy link
Contributor

shivapoudel commented May 7, 2015

+1

@GaryJones
Copy link
Member

GaryJones commented May 7, 2015

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
Copy link

afragen commented May 7, 2015

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

However works best for you Gary.

@rilwis
Copy link

rilwis commented May 8, 2015

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
Copy link

afragen commented May 8, 2015

@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
Copy link
Member Author

jrfnl commented May 8, 2015

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
Copy link

afragen commented May 8, 2015

@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
Copy link
Member Author

jrfnl commented May 9, 2015

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

@dovy
Copy link

dovy commented Jul 7, 2015

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
Copy link
Member Author

jrfnl commented Jul 8, 2015

@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
Copy link

Remzi1993 commented Jul 11, 2019

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

@DeoThemes
Copy link

DeoThemes commented Feb 9, 2021

Looks like abandoned

@GaryJones
Copy link
Member

GaryJones commented Feb 12, 2021

There's no active development on this.

@drkdw
Copy link

drkdw commented Mar 28, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants