Make plugin dependencies (suggestions) clearer in Themes Directory

[Eric3D]

More and more themes in the directory have plugin dependencies, but you don’t learn that until after you activate the theme.

I’d like to see dependencies clearly listed on each theme page, as well as having a feature filter to be able to weed out themes with dependencies.

[Otto42]

WordPress does not have "plugin dependencies" built into it. If themes have that, then the themes have to have code to add it themselves.

More to the point, themes in the directory are not allowed to "require" plugins. Per the theme submission rules, themes can only suggest plugins, they must still function without them. A theme requiring a plugin to work would be a reason to use the Report button, and have the theme removed from the directory.

[poena]

I like the idea of making it easier for users to find themes that are designed for use with and (claim too) work with specific plugins.

Right now, all users can do is search for themes that have added the plugin name in the theme description. This also leads to themes trying to pack as many keywords as possible into the description.

[Eric3D]

I usually build custom themes (from scratch or _s). When I need to get a theme from the directory these days, I find there is no way to evaluate it without installing it. A number of themes make extensive use (abuse?) of the customize feature, which now includes content as well as presentation elements. The reliance on plugins (even if not required) is another concern.

I don't have an easy fix (or even a good suggestion) for this problem. I wish I did. But a list of recommended plugins (this theme works better with XYZ) separate from the list of compatible popular plugins (tested with XYZ) would be a step in the right direction.

[dingo_d]

Possible solutions:

1. On theme upload detect if the theme has the tgmpa file, and parse the data from that, store it in meta fields for a theme and display.

2. Read the Recommended plugins: field from style.css and parse that and display only first N recommendations (similar to plugin tags) on the page.

[joyously]

I don't like encouraging plugin-specific stuff in themes. So if the readme was searchable, they could put all that in the readme.

[poena]

Replying to dingo_d:

Possible solutions:

1. On theme upload detect if the theme has the tgmpa file, and parse the data from that, store it in meta fields for a theme and display.

2. Read the Recommended plugins: field from style.css and parse that and display only first N recommendations (similar to plugin tags) on the page.

Both of these would benefit from having a feature in core where a user could one-click install plugins recommended by the theme.
Short term, I think number two is easer.

Add a new recommended plugins field to the themes API and style.css (WP_Theme class).
The value would be the WordPress.org plugin slug.

Something like this?:

Theme directory

-Get the slugs.
-Confirm that the slugs are for existing, (and not removed) plugins in the plugin directory.
-Get the plugin names and plugin page links.
-Display a list of the plugin names, linked to their plugin pages.
-Display this list below the Tags, above the Downloads Per Day.

Core

Same process as above but display it below the tags in the theme details modal.

[poena]

Theme directory display

[poena]

Core display

[poena]

Related: ​https://core.trac.wordpress.org/ticket/22316

[dd32]

Just noting, that the Theme Previewer will not be able to support required plugins, either in it's current form or any likely future form.

If required plugins for themes are added, the only real option for the previewer will be to disable the preview for that theme. We'd probably be able to enable a limited selection of plugins (like, the top 10 plugins or something)

[afragen]

We are actively discussing plugin dependencies for core in ​https://github.com/WordPress/wp-plugin-dependencies

While working on the feature plugin I created a branch the will parse a style.css file for the Requires Plugin: header. If a theme requires a plugin that theme will not be able to activate until the dependency requirement is met.

Perhaps a more current discussion is in order?

[joyously]

One of the reasons that theme cannot have a plugin dependency is because the theme can be switched at any time, even programmatically on each page request (done by a plugin). The switch affects the database in that menus and sidebars are adjusted.

The switch to the fallback for a non-functional theme only happens when an admin is on the theme page. Otherwise, a site visitor would be triggering a database write.

The look of the front end (theme responsibility) should not be dependent on plugins.

[poena]

Requiring a plugin and preventing installation, and showing which plugins the theme supports and recommends, should be considered two separate things.

As WordPress has three major releases each year, and Gutenberg has a release every two weeks, it is becoming more important that themes can indicate that it uses Gutenberg features that are not yet in WordPress core.

[pbking]

Requiring a plugin and preventing installation, and showing which plugins the theme supports and recommends, should be considered two separate things.
As WordPress has three major releases each year, and Gutenberg has a release every two weeks, it is becoming more important that themes can indicate that it uses Gutenberg features that are not yet in WordPress core.

This exactly. MOST of the themes I'm working on shouldn't REQUIRE Gutenberg. Our intent is that they work as well as possible without the plugin so we don't want to require it. But introducing a standard way to communicate that the plugin (or specifically a certain version of a plugin) is RECOMMENDED, or needed to leverage all the features the theme provides would be helpful.

Other themes might REQUIRE a specific version of Gutenberg (or other plugins) just to work (these would generally just be 'experimental themes' for me but I can certainly imagine other scenarios). That's a different thing to me. Equally important to be able to communicate (and filter on) both I think.