Drone failure is unerlated. See #21863

I have tested this item ✅ successfully on 5f7ef5d

Test:

• Contacts, Categories, Options
• Newsfeeds, Categories, Options
• Modules
• Tags

  ---

  _{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/21862.}

Is this a change where all 3rd party extension devs needs to follow? If yes, then we need to add the "Documentation required" label.

Is this a change where all 3rd party extension devs needs to follow? If yes, then we need to add the "Documentation required" label.

There were and will certainly still added in the WIP new admin template so many changes that I have no idea what will be finally required when we get to a real alpha. the custom-select is already in core for quite afew other stuff.

Will add the info nevertheless.

I have tested this item ✅ successfully on 5f7ef5d

Ready to Commit after two successful tests.

I'v added the documentation required label as on a first glance it looks like a change where extension devs need to follow.

Ahh, more tight couplings to Bootstrap. Great ?

At least,
the hard coding of this class inside the helper method rendering the field was removed
which was really problematic for anyone wanting to use something else

(same in J3, such class is not hard-coded in J3 (helper method) either)

Ahh, more tight couplings to Bootstrap. Great ?

You know, not every CSS class that Bootstrap uses/offers has to inherently mean "coupled to Bootstrap". Otherwise, you could never use generic class names like "alert", "row", "tab", etc.

(Not to say this PR is necessarily "right", I'd rather the class attribute in the XML forms define things unique to that field versus defining a framework integration as is the case here; the framework integration part should be left to the template to decide but the odds of us having the core form fields be framework agnostic and maintaining a set of Bootstrap designed layouts is going to be slim to none)

Every class in joomla should be written in Esperanto and then reversed to ensure it has no resemblance to the name of any other class used by anything

Problem solved

Ship <div class="_14f3 _14f5 _5pbw _5vra">What the!?</div> and have fun decoding it ?

So how am I supposed to change that class in the XML to fit my needs?
Isn't this a hardcoded situation that core doesn't even provide a way to override (unless if you write a plugin)?

But I guess I'm in the wrong ship here as it seems that bootstrap is a blessing for this project...

Isn't this a hardcoded situation that core doesn't even provide a way to override (unless if you write a plugin)?

Got any other ideas on integration points for manipulating forms then? Also, plugin manipulation actually only works for stuff going through MVC, JForm is blissfully unaware of the event system (this could be a good or bad thing depending on your perspective).

If you really want to create your own admin customisations I don't see why you can't create a class in your own template with that name?

@brianteeman and you're so right once again:

and you can't customise that class in your css because of?

Would it not be better to do this in the layout, rather than XML files?

Maybe I am getting this completely wrong but whatever framework or custom CSS you are using you need a class name to target in the markup

So I just don't get the problem with having a name used in bootstrap (or any other framework). If your not using bootstrap then you will need to create your own markup anyway

That is unless you really expect to be able to write 100% generic class names that will work out of the box in any framework

@brianteeman I personally couldn't care less what framework people use. It's more a matter of just having the default as art of the layout, so that extension developers don't need to remember to add the custom-select class to their XML files, should they wish to following the same styling.. It will already be done for them. Just my 2 pence anyway

So we need to remove all references to class="switcher" etc ???

@brianteeman No. The switcher still uses the radio form field.

type="radio"
class="switcher"

Exactly the same as with this pr

Or to stick to your example of the radio form field

type="radio"
class="btn-group btn-group-yesno"

type="radio"
class="btn-group btn-group-rotate"

type="radio"
class="btn-group btn-group-reverse"