berliner → created an issue.
Run into this too and I don't think that we can pass HTML markup in Drupal.t()
.
I have created a patch that changes the way these default strings are handled and how translation can happen now. Not sure this covers all use cases, but I'll attach it here for review.
Yes, thanks for the heads-up. It's always interesting to see what's out there in terms of new contrib modules. But I agree with the comments in 📌 Difference with layout_builder_ipe ? Active that both modules have different purposes.
Flyke summarized it quite good in #3476122-4: Difference with layout_builder_ipe ? → if you ask me. What do you want me to comment there?
Yes, from my POV these are still experimental because I can't assess how this affects other, maybe more widely used, contrib modules. I use both of these features in production sites, but unless I get feedback from other users (or ideally bug reports that can be fixed and makes these features more mature), I prefer to mark them as experimental.
Maybe I didn't use the right term, I mean experimental not in the sense that I'm considering removing these anytime soon, but that the way they have been technical implemented suggests to me that they either break easily depending on the specific individual setup, or that they break features from other modules.
Thanks for raising this issue drclaw!
While I generally agree with the patch, I'm just a bit confused how you encountered this issue. Looking quickly, I couldn't find anything that's actually broken due to the changes in page manager rc3 and my understanding is that even if $this->routeMatch->getParameter('page_manager_page_variant')
(/src/LayoutBuilderIpeService.php?ref_type=heads#L476) fails, the call to $this->getEntity()
in /src/LayoutBuilderIpeService.php?ref_type=heads#L488 provides a fallback (which actually looks at the request attributes just as you propose).
So for my own curiosity: Can you describe what is actually broken before this change?
According to the test runner I would expect issues: https://git.drupalcode.org/project/layout_builder_ipe/-/jobs/2793314
Last patch applies properly to 1.7. Thanks for the re-roll.
berliner → created an issue.
Great! I'll close this issue then and add a link to the core patch to the project page. Not sure how to prevent this issue otherwise.
Just in case you are on Drupal 10.3, did you try the patch from 🐛 Ensure consistent ordering when calculating library asset order RTBC ? It should also apply to Drupal 10, even though the issue is marked for 11.
Thanks for reporting. Can you update this issue with the following information?
- Exact version of Drupal Core
- Exact version of this module (ideally git commit)
- Do you have any core patches applied?
FYI that the nonce value must be unique for every single request, so caching the nonce is not an option: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Securi...
This is in reply to #3203811-18: Support Content Security Policy →
Looks good and removes the deprecation message. Easy enough for an RTBC.
Rerolled for 10.3
This core patch would help I guess: ✨ Split 'administer permissions' into a new administer roles permissions Needs work
Updated my last cherry-picked patch to apply to rc11
No feedback and it fixes the issue for me, so I have merged this.
Feel free to re-open if the problem persists at your end.
Good catch. I think that's curtesy of 🐛 Breaks resizing of uploaded images in ckeditor Fixed . Can you test if the MR fixes the issue for you?
berliner → made their first commit to this issue’s fork.
berliner → created an issue.
berliner → created an issue.
For discussion: Maybe something like this patch, which allows to opt-out of the gin breadcrumb processing doing this:
/**
* Implements hook_preprocess_breadcrumb().
*/
function MY_MODULE_preprocess_breadcrumb(&$variables) {
$node = \Drupal::routeMatch()->getParameter('node');
if ($node->bundle() == 'MY_BUNDLE') {
$variables['gin_breadcrumb_skip'] = TRUE;
}
}
The problem with this as far as I can see, is that whatever custom breadcrumb one puts in place, gin_preprocess_breadcrumb()
will just overwrite it for all routes where an entity object can by extracted by _gin_get_route_entity()
.
So this doesn't look like a feature request, but more like a support request. It would be good to be able to opt-out of this behaviour on the gin side. The way it is right now feels a bit greedy.
Or is there already a way to opt out of this that I just didn't see?
@Taran2L No disagreement then :)
berliner → created an issue.
I have updated the MR with the patch and a minor correction for backwards compatibility.
I'll also add a patch file that works for 8.x-1.3.
The patches have been a bit greedy though. Instead of only moving the form action submit buttons and button links into the dialogs button pane, it now moves all submit buttons and button links there.
So it's now doing exactly what it was meant not to do, according to this comment: https://git.drupalcode.org/project/layout_paragraphs/-/commit/9e6ce29756...
I have raised 🐛 Dialog form button logic is too greedy Active as a follow-up issue to fix this.
berliner → created an issue.
The performance concern raised in #10 was about the patch in #5, which only changed the urls inside the srcset without also adapting the logic in ImageStyleDownloadController, so I don't see how that would still be an issue with the current patch.
Updated patch from #38 for rc10. I hope I didn't miss anything.
I don't have the capacities right now to look at the MR unfortunately.
Still setting to "Needs work" to check if the MR needs modifications to be applied to the current dev.
I personally appreciate the patche files from saurabh rawat to have something usable in D10.2.
This works great and fixes the "Edit [term name]" on taxonomy pages as well. Just tested the last patch file but didn't look at the MR.
This patch hides the "Add child" link from a terms entity operations if the vocabulary is set to use flat taxonomy.
berliner → created an issue.
I get the feeling that this get's a bit out of hand here.
Those last patches do not seem to address the original issue about the changed button ids and the outdated references in the ajax subsystem. #12 should fix the issue as demonstrated by the "steps to reproduce", so this should be reviewed and tested. The other patches seem to be about different issues. Maybe it would be better to create a new issue for those with sufficient information to reliably reproduce the problems and then fixing them.
Given that ✨ Prevent JS errors when Layout Builder is not initially displayed but loaded later via ajax Fixed is done I'll call this fixed.
Good catch. Thanks for the MR. Merged just now.
berliner → made their first commit to this issue’s fork.
Rerolled #3 for rc9.
I would be in favour of not changing the ids in the first place though, just as hudri suggested. Removing unnecessary complexity is always preferable.
This overflow issue somehow appeared again in rc8 on D 10.2. I didn't have time to investigate further at the moment, but the "table { width: 100% }" fix worked in my use case again, ignoring issues with table overflowing the page content horizontally.
This seems to have been fixed in the meantime.
Thanks @ultrabob. But this issue is about a missing listing page for "trashed" content, using the soft-delete feature of this module. I am able to see the worflow buttons. But the link to the trash leads to a 404.
Note: I'm not using the module for my project after all, so I won't be able to provide further details.
Found an issue with the patch. The ProxySubscriber redirected to a non-valid URL. The attached patch fixes that.
This is a re-roll of #8, which sounds like the better approach compared to #9 which removed the config part (form and schema). Patch applies to current dev and to 8.x-1.6. Seems to work as expected.
berliner → created an issue.
Possible duplicate of 🐛 strnatcasecmp(): Passing null to parameter #2 ($string2) of type string is deprecated Needs work
berliner → created an issue.
Re-rolled for 10.1 and extracted a test-only patch from #110.
Re-rolled for rc4
I misread the last post and didn't look at the patch in detail, so I thought the update hooks were still missing.
Sorry for that.
@Anybody The steps to reproduce from the issue description don't help you isolate the problem? It took me a while, but in the end I was able to reliably reproduce this issue in my setup.
Possibly related to #3319004: DX: "force" is confusingly mapped to "checkDependencies" →
Great, thanks!
Drupal 9.4 is no longer supported, please upgrade to Drupal 9.5 or Drupal 10 which require PHP 8.1 or higher. PHP 7.4 is end of life since already and is not supported anymore.
The reported issue is due to PHP syntax not supported in PHP 7.4.
Which version of Drupal and PHP are you running?
As per #1433622-3: Contextual filter AND (,) operator for multiple values does not work → this works if using "Content: Has taxonomy term ID" as a contextual filter.
Adding a schema file.
berliner → created an issue.
Re-rolled for current dev.
Updated patch with minor improvements and added tests.
berliner → created an issue.
Updated patch to remove call to console.log
in build js file.
There is a simple patch to fix this issue available in ✨ Prevent JS errors when Layout Builder is not initially displayed but loaded later via ajax Fixed
Thanks for looking at coding standards!
berliner → made their first commit to this issue’s fork.
berliner → created an issue.
This patch fixes the issue for me.
berliner → created an issue.
I see this problem in Layout Paragraphs when the Gin admin theme in version 8.x-3.0-rc1 is used. It sets the --ck-z-modal
to 98 for all ck
classes. Updating to 8.x-3.0-rc2 fixes the issue.
@urvashi_vora There is no difference between your MR and the patch in #3, correct?
@tyler36 The WebP module seems to go down the same route though, with only a beta release, the last commit from 15 Jan, 2022 being older than a year now too and no visible activity from the maintainers anymore.
Bumping the priority, because this issue breaks the module.
Looks good, makes sense and fixes the issue.
Fixes the issue and simple enough to RTBC I guess.
This patch should fix that.
That was too quick and not properly tested. This one is fixing the issue for me.
This patch fixes it for me.
berliner → created an issue.