Log in with username/password: lyceum/lyceum

Ticket #770 (new defect)

Opened 1 year ago

Last modified 11 months ago

System settings sometimes override blog settings

Reported by: lyceum Assigned to:
Priority: high Milestone: The Future
Keywords: system blog setting precedence override Cc: bryan.thale@motorola.com

Description (Last modified by jjb)

Transferring from Forum discussion

John,

First and foremost, I would expect the system to be consistent in how it handles the precedence of system vs. blog settings, either system settings always override blog settings or blog settings always override system settings. Whether the setting value is being pulled from cache or read from the database shouldn't alter that.

Second, I would advocate that blog settings should take precedence and override system settings of the same name. In that way, default values could be specified at the system level and then tweaked as necessary for individual blogs. I notice that there is a "can override" field in the database schema but it doesn't seem to be used and I think it is probably superfluous anyway. If there is a system setting that blogs shouldn't be able to override, just don't provide the code for the blogs to override it.

When dealing with large numbers of blogs, being able to set defaults at the system level really cuts down on the effort to manage mass changes of the desired default behavior. It's simply amazing how often the corporate "standard" for something changes and if I can change one system setting and automatically update all blogs that are configured to use the system default (or rather NOT configured to use something other than the system default) then my life is easier as the admin.

So what I would like to see happen is the cache handling code should be flipped so that it honors blog settings over system settings the same way the database code in functions.php::get_gettings() does.

Regards,
Bryan.
--
Bryan Thale
Motorola Open Source Technologies, Mobile Devices

Change History

08/18/07 12:01:11 changed by jjb

  • description changed.

(in reply to: ↑ description ; follow-up: ↓ 4 ) 08/18/07 12:23:00 changed by jjb

Hi Bryan.

Replying to lyceum:

First and foremost, I would expect the system to be consistent in how it handles the precedence of system vs. blog settings, either system settings always override blog settings or blog settings always override system settings. Whether the setting value is being pulled from cache or read from the database shouldn't alter that.

Are you saying that is not the current behavior?

Second, I would advocate that blog settings should take precedence and override system settings of the same name. In that way, default values could be specified at the system level and then tweaked as necessary for individual blogs. I notice that there is a "can override" field in the database schema but it doesn't seem to be used and I think it is probably superfluous anyway. If there is a system setting that blogs shouldn't be able to override, just don't provide the code for the blogs to override it. When dealing with large numbers of blogs, being able to set defaults at the system level really cuts down on the effort to manage mass changes of the desired default behavior. It's simply amazing how often the corporate "standard" for something changes and if I can change one system setting and automatically update all blogs that are configured to use the system default (or rather NOT configured to use something other than the system default) then my life is easier as the admin. So what I would like to see happen is the cache handling code should be flipped so that it honors blog settings over system settings the same way the database code in functions.php::get_gettings() does.

You make a decent case and I've been pondering this. FYI, the 'option_can_override' setting mentioned in the forum thread is a WordPress? thing and honestly I'm not sure what it's used for, I've never seen a plugin that used it. I'm going to look into it.

Could you give me an example plugin/situation where you want this behavior (the options precedence swapped)?

08/25/07 14:14:28 changed by jjb

  • priority changed from normal to high.
  • milestone changed from 1.0.11.0 to The Future.

(in reply to: ↑ 2 ) 09/01/07 14:59:02 changed by bthale

Replying to jjb:

First and foremost, I would expect the system to be consistent in how it handles the precedence of system vs. blog settings, either system settings always override blog settings or blog settings always override system settings. Whether the setting value is being pulled from cache or read from the database shouldn't alter that.

Are you saying that is not the current behavior?

Correct. The cache returns system settings in preference over blog settings while the code in functions.php which is used if the cache is empty returns blog settings in preference to system settings. See original discussion in the [http://forum.lyceum.ibiblio.org/discussion/13/problems-with-ultimate-google-analytics-plugin/#Item_6[forum]].

You make a decent case and I've been pondering this. FYI, the 'option_can_override' setting mentioned in the forum thread is a WordPress? thing and honestly I'm not sure what it's used for, I've never seen a plugin that used it. I'm going to look into it. Could you give me an example plugin/situation where you want this behavior (the options precedence swapped)?

We have some default text that appears in the footer of the skin. An individual blog can override this text and display different text (chosen from a fixed set of possibilities) in the footer. The problem with just setting the default text as a blog setting when the blog is created and not having a system setting is that the text is all standardized and the current default value alternates between this small subset of approved values. When the default changes, simply doing a mass SQL update to change all TEXTA to TEXTB is that it doesn't distinguish between blogs that were defaulting to using TEXTA versus those that had specifically chosen TEXTA. In the latter case, we don't want the fact that the default has changed to TEXTB to affect those blogs that have specifically chosen TEXTA. Does that explain the use case?

Log in with username/password: lyceum/lyceum