Jetpack: Auto-activate Development Mode when on a staging site

[robertdall]

For the second time this year. (About every 6 months) Jetpack / WordPress.com has a issue with our staging server on wp-engine.

WordPress.com replaces our real domain with our staging server domain. This really messes with Publicize which can't auto tweet out our blog posts and sharing stats. (The numbers on the side of the sharing icon) get messed up or don't even show at all.

When you have Jetpack on a multisite this mean you have completely remove Jetpack on all sites and subsites from WordPress.com and then remove the plugin from your install.

You then have to install Jetpack back on your multi-site and go to each and every subsite and deactivate the modules that you don't want etc etc etc.

I then had to reconnect all of our social media accounts.

This took a quite a while to get everything reconnected and syncing again.

Yet I can't prevent Jetpack / WordPress.com from messing up again. Hence the title of this issue.

[kraftbj]

This is primarily occurring when cloning db from prod to staging. The site ID and the "secrets" used to verify communication are stored in the database, so with two sites using the same ID and credentials, things get mixed up in transit.

Turning on development mode in staging is a decent way of stopping it (can add it in via a mu-plugin or however works best. Probably pretty easy to have a plugin that if site/home_url contains staging.wpengine.com, enable dev mode, etc).

[kraftbj]

I'm going to close this to defer to #771 and #1611.

[robertdall]

But when I copy live to staging it copy's over everything. How can I stop this from happening again when the staging server is just a copy of the live site.

This issue is incredibility frustrating. Hours have been wasted on this issue.

[kraftbj]

Just did a quick test and a plugin that checks against the site_url appears to work:

if ( site_url() == 'http://example.staging.wpengine.com' ) {
add_filter( 'jetpack_development_mode', '__return_true' );
}

Edit: For multisite, checking network_site_url would likely be better, but idea the same.

It'll disable the features of Jetpack that require a connection (and likewise, prevent the staging site from polluting the data on the wp.com side), so there may be an issue there depending on what you're developing.

[robertdall]

FYI I had to use site_url()because it was on the main site not a sub site or network site. On the staging site it does give you the notice is that the staging server is in development mode but it still shows that the Wordpress.com features are still available and clickable. In my previous experience this isn't normal if I am not mistaken. See attached screenshot.

[asmartbear]

Hi All, you can definitely use the style of code given above, but you'd have to tweak it for domains etc..

A more reliable and portable method would be to use the fact that we define the PHP macro IS_WPE_SNAPSHOT only in the staging environment. Thus it's like the code above except:

if ( defined('IS_WPE_SNAPSHOT') && IS_WPE_SNAPSHOT ) {
add_filter( 'jetpack_development_mode', '__return_true' );
}

Having written this, of course, my next thought is that our own plugin ought to just do that for you always! :-) I'm adding an enhancement request to our backlog. :-)

P.S. Yes I know "snapshot" is a mis-nomer -- this is an accident of history and we didn't want to break back-compat.

[robertdall]

@asmartbear I am going implement what you have suggested in the small plugin we have created as a stop gap measure. Can you update this issue when that is completed on your end?

@kraftbj This should still be implemented into Jetpack for those not on WP Engine.

[kraftbj]

Reopening/renaming since there's solid discussion here. I've confirmed the same behavior on Panethon (curious if they had something cooking already since the support load on this has been almost totally from WPE customers).

@asmartbear Thanks. I'm working on patching up a couple of stray bugs this method reveals in Jetpack (namely, Jetpack's Settings page still provides options that should only be available outside of development mode).

[kraftbj]

For the record, I think the ideal is there's a solution within Jetpack that scales to any development workflow. We already auto-activate development mode, for example, if there is no period in the site's URL (e.g. http://localhost/ ).

Generally, having each hosting provider add code makes more to maintain long-term and break. In this case, there's no harm in a custom solution that add_filter( 'jetpack_development_mode', '__return_true' ); on top of us doing the same at some point. Just want to be clear we aren't asking hosting providers to work around us as much as finding a solution that works for everyone :)

[robertdall]

FYI @asmartbear code suggestions https://github.com/Automattic/jetpack/issues/2153#issuecomment-104343115 gives the same error I reported here: https://github.com/Automattic/jetpack/issues/2153#issuecomment-104127907 But it does show the staging server is

_In Development Mode, via the jetpack_development_mode filter._

[asmartbear]

@robertdall roger that on the "same error" -- I know, I'm just saying that form of the conditional is safer and universal, compared with looking at the domain name.

@kraftbj We're very happy to support whatever method of auto-dev you provide! Just let us know and we'll build it in.

[robertdall]

@asmartbear Agreed that note was more for @kraftbj saying the same error appears with the revision of the code.

I'z like to be thorough :smile:

[kraftbj]

@robertdall Yup, no matter how dev mode is enabled, at the moment, that problem would exist. I didn't have time today to dig in and determine the issue, but we're tracking it over in #2156 specifically for that piece.

[kraftbj]

Noting Pantheon's PHP constants are

