🇺🇸United States @kwiseman

I just tried setting up a Views Bootstrap accordion with a Drupal 10.4 site and have also noticed that the accordion buttons don't open their content. However, I have aggregation turned off. In my view, I've set accordion grouping to "Accordion content by grouped field" (in other words, group the output).

For accordions with grouped output only, I noticed that invalid HTML ids were being generated for the accordion's header and the <div> holding the accordion's body (lines 30 and 35 of views-bootstrap-accordion.html.twig). The invalid part of their IDs comes from a xss-filtered version of the accordion button's text set as an array key in the preprocess function for the accordion template (line 55 of views_bootstrap.theme.inc, I think). When I cleaned the filtered button text to make sure it works as an HTML id, the accordions began to work for me.

@sirclickalot, are your accordions grouped too? Maintainers, does what I'm experiencing sound like a separate issue? If so, I'll be happy to make that issue, elaborate, and/or provide the MR.

kwiseman → created an issue. See original summary → .

kwiseman → created an issue.

teknorah → credited kwiseman → .

I was able to recreate this problem with two different themes using Bootstrap 5, and verified that the proposed solution works.

kwiseman → made their first commit to this issue’s fork.

I think I'm experiencing this issue too. We're using IEF to only allow creating new referenced content (hopefully) without duplicates, but when I try to add more than one node simultaneously, I get an integrity constraint violation. Here's the text from my white screen:

Drupal\Core\Entity\EntityStorageException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '4878388b-8fb8-4325-a3ca-6e8e2a73fd04' for key 'node_field__uuid__value': INSERT INTO "node" ("vid", "type", "uuid", "langcode") VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3); Array ( [:db_insert_placeholder_0] => [:db_insert_placeholder_1] => resource [:db_insert_placeholder_2] => 4878388b-8fb8-4325-a3ca-6e8e2a73fd04 [:db_insert_placeholder_3] => en ) in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 817 of core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

kwiseman → changed the visibility of the branch 3310908-2x-make-detail-modal to hidden.

I made a new branch for a few reasons:

1. Accommodate changes to the module detail page's layout in 📌 Update project detail page layout & elements Needs work and the fix for 🐛 Remove Modals after They're Closed Fixed .
2. Styling from the commands modal was interfering with buttons and img elements in the new project detail modal.
3. I hid the "View Commands" button in the project detail modal to avoid opening a modal within a modal. However, the "Queue" button will show if Project Browser is allowed to install modules.
4. The HTML elements around a project's summary and description had the same id and are both displayed on a module's details page. I changed the id of the project summary's wrapper in the modal.

The modal is the same width (90vw), and the links in a project's description still open in a new tab. There are tests for the detail page in ProjectBrowserUiTest.php, ProjectBrowserUiTestJsonApi.php, ProjectBrowserPluginTest.php that will need to be rewritten.

kwiseman → changed the visibility of the branch 3310908-consider-making-detail to hidden.

I realize this might be better off in contributor.md in the repository, but here's what I did:

• Change "Drupal 9" in the summary to "Drupal 10+"
• Step 3: use DDEV's latest recommended config command for Drupal 10 and 11 (from DDEV's CMS Quickstarts).
• Step 5: separate instructions for Drupal 10 and 11.
• Step 7: replace the instructions to add the development version of project browser via composer with creating the contributed module directory.
• Add step 8 to follow the git instructions.
• Step 9: use the latest recommended version of automatic updates.
• Consistent capitalization of "DDEV" in the section "Building the app with DDEV".

We've been experiencing the same issue with Drupal 10.3.2 and 10.3.3. The patch is working.

kwiseman → changed the visibility of the branch 3036272-3.2.x-language-settings to hidden.

I recreated the patch from comment 5 ✨ Group language settings are missing Needs review for Group 3.3.x. It worked for me locally with Drupal 10.3.2, PHP 8.3.8, and MariaDB 10.11.8

kwiseman → changed the visibility of the branch 3036272-group-language-settings to hidden.

kwiseman → made their first commit to this issue’s fork.

This issue seems like a duplicate of ✨ remove node_modules from sass sub theme Needs review . Since the other issue has a merge request and is in "needs review", I think it makes sense to close this as a duplicate.

I replaced instances of "module" with "theme", and replaced inline plain text code tags with HTML.

It's working for me - I can now save the results of custom question types using the hook provided by Anu LMS Quizzes. Thank you, this is great!

Opening the Browse page in different tabs and opening different modules' modals simultaneously works for me.

I should also mention that there are a few blockers preventing this issue from moving forward:

