I have tested this item ✅ successfully on 6471330

Works great. Thanks, Roland.

I have tested this item ✅ successfully on 6471330

@roland-d See for changed behavior #37840

This is obviously not a correct fix. You have put a band aid on the issue that only resolves it partly.

animation removed - searching for an option to make it loop once only

@brianteeman It is the correct fix but you are also right that this is a band-aid. The real problem is two-fold.

1. Something about initialising fields which return array when you try to save empty array
2. Something about not being able to create a custom handler in plugins

I could explain more if it wasn't for that forever looping bloody animation you have put in your comment!

Please, for the love of whatever deity you believe in, DO NOT POST INLINE LOOPING GIFs IN YOUR COMMENTS! For someone who allegedly cares so much about accessibility you are being actively hostile to people with ADHD. That bloody animation is catching my attention and won't let me think.

I know exactly the problem, I have seen it myself in Admin Tools' Web Application Firewall and I could tell you exactly why it happens if you had not made this page inaccessible to me and other people with ADHD.

gif removed while I recompi;le the app - sorry

Thank you! For the GIF, you can drag'n'drop it to GitHub and after it's done change the inline image tag to a link. This way we can still see the animation, in a new window, then choose to close the window. What you were doing is not a problem on desktop — I can just make the edit area longer to hide the animation — but on mobile which forces me into the GitHub app it's frustrating. I'd normally use the accessibility option for less animation but this disables other visual cues on iOS which makes it just as much of a problem as it is a solution. Ugh.

OK, back to the issue at hand. The problem is that Joomla's form fields apply the default value when the configured value is "empty". However, PHP considers the following to be "empty": null, 0, array(), ''.

When you have a field which results in an array Joomla cannot distinguish between the uninitialised state and a deliberately saved empty array. To change that behaviour we'd have to return NULL when the option is uninitialised. However, that would be a substantial b/c break since all code written from at Joomla 1.6 onwards assumes that the uninitialised state of an array-returning form field is an empty array. That's why you typically see a no-op option (e.g. a module position "None") in these kind of multi-select form fields.

So looping back to what @roland-d did here, it's not wrong. It's the right way to do it. Yes, it's a band-aid because then way Joomla behaves makes no selection an impossibility UNLESS you have something like <option value="">No Selection</option> in the XML form and you, the user select the No Selection no-op option instead of clearing out all selections before saving the user profile.

Yeah. I know. This behaviour has been the source of many a complaint and frustrated user in Admin Tools' Configure WAF page.

That's why you typically see a no-op option (e.g. a module position "None") in these kind of multi-select form fields.

This is what I would consider to be the correct fix and why arbitrarily setting it com_content is not a fix - Especially annoying/confusing when the unselected items come back on save :(

@brianteeman I agree, on the basis that this is what is the accepted typical solution in Joomla even though it's problematic user experience (the user has to be taught that they need to make a special selection which means no selection is made instead of just removing all selected items, something that does boggle my mind every time I have to it; it's so unnatural).

I would say that you should do a PR to add this missing no-op option here.