New BuddyPress Standalone theme for buddypress.org

[espellcaste]

Ticket to start a conversation, and planning, for the next theme of the .org sites.

Things to address:

• what sort of theme to build? (block-based themes, regular themes, etc)
• for what sites? (developer, codex, homepage, etc)
• where to host? (WP themes directory?, wp trac?, etc)
• New design?!

[espellcaste]

I plan on resolving all tickets with fixes or improvements related to the bp.org sites, and point them here. I don't think we should spend resources on those tickets since we have plans to build something new.

--

We don't need to have all worked out in this ticket, but we should at the very least plan on what to build and how so that we can get some traction. Baby steps. =P

[johnjamesjacoby]

Also important to understand what exists today and why it is the way that it is.

• Shared CSS, HTML, & PHP that is 99% identical between bbPress.org & BuddyPress.org
• Root sites
• Codexes
• Forums
• Trac header & footer using its template system
• BuddyPress language sites (largely decommissioned)
• Profiles.WordPress.org child theme
• BuddyPress Profiles (could/should be decommissioned for above, so there is only 1 central profile)

It ends up being a non-trivial amount of abstraction to have the same CSS & JS running on top of everything, so that header & footers stay identical, so users aren’t confused by unique designs/navs/links.

It isn’t even currently 100% perfect in that regard, and it’s always been very close, but nobody’s bothered to get it the rest of the way done.

I am 100% in favor of modernizing everything, and I’ll happily review & deploy it anytime! Just know going in that what exists currently is already as little code as necessary to make it work the way it needs to!

[johnjamesjacoby]

Since Profiles.WordPress.org is primarily where BuddyPress is used (Profiles, Groups, Activity) most of the interesting BuddyPress-specific stuff will end up living in that theme.

BuddyPress.org and bbPress.org are basically marketing sites, with Codex/API/Developer docs as subsites with their own unique page templates to support the layout needs of those kinds of pages.

For historical reasons, bbPress.org is also still a single-site install of WordPress, and Codex.bbPress.org is on the BuddyPress.org network. This could be either separated or merged, but it’s never been a priority because we’ve worked around it successfully using themes 😅

[imath]

Thanks for creating this ticket.

As we're a small contributors team, I renew my suggestion to kill many birds with one stone:

• Use a theme that demonstrates BuddyPress for users (hosted on WP Themes directory)
• Renew BuddyPress.org appearance.
• Make it a Block only Theme (it should be ​https://github.com/buddypress/buddyvibes imho)

[emaralive]

I'm not going to get involved with this one. Whatever the rest of the team comes up with is fine with me.

[vapvarun]

Just a wild thought: To save time, we could use the ​BuddyX Theme, which already includes profile and bbPress support. We can create a child theme for our header/footer-specific customizations. Starting from the default WordPress theme would be time-consuming. The primary goal is to bring BuddyPress and bbPress sites up to current standards, and since BuddyX is available on WordPress.org, there won’t be any issues. We can fork it or easily make any changes to it.

We will concentrate on BuddyVibes for a versatile BuddyPress theme. This theme will offer a customized community appearance and experience for BuddyPress users. It will be a long-term solution with full block support, but there are still many pending tasks for BuddyVibes, which will require some time to complete.

We can easily create a development copy of our existing site and test it with BuddyX, which could provide an immediate solution. Due to the nature of BuddyPress and bbPress sites, they require a hybrid theme with support for templates and block support for new posts and pages.

[espellcaste]

We are currently blocked by some information from @johnjamesjacoby So I'll punt this ticket until we get consensus on how to move forward without this feedback.

[SirLouen]

According to the 6th November meeting, we must consider two things

Deciding how the new theme will be made. @vapvarun suggested using BuddyX while, @imath suggests @buddyvibes.

AFAIK, the problem with block-only themes, is that they are untraceable, so basically 100% of the content will be over the database, which could not be on a repo, so it will be completely impossible to submit any changes or review anything except for people with direct access to the WP admin.

None of the sites in the WP Meta ecosystem are running a full Block theme, probably because of this.

Personally, I would rather choose the @vapvarun ​https://github.com/vapvarun/buddyx choice, moreover knowing that it's coming from him, which happens to have a good full code template structure, and we can have support from him, and even @imath contributed to it, I can only see advantages on this option.

This said, about the ​https://meta.trac.wordpress.org repo committing part, I'm doing my research on multiple places to see if we could add some extra committer there, so we could have more flexibility in the near future.

But for now, we hardly still have anything, maybe if there is consensus, we should start a fork from BuddyX and start the works for the revamping from there?

About the themes, judging by the current structure it seems that there are

​bb-base (parent)
|
├── ​buddypress (child)
└─── ​bbpress (child)

While codex subdomains (codex.bbpress.org and codex.buddypress.org), don't share the same parent, and they are completely independent (which they shouldn't IMHO). And finally, the @imath experiment in ​https://developer.buddypress.org which happens to have also, another theme.

