WordPress MU

G'day,

I've looked at most of the older sitewide category and tag plugins (including MuTags). They all have their relevant flaws, and none of them seem to be an "elegant" solution.

My proposal is to write a new plugin (hopefully accepted into core) which extends the current wp_sitecategories functionality to create two new global tables wp_siteterms and wp_sitetaxonomy.

Currently terms created on each individual blog are copied into a master table and the two IDs kept in sync. However, that is not done for taxonomies. Really, taxonomies are the important part, terms are one layer of abstraction behind taxonomies. So I propose to globalise the taxonomies as well as the terms.

Can anyone see any faults in this logic? Any potential problems? Has anyone done this already and failed miserably? Any ideas why it won't be accepted into core?

Going forward, my plan is to create a global posts table (possibly truncated to the most recent 1'000 records) to use for site-wide feeds, possibly site wide searching, and so on.

Any / all feedback appreciated.

Cheers - Callum.

I did wonder when the taxonomy code came out why there wasn't a global one. I just assumed that it was going to be added in the next release.

the best you can do, I think, is to submit it to trac and see what happens.

i know in earleir conversations, Donncha has said the global categories table wound up not being used because it was too resource intensive. But for some reason, it's still included.

Just an honest opinion, but I don't think something like this (meaning the overall idea, nut just a tag/term/tax table) would end up in the core.

IMHO, the whole global tag system is something unique to wp.com, and including a similar high profile feature in MU out of the box (whether or not the underlying code structure is similar or not) probably isn't on the agenda.

Not that that is necessarily a bad thing. But wp.com took MU, and made it into what they use today. They have been nice enough to give back some things to MU, but you can't fault them (or anyone else) that keeps their unique features to themselves.

However, as a plugin, there are a few out there to choose from.

This is something that has been in debate for quite a long time, and you see where it's at. Or should I say, "not" at, and that being not in the core.

The resource implications are a good point, on big sites, it gets unwieldy to have all the categories in one table. However, the current system globalises the wp_term table, so it seems the next logical step is to globalise the wp_taxonomy table. It's really just completing what is already there.

As far as I can see, globalising the wp_term table alone serves no purpose whatsoever. The terms all have global IDs, but their taxonomies don't. Terms in and of themselves can't be practically referenced.

I need a scalable site-wide feed solution for my day job, so I'm thinking to build this as a foundation for that. I'll see if I can catch donncha on IRC and see what he has to say. :)

I'll post back once I have some code.

Cheers - Callum.

Had a chat with donncha on IRC and it does make sense to globalise the wp_terms and wp_taxonomy tables. I'll crack on with it and submit a patch. Hopefully if I get it right it might be accepted pretty quickly.

I've been trying to find a plugin like this and will send it to our developers to create. If anyone has already done one please stop me in time ;). Otherwise I will post again when we are finished with it.

Pineberry, I have written the code and we have deployed it. It's working on our system. I'm happy to publish it under the GPL. I've just been a bit lazy in terms of finding somewhere to actually release it! There's no equivalent of wordpress.org/extend/plugins for MU as far as I know. I'm happy to send the code by email / whatever though. Just give me a shout.

@chmac - Most plugins for WPMU are posted here: http://wpmudevorg.wordpress.com

Thanks!

Or on Google Code?

What would the plugin be called BTW?

@amanzi I'm not a big fan of WPMU dev. It feels clunky and overly commercial to me.

@musnake I'm an avid anti-google user. I Scroogle search, etc.

All this flurry of activity has encouraged me to finally pull the finger out and publish the code. I've released the Real Global Terms and SH Global Posts plugins. I've provided some documentation on those pages.

