I've been using this plugin for a while, it's really good as it places your google tracking code on all pages and also tracks outbound links, downloads etc. Really nice but it doesn't play nice with Lyceum. :-( It uses the functions: get_option() and update_option() to write it's settings to the database. Lyceum then has to know which blog has sent the request so that each blog can have independant settings. The problem is that the plugins 'settings' page doesn't save the setting against the right blog, it saves them as 'system' (ie. not associated with any blog), and therefore my changes don't appear to work. Really confusing. I'm no php expert but I had a look through and it all seem to be ok but something is amiss.
Can anyone explain how this mechanism works, in particular with regards to system vs per blog settings?
I don't think I modified either actually :-) It was a while ago and on lyceum version 0.33, I've now moved hosts and moving to 0.34 so I hope to reinstall this plugin at the weekend. I found it has some debugging too so I'll crank that up. For the record what seemed to be happening was that get_settings() and update_settings() were working on different rows.
How is system vs blog settings supposed to work? Am I right in thinking this was added as a Lyceum feature to enable multiple blogs to each have their own settings? Half the problem is that I don't understand how the mechanism is *supposed* to work, and that makes it's hard to debug ;-)
if a setting 'mysetting' is requested, lyceum first check if a system setting exists. if so, it returns it. if not, it checks if there is that setting for the _current_ blog. if so, it returns it.
First is that the plugin is installed as a system plugin. The plugin is enabled via the system admin section with the admin user. I don't have any blogs with that user so I log out and log in as 'me' and find the options page for my blog for the plugin. Here lies the problem. I change the settings and press save. The new settings are then displayed and we have the "options Saved" banner thing, however nothing in the database has been updated. Could this be a user/permissions problem (i notice there is a option_admin_level column in the lyceumoptions table).
My row in the lyceum.options table reads this: (I removed the actual settings since they were very long)
INSERT INTO `lyceumoptions` VALUES (387, 0, 'ultimate_ga_options', 'Y', 1, 'a:21:{ <snip>}', 20, 8, 'Settings for Ultimate Google Analytics plugin', 1, 'yes', 'system', 0);
So would this behave differently if installed as a per-blog plugin?
That seems to be true if the cache is used but what about this code from get_gettings() if the cache is empty?
$row = $wpdb->get_row("SELECT option_value FROM $wpdb->options WHERE blog = '$blog' AND option_name = '$setting' LIMIT 1"); if (!$row) $row = $wpdb->get_row("SELECT option_value FROM $wpdb->options WHERE option_domain = 'system' AND option_name = '$setting' LIMIT 1");
Isn't the caching behavior backwards? Shouldn't the settings for the individual blogs override the system settings unless option_can_override is 'No'? How else does one provide default values for options settings?
The code is from functions.php at the HEAD of the trunk in SVN. (Rev 1032).
Looking at system options first offers some protection if someone finds a hole in the system and is able to write a system-relevant setting to their personal blog, with a blog id of 0... or some strange combination where the system settings are intercepted.
at least i think that was my thinking when i made that decision many months ago.
brian- can you make a ticket expressing what you think is the problem and what should be changed? thanks.