Things That Matter Most

Things That Matter Most

Release Freeze is Coming

by

I’d finished my turkey. Finished my pie. Then retreated to the other room with my laptop to finish my project.

Years ago while I was still freelancing, I fell behind on a project and had to lug my laptop along with me to the family reunion/feast on Thanksgiving. This meant I had to forgo games with my cousins, football in the yard, and catching up with relatives so I could work. It meant I also got paid, but I wasn’t billing anywhere near enough to justify abandoning family traditions for my computer.

Never. Work. During. Holidays.

WordPress 5.0

The next version of WordPress is dropping sometime soon. It was originally scheduled for earlier this week, but has been bumped to (maybe?) sometime next week. That’s great. It’s shaping up to be a great release, but there’s still work to be done.

As much as I love to ship code, it needs to be “done” before it goes out the door.

Given the rapid pace at which new bugs are being discovered, triaged, and patched, I’m not convinced we’re ready for a release. Let alone a release candidate. This is despite the latest release candidate having been scheduled yesterday … with several open bugs still tied to the official 5.0 release deadline.

For the record: a release candidate is intended to be a version of the software you think is done done and ready for final review before the release heads out the door. WordPress 5.0 is not yet in a “finished” state. A release candidate should be releasable and we’re not there yet.

At the time of this writing, there were still 20 issues on the WordPress 5.0 milestone despite the release candidate having shipped …

We’re still chasing after an arbitrary deadline, and while we won’t be shipping things during the Thanksgiving holiday in the US, we’ll still likely be shipping during one of the largest travel seasons. Bumping things back to December is no better as we start treading on various other major holidays – Hanukkah is Dec 2-10, Christmas on the 25th, New Years … and I’m likely forgetting others.

WordPress 5.0 is going to be great.

It should still be held back until January at the earliest.

Release Freeze

To that end, I’m going to step up and set an example.

While I will be working during December and, more than likely, writing code for new features and projects I will not ship any new feature or product releases in December.

This will give me time to focus on family and treat hobby coding as what it is – a hobby. It will help me balance “work” and life and regroup at the top of the new year with fun projects and releases. It also means anyone who relies on my code won’t have to rush to report bugs or patch conflicts or do anything to support my release until they’re also done with a family break and well established into the new year.

This release freeze will include not adding any new release hashes to DGXPCO.

If you’re using my plugin to ensure any updates to WordPress are vetted and cryptographically signed, my commitment to waiting until January to release an update means, regardless of when WordPress 5.0 drops, your site won’t see an update until January.

I’ll likely be taking some time during December to queue up a bunch of new stuff, so rest assured that work will continue and new releases will ship. But know that nothing I do or release will result in your having to lug your computer along to family events.

I learned from that mistake. Let’s work together to keep anyone else from having to live through it as well.

Introducing Secure Updates for WordPress

by

Skip to the announcement …

One of the earliest conversations I had in the WordPress community almost saw me immediately leave and never return. I’d released some code in a few plugins and was just finally starting to get ramped up as a (very sub-par) developer. I hung around on IRC, subscribed to the various mailing lists, and tried my hardest to learn, improve, and contribute. Then someone pointed out that I’d never internationalized my plugins. Then they proceeded to go on a rant about how any developer who didn’t internationalize their UI was doing a disservice to the community and was betraying their personal bias against and hatred towards non-English speakers. I was horrified. I came to the development world from marketing. I used Windows. I was very comfortable with graphical (often skeuomorphic) interfaces and could work my way around things easily with a mouse. I didn’t understand the command line. I barely understood code. It took me months (and several misfires) just to learn enough Subversion to get my plugins out in the first place. All of the tools for internationalizing a plugin were, at the time, heavy into a command line that I didn’t understand and couldn’t use. I took a break and, ironically, this experience is what started me blogging. My break let me get some distance and gave me the chance to connect with other developers who did understand the command line tools. They taught me things I didn’t know and I came back a much stronger dev. One of my most popular blog posts today is an old introduction I wrote for developers who wanted to use GUI tools to publish a WordPress plugin. Honestly, though, I wrote the walk through more to remind myself how to do things than anyone else … and that’s how I got started with most of my blogging work. A topic I’ve focused on more recently has been cryptography. More specifically, using cryptographic tools to ensure the integrity of various packages and messages. It’s a heady topic, and a lot of the tools available for end users are painfully focused on power users who fully understand command line utilities. I want to change this.

