While fixing a small D7 problem in #741242: Cleanup left over set-to-global-defaults description, I got carried away and wrote down a couple of other usability issues regarding the theme settings pages, which in fact deserved their own (this) issue. I came to the conclusion that global theme settings can be removed.

At the moment, it isn't clear to the user how the global settings relate to the theme-specific settings. Theme-specific settings are following the global settings 'automagically' until the first time you save the settings form for a specific theme. On that moment, that theme stops following the global settings and starts storing it's own settings. I think the theme settings forms are suffering from a couple of problems:
1) The user doesn't know when he is breaking the invisible link with the global settings.
2) The theme even starts using its own settings (instead of global) if the form is submitted without changes.
3) On the theme-specific form, you can't see if you're looking at default values (loaded from the global settings) or at theme-specific settings.
4) There is no way to switch back to global settings (that choice was made in #518750: Rethink the system settings form).
5) It is not clear if global settings are overridden per-setting (which is not the case) or for the theme as a whole (which is what happens).

Global theme settings have probably served a purpose at some point, but currently, I don't see the need for global theme settings at all. You enable a theme, configure the settings and you're good to go. I only do that once or twice on each site I build. The global settings are making an educated guess as long as I haven't adjusted the theme-specific settings. That's not a huge time saver, especially now that the "Display author and date information" settings have been moved elsewhere. As far as I'm concerned, default values can simply be hard-coded in variable_get calls, just like you would do with settings for your average module.

I'd like to read your opinions. Are there good use cases for global theme settings? If so, let's improve the 5 points above. If not, let's remove global theme settings.

Comments

David_Rothstein’s picture

David_Rothstein commented

I think some of these problems can reasonably be considered a bug against Drupal 7 and have created a separate issue for that here:

#749018: No way to make a theme go back to using the global theme settings

Not sure if removing the global settings is a good idea or not, but in some ways it might be a lot easier than trying to actually fix the bugs it causes :)

jhedstrom’s picture

jhedstrom
Primary language English
Location Portland, OR
commented
Version: 8.0.x-dev » 8.1.x-dev

Probably too late for 8.0.x at this point.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

mstrelan’s picture

mstrelan commented

I agree that global theme settings are confusing. For most sites, a lot of the settings aren't really applicable anyway. For most sites I've worked on there are no user pictures, nor are there comments. It also doesn't make sense for "User verification status in comments" to be configurable per-theme (or in global theme settings). This should be comment.module settings. I don't know any site that would set the shortcut icon (favicon) per theme either, it's always global.

My suggestion would:

  1. Remove "User pictures in posts" and "User pictures in comments" from global settings. They can stay in themes that support them.
  2. Move "User verification status in comments" to /admin/config/people/accounts as a form alter in comment.module
  3. Move "Shortcut icon" to /admin/config/system/site-information

Then we can remove global theme settings.

w01f’s picture

w01f commented

I'm not sure about removing "user pictures" entirely, as I have quite a few sites where user (or avatar) pictures are included for both their authored content, profile pages, comments, etc.

But the current implementations are done using a new media entity image field for users, so this would need some major rework to be modern anyway.

mstrelan’s picture

mstrelan commented

I'm not talking about removing user pictures entirely, I said remove the setting from "global theme settings". It should be per theme, if it's something the theme can handle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.