Week in Core: Sept. 28 – Oct. 11, 2015

Welcome back to the latest issue of Week in Core, covering changes from Sept. 28 – Oct. 11, 2015, changesets [34659][35029]. Here are the highlights:

https://make.wordpress.org/core/2015/10/07/%F0%9F%8E%89-one-more-committer-for-4-4/

See that ↑ right there? That’s an oEmbed. And it’s loaded from inside this site.

Feature Plugins Merged

The Responsive Images, oEmbed Provider, and the “baby” REST API feature plugins have been merged into core. Grab the latest version of trunk and test them out.

WordPress logo with wordmark below

Responsive images in your posts. Just upload and insert!

Potent Notables

These changes were big enough to merit their own blog posts:

Deeper Reading

Some commits pack in a lot of info, from detailed background to best practices in using hooks. Here are a few worth reading the entire commit message:

  • WP_Term class introduced [34997] #14162
  • Fix scalability performance problem for previewing multidimensional settings in the Customizer. [35007] #32103
  • Ensure that wp.customize.Widgets.savedWidgetIds is defined up front. [34883] #33901
  • The history and implementation of oEmbeds. [34903] #32522
  • Improve role-related arguments in WP_User_Query. [34875] #22212
  • Use wp_installing() instead of WP_INSTALLING constant. [34828] #31130
  • Introduce *_network_option functions for Multisite installs. [34777] #28290
  • Ensure that comment permalinks reflect pagination. [34735] #34068, #34073

Continue reading

#4-4, #week-in-core

Outlining a possible roadmap for the Customizer

Planning for the future is a necessary and important part of the WordPress development process. As we consider the future of WordPress – both as a whole and individual features – we publish proposed roadmaps to encourage greater discussion and give insight into the core team’s thought process.

The process of creating a roadmap is just as important as the vision behind it and the final roadmap itself. This process gives the entire community an opportunity to research and document history, define what specific items can be accomplished to bring us closer to the vision, and outlines how those tasks fit together within a possible timeframe.

What follows is a potential roadmap for the Customize component. If you’re interested in the future of live preview in WordPress, now is the perfect time to get involved and leave your feedback.


A couple of months ago, the WordPress lead developers met with the maintainers of the Customize component to discuss the future of live preview in WordPress. The goal of the chat was to come up with a potential roadmap for both the component and for how live preview can improve the user experience of WordPress for all users.

The ultimate goal of live preview in WordPress is to create user trust and remove the “save and surprise” inherent in some of the backend features.

After a lot of discussion, the group decided to target the following goals over the next two years:

  • Considerably improve performance.
  • Continue iterating on current live preview features to ensure they are solid and as easy-to-use as possible, including theme browsing and installation, menus, and widgets.
  • Experiment with new and different user interfaces. If we were creating live preview today, what would it look like? In what ways can we ease the feeling that you’re looking through a “porthole”?
  • Removal of the ambiguous mode. Currently, the Customizer is contained in a sidebar without the admin toolbar, but ideally there is the admin and the theme, and no in-between. One direction this may go is enabling “Customize” on the front end to immediately load the Customizer controls.
  • Experiment with a guided new user experience (NUX). Live preview lends itself to site setup. How can we improve the live preview experience and combine it with the NUX? Consider a “setup wizard” use case and ensure the flow has no dead ends, i.e. users can customize everything in one.

Those overall goals for live preview in WordPress can be rewritten into some specific features that are in development or planned for the future of the Customize component. These include:

  • Transactions. This re-architecture of some of the Customizer internals improves compatibility with themes by loading the preview using a natural URL, and allows Ajax requests or even REST API requests to be previewed. It also allows the preview to be viewed independently of the Customizer, so changes can be shared for others to review. See #30937.
  • Selective refresh. Only a piece of the page will need to be refreshed when this backend feature is implemented. (Formerly known as “Partial Refresh”.) Currently, this is available for menus in the Customizer. This eliminates duplication of display between PHP and JS, keeping it DRY. See #27355.
  • Concurrency. Allows for “locking” settings using the Heartbeat API, improving the overall user experience by preventing users from overwriting each other’s changes. See #31436.
  • Revisions. Enables plugin developers to add features like draft, roll back, and scheduled changes (e.g. “change my background on January 1”). This builds upon transactions, as the setting changes are staged in a transaction, and this facilitates settings to be revisioned and for settings to be scheduled. See #28721, #31089.
  • Theme installation. Iterates on and completes the theme browsing experience.
  • Responsive preview. Iterates on the concept of live preview by giving users a better idea of what their site will look like on other devices. See #31195.
  • Bootstrapped Customizer. Lazy-load the Customizer into the current frontend view without having to leave the page. With selective refresh implemented, inline controls and frontend bootstrapping would be possible since full-page refreshes would no longer be required.
  • Improvements for both touch and small devices.

