WordPress In A Subdirectory Impacts REST

WordPress has two options that are important to path resolution and the overall functionality of your site. The home option and siteurl option determine the URL for your web presence and the WordPress install. On a vanilla WordPress install where WordPress serves up the entire site from the root directory , both of these values are the same.

The WordPress home option

The home option is the Blog address according to the WordPress.org Option Reference. Kind of confusing but the simple terms is “this is the MAIN URL you want users to type in to get to your site”. Normally this is going to be something simple; your company name as a domain — https://www.storelocatorplus.com/ for example.

In the WordPress Dashboard this settings is labeled Site Address (URL) ; so yeah, the HOME option is labeled “Site Address” which is not at all confusing.

The WordPress siteurl option

The siteurl option is the WordPress address according to the same resource. This is the URL to the place where you’ve installed WordPress under your Document Root.

The Document Root is the folder you’ve configured your web server to “read” to serve up the main pages for your website. For many sites the your-company.com site will point to something like /srv/www/public_html and when a person types www.your-company.com into a browser it runs the first app it can find in this folder.

On a typical install WordPress is in that folder, so it will run WordPress. Your siteurl option will match your home option and be set to your company name as a domain name — https://www.storelocatorplus.com/ for example.

However, in a case where most of your site may be run by another CMS and WordPress is relegated to only serving up the blog portion of the site this is usually something different. If you installed WordPress in the /srv/www/public_html/wordpress/ folder then the siteurl for your WordPress install should be set to https://www.your-company.com/wordpress/.

The siteurl tells WordPress “hey, this is where you’ll find the WordPress software to make things run this portion of the site”.

Linking to the non-WordPress part of the site

The home option is no longer viable as the “the address we want people to type to get to the site”. WordPress now assumes this is where WordPress lives and processes all requests. If you install other things in your ~/public_html/ directory such as a CMS you must use other methods to direct people there — custom links in a WordPress menu for example.

WordPress REST API Problems

This is where things get interesting and more than a little confusing. It turns out the WordPress REST API resolves the internal get_rest_url() function to use the HOME option setting to determine the path to the REST listener. I find that a bit odd since the general premise up until this point has been that the WordPress install is going to be at the siteurl path.

Apparently the home setting (Site Address) is not just “the home page that is different from your WordPress installation directory” but the “Hey, this is where ALL THINGS WORDPRESS HAPPEN” from a URL standpoint. Including the URL where the WordPress REST listener will reside at <home>/wp-json.

There are two ways to mitigate this. The easy way and the hard way.

The Easy Way…

That means your home option MUST be set to the URL where WordPress is installed and listening to your connections. If you’ve installed WordPress in ~/public_html/wordpress and that is where the WordPress index.php lives then that is what you must set your home option.

Generally this means your siteurl and home options will be the same thing.

That can mean that both settings have the /wordpress/ ending and people surfing your site will always see your-company.com/wordpress in their address.

It can also mean that both settings have https://your-company.com/ and you’ve moved your entire WordPress install into the root directory of your site.

The Hard Way

You’ll need to have some serious Apache or nginx configuration chops for this one. If you need to keep WordPress installed in the /wordpress/ subdirectory but want people to see the your-company.com domain in the URL then you need to write a stack of rewrite rules.

For Apache this can be in a local .htaccess file in the ROOT directory of your site. For nginx you are better off putting this in your site-specific site-name.conf file in the /etc/nginx/sites-available or /etc/nginx/custom-sites/ folder.

The rules are going to need to redirect any errant REST url requests sent to https://your-company.com/wp-admin or wp-anything really. There are a LOT of these rules and not all are going to work well if you have another set of PHP apps (especially) living in your ~/public_html/ document root.

Whatever you do , do NOT follow the advice of posts that are more than a year old about putting WordPress in a subdirectory. It will not work unless you want to redirect ALL web-based requests to /wordpress — in which case you might as well just set your Document Root to be the /wordpress subfolder and be done with it.

One quick check if your web server redirect rules are working is to fire up a WordPress 5 page or post in edit mode and look at the browser developer tools. If you are getting a slew of invalid JSON format messages you’ve done it wrong.

In the web browser developer tools you may see requests going to https://your-company.com/wp-json/ — you’ll need to make sure your custom web browser redirect rules point those to the /wordpress/wp-json/* equivalent for your “split” home and siteurl options to work.

Read More

Read more about homeurl and siteurl at BlogVault.

Read what WordPress.org says about “Giving WordPress Its Own Directory“.