A “reset to default” feature (with a strong worded “are you seerious” step) so a theme acts like it was fresh installed, limited to $wpdb->prefix . ‘options’
Read-only archive: GitHub · Where software is built
Author: Dora D.
Vote count: 6
Status: open
Tags:
Comments
Definitely theme territory. In fact, many themes do already have a “reset to default” option.
I think it should be part of core, so each theme doesn’t have to handle it.
It would be very simple to delete the registered theme options.
I’m not convinced it should be up to the core to clean up or manage plugin and theme settings. There are plugins for that purpose e.g. WP Reset – Most Advanced WordPress Reset Tool – WordPress plugin | WordPress.org.
Because the rest of the interface for theme options is provided by core, it makes sense that resetting to default is handled also.
Definitely theme territory.
The theme giveth, the theme should taketh away, if you’ll pardon the biblical reference.
Blessed be the name of the theme.
I agree. It’s a job for the theme.
Maybe I should have said: “It’s a Job for the theme”.
(obscure, but I like it)
groans
wp theme mod remove --all too simple?
Yes and no. You should be able to do it in the UI, and not all themes use theme_mods.
Themes should use theme-mods, how will your button in the UI know what options it uses otherwise?
Themes have a choice of individual options or mods (one option that is an array, all handled for you). The Customizer function parameters indicate which, so it’s not that difficult to use that to affect all of them.
That does mean that only Customizer settings would be affected, and themes in the wild might not use Customizer. Still, if the UI is in the Customizer, it could at least handle what is registered.
Whether you use set_theme_mod() or the customiser API the options are all stored under one key in wp_options: theme_mods_{theme-slug}
Themes in the WP repo follow certain standards. One is they have to use the Customizer. Another is they have to use only one entry in the option table, so most use theme_mods. Therefore, they never call set_theme_mod() since the Customizer does it for them.
However, themes outside the WP repo can do whatever they want.
If you look at WP_Customize_Manager::add_setting() | Method | ClassicPress Documentation and see the type parameter in the $args, it can be ‘option’, but it defaults to ‘theme_mod’.
Also, a lot of themes written before the Customizer (or by people who don’t like the Customizer) use individual options and make their own Settings page. Having every theme present their options a different way on a different page was terrible and hard to review, and why the theme review team made the rules to only use Customizer and one array.
Ok, fair enough themes can go against the defaults which makes the original question pretty much impossible.
I know, I was there.
I think a button in the Customizer could be for deleting the current theme’s registered options or for loading the default values that they registered. I have code that does this for getting a parent theme’s values. It seems obvious that if it’s in the Customizer, it only affects those themes that use the Customizer. The original petition didn’t mention where it should be though.