WordPress Not Running PHP After Reinstalling Apache: A Complete Fix

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.

If WordPress displays raw <?php ... ?> code or makes index.php download, Apache is delivering the file as static content instead of sending it to PHP. Reinstalling Apache often removes the PHP module or the PHP-FPM connection from the active virtual host. Restore one working PHP handler, verify it with a temporary phpinfo.php file, remove that file, and only then troubleshoot WordPress itself.

Identify exactly which failure you have

The visible symptom determines where to start. Do not change WordPress files until you know whether Apache is executing PHP at all.

#	Preview	Product	Price
1		WordPress Multisite Administration	$34.38	Buy on Amazon
2		Mon Site WordPress – Volume 2 – Administration & Utilisation (French Edition)	$9.90	Buy on Amazon
3		WordPress 24-Hour Trainer	$3.95	Buy on Amazon
4		Teacher Record Book	$4.89	Buy on Amazon

WordPress describes the raw-source case plainly: when <?php ?> reaches the browser, PHP is not working properly. A command-line result from php -v does not prove that Apache can execute PHP; the web server may use a different version, SAPI, socket, virtual host, or DocumentRoot.

Why reinstalling Apache causes this

Apache can serve HTML, images, CSS, JavaScript, and PHP files as ordinary files. PHP execution requires an additional dispatch layer. On Ubuntu, that layer is commonly either the libapache2-mod-php module or a FastCGI connection from Apache’s mod_proxy_fcgi module to PHP-FPM.

#1 Best Overall

Sale

WordPress Multisite Administration

$34.38

Buy on Amazon

An Apache reinstall can disable or remove the package that supplied the old handler, replace enabled-module links, restore a default virtual host, or leave the site pointing at a different PHP-FPM socket. The WordPress files may be untouched while every .php request changes behavior.

Use one consistent model for each site. The PHP documentation recommends PHP-FPM with Apache’s mod_proxy_fcgi for modern deployments. The older mod_php approach is simpler when its package is available, but it has Apache MPM compatibility requirements. Running an old mod_php module and a different PHP-FPM version against the same .php requests creates ambiguous troubleshooting and can send requests to the wrong runtime.

Step 1: Confirm the active site and DocumentRoot

Before installing anything, establish that the request is reaching the machine and virtual host you are editing. Apache may have several enabled sites, and editing a disabled configuration has no effect.

1. Identify the enabled virtual host and its DocumentRoot. On Ubuntu, apachectl -S shows the virtual-host map and which configuration answers a hostname.
2. Open the site configuration and confirm that its DocumentRoot is the directory containing WordPress’s index.php.
3. Check that Apache can traverse the parent directories and read the WordPress files. A permissions problem normally produces a 403, but it is still worth checking while you verify the path.
4. Request a plain marker file from that directory, then request the PHP test described below. If the marker is not the file you created, DNS, a reverse proxy, a container, or a different server is answering the request.

Checking the active path prevents a common false fix: installing PHP successfully on one host while the browser is still connected to another host or virtual host.

Step 2: Test PHP independently with phpinfo

Create a temporary file named phpinfo.php directly inside the active DocumentRoot. Its entire contents should be:

Rank #2

Mon Site WordPress – Volume 2 – Administration & Utilisation (French Edition)

$9.90

Buy on Amazon

<?php phpinfo(); ?>

Open https://your-site.example/phpinfo.php (or the equivalent HTTP URL while you are testing). Interpret the result as follows:

• If a formatted PHP information page appears, Apache is executing PHP. Record the PHP version and the Server API (SAPI), such as an Apache module or FPM/FastCGI.
• If the source code appears or the file downloads, the handler is still missing, disabled, mismatched, or attached to another virtual host.
• If you receive 404, verify the URL and DocumentRoot; the file must be in the directory used by the answering virtual host.
• If you receive 403, correct file and directory read/execute permissions before diagnosing PHP.

The PHP version and SAPI shown here are the ones WordPress receives over HTTP. They are more relevant than the output of a shell command. Delete phpinfo.php immediately after testing: the page exposes PHP, Apache, loaded modules, paths, environment details, and configuration values that should not remain publicly available.

Step 3: Restore one PHP execution path

Choose either the Ubuntu mod_php path or PHP-FPM. The package names below are examples for Ubuntu; use the matching package and service names for the PHP branch installed on your system.

Option A: Ubuntu mod_php

This option loads PHP into Apache. It is appropriate when the available PHP module supports the Apache MPM in use and you want Apache to manage PHP directly.

1. Install the PHP runtime and Apache integration package:

   sudo apt update
   sudo apt install php libapache2-mod-php

2. Check the enabled modules. If the PHP module for the installed branch is not enabled, enable that matching module with a2enmod. For example, a system using PHP 8.3 may use sudo a2enmod php8.3; do not enable a branch that is not installed.
3. Restart Apache:

   sudo systemctl restart apache2

4. Reload phpinfo.php and confirm that the SAPI is an Apache module and that the version is the branch you intended.

Installing libapache2-mod-php is what supplies Apache’s PHP execution configuration; installing only the command-line interpreter is not enough. If Apache is configured with an MPM that is incompatible with the module, use PHP-FPM instead of forcing a conflicting combination.

Rank #3

Sale

WordPress 24-Hour Trainer

$3.95

Buy on Amazon

Option B: PHP-FPM with mod_proxy_fcgi

PHP-FPM runs PHP in a separate managed service. Apache forwards PHP requests through mod_proxy_fcgi to the FPM socket or TCP endpoint configured for the site. This separation is the preferred model in the PHP manual for modern Apache deployments.

1. Install the FPM package for the PHP branch you intend to run, for example php8.3-fpm on an Ubuntu system using PHP 8.3.
2. Start the matching service and configure it to start automatically, such as

   sudo systemctl enable --now php8.3-fpm

   Use the actual installed branch in the service name.

3. Enable Apache’s FastCGI proxy support:

   sudo a2enmod proxy_fcgi

4. Enable the Apache configuration supplied for the same FPM branch, commonly with a command such as sudo a2enconf php8.3-fpm. If your distribution uses a custom virtual-host rule instead, configure that site to pass .php requests to the running FPM socket or TCP endpoint.
5. Verify that the socket or endpoint in Apache exactly matches the running FPM service. A PHP 8.2 socket configured while only PHP 8.3-FPM is running will leave PHP requests broken.
6. Restart Apache, then reload phpinfo.php:

   sudo systemctl restart apache2

The PHP information page should now report an FPM/FastCGI SAPI. Disable or remove any obsolete mod_php handler for the same site so that only the selected path handles .php requests. After validation, remove the test file.

mod_php or PHP-FPM: which should you keep?

Step 4: Check WordPress’s current server requirements

Once the standalone test executes, validate the environment WordPress actually needs. The current WordPress requirements page recommends:

Older PHP and database releases can still operate in legacy environments, but end-of-life versions no longer receive normal security maintenance. If an old WordPress installation depends on one, plan an upgrade rather than treating continued operation as a secure baseline.

• Review the extensions listed by WordPress and by every installed plugin. A working interpreter with a missing database, image, multibyte-string, XML, or other required extension can fail after PHP dispatch has been repaired.
• Confirm that Apache can read the WordPress directory and write only where WordPress needs to write, especially wp-content.
• Open wp-config.php and verify the database host, database name, username, and password. A PHP handler repair does not fix invalid database credentials.
• Check that the PHP branch used by Apache matches the compatibility range of the WordPress core, theme, and plugins.

The WordPress installation FAQ notes that PHP is required to interpret WordPress pages and that phpinfo() can expose Apache, PHP, and rewrite information. Use that information to compare the web request with the environment you expected, then remove the diagnostic file.

Rank #4

Teacher Record Book

• Keep track of everything from attendance to test scores
• Spiral bound
• Measures 8-1/2" x 11"

$4.89

Buy on Amazon

