Links from BuddyPress plugin to relevant doc pages/buddypress.org

[emaralive]

This is a placeholder, reminder and discussion regarding links from the BuddyPress plugin to relevant/respective documentation pages. In other words (IOW), over time links may become stale due to a variety of reasons.

Help Tabs

Location	Status	Actual Link
Extended Profile	link to GH docs Closed issue #287, PR 348 & Trac Ticket 9217)	Using Extended Profile
Activity	no link	TBD
Groups	no link	TBD
Manage Signups	link to GH docs Targeted for BP 14 Closed Trac Ticket 9149 (Commit 13856)	Managing Pending User Accounts
Profile Fields	link to GH docs	Managing Profile Fields
BP Tools (manage invitations)	no link	TBD
BP Tools (manage opt-outs)	no link	TBD
BP Settings (components)	link to GH docs	Managing Components
BP Settings (URLs)	link to GH docs	Managing URLs
BP Settings (options)	link to GH docs	Managing Settings
Member Types	link to GH docs Appears to be for BP 14 (Closed PR 254, Trac Ticket 9122 & Issue #152)	Managing Member Types
Site Notices	pending issue #169 & Trac Ticket 9098	TBD
Site Health (info)	link to GH docs Appears to be for BP 14 & 15 (Closed PR 228 & Trac Ticket 9093) Closed Issue #4 & PR 390 Closed Trac Ticket 9237 & Trac Ticket 9245 Closed Trac ticket 9256)	BuddyPress Site Health Documentation
Editing Activity	link to codex Pending issue #256	Managing Activity
Edit Group	no link	TBD
Group Types	link to GH docs Targeted for BP 14 (closed issue #224, Trac Ticket 9183 & PR 314)	Managing Group Types
BuddyPress Emails	link to GH docs Targeted for BP 14 Closed issue #281, Trac Ticket 9159 & PR 291	Managing BP Emails
Edit Email	link to GH docs Targeted for BP 14 Closed issue #281, Trac Ticket 9159 & PR 291	BP Email tokens usage
Add a New Email	Pending	TBD
BP Tools (Repair)	link to GH docs Targeted for BP 14 Closed Trac Ticket 9161	BP Repair Tool

No Help Tabs

The following list is open to discussion regarding whether these pages/screens should have Help tabs :

Note

A check will indicate that the item should have Help tab and link to relevant documentation page.

• Group Types
• BuddyPress Emails
• Add a New Email
• Edit Email
• Member Types
• Site Notices
• BP Tools (Repair)

Hello BuddyPress!

Note

When reviewing possible topics for the User Handbook, I ran into somewhat of a conundrum on how to handle this if screenshots are used and the fact that the current BP version is depicted, along with various links may change in the future. This is currently a placeholder/reminder to flush out a strategy or tactical process to handle this situation regarding possible updates.

Tip

The Changelog link depends upon the version that is installed; IOW the link will be to the relevant version information regarding the specific release.

Location	Status	Actual Link
What's new	Text Built in	Hard coded into class-bp-admin.php
Changelog	Link to Codex	Releases
Get involved	Link to Codex	Participate and Contribute

[imath]

Thanks for initiating this discussion @emaralive It's a very good initiative. To me, I believe we should try to include an help tab to each screen we're adding into the Dashboard. In other words, I think we can create "Add" tasks for missing ones 😄 . What do you think @dcavins ?

[emaralive]

Cc: @vapvarun

OK, I've placed check marks for all items that had no help tabs to indicate that they will eventually have help tabs, perhaps a single Trac ticket can take care of the help tabs or depending on the logistics of documents existing for each screen may require single Trac tickets for coordination, since there will be a requirement for links within the help tabs to their respective doc pages, along with having an "Add" Issue created within this repository for tracking purposes. Furthermore, I'll add the 2 items (Member Types & Site Notices) to the rough form tracking table, since @vapvarun had volunteered to provide doc pages for those item during the Feb 7th, 2024 doc-chat.

Additionally, regarding help tab links, the anchor elements should contain the target="_blank" attribute, as mentioned by you (@imath) , and I'm not sure if we need the rel=”noopener noreferrer” attribute, of which I'll leave for further discussion.

Backing up a bit, for those of us that may not be aware or have forgotten, Member Types & Site Notices have placeholders for links within the following document :

Note

Member Types & Site Notices are just 2 examples, there are other documents with such placeholders, maybe I should gather them up and list them so they don't fall through the cracks.

BuddyPress Administration - Users

Which means that this page needs to be updated with the relevant links for Member Types & Site Notices, when those pages are available.

Another point of view is that when one (maybe only me) looks at the Users submenu items, one might wonder why the Extended Profile is not a submenu item because the Extended Profile tab on the Profile page/screen is always available and it doesn't appear all that intuitive that it would be a tab on the Profile page/screen; in other words (IOW). it would be easier to find if it was a submenu item (just saying) ,

Furthermore, there are some submenu items that have dependencies to specific components being enabled, e.g. Extended Profiles → Profile Fields & Private Messaging → Site Notices, of which I'm not finding information of such on the BuddyPress Administration - Users page nor another (in addition to) possible place the help tab for Components. It boggles the mind why Site Notices is dependent on Private Messaging and not Notifications, however, neither here nor there, what is important is that these nuances should be explained within relevant places of the documentation.

OK, this reply is getting a bit lengthy, I had plans to describe what I found when looking at documenting the Extended Profile page/screen/tab, in short, some potential improvements and whether or not the improvements are worth doing along with other whatnots such as back-end & front-end (Extended Profile has both of these aspects which may be similar to @vapvarun comment about Group Invitations, etc. ) but, I'll save that for another day. Last but not least, @vapvarun suggestion about additional links in the help tabs to relevant sections within a given document, most likely, should be done, given that a document is setup such that this can be done, e.g., the use of headers for sectionalization.

[imath]

@emaralive excellent point about SiteWide notices. I'm going to open a ticket on Trac because it's a bit too bad this feature is dependent of the Messages component. The notifications component would probably be more consistent I agree. But I believe we should make it a Core feature as 11.4 showed we may need to notify admins no matter what components are active. We should improve our current workaround about it to use BP Notices and introduce new notice types: all users, writers, admins.

[emaralive]

I concur with the notion that Site Notices should be available in Core as a basic feature. The reason I use the nomenclature Site Notices as opposed to SiteWide Notices is because the menu item is labeled Site Notices because I have no other references (seems to be missing from any previous documentation or I've yet to discover such references). Additionally, the enhancements are a good idea (all users, writers or role types or even member types, depending).

Something else to consider is that Site Notices show up on each individual members area. Due to the way BP is set up, a member could be oblivious (unaware) to the fact that there could be a Site Notice waiting for them to read. Meaning, I previously mentioned during the last dev-chat (Feb 5, 2024) that I was a member of a BP site geared towards photography. When I visit the site I'm taken to the SiteWide activity stream/directory, from there I can visit various groups that I am a member of and then leave the site without visiting my members area.

Interesting enough, whether this is a workaround or not is that the site admin uses sticky activity posts in lieu of Site Notices and/or sends out a News Letter. Lest I forget, I've informed the site admin about BP 14, he has some interesting words about the potential of moving to other platforms such as BuddyBoss or PixelFed due to a variety of reasons but more so for what the site admin feels as lack of support, abandoned plugins, etc, putting it into a nutshell. I'm getting off topic so, I'll stop at this point because I'm wanting to make about Member Types, it;s relationship with Extended Profile and the tie in to the back-end and front-end. Additionally, more needs to be discussed regarding collaboration (how to collaborate) with documentation.

[vapvarun]

Group Invitations
Group Forums
Group Roles
We can add a couple of more pages dedicated to group components, as a single document will be too large to cover all aspects.

[emaralive]

What I find confusing is trying to document a topic from the perspective of whom; meaning site admin or member for example Group Roles:

• What are they?
  • Administrator
  • Moderator
  • Member
• How are they assigned?
  • Back-end (site admin)
  • Front-end (site admin, group admin)
• Where should this be documented?
  • Good question (not about which handbook but more in line with Getting Started or Introduction to Groups or Attributes of the "User Groups" component or what?)

How this was documented before is Page ID 1688 from the Codex list Group Settings and Roles, of which is obviously outdated. To add confusion to an already confusing situation consider the following screenshot fragment from the Editing Group screen (BP 12.2.0):

Versus the Editing Group screen (BP 14.0.0-alpha):

As I see it, there isn't a method/process/procedure for UI changes, what screenshots are affected; it appears that one has to stumble across such changes and be cognizant enough to notice the change, albeit the person(s) who have made the change is aware of such change. OK I'll stop here because I have to make time for a different post.

[imath]

Hi @emaralive the 14.0.0-alpha screenshot should look more like the 12.2.0 screenshot. I believe in the first case, you are using trunk where the BP REST API is not built but available from the BP REST plugin's repo. In the second case you're using a built BuddyPress. During the build process the BP REST plugin's is included into the BuddyPress plugin. If the BP REST API is not available the Group's Admin UI is falling back to a legacy UI.

[emaralive]

Thanks for the enlightenment, on the surface (for me) there wasn't an apparent dependency for needing the BP REST API for the Group Edit screen. However, we still need a process for UI changes that can potentially affect screenshots and/or text within related doc pages, e.g., Trac Ticket 9092 -Member type have no default title. Additionally, I see a need for coordination between version releases and document availability, e.g., Issue #4 ([Add]: BuddyPress Site Health panel), Improve BP debug info #228 & Trac Ticket 9093 - Improve the BP Site Health debug info panel, this change affects the contents of the Help tab.

[imath]

Totally agree, I know @renatonascalves will improve the Debug info panel to include information about defined BP Constants (See https://buddypress.trac.wordpress.org/ticket/9101). Once this is done, we'll need to update the doc as well as the Help tab. I believe this part can be achieved in the same PR.