Categories

Category: Code

Perhaps like many starting out with HTML, myriad aspects of the syntax were confusing, or downright overwhelming. For me, tables were one example of the latter. Despite their prevalence at the time (1995), their structure was something I struggled to understand.

Fortunately, one of the many amazing features of HomeSite was its table editor. The visual interface made it easy to create tables and set various attributes. Toying with that GUI helped me correlate what I saw there with the markup it produced.

That ability to experiment and connect changes to their output was essential for me to become familiar with HTML. With no formal training, meager search engines (Google didn’t yet exist), and documentation beyond my understanding, I had no way to learn but to change things and test those effects.

Thanks to the experimentation that HomeSite afforded me, I learned HTML, began hosting my own sites, and in 1999, encountered PHP. Had I abandoned web development out of frustration with learning the early syntax, there’s no chance I could’ve returned to programming as a career when the recession hit in 2009.

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.

With relatively little difficulty, I’m now running PHP 7 alongside PHP 5.6. PHP 7 was released at the beginning of the month, and WordPress was one of the platforms tested against. Given that I can’t stop tinkering with this server’s configuration, I really had no excuse not to set up PHP 7.

As I’ve started cooking again, I’ve been in need of a way to store the recipes I’m collecting. The last time I made a go of feeding myself, I still had physical cookbooks, but that generally won’t be the case this time around.

Last week, I went a little upgrade-crazy with the VPS that hosts this site. With SPDY 3.1 support in nginx 1.5, I upgraded. I also bumped PHP from 5.4 to 5.5.

The latter change is significant because PHP 5.5 drops support for APC, and I was using APC for both opcode caching at the PHP level and object caching at the WordPress level (thanks to Jaquith’s plugin). Since I’d lost my object cache, I’d also lost my page cache because I was using Batcache. Nice job, Erick.

Almost a year ago, I contributed twosmall changes to Eric Mann’s WordPress Redis Backend plugin. With Redis already running on my VPS for reasons unrelated to WordPress, it seemed an obvious choice over competing persistent caching options.

I receive a lot of interesting questions about the Photon module in Jetpack. Occasionally, users would like to disable Photon for certain requests, such as when a plugin or theme calls one of WordPress’s image functions (wp_get_attachment_image(), wp_get_attachment_image_src(), or anything else that ultimately calls image_downsize()).

While the Photon module does include filters to disable it for each individual image requested (see here and here), there are situations where one may wish to disable Photon regardless of the image being requested, such as when a certain widget retrieves an image from WordPress’s media library.

Doing so is relatively simple, but a bit obfuscated because the Photon module is written as a PHP class. The snippet below demonstrates how to do so, and is made possible because the Photon module is implemented as a singleton.

The code on line 1 should appear immediately before the function call that shouldn’t have Photon applied, and lines 5 and 6 should appear immediately afterwards to ensure that Photon is available for any subsequent calls to image functions.

Note that the Publicize module, which handles automatically sharing your content to your own connected social media accounts, does use shortlinks already; therefore, the code snippet above won’t have any impact on Publicize.

Also, I opted not to make this a plugin in anticipation of Jetpack making the switch to shortlinks at some point.

In recent days, many tech blogs have written about a distributed attack targeting WordPress and other content management systems. This brute-force attack focuses on compromising sites that use the admin user account. The attack is notable for its scale, as many hosts have seen reported degraded performance resulting from it.

There are plugin solutions, such as Limit Login Attempts, that can mitigate the effectiveness of this attack, but I wanted a solution that didn’t let the flood of attempts ever reach my server’s PHP processor. On this approach, there are numerous tutorials that recommend restricting access to wp-login.php and the entire wp-admin directory. This approach is problematic because WordPress’ Ajax endpoint exists within the wp-admin directory, so it must be publicly accessible for many themes and plugins to function properly.

Since this latest attack targets wp-login.php, I opted to place that file behind basic access authentication by modifying my server’s nginx configuration. This is a single-user site, so I don’t need to worry about managing users at both the server and WP levels.

The ~* tells nginx to match all requests for wp-login.php regardless of casing (WP-LOGIN.php, WP-login.php, etc.), and also without regard to the directory the request was made to. I took this approach because my access logs revealed many requests to wp-login.php in directories that didn’t exist, likely the bots’ attempt to uncover all possible locations for the file.

In the above example, PHP_CONFIGURATION is replaced with whatever directives your configuration needs to pass PHP requests to the processor; in my case, I’m using PHP-FPM, and those settings appear there. It is necessary to redeclare these configuration settings within this new location block since the existing declarations won’t be applied to requests handled by this new location block.

Beyond ensuring that the Ajax endpoint is accessible, protecting only wp-login.php also restricts this extra security step to login requests alone. Once I’ve logged in, and for as long as I remain logged in, I’m not prompted to provide the HTTP authentication credentials again. In other words, additional security without too great an annoyance for me.

To be clear, this change constitutes just one element of the login protections employed on my multisite network. The admin user doesn’t exist, I use a very strong password, and I’ve enabled a two-factor authentication plugin.

What are you doing to ensure your WordPress setup isn’t compromised by this latest attack?