I'm interested; if you could add me, that would be great. I will dm you the email.
bernardm28 → created an issue.
bernardm28 → created an issue.
addded a note about php limits and the white screen of death that can happen with a white line before a PHP opening tag on a file.
I tested this on the tugboat link and a clean throwaway Drupal 11 site.
The top toolbar displays properly after this fix and no longer remains unrendered.
This issue is currently solved by the https://www.drupal.org/project/event_platform_people → recipe. It should do this and more.
bernardm28 → created an issue.
Oooh, I thought this was everywhere, but if it is just on the session workflow, that makes sense.
I imagine this includes the training as well, and other related activities.
bernardm28 → created an issue. See original summary → .
Nice, thank you.
teknorah → credited bernardm28 → .
It would be great to start with a recipe that adds at least the home and 2 other nodes.
I would work on adding that, so the first time you enable event horizon you get a bit more than the picture above.
It seems like this issue happens because we are missing a requirement on the core
layout_builder module. Which is not installed by default.
However, installing that fixes that issue, but brings another one.
Configuration objects (user.role.authenticated) provided by event_platform_sessions already exist in the active configuration
That issue is solved by moving the user.role.authenticated from event_platform_sessions from the install folder to the optional folder inside config.
I also tried the ddev composer require 'drupal/event_platform:^2.0.x-dev' but ran into the same issue.
bernardm28 → created an issue.
bernardm28 → created an issue.
bernardm28 → created an issue.
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.