{"action":"created","issue":{"url":"https://api.github.com/repos/joomla/joomla-cms/issues/12016","repository_url":"https://api.github.com/repos/joomla/joomla-cms","labels_url":"https://api.github.com/repos/joomla/joomla-cms/issues/12016/labels{/name}","comments_url":"https://api.github.com/repos/joomla/joomla-cms/issues/12016/comments","events_url":"https://api.github.com/repos/joomla/joomla-cms/issues/12016/events","html_url":"https://github.com/joomla/joomla-cms/pull/12016","id":176336720,"number":12016,"title":"[RFC] An approach to soft upgrade bootstrap","user":{"login":"laoneo","id":251072,"avatar_url":"https://avatars.githubusercontent.com/u/251072?v=3","gravatar_id":"","url":"https://api.github.com/users/laoneo","html_url":"https://github.com/laoneo","followers_url":"https://api.github.com/users/laoneo/followers","following_url":"https://api.github.com/users/laoneo/following{/other_user}","gists_url":"https://api.github.com/users/laoneo/gists{/gist_id}","starred_url":"https://api.github.com/users/laoneo/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/laoneo/subscriptions","organizations_url":"https://api.github.com/users/laoneo/orgs","repos_url":"https://api.github.com/users/laoneo/repos","events_url":"https://api.github.com/users/laoneo/events{/privacy}","received_events_url":"https://api.github.com/users/laoneo/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/joomla/joomla-cms/labels/PR-staging","name":"PR-staging","color":"c7def8"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":20,"created_at":"2016-09-12T09:55:26Z","updated_at":"2016-09-12T15:34:01Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/joomla/joomla-cms/pulls/12016","html_url":"https://github.com/joomla/joomla-cms/pull/12016","diff_url":"https://github.com/joomla/joomla-cms/pull/12016.diff","patch_url":"https://github.com/joomla/joomla-cms/pull/12016.patch"},"body":"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.\r\n\r\nThis 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.\r\n\r\nIn 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.\r\n\r\nBS3 is used only for demonstration purposes, treat is a placeholder for the next frontend framework major version used by Joomla.\r\n\r\n### Summary of Changes\r\nThe template can define a new hidden parameter against which framework it is built to, like:\r\n```\r\n<field\r\n\ttype=\"hidden\"\r\n\tname=\"framework\"\r\n\tdefault=\"bs3\"\r\n/>\r\n```\r\n\r\nBy 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.\r\nThe params approach acts here only for demonstration purposes, there are many other ways how a template can define which framework it is made for.\r\n\r\n### Testing Instructions\r\n- Add the following code to the file templates/protostar/templateDetails.xml after the fluidContainer field\r\n```\r\n<field\r\n\ttype=\"hidden\"\r\n\tname=\"framework\"\r\n\tdefault=\"bs3\"\r\n/>\r\n```\r\n- Save the template\r\n- Create a new contact\r\n- Create a contacts category menu item\r\n- On the front, open the contacts link\r\n\r\nThe classes _col-md_ should be added to the grid cells and not _span_.\r\n\r\n### Pros\r\n- 100% BC\r\n- Framework related file can output a complete new content or set some variables for the default layout\r\n- No duplicate code\r\n- Template doesn't need to be shipped with all the layouts and template files of all components\r\n- Faster upgrade or switch to new frontend frameworks during one major version of Joomla\r\n- Reducing complexity for template developers as they don't need to create overrides for all extensions\r\n- 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\r\n- It is optional for the extension dev to create framework specific layouts and views\r\n- 3rd party extensions and the core will use the same way to deal with different frontend frameworks\r\n\r\n### Cons\r\n- Adds a new layer of complexity to the core\r\n- Performance decrease as more file lookups need to be done\r\n\r\nAt 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.\r\n\r\nI'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."},"comment":{"url":"https://api.github.com/repos/joomla/joomla-cms/issues/comments/246387468","html_url":"https://github.com/joomla/joomla-cms/pull/12016#issuecomment-246387468","issue_url":"https://api.github.com/repos/joomla/joomla-cms/issues/12016","id":246387468,"user":{"login":"mbabker","id":368545,"avatar_url":"https://avatars.githubusercontent.com/u/368545?v=3","gravatar_id":"","url":"https://api.github.com/users/mbabker","html_url":"https://github.com/mbabker","followers_url":"https://api.github.com/users/mbabker/followers","following_url":"https://api.github.com/users/mbabker/following{/other_user}","gists_url":"https://api.github.com/users/mbabker/gists{/gist_id}","starred_url":"https://api.github.com/users/mbabker/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mbabker/subscriptions","organizations_url":"https://api.github.com/users/mbabker/orgs","repos_url":"https://api.github.com/users/mbabker/repos","events_url":"https://api.github.com/users/mbabker/events{/privacy}","received_events_url":"https://api.github.com/users/mbabker/received_events","type":"User","site_admin":false},"created_at":"2016-09-12T15:34:01Z","updated_at":"2016-09-12T15:34:01Z","body":"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.\r\n\r\nPart 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.\r\n\r\nAgain, 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.\r\n\r\nThe 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."}}
{"actor":{"display_login":"mbabker"}}