Getting BuddyPress and sitewide tags to play nicely

Boone, thanks for taking a look.

Basically I have implemented sitewide tags in a multisite config which uses custom taxonomies to distinguish between blog posts and then display them with different layouts (as per Tumblr).

The plugin works sweetly in creating the tags blog (which is my main site) and aggregating all the post in sub-sites, but it doesn’t bring the postmeta data along with it.

I’ve tried adding filters to firstly declare the taxonomy ‘tumblog’ which is how I originally set up the micro-blogging plugin, then I changed its setup to to use the WP default post formats (so I then declared a taxonomy of ‘post format’ in the filter) but in neither instance did it work.

When set up for post formats I entered the custom field names in the SWT admin settings and have followed their progress within the plugin, but it fails to retrieve the data (i.e. the values of each array key) at the point where it executes the get_post-meta command.

Basically, I’d like to be able to get the postmeta data from the originating post on a sub blog and then update the tags blog with these fields so that I can reflect their unique layout on the main (tags blog) site.

Boone – Yeah, I was a bit over simplifying. I should probably have said ‘You’ll need to add in the actions/filters to pull CPTs into BP on your own.’ (Which I do know how to do, but haven’t gotten off my ass to implement ?? )

As Boone says, I don’t think this issue is anything to do with BuddyPress at all.

Thanks Paul, I appreciate you taking a look. At least you’ll have stopped me chasing another red-herring and I can focus back on the SWT plugin or its interaction with other plugins.

I don’t believe I’m doing anything THAT unusual so I would expect more people (BP or otherwise) to experience the same – it’s worth getting to the bottom of the issue and adding something more to the knowledge base. (assuming of course I solve it!)

From what I can deduce, the ‘wp_get_object_terms’ does not function within a BuddyPress installation. That seems a strange conclusion, since it’s so core to the workings of the wordpress platform.

Paul (and Boone) what’s your take on that? I may have been derailed by that.

Also, DoctorDR, it sounds like you set up the post-format filter right, but then added the same thing in the custom fields area. Did I get that right?

Also, DoctorDR, it sounds like you set up the post-format filter right, but then added the same thing in the custom fields area. Did I get that right?

Sorry I should have clarified earlier, I did initially set up the filter in a plugin which I network activated, but as soon as I shifted focus to the custom fields I deactivated the filter.

I am literally just running with Version: 0.4.1.1 of sitewide-tags.php and with a list of custom fields that I input (on seperate lines) in the admin settings.

Paul (and Boone) what’s your take on that? I may have been derailed by that.

wp_get_object_terms is a taxonomy-related functions. BuddyPress core doesn’t use taxonomies at all.

I’m clearly missing a couple things….

What are you trying to merge with BuddyPress? I mean, if you’re trying to pull in custom taxonomy, as Paul pointed out, that’s unused by BP, and would be a bit different.

I know that SWT can pull in post FORMATS (like links and asides) but those aren’t the same as custom taxonomies.

So let’s rewind ??

WHAT are you trying to do?

Are you trying to get Buddypress to show custom post types, post formats, or custom taxonomies? Or are you trying to get your tags blog to show one of those? They’re all different things, and the answers will change. Don’t worry about details for this answer (and leave out the history for a moment). Just something dead simple that an idiot like me can follow along with.

“I want my tags blog to show post formats” or “I want buddypress to show my CPTs” That level of simple ??

What code are you using for this?

You tossed some out there, but I’m fairly sure that’s NOT the code you put in a mu-plugins file. So take the post formats filter or whatever you made as a plugin and post the code here for us ?? Again, leave out the history, just share the code.

Can you give us the URLs?

I know, some people are weird about this, but it really does help folks. Visually looking and going ‘Aha! That!’ will help us ??

Finally …

Notice how I said NOT to network activate the code but to put it in mu-plugins? Make sure you did that. IIRC mu-plugins are run before the network activated, and it may help.

Also, make sure you activated SiteWide Tags network AND if you set it to ignore ‘hidden’ (non searchable) blogs, that the blog you’re trying to import FROM isn’t one of ’em.

Despite the length of this post, the outcome I’ve tried to achieve is really very simple.

Quick précis: I run a series of publishing titles (magazines and websites) and receive dozens of enquiries from would-be writers who’d like to see their work presented in our unique style. We’ve run several award-winning social communities and decided to revamp our automotive site to provide more of a showcase for aspiring writers and bloggers. We’ve built many wordpress sites and finally decided to give BuddyPress a chance to fulfil our needs.

Proposed Architecture:WordPress multisite using BP Default as a base theme but with a heavily modified design, the same theme is used for all the user sites. These user sites are configured to operate like pages of the main site. SWT plugin is used to aggregate all posts (from the main site and user sites) onto the homepage of the main site – just like wordpress.com

Publishing: The blog posts are all of a Tumblog format (Tumblr like) – they are created using an interface where the user chooses between video, link, quote, audio, image or asides.

When a post is published from any site within the network, the tags blog is updated and the main site shows the aggregated listing of these posts. That all works fine.

What I am trying to do (very simply) is to update the tags blog with the same metadata (custom fields) that are saved on the user blog posting, so that this index of posts can also reflect the tumblr style of each post. There are conditional statements which check the type of post format and then display a specific icon, default image etc.

What’s the problem?: As mentioned previously, the post metadata is not being included in the main tags blog, therefore the tumblr formatting is lost when viewed on the main site. Don’t get sidetracked by the BuddyPress context, unless of course its relevant to the WP functionality available.

BP works fine, each new post is reflected in the activity stream – I’m not bothered identifying the post formats at an activity stream level.

I’m well aware of the differences between post types, post formats, and custom taxonomies. Initially I tried to use custom taxonomies, but changed to post formats because these are how future versions of WP will be developed.

What code am I using: At this very moment, I’m only using the SWT plugin code configured with the custom fields used as the meta_keys of the post formats in use – video-embed, link-url, quote-copy, quote-author, quote-url, audio, image.

After trying various routes including the SWT filters (which didn’t work) and even considering a direct database query to bypass the WP functions, I decided to try and make the in-built plugin function work.

You can view the code for yourself in sitewide-tags.php from Donncha and Ron’s plugin.

Visual representation: I can’t share the URL with you, the site is hidden behind a redirect whilst I fix this problem, but here’s a screengrab to show how the front-end looks.

https://www.skiddmark.com/wp-content/uploads/2011/05/skiddnet-grab-190511.jpg

As Ron said a few days ago, post formats are not postmeta. They are a taxonomy called post_format.

I just tested your code from https://www.ads-software.com/support/topic/getting-buddypress-and-sitewide-tags-to-play-nicely?replies=40#post-2127136 It works – post formats are carried over to the tags blog. Put this filter in a new file in wp-content/mu-plugins. Do not put it in a regular plugin file in wp-content/plugins, as it may not be activated in time.

As Ron said a few days ago, post formats are not postmeta. They are a taxonomy called post_format.

Thanks Boone. I realise post formats as an entity do not map onto postmeta – they’re a type of taxonomy, however post formats create post metadata entries in the relevant wp_postmeta table. That’s where my focus has been lately in trying to get the SWT custom field settings to function.

I am assuming you ran the filter in an environment that includes BuddyPress?

I will test out now (in mu-plugins) and report back.

Perhaps we have different definitions of what ‘idiot simple’ is.. ??

“I want meta data from my posts to be carried over into my tags blog.”

Is that right?

In a word. Yes.

Both you and Boone have picked up on an issue that on the face of it is almost superficial, but is quite fundamental for anyone who didn’t use the previous WordPress MU platform – namely ‘mu-plugins’.

Nobody as far as I am aware had previously mentioned ‘mu-plugins’ and despite being a seasoned WP user, I’d never heard of it nor knew of its purpose. If I had seen mu-plugins mentioned in a sentence I would have assumed it was just referring to the plugins directory in a multisite install.

Seems like a pretty fundamental oversight – Nobody is to blame, I just feel its something that should be given more prominence in support communities.

Anyway, as per my luck I have now moved the plugin to a directory called ‘mu-plugins’ ensured it has 755 permissions and freshly installed the SWT plugin – it still doesn’t work, so I have decided to drop the DB tables and run tests on a clean install (using the latest WP 3.1.3, which I’ll have to work with anyway).

I don’t need any further assistance for now – let me see whether running the filter in mu-plugins enables it to load before the main SWT plugin.

If that works then I’ll put together an ‘idiots guide’ for anyone else who might meander this way..

FYI: https://wpmututorials.com/plugins/the-mu-plugins-folder/

Thanks Ipstenu, I’m aware of it now and it all seems pretty simple and logical.

It would be helpful, for the handful of plugin authors for which it is relevant, to point towards such a reference.

When I look at the ‘New Blog Defaults’ plugin for example, it says “Place the cets_blog_defaults.php file in the wp-content/mu-plugins folder.”

Which is great, but I’d wager that many people will not know there could be ‘two’ plugin directories and just assume it refers to the wp-content/plugins one, or they’ll get lost trying to find their own ‘mu-plugins’, without realising they have to create it themselves.

Getting back on topic, if this is indeed the solution, then it would be great if Ron could update his post – https://wpmututorials.com/plugins/sitewide-tags-update/ – for anyone not already familiar with WP MU, so that they know to add their filter in the mu-plugins directory.

Well, at least I know now…

Ron, I would just like to confim something with you about SWT pages plugin.

I have been able to make SWT work when using the default ‘New Post’ page in wordpress (and selecting a post format using one of the radio buttons), but that’s not how my site is designed.

In supporting ‘post formats’ you seem to do so via the ‘custom fields’ route, where these fields are stored in the wp-postmeta table whereas the wootumblog plugin uses set_post_format( $post_id, 'aside' ); for example, as well as storing specific custom fields (such as quote_url or video_embed) in wp_postmeta.

It seems to me that the protocols adopted within each plugin are incompatible, therefore my aim is to modify one plugin to fit the other.

The SWT pages plugin does not use get_post_format and I’m trying to understand why, because clearly whatever modification I make I’d like it to be inline with how WP 3.2 and future versions of WP are expected to handle post formats.