It feels like an important fix to allow for a real generic use of purging with Varnish.
simon georges ā created an issue.
simon georges ā created an issue.
This is an updated version of the patch for the latest version of the module.
I'm a big fan of Schema Blueprints, but I feel it's a little too opinionated for a generic recipe, which is not what we have been used to by Drupal. I would be very happy if we come to it one day, but it may be too early for that ;-)
simon georges ā created an issue.
On a project I was working on, we ended up using Yoast Analysis ā module instead to take Layout Builder into account. This worked perfectly.
Patch including all Rector + MR !2 changes + modification of the .info.yml file for D10.
Hi,
Here are my thoughts about SEO in Drupal. As a background, I have been building Drupal websites for more than 15 years, and I'm SEO-certified in my country, regularly taking about that in Drupalcamps.
The only mandatory modules are Pathauto & Metatag. Metatag default configuration is ok, but pathauto needs a dedicated rule for content, at least something like [menu-link:parents:join-path]/[node:title] just so that the breadcrumbs follows the menu hierarchy. And for me, at least Pathauto should be included in core, because that's what other CMS do, but that's another issue entirely ;-)
Apart from that, Redirect is really nice to have, especially with the default configuration where a path (with pathauto) can change when the title of a content changes: that way, a redirect is automatically created, and even with user errors, the history SEO is kept.
All other modules are just depending on the strategy the website will have, and we shouldn't impose anything. That said, people will often looks for Robotstxt (possibly only for factories with lots of website on the same core), Simple Sitemap (smaller websites should not need that at all), Sitemap (in that case, we need the multilingual patches to be there as well), and Metatag Schemaorg (this one could be preconfigured for specific recipes like events, products, things that will have impact on search results). All these modules could be included or suggested in the recipe, but they shouldn't be enabled by default, this will just clutter the UI and enabling them could even be counter-productive if the users do not know how to configure them or use them.
Even Metatag Opengraph is now sometimes useless considering Google+ has shut down, a lot of people are leaving Facebook & X (Twitter) has said they don't always respect it. Basically, both Facebook & X will try to find a suitable picture themselves. So I don't know if we should have it enabled by default or not, especially considering this one needs configuration, while default Metatag core configuration works out of the box.
Indeed, this label shows when you use the "Move" feature as well, so it's hard to know which block we are moving :-)
I think I have this issue as well (on latest Webform version).
@codechefmarc, the patch works for me in the Layout Builder as well, so I'm wondering what contrib module I have that could alter this... I'll check back at work this week, thanks for your feedback!
In my case, the patch in #17 was allowing the prepare_form to execute for Inline Blocks, but the form was not actually correctly prepared. Fix the attached fix, it works for me... Let's hope it's the case for all of you as well ;-)
We are currently working with some content types with a very "fixed" template, where each region can only accomodate only 1 component. In that case, the dropdown feels a better option, while for our other content types, having the pop-over with the list of components is nicer. I was just about to create a feature request to have the possibility to choose the UX depending on the entity bundle :-D
Simon Georges ā created an issue.
(in our case, we wanted to add a custom class on the link to be able to style it specifically)
The previous patch cannot work, considering it will add a "/" on external urls before testing them for externality, so the patch in #5 is the correct one, and still applies cleanly on current version.
As "Configuration" is not using the same Controller (but \Drupal\system\Controller\SystemController::overview), people still see the "Configuration" menu. Adding a $route->setRequirement('_access_admin_menu_block_page', 'TRUE'); using a custom RouteSubscriber seems to work, but I am wondering if this behavior is expected or if you did not take that into account for a reason.
We can agree :)
Actually, I still have the bug where the second resize is not saved (style & data-width values are not updated if I looked at the source).
Ok, I think I found it...
It comes from the following code:
.drupal-media.ck-widget_with-resizer .media {
width: 100% !important;
}
Olivero theme adds the "media" class in the media.html.twig, but we did not have it in our custom theme. I don't know if it's a bug or not, considering "starterkit-theme" adds the "media" class, we may consider this is the recommend way to start a theme in Drupal 10, and expect people to have that class, but it should at least be documented or adjusted, don't you think?
Actually, if it only works with Olivero as a front-end theme (which I can reproduce), it means that something is missing in the module, doesn't it? (considering we are working on a back-office page, why does the front-office current theme plays a role? Could there be a library-extend missing from the module?)
Simon Georges ā created an issue.
@DamienMcKenna, I seem to have an issue with my custom theme as well, do you happen to have fixed yours? Can you share what the fix was?
My current issue is:
image-style-configuration-definition-invalid
Object { dropdown: {ā¦} }
ā
dropdown: Object { name: "drupalMedia:viewMode", display: "listDropdown", defaultItem: "drupalElementStyle:viewMode:default", ā¦ }
ā
<prototype>: Object { ā¦ }
Read more: https://ckeditor.com/docs/ckeditor5/latest/support/error-codes.html#error-image-style-configuration-definition-invalid
I was there and was mostly coordinating & validating. We worked on Drupal core, Webform, Smart Date. Some hard strings to translate, but a good dedicated team effort \o/
It may still be relevant today ;-)
I concur, the performance gain is impressive (1 to 2 seconds saved on a 4 to 5 seconds load time in our case). Thanks for the patch!
Considering several people have reported it working without drawbacks, let's try to move it forward ;-)
Hello,
I am closing this issue as a duplicate š Automated Drupal 10 compatibility fixes Fixed , which already contains a patch with the same modifications (and more).
Changing status to "Needs review", considering a patch is included.
Simon Georges ā created an issue.
Simon Georges ā created an issue.