🇺🇸United States @bernardm28

Both are valid solutions, but DrupalCMS is leaning more on attributes [class].
https://git.drupalcode.org/project/drupal_cms/-/merge_requests/374/diffs...
So I would say preference goes towards class attributes.

Before this fix, without the !important

After the fix with [class]

To overcome some experience builder past bugs, we would add an attribute to increase the specificity.
Say.

.js-show[class] {
    display: block;
  }

https://developer.mozilla.org/en-US/docs/Web/CSS/Attribute_selectors
That could make it more specific than Claro and avoid using !important

We could add this the same way Stats was added, but with a hard limit of 3 elements. Or we could let people add as many elements as they want, and Twig will only parse the first 3 due to space constraints.
thoughts?

Maybe the first one should be called Year instead of name.

event_horizon/components/site-hero-25/site-hero-25.twig

I see it coming from there.
It's an interesting concept

<h1 class="site-hero__title">
{{ event_details.field_event_name.value }} {{ current_event.name.0.value }}
</h1>

But I wonder if we should pick one or the other, as I was just tempted to put the same on both. Either that or change the other or add labels.

bernardm28 → created an issue.

bernardm28 → created an issue.

Nice, that's great to hear. We might be able to add some docs about it to make it easier for others who might try to do the same.

Which scenarios do you have in mind?
Doing so would mostly be reconfiguring the SDC components to map whichever fields they provide the data.
So it's possible, but it's more challenging than an out-of-the-box experience as the event_platform integration provides.

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.