TGM Plugin Activation Library Contributors Work Toward Feature Plugin Proposal

photo credit: Startup Stock Photos
photo credit: Startup Stock Photos

The team behind the TGM Plugin Activation Library (TGMPA) is working to propose it as a feature plugin for WordPress. Last July contributors on the project opened the discussion on a post calling for feature plugins, and the upcoming 3.0 version is being developed with this path in mind.

Developers use TGMPA to manage dependencies between plugins and themes, as an alternative to bundling a heap of plugin-type functionality into one extension. It walks users through the process of installing plugin dependencies that are required or recommended by the developer. The library is used by 6% of themes as well as a large number of commercial products hosted on CodeCanyon and Themeforest.

TGMPA will require a substantial rewrite in order to make it ready for consideration as a feature plugin. It also needs to be multisite compatible, address a number of usability issues, and be trimmed of extra features to become leaner and more core friendly.

The team behind the project has a survey open to solicit opinions from the community regarding the implementation of these changes. A few sample considerations from the survey include:

  • What method should the plugin use to supply dependency information to multisite independently of whether a theme or plugin is active?
  • How should the plugin deal with themes and plugins which haven’t yet upgraded to the newer version of TGMPA?
  • Should the plugin support plugin download sources other than

“To me it feels like we need more core team support for it to be properly considered for feature plugin status, so some lobbying behind the scenes is in order,” TGMPA lead developer Juliette Reinders Folmer told the Tavern. “The survey is also part of this as that will give us hard data to use in the discussions.”

The Future of TGMPA Is a More Modular Architecture

Folmer said that regardless of whether TGMPA is approved to become a feature plugin, future development will continue with core in mind.

“Development for v3 will be a lot more modular,” Folmer said. “TGMPA currently is effectively one file with four classes. That makes it easy to include it in themes and plugins (one file), but not as easy to maintain. As v3 will contain some big changes, this seems like a good point in time to change the structure of TGMPA as well.”

With a more modular approach in place, Folmer said that the team plans to split the package into a number of different repositories for development purposes. She has tentatively identified features that would be offered in the core module, and everything else would be supported via add-on modules, i.e.:

  • support for bundled plugins
  • support for download urls
  • support for recommended plugins

TGMPA would also introduce two wrappers – each would function as a layer that will load all the available modules:

  • one for continued support for including TGMPA in plugins and themes
  • one for TGMPA as a feature plugin

“So no matter what will be decided concerning whether TGMPA will be allowed to become a feature plugin, support for the features of TGMPA as is (but better) will be continued,” Folmer said.

“With the modular development, it won’t be as easy anymore to download ‘TGMPA’ from GitHub, as you’d need to download all the different modules (or use composer / use git submodules),” she said. “I envision the Custom TGMPA Generator to be the way forward for downloading TGMPA as a complete package in that respect.”

Can TGMPA Gain Enough Support from Core Developers to Become a Feature Plugin?

Folmer said that the WordPress core developers she has spoken with are divided on whether on whether its current approach makes it a good candidate for a feature plugin.

During preliminary discussions on GitHub, WordPress core committer Gary Pendergast expressed reservations about requiring too much user interaction during the process.

“The primary goal of plugin dependencies should be that it’s invisible to the user,” Pendergast said. “If there’s ever a point where the user is asked to make a decision, then it’s not ready for core.

“I’ve had a quick read through the TGMPA code,” he said. “I think it’s solving the problem it needed to solve (providing a drop-in library for themes and plugins), but I think we’d need to tie it much more tightly into core for it to be a feature plugin.”

Folmer hopes to address user experience concerns with refinements to the plugin based on feedback from the survey, which will be open until the end of March.

“So far, most responses have been from developers using TGMPA,” she said. “Even though the survey is quite technical, we would very much also like to hear from more end-users.”

With the recent confusion over’s previously unwritten rule banning framework plugins from the official directory, the challenge of managing inter-plugin dependencies is under the spotlight again. The TGM Plugin Activation library isn’t the only possible solution to this problem, but it does have a motivated contributor base that is willing to take up the challenge of solving this problem via a feature plugin. If you want to be part of shaping the roadmap for version 3, make sure to fill out the survey before April 1.

There are no comments

Your email address will not be published. Required fields are marked *