chrisfromredfin → changed the visibility of the branch 3318817-improve-category-filter to hidden.
chrisfromredfin → created an issue.
Two things at a minimum -
1. Let's remove the boxes at the right hand column, and just stack that information up with some decent spacing.
2. We really want to show the "summary" of the body field, then the images, THEN the full description. I'm not sure if there's backend work needed here to make that happen, but we should have access to the summary field separately from the full description. The summary is what we're showing on the cards view, so we want to repeat it, then show the images, then the full description.
I think there are some other improvements to be made:
- Get rid of the "Details" heading
- get rid of the "Categories:" label and just show the chips
- let's get rid of the module author (i.e. "By Dave Reid") altogether
- let's make the slideshow actually work?? 😬
Indeed they are! Thanks for the triage, Sime.
With my thanks!
chrisfromredfin → made their first commit to this issue’s fork.
Thanks for the improvement!
chrisfromredfin → created an issue.
chrisfromredfin → created an issue.
Looking at this Draft MR today with @phenaproxima - https://drupal.slack.com/archives/C01UHB4QG12/p1715785363763219
This feels like the right general approach to me, we need to abstract 'activation' from assumptions about project type so that we can support more things. This is how I would have approached it, also.
General considerations are namespace collisions - but sounds like using Project (which already knows its type) will handle, for example, a recipe named 'zen' and a module named 'zen' - should such a thing exist.
This gives a good separation of concerns, also, that Projects can be meta/global information about a project from the source, and Activators can store more site-specific information relative to this Project - i.e. "installed status" for a Project.
realizing this is not my issue queue! leaving RTBC so credit can be attributed.
Please also credit @apaderno who did a lot of work in the original Google Doc.
Wiki page is up, woohoo!
I think there's good enough consensus here, and that we're seeing this pattern in Claro in other places (ex.g. modules List page) - if the screen gets super wide, the text gets super wide. Not ideal - we all agree limiting line length is good for readability - but closing here because I believe this should be fixed upstream (Claro, ex.g.) and we should not deviate to the extent we're able.
I have updated this page to reflect the template which is currently being used as the default module template when creating a new project on Drupal.org.
This template was agreed on through community consensus as part of the Project Browser Initiative.
Not sure if you need to globally add rollup in the commands at the bottom. Also not sure if this belongs here anyway - maybe belongs in Contributor.MD in the repo; and may already be there.
This may be obsolete with 📌 Improve the categories filter type in context to the rest of the filter component ui Needs work , unless we don't fix the checkboxes in that one.
I have begin work on moving these around. It's far from perfect, but it's a start. There's a draft MR (!476) in place.
A nice lil' bit o' usability, here!
The big issue here is that this would mess with the paging on the backend, unless we re-made a call to the server, which I think is less than desirable. I think the right solution for now is to not let any 'row' be more than 4 columns, and keep paging in multiples of 12. If we need to, let's enforce a max-width on the cards as well.
Added additional information about maintenance and development status, as well as pointing people to the template for the long description.
Wonderful! Thanks to all who helped; this issue was such a testament to the beauty of DrupalCon code sprints!
chrisfromredfin → made their first commit to this issue’s fork.
There is a linter error in eslint - ProjectIcon appears to still be imported at the top, but never used. Be sure to also remove that extra line.
Done.
Want to point out this solves some other issues around proper page titling / H1. When on a separate "page" the H1 really should be the module's title if you're on that page. Serving it on a modal makes it clear you're still in "Browse projects" and just getting some additional info about something. This may also make it easier to communicate back-and-forth between the 'add and install' on the detail page and the underlying buttons on the card.
Thank you for this extensive research, @jewelclark! This gives me a clear path forward. Updating proposed resolution.
chrisfromredfin → created an issue.
Ralf - since you had such a nice thorough plan here, if you want to try this out in GitPod that would be fun. :)
I was able to check it out in Safari and Chrome at least and it looks good - but if I had your blessing I'd feel better about this one. :)
chrisfromredfin → changed the visibility of the branch 3293899-focus-outlines-for to hidden.
I agree after thinking more; plus getting such great feedback from the community! This is a separately-scoped issue which I'm going to merge; I'm going to open a follow-on for "consider if Browse should be the default tab for Extend" and get community feedback on it.
nicxvan → credited chrisfromredfin → .
Much better; matches Drupal design system and I find it more readable and looks more Drupal-y. Reviewed & tested in DrupalPOd.
chrisfromredfin → changed the visibility of the branch adjust-chip-design to hidden.
chrisfromredfin → changed the visibility of the branch 3293977-adjust-the-chip to hidden.
woohoo, thanks for saving my butt
chrisfromredfin → created an issue.
confirmed pre-MR and post-MR that this fixes it. ship it!Will open a follow-up cuz I already merged before I realized this probably should have a test...
Tested in Drupalpod. While I still can't always reconcile whether other things should left-align or not, I'd rather do that in a follow-on because this is an incremental improvement.
chrisfromredfin → changed the visibility of the branch 3318726-reposition-the-card to hidden.
Yes, and standard search clear button then doesn't allow refreshing the results in a good way - see ✨ Ability to clear keyword/search filter with one click Needs work .
let's do the tabindex -1 approach.
chrisfromredfin → created an issue.
We should have the d.o team create a redirect url like drupal.org/category-help and we should link to that; that way if the page URL ever changes or the node ID does or something, the link won't break.
1) work with DA/d.o webmasters to create redirect
2) determine UI for adding the help / link
3) add into svelte code near the categories filter
(I don't think this will need a test)
Merged this because it gets us started and gets us a test, and we still need to discuss whether or not to make it the default tab (I believe so, but there is not consensus). There is another issue for that, so I like leaving this one.
Tests did fail, but they were separate fails on flaky FunctionalJavascript tests.
I believe this is related, or even a duplicate of ✨ [PP-1] Add support for scaffold files that aren't defined by Drupal core or the root composer.json Postponed , which DOES have a good issue summary.
The issue here is that in 📌 Do not allow drupal/core-composer-scaffold to be used by packages other than core Fixed we restricted use of plugins that are allowed to scaffold files to only the implicit ones.
Now that we're maturing, I was looking at things like "what would it take to get this running on, say, Pantheon hosting?" For one, Pantheon has pantheon-systems/drupal-integrations, which simply scaffolds three files in the sites/default folder.
So while knowing those files (via ✨ Create something like getAllScaffoldfiles() in core-composer-scaffold. Active ) would be nice, I wonder if there's also an option here to simply say, as a site owner "I know the scaffolding afforded by this plugin is safe, let's allow it to do what it does."
I imagine we could do this in a similar way as the composer plugins validator does, by adding some additional configuration that can be set:
https://git.drupalcode.org/project/automatic_updates/-/blame/3.0.x/packa...
Discussed with users at DrupalCon Portland.
Going to keep the scope of this issue small, which is, let's just left-align (or right-align for RTL) the short description text.
We can open follow-ons if we decide we need to alter the title, icon, or category alignment. Proposed solution currently reflects this.
As this issue is old, I would recommend that if you want to work on it, open a new MR rather than rebasing, since I *think* the fix is probably something close to removing a `text-align: center` somewhere in pb.css :)
Hi there -
At Project Browser, we came up with a project page template that is now the suggested template that is auto-injected into the body field of a new module page on d.o.
Should we update this page to reflect what is recommended there?
See ✨ Improve project descriptions by using a template suggestion for the body field Fixed
update for clarity in the initial directory creation step
updating for more recent info @ DrupalCon Portland '24
If we solve this in documentation (Handbook page), is that adequate? Need some feedback from new folks.
Would love to find Wim and Ted at DrupalCon Portland and put a (ted)bow on this!
Of the two choices in the proposed resolution, I like what Wim says in #6 - which is that if Package Manager enforces or enables maintenance mode itself, then (a) we don't need to worry about it, and it provides a consistent experience when more modules come along and start relying on Package Manager, and (b) it solves the 99% use case, which nullifies the 1% need for the settings.local.php override (maybe those numbers are more like 90% and 10%, but I think the point is still valid).
We would want to notify users that their site will be put in maintenance mode during "the operation" - and I would personally just encourage doing it at the latest possible time (for example prior to applying to real codebase, and not, say, during the beginning of the copy-to-stage phase), but I think that goes without saying. :)
I think this might be better served by making the detail page a modal and having this problem go away entirely. See https://www.drupal.org/project/project_browser/issues/3310908 ✨ Consider making 'detail page' a modal window instead of a separate "page" in app Active
just updated contributor.md with the instructions for rebase; no longer using contribkanban currently
Hi Rachel - now at DrupalCon I finally got around to testing this. I was able to get it to fail at 128M, and succeed at 192M. I didn't dig much deeper than that to get you an 'absolute minimum' but I think 192 is safe!
I THINK this is no longer needed. :)
Stars in general in Drupal are not super useful; and in fact, may be going away with Drupal.org upgrade to modern Drupal. Will not do anything with stars in the current iteration.
Big help! Sorry it sat so long. :)
New categories page with descriptions ('scope notes' from earlier discussions) is up and live, so closing this as outdated.
None of this is out-of-turn; however, not much of it is actionable.
Giving this a [meta] and will encourage folks to link existing child issues, or create them, around some of these specific issues. Especially if we can point to existing Drupal Design System elements that we should convert to, that would be amazing.
We are displaying modules that have a release compatible with _this_ version of Drupal. We wanted to keep Drupal 7 ("legacy") modules out of there, and I think this is the best-case scenario. We do intend to document what shows up and what doesn't, and why, and encourage folks to use Drupal.org to find the full suite of modules.
Actually, turns out this was fixed elsewhere!
chrisfromredfin → changed the visibility of the branch 3389250-add-docblock-to to hidden.
Tagging as post-mvp for the time being.