Ticket #641 (new defect)

Opened 5 months ago

Last modified 5 months ago

blog URLs redundantly defined and hardcoded in DB - headache

Reported by: jeremyclarke Assigned to: somebody
Priority: normal Milestone:
Component: component1 Version:
Severity: normal Keywords:
Cc: jeremyclarke

Description

While testing an upgrade to 1.5 and moving servers (I used an alternate domain to set up a staging version on the new server) I noticed that the SITEURL and HOME options are sometimes used to create links to parts of mu blogs while other times the information in the 'wp_site' table (for the root blog) and the 'wp_blogs' table (for root blog and children) is used.

Specifically, it seems that the general existence of the children blogs is dependent on the wp_blogs table ( 'domain' + 'path' ), while lots of parts of the admin (the admin blog list, the link to 'view site') depend on the values stored in the 'wp_options' tables of each individual blog (i.e. SITEURL and HOME).

Overall, this creates a pretty big annoying mess. It makes it insanely tedious to set up a working stage backup of site on a new domain because so many DB values need to be modified, especially considering the fact that really you should only have to change it in one place, the single row in 'wp_site'.

Has this come up before? It seems like MU should choose one source for each blog url and stick to it, at least on a blog by blog basis. Given what i've seen of the DB structure, the 'wp_blogs' table seems like the best overarching resource. Could MU just ignore the settings in wp_options of individual blogs in favor of the values stored in 'wp_blogs'? It seems like it wouldn't be too hard to override the behavior (or fill the holes where the old values are still used, seeing as at least some parts of the system (the MU parts) are already usign the wp_blogs values, because many thigns worked after i only changed those but hadn't altered the 'wp_options' versions).

Also: using the HOME and SITEURL wp-config.php defines in wp-config.php as one would with Wordpress.org causes ALL the sites to have their urls overridden, breaking everything but the root blog.

I.e. 

 //define('WP_SITEURL', 'http://siteurl'); 
 //define('WP_HOME', 'http://siteurl');

Ideally that probably shouldn't happen as there is no reason for someone to want that behavior (but I can't help thinking other people will try the same thing and get burnt worse than careful me). If the HOME and SITEURL constants were changed for the reasons above then ideally they might also fix this. In a perfect world you would be able to override the value in 'wp_site' in wp-config.php and have it affect all the blogs in MU, but that's just me dreaming (and I can imagine reasons why being ABLE to have multiple domains on one MU install is useful). Making an option for having multiple domains (with the default being to use one authoritative domain) could be a good solution for this.

Thoughts? I'm more familiar with the WP.org world than MU so let me know if I'm missing something important. I think this would be really useful for anyone who tends to keep staging and dev servers (which we all should, right?)

Change History

05/27/08 03:50:15 changed by lunabyte

Not sure about anyone else, but I prefer dev/test sites to be exact copies. Including the domain.

Sounds funny, but a simple pointer in my local hosts file (that can be commented out) works just fine. Saves a ton of editing as well. Simply uncommenting the line, or lines if you're running subdomains and want a couple to play with locally, when needing to work locally takes seconds and is much easier.

It also makes it easier to keep things consistent, and makes db imports/syncing simple as well.

05/27/08 10:34:37 changed by donncha

It is sort of annoying, but it's a legacy issue because WP expects to find those blog options there.

I have planned to write a plugin, or perhaps have it in core MU, code to strip out the redundant records in the options tables. Probably 90% of the options are the same on every blog, and the siteurl and home options could be derived from wp_blogs. That could save a lot of db space if there are tens of thousands of blogs ..

05/27/08 16:36:07 changed by lunabyte

Site, home, files, etc. I could see being a global/site option pretty easy.

Others though, where someone may have certain blogs with one setting, other with another, might be a little more tricky to overcome.

If we're getting into saving DB space, magpie takes a LOT, especially when we're talking hundreds/thousands of blogs. Rewrite rules take their fair share as well, but we're getting into WP core vs MU core stuff. Although, I could see something that perhaps checks for the rewrite pattern, and if it's standard it grabs the global option, if it's customized it would grab the local one.

Maybe put a function_exists around the current functions, then add in additional wpmu functions to override. Optional, of course, maybe similar to defining sunrise, it could check for a definition of say, GLOBAL_OPTIONS, and/or bounce against a setting in the blogs table (similar to spam, mature, etc.) where by default it's global options, with the site admin able to specify whether or not to use local blog options instead.

05/27/08 16:45:39 changed by donncha

There's the pre_* action that can be used to check the global options. No need to modify core functions, I think.

I have modified rss.php so Magpie stores it's cached files in the object cache, or in sitemeta. Hopefully large MU sites will use the object cache because putting all those cached files in one global table is asking for trouble!