Make relevance the default sort

Copied from slack thread: https://drupal.slack.com/archives/C01UHB4QG12/p1729069688461429

@Utkarsh_33 - @fjgarlin while working on https://www.drupal.org/project/project_browser/issues/3475056 issue on which the testCategoryFiltering test is failing I came accross an issue with the json API. The api does not return any data (for the test environment) as we have changed the default sort to best_match instead of usage_total. What is the best way to fix this issue?

@fjgarlin - well, the test is never hitting the jsonapi endpoint (by design), so maybe the issue is with the fixtures
https://git.drupalcode.org/project/project_browser/-/blob/2.0.x/tests/mo...

Checking that file, these are all the fixtures sorts that were generated:

sort=-active_installs_total
sort=title
sort=-title
sort=-created

There are 50 queries in that file, and only 3 have no sort specified, which is what best_match is supposed to be.

So, there are actually two things to do in here:
- Change the queries for whatever is queried by PB
- Regenerate the fixture files based on those queries

(slack message was until here)
--

We didn't write any way to re-generate the fixtures as this is something that we've barely need, but it's relatively easy. You can create a PHP file with the same info as $path_to_fixture in the linked file above. The key of the array is the query to run against https://www.drupal.org/jsonapi + $key, and the value is the name of the file where to dump the contents, so tests/fixtures/drupalorg_jsonapi/ + $value

Untested code:

// This script is in the root of PB.
$path_to_fixture = [
   "/index/project_modules/filter...super-long-query..." => "1.json",
   "/index/project_modules/filter...super-long-query2..." => "2.json"
];
foreach ($path_to_fixture as $jsonapi_path => $fixture_file_name) {
   sleep(1); // Wait between requests as otherwise they could be blocked.
   $contents = file_get_contents("https://www.drupal.org/jsonapi" . $jsonapi_path);
   if ($contents) {
      file_put_contents("tests/fixtures/drupalorg_jsonapi/" + $fixture_file_name, $contents);
   }
}

I also mentioned this in the MR, but if we want to only change the sortOptions for the DrupalorgJsonApi plugin, we should only change the method there, and not in the base plugin, as that would affect every plugin, where those other sort options might make sense.

I could help with this and build some tooling to make it easier in the future but I won’t be able to get to it in a few days/weeks.

That should be ok since the change is kind of tied to the improvements needed in the endpoint (which I’ll be doing 😅).

But if anyone wants to give it a go I’m happy to review.

Fixture regenerated, added some comments in DrupalOrgClientMiddleware so understand api requests. Moving it to NR.

I just added some tiny feedback on the MR about a file that might not be related to these changes but it's here. Also, the MR has conflicts, so it might need a rebase.

Last but not least, it'd be great to add some documentation about the fixture regeneration, either in the readme file or somewhere else, so when we need to do it again in the future we don't need to be going back in the git history or old issues.

Setting back to "Needs work" based on all the above.

Working on the suggested changes.

Worked upon the Readme.md and deleted unnecessary files.

The MR still shows conflicts (part of the feedback given on #10) and it's not mergable. It might need a rebase.

The readme additions don't seem to reflect what needs to be done to regenerate the fixtures. I think it might make more sense to revert those changes and give @NarendraR a clean slate to document what he did, as "creating/editing massive json files" is definitely not the way to do this.

Apologies for the confusion. I'll just revert the changes to ensure it doesn't interrupt your work.

No worries. Thanks for reverting.

I tried to explain the fixture generation process in https://git.drupalcode.org/project/project_browser/-/merge_requests/576/diffs#2c53c9f585a22c6bde4e9c11f8b48e8534303873_33_33

I think we should have something in the readme file about the steps you followed to regenerate the fixtures. Did you do it manually? Did you script it? If you script it, which script did you use? This is something that might be needed in the future, and the process should be relatively issue, without going via git history / issue comments.

I moved the mapping of query => file to a class constant so it can easily be reused, and I created a helper script to regenerate the fixtures based on my comment in #5.

I also documented how to use the script in the readme file.

A new fixture file is introduced in #3485386: Do not hardcode UUIDs in DrupalJsonApi plugin. If that issue is merged first, we will need to update the fixture generating script in here (as I coded to avoid conflicts with other issues).

If this one gets merged first, I'll take care of the rest on the other issue.