My friend and former colleague, Jim Reevior, presented a talk at this week’s Boston WordPress Meetup titled “Self Hosting Beyond the Website.” It’s a great introduction to Linux distributions and the components that go into hosting WordPress without using a shared or managed host.
As part of today’s admin track at WordCamp San Diego, I delivered a talk titled “Getting Started with SSL.” My intent was to demystify the terminology and process involved with securely delivering traffic. I described my talk this way:
Revelations like Edward Snowden’s about NSA spying, and Google’s announcement that it will begin considering a site’s HTTPS status in its rankings, led to a lot of talk about moving websites to secure connections. Similarly, the rise in ecommerce, and the simplicity with which one can accept payments online, has increased the need for sites to be available securely. With so much terminology that’s likely new, often very similar, and rarely more than a stream of initialisms, this entire discussion can be very intimidating. I’ll clarify basic terminology, offer some reasons why it’s worthwhile to secure a site whenever possible, and share several solutions to cover everything from simple to enterprise needs.
While securing a site can be intimidating at first, the recent introduction of Let’s Encrypt (https://letsencrypt.org/) significantly simplifies the process for most sites. Many hosts have introduced support for this service, which I’ll discuss before delving into options for sites and circumstances that aren’t suited to Let’s Encrypt.
There are too many Google Analytics plugins in the WordPress.org repository. By my count, there are 900:
When there are 900 results for "Google Analytics" in the official repository, it's safe to say we've failed all but the advanced user.
— Erick Hitter (@ethitter) April 14, 2016
When one of these plugins recently changed ownership and rebranded in a poorly-promoted way, I began looking for a new solution. Frustrated by both the volume of related plugins in the official repository, and their unending lists of features that I didn’t need, I did what many perturbed developers would: I wrote a custom solution.
With this week’s release of WordPress 4.5, yet again, I received props without being aware of it beforehand. As was the case when I wrote about this last year, this recognition came for code I contributed many years ago–four in this case, making it older than my contribution to 4.2.
As I wrote then,
I mention this not to bring attention my involvement, but to highlight the importance of patience when contributing to Open Source projects like WordPress.
Please, read Accidental Props 💥 if you’re discouraged or disappointed because your contribution hasn’t been accepted.
WordPress 4.4 simplified the process of embedding WordPress content on other sites with the introduction of post embeds. From the feature’s announcement post:
WordPress has been operating as an oEmbed consumer for quite some time now, allowing users to easily embed content from other sites. Starting with version 4.4, WordPress becomes an oEmbed provider as well, allowing any oEmbed consumer to embed posts from WordPress sites.
As exciting as this feature is, it ran into an incompatibility with my server configuration. I’ve set the
X-Frame-Options header to
SAMEORIGIN near-universally within my nginx configuration, thereby blocking other sites from displaying my sites in frames; instead, my sites can only display their own content inside of frames. I’ve done so as a security measure against “clickjacking.” This header has no impact on my use of WordPress, nor on visitors’ interaction with my sites, but as I discovered, it breaks post embeds in an awkward way.
In WordPress 4.3, a Site Icon feature was introduced, allowing users to set the icon used by browsers and smartphones when representing a given site. In Jetpack 3.9.2, the site icon was added as a potential fallback when choosing an image for social networks like Facebook.
Today at PressNomics 4, Josh Strebel shared an interview he did with Alex King back in September, just ten days before Alex passed following a long fight with cancer.
It’s both incredible to me, and simultaneously unsurprising, that Alex took the time to record this interview given how sick he was at the time–one final contribution to a community he was so important to and engaged with.
Many years ago, I used the HeadSpace2 plugin to manage SEO on a now-dormant site. I’ve left the plugin installed there to retain the data it holds, but recently decided to explore alternatives.
For the three visitors I attract in a month, I’ve had an outsized interest in making this the most secure WordPress site that I can. My focus of late has been primarily on the security-related headers I can set. In particular, ensuring that HSTS and HPKP were present on all requests became a priority.
A few weeks ago, I noticed that certain assets served from my CDN host lacked the Strict Transport Security headers (HSTS) I’d expected. To the best of my knowledge, I’d configured nginx to set these headers on every request.