@leymannx

With latest Rabbit Hole v2 this works OOTB anyways already. Nice

Any patches applied?

The report doesn't make clear how exactly the update process was performed. Just composer update? No drush updb? No drush cr?

Can I reproduce this issue with a fresh Drupal standard install, 2.0.5 Easy Breadcrumb installed, dummy content created and then update to 2.0.6 Easy Breadcrumb (how exactly)?

Sorry, it's the other way around.

With the new approach ...

Looking for the related issue..

leymannx → created an issue.

That's not our tests failing. Different issue.

Issue was against 3.0.2 which will soon be 2 years old. People needed a patch. Can we get this tagged, please?

Here we can see clearly what happens if we blindly apply coding standard fixes for credits without understanding the code.

Let's get MR !112 in. For me it fixes the issue.

Unfortunately the MR now contains lots of unrelated fixes. I agree with most of these improvements but they must be fixed separately. Here we want to fix the issue mentioned in the title.

The most important thing to understand is that we must not inject a service that might not exist. Since the redirect module is not a dependency of the easy_breadcrumb module the redirect.repository service was called only inside a request: if ($this->moduleHandler->moduleExists('redirect') { ....

I will now open another MR to solely revert the unfortunate changes from 🐛 Fix tests Fixed . This will fix this issue. We might then open follow-up issues to fix the other stuff.

This was an unfortunate MR. While Stan and CS might have been green, Unit became red. This MR introduced the bug mentioned in 🐛 Broken findMatchingRedirect() call Fixed and 🐛 "Paths to be excluded while generating segments" option says regex is supported, but it is not Needs work . Also not the best move switching from static to selfhere, blindly listening to a Stan warning, while you see this pattern nowhere else across any core or contrib code.

The fix now happens in 🐛 Broken findMatchingRedirect() call Fixed .

A single json_encode($value) without any flag also is not enough. You need at least json_encode($value, JSON_UNESCAPED_SLASHES) to prevent slashes in the URLs being escaped.

Isn't $position always 1 now?

Some tests are failing

leymannx → created an issue.

leymannx → created an issue.

I fixed some syntax errors for Drupal 9 (PHP 7.4) and now all tests pass.

Test was failing because it didn't like the trailing comma in the parameters, which is only available since PHP 8. CI seems to run on an older PHP version.

leymannx → created an issue.

This is very much needed, thank you!

But I don't see the functional tests running. The .gitlab-ci.yml file also still contains to much noise from the template.

Tasks:

* Make functional tests run
* Remove unnunnecessary comments from .gitlab-ci.yml

I really like the straightforward, clean and readable implementation and the already in-place solution to pick these events up in the password_policy_extras module, thus merging and tagging it. Looking forward for a release of the password_policy_extras module to be able to test it more easily.

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

Now that 🐛 Storage client should return empty array instead of NULL Fixed is in, the patch needs a re-roll, though I'm really not sure about if this is the right way. But given the earlier code and now with the chance of an empty, is this the right way?

Ah yeah, it even triggers this message in all of the backend:

Error message

One or more problems were detected with your Drupal installation. Check the status report for more information.

Yes, you get the below red warning on /admin/reports/updates and probably also in the mails.

Project not supported: This project is no longer supported, and is no longer available for download. Disabling everything included by this project is strongly recommended!

Would have been good to close the gaps first and give users an upgrade path. Now we need to figure out on our own. Will need to allocate time for it and try to document what needs to be done manually on top.

leymannx → created an issue.

xjm → credited leymannx → .

I find "ceespex" and "ceespim" easy to say and close enough to the former ones for memorization. Rest then following the pattern:

1. cspex
2. cspim
3. cspac
4. cspde
5. cspso

Like this but for "Link to receipt".

leymannx → created an issue.

leymannx → created an issue.

And the current user needs to have a role with the rebuild cache access permission, of course.

You need to create the link from the route, I think. Try:

<a href="{{ path('rebuild_cache_access.rebuild_cache' }}">Rebuild cache</a>

xjm → credited leymannx → .

Also to me this is really confusing. I think the module should clearly state these limitation on both the module page and in the README. This would help a lot to get the people maybe even create the MRs that are missing to make this work OOTB. Should we add an issue for it?

debug: true

First thing to tackle: Let's find the place in code where the publishing option becomes available/unavailable in the form :)

I also think that a dedicated toggle publish status permission is the way to go here, as with binding it to the delete permission we might run into the following paradoxon:

While "a user who can delete content should also be able to unpublish it" might sound right the following statement does not "a user who can delete content should also be able to publish it".

Making this a feature request instead of a bug. I think we can make it move forward faster that way. To me it sounds more like this was just not yet considered and implemented in core. So, let's implement it now.

Yeah best would be to leave it to JS, which the body class does. Tokens is PHP, I'm not even sure you can send cache tags along a token, but since user tokens do there must be something with a custom browser tag as well.

Best is you circumvent PHP (server code layer) here and do something with JS and CSS (browser display layer).

Can you print an obfuscated content of that field's content like you use it now with the tokens?

The browserclass module is actually just for adding a class and then style things accordingly.

The token seems to vary per user given the module description. Means all unauth users will get the first hit which then is cached.

Can you give a little bit more context? Like why is the body class not suitable for your needs? What do you do exactly with these tokens?

Seems only enabled blocks have a weight, so I did it like this:

{% if drupal_entity('block', 'volcano_search_autocomplete')['#weight'] is defined %}
  ...
{% endif %}

leymannx → created an issue.

Like the description page says this module should give you some CSS classes on the body tag. Which happens via JavaScript to prevent any caching issues. It's also not very let's say sustainable to bust the cache on every different browser. Because there are millions.

<body class="... chrome chrome11 mac desktop">
...
</body>

In CSS you then can use it to style things differently:

body.chrome.mac p {
  font-size: 11px;
}

I think with tokens the problem is that a custom cache tag has never been implemented. And as said already it's probably not the wisest move to bust the page cache on every different browser which comes to your site.

But I need to check. For the time being, yes, it's much better you rely on the body tag classes added via JavaScript.

Ah, I see. Thank you very much for the details. I will check.

One last thing: Are the classes added correctly to the page's body tag?

Please provide at least some steps to reproduce this issue, so we are able find the problem causing it.

Where did you place the token exactly? Where is the output getting printed exactly?

Okay, I found a way to output the machine name value from the field and it's a completely different value than the one that's expected: jvfavt8z == test_value_0_9 wich of course is false. Same can be seen in the test artefacts.

It's also the same what I experienced after I put $settings['extension_discovery_scan_tests'] = TRUE; into my settings.php and enabled the entity_test module. I opened URL /entity_test_string_id/add and it always contained some random name in the name field and the machine name field was always pre-filled with this machine name. When I changed the name, the machine name didn't change accordingly. It always stayed the same.

(It also looks really different from all other machine name elements I know in Drupal.)

By the name of Dries I couldn't find where this arbitrary name value was coming from. On every page load it was a different one. I also don't understand why all other asserts succeed and only this one doesn't.

Does anybody here have an idea why when accessing /entity_test_string_id/add the name is always pre-filled with a random value? Where does it come from?

Okay, I reverted the commit. That wasn't it.

#11 🐛 Spell-checking job fails with "Argument list too long" when too many files are changed Active did not help unfortunately, but in the end a rebase did.

git switch 11.x
git pull
git switch ISSUE-BRANCH
git rebase 11.x
git push --force-with-lease

leymannx → changed the visibility of the branch 11.x to hidden.

Which would be strange, though, as the machine name test says also says Test value !0-9@ translates to test_value_0_9: https://git.drupalcode.org/project/drupal/-/blob/11.x/core/tests/Drupal/... 🧐

Looks like the machine name is wrong. When I add a new field anywhere in Drupal, naming it Test value !0-9@, the machine name gets auto-created as field_test_value_0_9_.

And do your problems persist in 2.0-beta7?

Please open separate issues with one problem each and a proper description each, otherwise this is is difficult to fix. Closing as duplicate of the mentioned issue. Please reopen if issue title+description adjusted to focus on one thing only. Sorry and thank you ☺️

Can it be that you have the patch from #3273497-29: Passing null to parameter #1 ($data) of type string to unserialize() is deprecated → applied in your project? I had this patch applied in 2.0-beta7 and then this issue occurred. When I removed this patch everything worked fine and I had also no PHP 8.1-related errors or warnings.

#29 makes the views arguments not being respected anymore. Exactly what's described in 🐛 Contextuele filters not respected when used in paragraph Active .

Everybody just needs to update to 2.0-beta7.

You forgot the ^ character. It's trying to install an exact version otherwise, one that doesn't exist. The correct command can be found on the project page, you just need to copy it.

composer require 'drupal/viewsreference:^2.0@beta'

Yope, we need laminas/laminas-diactoros in a composer.json.

You created a 2.0.x branch which basically means you can only release hotfixes. You need a 2.x branch instead.

🥳 🙏🏻

Upping #26 as patch as it's working for me and I prefer this approach for fixing the problem exactly where it occurs. Credits need to go to @NicolasGraph.

Hiding patch, it's the same as in #2741877-121: Nested modals don't work: opening a modal from a modal closes the original → .

I should have checked first. 😭

Reroll for 10.2

leymannx → created an issue.

Problem was that Frontend Editing expected an entity ID when there was none. So let's skip Frontend Editing on previews of not-yet-existing nodes.

leymannx → created an issue.

migrate_tools command has now been moved into the correct place, see 📌 Move Drush commands from src/Drush/ to src/Drush/Commands/ Fixed . We need to adjust the statement again.

Please reopen.

The weight makes no sense here. Was just c/p. Updated patch with weight removed.

leymannx → created an issue.

Yeah, we with a long list of paragraphs and the screenlock you can't scroll in Claro. The patch fixes it.

leymannx → created an issue.

Maybe simply explain it on the project page and encourage people to get the player in like that.