WordPress Not Running PHP After Reinstalling Apache: Fix Raw Code, Downloads, and 404s

If WordPress displays raw <?php code or your browser downloads index.php, Apache is serving the file as plain text instead of passing it to PHP. Reinstalling Apache can remove the PHP module, disable a virtual-host configuration, or leave Apache pointed at a different PHP-FPM socket. Restore one working PHP handler, verify it with a temporary test file in the active DocumentRoot, and only then troubleshoot WordPress itself.

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

A blank page, a WordPress critical-error screen, and 404 errors on post URLs are different failures. The repair order below keeps those problems separate so you do not change WordPress files while PHP execution is still broken.

What the symptom tells you

WordPress is PHP software. Apache must recognize a .php request, hand it to a PHP interpreter, and return the interpreter’s HTML output. When the browser receives the original source, that dispatch step never happened. WordPress’s developer documentation states that seeing the <?php ?> tags in the browser means PHP is not working properly.

#	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

As an Amazon Associate I earn from qualifying purchases.

Do not use the command-line result of php -v as proof that Apache can run PHP. The CLI binary and the Apache SAPI can use different versions, configuration files, extensions, and handlers.

Why reinstalling Apache can stop PHP

On Ubuntu, the libapache2-mod-php package supplies the Apache module path for the traditional mod_php setup. Removing and reinstalling Apache can leave that package absent, disable its module, or replace enabled-site configuration. A server using PHP-FPM can fail for a different reason: Apache’s FastCGI proxy module may be disabled, the site’s FPM configuration may not be enabled, or the configured Unix socket may belong to a PHP version that is no longer installed.

#1 Best Overall

Sale

WordPress Multisite Administration

$34.38

Buy on Amazon

Apache can use only one coherent dispatch design for a site’s PHP requests. Mixing an old mod_php module with an unrelated FPM socket makes diagnosis difficult and can send different virtual hosts to different interpreters. Decide which model you want, remove stale references, and verify the resulting SAPI in a browser.

Step 1: Confirm Apache is serving the intended site

Before changing packages, establish which virtual host answered the request and which directory Apache serves. A reinstall may have restored the default site while your WordPress files remain in a custom site, or DNS may still point to another machine.

1. List the enabled Apache sites and identify the virtual host matching the hostname you enter in the browser. On Ubuntu, the enabled-site files are normally under /etc/apache2/sites-enabled/.
2. Open that virtual-host definition and record its DocumentRoot. This is the directory in which the PHP test file must be created; placing the file in another site’s directory proves nothing.
3. Check that the directory and WordPress files are readable by the account running Apache. A permissions failure normally produces a 403, but correcting ownership or modes is still necessary before testing application behavior.
4. Confirm that the request reaches the expected machine by checking the server identity, DNS record, load balancer, or reverse proxy in front of Apache. A successful change on one server cannot affect a different server answering the hostname.

Use Apache’s virtual-host listing when available to see the selected host and its configuration. The important result is not the command’s formatting; it is a definite mapping from your browser’s hostname to one enabled virtual host and one DocumentRoot.

Step 2: Test PHP independently with phpinfo

Create a temporary file named phpinfo.php in the active DocumentRoot with exactly this content:

<?php phpinfo(); ?>

1. Save the file in the directory identified in the virtual host, not merely in the directory where you think WordPress is installed.
2. Request it over the same hostname and protocol used for WordPress, for example, the site’s HTTPS address if HTTPS is enabled.
3. Read the result. A PHP information page proves that Apache reached a PHP interpreter. Check the PHP version, the Server API or SAPI value, the loaded configuration file, and important extensions.
4. Compare the displayed version and SAPI with the handler you intended to configure. A value such as an Apache module indicates mod_php; an FPM/FastCGI value indicates PHP-FPM.
5. Delete phpinfo.php immediately after testing: phpinfo() exposes paths, environment variables, module versions, and server configuration that should not be public.

If the file is downloaded or its PHP source is shown, WordPress is not yet relevant. Return to Apache’s handler configuration. If the file returns 404, you are testing the wrong virtual host or directory. If it returns 403, fix file and directory permissions before interpreting the result.

Rank #2

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

$9.90

Buy on Amazon

Step 3: Restore one PHP execution model

There are two supported patterns in the supplied documentation. Compare them before selecting one.

The PHP manual recommends PHP-FPM with Apache’s mod_proxy_fcgi for modern deployments. mod_php can still be appropriate where package availability and MPM compatibility are already settled, but it should be a deliberate choice rather than a leftover from an earlier installation.

Option A: Ubuntu mod_php

1. Install the PHP runtime and the Apache module package that matches the PHP version you intend to run. A typical Ubuntu package installation includes php and libapache2-mod-php; keep all PHP packages on the same version family.
2. Check the enabled Apache modules. If the matching PHP module is installed but disabled, enable it with Ubuntu’s a2enmod tool, using the module name shown by the package for your version.
3. Disable obsolete PHP module versions so Apache does not have competing handlers enabled.
4. Restart Apache with sudo systemctl restart apache2. A restart failure is a configuration error, not a WordPress error; read Apache’s service status and error log before retrying.
5. Reload phpinfo.php and confirm that the SAPI is the Apache module and that the version is the one you installed.

Installing libapache2-mod-php normally configures Apache to run PHP scripts, but a custom virtual host, an overridden FilesMatch rule, or an old handler can still intercept requests. The browser test is the authority.

Option B: PHP-FPM through Apache

1. Install the PHP-FPM package for the PHP version you intend to use and start or enable its system service. The service name and socket path include the version, so do not copy a path for one version while running another.
2. Enable Apache’s FastCGI proxy support with sudo a2enmod proxy_fcgi. Enable the FPM configuration supplied for the same PHP version, for example, an Ubuntu configuration such as sudo a2enconf php8.3-fpm when that exact version is installed.
3. Inspect the virtual host or generated FPM configuration and confirm that its Unix socket or TCP endpoint matches the running service. A stale socket path produces gateway or proxy errors even though PHP-FPM itself is running.
4. Restart Apache and verify the PHP-FPM service status. If the service is stopped, start it and inspect its own log for permission, pool, or configuration errors.
5. Reload phpinfo.php. Confirm an FPM/FastCGI SAPI, the intended PHP version, and the expected loaded configuration file.

Do not leave a previous mod_php rule and a different FPM version competing for .php requests. Remove or disable the stale path, then perform the browser test again from the same virtual host.

Step 4: Interpret common handler failures

The source is still visible after installing PHP

Installing the command-line PHP package alone does not make Apache execute scripts. Check that libapache2-mod-php is installed and enabled for a mod_php design, or that proxy_fcgi, the FPM site configuration, and the matching socket are active for an FPM design. Verify the selected virtual host and retest the temporary file.

Rank #3

Sale

WordPress 24-Hour Trainer

$3.95

Buy on Amazon

The browser downloads every PHP file

A download generally means Apache has a content handler or MIME mapping but no executable PHP handler. Inspect virtual-host directives that set a forced download type, remove stale handler lines, and ensure the selected PHP module or FPM proxy is enabled. Test a new PHP file rather than relying on a cached response.

Apache will not restart

Stop changing WordPress until the service starts cleanly. Read the Apache error output and configuration-test result, looking for duplicate module loads, a missing include, an invalid FPM socket path, or a directive provided by a disabled module. Correct one configuration error at a time, then rerun the configuration test and restart.

PHP-FPM is running but requests fail

Confirm that Apache can access the Unix socket and that the socket path in the site configuration exactly matches the path created by the running FPM pool. For a TCP endpoint, verify the address and port and check local firewall or listener settings. FPM service health and Apache proxy health are separate checks.

Step 5: Validate WordPress’s current prerequisites

Once phpinfo.php executes, check the application stack. The current WordPress requirements page recommends PHP 8.3 or greater, MariaDB 10.11 or greater or MySQL 8.0 or greater, HTTPS, and Apache or Nginx with mod_rewrite. Older versions may operate in legacy environments, but they are end-of-life and increase security and compatibility risk.

