The input has a template suggestion but we really need one for form-element-label.html.twig
The label itself is what holds the image but there are not suggestions for it.
Not at least that i could find.
A step closer to the Figma file. Not sure it's the ideal solution, but it's low complexity.
We might need a template suggestion for form-element-label.html.twig that's a bit better, though.
bernardm28 → made their first commit to this issue’s fork.
If we reuse said SVG, then it's nice to point to a file. Easier to swap and what not.
Otherwise, I guess it would not make much of a difference.
The length of text varies quite a bit based on the language label.
The longest is the one below.
The more challenging part is getting the Chevron icon to overlap, as the selected text is longer.
It works ok now, but could be better.
bernardm28 → made their first commit to this issue’s fork.
One issue for the event platform
https://www.drupal.org/project/event_platform/issues/3548239
📌
Add a boolean to display an event name
Active
and one for the event horizon.
https://www.drupal.org/project/event_horizon/issues/3547107
📌
Hero title should only include year if that option is checked.
Active
bernardm28 → created an issue. See original summary → .
We should also not display the welcome h1 block, which is part of another block that displays upon install.
It seems that these changes are also needed to avoid this.
instead of this code on web/themes/contrib/event_horizon/components/site-header/site-header.scss
ol.breadcrumb__list li a {
transform: skewX(30deg);
display: inline-block;
}switch it to this.
ol.breadcrumb__list li a {
display: inline-block;
}
And then add the following to this CSS class.
ol.breadcrumb__list li:first-child a {
transform: skewX(30deg);
}
Event horizon issues link to this meta.
https://www.drupal.org/project/event_horizon/issues/3546235#comment-1626... →
matthews → credited bernardm28 → .
volkswagenchick → credited bernardm28 → .
nicxvan → credited bernardm28 → .
Back to the Basics: Releasing a recipe on drupal.org
benjifisher → credited bernardm28 → .
added simple and complex websites. Removed reference to web apps, and that might make it more confusing for those looking for a simple explanation.
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.