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:


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

Last Week(s) in WordPress Core

Hi Everyone! It’s time for another update. This edition covers through Sunday, June 15th, and has taken a while due to travel, but @swissspidy & @designsimply have joined the team, helping to gather the information to bring us up to date. Hopefully this will help these updates be a bit more sustainable over time. If you’re interested in pitching in with these updates as well, please let me know in the comments below!

Especially of note are the first pass of the grid view for the media library, several SSL and oEmbed updates, and a new ‘Beta Testing’ tab on the Plugins screen.


  • Plugins Screen: Add a new ‘Beta Testing’ tab on the plugin installation screen, for features as plugins such as Press This. [28749] #28513
  • Media Library: Grid view for the media library, first pass. This is alpha; expect imperfection to start. [28682] #24716


  • Forcing SSL logins now forces SSL for the entire admin. [28609] #10267
  • Force SSL on the frontend when the home URL uses HTTPS. [28610] #27954
  • Force SSL admin when siteurl is explicitly configured with HTTPS. [28674] #27954
  • Use a secure logged_in_cookie when the home URL is forced HTTPS. [28627] #15330
  • Deprecate url_is_accessable_via_ssl(). [28709] #19555


Themes and Templates

  • Add a filter to human_time_diff() to allow more detailed depictions of time differences. [28670] #27271
  • Allow simple modification of sections of the title by adding a wp_title_parts filter to wp_title(). [28669] #17877
  • Add CSS rules to ensure that videos will be responsive, regardless of theme. [28650] #28414
  • Replace TEMPLATEPATH and STYLESHEETPATH with get_template_directory() and get_stylesheet_directory(). These constants are now deprecated [28563] #18298
  • Update Twenty Thirteen and Twenty Fourteen to Genericons 3.0.3. [28692] [28693]


  • Improve keyboard accessibility for the media modal. [28607] #23560
  • Add screen reader labels to the date inputs on the post editing screen. [28730] #25461


  • When parsing the main query, if s is set to empty: ?s= and $this->is_main_query() && array_key_exists( 's', $this->query ) – kill the query instead of loading the homepage. This will load the search page with no results. [28612] #11330
  • Kill queries that explicitly pass empty arrays to category__in, tag__in, tag_slug__in, and author__in to WP_Query. [28664] #28099
  • Fix SQL generation when meta_query has an 'relation' => 'OR' for its queries and wants to 'orderby' => 'meta_value'. [28659] #25538
  • Allow users to sort posts by type in WP_Query. [28605] #28214
  • Add access modifiers to WP_User_Query Add magic methods for BC: get(), set(), isset(), unset(), and call(). [28528] #27881, #22234


  • Wide-reaching changes to do away with many instances of variable-variables. See #27881 for full list of changes.
  • Eliminate use of extract() within WordPress. #22400
  • Fix curly quotes around numbers when applicable. [28721] #8775
  • Only include relevant post authors in WXR exports. [28731] #20206
  • Append the date to $wp_version in the build output, for nightly packages. [28611] #26751.
  • Update wp_insert_comment() and wp_new_comment() with a check for successful database insert. [28672] #28254
  • Use get_pages() instead of a raw SQL query in get_body_class(). [28696] #28159
  • Pre-populate the selected URL or mailto:<email-address> when “Insert/edit link” is clicked. [28705] #19992
  • Live update the menu item title when the user is editing the “Navigation Label” field. [28707] #23076
  • Deprecate get_all_category_ids(). Suggest get_terms() as a replacement. [28679] #21200
  • Deprecate like_escape() and replace with $wpdb->esc_like(). [28711] #10041
  • Redirect edit.php?post_type=attachment to upload.php to avoid an empty list table. [28729] #27951



  • Update TinyMCE to 4.0.28. [28606] #28391, #27941
  • In iOS, fix placing the caret at the bottom of longer posts when the keyboard is open and disable resizing on switching editors and on show/hide of the kitchen sink row. [28626] #28242
  • Fix problems with undo/redo after resizing an image several times. [28614] #28389
  • Fix saving the editor content on switching from Visual to Text. [28576] #28353

Thanks to @aaroncampbell, @adamsilverstein, @alexander.rohmann, @aliso, @atimmer, @avryl, @azaozz, @boonebgorges, @bramd, @celloexpressions, @clifgriffin, @coffee2code, @danielhuesken, @DavidTheMachine, @DeBAAT, @donncha, @DrewAPicture, @eddiemoya, @edwin-at-studiojoyo.com, @ericlewis, @filosofo, @frank-klein, @Funkatronic, @garhdez, @gauravmittal1995, @gcorne, @georgestephanis, @ghost1227, @grahamarmfield, @harrym, @helen, @iamtakashi, @iljoja, @issuu, @ixkaito, @jackreichert, @JanHenkG, @Jayjdk, @jdgrimes, @jeffstieler, @jeremyfelt, @jesin, @jgadbois, @jjeaton, @jkudish, @joedolson, @johnbillion, @johnjamesjacoby, @johnzanussi, @jtsternberg, @kitchin, @knutsp, @kovshenin, @kpdesign, @kraftbj, @kurtpayne, @kwight, @lancewillett, @lessbloat, @markoheijnen, @mdbitz, @MikeHansenMe, @mikemanger, @miqrogroove, @mrmist, @MuViMoTV, @nabil_kadimi, @nacin, @nd987, @Nessworthy, @netweb, @niallkennedy, @ocean90, @obenland, @pdclark, @pento, @purzlbaum, @rclations, @redsweater, @ruudjoyo, @schoenwaldnils, @scribu, @senlin, @SergeyBiryukov, @sharonaustin, @shaunandrews, @simonwheatley, @sixhours, @slimndap, @solarissmoke, @tar.gz, @tillkruess, @topher1kenobe, @torresga, @UmeshSingla, @winterDev, @wonderboymusic, @wpsmith, @zamfeer, and @duck_ for their core contributions!

Thanks to @swissspidy & @designsimply for their help with compiling this post.
Revisions covered: [28528] to [28757]. For the complete list of commits to trunk, check out the log on Trac.

Interested in joining in? Write or test a patch for 4.0.

#4-0, #week-in-core

Upcoming Global Admin Search (née Omnisearch) Meeting

After the feedback in the merge chat today, it looks like we’ve got a bit more work to do on the global search spine.

Based on a quick survey, it looks like Monday, November 11, 20:00 UTC (3pm EST) is likely to be the best time for the most people.

As we’ve done before, we’ll meet in #wordpress-core-plugins on Freenode, and I’ll give a shout in advance on #wordpress-dev for anyone that may be lurking in there.

Putting up the bat-signal:

Other folks who spoke up during the merge chat that I’d love to have join us:


Omnisearch / Global Admin Search, Final Pitch

Plugin: https://wordpress.org/plugins/omnisearch/
Diff: https://cloudup.com/cC6IbXxoHXN

Previous posts:

IRC chats in #wordpress-core-plugins:

We were a small, but scrappy group. It was mostly myself, @japh, and @lessbloat.

Omnisearch currently adds three ways to search.

  • A Dashboard Widget:
    Omnisearch Dashboard Widget
  • An admin page under the Dashboard:
    Omnisearch Admin Page
  • And as a search box on  the adminbar — when you’re on the admin side of the site:
    Omnisearch Admin Bar

All three turn up the same results page:

Omnisearch Results Page

And all is happy with the world.

We were trying to solve the proliferation of different search forms for different data structures in the admin.  When trying to find content, it’s inconvenient and difficult to always navigate to the right data structure and then search it — especially if you’re unsure if something was in a comment or a post (all too frequent in p2s)– and you just want to pull in all relevant results.

Other things we’d considered were potentially adding an Alfred-like pop-up modal where you could enter omnisearches, and see results from the menus on the page that happen to match — very much like WP Butler’s current functionality.  We opted not to add it in this pass, though, figuring better to keep a slimmer implementation.

Our user testing confirmed that this was a definite win.  In fact, the user even remarked that there should be a centralized search when we had them running through the initial steps where they were to search each data structure independently, before activating Omnisearch and seeing how that compared.

We’re eager to hear any feedback on code, methods, or even name.  I’ve had some people mention that they’d prefer it have a less ‘marketing’ name, and more of a generalized “Global Admin Search”.  I prefer Omnisearch for brevity, but would love to hear some discussion on the pros and cons of whether it would be better to use a more general name.

#3-8, #core-plugins, #feature-plugins, #omnisearch, #proposal

Omnisearch User Testing

Howdy, all!

Sorry for the delay, been a chaotic week or so. Just got the results of some user testing back thanks to the assistance of @lessbloat.

View Results: https://www.usertesting.com/videos/dQBRyueQ9EsMAv1OsQrQmg%3d%3d?back=%2Fdashboard%3Fnew_study_id%3D%23study_905321

Here’s my notes:

  • User remarks that there is no obvious intermediary way to search things. Seems frustrated about having to go from the current page, to the archive page, to search.
  • Unrelated Bug: (possibly due to browser extension?) For some odd reason, when the user selects the search box, it jumps below the list table. Really odd behavior in IE 10.
  • Dislikes native WordPress functionality of the “Search” in the adminbar expanding when selected (native is only on front-end, Omnisearch expands this functionality to admin ui as well) — believes it should be natively expanded. Reiterated several times. Perhaps look at making it drop down a search box on hover (kinda like twentyfourteen does), rather than expanding on click and shifting things about? Unsure.
  • Found Bug: Reply hoverlink in comments list [in omnisearch] doesn’t function properly (missing JS hook).
  • “Overall, I would say that this is a much better tool, much better layout.”

The user seems very positive, seemed to consider it a great win for usability. Pointed out a few bugs (as noted above — only notable one I caught with Omnisearch itself being the hoverlinks in the Comments to reply didn’t work), which I’m about to patch.

Our weekly meeting will be as usual, Thursday at 22:00 UTC (6pm Eastern)

#omnisearch, #user-testing


Howdy, folks!

Terribly sorry for the delay, but I’m pleased to announce that Omnisearch will be meeting Fridays at 5pm Eastern Time, 21:00 UTC, Thursdays at 6pm Eastern Time, 22:00 UTC, in #wordpress-core-plugins on freenode. Happy to adjust it later, if that’s too early or late for folks in other timezones.

Omnisearch is a central search form, meant to simplify the process of finding what you’re after. It is designed only for the WordPress Admin Interface — not the front end.

By default, it searches Posts, Pages, Media, Comments, and the Plugins Directory. However, it’s easy to hook into, and provide custom results from third-party modules, such as Grunion Contact Form in Jetpack.

Omnisearch has been living in Jetpack for a few months now, and has gotten mostly positive reviews. The only complaints that I’ve heard were that it doesn’t search media (which has since been added), the relevance isn’t always ideal (it just uses the default search that happens when you use the existing search form on the posts page or the like), and some coming from a misunderstanding where they were expecting it to be on the front-end of the site — not merely an admin tool.

Interested parties include @japh, with @lessbloat helping to design some user testing to determine its usefulness as a part of core.

If interested, you can install it yourself here, which will override the version in Jetpack if you happen to have that installed [ I made sure to only include the Jetpack one if ( ! class_exists( ‘WP_Omnisearch’ ) ) ] :


#3-8, #feature-plugins, #omnisearch

Present your 3.8 feature idea at tomorrow’s meeting

Tomorrow’s WordPress 3.8 meeting at Thursday 18:00 UTC is a great time to present your feature idea to the community. Many groups have already started forming around different ideas.

Comment on this post with a group name to add your group to the list of projects presenting tomorrow. Make sure you bring the following things with you:

  • What problem(s) are you trying to solve?
  • What proposal solution(s) are you interested in exploring?
  • When and where is your group communicating?
  • Who has joined your group so far?
  • If you’ve selected someone to lead your group, who is your lead?
  • If you’ve already started work on your plugin, bring a link to your plugin page.

