Your staging server does not use WPE's caching technology, which your production server will use. WPE will not give you details on how their secret-sauce caching works. This means that things that work on staging will break on production. WPE also refuse to turn off their caching on production, but also refuse to turn ON their caching on your staging server. This means there is no real way to test. Things that work with their staging server, and even work with the standard WP caching plugins, will break in WPE production.
Their solution? Buy another production site to test on.
That website is now moving from WPEngine after having its launch botched by the aforementioned issues, and after not being able to make a basic paywall work with their caching. Once they realised the use case, WPE simply suggested moving elsewhere without making any further effort to accommodate.
I had a similar reaction to the post yesterday by asmartbear as Jaques, but he made the extra effort to actually write the blogpost, so bravo to him. WPE enjoys this sterling reputation that misleads a lot of people into using them, but their comfort zone it seems is limited to vanilla WP installs with little deviation.
We invented this feature in response to bloggers and site owners who wanted to be able to test a new plugin before adding it to the live/production version of their site. We're also the only managed WP platform to offer such a feature as standard with all accounts.
I can see that in a true dev/staging/production test suite environment, it does't stand up as a true mirror of product for the reasons you stated - but then neither does the staging/local version of Google App Engine or Heroku offer the same exact environment of their production platform.
If you need true like-for-like mirroring of production and staging, then yes, you need to create another WordPress instance - that's the case for most providers. Also its wroth nothing all WP Engine accounts, other than the Personal plan, come with multiple WordPress instances, so rarely that means actually buying anything further.
You may be the only managed Wordpress platform to do so, but App Engine has had this functionality for a long time.
Not saying it was right or wrong, it just wasn't a fun experience thinking I was going crazy. And hopefully if anyone else is trying SETCOOKIE() and it's not working they also realize they will have to use JS.
Don't get me wrong, as a contractor to a company that uses WPEngine, we have had a great experience with it - but e.g. in the case of setcookie() being completely useless for unauthenticated users, some documentation / warnings / big red flags would be nice.
In my case I was trying to build a simple site selector for unauthed users that would forward them to their selected site every time they hit the main domain. Nothing exotic by a long shot.
This isn't something specific to WPEngine, this is how all the good WP caching plugins work.
Your frustration with their caching "secret sauce" is understandable. However, you can get a rough idea of their caching back-end by poking around in the WP Engine config files and plugins bundled with your installation. They also provide a nice little overview here: http://wpengine.com/our-infrastructure/.
If you are staging out anything more complex than a single blog, you will definitely want to have two production instances to test on. For some, this is a raw deal. I personally don't mind.
I am also not a huge fan of their CDN feature, which works by rewriting URLs in your page source to point files and assets to NetDNA servers. However, I am hopeful that they will improve upon it.
That said, I have enjoyed a platform that keeps my Wordpress installations secure with automatic upgrades.
Comparing WPEngine to other hosting providers like Linode or Dreamhost is really unfair. They offer completely different services, and specialize in Wordpress-optimized hosting only.
I also have to say that it was really nice to not be part of Amazon/Heroku's outage this week. WP Engine has a control panel hosted on Heroku, but all their sites live in the Linode network, evading downtime.
Same basic proposition: fully managed Wordpress.
They cost less.
And their service roflstomps WPEngine's.
1. Email FireHost with the event IDs and a request to unblock.
2. FireHost doesn't reply for 24 hours, or if they do it's with "we can't find that event in our logs".
3. I open a Page.ly ticket
4. "El Vaquero Furioso" (yes, that was his name in Zendesk) replies that the issue is fixed and won't happen again.
5. I ask for the root cause and what steps were taken.
6. Crickets, or a snide response from the founder that "we're all on the same team".
Sorry we handled that poorly. At the time Firehost was having some significant issues with their firewall policies. We do constantly walk that line between enforcing security at the edge and annoying customers that may run into WAF blocks. It's a delicate balance.
The problems you had have since been resolved and pagely is running under a new firewall (and new blades) which are much more reliable.
In addressing your frustration my comment of 'we're on the same team' was to demonstrate that we were all working towards a solution for you. As professionals dealing with other professionals we aim to acknowledge and address the problem while steering the conversation to a positive outcome. If our customer views us as an adversary it makes the process more challenging for all involved. By re-framing the conversation as we are all in this together, all working towards a solution, we feel it is more likely the positive solution will be found and implemented sooner. My comment was a gentle reminder to that effect: acknowledging the issue, and we are working with you, and with our partners to remedy it.
Thank you for your past business, and we hope one day to earn it again.
- joshua strebel, founder pagely.
I guess it's like how, in this thread, lots of people are saying they've had great experiences with WPEngine and then there's me, suddenly internet-famous as that unhappy WPEngine customer.
WPE has been great so far -- very responsive support -- and their caching handles about 8 million pageviews a month with 600-800 simultaneous visitors and very little downtime.
Just because you have a bad experience it doesn't mean that it sucks. My experience with WPEngine has been fantastic.
What blows a story like this up (as much as hitting the front-page of HN is 'blowing up') isn't that a service failed to meet the needs of one blogger, but rather that the people running the service respond to criticism (in public) sounding more like petulant children than professionals.
As someone not into blogging, I'm not that familiar with WPEngine, but based on comments here that link to various twitter comments now I suddenly have a negative-leaning opinion of them. Primarily because they couldn't take a negative review without calling the poster a "hater". (FWIW, a lot of my negative opinion is tied up in this stupid word, which IME comes out as a last resort when the person using it knows there's a lot of truth to what the other person is saying but they refuse to acknowledge it for whatever emotional reasons).
But I wasn't asking for anything exotic. A multisite network, not very large, not much traffic. It says, right there on their site, that they support multisite networks.
So I guess I ... well ... expected that they would be able to support a multisite network.
It would make sense for them to offer a dev plan with every production plan though, and let you upload your site, and serve it to a limited no of people as a testing ground. Given their 'Power Tools for Power Users' stuff on their website, they really should consider at least offering staging servers for testing.
I guess at present they're just not a good setup for developers trying to modify WP, and are instead trying to capture the market for hardened WP hosting for mostly vanilla installs.
I don't know of any large WP installs that would need the benefit of outsourced WP hosting/experts that use 'vanilla installs'. They may exist, but I can't imagine they're a large portion of the market. Perhaps my scope of experience is too narrow in this respect?
Part of their caching setup was causing the API request to fail for a select list of bots. The issue was escalated to a Sys Admin who figured out what the problem was. He tweaked my server and fixed the issue for me within a day. I think that is pretty good.
My point... if something is broken and you think it might be WPEngine's caching. Try it on your staging server.