1. It feels like a bad idea to create more modals when Project Browser doesn't remove a modal's HTML after it's closed: 🐛 Remove Modals after They're Closed Fixed
2. I haven't figured out how to add target="_blank" to links within a module/recipe's description in its modal. I don't think that can be done upon initial page load because the HTML for a modal doesn't exist until the title is clicked. It would be nice if the target attribute could be added to those links when the information is first fetched from drupal.org, (i.e. within the PHP of DrupalDotOrgJsonApi.php and Recipes.php).
3. Trying to reuse the code in popup.js (which uses Drupal's dialog function) made it feel like I had to use new to create modals because I can't pass in a svelte component. The linter didn't like the new keyword, so I assigned the modal to a variable, which the linter also doesn't like because it's unused.

kwiseman → created an issue.

To follow up on #11 🐛 Search API Schema reverts back to 4.2 after deploys or randomly Active : We're now experiencing this issue too. The Solr schema version has spontaneously reverted back to 4.2.10 on all of our environments and multidevs except for Live for a site after being set to 4.3.3.

kwiseman → created an issue.

@rkoller Thanks for your feedback - I definitely agree with all your suggestions. While the HTML for the modal's title and its closing behavior are out of scope for project browser, the "compatible" button being the first focused element might not be. I'm working on this today and will increase the modal's width as well as test with a screen reader (Voice Over).

I started working on this for 2.0.x. Given that there are some issues with the modal right now and 📌 Update project detail page layout & elements Needs work , it's still a work in progress. I copied ModulePage.svelte into the new file DetailModal.svelte to make edits so that simultaneously working on this issue and the one above is (hopefully?) easier.

kwiseman → changed the visibility of the branch 2.0.x to hidden.

The 3446416-2x-no-click-categories branch makes the categories look like this screenshot from the slack thread:

But now I'm running into the problem that sometimes the module's descriptions are different heights which causes the categories to be misaligned, but doesn't look great:

kwiseman → changed the visibility of the branch 3446416-module-categories-on to hidden.

kwiseman → changed the visibility of the branch 3446416-for-2x-module-categories-on to hidden.

kwiseman → created an issue.

It seems like the consensus in this thread in the Project Browser slack channel is to solve this problem (a module's category chips looking interactive but not being interactive on the Browse page) by removing the category chips altogether (only on the main Browse page). Prior to the Slack thread, the behavior of the category chips was also touched on in the Drupal UX meeting on 5/24/24. That discussion starts around 33:49 in the video.

I created a new branch for 2.0.x to solve this issue by removing the category chips.

kwiseman → changed the visibility of the branch 2.0.x to hidden.

kwiseman → changed the visibility of the branch 2.0.x to hidden.

kwiseman → changed the visibility of the branch 1.0.x to hidden.

kwiseman → changed the visibility of the branch 3446591-improve-styling-and to active.

@nick.murza - Thanks for the suggestion and MR! I also recently had the idea to add the ability for this module to add classes to the dialog's container, titlebar, and content based on what menu is in the modal. I realize the modal could also use a title, but I'm not sure that title should be the same as the modal trigger button's text.

Regarding comment #3, both sites in question are using the dev release. By default, dev releases won't appear on the Available Updates page. See this documentation: https://www.drupal.org/docs/develop/using-composer/manage-dependencies#s... →

We're having this problem too with sites on core 10.3.0-beta1 and 10.2.6, using the same steps as above. Additionally, when I output the available variables in my theme's image.html.twig template, the alt key is null, and the attributes array doesn't contain an alt key.

kwiseman → created an issue.

Personally, I think it makes sense to narrow the scope of this issue to just the screenreader accessibility and move the design part to its own issue, given that design for the toggle state doesn't exist yet.

I created a merge request on a new branch that's caught up with 1.0.x and has the same changes.

Also, I forgot to mention in #3 that I manually tested with VoiceOver on a Mac in Firefox. Manual testing with other screen readers and/or browsers is probably necessary.

kwiseman → changed the visibility of the branch 3446591-improve-styling-and to hidden.

Are we referring to the mockups from this Starshot issue: #3449347: [META] Recipes, Package Manager and Project Browser improvements needed for Drupal Starshot → ?

I added Project Browser's issue for the mini-browser ✨ Create a "mini-browser" UI Postponed: needs info to this issue's description.

kwiseman → changed the visibility of the branch 1.0.x to hidden.

kwiseman → made their first commit to this issue’s fork.

Unfortunately, I couldn't replicate the behavior shown in #12, and I mostly use Firefox. I'm not sure this is a bug because the --grid-column-count variable isn't supposed to change because it's being used to limit the number of possible columns, not directly set the number of columns that will be shown. The CSS that does this is between lines 262-280 in pb.css, and those lines were directly inspired by core (see core/modules/views/css/views-responsive-grid.css). This CSS Tricks article has a more detailed explanation.

I added the suggested aria-pressed attribute to the Link and Grid buttons that functions similarly to the two button grouping on https://tink.uk.

However, I wasn't sure how to go about applying the hover and active state styling on them given that the background color of the selected display button (either Link or Grid) in any state is the same as the design system's button active state background color. (In other words, the background of a selected Link or Grid display button is always #ADAEB3). When hovering over a selected display button, should it get 15% darker than #ADAEB3, and 30% darker if the user clicks it again? I looked around in the design system and other admin pages to try to find an example to copy, but couldn't.

I was thinking a solution to this hover/active state styling problem could be changing the color of the selected display button to blue, and then apply the design system's hover and active state styling as usual. Project Browser's Figma Designs shows an example of this on the "Updated MVP April 2022" page, on the frames that start with "April 2022: New Design Draft", but since they're called drafts, I wasn't sure.

kwiseman → made their first commit to this issue’s fork.

To fix this issue, I copied the code for the module categories' behavior from ModulePage.svelte into Categories.svelte. It seems to work the same on both pages, but it makes the code in ModulePage.svelte seem a bit repetitive. I've noticed that the markup for module categories is a bit different on the Browse tab vs a module's details page, but would it be a good idea to try to re-use Categories.svelte in ModulePage.svelte like some of the other components on the page? Given that the module details page is currently being worked on in issue #3322594 📌 Update project detail page layout & elements Needs work , I wasn't sure if I should make this point another issue, but I will if it's helpful.

Also, I noticed that in the CSS for the module details page, the entire `

` element holding individual module categories has `cursor: pointer;` applied, but on the Browse tab, I chose to change the cursor on hover for individual module categories so that it doesn't seem like non-interactive parts of the card are clickable. Please let me know which is preferable.

kwiseman → created an issue.

kwiseman → created an issue.

I noticed that limiting the max-width on individual cards at very wide screen sizes could result in the "Sort by" box and other parts of the UI being isolated (and harder to find) on the right side of the page. I added a screen shot to demo what limiting the max-width could look like. Given other UI changes in progress and @chrisfromredfin 's agreement, I only changed the CSS variable controlling the maximum number of columns.

kwiseman → changed the visibility of the branch 1.0.x to hidden.

I think line length is important and should be limited, but I also agree that this seems like an issue better suited for individual themes.

kwiseman → changed the visibility of the branch 3445811-current-page-not to active.

kwiseman → changed the visibility of the branch 3445811-current-page-not to hidden.

Added Portland2024 tag

kwiseman → changed the visibility of the branch 3444658-remove-the-clear to hidden.

I'm here!

I tested the Number filter in Drupalpod 10.1.x with the Umami demo after the last 2 commits by adding an exposed filter for number of servings to the Recipes view, and it works as expected. I wasn't sure if it mattered that the default values for min and max were empty strings (on lines 36 and 37 of src/Plugin/better_exposed_filters/filter/Number.php), so I tried setting them both back to NULL, and it still worked as expected.

I created a regular and high resolution version of the 2025 social card as media images. I've also updated the Midcamp 2024 wrap up article with the correct graphic.

kwiseman → created an issue.

I was unable to recreate this issue using Drupal core 10.2.5 with PHP 8.2 and Layout Builder Library 8.x-1.0-beta4. My testing site wasn't customized beyond the standard profile very much (I added the Admin Toolbar module and created a new content type to follow along with the suggested steps).

This last step was a bit unclear to me, but I tried all actions I thought it was referring to:

Thinking that selecting None as LL selection means it will use the "Default" layout (that i had previously set up for ALL nodes of this type) i go to edit that layout to make an adjustment. When i save those changes the following exception is created

Specifically, I tried:

• Changing and saving the full content view mode's layout.
• Changing and saving the default view mode's layout (which wasn't using Layout Builder).
• Changing and saving the layout of an individual node with the layout_selection field set to None.

Here, hello

@mradcliffe wanted me to mention that when I first saw this design, I thought it was a bookmark, but I do think it works well as a banner too.

Also, I sampled the contrast ratios of the text and dropshadow colors on the "ring" in "Mentoring" (on the left) with my mac's digital color meter, and here are my results:
Contrast of white text on green: 3.9:1 (green was #419232)
Contrast of grey dropshadow on green: 1.86:1 (#b3b3b3 vs #419232)

brianperry → credited kwiseman → .

Updated status to fixed. Thanks @kenyoOwen!