Facets summary: facet order ignored

I see the same. The cause of the problem seems to be that \Drupal\facets_summary\FacetsSummaryManager\DefaultFacetsSummaryManager::build has the correct order available in $facets_config, but instead of looping over that, it iterates over the unordered $facets to build the output. This could be solved by ordering $facets by the keys of $facets_config like this:

    $order = array_keys($facets_config);
    $facets = array_replace(array_flip($order), $facets);

But I think that's not all. While this seems to work correctly for the "reset_facets" summary processor, I noticed that \Drupal\facets_summary\Plugin\facets_summary\processor\ShowSummaryProcessor::build uses array_unshift to add the items to an array. So that suggests that the order would still be reversed. I hope this helps someone get started with a proper issue fork or patch.

Also, needs tests.

I followed what @marcvangend did, and it worked for me. I created the fork/MR to get something started. There will need to be tests (like what marcvangend mentioned).

Hopefully this will help others review this. Thanks.

I added the tests and adjusted a bit the method used to order the facet summary (instead of relying on the configuration, the `#weight` is checked).

The same tests that fail on the dev version of the module are failing here so the new tests are passing 🥳

This is ready to be reviewed.

Thanks, @Grimreaper and @nmillin for the initial work.

(I created two more branches by accident lol, I'm still learning how to use gitlab instead of relying on patches, apologies for that 😅)

I just realized that relying on the patch generated by the merge request might not be best idea given that if it is updated the Merge Request the patch will be updated, so here a static version of the patch.

Patch from #8 still works on 2.0.7 and fixes the issue for us.

Looks great, thanks all.