BuddyPress 2.9 Beta 2

Today sees BP 2.9 move to Beta 2 ( Beta 1 skipped for technical reasons ) testing phase and we would request all plugin authors, theme developers and other interested parties test out this release and feedback any issues found to our ticket trac home .

You can download the plugin to test from the WP repo BP 2.9.0-beta2 or grab a copy from our SVN repo.

Amongst other improvements and fixes to look out for are:

  • Fixing display of older activity comments.
  • Correction of message when removing friends that are not friends.
  • Group invites – omit sending to previously invited members.
  • Profile image upload fix for IE Edge breaksIOS fix.
  • Correct issue with hidden group & CSS specificity.
  • URL compatibility for LightSpeed.
  • Fix inability resizing of member avatar for cyrillic character filenames.

For a full list of commits see 2.9 tickets

Template changes

In this release there are a number of improvements to templates that add a level of improved a11y performance and markup changes for better semantics & Standards.

Theme authors may want to pay particular attention to changes to profile field visibility links and the profile field descriptions where significant markup changes are made that effect positioning of these elements – changesets for these are r11617 & r11618

Nouveau – new template pack

While we were definitely aiming for release of this feature for 2.9, the necessary final fixes and feature enhancements along with the necessary code reviews were going to prove very tight to get finished in time and would have likely meant a degree of rushing. We have decided that as this is such a major new feature, the first new theme in many years and that expectations will be high for it that we should not rush to put out a product that might be even slightly sub optimal.

However fear not we are very concerned that the project is focussed on through the last stages of 2.9 and has primary focus during the next release cycle to ensure an early completion.

It is further proposed that we’ll actually release Nouveau in a much shorter release cycle as 3.0, this way we can get an early release and not have the project just sitting in trunk until the end of the year.

Companion Styles: twentyseventeen

Companion stylesheets to support the latest WP twentyseventeen theme is now committed to BP core and will be included in the 2.8 release.

While further iterations are forthcoming shortly to address some design concerns feedback would be helpful especially browser /device testing.

Any issues spotted can be notified on this ticket:

https://buddypress.trac.wordpress.org/ticket/7338

Your comments and testing are appreciated 🙂

~hnla.

#companion-styles, #stylesheets, #theme

Nouveau Template Chat

At slightly short notice (although briefly mentioned last week on slack) I’m resuming the template chats for Thursdays @ 20:00 utc ( or earlier if it suits more people? )

As today is at short notice the chat is a more informal one to get the ball rolling again and I hope anyone that is interested will check in and lend a voice.

We’ll keep to a short meeting of 30 mins – depending on how things go this might roll on longer.

As the Nouveau project is in a fairly complete state vis a vis templates, styles, majority of the directory structure, functions/classes etc this is the opportune moment to discuss the areas that will dictate how the template pack is managed and executed in BP core and these areas to some extent dictate how work on the project in general moves forward.

The discussion points are therefore:

  1. Agreement or otherwise that template packs or templates are run in the core bp-templates folder.
  2. If running from core do we want to implement the template switching process? See ‘UI to Pick Template Packs‘ Trac ticket & to be considered in this point is that imath has effected a very effective solution here currently in use if running Nouveau as a plugin
  3. If we do run multiple templates – what if any are the implications of supporting these multiple packs in terms of time updating them if required?
  4. In terms of styles I’ve followed a ‘partials’ approach to breaking the various components into smaller file includes compiled into the main .scss sheet, the principle notion here was that those ‘ _partials’ are maintained in <code>/src/bp-templates/shared/styles/</code> and can be used as a base set for any new set of templates (obviously not being compiled into the ‘build’ for final releases). Although I have kept things flexible so we have options I think this best approach so would seek consensus &/or opinion here.

There is a fair bit to discuss just in the points above, ideally we seek consensus on these points so we can move forward but am  not expecting we can achieve this in one chat session but making a start is the important thing.

Hope to see as many there as possible.

~hnla

P.S. Please feel free to leave any comments about the points above or any other thoughts on the Nouveau templates project.

