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

@rkoller
+1 for this, for site builders or non-technical users this label is meaning less. Because this source is listing only modules it is better to rename it to "Modules".

From the usability point of view in the source tabs, I observed a few more things that consider to be improved:

1. Currently the label for source and total results are displayed all together which giving impression that it is a single label. We can consider having the label and results count separated with parenthesis something like Modules(5630 results) or Modules(5630), Recipes(85 results), or Recipes(85), this would make it more user-friendly. "results" word also seems repetitive.
2. Show a short summary about each source for each source label to make it clear what Modules, Recipes will do.

Thanks!

I agree with this, and "Modules" makes sense for the label.

My only concern is that core modules aren't included, and there is a separate "Drupal core" source for those, so the title doesn't make it clear that browsing "Modules" doesn't include core modules (though, personally I think the solution should be to include core modules, as a non-technical user shouldn't need to know they need to look in a separate source for core modules, or even whether a given module is coming from core or contrib, but that's definitely something to discuss under a separate issue).

@lostcarpark Yes, the "Drupal Core" source also needs discussion because I agree with you for a non-technical user it does matter whether it's core or contributed, for them, it's a Module.

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 📌 [PP-3] Figure out what to do with the install/uninstall modules page Postponed 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 📌 Rename the drupal.org (json:api) source type Active .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 🐛 Filter (categories) selection is leaking over into other sources Active 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 📌 Rename the drupal.org (json:api) source type Active .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.

Wait a sec. Is "Modules" really right here? What about themes? I'd imagine d.o is exposing themes and modules both, since they are all just regular projects.

Should this be "Modules & Themes"?

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.

Should this be "Modules & Themes"?

From the site builder's point of view, if we put "Modules & Themes" under one tab, he/she will have to apply some additional filter to filter out the Modules or Themes only.

But because the tabs are for sources and from D.O. if both are being pulled then it makes sense to display both and further filtering of (modules/themes only) needs to be considered.

I definitely don't think themes should be bundled in with modules or even under the "Extend" menu.

When we add Themes, I feel a version of the project browser should appear under the "Appearance" menu item.

Also, I have no idea how we would do it, but I feel our goal should be to show a preview of the front page of your site in the new theme before you install it.

I’ve been reflecting on the points in #10 📌 Rename the drupal.org (json:api) source type Active and wanted to share a few thoughts.

It might be beneficial to have distinct tabs for "Modules," "Themes," and "Recipes." Additionally, the "Browse" option could be placed in the "Appearance" menu or made accessible globally. I recall seeing an issue related to the placement of the "Browse" menu item, although I can’t seem to locate it at the moment.

If we decide to have a "Browse" option under "Appearance," it would make sense for it to take users to the "Themes" tab on the Browse page, while the existing "Browse" menu under "Extend" should take them to the "Modules" tab.

Lastly, it may be worth considering renaming the current "Drupal.org (JSON
)" tab to "Modules," as it lists and searches for modules only.

I created an MR with the change. I came to this issue purely because I thought that having JSON:API in the label of the tab would be meaningless or even confusing to less experienced users, so I wanted to remove it.

I don't think that we need to change anything else, as internal classes, the ID of the plugin, etc need to be meaningful from a code point of view. Changing the label and the description slightly might be all we need here.

I had the MR change it to just Modules, but it could also be Drupal.org Modules, which indicates the source of the data and type of the data, tho if we assume that Drupal.org is the default source, then we can omit that part and just leave it as it is in the MR.

Please review.

In addition to changing the label in the Browse tab to just "Modules", I also added the description of the plugin in the settings form in the admin screen as shown here:

I think it makes sense to add this as part of this issue as we need to take into account both Project Browser user types:
- Using the Browser screen, where you want to know what's in each tab
- Configuring Project Browser, where you want to know a bit more about the available plugins

Re comments #7 to #11 about Modules, Themes, etc.

The plugin is coded to _only_ request "Modules", so the word "Modules" is correct here. See the code here: https://git.drupalcode.org/project/project_browser/-/blob/2.0.x/src/Plug...

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

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).

Can you clear the cache? I'm pretty sure it's that as the string is not anywhere else and the Svelte templates are dynamic in this section.

I changed the description to the one that you suggested.

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)

Maybe this is related to the way that the "caching" is done, as it is not using Drupal cache system, but the keyValue system instead.

On the admin screen, can you change the order of the plugins and save the configuration? Or add/remove one of the plugins. I see in the code the following:

    if ($event->getConfig()->getName() === 'project_browser.admin_settings' && $event->isChanged('enabled_sources')) {
      $this->keyValue->deleteAll();
    }

So doing that might trigger a rewrite of the keyValue storage.

Testing with "fresh" Drupalpod gets the right value directly.

bingo! i can confirm your assumption. switched the order of modules and recipes, 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 storate is cache clear persistent at the moment?

Yes, it has a different mechanism to cache, using different tables, etc. This would need to be a follow-up if it is a problem. I am not sure why it's not tied to cache but I guess there is a reason behind it.

Tracking down code. KeyValueExpirable (the service used) seems to default to a week for expiry based on this value: https://git.drupalcode.org/project/drupal/-/blob/11.x/core/core.services...

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?) .

I think it's a legitimate follow-up issue that can be raised if only to discuss the rationale behind it.

As for this issue, all the feedback was addressed and it's still in "Needs review".

I agree with Ralf, the "Drupal.org modules" may not be clear to novice users. However, "Modules" seems too nebulous, since it may not be apparent that core modules will not be shown.

Contrib modules?

I am 100% on "Contrib modules" and "Core modules" for the two separate ones, and I have Leslie's agreement on that. Let's go forward with those labels. I understand that "Contrib" might be a bit of a Drupalism, but it's obviously short for Contributed, and they need a differentiator.

Also, OK if we change Core's plugin and Contrib's plugin in the same MR ;)

Addressed @chrisfromredfin feedback in #30 and #31.

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.

For the scope of this issue, it's an improvement, and I think it's acceptable for now. Otherwise we will bikeshed on language for a decade.

swore this was marked fixed.... ?!