FieldOptions with isOrderable doesn't maintain order

[NateWr]

Describe the bug
When a <FieldOptions> component has the isOrderable prop, the options can be reordered. However, when loading the field, the options are not displayed in the order they were last saved in.

The only place an orderable FieldOptions is used is Settings > Website > Appearance > Setup > Sidebar. There is a workaround on the backend to reorder the options before they are sent to the Vue component.

pkp-lib/classes/components/forms/context/PKPAppearanceSetupForm.php

Lines 53 to 71 in b8d985f

	foreach ($currentBlocks as $plugin) {
	if (isset($plugins[$plugin])) {
	$enabledOptions[] = [
	'value' => $plugin,
	'label' => htmlspecialchars($plugins[$plugin]->getDisplayName()),
	];
	}
	}
	foreach ($plugins as $pluginName => $plugin) {
	if (!in_array($pluginName, $currentBlocks)) {
	$disabledOptions[] = [
	'value' => $pluginName,
	'label' => htmlspecialchars($plugin->getDisplayName()),
	];
	}
	}
	$sidebarOptions = array_merge($enabledOptions, $disabledOptions);

To Reproduce
The easiest way to reproduce this is to remove the workaround code in PKPAppearanceSetupForm.php and then reproduce it with the sidebar setting:

1. Apply the following diff to main:

diff --git a/classes/components/forms/context/PKPAppearanceSetupForm.php b/classes/components/forms/context/PKPAppearanceSetupForm.php
index 84c05c16c7..684d037c1c 100644
--- a/classes/components/forms/context/PKPAppearanceSetupForm.php
+++ b/classes/components/forms/context/PKPAppearanceSetupForm.php
@@ -43,33 +43,18 @@ class PKPAppearanceSetupForm extends FormComponent
         $this->action = $action;
         $this->locales = $locales;
         $sidebarOptions = [];
-        $enabledOptions = [];
-        $disabledOptions = [];
 
         $currentBlocks = (array) $context->getData('sidebar');
 
         $plugins = PluginRegistry::loadCategory('blocks', true);
 
-        foreach ($currentBlocks as $plugin) {
-            if (isset($plugins[$plugin])) {
-                $enabledOptions[] = [
-                    'value' => $plugin,
-                    'label' => htmlspecialchars($plugins[$plugin]->getDisplayName()),
-                ];
-            }
-        }
-
         foreach ($plugins as $pluginName => $plugin) {
-            if (!in_array($pluginName, $currentBlocks)) {
-                $disabledOptions[] = [
-                    'value' => $pluginName,
-                    'label' => htmlspecialchars($plugin->getDisplayName()),
-                ];
-            }
+            $sidebarOptions[] = [
+                'value' => $pluginName,
+                'label' => htmlspecialchars($plugin->getDisplayName()),
+            ];
         }
 
-        $sidebarOptions = array_merge($enabledOptions, $disabledOptions);
-
         $this->addField(new FieldUploadImage('pageHeaderLogoImage', [
             'label' => __('manager.setup.logo'),
             'value' => $context->getData('pageHeaderLogoImage'),

2. Go to Settings > Website > Appearance > Setup > Sidebar.
3. Enable one of the sidebar blocks near the bottom of the list and move it to the top.
4. Save the form.
5. Reload the page.
6. See the enabled sidebar block is at the bottom again.

What application are you using?
This effects as far back as stable-3_3_0 and probably earlier.

Additional information
This bug is causing problems for me when using the field as a theme option. I tried using a similar backend workaround, but it causes serious side effects. In short, I must fetch the value of the theme option to sort the order of the options. However, once I fetch the value of the theme option, all theme options are cached. This means the resorting has to be done after all theme options are defined. I can do this, but it would break any theme options defined in a child theme.

[NateWr]

The following PR fixes the issue in FieldOptions.vue by sorting the options in the mounted hook. It also removes the workaround code from PKPAppearanceSetupForm.php.

I opened the PR against main because I'm having trouble running npm run [build | start] in my stable-3_3_0 checkout. I believe it may be a node version issue. Ideally, this would be back-ported to stable-3_3_0.

PRs:

main:
pkp/ui-library#429 (merged)
#10530 (merged)

stable-3_4_0:
pkp/ui-library#435
#10564

stable-3_3_0:
pkp/ui-library#436
#10565

---

TESTS ONLY:

main:
pkp/ojs#4475 (closed)

stable-3_4_0:
pkp/ojs#4489
pkp/omp#1739
pkp/ops#797

stable-3_3_0:
pkp/ojs#4490
pkp/omp#1740
pkp/ops#798

[NateWr]

@blesildaramirez just following up on this. It looks like maybe the PRs to main were merged but not the ones to the stable branch.