Hosting, PHP and cPanel errors: the WordPress fix guide (32 errors)

When WordPress breaks, the cause often sits one layer down: in the server, PHP or cPanel. This guide covers that layer, from blocked IPs and disk quotas to PHP handlers, phpMyAdmin imports, AutoSSL and the errors that only appear after a hosting move. Each fix lists the exact error text, why it happens and the steps we use on client sites.

Applies to: cPanel with CloudLinux and LiteSpeed, PHP 8.3 to 8.5, MariaDB and MySQL 8, WordPress 7.1. Last verified: November 2026.

01Quick reference: every error, its likely cause and the first fix

Find your error, then jump to the full fix.

02Start here: where hosting errors actually show up

Hosting problems hide in places WordPress never shows you. Before you change any setting, spend five minutes in these four spots. They name the real cause far more often than guesswork does.

WordPress-level errors such as the critical error, white screen, memory limit and upload limit are covered in our complete WordPress errors guide. This guide covers the layer underneath: the server, PHP configuration, cPanel, databases, DNS, SSL and moving between hosts.

03cPanel account and access errors

Your IP address has been blocked (cPHulk) or the site times out only for you

Quick fix: Test from a phone on mobile data. If the site loads there, your IP is blocked by the server firewall. Ask your host to unblock it and tell them which login failed.

Why it happens: cPanel’s cPHulk brute force protection and firewalls such as CSF block an IP after repeated failed logins to cPanel, email, FTP or WordPress. Saved wrong passwords in an email app or FTP client trigger it again and again.

1. Confirm the block by loading the site on a different network.
2. Find your public IP (search “what is my IP”) and send it to your host’s support.
3. Fix the source: update the saved password in your mail app, FTP client or backup tool.
4. On a VPS with WHM, remove the IP in WHM → cPHulk Brute Force Protection or in the CSF firewall.

This account has been suspended

Quick fix: Contact your host’s billing or support team. Suspension is a manual or automatic account action, not a WordPress error.

Why it happens: Hosts suspend accounts for unpaid invoices, abuse reports, malware or repeated resource overuse.

1. Check your email for a notice from the host. It usually states the reason.
2. Pay the invoice or ask which rule was broken.
3. If malware caused it, clean the site before asking for reactivation (see the security section of our WordPress errors guide).
4. Keep off-site backups so a suspension never blocks access to your own data.

Disk quota exceeded (uploads fail, saving fails, email stops)

Quick fix: Open cPanel → Disk Usage, find the biggest folders and delete old backups, cache and log files. Then check the inode count too.

Why it happens: When the account hits its storage limit, PHP can’t write files. Uploads, updates, cache files, sessions and even incoming email start failing, often with vague errors.

1. Open Disk Usage and sort by size.
2. Look for old backup archives in the home folder or wp-content (backup plugins keep many copies).
3. Delete large error_log files after reading the latest errors.
4. Clear the cache folder of your cache plugin.
5. Empty large mailboxes or set email retention.
6. Move backups off the server, then set the backup plugin to keep only a few local copies.

Inode limit reached (too many files)

Quick fix: Find folders with huge file counts (cache, sessions, email, old backups) and clean them. The disk may look half empty while the file count is maxed out.

Why it happens: Shared hosts limit the number of files, not just total size. Cache plugins, image size variants, PHP session files and mail can create hundreds of thousands of small files.

1. Check the inode count in the cPanel stats sidebar.
2. Over SSH, find the heaviest folders with the command below.
3. Clear plugin caches and old session files.
4. Remove unused image sizes and regenerate only what the theme needs.
5. Delete unused themes, plugins and staging copies inside the account.

find ~ -xdev -type f | cut -d/ -f1-5 | sort | uniq -c | sort -rn | head -20

508 Resource Limit Is Reached

Quick fix: Check cPanel → Resource Usage to see which limit was hit (entry processes, CPU, memory or I/O), then reduce the load or upgrade the plan.

Why it happens: CloudLinux hosts give each account a box of resources. When a site uses up its entry processes or CPU, the server answers with 508 until usage drops.

1. Open Resource Usage and look at the fault columns and the time of the spikes.
2. Match spikes to bots, cron jobs, backups or a busy page in the access log.
3. Enable page caching so most visits skip PHP.
4. Block bad bots at the firewall or CDN.
5. Move backups and heavy cron jobs to quiet hours.
6. If normal traffic hits the limit, the site needs a bigger plan.

For the related 503 and 429 errors, see 503 Service Unavailable and 429 Too Many Requests.

FTP: 530 Login authentication failed

Quick fix: Use the full FTP username (often [email protected]), reset the FTP account password in cPanel → FTP Accounts, and check you’re connecting to the right host and port.

Why it happens: The username or password is wrong, the account belongs to a different domain, or the client is trying FTP on a server that only allows SFTP.

1. Copy the exact username from cPanel → FTP Accounts.
2. Reset the password there and paste it into your client.
3. Use port 21 for FTP or the SSH port for SFTP. Some hosts use a custom SSH port, listed in their dashboard.
4. Too many failed attempts can block your IP: see IP blocked.

SSH or SFTP: Connection refused or timed out

Quick fix: Check the SSH port and whether SSH access is enabled for your plan. Many shared hosts turn it off by default or use a non-standard port.

Why it happens: SSH is disabled, the port is wrong, your IP isn’t allowed, or the firewall blocked you.

1. Find the SSH host, port and username in your hosting dashboard.
2. Enable SSH access or add your IP to the SSH allowlist if the host requires it.
3. Test with ssh -p PORT user@host from a terminal.
4. If it times out on every port, your IP may be blocked: test from another network.

04PHP version and configuration errors

PHP version won’t change (or switches back) in cPanel

Quick fix: Open .htaccess and remove old AddHandler or SetHandler lines for PHP, then set the version again in one place only: MultiPHP Manager or Select PHP Version, not both.

Why it happens: cPanel writes the PHP version as a handler line in .htaccess. Old lines from a previous host or tool override the version you pick. CloudLinux hosts also have two selectors that can conflict.

1. Check the real version in WordPress under Tools → Site Health → Info → Server.
2. Back up .htaccess, then look for blocks like the one below and remove stale ones.
3. Set the version again in your host’s PHP tool. On CloudLinux, set MultiPHP to the native or inherit option and use Select PHP Version.
4. Reload Site Health to confirm.

# php -- BEGIN cPanel-generated handler, do not edit
<IfModule mime_module>
  AddHandler application/x-httpd-ea-php81 .php .php8 .phtml
</IfModule>
# php -- END cPanel-generated handler, do not edit

php.ini or .user.ini changes don’t take effect

Quick fix: Wait 5 minutes, then check again in Site Health or with a phpinfo() page. PHP reads .user.ini on a timer, and the file must sit in the right folder.

Why it happens: PHP caches .user.ini settings for 300 seconds by default. Some hosts ignore custom ini files and want changes made in their PHP options screen. A php.ini in the wrong folder does nothing.

1. Put .user.ini in the WordPress root folder, next to wp-config.php.
2. Wait at least 5 minutes, or restart PHP from the hosting panel if it offers that.
3. Check the active value with a temporary phpinfo() file, then delete it.
4. If nothing changes, use the host’s MultiPHP INI Editor or PHP Options screen instead.

500 error after adding php_value to .htaccess (Invalid command 'php_value')

Quick fix: Remove the php_value and php_flag lines from .htaccess and put the same settings in .user.ini instead.

Why it happens: Those directives only work when PHP runs as an Apache module. Most hosts now run PHP-FPM, LSAPI or CGI, where Apache doesn’t understand them and returns a 500 error.

1. Open .htaccess and delete lines starting with php_value or php_flag.
2. Add the settings to .user.ini in key = value format.
3. Reload the site and confirm the values after 5 minutes.

; .user.ini
memory_limit = 256M
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 300

Missing PHP extension: Class ZipArchive not found, intl, imagick, curl or gd

Quick fix: Enable the extension in cPanel → Select PHP Version → Extensions, or ask your host to install it for your PHP version.

Why it happens: Each PHP version has its own extension list. Switching versions often leaves extensions like zip, intl or imagick turned off, and plugins that need them fail.

1. Read the error: ZipArchive needs zip, Normalizer or IntlDateFormatter need intl, imagecreatefrom… needs gd.
2. Tick the extension for the active PHP version and save.
3. Check Tools → Site Health → Info → Server, which lists missing recommended modules.

open_basedir restriction in effect. File(…) is not within the allowed path(s)