P.P.S. The template pack is available here on the BuddyPress github account ‘Next Template Packs

#template-packs

Nouveau – A BP Template Pack Story

Well a few further updates 🙂

Following on from our first introductory update The State of the BP Nouveau template pack we are happy to provide a little more insight into the ongoing development of this project.

Since that first update we have updated many files pushing some ~110 commits ~410 commits in total to date.

We have comprehensively re-factored and structured the directory layout and created many new include files. Styles are re-worked into a modular series of partial files representing two levels  – those that are called and compiled as the base styles and those that are unique to given TP & living in the TP directory.

The focus of the last couple of weeks has really been on template re-factoring, updating markup , improving semantics, adding or removing classes as required while working through screens updating styles. Updating visual styles also involves paying attention to  the structure and formatting of the files, looking at the nesting of rules (less depth allowed in lint rules) , attempting to ensure we have lighter files with selector specificity that’s lower and less troublesome to override and ultimately to hopefully compile css files that are a little smaller in kb.
Amongst other additions since last we wrote there have been:

  • Navigational user selected styles
    We now provide a vertical navigation selection for user object navs seen here

Nouveau Vertical Nav Menu

  • Additional styles for Navs or links exist too so we can have  a default subnav view or a tabbed look, the tabbed look  work as styles & classes  that can be dropped on most ul list links so we can use them on links such as the profile group links or the message screen links:tabbed-navsThese styles for tabbed navs work from classes to apply the styles in the same way the vertical navs function so in time we will add these to the customizer when we’ve worked out what elements benefit from the choices (apart from the obvious).

 

  • Messages gained a massive upgrade courtesy of @im4th as described in the last update further to this we have updated some of the markup for better semantics and tweaked the styling a bit for both the inbox messages listing & preview screen & single message thread views:

messages-inboxmessage-thread

  • All Nav elements in general have received a review and class tokens upgrade to try and make them a little more useful  and clear – gone is reference to ‘tabs’ unless they are specifically visually styled as such. Navs have had a round of default styling as a base line on which we can build out further styles and attention to some very simple screen widths so that we have something that will work for small mobile/tablet devices. small-screen-navs
  • On User screens we have looked at creating a more uniform approach and consistency to headings and simple explanatory text so for example on the user settings screens we have added headings and text to all screens so it’s clear exactly what your looking at, this process is replicated across all screens where required.

user-headings

  • Whats new textarea gets a tidy up of styles to compliment the work carried out by imath for both small and wide screen views.
  • General tables get a freshen up and font sizes managed for th/td cells.
  • BP Lists get attention for heading/meta font sizes & layouts for small / wide screens.
  • Update the Group Create steps screens, improves the markup and classes and pulls out the BP core steps navigation to include in nouveau template-tags file and adjusts markup.
  • Updates for mixins & scss variable files – improves color choices by variable reference, create more individual specific vars to allow changing of  more specific elements without changing all e.g $nav-hover: $dark-grey; allows $nav-hover to take a different color or var while another element can still use $dark-grey as set. Mixins get updates  for responsive text  to compliment the general font size mixin, this allows a value to be divided by a percentage on smaller breakpoints. New clearfix mixin allows clearfix rules to be added to an element fed as a param of the mixin. Add a variation of the messages box used in companion styles; this mixin allows backgrounds  and color to be passed to message element rulesets, authors can now override the defaults for border, background, color. Update our password strength warning colors for variable definitions rather than hardcoded hex.

Moving forward we have more templates to still run over and review for the best markup structure classes and of course a full and detailed review of accessibility improvements we can bring to our templates which @mercime will be tackling at a convenient moment.

@im4th is currently looking at the implementation of the template pack selector for core on this ticket :

https://buddypress.trac.wordpress.org/ticket/7157

