🇫🇷France @Grimreaper

Hello,

Thanks @alexpott for the merge!

I will do the follow up.
Should I also publish the CR?

MR was not mentioning git conflict and tests are still green after rebase.

Back to needs review.

Hi,

Code review addressed from comment 15.

Ok for me.

Thanks and happy new year!

Hi,

Assigning to myself to fix git conflict.

Currently focusing on ✨ Add a style utility API Active before this one.

Also as this MR had not been merged for 11.3, I will:
- add other token types
- handle token references
- reinspect design token spec to see if it has evolved during the last months regarding the concerns of overrides and limited unit types.

Hello,

Thanks for the issue and MR.

Would it be possible to add a test please?

Hello,

Thanks for the issue and MR.

Would it be possible to add a test please?

Hello @grask0,

Thanks for your MR, I put some review comments.

And happy new year!

Child issue #3564677: Add a display_builder plugin API and selection → created regarding comment 5, 8 and 9.

grimreaper → created an issue.

Releases done:
- 8.x-1.26
- 2.0.0-alpha4

The only difference between the 2 branches is the removal of the tests and dev requirements of the php module as it is not D11 compatible.

Initially the goal of 2.0.x was re-architecture + D11 compatibility.

Now that 8.x-1.x is D11 compatible, and the re-architecture stagnates for more than a year and an half, I wonder if it should not be better to mark 2.0.x as unsupported until some consequent changes will be done on it. So that people stay or move back on 8.x-1.x, marked as stable. In this case, I would also remove the tests for php module on 8.x-1.x.

Or release 2.0.0, mark 8.x-1.x as unsupported, and wait later for a 3.0.x for the re-architecture (or make some progressive rework instead of a big bang if possible).

What are your thoughts?

grimreaper → created an issue.

Hi,

I made the change into other things in 🐛 not compatible with Drupal <9.3 Active .

Strange because the only time the "matomo/matomo" library is added on the page, it is in this if statement too.

So the drupalSettings should be also. present.

I will try another approach with putting default settings into the library.yml.

Hello,

Please provide steps to reproduce from a fresh Core install.

Feel free to re-open if needed.

Regarding the attached log file it seems that the problem may be related to the https://www.drupal.org/project/visitors → module more than related to the Matomo module.

Reproduced with Core 10.6.1.

Confirm the MR fixes the problem.

Merging and cherry-picking for 2.0.x.

Ok, I will test on Core 10.6

Deprecations for 8.x-1.x branch had been fixed in 📌 Manual Drupal 11 compatibility fixes for matomo Active .

But 8.x-1.x remains marked as compatible with D9 which is not supported.

I will create a new MR because the https://git.drupalcode.org/project/matomo/-/merge_requests/76/ is doing what had been done in the other issue but less efficiently.

I will also increase minimum requirements so no more need of the deprecations helper if possible.

Ok.

I have tested with Claro and haven't been able to reproduce.

Can you try with Core 11.3.1 please?

Hello,

Regarding the lack of availability to work on this re-architecture of the module + the PHP module feature on the 8.x-1.x branch (which is not compatible with D11) which prevents some proper clean up.

I propose to postpone this re-architecture.

- 8.x-1.x: I am cleaning up some bug reports in the issue then do a D11 compatible release. But kept in minimal maintenance.
- 2.0.x: cherry-pick the changes of 8.x-1.x, potentially increase the Core minimum requirement regarding deprecations found in the bug reports. Then do a stable release. So people would create new issue against this branch.

Those dev dependencies had been added on 2.0.x.

Adding on 8.x-1.x

On a fresh standard install of Core 11.3.1 with:
- 8.x-1.x: https://git.drupalcode.org/project/matomo/-/commit/533adcfc3afe18aade593...
- 2.0.x: https://git.drupalcode.org/project/matomo/-/commit/252fbafad2f8ae5d93b49...

I do not reproduce the problem.

I think you may have other modules which could interfere with JS execution/library dependencies.

Fell free to re-open if reproducible on latest Core versions.

Hello,

What is the last status of this issue?

Hi,

Thanks for the issue and the patch.

Please provide the change as a MR.

Shorter title

Hello,

Closing this issue in favor of ✨ Is there an upgrade path from Drupal 7 to Drupal 10? Active as the other is older.

Hello,

Unassigning, I will focus myself on Styles API in Core + UI Styles 2 and related issues in the ecosystem.

Hello,

Do you still have the problem?

I think this is unrelated to the Matomo module, and just occurred for any newly enabled module on your website, just the next one enabled was matomo analytics tag manager.

Hello,

Did the error occurred when trying to save the settings form? If yes, what was the config you were trying to save?

Hi,

Thanks for the issue and the patch.

I am checking it, trying to reproduce.

Why is the issue in "needs work" if there is a patch? If the patch/MR is ready for review, it should be "Needs review".

Also please provide MR instead of patch. Use patch only for Composer.

grimreaper → created an issue.

@catch I completely agree that it could be a big change and need to synchronize the change with the different display builder modules. So, to handle in its own issue at its own speed.

grimreaper → created an issue.

Another thought I had about proposal from comment 5, is those "display_builder" plugins could implement a method to react to the change of selected display builder for view mode.

The method could have as arguments $previousBuilderId, $previousBuilderData. That way the plugins could optionally do data/config migration from one builder to it.

Would it be also the occasion to standardize "override per content" feature?

- Layout Builder allows to override the full view mode (or default if full is not enabled)
- Display Builder allows to override any view mode by allowing to select the field to store data into

Hi,

Thanks for the issue and the proposal.

Would it ease flexibility and be future-proof that instead of "just" enable/disable on the view mode (and why not also form mode in the future :)), it should be a select list with the different display builders available:

- Disabled (empty value)
- Field UI
- Layout Builder
- Display Builder
- Canvas
- (other)

I have not checked but I guess then we could declare the display builder as plugins for discoverability, plugin methods/interface could provide the routes for local tasks, admin actions, etc. dynamically.

Hi @smustgrave,

Sorry, as I have issue notifications disabled, I missed your comment.

You mean commit a version of the bootstrap library in the repository? No, we should not commit external assets.

Also users have the choice to use local or CDN in the theme settings, but for SASS compilation, the bootstrap library files should be retrieved locally.

Hello,

I applied the suggestion of the code review.

Helping to push this issue forward to unlock 📌 Drupal 11.3.0 is released - update variant variables Active which I need for new branches/releases on a bunch of projects I maintain (and don't want to put a workaround in gitlab-ci.yml which I will have to remove soon ;))

Thanks everyone for your work on Gitlab CI!

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

Remote SVG files are not supported for security reasons by Core icon extractors, svg and svg_sprite.

So not possible to do this feature request.

Mentions that svg_sprite extractor does not handle remote files.

Thanks for the issue and MR.

Looks good to me.

Hi @smustgrave,

If you can give the MR a try in the coming week (15th to 20th) before I merge it, it would be great!

theme_settings is deprecated

Unchanging:
- templates/system/details--accordion.html.twig: Not possible to administer the heading attributes in accordion_item
- templates/ui_patterns_library/ui-patterns-component-table.html.twig: component library will be reworked in UIP 2.1/2.2

Ok, MR updated.

grimreaper → created an issue.

grimreaper → created an issue.

Hi,

Thanks for the issue and MR.

Same problem applies for tooltips and popover if I remember well.

Those small JS scripts had not been implemented yet because it may interfere with cases where a manual triggering is requested. I remember an MR were I tried something like that 1 yeat ago but don't remember for which issue.

So in addition to the JS script, maybe we need to add a prop on the toast component to add an HTML attribute for "auto" initialization?

Need to wait for UI Styles 2 (/UI Skins 2), the theme settings will be changed.

Without reply, marking as fixed.