Getting BuddyPress and sitewide tags to play nicely

perhaps you could illustrate on wpmututorials how to adapt SWT to use custom posts types, custom taxonomies and custom fields.

I did describe how to use those filters in the post I linked to above. Unfortunately, I don’t have the tumblog theme, so I don’t know what it does. I was guessing at what to do in the filter based on the code you had posted above.

I verified that both the custom post type & custom taxonomies filters work correctly per what’s in my post. To use them you need to know what the post type is and what the taxonomy name is.

Ron, I appreciate that you’ve told me what to do, but despite trying every variation I can think of I’ve been unable to make it work. I must have searched every post written on SWT and have yet to find anyone who’s added a filter to enable a custom taxonomy, so I feel like I’m pioneering.

Here’s what I can see in the database. When a tumblog post is created in blog_id 9, the wp_9_posts and wp_9_postmeta are updated and then ‘two’ records are added to the wp_9_term_relationships table, where object_id is the post_id, and the first record reflects the category term_id whilst the second record reflects the tumblog taxonomy term_id (in this case ‘4’ which means it’s an image post).

At the same time identical updates are made in the tags blog (my main site blog), however the main tag blog’s wp_term_relationship table contains only the first entry (for the post’s category) and not the second entry which would reflect the tumblog custom taxonomy term.

By following the updates through I can see that everything updates fine and the SWT plugin serves its purpose, EXCEPT I lose the custom taxonomy within the main tag blog.

I’ve enabled the plugin as posted above, and tried some variations including amending line 2 to say..

$taxonomies['tumblog'] = true;

I am at a dead end and can only conclude that (a) either the inbuilt custom taxonomy function within SWT doesn’t work, or that the add filter function is incorrect.

As a workaround I’ve been trying to find a way of getting the taxonomy term within the ’sitewide_tags_post’ function of SWT and then update the tag blog’s post meta with an entry, but I’ve been unable to return the term name (or ID) despite using get_the_term_list,get_the_terms, get_terms or even wp_get_object_terms.

My lack of experience with custom taxonomies and filters is clearly limiting my ability to solve this issue. It’s such a simple issue, but it’s halted the whole project.

Does any of this make sense to you, and do you have any further suggestions?

How about a quick suggestion for how I might hard-code a fix into the plugin to pass thru my custom taxonomy as per the rest of the post meta data? Anything to get me past this issue…

Thx

Is the tumblog taxonomy registered on the main site? If it’s not then that would prevent it being saved to the main site.

What you need to return from the filter is the taxonomy field from the term_taxonomy table as a new element in the array per the example.

I implemented a very similar filter in https://www.ads-software.com/extend/plugins/genesis-simple-menus/. At the top of the plugin file is an example filter. The only difference is that the filter is genesis_simple_menus_taxonomies where the one in SWT is sitewide_tags_custom_taxonomies.

Yes, the tumblog taxonomy is registered on the main site – it installs as a network activated plugin – https://www.ads-software.com/extend/plugins/woo-tumblog/ – and then creates the 6 entries in the wp_term_taxonomy table which are the default terms for this taxonomy (video, articles, images, audio, quotes, links).

The table entry looks like this:

.       3 	Articles  articles 	0
	4 	Images 	  images 	0
	5 	Audio 	  audio 	0
	6 	Video 	  video 	0
	7 	Quotes 	  quotes 	0
	8 	Links 	  links 	0

I’ve examined the filter in ‘genesis_simple_menus’ and there are a couple of ‘slight’ differences between this and the filter you previously suggested, so I will try this out and see if it makes any difference.

Didn’t work.

I tried the filter like this..

add_filter( 'sitewide_tags_custom_taxonomies', 'my_swt_custom_tax_filter' );
function my_swt_custom_tax_filter( $taxonomies ) {
	$taxonomies[] = 'tumblog';
	return array_unique( $taxonomies );
}

But the main tags blog still does not get updated with the taxonomy, even though the sub-blog is updated correctly.

If the filter code is correct then is there any chance that the sequence in which it fires is the problem? – i.e. is it applying the filter ‘after’ the duplicate post has been written to the tags blog?

I’m not entirely sure how to debug a filter (i.e. set triggers to see which path it takes and in what sequence).

Since I have been unable to get a custom taxonomy filter to interact with SWT, I am now trying a post format after switching the settings within my wootumblog sites.

Ron, you state within your post – https://wpmututorials.com/plugins/sitewide-tags-update/ – that post formats are supported in the SWT plugin, but then you go on to provide the example of a custom post type, which is clearly a different entity.

The same problem persists now that I’m trying to use post formats – namely that SWT leaves behind these additional postmeta entries when creating the tags blog post. Have you any suggestions on how to pick up the post format and pass it as a single entry in the wp_postmeta table of the tags blog? I am presuming it wouldn’t be a good idea to just perform a wholesale write of all the post meta.

I have tried to perform get_post_format($post_id) within the sitewide_tags_post function in SWT, but I’m getting a NULL value despite $post_id being correct, so I am currently trying to figure out how to get the post format (from within the SWT function) and thereby update the parent tags blog post.

post formats are a built-in custom taxonomy. The post format taxonomy is post_format.

So what are you advising? Use ‘post_format’ as the taxonomy name in the above filter?

i.e.

add_filter( 'sitewide_tags_custom_taxonomies', 'my_swt_custom_tax_filter' );
function my_swt_custom_tax_filter( $taxonomies ) {
	$taxonomies[] = 'post_format';
	return array_unique( $taxonomies );
}

I tried the above change in my plugin, but no change to my wp_postmeta table to reflect the post_format elements which were saved at the same time to the sub-blog.

I even tried amending the taxonomies section within the SWT plugin to read as follows:

[Code moderated as per the Forum Rules. Please use the pastebin]

If I add in a

return false;

at Line 430, just before if( $post->post_status == 'publish' ) {

Then the post_format meta is successfully updated in the tags blog’s wp_postmeta, but I lose the the first four meta entries for the post, namely, ‘_pingme’, ‘_encloseme’, ‘permalink’, ‘blogid’

That doesn’t feel right to me. I thought maybe there was an errant ‘shift_array’ somewhere, but can’t see anything that would cause it – maybe all I’ve done is replace the main meta items with my new ones?

I can’t believe I’m still trying to get this plugin to work as described, but I’m determined to to leave an audit trail for other users so that they can avoid spending the time I already have.

For the avoidance of doubt, it’s easy enough to get the plugin working in its basic configuration – creating a tags blog of the core posts and metadata without further configuration. I had it working in less than 30 minutes, so if that’s all you’re looking to do, then read no further. The problems start when configuring for custom taxonomies or custom fields (i.e. additional post metadata) and perhaps (especially) when working within a BuddyPress installation.

I have tried every variation of the ‘add_filter’ suggestions provided on this post and elsewhere and in my configuration (WP3.1.2 & BP1.2.8), there’s not the slightest change in outcome from the SWT plugin. 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.

I’m sure it would be useful to know why, at the very least to flag the issue to other BP developers, but there seems little interest in doing so judging my own experiences – but hey, I’d be delighted if somebody could prove me wrong.

After failing to integrate custom taxonomies with the SWT plugin, I moved over to post formats and specifically the custom fields that I’m working with (video-embed, link-url, quote-copy, quote-author, quote-url, audio, image).

There is a routine within the **sitewide tags pages plugin** which takes a list of custom fields (entered in the admin settings) and then uses these as keys to read a post and output the keys and values in an array.

Here’s the routine within sitewide-tags.php: https://www.ads-software.com/extend/plugins/wordpress-mu-sitewide-tags/
*** line 369 in Version: 0.4.1.1 of sitewide-tags.php ***

$meta_keys = apply_filters( 'sitewide_tags_meta_keys', get_sitewide_tags_option( 'tags_blog_postmeta', array() ) );
		$global_meta['DEBUG TEST1'] = $meta_keys;
		$global_meta['DEBUG TEST2'] = $post_id;
	if( is_array( $meta_keys ) && !empty( $meta_keys ) ) {
		foreach( $meta_keys as $key )
			$global_meta['DEBUG TEST3'] = 'custom loop';
			$global_meta[$key] = get_post_meta( $post->ID, $key, true );
	}
	unset( $meta_keys );

I have added a small amount of markup to reveal what is happening at each step.

For my test case, post_id #1121, there is one custom field which sits in the wp_9_postmeta table has one meta_key ‘image’ with a corresponding meta_value ‘https://newsite.com/files/2011/05/alfaP.jpg’

However the routine returns no value within the function.

Here’s what each of the debug tests shows;

DEBUG TEST1:

a:7:{i:0;s:11:"video-embed";i:1;s:9:"image-url";i:2;s:8:"link-url";i:3;s:10:"quote-copy";i:4;s:12:"quote-author";i:5;s:9:"quote-url";i:6;s:9:"audio-url";}

DEBUG TEST2: 1121
DEBUG TEST3: Custom Loop

So the first test (#1) shows that all the custom fields are being returned from the ‘get_sitewide_tags_option’ on line 1. The second test (#2) confirms it’s looking at the correct post_id and the third test (#3) that it reaches the foreach loop and therefore passes the conditional clause.

I then added a further check to understand what the variable ‘$key’ contains whilst in the foreach loop. In fact, the custom fields are being held within the array but the loop returns NULL when it reaches the ‘get_post_meta’ command.

Is this another example where a standard WP command if failing within BP? Seems unlikely but I’ll escalate to the BP developer team just in case.

So, in conclusion if you’ve been told that the SWT plugin works flawlessly and are about to invest time in making it a part of your own network, then I’d advise you to run a few tests first just to be sure it can meet your needs. There is very little information available and few discussions to learn from, so hopefully this post will provide something to start with.

Here are some further references I would also recommend for anyone wishing to understand what can be customised:

https://dev.commons.gc.cuny.edu/2009/07/20/making-sitewide-tags-work/#comment-987

https://teleogistic.net/2010/08/enabling-popularity-contest-for-wordpress-networkwide-use/

You know … it occurs to me that BuddyPress, out of the box, does not pick up CPTs and toss ’em in the Activity Stream.
https://buddypress.trac.www.ads-software.com/ticket/2559 is a Wont-Fix too, and you have to build your own functions to pull it in.

So logically this would be a conflict with BP’s handling of CPTs, which is munging any other plugin.

By the way, out of the box, on a fresh build ot WP, it all works just fine, so logically the issue is your setup. Occam’s razor and all that :). And since I know you’re using BP, my gut feeling would be that it’s BP being a bit odd.

Is this another example where a standard WP command if failing within BP? Seems unlikely but I’ll escalate to the BP developer team just in case.

Actually I’d say that’s the MOST likely reason. Head over to buddypress.org and mention it there. It’s where the BP gurus hang out.

Thanks, I will dig a little deeper along the path of creating a custom function to duplicate the functionality of WP’s commands. It’s probably worth me doing that anyway as another test case.

This ‘cannot’ be an insurmountable problem – it’s only passing a few fields between tables..

I’m sorry to be persnickety, but I’m coming to this issue from a personal tap on the shoulder on buddypress.org, and I’m finding it very difficult to distill the issue out of the extensive and far-ranging discussion above. DoctorDR, can you sum up what you think the problem might be with BuddyPress?

I would by very, very, very surprised if BP were somehow interfering, as you suggest, with the way that core WP taxonomy functions work (like wp_get_object_terms()). I use such functions extensively in BP-related plugins, which also use custom post types. Ipstenu is correct to point out that BP does not “support” CPTs out of the box, but that’s in a very limited sense: namely, the activity functions hooked to save_post are set to bail if the post type is not ‘post’. This should not block you from doing whatever you want with CPTs.

Anyway, if you can summarize the problem in a few sentences, I might be able to help to figure out whether BP is indeed the problem.