Quick fix: Find which path the code tried to open. Usually it’s an old absolute path from a previous server, or a temp folder outside the account. Fix the path, or ask the host to add the folder.

Why it happens: PHP is only allowed to read and write inside certain folders. After a migration, settings that still point to /home/olduser/ or a system temp folder hit that wall.

1. Note the file path in the warning.
2. Search the database and config files for the old path, and update it.
3. Set WP_TEMP_DIR to a folder inside the account if it’s a temp folder problem.
4. If a plugin needs another folder, ask the host to allow it.

Warning: exec() has been disabled for security reasons

Quick fix: Check whether the plugin really needs that function. Most hosts disable exec, shell_exec and similar for security. Use a plugin that doesn’t need them, or move to a host or VPS that allows them.

Why it happens: The host lists dangerous functions in disable_functions. Backup, image and PDF plugins sometimes rely on them.

1. Find the plugin in the warning path.
2. Look for a setting in the plugin to use a PHP-only method.
3. Ask your host whether they can enable the function for your account. Many won’t on shared plans.

Code changes don’t show up (OPcache serving old PHP)

Quick fix: Reset OPcache from your host panel, the LiteSpeed Cache toolbox or a cache plugin, or restart PHP. Then reload.

Why it happens: OPcache keeps compiled PHP in memory. Some servers only recheck files every few minutes, or never, so edits to PHP files seem to be ignored.

1. Confirm the edit saved by reading the file over SFTP.
2. Reset OPcache with your host tools or a cache plugin that offers it.
3. Wait a few minutes if your host checks file times on a timer.
4. For the browser and page cache side, see changes not showing.

05File and permission errors

failed to open stream: Permission denied

Quick fix: Check ownership and permissions of the file in the error. Folders should be 755 and files 644, owned by your account user.

Why it happens: PHP runs as your account user on most hosts. Files uploaded as another user, extracted by root, or copied with odd permissions can’t be read or written.

1. Read the full path in the error.
2. Check its permissions in File Manager (right-click → Change Permissions).
3. Reset the whole site with the SSH commands below if many files are affected.
4. If permissions look right but it still fails, ask the host to fix ownership. You can’t change owner without root.

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 640 wp-config.php

500 error after setting files or folders to 777

Quick fix: Change them back to 755 for folders and 644 for files. Many servers refuse to run PHP from world-writable files.

Why it happens: Permission 777 lets anyone on the server write the file. Security modules such as suEXEC and suPHP block it on purpose.

1. Find recently changed permissions (often wp-content or uploads).
2. Reset them to 755 and 644.
3. If a plugin asked for 777, it’s wrong. Fix ownership instead.

Upload failed: Failed to write file to disk

Quick fix: Check the disk quota and the PHP temp folder. This error means PHP received the file but couldn’t save it.

Why it happens: The account is out of space or inodes, the temp directory is full or unwritable, or the uploads folder has wrong permissions.

1. Check disk quota and inodes.
2. Check wp-content/uploads permissions.
3. Set WP_TEMP_DIR to a writable folder inside the account and test again.

Browser shows “Index of /” or the host’s default page instead of the site

Quick fix: Make sure WordPress files are in the domain’s document root (often public_html) and that index.php exists there.

Why it happens: The domain points to a folder without an index file, or to a different folder than the one you uploaded to. Addon domains each have their own document root.

1. In cPanel → Domains, check the document root for the domain.
2. Confirm index.php, wp-config.php and wp-content are in that folder.
3. If you see the host’s default page, DNS reaches the server but the site files are elsewhere or missing.
4. Add DirectoryIndex index.php index.html to .htaccess if the server doesn’t look for index.php.

06Database and phpMyAdmin errors

#1045 Access denied for user

Quick fix: Reset the database user’s password in cPanel → MySQL Databases, make sure the user is added to the database with All Privileges, then update wp-config.php.

Why it happens: The username or password is wrong, or the user exists but was never attached to the database. On cPanel, names carry the account prefix, like acct_dbuser.

1. Copy the full prefixed database name and user from MySQL Databases.
2. Reset the user password and paste it into wp-config.php.
3. Under “Add User to Database”, link the user and tick All Privileges.
4. For the WordPress side of this error, see error establishing a database connection.

#2002 Can’t connect to MySQL server (No such file or directory)

Quick fix: Try 127.0.0.1 instead of localhost for DB_HOST, or the database hostname your host gives you. If that fails, the database service is down.

Why it happens: localhost makes PHP use a socket file. If the socket path is different or MySQL runs on another server, the connection fails.

1. Check your hosting dashboard for the correct database host.
2. Change DB_HOST in wp-config.php and test.
3. Ask your host whether MySQL or MariaDB is running.

Unknown collation: utf8mb4_0900_ai_ci (database import fails)

Quick fix: The export came from MySQL 8 and the new server runs an older MariaDB or MySQL. Replace utf8mb4_0900_ai_ci with utf8mb4_unicode_520_ci in the SQL file, then import again.

Why it happens: MySQL 8 uses a collation that older MariaDB versions don’t recognize, so the import stops at the first table.

1. Make a copy of the .sql file.
2. Replace the collation name with a text editor that handles large files, or with sed as shown below.
3. Import the edited file.
4. Better long term: ask both hosts which database versions they run before you migrate.

sed -i 's/utf8mb4_0900_ai_ci/utf8mb4_unicode_520_ci/g' backup.sql

#1071 Specified key was too long; max key length is 767 bytes

Quick fix: Upgrade the database server, or ask the plugin developer for an update. Very old MySQL versions can’t index long utf8mb4 columns.

Why it happens: Older MySQL versions limit index size. A plugin creating a long indexed text column in utf8mb4 goes over that limit.

1. Check the database version in Site Health → Info → Database.
2. Ask your host to move you to a current MySQL or MariaDB version.
3. If you can’t upgrade, report the error to the plugin developer.

phpMyAdmin import fails: file too large or times out

Quick fix: Import with WP-CLI or the mysql command over SSH instead of phpMyAdmin. They have no browser upload limit or timeout.

Why it happens: phpMyAdmin is limited by PHP upload size and execution time. Databases over a few hundred megabytes often fail halfway.

1. Upload the .sql file to the server over SFTP.
2. Import with one of the commands below.
3. No SSH? Compress the file to .sql.gz, or ask your host to import it for you.

wp db import backup.sql
# or
mysql -u DB_USER -p DB_NAME < backup.sql

MySQL server has gone away

Quick fix: Ask your host to raise max_allowed_packet and wait_timeout, and split very large imports into smaller files.

Why it happens: The database closed the connection because a query was too big or a script waited too long between queries.

1. Note when it happens: during imports usually means packet size, during long scripts usually means timeout.
2. Import with WP-CLI, which handles large files better.
3. Ask the host for higher limits, or move heavy work to a VPS.

07Domain, DNS, SSL and email errors

AutoSSL failed: domain control validation (DCV) error

Quick fix: Make sure the domain’s DNS points to this server and that /.well-known/ isn’t redirected or blocked. If Cloudflare proxies the site, use a Cloudflare origin certificate or Full (strict) mode with a valid origin cert.

Why it happens: AutoSSL proves you own the domain by loading a test file from your server. If DNS points elsewhere, a redirect or firewall rule blocks the test file, or a CDN answers first, validation fails.

1. In cPanel → SSL/TLS Status, read the exact failure for each domain.
2. Remove or fix domains that no longer point to this server (old subdomains often fail).
3. Exclude /.well-known/ from redirects and security rules.
4. Run AutoSSL again.
5. For the browser warning side, see your connection is not private.

DNS changes not showing (site still loads the old host)

Quick fix: Check the record with a public DNS checker. If it’s correct there, wait for the old TTL to expire and clear your local DNS cache.

Why it happens: Resolvers keep old answers until the record’s TTL runs out. Changes at the wrong place, such as editing DNS at the registrar while nameservers point to Cloudflare, don’t take effect at all.

1. Find which nameservers the domain uses with a WHOIS or DNS lookup.
2. Edit DNS in that provider only.
3. Before a planned move, lower the TTL to 300 seconds a day ahead.
4. Flush your computer’s DNS cache and test in a private window.

Email stopped working after moving the website

Quick fix: Copy the old MX, SPF (TXT), DKIM and autodiscover records to the new DNS. Moving nameservers replaces every record, not just the website ones.

Why it happens: When you switch nameservers to a new host or CDN, the new zone starts empty or with defaults. Mail records that pointed to Google Workspace, Microsoft 365 or the old host disappear.

