Makes sense. I'll see what I can do. That code is pretty messy at this point after many years of small public contributions.
I had noticed this problem on my own Drupal website, and didn't realize it was easy breadcrumb module doing it.
This cache improvement sounds fantastic. Hiding breadcrumbs on 404 also sounds good. If y'all want to just look over the cache code and make sure it's correct that would be ideal. The cache code is grouped in the module here:
https://git.drupalcode.org/project/easy_breadcrumb/-/blob/2.x/src/EasyBr...
I think this is an unrelated cache issue:
https://www.drupal.org/project/easy_breadcrumb/issues/3500483
🐛
Cache issue after Drupal 10.4 upgrade
Active
greg boggs → created an issue.
The images look great!
When I mentioned the secondary repository, here's the other file I wasn't sure on the process of updating:
https://git.drupalcode.org/project/drupal_cms_events/-/blob/1.0.x/conten...
~G
I actually don't know the process to contribute to drupal cms yet because the code is in two repositories. I think you'll want to open a merge request on this issue's fork, with the "get push access" button above. Once you have that you can update the file and propose a merge.
https://git.drupalcode.org/issue/drupal_cms-3502035/-/blob/1.x/recipes/d...
Here's some good news for our morning. Gimp 2.10 does a great job at exporting to webp.
My eyesight isn't the best, so I am not the best person to make our images because I can't see the compression artifacts. I think if we save at 75% compression in webp with Gimp, we're good to go. Drupal.org doesn't allow upload of webp images so sharing them is difficult. I'll need to open an MR later.
Large files are good. Ideal even. Most of the provided images with CMS are too small. But, I think that's a separate issue.
Large file still should be saved with the correct image type and compression settings. As far as I know, none of the other image programs save images as well as Photoshop. The last time I tried with GIMP, it gave me an image twice the size that it should be. I do think Google provides a tool to save images directly as WebP which could be a reasonable solution as well.
What we don't want is large source image files that are 10x larger than they need to be for the quality they have because we used the incorrect settings when saving the image in photoshop.
Yep. The process is to use Photoshop, then use the "save for web" interface to save png files as jpg files. Then to resave any large jpg files at a good compression amount. The amount of compression varies per photo and is a bit subjective, but it's usually between 40 and 60% quality. You have to manually review the image to make sure it looks good and is not pixelated by the compression.
Drupal CMS has been improved to use webp when displaying images. However, some of the source images are still using the wrong file type and some of them are much too large. This file should be under 200kb, instead it's 1.2 MB.
https://git.drupalcode.org/project/drupal_cms_events/-/blob/1.0.x/conten...
The reason to update these correctly is so when someone uses one of the provided images outside of the provided views, it doesn't give them a really slow website.
Awesome!
Fix away.
New maintainer prudloff added and permissions updated.
heh, so confusing. Why does wse menu link manager get called when we ask for the core one?
Looks good, thanks.
greg boggs → made their first commit to this issue’s fork.
oh heck yeah. Can't wait to upgrade. This is my only logged error.
Does anyone want to be added as a maintainer to tag said release?
Looks good.
I made the change. If you can test the dev release and report back, that would be awesome.
Yep, Yep. The new title is much more accurate.
For end users an extra 1MB event image is only really noticeable for folks on slower internet.
The Drupal.org home page has an incorrectly saved png file that's 600kb and I can't visually see it when I load the page because my Internet is fast.
The display is visually the same between a webp image and png image. But, the PNG image is 1.3 megabytes, and the webp image is 31.5kb.
The way I found it was I:
- installed all the recommended recipes
- opened inspect element
- opened the network tab
- loaded the page
- clicked sort on the "size" column twice so the large items appear at the top.
That's where the 1 mb+ image shows up.
Now that CMS exists and it's the primarily promoted way to use Drupal on the home page, it's important that projects work on CMS.
Hopefully we can solve for small machine name mismatches between Standard profile and CMS. If we can't solve it in a single release, then a CMS specific release for Recipes would be a start.
Tested this on a fresh install and it works as expected. Final image file for the DrupalCon event is 31.5kb when displayed on the homepage and the card mode now displays perfectly on the home page.
Compatibility with CMS recipes for recipes is ideal.
In theory, if a recipe works with minimal, it should work with CMS, although the types added will have body as a field name instead of content. An ideal solution would be to update standard from body to content rather than to do it in CMS.
greg boggs → created an issue.
Oph. Thanks for catching my mistake. I have reverted it back to your original.
greg boggs → created an issue.
greg boggs → created an issue.
I added 1 step to the release notes because there are 7 styles to update rather than 6.
greg boggs → created an issue.
So, the events recipe uses an unexpected render method and should be updated. And some of the image styles need updating to convert to webp.
Most of the styles converts to Webp. Here are the image styles not converting to webp:
1:1 | 300x300 | Focal Point | WebP
3:4 | 225x300 | Focal Point | WebP
3:4 | 450x600 | Focal Point | WebP
4:3 | 300x225 | Focal Point | WebP
Linkit result thumbnail
Social media - Facebook
Social media - X (Twitter)
Uncropped | 300w | WebP
greg boggs → created an issue.
greg boggs → created an issue.
Looks interesting. Will give it a try.
greg boggs → made their first commit to this issue’s fork.
new MR encouraged =)
Wow. Thank you. Epic code :)
greg boggs → made their first commit to this issue’s fork.
Also, why is url needed if url.path is already in the context? Here are the core contexts for reference:
https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/syste...
The interface language and the content language are not the same cache contexts.
After applying #6 in Drupal 10.3, I get a new error when applying a modify data VBO action.
Error: Call to a member function getEntityTypeId() on null in Drupal\rabbit_hole\Plugin\Field\FieldWidget\RabbitHoleDefaultWidget->formElement() (line 166 of modules/contrib/rabbit_hole/src/Plugin/Field/FieldWidget/RabbitHoleDefaultWidget.php).
Drupal 9.5 is no longer supported software. To fix this warning please upgrade to Drupal 11.
There is no patch to apply. This has been committed. Just waiting for someone to test the dev release and report that it works in Drupal 11 and we can tag a release.
Looks good. I'll give the dev release a test.
Code looks good. Needs some more manual testing still. We'll wait for Spuky to take a look.
~G
Awesome couldn't tell for certain the Diff, thanks for the extra info!
Also! Great freaking work on this merge request. Tests and everything.
My only question is on this line:
- $title = Html::decodeEntities(Xss::filter(trim($settings[0])));
Are we still escaping JavaScript if we remove that line?
greg boggs → made their first commit to this issue’s fork.
Thanks for the fix! We have 2 new issues in the current release that we want to fix before the next release. But, do let us know if y'all need a release soon to not be blocked.
greg boggs → made their first commit to this issue’s fork.
It's off topic, but I work for our library. Thanks for all the great work y'all do at City of Portland. Feel encouraged to open an MR with what you think the best fix is here.
I think it's reasonably safe to assume someone doesn't have a custom path with multiple leading slashes.
oph. Thanks for the report. We'll take a look as soon as we can. Clearly we need better test coverage for this feature.
To get security coverage, the module must have a stable release, and a maintainer of the module must have permission to opt into coverage. To get permission to opt into coverage, a maintainer has to have created at least one module that was reviewed and approved by the module review team.
If you already have permission to opt projects in, you can click a box. If not, here's the process:
https://www.drupal.org/docs/develop/managing-a-drupalorg-theme-module-or... →
A small note on |raw. Raw disables twig's output escaping so users might be able to post JavaScript in the URL if you pass content through Raw. So, you'll want to make sure that content is escaped before it gets to Twig.
Saw this exception in my log slowing down my website because bots trigger this one a lot. Looks like there's been significant work done on this merge request since it's last review.
Nice.
Thanks folks!
greg boggs → created an issue.
Heck yea! Nice.
Nice. Thank you!
greg boggs → made their first commit to this issue’s fork.
Logo looks good. Needs a Merge request.
Hrm. The site structure tag is already selected.
Unless I'm just missing it, this does not appear to be in 3.3.x-dev yet? I ended up here because 3.3.x still installed varation cache and varationcache project page says:
"Please uninstall and remove this module once you are using Drupal 10.2 or higher and have no more code mentioning the Drupal\variationcache namespace."
The reason the project name was in the summary was to make the summary clear when it was displayed to users in search engines.
Here's my best attempt to comply with the request while still having a complete sentence.
"This module updates the core Breadcrumb block to include the current page title in the breadcrumbs. It comes with settings that are common features needed in crumbs."
I've also adjusted the full description to better line up with the new summary.
greg boggs → created an issue.
Adding a patch of the current MR for testing purposes
Ok, apparently I have forgotten how to patch. This one will work, I think.
mucked up the patch file last time. trying again.
The current patch makes oauth scope a required field. However, some APIs don't use Oauth scope. So this patch makes oauth scope optional. Still needs a reroll for Beta 5
The patch needs a re-roll for Beta5
Another good place to get support is in Drupal Slack in the #support channel.
https://www.drupal.org/community/contributor-guide/reference-information... →
Thanks for the great improvement!
greg boggs → made their first commit to this issue’s fork.
The patch works perfectly for us.
Translations have improved some. But, Zip Code label does not translate and there's no UI for adding a translation for this. Any suggestions on next steps to get missing Address labels translated?
Yea, the bug is that webform doesn't set a correct page title for the thank you page. I'll open a ticket for webforms for the title bugs and link them here.
When viewed in the Gin theme, the crumbs are more readable, but also strange. I think there's some bugs with Easy Breadcrumb and Webforms together
Path: https://drupal-cms-dev.ddev.site/admin/structure/webform/manage/nerd_qui...
Crumbs: Home > Administration > Structure > Webforms > Flex Your Nerdy Opinions > Flex Your Nerdy Opinions
greg boggs → created an issue.
greg boggs → created an issue.
greg boggs → created an issue.
Thanks for the review! Happy to get improvements committed if someone wants to open a merge request with fixes, even if they aren't perfect yet.
And to confirm the Glossary module is still abandoned with only a release for Drupal 7?