Make WordPress Core

Updates from November, 2016 Toggle Comment Threads | Keyboard Shortcuts

  • Nick Halsey 10:14 pm on November 30, 2016 Permalink |
    Tags: , ,   

    Customizer Improvements in 4.7 

    WordPress 4.7 has been the most active release on record for the customize component, with four major feature projects merging and shipping with 4.7 and over 90 tickets closed as fixed. This post summarizes the highlights of the user and developer-facing changes.

    4.7 Customizer Feature Projects

    Create pages within live preview during site setup

    Add new pages while building menus and setting a static front page; outline your site directly in the customizer.

    This project began with the ability to create posts and pages direction from the available menu items panel in the customizer, as originally proposed near the end of the 4.6 cycle:

    Feature Proposal: Content Authorship in Menus, with Live Preview

    Subsequent changes also added the ability to create new pages when assigning the front page and posts page in the Static Front Page section. Because this is now built into the core dropdown-pages customizer control, themes and plugins can also allow users to create new pages for their options instead of relying on existing content. The homepage sections in Twenty Seventeen include this new allow_addition parameter. Here’s how to register a dropdown-pages control supporting new pages:

    $wp_customize->add_control( 'featured_page', array(
    	'label'          => __( 'Featured Page', 'mytextdomain' ),
    	'section'        => 'theme_options',
    	'type'           => 'dropdown-pages',
    	'allow_addition' => true, // This allows users to add new pages from this dropdown-pages control.
    ) );

    Additionally, a proposal for term statuses was developed as a first step toward expanding the menus functionality to work for creating and previewing taxonomy terms in a future release (see #37915).

    Improvements to the Sliding Panels UI

    Customizer navigation is now faster, smoother, and more accessible.

    This project tackled a series of tickets focused on improving the usability of the “sliding panels” UI in the customizer controls pane. The first step was to refactor the section and panel markup so that sections and panels are not logically nested. This is the biggest internal change to the UI and has a dedicated post going into the details:

    Changes to Customizer Sliding Panels/Sections in WordPress 4.7

    This primary change resolved numerous problems with sections and panels not opening and closing properly, and eliminated situations where navigation to leave a section could become hidden. The next step was making section and panel headers “sticky” so that navigation is easier to access within long sections (such as for a menu); see #34343.

    Finally, hover and focus styling for navigation in the customizer has been updated to use the blue-border approach found elsewhere in core, including for the device-preview buttons in the customizer, in #29158. This completes a refresh of the customizer controls pane’s UI design that began in WordPress 4.3 with #31336. The core UI now uses the following consistent UI patterns in the customizer:

    • White background colors are used only to indicate navigation and actionable items (such as inputs)
    • The general #eee background color provides visual contrast against the white elements
    • 1px #ddd borders separate navigational elements from background margins and from each other
    • 15px of spacing is provided between elements where visual separation is desired
    • 4px borders are used on one side of a navigation element to show hover or focus, with a color of #0073aa
    • Customizer text uses color: #555d66, with #0073aa for hover and focus states on navigation elements

    Plugins and themes should follow these conventions in any custom customizer UI that they introduce, and inherit core styles wherever possible.

    Any custom sections and panels, as well as customizations to the core objects in plugins and themes, should be tested extensively to ensure that they continue functioning as intended with all of these changes in 4.7. It’s particularly important to ensure that things like the use of color match the core conventions so that the user experience is seamless between functionality added by plugins and core.

    Customize Changesets (formerly Transactions)

    Browse your site and switch themes more seamlessly within the customizer, as your changes automatically persist in the background.

    This project rewrote the internals of the customizer preview mechanism to make changes persistent. Each change made to a setting in the customizer is saved to a changeset (a new customize_changeset post type), facilitating future features such as scheduled changes, revisions, or saving and sharing drafted changes. Changesets also open the door to using the customizer to preview Ajax requests, headless sites, and REST API calls for mobile apps. In 4.7, changesets enable switching themes in the customizer without needing to decide between publishing or losing your customizations, as they’re automatically persisted in the background.

    For more details on changesets, check out the two dedicated posts:

    Customize Changesets (formerly Transactions) Merge Proposal

    Customize Changesets Technical Design Decisions

    Custom CSS

    Fine-tune your site and take your theme customizations to the next level with custom css in the customizer.

    #35395 introduced a user-oriented custom CSS option in the customizer. Now that the base functionality is in place, it will be further enhanced in #38707 in future releases. Read the feature proposal for details on the implementation and why it’s important for core:

    Feature Proposal: Better theme customizations via custom CSS with live previews

    There’s also a dedicated post that walks through the process of migrating existing custom CSS options in themes and plugins to the core functionality – be sure to follow those steps if your plugin or theme does custom CSS:

    Extending the Custom CSS editor

    Other Changes with Dedicated Posts

    4.7 features several other features deserving special attention. Read the posts for visible edit shortcuts (which expand the functionality of customizer partials), video headers (which extend the custom header feature), and starter content for more information:

    Visible Edit Shortcuts in the Customizer Preview

    Video Headers in 4.7

    Starter content for themes in 4.7

    Additional User-facing Changes

    With over 90 tickets fixed in the customize component in 4.7, we can’t cover everything here. But, here are a few more highlights:

    Improved Custom Background Properties UI

    #22058 introduces a more comprehensive and more usable custom background properties UI when a custom background is set up. There are now presets to control all of the detailed options at once, and the individual options are presented in a more visual way. Background size and vertical position are also now available as standalone options when using a custom preset.

    Theme developers should update their add_theme_support() calls for custom-background to specify the default size, vertical position, and preset to reflect their default background image CSS. Perhaps the most significant improvement here is the ability for users to easily set up fixed full-screen backgrounds – and the ability for themes to make that behavior default if desired.

    And even more…

    4.7 also:

    • Loads the frontend preview iframe more naturally, eliminating a lot of weirdness with JS running in an unexpected location and ensuring that JS-based routing will work (#30028)
    • Allows the search results page to be previewed, and any forms that use the GET method in general can now be submitted whereas previously they would do nothing when submitted (#20714)
    • Hides edit post links in the customizer by default. Plugins, such as Customize Posts, can restore the links if they make post editing available in the customizer (#38648), although the visible edit shortcuts should generally be used instead.
    • Shows a cursor: not-allowed for mouse users when hovering over external links in the preview, as these can’t be previewed
    • Officially removes support for the customizer in Internet Explorer 8, preventing users of this outdated browser from accessing the customizer at all (#38021)

    Additional Developer-oriented Changes

    Hue-only Color Picker

    #38263 adds a hue-only mode to the Iris color picker, wpColorPicker, and WP_Customize_Color_Control. Built for Twenty Seventeen’s custom colors functionality, the hue-only mode allows users to select a hue and saves the hue degree as a number between 0 and 359. To add a hue-color control:

    $wp_customize->add_control( new WP_Customize_Color_Control( $wp_customize, 'colorscheme_hue', array(
    	'mode' => 'hue',
    	'section' => 'colors',
    ) ) );

    As demonstrated in Twenty Seventeen’s custom colors strategy, the hue-selection strategy opens up a whole new world of possibilities for custom color options in themes. Rather than introducing numerous text and background color options and requiring users to adjust them to ensure that adequate color contrast is provided, themes can consolidate their color options into one or more hue pickers. Then, the corresponding use of hsl colors in CSS allows themes to define color patterns where users customize color hues without impacting the lightness of a color option, thereby preserving the designer’s use of proper contrast between text and background colors, and any use of color lightness for visual hierarchy. Check out the implementation in Twenty Seventeen for inspiration (including instant live preview).

    Fix Sections that .cannot-expand

    When creating custom customizer sections that, for example, display an external link but don’t actually expand to show section contents, the cannot-expand class can be added to the section title container to prevent JS events and CSS hover/focus styles from being applied. Be sure to also remove the tabindex="0" from the container if you copy the core code since your custom section shouldn’t be focusable if it can’t expand (and any contained links or buttons would be keyboard-focusable automatically). See #37980 for details.

    Allow Plugins to do Comprehensive Late Validation of Settings

    To account for custom subclasses of WP_Customize_Setting that don’t apply the customize_validate_{{$setting_id}} filter, this filter now will be applied when WP_Customize_Manager::validate_setting_values() is called. This ensures that plugins can add custom validation for every setting. For more, see #37638.


    Huge thanks to the 61 people (and counting) receiving props for the 120+ customize component commits in 4.7 (as of RC2): @westonruter, @celloexpressions, @afercia, @sirbrillig, @ryankienstra, @helen, @ocean90, @melchoyce, @bradyvercher, @folletto, @johnbillion, @delawski, @karmatosed, @georgestephanis, @dlh, @curdin, @valendesigns, @mattwiebe, @michaelarestad, @joemcgill, @sstoqnov, @lgedeon, @mihai2u, @coreymcollins, @stubgo, @utkarshpatel, @desrosj, @odysseygate, @johnregan3, @aaroncampbell, @mapk, @iseulde, @mrahmadawais, @vishalkakadiya, @sayedwp, @hugobaeta, @jonathanbardo, @jorbin, @tristangemus, @deltafactory, @kkoppenhaver, @seancjones, @presskopp, @Mista-Flo, @nikeo, @adamsilverstein, @lukecavanagh, @coffee2code, @peterwilsoncc, @presskopp, @pento, @Kelderic, @sebastian.pisula, @mckernanin, @FolioVision, @MikeHansenMe, @welcher, @cdog, @grapplerulrich, @iamfriendly, @flixos90.


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


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

      Solid feature improvement.

    • AJ Clarke (WPExplorer.com) 7:02 am on December 12, 2016 Permalink | Log in to Reply

      I have an issue with the selective refresh icon not working after the theme mod is altered for the first time – https://cl.ly/3A3b1e3S1u12 – when you first load the Customizer you can click the icon and it goes to the correct section but after the partial refresh the icon is not clickable anymore (no errors in the console).

      Is there an argument that can be used using $wp_customize->selective_refresh->add_partial to disable the icon for the specific partial?

      Thanks!! Besides this bug, it is a nice feature!

      To add..doing shift+click on the element always works.

      • AJ
    • AJ Clarke (WPExplorer.com) 7:41 pm on December 29, 2016 Permalink | Log in to Reply

      Yes that fixes it! Thank you so much for the reply Nick.

      Happy Holidays,

    • AJ Clarke (WPExplorer.com) 1:54 am on January 11, 2017 Permalink | Log in to Reply

      I’ve noticed when adding a selective_refresh partial that uses the_content() it always returns empty. You can test it easily by using ‘render_callback’ => ‘the_content’. Is this a limitation of the Customizer done on purpose? Thanks!

    • scamartist26 4:51 pm on January 16, 2017 Permalink | Log in to Reply

      Is there a way to remove these icons? On my personal, and heavily widgetized theme I find it as a big distraction.

    • cramdesign 3:15 pm on January 17, 2017 Permalink | Log in to Reply

      Is there not a way that built in WordPress functions (get_bloginfo, wp_nav_menu, etc) could have selective refresh already baked in?

  • Eric Binnion 7:29 pm on March 9, 2016 Permalink
    Tags: ,   

    Week in Core, Mar 1 – Mar 8 2016 

    Welcome back the latest issue of Week in Core, covering changes [36801-36888]. Here are the highlights:

    Ticket numbers based on trac timeline for the period above.

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

    (More …)

  • Pascal Birchler 11:18 am on April 4, 2015 Permalink
    Tags: ,   

    WordPress Core Weekly 

    Here we go again! It’s time to look at what’s going on in WordPress core. This edition of WordPress Core Weekly covers March 28, 2015 [31916] through April 4, 2015 [32002].

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

    Highlights from this week

    This week WordPress 4.2 Beta 4 got released. This hopefully last beta saw lots of accessibility improvements and added the ability to make admin notices dismissible. Emoji support in core is now pretty stable – maybe the next weekly post is written in emojis only? Also, there were some notes posted on utf8mb4 and the term splitting in WordPress 4.2.

    Last but not least, @obenland and @wonderboymusic were announced as release leads for WordPress 4.3 and 4.4, respectively. Congrats! 🎉

    Code Updates

    Posts, Post Types

    • After [31114] and [31323], ‘View Post’ generated in get_sample_permalink_html() should go to pretty permalink. [32002] #30910
    • Avoid duplicate classes for different terms with UTF–8 slugs in post_class() and body_class(). [31979] #30883
    • In WP_Posts_List_Table::get_views(), don’t add the current class to the all status link if ->user_posts_count has a value, which triggers the additional mine status. [31959] #24869


    • WP_User_Query: When querying users with fields=all, ensure that caps and roles are filled for the current site. [32001] #31878
    • When updating the email address for an existing user, make sure the email address is not already in use. [31963] #30647



    • WordPress 4.2-beta4 [31997][31998]
    • Respect numerical keys in add_query_arg(). Avoid the use of array_replace() in add_query_arg(). [31966][31967] #31306
    • TinyMCE: always focus the editor after using the floated toolbar. [31972] #30619


    • Enhance twemoji.js to support passing of additional attributes for the replacement images. [31948] #31627
    • When encoding emoji into HTML entities, 0 was being incorrectly trimmed from the right side of the hex string, causing some characters to be encoded incorrectly. [31926]
    • When staticizing emoji into <img> tags, include an alt attribute of the original Emoji, to match both Smiley and Twemoji <img> tags. [31924]
    • Change the emoji CDN to w.org, from wp.com. [31938][31977] #31651


    • Accessibility improvements for Themes screen: fix keyboard events and callbacks for the Search field, increase trigger timeout a bit, improve Esc. key handling. [31994] #26600
    • Improve focus styling of add-new-theme link. [31952] #31203
    • Add a filter to short-circuit wp_prepare_themes_for_js(). [31943] #31789


    • Accessibility improvements for Options general screen: add missing labels and aria attributes. [31993] #31144
    • Accessibility: Add landmark roles to WordPress admin areas. [31955] #31450
    • Make sure the update button in “At a Glance” dashboard widget does not overlap with long strings. [31928] #30766

    Press This

    • Prevent pasting of HTML in the title H2. Insert the clipboard text instead. [31987] #31768
    • Use more accurate wording on Tools screen. [31980] #31836
    • Use the error message returned by wp_update_post() instead of a generic one. [31930] #31808
    • Fix accessibility for the post options “sidebar”. Fix size of the Add Category button. [31925] #31575


    • Introduce a string representing bulk plugin update success, ready for string freeze. Not used yet. [31991] #31770
    • Plugins Browser: Replace the download count with the number of Active installs of the plugin. [31990] #31865
    • Add beforeunload string for shiny updates. [31989] #31769
    • Update aria-label when doing a shiny plugin update [31982] #31722
    • Add some logic into wp_tempnam to prevent it creating ‘falsey’ directory names that might get used elsewhere within WordPress. [31936] #31811


    • Merge title strings on Edit Site screens. [31962] #31844
    • Remove unused printf() on network setup screen. [31961] #31841
    • Decouple strings where the singular and plural form are not just the same string with different numbers, but essentially two different strings. [31941][31951] #28502


    • Theme Switcher: Navigation streamlining. [31975] #31289
    • Theme Switcher: Remove “Add New” references. [31968] #31837
    • Theme Switcher: Switch the details/live preview buttons. [31954] #31791
    • Theme Switcher: Use the global panel back button instead of adding a new one. [31918] #31794
    • Theme Switcher: Fix invalid HTML markup when New Theme control is added. [31950] #31203
    • Make the available widgets overlay closable on narrow screens. [31974] #28784
    • Defer rendering theme controls until the section is displayed. [31944] #31793
    • Revert [31911]. We want to preserve url and return URL parameters to make the experience smoother. [31933] #31782
    • Increase size of search field and disable text size adjustment to prevent auto zooming. [31917] #31794
    • Increase initial-scale viewport specification to 1.0. [31921] #31794, #28784
    • Fix selector for container which includes the controls. Broken since [30102]. [31916] #31794, #31014


    • Correctly set the post author in wp_xmlrpc_server::mw_editPost() when the current user is not the author of the post. [31983] #24916

    Networks and Sites


    • Admin notices: Make (most) core notices dismissible. These no longer return upon refreshing the page when JS is on and working, so users should be able to dismiss them. [31973] #31233, #23367

    Bundled Theme

    • Twenty Eleven: add postMessage support for header_textcolor to improve the user experience in the Customizer. [31971] #24128
    • Twenty Fifteen: adjust scroll behavior to make sure sidebar height is calculated during scroll events, not just resize events. [31934] #31734
    • Twenty Thirteen: make sure submenu links work correctly on small screens with touch events. [31932] #31762


    • Alter the regex in wptexturize() to properly handle input like: <> "Hello world" <>. [31965] #30344


    • When shifting WP_Rewrite::flush_rules() to a later action if it was called too early, make sure to do a hard flush if requested. [31964] #30501


    • When editing an image from the editor, and the image has a value for alignment (but not for width or caption), don’t bail without first checking that the alignment’s value is not alignnone. If so, add the class to the <a> before bailing. [31958] #21848
    • Media Library: Add a label for attachment type select in list mode. [31942] #31795



    • When we check the character set of a column, and find that it’s utf8mb4, we should also check that the current connection supports utf8mb4. It’s possible that the environment may have changed since upgrading the DB, so we can fall back to utf8 when that happens. [31947] #31771
    • When we’re checking to see if the MySQL client library supports utf8mb4, we need a separate check for mysqlnd versions, which using different version numbering to libmysqlclient. [31939] #31644

    Login and Registration

    • Disable body scrolling when session expired log in modal is open. [31945] #31610


    • Revert using require for JS modules because that made them read-only for the public. [31935] #31684, #28510


    • Fix duplicate ID for Save Menu button on Menus screen. [31927] #31803

    Thanks to @A5hleyRich, @adamsilverstein, @afercia, @azaozz, @boonebgorges, @cdog, @celloexpressions, @davideugenepratt, @dd32, @deconf, @Denis-de-Bernardy, @designsimply @dllh, @DrewAPictur, @DrewAPicture, @ericlewis, @evansolomon, @folletto, @helen, @iseulde, @jeremyfelt, @joedolson, @johnbillion, @jorbin, @jorbin, @kraftbj, @lancewillett, @markoheijnen, @mattheu, @mattwiebe, @MattyRob, @mehulkaklotar, @MikeHansenMe, @miqrogroove, @mordauk, @mrahmadawais, @ocean90, @paulwilde, @pento, @ramiy, @redsweater, @rittesh.patel, @sagarjadhav, @SergeyBiryukov, @sgrant, @stephdau, @swissspidy, @tyxla, @valendesigns, @westonruter, and @wonderboymusic for their contributions!

  • Pascal Birchler 9:48 am on March 28, 2015 Permalink
    Tags: ,   

    WordPress Core Weekly 

    Hi Everyone!

    It’s time for another run-down of what’s going on in WordPress core. This edition covers March 20, 2015 [31845] through March 28, 2015 [31915].

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

    This week’s highlight is WordPress 4.2 Beta 3, which was released on Thursday. There were many accessibility and emoji improvements and bug fixes. Also, shiny installs functionality was removed.


    • Improve newly added strings for i18n. [31905] #31776
    • Remove <code> tags from translatable strings. Uncomment deprecation notice for get_bloginfo( 'text_direction' ). [31899] #30614


    • Theme Switcher: Opening themes details modal shouldn’t require two clicks on touch devices. [31914] #31794
    • Theme Switcher: Reset font size of theme names in overlay. Apply left position only to themes section. [31892] #31303
    • Theme Switcher: Don’t hide action buttons on narrow screens. [31912] #31794
    • Use proper preview URL for Live Preview links. [31911] #31782
    • Avoid SecurityErrors when the Customizer is embedded in an origin other than wp-admin. [31885] [31893] #31687
    • Use responsive button styles if screen is max-width 640px. [31913] #31794, #28784


    • [31864] changed emoji image’s inline style from height to max-height. Unfortunately, anything using feedparser.py (for example, NewsBlur) strips out max-height, which gives us massive emoji in feeds. This re-adds height, and also reminds us why we can’t have nice things. [31909] #31719
    • When we’re replacing emoji with <img>s in email, we can only do that if the Content-Type is text/html – otherwise, they’ll show up in the email as the HTML string. [31860] #31720
    • Instead of loading the emoji JS files automatically, we now include a small JS shim in the header, to test if the user’s browser needs Twemoji. It then loads the emoji JS files only if they’re needed. [31875] [31877] [31879] #31701
    • Set the emoji image protocol with set_url_scheme(), instead of defaulting to HTTPS. [31861] #31735

    Press This

    • Remove role="application" from the Categories list wrapper. This doesn’t make it work better in screen readers. [31907] #31443
    • On sites that support oEmbed, if the user has selected some text, quote it below the embed. [31894] #31763
    • Fix the links on inserted images to point to the source site. Fix inserting of images above the blockquote when the editor has not been focused. [31868] #31745


    • Fill $plugins['upgrade'] with extra info for use in list table [31872] #31738
    • Remove Shiny Plugin Installs [31897] [31900] [31901] #31773, #29820
    • When creating a temporary working directory, strip off .tmp as well as .zip incase we end up using that directory as the items main directory. [31863] #30945


    • Remove ambiguity in the time display format in core, switches to using 24hr notation where am/pm isn’t specified. [31862] #31121
    • Comments List: Don’t let “Quick Edit” break on smaller screens. [31889] #31482
    • Admin menu: Revert [31720] for swipe open/closed. This is problematic on any device that uses swipe for history navigation, particularly iOS. [31910] #31187
    • Do not output empty name and id HTML attributes in get_submit_button(). [31880] #31749
    • When altering the admin URL to reflect the canonical location, keep the existing hash (if present) in the URL. [31882] #31758, #23367
    • WordPress 4.2-beta3 [31902] [31903]


    • When saving post, ensure that non-hierarchical taxonomy input is defined before attempting to parse it. [31895] #30859
    • Taxonomy List Tables: On mobile devices, hide the slug column, to avoid cramping the action links into two rows. [31865] #29992
    • Supplement hook documentation for the get_terms_fields filter to more clearly explain the expected consequences of using it to modify the fields to select in a terms query. [31855] #31174


    • Make sure the editor is not completely empty before checking if the user clicked above or below a wpView. [31888] #31765
    • Pad empty paragraphs with <br> in Chrome to stop it from inserting non-breaking spaces in them. [31878] #31255
    • Fix error and PHP warning when adding more than one instance in RTL mode. [31874] #31578
    • Fix the icon for the wp_code button. [31858] #31733
    • When pasting an URL, check if the node it is pasted at is empty and remove any empty inline child elements. [31856] #31158

    Script Loader

    • Avoid a PHP notice in wp_enqueue_script() if $handle is an array. Calling wp_enqueue_script() with an array as the first argument is a “hidden feature” and should be avoided. Use dependencies instead. [31887] #31636, #14488


    • Text Widget: Use !empty() for checking if the filter setting is set. [31886] #31690
    • Trigger _doing_it_wrong() if register_sidebar() is not passed an id. [31850] #31675

    Login and Registration

    • Implement an aria-describedby attribute for login screen errors, and improve the “Forgot password?” anchor text. [31871] #31143


    • Introduce attachment_url_to_postid filter to let plugins manage the uploads location better. [31867] #31717
    • Show filename instead of extension in the list table. [31857] #30943

    Bundled Theme

    • Update editor styles to better display images and captions in small screens. [31849] #31250

    Build/Test Tools

    Thanks to @A5hleyRich, @afercia, @aferica, @atimmer, @azaozz, @boonebgorges, @Cheffheid, @dd32, @dkotter, @DrewAPicture, @ericlewis, @extendwings, @HarishChaudhari, @helen, @ianmjones, @iseulde, @jacklenox, @janhenckens, @johnbillion, @johneckman, @jorbin, @kraftbj, @lamosty, @lancewillett, @magicroundabout, @maimairel, @markjaquith, @mattheu, @mattwiebe, @MikeNGarrett, @nerrad, @obenland, @ocean90, @pento, @ramiy, @rianrietvel, @SergeyBiryukov, @sorich87, @stephdau, @swissspidy, @tschutter, @tyxla, @valendesign, @valendesigns, and @westonruter for their contributions!

    • Piet Bos 10:27 am on March 28, 2015 Permalink | Log in to Reply

      There is another open ticket for Emojis and that is #31651 with the request to switch the CDN from the .com domain to the .org domain

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

    WordPress Core Weekly 

    Hi Everyone!

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

    First, a couple quick notes!


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

    Twenty Fifteen


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


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


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



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


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


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

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

    Revisions covered: [30094] to [30292]. For the complete list of commits to trunk, check out the log on Trac.

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

  • Pascal Birchler 8:21 pm on October 29, 2014 Permalink
    Tags: ,   

    WordPress Core Weekly 

    Hi everyone!

    It’s this time of the week again: WordPress Core Weekly is here. This updates covers all commits since last week up to to today, October 29th.

    In case you missed it, the new default theme, Twenty Fifteen, is coming along very well, the feature plugins planned for 4.1 are being tested extensively and the Customizer JavaScript API is getting more and more complete.

    But there are many more things going on behind the scenes and Core has even passed revision [30,000]! Let’s have a look at this week:


    • Add labels to the Personal Options input fields on the user profile editing screen. [30027] #30101
    • Editor: Use <button> instead of <a> for the Visual/Text buttons, make them focusable. [30002] #27553
    • Customizer: Add the ability for a customizer control to render its controls via a JavaScript template. Switches the default color picker control to a JavaScript template. [30014] #29572


    • Twenty Fifteen: If the sidebar is taller than the viewport scroll it with the content, if it’s shorter keep it fixed. [30025] #29979
    • Introduce a new means of outputting a <title> tag in the theme head. Requires a theme to add support by calling add_theme_support( 'title-tag' ). [30074] #18548
    • Introduce some new template functions for navigation [30065] #29808
      • get_the_post_navigation() and the_post_navigation() for navigation to the next and previous post.
      • get_the_posts_navigation() and the_posts_navigation() for navigation to the next and previous page of posts.
      • get_the_pagination() and the_pagination() for paginated navigation between pages of posts.
      • Uses paginate_links(). This reduces the need for themes to define their own sets of navigation functions.


    • Deprecate admin_created_user_subject() [30005] #29915
    • Introduce an edit_form_before_permalink action which gets fired after the title field but before the permalink fields. [30028] #29691
    • In wp_link_pages(), only output link separators between actual pagination links. [30030] #24940
    • Rename _wp_password_hint() to _wp_get_password_hint() to bring it inline with core terminology. [30033] #21243
    • Don’t add sticky class in get_post_class() if ignore_sticky_posts query var is set. [30036] #18035
    • Don’t display Standard post format twice in the meta box if the theme unnecessarily mentions it in the add_theme_support() call. [30038] #16555
    • Add comment_reply_link_args filter for get_comment_reply_link() arguments. [30039] #10569
    • Allow slug param of get_terms() to accept an array. [30042] #23636
    • Introduce orderby=include support for get_terms(). [30052] #23261
    • Remove UNIQUE key from slug column of terms table. [30056] #22023
    • Add wp_json_encode(), a wrapper for json_encode() that ensures everything is converted to UTF-8. Change all core calls from json_encode() to wp_json_encode(). [30055] #28786
    • Introduce wp_is_trusted_network(). A first step to establish concepts around trusted and untrusted networks. [30071] #30145
    • Don’t hardcode height for videos – this was a workaround for MediaElement internals causing problems. Responsive videos now work properly and don’t cause extra whitespace. [30082] #30078
    • Introduce some actions and filters which aid plugins in revisioning post meta. [30091] #20564


    • Allow ORDER BY in WP_Comment_Query::query() to be disabled. [30004] #29902 DisableORDER BY by passing boolean false, an empty array, or the string none to the orderbyparameter. This mirrors the behavior of WP_Query.
    • Accept orderby=include in WP_User_Query. [30016] #30064 This lets the results of a user query be sorted manually by the value of the include param.
    • Fix count in WP_Comment_Query when using meta_query. [30026] #23369
    • Optimize site query when performing network database upgrades [30029] #30097
    • Improve WP_Tax_Query param sanitization for empty strings. [30031] #30117
    • Support multiple status values in WP_Comment_Query. [30084] #29612

    Thanks to @peterwilsoncc, @iamtakashi, @nacin, @mnelson4, @afercia, @psycleuk, @rianrietveld, @davidakennedy, @celloexpressions, @DrewAPicture, @jipmoors, @ipm-frommen, @mattwiebe, @avryl, @heshiming, @desaiuditd, @ankit-k-gupta, @captaintheme, @marcosf, @obenland, @tmtrademark, @briandichiara, @tareq1988, @jakub.tyrcha, @johneckman, @kosvrouvas, @ptahdunbar, @nacin, @pushplaybang, @joedolson, @aaroncampbell, @jfarthing84, @dlh, @danielbachhuber, @wpsmith, @hotchkissconsulting, @JustinSainton, @jwenerd, @wonderboymusic, @tollmanz, @chrisbliss18, @joostdevalk, @TobiasBg, @nofearinc, @karpstrucking, @ebinnion, @boonebgorges, @mattheu, @adamsilverstein, @momo360modena, @tareq1988 for their core contributions!

    Revisions covered: [29995] to [30093]. For the complete list of commits to trunk, check out the log on Trac.

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

  • Mike Schroder 2:18 am on May 21, 2014 Permalink
    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.


    • 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


    • 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


    • 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



    • 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


    • Fix case sensitivity regressions in 3.9. [28276] #27866
    • Treat “www” as a special subdomain, reversing 3.9 regression. [28280] #27927

    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.

  • K.Adam White 9:48 pm on November 5, 2013 Permalink
    Tags: ,   

    JavaScript Coding Standards 

    The PHP files in WordPress core become cleaner and easier to read with every release, thanks in part to our standards for PHP code style. Our JavaScript, on the other hand, hasn’t gotten nearly enough love. This post is intended to open up the recent discussion around JavaScript style to the greater community so we can make up for lost time.

    Don’t we already have a style guide for JavaScript?

    Back in March, @tommcfarlin added a set of coding standards for JavaScript to the developer handbook. These WordPress JS coding standards are a great work-in-progress, but weren’t fully comprehensive (leading to some comment threads clarifying various areas). More importantly, without any clear implementation plan the style guide failed to gain traction.

    At WordCamp Boston’s core contributor day I revisited this style guide with @mattwiebe and Corey Frang (@gnarf37). It is important to identify *and implement* conventions for JS style ASAP because syntax issues in the JS within WordPress may hide latent bugs, and inconsistent code discourages contribution. Focusing on implementation lead us to look for an existing, proven JS style guide with a .jshintrc file (a set of configuration options for the JSHint code quality tool) which we could adopt largely as-is: Getting JSHint in place lets us see the biggest issues in our JS, so we can begin tackling them incrementally (perhaps in the same manner as the inline docs effort).

    After looking at Idiomatic.js and several other widely-adopted JS style guides, we feel the jQuery Foundation’s jQuery Core JavaScript Style Guide guide is the closest match for what we need in WordPress.

    Adopting the jQuery Core JavaScript Style Guide

    jQuery’s guide shared WordPress core’s love of white space—the same “when in doubt, space it out” mantra from the existing JS style page. Moreover, jQuery’s code conventions have been referenced in trac tickets as an example of how we should be writing our code. Adopting their guide wholesale capitalizes on our stylistic similarities, and will let us adopt their .jshintrc and any future code quality tools they write with minimal changes.
    (More …)

    • Pbearne 9:55 pm on November 5, 2013 Permalink | Log in to Reply

      I will be happy do a bit of this.

    • deltafactory 9:57 pm on November 5, 2013 Permalink | Log in to Reply

      I’ve been thinking about threequals and curly-braces since Boston. It’s hard to break the habit.

      I’d like to help with the cleanup effort. It would benefit me to familiarize myself with more of the JS bits of WordPress.

    • Mike Bijon 9:58 pm on November 5, 2013 Permalink | Log in to Reply

      After reading the summary in email, my only concern was jQuery’s use of double-quotes vs. ours … seeing the longer article, that’s handled and I can’t think of any reasons to object.

      On the + side, adopting jQuery’s standards wholesale should reduce maintenance & debate. Plus, getting started sooner than later to *any* standard should help speed JS work & maybe help a few overly-debated JS tickets in Trac.

      Looking forward to seeing the sprint schedules

    • adamsilverstein 10:27 pm on November 5, 2013 Permalink | Log in to Reply

      Great post, thanks! I will try to make the meeting tomorrow and assist in the cleanup effort.

    • Matt Wiebe 10:46 pm on November 5, 2013 Permalink | Log in to Reply

      I have another (virtual) meeting at the same time, but I should be able to chime in.

      Thanks for pushing this forwards @kadamwhite 🙂

    • ericsherred 10:59 pm on November 5, 2013 Permalink | Log in to Reply

      Sounds like fun to me.

    • Dion Hulse 12:07 am on November 6, 2013 Permalink | Log in to Reply

      Wouldn’t it be better for us to standardise on for ( var i = 0; i < 100; i++ ) { instead of including var outside of the iterator? IIRC, including it outside was for some rather old browsers that we no longer (and probably haven’t for a long time) supported.

      • Andrew Ozz 1:12 am on November 6, 2013 Permalink | Log in to Reply

        As far as I remember defining all vars at the beginning of the scope mimics the actual way the script is parsed. Don’t think defining vars in the middle or end was a problem in any browser.

        • Dion Hulse 1:19 am on November 6, 2013 Permalink | Log in to Reply

          I thought I’d heard a rumour of an early IE bug.. but you’re probably right, defining it earlier is most likely only a parsing optimization, something we probably don’t need to worry about.

        • Tom McFarlin 1:52 am on November 6, 2013 Permalink | Log in to Reply

          +1 to this.

          Including all var declarations at the beginning of the function is how the script is parsed, and for those who are fans of JSLint, you’ll notice that combining all var declarations together is preferred[0].


        • K.Adam White 2:14 am on November 6, 2013 Permalink | Log in to Reply

          As Tom notes, Andrew is correct—Variable declarations are “hoisted” to the top of the function’s scope, so declaring all your variables first is a best practice (it unifies the code’s visual structure with how it is parsed by the JS engine). There’s actually a “onevar” parameter in JSHint to enforce this style.

      • WraithKenny 2:10 am on November 6, 2013 Permalink | Log in to Reply

        I think it’s better, considering `for ( i = 0; i < 100; i++ ) { … } … var i = 2; alert( i );` would be confusing ('100') because of hoisting.

    • Andrew Ozz 1:47 am on November 6, 2013 Permalink | Log in to Reply

      Re-reading jQuery Core JavaScript Style Guide again: apart from the single/double quotes, other differences are the lack of indentation for `case` in `switch` and the hard limit to 100 characters per line (counting tabs as 4 chars). All of the rest more or less match our PHP and current JS coding standards. We also (used to?) have few more, like the strong discouragement of using nested ternary operators.

      So the question is: should we adopt the jQuery standard “wholesale” and depart from our PHP coding standard or should we continue to keep our PHP and JS coding standards as close as possible?

      • Tom McFarlin 1:58 am on November 6, 2013 Permalink | Log in to Reply

        I’m for the adoption of jQuery standards as much as possible; however, I do err on the side of keeping the JavaScript closely-related to our PHP coding standards (which is what I tried to do with the first draft of the standards).

        The reason being is that I don’t think we, as developers, should have to maintain two different set of standards.

        When working on client-side code, I often find myself thinking What’s the server-side standard for this, again? and then I try to apply that.

        Because I – and I’m sure most of us – are so familiar with the PHP standards, perhaps we should implement a “when it doubt, default to PHP standards.”

      • K.Adam White 2:26 am on November 6, 2013 Permalink | Log in to Reply

        I’m of a case-by-case mind on this. For example, I’ve encountered very few situations where >100 characters in a line were truly needed (and not just a symptom of hard-to-read or overly-nested code), so I’d be inclined to keep that. On the flip side, I’m all for keeping indentation rules consistent with PHP.

        Thanks for raising these questions, this is exactly what we need! Both here and during tomorrow’s chat I hope to identify any other differences between our PHP style and the proposed guide, and make decisions about which way to go. We’ve already identified a few areas in which we want to go a different way than jQuery. It’s a useful set of default behaviors, but what style guide we adopt isn’t what’s important—what is important is that consistency.

        • Andrew Ozz 2:47 am on November 6, 2013 Permalink | Log in to Reply

          Yes, the “around 80, max 100 chars” limit might eventually surface when something has many levels of indentation (5 – 6 tabs). This is not so hard to hit with longer jQuery chains which should probably be broken on multiple lines. Thinking it may be nice to have it as a rule in the PHP coding standard too, just not sure if it needs to be enforced.

    • Tom McFarlin 2:02 am on November 6, 2013 Permalink | Log in to Reply

      I’m going to try to make it to the meeting – what server and channel will the meeting take place?

      • K.Adam White 2:12 am on November 6, 2013 Permalink | Log in to Reply

        Good point, that’s something people need to know: Freenode, right in #wordpress-dev. (Note: That time was selected because I was not aware of any conflicting meetings; If anybody has a meeting in #wordpress-dev scheduled at that time, please let us know and we’ll get another room!)

    • Paul Clark 4:09 am on November 6, 2013 Permalink | Log in to Reply

      Count me in for a JSHint sprint!

    • Gary Jones 9:22 am on November 6, 2013 Permalink | Log in to Reply

      Not sure I can make it tonight, so I’m leaving my thoughts here that hopefully someone can take into consideration during the meeting.

      General adoption of the jQuery standards: +1
      Two exceptions to those standards: +1

      Would like to see a push towards named rather than anonymous functions = more self-documenting code, fewer nested levels -> avoid hitting line limits, reduce complexity.

      Consider use of ‘es3’ option in .jshintrc, since WP still needs to support IE8-9, and that will catch use of reserved words being used as properties with dot notation etc.

      I’m up for helping out with some JS tidying.

    • K.Adam White 1:00 am on November 10, 2013 Permalink | Log in to Reply

      Just a heads-up for everybody waiting for an update on this: Hang tight for a day or two, I’m working with @kpdesign to get the JS Standards handbook page updated and up to our standards.

    • Lance Willett 3:36 am on November 12, 2013 Permalink | Log in to Reply

      Thanks for your work on this—more vigorous standards and cleaner code FTW.

  • Helen Hou-Sandi 8:18 pm on November 5, 2013 Permalink  

    #22862: Consider a CSS preprocessor 

    In #22862, it was proposed that core move to using a CSS preprocessor. Given that we now have the appropriate tooling in place and MP6 has been greenlighted for preparation to merge into core, it is time we hash this out: which, if any, CSS preprocessor should we use, why that particular one, what does implementing it take, and what does the contribution process look like? Some of this discussion has already taken place on-ticket, which is great, including a ton of proof-of-concept patching by @wonderboymusic.

    For further reference, MP6 currently uses SCSS for its color schemes, with a branch that demonstrates what it would look like in LESS. Many thanks to @ryelle for maintaining the LESS branch. By no means does this dictate what happens in core itself, but it is certainly an influence and a great data point.

    • Helen Hou-Sandi 8:18 pm on November 5, 2013 Permalink | Log in to Reply

      Here’s my personal opinion:

      Current admin CSS is heavily ID-based, generally overqualified, and insanely clunky to maintain after having been merged into one giant sheet (see #18314). I see very little benefit in putting effort into truly converting wp-admin.css in its current state (sorry, @wonderboymusic), especially given back-compat concerns. What I do think we can benefit from is going back to separate, modular files, and taking advantage of a build process to concatenate them for actual use. Yes, I do know that a preprocessor can do that in a build process, too. 🙂

      I imagine a build process could do something like this:

      1. For the purposes of SCRIPT_DEBUG and people who start in browser inspector tools, concatenate all non-color admin CSS files into one large unminified wp-admin.css, with comments added that denote where the development files are located and where each section starts to help with patching. If there’s a standard that web inspectors use or are beginning to adopt (e.g. source maps), we should take advantage of that.
      2. For production usage, minify the concatenated version, as it does now.
      3. Basically, the current wp-admin.css and wp-admin.min.css would still exist and essentially be as they are now, but patches would be against smaller, easier to digest files. This does raise the barrier to contributing actual patch files, but I think we should be open to helping people create patches out of notes from something like a web inspector (which does occasionally happen now, too, for what it’s worth).

        Bonus: we could also take advantage of an awesome tool like Autoprefixer (https://github.com/ai/autoprefixer) to automate that part of the CSS development process, rather than adding and removing vendor prefixes manually, and still missing them sometimes. Again, yes, I know preprocessors can do this with mixins (which have to be written/maintained) or libraries like Compass.

        Color schemes are pretty awesome with use of a preprocessor, as I’ve long suspected. We should do that as a starting point.

        In general, I think that a conversion can also espouse the iterative improvement philosophy – in this case, we can start with color schemes and really test out our tools and development process (including better documentation) in practice. In time, we may/probably will find areas where moving a file/component to being processed makes sense.

        Finally, I still have no preference when it comes to LESS vs. Sass. They don’t seem fundamentally different to me, even in practice. Sass in the form of scss seems to be gaining momentum in general.

      • Aaron Jorbin 8:37 pm on November 5, 2013 Permalink | Log in to Reply

        I love the idea of autoprefixer and concatenation as a first step. I’m happy to work on the grunt tasks for this if you want me to mock something up.

      • Scott Taylor 8:49 pm on November 5, 2013 Permalink | Log in to Reply

        Concatenation would be killer – as long as that 2 million line file is broken, I am happy.

        Outside of that, I don’t plan on doing any CSS, so it doesn’t *really* matter to me which is picked. I prefer LESS, and it’s what we use at the Times, but whatevs.

      • kkalvaa 10:22 pm on November 5, 2013 Permalink | Log in to Reply

        When you say “truly converting wp-admin.css” are you refering to changing to class based selectors? Or even going for OOCSS/SMACS/BEM?

    • nofearinc 8:21 pm on November 5, 2013 Permalink | Log in to Reply

      I like Sass as being backwards compatible with CSS, i.e. it would make no difference (in theory) if all the CSS is moved to Sass and it would require no conversion for starters, however enhancements and simplification would probably drastically improve the level of maintenance.

      Decoupling the file to smaller chunks and just combining on generation is also a good option.

      • Helen Hou-Sandi 8:34 pm on November 5, 2013 Permalink | Log in to Reply

        FWIW, I think LESS has the same compatibility without actual alterations.

        • nofearinc 8:43 pm on November 5, 2013 Permalink | Log in to Reply

          Wasn’t sure, last time I checked it wasn’t complete, but I might as well be wrong (or it could have been updated).

          • Andrey "Rarst" Savchenko 8:12 am on November 6, 2013 Permalink | Log in to Reply

            Wasn’t complete how? LESS maintained that valid CSS is valid LESS as far as I can remember, as well as getting plain non-compile CSS imports later.

            I cannot make sense where the lack of compat complaint keeps coming from, as far as I know it was never an issue (unlike SASS with their first syntax).

          • Remkus de Vries 8:26 am on November 6, 2013 Permalink | Log in to Reply

            you should see what LESS 1.5 had added to the mix; it’s quite complete nowadays.

    • nphaskins 8:24 pm on November 5, 2013 Permalink | Log in to Reply


      LESS is a little friendlier and easier to learn vs SASS IMO. I use LESS with every project. I’d also like to point out that Bootstrap opted for LESS instead of SASS.

      With this type of approach we can really start to get real color automation in place. Example, choose a base color and like items are styled appropriately. This lets devs cut down on options as well.

    • Jeff Behnke 8:30 pm on November 5, 2013 Permalink | Log in to Reply

      I think this will end up a opinionated discussion, since its going to be what ever the commentator is used to.
      Not sure how to solve that. (Voting) ?
      I agree that Sass in the form of scss is picking up speed. I actually prefer it over Less, but again thats an opinion.

      • Helen Hou-Sandi 8:33 pm on November 5, 2013 Permalink | Log in to Reply

        I sat on this post for weeks (months?) because I stress about starting wars of opinion 🙂 Voting sounds nice, but I don’t think a vote would be a final decision, so it’s sort of misleading. We’ll just parse general sentiments out of comments, I suppose.

    • Travis Northcutt 8:50 pm on November 5, 2013 Permalink | Log in to Reply

      As many have noted, this is largely a personal opinion thing. However, for anyone who isn’t already familiar with one or the other or both, the following comparisons may prove informative:


    • Pbearne 8:53 pm on November 5, 2013 Permalink | Log in to Reply

      It may come down that we are PHP programmers and know where the $ key is!

      Pick one and import the current CSS and break out overtime 😉

    • PeterRKnight 8:59 pm on November 5, 2013 Permalink | Log in to Reply

      I think Less is the more accessible of the two with more familiar looking syntax, also Lessphp is an excellent library to use and is extendable.

      • Bryan Petty 9:13 pm on November 5, 2013 Permalink | Log in to Reply

        When you say “accessible”, what do you mean?

        Also, note that when @helen mentions “appropriate tooling”, she’s referring to our Grunt build system, which would end up either using grunt-contrib-less for LESS, or grunt-sass for SCSS. LessPHP isn’t even necessary or being discussed anymore as we aren’t talking about bundling a compiler with WP anymore (Grunt has made this fairly pointless).

        • PeterRKnight 12:26 am on November 6, 2013 Permalink | Log in to Reply

          I admit to not being fully up to date on the latest SCSS/Sass syntax, I remember it looking more like a programming language in places (which a lot of people think is a pro). Further, what I like about using LessPHP is that it can compile on the server and plugin developers can extend it. Compiling via grunt or otherwise require dependencies that makes things less accessible (installing ruby/node.js etc). Having said that, I’m not sure how much these arguments apply to what’s being discussed here. I just chimed in because I’m superhappy with my lessphp workflow.

    • Amy Hendrix (sabreuse) 9:05 pm on November 5, 2013 Permalink | Log in to Reply

      Just to get clear before we get further into I Like Chocolate vs. I Like Peanut Butter, I’m pretty sure that adopting Sass would mean using SCSS syntax, not old-style (indented) Sass. It’s been the default in Sass for several years now, and is essentially the only thing being used any more except by a few HAML and Ruby fan holdouts.

      In that case, the “syntax is more accessible” and “easier to learn” arguments are basically moot. Both of them use a “Looks like CSS with some variables and stuff mixed in” syntax.

      That said, I prefer Chocolate. Err, Sass. Mostly because it’s what I already use.

    • Chris Van Patten 9:12 pm on November 5, 2013 Permalink | Log in to Reply

      I would like to voice a *strong* preference toward Sass, specifically using the default SCSS syntax. Syntactically, Sass w/ SCSS is really quite similar to LESS, although this article from Chris Coyier outlines the differences (and he ultimately says to use Sass).

      This is totally an opinion and based on my own perceptions (I’m not trying to incite a flamewar!), but Sass strikes me as more actively (and more seriously) developed. They have an intense focus on stability and maturity.

      Again, this is based on my own (biased) perceptions, but I also don’t see any serious professional front-end devs recommending LESS, and I can’t name anyone in my circle of front-end developers using LESS on a day-to-day basis. I’m sure they’re out there, but Sass seems to be the overwhelming choice for the front-end developers I know and trust.

      I realize this is largely an emotional response to a technical issue, but Sass just *feels* right to me, in a way that LESS does not. And—not to get too precious about the tools or anything—I would be much more likely to contribute to a Sass-based Core than LESS-based Core (for whatever little that’s worth, natch).

      • Bryan Petty 9:19 pm on November 5, 2013 Permalink | Log in to Reply

        I’ve already voiced my opinion pretty clearly on #22862, but I also agree with @chrisvanpatten.

      • Chris Van Patten 9:21 pm on November 5, 2013 Permalink | Log in to Reply

        I’d also add to this that if you look at the major open source projects that the big front-end devs are working on there is a clear consensus around building with Sass.

        For example, see this discussion on Github discussion a pre-processor to use for Effekt.css. The consensus overwhelmingly tipped toward Sass (and very quickly too).

        That’s *not* to say that Sass is the right choice for WordPress just because everyone else is doing it, but I think it does show that the industry is definitely heading in a Sassy direction.

      • CreativeNotice 9:42 pm on November 5, 2013 Permalink | Log in to Reply

        Agree completely. The only project I utilize that uses LESS is Bootstrap and even there I use the SCSS version provided by the folks maintaining Yeoman.

    • Paul Clark 9:28 pm on November 5, 2013 Permalink | Log in to Reply

      I’m with @chrisvanpatten on this — SASS — with SCSS syntax and no Compass. My reasons are:

      • SCSS shares variable syntax with PHP, so more conceptual overlap for beginners (Less uses Ruby syntax).
      • For advanced users, SCSS can be extended with Compass, which requires a bit more setup, but may be useful for some specialized purposes.
      • For team projects, I generally discourage the use of Compass, only because of decreased portability. Again, if there’s an extension that saves much time (or is only used for prototyping), that may override that.

      Quicker learning curve for beginning PHP developers and more extensibility for advanced users makes a clear case for SASS over LESS in my mind.

      • Chris Van Patten 10:19 pm on November 5, 2013 Permalink | Log in to Reply

        I’m a big fan of Compass (we use it at my company) but I’d tend to agree that it isn’t right for a project like WordPress. I think it would add too much overhead and increase the barrier to entry for new contributors.

      • Taylor Dewey 10:26 pm on November 5, 2013 Permalink | Log in to Reply

        I agree that Compass doesn’t have much of a place in WordPress core. I don’t think that it, in and of itself, should be seen as a +1 for SASS. However, the fact that a library like Compass can be built, may indicate deeper core extensibility. This is something WordPress core is unlikely to need or use in the short term (I can’t see us writing ruby gems to do anything in the short-term), but it’s presence is a comfort to the developer side of me.

    • Taylor Dewey 9:33 pm on November 5, 2013 Permalink | Log in to Reply

      sourcemaps are pretty (very) awesome as a dev tool, but may be difficult to implement by hand (the syntax is ugly and requires a sourcemap file to be generated). I believe both Sass and LESS have sourcemap support in trunk, but not stable at the moment. FWIW, sourcemap support could potentially extend to concatenated javascript.

      +1 for first steps being to break up the files and trial a preprocessor with color schemes.

      +1 for Sass / .scss syntax (yeah, it’s what I’m familiar with… there was a reason once…)

      As much as I’d love to see everything fixed — there’s a very real potential to preprocess our way into something even worse. IMO, there are a lot more best practices to keep in mind when using a preprocessor. Let’s focus on step 1 — and figure out the rest of the roadmap as people (core contributors, committers, etc) become familiar with the tool and folder/file structure.

    • CreativeNotice 9:34 pm on November 5, 2013 Permalink | Log in to Reply

      I’m also a fan of SASS w/ SCSS.

      It might be best to develop a set of requirements you need met by preprocessing and see which best meets those. Otherwise you end up with a game of tug ‘o war; consensus does not always provide the best solution.

    • Andrew Woods 10:01 pm on November 5, 2013 Permalink | Log in to Reply

      Recommendation: SASS using SCSS syntax

      Both are useful, and everyone should be using a preprocessor to manage their CSS. IMHO, SASS using SCSS is the better choice. From what I’ve seen SASS is used more by the Design community. There are also more tools that support SASS. the ‘compass watch’ command is invaluable and comes as part of SASS upon install. I’ve used both LESS and SASS. Even thought I’ve used LESS successfully on projects, I think SASS’ SCSS syntax provides more clarity. I think that helps with the on-boarding of new team members.

      • Taylor Dewey 10:20 pm on November 5, 2013 Permalink | Log in to Reply

        ‘compass watch’ would only be valuable if we adopted Compass + sass — which isn’t neccessarily on the table. Furthermore, we’d be processing sass using the grunt-contrib-sass plugin for Grunt. This way we can also benefit from additional processing on the resulting css file (e.g. autoprefixr). Since we’re in the context of grunt, the grunt-contrib-watch command will be quite flexible.

        I would, however, love to see an example of how scss is more clear than LESS. Is it just the $ variables being familiar to php devs, or is there something else?

    • kkalvaa 10:19 pm on November 5, 2013 Permalink | Log in to Reply

      I’m also a fan of sass/scss over less.

      I used to favour less, mostly due to it being easier to set up (less.js mainly), but i’ve changed my mind lately and now prefer sass. Sass seems to have a better defined goal and the newly redesigned website makes it quite a bit easier to read documentation. Also I’ve been finding more interesting projects released i sass than less lately (though that might be my bias).

    • Matt Wiebe 10:33 pm on November 5, 2013 Permalink | Log in to Reply

      The big thing here is to use one. Variables will make abstracting colour schemes far easier. Partials promote code organization and abstraction, allowing more and better collaboration.

      My only personal preference here is for Sass with the old whitespace-sensitive syntax, but even the Sass project understood that’s a non-starter when they introduced the now-default SCSS syntax. Much of the “LESS is easier” sentiment stems from this now-irrelevant item, as SCSS syntax provides you with familiar curly braces. (The other reason is that the LESS website was prettier. The Sass site was recently redesigned and this will no longer be an issue.)

      Sass and LESS are largely functionally equivalent, but here is why Sass is a better choice:

      1. The Sass project is under much more active development. Sourcemaps came to Sass first. Chrome devtools supported Sass first. There’s active work on libsass, a C-based Sass implementation that supports bindings for any language, like PHP and JS.
      2. Sass has a very active community; from frameworks like Compass and Bourbon, to simple (and not-so-simple) functions: https://github.com/Team-Sass I would not recommend using a framework, but active communities are one of the best ways to evaluate which technology to support.
      3. Any comparison list will show that Sass simply does more. It is more fully featured, particularly their extends functionality. (LESS now has extends as well, but Sass’s implementation is more mature and fully-featured)
      4. I was going to rant here about LESS’s homepage promoting client-side compiling on their home page, but they recently (finally) changed that. Good on them!
      • WraithKenny 1:56 am on November 6, 2013 Permalink | Log in to Reply

        I don’t think it’s clear that Sass has a larger, more active community or development. LESS has Twitter’s Bootstrap (and about a million projects based on it) among others and less.js core seems to have gotten a new stable of (really active) maintainers.

        The other point is of the programing language logic features of Sass versus the intentional avoidance of those in Less.js, which is also a feature (less went with gaurds). I don’t see WordPress using, or rolling it’s own, Compass, so I think the Less.js feature of not having complex programing logic in CSS preprocessing, is a actually a better fit.

        Other then that (and that in the WordPress build system, LESS doesn’t have extra dependencies like Ruby for compiling) feature wise, LESS and Sass are essentially the same.

        (Also, the ability of manually compiling LESS client side certainly has it’s uses, and is a great feature.)

        • WraithKenny 4:05 am on November 6, 2013 Permalink | Log in to Reply

          Turns out you can do complex logic and loops and whatnot in less.js, but the philosophy is that you probably shouldn’t…it’s just css after all.

        • Matt Wiebe 8:31 pm on November 6, 2013 Permalink | Log in to Reply

          Bootstrap is one project, albeit a massively successful one. One project (and its derivatives) does not a community make. Sass’s community is both broader and deeper.

          I don’t see WordPress using, or rolling it’s own, Compass, so I think the Less.js feature of not having complex programing logic in CSS preprocessing, is a actually a better fit.

          If we’re going to the trouble of using a preprocessor, I think that having the most powerful one is the better choice. We don’t have to use all that power, and I’m sure we won’t, at first. But we’ll be happy it’s there if/when we want it.

          I don’t just say this to cheer on my language of choice. There’s loads of people who start with LESS and end up with Sass. (Like Andy Clarke, who was vocally anti-Sass before that.) I have honestly never seen a single person move in the other direction. This tells me something.

    • Matt Wiebe 10:35 pm on November 5, 2013 Permalink | Log in to Reply

      Complete pedantry aside: Sass is not all caps. LESS and SCSS are.

    • OC2PS 10:36 pm on November 5, 2013 Permalink | Log in to Reply

      Does it matter that SASS is written in Ruby? Specifically, would that mean that Ruby would become a dependency for WordPress?

      Remember, while Ruby is expanding like nobody’s business, it is still not available on most hosting servers.

      • Taylor Dewey 10:43 pm on November 5, 2013 Permalink | Log in to Reply

        That’s a good point to make: Sass does have a *development* dependency of Ruby and the Sass Ruby gem.

        We also have a development dependency in this workflow (no matter if we go Sass, LESS, or even just separate CSS files) of Node, NPM, and Grunt.

        • Matt Wiebe 10:48 pm on November 5, 2013 Permalink | Log in to Reply

          Yes. That being said, it would be killer to have server-side compilation in the future (with appropriate caching etc)

          • Helen Hou-Sandi 10:57 pm on November 5, 2013 Permalink | Log in to Reply

            A script would take care of running the build that’s used for packages and the core repo, just as it already does for minified/uglified files. Otherwise: grunt watch, yo.

            • Matt Wiebe 8:21 pm on November 6, 2013 Permalink

              Yes, but that’s just for core. Let’s imagine a world where asset concat/minification for all enqueued styles/scripts happened on every page. I like that world.

        • Helen Hou-Sandi 10:56 pm on November 5, 2013 Permalink | Log in to Reply

          Develop repo already uses Grunt. I guess you don’t *have* to run out of build right now, though (I don’t, actually, I run out of src).

        • WraithKenny 11:29 pm on November 5, 2013 Permalink | Log in to Reply

          What’s that mean, “*development* dependency?” You do need Ruby installed to compile Sass. If Node, NPM and Grunt are the dependencies of the workflow, then LESS has no further dependency, but Sass (SCSS) does, right?

          • WraithKenny 11:30 pm on November 5, 2013 Permalink | Log in to Reply

            In my experience, setting up Ruby on a Windows environment is a pain, but installing Node/NPM was super simple.

          • Taylor Dewey 12:25 am on November 6, 2013 Permalink | Log in to Reply

            I was emphasizing that the dependencies are for those developing core — not for those using the product. As you mentioned, LESS would have no further development dependency beyond what is already in place (node/npm/grunt). Sass has the additional requirement of ruby/sass.

            Think we’re on the same page here.

            • Bryan Petty 4:32 am on November 6, 2013 Permalink

              On the same page, except that using Sass from Grunt does not actually require Ruby, not even as a “development dependency”, see below.

      • Helen Hou-Sandi 10:54 pm on November 5, 2013 Permalink | Log in to Reply

        Yes, it does mean requiring Ruby for development and build, but there’s not really a good reason to be running the develop repo on a host somewhere – you’d want to either use the old core repo that receives built files or a regular old package, both of which include and use compiled files (see, for instance, our unminified vs. minified CSS and JS). Doing a build would be done because you’re using the develop repo, which as its name indicates, is for developing WordPress core itself. A typical user or hosting environment shouldn’t be subject to any changes.

        • Bryan Petty 12:21 am on November 6, 2013 Permalink | Log in to Reply

          Actually, it doesn’t require Ruby if we use grunt-sass instead of grunt-contrib-sass (many projects have made this migration already) as I’ve mentioned in #22862 already, and as referenced by @mattwiebe here earlier.

          • WraithKenny 3:48 pm on November 6, 2013 Permalink | Log in to Reply

            Well, that’s nifty. I’ll definitely check that out.

          • Taylor Dewey 8:54 pm on November 6, 2013 Permalink | Log in to Reply

            I’m actually very interested in trying this out (libsass is supposed to be superfast), but it’s something to keep in mind, but it is considered “under development”

            Thanks for bringing it up.

    • Doug Wollison 11:19 pm on November 5, 2013 Permalink | Log in to Reply

      I say SASS.

      1 major advantage: if/then/else and for/while/each statements. It’s more of a programming language than LESS. There’s nothing super complicated about either language once you get past the nested styling and variables. Also, I feel SASS as a slightly more informative syntax and can give you a better idea of what’s going on in the code.

      Granted, SASS runs on Ruby/Gems, which I always seem to have trouble installing properly, but as long as somebody provides a decent how-to for setting it up on a dev server, we should be fine.

      • WraithKenny 11:32 pm on November 5, 2013 Permalink | Log in to Reply

        As far as I understand it, Windows is not supported by Ruby. They suggest using a 3rd party library to get it working.

        • Taylor Dewey 12:28 am on November 6, 2013 Permalink | Log in to Reply

          It doesn’t appear Ruby itself supports anything beyond compiling it yourself. All the third party tools to install are “not supported”

          That said, for Windows they suggest: http://rubyinstaller.org/ — would love to hear someone’s experience with it.

          • CreativeNotice 2:26 pm on November 6, 2013 Permalink | Log in to Reply

            I used the rubyinstaller last month, it ran like any other windows installer. No configuration needed post install if I remember correctly.

      • Mel Choyce 1:47 am on November 6, 2013 Permalink | Log in to Reply

        Do you have some examples where using if/then/else and for/while/each statements in Sass could be helpful? Just curious because I haven’t seen them used before. 🙂

    • Andrew Ozz 12:57 am on November 6, 2013 Permalink | Log in to Reply

      I’m still not 100% sold on the advantage of using a CSS preprocessor. Starting a new project and implementing a preprocessor is quite nice, importing and redefining 10 years worth of incremental (unorganized, often accidental) CSS is a nightmare 🙂

      Don’t get me wrong: as a coder I’d prefer to be able to use at least variables and conditionals in CSS, loops would be nice too.

      Advantages of using a CSS preprocessor:

      • Changing something in one place would automatically change it in many places in the final stylesheet.
      • (Can’t really think of another… The above is pretty nice though.)


      • Requiring all contributors that want to be able to build trunk, to install another application or bunch of applications (for SASS).
      • Rising the bar for all contributors that may consider contributing CSS.
      • Making it (much) harder to debug CSS in a browser console.
      • Making it harder to test CSS patches.
      • Will be exposed to regressions in the build tools (that’s a big one…) and differences in the output for different versions of the tools.

      Requiring every patch that touches CSS to include both the changes to the preprocessor file and the actual wp-admin.css would make it easy to test but would increase the chance of differences in the final build.

      • Dion Hulse 1:28 am on November 6, 2013 Permalink | Log in to Reply

        Prefix: I’m using SCSS below, but I’ve only ever used LESS.. so it’s really just a placeholder.

        So far the ideas mentioned seem to suggest to me that:

        • We’d have .scss files in /src/
        • We’d have built .css files in /src/ (ie. We’d have a CSS file for each SCSS file)
        • We’d have concat’d and minimised .css files in /build/
        • We’d have Sourcemaps in /buid/ pointing to the exact location in the SCSS file that the rule came from
        • We’d have a grunt task to convert the SCSS to CSS in /src/

        Due to the higher bar of entry, we’d probably:

        • Willingly accept patches against the .css files in either /build/ or /src/ and convert them to .SCSS patches

        Migrating old CSS would happen as it’s rewritten or altered, there would be no need to suddenly change all of our code to SCSS-style.. with MP6 being added in 3.8, it seems like 90% of our admin CSS is going to be re-written or modularized anyway, so it’s not such an issue.

        Sourcemaps make debugging in browsers much easier (I recently tried debugging a sites compressed JS, only to suddenly be looking at the exact character in the uncompressed/non-ugly code, Sourcemaps work great).

        As for regressions in the tooling, yes we’d be susceptible to those too, but as has been shown by 3.7.1, we’re already susceptible to them and it drives home that all testing should be done on a /build/ and development done on a /src/.

        • Andrew Ozz 3:33 am on November 6, 2013 Permalink | Log in to Reply

          Yes, that’s pretty much how I imagine the implementation too. The “(much) harder to debug CSS in a browser console” is mostly a concern about somebody trying to debug a client site remotely, or trying to pinpoint a problem described in a forum post. Especially in older browsers where sourcemaps wouldn’t be helpful.

          …it drives home that all testing should be done on a /build/ and development done on a /src/.

          Right, but the bug in 3.7 was caused by a regression in the newest tool version, while testing was done with earlier versions. I’m pretty sure we won’t let that happen again. Finding a way to “lock” the build tools versions and force an upgrade when needed would be best.

      • WraithKenny 1:33 am on November 6, 2013 Permalink | Log in to Reply

        Another often overlooked advantage of a preprocessor is that using nested rules and mixins naturally organize rules, uncovering and preventing many problems with redundant and conflicting rules. Maintainability and Reuseability are Huge advantages.

        To address your concerns:

        • Building the css *can* be a separate process for css contributors (for testing at least, the css core would use and ship would be from the automated build process, only). For example, Sublime Text can be easily set up to build LESS with a key stroke; the tutorial on that is simple.
        • Using a preprocessor is becoming a basic and expected entry-level skill for working with css.
        • Chrome and LESS (and Sass, I think) now support Source Maps (it’s not beta anymore). This makes it just as easy to find the file and line number of the source, using Dev Tools (no plugin needed).
        • patch and build wouldn’t be too hard for contributors, if they have the requisite basic entry-level skill mentioned above.(Alternatively, I did put a proof of concept plugin on the Ticket that could ultimately edit, compile, and show LESS changes live in the browser. There’s no technical reason the plugin couldn’t be extended to accept and output diff files.)
        • I don’t have an answer to this one, but I’m not convince it’s a big problem. Core will use Grunt, with a specific version of the preprocessor, so with care, it shouldn’t be a big deal. The preprocessors simply aren’t as complicated as a language like php or javascript. Any regression is easy to notice, and has no security implication that I can think of, and easily corrected.

        I don’t think requiring the compiled css in the patch is the right way to go.

        • Andrew Ozz 3:49 am on November 6, 2013 Permalink | Log in to Reply

          …using nested rules and mixins naturally organize rules, uncovering and preventing many problems with redundant and conflicting rules. Maintainability and Reuseability are Huge advantages

          Right, that should have been point two in my comment above.

          I don’t think requiring the compiled css in the patch is the right way to go.

          My concern is mostly about people who want to test (bigger) patches that contain CSS. Not sure if we should require them to be able to generate the stylesheets.

          • WraithKenny 3:59 am on November 6, 2013 Permalink | Log in to Reply

            Maybe a “companion” patch that just contains the .css changes? It’d be a courtesy patch that wouldn’t be commited, but is just available for testing, for use by folks who can compile the css.

    • Brendyn Montgomery 1:16 am on November 6, 2013 Permalink | Log in to Reply

      We use Sass (specifically .scss) in all our projects and so would have a preference for it over LESS.

      I love the idea of a preprocesser being built into the core, especially if it could be extended to include other addtions if a developer wants it (we also use SUSY grids, breakpoint and compass on all developement projects).

      Could it be implemented in such a way as to be an optional flag in the wp-config.php that defaulted to off? That might get around the issues of old CSS that could be problematic or people not wanting to use it for any reason?

      Another major advantage of Sass (can’t speak for Less) is that you can define the output to be compressed which will strip all the white space and comments out of the CSS and reduce file size. That means that you can be really verbose with comments in the Scss file and then know that this isn’t going to effect the size of the .css file.

    • fightthecurrent 1:47 am on November 6, 2013 Permalink | Log in to Reply

      I’m definitely in support of sass. Plenty of valid arguments have already been made 🙂

    • Till Krüss 3:38 am on November 6, 2013 Permalink | Log in to Reply

      I prefer Sass (SCSS syntax) over LESS.

      LESS is a good CSS preprocessor, but Sass is IMO simply better. It has a cleaner syntax, it supports conditionals & control structures like loops and variable defaults which LESS doesn’t or in a bad way. Plus Sass supports one-dimensional lists and with 3.3 multi-dimensional lists.

    • Remkus de Vries 8:31 am on November 6, 2013 Permalink | Log in to Reply

      I personally prefer LESS over SCSS, but surely this is influenced by my experience with Twitter Bootstrap. Does anyone remember why they opted for LESS at the time?

    • Nashwan Doaqan 9:11 am on November 6, 2013 Permalink | Log in to Reply

      I use LESS in all of my projects, never used SCSS before.. LESS gives me all what I need and I didn’t get a reason why I should learn SCSS!

    • Gary Jones 9:26 am on November 6, 2013 Permalink | Log in to Reply

      +1 for SCSS. When I looked at the differences a while ago, Sass as SCSS just had more development features and flexibility (i.e. you could do a little more with it as it was more powerful). When everything is generally status quo, having the *option* to use one of the advanced features at some future point should be a valid consideration.

      • Christian Foellmann 10:47 am on November 6, 2013 Permalink | Log in to Reply

        +1 for SCSS. I am with Gary on this. SCSS seems to be more powerful and thereby more future-proof.
        I really love the idea of using a CSS preprocessor and I think the concept of both is so similar that people familiar with LESS can switch pretty easily.

    • Josh Eaton 1:36 pm on November 6, 2013 Permalink | Log in to Reply

      +1 for SCSS

    • atadams 3:40 pm on November 6, 2013 Permalink | Log in to Reply

      +1 for SCSS.

      I think it should be pointed out that Linkedin has hired Chris Eppstein to maintain Sass (and Compass). Having a dedicated developer is a big plus. I don’t know if LESS has anyone comparable.

    • Pbearne 4:13 pm on November 6, 2013 Permalink | Log in to Reply

      I have thinking a bit about this and wondered if we should ..

      leave the current css tools (wp_enqueue_style) and add a whole new stack

      wp_enqueue_sass to add files
      wp_enqueue_sass_folder for all file in folder
      wp_enqueue_sass_fagment do just pass string of scss

      if debug on we compile every page load otherwise we cache a single css file and rebuild on plug-in / theme activated / deactivated etc. (add wp_complie_sass() so it can be called)

      I see the need for filters pre_complie_sass and post_compile_sass

      If do this plugin’s and themes can convert as they see fit

      let’s also fix/add conditional CSS and possible provide a ordering options

      does this make sense?

      • Helen Hou-Sandi 4:24 pm on November 6, 2013 Permalink | Log in to Reply

        I don’t think core should be compiling CSS on the fly. We already use a Grunt-based build process – this would be an extension of that.

        • Pbearne 4:45 pm on November 6, 2013 Permalink | Log in to Reply

          I can see that makes sense.

          Sorry to get it clear in my head are talking about adding a server side compiler or just a developer grunt script?

          What I believe we need is a server side compiler as will get more adoption in the community.

          So do we end up with 2 css files wp-admin core and plug-in’s

          Part of the benefit of sass is the reduction of css files I feel we should pursue this benefit as best we can.

          • Taylor Dewey 9:11 pm on November 6, 2013 Permalink | Log in to Reply

            The plan so far would be to use Grunt to process (if necessary), concat, and minify css files. So a developer build process using grunt.

            Server side concat and minification is an entirely different discussion that wouldn’t be influenced by our preprocessor usage.

            Server side processing is also a different discussion and shouldn’t influence our decision to use a preprocessor or not (nor which one).

            Reducing http requests is a noble goal—but has no relationship to this thread.

    • Shea Bunge 11:30 pm on November 6, 2013 Permalink | Log in to Reply

      I used to use Less before switching to Sass’s SCSS syntax. One of the main things that held me back was implementation, but this wouldn’t be an issue as we are using Grunt.

      Aside from Compass, I enjoy how much more powerful Sass is over Less. For one thing, Sass supports nested properties:

      body {
      	background: {
      		color: red;
      		image: url( 'foo.png' );
      		size: 42px 42px;
      		position: top right;

      Sass also supports nested media queries – an invaluable feature, IMO.

      body {
      	background-color: blue;
      	@media screen and (min-width: 130px) {
      		background-color: green;

      In Less, the above code would have to look like:

      body {
      	background-color: blue;
      @media screen and (min-width: 130px) {
      	body {
      		background-color: green;

      Sass also supports much more advanced logic and control than Less.

    • Shea Bunge 11:33 pm on November 6, 2013 Permalink | Log in to Reply

      Additionally, I would also like to suggest using the excellent Autoprefixer tool for automatically adding necessary CSS prefixes. There is also an Autoprefixer Grunt task available.

    • Sofia Rose 7:35 pm on December 25, 2013 Permalink | Log in to Reply

      @helen Are you still working on a 3.8 Style Guide? If so where can i get a copy? I would love to help with this. 🙂

    • Cameron Roe 11:07 pm on January 26, 2014 Permalink | Log in to Reply

      As the web moves forward, how are devs keeping up WITHOUT SASS?? I feel like it’s a must nowadays, and it would be extremely helpful to have Grunt running watch and build tasks with Core. The beauty of Grunt is that LESS users could easily add their LESS plugin if they wanted, but the majority would see built-in SASS. Compass, Bourbon, and most of the dev community pushed for SASS. Bootstrap is the exception in my book.

      +1 SASS.

    • Cameron Roe 11:17 pm on January 26, 2014 Permalink | Log in to Reply

      The other awesome benefits of this are the use of partials within themes and the nature of reusable variable declarations. It would allow for a more modular approach for styles.

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar