🇺🇸United States @bernardm28

Before

After

cards can be previewed now.

The image is commented out because it creates an error with experience builder. Commenting that section out removes said error and the props load from within experience builder. if that issue is solved we can bring it back.

The latest version is a bit of rewrite, but seems to match the spec closer at smaller screen sizes.

It seems to be working as expected though I could not add an image on experience builder. But that might be just related to that.

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

Just ran into an issue that could be made its own or linked to this one.
Media items only seem to export the first language file. It defines a second file dependency when it finds a translated entity on it but it does not export that. Hence we run into media items that have no images in Spanish but work well in English.
As an example, you can test the following. Umami works well for the first one but it does not find any image files for the Spanish one even though it was exported as expected.
https://www.drupal.org/project/distributions_recipes/issues/3365143#comm... →

There's one little glitch left where exported entities that have translated content into different files. This results in the Spanish version of Umami having no images. Even though the English one has them all. This might be a default content bug though.

Added a default content recipe that replaces the demo_umami_content.
To test it one can comment on this line.
\Drupal::service('module_installer')->install(['demo_umami_content'], TRUE); on demo_umami.install
and then run a ddev drush site-install umami
It's missing. Those I will probably add to the config install folder later.
# block.block.umami_banner_home
# block.block.umami_banner_recipes
# block.block.umami_disclaimer
# block.block.umami_footer_promo

bernardm28 → changed the visibility of the branch 3505905-argument-2-array to hidden.

bernardm28 → changed the visibility of the branch 3.x to hidden.

bernardm28 → created an issue.

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

Seems like this would need https://www.drupal.org/project/default_content/issues/3160146 ✨ Add a Normalizer and Denormalizer to support Layout Builder RTBC
As the latest version of umami has layout builder on by default though it does not use it much since most of the content is in the body field.

It be great to have a spaceless placeholder as to have backwards compatibility.
The docs could start pointing people towards the new solution in the mean time and glitches can be worked out as those migrate.
Rather than everyone migrate now and hope for the best.

I can confirm this is stil an issue.
Tested on 10.3.11.
One can select the view mode from the UI as seen on the pic below.

Selecting a different view mode works as expected there. One can switch view modes and see the changes visually on the page.

However, the twig template suggestion never adds the active view mode to the suggestions.

That makes it hard to theme a block in multiple ways based on its view mode. You can see the field change between them but have no access to the twig suggestion for it.

Latest testimonial component stacked on top of feature component.

The biggest challenge for the hero:
This component is confined to a small space so far. That makes the text too big to match the Figma design unless it is scaled down, but then it won't look great when stacked above a feature or card component.
In layout builder, there was a way to make the section container the full width. If that's added to XB that would make this easier. So far I can only place blocks on that region and can't find an option to exit out of it from XB

I noticed this morning that umami already does something very similar.
So instead of rewriting that we might as well copy UMAMI's and tweak it as needed.

New layout:

The new layout coming from Umami is a bit squished in that region. But other than that, it seems to do well.

Not sure how to switch it to full width to take advantage of the extra space.
Otherwise, xb makes the space small for a hero compared to other components such as the feature or cards.

The last update removes that error and makes it work with properties as seen on the image. As that seems to be what most other tickets are doing.

There seems to be a mix of syntax on this PR. Because image, cta1, and ct2 are defined as slots but the twig file calls them as properties by doing {{ cta1 }} instead of {% block cta1 %}{% endblock %} which is what slots use.
Besides that and the issues slots are having with XB should we make those slots properties for now?

Still needs some work but it looks like the image above.

I'm unsure how to load the placeholder image as in the example above.

Taking a look at this now. I will open a PR soon.

mradcliffe → credited bernardm28 → .

Is a person coming out of people? if so, new fields are needed to meet that design. if not, should it be its own content type? which does not seem to have been created yet.

bernardm28 → created an issue.

bernardm28 → created an issue.

  .views-exposed-form .views-exposed-form__item:has(.form-item__description) + .form-actions {
    margin-block-end: 1.75rem;
  }

Something like that would fix it too but idk why we would override claro there.

We could have a has css class that aligns that button based on the previus

bernardm28 → created an issue.

Pretty cool how USWDS is stacking the tables with just CSS. But kind of unfortunate that means somethings they could not solve, like the table headings.

Here is what the before and after look like.

Before

After

The code above does make a few assumptions but for basic scenarios it gets you there and might be easier to modify for more advanced used cases.

I did, but uswds does not include

https://designsystem.digital.gov/components/table/#component-variants-table

bernardm28 → created an issue.

bernardm28 → created an issue.

I'm not sure, I would imagine it would work as usual without it. However, bigpipe is considered best practice and significantly improved performance metrics.
https://docs.acquia.com/acquia-cloud-platform/performance/bigpipe
So i would imagine for those that don't use it they might run into this issue once they do.

Here is how we did it and how it can be done with the new way described by catch #63. 🐛 10.3 upgrade now missing status-message theme sugestions Active
https://www.drupal.org/project/uswds_base/issues/3465493 📌 Drupal 10.3 changes how to theme status messages. Active
My example is for a USWDS theme but you can replace those classes with those you had on status-messages.html.twig

bernardm28 → created an issue.

volkswagenchick → credited bernardm28 → .

volkswagenchick → credited bernardm28 → .

I like how this issue and its PR simplify the current workflow.
My only concern is this removes the ability to have multiple tabs open, which becomes useful when looking into multiple competing modules.
However, if one can queue the modules in a shopping cart of sorts which I heard may be in the future then that would not matter much I suppose.

