WordPress.org

Make WordPress Core

Recent Updates Page 2 Toggle Comment Threads | Keyboard Shortcuts

  • Joe McGill 9:20 pm on November 22, 2016 Permalink |
    Tags: , ,   

    Media Changes in 4.7 

    This post provides an overview of the changes to the Media component in WordPress 4.7. See a list of all the 4.7 media tickets.

    Two notable changes, enhanced PDF support in the media library and changes to the default fallbacks for alt attributes, are explained in separate posts.

    Enhanced PDF Support in WordPress 4.7

    Improving accessibility of image alternative text in 4.7

    Make media library searchable by file name (#22744)

    Before 4.7, if you uploaded a file to the media library and changed the title, it wasn’t possible to find that file again by searching for the file name. Now, attachment search queries will also include matches to the _wp_attached_file post meta value.

    Other enhancements and bug fixes

    • Added a $wp_error parameter to wp_insert_attachment() (#37813)
    • Fix Drag/Drop Ordering of Media in Chrome on touch enabled devices (#31652)
    • Avoid undefined offset notice in wp_prepare_attachment_for_js() when image_downsize filter in used in (#34437).
    • Improve docs for image_send_to_editor filter (#34823).
    • Use wp_get_attachment_metadata() instead of get_post_meta() where appropriate (#36246).
    • Ensure wp_get_attachment_link() output text for non-images (#37343).
    • Avoid undefined index notices when pathinfo() is used (#37608).
    • Improve alignment of inputs and button heights in media edit screens (#37806).
    • Set focus when closing the media modal (#38142).
     
  • Jeff Paul 9:46 pm on November 17, 2016 Permalink |
    Tags: , ,   

    Dev Chat Summary: November 16 (4.7 week 13) 

    This post summarizes the dev chat meeting from November 16th (agendaSlack archive).

    Reminders

    • Dev Chat timing: Weekly chat has been moved to 21:00 UTC.
    • Schedule: Thursday, November 17th is the target for RC! RC means the list of tickets should be at zero (with the exception of the about page), as a release candidate is supposed to represent software you believe you can release. It is currently at 24.
    • Tickets:For any tickets you’ve moved into the milestone, please get these resolved in the next day.
    • Dev Notes: These should all be published this week, with a collective Field Guide forthcoming from @jorbin.

    Dev Notes / Field Guide for 4.7

    • There are a few outstanding Dev Notes, but it’s getting close. We’re waiting on the Customize summary from @celloexpressions, Media summary from @joemcgill, Starter Content from @helen, and @davidakennedy is finishing up one on Twenty Seventeen.
      • Media summary is ready to publish, was just waiting on the PDF post from Tuesday, November 15th.
      • Video Headers post could be done by @bradyvercher, but @joemcgill own making sure it happens
    • @jorbin started drafting the Field Guide, but he’s going to need to hand off finishing it off since he will be offline starting Thursday, November 17th for a week.
      • @adamsilverstein and @jbpaul17 will work to finish things up
      • @jorbin to coordinate with Adam and Jeff to sure the remaining tasks are sorted out
      • @ipstenu happy to proofread for typos and grammar.
    • @jorbin also started the discussion to ensure the email to plugin devs goes out after the Field Guide is published.  That’s a collaboration with the meta team and the pluginsrepo team.

    Release Candidate

    • @helen (thankfully) was able to move RC back from Tuesday, November 15th to Thursday, November 17th.
    • However, we’ve got 23 tickets hanging out in the report, 22 of which need to be resolved or punted in order to reach RC.
    • [Bug Scrub of remaining 4.7 tickets proceeded]
     
  • Helen Hou-Sandi 7:02 pm on November 16, 2016 Permalink |
    Tags: , ,   

    Dev Chat Agenda for November 16 (4.7 week 13) 

    This is the agenda for the weekly dev meeting on November 16, 2016 at 21:00 UTC:

    • Meeting reminder: Weekly chat has been moved one hour later to 21:00UTC.
    • Schedule reminder: Tomorrow is the target for RC! RC means the list of tickets should be at zero (with the exception of the about page), as a release candidate is supposed to represent software you believe you can release. It is currently at 24.
    • Ticket reminder: For any tickets you’ve moved into the milestone, please get these resolved in the next day.
    • Dev notes:  These should all be published this week, with a collective field guide forthcoming from @aaronjorbin.
    • Getting ready for RC with a 4.7 open ticket scrub

    If you have anything to propose to add to the agenda or specific items related to the above, please leave a comment below. See you there!

     
  • Mike Schroder 6:12 pm on November 15, 2016 Permalink |
    Tags: , ,   

    Enhanced PDF Support in WordPress 4.7 

    WordPress 4.7 makes it easier to preview PDFs in the media library by generating image representations of the first page, which are now used throughout the media library and media attachment screens.

    If a WP_Image_Editor is available that supports PDF, the following sizes are generated:

    • Full size representation, rendered at 128dpi.
    • Thumbnail (without cropping)
    • Medium
    • Large

    The sizes generated can be modified, or the feature disabled entirely via the new fallback_intermediate_image_sizes filter, and are all stored in the sizes array in attachment meta.

    The preview images generated are used within the Media screen, Gallery, Attachment Details, and on the Attachment page for PDFs.

    Core support is provided through WP_Image_Editor_Imagick and requires Imagick, ImageMagick, and Ghostscript support. When not supported, or if the generation fails, WordPress falls back to previous behavior and saves the attachment without adding image previews to meta.

    For more context, see #31050 for the primary ticket and #38594 for the filter.

    Updated:

    Since this change requires having Imagick load only the first page of a PDF for performance reasons, this means that if you rely on core loading the entire PDF for your extension of WP_Image_Editor_Imagick, this will no longer function as expected (See: #38832).

    As a result, in [39303], the PDF setup code was moved to WP_Image_Editor_Imagick->pdf_setup(), which can be overridden to restore the previous behavior if needed.

     
    • yanai101 9:09 pm on November 15, 2016 Permalink | Log in to Reply

      WOW !!!

    • FolioVision 5:56 am on November 16, 2016 Permalink | Log in to Reply

      This is exactly the small but deft improvements WordPress.org core should be making to what is mature software now. Thank you very much Mike!

    • Julien 6:48 am on November 16, 2016 Permalink | Log in to Reply

      This is great news :))

    • Sergey Mochalov 1:27 pm on November 16, 2016 Permalink | Log in to Reply

      I waited this for the long time. thank you guys.

    • Tom Ryan 4:39 pm on November 16, 2016 Permalink | Log in to Reply

      Cool! Can the preview be used on a front end page too? Would love to have full (all pages) PDF preview and download capability.which can be inserted into posts.

      • Joe McGill 6:18 pm on November 16, 2016 Permalink | Log in to Reply

        They sure can, Tom. To do so, you would retrieve them just like you would an image asset, passing the ID and image size you want to generate to wp_get_attachment_image().

    • tristanfaganguimond 9:18 am on November 23, 2016 Permalink | Log in to Reply

      Excellent

    • Bjarne 5:04 pm on November 25, 2016 Permalink | Log in to Reply

      That’s a great improvement! Two questions?
      1) Is it possible to generate thumbs of existing PDF’s or is this for new uploads only?
      2) Is it possible to use the thumbnails when inserting media into a post, or via a gallery? In my tests, its still a text only link to the attachment page (which then shows the thumbnail). Without further coding that is… I’m testing on the Twenty Seventeen theme…

      /Bjarne

    • leemon 11:10 am on November 27, 2016 Permalink | Log in to Reply

      I don’t know if this has to do with this new PDF feature, but since upgrading to 4.7RC when I upload an image smaller than the smallest size set in the media settings, no thumbnail is shown in the media library/media uploader, the plain document icon is shown instead.

    • Knut Sparhell 4:56 pm on November 27, 2016 Permalink | Log in to Reply

      I always get the medium sized preview on the attachment page. Expected?

      What is the purpose of selecting size before inserting to the post, when only a text link appears in the post?

  • Joe McGill 5:40 pm on November 11, 2016 Permalink |
    Tags: , , ,   

    Improving accessibility of image alternative text in 4.7 

    WordPress 4.7 includes a change to the way image alt attribute values are generated. Formerly, any time WordPress created the markup for an image with an empty alt value, it would attempt to use either the caption text or the image title—in that order—as a fallback value.

    In 4.7, we have removed this fallback behavior.

    To ensure your images having meaningful alternative text, you should make sure to set a value for alt text in your media library.

    How removing fallbacks improves accessibility

    The intent of the fallbacks were to ensure each image included alternative text. In practice however, this fallback behavior often resulted in poor user experiences for people using screen readers. As counterintuitive as that may seem, let’s take a look at some common examples.

    Consider a situation where we’ve uploaded an image named “edbc4ef7.jpg” without changing any additional information. WordPress will generate the image title from the file name as shown in the following screenshot of the insert media modal.

    Attachment details for an image shown in the insert media modal.

    Formerly, inserting this image in a post would result in HTML similar to this (simplified slightly for clarity):

    <img src="https://example.wordpress.org/wp-content/uploads/2016/11/edbc4ef7-1024x683.jpg" alt="edbc4ef7" width="700" height="467" />
    

    A person using a screenreader on this page would end up hearing the file name read to them, which is not the most helpful experience, and can be quite frustrating when the file name is lengthy.

    For another example, setting a caption value but no alternative text would result in markup that looks something like this:

    <figure id="attachment_1741" style="width: 660px" class="wp-caption alignright">
        <img src="https://example.wordpress.org/wp-content/uploads/2016/11/edbc4ef7-1024x683.jpeg" alt="This is a caption." width="660" height="440">
        <figcaption class="wp-caption-text">This is a caption.</figcaption>
    </figure>
    

    Notice that the alt value and the figcaption text are redundant? WebAIM describes two ways of presenting alternative text:

    • Within the alt attribute of the img element.
    • Within the context or surroundings of the image itself.

    The same article goes on to explain that an alt attribute value may be omitted when an identical figcaption is present, to avoid redundancy; but best practice when using a figcaption is to provide a separate and different alt attribute to describe that image to users of screen readers.

    In each case, omitting the alt attribute entirely may result in screen readers reading the file name from the src attribute, so WordPress includes an alt attribute with an empty value, i.e. alt="", whenever the alternative text hasn’t been explicitly set—a technique that is common when an image is decorative.

    This change will not affect content already published, but will be the expected behavior for any new content published after upgrading to 4.7. For more background on this issue, see ticket #34635.

     
    • Carrie Dils 9:52 pm on November 11, 2016 Permalink | Log in to Reply

      +1

    • bahia0019 7:48 am on November 12, 2016 Permalink | Log in to Reply

      One thing to bear in mind is that while WebAIM will take either figcaption or alt, search engines haven’t declared the figcaption as a identifier in image search, whereas the alt tag is still in play with Google, et al.

      So, the alt should definitely not be pulled from image file name, but if a caption is filled out, it may be redundant for WebAIM, but it’s not redundant everywhere.

      • Joe McGill 2:51 am on November 13, 2016 Permalink | Log in to Reply

        Thanks for bringing that up @bahia0019. According to Google’s image publishing guidelines, they take several factors into account, including the file name and context around the image, including captions and titles. So it would appear that captions are indeed read by Google.

        Also, to be clear, if you define an alt attribute along with a caption for your images, WordPress will still display both. What has changed is that formerly, including a caption and omitting an alt value would result in the alt attribute duplicating the text that was in your caption.

    • FolioVision 7:21 pm on November 15, 2016 Permalink | Log in to Reply

      Hi Joe,

      Bahia’s quite right in making a difference between what Google says and what Google does.

      One shouldn’t take Google’s guidelines to heart. We coded lots of schema.org into a recipe plugin following Google’s guidelines, passing Google’s structured data tests. That markup was ignored for years, while an older form of microdata actually worked.

      For SEO, we should still be duplicating caption data to alt. It would be even more helpful to include an option to include file names at alt (for those who do use explicit file names), with the option turned off by default as most publishers these days are too lazy and amateur to name their media accurately.

      • Joe McGill 11:07 pm on November 15, 2016 Permalink | Log in to Reply

        Hi @FolioVision,

        Thanks for sharing your experience. I agree that anticipating how Google will actually parse markup in their algorithms is fairly opaque.

        In this case, the changes we have made do nothing to inhibit people from crafting `alt` attributes in ways that optimize how Google ranks their content, if they so choose. At the same time, we are making the experience better for actual users in the process.

        I think the benefits outweigh the downsides for publishers who aren’t taking the time to include good `alt` values with their images.

    • Aaron Jorbin 10:06 pm on November 15, 2016 Permalink | Log in to Reply

      WordPress should always choose the experience that humans have when interacting with a site over an attempt at better search rankings.

      This is a great change. Thanks to all the people who helped make it happen.

    • Chuck Reynolds 9:23 pm on November 16, 2016 Permalink | Log in to Reply

      👍

    • blepharisma 8:55 pm on November 21, 2016 Permalink | Log in to Reply

      I think this is just Step #1 — Step #2 would be to prompt the user to enter ALT text when the field is left blank.

      I know that the regulations differ in different countries, but in many is is becoming law that public and private business meet certain accessibility standards. Having the ALT text present is in the first level, and a prompt would go a long way to training content creators to automatically include this very important information.

      In similar implementations, a check box is present if the image is decorative.

  • Helen Hou-Sandi 4:01 am on November 11, 2016 Permalink |
    Tags:   

    4.7 beta and RC plans 

    To push us to get tickets resolved and take advantage of some shifting in my own schedule, I’d like to propose that we work quickly toward a beta 4 on Monday (November 14) and move RC back from Tuesday to Thursday (November 17). There are still 31 tickets open; I would like to get to 15 or below by beta 4, and the only one that should be open when we get to RC is the one for the about page. Be on the lookout for ad hoc scrubs and pings over the next week 🙂

    As a reminder, a release candidate should represent the software that we believe will ship, with any commits coming during the RC period being limited to regressions and serious bug fixes in new features. 4.7 will be branched off once we get to RC, at which time guest committers may continue to commit to trunk, but any merges back to the 4.7 branch must be done by a permanent committer with the additional review of another permanent committer (which includes lead developers).

     
  • Jeff Paul 2:30 am on November 11, 2016 Permalink |
    Tags: , ,   

    Dev Chat Summary: November 9 (4.7 week 12) 

    This post summarizes the dev chat meeting from November 9th (Slack archive).

    Reminders

    • Dev Chat timing: The Chat remains at 20:00 UTC.  Daylight Savings Time means that 20:00 UTC may be a different time for you already, or it may be a different time soon. However, next week we will be at 21:00 UTC.
    • Schedule: Today is the target for Beta 3! That leaves us one week until the Release Candidate, where the list of tickets must be at zero. It is currently at 32, down from 74 last week.
    • Tickets: For any tickets you’ve moved into the milestone, please make sure these are active tickets, with some kind of activity every day.
    • Bug Scrubs: @helen is running regular scrubs this week.
    • Dev Notes:  These will be compiled into the field guide this weekend.

    Bug Scrubs

    • Would like to see near daily scrubs for now until RC of report 6 and of the “Defects Awaiting Review, reported against trunk” section of report 40
    • @helen, @jorbin, and @jbpaul17 are all trying to run scrubs just about everyday, but everyone should also be scrubbing
    • Media, REST API, and Customizer component teams are all actively running scrubs as well

    Dev Notes / Field Guide for 4.7

    Beta 3

    • Likely to go out on Thursday morning instead of today, although given time zones and such we should operate on “it’s happening today” anyway
    • We are at 32 open tickets. Would love to see us get down to 20.
    • Work/tickets that folks would ideally like to resolve for Beta 3:
      • #38522: HTTP Errors on Upload with Certain PDFs
      • #38726: REST API: `unfiltered_html` and slashing: terms
      • #38672: Custom CSS should work with existing Jetpack custom CSS
      • #38541: Allow starter content to apply in a new theme when switching from another theme containing changes
      • #38660: Customizer: Edit shortcuts buttons: consider to don’t use flexbox
      • #38700: REST API: Cannot send an empty or no-op comment update
      • #38720: REST API: Updating a comment without sending content is valid, but unsupported
      • Starter content
      • Video headers

    Release Candidate

    • Please remember that with RC comes string freeze, so if you have any strings you think need to freeze, now is the time to get them in
    • We should be closing 4-5 tickets a day in order to hit RC on Tuesday.
    • Please keep testing, and working on patches.
     
  • Nick Halsey 7:18 pm on November 10, 2016 Permalink |
    Tags: , , ,   

    Visible Edit Shortcuts in the Customizer Preview 

    #27403 added visible edit shortcuts to the customizer preview, making it easier to see which elements of your site are editable in the customizer and how to edit them. Here’s a demo with Twenty Fifteen (note that the ability to toggle icons off has since been removed):

    Implementation: Selective Refresh Partials

    Visible edit shortcuts are an extension of the existing “shift-click-to-edit” functionality built into customizer partials. Partials are sections of the front end of the site, in the customizer preview, that are associated with customizer settings. When settings change, their associated partials are selectively refreshed via an Ajax call without reloading the entire preview. Partials are to the customizer preview what controls are to the customizer editing pane: a visual representation of a setting.

    Buttons are now injected into partials within the preview to expose this relationship visually and to users of all input modes. However, the role of the customizer preview is to provide an accurate representation of the frontend of the site as it’ll appear once changes are published. Accordingly, visible edit shortcuts pose a challenge as they have the potential to significantly hamper the preview-ability of the preview.

    To balance between discoverability and providing an accurate preview, the initial core iteration showed a flash of the buttons when the preview first loads, then hid them. To show the shortcuts, or to toggle them on and off, you could click/tap anywhere in the preview (except on a link or button). Keyboard users had a screen-reader-text button (visible on focus) to toggle the shortcuts on and off. This functionality was removed in [39131] and icons are currently persistently visible when customizing but hidden when the controls are collapsed, and supplemental usability testing validated this decision.

    Background & Prior Implementations

    Shift-click to edit an element in the customizer preview was first implemented with the widget customizer project in WordPress 3.9. Visual approaches to exposing this functionality were explored, but left for a future release. Selective refresh was also first proposed, and put on hold pending development of the concept.

    The first core implementation of selective refresh came with menu management in the customizer in WordPress 4.3. Menus include shift-click-to-edit on a per-menu-item bases, further demonstrating the powerful potential of associating portions of the customizer preview with their associated settings and controls.

    WordPress.com currently supports a similar feature with visible edit icons in the customizer. This approach serves as the inspiration for the final UI being introduced in core, with additional UX adjustments and a complete rewrite of the implementation to make it compatible with as many themes as possible.

    Adding Theme Support

    Theme support for this feature is all about supporting selective refresh, which was added in WordPress 4.5. In some cases, a small amount of additional CSS will be required to ensure that the shortcuts are positioned properly. Edit shortcuts will be enabled by default for all themes, but are contingent on themes supporting selective refresh.

    Selective Refresh for Widgets

    See the post from WordPress 4.5 for adding support for selective refresh for widgets. In most cases, add_theme_support( 'customize-selective-refresh-widgets' ) is the only requirement:

    Implementing Selective Refresh Support for Widgets

    Selective Refresh for Menus

    Menus support selective refresh out of the box unless: a custom nav menu walker is used, the echo argument is false, or wp_nav_menu isn’t used. In those cases, you’ll need to add support directly. Some themes may still be missing full support for selective refresh of menus, which has been enabled by default since WordPress 4.3.  Reference the post for details, but note that it predates the core implementation of an API for selective refresh:

    Fast previewing changes to Menus in the Customizer

    Selective Refresh for Custom Options

    Custom logo (since 4.5) and header video (since 4.7) support selective refresh automatically if you use the core features via add_theme_support. Other core options such as the site title and tagline or header images can support selective refresh if you register partials for them and set their settings’ transport argument to postMessage. Here’s an example from Twenty Fifteen:

    $wp_customize->get_setting( 'blogname' )->transport        = 'postMessage';
    $wp_customize->get_setting( 'blogdescription' )->transport = 'postMessage';
    
    $wp_customize->selective_refresh->add_partial( 'blogname', array(
    	'selector' => '.site-title a',
    	'render_callback' => 'twentyfifteen_customize_partial_blogname',
    ) );
    $wp_customize->selective_refresh->add_partial( 'blogdescription', array(
    	'selector' => '.site-description',
    	'render_callback' => 'twentyfifteen_customize_partial_blogdescription',
    ) );
    

    Where the render callbacks call bloginfo( 'name' ); and bloginfo( 'description' ); For more details on adding support for selective refresh for custom theme options, reference the official customizer documentation.

    Support in Default Themes

    Twenty Eleven through Sixteen support selective refresh as of WordPress 4.5, and also support edit icons for most of their features as a result. Twenty Fourteen and Sixteen require a few very minor positioning tweaks to ensure that all of the icons are visible. This is typical of what most themes could expect needing to add.

    Twenty Seventeen will be a great showcase for this new functionality, as the first theme to ship natively with selective refresh support and with visible edit shortcuts. A few additional adjustments in this new theme will ensure that every option can be previewed with selective refresh and provides visible edit shortcuts where appropriate.

    Limitations & Future Iterations

    The biggest limitation of the current approach is that implementation is entirely dependent on themes supporting it. However, unlike with many other theme-supported features, there is no add_theme_support for visible edit shortcuts. Where themes are already using selective refresh, shortcuts will be available out of the box in WordPress 4.7. To add theme support for edit shortcuts, themes need to add theme support for selective refresh, another newer customizer feature that allows the customizer preview to update granularly. Selective refresh provides superior user experience to the default refresh behavior because the preview context is not lost when changes are made.

    Edit shortcuts currently rely on the presence of selective refresh partials for every setting that needs an icon. Some settings may be previewed exclusively with JavaScript via postMessage. Icons also aren’t needed for every option; for example, layout or color options are broader than a specific area of the site, so they aren’t associated with a particular edit icon in the preview. In the future, a structured JavaScript API for partials in the customizer preview could facilitate adding icons to JS-previewed settings that don’t use selective refresh.

    Visible edit shortcuts are also the first step toward exploring the potential to edit elements of a site directly within the customizer preview. For this to be fully investigated, it’s imperative that a majority of themes and customizer option support selective refresh so that areas of the preview are associated with the appropriate customizer settings and so that context-disrupting full page reloads can be minimized.

    Contributors & Call for Help

    @sirbrillig led development of the feature for core based on the equivalent feature on WordPress.com. Core props went to @sirbrillig, @mattwiebe, @celloexpressions, @melchoyce, @westonruter, and @afercia. Thanks to everyone who has contributed so far!

    Now, your help is needed! Here’s what you can do to make this feature shine in WordPress 4.7:

    • Theme authors: add support for selective refresh to your themes. Start with widgets and make sure it’s working for menus, then make sure you’re using the core custom logo feature. Then, add selective refresh to the site title and tagline, header images, and any custom options with associated regions on the frontend.
    • Theme authors: adjust icon positioning in your theme’s CSS. You can add styles to.customize-partial-icon button to adjust all icons, and scope that to a specific container or even .customize-partial-icon-setting_id to adjust a particular edit icon. Note: these were updated with [39136].
    • Everyone: test edit shortcuts with your current theme with WordPress 4.7 Beta 1 (or newer). Most themes should be able to support them on widgets, menus, and logos with minimal effort. Contact your theme’s developer with any bugs or missing edit icon support, refer them to this post, and ask them to add support for visible edit shortcuts.
    • Everyone: test as many themes as possible and look for anywhere the shortcuts don’t display as expected, or at all. Contact the theme author with your findings, refer them to this post, and ask them to improve support for visible edit shortcuts in their themes.
     
    • Brad Markle 1:58 pm on November 30, 2016 Permalink | Log in to Reply

      Hi Nick! I sure wish you guys had this feature 6 months ago! I did quite a bit of work implementing similar “visible edit shortcuts” in a group of themes I help manage.

      If I need to disable this new feature within the Customizer, is the correct approach to toggle the customize-partial-edit-shortcuts-shown / customize-partial-edit-shortcuts-hidden classes within the body?

      Thanks!

      • Brad
    • Luke Cavanagh 10:17 pm on November 30, 2016 Permalink | Log in to Reply

      Solid feature improvement.

  • Peter Wilson 11:04 pm on November 7, 2016 Permalink |
    Tags: , ,   

    Whitespace changes in navigation for 4.7 

    In [38523] the argument item_spacing was introduced for the functions wp_nav_menu(), wp_list_pages(), and wp_page_menu() to:

    • ensure whitespace equivalent output when wp_nav_menu() falls back to wp_list_pages(), and,
    • allow theme authors to control how whitespace is output.

    Backward compatibility changes.

    There is a backward compatibility breakage when wp_nav_menu() is empty and falls back to using wp_list_pages().

    By default, wp_nav_menu() outputs markup with whitespace between each list item (</li> <li>). Prior to WordPress 4.7 when falling back to wp_list_pages() there would be no whitespace between list items (</li><li>). This caused layout to change when certain styles were applied.

    From WordPress 4.7 onward when falling back to a page list, wp_nav_menu() will output markup with whitespace between each list item.

    There is no change to the default behaviour when calling wp_list_pages() directly, it will not have any whitespace between each item in the menu.

    Controlling how menus and page lists output whitespace.

    From WordPress 4.7 onwards, theme authors will be able to control whether whitespace in wp_nav_menu(), wp_list_pages() and wp_page_menu() with the item_spacing argument.

    The item_spacing argument accepts either preserve or discard. To discard the whitespace in a menu, call the function with:

    wp_nav_menu( array(
    	'theme_location' => 'top',
    	'menu_id'        => 'top-menu',
    	'item_spacing'   => 'discard', // default 'preserve'
    ) );

    The same argument can be used for wp_list_pages(), and wp_page_menu() although the default is discard.

     
  • Dominik Schilling (ocean90) 9:20 pm on November 7, 2016 Permalink |
    Tags: , ,   

    Changed loading order for current user in 4.7 

    With the introduction of user locales it’s required to load the current user earlier in the bootstrap. Since WordPress 3.4 this is already the case for the customizer, see #24169 and the following simplified function stack:

    {main}()                              .../customize.php:0
    require_once( '/wp-admin/admin.php' ) .../customize.php:13
    require_once( '/wp-load.php' )        .../admin.php:31
    require_once( '/wp-config.php' )      .../wp-load.php:44
    require_once( '/wp-settings.php' )    .../wp-config.php:118
    do_action( 'plugins_loaded' )         .../wp-settings.php:295
    _wp_customize_include()               .../plugin.php:524
    WP_Customize_Manager->__construct()   .../theme.php:2086
    WP_Customize_Widgets->__construct()   .../class-wp-customize-manager.php:266
    current_user_can()                    .../class-wp-customize-widgets.php:97
    wp_get_current_user()                 .../capabilities.php:448
    

    For other requests the stack looks like this:

    {main}()                              .../index.php:0
    require_once( '/wp-admin/admin.php' ) .../index.php:10
    require_once( '/wp-load.php' )        .../admin.php:31
    require_once( '/wp-config.php' )      .../wp-load.php:44
    require_once( '/wp-settings.php' )    .../wp-config.php:118
    WP->init()                            .../wp-settings.php:398
    wp_get_current_user()                 .../class-wp.php:595
    

    WP->init() runs between the after_setup_theme and the init action.

    With WordPress 4.7 the function stack for admin requests will look like this:

    {main}()                              .../index.php:0
    require_once( '/wp-admin/admin.php' ) .../index.php:10
    require_once( '/wp-load.php' )        .../admin.php:31
    require_once( '/wp-config.php' )      .../wp-load.php:42
    require_once( '/wp-settings.php' )    .../wp-config.php:127
    load_default_textdomain()             .../wp-settings.php:389
    get_user_locale()                     .../l10n.php:665
    wp_get_current_user()                 .../l10n.php:92
    

    That’s because load_default_textdomain() needs to know the locale of the current user. load_default_textdomain() is called after setup_theme and before after_setup_theme (which is before WP->init()).
    If you compare this with the stack for the customizer then you’ll notice that wp_get_current_user() is still loaded much later.

    get_user_locale() is also used in the other text domain loading functions like load_plugin_textdomain() or load_theme_textdomain(). For backward compatibility we’ve made sure that no fatal errors are thrown when one of them is called before WordPress is fully initialized, see [39127] and [39134].

    Until recently BuddyPress and bbPress had a custom notice when a user was initialized without using WP->init(). This was fixed in #7305-buddypress and #2309-bbpress together with a new wp_roles_init filter in core. The new filter allows plugins to add their own custom roles whenever they’re initialized, see #23016.

     
    • Luke Cavanagh 9:27 pm on November 7, 2016 Permalink | Log in to Reply

      Thanks for sharing.

    • John James Jacoby 11:03 pm on November 7, 2016 Permalink | Log in to Reply

      Fun fact: my first ever WordPress IRC conversation was regarding the current-user load order, trying to load the proper language for a multilingual site I was working on for a client. Hence why BuddyPress & bbPress both had these notices built into them.

      Thank you to everyone that worked on fixing this for WordPress core. This is a huge deal, and lots of time & effort went into making sure this feature was done right. <3

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
Skip to toolbar