Code Signing

There’s been a lot of talk about the security of the WordPress updater. Primarily, the updater checks the MD5 hash of a package’s contents before proceeding to ensure its integrity, but that’s the only test it runs. Consider what might happen if a malicious party were able to somehow breach the WordPress.org update server and present their own download package. This could potentially inject malicious code onto more than a quarter of the Internet all at once! Considering such a breach has happened with a few plugins in the past, it’s not outside the realm of possibility. Now imagine if a hacker were able to drop themselves somehow between your server and the WordPress.org update system. Such an attacker could impersonate the updater and serve you whatever package they want. Your system wouldn’t know the difference. In the middle of last year, I said I was working on a solution to bring formal code signing to WordPress. I held off for a while because it looked like the WordPress community might bring this feature to core. That didn’t happen. So today, I’m proud to announce the release of DGXPCO: Digital Guarantees for eXplicitly Permitted Core Operations. This plugin integrates directly with the WordPress core updater and requires that any core package have a valid signature in order for installation. For the moment, I am personally signing the contents of every core package distribution and maintaining the collection of signatures in a separate repository that I serve through a secure CDN powered by Amazon Web Services. Every WordPress release includes both the core download fornew installations as well as “partial” upgrade packages for anyone coming from an older install. I’m signing all of these and keeping a record in one spot so that everything from new installs to partial minor updates to major updates can benefit from the added security of checking a signature. The signatures are leverage an Ed25519 public/private keypair and Libsodium to sign the files’ contents. I keep the private key offline, but have published the public key so everyone can keep an eye on things. This key will not change, and if anything is signed by a different key, you can be sure something is amiss. That public key, encoded in Hex, is 5d4c696e571307b4a47626ae0bf9a7a229403c46657b4a9e832fee47e253bc5b. Every commit to the release hashes repository is also signed with my personal PGP key so you can verify that I’m the one who added the new code.

Next Steps

Is this fool-proof? Probably not. It is, however, a huge step forward in terms of WordPress security. There’s quite a bit more we can do, and I want to outline some of my grand plan here. The first release of the plugin checks signatures upon update only, but WordPress will still tell you about an update even if the signature check fails. The next release will not even surface an update unless a signature is available. At the moment, this plugin only secures WordPress core updates. A future release will also secure plugin updates as well, in an opt-in fashion. I’ll start by securing my own plugins as a proof of concept, then allow for other developers to opt-in to the stronger security moving forward. Today, I am the only one allowed to sign release packages. This is OK for the short term, but is not a sustainable model. As I prove out the update system, I’ll also begin adding sets of public keys that are scoped to specific sets of packages. This will, for example, allow me to whitelist a small number of trusted developers to also sign core packages. It might also empower plugin developers to sign their own releases (but not anyone else’s). At the end of the day, I’m looking now for feedback. We don’t have this functionality in WordPress core yet, but DGXPCO is evidence that we can add it. We should add it. So let’s work on the feature together. As I mentioned in my initial post last year, if you want to help with this endeavor, please let me know! If you want to contribute financially,donations are always gladly accepted. This is the first project I’m launching under the name of my new WordPress-related business, Displace Technologies, LLC.

Gutenberg and the Road Ahead

by

I have a confession to make. I really like the new Gutenberg editor for WordPress.

I know, I know. Developers aren't supposed to like massive, intrusive changes like this. As of the time of this writing, the plugin stands with 2.6 stars on the plugin repository – at least 133 of those ratings are 1-star critiques.

Gutenberg suffers not from design aesthetic, but from the high level of distrust the community seems to have for the "new" principles of the editor.

As a writer, though, it's an incredibly slick interface.

As a developer, I can also see the promise behind the block structure for taking over the rest of the WordPress admin. The customizer could easily use the block structure for things like widgets and navigation and content layout. Even settings pages could be updated to leverage blocks for different sections.

Also as a developer, I can see why so many are hesitant to dive in with the new system. It still has a few rough edges, but nothing that's impossible to polish as development moves forward. It's also a massive deviation from the interface we're all used to.

The Problems Ahead

Having worked both as a WordPress freelancer and with a larger WordPress agency team I admit this new editor does give me pause. Several of the systems I've built or worked with feature rich, custom interfaces – all built atop the standard WordPress editor screen.

While I plan to leverage Gutenberg's newer interfaces with any project I build atop WordPress 5.0 or later, this isn't a solution for everyone.

Not that long ago, a friend of mine who works with an established non-profit reached out to me for some WordPress help. The team had hired a developer to build out their site, but they'd since parted ways. Unfortunately, the developer had left a large banner on the front-end of the site pointing out the design was new and soliciting user feedback.

The team wanted to turn off the banner, but didn't know how. They also couldn't ask the original developer to take care of it for them.

My point is that many existing WordPress users are working with platforms built by outside parties or powered by themes and plugins that they cannot update on their own for whatever reason. Switching to the Gutenberg editor for posts (and pages and other CPTs) is going to pull the rug out from under a lot of businesses who've grown to trust our product to build their business.

A Potential Solution

Two roads diverged in a yellow wood,
And sorry I could not travel both
And be one traveler, long I stood
And looked down one as far as I could
To where it bent in the undergrowth

The Road Not Taken, Robert Frost

About four years ago, I suggested that WordPress should fork itself for the sake of updating its PHP requirements and empowering developers to leverage newer features in their code. Several other developers chimed in and supported the idea, but we didn't tread down that path because, honestly, it wasn't a good fit for the project as a whole.

Now, though, everything is different.

Gutenberg is great, but it's not a good fit for the project as a whole. WordPress is not just a blogging platform. It's not just a tool for the creation of prose. It's a rich content management system with support for both prose and media and, thanks to the power of custom post types, anything else a customer might need.

I strongly believe that Gutenberg, and its block-based approach to building webpages is the way of the future. I strongly believe that Gutenberg should be part of WordPress – perhaps not just a part but should take over the WordPress interface entirely.

I just as strongly believe that the broader WordPress community isn't ready for Gutenberg and won't be for quite some time.

For the time being, I propose that WordPress create a "soft fork" of the project. Maintenance, security, and minor feature improvements should continue on a 4.X branch (with a 4.10 release coming next, followed by 4.11, etc). Gutenberg should (and will) be the default editor with WordPress 5.0, but no one necessarily has to upgrade to the 5.X branch until they're ready for it.

This would give developers the time to upgrade their plugins and themes. It would give users the time to familiarize themselves with the newer interface. It would also allow for faster, broader experimentation with the new block-based approach.

Rationale

WordPress' overarching development principle has been to always maintain backwards compatibility. It's one of the reasons why we target PHP 5.2 as a minimum. It's one of the reasons why I can click "upgrade" on an older 3.X site and bring it up to speed with 4.9.1 without anything breaking.

It's one of the primary reasons why WordPress has been so successful as a platform.

Unfortunately, Gutenberg is such a deviation from what we've used in the past that it's all but impossible to maintain backwards compatibility without ugly hacks.

  • Meta boxes, one of the core ways plugins extend the WordPress admin interface, are included in Gutenberg by way of iFrames. It's a buggy implementation that has many developers arguing over best practices and approach.
  • The page editor is missing the concept of "page templates" entirely. Up til now, templates were the key way site owners customized the appearance of their content – this doesn't fit within a Gutenberg model. Leveraging a page template requires deactivating the plugin, selecting the template, then re-activating the plugin to build content.
  • Blocks are added to post content using HTML comment tags – the content isn't actually broken up into separate blocks and the blocks themselves don't function as standalone objects. This reminds me too much of media within WordPress, where media items are inserted by way of HTML tags into content rather than as references back to the original media item.

Gutenberg reimagines and reinvents the way WordPress is built. This is a good thing! But we shouldn't be shoehorning the newer features into older structures because we're afraid of breaking backwards compatibility on the back-end. Gutenberg already sacrifices backwards compatibility on the front-end!

A soft fork of WordPress would allow us to:

  • Update all the JavaScript used within the admin interface
  • Update the database to better house blocks as objects that can be reused and references across content
  • Reimagine the media library as a catalog of reusable media blocks
  • Update other components of the WordPress admin to leverage blocks (a "settings" block perhaps?)

