🇳🇱Netherlands @timohuisman

Can confirm that it resolves our issue aswel.

Before

After

Attached is a patch with a snapshot of the MR, so it can be safely used with composer-patches.

timohuisman → created an issue.

8.x-1.5 → is fully compatible with Drupal 11.

Thanks for your contribution!

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

Thanks for your contribution! I've merged the MR and will tag a new release later today.

+1 RTBC. Attached is a snapshot of MR!13, so it can be safely used with composer-patches.

I've contacted the maintainer in the #d11readiness Drupal Slack channel for a new release. He'll look into this in a couple of days.

+1 RTBC. I've contacted the maintainer through the contact form on their profile for a new release.

Attached is a snapshot of MR!7 so it can be safely used with composer-patches.

Attached is snapshot of MR!6, so it can be safely used with composer-patches.

+1 RTBC. I've contacted the maintainer on Slack for a new release.

It seems to work fine with Drupal 11.

Attached is a snapshot of MR!25, so it can be safely used with composer-patches.

+1 RTBC. I've contacted the maintainers on Slack for a new release.

tunic → credited timohuisman → .

I've updated MR!25 with the suggested changes.

Attached is a patch file with a snapshot of the latest version of the MR, so it can be safely used with composer-patches.

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

+1 on RTBC.

Attached is a patch containing the current state of the MR, so it can be safely used witch composer-patches.

I've created a MR so we can see if the tests are still green.

timohuisman → created an issue. See original summary → .

The issue seems to be resolved, the po file for 10.4.1 contains all the translations (based on the file size of 1.6mb).

We don't know exactly what went wrong. We fixed it for now by offering a new translation and then forcing a new version of the Dutch Drupal Core po file.

I've reached out to the Dutch community on Slack, as mentioned on https://localize.drupal.org/translate/languages/nl

timohuisman → created an issue.

The patch from #22 seems to work with the MR from 🐛 Node Type / Entity bundle conditions evaluation is wrong when context is not provided Needs work .

I've added a condition to the page title block so its only visible on "Articles", visited the 404 route and still saw the page title. Without the MR from 2823432 the page title was hidden.

Attached is a snapshot of the current state of MR 4610, so it can be safely used with composer-patches.

I came across this issue through ✨ Add support for negating node type(content type) condition for block visibility Needs work , which seems to work in combination with MR 4610.

However, I've tried to test MR 4610 standalone, but I'm not sure what it should resolve. If I understand this issue correctly the MR should resolve the fact that blocks are hidden on non-node-type routes when there is a node bundle condition configured. I've add a condition for "Article" nodes to the page title block, visited a non existent page so I could see the 404 page but the page title was still hidden.

The patch from #7 causes deprecation errors;

Deprecated function: stristr(): Passing null to parameter #1 ($haystack) of type string is deprecated in Drupal\csp\EventSubscriber\ResponseCspSubscriber->Drupal\csp\EventSubscriber\{closure}() (line 177 of modules/contrib/csp/src/EventSubscriber/ResponseCspSubscriber.php).

This patch contains a snapshot of MR10177 so it can be safely used with composer-patches.

I've tested #9 with drupal/core:10.3.7 and drupal/ckeditor_details:2.1.0-beta1.

The issues mentioned in #7 are resolved. I've created a details element with a few different tags and they all stayed in the expected order after switching between the 'source editing' modus.

Back to RTBC.

I've tested the changes from MR11 against drupal/core 11.0.7 and it works as expected.

The steps I took;

