What Is PHP?

PHP is a server-side programming language. It runs on your hosting server and generates the HTML that gets sent to your visitors’ browsers. When someone loads your WordPress site, PHP is what reads the database, processes your theme and plugins, and builds the page before serving it.

It powers roughly 77% of all websites with a known server-side language, including WordPress, Drupal, Magento, and Laravel applications. If you run a WordPress site, you’re running PHP whether you think about it or not.

How PHP Works

PHP runs on the server, not in the browser. This is the key distinction between PHP and languages like JavaScript.

When a visitor requests a page, here’s what happens. The request arrives at your server. If it’s a static HTML file, the server sends it directly. If it’s a PHP file, the server hands it to the PHP interpreter. PHP executes the code: queries the database, processes logic, generates output. The result is an HTML document. That HTML is sent to the browser. The browser never sees the PHP code, only the HTML it produced.

This is called server-side rendering. The page is built on the server before being sent. It’s how WordPress has always worked, and it’s why WordPress requires a server with PHP installed, unlike a simple static website.

PHP and WordPress

WordPress is written almost entirely in PHP. Every core WordPress file, every theme function, every plugin: it’s all PHP.

When you load a WordPress page, PHP does a substantial amount of work. It boots WordPress, loads configuration, establishes a database connection, queries the database for the requested content, runs the theme’s template files, processes shortcodes and blocks, applies filters and actions from active plugins, generates the full HTML output, and sends it to the browser.

On an uncached page load, this chain of PHP execution is what determines your TTFB. Faster PHP processing means faster response times. Slower PHP, or too many plugins adding to the execution chain, means slower pages.

This is also why caching matters so much for WordPress. Page caching stores the finished HTML output so PHP doesn’t have to run at all for subsequent visitors. Serving a cached page is many times faster than executing PHP to generate one from scratch.

PHP Versions

PHP is actively developed and releases new versions regularly. Each version brings performance improvements, new language features, and security fixes. Older versions eventually reach end of life, after which they receive no security patches.

The performance improvements between versions are significant. PHP 8.x is substantially faster than PHP 7.x, which was itself much faster than PHP 5.x. Moving from PHP 7.4 to PHP 8.2 on the same server and hardware can reduce execution time by 20% or more for WordPress. That’s a real-world improvement in response times with no other changes.

Current PHP versions and their status:

• PHP 8.3: Current stable release, active support
• PHP 8.2: Active support
• PHP 8.1: Security fixes only
• PHP 8.0: End of life, no patches
• PHP 7.4: End of life, no patches

Running an end-of-life PHP version means your server is not receiving security patches for newly discovered vulnerabilities. It’s a genuine security risk, not just a performance consideration.

PHP in Practice: What It Looks Like in WordPress

You don’t need to write PHP to run a WordPress site, but seeing what it looks like helps demystify what’s happening behind the scenes every time a page loads.

Example 1: Outputting dynamic content

This is the most basic thing PHP does in a WordPress theme. Instead of hardcoding text into an HTML file, PHP pulls the value from the database and outputs it:

<?php
// Output the site name from the WordPress database
echo get_bloginfo('name');

// Output the current post title
echo get_the_title();

// Output the current year dynamically
echo date('Y');
?>

The browser never sees <?php echo get_the_title(); ?>. It receives whatever that function returns for example, “What Is PHP?” as plain text in the HTML.

Example 2: A conditional

PHP logic decides what gets shown. This is how themes show different content for logged-in users, or display a featured image only when one exists:

<?php
// Only show the featured image if the post has one
if ( has_post_thumbnail() ) {
    echo '<div class="featured-image">';
    the_post_thumbnail('large');
    echo '</div>';
}

// Show different content depending on whether the user is logged in
if ( is_user_logged_in() ) {
    echo '<p>Welcome back! <a href="/account/">My Account</a></p>';
} else {
    echo '<p><a href="/login/">Log in</a> to access your account.</p>';
}
?>

Every WordPress theme is full of conditionals like this. They’re what makes a single theme file handle dozens of different page types correctly.

Example 3: A WordPress hook

Hooks are how plugins and themes modify WordPress behaviour without editing core files. An add_filter hook lets you intercept a value and change it. An add_action hook lets you run code at a specific point in WordPress’s execution.

