WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Updates from April, 2014 Toggle Comment Threads | Keyboard Shortcuts

  • Helen Hou-Sandi 3:41 am on September 1, 2014 Permalink | Log in to leave a Comment  

    4.0 release plan and 8/27 meeting summary 

    Per dev chat on 8/27 (summary below), we are targeting a release of 16:00 UTC on 2014/09/03, kicking off at 14:00 UTC on 2014/09/03 in #wordpress-dev. There are a number of steps to go through, including running unit tests, checking build, and testing various update and installation scenarios. We’ll also do a dry run at the same time on Tuesday, 9/2, before we enter a 24 hour code freeze.

    I’d also like to meet at 18:00 UTC on 2014/09/01 in #wordpress-dev to clear out all open tickets for 4.0 and do an RC2. It is a holiday (Labor Day) in the US, but I will be around throughout the day, as will other committers and contributors.

    Summary of 8/27 dev chat (IRC log):

    (More …)

     
  • Scott Taylor 2:07 am on August 29, 2014 Permalink | Log in to leave a Comment
    Tags:   

    A more powerful ORDER BY in WordPress 4.0 

    orderby is the argument passed to WP_Query to tell it what column to sort on when it is creating the ORDER BY clause for its generated SQL. The default value for orderby is post_date.

    The default sort order for a column in MySQL is ASC (ascending), with smallest values first. For the reverse, DESC is used. You can sort on multiple columns, and each column can have its own sort order.

    The default value for the order argument inside WP_Query is DESC. ~23% of the internet automatically queries posts in reverse chronological order because of this. order can only be one of 2 values: DESC or ASC.

    orderby accepts a string, representing a column on which to sort:

    $q = new WP_Query( array( 'orderby' => 'post_title' ) );
    
    // or an alias
    $q = new WP_Query( array( 'orderby' => 'title' ) );
    

    Both will produce an ORDER BY clause like:

    ORDER BY post_title DESC
    

    orderby will also parse a space-delimited set of columns:

    $q = new WP_Query( array( 'orderby' => 'title author' ) );
    

    Prior to 4.0, there was a problem: the value for order would only be applied to the last value that you passed in that space-delimited list, producing an ORDER BY clause like:

    ORDER BY post_title, post_author DESC
    

    Remember that the default sort order for a column in MySQL is ASC, so queries like that can get weird real fast and produce unexpected/unpredictable results. If no value is passed for order for a column in the generated SQL, the column will be sorted in ASC order. This was not so clear to all developers. #26042 was a joy to debug.

    In 4.0, when you pass a space-delimited set of values, your sole value for order will be applied to all of your values that are parsed for orderby. This was fixed in [28541].

    So that’s pretty good, but it doesn’t allow you granular control over the sort order for each column. The syntax doesn’t allow itself much room for extending.

    Enter [29027].

    In 4.0, you can now pass an array to WP_Query as the value for orderby. The syntax looks like:

    $q = new WP_Query( array( 'orderby' => array( 'title' => 'DESC', 'menu_order' => 'ASC' ) ) );
    

    This allows you to control the generation of the ORDER BY clause with more specificity:

    ORDER BY post_title DESC, menu_order ASC
    

    Pre-4.0, you would have had to use some gnarly filters on the SQL statement or a specific clause. No bueno.

    To see the internals, check out the new protected methods in WP_Query: ->parse_order() and ->parse_orderby.

    Happy WP_Querying!

     
  • Nick Halsey 1:58 am on July 8, 2014 Permalink | Log in to leave a Comment
    Tags: , , customize   

    Customizer Improvements in 4.0 

    Building on the addition of Widgets to the Customizer in 3.9, and alongside my GSoC Menu Customizer project, @westonruter, @ocean90 and I have been working on a series of Customizer improvements for 4.0. In this post, I’ll summarize the changes and proposed changes that we’d like to get in before beta. Anything with an asterisk (*) still needs to be committed but has a patch. Keep in mind that everything here is liable to change before 4.0 is released.

    We currently have eight enhancements and feature requests that need to be completed before beta, but half of them are already marked for commit and all have patches. If you’re interested in helping out with these changes, we could still use help reviewing and testing many of them (especially for UI/UX). Huge thanks to everyone who’s helped out so far this cycle.

    Terminology Notes

    We recently renamed the Appearance trac component to Customize. I’d like to clarify a few things regarding terminology used to describe the Customizer:

    • We’re shifting toward using “Customizer” rather than “Theme Customizer”, as it isn’t necessarily theme-specific (though most of its uses currently are).
    • “Customize” is the action, “Customizer” is the thing. Most UI elements use “Customize” or “customizing”, but most documentation should probably use “Customizer”. If you’re questioning which to use, consider whether you’re looking for a noun or a verb and pick accordingly. Feel free to conjugate the verb form (eg. “customizing”).
    • “Customize” could refer to anything. That’s the point; it could be used to customize any part of a site. The Customizer can be used for anything, and we’d like to encourage more experimentation with different uses of the Customizer.

    UI Changes

    In 4.0, most of the Customizer UI changes are for the Customizer itself; the user experience inside the Customizer. I’m expecting a focus on the experience of accessing and navigating through the Customizer in future releases. In 4.0:

    • Widget areas are all grouped into a “Widgets” context, implemented via the new “Panels” API. Panels are a way to group Customizer sections, just like sections are a way to group controls. Panels slide over to the side, rather than expanding down, and contain vertically-expanding sub-sections. This could use some more work on the UI/UX side, see #27406 for details.
    • Only show “You are previewing / [theme name]” and the theme details & screenshot section when the Customizer is previewing an inactive theme. Otherwise, show “You are customizing / [site title]“, with a short description of the customizer. This matches panel headings, which are displayed as “You are customizing / [panel title]“, with the panel description as that heading section’s contents. #28550.
    • Replace Customizer close button with an “X” icon. This fits better with the arrow icon used to exit panels and makes the Customizer controls feel more like a modal/panel that is contextual to the front-end of the site, rather than a confusing mix between the admin and the front-end. We’d also replace the mess of buttons in the theme-install previewer (which looks like the Customizer) with icons and move them around. #28655.
    • Prevent loss of unsaved changes in the Customizer by warning users with an AYS if they try to close the customizer and there are unsaved changes. #25439.
    • Always return to the screen that the Customizer was opened from in the admin, like on the front-end. Look for more work here in the future. #25457.
    • All core customizer controls now support descriptions (#27981), complementing the ability to add descriptions to sections and panels. We could potentially add descriptions to some core controls if they seem needed, might want to do a UI/UX audit of the core Customizer controls and/or user testing.

    Here’s a screencast demonstrating some of these UI changes:

    API Additions & Improvements

    Customizer Panels

    The Customizer now includes a new way to group options together: panels. Just like a section is a container for controls, a panel is a container for sections. This was implemented in #27406. The Panels API is easy-to-use and works almost identically to the existing customizer section API. Add a panel with the following, within the customize_register action:

    $wp_customize->add_panel( 'panel_id', array(
    	'priority'       => 10,
    	'capability'     => 'edit_theme_options',
    	'theme_supports' => '',
    	'title'          => '',
    	'description'    => '',
    ) );

    As always, only use the arguments where you aren’t using the default values. Note that the panel will not be displayed unless sections are assigned to it. To add a section to a panel, just use the panel id for the new panel argument:

    $wp_customize->add_section( 'section_id', array(
    	'priority'       => 10,
    	'capability'     => 'edit_theme_options',
    	'theme_supports' => '',
    	'title'          => '',
    	'description'    => '',
    	'panel'  => 'panel_id',
    ) );

    You may notice that $wp_customize->add_panel and $wp_customize->add_section have the same arguments (other than panel, of course). This is because panels are a special type of section; technically speaking, WP_Customize_Panel extends WP_Customize_Section. Your sections are backwards-compatible: you can add the panel argument to existing sections without issues. However, you do need to check for the existence of WP_Customize_Manager->add_panel() if you’re maintaining pre-4.0 compatibility. As with Customizer Sections, you can access and modify Panels via:

    • $wp_customize->get_panel( $id );
    • $wp_customize->remove_panel( $id );

    New Built-in Customizer Controls

    WordPress core now provides support for a much wider array of Customizer controls. Implemented in #28477, these changes eliminate the need to create custom controls for most common use cases. The textarea type is now supported in core. For any type of input that uses an input element, you can simply specify the type attribute using the type parameter of $wp_customize->add_control().
    Here’s an example:

    $wp_customize->add_control( 'setting_id', array(
    	'type'     => 'url',
    	'priority' => 10,
    	'section'  => 'title_tagline',
    	'label'    => 'URL Field',
    ) );
    

    Which results in the following markup in the Customizer:

    <li id="customize-control-setting_id" class="customize-control customize-control-url">
    	<label>
    		<span class="customize-control-title">URL Field</span>
    		<input type="url" value="" data-customize-setting-link="setting_id">
    	</label>
    </li>
    

    This is pretty powerful, as you can now use the built-in WP_Customize_Control for most common use-cases rather than creating a custom control. But what about input types like number and range that require additional attributes like min, max, and step?

    New Built-in Customizer Control Parameters

    First of all, all of the built-in Customizer controls (including the custom controls such as WP_Customizer_Color_Control) now support descriptions, just like Customizer sections have descriptions (see #27981). This was much-needed and allows for inline help text at the control level.

    More interestingly, to complement the new support for arbitrary input types, a new input_attrs parameter allows you to add attributes to the input element (also implemented in #28477). This extends beyond just using min, max, and step for number and range, to the ability to add custom classes, placeholders, the pattern attribute, and anything else you need to the input element. Here’s an example:

    $wp_customize->add_control( 'setting_id', array(
    	'type'        => 'range',
    	'priority'    => 10,
    	'section'     => 'title_tagline',
    	'label'       => 'Range',
    	'description' => 'This is the range control description.',
    	'input_attrs' => array(
    		'min'   => 0,
    		'max'   => 10,
    		'step'  => 2,
    		'class' => 'test-class test',
    		'style' => 'color: #0a0',
    	),
    ) );

    Which results in the following markup in the Customizer:

    <li id="customize-control-setting_id" class="customize-control customize-control-range">
    	<label>
    		<span class="customize-control-title">Range</span>
    		<strong><span class="description customize-control-description">This is the range control description.</span></strong>
    		<input type="range" min="0" max="10" step="2" class="test-class test" style="color: #0a0;" value="" data-customize-setting-link="setting_id">
    	</label>
    </li>
    

    Which displays as follows (in Chrome 35):

    customizer-4.0-range-control

    The ability to add classes is particularly useful if you need to target specific controls with CSS or JS, but you don’t need any special markup. I’m using this in the Menu Customizer for the Menu Name field, which is just an ordinary text control with a special setting type.

    Contextual Controls

    Customizer controls can now be displayed or hidden based on the Customizer’s preview context. For example, options that are only relevant to the front page can be shown only when the user is previewing their front page in the Customizer (see #27993). This is already implemented in core for Widgets; Widgets have always been contextually faded and shown/hidden based on their visibility in the preview, but this functionality is now built off of the core active_callback API in both PHP and JS. There are three different ways to specify whether a given control should only be displayed in a certain context. The first, and most straightforward, is to use the active_callback argument in $wp_customize->add_control().

    $wp_customize->add_control( 'front_page_greeting', array(
    	'label'           => __( 'Greeting' ),
    	'section'         => 'title_tagline',
    	'active_callback' => 'is_front_page',
    ) );

    Note that you may use either built-in conditional functions or a custom function. If you have a custom control (via a subclass of WP_Customize_Control) and a custom callback function, you can skip the active_callback argument and override the active_callback method instead:

    class WP_Greeting_Control extends WP_Customize_Control {
    	// ...
    
    	function active_callback() {
    		return is_front_page();
    	}
    }

    Finally, the customize_control_active filter will override all of the other active callback options and may be a better solution in certain cases (note that this particular example will be avoidable with future work on expanding the Customizer’s JS API, and does not hide the title_tagline section, only the controls in it):

    function title_tagline_control_filter( $active, $control ) {
    	if ( 'title_tagline' === $control->section ) {
    		$active = is_front_page();
    	}
    	return $active;
    }
    add_filter( 'customize_control_active', 'title_tagline_control_filter', 10, 2 );
    

    In addition to the PHP API for contextual controls, you can override the control-visibility-toggle function on the JS side. By default, controls will slideUp and slideDown as they become visible or hidden when the Customizer preview is navigated. If you’re familiar with the Customizer control JS API (see wp-admin/js/customize-controls.js, and wp.customize.Control), the Widgets implementation of a custom toggle function is a good example:

    api.Widgets.WidgetControl = api.Control.extend({
    // ...
    	/**
    	* Update widget control to indicate whether it is currently rendered.
    	*
    	* Overrides api.Control.toggle()
    	*
    	* <a href='http://profiles.wordpress.org/param' class='mention'>@param</a> {Boolean} active
    	*/
    	toggle: function ( active ) {
    		this.container.toggleClass( 'widget-rendered', active );
    	},
    // ...
    ) };
    
    /**
     * Extends wp.customize.controlConstructor with control constructor for widget_form.
     */
    $.extend( api.controlConstructor, {
    	widget_form: api.Widgets.WidgetControl,
    } );
    

    Changes to the customize_update_ and customize_preview_ Actions

    You probably already know that the Customizer supports both option and theme_mod types for settings. But did you know that you can register arbitrary types? Since this is generally undocumented, I’ll show how it works (this has been in place since 3.4):

    $wp_customize->add_setting( 'setting_id', array(
    	'type'                 => 'custom_type',
    	'capability'           => 'edit_theme_options',
    	'theme_supports'       => '',
    	'default'              => '',
    	'transport'            => 'refresh',
    	'sanitize_callback'    => '',
    	'sanitize_js_callback' => '',
    ) );

    There are a few actions that you can use to handle saving and previewing of custom types (option and theme_mod are handled automatically). Namely, customize_update_$type and customize_preview_$type are useful here. Previously, the value of the setting was passed to these actions, but there was no context. In 4.0, via #27979, the WP_Customize_Setting instance is passed to these actions, allowing more advanced saving and previewing operations. Here’s an example from my Menu Customizer project:

    function menu_customizer_update_menu_name( $value, $setting ) {
    ...
    	// Update the menu name with the new $value.
    	wp_update_nav_menu_object( $setting->menu_id, array( 'menu-name' => trim( esc_html( $value ) ) ) );
    }
    add_action( 'customize_update_menu_name', 'menu_customizer_update_menu_name' );
    

    This part of the Customizer API is a bit too complex to fully explain here, as most of it already existed, but suffice it to say that the addition of the setting instance to these actions greatly expands the possibilities of working with custom setting types in the Customizer.

    New “customize” Meta Capability

    The Customizer has been essentially decoupled from edit_theme_options in favor of a customize meta capability (mapped to edit_theme_options by default), which is assigned only to administrators by default. This allows for wider use of the Customizer’s extensive capability-access options, which are built into panels, sections, and settings. Additionally, this makes it possible to allow non-administrators to use the customizer for, for example, customizing posts. This change is an important step toward expanding the scope of the Customizer beyond themes. See #28605.

    function allow_users_who_can_edit_posts_to_customize( $caps, $cap, $user_id ) {
            $required_cap = 'edit_posts';
            if ( 'customize' === $cap && user_can( $user_id, $required_cap ) ) {
                    $caps = array( $required_cap );
            }
            return $caps;
    }
    add_filter( 'map_meta_cap', 'allow_users_who_can_edit_posts_to_customize', 10, 3 );

    Customizer Conditional Function

    The new is_customize_preview() conditional function can be used to check whether the front-end is being displayed in the Customizer. The naming derives from the fact that the term “preview” applies to both theme previews and previewing changes before saving them. See #23509 for some sample use-cases from WordPress.com.

    Future Work

    Most of the changes in 4.0 focus on the Customizer’s PHP API and the user experience within the Customizer. In the next few releases, we’ll probably shift focus to building out the Customizer JS API (#28709) and work on the user experience of accessing and navigating through the customizer (potentially with something like #28602 and related), as well as improving the experience on mobile (#28784). The Customizer can be very slow currently but we’re exploring ways to improve performance; for example, controls could be dynamically loaded on an as-needed basis once a more complete JS API is in place (#28580). We’ll work on improving custom background images and potentially add menus and/or theme-switching to the Customizer eventually. We’ll also want to address what to do with screens that the Customizer effectively replaces (headers and backgrounds, maybe eventually widgets, menus, and themes).  Check out the future release Customize component tickets for more ideas.

    Thanks again to everyone who’s helped out with the Customizer in 4.0. If any of the outstanding items here pique your interest, feel free to jump in on trac!

     

    Update: all UI changes have been committed. Additional work to improve focus styling will happen during beta, see #28267.

    Update 2: everything here is in WordPress 4.0 beta 1, with the exception of the customize capability. The capability will most likely be implemented as a meta capability, not a primitive one, see #28605 for details.

    Update 3: customize meta capability is now in trunk, will be in 4.0 beta 2. Added usage example.

     
    • prionkor 2:10 am on July 8, 2014 Permalink | Log in to Reply

      >We’re shifting toward using “Customizer” rather than “Theme Customizer”, as it isn’t necessarily theme-specific (though most of its uses currently are).

      Correct me if I am wrong. We are still on “Theme Customizer” stage as customizer settings (on save) only affects theme options.

      Is there any plan for implementing Customizer with post meta in addition to the options? That is when we might truly customize things with the customizer.

      • Nick Halsey 2:31 am on July 8, 2014 Permalink | Log in to Reply

        The short answer is that it depends on what plugins you’re using. You’d probably be interested in the Post Customizer plugin (also linked above).

        However, note that many core (and plugin) options in the customizer are not theme-specific; for example, site title and tagline. That is, the settings are saved as options, not theme_mods, so they persist when switching themes. They’re just contextualized to being directly related to the theme in the customize context.

    • JakePT 3:50 am on July 8, 2014 Permalink | Log in to Reply

      I’ve been digging into the customizer a lot lately, and I’m really loving it. It’s a great way to open up parts of a theme so low-tech clients can make certain changes without an extra options page or awkward single-purpose widget areas. I’m happy to see most of the limitations I ran into being addressed here.

      The one thing that is apparently still missing that I really want is a proper Media control. The current one uploads files to the Media Library, but there’s no way to recover them in the customizer. If you upload 2 images, change your mind and want to go back to the first one, you have to upload it again and end up with duplicates in the media library. From a developer perspective, I’d also like it if it returned the attachment ID so I could do more with the file than just spit out the URL.

      • Weston Ruter 3:59 am on July 8, 2014 Permalink | Log in to Reply

        JakePT: Yeah, that’s being worked on. Have you seen the new Header Image control? You can select any image from the Media Library via the Media Manager. This same ability is being worked on for background images.

        • JakePT 10:12 am on July 8, 2014 Permalink | Log in to Reply

          No I haven’t. Thanks for pointing that out, I’ll take a look.

          Honestly, the reason that I hadn’t is that I generally avoid the Custom Header because I find it kind of ambiguous. Maybe it’s just the sites my company and I develop, but the images near the top couldn’t really be described as being in the ‘Header’, which makes it confusing. What is in the header is usually a logo (these are generally business sites), and the Custom Header functionality doesn’t work perfectly for that since, again, ‘Header Image’ isn’t how I would describe it, and if I want to allow uploading of a High Res logo for Retina, I can’t easily create a second Header control (last time I tried, anyway).

          But I’m glad to hear that it’s being enhanced in this way nonetheless, however I do hope that this enhancement eventually comes down to WP_Customize_Image_Control.

      • Nick Halsey 4:09 am on July 8, 2014 Permalink | Log in to Reply

        The media thing really bugs me too. In fact, I almost worked up a patch to try to get into 4.0 this past weekend, but I didn’t have enough time to get very far with it.

        What should (and probably eventually will) happen is that WP_Customize_Upload_Control should invoke the media library, and then the image and background controls would build off of it with slightly more specialized functionality. It should then be easy to create a custom control that extends this behavior to do all sorts of custom things with JS (like using other attachment metadata). Patches welcome on #21483.

    • Aristeides Stathopoulos 8:25 am on July 8, 2014 Permalink | Log in to Reply

      This is really exciting!
      It was about time this happened…

      The thing that bugs me the most in the Customizer is the fact that it’s almost impossible to save an array as an option… It’s easy to create new controls, but it’s almost impossible to create a control like for example a multi-select control and save it as an array. Instead we have to do some voodoo to convert the array as csv and save it that way.
      Any plans to change that soon?

    • Graham Armfield 10:21 am on July 8, 2014 Permalink | Log in to Reply

      When you’re building your changes to the Customizer as proposed here, please ensure that everything is keyboard accessible and is also providing enough information for screen reader users – not everyone will be using a mouse.

      The Customizer is currently pretty good from an accessibility perspective, and we wouldn’t want to see the Customize take a backward step with these changes.

      Keyboard only testing you’ll be able to do yourself, but feel free to post on the Make WordPress Accessible blog if you need help and guidance with anything else.

      • Nick Halsey 2:30 pm on July 8, 2014 Permalink | Log in to Reply

        Maintaining and improving accessibility is definitely a goal here. All of the new proposed icons (exiting panels, customizer close, etc.) have strong focus styling and use .screen-reader-text. I believe the focus indicators are sufficient even though the change is only color because the colors are inverted, with the darker color moving to the background and the lighter color for the icon. There is also an outstanding patch on #27406 that ensures that only visible elements are focus-able.

        It would be great if the Accessibility team could do an audit of the Customizer’s accessibility, particularly for screen readers, once these changes are committed. We could also maybe fix #27591 in 4.0 if it gets a patch soon.

        • Graham Armfield 1:56 pm on July 10, 2014 Permalink | Log in to Reply

          Nick, I’d like to have a look at the changes with a screen reader. Which ticket patches do I need to install to get the complete picture of the changes?

          • Nick Halsey 4:28 pm on July 10, 2014 Permalink | Log in to Reply

            Excellent!

            All of the user-facing changes are in WordPress 4.0 beta 1, so you should be able to test with that and won’t need any patches at the moment. The remaining known issue with accessibility is insufficient focus styling for Customizer sections and panel headings, which will be addressed in #28267. We’re definitely ready for an in-dept audit, keeping that in mind.

    • simplethemes 3:35 am on July 11, 2014 Permalink | Log in to Reply

      Very nice!

      Has anyone else noticed width issues with panels in Chrome (Testing in Version 35.0.1916.153)?

      http://d.pr/i/j93I

      No problems in latest Firefox.

    • nikeo 1:53 pm on July 15, 2014 Permalink | Log in to Reply

      Panels => just what I needed
      I also love the custom type and the context handling possibilities it creates with customize_update_$type, which I was ignorant of.

      Looking forward to see the JS API enhancements!
      Thanks for this overview @celloexpressions

    • Aniruddh 12:25 am on August 26, 2014 Permalink | Log in to Reply

      I don’t know if I’m missing something here but do we have contextual sections, too?

      • Nick Halsey 12:56 am on August 31, 2014 Permalink | Log in to Reply

        Not yet. There is currently no JS API for sections or panels, so there’s no good way to implement contextual sections. But this feature will be available in the future, once that’s in place. See #28709.

        You might look at what Widgets do in core to make sections contextual by doing special handling with a contextual control within the section.

    • Scott Smith 12:33 am on August 31, 2014 Permalink | Log in to Reply

      So is it possible to use the new ability to specify ‘type’ => ‘url’ in a way that’s compatible with WordPress 3.9 and lower?

      • Nick Halsey 1:07 am on August 31, 2014 Permalink | Log in to Reply

        Unfortunately, no. But you can check for the existence of `$wp_customize->add_panel()` for a 4.0 check and then act accordingly (just use text instead of url as the type). And it won’t cause any critical issues, the control just wouldn’t be displayed.

        It is forward compatible – if core implements something special for a specific html5 input type in the future, it will work with the current fallback input type handling back to 4.0.

  • Helen Hou-Sandi 2:42 am on June 27, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Summary of 6/25 dev chat (IRC log):

    General

    • Beta 1 is being pushed back to July 9 from July 2, with each successive beta and RC 1 also pushing back a week. The schedule has been updated.
    • oEmbed (@azaozz), i18n / language packs (@nacin), media grid (@ericlewis), and plugin installer (@tellyworth) should each have an update post published here before the weekend, outlining what has been done thus far, next steps, points needing discussion, and relevant tickets.
    • Each of the above should have a new patch ready by Monday. Across the board, it would be nice to see more work-in-progress patches — props @ericandrewlewis for recent patches on the media grid ticket
    • Daily scrubs in #wordpress-dev happening at 15:00 UTC.
    • @johnbillion would like to help coordinate people who are given time by their employers to work on WP; Make/Core post forthcoming.

    oEmbed

    • Recent updates to oEmbed: previews in the editor, media modal, added a bunch of providers
    • Todos: SSL, script sandboxing, caching improvements, UI/UX tweaks
    • Two thirds of our supported providers don’t support SSL: #28507
    • @sams suggested SSL should be a requirement for oEmbed providers going forward (have since revised to an important consideration for the time being).
    • Insecure iframes and/or insecure contained content will be blocked by newer Chrome and Firefox.
    • Two options: placeholder or a nonced, authed, proxied iframe.
    • For Monday: Placeholder fallback for SSL admin and non-SSL oEmbeds.

    i18n

    Media Grid

    • A quick phase 2 of the media grid is going forward
    • Media Grid needs a fair amount of work, not user testable yet.
    • Reminder: watch out for strings like “Edit Media” (#) won’t work well for long translations, i.e. ru_RU.
    • @ericandrewlewis asked for feedback on the JavaScript application structural decisions around Media Grid. This is likely worth a separate discussion.
    • For Monday: A user-testable patch.

    Plugin Installer

    • Screenshots for possibly comparable things.
    • @tellyworth is working on plugin-install.php and @stephdau is working on the details modal / page.
    • Next: Need to discuss what kind of data is most helpful to display for users when they are trying to figure out which plugin it is they want.
    • For Monday: @tellyworth and @stephdau will post patches in progress.

    Other

    With thanks (again) to @designsimply for note collation.

     
  • Mike Schroder 6:03 am on June 19, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    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.

    Admin

    • 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

    SSL

    • 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

    Embeds

    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]

    Accessibility

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

    WP_Query

    • 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

    Internals

    • 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

    Formatting

    TinyMCE:

    • 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.

     
  • Helen Hou-Sandi 7:59 pm on June 11, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    For today’s dev chat starting shortly let’s Do… 

    For today’s dev chat starting shortly, let’s:

    • Do a quick check on any of the bigger features for resource needs or sticking points (media grid, i18n, plugins page, oEmbed).
    • Talk about shared terms.
    • like_escape(): #10041.
    • Do an open-ended bug scrub, building on the momentum @wonderboymusic kicked off with commits and this post. Will guide these with specific reports to be linked in dev chat.

    Other proposed items:

    • 3.9.2 status.

    Add yours here below.

     
    • John Blackbourn 8:02 pm on June 11, 2014 Permalink | Log in to Reply

      Headline features for 4.0 – what do we have?

    • Robert Chapin 8:45 pm on June 11, 2014 Permalink | Log in to Reply

      Unable to attend. Let me know if I can be of any help on 10041. :)

    • Scott Taylor 9:46 pm on June 11, 2014 Permalink | Log in to Reply

      texturize tests are failing:

      1) Tests_Formatting_WPTexturize::test_quotes
      Failed asserting that two strings are equal.
      — Expected
      +++ Actual
      @@ @@
      -‘Here is “a test with a link”’
      +’Here is “a test with a link“’

      /Users/205410/Sites/wordpress-core-develop/tests/phpunit/tests/formatting/WPTexturize.php:84

      2) Tests_Formatting_WPTexturize::test_quotes_before_numbers
      Failed asserting that two strings are equal.
      — Expected
      +++ Actual
      @@ @@
      -‘Class of ’99’s’
      +’Class of ‘99’s’

      /Users/205410/Sites/wordpress-core-develop/tests/phpunit/tests/formatting/WPTexturize.php:114

      3) Tests_Formatting_WPTexturize::test_other_html
      Failed asserting that two strings are equal.
      — Expected
      +++ Actual
      @@ @@
      -‘‘Quoted Text’,’
      +’‘Quoted Text‘,’

      /Users/205410/Sites/wordpress-core-develop/tests/phpunit/tests/formatting/WPTexturize.php:132

      4) Tests_Formatting_WPTexturize::test_entity_quote_cuddling
      Failed asserting that two strings are equal.
      — Expected
      +++ Actual
      @@ @@
      -‘&“Testing”’
      +’&”Testing”’

      /Users/205410/Sites/wordpress-core-develop/tests/phpunit/tests/formatting/WPTexturize.php:176

      5) Tests_Paginate_Links::test_defaults
      Failed asserting that two strings are equal.
      — Expected
      +++ Actual
      @@ @@
      -‘1
      +’1

      50

  • Helen Hou-Sandi 9:44 pm on June 1, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Summary of 5/28 dev chat (IRC log):

    • @nacin and @tellyworth have been working on the .org API side for i18n and plugins page improvements respectively and should be ready for work on the core side soon. Be on the lookout for tickets and discussions.
    • @ericlewis has been working through the Media component in Trac and will be holding weekly scrub in #wordpress-dev alongside media grid chats, Fridays at 17:00 UTC.
    • @wonderboymusic has been evaluating various oEmbed endpoints as we add and remove them. Some services need some more evaluation: #28379.
    • Embed representations in wpview need an iframe sandboxing solution investigated to avoid script conflicts inside TinyMCE and the admin: #28249
    • The JSON REST API came a long way in the past week, especially on the documentation front, and is being placed onto the roadmap for the 4.1 release. From @nacin:

    1.0 is a great step in the right direction; let’s push it hard; let’s put it squarely, loudly, and officially on the 4.1 roadmap (I’m comfortable doing that); let’s get a lot of core contributors focusing on it for the final mile, especially when it comes to internals

    let’s get a lot of people to build things on it, including inside automattic, mobile apps, even wordpress.org stuff; let’s branch off 1.0 so we can decide paint and carpet colors on the master branch

    •  And finally, several people were added to various Trac components as component maintainers. You can be added at any time, or get on the road to becoming one by signing up for granular notifications on the components page.
     
    • Eric Andrew Lewis 10:35 pm on June 1, 2014 Permalink | Log in to Reply

      I think component maintainer gravatars should be surfaced to the components page, so we can see the core community at a glance rather than clickering into each.

  • Mike Schroder 2:18 am on May 21, 2014 Permalink | Log in to leave a Comment
    Tags:   

    Last Week in WordPress Core 

    Hi Everyone! This is the first Last Week in WordPress Core for WordPress 4.0! Last week, a minor update, 3.9.1 was released, and autoupdates started shortly afterwards. Development on 4.0 is ongoing, and you can see notes and meeting details posted by @helen on this blog as well.

    Media:

    • In wp.media.view.Settings::update(), when handling checkboxes, check for a value of false in addition to casting value to boolean. !! false evaluates to true. [28371] #23954
    • Allow users to set overrides for MediaElement instances by always passing _wpmejsSettings instead of just _wpmejsSettings.pluginPath. [28370] #25243
    • When pausing “all” players attached to MCE views, don’t reach into global scope and pause every player. Only pause the players bound to MCE views. [28364] #27971
    • In wp_read_image_metadata(), the values from exif_read_data() should only override values from iptcparse() that are empty. [28367] #23706
    • Support loop for [audio] and [video] shortcodes that specify files that are played using MediaElement’s Flash plugin bridge. [28363] #27368
    • MediaElement players need clear: both to play nice with adjacent floated elements. [28361] #27385

    Widgets:

    • Custom Navigation Widget: Force users to choose a nav menu in the custom nav menu widget, for a better customizer UX. Before, they had to make a dummy change to get it to render. Now they are made to choose a nav menu from the dropdown, which feels more natural. [28197] #27878
    • Recent Posts Widget: Use ob_end_flush() instead of ob_flush(). ob_end_flush() flushes the output buffer and turns output buffering off, same as ob_get_flush(). [28195] #28009

    Themes and Templates:

    • Prevent paged-* from being added to body classes and prevent Page %s from being added to page title on 404 error pages on default themes. [28249] #16468
    • Bundled Themes:Prevent Page %s from being added to page title on 404 error pages in bundled themes. [28250] #16468.
    • Bundled Themes: Use correct logic in IE conditional comments in header template. [28341] #28151
    • Set the proper value for wp_title() when is_author() and is_post_type_archive() are both true. post_type should always win due to the precedence indicated in get_queried_object(). [28251] #25398
    • Update the default (WP-defined) styles for MediaElement players to be more in-line with our flat aesthetic. Use the new official colors. [28365] #27516

    Custom Headers:

    • Allow to skip cropping header images if image width is smaller than or equal to theme width. [28219] #27936
    • Avoid hiding ‘Remove’ buttons unrelated to custom headers. [27882] #27848
    • Keep header image from being removed when background image is removed. [28269] #28046
    • Avoid warnings in the process_default_headers() method. #27850
    • Fix logic when a theme doesn’t set default-text-color. [28294] #28042

    Internals:

    • Move home option to the top of populate_options() to make it easier to find next to siteurls for manual changes. [28260] #28141
    • Scrutinizer Cleanup: @wonderboymusic has started the process of cleaning up core with Scrutinizer. Check out the full list of fixes so far on #27882.
    • Hack/HHVM Compatibility: More from @wonderboymusic. See #27881 and #22400.
    • Dev Tools: Introduce default wp-cli.yml for core development. [28221] #28036
    • Add .dfxp and .srt files to mime-type whitelist in wp_get_mime_types(). They are both captioning formats supported by MediaElement. [28259] #27643
    • Add .xps and .oxps extensions to list of supported document types. More about the types on Wikipedia. [28372] #15697
    • When $type is atom in get_the_category_rss(), use get_bloginfo_rss( 'url' ) when setting the scheme attribute for the <category> node. [28258] #24444
    • In WP_Date_Query::get_sql_for_subquery(), don’t parse duplicate parameters – only parse one of w and week or month and monthnum. [28252] #25835
    • Add a filter for wp_list_comments() arguments. [28285] #19581
    • In get_the_author_posts(), if there is no current $post, return 0 and bail. [28362] #27998
    • In WP_Terms_List_Table::single_row(), call sanitize_term() on the passed term ($tag). [28360] #16864

    Externals:

    TinyMCE:

    • First pass at wpview logic for the shortcode. URLs pasted on their own line are parsed as well. The toolbar will appear with the “remove” button when the view is clicked. Edit has not been implemented yet, nor have safety measures for non-iframe embeds. [28358] #28195
    • Audio, video, and playlist shortcodes: [28342] #22400, #27881
      • Convert all instances of variable variables to array properties
      • Stop using extract()
      • Rename $atts to $html_atts where collision with new $atts (shortcode atts holder) var might occur
    • Shortcode JS: Avoid errors when an escaped shortcode includes a newline between brackets. [28223] #27907

    Multisite:

    Thanks to @andrezrv, @arnee, @avryl, @azaozz, @boonebgorges, @celloexpressions, @Clorith, @danielbachhuber, @dimadin, @ebinnionm, @ehg, @ericlewis, @feedmeastraycat, @GaVrA, @gcorne, @greenshady, @helen, @hlashbrooke, @imath, @jartes, @jdgrimes, @jeremyfelt, @johnbillion, @jorbin, @jupiterwise, @mattwiebe, @MikeHansenMe, @m_i_n, @obenland, @ocean90, @pavelevap, @psoluch, @rob1n, @rzen, @sergej.mueller, @SergeyBiryukov, @t4k1s, @Tmeister, @westonruter, and @wonderboymusic for their help!

    For the complete list of commits to trunk, check out the log on Trac. We’ve been chatting about 4.0 plans, and things are shaping up. Come chat this Wednesday to continue the discussion, and please note if you encounter issues with 3.9.1 on Trac.

     
  • Helen Hou-Sandi 8:30 pm on May 6, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Summary of last week’s dev chat on 4/30 (IRC log):

    Announcements

    Features as plugins

    • Met on 4/29 (IRC log)
    • Current potential considerations seem to be WP API and media grid.
    • Press This is getting some attention from an early stages working group, which could also be a part of the 4.0 release.
    • Admin Help is poised to shift into more of a continuous testing and advisory group, which is awesome.
    • Front-end editor is making good progress, but has UX issues that are getting worked on, needs iteration and experimentation and probably won’t be ready by 4.0, but should continuously be worked on, as is the goal of features as plugins in the first place. Developers needed.

    Potential ideas and their suggesters:

    Summary: we have good things in mind about more media improvements, more editing experience improvements, more visual media grid and better plugin installer experience (following in the footsteps of themes), and behind the scenes wins in taxonomy, multisite, and post type and comment APIs.

    If you’re interested in any of the above or have other ideas, please sound off in the comments.

    Getting involved

    • We are always looking for more people to be involved with Trac gardening, patch review, patch writing, or some combination thereof.
    • Component pages are running well, and most could still use the caretaking of a component owner or somebody who’d like to become well-versed in a particular area of core. To get started, just sign up for component notifications at http://make.wordpress.org/core/notifications/. No need to be an expert now – learning and persistence is more important.To help with a specific plugin, join their weekly chats and/or follow along wherever they post. See the Features as Plugins page for more information.
    • A reminder from @matt to always be dogfooding the product – use WordPress every day.

    Bonus punnage, to the lead’s chagrin:

    > wonderboymusic will make a t-shirt for anyone who gets all 16 of those Cache tickets closed :)
    > sams: “Cache Master”?
    > wonderboymusic: Johnny Cache
    > jorbin: If you fix the Cache, you’ll get the Credit. That Checks out.
    > MarkJaquith: I’d put in a cache pun, but I don’t want to be sent to purgetory.
    > johnbillion: You would have to be a cache machine to fix all 16

     
  • Andrew Nacin 5:36 pm on April 30, 2014 Permalink
    Tags: , , release lead   

    Helen is the WordPress 4.0 release lead 

    Mike and I are pleased to pass the release lead baton to Helen Hou-Sandí for WordPress 4.0. I don’t think this will come as much of a surprise to most of you, but please offer @helen your congratulations, which are well-deserved.

    We’ve already discussed 4.0 a bit in our last two meetings. Expect today’s weekly meeting at 2000 UTC in #wordpress-dev to be the kickoff for WordPress 4.0.

    @DrewAPicture, @wonderboymusic, and @johnbillion have all been renewed for guest commit for 4.0. Additionally, I’m happy to announce that, after more than a year as guest committers, Dominik (@ocean90) and Sergey (@SergeyBiryukov) both have permanent commit access. Their prolific contributions have left a lasting mark on WordPress and I hope to see them at it for years to come.

    A release lead, if anyone is curious, determines all important parameters for a release, like schedule, deadlines, which feature plugins are merged, and more generally, scope and goals. They take point when it comes to meetings, shepherding contributions, announcement posts, and updates. A release lead is a connector and facilitator, identifying bottlenecks and friction wherever they may be and at the service of the developers and plugin teams that are aiming to have something in a given release, and be in frequent communication with them.

    The release lead should should follow what’s being committed, and set the tone for prioritizing and gardening the milestone on Trac. Given the constraint of time in hitting a date, help with prioritization and ensuring good communication lines are two of the most valuable things a lead can contribute.

    The last five release leads were lead developers, but that’s not a requirement, nor is being a committer. I always thought of my “code reviewer” and “committer” hats as being separate, additional responsibilities. (Helen, of course, also wears these same hats.) Regardless: the release lead has the final call on all important decisions related to the release.

    Addendum: For those unaware, for WordPress, version 4.0 sounds like a “big” version number but it’s just another major release for us, like 3.9 and 4.1, constructed over the same ~4-month release cycle. But don’t tell Helen that! Here’s to 4.0 being awesome.

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel