feat(image): enable the libvips image engine by default (#35989)

[wezell]

Summary

Flips the libvips image engine on by default: IMAGE_API_USE_LIBVIPS goes from false to true.

This is the follow-up switch for the work merged in:

• feat(image): optional libvips (vips-ffm) image engine behind a feature flag (#35989) #35990 — optional libvips (vips-ffm) image engine behind a feature flag (issue feat(image): optional libvips (vips-ffm) image processing engine behind a feature flag #35989)
• feat(image): register libvips rotate filter and SHARED_COMPLETED dotGenerated mode (#36283) #36284 — libvips rotate filter and SHARED_COMPLETED dotGenerated mode (issue libvips: SHARED_COMPLETED dotGenerated mode + register rotate filter #36283)

Nothing else changes — no new filters, no behavioural code, just the default.

Changes

File	Change
VipsManager.java	Config.getBooleanProperty(USE_LIBVIPS, false) → true
dotmarketing-config.properties	IMAGE_API_USE_LIBVIPS=false → true (comment updated)
image/vips/README.md	Default column false → true
ImageFilterExporterEngineSelectionTest.java	Javadoc no longer claims legacy-is-default (the test sets the flag explicitly in every case, so it is default-independent)

Why this is safe to flip

VipsManager.isEnabled() is flag && isAvailable():

• No native libvips installed → isAvailable() is false, the legacy Java2D engine is used exactly as today. Turning the flag on cannot break an install that lacks the library.
• Per-operation failure (corrupt image, missing delegate) → IMAGE_API_LIBVIPS_FALLBACK still defaults to true, so the legacy filter runs for that op.
• Opt-out → set IMAGE_API_USE_LIBVIPS=false, or env DOT_IMAGE_API_USE_LIBVIPS=false (the DOT_ prefix is required for env overrides).

The dotCMS Docker image installs libvips42, so containerized installs get the libvips path; the AVIF encoder plugin is already wired in CI/Docker from #35990.

Rollout note

This changes the engine that serves resized/filtered images by default. Renditions are byte-different from Java2D output (different resampler), so caches regenerate on first request after upgrade — no rendition invalidation is required, but expect a warm-up on first hit per rendition.

Checklist

• Docs updated (image/vips/README.md, config comment)
• Translations — n/a
• Security considered — no new input surface; the flag is read through Config
• Tests — no new tests; engine selection is already covered by ImageFilterExporterEngineSelectionTest (both engines exercised explicitly)

🤖 Generated with Claude Code

[claude]

Claude finished @wezell's task in 1m 20s —— View job

---

Code Review

• Read the diff
• Analyze changed files
• Post review

Reviewed the 5 changed files against origin/main (isolating the PR commits from merged-in noise).

New Issues

• 🟡 Medium: VipsManager.java:59 — the availability probe now memoizes on catch (Throwable t). That's the right call for the intended LinkageError/ExceptionInInitializerError case (the comment correctly explains why vavr Try couldn't be used — it rethrows fatal LinkageErrors). But it also captures VirtualMachineError (e.g. a transient OutOfMemoryError during first-touch native init) and permanently caches available = false for the JVM's lifetime, silently disabling libvips even where the library is present. Low probability, but the failure is sticky and invisible after startup. Consider narrowing to the linkage/native-load errors you actually expect, or at least not memoizing false for VirtualMachineError. Assumption: first probe can coincide with memory pressure. What to verify: whether a re-probe on transient failure is worth the added complexity vs. accepting the sticky-false risk.

Notes (non-blocking)

• VipsManager.java:75 / dotmarketing-config.properties:882 / README.md:14 — default flip to true is consistent across code, config, and docs. The flag && isAvailable() gate plus IMAGE_API_LIBVIPS_FALLBACK=true means an install without native libvips is unaffected, as the PR body states. ✅
• Image.postman_collection.json:222,265 — switching from an exact Content-Length assertion to reading width/height from the PNG IHDR chunk is the correct fix for engine-independent output. Offsets are right (8-byte signature + 4-byte length + 4-byte IHDR type → width at byte 16, height at byte 20), and >>> 0 guards the sign bit. pm.response.stream is the raw response buffer in Newman, so indexing is valid. ✅
• ImageFilterExporterEngineSelectionTest.java:20 — javadoc-only change; each case sets the flag explicitly so the test remains default-independent. ✅

Overall this is a clean, well-scoped default flip. The one Medium above is non-blocking — worth a look but the fallback design makes the change safe.
· issue-35989-enable-libvips-by-default

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request