WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Recent Updates Page 2 Toggle Comment Threads | Keyboard Shortcuts

  • Helen Hou-Sandi 6:37 am on July 18, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Dev chat summary for July 16, 9, and 2 

    We haven’t posted weekly summaries in a bit, so here’s a summary of the last three dev chats.

    • Beta 1: Shipped last Thursday, July 10. Feedback has been good so far.
    • Beta 2: Planned for tonight, July 17. @azaozz updated TinyMCE prior to release. Pending a couple of changes (or not) that @nacin is looking at: #22023 + #5809 and cookies tied to sessions (#20276).
    • Testing: Especially want feedback on the following things: plugin modals on many screens + accessibility devices, wpviews, customizer panels, media grid, install language flow.
    • Tickets: Generally under control, but still need more area-specific triage.

    In general, 4.0 is shaping up with two distinct groups of focuses: editing + platform & writing + global.

    Area specific updates:

    • Media Grid: Progress update from June 27. Reviews have been good but some help was needed on architectural reviews/revisions, CSS, keyboard accessibility. Attachment details will be tightened up (#28844).
    • Plugins: Progress update posted from June 28. Some API changes will take place so we can improve the Install Plugins page with groups of featured plugins. Need i18n attention on the plugin install page, but generally in good shape.
    • Customizer: we have panels now, some decisions need to be made about close vs. cancel language and possibly moving to a close icon + AYS
    • i18n: Progress update from July 2. Need help to complete things.
    • oEmbed: placeholders were added for when embeds are needed but not available—when the admin is SSL and a user pastes non-SSL embed URL, we try to get the SSL, if that fails, we try the non-SSL, if successful, we show the placeholder—the url in the post_content stays as pasted.
    • Other updates: Feedback will be posted about URL encoding with media_sideload_image(). Still looking at sessions; possible a schema change or two in there.

    As always, daily bug scrubs happen at 15:00 UTC.

     
    • Nick 5:53 pm on July 18, 2014 Permalink | Log in to Reply

      Please include Akismet 3.0.1 in WordPress 4.0 beta2. THX. I’m using WordPress 4.0 beta1 with the WordPress Beta Tester plugin and have to update Akismet after every new install of a nightly build.

      @Helen Hou-Sandi, great work!!! Thank you!!!

  • Helen Hou-Sandi 7:49 pm on July 16, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    For today’s dev chat, let’s check in on how we’re feeling about a beta 2, any blockers we might be seeing, and then do a scrub on tickets, particularly focusing on things that can be committed or punted. Please add any other agenda items in the comments.

     
  • Nick Halsey 3:15 pm on July 15, 2014 Permalink | Log in to leave a Comment
    Tags: , ,   

    GSoC Menu Customizer Update: Scalable Menus 

    Since my last GSoC update, I’ve spent a fair amount of time helping prepare the Customizer for 4.0 beta 1. But I’ve also continued working on the Menu Customizer and have a lot of progress to report.

    Add & Delete Menus

    You can now add new menus, via the “+ New Menu” section. Added menus currently have some issues, though; you’ll probably need to reload the page before adding items works. The problems stem from the lack of a proper JS API for adding, deleting, and managing Sections and Settings (and Panels), and the incompleteness of the existing Control JS API. This will probably need to be resolved in core before the Menu Customizer can be considered for core integration, see #28709.

    I’ve also implemented a menu-deletion mode, which can be toggled from the add-menu section. It’s too easy to delete menus otherwise, even with an AYS confirming the delete, because deleted menus cannot be restored, and are not “previewed” before being published to the db (added menus aren’t either). It’s probably worth augmenting the AYS to state the menu name being deleted, and to add an extra warning if it’s active in a theme location or a widget.

    Saving Menus and Menu Item Data in a Scalable Way

    In core, menus do not scale well at all. You don’t have to look very deep into the code to see why – massive amounts of data for each item are hidden on the admin screens (much of which never changes) and then must be updated every time a change is made.

    Since one of the goals of this project is to experiment with new approaches, I’ve begun implementing a new approach for saving menu data, which is currently in use in the plugin. Thanks to my mentors @ethitter and @obenland for guiding me on the best approach to take here, and @westonruter for the way he implemented the Widget Customizer UI, which inspired this exact approach. Here’s how it works:

    • Each menu has a nav_menu Customizer control that contains an ordered array of numerical menu item ids (known throughout the core menus codebase as their db ids).
    • When an item is added, it is created as an orphaned draft via ajax, and its id is added to the nav_menu setting’s array.
    • When an item is deleted, its id is removed from the nav_menu setting’s array.
    • When menu items are reordered, the order of ids in the nav_menu id is updated to match.
    • When menu items are moved into and out of sub-menus, the parent menu item id is updated in the individual item’s data (not yet implemented).
    • When a menu item field is changed (by default, this would mean changing the label or, for custom items, url fileds; there are screen options for several others), the original item is cloned and the copy is updated with the new data, using a wrapper for wp_update_nav_menu_item() that doesn’t require passing all existing (unchanged) menu item data. The cloned item’s id is returned and replaces the original id in the nav_menu setting (thereby marking the original item for deletion). Additional changes are saved to the cloned item until the settings are saved, at which point all items are marked for a new clone to be created if changes are made (not yet implemented).
    • When the user saves their changes from the Customizer (via the customize_update_nav_menu action), the array of ids is compared to the currently-published menu’s items. If there are items that are no longer present, those are marked for deletion. For each of the new ids, the corresponding menu item (which already exists) is updated to be published, assigned to the corresponding menu (for the new items created as orphaned drafts), and the item’s menu_order is set to the id’s position in the nav_menus setting array. Finally, all of the removed items are deleted.

    While menu previewing in the customizer is not yet implemented, it will also be able to use the nav_menu setting’s array of ids to display an augmented set of menu items. I’m also still working on ensuring that menu item data is not posted during the customize-save ajax, but the data isn’t needed so we’re most of the way there already.

    UI Aside

    customize-header-bigflat-buttons-close

    Quick aside: @DrewAPicture pointed out in IRC that the new Customizer close and panel-back icons don’t really match the save button. I’ve done some rough explorations of potential alternatives; if anyone’s interested in discussing them and possibly implementing a change here, feel free to ping me in IRC (@celloexpressions) and/or create a ticket and/or comment here.

    Finally, I’m hoping to finish implementing menu previewing by the end of this week, fully utilizing the Customizer. Once this is done, I’ll essentially be at feature-complete stage (other than some little details and several known bugs) and ready to iterate (I’m already planning on working on the add-menu-items backend, as it currently doesn’t scale).

     
    • michalzuber 5:30 pm on July 17, 2014 Permalink | Log in to Reply

      I’m figuring out why is `@todo: Remove choices` in the `wp-includes/class-wp-customize-control.php` ? Couldn’t get it.

      • Nick Halsey 5:43 pm on July 17, 2014 Permalink | Log in to Reply

        That’s more related to the Customizer post, but I think that’s leftover from the initial customizer development in 3.4. We can remove the todo, since removing $choices is no longer an option due to back-compat.

    • Weston Ruter 8:26 pm on July 22, 2014 Permalink | Log in to Reply

      When an item is added, it is created as an orphaned draft via ajax, and its id is added to the nav_menu setting’s array.

      Something that I’ve been exploring with Customize Posts is the addition and deletion of postmeta. Instead of actually mutating the database, when creating new meta I’m creating faux post meta IDs and then referring to them in the preview filter. When saving the Customizer settings, these posts meta are then inserted at that time. It’s not quite done yet, as I need to now gather the post meta IDs that were inserted at the time of saving, and update the setting to refer to them.

      Generating a virtual post meta ID: https://github.com/x-team/wp-customize-posts/blob/85dc4e562ea806c17480899f5d94f93d42297de1/js/customize-posts.js#L611-L618

      Sanitizing a setting that includes virtual post meta ID: https://github.com/x-team/wp-customize-posts/blob/develop/php/class-wp-customize-posts.php#L303-L310

      It would be ideal if Menu Customizer could add new menu items virtually without touching the DB.

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

        I’m not sure if it would be possible to add items without touching the DB in a scalable way. The primary reason for doing that is so that menu item data doesn’t need to be sent to the server all at once when saving, which causes scaling problems currently (for example, imagine if 100+ menu items were added to several different menus upon initial setup of a site – that data would all go up together).

        In the existing menus system, items are similarly added to the db via ajax before being made available for manipulation in the UI. So, the concept of orphaned draft menu item posts is existing and currently being leveraged here.

  • Konstantin Obenland 4:23 pm on July 10, 2014 Permalink | Log in to leave a Comment
    Tags: , bundled-theme   

    @lancewillett and I will hold a Bundled Theme Office Hour tomorrow, July 11, 2014 1700UTC in #wordpress-themes to clean out all tickets in the 4.0 milestone, starting with enhancements.

    Everyone interested is invited to join us! Please feel free to test/review patches prior to tomorrow’s office hours, comment on the tickets etc., everything helps.

     
  • Helen Hou-Sandi 7:41 pm on July 9, 2014 Permalink | Log in to leave a Comment
    Tags: 0, 4,   

    Proposed agenda for today’s dev chat. We’re targeting the late evening Eastern US time for beta 1.

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

  • Andrew Nacin 7:48 pm on July 2, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Here’s where we are on the five goals for internationalization outlined previously:

    1. The first step installing WordPress should be to choose a language. The rest of the install process would then be in that language.

    First pass done in #28577. There is a list of things to do in the ticket, which includes:

    • Improved error handling when the API or filesystem isn’t accessible. Working on this.
    • Bring this to setup-config.php. Working on this.
    • Place browser-based language suggestions at the top. Working on this.
    • Use better markup rather than simple select/option HTML, currently being worked on by @jorbin.

    2. You should be able to choose/switch a language from the general settings screen, after which the language pack should be downloaded.

    This simply requires replacing mu_dropdown_languages() with a new method that handles uninstalled languages gracefully. This is easy to implement and relies on much of the same code as the install process, so it’s simply on hold until that’s done. I’ve also worked out a UX flow with @sonjanyc.

    3. You should be able to search from the dashboard for plugins and themes that are available in your language.

    This is handled on the WordPress.org side. The updated plugins screen will need to pass a new argument to filter by language, and then remove that argument if the user requests showing plugins in any language. We’ll need to hack in readme/description translation support but that’s a small API change and otherwise WordPress.org work, not core work.

    4. All localized packages should be able to be automatically generated and made available immediately as part of the core release process.

    A script for this is written. While it needs more work, it was used as a test to build 3.9.1 packages, which are doubling as 4.0-alpha testing packages. This does not require changes in core.

    5. Localized packages should only be used for initial downloads from WordPress.org. Instead, language packs should be transparently used for updates.

    This is ready. A flag needs to simply be flipped in the API.

    Ongoing problems to solve:

    • I have a proposal to type up for how to handle readmes, license files, etc., in both core and plugins. Requires no core changes.
    • No one has picked up the plan to limit the code modifications still done in some locales. This may end up being a July project for me.
    • The relevant APIs we need in core were deployed to WordPress.org. Also, the plugin and theme directories are fully internationalized; we need to get those strings to translators and shoehorn them onto existing international sites.
     
  • Helen Hou-Sandi 5:57 pm on July 2, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Proposed agenda for today:

    • A look at the assignments from last week – next steps, any stucks, any needs. (@azaozz,
    • #27423: Improve Media Modal UI at small-screen sizes
    • #14759: Improve the way oEmbed deals with caching (@markjaquith)
    • #20564: Framework for storing revisions of Post Meta (@adamsilverstein)
    • How are we feeling about beta?

    Please add any items you have in the comments below.

     
  • Nick Halsey 2:44 am on June 28, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    GSoC Menu Customizer Update 

    Since this is my first post here, a quick introduction. I’m a student at the University of Southern California studying Civil Engineering, Architecture, and Music Composition. I’ve been contributing to WordPress Core for just over a year and this summer I’m pleased to be working on WordPress full-time for my Google Summer of Code project.

    Overview

    The goal of the Menu Customizer project is to add Custom Menu management to the Customizer. Ideally, the project should be able to replace the existing Menus screen, with full feature parity, but that’s obviously a bigger discussion that would take place later. For more details, check out my initial proposal.

    Current Status

    I started six weeks ago and have built out most of the plugin’s UI and structure. However, I still need to build the menu-item previewing and saving components of the project. The UI closely resembles the Widgets-in-customizer UI, with sections for each menu and controls for each item. New menu items are added via a slide-out panel, where they’re currently grouped by post type/taxonomy, custom links, and a global search feature. The existing “Navigation” Customizer section has been re-branded to “Theme Locations,” and emphasizes the ability to add menus to widgets. Development is being done on the plugin repo, and you can download and play with it from there, but note that adding items creates orphaned draft menu items that are never published currently. Here’s a demo of the current plugin:

    (If the embedded video doesn’t play for you, try this link: https://cloudup.com/cVJbk3u32QV)

    The add-menu-item UI and implementation will be getting a lot of attention throughout the rest of my project. Items are added immediately, rather than the existing two-step checkboxes and adding several at once process, and menu items can now be deleted without having to open their settings, making deletion and addition more streamlined.

    When editing menu items, changing the navigation label of an item instantly updates its drag-and-drop handle, and updating a menu name updates the corresponding Customizer section. Items can be reordered or moved into sub-menus via either drag-and-drop or a reordering mode similar to that of the Widget Customizer.

    To minimalize the UI, given the limited space in the customizer, the “Title Attribute” field has been turned off by default, and all of the existing menu-item-field screen options are available, syncing with the existing Menus screen. I might look into building a core API for customizer screen options now that #27406 is in trunk, time permitting.

    A good amount of my time in the past couple weeks has been dedicated to #27406, which is a prerequisite for the Menu Customizer to be realistic given the need to allow users to create new menus (and in turn, new Customizer sections). Committed to trunk yesterday, it introduces a “Panels” API to the Customizer. Panels are a way to group sections, adding a new layer of hierarchy to the Customizer. In the Widget Customizer, all widget areas are added to the Widgets panel, allowing widgets to take over the entire Customizer as needed. The Menu Customizer plugin does the same thing with Menus, and requires trunk accordingly.

    Upcoming Work

    My next steps are to implement menu-adding and deleting, to implement reorderability/sortability, and then to spend quite a bit of time developing a saving/previewing system that scales well (see #14134  and related). This will most likely involve creating clones of changed menu items (posts) and menus (taxonomy terms). Once all of that’s finished, the plugin should be feature-complete, and ready for iteration.

    Core Patches

    I’ve also taken the opportunity to spend a fair amount of time working on core patches related to either Menus or the Customizer, as this project is widely expanding my knowledge of both areas. A couple of examples that have made it into core include #27406 – Customizer Panels, and #23076 – which adds live menu-item label-updating to the existing Menu screen. I’m planning on continuing to work on Menus and the Customizer via tickets/patches throughout my project as time allows.

     
    • helgatheviking 3:00 am on June 28, 2014 Permalink | Log in to Reply

      The video is pretty sweet!, great work! I’m definitely interested in seeing #14134 get fixed because it has been holding up the addition of an [18584: action hook for custom menu item meta](https://core.trac.wordpress.org/ticket/18584), which is causing all menu modifying plugins (and themes) to not be compatible with each other.

      • Nick Halsey 3:21 am on June 28, 2014 Permalink | Log in to Reply

        Thanks! I’m hoping to both fix the scaling issues and add some hooks in the new interface. The addition of a hook would really open up the possibilities for what menus can do, as your plugin and others already demonstrate.

        That being said I’m thinking that an API for custom menu fields might be even better than a hook, as that would make it easier to work with and match other core patterns for this type of structure. We’re essentially looking at custom post fields here given the way menus work. I’ll definitely look into this more once I get to the initial feature-completion stage. The ongoing Metadata UI API project might be able to be integrated here in some form, too.

    • nikeo 8:28 am on June 28, 2014 Permalink | Log in to Reply

      Great work! The plugin’s code is really clean and well commented.
      Thanks for sharing

    • Rami Yushuvaev 5:05 pm on June 28, 2014 Permalink | Log in to Reply

      Have you tested this in RTL mode?

      • Nick Halsey 5:54 pm on June 29, 2014 Permalink | Log in to Reply

        Not yet, that’ll come once we’re ready to test on different devices & environments after the basic functionality is complete. That being said, I’m guessing that the core build process will handle most of it automatically.

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

      I think some accessibility testing needs to be done on this to ensure that anyone not using a mouse, and screen reader users are catered for here.

  • Alex Shiels 2:24 am on June 28, 2014 Permalink | Log in to leave a Comment  

    Update on the Plugins page work 

    A quick update on the Plugins page (previously: here and here). The three major areas of work are the Detail modal view; the plugin-install.php landing page; and the plugin list views. Some progress so far:

    #22599 has a minimal patch for displaying plugin reviews and ratings in the Detail modal. More work is needed.

    #27440 now has API support for image banners in the Detail modal.

    @stephdau is working on the next steps for the modal, which will probably include experimenting with removing or replacing the Thickbox code, and iterating on the UI.

    I’m working on the plugin-install.php page. There’s no specific ticket for it yet, but step 1 will be a basic overhaul incorporating some of the ideas in @melchoyce‘s thread in a rudimentary fashion.

    The plan is to get these minimally functional with API support very soon, and then experiment from there with the UI and incremental improvements.

    Some closely related tickets and posts:

    #28646 and #17902 suggest some improvements to the list views, both related to unifying the search list and the installed plugins list.

    #20002 suggests API improvements related to querying multiple plugins.

    This post includes screenshots of many web/app stores, which suggest some design cues. If you’d like to help out, we could use feedback and incremental patches on those tickets; and of course the Plugins component has many other tickets in need of attention.

     

     

     
    • Pippin Williamson 2:59 am on June 28, 2014 Permalink | Log in to Reply

      I love see these kind of updates. They make me so happy :)

    • Gustavo Bordoni 11:03 am on June 30, 2014 Permalink | Log in to Reply

      +1 for these, there is a lot of love for the Plugins!

    • Paal Joachim Romdahl 7:16 pm on July 1, 2014 Permalink | Log in to Reply

      Clicking the details of a plugin opens a modal box. If one wants to check the next plugin in the search list one has to first close the existing modal box and then click the next plugin details. What about including arrows to signal a forward and backward through the detail list of plugins one made a search for? (Similar to the themes screen.)

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