Fix Missing WordPress Thumbnails: GD & Imagick Extension Guide

You upload a photo to the WordPress media library and it looks fine at first — the file shows up, you can even open the full-size image. But the thumbnails never generate, featured images look broken on the front end, or WooCommerce product photos won't crop to the right size. Nothing in the WordPress error log makes it obvious why. Nine times out of ten, the culprit is a missing or misconfigured image-processing library on the server: GD or Imagick.

Symptom: Thumbnails Never Show Up

The pattern usually looks like one of these:

• You upload an image, the original file saves fine, but every thumbnail size (150x150, 300x300, etc.) is either missing or just a copy of the full-size image.
• WooCommerce product galleries show stretched or uncropped photos instead of the size you set in Appearance → Customize → WooCommerce.
• Plugins like Regenerate Thumbnails or Force Regenerate Thumbnails fail partway through, or complete without actually fixing anything.
• The Site Health tool under Tools → Site Health → Info → Media Handling shows "No support" or blank fields where it should list an image editor.

If you check your PHP error log (usually under public_html/error_log in cPanel, or your VPS's PHP-FPM log), you might see something like:

PHP Fatal error: Uncaught Error: Call to undefined function imagecreatetruecolor()
PHP Warning: WP_Image_Editor_Imagick::__construct(): Imagick not installed

Cause: No Image Editor Available to PHP

WordPress doesn't do its own image resizing math. It hands the job to whichever PHP image library is available — Imagick first, falling back to GD if Imagick isn't present. If neither extension is enabled for the PHP version your site actually runs, WordPress has no way to crop, resize, or compress anything. It just silently gives up on the thumbnail sizes and, depending on the plugin, either leaves you with the original file or a corrupted placeholder.

This trips people up in a few specific situations:

• You just changed PHP versions in cPanel. Each PHP version in WHM's MultiPHP Manager has its own separate list of enabled extensions. Switching from PHP 8.1 to 8.2 doesn't carry your GD/Imagick settings forward automatically.
• You migrated to a new server or moved to a VPS. A fresh Ubuntu or AlmaLinux install often ships PHP without php-gd or php-imagick installed at all.
• Imagick is installed but broken. This is common right after a PHP minor version bump — Imagick is compiled against a specific PHP ABI, and an update can leave the module present in php.ini but failing to load.

Fix: cPanel / Shared Hosting

If your site is on a cPanel account (SkyServer shared or reseller hosting), this is a two-minute fix through MultiPHP INI Editor or Select PHP Version:

1. Log in to cPanel and open Select PHP Version (sometimes called "MultiPHP Manager" depending on your theme).
2. Confirm which PHP version your domain is actually using — check the top of the page.
3. Click into Extensions for that version.
4. Tick the checkboxes for gd and imagick (enable both if available — WordPress prefers Imagick but will fall back cleanly to GD).
5. Save. No restart needed on most cPanel setups — PHP-FPM or CGI picks it up on the next request.

Then go back to WordPress, install the free Regenerate Thumbnails plugin (or Force Regenerate Thumbnails if you're on WooCommerce with multiple registered image sizes), and run it once against your whole media library. This rebuilds every missing thumbnail size using the now-available image library.

Fix: VPS / Root Server

On a VPS you're managing PHP yourself, so it's a package install rather than a checkbox. For a typical Ubuntu/Debian box running PHP-FPM:

sudo apt update
sudo apt install php8.2-gd php8.2-imagick
sudo systemctl restart php8.2-fpm
sudo systemctl restart nginx

Swap php8.2 for whatever version php -v reports. On AlmaLinux/CloudLinux with cPanel's own PHP builds, use the EA-PHP package naming instead:

sudo yum install ea-php82-php-gd ea-php82-php-pecl-imagick
sudo systemctl restart cloudlinux-selector 2>/dev/null
sudo /scripts/restartsrv_httpd

Verify it actually loaded before you move on:

php -m | grep -iE 'gd|imagick'

You should see both gd and imagick in the output. If imagick installed but doesn't show up, check /etc/php/8.2/mods-available/imagick.ini exists and is symlinked into conf.d — sometimes the PECL install finishes without registering the module.

Confirming the Fix Worked

Don't just trust that the checkbox saved. Confirm in WordPress itself:

Prevention

A few habits keep this from resurfacing:

• Re-check extensions after every PHP version change. Make it a standing step in your upgrade checklist, not an afterthought.
• Enable both GD and Imagick, not just one. If Imagick ever breaks after an update, WordPress falls back to GD instead of failing outright.
• Test uploads immediately after any server migration. Don't wait for a customer to report broken product photos — upload a test image yourself as part of your go-live checklist.
• Watch PHP-FPM error logs for a week after upgrades. Imagick's ABI mismatches don't always show up on day one if cached thumbnails are still being served.

If you're on SkyServer shared hosting and this checkbox is greyed out or missing for your account, open a support ticket — it usually means the extension needs enabling at the WHM/server level rather than the per-account MultiPHP page.

Frequently Asked Questions

Why does WordPress prefer Imagick over GD?

Imagick generally produces better quality resizing and handles more formats (including some RAW and vector formats GD can't touch), and it's less memory-hungry on very large images. GD is more universally available and lighter to install, which is why WordPress falls back to it automatically when Imagick isn't present.

Can I fix this without server/cPanel access?

Not really. GD and Imagick are compiled PHP extensions, not WordPress plugins — there's no way to add the actual image-processing capability from inside wp-admin. If you're on hosting where you can't reach PHP settings, this is exactly the kind of issue to hand to your host's support team.

I enabled GD and Imagick but old images are still broken. What now?

Enabling the extension only fixes new uploads going forward. Existing attachments need their thumbnails rebuilt explicitly — run Regenerate Thumbnails (or Force Regenerate Thumbnails for WooCommerce) against your media library once the extensions are confirmed active.

Does this affect anything besides thumbnails?

Yes. Anything that relies on server-side image manipulation is affected: WooCommerce product image cropping, some page builder image optimization features, PDF-to-image plugins, and any plugin that generates OG/social share images dynamically.

How do I know which PHP version my site is actually using?

In WordPress, check Tools → Site Health → Info → Server, which lists the exact PHP version handling requests. This is the version you need to enable GD/Imagick for — it's easy to edit the wrong version's extensions in MultiPHP Manager if your account has more than one PHP version installed.