LGTM! Works as expected and seems like the right fix!
I concur! Created a new 3.0.x branch and applied this patch. Changed core version requirements to ^10.3 || ^11.
🙏
Thank you everyone! This is in the newest 2.1.3 release 😁🙏
Thanks everyone! Sorry for the delay!!
Committed! Thanks!!
Patch converts $this->routeMatch->getParameter('page_manager_page_variant'); to $this->request->attributes->get('_page_manager_page_variant'); per above
🙏
Regarding the issue with the session not being set on Drupal 10.3+, there is another issue with a patch for that:
This is amazing! 🤩 Great work!! 🙏
This is awesome! 👏
But a small side effect / regression is that blocks are now rendered using the admin theme which means any template overrides / preprocessors in the default theme won't be used when rendering the block. Will post a new issue shortly with an MR 🙏
Ah beauty! That's good to know - thanks for reporting back 🙌
For anyone coming across this one, I don't think this is really a Gin problem. Gutenberg doesn't currently render the media library using the admin theme so none of the gin theme templates are being picked up. Some classes are missed in the process and so the styles are only partially applied. There's an MR out now though so it might be fixed soon.
✨ Set the media dialog route (/editor/media/dialog) as an admin route Active
I think it needs to be done in javascript with wp.blocks.unregisterBlockStyle(). Although, as mentioned on that documentation page, there can be a bit of a race condition if your script tries to unregister a style before it's registered. Even using wp.domReady() I still needed a timeout to ensure the unregistration happened after the style was registered. Probably, we need to use a different event for Drupal Gutenberg but I don't know what that is.
In the meantime, if you can handle the timeout, here's wha that looks like:
wp.domReady( () => {
setTimeout(() => {
// Remove the rounded style from the core/image block.
wp.blocks.unregisterBlockStyle( 'core/image', 'rounded' );
}, 1000);
} );
MR Submitted!
I tried to keep it close to the wordpress filter so the naming "..._render_block_...", as well as the parameter order. Let me know what you think!
Thanks!
drclaw
@Ahmad Aziz, at the moment you'll need to use the drupal/gutenberg:3.0.x-dev@dev version to get those style options on drupal blocks. That was only recently added and a new beta release hasn't been rolled out since December 2023.
✨ Add Color and Spacing block support to Drupal Blocks Fixed
The starter theme is great! Especially the filters/styles/variations examples! Thanks! 🙌
Yep - I agree! I apologize for not getting back to you way back then. I wish I had so that we could have kept the namespace and not left any FlexField users without an upgrade path. Totally my fault though for dropping the ball!
I've updated the FlexField project page to include a link to Custom Field and marked it as deprecated.
Cheers!
drclaw
Thank you for the report. I apologize but FlexField is now deprecated and will no longer be receiving further support. We encourage you to try out Custom Field → , which is a MUCH improved version of this module.
🙏
Yeah you know I started this module with pretty simple use-cases so I've never had any problems with it myself, but clearly it needed some work for various other uses.
In any case, I've deprecated Flexfield now because Custom Field → just does it so much better and is much more actively maintained.
🙏
Choo Choo!
Looks like we can just use the StyleEngine you added a few weeks ago to render the block styles on the server-side! 🙌
Oh yeah, HA I got so hyped on getting it to work in the editor I didn't even realize it wasn't working on the front-end of the site 😂
I'll see what I can do!
Been down the rabbit hole on this one. Found a few related patches which I've linked.
Looks like this patch reverses this issue 🐛 [random test failure] Drupal\Tests\layout_builder\FunctionalJavascript\LayoutBuilderUiTest::testReloadWithNoSections() Fixed which is probably why there are test failures. The change to have the off canvas debounce function run immediately (i.e. false -> true) was made to prevent those failures.
I actually think that the issue is with the debounce function itself but that's a whole separate issue - for now this patch fixes the problem even if it's not the final solution! 🙏
Setting to postponed and attaching patch
Re-rolled for 8.x-1.31 🙏
Great stuff! Thanks for picking up the reins on this project! 🙏
Updating patch using empty() since in some (if not all cases) the error is because the element is actually missing entirely.
The jquery ui package dependencies need to be updated to 2.x for D10 compatibility. Patch attached.
A new 3.0.0 release has been rolled out that is D9 and D10 compatible. I bumped to 3.x for semantic versioning and getting away from the 8.x-2.x version pattern.
A new 3.0.0 release has been rolled out that is D9 and D10 compatible. Closing this one down.
A new 3.0.0 release has been rolled out that is D9 and D10 compatible. Closing this one down.
Patch applied and a full release rolled out. There's a new 3.0.0 release y'all can use now.
Cheers!
drclaw
I just updated the issue fork's composer.json to include D10 as a version requirement. You can now include the issue fork in your composer.json for D10 upgrades. https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr... →
This feels like a bit of a sledgehammer fix since many of the cached "empty" routes could be belong to actual 404s (in which case you _want_ them to be cached for performance). The problem here isn't that the empty routes are being cached, but that they aren't being cached specifically enough.
The thing is that it's usually a module that's introducing the various context that makes a route accessible in one case and not another. In that case it's really up to the module to somehow inform the routing system about those contexts. Luckily core actually does have a way to do this with CacheableRouteProviderInterface::addExtraCacheKeyPart(). This was added in
#3007669: Add publishing status to path aliases →
and allows you to add your own contexts to the route cache key.
An example of this is the Domain Access + Country Path module. Country path lets you toggle the active domain by path so:
- example.com/uk -> Domain #1
- example.com/us -> Domain #2
In this case when you see a link to example.com/us/whatever from example.com/uk on a cold cache, the empty route gets cached for all domains because the routing system doesn't know that there's a difference based if you're seeing the link on /us vs /uk. In this case Country path or even Domain access could inform the router about this difference. And in fact, there is actually a patch doing just that for Domain Access ✨ Use core route provider with addExtraCacheKeyPart for route caching? Needs review .
Really the hard part is usually figuring out specifically which module is introducing the contexts that cause this behaviour to happen. Ideally, the router would pull from the various render contexts that are floating around automatically, but I've only seen that eluded to in https://www.drupal.org/project/drupal/issues/2799543#comment-13344318 →
Country Path actually has its own cache context of url.country that one should use instead of url.site. Not sure if that actually solves this issue, but I came across this one looking for something else and figured I'd mention it :)
Ah perfect, nice find! And good to know!
Thanks for reporting back. I'll close this issue down :)
Oh yeah interesting. I think I follow. I'd maybe suggest inspecting the resulting SQL query to see what the IDs look like there. Maybe they're being transformed somewhere along the way and not transformed back correctly before being inserted into the query.
Also, have you tried manually pasting one of the IDs into the views preview "Preview with contextual filters:" field? Might be good to see if the IDs work there or not. If they don't work there then it's probably an issue with views and not with this module.
@pumpkinkid2 Interesting! I suspect that the values just need to be URL Encoded. My use cases for this module has typically been for referenced entity IDs so I haven't tested much with string values. On line 213 in CurrentEntityFieldValue.php, try changing
$values = array_column($entity->{$field_name}->getValue(), $property);
to
$values = array_map('urlencode', array_column($entity->{$field_name}->getValue(), $property));
And see if that gets you there!
Committed and pushed to the new 2.0.0-beta2 release. Thanks everyone!
Done and Done! Thanks for the suggestion!
Yep, thanks @david.qdoscc for the patch but a Decimal type was added a while back based on @apmsooner's patch. Sorry I didn't update this task way back then!
Thanks y'all! Committed and rolled a new release!
@danflanagan8 - that's awesome about the tests! I'll be reviewing your other task sometime soon and getting that in there too 🙏
The 2.0.x branch is deprecated and was just kept around for anyone still stuck on D8 - considering D8 hasn't been supported for over a year, I think I can take it down now. Closing this one down!
Committed and new release has been rolled (2.1.2)! Thank you so much to everyone involved!!