Hacker News Reader

So we don't apply the caching stuff to the staging server because the purpose of the staging server is to stage content and test new plugins and themes.

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.

The solution with Heroku is to create a separate app and use that. The app will be identical except for having fewer (and optionally different) resources. Because it's billed hourly, it doesn't cost too much to run it at full power for a short while to answer a question, before scaling it back down. The reason you needed to "invent" this feature is because your environment isn't as self-service as it could be.

This is not true for App Engine. You can create a "staging" version of your app and access it at staging.my-app.appspot.com. It all runs on the same infrastructure that your main version runs on, and it's easy enough to make it admin-only. Once your satisfied that it's safe to deploy, it's two clicks to change which version is serving.

You may be the only managed Wordpress platform to do so, but App Engine has had this functionality for a long time.

I was helping a friend debug something on WPEngine. We learned that the caching doesn't allow you to set cookies it would seem (from PHP). Had to do it all using JS instead. I thought I was going crazy trying to debug the code when it was definitely an issue with the way they cache.

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.

That was my issue, and yes, it absolutely is one of the many reasons why staging instances should have a caching on/off switch that mirrors production. It is absolutely 100% feasible that WPEngine's caching will break your site, and you need to know this before you push to production.

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.

It sounds like you and ohashi don't understand how caching works. WP caching serves up static copies of your pages, bypassing the code and DB calls that would normally be required. Since your code is bypassed cookies won't be set.

This isn't something specific to WPEngine, this is how all the good WP caching plugins work.

I've had the opposite experience of WP Engine, and appreciate leaving caching and performance issues to somebody else, given that my company has a somewhat limited staff for supporting servers and CMS upgrades. I am building a semi-complex Multisite installation with multiple domains. So far, it's been pretty decent.

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.

Then compare it to Page.ly.

Same basic proposition: fully managed Wordpress.

They cost less.

And their service roflstomps WPEngine's.

…and they never accepted my credit card.

Just because you have a bad experience it doesn't mean that it sucks. My experience with WPEngine has been fantastic.

I suspect that for 99% of customers, WPEngine is fine. Excellent, even. Certainly better than barrel-bottom shared hosting outfits.

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.

Basically all services have a group of satisfied users and a group of unsatisfied users.

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).

I had the opposite experience as well -- I tried Page.ly first but could not import any of my sites (which all use a variety of custom post types). Their import process seemed more attuned to vanilla installs. Closing out my billing with them was also somewhat arduous.

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.

Page.ly was awful. When my sites weren't down due to botched infrastructure upgrades, users would get locked out of the admin interface by "FireHost Website Protection" (FireHost was/is their underlying hosting provider). The same sad cycle repeated multiple times:

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".

That sucks.

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.

Hey D,

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.

> Their solution? Buy another production site to test on.

... wow.

To be fair, any WP hosting company is going to run into issues with non-standard installs, and they're not going to be able to accommodate any setup. If you have a customised WP install, it might not work on this sort of provider, they're optimising for speed, not dealing with, and they probably don't want the headache of trying to support any plugins or modifications that you might bring to WP.

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.

Multisite has been part of the base Wordpress install since 3.0.

Just curious, why do some pages sort 189k db rows?

That could very likely be the "Recent Comments" feature, which is incredibly inefficient.

This is basically what I found with some preliminary detective work from Page.ly.

Wow!

"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?

Likely, yes. Most WP installs that I've done use 6-8 of the most supported plugins, a slightly customized theme, and mostly standard server configurations.

I had an issue where an API call was failing for Googlebot and other crawlers. I was worried about this being seen as "cloaking," so I was trying to figure out what was causing. Couldn't be my code. The API provider said it wasn't them. I finally realized that it was WPEngine when I visited my staging server as Googlebot. The content that was supposed to show up showed up!

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.