bernardm28 → created an issue.

volkswagenchick → credited bernardm28 → .

Seems like this issue MR accomplishes the main goal of this issue.
It could always be improved later on a follow-up.

So it looks like the carousel does not work because we renamed
project.field_project_images to project.project_images but the fixture only finds one image with that name.
FYI updating a fixture within drupalPod is very slow.

I'm considering using https://biggerpicture.henrygd.me instead of making our own gallery since that supports multiple types.
Thoughts? I will add it to the MR tomorrow.

Ooooh, that's a great suggestion and a pretty cool module.
Though we already do something similar, in a slightly different way.

My issue is mostly around providing a way where we don't have to do img[alt=""], because a given image might need the warning in the future. Some components change their requirements as they serve a slightly different purpose.
I thought about a setting any given editor could toggle through a keyword or similar. Similar to the module above but with an Editoria11y exposed setting.
Editors can choose if the image in that location is decorative but if at a later point, it's not. They could remove the check or keyword and provide a way for Editoria11y to parse it again. That would be ideal.

I was using 'img[src*=".svg"], img[src*=".png"]' to ignore the extension, but I'm pretty sure editors will change their mind and have a png or .svg at some point that need the alt text warning even though it might not need it today.

That said, it's ok if you feel that's outside the current scope.

I will run through a few prototypes and see if I find something that might fit.

This probably comes with it's own challenges but will allow an override for those images an ambitious site builder deems decorative.

bernardm28 → created an issue.

This issue worked as expected on DrupalPod on Chrome.
We should open an issue up if it does not work in Edge and Safari but because this is an enhancement. I think supporting edge and safari would be could be a follow-up.
The feedback and accessibility concerns are valid and will be super useful as we make later enhancements but for now, I think this achieved the targeted outcome.

After looking into this issue, It seems to have accomplished the requirements. I tested it with drupalPod.
Hence, I'm setting it to RTBC.
I agree with @rkoller on most suggested changes but we are likely to address those in a follow-up ticket. I can open that.
Additionally, we will likely have to roll out the Drupal design systems everywhere once we are merged into core. So it might be postponed a little but it's coming. #331817 is not ready yet, but it is a good idea to reference it.

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

I was thinking on this items.
There is a button for add/install button but the items underneath i did not see them on the svelte file.
Those include

• Message if not compatible
• # Installs
• Stable
• Maintain
• Link to Drupal.org

tekNorah → credited bernardm28 → .

Since drupal already has a sidebar, I might copy some of its styles.

Some of the items on the right panel below do not yet exist. I imagine I should leave a placeholder.

bernardm28 → changed the visibility of the branch 3322594-project-detail to hidden.

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

After chatting with Mike Herchel about this. He recommended we get rid of the x altogether and use the standard HTML web search element instead of input.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/search

I wonder if tabindex="-1" would be good enough or would there be a better way.

Note: tabindex="-1" may be useful for elements that should not be navigated directly using the Tab key, but need to have keyboard focus set to them. Examples include an off-screen modal window that should be focused when it comes into view, or a form submission error message that should be immediately focused when an errant form is submitted.

https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/tabi...

hehehe thanks

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

The test failure with the phpunit functional test is weird on this one.
Not sure that error is related to the changes here.

No worries, take your time. If anything, I might contribute back this one back after DrupalCon.
I worked around it by targeting the css classes. Which worked great.

bernardm28 → created an issue.

Patch https://www.drupal.org/files/issues/2023-09-28/2902164-149.patch → and 4.0.0-alpha5 seemed to work for the most part except inside group fields detail tabs, the parent and children would not hide even when the option was checked. However, I was able to hide regular paragraphs fields based another text list or drop down paragraph field.

That said, the current MR does not seem to work with paragraphs. https://git.drupalcode.org/project/conditional_fields/-/merge_requests/4...
My assumption is that https://www.drupal.org/project/conditional_fields/issues/2856720 ✨ Support for Inline Entity Form Fixed , the work related to supporting inline entities stepped on this.
I tried to apply the changes from #149 to the current MR on DrupalPod and most of the code overlap and highlights are related to the inline entities MR changes ✨ Support for Inline Entity Form Fixed . It might be tricky to support both and then layout builder not step on each other as the code in here seems to be growing in complexity and has started to lose some of it separation of concerns. Maybe a good problem to have since that mean more community will get behind it but a tricky one.

This should be ready to be reviewed.
I tested it with DrupalPod 10.1.x and the standard theme.

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

Looks good, thanks for checking and fixing those.

We are also experiencing this issue. While testing the current MR, 2902164-controlled-by-fields I noticed it also reorders the field's in the edit form when said field is inside of a details tab.
My paragraph had
field
field number 2
details tab
details tab number 2
embeded paragraph.

After applying the patch and trying to hide details tab number 2 with field number 2. The layout of the form switch to this.

field
field number 2
details tab
embeded paragraph.
details tab number 2

It did not hide the details tab number 2 but it did move it around.

Tested this with DrupalPod 10.1.x, stable theme. Seems to work as expected.
Searching and hitting enter multiple times does not remove any of the search filters.
I also tested this by removing one of the default test filters. Removing the maintained filter and searching repeatedly works as expected.

Thanks for the quick turnaround
The fix seems to work and this issue to be fixed by it.
We are looking to migrate away from extlink into linkpurpose so I might have some follow-up tickets.

bernardm28 → created an issue.