Beyond those features, the group identified some specific changes that should be prioritized, in conjunction with the features planned:

  • The sliding animation between panels should feel more like “moving panels” (see: iOS).
  • Keyboard navigation should be consistent and clear.
  • Identify “dead ends” in the interface and remove them, when possible. For example, prior to menus in the Customizer, it was not possible to customize that aspect of your site’s design with the Customizer.

The concepts surrounding live preview and the Customizer have been in development for a long time. Many of the concepts from Elastic Theme and the Visual CSS Editor have been incorporated over time. Over the next few years, experimentation with these concepts will likely take place in feature plugins. For example, this team may experiment with inline content editing, where it makes sense in the context of customizing a site. Another path for exploration is simple theme customization – e.g. change the header font, change the sidebar color, or change the width of the sidebar.

As with all components and new features, we shouldn’t be afraid to experiment and fail and should continually push for new experiments and ideas, especially in the context of feature plugins. Further, some of the above experiments may not make it into core, but are meant as a general direction that live preview should take in WordPress.

Taking these features together, below is a sequence outlining a possible roadmap for live preview and the Customize component in general, along with estimated targets. Please note that this is a proposed roadmap and is entirely dependent on contributor involvement. Additionally, many of these things will take place in a feature plugin prior to core inclusion.

  • Partial refresh. Performance Improvements. (Target: 4.4)
  • Responsive Preview. Transactions. (Target: 4.5)
  • Concurrency. Revisions. Theme Install. Beginning of NUX wizard. (Target: 4.6)
  • Focus on touch screen / small device improvements. (Target: 4.7)
  • Developer API improvements based on feedback from plugin developers. (Target: 4.8)
  • Improved UI after experiments in 2016. NUX “wizard mode.” (Target: 4.9)

Live preview is one of the most critical features in WordPress as we continually combat “save and surprise.” The Customizer in its current form provides an improved user experience to WordPress users when customizing their site’s design. Each feature mentioned above is a continuation of the live preview concept, building and improving upon the Customizer.

Everything above is just a proposal and we need your feedback to ensure it is the right direction. If you’re interested in any of the above, comment here with your feedback, or join the team in #core-customize.

This post was a collaboration between @helen, @nacin, @mark, @celloexpressions, @samuelsidler, and yours truly.

#customize, #roadmap, #roadmaps

Week in Core: Sept. 13-21, 2015

Welcome to the Week in Core — Week Four, with super-exciting news from around WordPress-land, and Core changes and updates for Sept. 13–21, 2015 (commits [34093][34361]). This week’s core contributors number 106! I’m especially jazzed about the number of new names on the list, and want to thank everyone for your effort this week.

News you can use

The WP REST API team submitted a proposal to merge the plugin into core, with a two-phase integration plan. The merge proposal blog post also does a nice job of presenting the history of the plugin and some use cases.

Do you use my-hacks.php in your site? Don’t. (A quick search through the plugin and theme repos shows only 10 plugins and 3 themes that mention the file.)

Multisite is making some pretty big changes, including the addition of the  WP_Network class. Check out this blog post, which outlines some of the changes and a roadmap for future updates for 4.4.

Interested in the user-focused part of WordPress? Of course you are! Join in the conversation about “Potential UI/UX projects in core.”

Code changes

Here are some highlights from the 268 change sets published to Trac; the complete report is available online in plain-text format for a bit more in-depth coverage.

Continue reading

#4-4, #week-in-core

Week in Core: Aug. 31 – Sept. 12, 2015

Welcome to the Week in Core, with updates from weeks 2 & 3: Aug. 31 – Sept. 12, 2015, changesets [33821][34092].

It’s been a busy couple of weeks in Core, with almost too many changes to count (for the record, this one covers 271 commits!). I’m going to keep this update shorter than usual and highlight some of the bigger changes.

If you’re interested in helping write this weekly post, ping @morganestes in #core-weekly-update on Slack.

Special Note: WordPress 4.3.1 was released this week, with three security-related fixes. Be sure to update your sites!

