WordPress Admin Page: Plain Text Apache Webserver Not Parsing PHP

When the WordPress admin dashboard displays raw PHP code instead of rendering the interface, your Apache web server is failing to process .php files. This issue typically stems from missing or misconfigured mod_php modules, incorrect MIME type associations, or permission errors preventing execution. You must verify that the PHP handler is correctly registered in your Apache configuration and that the file permissions allow the web server user to read and execute the scripts.

Verify Apache PHP Module Configuration

The most common cause for this behavior is that Apache does not have the necessary module loaded to interpret PHP code. If the module is missing, Apache treats .php files as plain text and sends them directly to the browser. You need to ensure that the correct module is enabled based on your system's architecture and PHP version. For systems using Apache 2.4 with PHP 7 or 8, you should check if the libapache2-mod-php package is installed. On Debian-based systems, you can enable the module using the following command:

a2enmod php8.1
systemctl restart apache2

If you are using an older setup or a different distribution, the module name might vary. For example, php5_module or php7.4_module. Always replace the version number with the one installed on your server. After enabling the module, restart Apache to apply the changes. If the problem persists, check if the module is actually loaded by running:

apache2ctl -M | grep php

This command lists all loaded modules. If you do not see any PHP-related modules, you must install and enable them. Ensure that you are not mixing multiple PHP versions in your configuration, as this can lead to conflicts where Apache falls back to serving static content.

Check .htaccess and Directory Configuration

Sometimes the issue lies within the virtual host configuration or the .htaccess file in your WordPress directory. If the AddType directive is missing or commented out, Apache may not know how to handle PHP files. Open your virtual host configuration file, usually located in /etc/apache2/sites-available/, and look for the <Directory> block corresponding to your WordPress installation. You should add or uncomment the following lines to explicitly tell Apache to treat PHP files as applications:

<FilesMatch \.php$>
    SetHandler application/x-httpd-php
</FilesMatch>

Alternatively, if you are using PHP-FPM, which is recommended for performance, you need to configure the proxy pass. In this case, the connection between Apache and the PHP processor is handled via a socket or TCP port. Ensure that the ProxyPassMatch directive points to the correct PHP-FPM socket:

<FilesMatch \.php$>
    SetHandler "proxy:unix:/run/php/php8.1-fpm.sock|fcgi://localhost"
</FilesMatch>

After making these changes, test your configuration for syntax errors using apachectl configtest before restarting the service. A syntax error here can prevent Apache from starting entirely, leading to a 503 Service Unavailable error rather than plain text output.

Inspect File Permissions and Ownership

Incorrect file permissions can also prevent PHP execution. If the web server user (usually www-data on Ubuntu/Debian or apache on CentOS/RHEL) cannot read the PHP files, it may fail silently or serve them as text depending on the security settings. Check the ownership of your WordPress files:

chown -R www-data:www-data /var/www/html/wordpress
chmod -R 755 /var/www/html/wordpress

Ensure that directories are set to 755 and files to 644. Avoid using 777 permissions as they pose a significant security risk. Additionally, check if SELinux is enabled on your system. If it is, it might be blocking Apache from executing PHP scripts. You can check the status with getenforce. If it returns Enforcing, you may need to adjust the context labels:

semanage fcontext -a -t httpd_sys_script_exec_t "/var/www/html/wordpress(/.*)?"
restorecon -Rv /var/www/html/wordpress

This ensures that SELinux allows Apache to execute the PHP scripts within your document root.

Debugging HTTP vs HTTPS Issues

The problem may manifest differently depending on whether you are accessing the site via HTTP or HTTPS. If it works on HTTP but fails on HTTPS, the issue might be related to SSL/TLS configuration interfering with the PHP handler. Some configurations require explicit handling of PHP in the SSL virtual host block. If you are using Let's Encrypt or similar certificates, ensure that the PHP module is loaded in both the non-SSL and SSL virtual host configurations. Sometimes, administrators copy the non-SSL config to create the SSL config but forget to include the PHP handler directives. Compare the two configurations side-by-side to identify missing sections. Additionally, check if there are any redirects in place that might be causing a loop or breaking the script execution. Use browser developer tools to inspect the network tab. Look at the response headers for the request to wp-admin/. If the Content-Type header says text/plain or application/octet-stream instead of text/html, it confirms that PHP is not being processed. For deeper insights into logging errors that might reveal why PHP is failing, you can refer to Troubleshooting PHP-FPM Apache Logging. This resource details how to locate specific error messages that indicate why the PHP interpreter is rejecting requests.

Frequently Asked Questions

Why does my WordPress site show source code only on some pages?

This usually happens when specific plugins or themes contain malformed PHP code that causes a fatal error, forcing Apache to display the source for debugging. Check your error_log file in the WordPress directory to identify the offending file. Fixing the syntax error in that specific file will restore normal rendering.

Can I use PHP-FPM instead of mod_php for better performance?

Yes, PHP-FPM is generally faster and more stable than mod_php because it handles processes independently of Apache threads. To switch, disable mod_php and enable the proxy_fcgi module, then configure the virtual host to point to the PHP-FPM socket as described in the configuration section above.

What should I do if Apache returns a 403 Forbidden error after enabling PHP?

A 403 error indicates that Apache understands the request but refuses to serve the content due to permission restrictions. Verify that the www-data user has read access to the PHP files and that the IndexOptions or Options directive in your virtual host allows execution. Also, ensure that AllowOverride is set to All if you are relying on .htaccess rules.

How do I check if PHP is actually installed on my server?

Run the command php -v in your terminal. If it returns a version number, PHP is installed. If it says command not found, you need to install the PHP package manager for your OS. Note that having PHP CLI installed does not guarantee that the Apache module is present; you must install libapache2-mod-php separately.

Does disabling caching plugins help resolve plain text issues?

No, caching plugins like WP Super Cache or W3 Total Cache do not affect how Apache parses PHP. They only store generated HTML files. If you see raw PHP code, the issue is strictly at the server configuration level. Disabling caching might help you debug if the issue is related to stale cached files, but it won't fix the parsing engine itself.