BuddyPress core developer Hugo Ashmore announced a new trial initiative this week that aims to create a library of CSS and JavaScript snippets to help users customize their communities. The Style Modules project will aggregate community-submitted code that enhances BuddyPress components in a plug-and-play manner.
Developers who want to contribute to the project can submit their modules by creating a ticket on BP trac and attaching a zip file that includes the CSS/JS files, a readme.md, and a screenshot.
Users who want to add a module will need to create a /style-modules/ directory and then unzip the module inside it. The next step requires the user to copy functions from the module’s readme file to their theme’s functions.php file, a step which provides a significant hurdle for a non-technical BuddyPress community manager.
“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,” Ashmore said.
The project’s GitHub repository includes an example module that re-styles the members list into a grid layout. Other example ideas Ashmore suggested include a new look for profile entries, a different presentation for the activity posting form, or something as simple as changing the font size for the activity stream.
The experimental initiative will test the waters to see if the BuddyPress community will chip in to provide enough modules to make this a real library. The support policy stated in the proposal doesn’t offer much incentive for module authors to submit their work:
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.
Historically, BuddyPress has struggled to present itself as an easily customizable solution for communities. Theme compatibility, introduced in April 2013, made it easier to use BP with any theme, but unless you purchase a theme specifically designed for the plugin, its default output is rather generic and in need of heavy styling.
The BuddyPress Style Modules concept is an attempt to make it easier for community managers to enhance BP components with different looks, but the project will need to provide a compelling reason for developers to contribute modules and continue to maintain them.
Thanks for the write up Sarah.
Yes there are areas in the overall concept that are perhaps weak but we do hope that this might just provide a means for the community to extend the the visual styling of BuddyPress in a simple enough fashion that can gain a lot of traction and enhance BP’s theme compat appeal.
My current concern is that the process for including modules might be a tad awkward for users to get to grips with, but it was felt that core changes to BP at this early stage were premature to make but as and when things pick up we’ll look at improving the users experience in this area.
Point taken on the support policy statement, it was never intended to be a negative statement, but I felt that it was important to stress that responsibility for the modules and the code therein belonged with the authors or more importantly that BP core devs weren’t burdened by additional responsibilities – even though I and others would always be more than willing to help an author with a module . This needs to be a community led and fuelled project. The liability section I agree isn’t perhaps the most positive, here, again, I had a fear that given we are talking themes and therefore can never know for certain what conditions might arise for a module, it’s impossible for a module to be tested to work for all situations/themes. A module might be dropped into a situation where it did fail and I wanted to somewhat pre-empt that event.
I will take a further look at the tone and purpose of the support policy and look to re-write it to better represent the project.
Your last comment is an interesting one, I agree that a compelling reason will help and would have hoped that the compelling reason would have been to help enhance and provide a more vibrant BP community through code snippets and that this project was yet one more manner in which the community could get involved especially those looking to cut their teeth in coding, obviously authors would get mentions and listings and in time we might introduce further module listings when appropriate on the main .org site.
I am very open to suggestions on improving /providing greater compelling reasons though, as there are a lot of areas like that that could do with more detailed thought. At the end of the day and to some extent the desire was to get something in place that could be refined and iterated on, and I would love feedback on how we might improve on this trial project either here or on the bpdevel posts comments.
~Hugo.