Here’s some highlights of recent changes in core, along with some future plans and ongoing initiatives. Remember, Core moves pretty fast. If you don’t stop and look around once in a while, you could miss it.

  • WordPress will support PHP7 when it’s released. Huzzah!
  • HTTP/2 is coming! Here’s a list of tickets that need attention to get WordPress ready.
  • Get involved in Twenty Sixteen, which is in active development on GitHub.
  • Write better commit messages. The world will thank you for it. 🙂
  • As described in this post by @johnbillion, the show_ui flag for post types now gets fully honored. See #33763 for the ticket discussion.
  • A new helper function, wp_validate_action( $action = '' ), was introduced in [34059] and is used throughout admin instead of directly accessing $_REQUEST['action'].
  • A new file, wp-admin/includes/noop.php, was created to load all of the noop functions for load-script|styles.php and is only loaded by those files. DRYs in the process. [34037] #33813
  • Schema change introduced in [34030] to increase the length of wp_options.option_name to 191 chars. #13310
  • Implement a priority system for Help Tabs to add them at specific positions. [33985] #19828
  • Multisite: Don’t allow sites to be created with the following reserved slugs: wp-admin, wp-content, wp-includes [33952] #33615
  • Updated recommendations for minimum versions of PHP (5.6) and MySQL (5.5), with a special note that Oracle only actively supports MySQL for 5 years after a General Availability release. [33937] [33946]

For the full report, visit https://core.trac.wordpress.org/log/?verbose=on&format=changelog&rev=34092&stop_rev=33821&limit=400&mode=stop_on_copy.

Thanks to @adamsilverstein, @afercia, @amereservant, @ankit-k-gupta, @antpb, @austinginder, @azaozz, @BdN3504, @benjmay, @boonebgorges, @bradt, @brettz95, @celloexpressions, @cgrymala, @Cheffheid, @chriscct7, @codeelite, @CoenJacobs, @danielbachhuber, @daniellandau, @dannydehaan, @dd32, @dimadin, @dipeshkakadiya, @dlh, @DrewAPicture, @dustinbolton, @egower, @enshrined, @ericdaams, @ericlewis, @extendwings, @figureone, @filosofo, @gaelan, @GaryJ, @gitlost, @gnaka08, @gradyetc, @gregrickaby, @hauvong, @helen, @imath, @ippetkov, @iseulde, @ixkaito, @jazbek, @jeffstieler, @jeremyfelt, @jesin, @jobst, @johnbillion, @joostdevalk, @jorbin, @juliobox, @JustinSainton, @kevinlangleyjr, @khromov, @kitchin, @kraftbj, @lancewillett, @liljimmi, @lukecarbis, @macmanx, @MatheusFD, @mehulkaklotar, @mercime, @metodiew, @michielhab, @MikeHansenMe, @miqrogroove, @mitchoyoshitaka, @mordauk, @morganestes, @mrahmadawais, @mrmist, @Mte9, @nacin, @netweb, @nikeo, @nikolovtmw, @nofearinc, @obenland, @ocean90, @OriginalEXE, @Otto42, @paulwilde, @pavelevap, @pento, @peterwilsoncc, @racaseh, @rachelbaker, @rajnikmit, @rmccue, @rommelxcastro, @sc0ttkclark, @scribu, @SergeyBiryukov, @sillybean, @solarissmoke, @stevehenty, @swissspidy, @tmatsuur, @trepmal, @tyxla, @umeshnevase, @utkarshpatel, @wen-solutions, @wenthemes, @westonruter, @wojtekszkutnik, @wonderboymusic, @yoavf, and @zeo for their contributions!

#4-4, #week-in-core

Shortcode Roadmap Draft One (Proposal – Request for Comments)

This is the first draft of the Shortcode API Roadmap. It describes in broad terms a new feature set and migration that might take place across versions 4.4 through 4.7. This roadmap gives notice to plugin developers that significant changes in plugin design may be needed for compatibility with future versions of the Shortcode API. This roadmap also identifies steps taken to minimize the impact on plugin developers to allow most plugins to continue working with only small changes.

The decision to create this roadmap arose from specific needs that are not met by the old code. Our old [ and ] delimiters were easily confused with the way those characters are commonly used in English quotations and sometimes even in URLs. The proposal to use [{{ and }}] instead should allow a better balance between being able to type in the shortcodes and avoiding confusion with any other input. With these more unique delimeters, we will be able to process registered shortcodes more efficiently because we will not have to search for them by name. Unregistered shortcodes will have more consistency because we can find them more accurately.

Old style delimeters also gave no strong indication whether or not a closing tag was required. The proposal to use }$] as the delimeter of a shortcode with a following closing tag increases the efficiency of regular expressions, because the search for a closing tag will only happen as needed.

Adding the new style of shortcode syntax provides an opportunity to make significant API changes. One of those major changes is to ensure that shortcodes are processed before paragraphs and before curly quotes. This will lead to greatly simplified code in related functions that currently must find and avoid shortcodes every time they run. We also have an opporunity to re-think the way shortcodes are filtered, and to give plugin authors more control over those filters when registering their shortcodes.

4.4 – Introduce New Syntax

A new syntax and documentation of how it works will be created in the 4.4 development cycle. Support for the new syntax will be introduced, allowing plugins to register for extra features. Core shortcodes will use the new syntax in all new posts. The old syntax will not change. Old posts will not be affected. Initial work on the syntax concept follows.

Proposed New Syntax

Self-Closing:  [{{shortcode}}]

Attributes:  [{{shortcode  attr1="value1"  attr2='value2'  "value3"  'value4'  value5}}]

Enclosing:  [{{shortcode}$] HTML [${shortcode}}]

Multiple Enclosures:  [{{shortcode}$] HTML [${encl2}$] HTML [${encl3}$] HTML [${shortcode}}]

Escaped Code:  [!{{shortcode}}]

Stripped Unregistered Code:  [{{randomthing}}]

Stripped Unregistered Enclosure:  [{{randomthing}$]  Content also stripped.  [${randomthing}}]

Stripped Empty Code:  [{{ }}]

Ignored Orphan:  [{{shortcode}$]

Ignored Orphan:  [${shortcode}}]

Ignored Orphan:  [${encl2}$]

Ignored Context:  [{{shortcode <br> }}]

Ignored Context:  <a href="[{{shortcode}}]">

4.5 – Deprecate Old Syntax

Starting in 4.5, plugins that register shortcodes without declaring support for new features will raise debugging errors to alert developers that support for the old shortcode syntax is ending.

Old posts will continue to work normally while the old syntax is deprecated.

4.6 – Upgrade Old Posts

Old posts will be automatically converted to the new shortcode syntax. The Shortcode API will continue to provide deprecated support for old syntax so that there is no disruption during the conversion process.

The API should be adequately abstracted so that old plugins are not affected by this conversion. However, as the new syntax will not support HTML inside of shortcode attributes, there is no guarantee that every shortcode will work the same way in 4.6 as in earlier versions.

4.7 – End of Support for Old Syntax

Old shortcodes will stop working in 4.7. Plugins that still produce the old shortcode syntax will be ignored by the Shortcode API.

The upgrade to 4.7 will include a second pass of the conversion of old posts so that any old syntax that was added to posts during 4.6 will still get converted.

In 4.6 or 4.7, if necessary, a filter could be added to automatically convert any old syntax still being produced by old plugins when new posts are created.

#proposal, #roadmaps, #shortcodes

Component Page Updates for 4.4

Now that 4.4 is underway, let’s update the component pages to reflect 4.4 activity. The Customize, Editor, and Press This pages serve as good templates, though they all need 4.4 updates. The component pages are targeted at beta testers. They should describe the component, list milestones (roadmap), and explain what needs testing and how to test it. Good component pages assist triage. For details, see the previous round of component page updates.

Also, if your component has a corresponding Slack chat, link to the component page from the chat’s channel topic. This assists using Slack in beta testing flows.

Component maintainers, here are your component pages…

Continue reading

#components, #maintainership

Taxonomy roadmap for 4.4 and beyond

In WordPress 4.3, we eliminated shared taxonomy terms once and for all. This means that, by the time WordPress 4.4 is released, just about every WordPress installation will have the same number of rows in the wp_terms and wp_term_taxonomy database tables.

Why does this matter? When terms in different taxonomies could share the same term_id, terms could only be uniquely identified by a ID-taxonomy pair. This is why every nearly function in our taxonomy API has $term_id and $taxonomy as required arguments. (The decision was made long ago to keep the truly-unique term_taxonomy_id internal for most purposes.) The lack of unique IDs for terms made our API interfaces and internals complicated, and it made it cumbersome to add new features like term metadata.

Now that term IDs are unique, we can begin the projects of unraveling the now-unneeded complications of the taxonomy API and adding new features that take advantage of the simplified data model. In this post, I’ll outline some of these tasks, and point to areas where interested folks can contribute.

API simplification and other work on taxonomy internals

Once each row in the wp_terms table corresponds to a single row in wp_term_taxonomy, there’s no point in having two separate tables (and all the JOINs that two tables require). In 2013, @nacin sketched how this might be done, through a combination of $wpdb tricks and a MySQL view. Here, we need someone to write a patch, and we also need to start a discussion about graceful failures for situations where there are still shared terms in the DB, as well as MySQL version compatibility (view functionality was phased in over the 5.0 series). The tracking ticket for simplification of the taxonomy database schema is #30262.

With a single term table, we can begin to rewrite our internal SQL queries to remove costly table joins. This kind of refactoring is probably at least one version (and a hundred unit tests) away. In the meantime, we can begin the process of simplifying the API interfaces. For example, functions that accept term IDs, like get_term() no longer need to require an explicit taxonomy parameter.

