In keeping with our WordPress compatibility policy, BuddyPress 2.6 will require WordPress 4.1. See https://buddypress.trac.wordpress.org/ticket/7013.
Recent Updates
Dev Chat Summary for April 6, 2016
BuddyPress Work Party Recap
@dcavins reported that several tickets were fixed and closed during the party.
- Fixed. Make sure inviter_id !== 0 before inviting a user to a group (#6941)
- Fixed. Avoid using HTML tags in translation strings (bp-settings/bp-settings-template.php) (#6900)
- Fixed. Request: Allow Gravatar’s “d” param to be filtered (#6989)
@djpaulgibbs and @boonebgorges also identified other tickets that are close or ready to be committed, if anyone wants to get in on the fun:
- Profile Cover not working when we define a custom BP_XPROFILE_SLUG (#6962). Has patch.
- Cover Image location is incorrect for blogs other than the primary blog (#6931). Has patch.
- bp_core_print_generation_time() should echo only in WP_DEBUG mode (#6976). Has patch.
Trac Tickets
filter for $after_member_slug in bp-core-catchuri.php (#6694). Has patches from @dcavins, @boonebgorges, and @rayisme.
Group Types API (#6784). Has patch from @mamaduka. @boonebgorges would like to see the patch for the proposed Group Type UI before proceeding with the review.
Activity post form template improvements (#6680). Has patch. “The main template changes in the activity form ticket is markup changes for the placeholder and some new hooks. The rest are CSS/JS related,” @rayisme mentioned. @djpaulgibbs noted that the enhancement would break backward compatibility with themes. On another note, even if this new enhancement was used in a new bp-template-pack, this would (potentially–we’re not certain, yet–see “homework” below) break backpat with some BP plugins.
Discussion then ensued about what constitutes “breaking backpat issues” – HTML/style enhancements or JS/break functionality of BP plugins or both – which prevent or halts adding new enhancements to BuddyPress. @dcavins then said, “The activity stream/post box was mentioned in the BP survey results last year, and some of the alternatives were pretty impressive. I don’t want BP to fall far behind on key UI/UX bits.”
Homework (for whoever’s interested): Try the patch in #6680 [with BP plugins and themes -Ed.] so we can revisit next week with surety in our hearts about the way forward.
Route /me/*/ to /members//*/ (#6325). Has patch by @dcavins. @djpaulgibbs noted that a decision should be made on where the redirection should be done. @boonebgorges has since commented in ticket to handle redirect in a callback function via new action/filter hook.
Framework for bulk data handling after updates (#6841) @boonebgorges: “I’m most concerned about upgrade flow, and how it affects the technical infrastructure. From my experience, people are afraid to click upgrade DB buttons. You can blame WC for that :)” From @imath: “A lot of users are not backing up their DB before a plugin upgrade, i think we should inform them to do it and then let them click on a button to launch the routine.”
“Since it sounds like we want to require user action here, I think we should just start with an existing UI – doesn’t matter which one (bbPress, imath’s, whatever) and use it as a framework for talking about database locking, batch processing, etc. Migrations probably need to have a UI if only to report any errors. If we ever want to migrate activity favorites (or anything else) to generic relationships, that’s another use case. Anyway, I think we should start with an existing AJAX-based UI because they already exist, and we should solve some of the other problems first,” per @boonebgorges.
Behat for BuddyPress. @djpaulgibbs reported, “There is no documentation. This is annoying. That is all.” @boonebgorges linked to an article about Codeception, a possible alternative.
Style Modules @hnla requests more feedback on the proposal here at bpdevel to get a consensus.
Special BP Template Pack Meeting
What: Template pack by @im4th
When: Wednesday, August 13 @ 18:00 UTC
Where: #buddypress channel in Slack
Who: All interested parties are welcome to join @dcavins, @im4th, @hnla, and @mercime
Slack log: https://wordpress.slack.com/archives/buddypress/p1459969462001401
Dev Chat Summary for March 30, 2016
BuddyPress 2.5.2
@dcavins, release lead for BP 2.6.0, packaged and released BuddyPress 2.5.2 on Thursday, March 31. This fixes some email issues reported in trac and forums.
BuddyPress 2.6.0 Schedule
- Beta 1: May 25, 2016
- Release Candidate 1 (string freeze): June 8, 2016
- Target Release Date: June 15, 2016
- There are 95 tickets slated for 2.6.0 to date. Forty-seven of 79 tickets still open have patches.
Weekly Meeting Time
Join us every Wednesday at 19:00 UTC at the #buddypress channel on Slack. @djpaulgibbs encouraged anyone who wants “to participate in these meetings but can’t always make it can leave comments in Slack beforehand” or in posts here at bpdevel.
For newcomers, here’s how to get a WordPress/Slack account.
BuddyPress Work Parties née Bug Fixin’
A friendly reminder from @dcavins re invitation to a party on Slack or Trac to fix ’em bugs this coming Tuesday, April 5 and Thursday, April 14.
2.6.0 Scoping/Wishlist
BP REST-API. @dcavins followed up on the status of this project, i.e., whether we can work on this or should this hold until WP API gets sorted. @djpaulgibbs noted that “WP API is sorted. You/we can work on it now.”
BP Style Modules – A Proposal. @dcavins asked for more information about the proposal. @hnla: “Style modules is an additional enhancement for templates, more for engaging the community and providing a means to add small code blocks, similar in the way frameworks offer them sometimes.” @boonebgorges and @hnla later exchanged a series of enlightening comments about some of the details of @hnla‘s proposal.
A new API to manage single items navigation (#6534) @boonebgorges passes baton to @im4th to save this ticket from oblivion. @im4th brought up the issue of an upgrade routine to implement this feature which requires Framework for bulk data handling after updates (#6841).
Incrementor-based caching for ID queries (#6643) @boonebgorges is looking to implement this for at least one component during 2.6.
Accessibility tickets. @mercime will be working on the ones already in trac and will be adding some more later.
Explore Behat to add a functional testing capability to the project. @djpaulgibbs‘ dream is look into adding a functional testing capability to the project. “I don’t know if this is something that we’ll want, but I need to build it before I can convince everyone.”
New bp-template pack @djpaulgibbs is trying to come up with a plan to answer the never-ending questions around if/when BuddyPress will ever get a new one. “I’ve started with asking about eight of you some questions around that. It’s going to be a lot of work to come up with some kind of plan. I got essay-length replies from everyone and each reply is vastly different. Everyone has a very different opinion. I think some goal-setting needs to occur before we are able to write new templates with 100% buy-in from everyone, but it’s still early days and I reserve the right to change that opinion.”
Group Types API (#6784) @boonebgorges mentioned that it would be good to make headway on this ticket. Ping @mamaduka
2016 BuddyPress Survey (#6792) @mercime will conduct this year’s survey after the April 15 tax day.
Activity link moderation doesn’t output useful error message to end users (#6719) @rayisme has made some headway on better error messages in the activity stream. “Question is should we be holding off on this for an activity_status DB column.” @boonebgorges noted that the “main issue would be documenting that select * from $bp->activity->table_name queries will have to be adjusted accordingly.”
Slack log: https://wordpress.slack.com/archives/buddypress/p1459364425000688
BuddyPress Work Parties
At the end of the 2.5 development cycle, a rare event occurred: many friends of BuddyPress happened to be working together (I mean at the same time and in the same Slack channel–we always work together in spirit ). It was super productive and entertaining, to boot. Let’s try to harness the magic again.
If you’d like to help out, please join us at these times:
You can help out by adding new tickets, commenting on tickets, testing patches, writing patches, writing content for the Codex, answering questions on the BuddyPress support forum, or offering moral support. We’d love to have you.
BP Style Modules – a proposal
User Submitted Style Modules
This post is a RFC to gauge feedback from the wider BP community for an idea I have been mulling over and sketching out in rough code locally.
Outline
Style Modules is a concept that seeks to provide or explore a means to add CSS and JavaScript snippets to existing themes in a modular sense for BP elements or components – think Members list ul/li constructs or user profile messaging table lists – allowing developers to work on specific aspects of BP’s components adding style enhancements or added JS functionality.
Why Modular? Modular is a method we can use to provide added enhancement in easy to manage smaller ‘chunks’; small enhancement files created by the BP development community where they can concentrate on improving a given area without feeling bowed down by an overwhelming challenge.
Modular because users can download and install just the enhancement they desire without effecting aspects of their BP install they’re happy with.
The Primary Benefit(s):
There is in this proposal one overriding aim, that prompted thinking this through to very basic implementation which is that the BP project is able to bring to the community a further means to engage in the project and to feel even more a part of that project as a contributor acknowledged as such by their module inclusion.
As we’re all aware engagement is paramount for a healthy project, the more people that feel engaged and involved the healthier any project is; this is one means to further that aim and to bring people in to contributing, and contributing at a level that could as equally suit mid range coders as more advanced coders, and where the established developers can mentor and advise where it helps.
A secondary benefit would be that BP gains far more by way of enhancement to it’s components and gains a growing library users can peruse and download modules they like the look of, which install in a very simple fashion by simply dropping into the correct sub folder.
The Approach
So far the approach to implementing this idea and which I’ve been working from is thus:
A module is defined in a ‘folder'(directory) that lives under the BP folders /community/style-modules//buddypress/style-modules/
The user needs to create the /style-modules folder (conversely we could possibly create programatically, but would rather avoid that)
The folder /style-modules/ is a critical one we scan for this folder and don’t continue if not found.
A module is defined as a folder e.g /bp-members-list-module/ this folder constitutes the ‘module’ as uploaded to the repo or downloaded to users site theme directory for use.
In the ‘module’ we have a series of files that validate the module, in the simplistic offering this folder will contain a stylesheet, in more advanced ones we might also have a supporting JS file or perhaps just a JS one (JS supporting styles was my original thinking). All modules will contain a readme.txt file (maybe in .md form), the stylesheet will use style headers in a similar manner to WP stylesheets. Both the style file and the JS file if included take the same name as the module directory name, using just the file ext to identify the type (file headers could expand this though & partly why they are mentioned)
By example in a practical module or example module to use as a skeleton we’ll set out some guidelines to follow for a module to be considered for inclusion.
An example initial module might be member lists as panels(boxes) – often desired; a module would provide this styling for members lists to work for twenty* themes.
Loading the Modules:
Loading up the modules will be relatively trivial and involve a directory scan and fopen to enqueue an array of files, for local purposes I’ve run a simple scandir and fopen looping out the files to build an array on files I find as long as the ‘modules’ parent is located otherwise I’ll bail. This process we already do do in BP’s templates functions.php so I propose we simply extend that to check for this folder given two criteria are met 1/ running a BP overloaded theme 2/ having the existence of a folder named ‘/modules/’
If BP provides the mechanism for loading automagically then it’s easy for users to use these files, and an incentive for dev to produce them.
Curating & Location:
My proposal would be that we maintained a ‘modules’ repo on BP’s github account in which modules would be kept available for download, along with instructions for use.
BP would be making it clear that while the modules were tested not to cause any major issues it didn’t guarantee that they would work for all themes/installs.
Curation would be amount to one or more devs stepping up to test a new module to work in a couple of main WP themes, not in detail but not to cause issues, then a scan of the files to ensure basic formatting standards were adhered to. All in all this shouldn’t be too much of a burden on existing BP team, as not expecting hundreds to be submitted, although would be only too happy if that were the case, this would also be something that could be a task for aspiring new contributors to tackle, similar to the way theme reviewing works.
Comments & Feedback:
Would love to hear some thoughts and comments from the wider community as to whether this idea has any merit, I certainly think it does; yes there are pros and cons and I have deliberately not included the cons at this stage as want to avoid the negative and focus on what might work and if thought viable then tackle the cons in the process.
One definite pro is that overall setting this up is not a huge amount of work!.
Looking forward to comments good or bad.
Hugo.
Dev Chat Summary for March 23, 2016
BuddyPress 2.5.2
Four tickets have been slated to date for this milestone. Possible release date: March 28, 2016.
Release Leads for BuddyPress 2.6.0 and 2.7.0
@djpaulgibbs, @boonebgorges, and @johnjamesjacoby have been talking about what they could “adopt from WordPress core’s development processes and see how they work out for BuddyPress.” Starting 2.6, we’re going to have release leads as described in this RL announcement in WP Core by Andrew Nacin.
@boonebgorges noted, “The RL gets a sense at the beginning of the dev cycle what he/she would like to accomplish, as well as what others want and are willing to contribute. Within those parameters, there is likely lots of room for the RL to make decisions about what the focus should be.”
David Cavins will lead BuddyPress 2.6. @dcavins (twitter) has been a member of the BuddyPress Core Team since January 2015. David is a huge fan of the groups component and the collaborative possibilities it offers a community. He also builds acoustic guitars in his adopted hometown of Columbia, Missouri.
Next at bat for BuddyPress 2.7, @mercime has been a member of the BuddyPress Core Team since April 2014. Mercime (twitter) enjoys building sites with an eye on accessibility as well as contributing to open-source projects like BuddyPress, bbPress, and WordPress via trac, codex, forums, theme reviews, and surveys.
BuddyPress 2.6
@dcavins will be setting the release schedule this Wednesday during our dev chat. One of the things he’d love to see are optimizations, like extending “our use of caching to group memberships, for instance.” (#6327). He’d love to get everyone’s feedback on ways to make BP run more lightly, “so please be thinking about your favorite component.”
BuddyPress 2.7
@mercime will share the focus and scope at a later time. In the meantime, @bowe suggested, “a release cycle focused on the community aspects. Bring some lesser known but awesome BP stuff to the forefront and implement some long standing UI/UX improvements and rethinking of what BuddyPress should be in 2016 and onwards.”
It takes a strong volunteer community to improve the BuddyPress project for each release. Your contributions are most welcome and appreciated!
Open Floor
1. Theme Review
@djpaulgibbs reiterated @karmatosed‘s invitation to join the WP Theme Review Team and review BuddyPress-specific themes currently in queue.
Hey amazing BuddyPressers :wave: – I come bringing good news. We have 4 themes waiting for theme review for BuddyPress which is unusually high. Unfortunately I also bring bad news and we don’t have enough reviewers anymore to do this without it taking ages for the poor themers. I know you’re all super busy, but if any of you with theme experience want to give us a hand it would be brill!
For those interested, please read how to conduct a theme review. @bowe mentioned that he will be reviewing a theme this weekend.
2. BuddyPress.org Theme and Plugin Pages
@bowe is currently working on the outline of the proposed new theme/plugin pages to replace the ones @djpaulgibbs deleted the other week. Let someone know at the #buddypress slack channel when you’ve got something ready Bowe.
3. Audit of Components in BuddyPress Trac
@offereins inquired about other development process ideas which the Lead Developers found useful besides having release leads, like having component maintainers and whether BuddyPress would benefit from the concept. @boonebgorges and @johnjamesjacoby noted the pros and con. @djpaulgibbs opined that BP trac components would probably need some review to see that they’d fit into this kind of model (BP Components e.g. groups would be way too big). @boonebgorges stated, “That would be a good first task for someone interested in making it happen.”
Result: @offereins has accepted the task of auditing components listed in BP trac
Slack log: https://wordpress.slack.com/archives/buddypress/p1458763237000341
As usual, BuddyPress’ dev chat…
As usual, BuddyPress’ dev chat is moving back to 19:00 UTC, thanks to DST. America switched a few weeks ago, and Europe switched yesterday. If you’re not sure what that is in your local timezone, check here.
