Not just that the directory they are in is set to be backed up, but actually backed up.
WordPress 4.4 added some major things behind the scenes (REST API infrastructure) and really sweet things on the front end, like responsive imaging.
For all of you Jetpack users, Photon already supports the vast majority of new hotness with responsive imaging with the rest to come very, very soon.
Twenty Sixteen is now the present. You’ve seen the theme on this site for months now—it has had a pretty clean development cycle. There only thing that I particularly noticed as a minor coloring issue on the secondary color schemes which was quick to patch. I do wish they post format templates were a bit more interesting (or different at all), but that’s my only real critique. It looks good with great accessibility.
The new oEmbed support is pretty great. Need to drop in a post from any other site running WordPress 4.4+? Just drop the link into the visual editor, like https://wordpress.org/news/2015/12/clifford/ for the release post and it transforms into:
wp_die() since there are some nice little wins in there).
To set this up for your website, you used to (and still do on some hosts) need a dedicated IP address for the website, a fair amount of money, and jump through of hoops with the certificate authority (CA) issuing the certificate. There was, also, a lot of back and forth needing a certificate signing request (CSR) to send to the CA, then installing the real certificate when it was issued.
Let’s Encrypt aims to change that. The goal is a fully automated process where someone could type in a command on a server, wait a few seconds, and have a certificate issued and installed on their system.
It’s been in development for a while now and I’m proud to say that my employer, Automattic, is a Silver sponsor of the project. Yesterday, the opened for a public beta period. So, of course, I gave it a spin.
This site has had a certificate for some time, but I never pulled the trigger on enabling HTTPS on any of my other domains. I opted to try this on, perhaps, my greatest domain— kraft.beer.
Let’s jump in and get some HTTPS going.
I run far too many WordPress sites. For me, for friends, for my old college fraternity’s 25th anniversary site. Far too many.
They never break on me. The plugins I use are pretty solid and I’ve become a bit lazy. I don’t always follow best practices of backing up everything before updating (though it is all automated anyhow), checking the changelog first, being at a real computer and not just at my phone.
That happened to me the other night. As I was waiting for a train to pass while driving home, I checked a site for an event this weekend on my phone and saw that it had an update. I knew the plugin and knew it would be fine.
I started the update.
But then, a horrible, horrible thing happened. Nothing. Maintenance mode started. The plugin’s update had started, which typically just takes a few seconds. Minutes passed. Nothing.
I opened a new tab. The dreaded scheduled maintenance message.
On a computer, this is no big deal. I’d login via FTP, delete the .maintenance file, and live to fight another day.
But I’m on my phone. Waiting for a train. Why do I do this to myself?
To make matters worse, by the time I got home, I forgot all about it.
The next morning, I turn on the computer and see an unrelated e-mail about the event, again that is coming up this weekend. OH NO I LEFT THE SITE BROKEN OVER NIGHT.
I hit the home page. It worked…
I logged into the site.
I’ve honestly never had an update fail like this that I didn’t immediately, as soon as I realized was taking too long, resolve manually.
When WordPress loads, early on it loads
/wp-includes/load.php which fires
wp_maintenance() which checks to see if we’re in maintenance mode, which is determined by the presence of a
.maintenance file in the root that is created when entering maintenance mode.
Then, it either loads the drop-in
wp-content/maintenance.php plugin (for a custom maintenance page) or the default maintenance page unless we’ve been in maintenance mode for more than 10 minutes. In that case, it simply keeps loading WordPress.
I’m not sure why the update failed in the first place, but WordPress handled the failure smarter than I thought it would. Smarter than I was upgrading sites from my phone.
I updated to the Nginx mainline repo and changed one line in my .conf file—
I’m exploring Server Push, though nothing is implemented at this time.
It definitely feels faster, especially navigating within the site to different pages.
Aside to the aside: Yes, I really did do this via my phone.
I've been sick in bed all day. So, I enabled HTTP/2 on my site from my phone. There are things wrong with me that aren't physical.
— A Guy Called Kraft 😷🏅 (@Kraft) November 19, 2015
And I feel pretty good about my site being among these as the ones having HTTP/2 connections: