undefined - Contrib.social

✨ | Drupal core | SVG Low Quality Image Placeholders

🇪🇨Ecuador jwilson3

Thanks @aficiona2 for catching the math error. a 5kb image is way more reasonable for inlining with data URI.

Here are some things we can try to reduce the LQIP-LCP image size even further:

1. Lower the WebP quality parameter to its minimum (quality=1). However, in my testing, even at this setting, the generated file size is still much larger than the theoretical minimum bits-per-pixel limit.

Full-res image: ~40 KB
Theoretical LQIP-LCP image: ~5 KB
Actual LQIP with WebP configured to use quality=1: ~14 KB

Other potential approaches:

2. Downscale the image before converting to WebP at quality=1.

3. Apply a blur (box or Gaussian, with varying strengths) before converting to WebP at quality=1.

4. Downscale, then upscale the image before converting to WebP at quality=1.

5. Downscale, convert to WebP at quality=1, then upscale client-side (in the browser).

6. Experiment with other lossy formats/algorithms (e.g., JPEG, AVIF). However, some formats may not achieve smaller sizes than WebP at their lowest quality settings.

It’s worth noting that achieving the theoretical bits-per-pixel limit is highly dependent on the visual complexity and entropy in the source image. Simple images compress much better than complex, detailed ones. To find a reliable algorithm or processing pipeline that consistently approaches this limit across a variety of images and sizes will likely be more challenging than it appears, and may require a multi-pass approach (adding to algorithmic time). Extensive testing with diverse images will be necessary to identify a robust solution. For that reason, I humbly also add a 7th option:

7. Look to see if someone has already worked on an "LCP" algorithm to do this already.

✨ | Search API | Enabled local development env with DDEV

Comment 14 days ago →

🇪🇨Ecuador jwilson3

Why not use a single DDEV environment for a core branch and clone contrib projects into it?

Two main reasons:

DDEV environments are cheap to spin up. It’s better to isolate contrib modules in their own environments to avoid conflicts and ensure clean, reproducible setups. Sharing a single site across unrelated modules can create unnecessary complexity around config, database, and dependency management.
Composer isn’t great at working from local composer.json files across multiple contrib modules. It typically tries to fetch packages from the web, making it hard to test local changes to a module’s dependencies. By contrast, ddev-drupal-contrib builds directly from a module’s local composer.json, including require-dev dependencies for optional integrations.

This approach avoids local dependency tree hell and ensures all contributors run the same clean, isolated, and predictable environment.

📌 | Drupal core | Update Drupal's default file type icons

Comment 21 days ago →

🇪🇨Ecuador jwilson3

t would be nice if there was an automated solution to always minify SVGs in core in the same way, because different tools optimize in different ways, using different default options, often stripping out important attributes. Applications that generate SVGs also generate their own different ways of structuring the SVG, so every time you pull an "optimized" file into an SVG editor, and save it again, it may make unrelated changes on the roundtrip back to optimized SVG. Therefore, the SVGs require manual edits after optimization to restore settings.

I think what is missing here is clear agreement to treat SVGs as implementation assets, not hand-curated visual code.

📌 | Drupal core | Update Drupal's default file type icons

Comment 21 days ago →

🇪🇨Ecuador jwilson3

Also worth noting: running SVGs through optimizers like SVGO can make them harder to review and maintain. For example,

path="M11 0L14 3V16H2V0H11ZM3 15H13V4H10V1H3V15ZM11 3H12.5L11 1.5V3Z"

becomes

path="m11 0 3 3v13H2V0zM3 15h10V4h-3V1H3zm8-12h1.5L11 1.5z",

which is more compact but much less readable for quick diffs or manual review.

📌 | Drupal core | Update Drupal's default file type icons

Comment 21 days ago →

🇪🇨Ecuador jwilson3

Isn't this kind of micro-optimization mostly obviated by gzip or brotli? I'm happy to be wrong, but these savings seem negligible in practice—especially considering that Drupal core’s own HTML output doesn’t aggressively strip whitespace, newlines, or indentation either.

✨ | CKEditor 5 Paste Filter | Expose raw pasted HTML for debugging Regex filters

Comment 21 days ago →

🇪🇨Ecuador jwilson3

Here is the RTF file I used for testing.

✨ | CKEditor 5 Paste Filter | Expose raw pasted HTML for debugging Regex filters

Comment 21 days ago →

🇪🇨Ecuador jwilson3

Here is a partial config export for what I've tested:

    ckeditor5_paste_filter_pasteFilter:
      enabled: true
      filters:
        -
          enabled: true
          weight: -18
          search: '<o:p><\/o:p>'
          replace: ''
        -
          enabled: true
          weight: -17
          search: '(<[^>]*) (style="[^"]*")'
          replace: $1
        -
          enabled: true
          weight: -16
          search: '(<[^>]*) (face="[^"]*")'
          replace: $1
        -
          enabled: true
          weight: -15
          search: '(<[^>]*) (class="[^"]*")'
          replace: $1
        -
          enabled: true
          weight: -14
          search: '(<[^>]*) (valign="[^"]*")'
          replace: $1
        -
          enabled: true
          weight: -12
          search: '<font[^>]*>'
          replace: ''
        -
          enabled: true
          weight: -11
          search: '<\/font>'
          replace: ''
        -
          enabled: true
          weight: -10
          search: '<span[^>]*>'
          replace: ''
        -
          enabled: true
          weight: -9
          search: '<\/span>'
          replace: ''
        -
          enabled: true
          weight: -8
          search: '<p>&nbsp;<\/p>'
          replace: ''
        -
          enabled: true
          weight: -7
          search: '<p><\/p>'
          replace: ''
        -
          enabled: true
          weight: -6
          search: '<b><\/b>'
          replace: ''
        -
          enabled: true
          weight: -5
          search: '<i><\/i>'
          replace: ''
        -
          enabled: true
          weight: -4
          search: '<a name="OLE_LINK[^"]*">(.*?)<\/a>'
          replace: $1
        -
          enabled: true
          weight: -3
          search: '<p>\W*<br>\W*&nbsp;\W*<\/p>'
          replace: ''
        -
          enabled: true
          weight: -2
          search: '<p>\W*<br>\W*<\/p>'
          replace: ''
        -
          enabled: true
          weight: -13
          search: '(<[^>]*) (dir="ltr")'
          replace: $1
        -
          enabled: true
          weight: -1
          search: (<br>)+
          replace: '<br>'
        -
          enabled: true
          weight: 0
          search: (<p><br></p>)+
          replace: '<p><br></p>'
        -
          enabled: true
          weight: 1
          search: '<br>\n'
          replace: '<br>'
        -
          enabled: true
          weight: 2
          search: \n+
          replace: '<br>'

✨ | CKEditor 5 Paste Filter | Expose raw pasted HTML for debugging Regex filters

Comment 21 days ago →

🇪🇨Ecuador jwilson3

jwilson3 → created an issue.

✨ | Label Help | Add Label Help support for the Autocomplete Deluxe widget

Comment 23 days ago →

🇪🇨Ecuador jwilson3

I'm not certain if I should change the $use_case to a new number

The use_case needs to be incremented to the lowest unused number. (Currently that would be 18).

✨ | Label Help | Add Label Help support for the Autocomplete Deluxe widget

Comment 23 days ago →

🇪🇨Ecuador jwilson3

Maintainer here. Thank you for the excellently written issue complete with MR!

I get the sense from the resulting markup that _label_help_append_title() is not ideal from an accessibility standpoint

You're probably right here. _label_help_append_title() is kind of the "worst case" scenario when nothing else works.

So what I recommend you do is to replace that with the other options to see if any of the other options work better and put the label help in the correct place, visually, on the form element.

_label_help_prepend_field_prefix($element, $content, $use_case);
_label_help_prepend_description($element, $content, $use_case);
_label_help_append_label_suffix($element, $content, $use_case);

If any of these work better than append_title, pls update to the MR. If not, leave a comment to that effect.

Thank you!

✨ | Search API | Enabled local development env with DDEV

Comment 26 days ago →

🇪🇨Ecuador jwilson3

I added ddev and ddev-drupal-contrib to Svg Image Field contrib module and to Rivet contrib theme, but ddev-drupal-contrib advocates for also committing the custom ddev commands it provides, it does become burdensome to keep things updated as the drop keeps moving (between ddev updates, drupal updates, ddev-drupal-contrib updates).

