Consider adding "local" as environment on WP_ENVIRONMENT_TYPE

[claytoncollie]

Ticket to consider adding a fourth environment type, local, to the newly added WP_ENVIRONMENT_TYPE. I host many websites with WP Engine and they have 3 environments; development, staging, and production. That is all well and good with this addition to Core, but it leaves out the fact that many people are using a local development environment such as Local Lightning or Lando or DesktopServer before sending their code to the cloud. This type would give developers a great deal of control over their existing development workflow and make sure that local is not the exact same as development if it does not need to be.

[johnbillion]

Moving to 5.5.1 for discussion.

Related: #50992

[jeremyfelt]

I would also appreciate "local" being part of the predefined list of environment types.

[kreppar]

It would be great to have this option available, it would allow customizing some of my workflows.

[dushakov]

+1 on adding "local"

[TimothyBlynJacobs]

I think it'd be helpful to give examples of how plugins should behave differently between when a site is in "local" and "development".

[Ipstenu]

This is what we did at the Bank I worked at many many moons ago!

localhost = This is on my laptop and I may be using it on an airplane, so remote calls should not happen. This is like dev, only _potentially_ offline. (NB: We did call it localhost so it was 100% clear it was all local all the time, and something familiar to our ESL devs)

development = I'm dev'ing some code and may need remote data, but basically I'm going to be hitting refresh a lot and swearing.

staging = This is a mirror of production/live, in a perfect world, and should do everything EXCEPT muck up my stats, thanks. (NB: We called this "User Acceptance Testing" - this is where clients went and clicked and said "Hey I love it except this color...")

production/live = Your real site.

[claytoncollie]

@TimothyBlynJacobs I am developing a plugin that connects to Algolia to host my search index. I want to have a unique index name for local, dev, staging, and production so that I am not overwriting data from another install. Also for my team of developers, they can have their own index mapped on their local machine that is independent of my index or the other 3 installs on WP Engine. If all of the developers were using the development index, they could be writing over each other's index while working on their local machines.

Add local as an option to wp_get_environment_type() so that developers can distinguish from cloud-hosted environments.

Trac ticket: https://core.trac.wordpress.org/ticket/51064

[claytoncollie]

I added a pull request for this ticket on GitHub.

​https://github.com/WordPress/wordpress-develop/pull/493

[khag7]

#50992 seems to be going the opposite direction from this ticket: they state there that the list of environment "types" should be limited to "development" "staging" and "production".

A noteworthy snippet from a recent comment there:

One of the challenges we've run into with the environment type label is that it's quite narrow and conflates different things:

• Where is this application running? (e.g. local environment or remote environment)
• What is the application’s purpose (e.g. production site; non-production site; staging site; etc.)

Maybe the solution here should be to come up with a way to define "where" the application is running. Then we can allow #50992 to restrict the environment type (i.e. purpose) to the three "development" "staging" and "production".

If local vs remote is defined in some different way (yet another constant?) then you could use that constant to differentiate between development(remote) and development(local).

If this is a bad idea (introducing a new constant to define local vs remote) then we're stuck in a position of deciding which ticket we implement and which we don't. Seems like #50992 is on track to win, meaning this ticket doesn't lead to any implementation.

[knutsp]

Replying to khag7:

If local vs remote is defined in some different way (yet another constant?) then you could use that constant to differentiate between development(remote) and development(local).

If this is a bad idea (introducing a new constant to define local vs remote) then we're stuck in a position of deciding which ticket we implement and which we don't. Seems like #50992 is on track to win, meaning this ticket doesn't lead to any implementation.

Isn't this what WP_LOCAL_DEV is for?

Environment type should be about purpose. Don't confuse 'local' into this type. A wontfix.

[khag7]

Replying to knutsp:

Isn't this what WP_LOCAL_DEV is for?

You're right, my mistake. I didn't even know about that. I sort of remember it now that you mention it. So the fact that it exists means already means there's no new constant needed. Why is it that this is even an issue?

Between WP_ENVIRONMENT_TYPE and WP_LOCAL_DEV and the ability to add your own constants in wp-config, what is it that is an issue here?

[claytoncollie]

@khag7 @knutsp

If we add local, plugin and theme developers could potentially use the following:

switch( wp_get_environment_type() ) {
    case 'local':
        // do something on local.
        break;
    case 'development':
        // do something on development.
        break;
    case 'staging':
        // do something on staging.
        break;
    case 'production':
        // do something on production.
        break;
    default:
        // do something when not defined, typically the same as production.
}

And if we do not add local but instead rely on WP_LOCAL_DEV, an alternative could be

$environment_type = wp_get_environment_type();

