Environment specific configs feature

[mcheck]

It would be great to be able to tweak the environments based on their use.

We are doing that slightly with the WP_DEBUG and WP_ENV vars within WP, but I would like a way to include more env-specific configs - both system and WP. Perhaps a file in WP called based on the WP_ENV result?

For the system, I'm specifically thinking of things like varnish. It doesn't seem that one would want to run varnish on a development box (local). It may run slower, but because I am changing all sorts of things, I don't want to worry about system-level caching. I've had the instance where I was tweaking css and the screen does not reflect those changes because of caching (I assume). So I have to manually restart varnish to see changes.

[ericclemmons]

Regarding Varnish, it's running on all environments for consistency in the stack, but caching is bypassed 100% for anything starting with ^local:

https://github.com/genesis/wordpress/blob/master/provisioning/roles/varnish/files/etc-varnish/conf.d/receive/wordpress.vcl#L2

As for per-env settings, you can perform the same checks in wp-config.php that Genesis added automatically (if (WP_ENV === 'local') { ... }, or do something like the following for per-env settings:

include_once __DIR__ . 'wp-config-' . WP_ENV . '.php';

I'm open for suggestions on specific system/env use-cases you have!

(BTW, v0.3 will be BC-incompatible changes where most of the provisioning gets moved out to separate repos so it's easier for your project to say "I want WP, but no Varnish", for whatever reason :D)

[mcheck]

Thanks, I did see that varnish is supposed to be ignoring the local
vmachine, but somehow, something with varnish (redirection, rewrite, etc)
wasn't completely ignoring it. I found that removing varnish allowed the
base configuration to work as expected.

Great, like to hear that env-specific is part of the plan.

Sorry, what's BC ?

[ericclemmons]

Backwards-compatible. Since we follow semantic versioning, moving from v0.2 to v0.3 will likely have some decent breaks in it that may require regenerating the core parts of the project. (Nothing too hard to sort out with git diff).

We will try to bake as many fixes into v0.2 before the change, though...

[ericclemmons]

@mcheck If you can find that case where Varnish is still caching, I'd <3 to know. Truth be told, @EvanK & I are using community-recommended configs, but my personal stance is to have something as simple & clear as possible.

For example, the Varnish config is "cleaning" up the request for Apache, and explicitly ignoring some cookies to prevent unnecessary PHP sessions from spawning.

However, that's clearly over-reaching and complicating what would otherwise be a simple, seamless, predictable reverse-proxy cache that is skipped for ^local only.

Cleaning that part up should be backwards compatible, as it should only require re-provisioning.

[mcheck]

Happy to help, but I need direction in determining where to watch for varnish caching and/or causing the issue.

The white screen of death on upgrades or various plugin installs was first reported by me in issue 12 then again by @ericrasch and @ggamel in issue 30, so it is my assumption that it is not isolated.

I can consistently get it to fail everytime with Jetpack by Wordpress. @ggamel mentions this also here.

My approach was to disable varnish completely in local by changing the following:

/etc/apache2/ports.conf

NameVirtualHost *:80
Listen 80

/etc/apache2/sites-enabled/000-local.mysite.com

<VirtualHost *:80>

sudo service varnish stop
sudo service apache2 restart

Then, plugins like Jetpack that previously would NOT install from the UI, now install without a problem.

I understand having a similar stack across the environments, and therefore running varnish on local and eliminating caching in config, but I'm not sure that it is completely ignoring it. Perhaps something is happening on UI plgin install when the redirect to upgrade.php changes the url, and something is caught? I'm not sure, but I can say that @ggamel and @ericrasch were having the same issues, at the same point, in local.

So, again, I'm happy to test to see if it is still happening, can you guide/point me to the place that I can monitor varnish and its interaction? Maybe if I can tail a varnish debug log while doing the plugin install, I can catch where varnish might still be interacting in some way.

[ericclemmons]

Sounds like I should resolve the other issues first, then come back to this one :)

[ggamel]

Since I was summoned via GitHub Issues, I'll say the following: though I might be out of my depth with helping resolve this issue, I'll help test anything, as much as needed.

[mcheck]

@ericclemmons Well, I think the issues are related, but that's just me :) Are you saying that with the current release, running the same precise32 vagrant, same provision, you can add the jetpack plugin from the wp-admin gui?

@ggamel Thanks, I have the same sentiment. Jack of All, Master of None, that's me :) I know enough to be dangerous, so I'm happy to test, revise, repeat as needed!

[ggamel]

Jack of All, Master of None, that's me :) I know enough to be dangerous, so I'm happy to test, revise, repeat as needed!

Yup! Happy to help great-for-me-and-probably-others-too projects because once the most annoying issues get resolved, more people can benefit. 😁

[ericclemmons]

I have to say, this is a project that's been ~year in the making for me, and we finally utilized it in my company, but having you guys eagerly & constructively help with everything has been huge ;)

[EvanK]

It may not be enough to force cache misses for the wordpress admin. Because of the way it plugin installs + updates work (effectively streaming output during the entire request), we may have to do a return (pipe) for it. I'll check into this and -- if it works -- add it to #62

[ericclemmons]

Side note: I think it's best to have Varnish run the same on local, staging & production (read: all environments) to avoid any sort of inconsistency between them. This also means that the logic like "bypass varnish when logged in" is necessary for local development, but shouldn't be a problem. Likewise, this will ensure there are no surprises upon deployment, which we've seen our fair share of by having different behavior with each env.