ThemeSwitcher Pro 1.6 is here, and it closes one of the last real gaps in running more than one theme on a single WordPress site: editing those themes in the Site Editor.

If you’re new to the plugin, here’s the short version. ThemeSwitcher Pro lets a single WordPress install serve different themes under different conditions, one theme for your blog, another for your documentation section, a third for a campaign landing page, or any condition you can express as a boolean. No multisite. No subdomains. No duplicate content. Just the right theme for the right context.

That works beautifully on the front end. But WordPress’s admin has always assumed your site has exactly one active theme, and block themes made that assumption a lot harder to work around. The Site Editor opens whatever theme WordPress considers active, which on a site running conditional themes, is frequently not the theme you’re actually looking at. Version 1.6 fixes that.

Edit the theme you’re actually looking at

The headline change is a new Edit Site link in the front-end admin bar. Browse to any page served by a switched block theme, and the admin bar now offers “Edit Site” labeled with that theme’s name, so there’s no guessing about which theme you’re about to edit. Click it and the Site Editor opens against the correct theme.

There’s a Navigation shortcut nested under it too, for the single most common reason anyone opens the Site Editor in the first place.

Under the hood this is doing more than adding a link. ThemeSwitcher Pro now resolves which block theme is genuinely in play for the current view, persists that choice through the handoff, and loads the Site Editor against it. The result is that the Site Editor stops being a dead end for multi-theme sites.

Hybrid classic and block sites finally behave

Plenty of real sites are mid-migration: a classic theme still running the main site, a block theme handling a newer section, or the reverse. On those setups WordPress makes a single global decision about which admin screens to show. Because block themes don’t use classic menus, WordPress hides the Appearance → Menus screen, even when a classic theme is still the one your site depends on. Sites in this state have historically had to reach for a direct nav-menus.php URL to manage menus at all.

Version 1.6 works out classic menu access per context rather than globally. Now:

• Appearance → Menus is restored in wp-admin whenever the installed theme still uses classic menus, even if the admin UI is currently running a block theme. It’s labeled with that theme’s name, so it’s clear whose menus you’re editing.
• A “Menus” link appears in the front-end admin bar whenever the view you’re on is being served by a classic theme.
• The stale Customizer link is gone from front-end views served by a switched block theme, where it never applied in the first place.

If you run a hybrid site, this is the section to care about. The admin now reflects what’s actually on screen instead of one global guess.

Now available in Spanish

ThemeSwitcher Pro 1.6 adds a Spanish (es_ES) translation and updates the existing Urdu one. Coverage isn’t complete yet — the strings introduced in this release, including the new Site Editor and menu labels, still fall back to English while we regenerate the translation template. That’s landing in a follow-up release.

If you’d like to see ThemeSwitcher Pro in your language, translation contributions are welcome.

Refinements

A few smaller improvements round out the release:

• The Site Editor’s floating theme selector is more reliable. It now appears only for users who can actually use it, and correctly reloads on success rather than on any server response.
• Your admin backend theme setting now informs Site Editor access. When the active theme isn’t block-based, the theme you’ve chosen under “Select theme for admin backend” is the one the Site Editor opens.
• Admin theme context holds steady. Theme selections made from the admin bar no longer override a configured admin backend theme as you move around the dashboard.

Behind the scenes

For developers, a few notes on the implementation:

• Site Editor features now bootstrap on wp_loaded via TSP_Admin::bootstrap_site_editor_features() rather than during initial plugin load, so theme and user APIs are available by the time access decisions get made. That bootstrap always runs. What varies is tsp_should_enable_site_editor(), which returns false when the current theme is already a block theme, WordPress handles that case perfectly well on its own.
• Classic Editor Plus is handled by unhooking rather than working around. On plugins_loaded, ThemeSwitcher Pro removes cea_restrict_patterns_editor_access and cea_hide_wp_patterns_submenu so site-editor.php can load normally.
• A new filter, tsp_filter_site_editor_enable, gates two things: whether ThemeSwitcher Pro instantiates on a site-editor.php request, and whether those Classic Editor Plus actions get removed. Think of it as a load-and-serve switch for Site Editor requests when the installed theme isn’t block-based, not a toggle for the admin bar links. It’s the first of several additional hooks on our roadmap.
• The AJAX handler behind the Site Editor theme selector no longer registers an unauthenticated (nopriv) endpoint.
• Theme resolution has been consolidated into a set of dedicated helper methods, giving classic, block, and hybrid setups a single consistent path through the plugin.
• On the development side, we’ve updated wp-coding-standards/wpcs to 3.4.1, which addresses CVE-2026-45293. This is a code-linting dependency used during development, it isn’t distributed with the plugin and never runs on your site, but we keep our tooling current as a matter of course.

Upgrading

ThemeSwitcher Pro 1.6.0 requires WordPress 6.0 or later and PHP 8.1 or later, and it’s tested against WordPress 7.0.4. Update from your WordPress dashboard as you would any other plugin.

Questions, or a multi-theme setup you’d like to see supported better? Get in touch, we’d like to hear about it.