"WordPress Address (URL)" & "Site Address (URL)" in WP Multi-site

[bamajr]

Most people, familiar with WordPress, know about the “WordPress Address (URL)” & “Site Address (URL)” settings and that they are located in the General Settings area.

As security becomes a bigger and bigger issue, more and more people are using SSL Cert. (HTTPS) to help secure their WordPress websites. Many of these people also have Jetpack installed. This combination can cause an issue to surface, related to how Jetpack uses the site URL settings to find (and access) the xmlrpc.php file.

Many SSL configurations (including EE / Let’s Encrypt) use server-side rewrites to force SSL. However, server-side rewrites do not make changes to “WordPress Address (URL)” & “Site Address (URL)” settings, within WordPress. As I continue to run into issues (using EE, Let’s Encrypt and Jetpack, together), I can’t help but think maybe there should be a process, built in to the Let’s Encrypt installation, to change these settings, auto-magically.

See:

The response to XML-RPC related issues can be read here:

Easy enough to fix, when logged into the WP Dashboard, right?

Not if you have WP Multi-site installed!

So, I’d like to know if there is there a way to address this issue, during the EE / Let’s Encrypt installation process?

If not, I’d like to know how to address these URL settings within a WordPress Multi-Site installation, immediately after the install process.

FYI: I posted a little about this issue, as a response to the Jetpack and Letsencrypt discussion.

[tyrro]

you can use this:

EasyEngine Wordpress non-www to www

cd /var/www/domain.com/htdocs wp option set home http://www.domain.com wp option set siteurl http://www.domain.com

so no need to be logged into your WP Dashboard

[bamajr]

@tyrro Let me make sure I’ve got this…

You’re suggesting to:

cd /var/www/example.com/htdocs/

…and run some commands (I assume they are WP-CLI commands):

wp option set home https://example.com

…and:

wp option set siteurl https://example.com

???

Will this work for Single and Multi-Site installations?

[tyrro]

yes, it should work for both.

[purbeckpixels]

The easiest way to achieve this is to use the WP_HOME and WP_SITEURL constants in the site’s wp-config.php file, e.g.:

define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');

This will set the correct URLs under Settings > General, and force them to be uneditable via Dashboard. Bear in mind this probably won’t change the URLs in the wp_options table in the database. I find the easiest way to change all URLs in a database from http to https is to use WP_CLI, e.g.:

cd var/www/example.com/htdocs

wp search-replace 'http://example.com' 'https://example.com' --dry-run

–dry-run does exactly what it says and allows you to double-check what’s going to be changed/updated in the database. You might have to append --allow-root to the above command if you’re logged in via SSH as root.

I hope this helps.

[purbeckpixels]

tyrro and I are doing practically the same thing, just different ways.

[purbeckpixels]

Having done a little research, it appears that you shoudn’t use the WP_HOME and WP_SITEURL constants for a Multisite install, so it’s probably best to ignore what I typed above. You can still use wp search-replace or tyrro’s wp option suggestion though.

[bamajr]

@tyrro & @purbeckpixels - I’ve attached a screenshot of what I did and the associated error, below:

Thoughts?

The website seems to be working just fine.

[tyrro]

I have the same error message, perhaps someone with more experience with PHP can identify the issue but it doesn’t seem to effect the CLI commands.

[bamajr]

After performing the set home and set siteurl processes I went ahead with the following:

cd /var/www/landmarkbirmingham.com/htdocs

sudo wp search-replace 'http:landmarkbirmingham.com' 'https://landmarkbirmingham.com' --dry-run --allow-root

Which provided the following output:

NOTICE the PHP Notice?

After reviewing the change locations I went ahead with the following:

sudo wp search-replace 'http:landmarkbirmingham.com' 'https://landmarkbirmingham.com' --allow-root

Which provided the following output:

Again, NOTICE the PHP Notice?

While there are a few PHP related concerns, I can confirm the processes above (combined with those in my last post) DO seem to fix the XML RPC issue, in Jetpack.

…which was NOT working correctly before.

[purbeckpixels]

Good to hear.

As for the PHP error notices, double-check you’re not defining WP_ALLOW_MULTISITE twice in your wp-config.php file. I recall having similar PHP error notices recently related to WP_CACHE - the issue was that a caching plugin was adding define(‘WP_CACHE’, true); to the top of wp-config.php but I had already defined WP_CACHE towards the bottom of my wp-config.php file, which was causing WP-CLI to display errors. Might be the cause…

[bamajr]

“Can open, worms everywhere”

Ok, now this is weird…

I’ve done only the traditional EE install for a website, and the above discussed database search/replace for http.

Then at your suggestion, searched for duplicate WP_ALLOW_MULTISITE in the wp-config.php file.

I found it twice and one line I’m not sure of (possibly a 3rd declaration):

What I’d like to know is:

1. Which WP_ALLOW_MULTISITE location is the standard/correct WP location?
2. What is the difference between

define( 'WP_ALLOW_MULTISITE', true );

…and…

define( 'MULTISITE', true );

???

Also, why are there two instances of WP_ALLOW_MULTISITE in my wp-config.php file?

I didn’t put it there, so something in either the EE scripts or the search/replace must have.

[purbeckpixels]

define( ‘WP_ALLOW_MULTISITE’, true );

…and…

define( ‘MULTISITE’, true );

are correct and both should be included in wp-config.php for a Multisite install.

define( 'WP_ALLOW_MULTISITE', true );

enables the Network Setup menu item in WordPress’s Dashboard, while

define( 'MULTISITE', true );

tells WordPress that it’s a Multisite install.

The location of

define( 'WP_ALLOW_MULTISITE', true );

doesn’t matter as long as all define statements are added above

/* That's all, stop editing! Happy blogging. */

Just remove one of the duplicate ‘define ( ‘WP_ALLOW_MULTISITE’, true );’ statements and the WP-CLI PHP errors will go away. As for what included the define statement twice, who knows, but it wouldn’t have been the ‘wp search-replace’ commands.

At least you’ve gotten to the bottom of what was causing the PHP errors.

[bamajr]

I just went back and looked at every multisite website (5 of them) I’ve deployed in the last 4 months and everyone of them has this problem.

Maybe @ssalil or @rahul286 could look at this, as it seems to be an issue with the EE Mulitisite installation process.

[bamajr]

I’ve deployed three more new multisite environments within the last 6-7 days and all three have the:

define( 'WP_ALLOW_MULTISITE', true );

…twice.

This has got to be an issue with the EE implementation of multisite as I do NOT get this with a standard WordPress deployment, not using EE. @ssalil and @rahul286 please take a look at this, as it is causing problems with SSL deployments.

[Justin_Antony]

I have the same issue and i found Wordpress Admin panel. General - > Set the right Site URL if you have SSL check the url starts with https:// instead of http:// This resolved the wordpress jetpack issue of RPC

pls visit: sqlpublic.com