Doesnt this need to be based on 4.1-dev and not 4.0-dev ?

Doesnt this need to be based on 4.1-dev and not 4.0-dev ?

I didn't break anything (I hope) and it's just an update of some dependency so it should be fine for 4.0.x

Im pretty sure @brianteeman said it could not go in 4.0.x somewhere.

#35182 (comment)

I also took a look the other day. It would have to be for 4.1.0 because of the breaking changes and not 4.0.1

Im pretty sure Teeman said it could not go in 4.0.x somewhere.

I thought also that it couldn't be done in a B/C way, but here we are...

If you are happy, then cool. I was just repeating what I had read elsewhere.

If you are happy, then cool. I was just repeating what I had read elsewhere.

I'm never happy when it comes to BS ?

Unrelated changes in templates/system/?

Unrelated changes in templates/system/?

These files need to be committed anyways. Check #35413 and #35098 (comment), in short, the Github actions should do that or someone needs to create a PR whenever the Github action runs...

Processing Legacy js file: template.es5.js...
Error: $color: var(--template-text-dark) is not a color.
   ╷
37 │   @return red($value), green($value), blue($value);
   │           ^^^^^^^^^^^
   ╵
  media\vendor\bootstrap\scss\_functions.scss 37:11                  to-rgb()
  media\vendor\bootstrap\scss\_variables.scss 423:13                 @import
  administrator\templates\atum copy\scss\vendor\_bootstrap.scss 6:9  @import
  administrator\templates\atum copy\scss\template.scss 11:9          @import
  administrator\templates\atum copy\scss\template-rtl.scss 1:9       root stylesheet
npm ERR! code 1
npm ERR! path C:\htdocs\joomla-cms
npm ERR! command failed
npm ERR! command C:\WINDOWS\system32\cmd.exe /d /s /c node build/build.js --prepare

atum copy

@brianteeman in your custom template (atum copy) do the following

• apply the changes in variables
• add the _root.scss in the template's scss root folder (copy from here and diff it)
• in your scss/vendor/_bootstrap.scss edit the line for the root to point in your template/scss/_root.scss

You have better eyes than me. I didnt even realise it was "atum copy". Something left over from a previous test. As its not relevant for testing this PR I deleted it and reran npm ci and it now completes. I can now test and make sure all the core templates work etc

The admin template seems to work fine and the color settings in the styles all work.
The site template seems to work fine and the font settings all work
The installation template seems to work fine.

I have tested this item ✅ successfully on 574932a

I have tested this item ✅ successfully on 574932a

Everything seems to work! Thanks!

I have tested this item ? unsuccessfully on 574932a

@dgrammatiko I noticed that the installer template now has an issue with the header color

Also the border of the dropdown is gone.

@RickR2H Nice catch, should be ok now with e2580b0

I have tested this item ✅ successfully on 076461f

@dgrammatiko Much better ?

@wilsonge you probably want to merge this for 4.0.3

4.0.3-rc1 has already been cut, surely its now too late to slip in a major css framework update before the release?

its now too late to slip in a major css framework update

It's not a major update, it's a patch and it doesn't break anything. Also provides a handful of fixes for bugs. Reminder: BS is already 2 releases behind in J4.

If this (or anything that is not a fix of something already in the RC) is merged after a Release Candidate is released, then that makes a mockery of the RC status.

But then, Joomla does that all the time /facepalm....

Never mind, I missed the RC part...

Joomla! 4.0.3 Release Candidate @wilsonge released this 32 minutes ago

We choose BS and imho falling behind is not the best way to go. We should at least keep external frameworks as updated as possible or not choose them at all. Technically it is a fix, as it is fixing BS issues.

Its not my decision thankfully.

Joomla commits to SemVer - however a release candidate is not part of the definition in SemVer it seems, apart from it being called a "pre-release" version which can have a version number appended by an identifier.

A release candidate "is a beta version with potential to be a stable product, which is ready to release unless significant bugs emerge" according to wikipedia.

The clue is in the word "candidate" - it is a "candidate" to be released as the official stable version. (Also interesting that Drupal has RC status for "at least a month" before release, and here is Joomla with 48 hours...)

But Im sure the Joomla project will just run roughshod through established software lifecycle processes and merge this before next tuesday, it has repeatedly done so in the past.

Targeting this for 4.0.4. It was too late for 4.0.3

FWIW normally release candidates are 1 week before the stable (for patch versions) - but I was massively late cutting it due to coming back from holiday and being hit with a mega backlog at work on my return.

@wilsonge copy that. I'll guess we have to hold this for a bit as 5.1.2 is ante portas https://github.com/twbs/bootstrap/projects/43

It's fine let's get this in. Bug fix versions should be a very simple npm update. I'd rather give people as much time as possible to report any potential issues with the CSS vars

@wilsonge your call

@dgrammatiko This PR has a merge conflict now in the package-lock.json file. It comes from the recently merged PR #35605 . Could you solve that and update your branch? Thanks in advance.

I will run again npm I but maybe we should add package-lock.json and composer.lock to the .gitignore and update them using an action on every PR merge (assuming there's some changes that need to be committed). My 2c for this as it keeps bothering, to put it nicely, every contributor...

Let's get this done. Adding the package-lock.json to .gitignore is a great idea. I would get built on any npm install / npm update command anyways.

Guys can we please push this in? I have a couple PRs depending on it.

@thednp it still needs 2 tests...

OK now that the conflicts have been solved, let's get to testing.

I cannot find the PR on JTracker.

I cannot find the PR on JTracker.

https://issues.joomla.org/tracker/joomla-cms/35518

Build successful on my local clone of your branch.

Should I also perform a quick install?

Should I also perform a quick install?

Yes, you need to confirm that all 3 templates (installation, front end, back end) are still good

Edit: irrelevant but what are the specs of your machine? (I'm concerned that the tools took 72 seconds to finish)

Win 10, 8 core CPU, latest XAMPP APACHE server v3.3.0.

BTW, how do you guys create those sample data plugins?

OK my test looks good, installer, admin template and front-end template, all looking good. I should confirm the test on the tracker now?

Unrelated: I couldn't install "Testing Sample Data" for some reason, there was an AJAX error.

Unrelated: I couldn't install "Testing Sample Data" for some reason, there was an AJAX error.

As you said, unrelated, but maybe it's a good idea to create an issue for that

BTW, how do you guys create those sample data plugins?

Well, the core has a different way but I have my own https://github.com/dgrammatiko/sloth-pkg/tree/main/plg_sampledata The sampledata is for the sloth template (an SPA-PWA template+, totally different thing than the usual MPA stuff people do with Joomla) https://github.com/dgrammatiko/sloth

I have tested this item ✅ successfully on dcfde0d

Tested all 3 templates and could not find irregularities.

@thednp could you mark your test as successful in the tracker so this could be finally merged?

I have tested this item ✅ successfully on dcfde0d

I have tested this item ✅ successfully on dcfde0d

RTC

RTC

@wilsonge friendly reminder ?

I'm so sorry - one last merge conflict fix?

@wilsonge done

Thanks!

https://blog.getbootstrap.com/2021/10/05/bootstrap-5-1-2/

@peteruoi well, that was expected: #35518 (comment)
The PR for updating to 5.1.2 should be fairly easy for anyone, the 5.1 was harder as there were breaking changes in the templates

EDIT: @peteruoi please test #35766