instead of putting a complete ddev config inside each module, a single config file should be sufficient.

Ideally, in the future, boilerplate code for providing local development environments will be reduced.

Strong 1+. This seems like the ideal goal to shoot for. For example, it would be fantastic if ddev addons (like ddev-drupal-contrib) could be added to a single .ddev/config.contrib.yml file and not have to commit all those custom commands. Users could run ddev config for their environment, and ddev pulls in the contrib file. Configuration overrides & customizations would go in .ddev/config.local.yml. Then, if the contrib module or theme itself needs custom DDEV commands, docker settings(?), or other things it could either commit them directly to the module's .ddev folder or create a separate ddev-addon-template, and add a dependency for their own ddev addon maintained in a separate codebase.

🐛 | CKEditor Font Size and Family | <span style> breaks 'Limit allowed HTML tags and correct faulty HTML' validation

Comment 29 days ago →

🇪🇨Ecuador jwilson3

Fix issue summary HTML code readability.

✨ | Drupal core | SVG Low Quality Image Placeholders

Comment about 1 month ago →

🇪🇨Ecuador jwilson3

I added a way to run lighthouse (locally, via the npm library) against all of the pages in the test site. I ran against the pages using a 1s delay and without any delay at all. Each run gives slightly different performance score but generally stays within a 2 point range in the mid nineties on each page, except for one. The "Ultimate LQIP" page can vary between a score of 100 AND then go consistently below 90 (as low as 87) in different runs. This must have something to do with the extra intermediate low-res image latency being what amounts to a double edged sword.

https://3523781-drupal-lqip.elementalidad.com/results.php

https://github.com/jameswilson/3523781-Drupal-LQIP/commit/245cbbc1d787a2...

🐛 | Feeds | Creation of dynamic property Drupal\feeds\Feeds\Item\SyndicationItem::$parent:fid is deprecated

Comment about 1 month ago →

🇪🇨Ecuador jwilson3

Any chance we could get a 3.1 (or 3.0.1) release that includes this fix? This generates a lot of unnecessary noise in logs.

We are seeing deprecation warnings on cron run after updating to PHP 8.3.21 and clearing caches. These are only notice errors, I think, so we should still be fine. But there are about 500 of them after running cron from the admin UI.

    Deprecated function: Creation of dynamic property 
    Drupal\feeds\Feeds\Item\SyndicationItem::$blog 
    is deprecated in Drupal\feeds\Feeds\Item\BaseItem->set() 
    (line 21 of modules/contrib/feeds/src/Feeds/Item/BaseItem.php).

    Deprecated function: Creation of dynamic property 
    Drupal\feeds\Feeds\Item\SyndicationItem::$parent:field_group 
    is deprecated in Drupal\Core\Queue\DatabaseQueue->claimItem() 
    (line 150 of core/lib/Drupal/Core/Queue/DatabaseQueue.php).

✨ | Drupal core | SVG Low Quality Image Placeholders

Comment about 1 month ago →

🇪🇨Ecuador jwilson3

Re: #15

adding the css .loaded class in inline js with a CSS rule is causing it to be the LCP again. So I don't think it's showing what the LCP would be for the different approaches.

The .loaded class is used on several of the examples (SQIP, BlurHash, Ultimate LQIP, CSS-only LQIP) to change opacity with a smooth transition between the blurred placeholder and the full-res version.
For contrast, the LQIP WebP Smooth example uses a slightly different technique to change opacity smoothly, via an inline style opacity:1 loaded via inline JS onload, but the smoothing transition effect on the opacity is still defined in CSS (I don't believe the distinction between inline vs CSS ultimately matters for performance other than if your page has many images at some point you're sending down a lot of duplicitous bytes).
Finally, the basic examples (LQIP BMP, LQIP PNG, and LQIP WEBP) do not use any smoothing transition and just rely on browser loading to show the full-res image and overlay the low-res placeholder.

I don't think LCP is affected by the opacity change (both with or without smoothing effect). Rather, the problem with the LCP is that all examples except "Ultimate LQIP" use placeholders that have a Bits-Per-Pixel ratio far less than the recommended 0.05 which means LCP will always consider the repaint of the full-res image.

The takeaway is that we cannot effectively reduce LCP with the LQIP technique unless the placeholder image is large enough >0.05BPP. And for the image to be "large enough" to take over the LCP for the 1200 pixel wide hero in the example site, it has to be on the order of 40k in size, which IMO rules out the option of base64 inlining. This implies the LQIP must be a reference to another image file, and yet another request (with potential latency) to download the placeholder image, somewhat defeating the other intended of the goal of the LQIP (having something on screen fast, at page load time, ideally piggy-backed inline via the HTML request).

📌 | Drupal core | Add option for fetchpriority attribute within "image loading" area on image field formatter

Comment about 1 month ago →

🇪🇨Ecuador jwilson3

The data model and schema should support all fetchpriority values — no question there. But I’d question the utility of exposing them at the image field formatter level.

Take the carousel example: there are (at least) two common patterns in Drupal:

A multi-cardinality image field used as the image source, or
A series of entities (e.g. paragraphs, ECK) each with a single image field.

In both cases, there's no reliable context at the field formatter or view mode level to determine which images are visible at page load. Exposing fetch priority there risks encouraging awkward architectures — e.g., splitting fields just to differentiate high vs low.

The complexity only increases with variations like random first slides or responsive carousels showing N slides. Handling these correctly almost always requires custom logic (alter hooks, preprocess).

A UI trying to cover this would have to offer nuanced options like:

Unspecified (let browser decide)
High (for LCP-critical images)
Low (for images above the fold but not visible initially)

For multi-cardinality:

First is high, others unspecified
First is high, others low
First N are high, rest low/unspecified

…which quickly gets unwieldy and still doesn’t address entity-based carousels.

In short, this might be better solved downstream (e.g., in preprocess) where real context exists.

✨ | Drupal core | SVG Low Quality Image Placeholders

Comment about 1 month ago →

🇪🇨Ecuador jwilson3

Re: #15 (.loading class LCP issue) Thank you. I'll try to make sense of what you're saying and get to the bottom of this soon. But happy to have a PR if you know what the fix would be offhand. (The project is setup for DDEV running locally).

Re: #16 (SQIP) While SQIP is a "superior" image, there are two major reasons it is problematic: it is both resource intensive on the server-side and on the client-side. For the server-side, even if we were to reimplement `sqip` in PHP, I expect it will be a fair bit more resource intensive than simply scaling down a raster image to 8x8 and applying a simple box blur, which Drupal image styles can do for us OOTB today. On the client-side, the problem is the <g filter="blur(12px)"> which is applied via browser rendering. you can inspect https://3523781-drupal-lqip.elementalidad.com/images/hero.sqip.svg to see the file that was generated by the npm library.

The sqip command took about 2.6 seconds to run, used about 4 CPU cores, (thats >10s total compute time) for the 400kb image.

If you look at the animated GIF demonstrating the processing progression of the underlying binary used by sqip, it becomes fairly obvious this is intensive work: https://github.com/fogleman/primitive?tab=readme-ov-file#progression

✨ | Drupal core | SVG Low Quality Image Placeholders

Comment about 1 month ago →

🇪🇨Ecuador jwilson3

For base64 images we need img-src data:, not entirely sure about SVG.

If you load SVG via data URI (e.g., src="data:image/svg+xml;base64,..."), then it would be covered by img-src data:. But we'll also need to ensure any generated SVGs (especially via 3rd parties) are additionally XSS sanitized.

It's a good point to consider, and maybe we'd have to have a site-level configuration to pick using inline data uris, or additional requests for the thumbnails.

✨ | Drupal core | SVG Low Quality Image Placeholders

Comment about 1 month ago →

🇪🇨Ecuador jwilson3

