"Theme Disabler" can't be disabled anymore

[maltmann-muc]

Oxygen "disables" the theme by setting non-existing template paths. However, some plugins require a theme to e.g. store templates. Sample: Plugin "Ultimate Member" wants to store email templates in the theme folder.

To solve this, it was possible to install a blank theme, and simply disable the Oxygen "Theme Disabler" by dynamically removing the filters "template", "template_directory" and "stylesheet_directory". Or also by adding a folder "/wp-content/themes/oxygen-is-not-a-theme".

To solve the theme-related issues with WordPress 6.4, a new action has been added for "setup_theme". But this action is implemented as an inline function, making it impossible to remove it dynamically. See screenshot.

Please implement the function for action hook "setup_theme" as a normal function, so it can be removed dynamically.

[Spellhammer]

We have never officially supported the re-enablement of themes when using Oxygen.

Any plugins that require template overrides should provide a plugin-based way to do them, like WooCommerce does.

[maltmann-muc]

That's a bold statement. Oxygen disables themes, one important key component of WordPress. And you state this design flaw should be solved by the plugins relaying on that key component?

You don't need to "officially support" the re-enablement, just change the action a bit to allow removing it – at our own risk.

function ct_remove_theme_paths() {
    $GLOBALS['wp_template_path']   = null;
    $GLOBALS['wp_stylesheet_path'] = null;
} 
add_action( 'setup_theme', 'ct_remove_theme_paths');

[Spellhammer]

And you state this design flaw should be solved by the plugins relaying on that key component?

It's not a design flaw. It's how Oxygen was built on purpose. It's always been this way, people just found a way to work around it by bypassing our measures to disable the theme. Our policy has always been to not support sites using these methods because Oxygen was not designed to work with these measures bypassed.

You don't need to "officially support" the re-enablement, just change the action a bit to allow removing it – at our own risk.

If we "just change the action a bit" we need to:

• Divert developers to changing the action, increasing development costs.
• Divert other team members to testing that theme disablement works as expected, increasing testing costs.
• Make sure we don't break peoples' unsupported bypass of our theme disablement in future updates, further increasing testing costs & technical debt in general.

All for something we do not support or advise people to do.

When you modify software to do something it was never intended to do, it's a calculated risk and the onus is on you to maintain that unsupported behavior if a core update ever breaks your modifications. I know this is clear to you as well from the "at our own risk" portion of the quote above.

[perrelet]

@Spellhammer

Yet another won't fix because won't fix courtesy of captain won't fix.

Please explain how refactoring this hook from a closure to an addressable method or function would increase development costs. Surely you can't be serious 🙃

p.s. Congrats on alienating your customers.