[@jeffsayre Participant 16 years, 6 months ago]

The milestone you have set is okay. Also, I bumped the priority up to critical.

https://trac.buddypress.org/ticket/2293

[@jeffsayre Participant 16 years, 6 months ago]

Yes.

function do_something_cool () {



// Code to do something cool



}

add_action( 'bp_core_something', 'do_something_cool' );

You could even add your own custom hook so that others could then modify the outcome of your do_something_cool function. So:

function do_something_cool () {



do_action( 'before_something_cool' );



// Code to do something cool



do_action( 'after_something_cool' );



}

add_action( 'bp_core_something', 'do_something_cool' );

[@jeffsayre Participant 16 years, 6 months ago]

Make sure you have read this first: https://codex.wordpress.org/Plugin_API

Here you can find a listing of most (all?) of the current WordPress hooks: https://codex.wordpress.org/Plugin_API/Action_Reference

Here you can find a listing of BuddyPress hooks, although this is out of date:

https://codex.buddypress.org/developer-docs/action-reference/

As far as your particular project, you probably can find the proper hook to tie into by searching the register.php file in the BP default theme. There are many hooks you can use.

Also, if you want to learn more about the current BuddyPress hooks, I would recommend searching for all “do_action” and “apply_filter” calls within BuddyPress.

[@jeffsayre Participant 16 years, 6 months ago]

As this is not an issue of overall BuddyPress privacy, but rather a malfunctioning action of hidden groups, I would call this a bug.

@ajohnson-

As far as privacy in BuddyPress, there are many threads about that topic that will provide you with an answer.

You can start here for a hint: https://buddypress.org/forums/topic/privacy-component-where-is-it

[@jeffsayre Participant 16 years, 6 months ago]

@Gpo1-

That was my kind way of saying that you hijacked the thread, taking it off topic.

[@jeffsayre Participant 16 years, 6 months ago]

@Gpo1-

Yes. But, that is a topic for a different thread.

[@jeffsayre Participant 16 years, 6 months ago]

I reread your post and deleted what I had previously written. If I understand your request, wouldn’t hidden groups be the solution? You can already do that in BuddyPress.

If Group A and Group B are both hidden groups, then only members within a given group would have access to the activity stream of that group. So, Group A members wouild not be able to see Group B activities and vice versa. The ony exception to that would be if a user was a member of both groups.

[@jeffsayre Participant 16 years, 6 months ago]

Hiding private messaging is another feature of the BuddyPress Privacy Component.

[@jeffsayre Participant 16 years, 6 months ago]

@hnla-

I would post that in Trac as a possible bug.

[@jeffsayre Participant 16 years, 6 months ago]

Only time will tell. I imagine a competent lawyer could argue that Channel Definition Format (CDF)–the original subscribable news feed and the precursor to RSS 2.0–was created by Microsoft in the mid 1990’s long before Zuckerberg even knew how to spell computer. It led to the wide-spread use (via RSS 2.0) of creating and distributing syndicated content throughout the Internet.

http://www.oreillynet.com/xml/blog/2006/12/who_invented_rss.html

So, did Facebook invent the news feed? No. They may have been one of the first to have locked it inside its own walled garden–which is antithetical to the spirit of the news feed. But IMO this is just an application of the concept, not a demonstrable innovation of something sufficiently new and patentable.

I imagine that some of the earliest blogging networks (before Facebook’s time) might be seen as early walled gardens and therefore their RSS feeds could be looked at as internal to the network. If you weren’t a member, you could not get access to the feed. So WordPress could then be viewed as the facilitator of the first internally-subscribable news feeds.

As a fully-licensed and practicing armchair lawyer, I look at this as just another example of a very large, powerful company being able to successfully overinflate its importance and contributions to the USPTO. Clearly the lead government patent lawyer failed the public on this one.

[@jeffsayre Participant 16 years, 6 months ago]

The siteurl and home (url) are required by BuddyPress to properly determine where it needs to look to find its various support files. So, that is why you could still access BP but the layout looked funky. BP could not resolve the path to the theme’s CSS files.

If you changed the url back to the original, proper path, it all should work now without any issues. Is that the case?

I assume that you were trying to provide your friend some assistance to a different issue. If you have a new issue, unrelated to this particular topic, please start a new thread and mark this one resolved.

By the way, for future reference, the topic you posted here is a WordPress issue and not a BuddyPress issue. That’s fine that you posted here, but if you have additional problems related to this particular issue, I’d suggest posting in the WordPress forums instead as most people here ignore issues that are not BuddyPress specific. I just happened to be looking at the right time!

Of course, if you have BuddyPress-specific issues, then post them in these forums.

[@jeffsayre Participant 16 years, 6 months ago]

Based on your description of where you were and what you did, I assume that your friend’s install is running WordPress and not WPMU (the multiuser version of WP). All is not lost.