<?php
// Filter: change the excerpt length from 55 words to 30
add_filter( 'excerpt_length', function( $length ) {
    return 30;
});

// Action: add a custom message below every post
add_action( 'the_content', function( $content ) {
    if ( is_single() ) {
        $content .= '<p class="post-footer">Enjoyed this? Check our hosting reviews.</p>';
    }
    return $content;
});
?>

When you install a plugin and it changes something on your site, it’s almost certainly doing it through hooks like these. The plugin adds a filter or action, WordPress fires it at the right moment, and the plugin’s code runs.

Example 4: A database query

WordPress provides $wpdb, a class for running database queries safely. This is how plugins and themes retrieve custom data:

<?php
global $wpdb;

// Get all published hosting providers from a custom post type
$providers = $wpdb->get_results(
    "SELECT ID, post_title
     FROM {$wpdb->posts}
     WHERE post_type = 'provider'
     AND post_status = 'publish'
     ORDER BY post_title ASC"
);

// Loop through the results and output them
foreach ( $providers as $provider ) {
    echo '<li>' . esc_html( $provider->post_title ) . '</li>';
}
?>

The esc_html() function sanitises the output before displaying it, preventing malicious content from being injected into the page. This kind of escaping is a core PHP security practice and something well-written WordPress plugins do throughout their code.

These four patterns output, conditionals, hooks, and database queries cover the vast majority of what PHP does in a WordPress context. Every theme template and plugin is built from variations of these building blocks.

PHP-FPM

PHP-FPM stands for FastCGI Process Manager. It’s the way PHP runs on modern server setups, particularly those using Nginx.

Older setups ran PHP as an Apache module (mod_php). This loaded PHP into every Apache process, even for requests that didn’t need PHP, wasting memory. PHP-FPM separates PHP from the web server entirely.

With PHP-FPM, the web server (Nginx or Apache) receives the request. If PHP processing is needed, it passes the request to PHP-FPM via FastCGI. PHP-FPM maintains a pool of worker processes ready to handle requests. The result comes back to the web server, which sends it to the browser.

The advantages are meaningful. PHP-FPM only runs PHP when PHP is actually needed. The pool of workers can be sized and tuned independently of the web server. Memory usage is lower. Performance under concurrent load is better.

On a VPS running Nginx with PHP-FPM, you have control over the pool configuration: how many worker processes to run, when to spawn more, how to handle timeouts. On managed WordPress hosting, this is handled for you.

PHP Configuration

PHP’s behaviour is controlled by a configuration file called php.ini. This file sets limits and options that affect how PHP runs on your server.

Key settings that matter for WordPress:

memory_limit sets how much memory a single PHP process can use. WordPress and plugins consume memory. If a plugin hits the limit, you get a fatal error and a white screen. Most WordPress sites need at least 256MB. Complex setups with WooCommerce and multiple plugins may need 512MB or more.

upload_max_filesize and post_max_size control how large a file you can upload through WordPress. If you’re uploading large images or videos and hitting errors, these are the settings to increase. They need to be set together: post_max_size should be larger than upload_max_filesize.

max_execution_time sets how long a PHP script can run before timing out. The default is 30 seconds. Long-running operations like database imports, search-replace operations, or bulk image processing may need a higher limit.

max_input_vars limits the number of input variables in a request. Complex WordPress pages with many settings fields (some page builders, for example) can hit this limit, causing settings to silently not save. Increasing this to 3000 or higher prevents the issue.

On shared hosting, you can often change these values in cPanel under PHP Settings, or by adding directives to your .htaccess file. On a VPS, you edit php.ini directly via SSH.

PHP Extensions

PHP’s functionality is extended through extensions: modules that add specific capabilities. WordPress requires certain extensions to function and recommends others for full functionality.

Required extensions: mysqli or mysqlnd for database connectivity, json for data encoding, mbstring for multibyte string handling, openssl for encrypted connections.

Recommended extensions: curl for making HTTP requests (used by many plugins for API calls), imagick or gd for image processing (used by WordPress’s image resize and crop functions), zip for plugin and theme installation, intl for internationalisation.

Most shared hosting plans have all the common extensions enabled. If a plugin requires an extension your host doesn’t provide, you’ll need to either request it from your host or switch to a plan that includes it. On a VPS, you install extensions via the package manager.

PHP Opcache

