🇳🇱Netherlands @timohuisman

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.

I understand your point, but that's not related to the changes in this issue right? With or without the new permissions from this issue, you still have to manually grant all the view permission after enabling the Paragraph Type Permissions submodule.

So maybe it could be a separate feature request, but in mine opinion we don't have to included in the scope of this issue.

The https://git.drupalcode.org/project/drupal/-/merge_requests/8742 is still applicable, but because it's a moving target we prefer a patch as snapshot of the MR.

Looks good! I've converted #5 to a MR.

I'm not sure about #6, because the current behaviour is as well that you have to manually assign all the view permissions to those roles.

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

Updated the Drupal 11 system requirements according to the release notes → .

Removed the deprecated functions, further no changes from #25.

I agree, its weird that the field is visible by default.

The patch from #7 doesn't apply against 10.2.x. I've rerolled the patch from #7 against 11.x, it should also apply to 10.2.x and 10.3.x. I've opened a draft MR, but the feedback from #8 is not yet addressed.

Attached is a patch with 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.

The MR is against the 8.x-1.x branch while the issue is for version 2.x-dev. The changes itself looks fine. The changes are also included in 📌 Automated Drupal 11 compatibility fixes for editor_file Needs review btw

bbrala → credited timohuisman → .

Somehow my colleague @adebruin couldn't create a MR, so I made one with the patch from #2

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

I'm not sure why, but I get a 404 when I try to create a new branch for this issue.

Anyhow, Quickedit is no longer in core, see [#3259831]. So we could just use the existing view mode instead of overwriting it.

I've checked MR !23 against drupal/core 11 and drupal/views_infinite_scroll 2.0.2, found no errors. Back to RTBC.

timohuisman → changed the visibility of the branch 3412444-make-cacheablemetadataapplyto-merge to hidden.