WP Engine is very neat, and clients really like it. But it is not ideal for development. In the cases where we are still working on WP Engine sites, we just do our best to put together as sensible a workflow as we can. Here are some things you may like to know about working on it.
Cron Jobs
Cron jobs that are created through WordPress such as wp_schedule_single_eventare processed when the site receives traffic. This works great on WPEngine, including staging environments, with one exception. If you're environment has Apache Basic Authentication in place with a username and password, no cron jobs will ever run.To fix this, turn off basic auth via the WPEngine admin, do your thing, and then re-enable once the job's complete.
Long Processes which Silently Disappear
WPEngine has a silent "Long Running Project Killer" process that runs by default on all new installs. If your process takes longer than 30-60s, it silently kills the process, without any errors.If you're doing any long-running processes as part of a cron job or custom script, you're going to have to ask them to specifically turn that off. There are performance implications.
Caching
You cannot modify the caching of WPEngine served pages, and EVERY page is cached. If you're creating a page that requires alternative caching strategies, you're going to have to contact support and submit requests on a per-URL basis for this alternative caching process.
“Git Push” Deployment
- WP Engine ships the last branch pushed to the remote repo
- The files are shipped from that repo’s location to the server. The server is not a git repo instance
- Pushing will not delete files from the site which were not deleted in the git repo (committed deletion)
- Subtree push essentially tells the repository instance which files are relevant, not which files to include. It has every commit and is a full history of the full project, but only makes the subtree’s files visible in the directory