@matthieuscarset

+1 for a solution to give instruction to the user once a recipe is applied.

I had this issue after installing the "Search" recipe on a fresh Drupal CMS install.

The installation works because the recipe's button now says "Installed" but - as a site builder - I have no idea what to do next.

Recipes should provide a way to display message and/or redirect the users to another page.

matthieuscarset → created an issue.

As a new user I m trying to customize my navigation but I cannot move blocks (e.g. I'm using Brave and/or Chrome browser).

+1 to fix this issue because it is now part of Drupal CMS and it is a blocker.

Either fix the drag&drop, display a "Show weight" field in the form somewhere or remove the drag&drop cursor with CSS maybe.

matthieuscarset → created an issue.

matthieuscarset → created an issue.

matthieuscarset → created an issue.

Adding screenshot

Happened to me several times today after a fresh install of Drupal CMS.

Creating a new node:page.

Clicking on `edit` from the canonical page, happening too as soon as the edit form is loaded in the browser.

Happened again creating a new node a few minutes after.

And again editing a translation of this node.

Seems to be random but also seems to be related to the "auto save" feature. Not sure.

I did not open an issue for this. Please do so @poker10 if you feel the courage to argument about displaying author/maintainer information.

I think you are having an issue with the web3php lib itself.

This module does not require anything else than drupal/key (see composer.json)

matthieuscarset → created an issue.

Thank you! It does answer my question for modules. I assume the behavior is the same for SDCs provided by themes - preventing themes from being uninstalled if it provides a SDC used in at least one XB field instance.

I think this will be an issue when we will upgrade Drupal sites with a lot of XB field instances - nobody will be able to uninstall old modules or themes because there will be old components using at least one of their SDC.

But this will happen in far future from now and there will hopefully be some

UX for automatically transitioning/migrating/upgrading to another SDC

To be more precise, I was expecting to see the avatar of the maitainers of the module in this sidebar:

Tried PB in a Drupal CMS instance locally and I was surprised that there is nothing about the authors/maintainers of a module in the page details.

I do not find info about this section in the previous comments on this issue 🤔 (I can't access the Figma to see if there's more details there).

Can we explain why we do not display the information of the authors and the maintainer(s) of a given module ?

I think it is valuable info to have.

Thanks a lot for the review.

I understand the config changes will happen in the other issue.

I've resolved comments in the MR.

I think there is nothing more to do.

MR ready for review.

matthieuscarset → created an issue.

Heading component implemented based on Figma (desktop only) in the attached MR.

I used CSS variables from Olivero parent theme whenever possible.

I am not sure about the design expectations. Here's what I did:
- Figma: 5 sizes/styles based on primary Olivero design system
- Me: I understand we want to decouple styling from semantic. I allowed users to select a size (H1..H6 html tag) AND also to select a size (h1....h6 CSS class) - this is what is also in the heading component from XB.

- F: Spans columns 3-10 on desktop
- M: I am not sure we can do it because `grid-columns` cannot be applied on the heading element directly - 🤔 do we want a wrapper div ? - plus when I tried it it looks strange to have the texts centered in the grid (see attached screenshot). There is no such things as grid-column: 3 - 10 elsewhere in Olivero too. There are 3 -11 but no 3 - 10 yet.

Looking forward to hearing from reviewers.

Thank you very much for the additional information.

I do have Drupal CMS installed with an xb_page for testing now.

I found out there is already a heading component provided by XB (e.g. [data-xb-component-id="sdc.experience_builder.heading"]) so I am confused about the expectations here.

After some discussion in Slack, I think the best I should do is to copy the existing component from XB module into drupal_cms_olivero, remove the unwanted complexity (i.e. no custom schema definition, only h1 to h6 - no div, no primary/secondary variations...etc), and implement the styling based on Figma.

I don't think I can ask questions in Figma asking here - do we have mobile versions of these heading elements ?

matthieuscarset → created an issue.

Willing to help. Assigning this to me.

Totally right, thank you for your reply.

It is better to have a D10+11 version for easy upgrade.

I am happy to make it in a new version 4.x

Release here: https://www.drupal.org/project/menu_manipulator/releases/4.0.0 →

D11 version here: https://www.drupal.org/project/menu_manipulator/releases/3.1.0 →

Thank you for your help.

Fix is shipped in the new release compatible with D11 only.

https://www.drupal.org/project/menu_manipulator/releases/3.1.0 →

Thank you for your help.

Fix is shipped in the new release compatible with D11 only.

https://www.drupal.org/project/menu_manipulator/releases/3.1.0 →

I thought the patches provided in the original issue were enough to replace menu_manipulator.

I see there is recent activities and uncertainties so I understand why we want a D11 release.

I'll make one asap

If I understood correctly, using translation means users will need to translate each field labels for every language of a site?

This is a serious amount of work. It makes the current situation worst IMO.

Just opened a MR to fix formatting of inline field label suffix per language with CSS only.

I just made two commits. I dont know why the MR show 450+ commits 🤷... something's wrong.

Need review.

@Eric good idea! I used a CSS variable:

:root {
  --drupal-field-label-inline-suffix: ":";
}

I join @aaronmchale here. I think the solution to content standardization is to provide a "universal" entity type: Storage is the best solution for this IMO.

@poker10 thank you for the reminder.

I actually double check this module again core 11.x and it became useless so I removed the compatibility with Drupal 11.

There are no reasons to maintain this module for newest Drupal versions since this change : https://www.drupal.org/node/3381495 →

Closing this ticket.

Updating the module description to let people know about this change.

That would be awesome @freelock, thanks !

I am not convinced about the necessity of implementing template suggestion for variants 🤔.

I think it is enough to add the `variants` object at the root of the component declaration.

IMHO it becomes confusing to mix the concepts of variations and display modes.

A variant prop is enough for developers to create an infinity of variations (e.g. includes, embed... simply thanks to Twig):

{# mysdc.twig #}
<div{{ attributes.addClass(variant|clean_class) }}>
  {% if variant == "averydifferentvariationrequiringanothertemplate" %}
    {% include "mymodule/mysdc/mysdc--extrathingstodisplayforthisverydifferentvariation.twig" %}
  {% endif %}
  {{ title }}
  {{ body }}
  {{ cta }}
</div>

BTW: Can we clarify if variants if a single value or if it is an array?

Oh, right

Maybe i mismatched things... i was thinking about adding this as a Condition in Blocks.

So we keep consistency with the rest of the admin UI.

Can we use a third party settings ?
I think it would be easier to use as developer AND as site builder

I think it is great to remove colons after label by default as it causes issues.

However using translations to manage it implies that we'll need to translate all labels if we want to remove colon (e.g. for Greek), add a space before (e.g. French)...etc. This seem to be less convenient than the current implementation in CSS - as of now, if it is easy to customize this with a one line CSS such as:
:lang(el) .field--label-inline .field__label::after { content: ""; }
:lang(fr) .field--label-inline .field__label::after { content: " :"; }

Marking as need review because I suggest we better provide custom CSS rules for the most languages possible in core + add example and documentation for developers to customize this colon for their sites' languages.

Bueno... I gave it another try but it is just too much work for the time I can dedicate to creating a CKE5 plugin. I think it is just not worth the time to try to create a specific CKE5 plugin to insert tooltips. I guess there is (or will be?) a premium feature for this provided by the CKE5 team.

Tooltip blocks work everywhere else - inserting in Twig, using a block, using arbitrary HTML...etc.

I am closing this issue because the CKE5 plugin won't happen.

For anyone trying to insert Tooltips in CKE5, I suggest to find a workaround such as:

• Using Entity Embed → and choose a specific view mode
• Using LinkIt with a custom Matcher (to retrieve block_content for instance) and a custom editor Filter to insert the tooltip
• Request this feature to the CKE5 product team 👷‍♂️

Happy coding!

greggles → credited matthieuscarset → .

Working on this issue again.

I have a solution to embed anything in a CKEditor5 WYSIWYG

I need to find a way to open a form like drupalMedia does.

Marking as active + assigning to myself.

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

I'd like to suggest an improvement.

The empty space alongside the logo in the navigation seems to be a "lost" space.

We should place the logo in the top bar and make it a full width component.

It will 1) improve the navigation sidebar design and 2) provide more space to add more items in the topbar.