Step 5: If PHP works but WordPress is blank or reports a critical error

A formatted phpinfo() page proves the dispatch layer, not the health of WordPress. For a blank page or critical error, inspect the error notification sent by WordPress and the file wp-content/debug.log. The useful clues are usually the first fatal error and the plugin, theme, PHP function, or file named in its stack trace.

• A plugin or theme may call code removed or changed in the PHP branch now used by Apache.
• A plugin may exhaust the PHP memory limit even though simple PHP pages execute.
• WordPress core or plugin files may be incomplete or corrupted after a failed deployment.
• The database may be unreachable because wp-config.php points to the wrong host or credentials.

Resolve the named application error before changing Apache again. If the log is empty, verify that WordPress can write to wp-content and that PHP’s error logging is enabled for the site; avoid leaving verbose diagnostics publicly visible after recovery.

Step 6: Fix pretty-permalink 404s separately

When the front page and phpinfo.php work but URLs such as /sample-post/ return 404, PHP dispatch is no longer the primary problem. Apache needs rewrite support and the WordPress rewrite rules must reach the request.

1. Enable Apache’s rewrite module:

   sudo a2enmod rewrite

2. Ensure the virtual host permits the site’s .htaccess rules where WordPress uses them, or place equivalent rewrite rules in the virtual-host configuration.
3. Confirm that the WordPress directory contains the expected .htaccess rules and that Apache can read the file.
4. Reload Apache and retest a post URL. If the home page still works while only permalinks fail, continue investigating rewrite rules rather than reinstalling PHP.

Keep this diagnosis separate from raw PHP output: rewrite processing chooses where a URL goes, while the PHP handler determines whether a selected PHP file executes.

Targeted troubleshooting by symptom

Source code remains visible after enabling a module

• Recheck apachectl -S; you may have enabled the module for a different site or edited a disabled configuration.
• Confirm the requested hostname resolves to the server whose Apache you changed.
• Inspect the virtual host’s DocumentRoot and place phpinfo.php there, not in a similarly named directory.
• Look for a stale FPM socket, an FPM configuration for another PHP branch, or a competing mod_php rule.
• Restart Apache after module or virtual-host changes and test again from a fresh browser request.

The test file works, but WordPress downloads or shows source

This usually means the test and WordPress are not being served by the same virtual host, path, or URL. Compare the URL host, DocumentRoot, and response headers for both requests. A reverse proxy or separate HTTPS virtual host can route them differently.

PHP-FPM returns a gateway or server error

Check that the FPM service is running, that Apache’s configured socket or TCP endpoint exists, and that permissions allow Apache to connect to it. Make the PHP branch in the service name, socket path, and Apache configuration identical.

WordPress works at the root but not for posts

Follow the rewrite procedure above. Do not replace WordPress files or change database credentials for a rewrite-only 404.

Quick Recap

SaleBestseller No. 1

WordPress Multisite Administration

$34.38

Bestseller No. 2

Mon Site WordPress – Volume 2 – Administration & Utilisation (French Edition)

$9.90

SaleBestseller No. 3

WordPress 24-Hour Trainer

$3.95

Bestseller No. 4

Teacher Record Book

Keep track of everything from attendance to test scores; Spiral bound; Measures 8-1/2" x 11"

$4.89

Final verification checklist

• The active virtual host points to the directory containing the intended WordPress installation.
• A temporary phpinfo.php page reports the expected PHP version and SAPI.
• Exactly one handler model serves the site’s PHP requests.
• The matching Apache module, FPM service, socket, and configuration are enabled and restarted.
• phpinfo.php has been deleted.
• Required PHP extensions are loaded, Apache can read the files, and wp-config.php has valid database settings.
• The server meets the current WordPress recommendations: PHP 8.3+, MariaDB 10.11+ or MySQL 8.0+, HTTPS, and Apache rewrite support.
• WordPress error email and wp-content/debug.log have been checked if the application still fails.
• Pretty-permalink testing is performed only after the PHP home page and standalone PHP test succeed.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.