All of this would be possible without breaking the functionality of highly customized sites if they remained on the 4.X branch. They'd still get security updates, maybe performance updates, and possibly even minor, non-Gutenberg-related feature updates moving forward.

Maintaining both the 4.X and 5.X branches in parallel would also provide developers (both on the larger agency and smaller freelance side) the ability to seamlessly upgrade from a legacy to a Gutenberg environment.

Soft-forking isn't unheard of. Microsoft followed this pattern when they replaced Internet Explorer with IE Edge. Firefox did it with the new Firefox Quantum.

Gutenberg is the road ahead for WordPress. It's a road I want us to take. But it's a road that not everyone will be willing to tread. We should respect that and plan a way to help those who can't follow to keep up.

World Domination through WordPress Security

by

WordPress powers over a quarter of the Internet. That’s quite a statement for a platform that began its life as a fork of a blogging engine. It’s also quite refreshing since WordPress is the reason I learned to write code in the first place.

One of the reasons WordPress is so popular is because it’s so easy. It’s easy to use as a writer. It’s easy to manage as a site administrator. It’s easy to code as a developer. This learning curve associated with WordPress is relatively flat – many devs and users can dive right in and get something functional from day 1 with little to no outside help.

Another reason for WordPress’ popularity is its long memory. WordPress has been around for over a decade, and the core development team has always prioritized backwards compatibility with the platform. Users of older versions of the software can upgrade to the latest version with, often, no loss in functionality. 1

Unfortunately, this long tenure also means that many in the community have a long memory of WordPress as well. They remember the days before plugins. The days before CSRF tokens were in common use throughout the codebase. The days when everyone just assumed WordPress was insecure by default.

Is WordPress Insecure?

Along a similar vein, WordPress is still very insecure.

At conferences I often remind people that the core code that powers WordPress is, in itself, vetted, secure, and reliable. The insecurities in code arise when administrators add a custom theme or start installing unverified third-party plugins. Any time you add someone else’s code to the system, you add a potential inroad for code-level vulnerabilities.

That being said, there are also specific platform-level risks 2 that affect the system.

Among the various risks presented by WordPress, there are four in particular that I see most often in conversation:

Insecure Logins

A few versions back, WordPress removed the default “admin” username and started enforcing stronger passwords for authentication. These are both good changes to make, but don’t necessarily take things far enough. WordPress does not ship with a multi-factor authentication system. The core team has been working to build one; unfortunately the current solution bundles so many potential options as to paralyze site administrators. They can choose anything from FIDO U2F to Google Authenticator to an email-based system.

It’s a good start, and will definitely help secure WordPress logins, but it’s bringing too many options to the table.

Insecure Emails

If you forget your WordPress password, you can easily request a reset link from your site by providing either your username or your email address. The downside with this functionality is that anyone with access to your inbox can then use this link to reset your account.

You use a different password for Gmail and for your blog? Great! Unless someone steals your Gmail password … then they can also steal access to your WordPress account.

Insecure Front-ends

Many WordPress sites are rocking HTTPS thanks to Let’s Encrypt and the awesome integrations managed WordPress hosts are forming with the project. Sadly, just as many sites are failing to prevent mixed content or are trusting the scripts on their site to CDNs or other remote providers who may or may not be injecting malicious code. The sheer number of people who recommend using a CDN-hosted jQuery versus the version that ships with WordPress 3 shows how often developers are lead to trust an outside party to load executable code onto their site.

Insecure Upgrades

WordPress ships all updates (core, themes, and plugins) from a central server, but does nothing to ensure the integrity of the code downloaded. On the one hand, if the central WordPress.org server distributing updates were ever breached, more than a quarter of the Internet would be vulnerable to malicious software.

On the other hand, if your server is behind any sort of proxy and that proxy is attacked, whether or not WordPress.org is shipping rock-solid code becomes a moot point. There’s still no way for you to verify the proxy didn’t modify the payload before you received it. 4

Changing the Conversation

I’m tired of people lamenting the state of security with WordPress and doing nothing to address it. To be certain, there have been some significant efforts to address these security risks, but they either haven’t landed or have been de-prioritized to the point of obscurity. That’s a major disappointment, but I’m not going to just sit back and do nothing.