Example in the capture attached.

I read the related issues and I think I see where this one comes from. We want to a standard way of declaring/using icons across Drupal (e.g. for menu links → for instance). We want to be able to declare it in YAML files. So we need a new plugin manager👌.

We are true YAML lovers.

I can see that we are building another SDC of icon.

It is clear the architectural decision has been made 👷‍♂️ so I don't really know what to say.

I wanted to point out some of the limitations that will certainly arise when real site builders will want to use icons.

Right, there would be no version control if icons are entities.

It would need to be a hook_update (or a recipe + action ? or default_content or a migrate process).

It is simpler to have icon files committed in core, I agree.

But I wanted to comment that we need to build a whole new set of functionality to handle all the future integrations (translation, permissions, categorizations, display...etc).

PS: as of now, don't we face the same issue ? We'll need to upload a new version of an icon pack if we want to update the files, right?

how do you start to write the update function for that in a way that works everywhere ?

Not sure but we have Recipes and Default content and Actions in core now.

how do you deal with that in a developer/user friendly way?

It is a challenge indeed but certainly easier to solver compare to the current suggested implementation. One solution out of my head: entity_reference_revisions.

I don't know if icons are not content but they are certainly a type of medias.

I just discovered this issue so I'm late in the game apparently... but I have a question.

