Hi George,
Just out of curiosity: the impact of switching back-end framework in 'the last' beta (from BS4 to BS5) mainly impacts extension developers. Especially the ones who did the hard work of migrating all their extensions to J4. It will also impact trainers who started to make instructions videos and documentation based on the BS4 back-end.
For me the 'Joomla community' is (unlike the Open Source code) very 'closed' when it comes to voting and having a say in some very important matters for the 'real' Joomla community (the ones using it or building on top of it).
My question is: who is 'production' that is supposed to vote and are extension developers and 'trainers' who are not considered part of the Joomla 'community' able to have a equal vote in this?

@wilsonge is referring to the people listed https://volunteers.joomla.org/departments/production

@wilsonge is referring to the people listed https://volunteers.joomla.org/departments/production

Thanks @brianteeman,
any insight as to how they are going to reach out to the Joomla community for this important change (not saying we should or should not do this move, just want the Joomla Community to have a vote in the matter)

@wilsonge @dgrammatiko guys I think a good approach with min b.c. (that will keep work that already done) would be:

• use the official Bootstrap 5
• make a migration css, js, that will cover missing parts from Bootstrap 4 (should be separated assets, that allows to disable it, who no need)

With this we and developers (who already adopted their code to B4) can continue migration to B5 even after Joomla 4 released.
At some point (let say in joomla 4.5) migration stuff can be dropped.

What do you think about, does it possible?
I did not checked the detailed structure and changes in b4 vs b5, cannot really answer on my own.

fedik best is to test @dgrammatiko PR #31990 for Bootstrap 5

@Ruud68 As you can see I am not in that list so I really don't know but I wouldnt expect any "reaching out"

@Ruud68 As you can see I am not in that list so I really don't know but I wouldnt expect any "reaching out"

Thanks, learning from history I wouldn't expect it as well, that is why I am asking. This will for sure result in valuable community members to 'vote' with their 'feet' (dutch saying :))
I have my hopes on the Core developers (in or not in the production team) to do what is needed. Never had 'management' made me do anything that I wasn't fully committed to doing my self :)

Hello, I know that I am not a developer, but a simple user who gives some of my time to Joomla. But not choosing to use Bootstrap 5 is like an automaker refusing to go hybrid or electric and questioning whether the network is ready. For once, after refusing the Khonsu template, the development team needs to be more visionary and ahead of its time. It is also a strategy for the future and the development of Joomla on the CMS market. It's also marketing!

Hello, I know that I am not a developer, but a simple user who gives some of my time to Joomla. But not choosing to use Bootstrap 5 is like an automaker refusing to go hybrid or electric and questioning whether the network is ready. For once, after refusing the Khonsu template, the development team needs to be more visionary and ahead of its time. It is also a strategy for the future and the development of Joomla on the CMS market. It's also marketing!

I fully agree on this, my concern is with the part of not having a vision and mission you can agree on and not having the process in place to involve the relevant 'community members' in this.
To many valuable developers are walking away or putting stuff on hold.

We are well aware. There are extension dev's involved here #31765 (if you haven't commented there I strongly recommend you do as we are monitoring that closely) and also Production have a separate A4 document of Pro's/Con's that @marcodings has been working on as a result of latest Production meeting on Tuesday when we first discussed this as a result of the open discussion. We are also consulting with JED about the number of extensions that have already been marked as J4 compatible to get a feeling. As well as the main reason I started on this was to get a feel of the work involved in converting some of the core extensions.

So I can promise you that this is being taken into account @Ruud68 - because I also understand that even if BS5 doesn't impact the CMS release time because people are willing to work with on this conversion it makes no difference if extensions are going to need 2 months after the J4 stable release to become compatible again

