Trouble with Wordpress local development and deployments

Question

The Setup:

I'm setting up a Wordpress-powered application using Elastic Beanstalk from Amazon Web Services. All development is being done locally under a MAMP apache2/php5 server environment with a GIT repository controlling the entire application root.

Deployment Workflow:

After committing any code changes (edits, new plugins, etc) to the repo the application is deployed using AWS EB CLI's eb deploy command which pushes the latest version out to any running EC2 instances managed by Elastic Beanstalk.

My Issue:

Sometimes the code changes aren't exactly syncing up between my development/production environments and I'm not sure how to overcome it. Especially when trying to install and setup plugins like W3 Total Cache or WP Super Cache.

Since my local environment doesn't have things like a memcahced server installed, but my production environment does (ElastiCache) I'm unable to save the proper settings file and deploy it for use in my production environment. These plugins won't allow me to select the needed services because it sees them as not available...

It seems I can only get W3 Total Cache to work if I install it directly onto a live production environment, which seems like a bad idea.

Given the above:

• Am I going about deployments the wrong way?

• Should plugins like W3 Total Cache be installed and configured on local development environments and pushed to production environments?

Answer 1

Couple different things going on here, but my two cents:

1) Philosophically: if a file may be modified somehow in any of its remote deployment contexts, don't keep it in the repo. Since W3TC keeps its settings in a flat file (and that flat file is updated every time you go into the W3TC settings screen in any context and hit "save"), it's difficult to ensure that changes made in any context make their way back to the repo (and subsequently to your other contexts). So, any config updates made directly on prod will be blown away the next time you push code up. Know what I mean?

2) Since some of W3TC's functionality is environment specific (as you said, memcahce vs not, apache vs nginx, etc.), it's not instructive to test it on a local environment that is substantially different than production. You can't create identical configs, because your environments are not identical. This is logical. I'd consider setting up a staging environment (identical to your prod setup), where you can test your W3TC settings. Once you've got your settings dialed in, you can use W3TC's export/import feature to move settings between environments. And if you want, you can save that export file (rather than the auto-generated settings file) into your repo for future reference. Kind of a poor-man's SCM, but works for things like this that don't need to change often, and can stand some manual setup.

There are plenty more "complete" solutions if you want to get into more complex deployment scenarios. If you're using a tool like Bamboo, you can literally script every aspect of the deploy. But with your setup, I'd just take the W3TC config out of SCM altogether, and take a manual approach. As a long-term goal, maybe look at running virtual machines locally instead of MAMP--they let you literally replicate your prod environment locally. But they come with a steep learning curve.

Answer 2

Typically your opcode cache will detect file changes and update the cache entry, so you need to be more specific with what exactly is not working, memcache, opcode, static files, transients, etc?

The default PHP Opcode cache is 5 seconds which can be changed in your config under opcache.revalidate_freq.

You can flush the cache on deployment using something server side such as memcache_flush or many plugins come with hooks that can be used to flush the cache, for W3 Total cache it is w3tc_pgcache_flush for example. Also have a look at wp_cache_flush. You can do this via the cli on push or create a web endpoint ( there are a lot of tools out there than already do this depending on what your using).

It really depends on your exact set up, typically you want to mimic your live site as close as possible, you should use a staging server with mimics the live server even if your localhost doesn't.

Answer 3

If you need a good environment for developing WordPress plugins, checkout wp-plugin-devkit. It runs on top of Docker, but does not require any Docker knowledge.

https://github.com/jamrizzi/wp-plugin-devkit