@matthieuscarset

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 suggestions Postponed , 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.

Was there listening with great attention. Thanks a lot for this meetup!

Pushed the quickfix from #3 into a PR thus marking this issue as NR.

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

For the record, it is possible to disable the theme debug output by calling the Twig service right before your rendering.

For instance :

      $node = \Drupal::entityTypeManager()->getStorage('node')->load(1);
      $build = \Drupal::entityTypeManager()->getViewBuilder('node')->view($node);

      // Make sure no debug output in XML.
      \Drupal::service('twig')->disableDebug();

      $output = \Drupal::service('renderer')->renderPlain($build);

matthieuscarset → created an issue.

matthieuscarset → created an issue.

Sorry I'm not sure.

Rebasing `issue/drupal-3306820:3306820-show-machine-name` over `11.x` ?

This gives a 2k files conflict.

I don't think failures are related to this code.

All errors seem to be related to something broken in Umami.

Example of a current failure: https://git.drupalcode.org/issue/drupal-3306820/-/jobs/1721378

It's a shame to miss a minor version 10.3 because of an unrelated broken part 😓.

How should I proceed to move this issue along?

@Dan_Rogers can you confirm #2 helps you solve your situation ?

For the time being as a workaround one can use drupal-lenient to install this module.

// composer.json
"extra": {
    "drupal-lenient": {
        "allowed-list": [
            'drupal/adminimal_admin_toolbar'
         ]
    }
}

Hope it helps other migrating to D10.

matthieuscarset → created an issue.

I see. Thank you for explaining.

IMHO it is more of a feature to request on Views, not on this module.

But it is interesting to have a list display for calendars anyway for other issues - such as a11y and responsiveness.

Leaving this as active if others want to jump in to provide more context and/or work on a new Calendar View style plugin extending the Unformatted list for instance.

Thank you @drupgirl ! I'm glad this module helps.

If I understand correctly, I think you want to have a new display to show events as a List.

If yes, this is not related to Calendar View specifically but to Views displays.

You can achieve it easily by creating a new display on your View and selected the a list display. Then you can add link to other displays in the header for instance, just like I did on the Drucal.org page (see attached screenshot).

Please let me know if this is what you needed.

Oh, merci @pameeela. DDEV took a clear lead indeed! I guess I was wrong about the proportions 😄 Long live DDEV !

+1k to make it simpler to kickstart a Drupal with recommended Docker-based development tools 🎉 !

But I'm surprised we want to push one tool over the other 🤷.

I read comments expressing personal tastes but I didn't read any actual statistics about usage. Some numbers are available in this survey about Drupal developer local environments for instance. We see that the diff is very small (350 DDEV users vs 306 Lando users) but DDEV + Lando >= 50% of respondents.

If we want to cover the 80% use case as we often do, we should recommend at least both - they are different but both great anyway.

PS: I use Lando for years and DDEV since last year for different project/teams. IMHO Lando is better for newcomer because it is transparent. DDEV is more Drupal-oriented, with a learning-curve, because of its file structure. I'd like to show the diff between Lando and DDEV thought for a newcomer (see attached screenshot).

• Left file tab: the one-file Lando config after executing lando init --recipe drupal10
• Right file tab: the root config file after ddev config --project-type=drupal --php-version=8.3 --docroot=web

---

I hope we produce very easy install process to avoid our learning-curve effect #69.

Let's support diversity and recommend to try both tools 👐

Thank you for your reply.

I still see 41440 pages in the JSON feed, which rounds up to 2,072,000 user accounts.

Is this accurate? 🤔

There is a new `calendar_timestamp` filter available (on 2.1.x dev branch for now).

You could add this filter to the view - without necessarily exposing it - and it should keep track of the URL query parameter.

You should stay on the same "page".

Hope it fix the situation.

Could you please review and let me know? Thanks!

Marking as fixed. Closing the issue.

Feel free to reopen if needed.

Just tried the patch but unfortunately I haven't found the way to select the view display I want by default.

🤷Is this just for a media library in CKEditor?

I wanted to have the Table display by default - instead of Grid - when users open the media library from an entity_reference field (see attached capture).

Yes of course. Thank you for your help.

Let me know when/how I can help to take this plugin further.

Thank you for your reply @mparker17

I agree it would be better to have this plugin in Domain Menus. I originally proposed this plugin there indeed (see referenced issue) but it was "rejected".

I could publish a new module specifically for this sitemap plugin but if you offer, i am happy to maintain the plugin here.

Let me know what you prefer.

Test failing because of an unrelated issue I think (e.g. SitemapBookTest).

Unassigning this issue from me.

Ready for review.

Understandable 🫡 I've opened this issue on the sitemap module ✨ Compatibility with Domain Menus Active to support compatibility with Domain Menus

Thank you for your reply.

MR coming

matthieuscarset → created an issue.

matthieuscarset → created an issue.

matthieuscarset → created an issue.

matthieuscarset → created an issue.