Proposal for packaging phpbb with empty style and extension

[javiexin]

Hi all,

One of the issues I have faced as administrator of a forum is the complexity of managing MODs. Great, that has been greatly simplified for admins with extensions... But the issue of "modding" still exists: all/tons of admins will tweak the extensions to fit their needs, and even more, the styling. So now, the issue with maintainability and where to place "your" specific code to override whatever is done elsewhere is moved from the forum software itself to the extensions. If you try to migrate to a new version of an extension and you have tweaked the code, you are in the same situation you were before with mods...

Most of the changes that admins do tend to be mostly "cosmetic", gui-related and very specific.

My proposal would be to add a "special" style (based on prosilver), and a "special" extension, that will be shipped with phpbb always, as "empty" containers, but activated, and properly structured by the phpbb team. That way, lots of visual changes could be made without touching the "core" stylesheets. This will also help to tweak the styling of extensions for that particular forum, again, without disturbing the core.

SImilarly, the container extension would be exactly that, an empty extension, without listener or service, or almost anything for that matter, just something you would use for other purposes, like
- changing events in extensions (moving code from one event to another)
- applying priorities to visuals while the new priority system is in place
- adding your own code to some template events
- and so on...

Well, I think I said something inexact before: I would include a listener in this extension, just to load another set of solutions to issues for admins: specific language file(s). This might not look so relevant, but if you support a multi-language forum, you find yourself (hard)coding texts and labels in templates that could benefit from having language files readily available...

As you see, all of these is trying to do is ease the life of forum admins. Don't know what you think. Remember, this is a first idea/concept, and bear with me if the idea is somehow useless...

Your thoughts? Regards,
-javiexin

[david63]

Where styles are concerned I have been think along the same lines for a while now.

A lot will depend on whether the "new" style will be of the parent/child style configuration that we have now. If it is what I would suggest is having the "parent" style (called say 'default') installed on all boards and the style that is used (let's call it prosilver3 for now) would be a "child" style with just the style folder structure and the minimum files necessary (probably just style.cfg). That way a user can simply drop their changed file into the prosilver3 folder and their changes will (or at least should) take effect - all done without changing any core code.

I would also, if it is possible/practical, like to see a similar parent/child structure for language files so that users can easily change parts of the language without the need to change core files.

I don't think that having a "dummy" extension would work as there are many complexities with extensions which can get the inexperienced into trouble (as I know - having been there and got several t-shirts to prove it). Also I am not a fan of the idea of putting many changes into one extension as if there is a problem and it has to be disabled then you loose all your changes - I much prefer many small extensions.

There is the "Extension Skeleton" extension which should go some way to fulfilling that need.

[hanakin]

the style changes that I have in mind should eliminate the real need for child styles ideally. Instead of the entire theme being the parent its broken into smaller individual components. These components are used to build the theme. To customize you simply override the specific components you need to both in the components html and the components css.

This is a very oversimplified explanation of it mind you.

Basically the need for template inheritance is wrong by every means as css already inherits by nature the only real benefit and I use this term lightly is the html files.

However if we are working with a truly modular component based approach to building a theme then this is pretty much solved by the nature of component design.

The way we interact with extensions is still sort of up for debate, but I would suggest strict namespace rules for classes for any changes to your components ie .ex-simple-mention_post to make alterations to the .post component.

This way it easy to see if there are any things that may need de-conflicted during install by check if there is more than one extension appending to that class.

As for new components they would already benefit from avoiding any unwanted inheritance ie .ex_mention, .ex_mention-text, etc...

to recap all extension are prepended with .ex

changes to global components are namespaced after this with the name of the extension .ex-extenstion-name_global-component this is ommited if its a new component that the extension adds .ex_new-class

the name of the class is then applied after an _

[javiexin]

Thanks a lot for this heads up, but... How long until this is available to forum admins? 3.3? Two years away (at least)?

What I am talking about is something that can work now, and will help the community immediately. In the future, they will probably have to move to your schema, but in the meantime, they could maintain a clean system, without that much core (or extension) modifications...

This is something that could be done for 3.1.x or 3.2, and would be available almost immediately...

The only issue I see is trying to keep BC with it in the future. But that is another story...
-javiexin

[javiexin]

Where styles are concerned I have been think along the same lines for a while now.

A lot will depend on whether the "new" style will be of the parent/child style configuration that we have now. If it is what I would suggest is having the "parent" style (called say 'default') installed on all boards and the style that is used (let's call it prosilver3 for now) would be a "child" style with just the style folder structure and the minimum files necessary (probably just style.cfg). That way a user can simply drop their changed file into the prosilver3 folder and their changes will (or at least should) take effect - all done without changing any core code.

Almost the same idea I had in mind. You would just need: overall_header.html, style.cfg, and dummy css files pre-included in overall_header.html. What I have done includes at least three/four such css files: core/common/colors, responsive, and extension, plus a language specific css; you may need/want other components like bidi to also be overriden. These should follow the guidelines mentioned here https://www.phpbb.com/styles/create/, most probably Method 3.

I would also, if it is possible/practical, like to see a similar parent/child structure for language files so that users can easily change parts of the language without the need to change core files.

That is (one of) the reason(s) for the "dummy" extension: auto-load language files that might define new key or override existing ones. Right now, only the panels/modules (ACP, MCP and UCP) auto-load language files. What I am proposing would be similar, but for one specific extension. And it should be done LATEST, after all core language files have been loaded, so that they might be selectibly overriden at the key level (no need to override the whole file).

I don't think that having a "dummy" extension would work as there are many complexities with extensions which can get the inexperienced into trouble (as I know - having been there and got several t-shirts to prove it). Also I am not a fan of the idea of putting many changes into one extension as if there is a problem and it has to be disabled then you loose all your changes - I much prefer many small extensions.

In fact, what I am proposing is not so different. Ideally, what I would want is to provide a way for admins to tweak the VISUALs of the forum, not core functionality. That is why I said that the extension should not have a listener (except for the language bit). The extension would only serve as a mechanism to use the existing TEMPLATE events with EXISTING (or extension) template variables. The need for this comes from the fact that styles do NOT process events within themselves, they are supposed to embed the code in the main template. This is, in my view, limiting, and prone to long term maintainability issues: if you change a template file to accomodate your needs, then in the future you will have to "fix" it every new version of the core... It would be much easier to ONLY use template replacement where strictly needed, and use Template Events for visual tweaks. But styles do not allow for that, only extensions do... That's why I would like to have a "dummy" extension as well. And yes of course, it should be a very small part of the Skeleton extension. In fact, only the bare minimum.

If more people think this might be useful, I could prepara some mockup, so that it might be tested...
-javiexin

[3Di]

+1 definitely.

[javiexin]

Another way to achieve something similar would be to have styles "load" template event files in the template/events folder for the style, and have these files to override any and all extension template events by the same name. The admin could then use a construct like <!-- INCLUDE @vedor_extname/template_event_file.html --> to hardcode loading of the extension template event file. Why? Two reasons at least: one, at times, you may need to change the extension event code to fit your needs, and including the modified code in the extension will most probably be lost with the next upgrade of the extension.
Another case would be conflicting extensions competing for the same event, that might create the wrong look if loaded in different order. An admin could simply create such an event file in his/her own style folder, and load the extension template event files in the "right" order, maybe even modifying something in between. Again, safe(r) than other changes in the event of an extension update/upgrade.
This way, you would "only" need an overriding style, and some mechanism for autoloading language files.
Regards,
-javiexin