if ( defined( 'WP_LOCAL_DEV' ) && WP_LOCAL_DEV ) {
    // do something on local.
} elseif ( 'development' === $environment_type ) {
    // do something on development.
} elseif ( 'staging' === $environment_type ) {
    // do something on staging.
} elseif ( 'production' === $environment_type ) {
    // do something on production.
} else {
    // do something when not defined, typically the same as production.
}

Does that sound about right?

[claytoncollie]

@khag7 @knutsp

By not adding local and having people rely on another constant, I think ignores the fact that local development is a very common practice especially with the prevalence of applications to do so as I listed in the ticket description. While I do agree with you, @knutsp, about an environment being about purpose, I am sceptical that most people will understand that amount of nuance.

[Clorith]

Although I was initially not a fan of adding another type here (as I perceive develop and local as much the same), the example from @Ipstenu perfectly outlines a usecase none of the other scenarios would account for.

On that example alone, I think this is something that should be implemented here.

I saw in the somewhat related ticket (#50992) a call for documentation of what each environment type is expected to represent, and I think that would make sense to define. What would this classify as, should plugins/themes/core expect local to mean "No internet, don't make remote calls", writing out what these classifications mean would be a huge benefit I believe, and @batmoo has some good examples that could be built on.

[TimothyBlynJacobs]

the example from @Ipstenu perfectly outlines a usecase none of the other scenarios would account for.

I disagree that a local environment type can solve that use case.

so remote calls should not happen. This is like dev, only _potentially_ offline.

Because this is only potentially offline, I don't think it is a useful distinction. For instance, I would anticipate any local development environment, mamp, Local, etc... would set local as the environment type. It would be wholly unexpected that remote HTTP requests stop working.

I think this is better served using something like ​Airplane Mode.

Isn't this what WP_LOCAL_DEV is for?

Of note, WP_LOCAL_DEV is really only used by Jetpack: ​https://wpdirectory.net/search/01EGGHQXTKT0BSFN4DXRC7JA3Y And hasn't been really announced as an official feature of WordPress Core, though it is now included by way of Site Health.

I want to have a unique index name for local, dev, staging, and production so that I am not overwriting data from another install.

I don't think using the environment type is the correct thing to do here. That is using the environment type as the actual environment/instance the site is running on.

writing out what these classifications mean would be a huge benefit I believe, and @batmoo has some good examples that could be built on.

💯

[markjaquith]

Replying to TimothyBlynJacobs:

I think it'd be helpful to give examples of how plugins should behave differently between when a site is in "local" and "development".

1. Using an image CDN like Jetpack/Photon (used on development, but not on local, because you cannot). This is different from an offline situation. I am online, but my local site is not accessible on the public web.
2. Talking to Cloudflare (purge after update type stuff, Cloudflare Worker communication code, etc). You want to test this on dev, but again cannot run it locally because Cloudflare isn't proxying to your local site.
3. Enabling dev plugins only on local. Yes, you could also run these on development, but you might want to only have the hardcore tools (Query Monitor, etc) active locally, and use development as a final developer check of running on production-esque hardware, but before you've pushed it out to the staging server that non-devs use to verify new functionality before deployment to production.
4. You might not have access to certain resources locally, like Elasticsearch.
5. You might not store a copy of production images in the local clone, and might want to transparently fetch those missing images from production for local development, but do that on your public-web development server.

Some of these are things that a plugin author could make intelligent decisions about. Jetpack already changes functionality on local sites. A Cloudflare/Varnish purge plugin could do the same. And then other plugins could allow the site operator to decide, or they could leverage it in their own custom code.

[TimothyBlynJacobs]

The points about a local environment not being accessible from the web is a great distinction I hadn't considered. I think that is a tangible thing that plugin developers can use to alter their behavior.

[kreppar]

The cases that @markjaquith mentions are the ones that I personally think would solve adding 'local' as an environment

[joostdevalk]

I'm quite ok with adding local as an environment option, given the great arguments given above.

[SergeyBiryukov]

In 48856:

Bootstrap/Load: Add local environment type to wp_get_environment_type().

This gives developers a better control over their existing development workflow and ensures that local is not the exact same as development if it does not need to be.

Props claytoncollie, johnbillion, jeremyfelt, kreppar, dushakov, TimothyBlynJacobs, Ipstenu, khag7, knutsp, Clorith, markjaquith, joostdevalk, SergeyBiryukov.
Fixes #51064.

[SergeyBiryukov]

In 48857:

Bootstrap/Load: Add local environment type to wp_get_environment_type().

This gives developers a better control over their existing development workflow and ensures that local is not the exact same as development if it does not need to be.

Props claytoncollie, johnbillion, jeremyfelt, kreppar, dushakov, TimothyBlynJacobs, Ipstenu, khag7, knutsp, Clorith, markjaquith, joostdevalk, SergeyBiryukov.
Merges [48856] to the 5.5 branch.
Fixes #51064.

Closing this out as the ticket has been committed.