Logo
cPanel PHP Apache EU-hosting legacy-hosting

cPanel EasyApache4 PHP module conflict: rebuilding Apache with compatible modules

Resolve PHP module conflicts in cPanel EasyApache4 when package dependencies clash during Apache rebuilds, causing build failures or broken PHP installations.

·
EasyApache4 refuses to build. PHP extensions won't load. yum spits out dependency conflicts between ea-php packages. Your sites are stuck on a broken PHP configuration and WHM shows the build as failed. Here's how to untangle it.

For broader hosting infrastructure operations, see our dedicated server operations page.

Symptoms

EasyApache4 build fails with dependency errors, or PHP silently drops extensions after a partial build:

# EasyApache4 build fails with conflicts
/usr/local/cpanel/bin/rebuild_phpconf --current
# Error: Transaction check error:
#   file /opt/cpanel/ea-php81/root/usr/lib64/php/modules/imagick.so
#   from install of ea-php81-php-imagick-3.7.0-1.el7.x86_64
#   conflicts with file from package ea-php81-php-pecl-imagick-3.6.0-2.el7.x86_64

# PHP missing expected modules
php -m | grep -i imagick
# (no output - module not loaded)

# Yum shows conflicting packages
yum list installed | grep ea-php
# ea-php81-php-imagick.x86_64         3.7.0-1.el7   @EA4
# ea-php81-php-pecl-imagick.x86_64    3.6.0-2.el7   @epel-ea4

# WHM EasyApache4 profile shows build failure
whmapi1 php_get_installed_versions
# version: ea-php74
# version: ea-php81
# (but modules are incomplete)

Sites return 500 errors on pages requiring missing extensions. WordPress sites fail with “Your PHP installation appears to be missing the MySQL extension” or similar.

Cause

PHP module conflicts in EasyApache4 typically arise from three scenarios:

  • Multiple package sources for the same extension - cPanel’s EA4 repo and a third-party repo (EPEL, Remi, IUS) both provide the same PHP module under different package names
  • Version pinning conflicts - an older ea-php package is locked by yum versionlock while newer dependencies require an updated version
  • Cross-version module contamination - modules installed for ea-php74 pull in shared libraries that conflict with ea-php81 or ea-php82 modules

cPanel’s EasyApache4 system expects exclusive control over PHP packages in /opt/cpanel/ea-php*/. When third-party repos inject packages into that namespace, or when manual yum install commands bypass EasyApache4’s dependency resolver, the build system cannot reconcile the package graph.

This is especially common on servers that have been upgraded through multiple cPanel versions or where previous administrators installed PHP extensions manually rather than through WHM.

Fix

Step 1: Identify the conflicting packages

# List all EA4 PHP packages and their source repos
yum list installed | grep ea-php | sort

# Check for duplicate providers of the same module
rpm -qa | grep -E "ea-php.*(imagick|redis|memcached|sodium)" | sort

# Check which repos are enabled
yum repolist enabled | grep -iE "epel|remi|ius|ea4"

# Look for versionlock entries blocking updates
yum versionlock list | grep ea-php

Step 2: Remove conflicting third-party packages

# Remove the third-party version (keep the EA4 version)
# Identify which package is from the third-party repo
rpm -qi ea-php81-php-pecl-imagick | grep "From repo"
# From repo   : epel-ea4

# Remove the conflicting package
yum remove ea-php81-php-pecl-imagick

# If versionlock is blocking updates, clear the lock
yum versionlock delete ea-php81-php-imagick

Step 3: Clean yum metadata and verify repo priorities

# Clear all cached metadata
yum clean all

# Ensure EA4 repo has higher priority than third-party repos
cat /etc/yum.repos.d/EA4.repo | grep priority
# Should be: priority=15 (lower number = higher priority)

# If priority is missing or too high, set it
sed -i '/\[EA4\]/a priority=15' /etc/yum.repos.d/EA4.repo

# Exclude ea-php packages from third-party repos
echo "exclude=ea-php*" >> /etc/yum.repos.d/epel.repo

Step 4: Rebuild PHP configuration cleanly

# Regenerate the PHP configuration
/usr/local/cpanel/bin/rebuild_phpconf --current

# If the above still fails, do a full EA4 profile rebuild
# First, export your current profile
whmapi1 php_get_installed_versions
ea_current_to_profile --output=/root/ea4-backup-profile.json

# Remove all PHP packages for the problematic version
yum remove 'ea-php81-php-*'

# Reinstall from the saved profile
/usr/local/cpanel/scripts/ea_install_profile --profile=/root/ea4-backup-profile.json

Step 5: Pin package versions to prevent recurrence

# Lock EA4 packages to prevent third-party repo interference
yum versionlock add ea-php81-php-imagick

# Or disable the problematic repo for ea-php packages permanently
yum-config-manager --save --setopt=epel.exclude="ea-php*"

Step 6: Verify PHP handler assignment

# Ensure PHP versions are properly assigned to domains
whmapi1 php_get_installed_versions
# Should list all expected versions

# Check handler configuration
/usr/local/cpanel/bin/rebuild_phpconf --current
# Should show: ea-php81 => cgi / fpm / lsapi

# If using PHP-FPM, restart the pool
systemctl restart ea-php81-php-fpm

Validation

# 1. Verify EasyApache4 reports no package conflicts
yum check 2>&1 | grep ea-php
# Expected: no output (no conflicts)

# 2. Verify PHP loads all expected modules
/opt/cpanel/ea-php81/root/usr/bin/php -m | grep -iE "imagick|redis|mysql|curl"
# Expected: all required modules listed

# 3. Verify Apache serves PHP pages correctly
curl -sI http://localhost/test.php | head -5
# Expected: HTTP/1.1 200 OK

# 4. Verify from WHM API that versions are clean
whmapi1 php_get_installed_versions
# Expected: all configured PHP versions listed without errors

# 5. Test a PHP info page to confirm module loading
/opt/cpanel/ea-php81/root/usr/bin/php -r "phpinfo();" | grep -c "module"
# Expected: count matches expected number of loaded modules

# 6. Check EasyApache4 build status in WHM
whmapi1 ea4_get_build_status
# Expected: state=complete, no errors

If yum check reports no conflicts and PHP loads all expected modules, the build is clean. Apache will serve PHP pages correctly and future EasyApache4 rebuilds will complete without errors.

Servers that have accumulated years of manual package management tend to develop these conflicts repeatedly. Each cPanel update, each PHP version addition, each “quick fix” yum install from a Stack Overflow answer adds another potential conflict. If the hosting panel is fighting you more than it’s helping you, it might be time to reconsider the architecture entirely.

For sites that no longer require dynamic hosting, consider static site conversion - it eliminates both the hosting panel dependency and the attack surface. See our WordPress-to-Jekyll conversion runbook for the full procedure.

 

Jerzy Kopaczewski

Ready to modernise your legacy hosting?

Book a free 30-minute call. We help teams migrate away from panel-managed servers to infrastructure that doesn't fight back - whether that's containerised workloads, static delivery, or managed cloud services.