wp media import fails in the workspace container: no GD/Imagick in its PHP

[louisreingold]

Problem

wp media import fails in the workspace container:

$ wp media import /tmp/img/hero-engine.jpg --porcelain
Error: No support for generating images found. Please install the Imagick or GD PHP extensions.

Anything that goes through WP_Image_Editor is affected the same way — wp media import,
wp media regenerate, and any custom wp eval that calls wp_generate_attachment_metadata().
The import fails outright; you don't get an attachment without thumbnails, you get nothing.

Cause

The workspace image installs PHP CLI plus a hand-picked extension list, and there's no
image extension in it — create-katalystwp/templates/workspace.Dockerfile:

RUN apt-get update && apt-get install -y --no-install-recommends \
        php-cli php-mysql php-curl php-xml php-mbstring php-zip \
        default-mysql-client curl ca-certificates git \
    && rm -rf /var/lib/apt/lists/*

The wordpress container is fine — wordpress:latest ships GD — so the two PHP runtimes
disagree about what WordPress can do. The site itself handles images correctly (media
uploads through wp-admin work, thumbnails generate); only wp-cli, which runs in the
workspace, can't.

Why it matters

This lands squarely on the agent workflow the sandbox exists for. "Build me a site with
photos" is one of the most common things anyone asks an agent to do in one of these
environments, and wp media import <url-or-path> is the obvious way to do it — it's what
the model reaches for first, and it's what WP-CLI's own docs point at.

Observed while an agent built a demo site in a Katalyst env (2026-08-16): it downloaded
five stock photos, hit this error on the first import, and spent several minutes working
around it. What it eventually landed on was copying the files into the shared
wp-content/uploads and calling media_handle_sideload() inside the web container
via the Agent Connector's php-eval ability — the same sideload path WP-CLI uses, just
executed where the image extensions exist. That works, but it's a non-obvious detour that
depends on Agent Connector being installed, and a less persistent agent would have given
up on photos or hotlinked external URLs into the page instead.

Suggested fix

Add GD to the workspace image:

 RUN apt-get update && apt-get install -y --no-install-recommends \
-        php-cli php-mysql php-curl php-xml php-mbstring php-zip \
+        php-cli php-mysql php-curl php-xml php-mbstring php-zip php-gd \
         default-mysql-client curl ca-certificates git \
     && rm -rf /var/lib/apt/lists/*

php-gd is what wordpress:latest itself uses, so this makes the two runtimes agree and
costs a few MB. php-imagick would also work and handles more formats, but it drags in
ImageMagick and its delegates — probably not worth it unless someone wants PDF/TIFF
thumbnails.

Worth a sanity check afterwards that a fresh import produces the same sizes the web
container would (wp media import, then compare _wp_attachment_metadata sizes against
an upload made through wp-admin) — a GD-vs-GD match is expected, but it's cheap to confirm
since the whole point is that the two runtimes should agree.