Lemmy

—
ignore, posted in error

Sorry, the link got lost. See here:
https://wordpress.stackexchange.com/questions/23522/wordpress-site-causing-lots-of-server-io

term_relationships and postmeta entries are also deleted.

DELETE a,b,c
FROM wp_posts a
LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id)
LEFT JOIN wp_postmeta c ON (a.ID = c.post_id)
WHERE a.post_type = 'revision'

By the way, I tired switching off the multi-user option in your plugin and it was not saved – it was ticked again when I reloaded the page. (WordPress 3.5.1, Buddypress 1.6.4)

Thanks, I’ll try your fix.

A temporary solution is to make sure that the function is not redeclared:

if ( !function_exists( '_bp_groupblogs_refetch' ) ){
    		function _bp_groupblogs_refetch() {
    			global $bp; ?>
    			<script type="text/javascript">
    				jQuery(document).ready( function() {
    					jQuery.post( ajaxurl, {
    						action: 'refetch_groupblogs',
    						'cookie': encodeURIComponent(document.cookie),
    						'group_id': <?php echo $bp->groups->current_group->id ?>
    					});
    				});
    			</script><?php
    			groups_update_groupmeta( $bp->groups->current_group->id, 'bp_groupblogs_lastupdate', gmdate( "Y-m-d H:i:s" ) );
    		}
}

However, I don’t see the _bp_groupblogs_refetch() function being called at all from anywhere. Certainly the javascript it writes is not showing up on any of my pages.
Perhaps someone else has an idea if this code is actually functional?

@kaktusan – I already had my cache folder set to 777. That wasn’t the issue for me.
I did some work on another plugin that was throwing some Fatal Errors, and the Super Cache plugin seemed to start working more smoothly. The built-in cache test works successfully for example. I’ve still got error suppression switched on, so I don’t know if that’s fixed.
Maybe it’s a timing issue triggered by another faulty plugin? The cached file is removed before WPSC gets a chance to do it? I haven’t looked into the plugin deeply enough to know.

Looking at the code, it seems that this can be fixed just by forcing
$update_users = true;
in groupblog_edit_base_settings.

Hi,
FYI – I just updated to v1.7 and this issue still seems to be present.
A workaround seems to be to change member status to admin and back again in ‘Manage Members’. That’s not really practical for large numbers of people though.
Was it supposed to be fixed in 1.7? I’m still using Buddypress 1.2.9
Thanks.

I tried this:

add_action( 'create_group_blog', 'bp_groupblog_member_join' );

But it seems that the function called checks to see whether group members are already blog members:

if ( !is_user_member_of_blog($user_id, $blog_id) ) return false;

Is there a special reason for this? I thought the idea was that all group members should have authorship rights on the group blog, as long as ‘enable member posting’ is checked?

Excellent, thanks.

Yes, there is a thread here:
https://buddypress.org/community/groups/bp-groupblog/forum/topic/fix-for-subdomains/

In short, the blog name is not available from the path value when using subdomains – it’s necessary to get it from the domain value instead.

By the way, I’ve customised the External Blog plugin to easily add feeds from all the group members’ blogs. They’re displayed as a list with checkboxes, in addition to the standard text box for external feeds. If anyone’s interested, let me know.
I’ve excluded any blogs which are also group blogs – as I’m worried about groups getting feeds from other groups in case a feedback loop is set up. (i.e. groups are subscribed to each other.) I’m not sure what would happen but I’m guessing that the internet would eat itself.

Sorry to exhume this.
I’m wondering how I might go about adapting this so that the blog posts of members of a group (that is, posts to their own blogs, not the group blog) are also integrated into the activity stream?

By the way, I posted a fix to the groupblog subdomain issue over on the buddypress site.