You need to gain access to the backend of the MySQL database that is being used by WP. The easiest way to do this is via phpMyAdmin. Your friend’s hosting provider should have a version of phpMyAdmin. Your friend, or whomever created the MySQL instance for the WP install will have the username and password for the MySQL database–which is different than the one used for WP Admin access. If they don’t have it, you can find it in the wp-config.php file of the WP install.

Once you have access to the MySQL DB, you navigate to the wp_options table (the first two letters of the table name might be different). In that table, search for two entries: “siteurl” and “home”.

They should both be reset (this is what you did) to ventureforchange.com. You need to edit those two separate fields adding back the “/community ” reference. Of course, do not include the quotes.

Once that is done, try accessing the Admin dashboard again. It should now work.

[@jeffsayre Participant 16 years, 6 months ago]

I’ve read several of the threads that you have started on this topic–and a few that you did not but have posted within–and I am still not clear what you are after. At the top of this thread, you state that:

How do I create “Main Themes” for forum discussions the way Buddypress did it here

You then list the names of the BuddyPress forums: Installing BuddyPress, How-To and Troubleshooting, etcetera. In other threads you refer to these as forums, or boards, or subforums.

For the record, what you are referring to as “Main Themes” are topics. I realize that the BuddyPress forums uses that phrase as a column heading, but it’s best to refer to them as forum topics or forum categories. Otherwise, it can be confused with the entirely different issue of creating themes for outputting content.

From all of your various threads and posts, it is not clear to me if you are having issues with:

1. Getting your external bbPress install to display properly in your site
2. Whether you are having issues in theming your external bbPress install so that it matches your BuddyPress theme
3. If you are trying to get the contents of each group forum from your internal bbPress install to display as separate forum topics (categories) within your external bbPress install
4. Whether you are trying to add forum topics (categories) to each group forum of your internal bbPress install

I’ve come to this game late, but a read through all of your postings has me confused about your real issue.

[@jeffsayre Participant 16 years, 6 months ago]

Thanks, Boone!

Action hook firing sequence is confusing. I think the sequence of actions, and their priorities, need to be carefully looked at in BuddyPress.

By the way, I clarified my above post a little and added some additional thoughts to it while you were more than likely reading an older version. So, please reread my post above.

[@jeffsayre Participant 16 years, 6 months ago]

Okay, I’ve just gone through BP core and commented out all references to the plugins_loaded event accept for in bp-loader.php. I then refactored these references to hook into bp-init instead. All hooks worked fine accept bp-setup-nav. I had to set it to no priority or a priority lower than ten to make my navigation items show up in my plugin.

So, I outputted the various do_action arrays and discovered the issue. It is as I thought above–somewhat.

Not only does WordPress search for action calls top-down and alphabetically, it then reorders all action calls for a given hook by priority and if no priority is given, by the order in which it first came across a given action reference. Yes, I know, this is probably confusing most of you. Without seeing the output it may be too complex to visualize.

Here’s why my navigation menu was not showing up:

– All third-party plugins are now supposed to hook into the bp-init event

– The function in my plugin’s loader file that does that is called ‘BPAz_init’. It hooks into bp-init as follows:

add_action( 'bp_init', 'BPAz_init' );

– As you can see, I do not set a load priority on that action

– With the bp_setup_nav event (see line 2025 in bp-core.php) now tied to the bp-init event, instead of plugins_loaded, in my test core hack, and without setting any priority

add_action( 'bp_init', 'bp_setup_nav' );

it gets fired after my BPAz_init function and my plugin’s navigation menu appears

– But, if I set a priority below 10 for the bp_setup_nav event, my navigation fails to load. If I set a priority above 10, it loads. So,

add_action( 'bp_init', 'bp_setup_nav', 9 );

does not work, but,

add_action( 'bp_init', 'bp_setup_nav', 11);

works. My plugin’s navigation appears and functions.

So, the question is why?

Here’s the answer. It has to do with the fact that the function in my loader file that calls the bp-init event is found in a file that comes alphabetically before the file in which the function bp_setup_nav exists.

So, my function BPAz_init lives in a file found in /bp-authz/bp-authz-loader.php but function bp_setup_nav lives in /buddypress/bp-core.php. When the do_action function is processing the array, it sorts them first by priority and second by the order in which they were first loaded. Since my initialization function lives in a subdirectory that is searched before the buddypress subdirectory, my function that is hooked into the bp-init event is discovered before the bp_setup_nav action. This means that if no priorities are set for either function, things just happen to work fine by simple virtue of my plugin directory having a lower alphabetical order and thus higher search priority.

