Add an extension point for adding tabs to the "Add Themes" screen, matching install_plugins_tabs on the Plugins screen

[elmastudio]

The gap

The Plugins screen (wp-admin/plugin-install.php) has a supported way to add a new tab: the install_plugins_tabs filter. WooCommerce already uses exactly this to add its own "Marketplace" tab — it's an established, working pattern.

The Themes screen (wp-admin/theme-install.php) has no equivalent. It's built as a Backbone.js application rather than a list table, so it doesn't share the Plugins screen's filter-based architecture. Today, the only way to add a tab there is DOM manipulation after the page loads — fragile, since any future change to the screen's markup can silently break it, and every host or plugin doing this has to maintain and re-test that fragility on every core release.

Proposed change

Add an analogous extension point to the Themes screen — a filter such as install_themes_tabs, mirroring install_plugins_tabs — so a tab can be registered without touching the DOM.

Why this isn't just "easier for us"

This gap isn't WordPress.com-specific. Any host or theme-marketplace plugin that wants to surface curated or commercial themes inside wp-admin hits the same wall today — Plugins has a clean path, Themes doesn't. WooCommerce already validated this kind of extension point is useful and safe on the Plugins side; this closes the same gap on Themes rather than introducing a new pattern. Without it, the only paths available to anyone wanting this are: don't offer it in wp-admin at all, or DOM-hack it — which is worse for every WordPress site involved, since it's exactly the kind of customization most likely to break silently on a core update.

On the abuse concern

An added tab is opt-in and additive — it doesn't change the default theme listing, search results, or ranking that every other tab shows. It's the same shape of extension already shipping on Plugins, where no abuse pattern has emerged. Guardrails Core wants — e.g. requiring themes_api() for the tab's data, or reserving certain tab slugs — can be scoped into implementation rather than blocking the extension point itself.

Prior art: install_plugins_tabs (wp-admin/includes/class-wp-plugin-install-list-table.php), used by WooCommerce's Marketplace tab on Plugins > Add New.

[audrasjb]

Hello and welcome back to WordPress Core Trac!
This sounds like a good idea, and it would add consistency with the plugin screen, too.
However (and unfortunately) the Themes screen is way different than the Plugin screen, and the implementation has to be completely different. But I think it's worth trying something here.

[pbiron]

Actually, there is (and has been since 2.8.0) an ​install_themes_tabs filter.

However, it's used for a different purpose: it's only use to filter out the "Upload Theme" button. See wp-admin/theme-install.php#L179. All of the existing tabs are, indeed, hardcoded in wp-admin/theme-install.php#L212.

I agree that having a filter for the theme install screen that mimics the one used for the plugin install screen would be a good idea.

Whether that functionality is implemented with a new filter or using the existing install_themes_tabs filter is a matter that will need to be discussed.

[poena]

The reason why I would be reluctant is this comment:
"surface curated or commercial themes inside wp-admin"

Is this really what we want? More advertising?