An Illegal Choice when Natural sort is exposed as an exposed filter.

I'm not able to reproduce this today. Can you try again and let me know if it's still an issue? Feel free to reopen if you can. Here's my attempt.

So I see what I did wrong... I didn't expose the sort... I think that's a more pressing issue from the "pager not working on ajax"... Going to reopen and change the title

kinda was following the symptom and got caught up in it.

I've run out of time to be able to track this one down today... but here's what I found...

In core/modules/views/src/Plugin/views/exposed_form/ExposedFormPluginBase.php, there's a function exposedFormAlter. It hard-codes the sort orders on lines 220-223 to just asc and desc. I'm not 100% sure how to get around this besides to check to see if someone chose to sort things naturally by asc or desc and then translate the asc and desc options to the proper counterpart. I think this may require some restructure from having NDESC and NASC to having a separte option that just says "Sort naturally" and check that... It does mean that likely I won't be able to allow people to expose whether to sort naturally or not... but they could at least decide if it's to be ASC or DESC and the naturally part is just on or off based on the person who configured the view.

Something like this:

Confirmed that this is still an issue.
According to comment #4, since it's an issue due to the sorting method being hardcoded in the base plugin file of exposed form, I created a workaround patch which creates a new exposed form plugin named "Views Natural Sort" and allows the options `NASC` and `NDESC` to be accepted for sorting.

@sker101,

Interesting idea. I kinda wish there was a way to "force" it to happen when someone has a naturally sorted as to remove the element of "mis-configuration".

I'll have to dig back into this one to understand the flow... But then again, I may have to just accept this gotcha without a major rewrite of the NASC/NDESC logic.

So looking at this... Is there any usecase where someone would want to be able to select between all 4 of Sort Ascending, Descending, Ascending Naturally, or Descending Naturally?

If not, I think the solution to this is to remove the option to select from the 4 different options as defined here:

Then we just add a checkmark option to that form "Sort Naturally" and go off of that. That should add a new option that we could flag on and it would then be up to the sort handler to make sure that the sorting happens naturally or not based on that instead of if there is an "N" in front of the option.

Then the exposed filter would sort natually if the option was checked or not if it was unchecked but you couldn't flip flop between the two without extra work.

@sker101,
I actually took a different approach all together from what you had in your patch to keep from having to have people go through and manually configure the exposed form filter. It's all based on the fact that we will never have 4 options in that Sort Order dropdown. In the future we might expand the exposed form to allow the new "Sort Naturally" checkbox, but for now, the exposed filter sorts Ascending or Descending either Naturally or Normally based on if the Sort Naturally checkbox is checked in the view configuration. Here's what the new form looks like

This new patch does the following:

• Refactors the sort handler to respect the Sort Naturally checkbox option
• Adds in a new class to help handle View Configuration updates going forward based on Drupal\views\ViewsConfigUpdater
• Adds a new Post Update hook to handle updating all naturally sorted
• Adds a new config schema to handle the updated options.
• Updates the test view configuration to reflect these changes.

Things I've tested...

• Unit Tests run cleanly.
• Tested the upgrade from the old configuration format and confirming it matches a view built from scratch
• Tested Exposing the form set with Asc as default and "Sort Naturally" selected validating the ordering works
• Tested Exposing the form set with Desc as default and "sort Naturally" selected validating the ordering works
• Tested Exposing the form with both options and "Sort Naturally" unselected... and validated the ordering sorts Normally instead of Naturally.
• Tested Adding Ajax and Pager to all options and moving on to the next page.

To give this a shot:

• Apply the patch
• run `drush updb -y`
• visit your existing view and validate it still works as you expect it to without the errors

@generalredneck - I applied the patch on our site and am seeing the update db fail with the following output. See attached.

Tech specs:
Drupal: v10.1.3
VNS: v2.0.0-alpha7
PHP: v8.1

FYI - Patch #5 applies okay and addresses the issue for our use case.

I couldn't apply the patch from #8 so I recreated the patch to work with the latest version of the module

Modified patch from #10 to fix PHP 8.4 deprecation warning in the definition of init().

looks like several people are using it well.

It turns out that I wrote similar functionality over in #3442536: How to safely uninstall? and the use cases overlap. That one's going to get merged though.

It's going to suck for those of you using this patch as you will have to migrate this configuration over to the new one. Someone may want to write a patch that does a configuration update from this to what is being released.

Also we will need to test again to double check this issue is fixed with what was merged.

Ok so After pushing #3442536: How to safely uninstall? this issue is fixed.