But if I set the priority for the bp_setup_nav action to be higher than ten (as in 9 or lower), then it is fired before my plugin is ever initialized and therefore my navigation menus cannot be rendered. If I set the priority for the bp_setup_nav action lower than ten (as in a number equal to or greater than 11), then my plugin is initialized before the bp_setup_nav event and my navigation menus work.

If I had not serendipitously named my file to something that has a higher alphabetical order than “buddypress”, I may never have discovered this issue. But, the moral of the story is this: the bp_setup_nav event must occur after all BP-dependent plugin’s have been initialized, otherwise their navigation menus will not appear. So, with the bp_setup_nav event tied to plugins_loaded, it fires before all BP-dependent plugin’s have been initialized. But, by setting a low-enough priority, it is possible to push that particular action of plugins_loaded to after all the BP-dependent plugin’s have been initialized. This is, of course, not the best way to do this.

As there may be other BP actions that are loaded too soon, I will need to spend a little time figuring out what this means for all the other action hooks in BuddyPress and BP-dependent plugins. The order in which an action fires can obviously be crucial. Since the firing order is based first on priority set, then on the alphabetical name of the functions that call a given hook, this can result in unexpected behavior.

Confused? Me too!

[@jeffsayre Participant 16 years, 6 months ago]

Okay, within BP, the plugins_loaded hook is added to nine times. I’m not positive on how WP searches for actions that are added to a given hook once fired, but I assume it is a standard directory search pattern–meaning top down, alphabetical. (Although I have not looked at function do_action to see if my assumption is correct.)

This means that for all activated plugins, once the plugins_loaded event is triggered, WP will first find the added actions to this hook in BuddyPress/bp-activity.php, then /bp-core.php, then finally bp-loader.php. After that, it will begin searching all BP subdirectories beginning with the BuddyPress//bp-activity/ directory.

What does this mean? It means that the single add_action to the plugins_loaded event in /bp-activity.php will be fired first, then the six added actions in /bp-core.php, and finally the single added action in bp-loader.php. This might be the root of the problem.

Since any added actions to the plugins_loaded event will be triggered no matter where they are (assuming a given plugin is activated), it causes an issue if crucial supporting code to a given function is not fired before. There is no reason for the plugins_loaded event to be referenced more than once within BP. The single occurrence of that in function bp_loaded is sufficient. From there all other added actions to the plugins_loaded event should be replaced with bp_init.

Also, no BP-dependent plugin should reference the plugins_loaded event because it will cause a conflict if BuddyPress is deactivated but for some reason that BP-dependent plugin is still active.

Instead, BP-dependent plugins should either reference the bp_init hook, or create their own custom hook.

Refactoring the aforementioned added actions in BP to fire on bp-init instead of plugins_loaded will more than likely not only solve the issue of the bp-set-nav hook not working, but also the bp_setup_root_components hook and the bp_setup_globals hook, and possibly any other hooks that we have not yet discovered are not working.

I also would recommend that priorities be set on all bp-init actions within BP core so as they are fired in the proper sequence and so that any future BP-dependent plugin that comes before “buddypress” alphabetically does not have any of its actions that are added to bp-init fire before others with in BP.

[@jeffsayre Participant 16 years, 6 months ago]

The issue is that any BP hook that ties into the plugins_loaded event must be fired in the proper sequence. For some reason, the default of not setting any priorities–which is usually a safe way to approach adding to any action hook–misbehaves in this case.

More than likely the culprit is that a necessary support function (or two) gets fired out of sequence, therefor not providing the required support for the function in question.

So, for the bp-setup-nav function to work, its add_action call must set a priority that does not cause it to be fired before any need support function.

I have not yet created a Trac ticket as a I think more sleuthing is needed to determine the proper sequence, and therefore priorities, for all added actions to the plugins_loaded hook within BP.

[@jeffsayre Participant 16 years, 6 months ago]

My aforementioned Privacy Component will offer fine-grained filtering of any activity stream content–that is as long as the plugin developer made sure to register all the activity stream actions for their component. No need for fancy bp-custom.php functions, core hacks, and the like.

[@jeffsayre Participant 16 years, 6 months ago]

Once my BuddyPress Privacy Component is out, Site Admin’s will easily be able to exclude their activity from the stream! And, since I know people will ask:

https://buddypress.org/forums/topic/privacy-component-where-is-it

[@jeffsayre Participant 16 years, 6 months ago]

Lots of questions to address, so I’ll do it in the order they were posed.

@stwc

On the BP install I’m currently working on, the following long list of plugins (all of which seem to be working flawlessly activated non-sitewide) do not even offer the option for Site-wide Activation.

Is there a reason (or reasons) for that? Is there any possible downside? Or are they fine the way they are?

These plugins should work fine whether or not they are activated sitewide. However, there are two reasons why a BP plugin should be tagged to activate sidewide automatically:

1. Because they are BuddyPress-dependent plugins and require BuddyPress to work. Since Buddypress operates sitewide, then all add-on plugins are sitewide-acting by implicit reference.
2. By virtue of the first point, only Site Admins should have access to any plugin configuration. Offering all members with blogs access to these BP-dependent plugins in their admin dashboard only creates confusion as these plugins are for BuddyPress only and not for WordPress blogs.

______________

@hnla

So for clarity if one adds ‘Site Wide Only: true’ to pluginin files main description then it forces site wide activation regardless of whether one chooses to activate normally non site wide

This is correct. When the Site Wide Only tag is set to true, it does not matter which activation link is clicked as either action will result in sitewide activation. In fact, for all BP plugins I test, I simply click the “Activate” link right under the plugin name and not the “Activate Site Wide” link. If the plugin then shows under the Site Wide listing of plugins, I move on. If it does not, then I know that the plugin author failed to set the tag properly.

Edit/ found a plugin that already had ‘Site Wide Only: true’ set yet does not activate site wide using the plain activate link placing it self in the site wide section unlike bp-links. Is there something else that must be set to enable the site wide activation link or the ability to force the plugin to activate site wide?

Not that I am aware. It might be that the plugin has two Site Wide Only tags and there is a conflict. To which plugin do you refer?

______________

@MrMaz

Still unsure if I should add this tag to my plugin header. Shouldn’t it be up to the site admin to decide how the plugin is activated?

See my response in this post to @stwc. Since your plugin requires BP to operate, there is no value in letting non-admin members have access to your plugin via their blog dashboard. The more you can do to make installation, activation, and operation of your plugin foolproof the better. Is there actual functionality that your plugin offers if activated non-sitewide? What features of your plugin even make non-sitewide activation a desirable option to Site Admins?

______________

@hnla

In an ideal world I would like BP installed much as is but described differently but along with BP are installed a series of modules that can be activated or not by admin but that these are only activated from within BP so to speak always sitewide as BP is these modules representing some essential core set of features

I agree completely. I always refer to BuddyPress as a plugin suite but that never sat quite right with me. BuddyPress is a feature-rich platform as far as I’m concerned. It transcends the idea of a simple WordPress plugin. I also agree that many of the BP “plugins” are best described as modules as well. In fact, I consistently refer to my privacy “plugin” as the BuddyPress Privacy Component to separate it from the idea of it being just another plugin.

I could see the possibility of BuddyPress modules having their own set of 3rd-party plugins. So BuddyPress > 3rd-party BP modules > 3rd-party module plugins.

I also like your idea of requiring that all BP-dependent “plugins” get activated within a BuddyPress dashboard–instead of outside of BP. That could take care of all activation conflicts.

In my version of an “ideal BP world”, BuddyPress would become the foundation of the WordPress ecosystem as it is a user-centric platform and not blog centric. WordPress then would be a layer that sits on top of BuddyPress and could be activated if desired. So, Site Admins would install BuddyPress and then could check a box to install WordPress (in single or multisite mode), bbPress, and other modules.

Now I’m taking this thread too far of topic.

[@jeffsayre Participant 16 years, 6 months ago]

Clear you browser’s cache and cookies then try again. You should be required to sign in once again.

[@jeffsayre Participant 16 years, 6 months ago]

All BuddyPress plugins should be activated sitewide. Since they depend on BuddyPress, they will only work with BuddyPress. This means they will only work on whichever blog BuddyPress is associated. So, although they are technically activated sitewide, they only work on the main blog–the blog that BuddyPress works on.

Now non-admin users can see Facestream admin options in console.

Yes, that is a problem with that plugin.

[@jeffsayre Participant 16 years, 6 months ago]

If you are truly using the default BuddyPress theme, and are logged out, then you should see a login box / create a new account area near the upper right-hand corner of the homepage.

Look at http://testbp.org/ for an example

[@jeffsayre Participant 16 years, 6 months ago]

This is a simple fix. Sometimes BuddyPress plugin developers do not set the proper plugin header tag to make their BP-specific plugins activated sitewide–which means that everyone with a blog has access to the plugin and not just the Site Admin.

So, go to the main files of each of the plugins in question and look for this in the header:

Site Wide Only: false

If you see that, then you make the following change:

Site Wide Only: true

Of course, if you do not even find that tag in the header section, then you add it.

BUT, before doing that, make sure you have deactivated the plugins in question. Once you’ve done that, make the change, save the file, reactivate, and it should now work sitewide only. This means that only the Site Admin will have access to the plugin settings and activation in the admin dashboard.

One final thing to do, since you’ve discovered this issue with these plugins, please help out the community by contacting each of the plugin developers and pointing them to this thread.

[@jeffsayre Participant 16 years, 6 months ago]

https://buddypress.org/forums/topic/where-is-my-forum