Ideally, we should be merging all (codex, developer, etc…) into the main domains, and put all the required templates according to them.

Conclusion: First developing a new or adapting an existing theme (BuddyX) to a new bb-press parent theme for buddypress/bbpress new sites before looking at how it will be introduced in the sites. Anyway, I'm on my way of looking for more committer options, as I mentioned before.

Some final notes:

1. If we choose BuddyX, since @vapvarun is the original dev of this theme, maybe he could fork this in GitHub into a "bb-base" new parent and start working from there?

2. Considering that bbpress is moving into git docs, why not take advantage of this revamp and do something like:

​https://developer.wordpress.org/advanced-administration/
​https://github.com/WordPress/Advanced-administration-handbook/
Git administrated docs with a front face into developer.b*press.org?, inside the newly selected theme?

[SirLouen]

Update:

I've been researching for the documentation part, (aka developer.b*press.org)

Considering that the BuddyPress team has already started moving into GitHub/MD files, I think this can be seriously advantageous.

Talking with Javier Casares from the WordPress Administration/Hosting Team (who is also in charge of the Advanced Administration Handbook docs team), he showed me a tool that I have adapted a little bit to run over Docker locally for testing purposes:

​https://github.com/SirLouen/wphandbook

I have put in the README all the installation instructions, pretty straightforward.

Basically, with this tool, it's as easy as:

1. Create a specific CPT for docs (say codex)
2. Create the template file within the theme planned to be built here for such CPT (say codex.php)
3. Say that the index for the CPT is buddypress.org/codex/, dev.buddypress.org can be redirected to that page
4. Then we set up the tool to run towards an exclusive Documentation repository, say https://github.com/b*press/Codex
5. And set a cronjob to run nightly updates with this tool over the repository (we might need to speak with the systems people @ WP to see how this can be executed, or we will need to set it up as a plugin with some sort of wp-cron procedure, otherwise).

The codex.php template could look something like this:

​https://developer.wordpress.org/advanced-administration/
Very clean and simple template: Menu in the left, in the right the TOC (we can use wp.org-table-of-contents plugin is the one being used there), and the content which is being loaded with this tool.

