[#12016] - [RFC] An approach to soft upgrade bootstrap
- Closed
- 21 Jan 2017
- Medium
- Build: staging
- # 12016
- Diff
- Digital-Peak:rfc/framework-exclude
- Success continuous-integration/drone the build was successful Details
- Failure continuous-integration/travis-ci/pr The Travis CI build failed Details
User tests: Successful: Unsuccessful:
The shift to a new Bootstrap major version is very difficult for Joomla and can be done only on a new major version like Joomla 4, becaus it breaks backwards compatibility. This would then require for all Joomla 3.x sites a new template when they want to upgrade to Joomla 4. Extension developers need to create special overrides, two different versions of their software or are forced to load their own namespaced version of frontend framework which has an impact on site speed.
This PR proposes a 100% backwards compatible way for a switch to a new frontend framework (FF) within the same major version of Joomla. All framework related code will be pushed to their own layout files where it belongs to. This means that Joomla can hold two different versions of frontend framework at the same time (only ONE will be loaded during a page load). The deprecated one and the new one. In practice it would mean that in Joomla 3.x, BS2 will be deprecated and BS 3 or 4 introduced, it will allow the site admins to move to BS3 or BS4 within Joomla 3. It gives the template and extension developers an unified way to deal with the problem and to switch faster to new frontend frameworks in Joomla core when required. Also the site upgrade to a new frontend framework can be done step wise and not with a big bang. You can have your old template and the new one installed at the same time and then migrate page by page by assigning the menu item to the new template, without doing any layout override.
In the Tauristar template project https://github.com/Digital-Peak-Incubator/tpl_tauristar, we made a proof of concept with that method. A BS3 template was created with no overrides. When Protostar is loaded, then only the default.php files are rendered, when Tauristar is activated then the bs3 related files like default.bs3.php are rendered. Mostly it is enough that the framework specific file does set some variables for the default file. So we have no duplicated code in Joomla as shown in this PR.
BS3 is used only for demonstration purposes, treat is a placeholder for the next frontend framework major version used by Joomla.
Summary of Changes
The template can define a new hidden parameter against which framework it is built to, like:
<field
type="hidden"
name="framework"
default="bs3"
/>
By loading the template params, the view, module helper and layout manager do search in their paths first for a framework specific file. If none is found, then they load the default file. If none parameter is set at all in the template, only the default files are loaded.
The params approach acts here only for demonstration purposes, there are many other ways how a template can define which framework it is made for.
Testing Instructions
- Add the following code to the file templates/protostar/templateDetails.xml after the fluidContainer field
<field
type="hidden"
name="framework"
default="bs3"
/>
- Save the template
- Create a new contact
- Create a contacts category menu item
- On the front, open the contacts link
The classes col-md should be added to the grid cells and not span.
Pros
- 100% BC
- Framework related file can output a complete new content or set some variables for the default layout
- No duplicate code
- Template doesn't need to be shipped with all the layouts and template files of all components
- Faster upgrade or switch to new frontend frameworks during one major version of Joomla
- Reducing complexity for template developers as they don't need to create overrides for all extensions
- Saver sites as it will no be neccessary anmore to make template/layout overrides just because of a different frontend framework, fixes will not get forgotten which are applied to the core, but not the override
- It is optional for the extension dev to create framework specific layouts and views
- 3rd party extensions and the core will use the same way to deal with different frontend frameworks
Cons
- Adds a new layer of complexity to the core
- Performance decrease as more file lookups need to be done
At the moment it is a big mess in Joomla because most of the templates do load their own frontend framework or load bs3 with tons of overrides for Joomla core. The extension developers do the same or have to do some other quirks to work flawless with any template. I know it adds some complexity but I'm convinced it is worth it as it solves more problems than it produces. Joomla will be able then to adapt faster to new technologies and to do real one click major upgrades. If this problem, which is addressed by this PR is not solved, then we are repeating the same problem over and over again and didn't learn from the past.
I'm aware that this is more of a practical approach and goes against some architecture decisions, but it allows us to extract all the frontend framework related code into files. On a later stage, it will be possible to remove them from the core completely and to make them installable or whatever. But the target must be to disconnect the core from any frontend framework and this is the first step to it.
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Labels |
Added:
?
|
||
| Category | ⇒ | Front End Components Layout Libraries Modules Templates (site) |
Imho it depends a lot on what the plan is for J4. If J4 wants to become framework agnostic, then this doesn't make sense here. If J4 will use BS4 like we do use BS2 now, then it may be useful for the transition phase.
In the end it really depends how it will work with existing 3rd party extensions. If they continue to work and display fine without issues (and without the devs doing something!), then it may be useful.
If the devs need to do some bigger adjustments (like creating new layouts) for it to work, then you can trash it right away as it will likely not happen. Reason is that if they do it today, chances are high that they still need to adjust it again for J4.
@brianteeman BS3 is nowadays so common among the templates on Joomla 3 that I tough I makes sense to use it, but you can treat is as a placeholder for the next version of FF. But with the RFC it will be then less painful to make the switch to BS4.
@Bakual as described in the description, it is 100% bc and will also work when the extension developer doesn't have a framework related file. He/she can use that feature or leave it, it's up to them.
The approach removes the need to have duplicate content, as we are forced to have nowadays duplicate content when a template wants to use a new FF, it must copy almost all views which have FF related code. Best examples are Beez or Hathor, they have a lot of overrides, for core components, modules or JLayouts.
If you're going to have template suffixed JLayouts at least use the build in suffix system rather than
But honestly I disagree with this approach. This introduces huge complexity for minimal gains. Core should and won't ever support bs3. We're adding in additional complexity by loading additional layouts (even if they proxy) and it will make it even harder for people to transition.
I personally feel that it's down to extension developers to provide additional layouts that people can just copy paste into their templates. Sure it's unideal - but it's going to be a better overall experience than what this gives.
This introduces huge complexity for minimal gains.
I would argue the opposite. The complexity it not big, and if somebody don't want to use, they don't have to. It removes the use of duplicate code in templates, I would call this as a remove of complexity.
I personally feel that it's down to extension developers to provide additional layouts that people can just copy paste into their templates.
So you really suggest that duplicate code should be the solution? That does sound for me so wrong.
There's so much more to a framework than grid classes. If it's just the BS3/4 grid your wish to support, why not map the classes?
@C-Lodder it is not just about grids, at the end all the FF code should be placed in their own files. This RFC should give just an impression where to go. A proof of concept can be found in an incubator project https://github.com/Digital-Peak-Incubator/tpl_tauristar where we created a BS3 template with no overrides running in Joomla without any BC break.
In combination with PR #11922 all the FF code is separated from the core then.
No part of the templating engine's filesystem operations should be framework aware. We should NOT be introducing conventions that use framework names in the file paths, nor should we be introducing parameters that declare the framework in use.
Using the override systems exactly as they were designed. Yes that means more work for the end users and the template developers, but that's the whole freakin' reason we have override systems to begin with!
Quite frankly this approach shows that Joomla has too many internal couplings to a frontend frameworking system and the solution proposed here is to introduce even more crap code to an already overly bloated system with more internal couplings to frontend frameworking systems.
You've already stated that templates are managing to provide Bootstrap 3 (and other CSS frameworks) on their own without the need to hack core with this crap. So what are you really trying to provide here?
Additional comments:
- It requires extension developers to create layouts for multiple template frameworks
- This potentially opens the door to require that Joomla core support multiple frameworks
Templating decisions should be left to the template and the rest of core be framework agnostic. Period. If you want to use BS3, BS4, Material Design, or any other framework, you should already be fully prepared to do the work necessary to accomplish it. You can't just add another parameter into the system and have everything work in a way that's multi-framework compatible unless you're writing framework agnostic HTML (so sticking to one version of the HTML spec and nothing else).
@mbabker From an extension developer, templater and user perspective, this approach can solve big problems. We need to decide, if the hardcode developer get satisfied or the day to day user. The best way is off course, to satisfy both groups. We can ask many extension Developers, Templaters and Users for their opinion to get a wide perspective for this purpose and it's worth to add an additional Layer to Joomla or not.
For me the override system should be used when somebody want's to change a view or layout output of his site and not all views or layouts, because we are locked to a FF major version within Joomla. As soon as I hear that we have to use duplicate content, an alarm bell is ringing. Not having a migration path when upgrading the FF is silly.
But the more important fact is that when we switch to a different BS major version in Joomla 4, then all sites need to be rebuild, one click migration is then not possible, because all templates need to be adapted. That is the major issue I'm trying to solve here. Learning from the past and try to do it better. If there is another approach, then I'm open for suggestion. But till we didn't find a solution, this here is the only way I can sink of to take away from the template the burden to adapt all views to a newer framework just because we can't get rid of an ancient BS version.
If the core should be framework agnostic, then this is ok for me. Question back. How would you do that then? There must be made a decision how to solve this situation. Till now, the only thing I heard was that Joomla 4 will come with BS4. And then we are with the same mess as from 1.5 to 2.5 and to 3. A new template is needed, when the upgrade has to be done, and that will make run users away from Joomla, it will give a bad impression on Joomla.
Here is the perception you need to break. The default layouts in the extension directories (hell I'll go so far as to say those provided by JLayout too) are NOT agnostic. They are designed very explicitly against the default templates (so for Joomla 3 that is Isis, Protostar, and whatever we call that template in the install directory). They are assets of those templates, NOT assets that are properly re-usable for all templates. The day you start looking at layouts from that perspective, you will truly understand why there are so many flawed philosophies in Joomla's templating layer.
But the more important fact is that when we switch to a different BS major version in Joomla 4, then all sites need to be rebuild, one click migration is then not possible, because all templates need to be adapted.
That will very likely be the case anyway, no matter what you do here.
And then we are with the same mess as from 1.5 to 2.5 and to 3.
1.5 to 1.6 (2.5) was a mess because the extensions were broken and couldn't run on both versions simultan. You weren't even able to update the core itself with a one-click updater. You had to rebuild from scratch or use a migration tool.
However 2.5 to 3.x was no mess at all. You simply clicked the button and got updated. After that you updated all extensions and if you were lucky there was even an updated template. Worst case was that you had to exchange the template and maybe some very outdated extensions. That's it.
If J4 is the same easy route, then I'm all happy!
But the more important fact is that when we switch to a different BS major version in Joomla 4, then all sites need to be rebuild, one click migration is then not possible, because all templates need to be adapted.
BS. I upgraded my 2.5 site which used the Joomla! Ad-Hoc Maybe-This-Will-Work-Here-But-Not-There CSS Framework to 3.x with exactly zero issues. It continued to use said template built for 2.5 until I could complete a proper integration with Bootstrap over six months later, and even that was only a transition until a fully new template was in place roughly a year after that. So to say that it's required to replace your template when upgrading between major versions is a complete lie and does nothing but to spread FUD.
Look at Hathor. How much of it was rewritten for 3.x and how much of it still uses the 2.5 structures?
If there is another approach, then I'm open for suggestion.
You've chosen to ignore it so there is no openness for alternative suggestions other than your approach of making the core templating engine 100% coupled with a parameter in the template and a filesystem structure to match.
If the core should be framework agnostic, then this is ok for me. Question back. How would you do that then?
Everything in (administrator/)components/*/views/*/tmpl, (administrator/)modules/*/tmpl, plugins/*/*/tmpl, and layouts MUST be considered a proper default layout and be agnostic of any specific framework conventions. What we consider default layouts today MUST be moved to the templates that we set as the defaults when installing a new version of Joomla. ALL templating decisions MUST be removed from the PHP class structure (no hardcoded HTML markup except for designated HTML helper functions like JHtmlBootstrap; oh, and if you want to override that with a newer Bootstrap version's API, use the JHtml API to do so, don't add parameters to those methods like you suggested in Tauristar).
Without implementing a system that mandates that the Joomla core system supports multiple CSS frameworks, the only alternative is to make the Joomla core system framework agnostic.
For me the override system should be used when somebody want's to change a view or layout output of his site and not all views or layouts, because we are locked to a FF major version within Joomla. As soon as I hear that we have to use duplicate content, an alarm bell is ringing. Not having a migration path when upgrading the FF is silly.
The problem to me is that many users making template tweaks only understand basic html and css and don't understand PHP. This is my part of my drive to reduce the number of parameters as much as I can because I want the templates to be largely comprised of really really simple html/css and a few echos of php variables as much as possible. This is simple. If you have overrides where you need to start looking for the view.html.php then the default.bs3.php then the default.php in a simplest scenario (potentially you then have prefixed jlayouts and main jlayouts. There is absolutely no way any user without real hardcore joomla knowledge is going to be able to understand what is happening. Maybe not even a experienced developer who is relatively new to Joomla.
Thing is that grids are (relatively) simple structures. But what happens if i have wells in bootstrap 2 and 3 that need to move to cards in bs4 (http://v4-alpha.getbootstrap.com/migration/#components) then this is going to become horrific to maintain. It might possibly be b/c if you're lucky. But there's no way for a user to practically understand what is happening in the code base and ever make tweaks and adjustments
So, the most seen feedback is to make the core framework agnostic. For me this sounds like we have to invent our own responsive and CSS component based framework or what?
Pretty much if we want to go that way. Honestly this also seems pointless which is why my conclusion to all of this (and i've repeatedly said this for a long time now including at JAB) is that what we have now with complete vendor lock in to BS2 is the best solution. Of course it has it's own pitfalls. But it's far better than the alternatives of either designing our own framework (with or without mappings to bootstrap) or trying to hack in support for other CSS frameworks which will make using template overrides easy for users truly impossible.
Why do we need to invent yet another thing specific to Joomla? You don't have to invent an in-house CSS framework to make core framework agnostic. You treat the DEFAULT layouts (paths I specified before) as proper defaults that have no framework couplings. You treat STYLED layouts as template assets and place them in the templates.
Part of the problem that we try to solve is we attempt to make the DEFAULT layouts usable out of the box in all scenarios for all skill levels. This has caused an excess of parameters in extensions and templates and the perception that there is a core coupling to a specific CSS framework.
Again, change your perceptions on things. If we aim to make the DEFAULT layouts usable by everyone for everything, the only option is to make core support a plethora of CSS frameworks. If we aim to give the scaffolding needed to build out sites effectively, then the DEFAULT layouts should become properly agnostic and generic.
The DEFAULT layouts do not need to be all fancy like, just usable. If you want fancy, you get into a template and you make them fancy. Pretend the system template is Joomla's default template (as in if you removed every other template and style that would be what Joomla uses; ironically that's not the case today as it tries to fall back onto Beez3 on the frontend at least). It's a minimalistic template that's not designed to look fancy or use all the latest fads in design. That is what I think our DEFAULT layouts should be; 100% functional and 100% agnostic.
Personally I thought the approach of a simple no css framework (means some specific classes that will map directly to any css framework, e.g. j-btn-success will map to btn-success in bs3,4) will be a nice way to get out of the css framework lock!
Although it will work on most cases there will be limitations.
Another idea is to scrap all these nice ideas and create some proper functionality that will translate the html of each layout to the one that the template is using. The current functionality is to JUST copy a layout to template's html folder. EXTEND this so instead of just copying a file will do the transformation needed.
EDIT: input bs2 output whatever the template dictates
EDIT2: The functionality SHOULD be provided by the template, Joomla core only needs to provide the hooks
There you go, problem solved
May be we can use some predefined variables for html classes.
Each template can use it or define own html class name (a little similar to language translation).
Example:
HTML_ROW_CLASS='row'
HTML_COLUMN_CLASS='col-md-2'
<div class="<?php echo JTmpl::_('HTML_ROW_CLASS', 'row');?>
Then each template can overrides that variable and set own html class.
This won't change any html structure on joomla templete file.
That is what this pr does
On 12 Sep 2016 5:40 p.m., "Tomasz Narloch" notifications@github.com wrote:
May be we can use some predefined variables for html classes.
Each template can use it or define own class name (a little similar to
language translation).Example:
HTML_ROW_CLASS='row'
HTML_COLUMN_CLASS='col-md-2'https://github.com/joomla/joomla-cms/pull/12016#issuecomment-246407850,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8fXZ8lYHD2mqes0wT_NP2xA7SNfQks5qpX_VgaJpZM4J6aoc
.
This isn't user friendly by any means. If we need a post processor to manipulate HTML or a language like system to define things we're over-engineering it.
That is what this pr does
This PR achieves that affect by creating another layer of override files. How's that beneficial to anyone?
We're hiding the framework parameter. The user has to dig into the template's manifest to figure out its declared framework to figure out what file(s) to override. The user goes to that file and sees it's just a proxy, now they have to override 2 files to make whatever change they need.
I'm with George on this.
A big plus for J3 is that the extension output follows a standard and thus the output looks more or less uniform across extensions. Which means they blend in nice with a given design.
In our case this standard happens to be BS2.
If we are going framework agnostic like what is suggested by some, then we get what Michael described. As I see it we would end up with a default layout which is completely unusable due to missing CSS selectors and we have to build an additional template layout which has to be copied (and maybe adjusted) by every template. Imho that doesn't make sense.
Imho it is much better to have a default layout which is useable by many templates without overrides.
The key point is that all HTML output has to be overrideable. That is the biggest issue today and where the complaints are coming from. If there was an easy way to override every HTML output, then it wouldn't be a topic at all.
To be fair, there is much more overrideable than people believe. As Michael pointed out, JHtml classes could be overriden with a plugin. In theory someone could write a BS4 JHtml plugin and all templates could use that.
Imho it is much better to have a default layout which is useable by many templates without overrides.
Not possible. Just look at Bootstrap's 4 major version branches and the incompatibilities between them. THEN factor in additional frameworks, especially surrounding their grid systems.
Utility classes (wells, labels/badges, and whatnot) are probably easier to cope with between systems. But the heart and soul of them, the grid systems, aren't. Unless you're suggesting we should have <div class="span6 col-md-6"> style markup, in which case we're going to bloat the core markup with a lot of extra junk.
Nah, you misunderstood or I wrote it wrong.
I meant to have a default layout that is like today using a standard (be it BS4 for J4). Certainly not having multiple framework markups within the same layout. As long as the templates are based on that framework, they will not need any overrides at all. And that will be many templates like today with all the BS2 templates for J3.
And now we've come full circle because that argument suggests to retain status quo and to close the issue. If you're going to keep building layouts based on a specific framework, there is always going to be a perception about vendor locking in Joomla. There isn't as long as you aren't doing frontend editing, and even that's pushing it (how many fields on the 3.7 branch use JLayout now?). The old help proxy system not once loaded jQuery or Bootstrap assets, so it is indeed entirely possible to build frontends without the default framework if you know how to use Joomla.
What we need is a proper set of defaults. By proper I mean agnostic and minimalistic. We don't have that, what we call defaults today are layouts that are built specifically for use with Isis and Protostar and they might conveniently work with other templates but probably not all that well unless you're aiming for a site that looks pretty damn close to default Bootstrap (our joomla.org site template only has layouts for pagination based on Isis' layouts, otherwise everything else is CSS tweaks there, now take away our header and footer elements and tell me the base template isn't in essence the default Bootstrap styling).
Personally I don't see anything wrong with that. When we made the decision
to go with one framework we made the life of developers !much easier and
the life of users much easier. Install a component and it just works - no
need to customise the existing template or even worse buy a new one that
supported that template. Sure that will not please the designer who wants
to control everything but are they really the target user
Why shouldn't designers be considered in decisions, surely they're an important persona to the community. You could just as easily argue half the code related things some of us try to do should just be ignored because developers sure aren't one of Joomla's target user groups.
We already have had a pseudostandard without any CSS framework back before J3. We all know how good those sites looked with all extensions doing their own things. I don't want to go back to this era. It would be a huge step backwards.
If extension developers have to build a very basic default layout plus a template specific BS4 layout you ask for double work here.
And what will template developers do if they want to build a BS4 template? Do they need to copy all the overrides from the default one (or create own ones)? How will they get hold of the 3rd party extension layouts? Or are the users supposed to copy them all manually?
I don't see the advantage it gives vs what we have today. Yes we "lock" into BS2, but since overrides can be used that isn't really an issue. If it is, we need to solve that, hopefully without creating multiple JLayouts for any given JFormField and JHtml method of course.
I could and I have regularly done so over the years. Something you have
come to realise yourself with your pr to remove various unused libraries
I've also come to realize it's a waste of time for Joomla to keep re-inventing its own solutions to problems because there are so many adequate solutions already on the marketplace but sadly everyone else continues to advocate for Joomla distancing itself as far as possible from design and development communities. This project fears giving developers the tools desired to create advanced projects (which is why anyone who is worth a damn has their own framework at this point, well that and the sad excuse of a B/C policy that existed before 2012), creating vendor lock by making heavy use of external libraries without alterations (see Bootstrap's JavaScript, Chosen, and TinyMCE translations as examples of the plethora of Joomla hacks), or allowing designers to work with the tools of their choosing.
Everyone seems so fond of Joomla 1.0 and 1.5. Here's my next suggestion. EOL 3.x and go back to those days. At least then the project would be back in sync with the majority of its userbase.
And what will template developers do if they want to build a BS4 template? Do they need to copy all the overrides from the default one (or create own ones)? How will they get hold of the 3rd party extension layouts? Or are the users supposed to copy them all manually?
@Bakual joomla provides a way to create overrides in any template, beefing up this functionality is all it is needed here. And is not Joomla's responsibility but template creator's.
Can this proposal done in a more intuitive way? YES (after installing a component overrides created automatically)
Will this proposal cover different frameworks? YES (as long as the html is pure and not
<?php echo '<div class="row">...</div>
My last comment then I'm done arguing here since I apparently don't use Joomla like a "simpleton user" and frankly it pisses me off every it's implied that because I think like a developer that I need to STFU and stay out of user related discussions.
Identify the freakin' target market already and write the application for it. Right now the target market seems to be anybody on the internet and it shows because you've got people trying to use Joomla for everything imaginable and according to some that's either a good thing or a bad thing (bad mostly being the things people like me try to do apparently). If you're targeting end users, Joomla needs to be dumbed down to match the WordPress experience because quite frankly there are too many options and too many technical terms floating around to keep people comfortable. If Joomla doesn't care about designers as someone on this thread would suggest, then honestly, why bother having a flexible design system; get rid of the override engines and work with whatever gets shipped.
We can either try to make Joomla better or we can be the FIG and talk each other's ears off, argue "founder's vision" versus a changing mission and vision and spend all day wasting time on political ego stroking. Call me when you're interested in the former.
I understand that *.bs3.php, will give more flexibility,
- but after years we will be left with *.bs3.php files *.bs4.php files and *.someframework.php files that will need to be removed ?
- it can double, triple or quandriple the template files, that are required to maintain at the same time
I have done similar thing with *.html5.php and i sometimes regret it, because it has doubled my template files, making my templating look more complex (unnecessarily ?) and i have to update 2 files every time instead of 1
About using variables or a preprocessor to support replacing the classes or other code to make code agnostic to the framework, that will be nice
Just this is difficult to read
?>
<div class="<?php echo JTmpl::_('HTML_INPUT_GROUP_CLASS', 'input-group');?>
This is easier
<?php
echo '
<div class="'.$j_input_grp_class.'">
<label class="'.$j_add_on_class.'">...</label>
<input ... />
</div>';
or with preprocessor
<?php
echo '
<div class="_J_INPUT_GRP_CLASS">
<label class="_J_ADDON_CLASS">...</label>
<input ... />
</div>';
I'm writing here with the hat of my day job as extension developer. Most of the issues I face are FF related, because almost every template comes with Bootstrap 3 nowadays. So it doesn't make sense that every extension developer needs to find their own way with that mess. Most extensions do deal differently with that problem, some load a namespaced FF, some have settings and others make their own plugins. It's just hard for the end user to find his way trough all of that and to have a bloated site, because additional CSS files are loaded. For the extension developer it's frustrating as well as there is no standard way to deal with that issue.
You will never have the situation that only one FF will exist properly in Joomla. With every major version of bootstrap which breaks BC, the mess will be more problematic. I don't want to convince anybody that my proposal here (that's why it is a RFC) is the best solution, but it is one way to deal with the situation to satisfy extension developers and provide a migration path for bootstrap upgrades.
If this way is wrong, what's the plan then?
About Joomla template/code agnostic.
I and @ggppdk see some potential with using in template files something like :
<?php
echo '
<div class="'.$j_input_grp_class.'">
<label class="'.$j_add_on_class.'">...</label>
<input ... />
</div>';
I read above cons.
What about to go the same way as modules with module class (for html).
Maybe a set of fields for html classes?
At least one class configured as in module class could be helpful for component.
component html can be wrap by that html class:
<div class="component_use_only_bs2">
... component html
</div>
For J3.5 there was a loot better ideas, unfortunately they all died in silence.
We all know how good those sites looked with all extensions doing their own things. I don't want to go back to this era.
Current state is better, but far from perfect. A loot extension developer still tried to include different frameworks by own.
But problem not in a framework version or name.
I think the problem that we do not have a good guideline for make UI (or how it names) in Joomla 3 (at least for backend). But to write such guide is a huge challenge, the task close to impossible
Current state is better, but far from perfect. A loot extension developer still tried to include different frameworks by own.
Agree here. I saw many extensions which do have namespaced CSS frameworks loaded, bloats the site. For me the problem is, that there is no unified way to deal with different frameworks.
copy paste was always a good approach (e.g. copy Bootstrap, paste Joomla)
?
Why don't we just fork the internet and be done with it? That seems to be the trend in Joomla anyway considering the number of hacked libraries the project ships and the desire from the top down to have 100% control over every line of code in the project with minimal influence by any third party to be able to screw stuff up.
Fork Bootstrap 2, add all the BS3 and 4 goodies into things, and be done with it already. No, I'm not trolling at this point.
After giving some thought to this,
whatever the disadvantages of having 1 layout file per framework,
it is more than worth the trouble,
because it makes changing / selecting a different display framework much simpler, it is also make the layout files readable and easier to update.
Then a global parameter in Joomla should select the display framework ! that will also load appropriate framework JS / CSS
J4 should be like this instead of tightening it to a specific bootstrap version !
@wilsonge But honestly I disagree with this approach. This introduces huge complexity for minimal gains. Core should and won't ever support bs3. We're adding in additional complexity by loading additional layouts (even if they proxy) and it will make it even harder for people to transition.
Humble question: Why the Core should or won´t never support bs3 and what is the plan for Joomla4 and how we can make a smooth Frontend transition?
We don´t load additional layouts beside the bs2 files. We load only bs2 or bsX (replace X with whatever Joomla4 uses). It can`t be harder, if the people have the oppurtinity to adopt bsX in Joomla 3.x base and a have huge time frame for the transition. I asume that the Frontend Style Migration was never really focused by Joomla. We have an good Data Migration from J2.5 to 3.x, but a bad one from FF perspective. I asume again, that this will happen again, if we don´t see this as a problem.
I personally feel that it's down to extension developers to provide additional layouts that people can just copy paste into their templates. Sure it's unideal - but it's going to be a better overall experience than what this gives.
A Tempater don´t knows what a extension do and if the extension developer provide overrides for the Templates. The extension developer don`t know, what FF use the templater. If the core has bsX in Support, then the Templater and the Extension Developer can use a modern FF and in a stable, realiable and modern enviroment. How the overall experience can be better in this situation? I know at least 3 or 4 projects (including my own) to create a proper bs3 override and make this public on github for everyone and none of them never seen the light. At some point you see limitations and quirks and give up. A native bsX Support in Joomla 3 can make a really big difference to the Extension and Template ecosystem and can reduce the "i try my own solution and bloat joomla with 1MB+ FF files"!
Nowadays i see many Joomla Sites with 500kb+ CSS and 400kb+ JS Files in our very own userbase, with many long lasted Joomla Interrgrators. The most of them can´t solve this. The extensions developers use their own prefixed bootstrag files. Joomla delivers in addition Bs2 and the Template load the uikit Framework and we have a bloated, slow and soup of HTML Markup. I for my own, use a complete overrided and complete on uikit based Markup and excluded every Bootstrap file. This works in my limited site, with some extension. But i cant sale my solution to my customers, because its a very specialized solution and not every extension, will work with this...
I have a suggestion: We should ask the marketing team, if they can make a official poll, with dedicated questions about this to Extension Developers, Templaters, System Integrators and Users. We can ask them if they see this as a problem or not? If this is a problem, how they solve that? And much more questions, like that. Then we can make a decision in any direction, if this is really a problem or not and if worth to try to find a solution for this problem. We have some really big communities on Facebook. The international FB Group has over 25000+ Members and maybe it`s a good place to start a poll there, to see what the Joomla user base really thinks about this.
I hope you can understand my intention, despite my poor english skills :-)
Had some chats on the Joomladay Germany. Most people agree that we need to some plan to disconnect the core from bootstrap and to have a unified way to support multiple frameworks and their different major versions without to duplicate code. Perhaps this approach is from architecture point of view wrong but we need to address that issue in some way. I tried to describe the problem in this blog post https://joomla.digital-peak.com/blog/205-the-joomla-bootstrap-problem for none technical users as it looks like here are mostly core devs commenting.
This is similar to the above but minimalist:
- Joomla core does not need add or change any template files.
- Joomla only have to add support for reading template setting(s) from component,..:
- ex. "What framework do you use?"
- Every component/module/plugin would get that setting before render own template files.
Joomla may to add only some standards for that.
The purpose is to add communication between component and template.
Closing this as the aim of this RFC was to get a solution for the bootstrap vendor lock-in. But I failed. But there is still hope we will achieve it some day.
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-01-21 21:20:27 |
| Closed_By | ⇒ | laoneo |
| Category | Front End Components Layout Libraries Modules Templates (site) | ⇒ | Front End com_contact Layout Libraries Modules Templates (site) Components |
Is it really worth doing this with BS3 - all development on BS3 has now
been stopped in favour of BS4
On 12 September 2016 at 10:55, Allon Moritz notifications@github.com
wrote:
Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/