WordPress Adds Emoji 13.1 Support

In WordPress 5.8, currently in beta and launching for everyone in July, adds support for Emoji 13.1!

As a quick refresher, WordPress has a built-in emoji support detection system in place that checks to see if your site visitor’s browser can support the latest emoji. If they are not able to see the latest emoji, we will automatically replace emoji characters with emoji images.

This allows authors to use any emoji character they wish and ensure that everyone can see them. Without this, site visitors would see those little boxes with an X or instead of seeing a transformed emoji (like an female astronaut, they would see an astronaut with the female symbol next to it… which isn’t great).

What’s in Emoji 13.1? Check out Emojipedia’s rundown of 13.1’s changes for Twemoji—the Twitter emoji design that we use within WordPress.

Some of the hightlights include being able to express bending a broken heart ❤️‍🩹 or show off your heart is aflame ❤️‍🔥 (also perfect for talking about the Sacred Heart, heh). Want to stay a little hidden in the clouds? Me too. 😶‍🌫️

The bearded person emoji now supports a whole range of gender, skin tone, and hair color. Lastly, the couple and kiss combination emoji have a wide range of options now with various skin tones, genders. Before, there were pretty limited options so you couldn’t really express a couple or kiss that matched you unless you happened to fit one of existing combinations. Now, I can send my wife an emoji that better displays us 👩🏽‍❤️‍👨🏻

WordPress’ goal is to enable you to express yourself however you wish, including through emoji without making you feel lightheaded 😵‍💫!

Automatic Updates in WordPress

This week, the topic of automatic updates in WordPress came up. Here’s a bit of a guide on how it all works, how to disable them, and so forth.

Automatic Updates?

First, “automatic” is a very problematic term given the history, so let’s define terms a bit.

In The Beginning…

When WordPress first came out, whenever you wanted to update to the next version of things, you had to manually download and install the update. This changed in WordPress 2.5 (March 2008) with, what was often referred to as, “automatic updates”. This post isn’t talking about these “one-click updates“.

The Humanless Era Begins For Minor Updates & Developers

The era of “background updates“, those updates that are possible without human interaction, began in WordPress 3.7.

WordPress 3.7 (October 2013) was billed as a very developer-heavy release. There weren’t really any splashy features—background updates, improved password meter, improved search. Under the hood, this release laid the groundwork for a ton of stuff.

The most visible impact of 3.7, at the time, in regards to updates was that now WordPress could update itself in the background and would start doing so for maintenance releases (e.g. 3.7 to 3.7.1 to 3.7.2).

In addition to the ability to update Core itself, the underlying guts for themes or plugins to background update were in place. There was no user interface for this—had to add a bit of code to activate.

The guts that allowed for plugin background updates also allowed for “background security updates” or “forced updates”. More on this in a bit.

Humanless Reaches The Masses

By WordPress 5.6 (December 2020), the underlying guts had seen various improvements over the years and now the ability to modify background updates expanded to everyone.

WordPress 5.6 included the user interface to enable site owners to indicate individual plugins could background update or even WordPress itself with major updates.

Generally speaking, this was adding UI to the existing framework, but the actual process is the same.

Summary of Terms

In short, “automatic” updates could refer a few different things:

  • One-Click Updates, with the wp-admin ability to upgrade, added in WP 2.5.
  • Background Updates added in WP 3.7 with expanded UI added in 5.6.
  • Forced Updates also added in 3.7 with no UI.

A Special Note About Forced Updates

What Is A Forced Update?

Forced Updates aren’t really a different thing than Background Updates. When a site checks for updates, it informs the API of the current version, the version of WordPress, and the version of PHP running on the site. The API then responds with what upgrade that site is being offered. If you’re running a modern version of WP and PHP, usually, it is the latest stable version of the plugin.

If you’re running an older version of PHP or WordPress that is older than the minimum supported version for the latest version of the plugin, it won’t offer you an upgrade at all.

For a Forced Update, the API responds a little differently. First, if you’re on an older version, it will only offer you the immediate patch for the security issue. For example, if Cool Plugin 2.0 is the latest version and you’re running Cool Plugin 1.5, the API will see that and respond with Cool Plugin 1.5.1 for your update (as opposed to 2.0) and mark it as a forced update (or autoupdate in the response). The overall mechanism is the same for regular upgrade offerings and a forced upgrade offering.

How Does An Update Become Forced?

Jetpack is one of the most installed plugin in the WordPress ecosystem and, as such, anytime there is a potential security issue discovered, it’s a Big Deal™ by way of the number of sites potentially impacted. We take that responsibility seriously, so we’ve had three “Forced Updates” since this became possible in 2013.

The process has been we discover an issue. This is often from our internal security folks trying to find issues or from a responsible person disclosing to us via our HackerOne bounty program (yes, we pay people who find security issues and report them directly to us).

Once we validate the proof of concept and confirm there is an issue, we determine the severity and the scope of the issue. How bad is it and how many people could it impact? At the same time, we determine the smallest possible solution to mitigate the issue. Generally, this is not the time to do a whole-hog refactor or something.

