Rename the drupal.org (json:api) source type

honestly speaking the entire drupal core source type could be questioned , which also leads into a discussion i've tried to suggest and initiate several times on the drupal slack bringing together folks from the usability meeting, the recipes group , and project browser and whoever is interested to join. we've repeatedly touched the extend page in #2035079: [PP-1] Figure out what to do with the install/uninstall modules page in the usability meetings and i guess the entire page has to be tackled and discussed holistically. a few personal thoughts.

at the moment on the extend page you have the local items list (list of modules), browse, update and uninstall (uninstall is referring to the uninstall of modules). all the entries shown on the list and uninstall modules page are modules already contained in the file system added by composer require.

within browse there is currently drupal.org json:api, recipes, and drupal core. none of the modules listed in the drupal.org json:api source type is contained in the file system yet, recipes in contrast currently only contains recipes shipping with drupal core which are already contained in the file system BUT sooner or later it will also list recipes on d.o not contained in the file system yet, while drupal core strictly speaking simply mirrors a subset of the modules on the list page, but all of them already contained in the file system.

personally i would vote for a clear separation of concern. the sources shown under browse should only list extensions (modules, recipes, themes) that are NOT in the file system yet and remote. while all the local items aside browse on the extend page have the entities listed on their tabs be already added and available in the file system, either installed or uninstalled. and i would have one local item for modules, one for recipes and one for themes (and the top level item appearance could be deprecated - something you dont use on a daily basis which would be the sole reason to justify having a top level item - something i've realized in one of the drupalism meetings where @cellear made that valid point). but that way concepts would be structured more clearly with a separation of concern. at the moment everything is overlapping and potentially confusing if you dont know about the underlaying concepts and their constraints. just a rough outline and idea but the longer i think about it the more sold i am on it.

but yeah out of the scope for this issue but i really think it would make sense to bring several groups together and having a discussion. cuz in particular if you test the prototype for starshot the problem is further emphasized and amplified. you have an overwhelming modules list page and no direct touchpoint with the list of available recipes nor any way to directly see which of theses recipes got applied setting up starshot /drupal cms. the user is in complete lack of situation awareness.

regarding #2.1 i disagree on that one. at the moment with for example the drupal.org json:api tab active you have the results count there as well as a second time underneath the filter field set. any redundancy should be avoided. but the general even bigger problem is the search field is within the filter section so the scope of the search field is the drupal.org json:api source type just based on the hierarchy in the DOM as well as the general proximity. but the search query gets applied to all the other active source types as well, each of them has a result as well. to make sense, the search field would have to be placed above the source type tabs. but what is the purpose of searching across modules, recipes (at the moment locally but sooner or later also on d.o) and drupal core(which is also local). that is simply too much complexity and a potential information overload. a clear separation of concerns is probably preferable. the proposed resolution in #3457966: Filter (categories) selection is leaking over into other sources suggested to keep the scope of a search to a single source type with each of the sources having their own filter and dropping the results count form the tabs.

regarding #2.2 not sure if the ui would be overloaded with another description here or popup button. i think a more elegant solution would be to create a tour for project browser (for the search page and the details page) in https://www.drupal.org/project/issues/tour . something i've suggested over in the discussions in the #tour chanel on the drupal slack. the development speeded up after it got moved into contrib and it is now considered by two tracks (seo and a11y) to be proposed to being added to starshot/drupalcms.

on d.o there are separate paths for the two:

https://www.drupal.org/project/project_module
https://www.drupal.org/project/project_theme

so not sure if the json api endpoint entails modules and themes or just modules. i've assumed the latter. and i thought the introduction of themes is planned at a later point? and i've just checked and simply searched for "adminimal" in the drupal.org json:api source type in project browser and there is no match for https://www.drupal.org/project/adminimal_theme in the search results.

thank you! I've applied the MR. I agree that it makes sense to update the description for the source type as well. There are a few details to note.

The label for the source type on admin/config/development/project_browser is set to Modules while on admin/modules/browse i still see Drupal.org (JSON:API). Not sure if that is due to some "caching" and or svelt issue? but oh i've tested a bit more and discovered the reason :D With no string to search for entered, i get:

After entering a string, i get:

And from a readability perspective and in regards of clarity i would prefer Modules over Drupal.org Modules. The detail of interest here is "Modules", for the suggested alternative Drupal.org Modulesthe user has to skim past "drupal.org", which provides no additional benefit, at least in the context of a tab label. the goal here, to be brief, clear and specific. and the general concepts the tabs deal with are project types like modules and recipes not their location imho (but that detail might be considered in a help text for a source type - in particular in cases if the source type contains local and remote entities, but out of the scope for this issue) .

In regards of the description i agree that it makes sense to note that the modules listed there are queried via the json:api endpoint on drupal.org. but taking a look at the description in the context of the descriptions of the other source type all three are are sort of inconsistent. for example modules talks about "related infromation" while drupal core talks about " filter information" . modules and drupal core have the suffix " project", plus module is singular while core is plural, and recipes is also in plural, but without the suffix "project".
To align all the descriptions for all the available source types is out of the scope for this issue. But I wonder if a more "compact" approach for the modules description could be explored within this issue and in a followup we align it with the other two? How about something like Modules on drupal.org queried via the json:api endpoint

I've cleared the cache several times yesterday, with drush and on admin/config/development/performance, and i did the same a few more times today, but still the same outcome (before and after i pulled your recent changes). :/ i still experience the behavior outlined in my two screenshots in #17. no idea why :( i've tried in safari. tried now in another browser (firefox) i havent logged into this project yet (have setup again this test instance recently) and i still get the same outcome :/ not sure if others run into the same issue? ( i am testing on ddev on macos with mutagen)

bingo! i can confirm your assumption. switched the order of modules and recipes source types, saved, and when i revisited the browse page the tab used Modules as the label immediately without the need of any additional cache clear. .

so does that mean that keyValue storage is cache clear persistent at the moment?

hm at least from a users perspective it is sort of confusing if that keyValue storage isnt included in a regular clear cache. probably an edge case cuz usually the tab labels arent updated that regularly nor the user has the ability to alter the name, and if the source typ order is changed or their enabled/disabled state the keyValue is updated. but if you have a case were you run into it is confusing. i am not developer so i leave it up to you and others if and where to fix it (but if it has to be fixed i guess a follow up would be totally fine - out of the scope for this issue probably or could folks who have project browser already installed and in use run into this problem i've experienced?) .

hm I am not sure of having the two concepts for modules exposed that explicitly is the right solution to the problem here, in particular if you take the perspective of someone new to drupal, neither core nor contrib not necessarily mean a thing, and yes "contrib" i would also consider a drupalism AND an abbreviation on top of it.

In the first place there is the question i have for a long time, what is the actual purpose of the core source type? it is redundant to the extend page content wise, the readability is harder either way with the list or the grid view, the list then the grid both miss the grouping you have on the extend page, plus for actual "browsing" you would also go into the details pages to read up about the module in question, and those "details" for core modules are none existent (so why "browse" it then?).
under the primary tab browse you have one secondary tab contrib module now which is remote modules only (in case they are not added yet) then you have recipes which are in the file system from core and with starshot from core and from starshot(which is technically contrib and at one point there will also be the contrib recipes on d.o remote), and then you have core modules which are in the file system as well. so by relabeling the modules and core source types into contrib modules and core modules you make those explicit while recipes remains implicit and nebulous. "technically" it would be required to relabel the recipes tab for the sake of consistency and clarity but then you would get into calamities: are the recipes available only those shipping with core or some from contrib /starshot or are there any in place from contrib even and how to label that then?

it is totally fine if project browser takes over the extend page at one point under the hood but i would make a clear separation of concern between primary tabs like extend and browse. that any secondary tab under browse is remote and you are browsing external sources while any primary tabs under the top level item extend are"local" in the file system.