WordPress MU

We have added a few new features to Sitewide Tags - looking for people to test it - http://downloads.wordpress.org/plugin/wordpress-mu-sitewide-tags.zip.

New features

- Option to include copying/re-posting of pages in tags blog
- If the tags blog is not public, option to include posts/pages from non public blogs in tags.
- Option to copy/re-post postmeta/custom fields

Bug fixes

- Category names with special characters - http://mu.wordpress.org/forums/topic/15717

This version should continue to function the same as the previous version until the site options are saved. If you have the previous version in your test install, can you replace it with this one and check to see that it functions the same?

Also, if someone has dsader's privacy plugin, please test to see that blogs with a higher privacy setting is not included in the tags blog.

Added the pages required changing the purge code, so, interested in seeing that this works as well.

I'll try and break it tonight.

thanks :)

Digest Version:
It all works fine.

Verbose Version:
Pages work. I'd love to see a practical use. I'm not quite sure how I'd use it.

I did learn that the Gallery feature in WP doesn't fare well being copied to the tags blog, but that's consistent with posts too.

We use a modified version of dsader's privacy plugin and it seems to work as I expect. One thing to note though is that disabling the non-public blogs does not remove posts from private blogs. Only going back to the originating blog and toggling the privacy back and forth gets the post removed from the tags blog.

The custom field copy worked. This is an interesting approach to that problem. Deanna had submitted a different approach a few months back and I'll have to think on which I prefer. What's the reasoning behind limiting the meta to only certain keywords?

Including the pages has been a popular request for mods to this plugin. We know several installs that are using a modified version including at least one of the new features.

The gallery relies on attachment posts which aren't copied by this plugin.

On the privacy, that's how I expected it to work. Andrea & I use this plugin in nearly every client install. As far as our clients go, once they decide the public vs non public tags blog, they don't change it. How important do you think it is to have that removal done automatically?

Reasoning? Only duplicate the data you need. An example of where I have added this for a client: the client was using a thumbnail plugin that used a thumbnail custom field to store the thumbnail url. By copying the custom field, the thumbnail could be used on the tags blog.

... and thanks for the extended feedback :)

I had guessed that the custom field approach was a specific solution for tim thumb kinds of theme sites.

My thought about the "only duplicate the data you need" is that it's predicated on knowing what data you need. In some very specific implementations that's certainly the case, but in more generically neutral hosting (take wordpress.com as an example) I see copying all custom fields automatically as laying the ground work for more flexible reactive solutions. It's like having to define which tags or categories instead of just copying them all over.

I can see the need for both approaches, but it seems to me that "copy all" should be default to be consistent with the rest of the copy behavior and "limit to" (and/or exclude) would be an additional mode. (And I actually think limit/exclude options could be a good enhancement for posts by tags/categories too.)

Just my 2¢. But as it is, everything seems to work.

Thanks for both testing and your thoughts :)

So far, everyone has reported back that it works as expected.

On copying all custom fields, both approaches have merit. The two sides that I considered were-

SWT has been downloaded 5000+ times. As much as possible, I try to make a new version of plugin so that it will continue to provide the same functionality that the previous version did (which I was able to accomplish in this case). Because it's fairly widely used, this weighed in quite heavily for me.

In theory, a site admin should know what custom fields are being added by a plugin. So, if they did want the custom fields copied, then they could add the fields to the SWT list when they made the plugin available to users (or activated sitewide, etc.). That will mean a learning curve for some. But, hopefully most people do look at what a plugin does before they add it to their install.

Anyone else with testing results/feedback?

Installed for 3 days under normal use, no errors or conflicts as far as I can tell. Thanks.

Thanks :)

As long as no reports of issues surface by lunch tomorrow, we'll update the version number to a new release.

I've just started testing this out, and not sure why it's happening, but posts are being published with the category ID. It seems the category is being added to the tags site (in my case, the main site), but a new category is added using the ID, and that's what's being published.

Also, is there a way to use the mapped domain for the URLs. All of my subdomains are mapped, and the users wouldn't want the links to their site be the subdomain.

Thanks in advance

Can you give an example of a category name that's being converted into a number?

Which DM plugin and version?

I'm using the latest version .4 ,and all categories are converted to a number, though the original category is also added to the blog, not the post.
The domain mapping plugin is Donncha's, and I'm actually using trunk on that.

I tried it with 2.9.1.1, created a new category 'My Latest Category'. The post and category showed up correctly in the tags blog.

Did you import a blog using SQL (vs the built in import)? If you did, did you sync up the terms between the SQL imported blog and sitecategories?

Yes, these blogs were all manually imported (via SQL, not WP import/export) over to a new installation. Can you expound on the "sync up the terms between the SQL imported blog and sitecategories?"

And this is 2.8.6 currently, the site tags is latest version.

The sitecategories table is used to sync terms (cats, tags, etc) across blogs.

So, if you have a new term test-term created in a blog with an term_id of 1234 that term is also added to the sitecategories table. After that, whenever another term is created in the install with the slug test-term, it will be assigned the term_id 1234 in the blog where it was created.

By importing the blogs with SQL you have duplicate term_ids with different slugs.

"By importing the blogs with SQL you have duplicate term_ids with different slugs."

So what is the solution to it? I look at my sitecategories table, and it contains, for example, the following:

7 worn out furniture worn-out-furniture

Now, when a blogger added a new post in this category, the sitecategories got the following:

9678 7 7

What needs to be deleted or fixed?

Just wanted to add that the new post that the blogger added, ended up in with the category of 7 instead of worn-out-furniture.