Must admit to never having seen this before. But following your links for adding missing values I see other values we have in our list that are not valid

actually its just prefetch that isdwrong. The others that I thought were invalid are non standard values created by google and should be included

Must admit to never having seen this before. But following your links for adding missing values I see other values we have in our list that are not valid

actually its just prefetch that isdwrong. The others that I thought were invalid are non standard values created by google and should be included

Yes, I saw prefetch too (which doesn't actually do anything when it's on an <a> tag) but not sure if we can straight up remove it without breaking b/c.

Rebase on 5.0.

Rebase on 5.0.

Can I ask why? It's not a massive change or backwards compatibility break unless I've missed something. Really very minor change, there are bigger ones going into 4.3.

Rebase on 5.0.

Can I ask why? It's not a massive change or backwards compatibility break unless I've missed something. Really very minor change, there are bigger ones going into 4.3.

You missed the part where you had to make amends in the login module for it not to crash. Extension developers must not be required to make changes in patch and minor versions. But you're right in that many more breaking changes have been introduced lately. It's almost as if the project does not follow SemVer anymore and screwing over Joomla users is the norm. So it's fine, another B/C break that bricks sites in a patch release is fine ?.

Snark is unnecessary, it was a genuine question. Please be kind.

I didn't make any changes to the login module.

I made a very minor change to the menu module helper, which still works with data saved prior to this change. (Hence my test case 1.)

Probably I could do it more elegantly as evidenced by the review comments, but I genuinely don't see how this is a breaking change when there is a check for the data type and it can handle both ways.

Okay, so, I understand better now how the changes I suggested are a b/c break.

Is there a way to approach this that would allow multiple rel values without the b/c break? Earlier in the process maybe, so that it gets turned to a string before any 3rd party component or plugin or template would call them?

I thought the menu helper would be early enough, but I understand some people may bypass it.

Copied from #39275 on request

ReLater:
In terms of maintenance and usability in other extensions, wouldn't it be better to introduce a new form field in Joomla? RelAttributesField.php or something?

crystalenka:
And do what with the input/data/current field? Wouldn't that be a bigger b/c break?

ReLater:
the idea is instead of using

<field
 name="menu-anchor_rel"
 type="list"
 label="COM_MENUS_ITEM_FIELD_ANCHOR_REL_LABEL"
 default=""
 validate="options"
>

to use

<field
 name="menu-anchor_rel"
 type="RelAttributes"
 label="COM_MENUS_ITEM_FIELD_ANCHOR_REL_LABEL"
 default=""
 validate="options"/>

You would have a single location to change/add/(remove) new options.

RelAttributesField.php could be a form field that extends ListField and thus would inherit all attributes of list field and behavior (multiple, layout etc.).

Concerning B\C break: I have absolutely no idea if that is one. The idea with a new field.

Was just an idea because I saw that you was correcting the options in 2 files.

This pull request has been automatically rebased to 5.0-dev.

This pull request has been automatically rebased to 5.1-dev.

This pull request has been automatically rebased to 5.2-dev.

This pull request has been automatically rebased to 5.3-dev.