As well as continuing to drive new and exciting functionality for bp-nouveau. (take a look at the proposal here for example: https://github.com/buddypress/next-template-packs/issues/64)

We encourage everyone to download and follow along with the development plugin, you can download from:

https://github.com/buddypress/next-template-packs/archive/master.zip

or of course checkout to your plugins local dev via git:

https://github.com/buddypress/next-template-packs.git

We have specific Template dev Chats on Thursdays @ 19:00 UTC on BP’s slack channel, please come along and provide feedback or simply follow along all and any participation is hugely welcome.

If you’re running the plugin and spot an issue or have an idea for an improvement then you can use BP’s issue tickets on the next-template-pack repo to report them:

https://github.com/buddypress/next-template-packs/issues

And last but not least please feel free to leave any comments or questions on this post and we’ll attempt to respond to them 🙂

 

Regards, the Template Pack Team.

 

BuddyPress Style Modules

Introducing an  initiative to provide community written styles for BuddyPress sites.

Today we are excited to launch the trial of a new project within Buddypress that sets out to provide an approach for people to develop small style snippets to enhance aspects of a BuddyPress site.

It is hoped that  development of styles under this approach will engage authors to create interesting new looks for BP components and provide users with a rich library of code snippets to enhance their site with.

Initially this is a trial to see whether we get sufficient interest in the concept to continue and develop further, perhaps enhancing the loading process with enqueueing of files based on directory scanning and loading of files as an array but run from the core theme compat class, removing the need for users to copy the loading functions to their functions file.

Provision of modules and use of them is entirely the discretion of the authors and users, while BP will run some basic checks on the module BP does not guarantee that the modules will work in all given situations or installs, or accept any liability in their use. Support for a module remains the responsibility of the author to ensure the continued effectiveness of the module with updates to themes, WP or BP.

Snippets is a loose term best thought of as styling parts of a BP screen or component without necessarily having to be concerned in managing the development of a whole theme and related styles.

An example of a style module may be found in the provided members list module that re-factors the member lists as  panel boxes in a grid layout, another could be a new look for the user profile entries, or even simpler updating certain elements in the activity list for font sizes. Importantly style modules can be as simple or complicated as one wants them or needs them to be, there is no stipulation on what constitutes a module in terms of provided styling, you do not need to be a coding guru we would encourage anyone to have a go if they have a good idea for enhancing an area of BuddyPress.

As a guide to what could be styled we could look at areas such as:

  • Activity posting form. The ‘what’s new’ form is ripe for styling and enhancing using a mixture of styles and scripting.
  • Activity Comments – new takes on presenting nested comments using styles and/or scripting.
  • Simply style an instance of the logged in user  – maybe make your own objects in lists etc less obvious using opacity, or conversely bring to prominence.
  • Style the new user types.

Authoring Modules

Anyone wishing to provide a module needs to look at the example module (the example  module may be used as it is fully functional) and study the guidance notes in the repo.

Having created your module you will open a ticket on bp trac and upload the module folder zipped along with readme.md and a screenshot, plus a basic description on the ticket of your module. A member of the core contribution team will review the module just to check some basic standards are adhered to and that the module works in respect of a standard WP theme, unless there is a clear statement that the module supports a given theme (preferably supporting a WP theme repo theme)

When the basic checks are finished the module would be included in the styles module repo on BP github and  listed on the  ‘Style Modules List‘ wiki page.

You can read more on the BP github repo and if there are any questions please use the comments in this post.

Users

Installing modules requires creating a  directory to hold them and then downloading the zip from the list link:

Modules are always located in the folder /style-modules/ so to use the members-list-module  you would need to create a folder structure that looks like this:
wp-content/my-theme/buddypress/style-modules/

You will then unzip the module into this style-modules directory.

In the modules readme file will be an example set of functions to enqueue your new modules styles and/or JS files, this is copied to a suitable point in your functions.php file.


We’re looking forward to submissions and are on standby to answer any questions that you may have regarding authoring or using style modules as they become available. Please feel free to use the comments on this post for general questions regarding this initiative or more specific questions can be raised   on the github issues tracker for the ‘style-modules’.

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.

Relocating Core Markup

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 – bp_search_input_name(), bp_search_placeholder(), bp_search_default_text()

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.

#templates