1. Export or screenshot the old DNS zone before switching.
2. Add the MX and TXT records to the new zone exactly as before.
3. Check email delivery with an MX lookup tool.
4. If mail was hosted on the old cPanel account, recreate the mailboxes and migrate messages before cancelling the old plan.

Addon domain or subdomain shows the wrong website

Quick fix: Check the document root for that domain in cPanel → Domains and point it to the right folder.

Why it happens: Each domain on a cPanel account has its own folder. A domain added with the default root, or pointing to public_html, shows the main site instead.

1. Open cPanel → Domains and find the domain.
2. Change its document root to the folder holding that site.
3. Check the site’s own Site Address in its database matches the domain.

08Hosting transfer and migration errors

Moving a Divi site? Divi adds its own traps, like static CSS files and serialized Theme Options. See moving a Divi site to a new host or domain: 10 errors and fixes.

Failed opening required '/home/olduser/…/wordfence-waf.php' after a migration

Quick fix: Edit .user.ini (and .htaccess) in the site root and fix or remove the auto_prepend_file line that points to the old server path. Then set up the Wordfence firewall again.

Why it happens: The Wordfence firewall loads itself before WordPress through auto_prepend_file, using an absolute path. On a new server, that old path doesn’t exist and every page fails.

1. Open .user.ini in the site root and find auto_prepend_file.
2. Remove the line, or update it to the new full path.
3. Check .htaccess for a matching php_value auto_prepend_file block and remove it.
4. Wait 5 minutes for PHP to reread .user.ini, then reload.
5. In Wordfence → Firewall, run “Optimize the Wordfence Firewall” again.

; .user.ini (remove or fix this line)
auto_prepend_file = '/home/olduser/public_html/wordfence-waf.php'

Site broken on the new host: old file paths in config and database

Quick fix: Search for the old home path (for example /home/olduser/) in wp-config.php, .user.ini, .htaccess and the database, and replace it with the new one.

Why it happens: Cache plugins, security plugins, backup plugins and page builders store absolute server paths. They break when the account username or folder changes.

1. Find the new path: it’s shown in cPanel’s sidebar or by wp eval "echo ABSPATH;".
2. Search config files for the old path and update them.
3. Run a dry run search and replace for the old path in the database, then the real one.
4. Clear and reconfigure cache and security plugins so they rebuild their own config files.

wp search-replace '/home/olduser/public_html' '/home/newuser/public_html' --dry-run

Migration plugin import stuck at a percentage or fails

Quick fix: Check the server error log at the moment it stops. It’s nearly always an upload limit, a timeout or disk space. For large sites, move files and the database manually or with WP-CLI.

Why it happens: Migration plugins run inside PHP requests, so they hit the same upload, memory, time and disk limits as everything else.

1. Check free disk space on the new host: you need room for the archive and the extracted site.
2. Raise upload_max_filesize, post_max_size and max_execution_time.
3. Exclude old backups, caches and logs from the export to shrink it.
4. For big sites, copy files over SFTP or with rsync, import the database with WP-CLI, then run search-replace.

cPanel cron job doesn’t run, or floods your inbox with emails

Quick fix: Use the full path to PHP or WP-CLI in the command, and end it with >/dev/null 2>&1 to stop the emails.

Why it happens: Cron runs with a minimal environment, so php or wp may not be found. Every line of output is emailed to the cron address.

1. Find the PHP path in your host’s docs (commonly /usr/local/bin/php on cPanel).
2. Use the full path in the cron command, as below.
3. Clear the Cron Email field or add the output redirect.
4. For WordPress scheduled posts, see missed schedule.

*/5 * * * * /usr/local/bin/php /home/USER/public_html/wp-cron.php >/dev/null 2>&1

09A server checklist that prevents most of these errors

• Know your stack: PHP version, database version, web server and limits, written down for every site.
• One place for PHP settings: use the host’s PHP tool or .user.ini, not a mix.
• Watch disk and inodes: keep backups off the server and cap local copies.
• Lower DNS TTL before moves and copy every record, including mail.
• Check paths after migrations: .user.ini, .htaccess, cache and security plugin configs.
• Test PHP upgrades on staging with the same extensions as production.

We run these checks for agencies on every site we look after. See our white label care plans, or our migration service if you’re moving hosts.

10FAQ