Make WordPress Core

Search Results for: gallery Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Nacin 8:02 am on January 29, 2014 Permalink


    27 open tickets. Last 7 days: +0 tickets

    27 open tickets defect (bug) enhancement feature request
    Awaiting Review 7 6 2
    Future Release 8 3 1
  • Matt Miklic 3:14 pm on July 7, 2016 Permalink |
    Tags: , , ,   

    Native Fonts in 4.6 

    When WordPress switched to Open Sans in version 3.8 at the end of 2013, the state of typography on the web was just beginning to evolve. Before, our choices for typefaces were limited to a small subset of fonts reliably installed on most major operating systems. And, in some cases, those fonts were optimized for print, not the web. Open Sans is optimized for the screen, has generous character support, and, best of all, is open source. For these reasons, it was a better option for a modern web app than the system fonts of that time.

    Today, the landscape has changed. The majority of our users are now on devices that use great system fonts for their user interface. System fonts load more quickly, have better language support, and make web apps look more like native apps. By using the same font that the user’s device does, WordPress looks more familiar as a result. This change prioritizes consistency from the user’s perspective over consistency in branding. And while typography does play a role in the WordPress brand, the use of color, iconography, and information architecture still feels very much like WordPress.

    To this end, Font Natively (#36753) replaces Open Sans with a set of system fonts that covers major operating systems, including Android, iOS, Windows, macOS, and Linux.

    The Font Stack

    Safari, Chrome, and Firefox on iOS and macOS have new CSS values that return the current system UI font, but on other platforms, the font has to be declared by name. As such, the font stack includes the following:

    • -apple-system for Safari (iOS & macOS) and Firefox macOS
    • BlinkMacSystemFont for Chrome macOS
    • Segoe UI for Windows
    • Roboto for Android and Chrome OS
    • Oxygen-Sans for KDE
    • Ubuntu for Ubuntu
    • Cantarell for GNOME
    • Helvetica Neue for versions of macOS prior to 10.11
    • sans-serif, the standard fallback

    The complete CSS declaration: font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen-Sans, Ubuntu, Cantarell, "Helvetica Neue", sans-serif;


    The operating system’s UI font is used for any text that’s part of the WordPress user interface. In other contexts, like the Editor, we continue to use a serif system typeface, Georgia. This creates a clear typographic distinction between text that is part of the interface, and text that is part of the user’s content.

    Not all system fonts provide the same range of weights that Open Sans did. We recommend using only the 400 and 600 weights, which will display most consistently across all platforms. I’ve created a test page that shows the difference between Open Sans and your current device’s system font at every available weight. (A collection of screenshots of that test page is also available).

    The order in which they’re called is important, because we want the user’s system font to be the first available font in the stack. For example: if Roboto were listed ahead of Segoe UI, Windows developers who have installed the Roboto font for Android development would see it instead of their native system font. There may be edge cases if users have manually installed these fonts on their machines, but this order should work best for the majority of users.

    When using this font stack, it must be called using the font-family property, and not the font shorthand. This works around an issue in Microsoft Edge.


    All screenshots were taken on a retina (2dppx) device. If you’re reviewing screenshots on a non-retina display, check out this Cloudup gallery of 1x screenshots.

  • Joe Hoyle 1:32 pm on May 6, 2016 Permalink |
    Tags: imagick,   

    ImageMagick Vulnerability Information 

    A few days ago an ImageMagick vulnerability was disclosed dubbed “ImageTragick” that affects WordPress websites whose host has ImageMagick installed. If you control your own hosting for your WordPress site, you should look to implement the following fix(es) immediately.

    The full effect of this issue is still unfolding and it’s not clear what the full impact will be; however, there are mitigation steps that should keep you safe with the known exploits so far. This vulnerability is already being exploited in the wild, and proof of concepts are being published.

    How is WordPress affected?

    Uploaded images to the WordPress admin that contain malicious data can perform a number of exploits via the underlying ImageMagick library. Uploads are available to all users who have the upload_files capability. By default that’s authors, editors, and administrators; contributors, subscribers, and anonymous users do not have that capability. This issue is still developing; however, it should be noted that if un-patched, this exploit allows for Remote Code Execution (RCE).

    What steps is the WordPress Core Team taking to mitigate this?

    The exploit is in the Imagick PHP extension, not WordPress itself (or any library that is shipped with WordPress). The WordPress Security Team is exploring ways to help mitigate this exploit due to the wide usage of ImageMagick in the WordPress ecosystem; however, this exploit is best handled at the hosting level (instructions below).

    How do I know if my site is vulnerable?

    If you do not control your own hosting environment then it’s likely that your host is taking steps to fix the issue. We recommend you reach out to your hosting provider to verify they are handling the “ImageTragick (CVE-2016-3714, CVE-2016-3718 and CVE-2016-3715)” exploit.

    Only WordPress sites that have the PHP Imagick extension installed are vulnerable to this exploit. If you don’t know if your server has this PHP extension, there are a few ways to identify this:

    1. Inspect the output of the phpinfo() function for “Imagick”.
    2. Run php -m | grep imagick on the command line.

    How do I patch the vulnerability?

    Currently the best known fix is to add a policy.xml file to your ImageMagick installation to limit the delegates that ImageMagick will use. Due to the ongoing nature of this issue, we recommend you refer to and follow https://imagetragick.com/ for instructions on how to handle the problem.

    ImageMagick 6.9.3-10

    ImageMagick released an update on 2016-05-03 to fix this issue; however, there are questions around whether this update provides a complete fix. At the time of writing it should be presumed version 6.9.3-10 does not fix the issues completely and you should take steps to patch the issue via the policy.xml file.

    Further reading

    More information and updates on this exploit can be found at https://imagetragick.com/. We recommend you keep an eye out for updates to this issue, as the full extent of problem is still being discovered.

    Documentation on the policy.xml file can be found at https://www.imagemagick.org/script/resources.php.

  • Helen Hou-Sandi 3:39 pm on May 4, 2016 Permalink

    Font Natively 

    Note: This project is currently a Trac ticket that has been committed for 4.6 (#36753) and is available for testing in trunk/nightlies.

    When a visual and small screen admin refresh was introduced in 3.8 (by way of the feature plugin MP6), the admin font was changed to Open Sans to better complement the redesigned vector iconography. This change was not without its bumps or controversy, notably around extended character sets and that it is loaded from Google Fonts for a variety of reasons.

    Instead of relying on an external resource, Font Natively moves the WordPress admin back to system fonts. This leads to faster load times, especially when working offline, a removal of a third-party dependency, and a more native-feeling experience as the lines between web experiences and apps continue to blur.

    Current Status

    Development – A plugin is available on GitHub by @mattmiklic and is ready for testing. It is also available in patch form on #36753.

    Documentation & Testing – This needs to be tested for any misalignments or other issues when switching to system fonts.


    Example screenshots (more needed)

  • Dominik Schilling 8:47 pm on April 20, 2016 Permalink


    Dev Chat Agendas | Dev Chat Summaries | Jump Starts | Dev Notes | All Posts Tagged 4.6

    Schedule, Focus, Features

    4.6 opened for commit on April 13th and is currently scheduled for August 16th of 2016. The release is lead by Dominik Schilling (@ocean90) and Garth Mortensen (@voldemortensen). The focus will be on fixing bugs and refining existing features. Other goals are to try improving collaboration between teams of features/components, communication to the outside via make/core.

    The following table includes tickets from the community wish list and by core committers.

    Community Wish List

    ID Summary Component Type
    #35133 Make the admin menu more flexible in width Administration enhancement
    #32396 Settings Reduction Administration enhancement
    #35774 WordPress admin <title> structure Administration enhancement
    #16708 Taxonomy checkboxes to radio buttons Administration feature request
    #25669 Introduce helper function for AJAX checks Bootstrap/Load enhancement
    #25137 Enable safe mode to run WordPress without loading plugins Bootstrap/Load feature request
    #34106 Comments should have real permalinks Comments defect (bug)
    #22198 Realigning the Discussions Settings page Comments enhancement
    #27111 Turning off global comments should include existing content Comments enhancement
    #16252 Allow comment reparenting to fix poor threading Comments feature request
    #34923 Introduce basic content authorship in the Customizer Customize enhancement
    #18584 Nav menus need more hooks for extensibility (on admin page & in customizer) Customize enhancement
    #35827 Customizer: Create a dropzone for adding images Customize enhancement
    #18623 Allow themes to pre-register multiple custom backgrounds Customize feature request
    #34062 The WXR export tool should export terms metadata Export enhancement
    #22435 Export API Export enhancement
    #32802 Update Masonry (v3.3.2) & imagesLoaded (v3.2.0) package External Libraries enhancement
    #24846 Usage of a shortcode disables wpautop filter Formatting defect (bug)
    #4539 Abbreviated year followed by punctuation or markup doesn’t texturize Formatting defect (bug)
    #28449 Prevent widows Formatting enhancement
    #30130 Normalize characters with combining marks to precomposed characters Formatting enhancement
    #13429 Updating Link URL on image within Admin with Gallery Gallery defect (bug)
    #21667 Add some user agent to wp_is_mobile General enhancement
    #36335 Next generation: core autoloader proposal General feature request
    #34053 HTTP API (Curl backend) inappropriately sends Content-Length header on POST requests made through a proxy server CONNECT HTTP API defect (bug)
    #33073 Some strings need “no HTML entities” translator comments I18N enhancement
    #34625 wp-login.php site title link points to wordpress.org Login and Registration defect (bug)
    #15384 wp-login.php refactor Login and Registration enhancement
    #34401 Search mechanisms complaning of access denied error on wp-login.php?action=logout Login and Registration enhancement
    #22139 Hooks for wp-login customization Login and Registration enhancement
    #22837 WP Needs to Set “Sender” and “Reply-To” or DKIM/DMARC will not work using wp-mail (via PHPMailer) Mail defect (bug)
    #21659 wp_mail() problem with Reply-To header Mail defect (bug)
    #29513 Move heavy lifting of wp_mail() to child class of PHPMailer Mail enhancement
    #22942 Remove Post by Email Mail enhancement
    #32378 Image Uploads automatically puts “Olympus Digital Camera” as caption Media defect (bug)
    #22938 Presentation of hierarchical taxonomy in Media modal should be checkboxes rather than comma-separated tag list Media enhancement
    #21295 Retroactively generate new images sizes if requested Media enhancement
    #31050 Better PDF Upload Management Media feature request
    #13910 Get Menu name with wp_nav_menu() Menus feature request
    #35791 WP_Site_Query class Networks and Sites task (blessed)
    #31245 Replace alloptions with a key cache Options, Meta APIs enhancement
    #17817 do_action/apply_filters/etc. recursion on same filter kills underlying call Plugins defect (bug)
    #20578 Allow users to delete a plugin without uninstalling Plugins enhancement
    #12718 Better structure for admin menu Plugins enhancement
    #15691 Network admin should have its own settings API Plugins feature request
    #32101 Ability to mark plugin as unmanaged Plugins task (blessed)
    #30352 Prevent an editor to move the front page / posts page to trash Posts, Post Types defect (bug)
    #8592 Private Pages not listed in the Parent dropdown Posts, Post Types enhancement
    #34982 New algorithm for displaying a hierarchical list of post objects in the WP_Posts_List_Table is incomplete Posts, Post Types enhancement
    #18375 Post type templates Posts, Post Types enhancement
    #12955 Add get_post filter Posts, Post Types feature request
    #12706 Custom post status bugs in the admin Posts, Post Types task (blessed)
    #16379 Better UI for doing “Page on Front” Posts, Post Types task (blessed)
    #29660 Functions in wp_includes/query.php assume non-null return value from get_queried_object Query defect (bug)
    #25473 wp_text_diff creates wrong number of columns if title arguments are set Revisions defect (bug)
    #23314 Allow published posts to be revised without being updated immediately Revisions enhancement
    #20564 Framework for storing revisions of Post Meta Revisions enhancement
    #21374 Add core support for letting custom permalink structure for different post types Rewrite Rules enhancement
    #30579 wp_enqueue_style in footer Script Loader enhancement
    #34292 Support for DNS Prefetching & Prerender Script Loader feature request
    #21022 Allow bcrypt to be enabled via filter for pass hashing Security enhancement
    #26475 Hierarchical meta box display issues when messing around with new terms Taxonomy defect (bug)
    #9777 Usability : add delete button to edit-tags.php Taxonomy enhancement
    #23421 Add sortable to taxonomy column Taxonomy enhancement
    #36574 Redesign term pages Taxonomy enhancement
    #14877 Ability to create exclusive custom taxonomies Taxonomy feature request
    #5034 Impossible to have duplicate category slugs with different parents Taxonomy feature request
    #35736 Replace ‘Lost Password’ phrase with ‘Reset Password’ Text Changes defect (bug)
    #34521 Unifying permission error messages Text Changes enhancement
    #31779 Warn users before using a built-in file editor for the first time Themes enhancement
    #30797 New function for parent theme stylesheet uri Themes enhancement
    #22355 Template stack – Beyond parent/child theme relationships Themes enhancement
    #33407 Theme tags overhaul Themes enhancement
    #14310 Make template hierarchy filterable Themes enhancement
    #19627 Themes should be able to opt-in to a static front page Themes feature request
    #33472 Templating Engine Themes feature request
    #27159 Removing TinyMCE buttons to improve user experience TinyMCE enhancement
    #32678 Audit toolbar links and content Toolbar enhancement
    #24579 Add Drag’n’Drop UI to plugin and theme manual uploaders Upgrade/Install enhancement
    #33932 Filters for Plugin/Theme Update Email Notifications Upgrade/Install enhancement
    #15955 move_uploaded_file mangles non-ascii characters on Windows platforms Upload defect (bug)
    #22363 Accents in attachment filenames should be sanitized Upload defect (bug)
    #35669 Store widgets in a custom post type instead of options Widgets enhancement
    #21165 Make categories widget work with custom taxonomies Widgets enhancement
    #36532 Allow Reordering of Available Widgets Widgets enhancement
    #32417 Add new core media widget Widgets feature request
    #4280 Allow to constrain widgets being displayed on certain page types only Widgets feature request

    Tickets by Committers/Component Maintainers

    ID Summary Component Type
    #36264 Make wpList easier to contribute to Administration enhancement
    #34941 Make the main bootstrap process in ms-settings.php testable Bootstrap/Load enhancement
    #36380 Moderate Comment screen no longer displays raw content Comments defect (bug)
    #35501 Dashboard page: incorrect work of “Activity” group box bottom counters Comments defect (bug)
    #35518 Dashboard page: No “view” link for approved comment Comments defect (bug)
    #35519 Dashboard At a Glance: comment counter isn’t updated if to approve comment Comments defect (bug)
    #33717 Send Notification Email When a Comment is Approved From Moderation Comments feature request
    #35214 Custom Comment Types Comments task (blessed)
    #34391 Harden panel/section UI code by removing contents from being logically nested (read: goodbye margin-top hacks) Customize defect (bug)
    #34893 Improve Customizer setting validation model Customize enhancement
    #36175 Simplify the Customizer Image Control action buttons Customize enhancement
    #34923 Introduce basic content authorship in the Customizer Customize enhancement
    #35210 Add notification area to Customizer Customize enhancement
    #29932 There is no error reporting in the Customizer Customize enhancement
    #30937 Add Customizer transactions Customize feature request
    #34115 oEmbed not working on author page without posts Embeds enhancement
    #35567 New argument `is_embeddable` for `register_post_type()` Embeds enhancement
    #12267 Upgrade loop objects to provide identical presentational interfaces General enhancement
    #21170 JavaScript actions and filters General feature request
    #36335 Next generation: core autoloader proposal General feature request
    #33055 Support Parallel HTTP Requests in WP_Http, et al HTTP API task (blessed)
    #20491 Introduce some JavaScript i18n functions I18N enhancement
    #34114 Remove the requirement to call load_plugin_textdomain() or load_theme_textdomain() I18N enhancement
    #22229 Plurals in JavaScript I18N enhancement
    #35791 WP_Site_Query class Networks and Sites task (blessed)
    #31245 Replace alloptions with a key cache Options, Meta APIs enhancement
    #35658 Provide additional data for registered meta through register_meta() Options, Meta APIs enhancement
    #13459 Conflict between post and page slugs/permalinks when permalink setting is set to /%postname%/ Permalinks defect (bug)
    #20578 Allow users to delete a plugin without uninstalling Plugins enhancement
    #36217 WP_Post_Type class Posts, Post Types enhancement
    #36292 Rewrites: Next Generation Rewrite Rules feature request
    #32358 Add unminified jQuery to core for better debugging with SCRIPT_DEBUG enabled Script Loader feature request
    #35381 Introduce `WP_Term_Query` Taxonomy defect (bug)
    #36224 WP_Taxonomy class Taxonomy enhancement
    #18146 Add user-level timezone setting Users feature request
    #28216 Allow to register pre-instantiated widgets Widgets defect (bug)
    #35574 Add REST API JSON schema information to WP_Widget Widgets enhancement
  • Dominik Schilling 9:24 pm on April 14, 2016 Permalink
    Tags: ,   

    WordPress 4.6: What’s on your wish list? 

    In the spirit of the existing wish list posts, I’d like know what you have for WordPress 4.6.

    • What are you most interested in seeing in WordPress 4.6 — big, or small?
    • What are your or your users’ biggest pain points?
    • What do you see as the most important UX to be solved?
    • Which existing feature should get a “version 2”?

    Look forward to hearing from you in the comments! Let’s make.wordpress.org/great-again! 😉


    The WordPress 4.6 kick-off chat will be next Wednesday, April 20, 2016 20:00 UTC.

    • Wolly aka Paolo Valenti 9:33 pm on April 14, 2016 Permalink

      The old @scribu plugin posts2posts

      Better users management (groups, native multi role management etc.)

      • Matt van Andel 5:52 am on April 15, 2016 Permalink


        Post and user relationships are at the top of my list, too.

      • roscabgdn 7:18 am on April 15, 2016 Permalink

        +1 😀

      • Daniele Scasciafratte 9:52 am on April 15, 2016 Permalink

        I really love that plugin but i think that is a feature only for developers and require a big work to be integrated in wordpress.

      • 3pointross 1:52 pm on April 15, 2016 Permalink

        +1 😀

      • Alexander Celeste 6:42 pm on April 18, 2016 Permalink


      • goelji 5:15 am on April 20, 2016 Permalink

        Yes! Yes! Yes!

      • KARTHOST 3:31 pm on April 20, 2016 Permalink

        Yes +1 – This is a BIGGY. Given permissions to certain Users to manage certain Posts/Pages or custom posts. Used this in several CMS sites before and it can be a invaluable tool.

      • Cristian 1:24 am on April 24, 2016 Permalink

        Ability to create many-to-many relationships between posts of any type would be highly useful.

    • jteague 9:34 pm on April 14, 2016 Permalink

      User auth logging /auditing would be especially useful as an forensic and tracking tool.

    • b-rad 9:35 pm on April 14, 2016 Permalink


      If WordPress is going to be a serious CMS then it needs to have a way to manage groups of users. Content shouldn’t be limited to being owned by one person. I should be able to change the owner of a page or post to a group, and anyone with the sufficient permissions should be able to then edit that content. Blows my mind that this doesn’t exist yet.

      And a better media manager.

    • Brian Krogsgard 9:38 pm on April 14, 2016 Permalink

      As a user, it is a lot of work to replace a media item or attachment that is used many places throughout a website.

      I understand that server issues may make “updating” an attachment post (image, pdf, audio, etc) challenging, but some interface for updating instances of a piece of media throughout a site would be a really interesting feature to explore.

      • Jon Brown 2:27 am on April 15, 2016 Permalink

        Funny, I mentioned this need to Shredder at Pressnomics. Currently I use the Media Replace plugin, but it really should be in core IMHO.

        I’ve long wanted better digital asset management tools baked into core, but “replace” is such a basic need that should be easy.

      • Aaron Jorbin 3:28 am on April 15, 2016 Permalink

        This to me seems like it would be a quality feature project. It is approaching the problem with few assumptions rather then coming in with a solution ready to go.

        I don’t know how big the use case is for something like this. I know that I’ve never needed to do it, but I do know that there have been times when large media sites I’ve worked on have.

      • Patrick Daly 1:48 pm on April 18, 2016 Permalink

    • Patrick Steil 9:45 pm on April 14, 2016 Permalink

      1. Ability to create unlimited sidebars and associate them with any page/post/custom post type/category/tag, etc just like is done in this fantastic plugin:

      This is critical for building out more complex sites.

      2. Ability to delete themes – why is this missing? lol (yes I know there are plugins for this)

      3. Incorporate and improve functionality / control of user login/registration/lost password forms and email notifications like “Theme My Login” does.

      4. When you Deactivate or Activate plugins, list them on the notification. So that WHEN you are testing for plugin conflicts you will know what you just did and not have to keep track of it mentally.

      • Simon Prosser 9:54 pm on April 14, 2016 Permalink

        2. Ability to delete themes – When have you needed a plugin to delete a theme? If you click on the theme in the themes admin page there is a delete button in the bottom right corner.

        • Patrick Steil 11:06 am on April 15, 2016 Permalink

          Wow, never saw that button. I was always looking for it on the main Themes listing page. Would be more intuitive there, thanks.

    • Retrofitter 9:45 pm on April 14, 2016 Permalink

      Storing widgets in a custom post type instead of options #35669 and afterwards melting widgets and shortcodes together

    • Stephanie Leary 9:51 pm on April 14, 2016 Permalink

      I return from a long hiatus to bang the drum for #8592. We need a consensus on the desired UX for building draft/private/future page hierarchies before moving forward with any of the various patches.

      • Tammie 10:38 pm on April 14, 2016 Permalink


      • Kaspars 11:58 am on April 20, 2016 Permalink

        +1. We should also consider allowing “private” posts that are scheduled for publishing later, draft posts that should be private when published, etc.

    • Wolly aka Paolo Valenti 10:00 pm on April 14, 2016 Permalink

      Enhanced users permissions by post, taxonomy, or cpt. You could assign to a user or a groups of users only one post, or a category ora a page or a cpt.

    • Howdy_McGee 10:02 pm on April 14, 2016 Permalink

      I wish query.php would stop throw large amount of non-object errors into the debug log #29660 – conditionals should check for object or non-null return values.

    • Brian Krogsgard 10:04 pm on April 14, 2016 Permalink

      Also, two big ‘ole scary topics:

      ✨ Custom post statuses
      ✨ Native multi-author support

    • Brandon Hubbard 10:04 pm on April 14, 2016 Permalink

      #34292 – Support For DNS Prefetch

    • Torsten Landsiedel 10:05 pm on April 14, 2016 Permalink

      I would really like to solve some of these small annoyances:
      Problems with the output from wp_text_diff
      Normalization to NFC in all input fields.
      Unnecessary paragraphs with wpautop and shortcodes
      I18N needs some translator comments if we shouldn’t use HTML entities
      wptexturize is not working correctly.
      And I think we should re-think the decision about not removing special characters from filenames

    • vovkasolovev 10:07 pm on April 14, 2016 Permalink

      ANY official way to have custom REAL FTP folders in Uploads.

      — Today’s date-driven folder names have no human mean at all.
      — In UI it’s hard to manage all images in one continuous Media Libray list.
      — It’s a pain to make two different Posts each with like 30 images from one trip. You have to remember image yourself by thumbs.
      — Hardcoded WP limitations (safety reasons). We can’t create plugins to extend Media Uploads functionality.

      I will be happy if there will be just some field with %rules% in Media Settings about folders. Or field on every Media, like Permalink in Posts.

      (Super-duper UI solution for me looks like this https://www.joomunited.com/wordpress-products/wp-media-folder this plugin about taxonomy only).

      • Gabriel Mariani 1:45 pm on April 18, 2016 Permalink

        +1 WordPress NEEDS better media management. Any other CMS makes this simple, WordPress just dumps it into a bucket and calls it a day.

    • David Anderson 10:11 pm on April 14, 2016 Permalink

      As a plugin author, two big, ongoing annoyances are 1) that if WP crashes whilst unzipping a plugin install or update, it can leave it in an inconsistent state so that it doesn’t show in the ‘plugins’ page and can’t be removed without FTP or other advanced skills, and 2) that if a user tries to install an update using the installer, he gets an error message about a destination directory existing that he doesn’t understand. We see support requests for these all of the time.

      • Frank Corso 10:28 pm on April 14, 2016 Permalink

        In terms of UX, I think the error message for the destination directory existing could be improved to help new users understand the issue. I also get quite a few support tickets concerning this.

        • David Anderson 11:13 pm on April 15, 2016 Permalink

          I got another just now… user says “I am not a computer guy. I don’t want to be! Its Greek to me.”

    • Lee Hodson 10:18 pm on April 14, 2016 Permalink

      1) Sidebar Widget Style Dashboard Widgets

      GUI (Customizer) method to create and position dashboard buttons and widgets. Be nice for clients to be able to create their own buttons and for them to add/remove dashboard widgets the way we do with sidebars widgets. We could extend the sidebar widget functionality to dashboard widgets. This way plugin developers could write dashboard widgets for users to add/remove/configure at will.

      At the moment we can drag, disable and collapse dashboard widgets but regular non dev users can’t easily create widgets or customize them in a truly meaningful way.

      2) Configurable ‘maintenance mode’ page.

      Never quite understood why the default maintenance mode page is so boring, uneditable and why isn’t there an on/off switch for it in the dashboard? Maybe this can be changed in 4.6.

      3) Editable ‘Credits’ page

      A credits.php page where WordPress core developers, site admins, web developers, graphic artists and site maintainers – old and new – can be listed.

      We can use a text file on the server for this but it would be nice if credit.php existed as part of core as an editable page that won’t be entirely overwritten when version updates happen. Make it nofollow, noindex by default so as not to sour SEO.

      4) Simultaneous Multi User Editing of Pages

      This would work similar to Google Docs or Gobby (https://github.com/gobby/gobby/wiki). Many content creators collaborate using Google Docs then transfer the end result to WordPress. Wouldn’t it be nice to be able to collaborate right in the WordPress content editor?

      I can think of several more ideas but those 4 will do for now.

      • Aaron Jorbin 2:24 am on April 15, 2016 Permalink

        > 2) Configurable ‘maintenance mode’ page.

        You can use a drop in at WP_CONTENT_DIR . ‘/maintenance.php’ to have the maintenance page styled however you want

        > 3) Editable ‘Credits’ page

        wp-admin/credits.php already exists.

        • Lee Hodson 2:59 am on April 15, 2016 Permalink

          Is there an easy way for the maintenance flag to be set without code edits?

          I don’t advise editing core files like wp-admin/credits.php because they get overwritten during updates.

          • Aaron Jorbin 3:31 am on April 15, 2016 Permalink

            You can add a .maintaince file to the root with <?php $upgrading=time(); and you will be in maintance mode until your remove that file.

            • Lee Hodson 3:43 am on April 15, 2016 Permalink

              That’s not user friendly.

              We have a maintenance mode page built into WordPress and a maintenance mode flag that is installed in the domain root which tells WP to serve the maintenance page. As a developer I’m aware of this, though I will normally use a maintenance mode plugin to manage the maintenance mode experience more elegantly than WP does by default.

              We have a maintenance mode built into WP. Why not extend it to something non devs can make use of? Seems reasonable to me.

        • Ipstenu (Mika Epstein) 3:15 am on April 15, 2016 Permalink

          I think by ‘credits.php’ the OP means ‘Credits for MY site.’

          Though why not just make a page that says ‘credits’? Or do you mean like a humans.txt file?

          • Lee Hodson 3:38 am on April 15, 2016 Permalink

            That’s close to what I mean.

            Sites change over time. Site admins change. Sites even change hands. I think it would be nice to have a standard page, with a standardized organization, where those who are aware of the page can list themselves as being party to the site’s development, the site’s administration or or the site’s maintenance. A credits page that says who, what and when.

            The worry is always that someone will come along and accidentally or deliberately delete the developer, admin or maintainer credits added to any page that can be accessed too easily via the dashboard or that someone might delete the credit added within the footer of a website.

            I don’t like sticking a credit link in a site footer because I think it looks crass to do so, though it is the standard practice.

            I wrote a plugin to add credits in the source code of sites I work on but I prefer to not use it.

            Next best method is a document on the server that holds a signature I can point potential clients to.

            A credits page would make it harder for people to falsely claim work as their own within their portfolios and would make it easier for developers and admins to prove their portfolios to potential clients.

            • BinaryMoon 1:48 pm on April 15, 2016 Permalink

              humans.txt is good for this sort of thing. Not sure how commonly it’s used though – http://humanstxt.org/

            • Ipstenu (Mika Epstein) 3:32 pm on April 18, 2016 Permalink

              The problem here is that either you make it so people can edit it or … You don’t :/ A humans.txt is oft the best balance since only people with server access can edit it. And you can use a plugin to display on the front end.


              A credit link in the footer isn’t crass any more than my car having a logo 🙂

          • Lee Hodson 10:36 pm on April 15, 2016 Permalink

            Being honest, I had forgotten about humans.txt. Thanks for reminding me of it. Have sent the project an email to offer help expanding the humans.txt idea.

        • WPDevHQ 2:42 pm on April 15, 2016 Permalink

          “You can use a drop in at WP_CONTENT_DIR . ‘/maintenance.php’ to have the maintenance page styled however you want” – any chance of dropping this in a theme/plugin instead?

          • Pascal Birchler 3:41 pm on April 15, 2016 Permalink

            That wouldn’t really work. The maintenance page needs to be accessible even when a plugin/theme is being updated (and technically isn’t available then).

    • thomaswm 10:21 pm on April 14, 2016 Permalink

      Improvements on HTTPS. Let’s Encrypt has recently left beta and encryption is becoming more and more important. There’s a bunch of tickets with keyword “https” in Trac, which could be tackled in this release.

    • Mel Choyce 10:23 pm on April 14, 2016 Permalink

      Media widget: https://core.trac.wordpress.org/ticket/32417
      Image dropzones in the Customizer: https://core.trac.wordpress.org/ticket/35827
      Better “page as front” UI: https://core.trac.wordpress.org/ticket/16379

      Also, a way to keep primary menus set when you switch between themes.

      • Tammie 10:32 pm on April 14, 2016 Permalink

        +all the 1s

        • Mark Root-Wiley 10:40 pm on April 14, 2016 Permalink

          All super great. Media widget takes the cake though. +1 for that.

      • Bozz 11:08 pm on April 14, 2016 Permalink

        Digging the media widget proposal!

      • cavalierlife 1:27 am on April 15, 2016 Permalink

        +1 for media widget. Seriously!!

      • nathangraham 1:32 am on April 15, 2016 Permalink

        +1 for better “page as front” UI

      • Ross Wintle 9:59 am on April 15, 2016 Permalink

        As well as a media widget, I’d like a standard rich-text widget. I’m sure there are UI problems to solve with creating this, but I shouldn’t have to tell people they need to type HTML tags into the text widget.

      • Retrofitter 12:23 pm on April 15, 2016 Permalink

        +1 for better ’page as front’ UI – as is now it may very well be one of the confusing aspects I have ever encountered in WordPress.

      • j-falk 1:28 pm on April 15, 2016 Permalink

        +1 on all of these!

        As for:
        #16379: Better UI for doing “Page on Front”

        that seems to have some similarities with this ticket that @westonruter mentioned in the “Customizer Kickoff for 4.6” post quite recently in terms of giving the possibility to easily create a new page that you then point out to show as a menu item.

        #34923: Introduce basic content authorship in the Customizer

        As for:
        #32417: Add new core media widget

        I totally agree with your last comment @melchoyce on that ticket to rather add the “Add media” button to the existing text widget. I think that would give the best and most flexible user interface.

      • BinaryMoon 1:50 pm on April 15, 2016 Permalink

        yes, yes, and yes.

        Similar to the dropzone in the customizer – there’s a plugin called ‘Easy Featured Images’ that lets you edit thumbnails on the post listing page (https://wordpress.org/plugins/easy-featured-images/) which I also find really useful.

      • bluantinoo 2:24 pm on April 15, 2016 Permalink

        +1 for media Widget. With optional link please 🙂

      • Benny 3:13 pm on April 16, 2016 Permalink


      • Mayo Moriyama 12:29 pm on April 21, 2016 Permalink

        +1 for media widget.
        If we could use image field in our own widget like this plugin that would be supercool!

      • Mike Selander 4:30 pm on April 21, 2016 Permalink

        +1 on the media widget – really should be in core.

    • David A. Kennedy 10:26 pm on April 14, 2016 Permalink

      Themes should be able to opt-in to a static front page: https://core.trac.wordpress.org/ticket/19627

      The experience for setting up a static front page is daunting for new users, and this could make it easier, and more integrated with the theme experience. Somewhat related, Better “page as front” UI: https://core.trac.wordpress.org/ticket/16379

    • Valdemar.in 10:31 pm on April 14, 2016 Permalink

      I think WP core must have function which widgets (sidebar) appear on which pages (categories, posts,) of your site.

      • Caspar Hübinger 5:02 am on April 15, 2016 Permalink

        What’s wrong with using Jetpack or a plugin for that purpose?

      • bluantinoo 2:28 pm on April 15, 2016 Permalink

        There are several plugins to do that. Each of them works in a different way. It’s better having a freedom on how manage the widget display options, something that is often related to other plugins use (such as multilanguage plugins). A core function can’t be as flexible as it has to be.

    • dmccan 10:31 pm on April 14, 2016 Permalink

      • The front-end editor. This is languishing and it a really great idea.
      • Ability when viewing themes to create a child theme by clicking a button or link. Creating a child theme is best practice, so let’s make it easy. Maybe promote this to a feature and finish it (see greenshady’s comments in the issues thread):


      • Standardize method to edit / change the theme footer credits and push that. Lots of people only make a child theme because they need to change the credits. Let people change the footer text in the customizer. Lead the way with the 20xx themes.
      • Agree with @thomasm, Cleaning up any HTTPS issues.
      • “WordPress.org” is the author of the WordPress Importer plugin. It needs some help.


      Thanks for asking!

    • boogah 10:36 pm on April 14, 2016 Permalink

      Let’s put some training wheels on the plugin & theme editor! https://core.trac.wordpress.org/ticket/31779

      • Jon Brown 2:34 am on April 15, 2016 Permalink

        Personally feel the editor should be removed from core and made a install on demand plugin like WordPress Importer currently is. Then maybe the editor would get some love with syntax highlting, basic syntax highlighting and checking.

        • websupporter 7:40 am on April 15, 2016 Permalink


        • leemon 1:38 pm on April 15, 2016 Permalink


        • BinaryMoon 1:53 pm on April 15, 2016 Permalink

          definitely remove and pluginize – or even scrap it entirely and let someone else make a plugin for this if they want

        • Benny 2:45 pm on April 15, 2016 Permalink


        • boogah 3:19 pm on April 15, 2016 Permalink

          I’ve long been for the “remove and pluginize” approach when it comes to the plugin & theme editors. However, I also get Helen’s argument. The plugin & theme editors were how I started tinkering under the hood. It’d be a bummer if people new to WordPress lost that entry point by phasing the option out entirely.

          Training wheels sounded like a happy medium, but going with an importer approach (installing the plugin as needed) appeals to me even more.


        • Patrick Steil 12:35 pm on April 16, 2016 Permalink

          +1 for removing the plugin/theme editor and making it a plugin – or adding a new “Developer” role that includes all Admin capabilities + things functions like this.

        • Ricky Lee Whittemore 8:21 pm on April 16, 2016 Permalink

          + 1

        • Mike Selander 4:27 pm on April 21, 2016 Permalink

          +1 – pulling this out into a plugin is a fantastic idea.

      • Ross Wintle 9:58 am on April 15, 2016 Permalink

        Oh my goodness, anything on this topic is good. Ideally remove it, or make it a plugin that people can use to learn to edit code with. It shouldn’t be in core. I disable it on EVERY site I create, and where I forget to trouble almost always ensues.

      • Ricky Lee Whittemore 8:21 pm on April 16, 2016 Permalink

        + 1

    • Mark Root-Wiley 10:38 pm on April 14, 2016 Permalink

      Make “Available Widgets” sortable: https://core.trac.wordpress.org/ticket/36532

      Make the WordPress Editor Great Again: https://core.trac.wordpress.org/ticket/27159
      (Ditch out-dated buttons that encourage bad UX and a11y)

    • Todd Lahman 10:41 pm on April 14, 2016 Permalink

      It would be great to be able to use add_meta_box() to add a metabox to a Custom Post Type submenu.

    • Rodrigo Primo 10:42 pm on April 14, 2016 Permalink

      Improve algorithm to display a hierarchical list of post objects in the WP_Posts_List_Table: https://core.trac.wordpress.org/ticket/34982

      Minor SEO enhancement to wp-login.php?action=logout: https://core.trac.wordpress.org/ticket/34401

    • Frank Corso 10:43 pm on April 14, 2016 Permalink

      I think a UX concern to consider would be in the media library. If you click an image when in grid layout, it opens a modal with certain options. However, if you are in list layout and click on an image, it opens a new page with different options. Definitely confusing to a newer end user.

    • leemon 10:44 pm on April 14, 2016 Permalink

      https://core.trac.wordpress.org/ticket/13429: Updating Link URL on image within Admin with Gallery
      https://core.trac.wordpress.org/ticket/9777: Usability : add delete button to edit-tags.php
      https://core.trac.wordpress.org/ticket/20901: Taxonomy descriptions should be TinyMCE editable
      https://core.trac.wordpress.org/ticket/23421: Add sortable to taxonomy column
      https://core.trac.wordpress.org/ticket/14877: Ability to create exclusive custom taxonomies
      https://core.trac.wordpress.org/ticket/22938: Presentation of hierarchical taxonomy in Media modal should be checkboxes rather than comma-separated tag list
      https://core.trac.wordpress.org/ticket/21165: Make categories widget work with custom taxonomies
      https://core.trac.wordpress.org/ticket/5034: Impossible to have duplicate category slugs with different parents
      https://core.trac.wordpress.org/ticket/32378: Image Uploads automatically puts “Olympus Digital Camera” as caption
      https://core.trac.wordpress.org/ticket/32101: Ability to mark plugin as unmanaged
      https://core.trac.wordpress.org/ticket/22355: Template stack – Beyond parent/child theme relationships
      https://core.trac.wordpress.org/ticket/33407: Theme tags overhaul
      https://core.trac.wordpress.org/ticket/19627: Themes should be able to opt-in to a static front page
      https://core.trac.wordpress.org/ticket/22942: Remove Post by Email
      https://core.trac.wordpress.org/ticket/22363: Accents in attachment filenames should be sanitized
      https://core.trac.wordpress.org/ticket/12718: Better structure for admin menu

    • dallasnz 10:59 pm on April 14, 2016 Permalink

      I think security should be a priority and have some teams really focus on it… because there is still too many security issues occurring around WordPress…

      • two factor authentication in the core has been delayed for too long and should have been standard by now.
      • VaultPress exists, but there should also be some free automated recovery tools that come standard in the core, or free with Jetpack.
    • MyInternetScout 11:00 pm on April 14, 2016 Permalink

      Front-end editing of posts!
      Customizable Top admin bar!
      Easy Http:// to Https:// migration tool for images and other media.
      List more image details when viewing media library list – I want to easily find the excessively large image files.

      • MyInternetScout 11:03 pm on April 14, 2016 Permalink

        Also… Detail logging of user activity. Knowing who made changes to a post or child theme and when they were made is becoming more important.

      • nathangraham 1:37 am on April 15, 2016 Permalink

        Agreed on the admin bar. I’d also like some more granular options around display. Currently you can hide for individual users but it would be nice to be able to hide by role without adding a plugin.

      • nathangraham 1:59 am on April 15, 2016 Permalink

        1. REST API endpoints
        2. Fields API
        3. HTTPS options to “secure all urls” (force https everywhere) and “secure administration” (force https in admin)

        • Scott Kingsley Clark 8:53 pm on April 15, 2016 Permalink

          +1 Fields API 🙂

        • leemon 4:05 pm on April 16, 2016 Permalink

          +1 Fields API

        • Edir Pedro 12:12 am on April 17, 2016 Permalink

          Fields API is a good one, will reduce the number of frameworks each plugin and theme loads to build their options page. Everyone would use the same framework and only create custom fields when necessary. I’m thinking on ACF example that i use in my projects and is like a service to build all my custom plugins and themes, it has good fields built in and i can build another if necessary.

        • Saru Tole 10:13 am on April 22, 2016 Permalink

          +1 Fields API

    • Ronald Huereca 11:22 pm on April 14, 2016 Permalink

      Would really like to see my update notification emails patch committed for 4.6. People who have automatic updates turned on for plugins and themes who manage multiple sites are getting a TON of e-mails. A way to turn them off without disabling the global filter is needed.

      I submitted a patch yesterday and it is ready for testing and possibly new ownership.


    • Brad Touesnard 11:48 pm on April 14, 2016 Permalink

      Background image generation:

      …and eventually (probably in another release) a background processing API that plugins and themes can use.

    • Stephen Edgar 11:55 pm on April 14, 2016 Permalink

      ❤️ Export API https://core.trac.wordpress.org/ticket/22435

      Also taking a look at the list of “Popular Tickets”, maybe aiming to pick one, some, or many from this report for each cycle https://core.trac.wordpress.org/report/23, personally I’d love to see the #1 ticket in this report “Custom post status bugs in the admin” via #12706 worked on for 4.6.

    • Knut Sparhell 12:16 am on April 15, 2016 Permalink

      I do NOT think core should add new complex and ready-to-use features with an UI, like user groups, multi languages and the like. Concentrate on the APIs and make it easier for plugins to add such great features and user intefaces. Except for the editor, the main workplace for end users. Continue the good work!

      Also, try to get rid of some outdated legacy features and options.

      • Post metaboxes cleanup and reorganizing (all closed by default)
      • Remove sending trackbacks
      • Core framework for user groups
      • Core framework for multi-language
      • Implementations of Fields API
      • Continued Multisite cleanup and OOP
      • Easer way to display translated user roles
      • Remove Post-by-Email in favor of plugins
      • Tool to convert Links to Menus, in preparation for removing Links in a later release
      • Continued user facing options cleanup
      • Unmanaged/private plugins marker
      • Install multiple plugins
      • Implement REST API endpoints
      • Framework/API for 2-factor authentication
      • Better password hashing
      • Preview post on different emulated devices
      • Front-end editing of posts
      • New strategy for bumping PHP requirements
    • John James Jacoby 12:27 am on April 15, 2016 Permalink

      ❤️ Role groups (better UI for multiple roles, per user, per site)
      💙 Custom post status API (WP_Post_Status objects, with transition support)
      💛 User status API (right now it’s barely partially implemented for multisite only)
      💜 Query classes for sites and networks 💞

    • jamesb101 2:36 am on April 15, 2016 Permalink

      More stats outside in generic stats …
      The Jetpack unit slows down my site…
      For those of us that us links ?
      The 4.5 added bottom window is useless…make so we turn the bottom window off ….
      I STILL can’t drag and drop images from Safari….
      Only Firefox…
      I never use the image thing in the basic…
      I blog…
      Drag and drop is much faster and direct….
      On the states?
      Because of the size of my site?
      It takes 5 to 10 sec’s or mre to have the states boot up….Anything on this or is the host?
      Love WordPress it’s been interersting seeing how many Highend sites are now using the same thing this ole Dog is using…

      • jamesb101 2:38 am on April 15, 2016 Permalink

        Oh, and the Day Lioght Saving time is what my site’s date stay at even if it try to change in the way the forum answers advertised..It doesn’t work for the visit total’s when we go to EST….

    • Benoît Chantre 2:36 am on April 15, 2016 Permalink

      I think one of the users biggest pain points are shortcodes.

      My wish list :

      • 2 factor authentication
      • Shiny updates v2
      • Content blocks
      • #31050 : Better PDF Upload Management
      • #22363 : Accents in attachment filenames should be sanitized
      • #28449 : Prevent widows
      • #18375 : Post type templates
      • #22139 : Hooks for wp-login customization
      • #34625 : wp-login.php site title link points to wordpress.org
      • #30352 : Prevent an editor to move the front page / posts page to trash
      • #22198 : Realigning the Discussions Settings page
      • #27111 : Turning off global comments should include existing content
      • #32396 : Settings Reduction
      • #32101 : Ability to mark plugin as unmanaged
      • #13910 : Get Menu name with wp_nav_menu()
      • #14877 : Ability to create exclusive custom taxonomies
      • #26475 : Hierarchical meta box display issues when messing around with new terms
      • #18623 : Allow themes to pre-register multiple custom backgrounds
    • Jon Brown 2:42 am on April 15, 2016 Permalink

      #1 REST API (No I’m not joking or trolling, merge it now I don’t feel we need all endpoints for initial merge of an API)
      #2 Fields API

    • Ipstenu (Mika Epstein) 3:16 am on April 15, 2016 Permalink

    • conservativeread 3:43 am on April 15, 2016 Permalink

      MAIN Goal Should Be Performance speed and Enough with New Functionality. Please slim down, Clean up all old and Unnecessary code, Bloatware, etc. thank you.

      • Aleksandar Mitić 11:25 am on April 19, 2016 Permalink

        +1 Totally agreed! Anything beside simple website is becoming to heavy to maintain on WordPress today 🙁

    • vhmark 4:14 am on April 15, 2016 Permalink

      • Multisite cron – one CLI call, efficient, fast, limit # processed per run, run on each web server in the stack
      • Make all email strings customizable via a language UI
      • Proxy non-https media to avoid mixed-content errors on https sites
      • A full-on permissions scheme: users have roles, roles have permissions in contexts, sites are broken up into contexts.
      • Ajaxify all the things! Front end UI Ajaxes to the server-side.
    • Sisir 5:11 am on April 15, 2016 Permalink

      Here are some ideas I think would be good inclusion to core. I don’t know if there are plugins for them but this feature will be useful to people who uses private plugins/themes.

      1. Install theme/plugin from url.
      2. Update theme/plugin from url.

      • j-falk 1:46 pm on April 15, 2016 Permalink

        +1 on the install url.

        I think this could be very useful for a couple of reasons:
        1) not only useful for private plugins/themes but also .org directory hosted plugins/themes where you today if you find a plugin/theme on the external .org directory either need to download the zip and upload the zip to your WordPress or search and find the same plugin/theme using the built-in directory in the wp-admin. Being able to copy a url from the external .org plugin/theme directory and install it in wp-admin using that would probably make it a bit easier.

        2) It could be a way to get around if you are not able to upload a theme/plugin due to a too low upload limit on you server.

    • Webliberty 5:21 am on April 15, 2016 Permalink

      ⭐ Please remove inline CSS styles and JS scripts Emoji in a separate file that the source code of the page was clean and beautiful.

    • cybmeta 5:45 am on April 15, 2016 Permalink

      I think these tickets regarding `wp_mail()` need some attention: #22837 and #21659.

    • Matt van Andel 5:51 am on April 15, 2016 Permalink

      1. Shortcake UI
      2. Restoring custom bulk actions (this is on me)
      3. REST API
      4. Posts-2-Posts functionality in core
      5. PHP 5.3 as a requirement
      6. A notifications settings page that allows admins to select the types of emails they want to get. Right now WordPress generates a massive amount of garbage admin notifications that can only be disabled through plugins or code changes. This needs to be a settings page.
      7. Fix for the invalid proxy headers bug (#34053)

      • Benny 2:54 pm on April 15, 2016 Permalink

        1. Shortcake UI: +100 (our end users will love it and our support too)
        5. PHP 5.3 req: +10

      • Edir Pedro 12:25 am on April 17, 2016 Permalink

        Shortcode UI is a good feature, but i avoid using shortcodes on my projects because of the WYSIWYG editor, it does not work very well to return paragraphs when a shortcode is present in the text. Shortcodes are not a good way to build custom elements inside the text editor, i prefer to use the ACF solution Flexible Content that is like a Content Builder.

    • David Shanske 5:54 am on April 15, 2016 Permalink

      I have long been interested in dealing with the fact that pingbacks in WordPress as an experience are unacceptable. The display of pingbacks has always been sub-optimal, and as a result, there was less about them to encourage addressing the abuse problems.

      There is a lot that can be done in the areas of display to make them worth displaying, and improving their security to a reasonable extent is easily possible. There is also a successor to pingback that can be integrated called Webmention.

      • Aaron Jorbin 4:23 pm on April 15, 2016 Permalink

        This feels like it could be a good Feature Project to me. Would love to see it mentioned at the next feature project chat and a group put together to look into it.

    • Compute 7:00 am on April 15, 2016 Permalink

      • Shortcode UI
      • Posts to posts
      • Updated Rewrites

      And some rewrites in terms of code:

      • David Shanske 6:26 pm on April 16, 2016 Permalink

        I hope to make it a feature project. It might span a few versions of WordPress, but it could add pieces each time.

    • andreasnrb 7:33 am on April 15, 2016 Permalink

      • Custom comment types
      • Up PHP min version. Its time says everyone.
    • Jonathandejong 7:34 am on April 15, 2016 Permalink

      I think it’s high time to be able to pass an array to the role parameter in WP_User_Query.. merging multiple queries just to fetch two/three different user roles just isn’t acceptable anymore. This issue has been around since 2012 at least.

    • Felix Arntz 7:42 am on April 15, 2016 Permalink

      A Network Settings API so that we don’t need to hack our network plugins into it (see #15691). The API should work similar to the regular one.

    • Nicolas Juen 7:56 am on April 15, 2016 Permalink

      Hook on locate template to handle multiple levels of themes
      Composer compatibility
      Primitive autoloading for performances
      Merge of the fields API
      All code on WordPress CS

    • Stagger Lee 8:19 am on April 15, 2016 Permalink

      • Shortcake (Shortcode UI) in core (to speed up developement, right now it is almost non existent).
      • Real avatar management for Users (bbPress & buddyPress can use it too)
      • Force all plugin developers to make option to remove their buttons from Post edit screen, and to make it manageable for Roles. If not option, force them to write a filter in documentation.
      • Ad Adminimize plugin in core. Maybe first as featured plugin.
      • Merge your Dashicons with Fontawesome. We can use it on frontend too. Plugins can use it.
      • Option / filter to limit max number of images in (one) WordPress gallery.
      • More work on WP Super Cache and include it in core. Now when Google value it much it is the right time. W3 Total Cache should not be better than this plugin.
      • Plugin organizer plugin as featured plugin. And later when speeded up and code cleaned added to the core (actually it is my number one wish) No matter if you have news portal or About Us, Contact website this plugin is used.
    • Netzialist 8:24 am on April 15, 2016 Permalink

      HTML-Tags in Shortcode UI. Please.
      Shortcode UI is awesome, but of not much practical use as people can’t add any HTML in textareas for example. I tried to implement some shortcodes for content elements (boxes, Lists etc.) in a project, where the client asked for help to structure long blog posts. But no HTML was a real showstopper.

      I think content elements are important. There is simply no proper way to do it right now.
      People have to go with a page-builder monster or stick to something very, very dull (headline, paragraph and blockquote).

    • Asgaros 8:24 am on April 15, 2016 Permalink

      Some captcha-/antispam-api would be nice which could be used by plugin authors to provide a safe way to interact with guests (to avoid spam) who dont have an account on the website.

      It would also be nice to add some protection to the account-registration form by default because without any captcha-third-party-plugin a lot of fake-accounts are getting registered by bots.

      • Pascal Birchler 10:46 am on April 15, 2016 Permalink

        There’s a reason Akismet comes bundled with a fresh install of WordPress by default. From my experience I know that the field of spam changes quite frequently. A plugin or external service can react to these changes faster than core.

        Regarding users: What about needing to approve new registrations and marking users as spam? Much like comments. Would be interesting to explore that.

    • Chantal Coolsma 8:34 am on April 15, 2016 Permalink

      New modern admin UI

    • kirkward 9:25 am on April 15, 2016 Permalink

      I would like to see “Save Working Copy” added to the “Publish” widget on the “Edit Post/Page” page. I frequently edit or modify existing pages and would like the ability to save my work and continue later without having to publish or abandon. It would be in addition to “Save Draft” and would only appear as an option after the post or page was published, as “Save Draft” would achieve the same function prior to first publication. Think of it as a way to change or update landing pages and such without having to create a totally new page with a new permalink.

    • Paal Joachim Romdahl 9:28 am on April 15, 2016 Permalink

      Drag & drop of posts, pages, custom posts and categories (+ a tree branch view) – https://core.trac.wordpress.org/ticket/2702
      Shiny Updates – get Automatic updates in place.
      An update of the top admin toolbar – https://core.trac.wordpress.org/ticket/32678

      Better media handling. Folders, media replace, autorenaming files that have weird characters in them, and more….

      Visual shortcodes.

      By default having the TinyMCE kitchen sink active.

      Adding a CSS editor and additional edits into the customizer.

      A better content creation experience.

      Better role/users customizations. So we can make it easier creating a client experience where we decide which areas to hide and which to leave visible.

      • Pascal Birchler 10:37 am on April 15, 2016 Permalink

        > By default having the TinyMCE kitchen sink active.

        > Adding a CSS editor and additional edits into the customizer.

        > Better role/users customizations. So we can make it easier creating a client experience where we decide which areas to hide and which to leave visible.

        I do not think the majority of users need a CSS editor for example. Most don’t even know what CSS is.

      • Mark Root-Wiley 4:00 pm on April 15, 2016 Permalink

        Preferred solution to default kitchen sink is single row of useful buttons and no kitchen sink! https://core.trac.wordpress.org/ticket/27159

    • Daniele Scasciafratte 11:03 am on April 15, 2016 Permalink

    • Pascal Casier 11:58 am on April 15, 2016 Permalink

      I just hope that all of these will go into a nice system where we all can upvote or propose rankings so you get to a top 10, 20 or 100 ?

      • Pascal Birchler 3:28 pm on April 15, 2016 Permalink

        I don’t think that’s planned, nor would it be very useful. At least it has never been done before for WordPress releases.

        A the no. 1 suggestion in some subjective ranking does not necessarily mean it must be implemented and everyone around the globe will use it.

    • tomdxw 12:49 pm on April 15, 2016 Permalink

      Let’s increase the security of passwords by using bcrypt: https://core.trac.wordpress.org/ticket/21022

    • influencebydesign 1:20 pm on April 15, 2016 Permalink

      Make template hierarchy filterable – This request has been around, planned for releases and then remove at the last minute for so long it’s embarrassing.


    • amijangos 1:22 pm on April 15, 2016 Permalink

      As a user these are my annoyances / wishlist:

      • Add tags to images for easy search or other uses
      • Easier way to add commonly used html constructs, I have a document and do copy/paste
      • Better code editor in WP
    • Stephen Harris 2:04 pm on April 15, 2016 Permalink

      Now that we have term meta data, can we expose that data in the export? #34062 There’s also a corresponding patch for @rmccue‘s improved importer: https://github.com/humanmade/WordPress-Importer/pull/18 waiting on that ticket.

    • bluantinoo 2:30 pm on April 15, 2016 Permalink

      SMTP setup without using external plugins.

      • Pascal Birchler 3:39 pm on April 15, 2016 Permalink

        What do you mean by SMTP setup? Setting up an email server is not part of WordPress’ job.

      • Benny 3:19 pm on April 16, 2016 Permalink


      • guillaumez 9:45 am on April 18, 2016 Permalink

        I agree. Sending wordpress emails through external smtp services would be great.

    • lauragusti 2:59 pm on April 15, 2016 Permalink

      I would like a better solution to add meta-boxes into Menu item management.

    • Rami Yushuvaev 3:39 pm on April 15, 2016 Permalink

      https://core.trac.wordpress.org/ticket/34521 – Unifying permission error messages
      https://core.trac.wordpress.org/ticket/35736 – Replace ‘Lost Password’ phrase with ‘Reset Password’
      https://core.trac.wordpress.org/ticket/35774 – WordPress admin title structure
      https://core.trac.wordpress.org/attachment/ticket/31237/31237.3.patch – improve get_the_archive_title() with new filter

    • Abel Cabans 3:42 pm on April 15, 2016 Permalink

      +1 Merge of Fields API

    • Robert Dall 3:58 pm on April 15, 2016 Permalink

      Here is a think that bugs me. Why when we put in a email address into the post editor as a link is it already not using antispambot. https://codex.wordpress.org/Function_Reference/antispambot

      Yes you can easily roll your own short code to protect those email address from the spammers. But in my thoughts this would be WIN WIN LOSE.

      • WIN for the user of WordPress – No confusing short code required
      • WIN for the the person with the address – Reduce the amount of spam
      • LOSE for the spammers!

      I see this a lot in WordPress install I work on because the user just doesn’t know how to make it linkable but hidden from the spammers.

      I am 100 percent behind Brian Krogsgard suggestion of the media https://make.wordpress.org/core/2016/04/14/wordpress-4-6-whats-on-your-wish-list/#comment-29688

    • mrpritchett 4:13 pm on April 15, 2016 Permalink

      I’d like to see a css prefix added to all admin classes. With the customizer and front end editors starting to proliferate, the amount of bleed on elements like .button and textarea causes issues.

    • Ulrich 4:55 pm on April 15, 2016 Permalink

      https://core.trac.wordpress.org/ticket/30797 New function for parent theme stylesheet uri
      https://core.trac.wordpress.org/ticket/20578 Allow users to delete a plugin without uninstalling
      https://core.trac.wordpress.org/ticket/32802 Update Masonry (v3.3.2) & imagesLoaded (v3.2.0) package

    • andreasnrb 5:21 pm on April 15, 2016 Permalink

      Id like a hook in the template loader method instead of an include. This to make possible to override the default wp theme engine better. https://core.trac.wordpress.org/ticket/33472#comment:7

    • voldemortensen 5:59 pm on April 15, 2016 Permalink

    • Andy Mercer 6:04 pm on April 15, 2016 Permalink

      Virtual folders for media in the grid views, based on taxonomies.

    • Thorsten Frommen 9:39 pm on April 15, 2016 Permalink

      Split up files that either hold multiple classes, or both classes and other (global) stuff. This would mean a great deal to https://core.trac.wordpress.org/ticket/36335.

    • Robert Reiser 5:47 am on April 16, 2016 Permalink

      I would like to see the ability to add custom fields to taxonomies in the same way we can already add custom fields to posts and pages:

      Screen Options -> Custom Fields

    • jschlick 10:01 am on April 16, 2016 Permalink

      Optimization for energy efficiency, thinking about the carbon footprint of core.

    • Frank Bueltge 12:45 pm on April 16, 2016 Permalink

      I miss really the Settings API in the multisite environment. As developer we create plugins for single and multisite with different settings methods, class etc. Lot of effort and not cleat for validating, secure code. It is time to clean this issue in WP.

      I like also the autoloader poposel – https://core.trac.wordpress.org/ticket/36335

      Yes, no visible features, but really helpful for the end-users and the developers, there also maintain, create the popularity of WordPress.

      Even now thanks for your job @ocean90

    • Spacedmonkey 1:52 pm on April 16, 2016 Permalink

    • Ricky Lee Whittemore 8:24 pm on April 16, 2016 Permalink

      Allow to register custom radio button taxonomy similar to Post Format.


    • Edir Pedro 12:52 am on April 17, 2016 Permalink

      • Interface UI Kit on admin, like bootstrap, with tabs, fields, modal, etc, well documented.
      • Fields API
      • Rest API
      • Ease migration, do not store domain on database, like settings and post images.
      • Generate image sizes on the fly to reduce the number of files never used on server.
      • When upload, sanitize filename to replace accents and prevent server errors when migrate to another server with different locale setup, servers at different countries.
      • Multi-language native support, Polylang plugin is a good example.
      • Native debug tool like Symphony.
      • Native rules and group editor to manage users.
    • tpnotes 3:35 pm on April 17, 2016 Permalink

      I would be happy to see the following features in core:

      • Domain mapping feature for Multisite
      • Nofollow option for inline link editing with the visual editor
      • Option for setting a whole site (or a single site from a multisite installation) to private/non-public/registered users only. Similar to the feature for posts and pages.
    • Ahmad Awais 6:11 am on April 18, 2016 Permalink

      #1 REST API
      #2 Customize — Add new Post | Metadata
      #3 Fields API
      #4 Custom Comment Templates

    • Juniper Webcraft 8:07 am on April 18, 2016 Permalink

      Add ability to limit authors to attaching media that they themselves have uploaded, in much the same way that they’re limited to editing posts that they’ve created (are flagged as Author of), rather than giving all authors access to the entire media library.

    • Compute 9:38 am on April 18, 2016 Permalink

      Would love to see some focus on this: #15955

    • Rami Yushuvaev 10:39 am on April 18, 2016 Permalink

    • Gabriel Mariani 1:50 pm on April 18, 2016 Permalink

      https://core.trac.wordpress.org/ticket/24579 – Drag-Drop Plugins/Themes / multiple upload
      https://core.trac.wordpress.org/ticket/21374 – Permalinks for other post types

    • csigncsign 6:32 pm on April 18, 2016 Permalink

      fixing finally the annoying handling of the “blog” slug/permalinks on multisite installations.
      The main blog of a multisite installation always adds another “blog” slug in the permalinks, to avoid conflicts with sub-blogs, yes, but there are lots of troubles with breadcrumbs etc.
      This should be solved in another intelligent way 🙂

    • Ryan Boren 8:28 pm on April 18, 2016 Permalink

    • Morten Rand-Hendriksen 9:33 pm on April 18, 2016 Permalink

      Post (Type) Templates along the lines of Page Templates:


    • cindyleonard 9:44 pm on April 18, 2016 Permalink

      I would love to see “Menus” moved from under Appearance and just below Pages. I also recommend to my clients that they should have very few Administrators and make the content-only folks Editors. The only problem with that is they aren’t able to add or alter the menus if they need to. I’m okay with people editing menus, but hate the idea of giving them access to everything else in the Administrator view to facilitate that.

    • jleung1994 10:26 pm on April 18, 2016 Permalink

      • custom post types
      • custom fields
      • bulk image edit, image categories, auto create alt from image name without dash and underscore
      • rename and replace images
      • set image thumbnail sizes
      • force https://, redirect
      • WordPress version and plugin update control
      • drag and drop page and post order
    • Peter Hardy-vanDoorn 11:37 am on April 19, 2016 Permalink

      Admin post navigation please, along the lines of https://wordpress.org/plugins/post-navigator/

    • SvetAndroida.cz 12:42 pm on April 19, 2016 Permalink

      I’d like Neve version two versions.
      1) to natovně users can sign in using a social network (one click) on anyone with the already tired of creating new accounts, but on one of the social networks is almost everyone
      2) such as WordPress can send emails to prove send PushNotifikace (https://developers.google.com/drive/v3/web/push)

      Is any of this real?

    • Kokomo 1:34 pm on April 19, 2016 Permalink

      Not sure if this has been mentioned before, but would be nice to have a better way to copy the url of media items. Maybe a “copy to clipboard” next to the url? Right now it’s a hassle to select the whole URL and copy it manually.

    • tinnyfusion 1:59 pm on April 19, 2016 Permalink

      Two things of the top of my head, one little and one huge. The first, a better way to copy the URL of media in Attachment Details as it’s frustrating on desktop and near impossible on mobile.. Secondly, a real Notification Center!

    • ahmadabuaysheh 6:31 pm on April 19, 2016 Permalink

      what an awesome thing is to be able to create a systematic flow for articles department, which means that you could add a writer, editor then an media expert to publish in time. so there is a like a pipeline of production inside the WordPress itself.
      To be more clear on that, imagine the writer has wrote his article then when publishing it, the editor must see first and correct what it needs. So, when the editor accepts it, it is now for the media expert to publish the article by controlling the date of publishing.
      This would make any journal, magazine, news blogs to implement this system into WordPress.
      I know that because I was asked to do so but I didn’t really been dependent on the WordPress core to do it. I just build an Email workflow to do it and just one uploads the article and publish it.
      I know that the current user roles can be used to that somehow, but how is it possible when there a more clear way, maybe also to specify the roles and rename them maybe.

    • Anthony Hortin 6:38 am on April 20, 2016 Permalink

      • Redesigned/improved Image Library along with the ability to create folders.
      • Fix the Image Library Grid/List UI so there’s not multiple screens that perform the exact same function. The whole Gird/List UI has been a mess since the Grid layout was introduced.
      • Customizer redesign including the ability to default to a wider 2 column layout so you’re not scrolling for pages and pages when there’s heaps of options.
      • Better consistency with the Customizer UI. Sometimes you click a button and more fields appear below it. Other times you click a button and a panel slides in and out of view. Sometimes when you click a button, the panel slides to the left, other times it slides to the right. Users shouldn’t have to wonder what’s going to happen when you click a button.
      • Better notification experience. Too many plugins/themes are cluttering up the WordPress Dashboard with multiple and constant notifications.
      • Redesign of the Show Password/Hide/Show/Cancel/Generate Password buttons on the User Profile screens. The UI is confusing and there are too many unnecessary buttons.
      • The ability to be able to upload AND overwrite existing plugins. So Annoying not being able to upload newer plugin versions through the dashboard and simply overwrite the old version
      • HoaSi 9:38 am on April 21, 2016 Permalink

        Yes to all. Better image management, with folders for images and galleries would be particularly useful.

      • colomet 9:32 am on April 23, 2016 Permalink


    • superbotics 9:35 am on April 20, 2016 Permalink

      wp list table would need a large work around. probably convert it to ajax based. meaning for search, pagination, sorting, etc. that will save lot of time just keeping reloading every thing

    • Paal Joachim Romdahl 9:05 pm on April 20, 2016 Permalink

      I came across this age old widgets per page/post trac ticket:

      It would be nice to create some discussion about this area again.

    • Arachnoidea 7:23 am on April 21, 2016 Permalink

      It would be great if you could improve the way we can change the “Published on:” date for posts (in the post editor). Now this part consists of 5 different form fields, and its date format (Month, Day, Year) is not a standard one in all countries.
      Why not using a jQuery UI -like date/time picker here?
      Also it would be visually more appealing to see it in a calendar-like view when my scheduled post is going to go public…

    • sumeetgohel 11:18 am on April 21, 2016 Permalink

      Hello WP Devs,
      It would be very nice if WP has in-built options for
      1) Facebook and other Social networking sites URL text inputs in administration side.
      2) Add link in single post for ‘Duplicate’ in supported post types in post/custom-post-type listing for make duplicate post.

    • Ben Lobaugh (blobaugh) 8:36 pm on April 21, 2016 Permalink

      Autoloader in core!!!

      See proposal https://core.trac.wordpress.org/ticket/36335

    • brunowebdesign 9:56 pm on April 21, 2016 Permalink

      4.6 should focus on security. I can’t tell you how much xmlrpc and wp-login get abused by botnets, and its easy to DoS a server because of all the mysql connections opened. Why not touch a flat flle with a timestamp, and if the next wp-login comes in under 3 minutes (user configurable) it spits out a 1 line text error.

      This would stop botnets from brute forcing and overloading servers all over the place. None of this should be taken care of by 3rd party plugins or server configurations. WordPress default install should have these types of protections in it.

      I know someone is going to say, just use .htaccess or some other mechanism to block wp-login and xmlrpc. But without this external configuration, why doesn’t wordpress default core try to do “something” to stop answering repeated requests? This is such an easy problem to fix and one of the reason that so many wordpress installs in the wild get hacked or ddosed

    • davidperez 8:47 am on April 22, 2016 Permalink

      Please Taxonomy images. Add Image featured in taxonomy and tags.

    • colomet 9:32 am on April 23, 2016 Permalink


    • jbarrett888 10:00 pm on April 23, 2016 Permalink

      It would be great to add the following characters to the WordPress “special characters” box. These reflect a diacritical mark (macron) used on some vowels in Hawaiian language:

      Ā ā
      Ē ē
      Ī ī
      Ō ō
      Ū ū

      • Samuel Sidler 7:05 pm on May 3, 2016 Permalink

        Hello! I’d love to chat with you about bringing the Hawaiian translation of WordPress up-to-date and at 100%. Can you ping me on Slack (I’m “sam”)?

    • jynxy 9:24 am on April 25, 2016 Permalink

      My wishlist,

      • Make it easier to transfer wordpress to another url.
      • Remove the security tokens within the database no need for them.
      • stop wordpress modifying html code, really annoying.
      • better security, captcha, hide invalid user/password, .htaccess to prevent php files in directories such as uploads.
      • disable comments by default on every page and post, which better control on enabling. i.e posts only.
      • able to mass delete menu items without having to open each one you wish to delete.
      • inbuilt gallery
      • Notification system for all wordpress and 3rd party, stop cluttering the dash.
      • merge core js/css files.
    • medieskolen 5:30 am on April 26, 2016 Permalink

      I just found this plugin : https://wordpress.org/plugins/publish-on-screen/ …. and it just makes my everyday-WP-life sp much easier.

      The developer description is clear: A WordPress plugin that alters the position and behavior of the Publish button, making it stick to the bottom of the page when scrolling down the page (RTL Support).

      … I now use this plugin on ALL my sites

      And think that so simple and usefull that it should be in WP

      //Lars, Copenhagen

    • medieskolen 5:39 am on April 26, 2016 Permalink

      Make it possible to have two different languages …. frontend language AND backend language

      I’m making WP-sites in Denmark (mostly in danish)

      I like the Admin to be in english – because I’m used to it and because most help is to be found is in english and not in danish.

      The problem is that if I set the Site Language to English – the “frontend code” () will tell Google that the site language is English and not danish.

      Therefore I would like to suggest two language-settings instead of just one …. something like this:

      Site language
      Admin language (or Backend language)

      I have found a plugin that might do the trick but I think this should be added to the “standard settings”
      ( https://wordpress.org/plugins/english-wp-admin/ )

      I hope you can see my point

      Best regards from Lars, Copenhagen

    • Rask 11:06 pm on April 26, 2016 Permalink

      `alloptions` cache needs some rearranging. https://core.trac.wordpress.org/ticket/31245

    • Paal Joachim Romdahl 9:56 pm on April 29, 2016 Permalink

  • Ella Iseulde Van Dorpe 8:24 pm on April 14, 2016 Permalink |
    Tags: , , , ,   

    Media Chat 

    In the regular #core-images chat this Friday, 15 April, 19:00 UTC we are planning to discuss enhancements for 4.6. So far there are four items on the agenda:

    • We are planning to add responsive images to the editor and discuss different implementation methods, e.g. saving srcset and sizes attributes to the database versus generating them on the front end. See #36475.
    • The makers of TinyMCE recently released JavaScript image tools for editing images in the browser which could replace the current server based image editor. The new editor would be quite faster, allowing you to edit and resize images before uploading them, and it would be easier to include in other scripts. This may well be a feature project over a few releases.
    • PDF preview images. See #31050.
    • Continue to improve mixed content issues on HTTPS sites. See #34945.

    If you have more ideas or tickets to discuss regarding media, please join us or leave a comment here. 🙂

  • Weston Ruter 12:50 am on March 22, 2016 Permalink
    Tags: , , ,   

    Implementing Selective Refresh Support for Widgets 

    WordPress 4.5 includes a new Customizer framework called selective refresh. To recap, selective refresh is a hybrid preview mechanism that has the performance benefit of not having to refresh the entire preview window. This was previously available with JS-applied postMessage previews, but selective refresh also improves the accuracy of the previewed change while reducing the amount of code you have to write; it also just makes possible to do performant previews that would previously been practically impossible. For example, themes often include some variation of the following PHP and JavaScript to enable performant previewing of changes to the site title:

    function mytheme_customize_register( WP_Customize_Manager $wp_customize ) {
    	$wp_customize->get_option( 'blogname' )->transport = 'postMessage';
    add_action( 'customize_register', 'mytheme_customize_register' );
    function mytheme_customize_preview_js() {
    	$handle = 'mytheme-customize-preview';
    	$src = get_template_directory_uri() . '/js/customize-preview.js';
    	$deps = array( 'customize-preview' );
    	$ver = '0.1';
    	$in_footer = true;
    	wp_enqueue_script( $handle, $src, $deps, $ver, $in_footer );
    add_action( 'customize_preview_init', 'mytheme_customize_preview_js' );
    ( function( $, api ) {
    	api( 'blogname', function( setting ) {
    		setting.bind( function( value ) {
    			$( '.site-title a' ).text( value );
    		} );
    	} );
    } ( jQuery, wp.customize ) );

    In 4.5, the core themes now utilize selective refresh for previewing the site title and tagline. This allows the above code to be replaced with the following PHP:

    function mytheme_customize_register( WP_Customize_Manager $wp_customize ) {
    	$wp_customize->selective_refresh->add_partial( 'blogname', array(
    		'selector' => '.site-title a',
    		'render_callback' => function() {
    			bloginfo( 'name' );
    	) );
    add_action( 'customize_register', 'mytheme_customize_register' );

    So as you can see, not only is the amount of code more than cut in half (also eliminating the JS file altogether), it also ensures that when a site title change is previewed it will appear with all of the PHP filters applied from core and plugins: for example wptexturize will apply so that curly quotes and dashes will appear as expected. In REST API parlance, selective refresh enables the Customizer preview to show title.rendered instead of just title.raw. (For more on this change to previewing the site title and tagline, see #33738. The previous JS-based previewing is retained for an instant low-fidelity preview while the selective refresh request returns.) Selective refresh is also the mechanism used for previewing the new custom logo feature in 4.5, ensuring that the logo image is rendered re-using the image_downsize logic in PHP without having to re-implement it in JS (keeping the code DRY).

    With that recap of selective refresh out of the way, let’s turn to the focus of this post: selective refresh for widgets. When widget management was added to the Customizer in 3.9, every change to a widget required a full page refresh to preview. This resulted in a poor user experience since a full refresh can take awhile, especially on weighty pages. So selective refresh of widgets is a key usability experience improvement for widget management in the Customizer in 4.5. However, as live postMessage updates to the site title and tagline have required supporting theme code (see above), so too will theme support be required for widgets, as noted in the Selective Refresh of Widgets section from the previous post on this topic:

    Selective refresh for nav menus was enabled by default in 4.3. While some themes needed to add theme support for any dynamic aspects (such as the expanding submenus in Twenty Fifteen), generally nav menus seem to be fairly static and can be replaced in the document without needing any JS logic to be re-applied. Widgets, on the other hand, have much more variation in what they can display, since they can in fact display anything. For any widget that uses JavaScript to initialize some dynamic elements, such as a map or gallery slideshow, simply replacing the widget’s content with new content from the server will not work since the dynamic elements will not be re-initialized. Additionally, the sidebars (widget areas) in which the widgets are displayed may also have dynamic aspects associated with them, such as the Twenty Thirteen sidebar which displays widgets in a grid using Masonry. For this theme, whenever a widget is changed/added/removed/reordered, the sidebar needs to be reflowed.

    In order to allow themes to reflow sidebars and widgets to reinitialize their contents after a refresh, the selective refresh framework introduces widget-updated and sidebar-updated events. Additionally, since re-ordering widgets in a sidebar is instant by just re-ordering the elements in the DOM, some widgets with dynamically-generated iframes (such as a Twitter widget) may need to also be rebuilt, and for this reason there is a partial-content-moved event.

    For the above reasons, I believe it will be much more common for widgets (and sidebars) to need special support for selective refresh, and so I think that at least for 4.5 the selective refresh should be opt-in for widgets (and perhaps in themes for sidebars). See theme support for Twenty Thirteen and plugin support for a few widgets in Jetpack (which won’t be part of the merge). At last week’s Core dev meeting, it was suggested that we add the opt-in for widget selective refresh at RC.

    So as noted, selective refresh for widgets will be opt-in as of 4.5 RC1 (see #35855).

    What do themes and widgets need to do to opt-in for selective refresh support?

    Selective refresh will be used for previewing a widget change when both the theme and the widget itself indicate support as follows:

    Adding Theme Support

    If your theme does not do anything fancy with its sidebars (such as using Masonry to lay out widgets), then all that you need to do is add the following to your theme:

    add_theme_support( 'customize-selective-refresh-widgets' );

    On the other hand, if the theme is rendering a sidebar in a unique way, then to add a bit of logic to handle the changes properly. For example, as noted previously the footer area in Twenty Thirteen consists of a sidebar that is laid out using Masonry. When a widget is added, removed, or updated, the Masonry logic needs to be re-run to update the positioning of the widgets in the sidebar. The following highlighted code is what handles this:

    jQuery( function( $ ) {
    	var widgetArea = $( '#secondary .widget-area' );
    	widgetArea.masonry( {
    		itemSelector: '.widget',
    		columnWidth: columnWidth,
    		gutterWidth: 20,
    		isRTL: body.is( '.rtl' )
    	} );
    	if ( 'undefined' !== typeof wp && wp.customize && wp.customize.selectiveRefresh ) {
    		wp.customize.selectiveRefresh.bind( 'sidebar-updated', function( sidebarPartial ) {
    			if ( 'sidebar-1' === sidebarPartial.sidebarId ) {
    				widgetArea.masonry( 'reloadItems' );
    				widgetArea.masonry( 'layout' );
    		} );
    } );

    Update 2016-07-17: Added the jQuery() DOM ready wrapper around this logic to ensure it runs after the DOM has been fully loaded, and thus ensuring the wp.customize.selectiveRefresh object exists if it is going to be loaded. See ​#37390 as this also turned out to be broken in Twenty Thirteen.

    Note the if statement is there so the code will only run in the Customizer preview and if selective refresh is available (that is, if they are running 4.5 or later).

    Adding Widget Support

    If your widget lacks any dynamic functionality with JavaScript initialization, adding support just requires adding a customize_selective_refresh flag to the $widget_options param when constructing the WP_Widget subclass. If you are enqueueing any CSS for styling the widget, you’ll also want to enqueue this unconditionally in the Customizer preview (if is_customize_preview()) so that a widget can be added to the preview and be styled properly without doing a full page refresh. For example, note these highlighted lines in a sample widget:

    class Example_Widget extends WP_Widget {
    	public function __construct() {
    			__( 'Example', 'my-plugin' ),
    				'description' => __( 'Selective refreshable widget.', 'my-plugin' ),
    				'customize_selective_refresh' => true,
    		// Enqueue style if widget is active (appears in a sidebar) or if in Customizer preview.
    		if ( is_active_widget( false, false, $this->id_base ) || is_customize_preview() ) {
    			add_action( 'wp_enqueue_scripts', array( $this, 'enqueue_scripts' ) );
    	public function enqueue_scripts() {
    		wp_enqueue_style( 'my-plugin-example-widget', plugins_url( 'example-widget.css', __FILE__ ), array(), '0.1' );
    	/* ... */

    On the other hand, as with sidebars in a theme, if a widget uses JavaScript for initialization, you’ll need to add logic to make sure re-initialization happens when the widget is selectively refreshed. So in addition to the above example, you must:

    1. Enqueue any dependent JS logic if is_customize_preview() just as noted above for enqueueing any CSS stylesheet.
    2. Add a handler for partial-content-rendered selective refresh events to rebuild a widget’s dynamic elements when it is re-rendered.
    3. As needed, add a handler for partial-content-moved selective refresh events to refresh partials if any dynamic elements involve iframes that have dynamically-written documents (such as the Twitter Timeline widget). (Adding this event handler should normally not be required.)

    The Twitter Timeline widget in the Jetpack plugin is a good example for how to write these event handlers:

    jQuery( function() {
    	// Short-circuit selective refresh events if not in customizer preview or pre-4.5.
    	if ( 'undefined' === typeof wp || ! wp.customize || ! wp.customize.selectiveRefresh ) {
    	// Re-load Twitter widgets when a partial is rendered.
    	wp.customize.selectiveRefresh.bind( 'partial-content-rendered', function( placement ) {
    		if ( placement.container ) {
    			twttr.widgets.load( placement.container[0] );
    	} );
    	// Refresh a moved partial containing a Twitter timeline iframe, since it has to be re-built.
    	wp.customize.selectiveRefresh.bind( 'partial-content-moved', function( placement ) {
    		if ( placement.container && placement.container.find( 'iframe.twitter-timeline:not([src]):first' ).length ) {
    	} );
    } );

    (This is adapted from a pending PR for Jetpack.)


    All core themes and core widgets will have support for selective refresh in 4.5. Now it’s up to theme and plugin authors to also add support to also start taking advantage of these drastic performance improvements for previewing widget changes.

    • Matthew Eppelsheimer 1:33 am on March 22, 2016 Permalink | Log in to Reply

      This is very exciting. We’re depending on the Customizer more and more, and widgets are a great fit for content management there. I’m excited to tell our clients/users about this, and how it will speed up some of their daily content management tasks.

      Excellent work Weston, and the entire Customizer component team!

    • Tada Burke 1:16 am on March 31, 2016 Permalink | Log in to Reply

      Nice work Weston! Is it too late to shrink this string? Re: customize-selective-refresh-widgets

      • Weston Ruter 2:50 am on March 31, 2016 Permalink | Log in to Reply

        @neurobotic Thanks! And yes, it is too late to shrink the string. That being said, the hope is that the need or themes to opt-in to this feature will be temporary, and that in a future release once enough themes have adopted support, that the feature can be opt-out instead of opt-in.

    • Martin Tod 8:15 am on April 3, 2016 Permalink | Log in to Reply

      Is there an event that’s triggered before the old content is removed? In order to close down the previous JavaScript that’s expecting it to be there?

      • Weston Ruter 4:39 pm on April 3, 2016 Permalink | Log in to Reply

        @mpntod The partial-content-rendered event will include a `placement` context object which has a `removedNodes` property with a reference to the old content that was just removed. So no, there is no event triggered before the replacement is done (not at the individual partial context at least. There is a render-partials-response that is triggered when the data is first received). I’d like to understand the use case for this, but en lieu of there being a core event for this, you could also override/wrap the wp.customize.selectiveRefresh.Partial.prototype.renderContent method to trigger another event before the normal logic is run.

        • Martin Tod 6:40 pm on April 3, 2016 Permalink | Log in to Reply

          @westonruter It’s a bit of an odd issue. My plug-in uses a mildly modified version of the jQuery Cycle2 script – which was crashing after the partial content re-rendering. So I mildly modified it some more and solved the problem.

          However, sometimes when other plug-ins have their own version of jQuery Cycle2, to avoid clashes, my solution has been to use their version – but this doesn’t have the fix in. So I was wanting to try to run the `destroy` command for jQuery Cycle2 before the content was removed to see if this was a possible fix.

          I’ll try to find some other solutions in the meantime!

    • mooberrydreams 3:51 pm on April 8, 2016 Permalink | Log in to Reply

      The widget in my plugin uses Javascript on the admin side, not the viewing side. I’m having trouble getting it enqueue’d when viewing in the Customizer. I’m enqueue’ing in the admin_footer hook. What am I missing?

      • Weston Ruter 3:55 pm on April 8, 2016 Permalink | Log in to Reply

        @mooberrydreams So this isn’t related to Selective Refresh. Instead of using the admin_footer hook, you should enqueue the script in admin_enqueue_scripts when the $page_hook is 'widgets.php'. This will get triggered for widgets in the Customizer.

    • jhill365 2:58 am on April 19, 2016 Permalink | Log in to Reply

      So, in the case of a widget that is being used in the customizer and being updated by javascript (for example by a returned value from the media manager window), will this fix the bug where updates to widgets performed in javascript aren’t recognized by the customizer? For example, in 4.4.2 if you have a hidden input field that is used in the Widget PHP class’ update method to hold the return value of a javascript control such as the media manager or color picker (as is a common widget practice), the customizer isn’t notified automatically of the changed field value in the way that manual updates seem to fire an ajax request to the server and notify it you’ve typed a new value into a widget’s field. I hope that makes sense.

      • Weston Ruter 4:46 am on April 19, 2016 Permalink | Log in to Reply

        @jhill365 If you want an input field change in the widget form to be picked up by the Customizer, you need to trigger a change on the input element if you manually populated the value.

        • jhill365 11:18 am on April 19, 2016 Permalink | Log in to Reply

          Thank you for replying Weston. I apologize for my ignorance here, but are you saying to hook an event handler to the onchange event of the html input element? I have been trying to figure out what event notifies the customizer that a widget value has changed for a couple days now, but I cannot find it in the documentation. I have a widget that uses the native wp media manager to let the user select an image to display, but the customizer doesn’t seem to get notified of the change when I update the input field using the value returned by the javascript (only if I manually change/type it into the field).

          • Weston Ruter 1:57 pm on April 19, 2016 Permalink | Log in to Reply

            @jhill365 That’s right. So something like this:

            $( document ).on( 'widget-added', function( e, widgetContainer ) {
            	var mediaIdInput = widgetContainer.find( 'input.media-id' );
            	widgetContainer.find( 'button.select-image' ).on( 'click', function() {
            		var mediaId;
            		// ... open editor ...
            		// ... some other callback when image is selected ...
            		// ... selected attachment id is assigned to mediaId ...
            		mediaIdInput.val( mediaId )
            		mediaIdInput.trigger( 'change' ); // <==== Key line here.
            	} );
            } );
            • jhill365 8:45 pm on April 19, 2016 Permalink

              Weston, I can’t thank you enough! I’ve gotten it working now.

    • peterigz 9:41 pm on April 20, 2016 Permalink | Log in to Reply

      Thanks for the work on this it”s been working great so far. I got confused about how to implement the ‘partial-content-rendered’ binding as it just wasn’t registering the bind – for some reason at that point wp.customizer.selectiveRefresh didn’t exist then I finally realised I was missing the customize-selective-refresh dependency when en-queueing the script, so for the record it should have been:

      wp_enqueue_script( 'mytheme_customizer', get_template_directory_uri() . '/assets/js/customizer.js', array( 'customize-preview', 'customize-selective-refresh' ), '20130508', true );

  • Joe McGill 12:51 pm on February 22, 2016 Permalink
    Tags: , , ,   

    Proposal: Increase the default image compression in WordPress 

    Note: This proposal was merged to core in [36615]. Download the latest nightly build and give it a try!

    In order to improve page load performance, I propose that the default image compression setting be changed from 90 to 82 in WordPress. Let’s get into why.


    The default quality setting for resized images in WordPress has been 90 since the image_resize() function was shipped in version 2.5. This setting creates images with much larger file sizes than recommended by modern web best practices.

    Over the past several years, the importance of performance has been highlighted as users access the web globally on slower connections, and performance has even started being used by search engines to influence search results.

    Tools like Google PageSpeed Insights and WebPagetest will warn site owners if images aren’t sufficiently compressed. For example, the glossary at the bottom of the WebPagetest performance optimization page states:

    Within 10% of a photoshop quality 50 will pass, up to 50% larger will warn and anything larger than that will fail. The overall score is the percentage of image bytes that can be saved by re-compressing the images.


    With this in mind, web developer and performance advocate Dave Newton published recommendations for ImageMagick compression settings based on his research comparing various ImageMagick settings against Photoshop’s ‘high quality’ (60) setting for JPEGs. He found that an Imagick compression setting of 82 was closest to this using an objective measurement named DSSIM to compare the visual similarity between two images.

    We experimented with Dave’s settings in the RICG Responsive Images plugin during the 4.3 cycle and found that not all Dave’s suggestions can be easily applied by default in WordPress due to the memory required to process large images on shared hosts. However, changing the default image quality setting is a relatively small change that makes a big impact on file size without sacrificing much in the way of perceived image quality.

    In research released in 2014, compressed images with a DSSIM score of 0.015 were deemed acceptable to most people. In tests of several different images, I found that changing the default compression setting in WP_Image_Editor from 90 to 82 reduced image sizes by an average of ~25% with DSSIM scores ranging from 0.0014 to 0.0019 for ImageMagick and 0.0019 to 0.0023 for GD — both of which are drastically under the 0.015 threshold cited above.


    Given these results, I suggest making the change to 82 for the default image compression setting. You can follow the discussion on the related ticket (33642) and give feedback in the comments or in the #core-images channel on Slack.

    As a reminder, this setting only applies to the intermediate sizes that WordPress creates, and not the original files uploaded by users. For any users who need to maintain a higher image quality for intermediate sizes, the default quality can still be changed with the wp_editor_set_quality filter.

    • leehodson 1:26 pm on February 22, 2016 Permalink | Log in to Reply

      How about setting the default to 82 and providing an easy way for site admins to adjust the setting from within the upload screen at the time of upload and for site admins to set a default compression value in Settings > Media.

      Many site admins, editors and authors are unaware that images are compressed on upload and so few (even among developers) are aware of the wp_editor_set_quality filter; makes sense to provide a user friendly way for the quality setting to be adjusted both at time of upload and from within the media settings screen. I’d even go as far as to let those with media upload permission to rebuild their uploaded images from within the media library.

      What’s the general feeling toward this idea?

      • Eric Andrew Lewis 2:14 pm on February 22, 2016 Permalink | Log in to Reply

        I don’t think the typical end-user needs to worry about image compression levels.

        • leehodson 2:32 pm on February 22, 2016 Permalink | Log in to Reply

          They do when they can’t figure out why their beautiful high quality images of special events look fuzzy on their iPads when viewed within their websites.

          Really isn’t for us as web developers to tell people what they do and don’t need to worry about; it is for us to make it easy for people to control their websites. One extra slider in the media uploader won’t be huge distraction to authors but will make life easier for them and for site admins.

          • Samuel Wood (Otto) 4:18 pm on February 22, 2016 Permalink | Log in to Reply

            Really isn’t for us as web developers to tell people what they do and don’t need to worry about

            Actually, it is. That’s exactly your job. You don’t tell your mechanic the best way to fix your car, you don’t tell your plumber the best way to plumb. And you don’t tell your web developer the best way to develop for the web.

            “It’s our duty as developers to make smart design decisions and avoid putting the weight of technical choices on our end users.” – https://wordpress.org/about/philosophy/

            • Jon Brown 4:56 pm on February 22, 2016 Permalink

              I don’t think anyone would suggest exposing the technical details to users.

              Images and image quality are deeply personal things for many bloggers and site owners though and ignoring those desires isn’t serving our users.

              IMHO, we should have always had an option for image quality vs speed, something like

              Image quality settings could be:
              [ ] High (Minimal compression/large file size, 90 old default)
              [ ] Medium (Optimized Compression/small file size, 82 new default)

              • Neither setting affects your originally uploaded image. Changing the setting will only affect newly generated thumbnails.

              Photographers could set things to “high”, everyone else would stop generating poorly compressed thumbnails.

              I find users are very strongly bipolar on this. Either they’re photo focus and want “100% quality JPEGs” or they’re speed focused and want “A’s on all the speed test suites”. Of course the first group actually wants both, but one can explain, or at least try, to explain why those are mutually exclusive options.

            • Ihor Vorotnov 5:14 pm on February 22, 2016 Permalink

              I totally agree that it’s our job develop properly. But WordPress is used by many non-devs, without dev assistance/hiring. It this case, a UI for setting this option would make sense. IMHO, it should be:

              • default option value is 82
              • a user can change this options in Settings – Media (simple input with instructional text would be sufficient)
              • a developer can override this value via `wp_editor_set_quality` filter
            • chrishoward 5:43 pm on February 22, 2016 Permalink

              There’s so many things in WP where we allow the user to make their own choice.

              The breadth of WP users goes well beyond those reliant on other developers. Many, many, many, many WP sites are one person shops, so the user is also the admin.

              They have to set things like permalinks, home page type (blog/static), use the theme customizer, post format types, widgets, menus, categories, tags, etc.

              People have had quality setting on their digital cameras for 20 years. Likewise photo editing software.

              Poor user is sitting their trying to decide if his post is an “Aside” or a “Quote” or a “Status”… so seeing an image quality option would be like seeing old friend!

              An image quality setting is not going to scare anyone – esp if you put it in words. i.e. Max, high, medium, low.

              Adding an option for image quality is hardly “a weight of technical choices”.

              “It’s our duty as developers to not treat users as idiots – even if they are.”

              The only I’d do different to Lee is I’d only have a control for it in the Media Settings.

            • Jeremy Clarke 6:01 pm on February 22, 2016 Permalink

              FWIW you guys should focus on accepting the fact that there will not be an option for this, and definitely don’t allow yourselves to waste cycles on feeling bad about it. Decisions v. Options is an ancient debate in WP and this particular setting will NOT be the one that breaks the trend.

              Opine on what you think the default should be and accept that changing it will involve either 4 lines of code or installing a tiny plugin.

            • leehodson 6:24 pm on February 22, 2016 Permalink

              The web developer’s duty is to build the site and make it as easy as possible for the site owner or his/her designated admins to use it to create and publish contenet. Control of the site belongs to the site’s owner, not me; I’m the experienced developer, not the inexperienced site owner: make it easy to use the site.

              To use the plumber example, I’d tell the plumber what I want done and give instruction on how I’d like the end product to look e.g. fit the new sink in the corner but please make sure there is enough room for me to move my elbows without hitting the wall and try to hide the pipes as best you can without leaving any pipes sticking out for me to trip over. I’m the householder, not the plumber, but I know what I want and what I don’t want: what I want is the plumber to do the work and leave me with a way to turn on the taps without need to call in a plumber each time I need to wash my hands.

              In any case, this belongs in a different discussion.

            • leehodson 6:26 pm on February 22, 2016 Permalink

              Jeremy, who says this feature isn’t up for discussion? It obviously is up for discussion. We’re looking at changing the way WordPress handles media files and we, as end users and developers, are making a reasonable suggestion. The discussion is still open.

            • Jeremy Clarke 6:37 pm on February 22, 2016 Permalink

              leehodson: What’s up for discussion is changing the default compression level. That’s what the OP was about and that’s what this conversation could potentially change.

              Nowhere in the OP did anyone ask whether there should be a setting and the reason is there won’t be. I say this as a fellow traveler who has wasted too much energy fighting for my own pet settings, and as someone with no influence over core WP and nothing to gain other than reducing the overall community drama.

            • leehodson 6:51 pm on February 22, 2016 Permalink

              Thinking about it, there is another solution: could be added to Jetpack as part of the gallery or carousel module.

              The problem with not providing a visible override setting in core is that those with image rich sites who are unknowingly accustomed to an image compression value of 90 may suddenly find their displayed images look low-res when compressed at 82. That will catch many users unaware and I can already see the headlines slating WordPress for making the change without providing a visible method to manually adjust the setting that doesn’t require a plugin (which so many equate with the mantra ‘too many plugins are bad’) or that doesn’t require a single line of code (which many users don’t expect to be forced to use).

              Really wouldn’t like to see some developers charging WP users high fees for adjusting the compression setting. We all know some will.

              The idea of changing the default compression value to 82 or between 82 and 90 is good and is one I like but without an easy way to adjust the setting I can’t see the idea being welcomed by regular end users.

        • Mike Schroder 10:32 pm on February 22, 2016 Permalink | Log in to Reply

          Completely agree. This is one of the areas where “Decisions, not Options” is pretty clear. It’s up to us to do the research (as @dnewton, @joemcgill, and more have) and make a decision that’s good for the majority of sites. Plugins can (and do) modify this value or present a UI as they would like.

      • Jon Brown 4:40 pm on February 22, 2016 Permalink | Log in to Reply

        +1 on this proposal and +10 on Lee’s additional suggestions.

        The current setting is awful for users and we should make this better all around.

        Witness the plethora of cloud based images compression services and plugins that have sprung up to do little more than fix this fundamental design flaw in WP media management. Setting up SmushIt, Krakken, EWWW, etc should be completely unnecessary and it’s become de rigeur.

        Over the years I can’t begin to count the number of users frustrated by WP’s handling on images. Granted a huge number of those don’t understand compression, image size or color space, but the frustration stems from poor defaults without transparency (ie. making it clear what compression is happening, what sizes are being created and used) and zero control over any of it.

        • Jeremy Clarke 6:07 pm on February 22, 2016 Permalink | Log in to Reply

          Adding a setting for image compression will solve pretty much none of those problems, which IMHO are related to featured images and custom sizes (which have never been well-expressed in the UI despite being critically important to authoring workflows). Compression doesn’t confused people, it’s just something people want once they learn the benefits. Turning it on by default is the solution. Once WP has aggressive compression by default a lot of those plugins will fade away as users see the diminishing returns offered by them.

          Unlike custom image sizes, which are editorially relevant (like most of the other decisions highlighted by people in these comments as examples of settings) compression levels are not relevant to how you publish posts. No one NEEDS a different compression level no matter how much they might believe they do, whereas having a custom image size that works properly as a thumbnail in X part of your theme is mandatory.

          • leehodson 6:16 pm on February 22, 2016 Permalink | Log in to Reply

            I need it. Countless others say they need it. Where do you get the idea that no one needs it? Evidence suggests otherwise.

            • Jeremy Clarke 6:25 pm on February 22, 2016 Permalink

              I don’t think you can prove you “need” it. You want it and that’s fine, lots of people feel they want it, but your site will continue to function and display correctly without it (unlike a site with messed up Custom Image Sizes).

              Also for those who “need” it 4 lines of code or a tiny plugin is not an unreasonable step. If you really need it you can install a plugin, that’s how WP works.

              It would be so boring to make a list of options in WP that people actually need but aren’t supported by core (about as interesting as the lists above of settings that ARE in core). For now I’ll leave you with this: Despite WP having a powerful and elaborate capability/role system which can be customized infinitely, there are no options to control it anywhere in core. You can’t add roles or modify the capabilities of roles at all without a plugin. You are stuck with 4 crappy roles that barely cover common use-cases of multi-author sites. Pretty much any site with more than a dozen users will need a plugin like Members or Capability Manager. This is not a bug, it’s a decision made by core to protect users from the extra complexity.

            • leehodson 6:31 pm on February 22, 2016 Permalink

              Role management is a reasonable point. WordPress core presently allows admins to perform tasks that editors, authors and subscribers can’t perform. Is there a reason that same method can’t be employed to control access to a compression value setting in Media Settings or within the media uploader? I can’t think of one.

            • Jeremy Clarke 6:40 pm on February 22, 2016 Permalink

              >Is there a reason that same method can’t be employed to control access to a compression value setting in Media Settings or within the media uploader? I can’t think of one.

              Sorry you missed my point. I wasn’t saying that role/capability management somehow complicates the question of a setting for image compress, I was just pointing out that even role/capability management has no option visibility in core, despite being a huge, complex feature set in place under the hood.

              If such an important (security/workflow/community) feature doesn’t get admin options, you can see why options like image compression are left as “plugin territory” too.

            • leehodson 6:55 pm on February 22, 2016 Permalink

              I read it a bit fast, maybe. Thanks for clearing that up. I do see what you mean though I don’t see it the same way. Might do after an internal debate with myself.

    • chrishoward 1:37 pm on February 22, 2016 Permalink | Log in to Reply

      What Lee said!

      Some sites want minimum compression, wanting their images to look their best.

      Most folks though can’t even tell.

      Looking at that owl, I reckon you can set the default much lower, and then like Lee said, provide an override in the Media settings.

    • Mark-k 1:49 pm on February 22, 2016 Permalink | Log in to Reply

      This doesn’t sound like a real research. I am not objecting but to actually test the usefulness of this change you will need actually web page to test against.

      For small images 25% reduction will not be felt by the user as the bigger factor is the latency.. Big images are many time used as the original image so there will be no change there.

      As for saving money argument, lets call it BS. I get 10GB/mo for 8$ which I can’t even get close to utilizing. I know that israel in this regard is an outliner, but still the price for byte/mo on desktop is virtually 0 and mobile is rapidly getting there all over the world.

      Again, no objection if people can not see the difference, but not sure that a surprise reduction in quality will be welcomed by site owners that will be able to notice it. If implemented this feature should be active only on new installs.

      • Ihor Vorotnov 5:27 pm on February 22, 2016 Permalink | Log in to Reply

        > and mobile is rapidly getting there all over the world

        If you’re talking about mobile traffic cost, you’re soooo wrong. I live in Ukraine, Turkey and Montenegro. All mentioned countries aren’t technical outsiders. In fact, regular internet in Ukraine is much, much, much better then in US. I have unlimited 100Mbps cable for $5/m. However, we just got 3G in 2015, it’s available only in large cities and it’s expensive. Same applies to Russia and Belarus. In Turkey, regular networks are bad and slow, but they have great 3G even in mountain villages. But still, it’s pretty expensive. In Montenegro, regular network is fine (not that good as in Ukraine, but pretty good), 3G is fine but not cheap too. Same applies to many other european countries. So, mobile bandwidth isn’t even close to being cheap. And I’m not even talking about less developed countries. Check India, for example, or Thailand, other asian countries (except China, that’s a different beast). I don’t know how things are going in Latin America, but somehow I’m sure it’s not better. All mentioned countries/regions combined are at least half of the world. So, yes, your Israeli experience is rather an exception.

        • Jeremy Clarke 6:12 pm on February 22, 2016 Permalink | Log in to Reply

          +1 What we know for sure is that decreasing bandwidth requirements has a meaningful impact in all contexts and on mobile the impact is very important for MANY users all over the place for all kinds of reasons.

        • Mark-k 11:51 am on February 23, 2016 Permalink | Log in to Reply

          You don’t design features for today, you should design features for tomorrow when they will actually be used. Changing the default in 4.5 will have no impact on images generated before that and it will take a long time for this feature to generate more then half of wordpress hoisted images on the web. So if you think that anyone around the world will be able to save any money from the introduction of the feature then I think you are very wrong.

      • Drivingralle 3:33 am on February 23, 2016 Permalink | Log in to Reply

        @Mark-k: Happy for you that you can get cheap mobile data. But even in Germany 1GB/mo can cost you around € 10,-. The networks are quite good there but still no reason to send big images.

        Right now I’m in Asia and bandwidth is a big concern here. Volume is cheap, but a lot of sites take ages to load.

        The combination of srcset and an increased compression for intermediate sizes would be a win for both cases/locations.
        In general the weight of most websites is way to high. Images are the biggest part of it. Working on that is a a really important thing.

        • Mark-k 12:01 pm on February 23, 2016 Permalink | Log in to Reply

          srcset **increases** the sizes of the images being send, it is the opposite of this feature in terms of bandwidth performance. srcset increases the size by a factor of 4 for retina displays. shaving 25% off it will end you in an increase of a factor of 3. Maybe a faster and better way to improve image bandwidth performance is to have an option to disable srcset in core so people in “developing world” (whatever that is) can out of the box help their users save bandwidth.

    • dsthedev 2:26 pm on February 22, 2016 Permalink | Log in to Reply

      This is a great idea. I think some people are missing the point here. A mere 8% reduction in quality level can yield ~25% smaller image sizes across the board (minus original) with almost no visual difference? That sounds like it would be good for everyone. Especially since adding an option in media settings would be easy enough and allow for a little more customization.

      I think it makes even more sense if you combine it with the responsive images feature recently added. Improving performance with practically no downsides?

    • Benjamin Pick 3:11 pm on February 22, 2016 Permalink | Log in to Reply

      While I support this proposal, we need to make sure that site editors/admins (!) can find out why their images become blurry. That’s why I like the idea of a media setting – this makes it clear that there is some subjective judgement involved.

      (For example, we had a client that complained that the PNGs become blurry already at the 90%-Level. This was because the typical image was technical drawings or product images with text on it, so it feels blurry much earlier than with photos. I also think of the PDF thumbnails that might get merged into core – please test if 82% would be appropriate there as well.)

      • Jeremy Clarke 6:17 pm on February 22, 2016 Permalink | Log in to Reply

        Benjamin you’re our only hope! Can you go find those images and see how they perform at 90 v. 82?

        I suspect the difference will be invisible as in the test above, and that if they get “blurred” (certainly not a description of the test above) then 90 v. 82 won’t be the reason.

        Either way, at this point it’s up to whoever thinks 82 is to low to show examples.

        • Mark-k 12:09 pm on February 23, 2016 Permalink | Log in to Reply

          Why? it is always the people that want to change things that need to justify it. 90% kinda works and maybe the difference between 90% and 82% is not big, but is it too much difference between the original and 82%? Wherever you have text it will become harder to identify, so maybe the nice owl in the example should be replace with an image of text and the difference should be tested on this kind of images.

          Then you will say that most images do not contain text, and I will agree but before a proper measurement and additional research is done you can not just say that the “difference is invisble” to everyone.

          • Helen Hou-Sandi 3:33 pm on February 23, 2016 Permalink | Log in to Reply

            The post very clearly lays out DSSIM as a proper objective measurement, existing outside research on a precise threshold, and a lot of work done by this team to quantify various outcomes as documented in a spreadsheet. The image set includes images with text, both JPG and PNG. If that is not “proper measurement and additional research”, I have a hard time believing you’re actually open to discussion.

    • jeffmcneill 3:23 pm on February 22, 2016 Permalink | Log in to Reply

      I strongly endorse this proposal. File size, besides number of files, is one of the biggest factors in a slow user experience. Yes indeed, “the biggest factor is latency” but it is latency for requests and responses, that is what is being requested is slow making it to the device, because it is big. Also, the idea that everyone has cheap bandwidth/throughput everywhere, all the time, is simply mistaken. We need ways of making WordPress more mobile-friendly (not to mention developing-country friendly), and this is an excellent proposal to do just that.

    • Aaron D. Campbell 3:46 pm on February 22, 2016 Permalink | Log in to Reply

      I’m all for this change. An average of 25% reduction in file size seems like an obvious win, especially since the visual difference between 90 and 82 is almost none.

      However, we do not need, and should not add, a setting for this. The vast majority of users not only won’t need the setting, but won’t understand it (What does an image quality of 90 vs 82 vs 60 vs 100 actually mean?). The filter (wp_editor_set_quality) is already in place for those that really want it, and a plugin could easily be created to add this setting for any users that want it.

      • dsthedev 4:26 pm on February 22, 2016 Permalink | Log in to Reply

        I don’t know, I feel like it would be pretty easy to write a simple 1 – 2 sentence description of what the setting does. Benjamin Pick provided a perfect example of somebody uploading technical drawing or images with text on them. If a user doesn’t understand the setting they will probably skip it entirely. I also don’t think we need yet another plugin for something that could be a very simple option in core. A great example of that is needing to download the “Disable Google Fonts” plugin on every site I create because wp-core forces Open Sans on everybody without providing a very simple checkbox option to not use it.

        • Aaron D. Campbell 6:06 pm on February 22, 2016 Permalink | Log in to Reply

          The problem here is two fold:

          1) If the majority of users will never use an option, then it shouldn’t be in core. We generally refer to this as the 80-20 rule of thumb. We want core to be what 80% of the people need, and plugins to cover the needs of the other 20%. I don’t even think 20% of users will need this option, much less 80%.

          2) Option overload is a real thing. Users freeze up when there are too many options, because they feel overwhelmed. Every option that goes into the WordPress admin needs to be carefully examined and an EXTREMELY good case needs to be made for it’s necessity. A single new option, then another int he next release, and another after that, and soon our options screens are overfilled and scary to an average user. “It’s our duty as developers to make smart design decisions and avoid putting the weight of technical choices on our end users.” – https://wordpress.org/about/philosophy/

    • Stephane Daury (stephdau) 4:01 pm on February 22, 2016 Permalink | Log in to Reply

      Thanks for the time you put into this. I’m also in favor of looking deeper into this. Those not browsing on broadband, or those with bandwidth limits, will surely appreciate such savings, especially when thinking web scale, and WP as “25% of it”.

    • pix365 4:25 pm on February 22, 2016 Permalink | Log in to Reply

      LIke Aaron, I too am in favour of the change, Mobile data packages in Europe is quite expensive, so reducing the volume of data downloaded can only be a good move, I vote for a Option (& i am assuming it will be dropped to 82) inside the Media admin section to allow folks to override the new default with the Legacy setting (90)
      AND OR if you gave folks the ability to enter a custom value, i think most will use it responsibly, but you can bet some users will use 100%. for that reason alone a custom value field setting is probably not a good one, unless max setting was 90.

    • Aaron Jorbin 5:57 pm on February 22, 2016 Permalink | Log in to Reply

      Thanks for writing thus up.

      The proposal looks great. Let’s do it!

    • Helen Hou-Sandi 6:05 pm on February 22, 2016 Permalink | Log in to Reply

      I’m for this. Really great to see the numbers from objective measurements (DSSIM) included in this, always appreciate the thoroughness and thoughtfulness. Also really cool that this came from responsive images work, which while related, is not inherently coupled to this. Having API improvements come from feature work tends to work well for us.

      Regarding the comments here, no core UI settings for this, please. We don’t have one now and this change is, per the numbers, incredibly unlikely to be visually noticeable in the end results, so I don’t see why it requires further changes in the admin.

      Just so I’m clear on this point – this only applies to JPGs, yes? Are PNGs resized to PNGs or are they resized to JPGs? (There’s also a comment above with concerns about PNG quality loss.)

      • Joe McGill 6:37 pm on February 22, 2016 Permalink | Log in to Reply

        Good questions Helen.

        The quality setting affects both JPG and PNG files. PNGs will remain PNGs but compression in Imagick affects PNGs differently than JPGs so the file size differences aren’t as noticeable. There are a few tickets floating around track about better compression for PNGs specifically, which would be another nice addition to tackle.

    • Primoz Cigler 6:55 pm on February 22, 2016 Permalink | Log in to Reply

      Yes, do it. And no, no extra settings are needed. I even think you could set it to lower than 82, but I guess some other people here will kill me with fire 😀

      Are metadata and exif stripped also? I think it is a good idea they should be stripped by default as well. So called lossless compression.

    • Dave 7:10 pm on February 22, 2016 Permalink | Log in to Reply

      I’m all for this change, and appreciate Joe’s time in writing it up, and providing data to explain why.

      I agree with the last few comments about no UI settings in core (for all the same reasons that were already mentioned).

    • jteague 7:13 pm on February 22, 2016 Permalink | Log in to Reply

      +1 on this proposal. Our own recent tests came out at 84% optimal, but either compression percentage is fine.

    • Ansel Taft 7:53 pm on February 22, 2016 Permalink | Log in to Reply

      A great write-up, well reasoned, and an excellent tweak to WordPress. [/makeitso]

    • Gary Pendergast 11:20 pm on February 22, 2016 Permalink | Log in to Reply

      +1 on this change, nice writeup, Joe. 🙂

      -∞ on adding UI for an option, the existing filter is sufficient.

    • jtleathers 1:15 am on February 23, 2016 Permalink | Log in to Reply

      I’m all in favor of this change. It always bugs me when the current default creates smaller resolution images with larger file sizes than the original image. This change should definitely help.

    • M Asif Rahman 2:14 am on February 23, 2016 Permalink | Log in to Reply

      Agreed. Let’s do this.

      And for changing the value, we have a hook already.
      add_filter( 'jpeg_quality', create_function( '', 'return 80;' ) );

      Read more at – https://developer.wordpress.org/reference/hooks/jpeg_quality/

    • Drivingralle 3:45 am on February 23, 2016 Permalink | Log in to Reply

      +1 for this.

      I created a ticket in trac about giving developers a way to control image compression for costume image sizes per size to save even more file size. I think somehow related.

    • Mark Howells-Mead 8:42 am on February 23, 2016 Permalink | Log in to Reply

      +1 from me. When I make the effort to optimize content photos as precisely as possible before uploading them, WordPress’ processing always creates copies from them which are larger in file size than the originals.

      I doubt many editors or admins will take the time to pay attention to a setting in wp-admin: I think that a customization of the default setting should continue to be handled by the experienced developer, via a hook.

    • AllenAyres 8:02 pm on February 23, 2016 Permalink | Log in to Reply

      I understand I’m not a developer, but speaking for the thousands (millions?) of photographers using WP for their business-front end, it would be appreciated to give them a heads-up on the change and the way to undo it if they prefer.

      *You* may not care for image-quality vs download speed, but those who rely on the display of their work to be seen at its best do. Our life’s work is image quality, what may not be obvious to some is glaring to others.

      For those who are on slower/metered access, I’m ok if they bypass my site, it’s generally not for them in the first place.

      • Ipstenu (Mika Epstein) 12:45 am on February 24, 2016 Permalink | Log in to Reply

        I’m curious… Do you have people looking at the downsized images or the full sized? Because as I understand it, we’re only going to be changing compressions for the resized images.

        • Ryan Hellyer 8:25 am on February 24, 2016 Permalink | Log in to Reply

          I suspect it’s both. Even the “full sized” images shown on photography websites tend to be scaled down to a more reasonable number for display. And photographers tend to be very particular about their thumbnails in my experience too. I actually think the thumbnails can be even more important, as they tend to show up JPG compression more, due to their small size and people staring close at them.

          • Ipstenu (Mika Epstein) 7:55 pm on February 24, 2016 Permalink | Log in to Reply

            But isn’t the fullsized not scaled down by WP? If I upload a 3000×2000 image, it doesn’t get processed, it just gets copied.

            Thumbnails, yeah, I totally agree there. Not sure how to get the word out really.

      • Joe McGill 4:20 pm on February 24, 2016 Permalink | Log in to Reply

        Hi Allen,

        While the visual differences will be slight, I agree that we’ll want to let users with strong opinions about this sort of thing know. In fact, that’s the main reason for publicly publishing this proposal in the first place. Besides publishing information on this blog, I’d be curious to know where else you suggest we publicize this information?

        • AllenAyres 4:57 pm on February 24, 2016 Permalink | Log in to Reply

          Thank you Joe.

          To me, it would need to be published in the release notes so that those many photographers (and the developers a good percentage of the photographers pay to develop their site) would know before they update. On some hosts that update automatically it would be good to know what happened to their image quality.

          Again, what may appear slight to some is a huge change to others, and as Ryan mentioned, the resized images would be affected more (I spend a lot of time getting each image looking perfect, all the while optimizing for download speed, upload a 900×600 image, the theme resizes it to something a bit smaller to fit and then generates 1-2 thumbnails to display varying sizes throughout the site – the smaller the image the more compression affects perceived quality).

          Please don’t strip exif data either, our IP is carried in there via copyright notices, etc. I already strip out as much as possible but have seen many photographers track down theft of copyrighted images through the searches of the info they place within the exif.

          For professionals, we work/invest tremendously already to have the image display at its best, balancing that with download speed too, at least allow us a way to undo the changes made.

    • davidshq 2:02 am on February 26, 2016 Permalink | Log in to Reply

      I’m not a huge fan of this idea. I see too much deterioration in image quality. The owl looks great, but I see way too much degradation in numerous images I’ve utilized on sites in the past…

      What I would like to see is something akin to jpegMini’s technology, which reduces file size but maintains perceived image quality.

    • Todd Lahman 2:15 am on March 1, 2016 Permalink | Log in to Reply

      Not sure if this was mentioned, but this should also be applied to the jpeg_quality filter.

    • Mark Howells-Mead 8:42 am on March 31, 2016 Permalink | Log in to Reply

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