Make WordPress Core

Recent Updates Page 2 Toggle Comment Threads | Keyboard Shortcuts

  • Gary Pendergast 11:17 pm on April 2, 2015 Permalink |
    Tags: , , ,   

    OMG EMOJI 😎 

    One of the fun bits of the utf8mb4 upgrade is that we can now store emoji! Once your site is upgraded to utf8mb4, it can natively store any emoji character. There were a couple of problems with that, though:

    • Some browsers don’t know how to render emoji 👎, or they have bugs in their implementation 😢. Notably, Chrome either doesn’t work or has bugs, older versions of IE don’t work, and Firefox has bugs.
    • Not all sites will be able to upgrade to utf8mb4, which means they’ll be unable to save emoji characters that they enter.

    Not being able to use emoji makes everyone a sad panda (😭🐼), so we need to fix this. There are a few moving parts of our emoji support, so lets go through them.

    utf8 backwards compatibility

    If a site can’t be upgraded to utf8mb4, we convert emoji to their HTML-encoded equivalent, and store that, instead. From a UI perspective, post editing works as expected 🎉. Because fields need to be white listed to support this, we don’t allow it everywhere – just post_title, post_content and post_excerpt. We also allow it in the site title and the site description.

    Browser support

    There’s a small compatibility check included on every page, both on the front end, and in the Dashboard. For those interested, this adds 1-4ms (⚡️-fast!) to the page render time – the aim was to keep this as low as possible, to avoid affecting your UX. If you notice a little chunk of compressed JS at the top your HTML, that’s probably it. If you’d like to check out how it works in a more readable format, have a look through wp-emoji-loader.js.

    Email ✉️ and RSS 📯 (There’s no RSS emoji, give me a break.)

    Of course, the JS shim won’t work in email and RSS. So, we replace all emoji with a static PNG version in those cases.

    TinyMCE 📝

    In addition to the browser support JS, there’s a TinyMCE plugin that handles keeping emoji looking good, while you type. It’s pretty magical.

    Taxonomies and URL slugs

    You can totally make taxonomies and URL slugs with emoji in them. Because we love you, and want you to be happy. 😀

    So, that’s about it. If you have any questions about the implementation, drop them in the comments below.


    • Scott Kingsley Clark 11:19 pm on April 2, 2015 Permalink | Log in to Reply

      Does this mean post type names / taxonomy names / option names / meta keys support emoji now?

    • Adam Silverstein 11:24 pm on April 2, 2015 Permalink | Log in to Reply


    • Lara Littlefield 11:38 pm on April 2, 2015 Permalink | Log in to Reply


    • Mustafa Uysal 11:41 pm on April 2, 2015 Permalink | Log in to Reply


    • Stephen Edgar 11:56 pm on April 2, 2015 Permalink | Log in to Reply


    • bravokeyl 12:11 am on April 3, 2015 Permalink | Log in to Reply

      Emoji in URL’s , Cool 1F382

    • Ihor Vorotnov 12:30 am on April 3, 2015 Permalink | Log in to Reply

      omg, will there be a way to prevent upgrading and completely remove this compatibility check and that ‘little chunk of compressed javascript’ which is a thing Google does not tolerate?

      • Gary Pendergast 12:36 am on April 3, 2015 Permalink | Log in to Reply

        There’s a plugin to disable emoji compatibility. It’s currently broken (it’s unhooking the wrong filters), but I assume it’ll be fixed before 4.2 is released.

        which is a thing Google does not tolerate

        Can you please clarify what you mean by that?

        • Ihor Vorotnov 2:53 pm on April 5, 2015 Permalink | Log in to Reply

          Google’s recommendations for faster and better sites include “remove any inline styles and scripts from your html source”. Which is actually a common sense – scripts are scripts, markup is markup. We were fighting for years to remove inline WP gallery styles and now we’ve got inline scripts. Awesome)

          It’s a good thing to include this compatibility in core, but turning emoji support (and adding extra inline script) by default isn’t. Most sites (not blogs) have serious tone of voice and don’t need emoji. Those who want them can turn them on in options or using add_theme_support( ’emoji’ ) for example. That’s how it should be, IMHO, not vice versa.

          • Gary Pendergast 12:16 am on April 6, 2015 Permalink | Log in to Reply

            Google’s recommendations for faster and better sites include “remove any inline styles and scripts from your html source”.

            That is true for large scripts and styles, but not for small scripts.

            For scripts needed for page rendering, Google recommends putting them inline, to avoid extra network requests:

            Scripts that are necessary to render page content can be inlined to avoid extra network requests, however the inlined content needs to be small and must execute quickly to deliver good performance.


            • Julie @Niackery 2:32 pm on April 6, 2015 Permalink

              Hi Gary, thanks very much for answering all the questions here! I’m finding the info very useful. I’m just wondering about the second part of the comment above. Currently my settings are not to convert emoji — so as of 4.2 this setting won’t exist anymore? Emoji will be converted automatically regardless of settings? Or will I have to readjust my settings? I really despise the idea of installing a plugin to configure something I should be able to do in my settings. I sincerely hope WordPress isn’t forcing emoji on every single install. As stated above, a great many sites will not appreciate having emoji turned on automatically, especially without the ability to disable without a plugin. WordPress shouldn’t force the use of a plugin to disable such a frivolous feature (which can’t possibly meet the 80% use requirement). Really hoping I’ve misinterpreted this, so I’m very much looking forward to your reply — cheers!

            • Gary Pendergast 1:32 am on April 7, 2015 Permalink

              This is where the difference between smilies and emojis becomes a little more important. The setting you’re referring to is specifically for converting smilies to images. This setting will continue to exist in WordPress 4.2, but will only apply to smilies.

              Emoji are a different case – they’re text, not images. They’re part of the Unicode standard, and all OSes and browsers are working towards supporting them natively. The problem is that the support is not 100% yet, so the emoji image replacement is all about providing a compatibility layer for those users. As native support is rolled out, the compatibility layer will automatically stop loading the image replacement code.

              While I appreciate that your specific usage may not require emoji support, it’s fairly clear from other platforms (including WordPress.com) that emoji are becoming an important part of communication – a simple way to convey a wide range of emotions in a text format. To take an easy example, look at any business page on Facebook – while the business news posts may not use emoji, you’ll struggle to find a comment thread replying to those posts that don’t contain emoji.

              The important part to remember is that, as of WordPress 4.2, all WordPress sites will support emoji. This is entirely a side effect of our improved Unicode support, and it cannot be disabled (in the same way you cannot disable some of the letters in the alphabet). The compatibility layer is focussed on improving the reading experience for your end users. You can disable that if you really want to, but I think the cases for disabling it are fairly narrow.

            • Julie @Niackery 4:05 pm on April 7, 2015 Permalink

              Thanks very much for that answer, Gary! I continued to read up on emoji some more after leaving that comment and suspected I was misunderstanding the issue. Thanks for clearing it all up — I’m assuming/hoping I’m not the only one who may have been confused about this 😉

              I hope you don’t mind my asking one last question — in Facebook or on my phone, I just click on the image of the emoji I want to use (as opposed to typing the symbols for emoticons, as I understand it). So does this mean that the support added to WordPress will also add buttons to the post editor? How would that work for those using the html editor?

              Thanks again for your help!

            • Gary Pendergast 12:37 am on April 8, 2015 Permalink

              Good news! We wrote a codex page, just to let you know how to use emoji:


              (Summary: On your mobile device, your emoji keyboard will work, both in the WordPress app, and if you visit your Dashboard in your Browser. OS X and Windows 8+ also provide emoji keyboards that you can use.)

            • Julie @Niackery 1:14 pm on April 8, 2015 Permalink

              Oh my goodness! You guys are the best :) Thanks a million!

        • Ihor Vorotnov 2:56 pm on April 5, 2015 Permalink | Log in to Reply

          and, btw, check current page’s url in Chrome on Windows.

          • Gary Pendergast 12:17 am on April 6, 2015 Permalink | Log in to Reply

            Windows 7 and earlier has no native rendering of emoji, so native controls (such as the URL bar) won’t render them correctly. Unfortunately, we don’t have any control over that.

    • marsjaninzmarsa 1:38 am on April 3, 2015 Permalink | Log in to Reply

      Ugh, this article in Feedly (via RSS) looks awful. 😞

    • Primoz Cigler 2:06 am on April 3, 2015 Permalink | Log in to Reply

      Hilarious, never seen the emoji in my URL bar before! 😀

    • Brandon Kraft 2:34 am on April 3, 2015 Permalink | Log in to Reply

      Emoji in URL, while supported per spec and fun, isn’t the greatest experience yet. I have a few notes on it toward the end of http://www.brandonkraft.com/b/2015/03/emoji-wordpress-and-you/

      Now that we support it, I would imagine more folks will sooner than later.

    • Nile Flores 3:14 am on April 3, 2015 Permalink | Log in to Reply

      I’d like to use my own emoji like I did back in the day. I’ve got all these emoticon sets I made that I can choose from. Possible to do this like I could in the past??? For example b2 grins by Alex King became wp grins and you could do this for both post types and comments, and then with a a filter, change the path to the directory of the emoticons you want to use if you wanted to use your own.

      What about like the old days when the comment form on posts, you saw the emoji load and just clicked to add them into your comment?

      • Gary Pendergast 3:40 am on April 3, 2015 Permalink | Log in to Reply

        You can absolutely use a different emoji set!

        As this is based on Twemoji, it uses their naming scheme for the image files. For single character emoji, that looks like “1f4a9.png” (💩). For two character emoji, that looks like “1f1ec-1f1e7.png” (🇬🇧). EmojiOne, for example, uses the same naming scheme, so a plugin to convert emoji to EmojiOne would simple use the “emoji_url” filter to change the location of the emoji images.

        We won’t be doing an emoji selector in core, though. It would be about 400KB of JSON, plus the images – pretty weighty to include on every page. :-)

    • Dave McHale 1:00 pm on April 3, 2015 Permalink | Log in to Reply

      As a chrome user, this does little to excite me. Rectangles in the URL, yay? My email notification about this post was LITTERED with rectangles in Gmail, though most emoji seem to render fine on the page itself. It seems like there are too many rendering support issues for this still… My $0.02

      • Pascal Birchler 5:37 pm on April 3, 2015 Permalink | Log in to Reply

        I use Chrome as well and the emoji in the URL is displayed just fine. And I’m sure Gmail supports emojis just fine too and the rectangles in the email were caused by the Jetpack email subscription.

      • Gary Pendergast 10:37 pm on April 3, 2015 Permalink | Log in to Reply

        Unfortunately, we can’t do anything about Chrome’s URL bar – that only works where the OS has native support for emoji.

        The email problem will be fixed next week: Jetpack’s email subscriptions go through WordPress.com, which I haven’t rolled full emoji support out to, yet. It’s on my list. 😎

    • Chris Van Patten 10:18 am on April 5, 2015 Permalink | Log in to Reply

      I noticed that in Chrome 42.0.2311.68 beta on OS X, the script still kicks in and replaces the emoji even though this version of Chrome fully supports emoji. There’s a noticeable flash as the system-standard emoji get replaced with the Twemoji variants.

      Is that intentional? I thought the aim was for the script to detect if the browser already supports emoji and only kick in if it doesn’t.

      • Gary Pendergast 10:24 am on April 5, 2015 Permalink | Log in to Reply

        This is intentional. Chrome OS X doesn’t render colour emoji if the font weight of the element they’re in is greater than 500 (ie, anything bolder than normal). So, rather than have invisible emoji under some circumstances, we’re replacing all emoji on the page. Once Chrome releases a version that does render emoji in bold elements, the script will automatically stop loading Twemoji.

        For reference, here’s the Chrome ticket for this bug: https://code.google.com/p/chromium/issues/detail?id=441946

  • John Blackbourn 3:53 am on April 2, 2015 Permalink |
    Tags: ,   

    Reminder: Term splitting in 4.2 

    Here’s a quick reminder to plugin authors. Beginning in WordPress 4.2, shared taxonomy terms will get split into separate terms when one of the terms gets updated.

    What does this mean for you? If your plugin is independently storing term IDs in post meta, user meta, or options, then it’s likely you’ll need to update your plugin to prevent problems when a shared term gets split.

    Boone Gorges has posted a complete guide to preparing for term taxonomy splitting. Take a read if you’re a plugin author and you think a plugin of yours may be affected.

  • Gary Pendergast 2:25 am on April 2, 2015 Permalink |
    Tags: , , utf8mb4,   

    The utf8mb4 Upgrade 

    In WordPress 4.2, we’re upgrading tables to utf8mb4, when we can. Your site will only upgrade when the following conditions are met:

    • You’re currently using the utf8 character set.
    • Your MySQL server is version 5.5.3 or higher (including all 10.x versions of MariaDB).
    • Your MySQL client libraries are version 5.5.3 or higher. If you’re using mysqlnd, 5.0.9 or higher.

    The difference between utf8 and utf8mb4 is that the former can only store 3 byte characters, while the latter can store 4 byte characters. In Unicode terms, utf8 can only store characters in the Basic Multilingual Plane, while utf8mb4 can store any Unicode character. This greatly expands the language usability of WordPress, especially in countries that use Han character sets. Unicode isn’t without its problems, but it’s the best option available.

    utf8mb4 is 100% backwards compatible with utf8.

    Due to index size restrictions in MySQL, this does mean we need to re-create a handful of indexes to fit within MySQL’s rules. Using a standard configuration, MySQL allows 767 bytes per index, which for utf8 means 767 bytes / 3 bytes = 255 characters. For utf8mb4, that means 767 bytes / 4 bytes = 191 characters. The indexes that will be resized are:


    And from Multisite:


    Of course, the Multisite (and wp_usermeta) keys obey the DO_NOT_UPGRADE_GLOBAL_TABLES setting. The upgrade will only be attempted once, though we’ll probably add a check in a future WordPress version to see if we can upgrade now (say, if you’ve upgraded your MySQL server since upgrading to WordPress 4.2).

    If you’re a plugin developer and your plugin includes custom tables, please test that your indexes fit within MySQL’s limits. MySQL won’t always produce an error when the index is too big, so you’ll need to manually check the size of each index, instead of relying on automated testing.

    EDIT: One more thing…

    If you’d like to upgrade your custom tables to utf8mb4 (and your indexes are all in order), you can do it really easily with the shiny new maybe_convert_table_to_utf8mb4( $tablename ) function. It’s available in `wp-admin/includes/upgrade.php`, and will sanity check that your tables are entirely utf8 before upgrading.

    • Thomas Townsend 2:33 am on April 2, 2015 Permalink | Log in to Reply

      Hi Gary, glad to see you and the team are looking after the devs too ? I owe you a beer or tow if you even get down to Tampa Florid area…

    • Pippin Williamson 2:36 am on April 2, 2015 Permalink | Log in to Reply

      Excellent, thanks for the notice!

    • Todd Lahman 3:47 am on April 2, 2015 Permalink | Log in to Reply

      Great to see WP Keeps moving forward. Thanks for the update Gary.

    • J.D. Grimes 1:03 pm on April 2, 2015 Permalink | Log in to Reply

      @pento I’ve noticed that the difference in index length can cause notices when updating tables using `dpDelta()`.

      I was getting this error locally, when running the install tests for a plugin against WordPress trunk:

      WordPress database error: [Duplicate key name ‘meta_key’]
      ALTER TABLE wptests_dbdelta_test3 ADD KEY meta_key (meta_key)

      After some debugging, I found that dbDelta() was being thrown off by KEYs for VARCHAR columns, because the description of the key from the database would be like this:

      `KEY meta_key (meta_key(191))`

      But in my CREATE TABLE string, they are defined like this:

      `KEY meta_key (meta_key)`

      Since these don’t match `dbDelta()` attempts to add the key again, resulting in the error. This would happen to users on sites that support utf8mb4, if the plugin is deactivated and then reactivated.

      Kind of related: #31388.

      • Gary Pendergast 1:29 pm on April 2, 2015 Permalink | Log in to Reply

        Thanks for the bug report, @jdgrimes! I’ve recorded it in #31869, I’ll have a think about the best way to fix it.

        In the mean time, a valid work around is to specify the index length in your CREATE TABLE statement – this is what we’ve done in core, hence why I haven’t run into this bug previously.

    • pix365 3:05 pm on April 13, 2015 Permalink | Log in to Reply

      For folks on v4.1.1 ior earlier – Will there be a plugin released that will perform the the sanity checks to ensure existing sites have all the SQL pre-requisites in place before folks even attempt the upgrade to 4.2. ( or have miss understood the above “Edit on the upgrade.php” or is this check is already built in to 4.1.1)

      • Ipstenu (Mika Epstein) 4:00 pm on April 13, 2015 Permalink | Log in to Reply

        The checks are built in.

        > Your site will only upgrade when the following conditions are met:…

        That’s what’s doing it :) If any condition fails, no DB changes. If you’re not even on the right version of MySQL, it won’t do it either.

  • Andrew Nacin 7:35 pm on April 1, 2015 Permalink |
    Tags: 4.3, 4.4,   

    Release leads for WordPress 4.3 and 4.4 

    Since WordPress 3.5, we’ve had a rotating release lead. Because of the ever-present demands of the current release’s development cycle, we’ve found it tough to make these appointments well in advance. We’ve always wanted to give leads opportunity to prepare, so they can hit the ground running. (Long term, we’d love for release development to overlap pretty significantly, aided primarily by feature plugin development, but also by branching.)

    A release lead determines all important parameters for a release, like schedule, deadlines, which feature plugins are merged; and more generally, scope, goals, vision, and process. They take point when it comes to holding meetings, shepherding contributions, and writing announcement posts and updates. A release lead is a connector and facilitator, identifying bottlenecks and friction wherever they may be. They’re in frequent communication with the developers and plugin teams that are aiming to have something in a given release. The release lead follows what’s being committed, and sets the tone for prioritizing and gardening tickets. Given the constraint of time in hitting deadlines, help with prioritization and ensuring good communication lines are two of the most valuable things a lead can contribute.

    Today, I’m excited to announce release leads for both WordPress 4.3 and 4.4.

    Konstantin Obenland will lead WordPress 4.3, currently planned for August. Many of you may know @obenland (twitter) from his early work on default themes, but his contributions span across WordPress core. More recently, he shipped the new WordPress.org theme directory. Obenland is a native of Germany and lives in southern California. He’s a code wrangler at Automattic, which donates all of his time to WordPress core and WordPress.org.


    Scott Taylor will lead WordPress 4.4, due at the end of the year. A committer since 3.7, @wonderboymusic (twitter) has been plowing through major changes to media and pretty much everything else he can get his hands on. Scott is a Tennessee native and lives in New York City. He’s a senior software engineer on the interactive news team at The New York Times.


    You’ll hear from both of them in the coming days and weeks as they start to plan out their releases, including potential features, deputies, and strategies. Congratulations 🎉 and best of luck to both!

    Not an April Fools’ joke.

  • Drew Jaynes 6:05 pm on April 1, 2015 Permalink |
    Tags: ,   

    Dev Chat Agenda, April 1, 2015 

    Here’s the agenda for Wednesday’s Dev Chat in the #core channel on Slack.

    • Beta 3 was tagged last week as scheduled and we’re heading toward tagging Beta 4 this week.
    • The soft string freeze is targeted to coincide with tagging Beta 4 this week, so we need to wrap any tickets with string changes (save for the About page).

    Time/Date: Wednesday 21:00 UTC 2015:

    DST reminder: The dev chat time has moved up an hour to 20:00 UTC following the European DST change.


    1. Congrats if you got ’em for @obenland and @wonderboymusic, release leads for WordPress 4.3 and 4.4!
    2. Task/Enhancements Review [List]
    3. String Ticket Scrub [List]
      One string:

      • #29958 – collapse menu keyboard accessibility
      • #31233 – Dismissable admin notices
      • #31769 – Prevent navigating away while plugins are updating via shiny updates
      • #31836 – Press This: Clean up text on tools.php

      Two or more strings:

      • (2) #31144 – Options general screen, accessibility improvements
      • (2) #31770 – Better feedback after bulk updating plugins via shiny updates
      • (3) #31722 – Shiny Updates: the aria-label should be updated to reflect the current status

      Various string changes:

      • #26600 – Search installed themes input has no submit button – New help text, one string split into two, new strings
      • #31832 – Add an Emoji section to the Help tab on post edit screen – New help text, replaced string
      • #27115 – HTTPS links to wordpress.org – Strings adjusted for links, may not need re-translating

    No Open Floor this week – Due to time constraints, we won’t be holding an open floor period during the regularly-scheduled dev chat this week. If you have a ticket on the 4.2 milestone you’d like to get dev feedback on, leave a note in the comments.

    Testing Stages Progress
    • Beta 1
      • Punt/convert all non-essential enhancements to tasks
    • Beta 2 (120 tickets on Report 6)
      • Get first run of FTP credentials modal in trunk
    • Beta 3 (90 tickets on Report 6)
      • Start finishing up tickets with string changes
      • Start About page
    • Beta 4 (50 tickets on Report 6)
      • Soft string freeze (all string changes completed save for the About page)
      • Start finishing up the About page
    • RC 1 (0 tickets on Report 6)
      • About page finished
      • Hard string freeze
  • Drew Jaynes 3:10 pm on April 1, 2015 Permalink |
    Tags: ,   

    This Week in 4.2: March 30 – April 5 

    This is the jump-start post for the eleventh week of the WordPress 4.2 release cycle. Posted just a little bit late this week, sorry folks.

    We entered the Beta 3 stage of development last week. We need to wrap up any tickets with string changes and transition to Beta 4 this week.

    Thrice-weekly scrubs will continue this week on Tuesday, Wednesday, and Friday using Report 6.

    Core Meetings this week:

    Core meeting times have been adjusted following the DST change in Europe over the weekend. No joke!

    Priorities this week:


    • Committers: please take a look at the list of tickets you own. Many of those tickets are simply waiting for you to follow up on commit or patch feedback and are stalled without it.
    • #31794 – Theme Switcher: Improve mobile experience – Needs a patch based on feedback


    • #30468 – wplink modal accessibility
    • #31722 – Shiny Updates: the aria-label should be updated to reflect the current status
    • #31233 – Dismissable admin notices
    • #26601 – Inappropriate content in headings on admin screens

    Make Flow:

    • #29906 – Submenus can’t be dismissed on mobile.
    • #31611 – Scroll bleed in the attachment details modal on iOS
    • #31609 – Scroll bleed through and scroll position loss in the view plugin details modal on iOS
    • #31612 – Scroll bleed in the link modal on iOS

    Recent posts seeking feedback

    Notable updates from the last week:

  • Daniel Bachhuber 1:30 pm on April 1, 2015 Permalink |
    Tags: meetings, ,   

    Shortcake (Shortcode UI) has a weekly meeting time: Mondays at 7 pm UTC 

    The title says it all. Our next weekly meeting is Monday, April 6 at 19:00 UTC

    We also have a channel on Slack. Come join us in #feature-shortcode

    Shortcode-curious? Check out this recent WP Tavern post for the details on our latest release.

  • Drew Jaynes 5:20 pm on March 31, 2015 Permalink |
    Tags: dst   

    Reminder: Core meetings move up an hour starting this week (DST) 

    Following the Daylight Saving Time change in Europe over the weekend, all core meeting times will move up an hour, bringing those in North America and surrounding areas back in sync with those in Europe.

    Contributor team and development meetings are held in Slack.

    Updated Meeting Times

    What Where When Was (UTC)
    4.2 Core Bug Scrub #core Tuesday 15:00 UTC 16:00
    4.2 NUX Working Group #core-flow Tuesday 18:00 UTC 19:00
    Multisite Weekly Chat
    Starting April 7th
    #core-multisite Tuesday 19:00 UTC 20:00
    4.2 Core Bug Scrub #core Wednesday 16:00 UTC 17:00
    Core Dev Chat #core Wednesday 20:00 UTC 21:00
    Dashicons Weekly Chat #design-dashicons Thursday 17:00 UTC 18:00
    4.2 Core Bug Scrub #core Friday 15:00 UTC 16:00
    Customizer Component Weekly Chat #core-customize Friday 18:00 UTC 19:00
    • Samuel Wood (Otto) 1:51 pm on April 1, 2015 Permalink | Log in to Reply

      I edited your post to remove the time shortcode, as it wasn’t able to parse those times and was showing incorrect information. Hope you don’t mind.

      When using the time shortcode, it only works for specific date/times, not recurring ones. “Tuesday 15:00 UTC” is not specific enough for it to figure it out so it was displaying the wrong thing..

    • Ryan McCue 7:58 am on April 2, 2015 Permalink | Log in to Reply

      Note: this does not apply to the REST API chat, which will not be moving from its regularly scheduled time of 23:00 UTC. :)

  • Ryan Boren 5:01 pm on March 31, 2015 Permalink |
    Tags: ,   

    We must be our own beta audience. 

    Using the beta tester plugin, I follow trunk through every phase of development via five devices (iPhone 5, iPhone 6+, Nexus 5, iPad Air, Macbook). With the plugin installed, select “Bleeding edge nightlies”. Every day, your site will auto update to the latest nightly build. We committed long ago to ensuring that trunk is continuously dogfoodable and quickly fixed in the rare event that something nasty happens, like a fatal error. I have never once experienced loss of content while following trunk.  If you follow this blog, consider putting the beta tester plugin on a real site that you use regularly. We must take this small extra risk with our own sites so that we truly see what we’re making before releasing it.

    We desperately need mobile beta testers. WordPress will be a champion of the open mobile web. We will work around the iOS Safari bugs that hamper us. We will make the mobile web a better place. With the beta tester plugin installed on a public site, testing betas from any touch device is as straightforward as testing from the desktop. Despite this ease, 4.2 in its current state is a regression from 4.1 on mobile, particularly on iOS. We’ll work through these problems before release, but we really need mobile beta testers as well as mobile patch testers. Mobile patch testing (and patch testing in general) is not so easy to set up. We need better tools and documentation here.

    Check out the Beta Testing section of the Core Development Handbook for help setting up the Beta Tester plugin. I’m always hanging out in the #core-flow Slack channel as @boren if you have questions. Let’s build a mobile beta audience.

  • Aaron Jorbin 3:52 pm on March 31, 2015 Permalink |
    Tags: , ,   

    Screen Reader Text in output of comments_popup_link 

    As of WordPress 4.2, the output of comments_popup_link now uses .screen-reader-text in themes using the default strings in calls to comments_popup_link. The accessibility team has put together a post on hiding text for screen readers that includes sample code to use in your themes.

    I recommended that all themes include the .screen-reader-text class. This change was announced by the on the theme team blog in January. In the future, there may be more changes to output that relies upon the presence of the .screen-reader-text class.

    Related Ticket:

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar