Just an addition as an pro argument for this pr: Bootstrap 5, yet in alpha state, has removed the column-count classes. I think there are reasons why they did that ;-)

Similar PRs #29398, #28790

Display issue when editing an image.

Display issue when editing an image.

That is a caused by mediamanager.scss

#media-form .control-group {
  display: inline-flex;
  flex-direction: column
}

if you disable that, it works correct.
Who is the developer for this css and can tell me why it is there in the first place (without this css all seems to work fine even when three or two colums)

IMO css should override html and we should not be changing html to override css

@Quy is this the only issue that you found or are there other components / config / layouts etc. causing issues?

Just an addition as an pro argument for this pr: Bootstrap 5, yet in alpha state, has removed the column-count classes. I think there are reasons why they did that ;-)

Agree, it looks great but is unworkable.
Can you test and report issues when you find them using this PR?

@Quy could you retest, I just did a change to the media manager scss file, now also needs some npm voodoo magic to generate the media/com_media/css/mediamanager.min.css file

Under Articles, Configure Edit Screen tab should also be changed for consistency.

Under Articles, Configure Edit Screen tab should also be changed for consistency.

@Quy Good catch, just removed it. now there are no more column-count classes :)
Let's see if we can get this tested and approved, would close a lot of long standing issues / discussions #fingerscrossed

Looks good. On smaller screens there is s horizontal scrollbar. Is it possible to show the fields in a column on small screens?

thanks for testing and your feedback @chmst what you are pointing to is due to another bug that is not addressed by this PR. That is due to subforms not being responsive (#29241 )

I have tested this item ✅ successfully on 619fbd7

Thanks @Quy for testing! Highly appreciated

I have tested this item ✅ successfully on 619fbd7

RTC

Thanks for testing @richard67

@Ruud68 Thanks for the PR ?

just noticed that beta2 was released, but this PR was not part of it? may I ask why not?

Because I want to sit down and deep dive this more. This view affects way more than just plugins - it’s shared between many components and with the hassle of releases i didn’t have time to fully test

Because I want to sit down and deep dive this more. This view affects way more than just plugins - it’s shared between many components and with the hassle of releases i didn’t have time to fully test

A okay, that explains it :)
You are right, it affects more then just plugins. All views that use this layout have been tested and there where only issues with com_media (which have been fixed in the PR). com_media should in my opinion not use this layout because it feels like abusing a parameters layout for something else then parameters. That said: it impacts the way the layout looks so also for the other views, and although none break (technically) the current column layout really (!) breaks plugins. And that is where we do not have control over as these are done by external developers. As an extension developer alternative is to use your own interface to plugins, or overwrite things with javascript and css but that defies imo the whole point of using the platform to its fullest.
If you needs a live example of why the current implementation is not working for plugins and why we need this pr, please dm me :)
If you needs anything else to test etc. please let me know.

@Ruud68 has a good point ;)
i have my own template with a complete bootstrap compiler and therefor lots and lots of paramters in several tabs and the current implementation is just a mess.
especially with repeatable table fields, they are all over the place.
i strongly hope this PR gets implemented! i have updated my beta 1 with this PR and it's way better than before ;)

Just pinging @wilsonge here to see if there is anything I can do to get this PR accepted.
Maybe an idea to tag the people you feel confident about okaying this PR to get some stuff of your plate.
I feel that this is not only holding this PR back, but also my 'motivation' to try to contribute, I would really hate it to go the route @regularlabs is going here: #25891 (comment) that would be a total waste of extension developers their time IMO...

its realy important to find a solution i try to migrate some dev and same problem colum in backend aren't good in may case like use repateable field completly broken

My customers are testing my extensions on J4 and are reporting this exact thing being unworkable raising an issue that it should be fixed. This should be fixed in core (with this PR or in a different way), or every dev will fix it in their own extensions overwriting core functionality.
I have done the PR, I have tested extensively and so did others, it is status RTC but I have no clue as to why this is being ignored / held back.
If we wait long enough, this PR cannot be implemented anymore as people are starting to work around it and it will be a B/C break.
I really don't get it: every time I see calls for action "please help us test en fix", this is very frustrating and holding me personally back from doing PR's for J4.
So here is my call for action: accept this PR as is, comment as to what needs changing, or decline. Just DO NOT ignore!

Please fix the conflicts

@brianteeman I am a volunteer too and can only spent my time once. When submitting there was no conflict, but I understand things change. This will take a lot of time to get my dev environment for j4 setup again, make the changes again, run all (and there are a lot) tests. All with the risk of wasting this time (again) because the PR will not get merged or will get merged but it will take a lot of time where there are due other conflicts.
So (again): will this PR get merged when conflicts are resolved?