@chmac: May as well just put them in wordpress.org/extend/plugins and tag them 'wpmu'. I do that for all of my WPMU-compatible plugins (though I haven't put any exclusively WPMU plugins up there thus far).

@jdub: These are exclusively WPMU plugins, so I'm a little reluctant to put them onto wp.org. They don't have any application to WP blogs, so not sure what to do with them.

Yeah, most of the MU only type plugins in up on WPMUdev.org, which has been around for quite a long time.

Why not put them on both?

As a side note, even Automattic has put an MU plugin up in the official repository.

This plugin will make a copy of every post, on every blog, and put all those copies into one, single blog. It will copy the post as well as the post’s tags and categories. This means that you can search the single blog for all posts across all blogs across your whole site.

this seems a lot like dr. mike's solution. so if i'm reading this right, i can drop my outdated sitewide feed plugin and simply use the blog ID#1's feed. I can also hack my theme to display posts by tags or by global cats. correct me, please, if i'm wrong.

@demonicume: It is similar to drmike's solution. However, it's different in a few significant ways.

1) It will be *much* less database / resource intensive. All the global feed plugins that I've seen query every blog, grab the most recent posts, then rearrange the whole lot into one giant feed, and only display the most recent X posts. Very resource intensive, not very efficient. This plugin pushes each post as it's created / updated.

2) No standalone WordPress install is required. You can use one of the existing WPMU blogs. I had originally written the plugin to use an standalone WP blog. Then I realised, why bother. I'm moving posts at the database level so I can use an existing blog.

3) Posts don't get munged by the RSS export / import. It's a straight database copy, so the post should be exactly the same on the global blog as it is on the individual blog. This is a fairly small point, but if you have multiple timezones on your install, you might find times go wonky in the RSS import part.

With regards to support questions, about themes, etc, please post them on the plugin pages so that all the questions / answers are in the one place. Happy to cross post here, so long as the info is collected in one place.

@andrea_r: Automattic have a WPMU only plugin in the wp.org repo? Which one? If that's the case, I'll put them up there. I have another few plugins there and it's pretty easy to manage.

great work. i'll have to include this in my upgrade.

chmac does this copy "all" posts across or just posts that are public? I guess I say this because if a post is in a private blog or one that has been marked "mature" will they be except from being copied?

Trent

@Trent: Hmm. Good question. It will copy all posts. It doesn't distinguish between regular and "mature" blogs. Hmm. Might not be too much work to change that. How important would that feature be?

Certain installs offer blogs that are private to registered members and there are some "mixed" blogging platforms where not all the blogs are PG :) It would be a nice addition I think as any install that wants to separate mature or private blogs posts from public consumption would never be able to use this plugin.

Either way, it is a great plugin set and great idea :)

Trent

@Trent: How do you offer "private" blogs? I don't see anything in the back end around that.

I hadn't considered wanting to exclude some blogs. But it's a good idea. I've implemented the option to exclude mature blogs, and added a generic filter which means the plugin can be extended to exclude blogs by almost any criteria. I've published the new version.

@chmac: unfiltered-mu.

grrr, i don't know why i'm the guy who gets the blank screen after install. looking in my log, i see some DB errors, but nothing that'd bring down the whole site.

this line is bringing my site down.
'define ( 'REAL_GLOBAL_TERMS_INSTALLED', false );'
when its set to false, my site goes down. when set to true, the siute comes up, but I'm need seeing any information in the DB. off to check the error log.

@demonicume: Did you get the error after installing my plugin? Please post some info on the relevant plugin page and I'll see what I can do to help. I'd like to keep all the questions / answers in one place.

Installed the plugins and they work great. @chmac, great work.

Could someone help me on how to implement search functions for tags on the GLOBAL_POSTS_BLOG. is there any plugins like "search everything" that i can use for this? right now i can only search the posts and pages on the main blog. posts from the sub blogs cannot be searched.

apologize if my errors sound stupid. did a lot of research but did not find any answers. any help would be appreciated.

chmac, this solution offers a less resource intensive way to do this, however you end up with potentially huge amounts of redundant data - which is worse?

Plus, what if a user wants to edit a previous post? Will their changes on their blog be reflected by updating all copies of the post in the global table?

@earthman100: I haven't looked at the code for a while, but I'm pretty sure it will push updates every time the post is changed. The biggest change will be the move to post revisions, I'm not sure how it will handle that.

Yes, it creates duplicate data, that's true. It depends on the size and specs of your install on which approach will work better. One option is to cull the global_posts table at a few thousand records. That could be done quite easily on a regular basis, and keep the "most recent" history available, but leave the archives in the individual blogs.

I think if you want to do truly global tags / searching and so on, you'll need all the data in one table. The additional cost of storing the data twice would outweigh the resource benefit of searching thousands of blogs in most cases I reckon.