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
Comments
Comment #2
drummThis message can also mention this is a prototype & feedback is appreciated. While keeping it brief & readable.
Comment #4
fjgarlin commentedMaybe 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
Comment #5
chrisfromredfinI 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
Comment #6
tim.plunkettOne 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.
Comment #7
hooroomooComment #9
hooroomooComment #10
hooroomooComment #11
thejimbirch commentedWhile 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
Comment #12
bnjmnmI 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.
Comment #13
run fast think slow -lets4- commentedI 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.
Comment #14
chrisfromredfinI 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.
Comment #15
leslieg commentedI 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
Comment #16
hooroomooUpdated to use suggestion in #11 and changed from warning message to status message
Comment #17
thejimbirch commentedBased on the comments above, and feedback in Slack, I am moving this to RTBC.
Great job @hooroomoo!
Comment #19
tim.plunkettgetDataFromPlugin()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.