bernardm28 → created an issue. See original summary → .
bernardm28 → changed the visibility of the branch 3526495-meta-issue-- to hidden.
By adding an updated twig template, we can get this behavior on the homepage
First step here seems to be:
Modify the sponsor side block so it won't display on the homepage or the sponsors page.
We don't need it on the sponsors page, as it would be a duplicate, like the image below.
This is how that config file should look after this change.
The second step is
Add a full-size homepage sponsors block.
Adding said block will make it easy to see sponsors fully featured on the homepage.
bernardm28 → created an issue. See original summary → .
After reading a bunch of docs, I found that the reason the promoted to front page section comes up is because we haven't assigned a node for the front page. Assigning any node gets rid of it.
that can be done on /admin/config/system/site-information.
I guess is not every day I use a default page as the front page.
This issue is related to https://www.drupal.org/project/event_horizon/issues/3547107 📌 Hero title should only include year if that option is checked. Active
field_event_name_display was suggested as an alternative name so that the field name for the taxonomy won't be the same as the config field name, even though they share two properties ( one boolean and the other a string).
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.