@richard67 please have a look here.

The masonry layout breaks articles in two if it fits the column layout.

I am assuming this is referring to article 4 in the screenshot for cassiopeia vertical ?

I agree that the scss implies the intention was to prevent the column break. If you are saying it doesn't work then wont simply fixing it prevent the need for any extra classes

I am assuming this is referring to article 4 in the screenshot for cassiopeia vertical ?

Yes, exactly.

I agree that the scss implies the intention was to prevent the column break. If you are saying it doesn't work then wont simply fixing it prevent the need for any extra classes

I guess so. Maybe @ciar4n or somebody who is more involved with the Cassiopeia template can tell whether the current behaviour is intended or not? I don't want to break anything just because I assume it's a bug.

Are you using firefox?

Are you using firefox?

Ohh. Yes I am. And in Chromium, the breaking is indeed avoided. Good point!

So this seems to be some weird Firefox thing that it doesn't respect break-inside: avoid for elements that have a display: flex. Too tired now, but I'll do some research tomorrow if this is a known bug or behaviour.

It is a known bug which is why I asked ;)

See https://www.smashingmagazine.com/2019/02/css-fragmentation/

It is a known bug which is why I asked ;)

See https://www.smashingmagazine.com/2019/02/css-fragmentation/

Hmm, if I'm not missing anything, that article says that Firefox has issues with break-avoid: column, break-after and many other things. But that it should support break-inside: avoid / page-break-inside: avoid, which we are using here.
I filed a bug for Firefox, because I couldn't find any information on this behaviour: https://bugzilla.mozilla.org/show_bug.cgi?id=1680720
So for the moment, I'd treat this as a separate browser issue that we might need to keep in mind, but don't need to fix with this PR.

For the "categories" view, I now chose the simplest option, that is, adding the "blog class leading" and "blog class" field to the "Blog Layout" tab of this view.
One question I'm asking myself right now: We have these two fields which include the "useglobal" flag, but we don't have a global option to set the blog class for intro or leading articles. Should we add this to the config of com_content? If we don't, this PR is going to replace global options for the number of columns or the order with local options, i.e. a class specified in the respective menu item.

Looks really good. It resolves the migration problem in an elegant way without needs for extra params in J4.

About the categories view:
I don't remember that categories are displayed in columns in j3 and think that these params in j3 were not used at all and can be ignored.

About the categories view:
I don't remember that categories are displayed in columns in j3 and think that these params in j3 were not used at all and can be ignored.

Checking something on a 3.10-0-alpha4-dev:

a) Articles Options Blog/Featured Layouts > Multi Column Order: down or across.

b) Menu Item Typ: Category List > Choose a Category > there are no columns.

c) Here I'm not sure:
Menu Item Typ: Featured Articles > Show all featured articles from one or multiple categories in a single or multi column layout.
But it's the same as a)

About the categories view:
I don't remember that categories are displayed in columns in j3 and think that these params in j3 were not used at all and can be ignored.

No, they are used indeed. I'm going to update the test instructions with this.
If you have a "List all categories" view, you can choose how a single of these categories should be displayed when you click on one of them (given that the category doesn't have its own menu item). Quoting the hint on that parameter tab:

These options are also used when you select one of the category links, on the first page and/or thereafter, unless they are changed for a specific menu item.

This includes the columns parameters. So if you select to display two columns there, this does not apply directly to the "List all categories" view, but to category views accessible from there.

@ChristineWk This PR treats cases a) and c) (plus d) the menu item type "List all categories", as explained above).

b) Menu Item Typ: Category List > Choose a Category > there are no columns.

Correct, the category list doesn't include columns and thus, needs no changes here.

Where are you getting masonry from? in bs4 its card-columns. https://getbootstrap.com/docs/4.5/components/card/#card-columns

At the moment it is bootstrap4. I would prefer a pure css solution, but this not necessary in scope of this pr

Where are you getting masonry from? in bs4 its card-columns. https://getbootstrap.com/docs/4.5/components/card/#card-columns

Masonry classes were introduced in #18319. But yes, card-columns might be an alternative.

I have done the various steps from J! 3.10, but then didn't apply the PR and upgraded to J! 4-dev with Joomla! Update.
After the update I have this screen.

The content has remained the same. About the modules you have to reposition them, but it's part of the upgrade steps J3->J4.

With PR enabled, I can't find the "Number of Columns" and "Order of Multiple Columns" parameters in "Blog Layout".
Screan:

Is npm necessary?

I have done the various steps from J! 3.10, but then didn't apply the PR and upgraded to J! 4-dev with Joomla! Update.
After the update I have this screen.

(?) #28465
#31561

Thank you for testing!

After the update I have this screen.

That's a known issue, see comment by @ChristineWk. Not sure if it's fixed by #31561, but we can ignore it for this PR.

In order to update based on this PR here, you need to use a custom update package. I added some details to the testing instructions. If it's not clear what to do, feel free to ask! :-)

With PR enabled, I can't find the "Number of Columns" and "Order of Multiple Columns" parameters in "Blog Layout".

This PR does not re-introduce the parameters, because in #18319, the choice was made to remove these parameters and use CSS classes instead. This PR adds a step to the update to 4.0 (which is why you need to use the update package of this PR instead of applying the PR after the update). There, the parameters from J3 are converted to the according CSS classes for J4.
So after you updated with an update package from this PR, the field "Blog Class" in your screenshot should contain something, and in frontend, the layout should look similar to that from J3.

Is npm necessary?

No, not for this PR.

• Reset del sito, base 3.9.24-dev
• Upgrade to 3.10
• Create 4 articles in a category
• Create a Blog category
• Upgrade to 4 from URL custom of PR

The position of the items remains and is correct.

Blog Layout of the BackEnd is this

I did not understand how you act on the parameters "Number of Columns" and "Multi-Column Order".

Sorry

The parameter Blog Class works.

I have tested this item ✅ successfully on 905d509

With a prev steps, the par Blog Class works. :)

I have tested this item ✅ successfully on 905d509

@Harmageddon Could you please wait with merging, as I'm trying to start the update from J 3.10.0.alpha4-dev to J 4.0.0 (with the update package) Thks. I hope it will work :-)

a) Update was successful:

::

b) Your site has been updated. Your Joomla version is now ‎4.0.0-beta6-dev+pr.31570

c) but: It's broken.
An error has occurred.
0 Call to undefined method Joomla\CMS\Application\AdministratorApplication::isAdmin()

Then I made some checks etc:

There are tables not up to date! > Then Repair button > Update Structure > OK now.

Then I checked via "System" > Templates
Administrator: Atum
Site: Cassiopeia and Protostar (Copy)

Maintenance: Global Check in of:
categories_table
extensions_table
modules_table
Result: 219 items check in.

Templates Style: Changed Cassiopeia to default.

System Dashboard = OK
Home Dashboard = Broken (see above response).
Frontend: No Cassiopeia

Update from my experiment :-)

• Home Dashboard was broken (see response previous comment)
  Solution: 1 Plugin I had to remove. In addition: Some JCE Plugins.

• Frontend: No Cassiopea, even it was set under Style to cassiopea as default.
  Solution: I had to change it on each menu separately. Reason: It was a copy of previous Protostar.

Module: Main Menu (Top Menu) changed from position-1 to: menu!

I had created (previous Joomla 3.10) 2 menus as featured (top menu), 2 menus (bottom menu) as blog & 1 menu List all Categories.

Joomla 4.0.0 now: as above: looks OK. I also tried 1 menu with: masonry-2 > it works.

About the Open Points: My suggestion

1. Adding both input fields into the categories layout is correct.
2. We add these classes to config.xml
3. Question is, which class to use during migration for a vertical "down" ordering. A class "column-x" means that the articles appear "across".

• masonry-x (bootstrap v4) means ordering "down" but has some disadvantages
• card-column is the correct and newer implementation for masonry but does not say how many columns.
• something other like columns-down-x or card-columns-x

I think that users would understand best the masonry-x. Otherwise we must explain our own class. We can use this now as is or override the whole in our scss / layouts.

Would be nice to have mor meanings about that.

As this PR here is still in draft status, and the alternative PR #30910 has been closed, should the issue #27478 be re-opened and the newer duplicate issue #31801 by the same author be closed? Or vice versa?

@Harmageddon Any plans about when you will mark the PR as ready for review?

@richard67
My personal opinion is: #27478 should not be re-openend and #31801 should be closed, as both refers to this Draft.

@Harmageddon Any plans about when you will mark the PR as ready for review?

I planned to allow for a discussion here regarding the open points (global parameter for Blog Class and the things @chmst pointed out). But if everyone implicitly agrees in silence, I'm going to add the global parameter, resolve the review above, and mark it as ready for review in the next few days. ;-)

@Harmageddon yes, please do so. I will be happy to test it and think that it is the best solution we can get.

I added the global parameters for the blog class fields, along with a table in the testing instructions above that indicates which setting should lead to which result.
There is one inconsistency that I found (see last row of the table): If in J3, we set the global number of columns to 2, and the local number of columns for one menu item to 1, the update script now uses "columns-2"/"masonry-2" as the global option, but leaves the local class field empty, as one column would be equivalent to not adding any CSS class. However, if this field is empty, the global value of "columns-2"/"masonry-2" is used.
The only solution I see right now would be to use some nonsense class like "columns-1" in the case of a menu item having only one column specified. Does this make sense?

I added the global parameters for the blog class fields, along with a table in the testing instructions above that indicates which setting should lead to which result.

Thats works. Thank you!

The only solution I see right now would be to use some nonsense class like "columns-1" in the case of a menu item having only one column specified. Does this make sense?

Hmm. Tested something:

Menus Edit Item: Blog Layout it shows:
Use Global masonry-2 (per default)

a) if you want to delete the: masonry-2. It‘s (was) not possible, it will be changed to: "Use Global (masonry-2)" and becomes inactive.

b) To change that menu to 1 column, you have to enter (overwrite) with e.g: column-1. Thats works.

All other menus remains unchanged (= still showing e.g. masonry-2 Layout) = OK.

@Harmageddon Could you remove the sentence about draft status at the beginning of the testing instructions? Thanks in advance.

@richard67 Oh, sorry. Done! Thank you for the reminder. :-)

I have tested this item ✅ successfully on ef54688

All columns parameters I had set up in J 3.10 were modified in the corresponding class (columns-x or masonry-x) after update to J4

Thanks @drmenzelit for testing.

In principle, the test was also successful for me, but I waited for a comment, because of the topic of column-1, as written above. Ev. to enter manually: column-1 (if desired) was just a suggestion & shouldn't be a problem.

@ChristineWk sorry, I missed your comment...

a) if you want to delete the: masonry-2. It‘s (was) not possible, it will be changed to: "Use Global (masonry-2)" and becomes inactive.

b) To change that menu to 1 column, you have to enter (overwrite) with e.g: column-1. Thats works.

a) That is the same behaviour as in columns parameters in J3, if you don't set a specific number of columns in the menu item, the global configuration will be taken
b) Related to a), I think it is ok to have to change manually to columns-1 if you want to have 1 column ( you have to do the same in J3)

Thanks Viviana for your clarification/help

b) Related to a), I think it is ok to have to change manually to columns-1 if you want to have 1 column ( you have to do the same in J3)

That's what I meant.

I have tested this item ✅ successfully on ef54688

RTC

@ChristineWk @drmenzelit Thank you for testing! :-)
I think I agree with you: People who want this very specific setting of having two columns globally, and one column for a single menu item just have to use the workaround with "column-1", or need to remove the global class and set the "column-2" locally. This should be okay, if we document the available classes somewhere.

This makes sense to me. Nice job - thanks!