Instead, I’m going to open source the solutions I’m personally building to help fix the holes and turn the conversation around.

Insecure Logins

I continuously beta test various login security plugins to see how they can help average users stay more secure. The Two Factor plugin the core team is kicking around is great for people who know what they’re doing and want multiple options for authentication. I like it because I can use it with a Yubikey. I don’t like it because most users don’t even know what a Yubikey is.

I started with that plugin as a core, but reworked it to focus just on using a time-based OTP app and released a simplified fork named Dovedi. This plugin uses a lot of the same techniques, but is tested to work with everything from Google Authenticator on Android to Windows Authenticator on Windows Phone. 5 I wanted to target technology many users already have – even if they’re not already using an Authenticator app, it’s something portable enough they can use it with other systems as well.

Dovedi was my first step in helping to make WordPress secure.

Insecure Emails

I’ve written extensively elsewhere on the need for and ease of configuring encrypted email systems. I use both GPG and S/MIME myself to ensure messages are signed whenever I send them and encrypted when they need to be. Once you have an email client capable of receiving and decrypting messages, the next trick is getting WordPress to send encrypted messages.

This past weekend, I released a new plugin called Secure Messaging that uses GPG to automatically encrypt password reset emails before they’re sent to a user for reclaiming their account. Once you’ve given WordPress your GPG public key, no one but you (with your private key) can ever steal your account, even if they somehow manage to hack your inbox.

Insecure Front-Ends

One of the coolest tools I’ve seen lately is Mozilla’s Observatory. This tool scans your site for compliance with many different security features:

  • A content security policy that whitelists the domains allowed to serve scripts, images, fonts, and iFrames
  • Whether or not your site properly implements HTTPS and if it strictly prevents TLS downgrade
  • Whether or not your site implements sub-resource integrity for remote scripts
  • If your site is protecting against cross-site scripting or frame-injection attacks
  • And so on

By default, it’s difficult to get WordPress to score well under these tests. 6 I’m collaborating with a couple of other developers to flesh out a plugin that helps configure a WordPress site to score much better according to these scans.

Remember, a higher score means a more secure front-end and a safer experience for your customers.

Insecure Upgrades

It doesn’t look like the core team will be cryptographically signing updates or payloads any time soon. That being said, I still want to ensure sites I interact with are receiving vetted, secure code. To that end, I will be publishing a list of signed hashes for core files (and a handful of plugins and themes) myself.

I will also be writing a plugin to force the WordPress updater to verify these hashes before completing the upload.

This obviously won’t fix a hacked site, and it won’t protect against all possible avenues of attack. However, it will help ensure that critical code being download through an automated update (via a proxy, for example) is guaranteed by me to be free from outside manipulation.

Next Step: Profit?

All of this is a labor of love. The tools above are, like almost everything else I do, freely available as open source. Where possible, I license under the terms of the MIT license (but use the GPL on tools like Dovedi, which are forked from others). All of the above constitute a fair amount of work on my part, but my goal is to provide these tools to the community and help change the conversation about WordPress and core security.

If you want to help, feel free to reach out to me on Twitter. If you want to contribute financially, donations are always gladly accepted.

The best way to help, though, is to raise awareness and offer feedback. Where are the rough edges in WordPress or in the systems that secure it? What could be done to make the “secure” way to do something the “easiest” way?

Notes:

  1. I personally upgraded a WordPress 2.3 site to 4.0 once. For context, version 2.3 came out 7 years before version 4.0. Still, the upgrade went flawlessly with zero lost content. The old theme even still worked on the newer platform! ↩
  2. I use the term “risk” instead of vulnerability here because each of these potential issues requires specific expertise to exploit. They’re also easy to defend against in a rigorous system. They are still risks, though, because it’s even easier to fall prey to a hack merely by being lazy or misreading a configuration tutorial. ↩
  3. These two are not equivalent. WordPress enables “no conflict mode” by default by adding a line to their own script! ↩
  4. For all the talk about why update signing isn’t a priority, the risk of a hacked proxy is significant to anyone running on a managed host, in an enterprise environment, or retrieving data through any sort of cached proxy (or external update system like Packagist). ↩
  5. The hash spec is implemented roughly the same for both, but Windows requires a longer key than Google does. I needed to increase the byte length of device secrets to gain universal compatibility. ↩
  6. My “dev journal” on WordPress.com, for example, only scores a D where an A+ is possible. If WordPress.com is the “gold standard” for WordPress hosting, we’ve obviously got a lot of work left to do. This site, hosted on WP Engine at the time of this writing, does even worse with an F. ↩

