Bootstrap, Joomla 4.0 and upgrades

[jhallshape5]

Hello,

I have no idea where to post this so I figured this ideas board might be a good place.

My name is Jonah and I am the co-founder and owner of the Shape5.com Joomla template club. My business partner and I are extremely thankful for Joomla! and what it has provided to our families. I've always thought I should get more involved in the development of the project but unfortunately I just never have. Anyway this is my first post and suggestion.

Once a big CMS, its been sad to see the community lose more and more people. This in turn has caused such a huge drop in sales in our template club. It seems to stem from many reasons. One of the biggest is backward compatibility. We've had to create entire new templates at times (costing us hours of work and money) just to have them work on new Joomla versions. The lack of backward compatibility has pushed users to WordPress, etc.

Joomla 3.8 was just released and a tiny menu class change broke all the menus for our users running our templates. Thankfully we run a framework and core files can be updated to fix them but I just continue to see the lack of backward compatibility causing issues for end users. Sometimes its been changing a "_" to a "-" and the end result is things break.

My suggestions for Joomla 4.0?

1. In our opinion Bootstrap should never be forced upon the front end of Joomla (backend its welecomed for beautiful consistent styling). Maybe a switch to turn on and off for the front end? Since its been forced in we've had to create additional CSS (bloating sites) to override its outputs so we can style our templates to our liking. Bootstrap is nice but who wants every site to look like a bootstrap styled site?

2. If backward compatibility could be taken into deep consideration upon new releases I believe this would help the community. Is it too late? I'm not sure but I know over the 10 years our club has been around its been quite an issue for us let alone our users and their clients.

All the best to Joomla! and the volunteers. We are so thankful at Shape5 for all the hard work that is put into the project by everyone. This post may come off negative but this is not my intention. I love Joomla and only want to see it succeed. I remember talking to Louis Landry years ago at a Joomla conference and he said he never heard much from template developers. I'd love to chat more if there are any questions or ways that I could give feedback.

Thanks,

Jonah

[deleted user]

1) Bootstrap is not forced. In earlier 3.x releases, there was more of a requirement to use its markup as certain elements did not support overrides, but core is now at a point where almost everything markup related either uses a layout system, supports an override mechanism, or the Bootstrap "bloat" exists as element classes or DOM structure. As such, a toggle like this should never be introduced as it is ultimately up to the template to choose a framework for use and override the required elements to make things compatible.

2) Please give specifics as it relates to your B/C concerns. The project's development strategy is publicly available, including a focus on B/C at https://developer.joomla.org/developmen ... patibility which is our "contract" for what breaks are and are not acceptable or when they are allowed.

[jhallshape5]

1. Really? We don't know of anyway to disable its output on the front end. Could you please explain how? Thanks

2. Recent changes in Joomla 3.8 that have caused issues for our templates and users:

a. The little cog icon for the print and email changed from an <a> to button now. So they are all stylized as buttons now causing an override or rewrite of CSS for us and users.
b. A change was also made to the "next" and "prev" buttons on articles with also broke output as we had CSS hiding the span icon.
c. This is the biggest issue and we are responding to tons of threads and emails on this daily right now. The menu class change I mentioned above is as follows and broke all sites using our templates when upgraded to Joomla 3.8:

'/includes/menu.php' : '/libraries/cms/menu/site.php');

To:

'/includes/menu.php' : '/libraries/cms/html/menu.php');

[deleted user]

For the markup, if you want to use another markup structure you must use overrides appropriate for the system (component or module layouts, plugin layouts, layouts using the JLayout API, or if the markup is generated by a JHtml helper then registering an override for the service key and replacing the PHP callback). There is no option to enable/disable a specific framework's markup nor should there be as at the end of the day the markup is entirely in locations that support easy overrides.

The markup structure changes you reference are all changes required to address accessibility concerns in the core layouts. As noted in the development strategy, right now HTML structure is not required to retain 100% compatibility between releases and as such there may be minor updates required for various reasons (accessibility fixes or changes required to support new features being the two common things).

`includes/menu.php` has not existed in the CMS package for years. Also, there has been no requirement for you to manual include the file at any point as long as Joomla is correctly bootstrapped as you should be using `JMenu::getInstance()` which handles all of the class/file loading. So correct use of the API would help you in regards to getting the menu class loaded.

[mmx]