With all that information in place, if we think the issue is potentially serious, we will contact the WordPress Plugins Team. These folks, none of whom work for Automattic, can help advise us on next steps.

If they concur the issue is serious, they advise on if the fix should be backported to older versions or not. In such a case, there are some very important and firm guidelines:

  • To the extent feasible, we need to fix everyone possible. If the problem exists in five versions (e.g. 1.1, 1.2, 1.3, 1.4, 1.5), then we should provide patched versions for each of those versions.
  • The updated versions can only contain the smallest change possible to mitigate the issue. This is not a time to fix other bugs, add features, or anything. It is exclusively to fix the issue discussed.

After that, we go back and fix everything and prepare releases.

When everything is ready, we check-in the new versions to the plugins repo and the WordPress Meta Team updates the API to give the modified response for these versions.

Disclaimer: I suppose I could be considered on the Meta team since I help maintain parts of WordPress.org. I don’t have the authorization nor the access rights to modify the API.

How To Control These Updates?

One-Click Updates

If you want to really lock down your site and disallow, basically, everything, you can do that with a single line in your wp-config.php file:

define( 'DISALLOW_FILE_MODS', true );

This will disable all updates—background, one-click, or manual. You will not be able to install new plugins or themes. It’ll actually disable the Upgrader completely to the point that you won’t be able to see pending upgrades.

I do not suggest using this unless you have extremely specific needs and have the resources to ensure your site is up to date manually.

A common use of this, though, is to mark your production site with DISALLOW_FILE_MODS while running a staging site without it. You can make changes to the staging site, then deploy them to production when you’re ready.

Background Updates

There are a few different ways to control Background Updates.

Via UI

Via the wp-admin user interface, you can control WordPress Core updates via the Dashboard->Updates page.

For plugins, visit Plugins->Installed Plugins and select “Enable auto-updates” option for each individual plugin you’d like to background update.

For themes, visit Appearance->Themes, then choose “Theme Details” for each theme you’d like to background update. On the details page that opens, you’ll see an option to enable updates under the title and author.

The UI options have no effect on Forced Updates.

The UI options have no effect on Forced Updates. You can think of this as replacing the need for One-Click Updates.

Via Code

The DISALLOW_FILE_MODS constant mentioned above will still work, but you have a lot more granular control too.

For the sake of being complete, if your server’s user does not have permission to access the file system or you’re on a version-controlled setup, background updates won’t work. For Core updates, you’ll get an e-mail about them.

SegmentMethodPossible ValuesNotes
AllConstant: AUTOMATIC_UPDATER_DISABLEDbooleanFalse also disables update notification e-mails for Core.
AllFilter:
automatic_updater_disabled
boolean

Default: Value of AUTOMATIC_UPDATER_DISABLED
False will disable notifications too. Overrides the constant above. The below values do not override this. This would still allow UI updates without allowing any background updates. See below the table, though, for an alternative.
CoreConstant: WP_AUTO_UPDATE_COREfalse (bool) – No background updates for Core
minor – Only security/maintenance updates for Core
true (bool) or beta, rc, development, branch-development – All updates allowed.
Filters can still override this behavior.
CoreFilter: allow_dev_auto_core_updatesboolean

Default: False unless WP_AUTO_UPDATE_CORE is set to allow all updates.
If the site is currently on a dev version (alpha/beta), should it background update Core.

3.7-alpha-2500->3.7-alpha-25678->3.7-beta1, etc.
CoreFilter:
allow_minor_auto_core_updates
boolean

Default: True unless WP_AUTO_UPDATE_CORE is false.
3.7.0->3.7.1->3.7.2
CoreFilter:
allow_major_auto_core_updates
boolean

Default: False, unless WP_AUTO_UPDATE is set to allow all updates.
3.7.0->3.8.0->3.9.1
ThemesFilter:
themes_auto_updates_enabled
boolean

Default: Generally true, unless the automatic_updater_disabled constant/filter are false.
This is more the themes system being enabled. This doesn’t mean it will upgrade individual plugins. This can be overridden by Forced Updates.
PluginsFilter:
plugins_auto_updates_enabled
boolean

Default: Default: Generally true, unless the automatic_updater_disabled constant/filter are false.
This is more the plugins system being enabled. This doesn’t mean it will upgrade individual plugins. This can be overridden by Forced Updates.
Plugins/ThemesFilters against the auto_update_themes and auto_update_plugins optionsIndividual plugin and theme background update settings are stored in these options. If you wanted a confusing experience, you could filter these options. I wouldn’t personally.
This can be overridden by Forced Updates.
———–Important Note!Everything above allowing a background update can be overridden by the the API to disable a background update.I’m not sure how/if this has been used, but it is possible. I would guess this is a way that WordPress.org can throttle the rate of downloads by marking something as disable_autoupdate for a percentage of sites. Just a guess.
AllFilters:
auto_update_core
auto_update_plugin
auto_update_theme
auto_update_translation
booleanThese filters also pass $item which is the upgrade object response from the API. You can use these filters to more selectively control updates via code. Want to allow only plugins whose slug begins with a, this is your filter. Or a more realistic setup would be to allow background updates only from a select allow list.