PANTHEON_ENVIRONMENT = 'dev'; // development
PANTHEON_ENVIRONMENT = 'test'; // meant for staging of completed features before going live
PANTHEON_ENVIRONMENT = 'live'; // production

[robertdall]

@kraftbj While I know that we aren't going for a hosting specific resolution to this issue. I wonder if contacting flywheel would help to just to get their point of view before building on this. They might have some good feedback or incite for ya.

[kraftbj]

@robertdall The current idea is we'll attack this two ways: For known staging sites, we'll add a check for these constants to auto-activate dev mode. For providers that we either don't know about yet or don't add a constant, etc, we have a related enhancement that will flag if the site's URL is different than we expect with an option to acknowledge it is a staging site. Once acknowledged, we'll save it as a known staging site and auto-activate dev mode in that case for your particular site (if you're doing like testing.example.com, etc).

[georgestephanis]

It's tricky, because a lot of sites would demand a fully functioning mirror of production on their staging environment, and then be upset because it wasn't providing that. So while we may auto turn on local dev mode, we may also need to give them a way to opt out of acting like a staging environment.

Ideally we should be testing for two things -- Jetpack::is_staging_environment() -- which tests for environment stuff and then fires off a filter so folks can override either way -- and a filter that lets folks in a staging environment tell it to act like a production environment instead.

[kraftbj]

Just finished a call with the devs about this and a couple of related issues. For 3.6, we're going to prompt users when a site's URL doesn't match what we'd expect it to be and prompt if it is a staging site. When that's done, it would prevent things that would mess with production, but still give the full experience. (#2146)

Dev mode itself will be looked at more in depth in a future release (3.7 as now), so punting this issue to that milestone.

@georgestephanis My thought on this was add the check for the constant before the final is_development_mode return, so the filter could still be used as a final way to get around anything automatic.

[asmartbear]

I'm a little confused why the hook for whether it's a dev environment isn't sufficient? You could provide your default implementation, but that way individual hosting providers (like us) can redefine it and thus maintain it on your behalf, even providing additional UI to our customers, and yet our customers can still override _ours_ and do whatever they want as well.

In short, it allows good default behavior in various cases, while still allowing vendors and end customers override and thus still be in control.

It sounded like the original complaint was about the way the result of that hook was displayed? Perhaps that's an orthogonal issue?

[kraftbj]

@asmartbear I'm approaching this as we do conflicting plugins (e.g. those that generate OG tags also). Generally, we implement a workaround on our end, then as we confirm that any particular plugin themselves disable Jetpack's functionality, remove our workaround—sometimes happens totally in dev and the workaround never ships out.

Based on the conversation here, I would lean toward excluding WPE as you're handling it.

Psudeocode for what's in my head right now:

function is_development_mode() {
    $development_mode = false;

    if ( defined( 'JETPACK_DEV_DEBUG' ) ) {
        $development_mode = JETPACK_DEV_DEBUG;
    }

    elseif ( ( defined 'HOSTING_CONSTANT_1' && HOSTING_CONSTANT_1 ) || // WP Engine
             ( defined 'HOSTING_CONSTANT_2' && HOSTING_CONSTANT_2 ) || // Another host
             ( defined 'HOSTING_CONSTANT_3' && HOSTING_CONSTANT_3 ) ) { // another host
            $development_mode = true;
    }

    elseif ( site_url() && false === strpos( site_url(), '.' ) ) {
        $development_mode = true;
    }

    return apply_filters( 'jetpack_development_mode', $development_mode );
}

In all cases, the filter jetpack_development_mode has final say and priority so if either we're wrong, the user/host/etc wants more control, etc, there's a way ignore our suggestions.

[georgestephanis]

I'd say it should be a new fn Jetpack::is_staging_environment() -- and we shouldn't automatically put it into dev mode, as some folks may want to test how Jetpack behaves in production in staging. After all, that's kinda the point of a staging environment.

[dereksmart]

Agreed. There's a fn in the ID crisis PR that I plan on building off of

[georgestephanis]

Yup, I just don't think it should be the Jetpack_Sync class -- and when in a class, we don't really need to prefix the method with jetpack_

[samhotchkiss]

@dereksmart is taking ownership

[kraftbj]

Noting flywheel's staging URL structure: staging.*.flywheelsites.com

[kraftbj]

Spoke to Flywheel today and they don't set a constant at this time, but may in the future.

[mathuaerknedam]

I'd just like to make this a little more explicit for anyone who comes here and needs help knowing what to do on Pantheon... Add the following to wp-config.php:

if (isset($_SERVER['PANTHEON_ENVIRONMENT']) &&
  ($_SERVER['PANTHEON_ENVIRONMENT'] !== 'live')) {
    define( 'JETPACK_DEV_DEBUG', true);
}

[stale[bot]]

This issue has been marked as stale. This happened because:

• It has been inactive in the past 6 months.
• It hasn’t been labeled `[Pri] Blocker`, `[Pri] High`.

No further action is needed. But it's worth checking if this ticket has clear reproduction steps and it is still reproducible. Feel free to close this issue if you think it's not valid anymore — if you do, please add a brief explanation.