BuddyPress 2.5.0 Beta 1 is now available. Get testing !
Autoload BP classes (#6853) @boonebgorges noted the performance benefits in chat and in ticket. Update: “Rough benchmarks are showing a pretty consistent memory savings of between 1.5 and 2MB, on a local dev installation that has about a zillion plugins running … And with some further rearrangement in the future (so that components are loaded in a sleeker way) we could get that number down even further.”
All classes should be in their own files (#6870) @boonebgorges indicated that “it’s possible that full autoload (#6853) will reduce BP’s memory footprint by 10 or 20%” with the moves for all components. Update: This has been committed to core.
BP_Attachment::get_image_data() unit test is failing due to upstream change (#6868) @im4th has created ticket in WP Core because BP unit tests for `BP_Attachment::get_image_data()` were failing due to changes upstream. Update: The fix has been committed to core.
- Beta 1 is scheduled for today, February 8.
- There are now 86 tickets slated for this cycle. (Closed: 73. Active: 13.)
- From @boonebgorges: We’ll need to assemble a beta post by Monday. Traditionally, this has been a bullet-point list of big features, along with pointers to anything that needs special attention from users/developers testing the beta. I have outlined some of the new features already, but if people think of other things, they should speak up.
Slack log: https://wordpress.slack.com/archives/buddypress/p1454530078000766
Comment syncing between activity and post comments for Custom Post Types (#6842) @im4th needed to run an upgrade routine to add a new activity meta to activities about a blog post and consulted whether he could do this using a regular upgrade routine or wait for #6841 to be fixed to committed to core. @boonebgorges, @djpaulgibbs, @johnjamesjacoby, @rayisme, and @dcavins joined in the discussion to find the optimal solution in the upgrade routine. @im4th also suggested using a dynamic meta_key so that he could avoid the upgrade routine. Update: @im4th has uploaded a new patch which shows that using the dynamic meta_key can avoid an upgrade routine :)
- Beta 1: February 8, 2016
- RC 1 (string freeze): February 22, 2016
- Target Release Date: March 2, 2016
- There are 126 tickets slated for this cycle to date. (Closed: 41. Active: 85)
This post outlines a proposed task within the BuddyPress project that will attempt to identify and relocate all core html markup that currently lives in core files to theme file locations.
There exist a number of functions in core that are almost exclusively markup related (
bp_directory_*_search_form() reference throughout this article as one, that live in the component bp-*-template.php files.) there also exists a degree of code replication due to the nature of component files that would seem to be unecessary.
Why is this something we should be concerned about? There are a number of reasons why this approach is perhaps not to be considered optimal and broadly speaking the following…
- (very loosely) the belief that a separation between backend code and frontend code is to be the preferred goal always – mixed scripting and markup can lead to hard to maintain code blocks.
- In a plugin paradigm where developers know they can’t modify core files locking markup into those core files just leads to increased work to be able to modify and manage that markup.
Now in BuddyPress terms it does need to be pointed out that whereas we do have markup in core files it is and has been written in as clean and thoughtful a manner as possible, and provision is made to be able to filter, for example, the search form markup in its entirety so developers can write their own markup, return via add_filter to effectively replace the entire form.
So what is the problem then? The problem or problems might be thought of as:
- Replication of markup – core writes a search form 4 times once for each component, bulk action markup for messaging occurs repeatedly.
- In respect of our search forms they are, in reality, one form that only changes classes and query args so we should be writing one form with logic to add the correct class/query arg for component.
- A developer needing to adjust a form for any reason, lets say to add a new token, would need to stop find a convenient file to write a new function in and filter that back to the core function, possibly having to do that for four instances; either way a two sec job to add a new class becomes substantially more involved.
- It is not so much the Cores responsibility to write markup this is the province of template files, at most, Core is required to provide template tags or functions to return out ? query arg as appropriate.
- While Core retains control over this markup it makes things harder in respect of building clean new fresh templates – if those templates are having to reference functions that are perhaps not optimal, that might carry inherent issue through – moving the responsibility for that markup/functionality to template files allows us completely re-write the markup with absolute freedom.
The current task exploratory progress:
I started a wider discussion a while back on tasks pertaining to the ultimate goal of creating a new set of templates files to replace bp-legacy (often we refer to new template packs, I prefer though not to use this phrase in reference to what I see as the base level theme_compat template.)
This somewhat lengthy and admittedly ? rambling ticket can be read here: https://buddypress.trac.wordpress.org/ticket/6556
To achieve the wider goal I realised that really the issue of tackling core markup was required in advance of any other tasks, and actually could stand as a useful task in its own right even if further template updating wasn’t tackled.
In https://buddypress.trac.wordpress.org/ticket/6844 I started this process of with a patch and approach to dealing with Search forms as an example to work with.
In the initial patch I removed the search form markup to a new file, which I then located in a new folder under the template parent and included from the buddypress-functions.php file, one immediate issue was the apply_filters that existed for each search form function as this meant backwards compatibility had to be taken into account, if any function had been filtered we needed to honour that also in each template we called the search forms in using a unique name, both of aspects required a re-think on the approach I’ve used in the past replacing function calls and creating a new single form function checking components to add correct query arg, my initial approach then was to write out the existing functions in my new file but in each I called in a new form block so that I only need deal with one single form in markup terms, as the apply_filters were retained, I was free to then delete the old core functions altogether, this worked but was far from the rosy ideal I had in mind I also struggled with whether it was better to use
bp_get_template_part() with it’s built in ability to look to theme directories for parts to include over a new function to manage including files looking at the template stack (similar to our stylesheet
locate_asset_in_stack() I settled on the latter as I felt uncomfortable with the new file being strictly regarded as a template part.
A second approach was mooted and demonstrated when @boone took a look and provided an alternative approach and I’m very grateful for Boone’s time on this as it settled some concerns I had but also provided a better alternative.
This second pass at the task is the one I’ve now reverted my files to and updated the other directory index templates to.
Essentially we now check in the template files to see whether the old function has filters applied to it
has_filter() in which case we load the original function else we load our new function from the new template file located in a new dir
common/ fetched via bp_get_template_part() which handles the file location, i.e overloading files from BP core to theme or child theme positions. To provide the correct form control names, query args etc we have new template tags in bp-core-template.php –
Although I have some regrets having to run checks in case filters are in use and loading older functions, in truth this aspect in the actual templates would simply be changed to just run the new template call in any new core templates or overloaded ones, the other sadness is that in fact we need to retain functions in core that really I wanted to see removed, but given we achieve the majority of requirements with the approach in the second pass the regrets are minor and not impediments.
Moving forward I want to implement the next ticket perhaps tackling the directory filters which also could be streamlined into one function, and tackling another set of template markup functions will allow us to see whether the generic approach will work or needs refinement to some degree.
It will be interesting to hear anyone’s thoughts on this whole process, feedback and considerations perhaps overlooked will be really welcome, it could well be the case that in fact we could build a better approach in core to managing new template tags? At this stage we have the opportunity to explore options, do we like the idea of this new directory ‘commons/’ for new template parts, has anyone a better suggestion for naming convention? Has anyone any thoughts on how we might best handle new template tags, will it suffice to add these as has been done in bp-core-templates.php or should we separate them in some other way, any and all thoughts are welcome!
I’ve made an early start to this in the belief that we could get a lot of these markup functions identified and moved for BP 2.6, if not all a significant number of them should be possible.
This summary includes pertinent developer conversations in Slack before and right after the official chat time last week.
Email API and customisation features (#6592) Three hours before dev chat, @boonebgorges and @djpaulgibbs had a long and interesting discussion about the new Email API. Topics covered: standardizing verbs for method names, choosing taxonomy for Email Types to give admins the option of implementing multiple templates, among others. Latest: @djpaulgibbs has since updated the `amazing-emails` branch at https://github.com/paulgibbs/buddypress/
Groups: Add Profile Fields and Profile Field Groups (#6783) From an enhancement for the Groups component, @im4th has proposed a change in direction to making this a generic component which would work for any object (Members, Groups, and Blogs) in ticket. @im4th consulted with @johnjamesjacoby about the best way forward.
Comment syncing between activity and post comments for Custom Post Types (#6482) @imath and @rayisme deliberated and agreed on adding `bp_activity_type_supports()` which works similar to WP’s `post_type_supports()` function. This would provide some flexibility if/when more features are added to BP activity types in the future.
A lively brainstorming session arose from a proposal by @johnjamesjacoby to replace the old “social network” association used for the past 8 years. There were slogans, taglines, and observations shared during and even after the chat:
• If we’re going to change it, can we think of it more as a strategic/goal/mission statement—more than just a tag line? ~@dcavins
• Social network” and “in a box” are both icky. Something having to do with “community” is better than “social network”. As for “in a box”, it glosses over the developer-focused flexibility of BP, which IMO is one of its strong points. ~ @boonebgorges
• It (“BP as a platform”) seems technically accurate, and speaks to the breadth of purpose, and I think it’s meaningful to a non-technical audience. I think we have two audiences – network builders and developers – so maybe our branding should have two parts too ~ @boonebgorges
• BuddyPress. Go Social. Build Communities. Create Networks. ~ @mercime
• Enabling Community Platforms ~ @hnla
• Building Blocks for your Community ~ @jjj
• Community toolbox ~ @karmatosed
• Community components you can put together in a very easy and funny way ~@im4th
• A suite of social components for building communities ~ @pollyplummer
• BuddyPress. A developer/professional platform that can scale up to millions of users. ~ @mercime
• BuddyPress: Create your own community space ~ @rayisme
• You have the users, BuddyPress (has) the building blocks to kit out your community to the fullest ~@netweb
• BuddyPress, an online community building kit ~ @robkk
• Fun & flexible software for online communities, teams, and groups.
BuddyPress helps you build any type of community website using WordPress, with member profiles, activity streams, user groups, messaging, and more.
New BudddyPress.org Theme
@johnjamesjacoby noted that the “theme needs a complete revamp and redesign to make it more attractive. I would like for BuddyPress & bbPress to be powered by the same theme, so that they are effectively co-branded as such.” Someone’s going to be tapped to work on the new theme.
Slack log: https://wordpress.slack.com/archives/buddypress/p1453320187003820
As you might know, we recently started work on a REST API implementation for BuddyPress.
To support this, we’re going to arrange a once-per-fortnight dev chat. @bronsonquick and @modemlooper will be leading the discussion. This will be run alongside the regular dev chat for the main project, so on some days, there’ll be two chats!
There will be a BP REST API dev chat this week. Here’s the times/dates for your calendar:
- Wednesday at 22:00 UTC.
- Dates: Every other Wednesday, e.g. 27th January, 10th February, 24th February, and so on.
- Beta 1: February 8, 2016
- RC 1 (string freeze): February 22, 2016
- Target Release Date: March 2, 2016
- There are 113 tickets slated for this cycle to date. (Closed: 29. Active: 84)
Trac Tickets Mentioned
Comment syncing between activity and post comments for Custom Post Types (#6482) @imath Patch updated. Dev feedback needed.
Comment notification NOT notified (#6057) @imath Has patch. Ready to commit. Dev feedback needed.
Manage Signups on Network Admin dashboard returns Blog Admin URL, not Network Admin URL (#6371) @imath Has patch. Ready to commit. Dev feedback needed.
Deleted activity items remain favourited (#3794) @imath Wants to reactivate the discussion on this issue. Has patch. Dev feedback needed.
Slack Log: https://wordpress.slack.com/archives/buddypress/p1452715302003088