New Template Pack
We held the first meeting to discuss the new template pack an hour before our regular Dev Chat as scheduled. Members of the core team shared expectations and observations about the new BuddyPress template pack based on what @im4th has accomplished so far in his next-template-pack plugin. The plugin already has an option for end users in the back end to either use bp-legacy templates or use the new template pack and it uses handlebars templating but like email tokens, you can only work with what you have in the JSON payload.
The initial discovery phase touched on the following items:
- modularized template pack with some theme goodies sprinkled in
- put all the new features in next-template-pack including improved UI, compatible with latest BP/WP versions, and all the accessibility baked in.
- modern JS and CSS, works really nicely with the idea of the CSS snippets library, too … making the whole experience more flexible and easily customizable
- general agreement that the new template packs don’t have to be beholden to bp-legacy backward compatibility
- core files still have to honor the parent theme styles
- modular CSS – BP pattern library
- make a list of the kinds of things we need to output, so we can work to unify styles as much as possible, see http://alistapart.com/blog/post/getting-started-with-pattern-libraries
- planning documents: Google Docs, bpdevel, Trac tickets
- identifying core markup to use/move
- move next-template-pack to BuddyPress github account
- manifesto with project scope and implementation plan
- Shoot for the moon. “I’d say let’s not be circumspect (with anything). Let’s go for it, then throttle back what we have to,” per @dcavins
Next meeting: Wednesday, April 27, same time (18:00 UTC), same #buddypress channel in Slack.
Update: See additional notes in the April 20 Dev Chat at the bottom of this post for the Template Pack meeting next week.
- There are three tickets in queue with improvements to BP Email.
- Release date: TBA
Email Subject special characters display problem with initiator.name token (#6966). This is the only ticket left open for this minor release. @dcavins, @djpaulgibbs, and @rayisme discussed about the feasibility of adding emoji support in BP Emails. Need to check which email providers and mobile clients show emojis. @rayisme has volunteered to work on this ticket.
- There are 115 tickets currently slated for this cycle (32 closed. 83 open)
- Beta 1: May 25, 2016
- Release Candidate 1 (string freeze): June 8, 2016
- Target Release Date: June 15, 2016
Activity post form template improvements (#6680) Has patches by @rayisme and @mercime. @dcavins has posted before and after-patch screenshots of the Twenty-* themes and premium themes to address some backpat concerns. Comments on the ticket are welcome.
Re backward compatibility from @boonebgorges: “I think we should try to differentiate between different kinds of (potential) backward compat breaks for templates. some are minor, while others are debilitating. some will simply be a case of a custom template not receiving new features, while others will break markup so that stuff like JS no longer works.” Weigh potential gains from the break “on a case-by-case basis . If we were never willing to break compatibility, we’d never fix any bugs 🙂 “
Accessibility: Update Heading Structure in Template Files (#6871) @mercime asked for the consensus of the team. @boonebgorges, “My position is that if we can demonstrate that the styling changes are minimal in the Twenty themes, it’s fair evidence that it’s a change with fairly low negative impact. This also assumes that the a11y benefits are meaningful, which I’m relying on your judgment for.” @djpaulgibbs noted, “BuddyBoss and a UK agency have both told me that the heading changes that have gone into 2.6 will require them to update all their sites/themes. I am not trying to be against improvements. But it’s a fine line. I am just saying if we are committing to making such significant changes to the main markup, we need to communicate that NOW and way better than we ever have before. Because honestly we’ve always changed stuff and broken it. It has had little to no documentation, generally. As Boone said, we need to look at the impact of each change on its own basis.”
Creation of developer.buddypress.org (#6812) @tw2113 would like to get this going sometime soon, “Essentially we need to get a final destination set up, run a parser scan on the latest stable version, and then comb the website for inconsistencies and things needing changed also work on any sort of triggers/automation to update the source there and re-parse.”
BuddyPress Work Party
Dev Chat – April 20
Notifications for activity stream comments and replies (#6057) @im4th has patch plus screenshots uploaded and would like to get this new feature in for 2.6. @boonebgorges has posted feedback in ticket. Feedback in Slack was very positive with some suggestions on inline documentation. Looks like this will be fixed soon.
BP Template Versioning (#6642) @dcavins: “Need to settle on the format/requirements for the template versioning, we could tag all of the templates, before we come up with our super jam for how to help site owners realize their templates are no longer up to the current high standards.” @boonebgorges “The minimum that needs to be decided for the process to start is what header format we’re going to use. Questions about how we inform users, how we assemble changelogs, etc – these can wait. On the other hand, Inline changelog + summary changelog with each version may be enough.”
Allow admin to select fields to display in user “excerpts” on Groups’ user list page (#4126) @boonebgorges mentioned the UX considerations in the ticket proposed by @oc2ps require admin-level tools (which we don’t currently have) for site owners to modify the way that BP content looks on the front end. Comments/thoughts about whether it’s the kind of thing we want to do are welcome.
@booneborges noted that “if we’re going to introduce something like this into BP, it would have to be an actual interface where you could customize things and it would extend to interfaces other than member directories, in the long run. I think the answer for this ticket is that it’s not a route we can comfortably go down given our current approach to templates.”
Date xprofile field enhancement (#5500) @boonebgorges mentioned that this ticket has a new patch which “has some promise, but will need extensive rewriting to fit with BP/WP standards (not just coding standards, but architecture). I will try to take some time in the next couple weeks to pore over it, but if anyone has time in the meantime, feel free.”
Additional notes for next week’s Template Pack Meeting
- @johnjamesjacoby: “I’d like to propose that in whatever new template pack is built, that no `do_action()` calls exist in template parts, and if we find ourselves wanting them, we architect a better solution inside of the API.”
- Use “magic hooks” from @johnjamesjacoby, “anywhere we need `before/after` actions in templates, is a place where a new template part should exist, and `bp_get_template_part()` should fire its own `before/after` actions before & after every part is successfully pulled in.”
- On the other hand, @boonebgorges noted, “Here’s another take on this. If you are a WordPress developer, you know that if you see a `do_action()`, you can make something appear there by calling `add_action()`. If we introduce micro-APIs for every little thing, it obfuscates what is currently a fairly simple process.” @im4th added, “without overriding the full template. That’s the good part of the `do_action` i agree.”