[kalico]

Thanks @shanebp. At the time when I wrote that snippet, I researched carefully the different template tags, and selected those to each perform a different purpose. Now I’m not sure how to change the code, so I need to do more research.

So if I may rephrase my question….where can I find information on the available template tags that is accurate, up-to-date, and provides enough detail to help me decide which one(s) to use?

The template tags reference page says:

This page is currently undergoing review and updating. References marked with ? have been reviewed for current accuracy.

This statement has graced the top of this page for over 3 years. Changes have been made to this page since then, but there are only two items on the page that have the “?” to indicate that they are currently accurate. The rest is left to be doubted. Many items have no explanation at all.

I also wonder why you had to send me to hookr.io to find out that bp_is_home is deprecated. Forgive my ignorance, but is that a vetted or official source for BP code? Other template tags are noted as deprecated on the template tags reference in the codex, which I thought was supposed to be the comprehensive reference.

So I can easily fix the warning message; however, my deeper intent is to figure out how to get accurate information so I can properly code my projects.

Any advice would be greatly appreciated. 🙂

[kalico]

Hallelujah! After MUCH ado, I have finally figured out what the heck is going on here.

At first, every change I made per the instructions from @hnla and @r-a-y had failed. I was sure it must be something in my set up, so I did a LOT of detective work and testing, and finally discovered multiple sources of problems.

Although it’s unlikely this will be relevant to many others, I am posting it just in case it might help someone. I always like reading other people’s solutions — it often gives me fresh ideas, even if it’s not an exact fit. So here goes….

1) I was copying my page.php from my child theme to use as /groups/index-directory.php, and it was breaking the groups directory page. Well…it’s in the child theme because it’s been modified from the parent theme, and whatever mods I made were not playing nice with the BP template hierarchy system. When I copied page.php from the parent theme, it worked just fine. (Maybe that’s why they are theme devs and I am a lowly hacker…)

Now having solved the problem of which file makes the best template for a new groups directory, I had to figure out how to actually affect the area of the page that I want to affect: the section where the tabs and the group search live. Those are not in the page.php file, they are coming from somewhere else.

I hunted down some bits of code that were in the section I wanted to modify, and searched all the theme and plugin files on my system for that snippet, and discovered the next problem…..

2) The only place that the code exists is in BP Groups Hierarchy plugin, and BP itself. I had BP Groups Hierarchy (old version, with Ray’s compiled updates) enabled, along with an older version of BuddyPress (due to incompatibility issues between new BP and old BP Groups Hierarchy). Within this environment, the BP Groups Hierarchy plugin was actually taking over the display of the groups/index.php so none of my changes were showing up.

3) The next thing I realized is that I have a customized community.php file (a.k.a. buddypress.php) which is where my buddypress loop actually lives. Or, more specifically, that file is pulling content-page.php. So I had to use that file (which had already started out as a copy of the parent theme’s page.php) to create a working and fully compatible template.

In a nutshell, my new groups/index-directory.php goes something like this:

The first part comes from COMMUNITY.PHP, which is a customized version of the PARENT THEME’S PAGE.PHP

Then the PAGE TITLE CODE is copied from the child theme’s CONTENT-PAGE.PHP

Next I replace THE LOOP from COMMUNITY.PHP with the ENTIRE CONTENTS of the original/default GROUPS/INDEX.PHP. We’ll call this the “new loop”.

After the “new loop” section of the code, then my CUSTOM COMMUNITY.PHP FILE takes over again, filling out the rest of the file with the sidebar and footer.

Note: Somewhere in here, I had to add a ?> to close the PHP. Can’t remember exactly where, but something I copied did not have a closing PHP tag. So if you get a blank screen, that would be a good place to look. 🙂

I’ve posted my entire custom index-directory.php in a gist in case anyone wants to see it. It is commented in 4 places where I transitioned from one fragment to another. You can search on “GROUPS INDEX TEMPLATE” to find the comments in the gist. My parent theme is Zerif Pro, and I have a customized community.php/buddypress.php file. so you CANNOT JUST COPY this code. It just serves as an example of how I cobbled the code together to get a working template. Hope it is helpful.

Grateful thanks to Ray and Hugo for all the assistance and advice!

[kalico]

Thanks @r-a-y. That’s very helpful. Appreciate the correction. I’ll give that a shot.

[kalico]

Hi @r-a-y, Thank you for the reply. My parent theme doesn’t have that file, and yes I am using a child theme already, and I do understand that it doesn’t work with bp-default themes, but it SHOULD work with bp-default templates – no?

For reasons I don’t understand,

/bp-templates/bp-legacy/buddypress/groups/index.php

does not work as the index.php file when copied to

/community/groups/index.php

Now, if you’re saying I should not expect it to, then….what should I use as my template for the groups index?

If I’m reading correctly, @hnla says I should just use a regular page template from my theme, and strategically add in the contents of /bp-templates/bp-legacy/buddypress/groups/index.php (which, as he points out, is not a complete file with header, etc) and call it index-directory.php. (And thank you, @hnla for the reply as well 🙂 )

I can do that. However, I haven’t found any documentation to that effect, and it seems to be much more complicated than the template hierarchy documentation implies:

Therefore, you can modify any bp theme compatibility template by copying it over from:

/bp-templates/bp-legacy/buddypress/

To:

/my-theme/community/ or /my-theme/buddypress/

That is what I have always done, and I’ve never had this much trouble with it before.

I have other template modifications to make, and if Hugo’s instructions are correct, it would be really helpful to know where the documentation is, in case I have further issues.

If the template hierarchy page is correct, then something is wrong with my site, because I’m following those instructions (in spite of my original faux pas of using “themes” instead of “templates”).

Thanks in advance for any further clarification you can provide.

[kalico]

I’m now trying to re-word my original response, so hopefully it will get past whatever filter is preventing me from reposting the dropped message.

Thanks @danbp. Unfortunately, this wasn’t the solution I needed. Partly, perhaps, but not entirely.

As you pointed out, I was wrongly copying files from bp-themes rather than bp-templates (a codeblind mistake on my part). But I was doing everything else correctly, in terms of file structure and use of /community/ according to your write up.

I went through my steps again, this time copying

/bp-templates/bp-legacy/buddypress/groups/index.php

over to

/community/groups/index.php

with zero impact. (I test this by adding a bit of text in a spot that should display on the live site, and it does not show up. Tried several different places, no effect.)

This would seem to demonstrate that BP is not reading that index.php file at all. It’s only reacting to the template change if it is called “index-directory.php”.

I changed the file name (without moving the file) from index.php to index-directory.php, just as I did before, but again, it did not work as expected. The groups directory page picked up the new template, but it displayed a completely stripped-down version of the page, with no CSS at all (white background, default font, everything left-aligned, etc).

I have been assuming that the index.php file would be a proper starting point (a template) to create custom modifications to the groups directory page (i.e., index-directory.php), but clearly that does not hold true.

This seems very strange, because in looking at the php code in index.php, it’s got all the elements I see in the source for my live groups directory page. So it appears to be getting that exact same information from “somewhere else” within the plugin structure, but I can’t figure out where.

My question is now: What file should I use as a starting point to duplicate my existing groups directory, so I can make custom modifications?

I do hope you (or someone) can point me in the right direction. Thanks in advance!

[kalico]

I don’t know what’s going on here — I made an edit, and when I hit “submit” my post was gone. I’ve force-reloaded the page several times, and still my post does not show up. However, when I try to repost the same information, I get a message “ERROR: Duplicate reply detected; it looks as though you’ve already said that.”

If you do not see my reply above (it should be the 3rd message in this thread, this one should be the 4th) then please write back and let me know, and I’ll attempt to repost it.

Thanks.

[kalico]

Thanks so much for the reply, @r-a-y. I used @dcavins’ fix and it worked to fix the count, but it broke the group search function. When I search for a public group, it doesn’t show up in results. I’ll post over at the community for additional help with that.

I’ll post back here with results so you can (potentially) do that merge.

[kalico]

I solved this problem by rolling back to BP v 2.6.2. Further testing required to see if this is a bug, or a conflict with my set up.

(Looks like I neglected to mention in my op that I was on v 2.7.0. Updated several days ago, and did not notice any issues until last night….but from the backups I’ve been looking at, it seems the problem must have cropped up immediately when I upgraded.)

[kalico]

There are a few ways to do this, and it depends a bit on why you want to do it. If you are in development, and just want to ensure that no users get emails while you’re working on stuff, I highly recommend Postman SMTP. You can configure it so that all emails get logged, but not actually sent. It’s very useful for troubleshooting and for protecting your users from accidental mail. But with the ability to still see what “would be” sent, if you were live.

If you have a different goal — like just eliminating the sign up or activation emails, that’s a different thing. If you post up a bit more detail, I’m sure you’ll get the info you need. 🙂

[kalico]

I tested by creating a new group. The new group has no admins on the frontend, but I am the admin on the backend.

[kalico]

Another test group:
http://beta.nrocnetwork.org/community/groups/nroc-member-groups/eracebranford-adult-education/

Has an admin on the backend, but no admin on the front end. No members (that’s legit).

I tried adding a member to the group in admin. The member shows up on the front end (but still no administrators for the group, even though there is one in the backend).

When I promote the new member to be an admin, the site reverts to showing no administrators at all. Both admins are still admins on the back end.

I cannot demote the original admin to member on the backend.

[kalico]

Thank you @walkerdesign1. I’m not sure I would have ever considered that the filename would be too long, but that fixed the problem for me. This could really use some improved error handling.

[kalico]

Sorry for the delay — I’m the lone dev on a project right now, so my attention is scattered.

I did not roll back the db, although I should have. The old version seems fine (so far!) with the upgraded db.

Not sure what to look for that might be broken…..?

[kalico]

I’m getting a blank page for all groups, and some topics (I can’t see a pattern yet to which topics are blank). It’s so blank that there is nothing in “view source” at all (usually when it’s a theme problem I get something there, like basic body/html tags – just not enough to build a page).

I’m getting ready to test for theme issues. But I definitely determined that a rollback to the previous version fixes the problem.

EDIT: I should mention that it happens in TWO themes: BuddyBoss and Zerif Pro. So I suspect it’s a BP or plugin problem, not theme.

I realize, however, that this could be a different problem than you have reported, so I will just watch this thread, and start a separate one if my problem persists.

[kalico]

Thanks @r-a-y – I actually came back here just now with exactly that thought in mind, now that it’s been narrowed down. Thanks for providing the links. 🙂

I’ll head on over there and summarize the issue as it now stands.

[kalico]

Same as it was, @sharmavishal. Just on the one site.

[kalico]

Hi @sharmavishal ! Thanks for asking! bbPress was network activated initially (the CBOX plugin activates everything network-wide; it is a “network only” plugin). But as per my last post, I deactivated it from CBOX and activated it just on the one subsite (the root blog for BuddyPress).

After some additional testing tonight, I’ve narrowed down the problem a bit more. At least I know which CBOX plugin is causing the problem:

1) I deactivated all the CBOX plugins, except for BuddyPress. Tested forums/groups and it all appears to be associated properly. The users can see the private forums in private groups. Yay!

2) I activated the “Group Email Subscriptions” plugin via CBOX, since that one is very important to our existing setup. Forums/groups associations are still working fine. Yay again!

3) I activated the “Docs” plugin via CBOX, and WHAMM! It clobbered my forum visibility! Now only admin can see forums on the front end “group” pages. I tried deactivating it from CBOX (which makes it network-wide) then activating it just on the root site for BuddyPress, and it still has the same breaking effect.

We really need “Docs” working, so now the focus is on figuring out why Docs is breaking the forums.

I suppose my next step will be deactivating other plugins to see if one of them is causing a conflict with “Docs”.

I hope someone has an idea to share! 🙂

[kalico]

I may have managed to shake out some of these issues by de-network-activating bbPress, and re-activating it just on the root BuddyPress site. I rebooted my permalinks on that site, and that part seems to be improved.

However, I still have the core problem: Private forums are not associated with their private groups. Users see a message that says

When I try to repair those relationships (groups/forums) the message says, “Repairing BuddyPress group-forum relationships… Complete! 0 groups updated; 0 forums updated; 0 forum statuses synced.”

[kalico]

Hey, thanks for the advice, Brajesh! I actually intended for it to be network active — but I guess I need to be open to considering other alternatives. My multisite is for a single company. We were aiming to have users’ BuddyPress account dropdown information on the admin bar no matter what site they are on, and this setting (network active, but hosted in a secondary site) seems to have accomplished that (without making BuddyPress active in the primary site, which didn’t work for other reasons).

From your suggestion, and I correct in understanding that this behavior I’ve seen is indeed related to being network active, with a subsite root blog for BP defined?

[kalico]

Thanks @r-a-y!

[kalico]

@Henry second run at the code worked perfectly. Thanks!!

[kalico]

I ended up (mostly) resolving this issue by using the Commons in a Box plugin. It has two checkboxes in the “Settings” area that allow you to set the Group and Member default tabs to “Forums” and “Profile”, respectively. Lifesaver.

[kalico]

Thanks to both of you! I will try WPMU.

I am curious — if anyone has the time or inclination to enlighten me — what differences I might encounter between Buddypress on MU vs. normal WP? Or if there is any documentation somewhere….? Thanks.