See you tomorrow!

#3-8, #agenda, #core-plugins

Howdy everyone There’s been a lot of discussion…

Howdy everyone! There’s been a lot of discussion over the last week or two around widgets for 3.8. Inspired by @lessbloat, I’ve made a short survey with a few basic questions about widgets and how you use them. It you could, please take a few minutes to share your thoughts:

Take the Widgets Survey


#3-8, #survey, #widgets

Post Formats, Schedules, and Philosophy

Post Formats UI is looking like this right now:
Screen shot 2013-04-23 at 9.05.04 AM

This seems confusing, because it looks like they are icons to insert something (Image, Gallery, Link, Video, etc), but instead of launching a popup to insert a link or an image, the screen changes and the navigation that was just used to choose disappears completely. (Note: If Standard had some indication of being the default/current selection it wouldn’t be as confusing)

Clicking on one — say Link — makes the UI change, the big icon row go away, and a format switcher link drops below the title rather than keeping its visual hierarchy above the post stuff, and it’s generally disorienting.

Screen shot 2013-04-23 at 9.09.35 AM

If the user thinks, “Whoa, what happened, I better change format again,” and they click on the “Change format’ link under the title field and next to the “Enter URL” instruction, the screens morphs again to this:

Screen shot 2013-04-23 at 9.12.41 AM

Where the icon strip is back, but the link field has disappeared and the icon next to Add New Post is still a link. This is super confusing. Does it still think it is a link bc they didn’t actively choose to return to standard, they just chose to see the options? If that’s so, why did the url field disappear?

Looking at the release schedule:
Screen shot 2013-04-23 at 9.40.18 AM
We launched Beta 1 on April 4, and it’s been almost 3 weeks without a follow-up beta 2.
…I am wondering if the post formats ui is really prime time ready, or if it should be one of the very first thing sto land in a 3.7 branch so we can get the things that are completely ready into the hands of users sooner rather than later?

Since I’m outside the core dev group now, I’ve been on both sides of the deadline delay dance. I know how hard it is to let go of something that feels like it is thisclose to done. And I know that just about everyone on the core team will be thinking right about now that I should shut up (and I’m okay with that, because it used to be my first response to deadline questions to core, too). But we have this philosophy posted on wordpress.org:

Deadlines Are Not Arbitrary

Deadlines are not arbitrary, they’re a promise we make to ourselves and our users that helps us rein in the endless possibilities of things that could be a part of every release. We aspire to release three major versions a year because through trial and error we’ve found that to be a good balance between getting cool stuff in each release and not so much that we end up breaking more than we add.

Good deadlines almost always make you trim something from a release. This is not a bad thing, it’s what they’re supposed to do.

The route of delaying a release for that one-more-feature is, literally, a rabbit hole. We did that for over a year once, and it wasn’t pleasant for anybody.

The more frequent and regular releases are, the less important it is for any particular feature to be in this release. If it doesn’t make it for this one, it’ll just be a few months before the next one. When releases become unpredictable or few and far between, there’s more pressure to try and squeeze in that one more thing because it’s going to be so long before the next one. Delay begets delay.

I’m not trying to be a troublemaker or imply that anyone isn’t doing everything they can — I know for a fact that people are working themselves into the ground on this release. Nor am looking to incite a debate about deadlines or all the explanations of how we fell behind this time (I’ve been following along, everything is really pretty normal). But would it be better to not try to squeeze it all in, get out what we can ship now (including the awesome 2013 theme that regular people still don’t have access to), and take a quick breath to relax before diving back in on a new cycle? Shipping is a feature, too. 😉

#3-6, #deadlines

Post Formats UI Update, 3/14

As noted in The Road to 3.6 Beta 1, we’ve got quite a bit going on for post formats. Many of the tickets are in need of testing (including unit tests) and then a commit. As always, there are a few different fronts: UI/administration, data, and parsing. Here’s where we are with each, and what needs to get done. There’s a large variety of tasks here, and we are seeking contributors to help 🙂

Continue reading

#3-6, #post-formats