Not trying to be a $&%& about this, but as said frustration grows with every call for action on social media to help J4 forward by testing and doing PR's...

I've allowed myself to fix the conflicts.

The conflict was in file layouts/joomla/edit/params.php due to meanwhile merged PR #30450 .

It needs to test this PR again, and check if with this PR the change from PR #30450 still looks good.

@richard67 Thanks you very much, I limit myself (to avoid getting sucked in) to two open PR's. Normally they get accepted and i can work on another one and by doing that keeping my J4 dev environment current. but now I have been 'on hold' for months because of no action on my PR's so that results in not working actively on J4 anymore and thus a 'stale' dev environment. very inefficient. Just speaking my mind in case 'leadership' wonders why calling out for help is not always successful :S

@Ruud68 I can understand your frustration. Unfortunately I can't do much to help against it right. Due to private reasons I'm currently very limited with time and energy. But I will try to find time for testing your PR again. I hope that we come forward with this PR in the one or other way, and please don't give up contributing in case it will not be accepted for some reason which I can't see right now.

i don't understand why there's noone of the core team assigned to this to keep an eye on it since this is crucial for extension developers and therefor for the whole community!

ok i've now assigned this task to the attention of the RL peoples
let's see what happens
in the meantime this pr needs 2 testers

Back to pending.

I have tested this item ✅ successfully on f9f51c2

I have tested this item ✅ successfully on f9f51c2

The PR does what it claims to do and solves all issues with multi-column layout by using single-column.

If that's the way to go or not I can't decide.

RTC

@wilsonge How can I help getting this PR merged? It tested okay (multiple times), it is being requested (multiple times) and it fixes a 'broken' UX. Where is the doubt, what needs to be clarified?

Every day we wait will make it 'harder' to implement as this is a UX change: without this change I cannot move forward with making my extension J4 compatible (without adding JS to the configuration screen that will remove these classes when found in the DOM, a step i am currently not willing to do)

Maybe just merge it and see if (legit) 'issues' arise? we can always revert...

developers log entry # 15, git date October 8th, 2020: "another two weeks passed without any sign of Leadership stepping in and making decisions. I'm worried that all time invested in J4 will go to waste and with this pace it will never never reach RC status. Wondering what I could have done code wise instead of following up on status, a well... we will never know" #startrek

developers log entry #15, git date October 8th, 2020: "another two weeks passed without any sign of Leadership stepping in and making decisions. I'm worried that all time invested in J4 will go to waste and with this pace it will never never reach RC status. Wondering what I could have done code wise instead of following up status, a well... we will never know" #startrek

And you think that's better? Maybe finding a way to make this layout control able so that you can decide when you want to have full width buttons or columns would be a nicer.

@HLeithner Nobody said the field inputs should have a forced width of 100%... Joomla 3 sure didn't... Don't fix it if it's not broken.

Not sure if it's much better in j3

@HLeithner thank you for your response. Now this is something we can work with (instead of the silent treatment that leads nowhere). As @AndySDH said, the field width can have a different size opposed to the current (defaulting to) full width.
The main issue to solve here is the impossible UX where settings 'bounce´ over the screen due to the three column layout. When we have consensus that this is unwanted and we can go back to one column, then it is a matter of styling to set the width of that one column.
If that change will make this PR get merged, then I will of course make that change. But looking at the history of this PR (the non-history actually) I will not put in any more time, just for it to ignored again. Hope you understand :S

Exactly. It's very easy to set a default width for the input fields.

But the important thing is going to 1-column layout.

@HLeithner Somehow that was better. At least there, the two columns are split in vertical order, and not horizontally, meaning that at least settings that are meant to be together are not split around.

@AndySDH
if I look at the publishing tab it looks like a decision of the developer how to design the layout:

looks the same with and without the patch. Of course these fields are grouped.

I have a complete different idea of having a simple "formbuilder" based on xml attributes override able in the layout but not sure if this is the correct place to talk about. Except if someone want's to help me to integrate such a solution or at least talk about it.

This is the main issue that my testers are asking me to fix (and I can fix by adding JavaScript to my extensions removing classes etc. but that will not solve the issue).
In the screenshot I am toggling a button where the button and the fields associated jump from column to column making the user scroll up and down...

idea:
introduce a new form element <column></column> ;)
so the markup would be
<fieldset>
<column>
<field />
</column>
</fieldset>
and then add the respective class with a count($columns)

maybe?

This is the main issue that my testers are asking me to fix (and I can fix by adding JavaScript to my extensions removing classes etc. but that will not solve the issue).
In the screenshot I am toggling a button where the button and the fields associated jump from column to column making the user scroll up and down...

