cPanel EasyApache 4: Rebuild PHP/Apache Without Breaking Sites
Every VPS or dedicated cPanel server owner eventually opens WHM, clicks into EasyApache 4, adds one PHP extension, hits "Provision," and then spends the next hour fielding "why is my site down" tickets. It's not bad luck - EasyApache 4 rebuilds your entire Apache and PHP stack from a profile, and a profile change can ripple into every account on the box. Here's what it actually does, why rebuilds break sites, and how to run one without surprises.
What EasyApache 4 Actually Is
EasyApache 4 (EA4) is WHM's build system for Apache, PHP, and their modules. Unlike the old EasyApache 3, EA4 packages everything as RPMs and applies changes through a profile - a JSON file listing exactly which Apache modules, PHP versions, and PHP extensions should be installed. When you "provision" a change, WHM compares your current state to the profile, then installs, removes, or recompiles packages to match it.
That matters because a rebuild isn't additive-only. If a module isn't in the profile you save, EA4 removes it - even if a site depends on it.
Every provision also gets logged under /var/cpanel/easy/apache/, including a history of previous profiles. Most admins never look there until something breaks - it's worth knowing it exists before you need it.
Symptom: Sites Break Right After a Rebuild
The usual pattern support sees: an admin adds one PHP extension (say, imagick or redis) for one client, clicks through the wizard, and twenty minutes later half the accounts on the server are throwing errors. Common ones:
- WordPress sites showing a 500 error or white screen right after the rebuild finishes
- A specific plugin (WooCommerce, image editors, caching plugins) suddenly fatals with
Call to undefined function - PHP-FPM refusing to restart, or Apache failing to come back up at all
mod_securityor a custom Apache module missing fromhttpd -Moutput
Cause: Profiles Don't Carry What You Think They Do
A few things catch people out every time:
| What breaks | Why it happens |
|---|---|
| A PHP extension a site needs (imagick, mcrypt-style legacy extensions, redis, memcached) | It was never in the saved profile, so EA4 uninstalls it as part of "matching" the profile - even though it was working fine before |
| PHP handler mismatch (suPHP vs PHP-FPM vs DSO) | MultiPHP Manager settings can get reset to a default handler after certain EA4 changes, especially after a fresh version is added |
| Custom Apache modules (ModSecurity rule sets, mod_pagespeed, mod_ruid2) | Anything installed outside the EA4 package system isn't tracked by the profile and gets wiped on a rebuild that touches Apache |
| Apache won't restart | A syntax error introduced by a module that didn't recompile cleanly, or a vhost include referencing a module that's no longer loaded |
Fix: Recover From a Bad Rebuild
1. Check what actually changed
Start with the EA4 provisioning log - it tells you exactly what was installed or removed:
tail -n 200 /var/log/ea4/pkgmanage.logCross-check current PHP modules against what a site needs:
/usr/local/cpanel/bin/rebuild_phpconf --current
php -v
php -m | grep -i imagick2. Re-add the missing extension
In WHM, go to EasyApache 4 → Customize, pick the PHP version(s) affected, and re-check the missing extension under "PHP Extensions." Save, then provision again - this is the safe direction, since you're adding back to the running profile rather than replacing it.
From the command line, the equivalent is:
/scripts/easyapache4 --install ea-php81-php-imagick(swap ea-php81 for whatever PHP version tag the site is on - check with whmapi1 php_get_installed_versions).
3. Fix a wrong PHP handler
Go to WHM → MultiPHP Manager, select the affected domain(s), and confirm the handler is set to PHP-FPM (the modern default) rather than suPHP or DSO, unless a site specifically needs the older handler. Apply, then test the site before moving to the next domain - don't bulk-apply across every account at once.
4. If Apache won't come back up
Test the config before restarting blind:
apachectl configtest
/scripts/restartsrv_httpdconfigtest will name the exact vhost or module line causing the failure, which is faster than guessing.
Prevention: Rebuild Like You Mean It
- Export your current profile before touching anything - WHM → EasyApache 4 → Profiles → "Save Current Configuration As." If a rebuild goes sideways, you can re-provision the exact working state.
- Take a VPS snapshot first if you're on a plan that supports it. A snapshot restore is faster than untangling a partial rebuild by hand.
- Run it in a low-traffic window. A full rebuild can take Apache offline for a few minutes; don't do it during business hours on a shared box.
- Check what every site on the server actually uses before removing anything from the profile -
grepyour vhost configs andwp-contentplugin folders for extension dependencies rather than assuming nothing relies on it. - Change one thing at a time. Adding an extension and swapping a PHP version in the same provision makes it much harder to tell which change caused a break.
Rolling Back a Profile
If you saved a profile before the change, restoring it is the cleanest fix:
whmapi1 fetch_current_ea4_profile
/scripts/easyapache4 --build-profile=/var/cpanel/easy/apache/profile/exported/your_saved_profile.jsonThis re-provisions the server back to the known-good state rather than trying to manually reverse each package change.
EasyApache 4 is one of the more powerful tools in WHM, but it treats the profile as the single source of truth - not "the current state plus whatever you clicked." Save a profile before every change, add extensions instead of full rebuilds when you can, and test one domain before assuming the whole server is fine.
Frequently asked questions
Will EasyApache 4 restart Apache and take my sites down?
A provision that only adds a PHP extension is usually quick, but any change touching Apache modules or the httpd package itself restarts the web server, causing a brief outage. Always run rebuilds in a low-traffic window.
Why did my PHP extension disappear after I only added a different one?
EasyApache 4 rebuilds to match the saved profile exactly. If the existing extension was installed outside that profile (manually via yum, for example) rather than through WHM, the next provision removes it because the profile doesn't list it.
How do I know which PHP version and handler a specific domain is using?
Check WHM → MultiPHP Manager for the per-domain PHP version, and look at the account's PHP-FPM/suPHP setting in the same screen. From SSH, `whmapi1 php_get_vhost_versions` lists it for every domain at once.
Can I undo an EasyApache 4 rebuild?
There's no single undo button, but if you exported your profile beforehand you can re-provision that saved profile to restore the prior module and version set. Without a saved profile, you'll need to manually reinstall the missing packages via `/scripts/easyapache4 --install`.
Is it safe to remove PHP extensions I don't recognize during a rebuild?
No - check every account's codebase first. Extensions like imagick, redis, or memcached are easy to assume are unused when they're actually load-bearing for one client's caching or image processing, and removing them silently breaks that site.