This article is about my thoughts on different scenarios regarding the moment when a WordPress theme adds plugins suggestions in a clear and useful way.

I think the whole WordPress community raises a strong need for a visible and clear relationship between plugins and themes. I came across situations when a theme adds a style for a certain plugin, but the same WordPress doesn’t offer a clear way to tell us “What plugins can I use with this theme?“

Why should WordPress add theme suggestions for plugins?

In my opinion, this is a good topic to sleep one since the latest debate in the WordPress community regarding the moment when the Zerif theme was removed from the wordpress.org.
After a deep review, admins discovered that the theme has plugin-territory code and features which should not be set inside a theme.To be more explicit, Zerif creates some minimal content for the home-page. Thanks to Ionut Neagu for the heads up.

Let’s imagine a scenario when a theme registers a custom post type, such as a testimonial, all the content held by it depends on the theme. This behavior is completely wrong since a user will lose all the content when he takes the decision to switch to another theme. A proper solution is to register the custom post type from a plugin, but keep in mind that the theme should recommend that plugin.

This behavior is completely wrong since a user will lose all the content when he takes the decision to switch to another theme. A proper solution is to register the custom post type from a plugin, but keep in mind that the theme should recommend that plugin.

 Current solution?

Well, the WordPress community knows this issue, and maybe this is why a library called TGM Plugin Activation gained so much popularity that nowadays when you say “recommend plugins in theme” you automatically say “TGMPA.“
This is the WordPress approach when something isn’t touched by the WordPress core. It will always be proposed or implemented by the open-source community via plugin/library / CLI.

Now, please don’t get me wrong. I’m not saying that TGM is not a good solution, I’m constantly using it myself, but:

  • It is not a genuine WordPress feature, and some users aren’t confident with it.
  • It is hard to keep it up to date. When a core feature has an issue it is modified with the core; this library must come with a theme update which is again, an update feature = plugin-territory.
  • It replicates a separate page, outside of the plugins list page, for plugin activation, installation, etc. Duplicating features is not a WordPress thing, always use WordPress functionality and features first, if available.
  • A personal one, it always messes with Theme Check requirements.

Let’s find a real solution and build it!

My honest desire is to take this subject to the next level of conversation and implementation as well. As you may know, the plugins and themes relationship is already a big deal in the WordPress ecosystem, but now I guess it became a true requirement.

Every guideline tells us explicitly to separate features from view, even if we talk about Codex, Envato, wordpress.org they all sing the same song: keep out functionality from view/template.

We already have a way to ask a feature from a theme.There is a function which says “Hey! This theme supports the X feature.” The function is, <a href="https://developer.wordpress.org/reference/functions/add_theme_support/">add_theme_support</a> and it is present in:

  • Default Twenty themes (and others) when they call core features like Custom Logo or Custom Header Image.
  • Every WooCommerce theme like which want to declare support for this plugin must use add_theme_support( ‘woocommerce‘ ).
  • Soil plugin where they ask modules with this function.

Here’s the place where I recommend to dig deeper. This functionality can help us see which plugins can work nicely with the active theme, and which not. Maybe something like this could make the trick:

add_theme_support('my_recommended_plugin_slug');

I don’t say this is the best way to implement the “asking.” A better solution could be a separate function like “add_recommended_plugin” or something else, I’m just theorizing here (or playing with the trial-and-error approach).

However, in my humble opinion, a list of plugins supported by the active theme is mandatory.

theme-suggestions-list

Also, the brand new Shiny Updates V3 should bring a great user experience while adding plugins suggested by theme.

theme-suggestions-add

 

Still, what I say is a pure theory. But hey! Hopefully, I will have the guts to open a track ticket on this subject.