Splitting the fields into more fieldsets would solve this or?

This is the main issue that my testers are asking me to fix (and I can fix by adding JavaScript to my extensions removing classes etc. but that will not solve the issue).
In the screenshot I am toggling a button where the button and the fields associated jump from column to column making the user scroll up and down...

Splitting the fields into more fieldsets would solve this or?

nope, i tried this as well ;)
it still depends on the viewport/screenresolution of the user how they'll get aligned ;)
the only way to solve this is by the class

It is important (for me?) that any change will not break J3 compatibility, if it does then you cannot use the same XML and end up developing and maintaining two versions (one for J3 and one for J4)

It is important (for me?) that any change will not break J3 compatibility, if it does then you cannot use the same XML and end up developing and maintaining two versions (one for J3 and one for J4)

didn't thought about that
then maybe just add a paramter column="" to the fieldset (define total count of columns) and/or field (define in which column this field goes) ;)
it should be ignored by J3

Yes but that is an extra feature. That can be added later after this PR.

This PR is only meant to fix the CSS of forcing random columns via CSS.

Let's get this merged first.

Unsubscribing from this... back to discussion mode! ?‍♂️

I have tested this item ✅ successfully on f9f51c2

I'm sorry I've allowed this to sink into the pile for so long. I do understand there's a genuine issue that needs to be solved here (that's why I haven't closed it).

I just don't want to make all the other components look worse either - because in my opinion this was a definite UX improvement for larger screen sizes too.

I'm happy with the proposed XML attribute proposed that could disable the column grouping. At least for plugins and modules this would seem fairly logical - in general component layouts where you have control of the HTML output I guess it matters less (although as it would sit in the JLayout I guess components will be able to use it too).

On PBF, so what is the solution for this moving forwards? I can test it but it seems like we need a clearly defined testing process to test certain layouts and views. If you can tell me which ones I can test them.

For the record, I agree with @HLeithner that 100% width for inputs doesn't look great. It is not good for accessibility or usability so that is worth considering.

But its important to find solution because this display broke subfield display

Knock knock anyone there

Knock knock knocked-out.... :S

As far as I am concerned, this PR has been declined by @wilsonge in favor of a different (to be developed) PR. Will close this one.
I do not have the time / energy / joy to do that proposed PR. When there is a new PR I am able to test.

Wow. Well, closing this does nothing good if not make people forget about this even more

I won't forget :) I get reminded every time I use J4. It is far easier to 'abandon' the J platform route and do a JS override from the extension / plugin.

yeah.. and the fact that Subfields are pretty much unusable: #28340

The question is if there is still an open issue for it, and if not, which of the issues referred to in the desciption should be re-opened, if not all.

@richard67 This was the only issue left opened about this subject, all the others were closed pointing to this one lol

So fresh wind here: What if:

• The columns will been used when a dev groups its fields additionaly by fieldsets:
  < fieldset name="myTab">
  < fieldset name="basics">
  < field>< /field>
  < /fieldset>
  < fieldset name="borders">
  < field>< /field>
  < /fieldset>
  < /fieldset>

And when no fieldsets are used INSIDE the main fieldset the columns are limited to one column...
every additional fieldset (level 3 and after) should be ignored by this changes

This solution could have this benefits:

• the dev can define if she / he likes to use columns
• columns count would / could still be possible to define if another PR will be created to define the columns
• both sides got what they want to have (multiple columns and single column)
• "Jumping issue" for hidden and later visible fields are not solved in general, yes but it will not happen anymore with this structure
• you have nothing to change for existing J3 extensions XML to migrate

In my test it was necessary to put div's arround the fieldsets to have a nice looking GUI

In my test the generated HTML would need to look like this:
https://ibb.co/PWhx0V7
https://ibb.co/6Yw0Pjx

Things ToDo for this:

• Check in Form Renderer for fieldsets in main fieldsets
  -- Add the column classes as already been done in the actual release & wrap fieldset element inside a div
  -- Otherwise add column class for 1 column (because there are only fields and all of you are happy)
• Small CSS changes (add rule to remove display inline block for sub sub fieldsets
  -- gets actually broken by [class^="column-"] > div, [class*=" column-"] > div {
  /* display: inline-flex; ... } in template.css on 10062 (Beta 5) (disable in console while live testing and it worked like a charm)

And yes a small note inside the J4 docs would also be necessary to understand the logic and as i can see it should be backwards compatible too.

I'm sorry but i have no clue how to create build that for you to testing - but the GUI changes can be simulated by changing the HTML directly in the browser. What do you guys think?