Having a unique identifiers for terms means this is also a good time to move toward WP_Term; see #14162. This class can start off being a fairly simple model that takes care of things like basic cache management and data integrity – see WP_Post – but over time, I envision moving business logic to the WP_Term, introducing convenience methods for chaining, and so on.

Term Meta

There’s been lots of clamoring for taxonomy term metadata #10142. Unique term IDs make it viable, since WP’s *_metadata() functions assume object IDs as identifiers.

The technical implementation is not complex. We need wrappers for the CRUD functions, ‘meta_query’ support in get_terms(), an update routine to create the database table, metadata pre-caching (‘update_term_meta_cache’) when fetching terms, and maybe a few other small items.

The larger challenge is to build a core solution that minimizes conflict with third-party tools. Developers have wanted termmeta for a long time, so there are many public plugins and private libraries that provide it. Many of them use unprefixed function names like update_term_meta(), and many of them use a database table called wp_termmeta. We should do a survey of publicly available plugins to get a sense of usage statistics and schema compatibility. We’ll need to organize outreach to developers of known plugins, so that they can add off-switches to their tools before termmeta appears in core. And we may decide to borrow code from one or more of the existing GPL-licensed tools, ideally with the participation of the original author.

Let’s share this journey

Many hands make light work. We need code, but more importantly, we need folks who are nuts about strategy and outreach and backward compatibility.

There’ll be a meeting for all Taxonomy Heroes, on September 3 2015 20:00 UTC, in the #core channel on Slack. If you’re interested in helping out with any of these taxonomy projects, drop a comment below or come to the meeting. We’ll get a team or two together, and make a plan for 4.4 and beyond.

#4-4, #roadmaps, #taxonomy

Dev Chat Summary, May 20

Agenda, Slack log.

