Design an API for sources to define their own filter sets

This might be a follow-up issue - for the Drupal.org source, this metadata should come from Drupal.org itself, not be hard-coded in the client code.

For example, we might merge maintenance status & development status, or their options in the future. We should be able to do that, including changing what’s rolled up into more-simplified "show maintained / show everything” filters.

This should also extend to sort orders. For example, the default sort order being only project usage could be augmented to consider other factors, like minimal maintenance being ranked lower. And other sources won’t have usage information.

Re sorting, the base plugin offers the defaults: https://git.drupalcode.org/project/project_browser/-/blob/2.0.x/src/Plug...

and these can be changed per plugin as needed: https://git.drupalcode.org/project/project_browser/-/blob/2.0.x/src/Plug...

--

Adapting what we currently have to what @phenaproxima is suggesting shouldn't be too difficult in the backend. Maybe we can just add a method in the interface that will force all plugins to implement it and return that json info for filters and sorting.

I see most of the work happening in the front-end. In fact, I'd probably start there once we agree on "the contract", and once the front-end is ready we can adapt all the plugins.

Also, even tho I mentioned the part of the sorting above, I agree that this should also be moved to be part of "the contract", so filters and sorting are all included.

I actually think sorting is fine as-is. It's inherently less complicated than filtering; how many different ways do we need to render a sort control? What could it contain except for "this the field to sort on, and this is its human-readable label"? That's already covered...

Happy with that too. Sorting is easy as it has defaults and overriding is just providing a relatively simple array.

For Drupal.org, we could always sort by “relevancy” which is

• Project usage, potentially with boosts added later for moving projects up/down based on signals that reliably show module quality
• When searching for text, the primary ranking is the text search (balanced among title/description/etc) and then usage and any other factors

Like we do on https://www.drupal.org/project/project_module → . I’m not sure we actually need any other sorting options. The point for this issue would be making sure we’re not hard-coding anything like “most installed”

We're not going to add any kind of filtering or sorting by most installed; this is strictly about defining and implementing the PHP API, and adjusting the JavaScript to match.

This is the current map for sorting: https://git.drupalcode.org/project/project_browser/-/blob/2.0.x/src/Plug...

Left key is project_browser sorting, right value is hiw it’s tranlated into the sort field for the endpoint. Note that the value is not a direct field name but an alias created in the search api index.

kunal.sachdev → made their first commit to this issue’s fork.

@phenaproxima is this still a Drupal CMS blocker now that we are using a standalone browser?

I'm not sure this should ever have been a Drupal CMS stable blocker, honestly. It should probably block a beta of Project Browser, but I don't see why it need block Drupal CMS.

Since project browser is installed with Drupal CMS. We do need to get the Drupal.org API as final as possible. I fully expect there are more API changes we might want/need to make server side, since there wasn’t a real API design phase. Some of those API changes might be breaking changes. Once Drupal CMS 1.0 is released with project browser, we’re committed to no longer making breaking API changes. Finalizing the API has a good chance of also requiring changes to the project browser plugin API.