As you can see, there is a lot of flexibility for site owners who wish to have a very specific background update solution. While Forced Updates are given a lot of preference, you can still disable them via the auto_update_{$type} filters.

One idea, if you’re concerned about an autoupdate, but want to be aware, is to hook into those filters and if $item->autoupdate is true, send you an e-mail, before returning false. That way you’d know you’re missing the update but you can completely control when your site’s code is modified.

When do these updates happen?

Generally, every 12 hours. There are wp_update_plugins, wp_version_check and wp_update_themes cron events that are set to run twice daily. There’s not a set time—on every page load, WordPress checks to see if the check is scheduled. If it isn’t, it schedules it for immediately and then every 12 hours thereafter.

One more note about Jetpack

While I’m here, before Core added the UI for background updates, Jetpack had one that was accessible via WordPress.com for connected sites. For while there, this system did not use the same filters as above. With WordPress 5.6 bring a renewed focus to background updates, we modified our system to use the same options and filters as Core’s. The above should all still work the same for any autoupdates selected via the WordPress.com interface for connected Jetpack sites.

I hope this help explains things a bit more with a bit more specificity than a lot of the conversations around “automatic updates” .

Support Rotation

At Automattic, after being hired, your first two weeks on the job is working with our Happiness teams to directly support customers. For engineers or designers, it gives you a taste of who we’re building this for. For other roles, it is a reminder that we’re all contributing toward the success of our customers in their mission to publish, to sell, to teach, or whathaveyou.

After that, we take a week a year in some form—a fully week, five days spread out over the year, whatever works for your team—to go back to Happiness to work with our customers directly again.

I spent my first five years at Automattic within Happiness so I had a lot of interaction directly with our customers, but after swimming over to the engineering side 100%, it is time again for my annual support rotation.

For a lot of non-Happiness folks, the idea of jumping back into direct support can be a bit scary. Happiness folks have to know everything about the product. Engineers just need to know their portion and lightly keep up with what other teams are doing. Customers come up with the most bizarre issues sometimes and you can’t just say “wow, that’s messed up.”

In actuality, the Happiness teams at Automattic are extremely supportive folks to their non-Happiness teammates who join them during the rotations. Happiness Engineers are helpful and supportive to the folks contacting us, but internally, they are also some of the most selfless, helpful folks in the company.

If you’re a customer of WordPress.com or Jetpack, feel free to reach out and say hello. We usually hear from the folks having problems, but if you want to write in just to say everything is working fine, that’s okay too. 😀

Genesis eNews Extended 2.2

Today, I shipped a new version of Genesis eNews Extended. Beyond some minor invisible stuff—bringing everything up to modern PHPCS rules—the latest version brings in a new set of classes that theme designers can use to more surgically modify the design of their subscriptions forms.

Suggested and implemented by Mike Hemberger, also known as JiveDig, this version adds a number of classes for easier theming:

  • enews-form, a class on the top-level form element.
  • enews-fname, a class on the first name form field.
  • enews-lname, a class on the last name form field.
  • enews-email, a class on the e-mail address form field.
  • enews-submit, a class on the submit button.

The form has always been wrapped in a div element with the enews class. This version also adds a new enews-{$field_count}-field(s) class to that div so you can apply different rules if there are 1 field—for only the e-mail address—or 2 or 3 if there are one or two name fields.

As part of my commitment to backward-compatibility, no classes were removed or changed—only additions—so this update is safe for existing sites without any need to make changes.

A major thanks to Mike for using eNews Extended, seeing room for improvement, and then going to the next level to implement it. If you have suggestions for improvements or would like to submit patches, check out Genesis eNews Extended on GitHub.

1,000,000 Blocked Attempts

Today, my site hit a milestone. Jetpack Protect has blocked 1,000,000 malicious login attempts.

Typically, when using the wrong user name and password on the site, those credentials are sent to the site itself and you’ll see the site’s response that it was a bad password. Since a bunch of bots could try every combination, it could eventually guess your password.

Jetpack Protect monitors who is submitting failed login attempts on every site using Jetpack Protect. When it sees a single actor failing a number of login attempts—on one site or multiple sites—it will block that person from attempting to login on any site using Jetpack Protect.

Emoji 13 Coming to WordPress

As of r48048-core, WordPress will polyfill Emoi 13 glyphs on devices that do not support them.

What this means is whether or not your viewer’s device is able to display a 🫀 or not, you can include one on your WordPress site and it’ll display for them.

You have stuff to do — like feed your kids 👨‍🍼 or tend to a plant 🪴 or making face masks 🪡 — so no need to think about whether or not someone will see an emoji or a blank box on your site.

It isn’t magic 🪄. WordPress has a small bit of JavaScript that will check if your browser will render one of the latest emoji and see if it is what we’d expect or not. If not, it’ll load a script to replace emoji characters with graphical images. If it does support the latest emoji standard, it’ll do nothing and let the viewer’s operating system display it like normal.

This will roll out to production as part of the WordPress 5.5, expected to ship in August.