Committers Update (#)
@nacin
New guest committers: @iseulde, @westonruter, and @obenland, renewed guest committers: @jorbin, @jeremfelt, permanent committers: @pento, @boone, and @johnbillion
Also see https://make.wordpress.org/core/2015/05/20/new-committers-for-4-3/

Editor (#)
@azaozz@iseulde
No update here. Will discuss goals for this week and next week outside of dev chat.

Admin UI (#)
@helen
@helen is plugging away at some groundwork for the CSS roadmap, @stephdau should be taking a look at the first steps for list tables in the next day or so. Will discuss goals for next week in tomorrow’s UI meeting.

Network Admin UI (#)
@jeremyfelt
They talked through aspects of the Edit Site and Add Site flows yesterday to help @hugobaeta with mock-ups. Hopeful to see a mock up of these soon. They have a couple flows in Make/Flow with more on the way. The 5s flow highlighted an issue with text inputs overflowing. There’s also an updated `WP_Network` patch.

Things they want to have done by next week:

  • Android and iPad flows.
  • Conversation around updated `WP_Network` patch and a first attempt at `WP_Site`.

Partial Refresh (#)
@westonruter
Now has support for refreshing menus changed by Menu Customizer: https://github.com/xwp/wp-customize-partial-refresh/pull/12/files
It’s much simpler than partial refresh for widgets, and @westonruter thinks that maybe it could safely be on by default, instead of requiring opt-in as is currently done for widgets. The concern with on-by-default would be if menus get some dynamic behaviors added to them with JS, so maybe it’s just something that theme authors would need to account for.
Also waiting on feedback and testing from the Menu Customizer, merging the corresponding PR for Menu Customizer, to then merge the PR for Customize Partial Refresh and do a new plugin release.

Goals for next week: Take what was done for Menus and then abstract a level again to facilitate plugins easily adding their own partial-refreshing.

Menu Customizer (#)
@voldemortensen, @celloexpressions
Lazy loading and error handling were committed. Will discuss goals for next week outside of dev chat.

Better Passwords (#)
@markjaquith
They’ve been working on a mockup of the password UI: http://codepen.io/markjaquith/pen/GJjZbJ
Probably best to create a temporary hook in core for the password-set UI in the profile, to allow the team to work on this as a plugin. @markjaquith can take care of that core change, and start the plugin on GitHub.
#32428 is on hold until the Password UI is usable. @voldemortensen started work on expiring reset keys #32429, but hopes to get it showcase-able by the end of the week. @rmarks made a first pass at #32430 but it needs more work.

Goals for next week:
1. Hook in core to enable plugin for PW change UI.
2. Working version of PW change UI on the Profile screen (that is, you can change your password with it… show/hide… back compat for the pw confirmation field… not promising the strength hint stuff yet).
3. #32430 ready for commit.
4. Working patch for #32429.

Favicons (#)
@johnbillion
@johnbillion made a start on the site favicon manager. As discussed during dev chat last week and in #16434 it has an API so plugins/themes can register new sizes for favicons/touch icons/etc if the need arises. I’ll be pushed to a GitHub repo by tomorrow. The main thing that will need to be discussed is whether this should just be a customizer setting or not. @johnbillion will post about the repository location and meeting times on this blog.

Other:
@ocean90 is looking for feedback on #29783!

Next chat will be on May 27 2015, 20:00 UTC

#4-3, #meeting

4.2 Scrub

We’ll be scrubbing report 6 in the #core channel on Slack in about 20 minutes at Tuesday 18:00 UTC 2015. Join us!

@azaozz @dd32 @nacin @helen @sergeybiryukov @ocean90 @wonderboymusic @mark @johnbillion @jorbin @boone @jeremyfelt @pento

#4-2

WordPress Core Weekly

Howdy! Sorry, I dropped the ball last week so this week’s Weekly Roundup is a double issue — it covers April 4, 2015 [32003] to April 18, 2015 [32140].

This week marks the release of RC1, which is the first release that many plugin authors and beta testers will test heavily. If you don’t already, now is a good time to check out the Alpha/Beta forums for any issues that crop up during this testing cycle.

We’re only days away from the release of 4.2; let’s finish strong! 🏃👏 Here’s the rundown of recent changes:

TinyMCE

  • Update to 4.1.9+. Changes:
    • Fixed bug where extra empty paragraphs would get deleted in WebKit/Blink due to recent Quriks fix.
    • Fixed bug where the editor wouldn’t work properly on IE 12 due to some required browser sniffing.
    • Fixed bug where formatting shortcut keys where interfering with Mac OS X screenshot keys. [32058] #31895
  • Disable the wp-autoresize plugin in iOS. All iframes there are already expanded to the height of the content document. [32095] #31937
  • Update the “Keyboard Shortcuts” modal. [32060] #29558
  • Fix our shortcuts on Mac, use Ctrl + Opt + letter. [32059] #29558
  • Use window.twemoji directly in the wpemoji plugin. Gives a chance to the browser to lazy load twemoji.js when reloading the page. [32142] #31901
  • Remove the empty paragraph that sometimes is left over after adding an image caption. [32141] #32003

wpView

  • Remove selected views when inserting content but not when loading all content, and remove the ref. to the selected view node on resetting the views. [32140] #31998
  • Resize sandbox iframes on load. [32056] #31480
  • Empty the content in the timeout, so it doesn’t render iframes twice. [32022] #31669

Build/Test Tools

  • During PHPUnit tests, don’t autodetect permalink structure during WP installation. [32139] #31994
  • Move the built media JS files up a directory to their previous location and naming convention. [32125] #31912 (see [31373])
  • Don’t reference underscore.js source map. [32065] #31477

General/Misc.

  • WordPress 4.2-RC1 [32137] [32138]
  • Use HTTPS URLs for codex.wordpress.org. [32116] #27115
  • Explain all placeholders in translator comment, not just the first one. [32111] #31675
  • Ensure post title input is not shortened for non-public post types. [32071] #30968
  • Improve handling of incomplete From and Content-Type headers in wp_mail(). [32070] #30266
  • wpLink: always show the URL field at the top. [32017] #28206
  • Force default avatar for HiDPI avatars on Discussion Settings. [32129] #31972

Translation and Strings

  • Merge strings that describe the same command. [32078] #31776
  • Update placeholder for FTP credentials. [32077] #31922
  • After [31941], use the decoupled strings from wp-admin/network/themes.php in wp-admin/network/site-themes.php as well. [32029] #28502
  • Correct grammar when referring to “a user” vs “an user” in several places. [32025] #31894

Administration

  • Fix flickering of the admin menu on over-scrolling. [32089] #30900
  • Dashboard: Ensure images other than avatars (such as emoji replacements) in recent comments are not incorrectly positioned. [32076] #31919
  • Admin menu: fix colors for focus state and in IE8. [32075] #31345
  • Dismissible notices: more precise positioning across browsers. [32068] #31233
  • Reset padding for buttons in theme details modal. [32128] #31963
  • Revert [32099] per discussion in #core. [32100] #30900
  • Remove z-index from #adminmenuback. [32099] #30900
  • Don’t print the custom-background class in body_class() when a default color is in use. [32081] #28687
  • Toolbar: Search item consistency for focus state and IE8. [32074] #31322
  • Pointers: Make the dismiss icon a consistent size. [32069] #31915
  • Update more instances of default admin blues and grays. [32051] #31234

Emoji and Smilies

  • Tweak which smiley matches which emoji. [32105] [32107] #31709
  • Update our few remaining smilies to better align with Twemoji, and add frownie.png until Twemoji provides a build containing it. [32104] #31709
  • The emoji JS files should be run through the script_loader_src filter, as they would be if they were registered scripts. [32097] #31938
  • Tidy up the wp_encode_emoji() regex, and clarify the function comment on Unicode 8 support. [32096]
  • Remove an errant / in Twemoji URLs. [32024] #31893
  • Remove executable bit from smilies. [32109] #31709

Themes

  • Twenty Fourteen: update editor styles to better account for adaptive images in small screens. [32094] #31934
  • Twenty Fifteen: update editor styles to better account for adaptive images in small screens. [32090] #31934
  • Theme Compat: Make string translatable and add translator comments. Added in [31941]. [32084] #28502, #31921
  • Move initialization of $customizeSidebar to api.ThemesSection.initialize() to prevent cases where the result can be undefined. [32119] #31793
  • Translator comment should just reference placeholder numbers, not the actual placeholders. [32112] #31675
  • Tell developers how to correctly silence register_sidebar() notices. [32110] #31675

Customizer

Theme Switcher

  • Fix some esoteric breakage in iOS Safari. [32103] #31794
  • Don’t deactivate section on empty search results. [32083] #31889
  • Remove “Add New” reference from customize-controls.js. [32004] #31837
  • Use text input for the search field to prevent double tap issues for Preview and Customize buttons on iOS. [32127] #31794
  • Don’t re-render a theme control if it has already been rendered.
  • Lazy load theme screenshots. [32088] #31793
  • Fix tabbing order if section is open. [32087] #31289
  • Fix preview URL for subfolder installs. [32086] #31896

Shiny Updates

  • Disable shiny updates from modal based on parent window [32082] #31739
  • Fix logic for details based shiny updates. [32080] #31739
  • Disable modal initiated shiny updates on wp-admin/update-core.php. [32067] #31739
  • Use dashes instead of dots as separator for jQuery events in shiny updates . is used for namespaces, so better to use dashes. [32063] #31819
  • Trigger events upon the completion of a shiny update. [32061] #31819
  • Remove Shiny Bulk Updates. Bulk updates don’t need to be ajaxified so let’s revert. [32053] #31770, #29820
  • Conditionally add AYS to leaving shiny updates. [32052] #31769
  • Enable users to initiate a shiny update from plugin detail modal. [32062] #31739

Media

  • Don’t allow whitespace-only image captions from the Media modal. [32079] #21848
  • Fix focus and selected state for the selected attachments set. [32072] #31898
  • Rename get_media_embedded_in_content_allowed filter tomedia_embedded_in_content_allowed_types. [32113] #26675
  • Bring back spinners, now without bouncing select elements. [32101] #22839, #30725
  • Fix the media modal Insert into post button on narrow screens by limiting the width of .media-toolbar-primary and .media-toolbar-secondary only inside .attachments-browser (the top toolbar). [32121] #31908
  • Insert from URL: Make sure the link text is actually used. [32055] #29476
  • Make sure the spinner in the media modal is visible on narrow screens (without affecting the media grid). [32120] #30725

Build Tools

  • Don’t override minified libraries included in core. [32066] #31477

Docs

  • Remove unnecessary inline @see tags from a variety of parameter and return descriptions in wp-includes/wp-db.php. [32050] #31888
  • Remove unnecessary inline @see tags from the wpdb::process_field_charsets()DocBlock. [32049] #31888
  • Add a missing return description for has_header_image(). [32048] #31888
  • Fix a variety of inline documentation syntactical issues in wp-includes/taxonomy.php. [32047] #31888
  • Add a missing @access tag to the DocBlock for the WP_Meta_Query->$clauses property. Also adds a missing return description for WP_Meta_Query::get_clauses(). [32044] #31888
  • Add a variety of missing descriptions and fix syntax for wp_scripts(),_wp_scripts_maybe_doing_it_wrong(), and wp_script_add_data(). [32040] #31888
  • Remove an unnecessary inline @see tag and document the $wpdb global in two WP_Comment_Query methods. [32038] #31888
  • Add missing parameter and return descriptions to WP_Customize_Widgets->filter_customize_dynamic_setting_args(). [32036] #31888
  • Add parameter and return descriptions for WP_Customize_Widgets->get_setting_type(). [32035] #31888
  • Add missing @access tags to two DocBlocks in WP_Customize_Setting. [32034] #31888
  • Document the $theme property in WP_Customize_Themes_Section. Also adds a missing@access tag to the DocBlock for WP_Customize_Themes_Section->render(). [32033] #31888
  • Cleanup DocBlock syntax, add a missing parameter description for WP_Customize_Manager->set_post_value(). [32031] #31888
  • Add inline doc syntax fixes for WP_Customize_Manager->doing_ajax(). Also adds a return description. [32030] #31888
  • Add documentation for the $type and $theme properties in WP_Customize_Theme_Control. Also add some missing @access tags to various DocBlocks. [32028] #31888
  • Fix description alignment for the category_css_class filter docs. [32026] #31888
  • Add documentation for the $type, $mime_type, and $button_labels properties in WP_Customize_Media_Control. [32023] #31888
  • Clarify the DocBlock summary and parameter description forwp_edit_attachments_query_vars(). [32019] #31888
  • Add proper descriptions for the @global and @param tags in the wp_media_attach_action() DocBlock. [32018] #31888
  • Clarify the DocBlock description for wp_print_request_filesystem_credentials_modal(). [32016] #31888
  • Clarify 4.2.0 changelog entry, add global description to the DocBlock for WP_Users_List_Table->single_row(). [32015] #31888
  • Add missing @since versions from a variety of methods in WP_Press_This. [32014] #31888
  • Add missing DocBlocks for the _limit_array(), _limit_string(), _limit_url(),_limit_img(), _limit_embed(), and _process_meta_entry() utility methods in WP_Press_This. [32013] #31888
  • Add a return description to the DocBlock for WP_Posts_List_Table->is_base_request(). [32009] #31888
  • Add an @see mention for Plugin_Upgrader, plus spacing to the wp_ajax_update_plugin()delcaration. [32006] #31888
  • Add a more descriptive function summary for options_discussion_add_js(). [32005] #31888
  • Fix Docblock syntax for the taxonomy_parent_dropdown_args filter. [32003] #31888
  • Add a missing return description for wp_styles(). [32041] #31888
  • wp_install_maybe_enable_pretty_permalinks() should have a consistent @return value. [32027] #6481, #31888

Help/About

  • All strings are available for translation. [32132] [32135] [32136] #31929
  • Change the subhead strings on credits.php and freedoms.php to match about.php.
  • Link the Emoji Codex article in the emoji blurb.
  • Add a second sentence to the JavaScript Accessibility blurb.
  • Switch positions for the JavaScript Accessibility and Complex Query Ordering sections for balance. [32131] #31929
  • Update about page for 4.2. [32118] [32123] [32130] #31929

Upgrade/Install

  • Move wp-plugin-update-success event to after lock is released [32133] #31978, #31819
  • Use named function instead of anonymous function, making it testable and replaceable. [32126] #31964
  • When dbDelta() is checking whether an index is defined in a CREATE TABLE statement, don’t worry if MySQL has a subpart defined on an index, but the CREATE TABLE doesn’t. [32108] #31869

Script Loader

Press This

  • Do not show the bookmarklet upgrade notice when accessing directly press-this.php. [32122] #31968
  • Add mb_strlen() compatibility function. Works the same way as the existing mb_substr() compatibility function. [32114] #31951
  • Check the bookmarklet version and add the update notice from PHP. [32106] #31942
  • Add ARIA attributes to the alerts container. [32102] #31942
  • Fix focusing the Standard Editor link after saving draft, if the user has not focused another element. [32098] #31923
  • Change the link text to Standard Editor. [32093] #31923
  • When saving a draft change the text of the Save Draft button to “Saving…” [32092] #31923
  • Update documentation for press_this_save_redirect filter after [31992]. [32143] #31996

Taxonomy

  • wp_update_term() should check if get_term() returned null. [32117] #31954
  • Avoid an unexpected object error when syncing global terms. Pass the expected single value, rather than object, when recursively calling global_terms(). [32064] #31914, #31149

Editor

Thanks to @adamsilverstein, @afercia, @awbauer, @azaozz, @boonebgorges, @DavidAnderson, @dimadin, @dlh, @DrewAPicture, @ericlewis, @hauvong, @helen, @hugobaeta, @iseulde, @jamescollins, @jeremyfelt, @joemcgill, @joen, @johnbillion, @jorbin, @kraftbj, @lancewillett, @markjaquith, @mattheu, @Michael-Arestad, @mindrun, @morganestes, @nacin, @nitkr, @obenland, @ocean90, @pavelevap, @pento, @peterwilsoncc, @samuelsidler, @SergeyBiryukov, @siobhan, @sirbrillig, @slobodanmanic, @swissspidy, @tmatsuur, @Tmeiste, @tyxla, @valendesigns, @westonruter, and @wonderboymusic for their contributions!

#4-2, #week-in-core