Problem/Motivation

While we continue to use the mock data, we will continue to have stale data exposed to users.
Additionally, we don't support full text search. So if you search for "layout", you won't find Panels, Display Suite, Fieldable Panels Panes, etc, because they don't have the word "layout" in the module title.

Steps to reproduce

Proposed resolution

Add a message to the UI until we switch to the full endpoint.

Remaining tasks

  • ✅ File an issue about this project
  • ☐ Addition/Change/Update/Fix to this project
  • ☐ Testing to ensure no regression
  • ☐ Automated unit/functional testing coverage
  • ☐ Developer Documentation support on feature change/addition
  • ☐ User Guide Documentation support on feature change/addition
  • ☐ Code review from 1 Drupal core team member
  • ☐ Full testing and approval
  • ☐ Credit contributors
  • ☐ Review with the product owner
  • ☐ Release

User interface changes

API changes

Data model changes

Release notes snippet

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

tim.plunkett created an issue. See original summary.

drumm’s picture

This message can also mention this is a prototype & feedback is appreciated. While keeping it brief & readable.

chrisfromredfin made their first commit to this issue’s fork.

fjgarlin’s picture

Maybe we can use the Plugin's labels and descriptions for this?
$this->enabledSource->getCurrentSource()->getPluginDefinition();

We could use the above in "BrowserController.php" and that will return the label and the description of the plugin (which comes from the annotation in the plugin class) and pass it to the front-end.

So, for example, when using the mock, it will look like this: Drupal.org (mocked): Gets project and release information from a mock API

chrisfromredfin’s picture

I like that idea. I think that it makes sense to allow each plugin to provide its own helper text?

I would pitch the text as:

Title: "Drupal.org Mock API"
Description: "Provides a mock implementation of data from Drupal.org. Though the data looks real, it is a sample of data pre-populated from a fixed data set. It may show stale or incomplete data."

Then I think show it... maybe above the keyword search as like:

Data Source: Drupal.org Mock Api
Full description here

tim.plunkett’s picture

One thing I want to keep in mind here: there are still loose plans to eventually allow multiple source plugins to be active at once.
Maybe instead of adding to the source plugin API in this issue, we should hardcode a check for the plugin ID and have the specific text we need for this mock plugin added directly.
That takes all of the API considerations out of this issue, and lets us focus on the major MVP blocking aspect of this.

hooroomoo’s picture

Assigned: Unassigned » hooroomoo

hooroomoo’s picture

Issue summary: View changes
Status: Active » Needs review
StatusFileSize
new114.14 KB

hooroomoo’s picture

Assigned: hooroomoo » Unassigned
thejimbirch’s picture

While the merge request does exactly as requested in the comment in #5, it doesn't speak to the site builder at all as it is very technical.

How about something more like this? Included is the word prototype and call for feedback as recommended in #2.

Project browser is currently a prototype, and the projects listed may not be up to date with Drupal.org. For the most updated list of projects, please visit https://www.drupal.org/project/project_module

Your feedback and input are welcome at https://www.drupal.org/project/issues/project_browser

bnjmnm’s picture

I prefer the language proposed by @thejimbirch in #11. I'm also aware that message phrasing can quickly get bikesheddy.. and I'm also aware that this is one of the more set-in-stone MVP requirements. SO. I propose the following:
If there's reasonably fast evidence that other people agree the language should shift to #11, lets quickly make that change and get this in.

If there isn't clear support, or it's being debated (which is reasonable), lets move that discussion to a different issue and commit this one as-is so the MVP requirement is addressed. Basically, I like the suggestion but I want to avoid delaying the MVP on it so if there's not quick agreement, a followup issue is where it can get the attention it deserves.

run fast think slow -lets4-’s picture

I like #11 as well.

I thought of some suggestions to improve it - but I think the wording in #11 is just fine. Lets run with that is my vote.

chrisfromredfin’s picture

I prefer the language in #11. Even the warning looks scary. I would prefer it to be more plain text just in italics maybe? But again, don't want to bikeshed. Something is better than nothing, and I'm OK if we ship it as-is with #11 text.

leslieg’s picture

I agree that #11 is better than #9 for our target audience. We can ship it like this and update later if needed. The intent of letting folks know that the data may not match that on drupal.org is the key

hooroomoo’s picture

Issue summary: View changes
StatusFileSize
new203.02 KB

Updated to use suggestion in #11 and changed from warning message to status message

thejimbirch’s picture

Status: Needs review » Reviewed & tested by the community

Based on the comments above, and feedback in Slack, I am moving this to RTBC.

Great job @hooroomoo!

tim.plunkett’s picture

Status: Reviewed & tested by the community » Fixed

getDataFromPlugin() is called multiple times, no reason to re-process the messages each time. And I think having a status message stored on the plugin definition is overkill. But I agree with the wording, so I'm merging this.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.