Why can't icons be content entities?

Implementation could be much simpler IMHO.

Following the issue because I was actually implementing a custom template for Drupal messages. My use case is to use a single-directory component for message items. I naturally use the same logic as explained at the beginning and in the current MR: to pass the template to JS through the drupalSettings.

Unless I'm wrong, this is how we do things in Drupal for years. Let JS knows about things from the back via drupalSettings 🤷

Using a WebComponent (e.g. template) sounds like a good idea but It seems a bit too much to me to implement something different that what we're used to. If we go this way, doesn't it retire the whole Drupal JS API / drupalSettings in some ways? Does it means that we should use WebComponent for everything that can be rendered both in backend and frontend basically?

I +1 to pass the template with a placeholder through drupalSettings.

matthieuscarset → created an issue.

This is "the root cause" for this specific scenario (e.g. using SDC to theme Messages).

The feature request is still relevant for any other use cases such as printing mycomponent:xyz using a custom Drupal.theme.xyz in JS

The scenario which leads me to this issue was the following: How to use a SDC to theme Drupal messages individually?

Since Drupal 10.3 and this bug in particular 🐛 10.3 upgrade now missing status-message theme sugestions Active , there is no way for individual message to use a Twig template. Each Drupal messages are rendered via Drupal.theme.message.

Consequently there is no other choice than implementing a custom Drupal.theme.message method in a custom theme or a custom module and - if one wants to use a SDC to render messages - I don't see any other way than to pass the component output to drupalSettings to be reused in JS.

Example code in this snippet: https://git.drupalcode.org/-/snippets/214

matthieuscarset → created an issue.

Does it mean we cannot use span out of the box in CKE5 styles on Drupal 11 ?

I don't understand the technical decision being made at CKEditor. It is a shame we cannot convert elements to div or simply inject a div manually for styling.

Sharing this issue to all my Drupal relatives.

I have a dream we'll have a proper editing experience by the end of the decade 😅...

It is still impossible to convert a <p> into a <div> automatically by selecting from the Styles dropdown?

And if yes, why are this issue and the upstream issue marked as closed ?

Thank you for this issue! it just saved my day 😅

Dots on pictures are confusing.

I want to click them thinking they are navigation of a slideshow - which they are sometimes.

Not a slideshow

Not a slideshow

A slideshow

Yes and no, Pierre.

I use the requestContext to grab the base URL - as per this snippet as example - but I could certainly get it differently and thus avoid any dependencies.

Feedback from a Drupal developer visiting this new home for the first time.

First of all, I look great, I like the aesthetic and the browsing / scrollin navigation feels smooth.

Second reaction, scrolling back to top and reading the actual content, I feels a bit confused about the cover section. I would had loved to see a "real community" member instead of a stock picture. And the catch phrase feels mismatch with the target of the picture. The picture says we want to promote Drupal to UX people, but the title is focused on the power of Drupal for developers. IMHO this hero is a bit confusing.

1. My least fav suggestion : change the catch phrase.
2. My fav suggestion : Use picture of real Drupal community members - randomly or sorted on our karma/contribution.

Bravo to everyone involved in this redesign anyway! It's a big leap and it looks fantastic anyway.

My 2 cents, replying to the original use case explained in #2 (e.g. preprocess things for an external url).

Whenever I need a preprocess I use a custom Twig function / Twig filter.

Example below shows a custom filter is_external.

