Ready to get started?Download WordPress

Make WordPress Core

Updates from February, 2015 Toggle Comment Threads | Keyboard Shortcuts

  • Pascal Birchler 7:37 pm on February 25, 2015 Permalink |
    Tags: ,   

    WordPress Core Weekly 

    Hello everyone, let’s have a look at what’s going on in WordPress core! This edition covers February 19th, 2015 [31479] through February 25th, 2015 [31544].

    If you want to write the next WordPress Core Weekly summary, check out the table over at make/docs and get in touch in the #core-weekly-update Slack channel.


    • Make sure WP_Customize_Manager::theme() never returns null. [31536] #31445
    • Add theme browsing and theme switching to the Customizer. Brings into core the Customizer Theme Switcher feature plugin. You can now browse, preview, and activate themes right from the Customizer [31533] #31303


    • Provide proper label associations and descriptions throughout the network admin [31517] #38406
    • Add missing labels to Archives and Categories dropdown widgets. [31520] #18650

    Press This

    • JSON encode the URL before appending it to the bookmarklet. See #31373. [31537] #31373
    • Hard-code the minified bookmarklet js. Adding the non-minified bookmarklet to the browser bookmarks bar may have unexpected effect. #31373
    • PressThis v2, first run. [31534] #31373


    • Add orderby=description support to get_terms(). This appears as a sortable column header. [31532] #31364
    • Pass taxonomy name, not object, to edit_term_taxonomy and edited_term_taxonomy actions. [31525] #30999


    • Better image-type support checks in image unit tests. PHP can be compiled without support for certain image types. Our unit tests should be sensitive to these configurations. [31510] [31512] #31124
    • Specify globals in media JS files – it is important to denote where we are diverging from dependency injection. [31489] [31491] [31492] [31493] [31494] #28510


    Script Loader


    • Menus: Remove fixed height from .description-thin fields. [31524] #31426
    • Menus: Prevent checkboxes and radio buttons from being stretched to full width on mobile. [31523] #31425


    • Use a darker color for “No themes found” message to increase contrast. [31519] #26600
    • Add feedback for screen readers when search results are changed. [31497] #26600
    • Update the theme count when searching for installed themes, like we do on Add Themes screen. [31495] #26600


    • Add comment-author-is-site-member class to comment output for site members. [31518] #24054
    • Delegate focusin and focusout events for row actions to make sure the actions are always revealed on focus. [31509] #29765


    • Multisite: Pass a response code of 200 to wp_die() when a user is successfully added to an individual site after using the /newbloguser/ URL from an invite email. This is a user facing success message. [31514] #31224
    • Multisite: Avoid clearing stored capabilities for a user when removing their built in role in multisite. [31516] #18934
    • When creating a new user, pasting a password should update the password strength indicator. [31483] #31226


    • Improve table footer tab sequence by moving <tfoot> after <tbody>. [31513] #30914
    • Dashboard: Add a filter for the query arguments used for the Recent Posts widget. [31508] #29374
    • Quick Edit: Make date fields a bit wider. [31507] #27912
    • Use correct closing tag for “Under the Hood” header on About screen. [31503] #31402


    • Do not activate plugins on initial installation in multisite. Check is_multisite() before activating a plugin that has been installed via AJAX. Without this check, the plugin would be automatically activated on the main site of the network. [31511] #31327


    • TinyMCE wpView: don’t insert nested paragraphs when inserting embeddable URLs. [31485] #29526

    Bundled Themes

    Thanks to @afercia, @ AramZS @atimmer, @azaozz, @boonebgorges, @celloexpressions, @cfoellmann, @danielbachhuber, @dd32, @designsimpl, @dipesh.kakadiya, @DrewAPicture, @folletto, @ianmjones, @ipm-frommen, @iseulde, @janhenckens, @jeremyfelt, @jlevandowski, @joedolson, @joostdevalk, @kraftbj, @lancewillett, @mako09, @marcelomazza, @markjaquith,@michael-arestad @MikeHansenMe, @neil_pie, @NikV, @obenland, @ocean90, @PeteMall, @ravindra-pal-singh, @rachelbaker, @rianrietveld, @SergeyBiryukov, @stephdau, @stevegrunwell, @swissspidy @tyxla, @Viper007Bond, @westonruter, and @wonderboymusic for their contributions!

  • Morgan Estes 9:50 pm on February 19, 2015 Permalink |
    Tags: ,   

    WordPress Core Weekly 

    Hello everyone, and welcome to this installment of the WP Weekly Roundup! This edition covers February 11th, 2015 [31411] through February 18h, 2015 [31478].

    Right at the top of the list: the release of 4.1.1 rolled out Wednesday. You can read the changelog for full details, but here’s the overview.

    WordPress 4.1.1

    • Tag 4.1.1 [31478]
    • Bump $tinymce_version in the 4.1 branch. [31477]
    • Remove errant string. [31475]
    • About: Add changelog for 4.1.1. [31474]
    • Add SVN eol-style = native where missing. [31471]
    • Add eol-style property and normalize EOLs. [31470]
    • Bump 4.1.1 version numbers & dates. [31431]


    • Revert [31198] from the 4.1 branch, as it is an incomplete fix that introduces more problems than the tiny issue it was attempting to solve. [31468] #30725
    • Don’t try to read a non-existent Exif:Title tag in wp_read_image_metadata(), as it’s not a part of the Exif standard. [31462] #31043
    • Fix the display of Audio and Video in the Media Library when using IE8 and below. [31444] #31058
    • Prevent IE9 and lower displaying the download file dialogue when attempting to upload using the html4 Plupload handler. [31429] [31430] #31037


    • Fire nodeChanged when an embedded iframe is resized so we can adjust the editor height and other UI components. Props iseulde, [31466] #30646
    • Ensure the image toolbar stays visible when the image is much wider than the editor. Merges [31362] to the 4.1 branch. [31437] #30696
    • Select the iframe element by id. Needed as some browser extensions insert extra elements in the page. Merges [31180] to the 4.1 branch. [31436] #30785

    Bundled Themes


    • Add inline documentation to clarify the reasoning behind the various conditions that control how WP is loaded. [31463] #30935
    • Improve ‘orderby’ syntax for WP_Comment_Query[31467] #31045, #30478, #31265
    • Replace hardcoded usage of comment-page with the comment pagination base. [31459] #18084
    • Respect ‘default_option’ filters during early sanity checks in add_option() and update_option()[31473] #31047
    • Add $expiration as a parameter to the pre_set_transient_{$transient}filter. [31414] #30576
    • Restore PHP 5.2 to Travis CI. [31472] #31244
    • Return a WP_Error if an empty name is provided when registering a post type. [31450] #31134
    • Posts list table: Add a filter to disable the months dropdown. [31438] #30254
    • In paginate_links(), don’t override custom format arguments when setting up default ‘add_args’. [31433] #30831
    • Avoid a PHP Warning when add_args is passed as false to paginate_links(). [31432] #30831


    • Remove margin for hidden controls. [31460] #31330
    • Don’t focus new widgets if they are added programmatically. [31428] #31295
    • Escape Customizer links in the admin menu. Fix usage of add_query_arg(). [31427] #30952
    • Restore showing a login form inside the previewer if an user is logged out. Broken since [31370]. [31421] #31294
    • Widgets: Add return param for widgets admin page to the “Manage in Customizer” link. [31420] #30888
    • Improve [31252] to show the move-widget buttons only if there is more than one rendered sidebar. [31419] #30690


    • More careful type conversion in WP_Query is_*() methods. [31458] #24674
    • Add tests for some of WP_Query‘s sticky post logic. [31439] #27282


    • Remove title attributes from ‘About WordPress’, ‘Add New’, and ‘My Account’ items. [31456] #31324
    • Add a label for search field on front-end. [31455] #31323
    • Use require_once() to prevent a fatal error if _wp_admin_bar_init() is called twice. [31411] #31287


    • Provide a secondary sort order for wp_get_archives() when type=postbypost[31452] #30480
    • Update the default admin color scheme for more unity and refinement.
      This removes the red channel from blues and cools the grays a bit for a more cohesive and purposeful color scheme. [31422] #31234


    • Return a WP_Error if an empty name is provided when registering a taxonomy. [31449] #31135
    • Split shared taxonomy terms on term update.
      When updating an existing taxonomy term that shares its term_id with another term, we generate a new row in wp_terms and associate the updated term_taxonomy_id with the new term. This separates the terms, such that updating the name of one term does not change the name of any others. #5809

    Networks and Sites

    • Use get_admin_url() to get the correct My Sites URL without calling switch_to_blog() directly. [31448] #31314
    • Create the My Sites URL in the context of a user’s primary site.
      Switch to the user’s primary (or active) site before creating the My Sites URL. This previously linked to the current site’s dashboard, even if a user was not a member of that site. [31445] #31314


    • Use correct default values for some admin template functions. [31446] #31308
    • Rename unused argument and remove obsolete global in iframe_header(). [31443] #31309
    • _list_meta_row() should always return a string. [31442] #31310
    • Terminate JS statements in two admin files. [31440] #31311
    • Move the (recently added) .notice admin notices below the first H2, same as the .updated and .error notices. Merges [31023] to the 4.1 branch. [31434] #30885
    • Admin menu: Ensure top level menu item keeps hover color when hovering over or focusing on the submenu. [31424] #31275
    • Introduce a logout_redirect filter so the redirect destination can be changed when a user logs out. [31417] #27617


    • Use RegEx instead of DOMDocumentwhen protecting <pre> tags in WP_oEmbed::_strip_newlines(). It is incredibly difficult to maintain character encoding and whitespace when parsing viaDOMDocument. [31423] #31214
    • After [31415], make sure str_replace() only occurs once for each matched tag to avoid overwriting until <pre>s. [31416] #31214
    • Protect <pre> tags when parsing oEmbed responses in WP_oEmbed::_strip_newlines() in DOMDocument is available. [31415] #31214
    • oEmbed discovery fails on encoded link URLs: decode HTML chars in the HTML-encoded URLs that are returned. [31413] #31213

    Dev Chat Notes

    The merge period for Feature Plugins has opened. The two candidates, Customizer Theme Switcher and the revamped Press This were both approved and will be “shepherded” in over the next week.

    Also discussed were the possible switch in build tools from CSSJanus to RTLCSS (#31332), using the button element for buttons (instead of <a href="#">) and recruiting release leads for 4.3 and 4.4, with a reminder that this isn’t necessarily a developer position.

    Yeah, so, the leads are already thinking about who might lead 4.3 and 4.4. The goal was always to announce these ahead of time, and hopefully see overlap with releases, but if nothing else, the release lead for next major +n can be looking at feature plugins, tracking them, pushing them, etc.

    With 4.3 starting development in less than 3 months, now would be the time to throw your hat into the ring. I think, ideally, there is an announcement before 4.2 hits beta. This wouldn’t be about doing nothing for the next 3 months, but already getting started in terms of laying the groundwork.

    If you are interested in leading a release in 2015, now would be the time to say something. Same if you are interested in helping to lead a release in 2015.

    Tickets needing a look

    These tickets were specifically mentioned by developers looking for assistance or an extra set of eyes:

    • #31218: nav-menu.js menu item added event
    • #27282: WP_Query returns more results when there are sticky posts
    • #17817: do_action/apply_filters/etc. recursion on same filter kills underlying call
    • #31332: RTL CSS generation: Switch from CSSJanus to RTLCSS
    • #23367: Remove message parameters from admin URl’s in the browser address bar
    • #31233: Dismissable admin notices
    • #31251: Show username in wp_dropdown_users when deleting users, not display name
    • #22768: EXIF/IPTC captions should populate caption/post_excerpt on upload, not description/post_content

    Thanks to @adamsilverstein, @afercia, @azaozz, @barrykooij, @boonebgorges, @boonebgorges, @clifgriffin, @cweiske, @danielbachhuber, @dd32, @dlh, @DrewAPicture, @GregLone, @helen, @herbmillerjr, @hugobaeta, @Idealien, @ipm-frommen, @iseulde, @jdgrimes, @jeremyfelt, @johnbillio, @johnbillion, @johnjamesjacoby, @jorbin, @lancewillett, @mattheweppelsheimer, @mboynes, @melchoyce, @mgibbs18, @MikeHansenM, @morganestes, @nacin, @netweb, @norcross, @nunomorgadinho, @obenland, @ocean90, @r-a-y, @SergeyBiryukov, @simonwheatley, @sippis, @stevehickeydesign, @tywayne, @tyxla, @webord, @westonruter, and @wonderboymusic for their contributions!

  • Pascal Birchler 3:31 pm on February 11, 2015 Permalink |
    Tags: ,   

    WordPress Core Weekly 

    Hi Everyone!

    It’s time for another run-down of what’s going on in WordPress core. This edition covers February 3rd, 2015 [31332] through February 11th, 2015 [31410].

    Quick info: If you’re interested in helping out with these updates, comment below, or ping @mike on Slack! There’s a dedicated #core-weekly-update channel and you can even use a super cool script to parse the logs.

    Without further ado:


    • Improve the Customize experience on mobile. [31384] #28784
    • Introduce an API to create WP_Customize_Settings for dynamically-created settings. [31370] #30936


    • Replace $.post() calls with wp.ajax.post(), and clean up a bunch of the now unnecessary code. [31409] #29820
    • Use a positive wording for translations update notice. [31368] #28199
    • If the current user is not allowed to install/update plugins, we should return a JSON error, so it can be used by the JS handlers. [31335] #29820
    • Add capability checks to the ajax callbacks, to ensure the current user is allowed to install/update plugins. [31334] #29820
    • Add ajax-y updates to the plugin list page, and ajax-y updates and installs to the plugin card page. [31333] #29820
    • Updates: Display plugin update rows even for plugins which are not hosted by WordPress.org or the HTTP request times out on. [31382] #29583, #30767


    • oEmbed discovery fails on XHTML head links, adjust the regex to not match /. [31407] #31212



    • Replace generic “Dear user” greeting in email notifications with a more personalized one. [31403] #31217
    • Update body class when switching between admin color schemes. [31400] #30488
    • Avoid inadvertent stomping of the original $args parameter passed to plugins_api_result and themes_api_result filters in plugins_api() andthemes_api(), respectively. [31363] #29079


    • Switch to a string placeholder, as number_format_i18n() returns a string. [31402] #26553
    • Use _n() in comments_popup_link() when setting the default string to display if there are more than one comment. [31401] #26553
    • Use screen reader text instead of a title attribute in comments_popup_link. [31388] #26553


    • Don’t parse empty tax_input keys in edit_post(). [31392] #30615
    • Remove unnecessary array_shift() usage in get_terms() for better performance. [31365] #31182
    • Parse non-hierarchical tag input into term IDs before sending to wp_insert_post(). [31359] #30615
    • Update the DocBlock for wp_dropdown_categories() to reflect that the entire $args parameter array is optional instead of individual arguments. [31357] #30306
    • Use field-specific sanitization in WP_Tax_Query::transform_query(). [31346] #27810


    • WPDB: If a site is using the utf8 charset, and their version of MySQL supports utf8mb4, auto-upgrade them to utf8mb4. [31349] [31351] [31354] [31358] [31391] #21212
    • WPDB: The mysqli_query() call in wpdb::set_charset() had the parameters the wrong way around. [31374]


    • Add orderby=meta_value_num support to WP_User_Query. [31369] #27887
    • Remove leading space from the definition of a global cache group. This only applied in a rare situation during the switch_to_blog() process where no global groups were currently defined. [31348] #31243
    • Add useremail and userslugs as global cache groups. [31347] #31243


    • Editor: prevent errors in editor-expand when the Text editor is not used. [31361] #31163
    • Fix displaying long tag names in the Tags postbox. [31332] #18946
    • MCE views: Always refresh the view after updating a gallery. This allows things like caption changes to be synced, as they are tied to the attachment and not the shortcode. [31343] #31239
    • TinyMCE: ensure the image toolbar stays visible when the image is much wider than the editor. [31362] #20696

    Build/Test Tools

    • Update Travis-ci Slack notification token [31352] #30755
    • Temporarily (I hope) remove PHP 5.2 from tests being run on Travis-ci. Travis-ci has disabled PHP 5.2. This has happened before when 5.2 didn’t compile and then was restored when that was fixed. #31244

    Posts & Pages

    • Introduce 'value_field' parameter to wp_dropdown_pages(). This parameter allows developers to choose the post field that will be used to fill in the ‘option’ attribute of the generated dropdown markup. [31338] #30306, #12494
    • Always pass back the custom classes get_post_class() was called with, even if the post was not found. [31408] #22271

    Thanks to @adamsilverstein, @afercia, @ArminBraun, @azaozz, @boonebgorges, @bswatson, @Bueltge, @celloexpressions, @ChriCo, @Corphi, @cweiske, @dd32, @dlh, @DrewAPictur, @DrewAPicture, @ericlewis, @F J Kaiser, @Funkatronic, @genkisan, @helen, @hissy, @ipm-frommen, @Ipstenu, @iseulde, @jfarthing84, @joedolso, @johnbillion, @jorbin, @lgladdy, @lgladdy for the initial patch, @nacin, @netweb, @obenland, @ocean90, @pento, @SergeyBiryukov, @siobhan, @tyxla, @valendesigns, @Veritaserum, @VolodymyrC, @vortfu, @westonruter, and @wonderboymusic for their contributions!

  • Ryan Boren 7:32 am on January 29, 2015 Permalink |

    Dev Chat Summary, January 28th 





    • Jumpstart posts will be posted every Monday.
    • Weekly bug scrubs will occur on Fridays at 16:00 UTC in #core.
    • Each feature plugin will have a core mentor.


    • @drew will post a Jumpstart to make/core on Monday.
    • @mark will be the core mentor for Customizer Theme Switcher.
    • @azaozz will be the core mentor for Press This.
    • @boone will relay term splitting doc plans to the docs team this week.
    • @pento will post a Shiny Updates update post to make/core by the weekend.
    • @ryan will post to make/core about contributing to mobile flow improvements.

    Links Mentioned


    (More …)

  • Scott Taylor 9:54 pm on January 22, 2015 Permalink |
    Tags: , ,   

    The Case for JS Modules 

    I originally posted some of this content here: Split javascript files in media into modules

    The patch on that ticket breaks up the Backbone classes in media-models.js, media-views.js, media-audiovideo.js, and media-grid.js into modules and injects them via Browserify on build/watch into a built file. Let’s start at the beginning.

    Brain overload

    Files that are 1000s of lines long are hard to consume. We try to alleviate this by adding copious amounts of docs. Still, it’s a lot to look at. Ideally, we would break our files into smaller modules and then somehow join them together in a build process.

    It is common practice to serve (sometimes very large) minified files for JS and CSS that have concatenated many smaller files together and uglify’d (minified/obfuscated) them. It is no longer common or best practice to develop with huge files. We can learn a lot from emerging front end development trends, especially those from the Node/NPM community. In some cases, we can even share code.

    We’ll use Media as the main culprit, but this could apply to any “manifest” – a term I use to describe files that contain the entire public API for a feature. Something like media-views.js, it might be nice to bounce from view to view in the same file, provided you know exactly what you are looking at, what depends on what, etc.

    I have found, it is completely overwhelming for almost everyone. It would be great if each discreet piece could be viewed in isolation with its dependencies clearly stated.

    There are many ways to accomplish the splitting of large files. I want to focus on 2 of the most common.


    Backbone is one of a growing number of MV* frameworks for JavaScript. A large majority of the code related to media either belongs to a handful of Models or to the increasingly large library of Views and View Templates.

    Views are the building blocks for the presentation of Media (you know, “the Media Modal” or 4.0’s “Media Grid”).

    The main canvas on which these Views are stitched together are called Frames, which are themselves Views – tilting our use of Backbone more towards MVP, P standing for Presenter.

    We have Controllers, which are called States, but they belong to a Frame (Presenter! also a View!), so anyways…. for now….

    When we create new UIs, we are more than likely adding new Views/Templates, or updating existing Views.

    If we wanted to move from one large file to many files that each contain a class, we would create Modules.

    Grunt is a task runner. We use Grunt to build our src directory into our build directory.


    Require is a great tool for converting AMD modules into built files. Require leans on Dependency Injection in its syntax:

    ], function (Taco, Burrito, Meal) {
        var Dinner = Meal.extend({
            // taco-related code
        return Dinner;

    This syntax works great, unless you have way more dependencies. Refactoring code could unwind a module that has a lot of dependencies, but if you are just trying to convert legacy classes into a module, Require starts to get a little weird. Concrete example: Frames have a TON of dependencies.

    Require becomes a Grunt task to make one big file by recursing the dependency tree in an initial manifest. Require, by default, loads JS asynchronously, which can cause race conditions with plugins or themes that expect code to be registered on $(document).ready() or window.onload.

    Require works even if you don’t build via Grunt.


    Browserify is a tool that allows you to use Node-style modules and run them in a browser without changing from the Node syntax. Browserify requires a build for this to work.

    Using our example from above, this is the syntax for Browserify:

    var Taco = require( './models/taco.js' ),
        Burrito = require( './models/burrito.js' ),
        Meal = require( './controllers/meal.js' ),
    Dinner = Meal.extend({
        // taco-related code
    module.exports = Dinner;

    Browserify leans more towards the Service Locator pattern.

    Browserify scans the abstract syntax tree (AST) of your JS code to compile dependencies. Your modules themselves get wrapped in their own scope like so:

    (function (require, module, exports) { 

    After spending a lot of time messing around with both: I think we should use Browserify.

    Converting “Legacy” Code

    The media JS code is some of the most “modern” code in WordPress, but it still clunkily lives in huge files. To convert the code into modules, we need to make a lot of individual files (one for each Backbone class).

    We also need to make sure we maintain the existing wp.media namespaces for backwards compatibility. We don’t want any existing functionality to change, we just want to build the files differently.

    Even though the code is defined differently, wrapped in a new scope, and looks different when “built”, we can still maintain our current API design: what is publicly accessible now will remain publicly accessible.

    In the patch

    Disclaimer: this patch is for experimentation only. It will go stale probably before this post is published. It works, but it is only a playground for now. If this moves forward, it will be a laborious Subversion process to create a bunch of new files.

    I have added a folder to wp-includes/js, media, that contains the modules and the built manifests. My patch adjusts script-loader.php to use these new paths.

    media contains the following files/folders:

    views/ (with another round of subfolders)

    The build pipeline

    If you are following along with that patch and want to see this in action, run in the project root:

    npm install

    Afterwards, run:

    grunt watch

    *.manifest.js files get built into *.js files when you change a file in media/*, provided you are running the grunt watch task. The watcher will automatically call browserify:media and uglify:media when those files change. This allows you to run your site from src or build, and you will still get Browserify’d files. SCRIPT_DEBUG will either run *.js or *.min.js, just like any other minified JS in core.

    This is a proposal

    I would like to hear feedback from the overall community and certainly from our fair share of JS-trained ninjas. A common reason to *not* do something like this is the barrier to entry for new developers. I would argue in this case that the code becomes MORE readable and understandable. I was shocked myself to see how much simpler it was to absorb one piece at a time once the code was laid out in modules.

    • deltafactory 10:07 pm on January 22, 2015 Permalink | Log in to Reply

      As someone who was trying to wrap my head around wp.media as recently as yesterday (with little success), I strongly support this from a development and maintenance perspective.

      • Primoz Cigler 6:12 pm on January 23, 2015 Permalink | Log in to Reply


        I attempted several times to ‘load’ these enormous JS files to my brain in last few months. Every time with little to no success. As I am using RequireJS I would be more font of the later, but I absolutely agree with your foreseen troubles it would bring. So browserify + grunt it is, hurray!

    • Daniel Bachhuber 10:13 pm on January 22, 2015 Permalink | Log in to Reply

      I strongly support breaking apart our JavaScript. Browserify has become a new standard for the projects I’ve been working on.

    • Luis Rodrigues 10:22 pm on January 22, 2015 Permalink | Log in to Reply

      I for one applaud this initiative. There may be a couple of extra hoops to jump through, but they become virtually irrelevant with a properly configured Gruntfile to handle watching and building modules into the project.

      Big fan of Browserify, too. Browserify will handle AMD modules if you need them (using plugins like `deamdify`) and coexists with non-module dependencies much, much better than RequireJS. (Last time I got RequireJS and WP to work together, I had to mess with WP’s enqueue mechanism because the loader is rather sensitive to scripts that alter the DOM.)

    • K.Adam White 10:28 pm on January 22, 2015 Permalink | Log in to Reply

      Music to my ears, @wonderboymusic! Regarding the “barrier to entry” argument, in my experience the biggest barrier I’ve seen people hit while working with modules has been that in almost all circumstances, the complexity of setup and configuration required by a system like Require results in a front-loaded learning curve. Coming onto an existing project with a modular system is, by point of contrast, generally a pleasant experience because it is much more obvious where any particular piece of code lives.

      I’d throw in my $0.02 that since we’d need a build process anyway to ship production files, we should optimize for ease of development: whichever system requires the least work when adding a file. Webpack’s a good build tool that we’ve been using which supports both AMD and Node-style modules, as well.

    • Solinx 10:41 pm on January 22, 2015 Permalink | Log in to Reply

      Like K. Adam I found that working with modules does increase the initial barrier a bit for developers who rarely use javascript, but certainly not by much. And once the required code to work with modules is understood it makes things easier due to the clear structure and focussed content of each module.

      Currently we use AMD (require.js) and build our combined js file with Almond, but we’re strongly considering to switch to Browserify or Bower. AMD isn’t as widely supported by packages as we’d like, and Require.js appears to clash with our new general purpose build tool, Gulp.js.

    • Mike Schinkel 11:14 pm on January 22, 2015 Permalink | Log in to Reply

      I have nothing but support for this proposal. Great work!

    • faction23 1:09 am on January 23, 2015 Permalink | Log in to Reply

      Having the js broken up into modules will be great! Have you tested/considered your third option, the use of native es6 modules and then something like webpack with the 6to5 loader (es 6 to 5 transpiler)? es6 modules are finalized since last august – es6 was fully feature frozen then -and I’ve been working with 6to5 for a little bit and its rock solid. The main reason would be longer term viability. es6 modules are going to be here to stay guaranteed, plus they pretty well supersede common/amd modules…

    • Mike Schroder 1:41 am on January 23, 2015 Permalink | Log in to Reply

      This sounds most excellent.

      Thanks for putting this together!

    • Helen Hou-Sandi 4:06 pm on January 23, 2015 Permalink | Log in to Reply

      Really looking forward to some sanity in this area. Concerns I typically have about barrier to entry are mostly irrelevant here – components such as media already require a high level of understanding and some amount of experience, which makes familiarity with build tools as a requirement of development much more likely. As I’m understanding the proposal, build/watch won’t be needed if you don’t touch any involved JS.

    • Aaron Jorbin 8:42 pm on January 23, 2015 Permalink | Log in to Reply

      My concerns are the same as others, that this increases the barrier to entry. I think that as long as some documention get’s written for the core handbook that we can also reference and point to about how and why (with this post serving as a great foundation).

      One thing we will want to consider, if a file like wp-includes/js/media/models.js is going to be a generated file, we should exclude it from jshint.

    • Ben Doherty (Oomph, Inc) 12:42 am on January 25, 2015 Permalink | Log in to Reply

      You have my +1 in this effort. The media-* files are just too much to wrap one’s head around effectively, and in general we are in dire need of organization and better documentation for the entire Media Manager API so that developers can write better integrations. I don’t believe there will be much increase in barrier-to-entry by splitting these files up. As Helen said, developers who dig into this are likely to already be familiar with the build toolchain, but may not need even it when using the files for reference.

    • nikeo 3:04 pm on January 25, 2015 Permalink | Log in to Reply

      +1. Those types of workflows + tools have to be democratized. I don’t think there will be much increas in barrier-to-entry as well.

    • lmartins 10:16 pm on January 25, 2015 Permalink | Log in to Reply

      Common JS with Browserify or similar every time. Any front-end person deals with them these days, so I imagine quite accessible to any dev.

    • Per Soderlind 11:13 am on January 28, 2015 Permalink | Log in to Reply

      + 1, understanding (your) wp.media code today is hard.

    • Andrew Ozz 6:07 pm on February 2, 2015 Permalink | Log in to Reply

      Don’t think this is going to make huge difference. Generally whether you edit few places in a single file or have to open and edit several files doesn’t make a difference. Your IDE should handle both cases transparently :) However agree that it is better to have a nice file structure that somewhat matches the JS structure.

      In my mind it is more important to improve/fix the “JS structure”, i.e. this:

      The main canvas on which these Views are stitched together are called Frames, which are themselves Views – tilting our use of Backbone more towards MVP, P standing for Presenter.

      We have Controllers, which are called States, but they belong to a Frame (Presenter! also a View!), so anyways…. for now….

      I’m hoping we will get that opportunity when implementing the image flow changes.

    • Dwain Maralack 9:25 pm on February 8, 2015 Permalink | Log in to Reply

      +1 for a more logical file structure. Most of the files here will most probably only be changed by experienced / core dev’s so the barrier to entry is not a major concern. The entry barrier can easily be solved by supporting documentation.

  • Ryan Boren 3:48 pm on January 22, 2015 Permalink |  

    Dev Chat Summary, January 21st 




    • @drewapicture is the 4.2 release lead.
    • @wonderboymusic will be feature lead for a lot of media/image stuff.
    • 4.1.1 will drop within a week.
    • All 4.1 guest committers are renewed for 4.2.
    • The tentative target release date for 4.2 is April 8th.
    • Wednesday meetings will continue as usual.
    • Weekly Friday bug scrubs start next week.
    • This Week in Core posts will resume.
    • The 4.2 feature plugins are, tentatively: Press This, Customizer Theme Switcher, and Shiny Updates. Customizer Menus is a possible long shot.
    • The general focus of 4.2 will be polishing existing UIs in terms of mobile and accessibility.


    • @nacin will post about guest commit renewal on make/core.
    • @drewapicture will post weekly bug scrub times on make/core.
    • @dh-shredder will start This Week in Core posts while permanent contributors are located.
    • @johnbillion will add a page to the core handbook on development processes for mobile.
    • @pento will post about contributing to Shiny Updates on make/core.
    • All feature plugins will post an update to make/core.
    • Component maintainers will make a list of the main issues affecting their components.
    • @johnbillion will post a call for component maintainers on make/core.

    Links Mentioned


    (More …)

  • Andrew Nacin 8:54 pm on January 21, 2015 Permalink |

    Drew Jaynes is the 4.2 Release Lead 

    I’m pleased to share Drew Jaynes (@drewapicture) is the release lead for WordPress 4.2.

    Drew will be kicking off 4.2 today in about 7 minutes in #core on Slack (the regular weekly meeting). This is a follow up to yesterday’s excellent chat that I led on feature plugin development, which has highlighted a few things:

    • Menus in the customizer need additional development and user testing, and may or may not be a 4.2 candidate. Extra time here is not a bad thing.
    • Theme switching in the customizer needs user testing. It is a possible 4.2 candidate.
    • Press This has been in the wild for some time and is a possible 4.2 candidate.
    • Update improvements initially discussed for 4.1 is gonna get started in 4.2.

    As you may know, Drew led the massive year-long effort to document every hook in WordPress. This showed off his impressive management and organizational skills that we know will translate nicely to running a release. Also, don’t be fooled — while his focus has been inline docs, he’s an engineer at 10up.

    Additionally, Scott Taylor (@wonderboymusic) will be taking point as a core feature lead for a lot of media and image efforts underway, including two feature plugins (image flow and also responsive and HiDPI images), media on mobile, and such. This effort spans not only 4.2 but also 4.3 and really 2015. There will be more on all of this in the coming days.

  • Jeremy Felt 4:33 am on November 21, 2014 Permalink |

    Multisite Office Hours (Redux) 

    Several months ago, @wonderboymusic proposed office hours for Multisite. The response was great, but we kind of laxed on making it happen after the first one or two.

    After talking with a few people at WCSF last month, I’d like to fire this up again. As Scott mentioned before, there is no master plan, though there is a roadmap.

    We do have some interesting things that should be on the front of our minds:

    • What does a trusted network look like? #30145 introduced the concept and we need to figure out where to take it.
    • What kind of improvements could/should be made with a “feature as a plugin”? This may help to jump start some ideas, even if they aren’t merged into core immediately.
    • What steps should we take toward multi network? #29415 comes to mind immediately for a likely inclusion in 4.2. #30294 is another example.
    • Unit tests. I’d like to continue doing things like #30080 to really expand how we’re testing multisite.

    Let’s do our first office hours at 20:00 UTC this coming Tuesday (November 25). We can decide then if it’s appropriate.

    /cc’ing some that are likely interested – @ethitter, @johnjamesjacoby, @johnbillion, @ipstenu, @earnjam – but this is by no means a complete list.

    Please stop by in #core on Tuesday and comment away on this post with other things you have your eyes on.

  • Mike Schroder 8:49 am on November 14, 2014 Permalink |
    Tags: ,   

    WordPress Core Weekly 

    Hi Everyone!

    It’s that time again: WordPress Core Weekly is here. This is a catchup post and covers all commits since the last post up until 11/9/2014.

    First, a couple quick notes!


    • Do not create shared taxonomy terms. [30240] #21950; See #5809.
    • Split shared taxonomy terms during term update. [30238] [30239] [30241] #5809
    • Don’t force child_of=0 for non-hierarchical taxonomies in get_terms(). [30265] #30275
    • In get_adjacent_post(), $excluded_terms should check term_id rather than term_taxonom_id. [30263] #29663, #22112.
    • Allow resource_type to be specified in get_ancestors(). Being explicit about resource type (taxonomy vs post_type) allows for the proper resolution of conflicts when a taxonomy and post_type share a slug. [30141] #15029
    • In wp_insert_term(), clean up accidental duplicate terms after insert. [30238] See #22023, #5809.
    • Add some unit tests for is_object_in_term(). These tests check a number of the ways that different kinds of values for $terms (integers that match term_id, strings that match term_id or name or slug) are handled. [30204] #29467
    • In in_object_in_term(), only check numeric string values against term_id. [30205] #29467
    • Introduce term_template param to get_the_taxonomies() to allow theme and plugin authors to specify the formatting on term links as they are parsed into the taxonomy list. [30209] See #27238.
    • Allow duplicate slugs across different post types. [30158] #18962
    • In get_terms(), do not override hierarchical and pad_count when parent is present. The previous behavior resulted in descendant terms being improperly excluded from the results when passing a parent, even when hierarchical had been set to true. [30107] #29815
    • Clean up get_term_by() caching, fix cache key/group modification that was missed in [30073], and update unit tests. [30108] #21760

    Twenty Fifteen


    • Bump db_version and add upgrade routine for schema change in [30056]. [30121] [30134] #22023
    • WPDB’s __get() function should perform strict comparisons against member names. [30292]


    • Allow revision Backbone classes to be used on pages other than revision.php. [30128] #30221
    • Add a single responsibility function for outputting Revisions JS templates: wp_print_revision_templates(). Use it in wp-admin/revision.php. [30129] #30220
    • Revisions modules should not rely on global settings; only pass in global settings on init, this allows the classes to be used agnostically elsewhere. [30131] #30219


    • Pass all updated meta IDs to filters in update_metadata(). [30140] #11683
    • Unserialize get_metadata() results when key is omitted. [30115] #15030



    • Display error message when Media Library upload fails. [30156] [30177] #29891
    • Delete admin_created_user_subject() rather than deprecate. As it was never used as anything more than a callback to a filter before the MU merge, and is only available in user-new.php in multisite, it is safe to remove this function entirely. [30176] #29915


    • Improve/introduce Customizer JavaScript models for Controls, Sections, and Panels, along with a reference. [30102] see #28032, #28579, #28580, #28650, #28709, #29758. Fixes #29529.
    • Improve ColorControl‘s wpColorPicker to update UI based on setting changes. Update Twenty Fifteen’s colorScheme control to properly interact with the API, using wp.customize.control(). [30126] #30031
    • Add stable sorting for panels, sections and controls in JS. Improve sorting in PHP. [30214] #30225
    • Bind input and propertychange events for range input types. [30219] #30223
    • Twenty Fourteen: Make featured content in Customizer contextual to the front page. [30143] #29578


    • Introduce new template functions for archive titles and descriptions: [30223] #21995
      • get_the_archive_title() and the_archive_title() for returning/displaying the title of the current term, date, post type, post format, or author archive.
      • get_the_archive_description() and the_archive_description() for returning/displaying the description associated with the current term archive.
    • In get_page_children(), only check $page->ancestors once to avoid duplicates when the function recurses. Adds an argument, $ancestors. [30246] #18962
    • Allow get_pages(), with child_of passed to it, to work with interrupted hierarchies. [30159] #18962

    Thanks to @afercia, @avryl, @azaozz, @bobbingwide, @boonebgorges, @bradyvercher, @Caspie, @celloexpressions, @dancameron, @davidakennedy, @davidjlaietta, @dikiy_forester, @dlh, @donutz, @DrewAPicture, @ericlewis, @filosofo, @florianziegler, @garyc40, @gcorne, @greuben, @hereswhatidid, @iamtakashi, @iandstewart, @imath, @Jayjdk, @jeremyfelt, @jesin, @joedolson, @johnbillion, @jorbin, @kitchin, @kovshenin, @kraftbj, @kurtpayne, @lancewillett, @landakram, @loushou, @markjaquith, @mattkeys, @mattwiebe, @mboynes, @MikeHansenMe, @mlteal, @mordauk, @morganestes, @nacin, @NikV, @nobinobi, @obenland, @ocean90, @pento, @philiparthurmoore, @realloc, @rmccue, @ryankienstra, @sakinshrestha, @SergeyBiryukov, @slobodanmanic, @TobiasBg, @tollmanz, @tywayne, @voldemortensen, @wedi, @westonruter, and @wonderboymusic for their core contributions!

    Revisions covered: [30094] to [30292]. 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.1.

  • Ryan Boren 1:42 am on November 6, 2014 Permalink |  

    Dev Chat Summary, November 5th 




    • Beta 1
    • Feature plugin merge window


    • Extend the feature plugin merge window to Friday, or later.
    • Tag Beta 1 on Friday, or later.
    • Do a scrub of enhancement tickets this week, particularly customizer tickets. 1600 UTC tomorrow (Nov. 6) was suggested.
    • Hook recursion, #17817, will be discussed further after beta 1 with the aim of having it ready for early 4.2.
    • Pending the final call of @ johnbillion, the full UI for the session manager will come later (and will be moved into a plugin in the plugin repository). @jorbin will work up a patch that adds a “Sign out everywhere else” button along with killing all other sessions on password change and capturing data for a future UI.

    Uncertainties, Ambiguities, Do Betters

    • Shiny Updates may be punted in whole or in part. The necessary folks are preoccupied.
    • The Session Manager UI was debated and will likely change for 4.1.
    • “We need guidelines for how we handle feature plugins. It’s been really haphazard, and it has affected our ability to get the features in front of a lot of people.”
    • There is skepticism that merge and Beta 1 will happen this week.


    • @markjaquith will do a merge request post for Focus on make/core.
    • @jorbin will work up a patch that adds a “Sign out everywhere else” button along with killing all other sessions on password change and capturing data for a future UI.
    • @nacin will leave feedback on #29395
    • @drew will look at #21483

    Links Mentioned



    drew [15:10]
    Seems like there’s more than a few Customizer-related enhancements. @celloexpressions: ya’ll have an idea about what could be close and what might need to be punted?

    celloexpressions [15:10]
    Most of the customizer stuff has been ready for/waiting for commit or further feedback for a while

    celloexpressions [15:11]
    A couple aren’t quite there, but we want to get in if we can because they enhance Twenty Fifteen

    Hook Recursion

    #17817: do_action/apply_filters/etc. recursion on same filter kills underlying call

    drew [15:18]
    This is quite likely 4.2-early, but could use eyes-on for unit test coverage and regression testing,

    jbrinley [15:19]
    To _briefly_ answer (as well as I can), the three questions in the agenda:

    jbrinley [15:19]
    Is there enough unit test coverage?

    I don’t know.

    jbrinley [15:19]
    Does it break plugins which interact with $wp_filter and $wp_actions directly (eg accessing the nested arrays)?

    The patch doesn’t touch $wp_actions. $merged_filters is removed. The $wp_filter array will contain WP_Hook objects instead of nested arrays. Those objects can still be accessed as an array, albeit with some of the quirks that come with the ArrayAccess interface (e.g., you can’t indirectly set elements).

    Does it “fix” any existing behavior which could be seen as a regression?

    Currently, let’s say you have a callback at priority 10. In that, you set another callback with priority 1. The latter ends up running after the former. This patch would change that. Similarly, if you have something at priority 10 and something at priority 11, but the priority 10 callback end up calling the hook recursively, the priority 11 callback won’t run for the outer loop. This patch would change that.

    nacin [15:20]
    As this is definitely not 4.1 (sorry @jbrinley! though I know you know that), can we sit on this until after beta is out and then chat more later this month? This is a good briefing of things as it stands, and I hope a few of us can pick it up soon, but there are lots of other things on everyone’s plate at the moment.

    drew [15:21]
    yep, sounds good @nacin



    drew [15:23]
    @mark: Any update on posting the merge request update on make/core?

    mark [15:23]
    Got sidetracked yesterday. Will do that now.

    Since it’s such a visual thing, I’m just gonna make a video that shows it off and talks through some of the decisions.

    drew [15:24]
    Great. Sounds like the patch is looking pretty good too.

    azaozz [15:25]
    yes, patch is good. May need some more around interactions with the old DFW

    boren [15:25]
    Has it been flow tested on mobile lately, to make sure it doesn’t break anything?

    azaozz [15:26]
    New DFW is pretty much disabled on mobile because of the screen size

    janneke [15:26]
    azaozz: Right, I work on that. Also maybe move the button out.

    janneke [15:26]
    Yeah, it’s disabled…

    psoluch [15:26]
    joined #core

    ginsterbusch [15:27]
    @drew + @mark Hope it doesnt break a11y

    janneke [15:27]
    Don’t think so, but please test. :simple_smile:

    boren [15:28]
    A visual record of a mobile flow would demonstrate that it is indeed disabled for mobile.

    mark [15:28]
    We addressed keyboard accessibility. But please do advise if we missed something.

    azaozz [15:28]
    It doesn’t change anything for accessibility.

    mark [15:28]
    We addressed keyboard accessibility. But please do advise if we missed something.

    azaozz [15:28]
    It doesn’t change anything for accessibility.

    azaozz [15:28]
    For the UI outside of the editor

    boren [15:29]
    A feature plugin shouldn’t break mobile or accessibility the moment it lands.

    boren [15:30]
    I’m not too worried about mobile with Focus, but we don’t have a good record here and I’d like to improve it.

    azaozz [15:31]
    Ryan, right, DFW v2.0 is not loaded on mobile and on old browsers, IE < 9 (edited)

    gokejnr [15:31]
    joined #core

    boren [15:31]
    Someone tell me that with a visual record.

    boren [15:31]

    mark [15:31]
    We just need to verify that for sure. Yup.

    mark [15:32]
    I learned you can tether an iPhone and record video on its screen, so I’ll try that.

    boren [15:32]
    Screenshots would probably be good enough for mobile in this case, but cool.

    ginsterbusch [15:33]
    @mark a11y is not just about keyboard. its also eg. about folks not being able to quickly shift *their* focus (viewing field) to something else. and reading through the ticket doesnt really indicate its an automated or a “click this button to”-feature right now.

    janneke [15:33]
    The button still needs to be removed I think, but I mentioned before I’ll redo that. :simple_smile:

    Sessions UI

    #30264: Users should have a UI for managing sessions

    jorbin [15:41]
    For #30264@johnbillion is supposed to be working up a patch. I’ll check with him and if he needs help, will take over. Otherwise I think the only piece we are waiting on is the API on wordpress.org that @nacin is still working on.

    jorbin [15:42]
    User testing of the feature at WCSF only identified some enhancments we can do to make it more mobile friendly, otherwise it was very well received. Note that it still works fine, but the experience on mobile can be made better (edited)

    drew [15:43]
    @jorbin: Were there still UI concerns with the single vs many sessions problem?

    boren [15:43]
    I know it is a small feature, but this thing wasn’t really a feature plugin. It’s not in the plugin dir, the slug collides with an existing plugin, and hearing “the experience on mobile can be made better” is a bit aggravating.

    jorbin [15:44]
    Not that I know of, but if there are it seems like something we can iron out in beta

    boren [15:44]
    Iron it out before merge.

    boren [15:45]
    Otherwise these aren’t feature plugins, they’re blobs of code on github that are merged without criteria.

    nacin [15:45]
    I’m still kind of tempted to bring it in as a single “Sign out of other sessions” button with no extra UI for 4.1, and continue to play with it for 4.2.

    nacin [15:45]
    Identifying browsers and locations is no small thing.

    jorbin [15:46]
    I hate that idea. I think it adds a button without any context for people to understand “why”

    mark [15:46]
    Context could be added.

    jorbin [15:46]
    The context is the other sessions

    nacin [15:46]

    • Sign out all other sessions *

    Lost your phone? Left yourself logged in on a public computer? Need a way to sign out everywhere except your current browser? This is for you.
    [ Sign out all other sessions ]

    mark [15:46]
    Was going to point to Slack, yeah.

    drew [15:47]
    That’s also not say that you can’t just specify the number of other session without spitting out the fine-grained details.

    mark [15:47]
    And the context could additionally be “You are signed into this site in %d other locations.”

    drew [15:47]

    chriscct7 [15:47]
    Yeah I like that idea

    drew [15:48]
    Either way, I agree with @nacin that continuing to flesh out the UI/plugin for a future release might be the smartest way to go. (edited)

    nacin [15:48]
    I think an actual number is possibly more confusing, because we can’t tell them context, and would consider just showing the Slack-like UI if it’s > 1.

    jorbin [15:48]
    That seems confusing to me. %d doesn’t really help me as nacin is pointing out

    jorbin [15:48]
    ok, so is the decision that we punt?

    nacin [15:49]
    I’m not advocating punting necessarily, I just saw an opening that would allow us to provide immediate user benefit and try to further improve the overall UX and data we can provide.

    mattheweppelsheimer [15:49]
    +1 to a Slack-like explanation without %d sessions, in 4.1

    drew [15:49]
    I think punt is still up to @johnbillion, but as it is now, that would be my recommendation (in terms of the detailed UI)

    georgestephanis [15:49]
    I’d like to see some user testing sessions on the ux of it to see if / how much it is confusing to normal users.

    stephdau [15:49]
    on the +1 side too. Seems the friendliest, while addressing an immediate need.

    nacin [15:50]
    Also, I’d suggest: “If you think you were compromised, you should change your password. This will also sign you out everywhere.” (And on password change, I don’t know if we clear out all of their sessions, but we should, since they’re dead at that point.)

    jorbin [15:50]
    If we go that route, we should start capturing the UA string and other data in 4.1 so that we have less “unknowns” displayed

    drew [15:50]
    @jorbin: Can you possibly work on a patch for the alternate approach?

    nacin [15:51]
    As a replacement for %d, something like this, perhaps something like this, so as not to completely terrify them: `<small>You are signed into this site in %d other locations. This could be a different browser on your computer, your phone, or another computer.</small>”

    nacin [15:51]
    I’m not against capturing more data now.

    boren [15:51]
    This is the correct repo, yes? https://github.com/johnbillion/wp-session-manager

    Contribute to wp-session-manager development by creating an account on GitHub.

    drew [15:51]
    @boren yes

    chriscct7 [15:51]
    boren: yes

    boren [15:51]
    Last updated 23 days ago?

    jorbin [15:51]
    I can work up the alternate patch based on this discussion

    georgestephanis [15:51]
    @nacin: Or the same browser that had its cookies purged, even.

    boren [15:51]
    Not in the plugin repo.

    boren [15:51]
    Why are we even talking about it?

    chriscct7 [15:51]
    name conflict on it

    chriscct7 [15:51]
    its a feature plugin for 4.1

    georgestephanis [15:51]
    So let’s give it a different slug.

    georgestephanis [15:52]
    +lots to getting these things into the repo as early as possible.

    georgestephanis [15:52]
    Better discoverability for feature plugins would be super-handy.

    mark [15:53]
    We need guidelines for how we handle feature plugins. It’s been really haphazard, and it has affected our ability to get the features in front of a lot of people.

    jorbin [15:55]
    @johnbillion will need to make the final call, but it sounds like the decision is: Full UI will come later (and will be moved into a plugin in the plugin repositroy), I will work up a patch that adds a “Sign out everywhere else” button along with killing all other sessions on password change and capturing data for a future UI. Any objections to this plan?

    sabreuse [15:55]
    I’ve thought about session-by-session, and I agree that it feels plugin-like to me.

    sabreuse [15:55]
    But +1 for an easy “sign me out everywhere else”

    drew [15:55]
    @jorbin I think that sounds reasonable. If it’s not where we need it to be by Friday, we can wait.

    mark [15:55]
    If a feature plugin effort just results in a well-crafted plugin, that’s not a terrible outcome.

    stephdau [15:55]
    @mark @georgestephanis : we could at least use a standard prefix, to “ensure” slug uniqueness: wpf- or something

    Shiny Updates

    Smooth installation and updating of plugins and themes

    drew [15:57]
    It’s my understanding the decision was made at WCSF to go with shiny installs and leave shiny updates for later

    nacin [15:57]
    Correct. Updates can already be done in bulk, while installs cannot.
    However, all of the people most familiar with the updates code are tied up right now. Beta 1 is unlikely for what we want.

    It’s possible some stuff can be aligned by next week, and that’s up to John if he wants to accept some discrete changes.

    drew [15:58]
    @nacin: OK. So are you thinking punt for the whole thing?

    nacin [15:59]
    Right now, I’m not thinking about it. I may have a better idea come Friday.

    FS Credentials Modal

    #29820: Smooth installation and updating of plugins and themes

    #29395: Site Language: Install translations on the fly

    nacin [16:01]
    FS credentials is tied into updates/installs more than language.

    nacin [16:02]
    While it’s nice-to-have for language, if language installs can only happen with ‘direct’, I’m not going to cry.

    drew [16:02]
    Can you leave some feedback to that effect on 29395?

    nacin [16:05]
    Sure. @ocean90 is it already good to land, otherwise?

    ocean90 [16:06]
    If we can ignore the FS credentials, yes

    Taxonomy Roadmap


    #5809: Updating a term in one taxonomy affects the term in every taxonomy

    boone [16:09]
    I also created some new tickets and dug up some oldies to reflect next steps in the extended Taxonomy Journey

    drew [16:09]
    @boone: Is there a specific report where people can follow progress on that roadmap?

    drew [16:09]16:09
    Or just the Taxonomy component?

    boone [16:09]
    No. Taxonomy component is best for now.
    In the next week I’ll write up a make/core post with some updates and some thoughts about the future

    boone [16:10]
    that’ll have links to relevant tickets

    nacin [16:11]
    some of the stuff that went into this had to do with properly handling DB replication lag and such, just to give you an idea.

    mark [16:11]
    Yes, this is the equivalent of us building a rocket to go to McDonalds and then disassembling it while in flight.

    Twenty Fifteen

    drew [16:14]
    Apparently we’re looking pretty good as we approach beta.

    iandstewart [16:14]
    It’s looking pretty good
    we have one milestoned bug with expanding widgets that we’re still trying to figure out
    and there are some template tag and customizer enhancements that’d be nice to have solid
    but it’s in good shape
    @obenland: did you want to chime in on template tags?

    obenland [16:16]
    Sure. So there are only very few pieces left after a very productive few days at wcsf

    obenland [16:17]
    One is #29890 which @helen is looking at

    #29890: Make menu descriptions available to be displayed on the front-end

    obenland [16:17]
    Then we have #29808 with two proposed patches

    #29808: Post/paging navigation template tags

    obenland [16:18]
    https://core.trac.wordpress.org/attachment/ticket/29808/29808.8.diff fixing some some bugs and simplifying bits, as well as changing the screen reader text to an h2 as requested by the a11y team (edited)

    obenland [16:18]
    And https://core.trac.wordpress.org/attachment/ticket/29808/29808.9.diff which would add parity between post and comment navigation template tags (edited)
    Between 29808.9.diff and 29890 we could remove two callbacks from Twenty Fifteen
    and have a nice set of theme api improvements in 4.1

    iandstewart [16:22]
    #29988 would also be a nice improvement that depends on a few other patches outside of the theme (edited)

    #29988: Twenty Fifteen: Use JS/postMessage to update the color scheme instead of triggering a page refresh

    ocean90 [16:25]
    For the record, 29988.patch will not land in. We have new tickets for this where some are already fixed. But still needs some work. Or a review by me. (edited)

    westonruter [16:25]
    That’s right. The existing patch on 29988 is a standalone proof of concept.

    Bug Scrubs

    drew [16:27]
    We had kind of lackluster effort on the Friday bug scrubs the last couple of weeks due to WCSF/summit stuff.

    As discussed a little bit ago, I’d like to do an enhancement scrub tomorrow morning-ish to see if we can’t clear out some of those outstanding tickets. Any takers for probably 11:00 am EST tomorrow in here?

    drew [16:29]
    I guess 16:00 UTC

    Open Mic

    kraft [16:32]
    Would still love to see feedback on this UI adjustment for default categories: https://core.trac.wordpress.org/ticket/26268 :simple_smile:

    #26268: Add UI to Category page to indicate default category

    drew [16:32]
    I think @helen had some feedback on 26268 but she had to go. I’m not convinced that’s ready for primetime in terms of flow.

    chriscct7 [16:34]
    If a core committer has a couple minutes, got a running list of tickets that are ready to be committed here: https://make.wordpress.org/core/2014/11/03/open-update-thread/#comment-20901

    celloexpressions [16:35]
    #21483 would also benefit from feedback. In addition to UI and code, could use docs help from @drew, has an audio/video issue for @wonderboymusic

    #21483: Refactor Customizer Upload, Image, and Background Image controls to leverage the media library/modal

    drew [16:37]
    @celloexpressions: OK, I can take a look.

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