And we will have sorted the Docs/Codex part, and will be WAY simpler for the Docs team in both BuddyPress and bbPress to work from now on (+ BuddyPress team can remove the docs' folder within the project). I find it a simple and neat solution.

I will be tomorrow 13th Nov @ 18H CET in the #buddypress channel for the Docs in case there are any comments regarding this specific part.

[SirLouen]

I have some updates on this topic. Yesterday I had a meeting with @johnjamesjacoby coming from the WP mentorship program, and we had the opportunity to discuss this topic more deeply and understand better his initial reluctance. I apologize for such a long post, but I've tried to put all the ideas that came into the meeting without missing much + some of the ideas I've been thinking afterward.

First, and foremost, the idea that @espellcaste suggested about creating and using a public repo theme appears to be incompatible with how meta sites work because it seems to be considered a security breach. And obviously b&bpress.org domains DNS are pointing to such host, so any other alternative won't be ever viable (unless you plan to create a brand-new domain for this purpose).

So if we plan to stay on the same domains, we need to go through the natural river bed which is the SVN.

About the SVN, currently JJJ is the only member who has access there, and given that we cannot count anymore with @imath for a long while, it seems that, from the "Meta team" perspective, is going to be very complex to postulate any other member to submit commits there (given that you get permissions to submit commits to the whole meta networks, including all the wordpress.org sites, which happens to be highly sensitive from the meta team perspective). It's "somewhat easy" to get access to the administration interface of the sites to publish this and that, for things like editing content, but not to the core underlying files (commit access). At least for now.

So if we truly want to make this change, we have to bear with these limitations. And at first, JJJ felt a little reluctant about the changes, and he expressed that there are 4 elements that should be sorted before stepping forward:

Main Meeting Topics

1. Firstly, defining the most important one for him was: What is missing in the current site that is worth updating and cannot be updated with what we already have. This seems simple, but it's a very complex question, and reading through the previous answers in this topic I don't get anything clear, apart from the design aspect, which brings us to the second point. I've been thinking a lot of this, and now I'm bringing up a couple of topics in my ideas section.

2. Secondly, the design part: how a new design could solve any problems that we might be facing now. For this, I have a very short answer: after the meeting, my partner asked me about it, and I told her that we were discussing the possible new site for the plugins and I gave her the URLs. As soon as she went into the pages, she showed surprise because she did not see a design like this since the year she finished her major (~2010) which happens to be by the time when these sites were built approximately. So yes, design is completely outdated and probably one of the main elements on why we are thinking about this, because of this ​this and ​this.

3. Thirdly, the technical challenges. JJJ was very concerned about the multiple integrations that current themes have. For example, as you may notice, this track header is the same template, as the buddypress.org header. This is just an example, but there seem to be a couple of technical complexities like this. And this leads to the fourth and last point

4. Lastly, where is the need of switch the base-theme? He meant, why could we not simply add improvements, but over the base theme instead of having to "reinstall" a brand new theme from scratch?

My ideas

Here are my conclusions to all these topics

1. About the "what is missing":

• Better docs site. Specially Handbooks. Buddypress is already doing a wonderful job with currently @emaralive in the had of this work. The same will be soon replicated for bbPress (I will take it for now, and hope to see someone to take over any time soon). Now, @emaralive is pushing over GitHub, which definitely is the way to go. This, added to the possibility of an integration as I explained in the previous comments, could make, a new template for developer.* or codex.* a massive addition for the b*press ecosystem.
• JJJ as also commenting about the possibility of doing an effort and fully integrating bbPress and buddypress profiles with profiles.wordpress.org
• Better news/events section, better Developer relationship section. And overall better developer onboarding protocol. I think that WP is doing a brutal job in this regard, something that bbPress has never flourished on (and I'm not sure about buddypress). Easy to compare this with this.
• And anything you can add here in the future comments. The more, ideas the better to convince JJJ that this has to be done inevitably and asap.
• The BIG question here is: Can't all this be done in the current theme? We need to evaluate this.

2. About the Design. One of the topics that came during the meeting was the fact that the current b&bpress.org themes, were originally exactly the same as the wordpress.org theme which goes back to 2013?.

And WordPress.org has stayed with this base theme until 2022 when they finally changed it. And this leads me to think: Why shall we not follow WordPress team and simply use their current theme with the right accent for each site? Wouldn't it be the simplest way to readapt our sites and keep some degree of compliance with the Meta team at a lower development cost?

3. And this leads to my last point: given that we already have some templating, why not simply rewriting over it? If we consider this WordPress theme idea part, it would be mostly migrating code from one to another and then adding any new features we have in mind to it, but respecting the current implementation, to tackle the technical difficulties more easily (since they are already implemented)
   1. So for example, if we happen to rebuild, just the header, it will be easily translatable to the Trac main header, since it will follow the same design patterns, but with a new design and menus.
   2. And also, instead of wasting a ton of tempo trying to communicate with JJJ who happens to be somehow difficult to communicate with, we could be tackling most of the technical elements, but they will be present in the current theme implementation, and we will be just writing on top of them without replacing.

Final Conclusions

1. According to JJJ, first we need a plan and something to show, not just ideas or something fast and poorly cooked that could bring more problems than solutions. He is mostly reluctant because he feels that, if at some point we end leaving the project, he will be the one having to maintain an unfinished project where he has not participated. So he wants to have everything clear and in order, to be confident that, in the case this event happens in the near future, he could take the lead and keep maintaining it as he is currently doing with the current sites.

2. We require ideas, specially on WHY we would like to move into something new and WHAT new we think we need. I've given some ideas, but anything extra will be relevant.

3. We need to start moving the needle in some direction. I'm going to start researching on a draft based on what I've written here and see its viability.

4. For now, the BuddyX Theme idea is discarded because it's too complex for a swift integration, and the blocks' idea, with Buddyvibes is not going to work either. Or we revolve around the current theme with a new styling proposed by anyway with design skills around us, or we consider the migration of the WordPress current theme idea as I have explained.