
🛠 2 Ways to get the WordPress root path
You include a file in functions.php, and WordPress can't find it. Sound familiar? The reason is almost always an incorrect path to the root folder.
A manually hardcoded /var/www/html/ breaks when you move to a different server. And a rigidly baked-in ../../wp-content/plugins/ stops working when the directory structure changes. Fortunately, WordPress provides two standard ways to get the absolute path to the site root, with no guesswork. Both include a trailing slash out of the box, so concatenating subpaths doesn't require an extra /.
By the end of this post you'll know exactly when to use get_home_path() and when to use ABSPATH, and why they match in some projects but return different directories in others. As a bonus, we'll cover a common double-slash mistake and a scenario for external cron scripts.
💡 Quick overview:
- Open your theme's
functions.phpand includewp-admin/includes/file.php, then callget_home_path()to get the absolute path with a trailing slash - Use the
ABSPATHconstant fromwp-config.php; it's available globally, requires no manual inclusion, and works even on the front end - With a non-standard directory structure (Bedrock, relocated core), compare the output of both methods on a test server; they may point to different folders
- For plugins and themes distributed through the WordPress.org directory, use
ABSPATH; it's the standard that works reliably on any hosting
Characteristic |
|
|
|---|---|---|
Where defined |
|
|
Availability | Admin only / after | Global |
Trailing slash | Always present | Always present |
Do they match | In a standard install, yes | In a standard install, yes |
When they differ | Core is relocated from the document root | Bedrock, custom structure |
1. Get_home_path(): the path via the admin API
The get_home_path() function is documented in the official WordPress documentation and returns the absolute filesystem path to the installation root, the directory that contains wp-admin, wp-includes, and wp-content. Unlike manual hardcoding, it doesn't depend on the hosting environment and won't break when you migrate.
The main advantage: you don't need to guess whether the site is deployed at the domain root or in a subdirectory. The function figures it out and returns, for example, /var/www/html/ for a standard install or /home/user/site.com/wordpress/ for a site in a subfolder. No ../../ and no manual config edits.
The file containing the function is located in wp-admin/includes/file.php, so get_home_path() is not available directly in a theme or on the front end. To use it outside the admin area, include the file manually first. Add the code to your child theme's functions.php or via a plugin like Code Snippets:
1 // Include the file with the function — without it get_home_path() will cause a fatal error 2 require_once ABSPATH . 'wp-admin/includes/file.php'; 3 4 // Get the absolute path to the WordPress root 5 $root = get_home_path(); 6 7 // Example: include the update.php file from wp-admin 8 require_once $root . 'wp-admin/update.php';
Here require_once with a path built from ABSPATH loads the admin file only once; a second inclusion won't cause a conflict. After that, get_home_path() is available anywhere in the theme.
Note: the trailing slash is already included in the returned string. Concatenate subpaths without an extra leading /: $root . 'wp-admin/update.php', not $root . '/wp-admin/update.php'. PHP will silently swallow a double slash on most filesystems, but some strict file_exists() checks may stumble.
2. ABSPATH: the constant straight from wp-config.php
ABSPATH is a constant that WordPress defines in wp-config.php during boot. In a standard file it looks like this:
1 if (!defined('ABSPATH')) { 2 define('ABSPATH', __DIR__ . '/'); 3 }
__DIR__ returns the directory where wp-config.php itself resides, and that is the WordPress root. The constant is available globally: in themes, plugins, on the front end, in the admin, in WP-CLI. No require_once needed to load it; it's already in memory from the moment the core starts.
Usage is trivial: use ABSPATH anywhere an absolute path is required:
1 // Save the path to a variable for readability 2 $rootPath = ABSPATH; 3 4 // Include the file from wp-admin 5 require_once ABSPATH . 'wp-admin/update.php'; 6 7 // Or load a custom file from the root 8 include_once ABSPATH . 'custom-cron.php';
The trailing slash is present here as well, behavior identical to get_home_path(). The pattern require_once ABSPATH . 'wp-admin/update.php' will work on any hosting, in any directory structure, with zero path adjustments. That's exactly why most plugins in the WordPress.org directory use ABSPATH rather than get_home_path(): the constant requires no manual file inclusion and doesn't depend on the call context.
When get_home_path() and ABSPATH return different directories
In a standard WordPress install, both constructs return the same string. But there are two scenarios where they diverge, and if you're unaware of them, a bug can live in your code for months.
Core is relocated from the document root. Some hosting providers (Kinsta, WP Engine) and custom setups place core files in a separate directory, with wp-config.php one level above. In this case ABSPATH points to the folder containing wp-config.php, while get_home_path() points to the subdirectory with the core. On WordPress StackExchange developers share a real-world example: ABSPATH = /www/site/, while get_home_path() = /www/site/wp/. A one-directory difference, and require_once fails with a fatal error.
Bedrock and other non-standard structures. In Roots' Bedrock, the site root (web/wp/) is separate from the project root, which contains config/, vendor/, and web/. ABSPATH in Bedrock points to web/wp/, whereas get_home_path() orients itself based on multisite settings and the home URL. In practice, get_home_path() in Bedrock may return a path to web/wp/ that matches ABSPATH, but don't rely on that; verify on your specific project.
Practical takeaway: if you're writing a plugin for the WordPress.org directory, use ABSPATH; it's available everywhere with no extra includes. If you're writing code for a specific site with a non-standard structure, check both constants in a test environment and pick the one that points where you actually need. Five minutes of comparison on a test server will save hours of debugging in production.
There's one more nuance with themes: if your theme is distributed on ThemeForest or in the WordPress.org directory, always use ABSPATH; it's guaranteed to be defined on any client's hosting. get_home_path() may not work if the theme calls it before the admin area loads.
The short video above visually demonstrates how ABSPATH protects plugins from direct execution and why the defined('ABSPATH') or die pattern is a security standard for any PHP file in the WordPress ecosystem.
⁉️🤔 Frequent questions
Which is faster: get_home_path() or ABSPATH?
ABSPATHis a constant: its value is defined once when WordPress loads and is stored in memory.get_home_path()is a function that, on the first call, parses the home URL and computes the path relative to the filesystem. The speed difference is vanishingly small (microseconds per call), but if the path is requested dozens of times in a single HTTP request, storeABSPATHin a variable at the top of your script and use that.
Do I need to manually include ABSPATH in my own files?
If your code runs in the WordPress context (theme, plugin, AJAX handler),
ABSPATHis already defined; you don't need to include anything. The checkif (!defined('ABSPATH')) { exit; }at the top of a standalone PHP file in the site root is a good security practice: it blocks direct script execution bypassing WordPress and protects against data leaks via a direct HTTP request to the file.
Can I use ABSPATH in an external cron script?
You can, but with caution. If the script lives outside the WordPress installation, load
wp-load.php:require_once '/path/to/wp-load.php';. After that,ABSPATHbecomes available. Keep in mind: callingwp-load.phpdirectly loads the entire core and all active plugins, which is overkill for frequent cron jobs. For high-traffic projects, it's better to move the logic into a WP-CLI command.
Does get_home_path() return a path with a double slash?
No. The function is guaranteed to return a single trailing slash. A double slash can only appear if you add a
/at the beginning of the subpath yourself:get_home_path() . '/wp-admin/'. The correct way is without a leading slash:get_home_path() . 'wp-admin/'. On most Linux systems a double slash is equivalent to a single one, but don't rely on that;file_exists()checks on some configurations may returnfalse.
How is the root path different from the home URL?
The root path (
/var/www/html/) is the server's filesystem. The home URL (https://site.com) is the address the browser sees. To get a URL, usehome_url(); for a filesystem path, useget_home_path()orABSPATH. Don't mix them up:require_onceexpects a filesystem path,wp_remote_get()expects a URL. If you confuse them, you'll get eitherfalsefromfile_exists()or a broken HTTP request to a local path.
What to use in your project: the bottom line
For the vast majority of tasks, ABSPATH is sufficient. The constant is available immediately after WordPress loads, requires no manual file inclusion, and works identically on any hosting. If you're writing a plugin or theme for distribution, ABSPATH only, no alternatives.
If you administer a site with a non-standard directory structure (relocated core, Bedrock, multisite with different home URLs), spend five minutes and compare the output of get_home_path() and ABSPATH in a test environment. A one-directory discrepancy can cost hours of debugging in production.
Which method do you use, get_home_path() or ABSPATH? Let us know in the comments: we read every one.