I set up a test site with a few LQUIP approaches to be able to test the visual load transitions (using a poor man's "delay" dropdown parameter to simulate latency and to actually see the LQIP for more than a brief second).

A couple baselines (OOTB Drupal eager/lazy load settings).
A couple basic LQIPs based on an inline square 8x8 thumbnail inspired by how Unsplash does it. Unsplash uses an inline BMP, but I also tested with inline PNG (same size as BMP), and an inline WebP which produced a much smaller inline payload as well as a slightly different visual blur (the BMP and PNG were visually equivalent). The key here is to add a simple box blur to the 8x8 thumbnail to avoid browsers rendering jagged edges between adjacent high-contrast pixels when scaling up the thumbnail to full-res size in the browser. I also tested without blur, and with larger thumbnails like 16x9, but none of these options look as visually appealing as the simple, blurred 8x8 square image.
A LQIP WebP Smooth using an 8x8 blurred WebP inline thumbnail with smooth fade-in effect requiring an "onload" JS to transition from low- to high-res. IMO this is the clear winner to satisfy the visual perspective, architectural simplicity (no 3rd party deps aside from GD), and resource usage both client- and server-side.
The Ultimate LQIP technique, which depends on 2 LQIPs and suffers from the twice the number of http requests.
The Blurhash technique. Blurhas has an existing Drupal module, but calculating the blurhash is fairly resource intensive on the server-side, and the Drupal module doesn't have any caching. It also depends on the clever base83 hash being decoded with Javascript on the client-side, but the 3rd party library is a JS module which complicates usage for Drupal requiring the use of import and knowing the path to the library JS file.
A couple CSS-blur techniques including:
- a client-side blur of a small thumbnail. CSS blur applied to an image looks really bad around the edges of the image and is a non-starter.
- CSS-only LQIP technique. This has horrible CSS complexity to create the integer hash and the clien-side CSS gradient code to "decode" the integer hash. Also, the resulting effect of the grayscale gradient applied onto the image's calculated average color (which must be calculated server-side from the source image) look extremely simplistic compared to the 90-byte WebP thumbnail.

I had a look at LCP for each of these with WebPageTest and PageSpeed Insights, but couldn't find a solid winner emerge. In my tests, the "Ultimate LQIP" option had the worst LCP of them all on WebPageTest, so it appears that the LCP algorithm may vary based on what tool is being used. YMMV.

Ultimately, I think the LCP goal is possible but difficult to achieve for hero images with an LQIP approach alone, since you need twice the requests and the >BPP0.055 ratio ends up creating a fairly large image for the LCP (44-kilobyte) versus a simple 90-byte 8x8 thumbnail. However, it is also worth noting that none of the other approaches I've found that depend on a low-res blurred image or css-gradient will positively affect LCP since they inherently do not meet the minimum BPP ratio.

Looking forward to having others' thoughts, insights, and reviews.

Code here: https://github.com/jameswilson/3523781-Drupal-LQIP
Site here: https://3523781-drupal-lqip.elementalidad.com/

✨ | BlurHash | Don't generate blurhashes at render time

Comment about 1 month ago →

🇪🇨Ecuador jwilson3

Because the blurhash is calculated inside a hook_preprocess_image() function, unnecessary and costly regeneration of the hash happens after a Drupal cache rebuild or anytime the hook is executed such as during theme development when Twig caching is disabled. This severely hinders the theming process so as to be completely unusable on any page with an image of significant size.

Therefore, I would reiterate the importance of caching the generated blurhash either in the database (as issue summary suggests) or at the very least in the filesystem.

🇪🇨Ecuador @jwilson3

Merge Requests

!11983Update Drupal's default file type iconsOpen Show issue Drupal core

!41Drupal\Component\Plugin\Exception\PluginException: The plugin (svg) did not specify an instance class.Open Show issue SVG Image Field

!35Ensure footer links are colored correctlyMerged Show issue Rivet

!34Update to rivet 2.9.0Merged Show issue Rivet

!33Update Ddev and ddev-drupal-contrib to 1.0.0-rc22Merged Show issue Rivet

!32Theme local actions blockMerged Show issue Rivet

Recent comments

!11983Update Drupal's default file type icons
Open
Show issue
Drupal core

!41Drupal\Component\Plugin\Exception\PluginException: The plugin (svg) did not specify an instance class.
Open
Show issue
SVG Image Field

!35Ensure footer links are colored correctly
Merged
Show issue
Rivet

!34Update to rivet 2.9.0
Merged
Show issue
Rivet

!33Update Ddev and ddev-drupal-contrib to 1.0.0-rc22
Merged
Show issue
Rivet

!32Theme local actions block
Merged
Show issue
Rivet