<a{{ attributes }}>
  {{ text }}
  {% if url|is_external %}
    {# ⇗ Print an icon here ⇗ #}
  {% endif %}
</a>

See this post for reference about how to create a custom Twig filter/function.

Unless I'm wrong, this resolves the needs of providing a preprocess function.

We can 1) redeclare the template of a SDC in our theme and 2) use a custom filter in this new Twig for the specific use case.

New release should fix this issue : https://www.drupal.org/project/calendar_view/releases/2.1.10 →

Thank you for reporting it.

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

Added related issue.

matthieuscarset → created an issue.

Could you give more details about the configuration of this view ?

I guess it is not related to Calendar View directly though - I guess you are trying to share filters between the view and attachment (see this answer on stackoverflow).

I guess you'd need to use the format_date() filter.

This is not an issue with Calendar View though.

Closing it.

I'm sorry I think I mismatched some things and my issue was not directly related to Easy Breadcrumb.

The latest version (2.1.7) works correctly even with fake routes.

Marking this issue as closed.

matthieuscarset → created an issue.

FYI I've added this file to keep track of the Architectural Decisions.

Thank you for opening this issue @mortona2k.

There was indeed an attempt to filter the calendar view at the View's query level with the query() method but it was very tricky and prompt to errors - in particular in combination with smart_date module and other date fields provided by other modules - with the table name and/or suffix (e.g. missing or extra suffix _value...etc).

After many trials, I decided to remove the filtering with query(). The site builder is in charge of building a sustainable View (i.e. do not try to load thousands of recurring events 😱).

There is a documentation page about setting the filters with an offset value such as -1 month and +1 month.

I hope it is clear now. Let me know if I can help explaining more architectural decisions.

I'm sorry about this issue but I don't manage to reproduce it.

I've created a new calendar view on a fresh D11 with smart_date_recur enabled.

I create a node with an "All-day" event repeating weekly.

The result is correct:

Marking this issue as "postponed" because we need a detailed step by step process to reproduce it.

I'm sorry but i don't manage to reproduce the error.

I installed the module on a a fresh D11 site. I created a new Calendar View and then I uninstalled the module without any issue.

There is no issue with the config too - as the view is deleted.

I can even reimport the configuration with drush cim and the module is reinstalled + the view recreated.

Marking this issue as Postponed. We need a detailed step by step method to reproduce it.

Thank you for this issue and for the work done.

I've updated the default stylesheet with basic styling using CSS variables from Gin.

We won't do much on 2.1.x because there is a rework being done in 2.2.x and all CSS files will be reworked anyway.

The Calendar View table looks better with Gin dark mode now:

Marking this issue as fixed.

Thanks @gge @lexfunk

I'm glad there is an easy fix with this MR for the core and another if you're using BEF (see #3 as commented above).

@fkohrt Thank you for explaining your use case.

I understand the expectations here and - unfortunately - the multiday module does not handle separate fields for start and end.

This is a great feature request. I'm updating this issue's title and summary to work on it whenever possible.

Thank you for your help testing this issue and please forgive the delay in answering.

I've tested again and there was indeed an issue with the previous date when using last day of last week.

I've merged with the change you suggested: first day of last week.

It's on 2.1.x and will be release soon.

No feedback but still merging this small change as it fixes the situation with translation based on my local testing.

Thank you for your help and please forgive the delay in merging this change.

Trusting the RTBC status, it's merged on 2.1.x and will have a new release soon.

matthieuscarset → created an issue.

Also can you test the same view rendering but with a default display such as unformatted ?

Looking forward to hearing from you @StijnStroobants.

I'd like to help contributing to this track with a focus on the Calendar display. I suggest to use the Calendar View → which is compatible with core and smart_date but it needs work to improve the display of complex events (i.e. events spanning on several days, display as day with hours or agenda list...etc).

This track is an opportunity to improve this module and vice-versa!

matthieuscarset → created an issue.

Is #config_target applicable on any element of the Form API ?
Is it tested against everything such as text_format elements ?

Is there any documentation about how `#config_target` should/can be used?

Agree. This module needs to provide configuration forms.

There are several places where it needs to happen AFAIK:

• View rows (?)
• Field formatters (?)
• Blocks
• Custom settings form in admin with some sort of an unlimited cardinality element (?)

I'm not sure what to focus on to help site builders.