A great simple example for those interested in building pure JS web services.
Keeping the WordPress login intact between Cypress.IO tests was a challenge. There are plenty of Cypress.IO articles about login management and just as many about “anti-pattern” which lean toward the “login/authenticate between each test”. I don’t really want to test the WordPress login that often. I’m pretty damn sure it works. What I want to do is run my tests efficiently.
Unfortunately the “out of the box” examples, which I’ve been following, forgets about your login state between each test. Take my original Cypress.IO test — it logs in, configured the WordPress permalinks, logs out, does the Cypress.IO WordPress login again, sets the theme.
Far too often people do NOT ask me, or my colleagues in the industry, whom they should use as a web hosting company. Most business owners figure they are smart enough to at least select a host — especially when it comes to hosting a WordPress site.
And they Google it.
From the instant they made that decision they are screwed. Web hosting is an insanely profitable business and as such it has attracted tech titans; companies with a couple zeros in the “millions column” on their revenue sheets. They earn millions every month in hosting fees and pay a LOT of money to be the “first recommended” by Google or others.
WordPress REST performance sucks. There, I said it. Not because I dislike WordPress — in fact I think it is the best open source web application we have seen thus far. It is a great piece of technology. It even has the potential to be a great web application framework — in fact I use it for the Store Locator Plus managed service, MySLP.
However, unless you are in 100% complete control of every component in the system you are going to very likely end up with an underperforming over-burdened web service if you build your tech on typical WordPress components. Even the highly customized MySLP service is 5-10x slower than it would be if it was build on a completely customized application stack outside of WordPress.
WordPress is NOT built around performance. WordPress is built on two core tenets – ALWAYS support legacy users at all costs. Be extensible.
Google dropped a bombshell on most maps users, including many of the people using the Store Locator Plus WordPress plugin — they now require ALL SITES to register for an API key. The bigger part of the announcement was that ALL registered API keys must now be attached to a Google Billing Account. That’s right, Google now wants your credit card information on file and ready-to-bill at a moments notice if you garner any traffic on your displayed maps.
You will see a lot of map plugins and services changing over the coming months because of this. The WordPress plugin version of Store Locator Plus is one of them. Thankfully those clients that opted to use the fully-managed My Store Locator Plus service won’t need to deal with Google — but there will be “in the background” changes made to that service as well.