Run the latest version of Jetpack and WP on a multi site withe the sub site setup.
define( 'WP_SITEURL', 'https://example.com' );
define( 'WP_HOMEURL', 'https://example.com' );
That the sites would work as expected when interactiing with the API.
The sites returned the error jsonAPI not found.
the siteurl for the subsites was being synced as the main sites url.
cc @ebinnion.
Note that
define( 'JETPACK_SYNC_USE_RAW_URL', false );
fixed the issue for me.
@ebinnion Would you mind taking a look at site ID 137325493?
siteurl actually lives in a subdirectory.siteurl set to the same value as home.Thank you!
Ticket: 755855-zen
Would you get the user to run wp jetpack sync start on their site?
I just moved my multisite install (132849040) into a subdirectory, ran that sync command, and the siteurl synced correctly:

Also, a new debug might be helpful now that the user has changed the Jetpack code they're running.
Would you get the user to run wp jetpack sync start on their site?
That did not help unfortunately.
@ebinnion Is there anything else we could try to fix this?
Can you get a new Jetpack debug? I'd be interested in seeing what the Sync IDC URLs: value is. That should let us know what the site thinks it's sending us.
Also, looking at the current debug, it looks as if the site is not opted into IDC management. That may become an issue since it seems like we have been sent a couple of other URLs for that blog ID.
Attaching notes to ticket.
The user came back with the JP debug info (it's in the ticket).
@ebinnion - would you mind looking at this again?
One question they is how much of a problem is this for Jetpack? Is it only going to break the manage module or will other features break too?
Dug in and left reply on ticket.
In short, it appears as if Bedrock doesn't handle the home and siteurl options the same as core, and perhaps, out of the box, has errors with multisite.
For example:
Multisite in core remove the default option_home and option_siteurl filters in favor of the values stored in the db. From what I can tell, Bedrock recommends setting both values to the main URL, even though WordPress is stored in a subdirectory. Then there's a Bedrock plug-in that they use to overwrite the URLs:
https://github.com/roots/bedrock/pull/276
We can likely provide 3rd-party support to handle this. But, for now, users should probably use something like this:
add_filter( 'jetpack_sync_site_url', 'jetpack_fix_url_for_bedrock' );
function jetpack_fix_url_for_bedrock( $value ) {
if ('/wp' === substr($value, -3)) {
$value = substr($value, 0, -3);
}
return $value;
}
Thanks a lot. I replied to the user.
Hey there! I'm pretty sure I'm the "user" here ๐... I appreciate all of your team's help!
I'm quite active on GitHub as I'm on the Roots team and seeing your references pop up here and there...
I've added your code as an mu-plugin and have responded to the ticket, but let me know if I need to do anything here as well.
Hey @JulienMelissas ๐
Thanks for sticking with us as we debug!
Yes sir, we have been chatting about your issue since Jeremy reopened the issue.
Now that you've got this code hooked up, would you mind running wp jetpack sync start --modules=functions to sync the home/siteurl values over. Then, I'll confirm that we are getting the correct values.
If this does work, I'll be glad to get a patch in so that we can support bedrock out of the box ๐
@ebinnion no worries! This should hopefully go by quicker, even though we're (almost?) done. I'm happy to do anything to get it working long-term, and I know we will all appreciate the built-in Bedrock support.
I ran it on production and this is what I've got:
commerce@lak-commerce:~/public$ wp jetpack sync start --modules=functions
PHP Notice: Undefined index: HTTP_HOST in /www/{sorry, not this time ;)}/public/config/application.php on line 97
Initialized a new full sync with modules: functions
Sent data to WordPress.com
Success: Finished syncing to WordPress.com
It looks like the PHP Notice is a specific Cookie thing (define('COOKIE_DOMAIN', $_SERVER['HTTP_HOST']);) that was configured specific to our host popping up because I'm running a command in WP-CLI. Hopefully that doesn't cause any problems on your side.
Let me know what you think/if it worked!
Hey @JulienMelissas -
I can confirm that your siteurl now shows as having the /wp on our end. Also, your site has a clean debug at https://jetpack.com/support/debug/. All seems to be well with the world now! ๐ช
Thanks for working with us on this.
I created #8213 to track support for Bedrock. Closing this issue for now.
@ebinnion -- thanks for your help! I'm seeing a successful connection on the WP.com side of things too ๐
If you need help in #8213 I help to maintain Bedrock (although mostly support and use-cases, I have much more time invested in our other projects) and we might be able to find a way to detect it. Bedrock is used by hundreds (possibly more) of popular sites, so this will be appreciated I'm sure.
Hey folks! I'm getting this issue again on a new site, even with the above code mentioned. Should I re-open this here or would you like me to refer to our previous thread?
(ping @jeherve, @ebinnion)
Hey @JulienMelissas โ
Would you please submit a support request from the debugger in your Jetpack site? You can do that by going to $site.com/wp-admin/admin.php?page=jetpack-debugger, clicking the "click here to contact Jetpack support" link, and then filling out the form. Please mention me in the ticket and a happiness engineer will pass it off.
@ebinnion I hate to do this over GitHub, but I just wanted to check in... I sent a request in a few days ago and haven't heard anything since. I mentioned you in the request. Request came from [email protected].
No. That's perfectly fine. I'll try and track down that ticket right now.
@JulienMelissas โ I've sent you an email so we can chat there.
Hey @JulienMelissas โ I didn't receive a reply back to my email.
We did get a ticket in about 40 minutes ago to which I have replied. I wanted to be sure to let you know I responded so you can be on the lookout.
Most helpful comment
Dug in and left reply on ticket.
In short, it appears as if Bedrock doesn't handle the
homeandsiteurloptions the same as core, and perhaps, out of the box, has errors with multisite.For example:
Multisite in core remove the default
option_homeandoption_siteurlfilters in favor of the values stored in the db. From what I can tell, Bedrock recommends setting both values to the main URL, even though WordPress is stored in a subdirectory. Then there's a Bedrock plug-in that they use to overwrite the URLs:https://github.com/roots/bedrock/pull/276
We can likely provide 3rd-party support to handle this. But, for now, users should probably use something like this: