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.
BP Dev Updates 