1. Fresh Drupal installation with drupal/recommended-project:^11
2. Used mglaman/composer-drupal-lenient and cweagans/composer-patches to install the patch
3. Enabled the administerusersbyrole module
4. Verified that I can still add new users (resolves #11)
5. Verified that I can only assign roles which I'm allowed to

I've tested the changes from MR11 against drupal/core 11.0.7 and it works as expected.

The steps I took;

1. Fresh Drupal installation with drupal/recommended-project:^11
2. Used mglaman/composer-drupal-lenient and cweagans/composer-patches to install the patch
3. Add the file plugin to the editor
4. Verified that I can upload a file

I've send the maintainers a message in Slack. Would be nice if this issue lands soon.

timohuisman → created an issue.

Thanks for taking the time to create a issue and for sharing your icon. I agree that I would prefer if we could first take a look at fixing the existing icon. I do think that it could be slightly updated so it matches the icons from CKEditor5 beter (thinner lines).

I have updated the summary to reflect the remaining steps. I have hidden the files that have nothing to do with the chosen solution to avoid confusion. Assigned credits for the work done so far.

Thanks for your contribution!

timohuisman → changed the visibility of the branch 3487022-add-title-and to active.

timohuisman → changed the visibility of the branch 3487022-add-title-and to hidden.

References to "Piwik Pro" in the codebase are changed to "Piwik PRO". Keep in mind that there are also some references on the module page that needs to be changed.

timohuisman → created an issue.

timohuisman → created an issue.

I'm interested to work on this issue. I'll try to work on this in the coming weeks.

I like the examples from the IS and #5. I think it would be helpful if the added twig blogs have predictable names. Should the wrapping block always have the same name, something like {% block base %}, or should it be specific to the entity, like {% block node %}?

timohuisman → created an issue.

Thanks! Changed the filename and now the tests have run and succeeded.

After running ddev start you should be able to run for example phpunit tests local with ddev phpunit

timohuisman → created an issue.

I've added some tests. It's actually the first time that I've written tests for a module, so let me know if somethings needs to be handled differently.

timohuisman → created an issue.

timohuisman → created an issue.

timohuisman → created an issue.

The MR contains the simplified proposed solution, I'm interested if this is something that is wanted in the module.

timohuisman → created an issue.

Followed the best-practices listed on https://www.drupal.org/docs/develop/managing-a-drupalorg-theme-module-or... → . Chose to place the introduction above the table of content because it felt more logical in that order. The listed examples are not consistent where the introduction should be.

timohuisman → changed the visibility of the branch 3482195-readme-md to hidden.

I've updated the issue summary, fixed the phpcs warnings and updated the readme. I'll try to write some test later this week. I've also created 📌 Replace README.txt to Readme.md file Active , I'll work on that later this week.

timohuisman → created an issue.

I've discussed this with rhezios, a collegae of mine. We think that ECA is a bit overkill for a simple feature like this. We could possibly look into a plugin-based solution so it could be used for more situations.

I did a functional test and it works as aspected.

I see that this issue is closed because it seems like its a duplicate of 🐛 Using ${var} string is deprecated Fixed , but that fix is only committed on the 2.0 version. The 8.x-1.23 version is as far as I can tell still the recommend release, so it would be nice if this can also get fixed in that release.

The patch from #2 does still apply against 8.x-1.23 and resolves the warnings.

🐛 PHP 8.3 Deprecated: Using ${var} in strings is deprecated, use {$var} instead Closed: duplicate is actually a duplicate of this issues.

timohuisman → created an issue.

timohuisman → created an issue.

Rerolled #17 against 11.x and made a MR.

Attached is a patch containing a snapshot of the current state of the MR, so it can be safely used with composer-patches.

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

jQuery is removed from 7.0.x, but still present in 6.x. I've rerolled patch #13 for the latest tag (6.0.6) and the dev branch.

Patch from #2 doesn't apply anymore because 🐛 FormStateInterface::setError*() PHPDoc are incorrect Fixed is resolved.

This patch contains a snapshot of the current state of the MR so it can be safely used with composer-patches.

Alright, agreed.

I've removed the fallback alt option from #82 and created a new patch for 10.3. If this is the satisfied approach I can also updated the existing MR's or create new ones. Not sure whats where the right approach because if the existing MR's are updated the fallback functionality is removed and some people could depend on them.

Can confirm that #4 works with 8.x-1.1 on 10.3. + RTBC

The MR contains the proposed solution. Attached is a patch with the current state of the MR so it can be safely used with composer-patches.

timohuisman → created an issue.

Added "Needs subsystem maintainer review" based on the summary and #70

The MR is updated with the latest changes from 1.2.1.

Attached is a patch containing the current state of the MR, so it can be safely used with composer-patches.

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

All the raised concerns that we discussed this morning are resolved. RTBC

We've fixed it by skipping the update hook. We've verified that the primary key was already set so it doesn't had a lot of impact to skip the hook. I wouldn't recommend it if you can't verify the impact yourself.

The last run hooks are stored in the key_value table. There is probably a row system.schema | date_recur | i:8207;. If you increase the number to 8208 the update hook will be skipped next time you run your updates. But again, I wouldn't recommend this if you can't verify the impact.

bbrala → credited timohuisman → .

@brulain, as far as I can tell is the update hook that is causing this error introduced in [3205682]

Can confirm as well that the patch from #5 resolves the problem and that a new release is really needed. One of the maintainers (bbrala) is a colleague of mine, I'll check with him if we can get a release today.

This patch contains a snapshot of the latest state of the MR 9429 so it can be safely used with composer-patches.

Patch doesn't match anymore because of the changes from https://git.drupalcode.org/project/date_recur/-/commit/a9d7e755c7c45ec3d....

The constraint violation doesn't seem to occur anymore.

I just came across this issue because a client of us selected a 304 for a redirect. A 304 is not a valid redirect code according to the Symfony docs. I've updated the Issue summary and created a MR with the proposed solution.

Attached is a patch file containing the current state of the MR, so it can be safely used with composer-patches.

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

Just tested it on 10.2, works fine.