🇺🇸United States @bernardm28

I agree with most of Pier's additions, but one thing. clean_unique_id provides a more semantic version than random(), and it's a better experience for the end user.
I would argue that even if it violates the component state, there's no better alternative. What would be a downside of having it in practice? Would it not get cached as good, or is it more of the principle behind it?

Seems like site-hero__desc {grid-column: 2 / span 3} would do it.

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

volkswagenchick → credited bernardm28 → .

Pretty sure this likely was fixed along something else.

teknorah → credited bernardm28 → .

changes wording to modern Drupal and a range.

https://www.drupal.org/project/name →
something like that, that included organization name and position would be great.

The social media module addresses one aspect, but the extra information about a person would be helpful when displaying information about them.

It be nice to add the following fields.
First Name
Last Name
Home Town
Title
Organization

Links
Drupal.org Profile
Twitter Profile Link
Bluesky profile link
Mastodon profile link
Personal Website Link

This would be great at wil simplifying providing content and allowing drush si --existing-config to work.
--existing-config does not work with standard only minimal and event_platform makes it harder to switch profiles harder since it depends on a hook_install.
hook_install is the reason --existing-config does not play well with the standard install profile.

Theme recipe: A recipe that adds content to a site based on a specific theme.

This makes it harder for the theme recipe to cleanly rebuild the site from config and reapply its content. So some items have to be handled with more care and it's easier to start from a good configuration.

mradcliffe → credited bernardm28 → .

mradcliffe → credited bernardm28 → .

Uff it's been so long, it might have been specific to that scenario or user error.
I will take a look next week and close iit if i can't replicate it.

volkswagenchick → credited bernardm28 → .

volkswagenchick → credited bernardm28 → .

volkswagenchick → credited 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...