WordPress.com is not WordPress

by

A story I enjoy retelling is how a friend of mine tricked me into using WordPress. At the time, I was working with him on a career mentorship project. He’d written a book that I was publishing, and we wanted to add a premium video series to go along with it.

We just needed a way to host those videos online.

I was still very new to web development. I had built my own portfolio site in PHP, having learned PHP through a series of emails from a good friend in Arizona. My business partner was excited about the prospect of a dynamic website and turned me loose to find the right tool.

I settled on … not WordPress.

A few days later, he invited me to lunch downtown. Having no real job and, since our project wouldn’t be launched or profitable for a few months, I had no money and was thrilled at the thought of a free lunch. I parked downtown and met at an obscure office building … where the first ever WordCamp Portland was being held.

Spending the day with a bunch of WordPress geeks was fun and excited me about the tool. I switched gears and rebuilt our site on WordPress. I rebuilt my own site on WordPress. I started publishing plugins and a few themes for WordPress. I started contributing code back to WordPress Core.

But I still wasn’t a “WordPress professional.” It was just a hobby.

Software as a Profession

I was active enough in the WordPress community that I could start freelancing and actually earning money with my hobby. I never wanted to be a developer, so it was a bit humbling to admit that I was making more money with my hobby than with my real career in business. That said, I was able to use my WordPress freelancing to build a solid resume and get a job.

Writing code in C#.

I still hacked on WordPress as a freelancer in the evenings and on weekends. I still gave my code away for free, having been inspired by meeting Matt Mullenweg and hearing his mantra of “do your best work, give it away for free, and the universe will provide.” Considering his success, I figured it was good advice and followed suit.

I also kept attending WordCamps and worked my way up to speaking at them. Several people asked me why, despite my passion for open source, I wasn’t working with WordPress professionally. The constant questioning, and direct encouragement from certain individuals I highly respect, lead me to apply to Automattic.

Working with WordPress

I applied to … several positions with Automattic over a period of years. I applied to be a code wrangler. A theme wrangler. A happiness engineer. Whatever position I saw open, I threw my resume at. Every time I got back a “thanks, we’ll be in touch” response.

But that was it.

I have never once actually worked for Automattic. In 2012, I was incredibly excited to accept an offer with 10up where I finally got to work with WordPress full time. I spent four years with that team, building some of the best, most complex WordPress installations on the Internet. I also kept up with my habit of evening and weekend work to help polish and improve the platform upon which we built our products.

That’s also when I noticed a troubling trend …

WordPress is not WordPress

I can already feel the backlash brewing, but there are a lot of problems within the WordPress world. Among the worst of them (from a business perspective) is the WordPress name itself.

“WordPress” is a trademark owned by the WordPress Foundation. Because Matt Mullenweg is the founder of WordPress, the WordPress Foundation, and Automattic, the latter has perpetual and unique permission to use the trademark in ways prohibited to the rest of us. No one else is allowed to:

  • Call their product “WordPress ____.” It must be “___ for WordPress” or something similar that explicitly calls it out as an extension.
  • Use WordPress in their domain name.
  • Use the WordPress name, logo, or in any way suggest an affiliation with a non-GPL licensed work.

There are other, implied restrictions that have come up over the years. Mostly they’re present when someone violates an unspoken rule and is in some way punished for it.

One of the consequences of all of the above: Automattic directly and financially benefits from the WordPress name because their flagship product, WordPress.com, is so often confused with it. This is an issue that’s come up time and again, but which Automattic does nothing to combat. In fact, they often encourage it!

It cannot be said enough: WordPress.com and Automattic are not the same thing as WordPress.

The other day, I tweeted my frustration about the ongoing confusion bleeding its way into (and being encouraged by Automattic) radio commercials for the WordPress.com product. A few people challenged me on that, some even going as far as to say it was a good thing. I disagree.

As a volunteer contributor to WordPress, watching a for-profit company benefit directly from my unpaid work is infuriating. Said more eloquently:

The people that work on WordPress put their energy and passion into the project. It’s demoralizing to hear the project referenced as something made by a company you have nothing to do with. (WordPress versus Automattic)

The last time I engaged in this debate was over the mobile apps for WordPress. Again, due to trademark issues and the fact that a business needs to “own” the apps in both the Android and iOS stores, the WordPress mobile apps are listed as being “by Automattic.”

As a past contributor to both, I bristle at the thought of a company with whom I have no affiliation putting their name on my work. As I said at the time, I would have no problems with these apps being “by the WordPress Foundation” or carrying some other affiliation stating they’re community projects and not Automattic products.

I have no problem with Automattic building their business and promoting WordPress.com as a product. It’s solid and solves real needs by consumers.

I have no problem with WordPress.com advertisements on TV or the Radio or elsewhere. They’re great ways for Automattic to build recognition of their product and encourage new signups.

I do have a problem with advertisements conflating WordPress and WordPress.com by subtly suggesting that the “27% of the Internet run on WordPress” is due to Automattic or is somehow because of WordPress.com.

I do have a problem with anyone, organization or individual, claiming to respect and value community contributions or open source who directly uses restrictions like trademarks to financially benefit on the otherwise free donations of that community.

Security, Internationalization, and Performance

by

When I began writing code for WordPress projects, I had no idea how to properly internationalize 1 my content, There were a few blog posts at the time that accused developers like me of doing a disservice to our customers.

I took offense at the time, but they had a point.

Internationalization is extraordinarily important for open, distributed systems. It’s a valuable feature of WordPress that helps make the software accessible to millions of non-English-speaking writers around the world. Unfortunately, it’s also a mechanism that’s poorly understood and has been confused with some security features of the software.

Rather than call anyone out for doing something wrong, let me instead explain a common mistake that I have made in the past so you can avoid it in the future.

Security

Anyone working with large computer systems today will explain to you the importance of working with safe versus unsafe data. The data returned by an atomic, deterministic function under your control is safe. Data input by a user or retrieved from a remote data source is unsafe.

Unsafe data must be sanitized before it can be used.

When we’re building WordPress websites, we’re required to take a somewhat pessimistic view of our own data sources. While we make every effort to ensure no nefarious data is ever stored in the database, the fact remains that it’s still not entirely within our control. As a result, we must also escape this data upon output to the web browser.

In WordPress, we use a set of specialized functions to do this:

  • esc_html() for arbitraty data that may contain HTML
  • esc_attr() for HTML attributes
  • esc_url() for URLs
  • esc_textarea() for arbitrary data targeted for entry into a textbox

The downside is that some of these functions look deceptively similar to some other, internationalization-specific, ones.

Internationalization

While there are far more than just two, the two most common translation functions you’ll see in a plugin, theme, or in WordPress itself are __() and _e(). The first is meant to return a translated string while the latter is meant to echo the translated string to the browser.

The hitch is: the list of translated strings available is and should always be considered an untrusted data source. A third party could embed rogue HTML or JavaScript into the translation file, so any translated strings should also be escaped before being otherwise used in markup.

Luckily, WordPress exposes a set of functions to do just that:

  • esc_html_e()
  • esc_html__()
  • esc_attr_e()
  • esc_attr__()

Considering what we know about the escaping functions above and the new translation functions just mentioned, it should be fairly obvious what these are and how they’re meant to be used.

The Problem

Unfortunately, it’s fairly easy to assume that things like esc_html_e() are aliases for things like echo esc_html().

They’re not and should not ever be used as such.

In reality, esc_html_e() is an alias for echo esc_html( __() ). If used to escape and echo arbitrary (not translated) text, it will still pass the content through WordPress’ translation mechanisms. It isn’t quite apparent from the seemingly short function names for these internationalization functions, but translation mechanisms are among the most expensive operations that run in WordPress.

In other words: using a translation function on content not meant to be translated is a massive performance sink for your site.

If you’re using these functions incorrectly, don’t be discouraged. It means you were on the right track and are far ahead of many other developers; you just need to take one more, minor, jump to use the functions correctly.

Notes:

  1. Internationalization (sometimes shortened to I18N) is the practice of marking strings in one language as translatable to other languages and helping to enable the translation. ↩