TLDR:
In a non-standard installation, you can place your WordPress files in a subdirectory of your website root.
…and still allow your visitors to visitors to access your WordPress “website” from your site’s Domain (root) URL, without appending the subdirectory name:
(ie: www.example.com vs www.example.com/wordpress):
WP function | wp_options. | WP constant | what it represents | WP Settings Label | Example ------------------------------------------------------------------------------------------------------------------------------------- `site_url()` | `siteurl` | `WP_SITEURL` | WordPress files location | WordPress Address | https://www.example.com/wordpress `home_url()` | `home` | `WP_HOME` | browser address bar | Site Address | https://www.example.com
Where the value for a WP constant takes precedence over an wp_options/ WP Settings value.
Different Configurations for WordPress
In the most standard WordPress installations, home_url and site_url will have the same value.
Regardless, they represent two different things.
In a non-standard installation, they may have different values.
NOTE: I am leaving off the protocol in my answer for easier readability.
In this post, PREPEND EVERY URL with:https://,http://OR//
(unless I included it already).
(// is the relative protocol and will work for either/both http:// or https://)
Standard Installations (including “One-Click” Installs)
home_url: is the home page of your (wordpress) website, as indicated in the user’s address bar.site_url: is the directory where your wordpress files are located.
WordPress’s 5-minute install installs wordpress files these two values will be the same – wordpress files will be installed in the same folder that you want people to use to address your website, or the wordpress (blog) portion of your server’s website.
Example 1:
user accesses your blog at: www.example.com,
wordpress files installed at: www.example.com, or the root folder of your server’s website.
home_url === site_url === "www.example.com"
Example 2:
user accesses your blog at: www.example.com/blog,
wordpress files installed at: www.example.com/blog, or in the blog folder inside the root of your website.
home_url === site_url === "www.example.com/blog"
In this case www.example.com is the main website, and www.example.com/blog is the root of your blog.
Here your blog is separated from, and works as subset of, your main website.
In this case, your main website is not controlled, defined, or styled by WordPress.
Just your blog is. All urls in your blog will be proceeded by www.example.com/blog
Note: In documentation, “WordPress site/website” (as opposed to simply “site/website”) refers to the directory where your WordPress files are installed. In this case, it is www.example.com/blog – everything within the blog folder. The “WordPress website”, in this scenario, is not the same as your domain, your root, or your main website. It is a subset of your overall website. Kind of like a website inside a website. I mention this as the terminology can seem unclear or confusing, given this particular setup.
Alternate WordPress Installation Configuration
Giving WordPress Its Own Directory, the section Method II (With URL change).
For example, many people don’t want to clog up the root folder of their website with all the wordpress files.
They want to install wordpress in a subdirectory, *but have the “blog” or “WordPress website” accessed as if the files were installed in the root of the server’s root for the website.
This is particularly be true when WordPress is used to build and run an entire website that does not even have a “blog”.
Example 3:
user accesses your “blog” at: www.example.com,
wordpress files installed at: www.example.com/wordpress, or the root folder of your server’s website.
home_url === "www.example.com"site_url === "www.example.com/wordpress"
(Note: this configuration will not work “out of the box” just by changing the values of these variables. It requires additional configuration changes to work properly)
See Giving WordPress Its Own Directory, the section titled Method II (With URL change) for how to do this.
In this case home_url and site_url should hold different values.
In this setup, you want your website to function exactly as if WordPress files were installed in the server’s root directory for your website…
BUT, for organizational purposes on the server,
you actually have your WordPress files in a folder called wordpress in the server’s root directory for your website.
So, user will type in www.example.com to get your WordPress home page, instead of www.example.com/wordpress
wordpress function <–> database variable <–> WordPress Constant
This section assumes Example 3 configuration above.
address bar url: www.example.com
wordpress files: /wordpress directory
(The other cases are trivial: All variables/functions hold/return the same value.)How to set the values for site_url and home_url
First, let me note that siteurl and home store values returned by the functions above
1) Normally you set these values on the WordPress backend/dashboard/admin panel:Settings -> General ->siteurl WordPress Address: https://www.example.com/wordpresshome Site Address: https://www.example.com
(do not include trailing slashes here – that would be configured elsewhere)
2) Alternatively, you set these values in your WordPress database:wp_options table ->
`options_name` | `options_value` ---------------------------------------------------- `siteurl` | `https://www.example.com/wordpress` `home` | `https://www.example.com`
(do not include trailing slashes here – that would be configured elsewhere)
3) Edit your wp-config.php
Define these specific constants to hold your values
Define WP_HOME and WP_SITEURL settings by inserting these lines toward the top of your wp-config.php file:
define('WP_SITEURL','http://example.com/wordpress'); // wordpress core files
define('WP_HOME','http://example.com'); // address bar url
// ** MySQL settings - You can get this info from your web host ** //
... (do not include trailing slashes here – that would be configured elsewhere)
Reference: WP_SITEURL and WP_HOME
NOTE: This is confusing
(I really wish WordPress had Labeled the Settings similar to their php names,
such as WordPress Site Address and Home Page Address or something more explicit like location of WordPress Site core files and browser url to access WordPress home page)
`WP_SITEURL` <--> `site_url()` <--> `siteurl` <--> WordPress Address <--> /wordpress `WP_HOME` <--> `home_url()` <--> `home` <--> Site Address <--> /
Now Here is where it gets tricky !
IF you defined those constants in your wp-config.php file, it does not matter what values you have in your database/settings page.
In fact, you will not be able to modify this value through the back end (it’ll be greyed out). You can still modify in by editing your database, but doing so will have no effect on your site, while the constants exist in your wp-config file.
You config file will not change the values in your database (or hence you settings page). Instead, your database/settings page values will be ignored. The values in wp-config override or take precedence over your database setting.
So… to wrap up (TLDR) :
WP function | wp_options. | WP constant | what it represents | WP Settings Label | Example ------------------------------------------------------------------------------------------------------------------------------------- `site_url()` | `siteurl` | `WP_SITEURL` | WordPress files location | WordPress Address | https://www.example.com/wordpress `home_url()` | `home` | `WP_HOME` | browser address bar | Site Address | https://www.example.com
Where the value for a WP constant takes precedence over an wp_options/ WP Settings value.
The wp_options record value and the WP Settings value are the same.
Editing one, by definition edits the other.
It is just 2 different ways of accessing the same variable.
On the other hand, the WordPress Constants are unique and independent.
Internally, WordPress (PHP) constants override their db counterparts.
If a constant is defined in wp-config, it does not change the database.
But internally WordPress will always prefer/use its value instead of the db one.