Among other publications, David Sawyer McFarland wrote a book called CSS3 the missing manual (ISBN: 978-1-449-32594-7). Although I do not agree with all of his approaches and ideas, he has a good grasp of css inheiritance and the cascading principles of the language. The book contains guidelines and tips for overriding css code. You might find the book useful.

[jhallshape5]

Thanks in regards to the menu class loading.

So we are testing on Joomla 4 alpha today. Some great examples of what I'm talking about. First off it looks great, happy to see the admin looking like WordPress. Hopefully it will help people navigate the admin better and not feel like its too hard to understand (although I always loved the admin myself).

Ok so tons of function changes that break our templates. This never happens on the successful CMS WordPress and I believe part of a reason for its success is backward compatability. And the changes just don't even make sense to us. In the alpha here is a perfect example of why I started this whole post. Before it has been things like changing a _ to a - and breaking CSS code, etc:

JURI::root();

to:

JUri::root()

Why oh why? Why change the uppercase to lower and break everything relying on this code? I just don't get it but its been like this with all big Joomla upgrades.

Date::toFormat() = This is no longer supported and causes issues for our products that rely on it to output dates.
JFactory::getURI() = Another one no longer supported breaking things. These 3 things are just right off the top when installing one of our templates on a fresh Joomla 4 alpha.

Thanks

[xfsgpr]

1. In our opinion Bootstrap should never be forced upon the front end of Joomla (backend its welecomed for beautiful consistent styling). Maybe a switch to turn on and off for the front end? Since its been forced in we've had to create additional CSS (bloating sites) to override its outputs so we can style our templates to our liking. Bootstrap is nice but who wants every site to look like a bootstrap styled site?

Bootstrap is not forced on anybody unless they decide to use default template in which case Bootstrap is used. For Front End, it is the work of the template and that is where you come in. You need to make sure your templates work on any particular Joomla version.

2. If backward compatibility could be taken into deep consideration upon new releases I believe this would help the community. Is it too late? I'm not sure but I know over the 10 years our club has been around its been quite an issue for us let alone our users and their clients.

With Bootstrap, you can't guarantee backwards compatibility because the Bootstrap CSS files changes and so some classes and IDS also change. Bootstrap 4 uses the CSS3 Grids and Flex so how can you make it backwards compatible? Any new templates made using BS4 will inevitably use Flex and Grid.

One of the biggest is backward compatibility. We've had to create entire new templates at times (costing us hours of work and money)

That is the price you must pay for being in business. What is the point of doing the same thing year after year? Businesses have to change as technologies change.

[jhallshape5]

I was a bit wrong about bootstrap being included I forgot we included a modded version of it. A lot of components rely on it and thus if we don't include it they look horrible. So we've been stuck with having to include it in our templates and basically create our own version of the CSS so that any 3rd party extensions will still look proper on the frontend with our templates. Gavick, another big Joomla template provider also actually blogged about this and its interaction with template providers:

https://www.gavick.com/blog/mixing-joom ... -good-idea

With Bootstrap, you can't guarantee backwards compatibility because the Bootstrap CSS files changes and so some classes and IDS also change. Bootstrap 4 uses the CSS3 Grids and Flex so how can you make it backwards compatible? Any new templates made using BS4 will inevitably use Flex and Grid.

Exactly my point and I believe Gavicks. This wouldn't be an issue if it wasn't there in the first place. Layout should be up to the template author not a framework/layout system that now many components have adapted to taking on with class names, IDs etc.

That is the price you must pay for being in business. What is the point of doing the same thing year after year? Businesses have to change as technologies change.

I'm sorry but you are missing my entire point about being backward compatible. I agree things due change with technology but customers don't want a CMS that can't be upgraded. Why? Because then they have to buy a new version of the template, hopefully find an update to their components (can be very hard as developers dont feel like recoding for the new version) they are using, etc. If not they are stuck on an old version of Joomla. And what happens when someone uses Joomla and spends thousands of dollars to hire someone to code a component, etc? Then a new version of Joomla comes out and basically they are forced to dump more money into the site to recode things so they work on the latest version? Its just crazy to me to expect that. You don't see this in WordPress as far as I know (I only mention because of its success, there is something to be said about how its been run).

I'm telling you we've heard this first hand. This is part of the reason why people have left the Joomla community. All of us as template providers have had to gone through such headaches over the years due to Joomla not keeping backward compatibility in mind. Changing little tiny things thats break stuff. I just gave an example above. A pointless change by renaming a function to have some lower case letters is not a needed technology change.

We've been in business 10 years now. WordPress never has had this issue (we also convert our Joomla templates to WordPress and offer them). I'm just trying to help the community by posting here like this that's all. You are hearing from a Joomla template developer thats been in the biz for a decade and served thousands of customers. And Gavick being one of the top providers is unfortunately no longer with us now due to the decline of Joomla.

All the best and thanks for the input. I'm not trying to be harsh. I believe in person communication is the best not text or email but hey this is what we've got right We would love to see Joomla blow up again like back in the day,

Jonah

[deleted user]

PHP is case insensitive as it relates to class and function names. So that is not an issue at all.

What is case sensitive as it relates to class names are autoloader definitions. In the case of Joomla, our global namespace class names use CamelCase and our autoloader splits the class name based on capital letters to map to the filesystem. JUri is a class that should be loaded pretty early in the cycle, so you shouldn't really be bitten by using it with incorrect casing, but if for whatever reason it isn't loaded and you try to reference it as JURI then Joomla won't be able to load it because the autoloader would basically try to find the file at libraries/joomla/u/r/i/i.php instead of the correct libraries/joomla/uri/uri.php.

With the namespacing effort and renaming classes in 3.8 (i.e. JUri actually is now Joomla\CMS\Uri\Uri but the old name will work for a while thanks to a migration layer), extra effort was put into ensuring the autoloader would take any casing of aliased class names to map to the correct class (so JUri, JURI, JurI, or JuRi should all work).

As for the Joomla versus WordPress arguments, fundamentally the two projects have differing strategies that are not always suitable for the same focus groups. Joomla makes B/C breaks in major versions (X.0.0), WordPress supposedly won't break B/C or remove code that has been deprecated since 2009. This isn't much different to Apple or Microsoft releasing a new major version of their operating systems and the software developers having to issue updates for compatibility or users having to update their systems when the time is right for them.

[jhallshape5]

Oh ok but JURI is still causing the frontend to break and throw an error unless I change it to "JUri". You can test with one of our free templates if you want. Just have to get passed the date error first which can be commented out in the "vertex/cms_core_functions.php" file. After getting a free account you can download here if you would like:
https://www.shape5.com/product_details/ ... plate.html

I understand but I'm just suggesting it might be good for the life of Joomla not to do it this way. I only bring up WordPress because of its success. I've given real world examples where it hurts not only us but the actual end users with Joomla on their sites. They are stuck and can't upgrade many times without again spending a good amount of money.

[paulala]

PHP is case insensitive as it relates to class and function names. So that is not an issue at all.

What is case sensitive as it relates to class names are autoloader definitions. In the case of Joomla, our global namespace class names use CamelCase and our autoloader splits the class name based on capital letters to map to the filesystem. JUri is a class that should be loaded pretty early in the cycle, so you shouldn't really be bitten by using it with incorrect casing, but if for whatever reason it isn't loaded and you try to reference it as JURI then Joomla won't be able to load it because the autoloader would basically try to find the file at libraries/joomla/u/r/i/i.php instead of the correct libraries/joomla/uri/uri.php.

With the namespacing effort and renaming classes in 3.8 (i.e. JUri actually is now Joomla\CMS\Uri\Uri but the old name will work for a while thanks to a migration layer), extra effort was put into ensuring the autoloader would take any casing of aliased class names to map to the correct class (so JUri, JURI, JurI, or JuRi should all work).

As for the Joomla versus WordPress arguments, fundamentally the two projects have differing strategies that are not always suitable for the same focus groups. Joomla makes B/C breaks in major versions (X.0.0), WordPress supposedly won't break B/C or remove code that has been deprecated since 2009. This isn't much different to Apple or Microsoft releasing a new major version of their operating systems and the software developers having to issue updates for compatibility or users having to update their systems when the time is right for them.

Interesting stuff. Thanks mbabker

[darb]

Joomla4.jpg

"I agree things due change with technology but customers don't want a CMS that can't be upgraded. Why? Because then they have to buy a new version of the template, hopefully find an update to their components (can be very hard as developers dont feel like recoding for the new version) they are using, etc."

I have never had a problem with Joomla as "a CMS that can´t be upgraded". You should always upgrade Joomla to the latest version for all reasons you should be aware of, but take it easy with the major updates and test before doing it. If you have not skilled developers that develop your Joomla extensions thats is the problem they have to be updated about Joomla itself and active in the Joomla development community.

You just learned a lot from this thread that could have helped you years ago..