The WordPress installation FAQ notes that PHP interprets WordPress pages and that phpinfo() can reveal Apache, PHP, and mod_rewrite information. Use that information to compare the web request with the environment in which you run administrative commands.

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 6: Troubleshoot WordPress only after PHP executes

Blank page or critical-error message

If the PHP test works but WordPress produces a blank page or a critical-error screen, PHP dispatch is no longer the primary fault. Read the recovery email WordPress sends to the site administrator and inspect wp-content/debug.log if debugging is enabled. Common causes include a plugin or theme conflict, code incompatible with the selected PHP version, an exhausted memory limit, or corrupted WordPress files.

Change one application variable at a time. Disable the most recently changed plugin or theme, retest, and then review the PHP and Apache error logs for the exact file and line. Do not delete the entire wp-content directory as a first response: that can destroy uploads and configuration.

Database connection errors

A working PHP page does not prove that WordPress can reach its database. Check the values in wp-config.php, confirm that the database service is running, and test connectivity from the web server using the configured host, user, and database name. Correct credentials or network access before changing PHP handlers again.

Permission and ownership errors

Apache needs read access to WordPress core files and write access only where WordPress genuinely requires it, such as uploads or update directories. A permission problem can appear as a 403, failed update, missing generated file, or an application error. Fix the specific directory and ownership mismatch rather than making the entire site world-writable.

Pretty-permalink 404s are a separate Apache problem

If the home page and phpinfo.php work but URLs such as /sample-post/ return 404, PHP execution is already confirmed. WordPress identifies Apache’s mod_rewrite and the site’s rewrite rules as the relevant remedy.

1. Enable Apache’s rewrite module with sudo a2enmod rewrite, then restart Apache.
2. Check that the virtual host permits overrides if WordPress relies on its .htaccess file. The relevant directory must allow the rewrite directives used by WordPress.
3. Confirm that the WordPress .htaccess rules are present in the correct document root and have not been replaced by rules for another site.
4. In the WordPress administration area, open Settings, Permalinks and save the existing structure once to regenerate rewrite rules.
5. Retest a post URL and the home page. Do not disable PHP or reinstall WordPress for a rewrite-only 404.

Logs that identify the failing layer

Use logs after each change and correlate the timestamp with one request. Apache’s error log can show module-load failures, permission denials, proxy errors, and rewrite problems. PHP-FPM’s service or pool log can show startup failures, worker exhaustion, and socket permissions. WordPress’s wp-content/debug.log records application-level errors when debugging is configured.

• Raw source or download with no Apache error: inspect handler selection and the active virtual host.
• 502 or proxy error: inspect PHP-FPM service state, socket path, endpoint permissions, and version match.
• 403: inspect directory traversal and file permissions.
• 500 after PHP starts: inspect Apache, PHP, and WordPress logs for the first reported error.
• 404 only for friendly URLs: inspect mod_rewrite, .htaccess, and virtual-host override settings.

Final recovery checklist

1. Classify the symptom: raw source/download, blank or critical error, or rewrite-only 404.
2. Identify the enabled virtual host and its exact DocumentRoot.
3. Create phpinfo.php there, request it through the real hostname, and confirm PHP version and SAPI.
4. Choose either matching mod_php or PHP-FPM with mod_proxy_fcgi; do not run competing handlers.
5. Restart Apache and, for FPM, verify the service and socket or TCP endpoint.
6. Delete phpinfo.php as soon as the test is complete.
7. Check PHP extensions, WordPress file access, database credentials, and the recommended PHP and database versions.
8. Only after PHP works, investigate plugins, themes, memory, corrupted files, and wp-content/debug.log.
9. For permalink-only 404s, enable mod_rewrite and regenerate WordPress rewrite rules.

This sequence restores the missing Apache-to-PHP dispatch path first, then narrows any remaining fault to WordPress, the database, permissions, or URL rewriting instead of treating every symptom as an Apache reinstall problem.

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

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.