Ever had your Featured Image Admin Option go missing in WordPress? This very useful cute little box:
The Featured Images check box is not in Screen Options either:
Recently we struggled with a difficult issue in WordPress Multisite. We take care of a network of sports weblogs. Each is for a different sport and not all the domain names sound the same.
We have a master install at say worldrecords.org (sample name, not our client's site). Logins only are SSL and all take place at worldrecords.org. An account at any site gets you access to all the sites. Hence login and password takes place at the master domain. Most visitors are not even aware of the domain switch during login.
When people would lose their password, the password reset email would not come from skatinggolds.org or lugegolds.org but from worldrecords.org. Many people would not recognise the domain and would delete the email without clicking and finishing the password reset. Worse yet the email might be considered spam by spam filters.
There's been a lot of talk and writing about radically revamping WordPress edit experience since the New Year. It's great that the conversation has been started and many strong ideas have been shared. Matt Mullenweg kicked off the discussion on 4 January with a Coleridgian description of a new editor. Like Kubla Khan's "stately pleasure-dome", the new editor should be a "miracle of rare device".
The editor will endeavour to create a new page and post building experience that makes writing rich posts effortless, and has “blocks” to make it easy what today might take shortcodes, custom HTML, or “mystery meat” embed discovery.
Any "post building experience" which aspires to make "writing rich posts effortless" has my full attention. What should this experience look like in practical terms?
At Foliovision, we like to stay behind a few versions on WordPress. This means our clients enjoy stable custom code for their complex membership and business sites. What it means in real terms is that a site usually stays on the major WordPress iteration on which it was released.
Staying on security updates enormously decreases a publisher's WordPress maintenance burden. We're really grateful to the core WordPress crew for continuing to post security updates for every WordPress release from 3.7 on. On the other hand, it's extremely rude of WordPress to constantly push small publishers to do major version updates without letting the publisher know security updates are available (1). Our BusinessPress plugin solves update anxiety. We lighten up the update notifications, give you more information about what version you are running and encourage you to install the latest security update. Most importantly, BusinessPress prevents clients from pushing through a major update accidentally and breaking their site. On the Christmas holidays for instance.
We are adding comment ratings to our FV Thoughtful Comments at the request of one of our clients. He likes Disqus features but doesn't like entrusting his user generated content to a third party service and doesn't like Disqus page load slowdowns. A very smart guy and successful publisher.
We've experimented with Epoch and wpDisquz and have even donated to the latter. Unfortunately wpDisquz is not fast enough either on a really busy site (measured in both page views and frequency of comments).
In a conversation at WP Tavern (a Matt Mullenweg official property) about the problems with maintaining recent WordPress versions (say anything post 3.7), a very lively debate took place about whether major new features in WordPress should come enabled by default with no option to disable them.
The feature in questions was oEmbed this time but it could just as easily have been emojis or XML-RPC (which recently took thousands of WordPress websites down in a major hack exploit).
We use a lot of software at Foliovision. What we like are stable reliable solutions which deliver what they promise. What we hate is hypeware which overpromises and underdelivers. Often hypeware is delivered by companies which look for successful niches, clone the existing software (easy enough thanks to Matt Mullenweg's and Automattic's insistence that all code must be GPL). Cloned code is generally vastly inferior to the original (most often coded by a passionate coder with a deep understanding of the problem he is trying to solve).
What those copycat coders then do is market the heck out of "their" new product, often making sales where better code is available free or outselling a less expensive and better solution.
Automattic and Akismet have a big drive on now to force people to upgrade their existing Akismet subscription. We've been paying Akismet for four years now and sometime even we are now seeing warnings like this one on our own websites. Our clients are seeing them as well (even when using their own key).
Of course, we don't mind paying Automattic/Akismet something but we don't really want to pay more than we are now.
We recently found our users were having difficulty resetting their passwords. As many of our users are paid owners of our WordPress video player FV Player Pro, it is essential they are able to log in to manage their licenses. Log in issues were a very big deal for us and we had to stop the presses to get it working right. Much thanks to Klaus for helping us track down the bug.
We love Satollo and loved Hyper Cache (we're longtime paid users and supporters of his Newsletter technology as well). Strangely, sometimes good developers do bad work. The latest version of Hyper Cache (version 3) is a prime example of what can go wrong with rewrite upgrades.
Since we were struggling with Hyper Cache we decided to take a look at WP Rocket who is the hot new caching kid on the WordPress block. Sadly WP Rocket is not a good replacement for us for now. We test and compare Hyper Cache and WP Rocket below.
Many successful WordPress site owners have moved their sites over to WPEngine for their high performance and high speed even under very heavy traffic.
WP Engine is able to provide this kind of speed thanks to their "hand-built a WordPress-specific EverCache system" and "a fully-managed CDN service" (for more info see WP Engine's articles on speed and infrastructure).
WordPress cache plugins were in really sad shape by the summer of 2012. WordPress 3.3 and WordPress 3.4 have changed some important parts of these plugins and they started to collapse. The first one to go was W3 Total Cache (at WordPress.org) which has been getting about 50% broken ratings since last fall. After spending months learning how to use W3 Total Cache just right (it's a complicated beast), we had to pull it off all our sites. Fortunately the much simpler WP Super Cache (at WordPress.org) remained bullet proof.
This spring and summer WP Super Cache broke too. Garbage collection does not work reliably any more, leading to people getting served week old pages. Donncha first suggested it's impossible to make WP Super Cache work for all hosting out of the box. Strange as for more than five years WP Super Cache did just that. The real answer came a bit later. WP Super Cache is a free plugin and Donncha just doesn't have time anymore.
I have hardly any time to devote to this any more. One of the dangers of becoming a father I'm afraid.
We've struggled to get garbage collection working properly to keep our clients' sites cached but reliably up to date. For the moment garbage collection still won't run reliably on at least Informed Comment. As JuanCole.com is one of the most read political sites in the world, this is something which needed to be fixed right away. It turns out there is a third WordPress cache plugin out there, Hyper Cache (at WordPress.org). We know the author of this plugin Stefano Lissa from his Newsletter Pro plugin which we use for a few clients. Lissa's code is good, he can handle sophisticated tasks while keeping the code structured enough for external teams to find and repair bugs and he answers his email.
So while HyperCache is less well-known than the big two, it seemed worth a try. We think long and hard before changing horses on core functionality like caching as we have years of experience with our core plugins. Usually our philosophy is better the devil you know is better than the one you don't.
In addition, WP Super Cache has mod_rewrite capability which means no PHP has to run (and hence presumably no CPU) to serve cached pages. We put a high value on Super Cache's capability to bypass PHP processing. But to our surprise testing last year had shown to Hyper Cache to be a bit faster than WP Super Cache. Other testing had shown Hyper Cache competitive. What is also worth noting from the other two tests is that in a comparable environment W3 Total Cache is in no way superior to either WP Super Cache and Hyper Cache, just more complicated. Complicated is bad: KISS is the best development rule ever written.
We still didn't really believe these results and thought there must be something strange in the test environment. We wanted to test against a real site and a real server that had been online.
We still had a testbed server available with Informed Comment on it and no traffic. The nice thing about this test bed is that it is a very limited 768 MB VPS with bare bones Apache and mod_php on it. I.e. we knew that if we gave it a good effort we'd be able to saturate it with proper external testing from LoadImpact. Our main dedicated servers with nginx would cost hundreds of dollars per test instead of $15/test. Based on past testing, we far prefer real web traffic than synthetic benchmarks like ApacheBench.
Here's what we found with 500 concurrent connection test. First the results for WP Super Cache.
Now from the challenger HyperCache.
Basically the results are identical. Both plugins allow the post to be downloaded at a fairly constant 1.8 seconds per load.
We've helped build WordPress sites for Microsoft, Yammer, The Hollywood Reporter, Wesleyan, Zendesk, Informed Comment and many more.
We'd like to help you improve or host your busy WordPress site too.