Their are two big topics that I really want to hit on out of all the topics in this series. This is the first of those.
We need to stop re-labeling things to confuse those who maintain and develop the content. We need to adhere to a structure that is more closer if not identical to the industry standards.
Currently we have two folders within the Style directory, Template & Theme. The first confusion should immediately be obvious. This provides confusion as its backwards the overall all directory should be themes and the content within should be a style as the content that we change is a stylesheet
Themes > Prosilver > Template, Style
The next confusing part when first looking a phpbb "Themes" is the breakdown of content it self.
In the Theme directory we have css files and images folder and a language folder? As a designer and developer I have never seen it broken out this way mainly because its confusing! Whats more confusing is that in the Template folder you have HTML and JS files?
We need to take an Asset approach to the breakdown of a theme as this is most common in the design community as well as the development community.
Proposal:
- themes
- prosilver
- assets
- css
- fonts
- js
- less
- design <- design related files such as .ai or .psd files
- includes <- template parts, this is anything that is not a main page & not required for all pages
- index.html
- header.html
- footer.html
- viewforum.html
- viewtopic.html
- faq.html
- mcp.html
- memberlist.html
- posting.html
- reporting.html
- search.html
- ucp.html
- viewonline.html
- assets
- prosilver
gains:
- The ability to clearly find exactly what we need to edit
- Immediate understanding of the breakdown of a theme to new individuals to phpbb
- ability to modularize the theme in order to make it more maintainable
- clearly defined and established scope and content
loses:
- Language directory <- but do we still need this I was under the impression that the buttons have all been converted to css?
- The need for more template variables for paths
- Could require some minor changes if not possible complex ones to the template engine
The last aspect of this that I have not hit yet is the changing of the way we breakout the css. I am addressing this separately as if we go down the route of using a preprocessor, then this would be moot as the less files would generate the css.
Currently we are breaking out by property values when it should be broken out based on object relation for modularity and scope.
Thoughts & Suggestions?