Every time PHP executes a script, it has to read the file, parse it, compile it to bytecode, and then run it. For a WordPress site with hundreds of PHP files, this happens on every page load.

Opcache changes this. It caches the compiled bytecode in memory. On subsequent requests, PHP skips the reading, parsing, and compiling steps and runs the cached bytecode directly. This reduces PHP execution time significantly on warm loads.

Opcache is included with PHP and just needs to be enabled and configured. On most shared hosting and managed WordPress hosts, it’s enabled by default. On a self-managed VPS, you may need to enable it in your PHP configuration.

The most important Opcache settings are opcache.memory_consumption (how much memory to allocate for the cache) and opcache.max_accelerated_files (how many files to cache). For WordPress with many plugins, the defaults can be too low. Increasing both settings prevents the cache from evicting files before they’re reused.

Choosing a PHP Version on Your Host

Most hosts let you choose your PHP version per site, either through cPanel, Plesk, or their own control panel.

You should always run the latest stable PHP version your WordPress plugins and theme support. Running the latest version gives you the best performance and security. Running an end-of-life version is a security risk.

Before upgrading PHP, check compatibility:

1. Check that your theme is compatible with the target PHP version. Reputable themes update quickly.
2. Check your active plugins. Most major plugins maintain compatibility, but older or abandoned plugins may not.
3. Enable a staging environment, upgrade PHP there, and check for errors before applying the upgrade to your live site.

Some hosts like Kinsta and SiteGround have PHP version switching built into their dashboards. On cPanel hosts, it’s usually under Software > Select PHP Version. On Plesk, it’s in the domain’s PHP settings.

PHP and Hosting Plans

The PHP version and configuration available to you depends heavily on your hosting plan.

Shared hosting gives you limited control over PHP configuration. Most hosts let you switch versions and change some settings through the control panel, but you can’t tune PHP-FPM pools or modify all configuration directives. Memory limits and upload sizes are often capped.

VPS hosting gives you full control. You install your preferred PHP version, configure PHP-FPM pools, set all limits, enable or disable extensions, and tune Opcache as needed. More flexibility but more responsibility.

Managed WordPress hosting handles PHP configuration for you. Kinsta, WP Engine, and Rocket.net run current PHP versions, tune Opcache, configure PHP-FPM appropriately for WordPress, and handle version upgrades. You choose the version in the dashboard and the host manages the configuration.

Frequently Asked Questions

What PHP version should I use for WordPress? Always use the latest PHP version that your theme and plugins support. At time of writing, PHP 8.2 and 8.3 are the current stable releases. WordPress officially supports PHP 8.2 and 8.3. Check your plugins and theme for compatibility before upgrading, then run on the latest version you can.

How do I check what PHP version my site is using? In cPanel, go to Software > Select PHP Version. In Plesk, check the domain’s PHP settings. Alternatively, create a file called phpinfo.php in your site root containing <?php phpinfo(); ?>, visit it in a browser, note the version, then delete the file immediately (it exposes sensitive server information).

Why does WordPress say my PHP version is outdated? WordPress displays a notice in the dashboard when your PHP version is end of life or below the recommended version. This is a genuine recommendation, not just a warning. Update PHP through your host’s control panel. If your host doesn’t offer a current PHP version, that’s a reason to consider switching hosts.

What’s the difference between PHP and JavaScript? PHP runs on the server and generates HTML. JavaScript runs in the browser and handles interactivity and dynamic updates. They serve different purposes and are often used together. WordPress uses PHP to generate the page and JavaScript for features like the block editor, interactive menus, and AJAX-based functionality.

Can PHP slow down my WordPress site? Yes. Slow PHP execution is one of the primary causes of high TTFB. Too many plugins, inefficient plugin code, low memory limits causing garbage collection, and outdated PHP versions all contribute. Running a current PHP version with Opcache enabled, limiting plugins to those you actually need, and using page caching to reduce how often PHP has to run at all are the main levers.

What is a PHP fatal error? A fatal error is an unrecoverable error in PHP execution. It stops the script from running and typically results in a white screen or an error message. Common causes include hitting the memory limit, a plugin or theme conflict, calling a function that doesn’t exist (often after a plugin update), or a syntax error in custom code. WordPress logs these to wp-content/debug.log if debug logging is enabled.