Thanks @wilsonge , I just commented (#31765 (comment)) :)

It's less radical than @dgrammatiko 's work in #31990 in that it uses the official Bootstrap 5 JS combined file (although I think his work is valuable and probably should be merged in a future J minor

Just a comment here about #31990:

• As it is atm ( 7d03afe ) it's not B/C but it can be patched to become.
• I started that as a clean slate just to showcase the amount of work needed to do the transition (to vanilla not just v5 as George is doing here) #31990 (comment)
• This PR and #31990 are not exclusive, you can have the markup/css from this one and the JS from the other (assuming the B/C breaks are patched).

In sort my take on the transition is simple: Move to BS5 (the vanilla js version) and patch the B/C breaks (doable) for any of the areas: SCSS, JS the project needs to keep B/C (personally I'll say it's better to break both at the major version). Postponing some of the needed work to a later day is not a very pragmatic approach. Bite the bullet and DO the work NOW.

Lastly I think the project needs a clearly defined vision on where it goes, eg: do we really want to ship our UI based on jQuery in 2021? In the other PR the UI is modular which in most views result to over, at least 50% less JS (for the same interactivity). Why would you punish the performance (and by extension SEO, etc) by keep on doing things the way it was done 10 years ago? (Rhetorical questions, I don't expect any answer here, I have been talking about all these matters the last 5 years and it seemed that the devs are not willing to evolve to the current state of the web. But then again if the project doesn't evolve it becomes irrelevant and finally dies).

Hi
Formerly a developer, now a simple user, I wouldn't dare say whether to integrate it or not.

In contact with developers who sell extensions, I'll just say that we (them, me) are waiting impatiently for the new version. I'm afraid of a new delay that could make lose more members of the community than the absence or presence of this feature when the final joomla4 version is released.

HDInfautre please do not hijack the topic and waste our time, but better go and test wilsonge or @dgrammatiko PR #31990 for Bootstrap 5

Remember topic is [WIP] Bootstrap 5

@chnnst he's more than welcome to post his opinion but @HDInfautre if you could post that on the discussion track here #31765 it's better so it can be all kept together!

Please rename all instances of .sr-only to .visually-hidden. Thanks.

Please rename all instances of .sr-only to .visually-hidden. Thanks.

Done - but as a global search/replace as over 400 instances - so hoping I haven't broken anything doing it

renaming sr-only to visually-hidden is guaranteed to cause problems that dont need to happen. Even if you rename all the uses in core you must leave sr-only as a class in the template css. It's such a well used class and just removing it will cause problems that dont need to occur

@wilsonge Nice work ? ?

Going through all the front end view and unable to find any real issues with it. Maybe some small tweaks but at first glance you have 98% of the work done here.

Considering the 2 separate PRs here, maybe a new core branch for BS5 might make sense?

renaming sr-only to visually-hidden is guaranteed to cause problems that dont need to happen. Even if you rename all the uses in core you must leave sr-only as a class in the template css. It's such a well used class and just removing it will cause problems that dont need to occur

Font awesome actually still contains it - so it is present - I wasn't sure whether to do an explicit class map in the template css as a result. Happy to if people think it's necessary.

Maybe some small tweaks but at first glance you have 98% of the work done here.

That's the stuff I may need help with - I'm not a real frontend person. Mainly this is fix compiling errors and working my way through the migration guide.

Considering the 2 separate PRs here, maybe a new core branch for BS5 might make sense?

I think they just go in order. As @dgrammatiko said mine first then his (which will be much smaller). I've kept my branch upto date with his I think largely - the only thing I haven't pulled in is some of the later tweaks where he swapped some instances of the popover element from class driven to data attribute driven. I think in both our branches the modals from toolbars are broken (which is related to how the toolbar's are triggering the modals by custom elements - but the modals are outside the custom element)

Finally it would seem something under the hood with the bootstrap 2 -> 4 changes mean the system tests can't deal with the switcher element now. I wondered if it was the removal of overflow: visible to all inputs but adding that back didn't seem to fix anything. Guess I'll need someone's help from the testing team or something.

regarding sr-only they should NOT be renamed to visually-hidden. They are separate classes with seperate design uses. See BS5 official documentation.. https://getbootstrap.com/docs/4.0/getting-started/accessibility/

oops, thats bs4 but still shouldn't be changed... https://getbootstrap.com/docs/5.0/getting-started/accessibility/

Per the Migration doc:

Renamed .sr-only and .sr-only-focusable to .visually-hidden and .visually-hidden-focusable

oops, thats bs4 but still shouldn't be changed... https://getbootstrap.com/docs/5.0/getting-started/accessibility/

What part of that document gave you that (wrong) impression

I've spent quite some time today with this and I couldn't find anything that's obviously broken although I think I tried all possible views for all 3 clients.

Hats off to @wilsonge for the awesome work here! ?

Options and Help buttons not right-aligned.

Options and Help buttons not right-aligned.

That's because the alignment is done with JS, will so a PR

PR #53 also there's another PR #52 from @ciar4n

Should the following be considered?

Removed and replaced .badge modifier classes with background utility classes (e.g., use .bg-primary instead of .badge-primary)
Removed .badge-pill for the .rounded-pill utility class

Yes but that’s being covered already in the PR @ciar4n has against my branch (it’s not quite ready for merging though)

There's still the tests to fix (but this is something related internal to selenium and the switcher element - it's not an issue in the UI).

There's some last issues to fix with custom-select class alias' (the publish item is missing it's colours - @ciar4n is helping me with that).

Other than those two known issues I think this is ready for testing.

Rename .text-left and .text-right to .text-start and .text-end.

Go to Systems. See spinners spin indefinitely.

Spinners aren't going indefinitely here - going to need a bit more info to reproduce (are there any JS errors in the console?). Text classes fixed - good spot.

Uncaught DOMException: String contains an invalid character admin-system-loader.js:45
    onSuccess http://localhost/Joomla_4.0.0-beta7-dev+pr.32037-Development-Full_Package/media/com_cpanel/js/admin-system-loader.js?eddae4cda204acc628ff926ed4d2cb41:45
    onreadystatechange http://localhost/Joomla_4.0.0-beta7-dev+pr.32037-Development-Full_Package/media/system/js/core.js?eddae4cda204acc628ff926ed4d2cb41:214

OK Guessing at the fix with 34ed80c - let me know if this helps or not - as i say it works for me (TM) so going to have to be a bit speculative.

OK Guessing at the fix with 34ed80c - let me know if this helps or not - as i say it works for me (TM) so going to have to be a bit speculative.

Fixed.

Yay for guesswork ? Let me know if anything else is broken

I tried to submit a PR in your branch but GitHub is not cooperating.

Change form-control to form-range.

https://github.com/wilsonge/joomla-cms/blob/34ed80c8835d9f7250425d8bf2e7dba8c1c12fc3/layouts/joomla/form/field/range.php#L51

Dropped .form-inline for the more flexible grid.

BS4:

BS5:

Uncaught TypeError: Joomla.Bootstrap is undefined
    <anonymous> /media/mod_multilangstatus/js/admin-multilangstatus.js?ca3b4532d8863ed38fcdea91cea46bc7:25
    EventListener.handleEvent* /media/mod_multilangstatus/js/admin-multilangstatus.js?ca3b4532d8863ed38fcdea91cea46bc7:13
    <anonymous> /media/mod_multilangstatus/js/admin-multilangstatus.js?ca3b4532d8863ed38fcdea91cea46bc7:28
admin-multilangstatus.js:25:7

Go to Media. Click Create New Folder button. See Close button.

@Quy I think I've addressed everything you've raised so far other than the form-inline things - will look at them this evening

Go to Media. Edit an image. Click Rotate tab.

Edit an article. Click Publishing tab. Click User icon. See missing bottom border.

<small class="form-text text-muted">

form-text includes font-size and color which have same values as small and text-muted.

• change to div
• remove text-muted

Banners > Tracks > Export button
Modal behind overlay.

Banners > Tracks > Export button

@Quy there's a PR for a less hacky solution for this #32062 (All the modals in the toolbar have this issue, there was a hack to move them out of the toolbar area with JS, the proposal is using a new renderer so no js hacks)

ah - I wondered what the reason was for that PR

form-text includes font-size and color which have same values as small and text-muted.

I'm going to leave this one. I can see in our SCSS we're overriding so the text-muted has an opacity in the atum global.scss file. I'd rather not optimise right now and just fix the things which are actively broken. It's probably a good optimisation to make after this is merged though

@ciar4n can i have some help with the issue @Quy mentioned in #32037 (comment) - it's related to Simplified table styles (no more odd top border) and tightened cell padding.. As best I can tell we relied on the top-padding in the past. And it now looks odd because .tbody-icon has border: 0 applied from before and the border-top now longer "overrides" it. I'm sure I can bodge something - but I'd rather have someone who knows better rework it to be 'proper' across all our table styling

@Quy media buttons fixed. I believe currently outstanding things outstanding are the table thing I've just asked Ciaran for help on and the Exports modal & form-inline stuff which is on me

@Ruud68 the whole production has been looking at this issue with great seriousness and much research. There is a document that has been worked on for the last two weeks to outline the pros and cons of this idea of moving to BS5 at this point.

Clearly there is no one in production, not even @wilsonge who has any agenda or over bearing motive to push for BS5 or the be against it. There a strong desire to do what is best for Joomla, the community, and a specially for extension developers like me who has 70+ extensions ready with bootstrap 4.

We all realize that Joomla has been at this door before, and so trying to learn from past failures and earnestly looking to do the right thing, so the vote/motion in production is still in discussion.

Production is ready to support the community, to try and make the best decision on this issue, and yet we realize we are not going to be able to satisfy everyone, this is just not possible.

So as just another guy I would like to think that we are all trying our best, and if anyone can do better... we need you in a team in production to help us make the better decisions.

Now do you see the value of communication with the community instead of keeping silent behind a brick wall

@Llewellynvdm , I do not understand that it is so difficult to make a choice between the past and the future ...

@brianteeman we are not silent, just speaking to those who are in production (mostly on glip) and trying to listen to those on the github without imposing our views (so yes I/we read and take long to say something). But those in production who are on Glip knows there are no walls, anyone can become part of production and have a say. I have been humbled and encourage by how wrong I was about the PTL... they are a great team of volunteers who are serving this community with serious advance skill and endless commitment. I really appreciate their long and tireless labor that often goes unseen.

I really appreciate their long and tireless labor that often goes unseen.

If only it was seen then @Ruud68 would not be making the valid comments he has made.

I really appreciate their long and tireless labor that often goes unseen.

A shame all contributors are not appreciated

A shame all contributors are not appreciated

That is not what I said (don't place words in my mouth)... I appreciate your contribution and that of other very much... and also that of those who are in production.

@Llewellynvdm please take the conversation to the discussion issue #31765

This is not the place for it, let George and anyone else actively working on this to do that without irrelevant notifications. Thanks

The module on the login page no longer has any padding

Before

.col,.col-1,.col-2,.col-3,.col-4,.col-5,.col-6,.col-7,.col-8,.col-9,.col-10,.col-11,.col-12,.col-auto,.col-lg,.col-lg-1,.col-lg-2,.col-lg-3,.col-lg-4,.col-lg-5,.col-lg-6,.col-lg-7,.col-lg-8,.col-lg-9,.col-lg-10,.col-lg-11,.col-lg-12,.col-lg-auto,.col-md,.col-md-1,.col-md-2,.col-md-3,.col-md-4,.col-md-5,.col-md-6,.col-md-7,.col-md-8,.col-md-9,.col-md-10,.col-md-11,.col-md-12,.col-md-auto,.col-sm,.col-sm-1,.col-sm-2,.col-sm-3,.col-sm-4,.col-sm-5,.col-sm-6,.col-sm-7,.col-sm-8,.col-sm-9,.col-sm-10,.col-sm-11,.col-sm-12,.col-sm-auto,.col-xl,.col-xl-1,.col-xl-2,.col-xl-3,.col-xl-4,.col-xl-5,.col-xl-6,.col-xl-7,.col-xl-8,.col-xl-9,.col-xl-10,.col-xl-11,.col-xl-12,.col-xl-auto {
    position: relative;
    width: 100%;
    padding-right: 1rem;
    padding-left: 1rem;
}

After

    .col-md-12 {
        flex: 0 0 auto;
        width: 100%
    }

Comment

It's a matter of taste if there is padding but if there isnt then the rounded corners look wrong

Language Overrides

Before

After

Tables are all missing a line between the header and the rows. This is easily fixed by removing
https://github.com/wilsonge/joomla-cms/blob/476c2961f44739924e1c9864029d94870f3e6b58/administrator/templates/atum/scss/vendor/bootstrap/_table.scss#L17

But then the color is wrong (beyond my skillset)

Language Overrides

Fixed with wilsonge#58

@ciar4n can i have some help with the issue @Quy mentioned in #32037 (comment)

wilsonge#59 should apply J4 borders and spacing and covers both default an -sm tables

Ref..
#32037 (comment)
#32037 (comment)

@brianteeman table styling and login padding covered with wilsonge#59

Edit an article.
Click CMS Content > Image.
Select an image.

BS4:

BS5:

Uncaught TypeError: element.toggle is not a function finder-edit.js:50:21

Go to Components > Filters.
Add a new filter.
Toggle Expand all button.

Ref: #32037 (comment)

@Quy Fixed with #wilsonge#59

Go to Components > Filters.
Add a new filter.
Toggle Expand all button.

@Quy out of curiosity: is this working as expected on the dev-4.0 branch?
BTW the issue is related to the Joomla-tabs and has nothing to do with the BS changes

@Quy out of curiosity: is this working as expected on the dev-4.0 branch?
BTW the issue is related to the Joomla-tabs and has nothing to do with the BS changes

Working fine in the dev-4.0 branch.

Shouldn't we also switch to bootstrap icons?

I don’t plan on switching the icons

wilsonge#59 should apply J4 borders and spacing and covers both default an -sm tables

Not fix with Users. Also an issue with Status column under CMS Content dropdown for Article, Contact, and Module,

BUG RTL ADMIN MENU

Create new menu item

1. The rows are very close together
2. they dont open at all

they dont open at all

@brianteeman it's fixed in the other PR so we have to propagate the changes here as well: 8f1bbda

Also you can check the same issue in Smart Search -> Filters ->filter edit view

Install From Web

BS4:

BS5:

Accordions fixed with a combination and @dgrammatiko 's commit + a missing scss import

With the decision now made, and public https://developer.joomla.org/news/839-joomla-4-0-will-ship-with-bootstrap-5.html, please can this just be merged so we can make progress

Then we can tidy up the rest of the bugs and issues as smaller PRs/Issues that have more chance of being reviewed, tested and merging.

We cannot expect everything to be made perfect in this one PR. We cannot expect @wilsonge to be reviewing all the comments, picking out the bugs, and fixing everything in his fork/branch for this PR. This job is not for a one man band but needs all of us. The time has come to merge, and then we can start systematically going through what's left.

More people will test if this is merged, than if this (and the the JS PR) stay as one huge PR in draft.

@PhilETaylor maybe merge both PRs and release immediately another beta? I guess this is @wilsonge 's call how he wants to handle things

Not my call - my point is that the more hands and eyes on this the better, and the only way that is going to happen is to merge ( and break?) it to 4.0-dev and let people get to it...

Maybe label it an Alpha not a Beta too... make @mbabker smile :)

@wilsonge things like changing class names you could have asked me to do. In the future to free you for more important projects remember me for things like that.

With the official decision now in place, i think that it's fundamental to merge as soon as possible in a new Beta 7 and inform all developers through a JED newsletter to start to update their extensions.

maybe merge both PRs and release immediately another beta?

sure merge both pr's 1st....
it's really time expensive right now to test both

merging we will gain more tester ect

The plan is now for an additional beta once we've stabilised the bs5 stuff. I've not talked to marketing yet (decisions finalised and blog posts have gone out today whilst I've been at work), but I'd imagine probably either next week or the week after.

sure merge both pr's 1st....

No because there can be issues from bs5 and issues from compiling bootstrap javascript ourselves. I want to do one then the other so we know the source of each bug.

compiling bootstrap javascript

Glad to report, I'm just cleaning the branch before pushing it:

I didn't intend to release a new beta....
just have a single pr

just have a single pr

That only one person can contribute to. Madness.

Just merge it now that its almost complete/when its almost complete - let others test, let others contribute, for one man to do all on his own is madness - and slow.

Merged with get more testing and feedback.

A new beta will get the most testers.

Sorry, but what testers and developers need is a plan with dates. Beta 7 for 3 weeks, PR1 for three weeks, ... and above all stick to it to regain everyone's confidence. And don't imagine that Joomla 4 will be released in 2022.

That only one person can contribute to. Madness.

yet again i'm expressing myself badly

a pr can have pr .....just for the record

a pr can have pr .....just for the record

What a mess. :-) :-)

Please, be patient. Let George to take a breath. Everything will be fine and this brunch will be merged with 4.0-dev soon. Let George and Dimitris do it when they're ready.

@wilsonge your doing too much. No one can review what you're doing and you don't need to do it on your own. plus your actually holding up others who need to make changes. Just merge this NOW and then everyone else can test, fix and find missing bits.

plus i can see silly little errors creeping in because no one can test it etc

oh and visually-hidden is not a direct replacement for sr-only so they all need checking :(

plus i can see silly little errors creeping in because no one can test it etc

Sorry I was sitting on a call with @webgras and @softforge trying to fix issues as they came across them. I've tried to fix as possible

oh and visually-hidden is not a direct replacement for sr-only so they all need checking :(

How come? I think in BS4 that is true but in BS5 i thought it was a straight class rename Renamed .sr-only and .sr-only-focusable to .visually-hidden and .visually-hidden-focusable https://getbootstrap.com/docs/5.0/migration/#helpers As far as I could tell from a quick comparison that was the case too.