@miiimooo

miiimooo → created an issue.

This should be closed since it has been committed https://git.drupalcode.org/project/drupal/-/commit/c61d707ed4 to 10.2+

Re-rolled @diegors patch from #5 for core 10.2

Adding a re-roll of the patch in #13 for 2.1.0

The patch in #27 adds some check which is not part of this patch

miiimooo → created an issue.

Hi @arnalyse, I think it should be possible to roll your own using this

https://github.com/Lullabot/storybook-drupal-addon/blob/8a6690e09f6471b9...

and this https://github.com/Lullabot/storybook-drupal-addon/blob/main/src/manager.ts together with the guide on writing plugins

The folks at lullabot and e0ipso might be better at helping with this

The solution outlined in #3362451-16: [upstream] [Style] Allow CKEditor 5 to *create* a

directly (instead of first

, then adding a class) → works, thanks @aludescher

To summarize, it uses a core patch to allow any tag in the ckeditor5 heading plugin, not just PS. in my use case I added an option for support for formatted text. I tried to add that then in the custom list for source editing tags so the editor wouldn't just remove them. But the text format configuration was clever and produced an error on save, since the tag is already supported by the CodeBlock ckeditor5 plugin. As a workaround I found out adding the tag with an arbitrary class bypasses that check and makes any tag work that is added in the alter hook.

Tracing this down my entity_embed/embed stack..

miiimooo → created an issue.

miiimooo → created an issue.

@arnalyse thanks for this fix. It allows to select a different theme from the site default theme like this:

# .storybook/preview.js

/** @type { import('@storybook/server').Preview } */
const preview = {
  globals: {
    _drupalTheme: 'my_theme',
  },
  parameters: {
...

miiimooo → created an issue.

miiimooo → created an issue.

Here is the patch re-rolled for 3.1.2

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

miiimooo → changed the visibility of the branch preview_link-3124785-reroll-68f89a1 to hidden.

Consider a case where there is a lot of legacy content that has embedded JS and that you add CSP to in order to improve security.

In this case, you currently have to allow things like `script-src 'unsafe-inline'` globally, and other things like JS libraries that are loaded from CDNs for instance.

If it was possible to override this on a per-page basis, the security situation would be much better

miiimooo → created an issue.

miiimooo → created an issue.

miiimooo → created an issue.

Attached is a patch that sets responses from the preview link controller to max-age=0, making them un-cacheable.

I'm open for better suggestions but in many cases this will be the desired behaviour. The impact on performance should negligible as preview-links are mainly shared in smaller groups

miiimooo → created an issue.

miiimooo → created an issue.

miiimooo → changed the visibility of the branch 3.x to hidden.

miiimooo → changed the visibility of the branch 8.x-3.x to hidden.

miiimooo → changed the visibility of the branch 3416902-port-3.x-for to hidden.

miiimooo → changed the visibility of the branch 3416902-port-3-drupal10 to hidden.

This works but referencing the commit instead of a working branch is ugly and really should avoided.

The underlying problem is that in 3.x two more commits were added (109da268 and 15ebbd47).

The first one of them introduces breaking changes since it moves everything from build/ to dist/

I would argue that this change warrants a new branch and that it should be removed from 3.x

The second change makes a path change which I'm not convinced it is required by 9.5 →

Please remove this also from the 3.x branch. Unless you can find a reference where the reason for this change is documented

I spoke to soon. After upgrade to D10 I realised that dev-4.x already includes a lot of the refactoring.

Here is the D10 patch re-rolled for 3.0-alpha1

The work for this was already done in the 3.x and 4.x branches.

This seems to work for now:

composer require drupal/components:'dev-3.x as 2.4.1'
composer require drupal/prototype:dev-4.x

miiimooo → created an issue.

Lower priority since doing this in the UI and exporting to config (stabel->stable9 in core.extension.yml) works

miiimooo → created an issue.

Here a quickfix if you need to add this in your project while there is no progress on this issue (since ckeditor4 is deprecated I doubt there will be much progress)

    "repositories": [
        {
            "type": "package",
            "package": {
                "name": "ckeditor-plugin/a11ychecker",
                "version": "1.1.1",
                "type": "drupal-library",
                "dist": {
                    "url": "https://download.ckeditor.com/a11ychecker/releases/a11ychecker_1.1.1.zip",
                    "type": "zip"
                }
            }
        }

composer require ckeditor-plugin/a11ychecker

Check your (web/)libraries folder for presence of the a11ychecker folder

miiimooo → created an issue.

miiimooo → created an issue.

miiimooo → created an issue.

+1 from me for this patch.

I have added an example project that is useful when there are many languages installed on a site here https://www.drupal.org/sandbox/miiimooo/3414705 →

The project depends on this patch at the moment

@plopspec thanks for reviewing. I've added the post_update hook now as you suggested now and confirmed it's working

miiimooo → created an issue.

Thanks for reviewing @marcelovani . I'm not sure I made it clear enough what this simple patch achieves. In addition to what the module does so far, that it allows selecting from a list of paragraph types, it makes it possible to preset a paragraph type in an entity embed button in the editor. This works really well. The change is also minimal but maybe needs better documentation.

Use case 1 (original)

this is still supported and works like before

Use case 2 (added by patching)

This is the new functionality.
When using this embed, ckeditor jumps directly to the entity add form of the bundle

Okay, the title could be improved..

Change to 2.0.0

Fixed the "reset" warning and created a new MR

miiimooo → created an issue.

I can confirm that the errors in Google Search Console are gone.

Fixed the namespaces - do not use https see https://support.google.com/webmasters/thread/242628204?hl=en

MR created

miiimooo → created an issue.

@ben.hamelin Have you tested wit the re-rolled patch from #96? I did that re-roll because previous patches were broken after upgrading to 10.1

Updated the patch to add a check for when getRouteName returns NULL (e.g. running in cron)

This changes also the temporary://path_redirect_import/migrate.csv in the migrate yaml config

miiimooo → created an issue.

miiimooo → created an issue.

The patch https://git.drupalcode.org/project/drupal/commit/c61d707ed4.patch applies cleanly against 10.1

    https://git.drupalcode.org/project/drupal/commit/c61d707ed4.patch (3108102 - Destination url query param affects on form translation delete submission)
patch '-p2' --no-backup-if-mismatch -d 'web/core' < '/tmp/652fa878032e9.patch'
patching file modules/content_translation/src/ContentTranslationHandler.php

patching file modules/content_translation/tests/src/Functional/ContentTranslationRevisionTranslationDeletionTest.php

patching file modules/content_translation/tests/src/Functional/ContentTranslationUITestBase.php

patching file themes/claro/claro.theme

Hunk #1 succeeded at 419 (offset 5 lines).

The patch in #41 preserves the functionality itself and replaces the deprecated `file_create_url` function but it does not contain some of the code form the previous patch #39: there are no form element to set the icon file location.

Re-rolled the patch in #39for compatibility with Drupal 10 (CKEditor 4)

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

Is there any point in marking 6.0.x-dev as compatible with Drupal 10.1.x?

I can imagine people upgrading their sites going through the upgrade status recommendations and upgrading this blindly to the admittedly alpha version thinking it will not break their site. They would be in for a surprise when deploying such an upgraded site.

If on the other hand disabling features as outline in #23 makes the upgrade "safe", then this could go into a hook_upgrade_10100

miiimooo → created an issue.

miiimooo → created an issue.

@HeikkY closing this - like I said I left this here since it's only against RC6 but removed in dev. Thanks for reviewing

miiimooo → created an issue.

Re-rolled patch from #83 to apply cleanly against 10.1.x

With the patch in #70 against 9.x I got this for example for an exposed views block:

<!-- THEME HOOK: 'form' -->
<!-- FILE NAME SUGGESTIONS:
   * form--audio-series-listing--block-1.html.twig
   * form--block-1.html.twig
   x form--audio-series-listing--block.html.twig
   * form--block.html.twig
   * form--audio-series-listing.html.twig
   * form.html.twig
   * form.html.twig
-->

With the latest patches here against 10.x I only get

<!-- THEME DEBUG -->
<!-- THEME HOOK: 'form' -->
<!-- BEGIN OUTPUT from 'themes/contrib/stable/templates/form/form.html.twig' -->

Going back to #83 against 10.x brings back the theme suggestions (form---VIEW_ID--DISPLAY_ID.html.twig,..) (though it doesn't apply cleanly due to the patch for core/modules/aggregator/src/Plugin/views/row/Rss.php)

Something went missing in #92

The core/jquery.once.bc library got removed in D10

New patch attached

Patch in #2 #3384121-2: Javascript once issue in Drupal 10 → and in #4 #3384121-4: Javascript once issue in Drupal 10 → don't apply - tabs.js in 3.4 and in 3.x has no "attach" method https://git.drupalcode.org/project/field_group/-/blob/8.x-3.4/formatters... and https://git.drupalcode.org/project/field_group/-/blob/8.x-3.x/formatters...

I am seeing this issue in D10 with tabs at least too

In 🐛 RouteEntityUuidCacheContext Fixed the dependency on RequestStack was dropped. I changed the target to 1.0-rc6 since it's the last version that has the RequestStack in it.

It might still be useful for some people so I'm leaving the patch here.

miiimooo → created an issue.

After upgrading to Drupal 10 with the patch from MR17 I got a deprecation notice for the Drupal\Core\Http\RequestStack

I've added a commit 54abd2 that makes the patch Drupal 10 compatible in MR17

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

Thanks for all the feedback.

For now I've kept the dependency on the library. Instead I have made a new release in github release 3.0.0 and changed the dependency accordingly.

I have rolled a new release of this module for Drupal 10 compatibility and this is ready for testing. To install use

composer require drupal/matomo_reporting_api:3.0.x-dev

This depends on Guzzle 7

If you need to the flexibility to depend on Guzzle 6 or 7 use

composer require drupal/matomo_reporting_api:"^2.4||3.0.x-dev"

^^^ this commit 3b9109d7 shows what this would look like. I have taken it out from the MR6 though to sort one issue at the time

The MR fixes the D10 `core_version_requirement` and `phpunit --list-groups` but not the tests. The deprecation of the at() (https://github.com/sebastianbergmann/phpunit/issues/4297) looks tricky to fix. But maybe this is good enough as it is to go into 2.x-dev and solve the tests separately (see also #3217717: Replace usages of the at() matcher, which is deprecated → ), automated tests are broken as it stands with the old code base, not sure what the problem is there https://www.drupal.org/pift-ci-job/2776370 →

I'll wait a little while for objections to merging MR6 and splitting fixing the unit tests in case it'll break in D10 sites.

In a more daring proposal, I am thinking of moving the code from the separately pfrenssen/matomo-reporting-api into the Drupal module, mainly to reduce maintenance and complexity. I can't see that the lib is used in any other project.

@pfrensen if you can add me as a co-maintainer I can dedicate some time to this since we are using this module

I was wondering the same. After a bit of experimentation this worked (based on your suggestion as a practical example):

$query = "UPDATE {node} n SET n.langcode = 'fr' where n.nid=1";
$stm = Drupal::database()->prepareStatement($query, [], TRUE);
$query = Drupal::database()->query($stm);
$affected = $query->rowCount();

If there is another way I would be interested to hear.

Attaching updated patch for compatibility with 1.6.0

For this to work it also needs the `core/jquery.once.bc` library

Attached updated patch.

Attached a patch to add the dependency in the libraries yaml file

The patch will work for Drupal core versions greater 9.2 - see [#3158256] so this should be applied to a new 9.x branch

miiimooo → created an issue.

Thanks for offering to help with this. I have added you to the maintainers list

Attached find a minimal patch