<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	>
<channel>
	<title>Comments on: Extending BuddyPress Group Hierarchy &#8211; Join to Upstream Groups</title>
	<atom:link href="http://www.generalthreat.com/2011/12/extending-groups-hierarchy-join-upstream/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.generalthreat.com/2011/12/extending-groups-hierarchy-join-upstream/</link>
	<description>Dangerously different projects and code</description>
	<lastBuildDate>Sat, 07 Jun 2014 17:10:44 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>https://wordpress.org/?v=4.2.38</generator>
	<item>
		<title>By: W.J. Kok</title>
		<link>http://www.generalthreat.com/2011/12/extending-groups-hierarchy-join-upstream/#comment-64491</link>
		<dc:creator><![CDATA[W.J. Kok]]></dc:creator>
		<pubDate>Thu, 03 Apr 2014 08:28:35 +0000</pubDate>
		<guid isPermaLink="false">http://www.generalthreat.com/?p=74#comment-64491</guid>
		<description><![CDATA[Awsome! Thanks for sharing this piece. ]]></description>
		<content:encoded><![CDATA[<p>Awsome! Thanks for sharing this piece. </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Johnny</title>
		<link>http://www.generalthreat.com/2011/12/extending-groups-hierarchy-join-upstream/#comment-36175</link>
		<dc:creator><![CDATA[Johnny]]></dc:creator>
		<pubDate>Sat, 30 Nov 2013 16:45:14 +0000</pubDate>
		<guid isPermaLink="false">http://www.generalthreat.com/?p=74#comment-36175</guid>
		<description><![CDATA[Are you saying you can restrict which groups are available as parents? 
 
Can we do the top 3 in the chain? 
 
Cheers, 
 
Johnny ]]></description>
		<content:encoded><![CDATA[<p>Are you saying you can restrict which groups are available as parents? </p>
<p>Can we do the top 3 in the chain? </p>
<p>Cheers, </p>
<p>Johnny </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: intrd</title>
		<link>http://www.generalthreat.com/2011/12/extending-groups-hierarchy-join-upstream/#comment-710</link>
		<dc:creator><![CDATA[intrd]]></dc:creator>
		<pubDate>Tue, 17 Jul 2012 04:45:34 +0000</pubDate>
		<guid isPermaLink="false">http://www.generalthreat.com/?p=74#comment-710</guid>
		<description><![CDATA[David, thanks! this almost solved my problem.. 
but i have a problem with new groups.. a user who joined at the site_root in the past does not join automatically at the new parent groups.. 
I&#039;m trying to make SiteRoot group to show all Parent Groups streams without force members to join at all subgroups, did you have any sugestion?]]></description>
		<content:encoded><![CDATA[<p>David, thanks! this almost solved my problem..<br />
but i have a problem with new groups.. a user who joined at the site_root in the past does not join automatically at the new parent groups..<br />
I&#039;m trying to make SiteRoot group to show all Parent Groups streams without force members to join at all subgroups, did you have any sugestion?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: OC2PS</title>
		<link>http://www.generalthreat.com/2011/12/extending-groups-hierarchy-join-upstream/#comment-7</link>
		<dc:creator><![CDATA[OC2PS]]></dc:creator>
		<pubDate>Mon, 12 Dec 2011 15:34:53 +0000</pubDate>
		<guid isPermaLink="false">http://www.generalthreat.com/?p=74#comment-7</guid>
		<description><![CDATA[I understand that you don&#039;t want to go down the slippery slope of feature creep. 
 
In the example you have used, however, I think we are getting muddled in a fringe case or a corner case. If the on/off option is available, and privacy is a major concern the way you have described, then surely the site owners can happily not switch membership propagation ON. 
 
I know I am biased and want to resist the temptation of equating what I want with what &quot;most people&quot; want. However, since in the beginning of the article you say that this is a frequent feature request, I can&#039;t help but think that I am not the only one who wants this, and that membership propagation is not itself a fringe case. In fact, to be completely honest, I consider membership propagation to be a core requirement for a hierarchical group structure. 
 
All that being said, you have been so kind to already write up the core code for membership propagation above. It might make sense if you wrote up a plugin that adds upwards/downwards propagation (if BP Group Hierarchy is installed)...if not add this option to the BP Group Hierarchy plugin itself.... ]]></description>
		<content:encoded><![CDATA[<p>I understand that you don&#039;t want to go down the slippery slope of feature creep. </p>
<p>In the example you have used, however, I think we are getting muddled in a fringe case or a corner case. If the on/off option is available, and privacy is a major concern the way you have described, then surely the site owners can happily not switch membership propagation ON. </p>
<p>I know I am biased and want to resist the temptation of equating what I want with what &quot;most people&quot; want. However, since in the beginning of the article you say that this is a frequent feature request, I can&#039;t help but think that I am not the only one who wants this, and that membership propagation is not itself a fringe case. In fact, to be completely honest, I consider membership propagation to be a core requirement for a hierarchical group structure. </p>
<p>All that being said, you have been so kind to already write up the core code for membership propagation above. It might make sense if you wrote up a plugin that adds upwards/downwards propagation (if BP Group Hierarchy is installed)&#8230;if not add this option to the BP Group Hierarchy plugin itself&#8230;. </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ddean</title>
		<link>http://www.generalthreat.com/2011/12/extending-groups-hierarchy-join-upstream/#comment-6</link>
		<dc:creator><![CDATA[ddean]]></dc:creator>
		<pubDate>Thu, 08 Dec 2011 11:54:27 +0000</pubDate>
		<guid isPermaLink="false">http://www.generalthreat.com/?p=74#comment-6</guid>
		<description><![CDATA[This code could go either in a new plugin, or in your theme&#039;s functions.php file. That&#039;s a great question! I&#039;ll update the post to include this. 
 
And I&#039;m happy to elaborate. I guess what I failed to explain above is that this plugin is intended to allow BuddyPress groups to be subgroups.  Over time, certain things have been added: an interface for viewing a group&#039;s subgroups, a tree for navigating all groups, etc.  But all these features are about enabling subgroups , i.e. adapting the parts of BuddyPress that assume a flat group structure to accommodate subgroups. 
 
Adding features for membership or activity propagation starts us down the path of trying to enable anything anyone would want to do with subgroups. In addition to being practically impossible, this takes time and energy away from improving the core product. 
 
On top of that, what I was trying to describe in the post is that no feature is ever as simple as you think. Here&#039;s a quick example:  
You want &quot;just&quot; an option. But a global on/off switch for membership propagation means that anyone who can create a subgroup can circumvent the privacy settings of parent groups.  This would harm sites that use a parent group as a &quot;category,&quot; but who may want to use this function for child and grandchild groups. So, now we &quot;just&quot; also need a UI and code for stopping the process, or excluding groups from the process. Are all private groups excluded, or just top-level ones? Does it vary from install to install?... 
 
These kinds of issues, and the time needed to design and code and TEST these different scenarios, is why I won&#039;t just expand the scope of the plugin to include loosely-related features. ]]></description>
		<content:encoded><![CDATA[<p>This code could go either in a new plugin, or in your theme&#039;s functions.php file. That&#039;s a great question! I&#039;ll update the post to include this. </p>
<p>And I&#039;m happy to elaborate. I guess what I failed to explain above is that this plugin is intended to allow BuddyPress groups to be subgroups.  Over time, certain things have been added: an interface for viewing a group&#039;s subgroups, a tree for navigating all groups, etc.  But all these features are about enabling subgroups , i.e. adapting the parts of BuddyPress that assume a flat group structure to accommodate subgroups. </p>
<p>Adding features for membership or activity propagation starts us down the path of trying to enable anything anyone would want to do with subgroups. In addition to being practically impossible, this takes time and energy away from improving the core product. </p>
<p>On top of that, what I was trying to describe in the post is that no feature is ever as simple as you think. Here&#039;s a quick example:<br />
You want &quot;just&quot; an option. But a global on/off switch for membership propagation means that anyone who can create a subgroup can circumvent the privacy settings of parent groups.  This would harm sites that use a parent group as a &quot;category,&quot; but who may want to use this function for child and grandchild groups. So, now we &quot;just&quot; also need a UI and code for stopping the process, or excluding groups from the process. Are all private groups excluded, or just top-level ones? Does it vary from install to install?&#8230; </p>
<p>These kinds of issues, and the time needed to design and code and TEST these different scenarios, is why I won&#039;t just expand the scope of the plugin to include loosely-related features. </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: OC2PS</title>
		<link>http://www.generalthreat.com/2011/12/extending-groups-hierarchy-join-upstream/#comment-5</link>
		<dc:creator><![CDATA[OC2PS]]></dc:creator>
		<pubDate>Wed, 07 Dec 2011 19:58:45 +0000</pubDate>
		<guid isPermaLink="false">http://www.generalthreat.com/?p=74#comment-5</guid>
		<description><![CDATA[Thanks for this. 
 
I am a true novice. Which file are we talking about here? 
 
Not sure I understand the reasons you have given for not including this in the plugin at least as an option where admin can switch it on or off. Please can you elaborate a bit? ]]></description>
		<content:encoded><![CDATA[<p>Thanks for this. </p>
<p>I am a true novice. Which file are we talking about here? </p>
<p>Not sure I understand the reasons you have given for not including this in the plugin at least as an option where admin can switch it on or off. Please can you elaborate a bit? </p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Performance optimized by W3 Total Cache. Learn more: http://www.w3-edge.com/wordpress-plugins/

Page Caching using disk: enhanced

 Served from: www.generalthreat.com @ 2026-06-28 11:22:01 by W3 Total Cache -->