WordPress.org

Make WordPress Core

Updates from Scott Taylor Toggle Comment Threads | Keyboard Shortcuts

  • Scott Taylor 7:33 pm on August 26, 2015 Permalink |
    Tags: ,   

    Notes/Agenda – 4.4 Dev Chat, August 26 

    Here’s the agenda for today’s Dev Chat in the #core channel on Slack.

    Time/Date: Wednesday, August 12, 2015 16:00 UTC-4:

    1. New Committers were announced 
    2. Who wants to be the backup lead?
    3. Schedule is still being decided, looking at WordCamp US timetables
    4. Community Feedback

    What’s going to be in 4.4?

    There is still a lot to decide this week, but there are some things I know for sure we want to work on:

    Twenty Sixteen

    Announcement Post: https://make.wordpress.org/core/2015/08/25/introducing-twenty-sixteen/

    Responsive Images

    Update Post: https://make.wordpress.org/core/2015/08/25/responsive-image-support-update/

    ImageFlow

    This will be worked on in a feature plugin, coupled with a healthy dose of user testing and intersecting with Boren’s Flow Patrol initiative. @sheri is going to help me with/teach me user testing, which will drive any new UX/UI media desktop/mobile/responsive initiatives.

    Customizer Performance

    @westonruter and team have some GREAT initiatives:

    HTTP 2.0 Exploration

    @tollmanz has been giving great talks about HTTP/2. He and @ericlewis are going to deep-dive and see how WordPress can prepare itself/the community for taking advantage of HTTPS/TLS/HTTP2 and identify changes that can be made in core and things like VVV to get us there.

    Media Widget

    @sheri and @melchoyce worked on this in 4.3 – we hope to pick this up again

    Mutlisite, the Next Generation

    @jeremyfelt is putting together a plan for WP_Site, WP_Network, WP_Network_Query, WP_Site_Query

    The Taxonomy Roadmap

    A lot of people want Term Meta, it has some pre-reqs. @boone will give us an update of where we are in the Taxonomy Roadmap, what we’ve done, what’s left, etc.

    Things that landed in the past week

    • Images should default to not linking #31467 [33729]
    • WP_Embed::maybe_run_ajax_cache() now runs for pages [33642]
    • Term Splitting: Fix a reversal of parameters to wp_schedule_single_event() introduced in r33621. [33646]
    • Introduce post_name__in parameter for WP_Query. [33653]
    • Comments shouldn’t have more than one _wp_trash_meta_status entry. When deleting _wp_trash_meta_status, also delete _wp_trash_meta_time. [33654]
    • Show count next to “Approved”/fix dynamic counts when moderating comments: [33655][33656][33657][33662][33692]
    • Ensure that feeds are served with the proper Content-Type HTTP header. [33658]
    • Deprecate post_permalink() [33659]
    • Introduce is_post_type_viewable( $post_type_object )/Don’t show certain UI pieces when a post is not viewable on the front end [33666]
    • 'post_edit_category_parent_dropdown_args' filter [33682]
    • new filters: default_hidden_columns and hidden_columns [33689]
    • Add new constant: MONTH_IN_SECONDS [33698]
    • Ensure that attachment_url_to_postid() matches cross-scheme when front-end and back-end schemes are different. [33705]
    • Add a query var, 'title', that allows you to query posts by post_title. [33706]
    • In wp_sanitize_redirect(), don’t eat @ characters. [33707]
    • In wp_insert_user(), add a filter: 'insert_user_meta' [33708]
    • wpdb::get_table_from_query() didn’t find table names with hyphens in them. [33718]
    • oEmbed: Remove blip.tv [33719], add ReverbNation [33745]
    • In WP_Query::parse_tax_query(), allow 'cat' and 'tag' querystrings to be formatted as arrays. [33724]
    • Multisite: Add 'invite_user' action that fires immediately after a user is invited to join a site, but before the notification is sent. [33732]
    • Pass option name to option and transient filters with dynamic names. [33738]
    • Move a lot of classes into their own file, same with functions, load both in the original file: Widgets [33746] HTTP [33748] Users [33749] Comments [33750] Rewrite [33751] Roles [33752] Posts [33759] Tax [33760] Meta [33761]
     
    • Tom Peranteau 2:10 pm on August 27, 2015 Permalink | Log in to Reply

      This one gave me the white screen of death. Renamed the plugins folder, deleted my theme, renamed .htaccess, no luck. I had to overwrite 4.3 into the public_html directory to get the site back.

    • scotthack 9:34 pm on August 27, 2015 Permalink | Log in to Reply

      Not that it matters a lot, but the date of the chat above is wrong I think. You said the chat is today, right?

  • Scott Taylor 5:15 pm on August 25, 2015 Permalink |
    Tags:   

    Show Me Your WP REST API v2 Apps 

    WordPress 4.4 development hit the ground running last week, only a few hours after the launch of 4.3. We’re already close to 100 commits, and digging through the 385 responses on my “what’s on your wishlist” post. One feature that many of you want is the WP REST API (heard of it?). Lots of work has gone into it, and some people are already using a flavor of it in production – two that I know of:

    Both use version 1.*. I am working on an upgrade path for the NYT to version 2.

    The point of this post is to solicit feedback from the general community:

    • What have you built using v2 of the REST API?
    • Are you running the project in production? If so, please post a link :)
    • Have you upgraded from v1 to v2? If so, how was it?
    • If you believe in the project, would like to see it in core, and haven’t built anything with it: what’s stopping you?

    Let’s take the excitement everyone has for the feature and start stress-testing it. Build something. Anything! And then report your findings back here.

     
    • Scott Bolinger 5:34 pm on August 25, 2015 Permalink | Log in to Reply

      The WP-App Project is using v2. It’s still under development, but making good progress: https://github.com/wp-app/wp-app

      I like v2 better than v1, it’s coming along great. One thing that’s still really difficult is authentication from 3rd party clients (like mobile apps). It won’t be possible to build a widely used mobile app until OAuth is in core, with a simple way to create tokens.

    • prionkor 5:35 pm on August 25, 2015 Permalink | Log in to Reply

      I have built an EmberJS app top of WP REST API. Unfortunately it is not live yet :)

    • JS Morisset 5:43 pm on August 25, 2015 Permalink | Log in to Reply

      WPSSO has support for REST API v2 — it adds a new ‘head’ field that contains two arrays: the ‘html’ array is a list of all social meta tags created by WPSSO for that post/term/user, and the ‘parts’ array provides the same, but with each meta tag exploded into its parts. See http://wpsso.com/codex/plugins/wpsso/notes/modules/wordpress-rest-api-v2/ for an example post REST API response.

      js.

    • Florian Girardey 5:43 pm on August 25, 2015 Permalink | Log in to Reply

      I have built a little Backbone application with the WP REST API v1.
      An iOS and Android app is currently in development.
      They only use my own custom endpoints, so i’m about to try a v1 to v2 update.

      My question is : When the WP REST API will meet the core (maybe in the 4.4?) if my apps are still running on WP REST API v1, did the update will broke my apps ?

      Maybe a way to make the feature plugin take over the core in the first place would be great.

    • Justin Sainton 5:51 pm on August 25, 2015 Permalink | Log in to Reply

      We’re working on v2 integration for WP eCommerce – https://github.com/wp-e-commerce/WP-e-Commerce/tree/feature/rest-api. Basically just barely stubbed out right now, but I’m hoping to be able to devote a few weeks to it next month. Should have a lot more to report back at that point.

    • Adam Silverstein 6:50 pm on August 25, 2015 Permalink | Log in to Reply

      I built a very simple demo Backbone app on top of the v1 api, then updated it to use v2.

      Main pain points were lack of documentation (at the time) and changes in the api between versions.

      https://github.com/adamsilverstein/backbone-demo

    • J.D. Grimes 7:04 pm on August 25, 2015 Permalink | Log in to Reply

      I played around with v1 a while back, but I have yet to build anything with v2. I’m one of those people in your 4th category: I believe in the project and want to see it in core, but I haven’t built anything with it yet. So I’ll try to explain why. It isn’t because I don’t want to, or that I’m waiting for the API to mature. It is because I don’t have time to build something that people can’t use. If the API was in core, I would be building something with it right now. Yes, literally. I’m building a feature in a plugin right now that could use it, but I’m using wp_ajax_* instead, because that is the API that core offers. From the perspective of a plugin developer wanting to extend the API and add their own endpoints, the REST API is a developer feature. And I’m not going to ask users to install a developer tool just so they can use my completely unrelated plugin—even if that tool is itself a plugin. I really don’t think usage of the API by plugins will ever take off unless it is in core. Not because it isn’t nice to use, but because it currently requires duplication of work, and folks just can’t do that. I think that is the biggest pain-point for a lot of people :).

    • martijnn94 7:08 pm on August 25, 2015 Permalink | Log in to Reply

      Working an a vacancy site at the moment on V2, already so satified compared to projects I made with V1. Especially the easy way to manipulate and add data to the response which wasnt easaly possible in V1.

      Had to hack V1 basicly to make it possible to create a multiple tax query with soring on distance based on coordinates. Way easier in V2!

      Using Angular for both of the projects!

    • Mike Nelson 8:20 pm on August 25, 2015 Permalink | Log in to Reply

      We extended the REST API to serve Event Espresso data (lots of it in custom tables) using v1. We looked into v2 but figured we’d stick with whatever’s considered “stable”.
      We built a few code samples to show how to use our integration. One of them is a calendar that shows Event Espresso events and fetches the data from a separate server. Initially, however, we had cross-site scripting issues because it didn’t want to send an ajax request to a different domain (because the demo calendar was hosted on a separate server than where the Event Espresso data was contained), and so we needed to activate the CORS REST API addon which currently only works with v1 (and it’s not even considered stable for v1).
      I would think that it would be a fairly frequent occurence that siteA wants to fetch REST API data from siteB over javascript, no?
      So I guess this is mostly a vote for adding CORS support to v2. Maybe just in an addon for now, but I wouldn’t object to it being added to core either.

    • borekb 9:53 pm on August 25, 2015 Permalink | Log in to Reply

      The admin screens of VersionPress 2.0 are being built in JavaScript / React, talking to the backend using WP REST API v2. http://versionpress.net/

    • Lester Chan 2:07 am on August 26, 2015 Permalink | Log in to Reply

      I am using v1, but since v2 is not backward compatible, I will guess I have to wait.

    • Rouven Hurling 5:48 am on August 26, 2015 Permalink | Log in to Reply

      I’m using v1 in a custom backend.
      I did a trial update to v2 just before the last beta got out (which broke some of my changes).
      For me the update was pretty easy, once I figured out which functions I needed to use, which took a while and some questions in the slack channel, because some of them weren’t in the docs (new register_post_type args for example).

    • brad989 5:53 am on August 26, 2015 Permalink | Log in to Reply

      I’m using v2 in an AngularJS powered theme. http://demo.redeyetheme.com

    • kokarn 9:24 am on August 26, 2015 Permalink | Log in to Reply

      IKEA Sweden’s restaurant pages is built with V1.

      http://www.ikea.com/ms/sv_SE/restaurang/index.html

    • NateWr 3:00 pm on August 26, 2015 Permalink | Log in to Reply

      Not quite production, but getting close to release. Gonna go with the beta and hope for the best. Did not transition from v1 to v2. Outline of a couple projects I’m using it on here:

      https://make.wordpress.org/core/2015/07/23/rest-api-whos-using-this-thing/#comment-26367

      I’d also like to make use of it in some of my free plugin development. But obviously can’t touch it until it’s in core. Not going to bundle it. Seems like a maintenance nightmare.

    • Matthew Haines-Young 3:01 pm on August 26, 2015 Permalink | Log in to Reply

      We’ve just launced a new website for the digital product studio Ustwo ustwo.com. Built on V2.

      The front facing site is built in React and runs on a Node server totally separate from the WP install used to manage all the content.

      As well as using the standard endpoints, we have written quite a few custom ones too, and V2 of the API made this really easy to do.

    • Jake Spurlock 4:30 pm on August 26, 2015 Permalink | Log in to Reply

      In addition the data sync we built, we also use the JSON API for the WIRED liveblog, using React for rendering. Example here: http://www.wired.com/2015/06/apple-wwdc-liveblog/

    • Tanner Moushey 5:58 pm on August 26, 2015 Permalink | Log in to Reply

      I’m using V2 for the StudyChurch study builder along with Backbone js. You can see it in action here

    • Dave Navarro, Jr. 5:58 pm on August 26, 2015 Permalink | Log in to Reply

      I am using v1 to share posts between multiple web sites. I’ve been porting it to v2, but it’s been difficult as there are significant differences.

      I’ve also not been able to get v2 to let me access user data, which is causing delays on a project for syncing users between multiple sites.

  • Scott Taylor 3:58 pm on August 19, 2015 Permalink |
    Tags:   

    WordPress 4.4: What’s on your wishlist? 

    4.4 has unofficially kicked off, now that 4.3 is out the door. As with any release, we want to garden Trac, squash bugs, add new tools for dev, and wow our users.

    I have spoken to many of my fellow core contributors about their own wish lists. Now, it’s your turn:

    • What do you want to see happen in 4.4?
    • What are pain points for users?
    • What features can we add or iterate upon to empower our user base?

    It can be anything: big or small.

    As most of you know, I am leading WordPress 4.4

    If we’ve never met, hello! You can learn a lot about me here:

     

     
    • Justin Sainton 4:04 pm on August 19, 2015 Permalink | Log in to Reply

      Biggest hope for me is that we’ll see the REST API actually land in core. Anything that can be done to that end, I think, would be the biggest win for 4.4.

      Sidenote: SUPER excited for you leading this release. It’s going to be epic :)

    • Nicolas Juen 4:05 pm on August 19, 2015 Permalink | Log in to Reply

      Infinite child themes, handled by a Walker or something like this.
      Metadata API functionnal and usable. On terms too.

    • pro99 4:06 pm on August 19, 2015 Permalink | Log in to Reply

      Two factor auth built into WordPress or JetPack,using a standard code generator e.g. Google Authenticator, would be great.

      • George Stephanis 4:13 pm on August 19, 2015 Permalink | Log in to Reply

        Howdy! We’ve got a group working on that as a feature plugin for core right now!

        https://github.com/georgestephanis/two-factor

      • Monika 4:24 pm on August 19, 2015 Permalink | Log in to Reply

        I never use a third party two factor auth built. Neither jetpack ( at austria we are not allowed to use this plugin due our private protect law) nor Google…

        • George Stephanis 4:26 pm on August 19, 2015 Permalink | Log in to Reply

          Google Authenticator is actually just an implementation of the RFC 6238 TOTP Standard — https://tools.ietf.org/html/rfc6238 — anything that uses Google Authenticator can use other code generators just as easily, such as Authy.

        • Bego Mario Garde 7:19 am on August 20, 2015 Permalink | Log in to Reply

          @Monika “at austria we are not allowed to use this plugin due our private protect law…” – As far as I know, you can still use Jetpack in developer mode (i.e. with direct access to w.com disabled) though?
          I also doubt that two factor authentication for a user login would affect privacy protection for website visitors.

          • Monika 7:50 am on August 20, 2015 Permalink | Log in to Reply

            yes, we can use Jetpack in developer mode, but user “john doe” doesn’t know how and why :-). So it is better to say: don’t use it. It is really expensive if someone is taking you to the court!

            • atomicjack 2:48 pm on August 20, 2015 Permalink

              Privacy laws don’t restrict the use of two-factor authentication.

              They just provide an alternate, more secure method of authenticating a user – they do not transmit any personally identifiable information, at most, a username and token.

    • nicholas_io 4:08 pm on August 19, 2015 Permalink | Log in to Reply

      Congrats Scott.

      If possible, I would love to see Fieds API into core on 4.4.

    • kraftner 4:11 pm on August 19, 2015 Permalink | Log in to Reply

    • electricbrick 4:12 pm on August 19, 2015 Permalink | Log in to Reply

      Fixing the media attachments export bug would be HUGE. It’s been an open bug in Trac for 4 years. 4 YEARS.

      https://core.trac.wordpress.org/ticket/17379

    • dpegasusm 4:15 pm on August 19, 2015 Permalink | Log in to Reply

      Would be awesome to finally see a way to sort media when uploading. There has been discussion of it and a highly rated idea here:

      https://wordpress.org/ideas/topic/how-about-ability-to-sort-media-by-saving-them-into-folders-when-uploading

      • Mel Choyce 4:18 pm on August 19, 2015 Permalink | Log in to Reply

        What if you could tag media? Same kind of concept, but a bit more flexible since you could put media into multiple groups.

        • Andy Mercer 4:23 pm on August 19, 2015 Permalink | Log in to Reply

          Tagging and then creating pseudo-folders via the tags would be ideal, as long as there was an easy way to sort, graphically, with drag and drop simulating “moving”, though really just changing tags.

          • trailness 9:45 pm on August 19, 2015 Permalink | Log in to Reply

            +1. We have thousands of uploads and it’s hard to even sort through and remove old items that should have died years ago. Tagging would help immensely.

        • rkoller 4:45 pm on August 19, 2015 Permalink | Log in to Reply

          That would be useful!

        • Dave Navarro, Jr. 5:11 pm on August 19, 2015 Permalink | Log in to Reply

          +1 to this, I am using a third-party plugin now to add a custom taxonomy to media uploads. With over 300 users posting stories and uploading media on a weekly basis, this is critical to media management.

        • Helen Hou-Sandi 5:17 pm on August 19, 2015 Permalink | Log in to Reply

          “Media library filtering” is written on my whiteboard behind me. I’d love for searching to do better matching – we’ve tried and it has a ton of gotchas, but it would be worth trying again early in a cycle.

        • dpegasusm 5:59 pm on August 19, 2015 Permalink | Log in to Reply

          Tagging would help the items and seeing that media is just a post type shouldn’t be that difficult to implement. Could this be turned into a feature plugin item? i would love to help on it.

        • fatpat76 6:37 pm on August 20, 2015 Permalink | Log in to Reply

          +1

      • kkalvaa 7:02 am on August 20, 2015 Permalink | Log in to Reply

        Folders sounds like a good idea until you have a system with hundreds of badly named folders with a less and less consistent system. The flat system media system of WordPress is a lot better than folder based media.

        A tag based system to help filter would however be quite good.

      • Christian Ruggeberg 8:04 am on August 20, 2015 Permalink | Log in to Reply

        +1 Any kind of a better media handling / overview / management is almost one of the greatest wish from the users i support!

      • Alvaro Gois dos Santos 11:25 am on August 21, 2015 Permalink | Log in to Reply

        +1

      • Michaela 7:14 am on August 24, 2015 Permalink | Log in to Reply

        This would also be one of my favorite wishes to WP 4.4: Having the possibility to sort Media Uploads in different folders, tagging Media and Rename Files after Upload.

    • Hapiuc Robert 4:18 pm on August 19, 2015 Permalink | Log in to Reply

      Big news i see, one UX issue i have discovered today with a client was sortable terms. I think it will be great to have sortable terms in the new WordPress version.

      Also better mobile detection for mobile devices will be great.

    • Josh Levinson 4:19 pm on August 19, 2015 Permalink | Log in to Reply

      Term Meta would be great!

    • Seth Rubenstein 4:20 pm on August 19, 2015 Permalink | Log in to Reply

      Shortcake completion and in core is the biggest thing we should focus on in 4.4.

    • jadpm 4:20 pm on August 19, 2015 Permalink | Log in to Reply

    • PeterRKnight 4:25 pm on August 19, 2015 Permalink | Log in to Reply

      • Rest API
      • term meta
    • Eric Binnion 4:26 pm on August 19, 2015 Permalink | Log in to Reply

      Under the hood, it would be nice if we could factor out some of the logic that handles new users and invites in `wp-admin/user-new.php`. This would make it a bit easier for us to create endpoints for that functionality. I’m glad to help with that.

      On a related note, I have a ticket in that adds an action for when a user is invited. https://core.trac.wordpress.org/ticket/33008. This would be of use to us on WordPress.com so that we could send notifications.

    • Spacedmonkey 4:27 pm on August 19, 2015 Permalink | Log in to Reply

      My wish list is very developer

      • Shortcake
      • Term meta
      • Rest API
      • Post statuses
      • shawfactor 1:15 pm on August 20, 2015 Permalink | Log in to Reply

        Term meta is not required. Once you add meta to a term you might as well have a post. WordPress would be better served by adding the ability to create relationships between posts.

    • thomaswm 4:28 pm on August 19, 2015 Permalink | Log in to Reply

      No more mixed content when accessing a WordPress website via HTTPS. The scheme of the src-URLs of embedded images should adapt automatically to the scheme of the page URL.

    • WP Sites - Brad Dalton 4:35 pm on August 19, 2015 Permalink | Log in to Reply

    • Schwarttzy 4:35 pm on August 19, 2015 Permalink | Log in to Reply

      Sanatize function for choice in customizer

    • Shapeshifter 3 4:35 pm on August 19, 2015 Permalink | Log in to Reply

      Complete the integration of the RICG Responsive Images Plugin into the core AND possibly increase the current number of standard Media Size options available to match breakpoints. See this to see what I’m talking about:
      https://wordpress.org/support/topic/the-future-use-of-breakpoints-in-this-plugin-and-wordpress?replies=1
      (and I might be wrong).

      My thought is make WordPress core fully Mobile First responsive regardless of any theme used.

      • rkoller 4:40 pm on August 19, 2015 Permalink | Log in to Reply

        i’ve suggested an improved way to handle breakpoints for the RICG responsive images plugin a while back. it got closed due to the scope for the plugin but i still think it would be an useful addition and possibly relating to the things you’ve suggested and wanted:
        https://github.com/ResponsiveImagesCG/wp-tevko-responsive-images/issues/45

        • Shapeshifter 3 4:59 pm on August 19, 2015 Permalink | Log in to Reply

          rkoller,

          Really good thought process on your end (much more orderly than mine)!

          Maybe the plugin needs to remain separate, but the core developers might be able to revisit the Image Sizes Media Settings and rethink their usage.

          Maybe in the back of my head, I was thinking that the core could have a wide-spectrum standard set of breakpoints automatically preset for theme developers and end users similar to Google is doing.

          • rkoller 5:07 pm on August 19, 2015 Permalink | Log in to Reply

            Yep ithings should be kept separate between the actual plugin functionality and the handling of image size creation and so on imho. but i wouldnt clutter the interface with too many automatical presets. that would just raise confusion. i would rather stick more or less to my suggested approach. it is unobstrusive. as default wordpress behaves more or less the same like today but with the suggestions from the issue the flexibility could be leveraged tremendously as well as the number of megabytes saved on the server raised significantly.

      • Scott Taylor 12:49 pm on August 25, 2015 Permalink | Log in to Reply

        Responsive Images are on my mind for 4.4

    • pingram3541 4:42 pm on August 19, 2015 Permalink | Log in to Reply

      shortcake/shortcode – ability to nest same name shortcode, would be great for columns/containers. There is a light weight regex hack floating around on stackexchange somewhere

      Plugin hook for page/post template, let plugins get in on the design regardless of theme

      Term meta

      Rest API

    • Scott Kingsley Clark 4:44 pm on August 19, 2015 Permalink | Log in to Reply

      • Rest API
      • Term meta
      • Fields API :)
      • Shortcake
    • schlimpf 4:44 pm on August 19, 2015 Permalink | Log in to Reply

      Native multi-domain support for network installations.

      This feature is missing way too long now.

    • Ryan Kanner 4:48 pm on August 19, 2015 Permalink | Log in to Reply

      • Rest API
      • Term Meta
    • tharsheblows 4:51 pm on August 19, 2015 Permalink | Log in to Reply

      Scaling Users on single installs as well as multisite.

    • andreasnrb 4:53 pm on August 19, 2015 Permalink | Log in to Reply

      Custom comment types #12668

      • dshanske 6:34 pm on August 19, 2015 Permalink | Log in to Reply

        I will give a +1 on this. Better functionality around comment types would be great.

        • Setzfehler 3:05 pm on August 25, 2015 Permalink | Log in to Reply

          Yes, and by the way a possibility to decide what to show in recent comments widget: only personal comments without track- and pingbacks, or all comments including track- and pingbacks!

    • Brent Jett 4:56 pm on August 19, 2015 Permalink | Log in to Reply

      It’d be great if Customizer had some notion of “Saved sessions” or settings presets where you could preview multiple configurations, select a favorite, or save groups of settings to come back to later. Also themes might offer various configurations or looks this way. And also:

      • Shortcake
      • Rest API
      • Customizer Partial Refresh API
      • Customizer Repeater/Collection Control
      • Nav Menu Item Metadata (and nav menu admin hooks for fields)
    • Doug Wollison 5:02 pm on August 19, 2015 Permalink | Log in to Reply

      I’d like to see some further improvements to the media manager, such as adding a media taxonomy out of the box for organizing; integrated into core rather than still reliant on plugins.

      Also, I think the Settings API, specifically options.php, should be adjusted to allow for settings saved from certain pages to not require the manage_options capability. I like using the API for easily building admin pages with settings fields, but it’s annoying how even though I can set a capability requirement for getting to the page, I can’t set one for actually saving the options manageable on that page. Maybe also add a version for more easily registering custom meta fields on users.

      I’d also like to see term meta would be awesome, along with an order manager UI for pages and other hierarchical post types, and filtering said post types by parent.

      Oh, I can’t recall, but do post revisions include meta data? That would be good to have if not already.

    • Jonathan Desrosiers 5:10 pm on August 19, 2015 Permalink | Log in to Reply

      Adding WP_Tax_Query support to WP_User_Query: https://core.trac.wordpress.org/ticket/31383

      Progress towards term meta (https://core.trac.wordpress.org/ticket/10142) would be nice too!

    • rkoller 5:12 pm on August 19, 2015 Permalink | Log in to Reply

      A complete Multilingual API. So far only interface microcopy is localizable but it would be nice if it could be extended to the content as well that there isnt a need for a plugin to do the heavy lifting. WordPress should be able to do that out of the box.

    • Nick Halsey 5:15 pm on August 19, 2015 Permalink | Log in to Reply

      All three current components in the Customizer UI Experiments should be ready for merge in 4.3; most notably, device preview toggles: https://wordpress.org/plugins/customizer-ui-experiments/.

      Let’s finish revamping the toolbar – #32678 / https://github.com/helenhousandi/wp-toolbar-experiments. We have a working patch that could use a refresh and a mostly functional version in plugin form, along with extensive discussion and iteration via design mockups.

      I’d love to get theme installation into the Customizer, but will have time. Might be able to do at least the development if @folletto and others work on refining our initial concept design.

      • Davide 'Folletto' Casali 5:17 pm on August 19, 2015 Permalink | Log in to Reply

        Sure thing. You’re thinking of the full screen sliding thing, or an initial “installation” step in the current iteration? :)

        • Nick Halsey 9:36 pm on August 19, 2015 Permalink | Log in to Reply

          Probably the full screen version. Maybe keep the existing UI and add add new buttons that open the full-screen browser, which would largely mimic the existing tabbed theme-install experience but with the addition of an installed tab. Theme installs/downloads would happen inline like shiny plugin updated do.

      • nikeo 7:02 am on August 21, 2015 Permalink | Log in to Reply

        Yep agree, +1 for theme install in the customizer.

    • Lara Littlefield 5:19 pm on August 19, 2015 Permalink | Log in to Reply

      REST API in core! 🎉

    • Tracy Levesque 5:19 pm on August 19, 2015 Permalink | Log in to Reply

    • joncampbell 5:28 pm on August 19, 2015 Permalink | Log in to Reply

      Lets implement this multipart mail fix: https://core.trac.wordpress.org/ticket/15448

    • Ricky Lee Whittemore 5:29 pm on August 19, 2015 Permalink | Log in to Reply

      REST API
      Term Meta
      Posts 2 Posts
      Shortcake
      CMB2-like Metabox Registration
      Radio Button Taxonomies – https://core.trac.wordpress.org/ticket/14877

    • Travis Smith 5:29 pm on August 19, 2015 Permalink | Log in to Reply

      I would like to see:

      • Term meta
      • Rest API
      • Post statuses
    • Roy Tanck 5:35 pm on August 19, 2015 Permalink | Log in to Reply

      I mostly work with multisite and corporate clients, and I’d love a “WP_Query_Network” class that mimics WP_Query, but queries the whole network’s content (by default, it’d obviously need “include_sites” en “exclude_sites” parameters). I realize this would be a very ambitious undertaking, and one which doesn’t suit a well-known multisite implementation, but this would really help multisite installs where blogs are used to separate departments or projects but content needs to be aggregated.

      • Jeremy Felt 5:46 pm on August 19, 2015 Permalink | Log in to Reply

        We can start with `WP_Network_Query` first. 😉 https://core.trac.wordpress.org/ticket/32504

        Querying an entire network’s content is definitely ambitious. I think it would be interesting to see some various approaches as featured plugins. Because of the varying sizes of networks, having a core solution would be tough. One preferred way now would be to mirror content in something like Elasticsearch that is better at handling these types of queries.

        • Roy Tanck 7:12 am on August 20, 2015 Permalink | Log in to Reply

          Yeah, we’d need some very clear naming ;). I remember reading that ticket and being disappointed that it didn’t do what I had in mind :).

          Ambitious, yes. But imho it’s _the_ feature still missing in multisite. Elastic (or GSA, etc) is fine for search, but I’d like to be able to display the ten most recent posts across a network using just core components.

          Feature plugin material for sure.

      • nicholas_io 5:50 pm on August 19, 2015 Permalink | Log in to Reply

        Take a look at this plugin that I wrote: https://wordpress.org/plugins/wp-central-posts-network/

        It`s not a WP_Query_Network but it alows you to select posts from any site within the network.

      • Piet Bos 6:49 am on August 22, 2015 Permalink | Log in to Reply

        +1 that would be super useful indeed!

    • francesdath 5:38 pm on August 19, 2015 Permalink | Log in to Reply

      Proper multilingual without a plugin. I’ve used/tried most of the plugins and at best all of the implementations feel (or are) somewhat sktetchy and non-WordPress
      Better HTTPS (@thomaswm)
      Improved media manager (sorting when uploading, etc @dpegasusm)
      Rest API
      Shortcake

    • Stagger Lee 5:40 pm on August 19, 2015 Permalink | Log in to Reply

      Would like to see improvements in these areas:

      • User profile screen.

      To be make as post edit screen. Means we could add custom metaboxes, collapse metaboxes, use featured image in profiles (avatar ?), rearange drag and drop sections (metaboxes) in profile screen. Anyway WordPress would benefit tremendously if profiles worked similar way as post/pages.

      • User/Role dependent TinyMce settings. (as Drupal has long time ago)
      • Visual Editor in comments, maybe optional as one checkbox in settings.
      • Post/Page/Settings/etc.. Save and Close button. Saving close edit screen and redirect to the list.
      • Easy to adapt Dashboard.
      • Random Math captcha in the core for registration, login, comments. Forms can follow and use core code.
      • Default featured image fallback.
      • Put basic robots.txt in root.
      • Put Interconnect script for converting URLs in core folder, or implemented in settings. Dont know how other people do but I am using it 100%, on all websites. If this doesnt qualify as candidat for core, I dont know what would.
      • Number of revisions and Autosave interval as settings in backend.
      • Backend left sidebar auto adapting to longer menu item names, adapting middle area too.
      • One or two metaboxes of beer and collapsible so kids cannot see them. :)
    • rahulnever2far 5:40 pm on August 19, 2015 Permalink | Log in to Reply

      • Shortcake
      • RICG Responsive Images Plugin
      • Fields API
      • Term meta

      :)

    • codeinwp 5:44 pm on August 19, 2015 Permalink | Log in to Reply

      I would love to see some love here : https://core.trac.wordpress.org/ticket/19627 :)

    • Abcmoteur 5:45 pm on August 19, 2015 Permalink | Log in to Reply

      A better modern comment system. Ajax and vote buttons. Thanks!

      Note : here we doesn’t have to reload page to see new comments. 😉

    • dziudek 5:49 pm on August 19, 2015 Permalink | Log in to Reply

      I think that better plugin security management is very important in a world where WordPress is engine for 1/4 of the Internet: https://core.trac.wordpress.org/ticket/33374

    • Dave Navarro, Jr. 5:51 pm on August 19, 2015 Permalink | Log in to Reply

      +1 Shortcake
      +9 REST API (appreciate all the hard work they are doing, but it’s been dragging on too long)
      +1 Nav Menu Admin update
      +1 Taxonomy for the Media Library

      I’d also love to see a hook fired when WP is about to to update so that existing backup plugins can automatically backup first. Also, WordPress should, at bare minimum, backup/export the DB before any update on its own if a backup plugin is not installed. I think it’s criminal that it doesn’t do this already. Optimally, WordPress should have an internal backup/roll-back functionality.

      Responsive design is nice, but many (if not most) sites need “mobile” support. I’d love to see better mobile detection built into core. I use a plugin called “mobble” to do that now.

      I would LOVE to see a standard UI toolkit (based on jQuery UI) in core for building metaboxes, option pages, widgets and more. A ton of bloat I see in themes and plugins are people using massive UI toolkits or rolling their own. A standard API for UI in core would increase performance and cut down on the bloat.

    • Jeremy Ward 6:13 pm on August 19, 2015 Permalink | Log in to Reply

      +1s for REST API and Fields API.

      Not necessarily user-facing, but I would love to see (and be involved with) some sort of internal code quality evaluation/updates (e.g., refactoring class files as described here: https://core.trac.wordpress.org/ticket/33413, but also ensuring core files follow, at a minimum, WordPress’s own coding standards, as there are certainly places in the codebase that can and should be simplified).

    • Brent Jett 6:22 pm on August 19, 2015 Permalink | Log in to Reply

      It’d also be great to see the awesome work done on Shortcake UI combined with the WP_Widget class into one structure so that WordPress has one interchangeable component format with a unified way to declare input fields.

    • Brian Krogsgard 6:32 pm on August 19, 2015 Permalink | Log in to Reply

      In terms of a user facing feature, I’d like to renew the 4.2 effort for new user onboarding, starting with the “Welcome to WordPress!” metabox. It got some traction with a “Flow” team, and those results are on Make Flow. But I’d love to see that get kickstarted again and offer a better onboarding experience in 4.4.

      • Hugh Lashbrooke 8:04 am on August 21, 2015 Permalink | Log in to Reply

        Definitely agree here. The onboarding copy could do with some improvements along with the whole NUX. Very excited about where the Flow team can take things in that regard.

    • Frank Bueltge 6:34 pm on August 19, 2015 Permalink | Log in to Reply

      My wishlist is short, but old.

      • relationship between posts, taxonomy,…
      • multisite topics, clean api like single install, as example the settings api
    • Brian Krogsgard 6:37 pm on August 19, 2015 Permalink | Log in to Reply

      At the risk of being an unpopular opinion, I would actually not say the REST API should go into version 4.4.

      I personally think that the REST API should be a two-step process. I think it’d be great for the Core team to give a stamp of approval in 4.4, and perhaps lay some groundwork if the team needs certain things in core for the API to achieve certain things. But most of all, it needs that final “yes, this will be in core” sooner than later. I’d like to see that this release cycle.

      Then, I’d actually propose that the merge itself is given a full additional release and see it go into WordPress 4.5. That gives this extremely important feature two releases to be worked on and ironed out and tested. The first release would also allow more developers to see that it is indeed meant for core and give them the encouragement needed to put it into production with confidence.

      • Dave Navarro, Jr. 7:01 pm on August 19, 2015 Permalink | Log in to Reply

        The problem I see with that is that it’s LONG OVERDUE and needed by so many. Sure, sure, we can install the beta plugin on any sites where we HAVE TO HAVE IT (like we are now), but it “scares” people who don’t understand what’s going on.

        NOTHING is perfect and stuff gets already into core that doesn’t work out the gate, so lets get it in core already.

      • Josh Pollock 7:15 pm on August 19, 2015 Permalink | Log in to Reply

        What part of the API do you think shouldn’t be in core right away? Are you suggesting infrastructure, but not default routes go in? Seems like that would guarantee low adoption.

      • NateWr 9:18 pm on August 19, 2015 Permalink | Log in to Reply

        If such an approach were taken (and I would rather it just go in now), it would be great to at least have the API in core but off by default. Then plugins and other products that wished to make use of it could do so. Until it’s in core, the “confidence” and “real-world use” everyone keeps clamouring on about will not materialize.

    • dshanske 6:45 pm on August 19, 2015 Permalink | Log in to Reply

      #32653 Linkbacks are being defaultly disabled because of misuse and that the benefits do not outweigh the downsides. By improving the presentation, we can make it worth turning on.

    • dshanske 6:54 pm on August 19, 2015 Permalink | Log in to Reply

      I’d also like to see about #30783.

    • Josh Pollock 7:20 pm on August 19, 2015 Permalink | Log in to Reply

      Obviously REST API in core.

      Also, would love to see cancel_comment_reply_link() work when used in an AJAX call (IE when $_SERVER[‘REQUEST_URI’] is not appropriate to use for the base of the link.) This is very similar to the fix in #31333. Tickets for this are #32299 and #28314

    • Aaron Jorbin 7:37 pm on August 19, 2015 Permalink | Log in to Reply

      I would like to see a new default theme.

    • thomask 8:11 pm on August 19, 2015 Permalink | Log in to Reply

      As a developer who uses WP from version 1.2 and who has made about 500 websites on it, i miss only one thing – BUILT-IN MULTILINGUAL SUPPORT. Most of the Automatic programmers are Americans and you do not simply care about other languages, but WP is now used mostly in other languages and believe me, that this thing is really pain in the ass with wordpress. Yes, there are some plugins, that creates tons of new db tables and none of them works perfectly, they are slow, sometimes they do some mishmash after upgrades and so on. And the most functional ones are not for free.
      I have experience with other CMS, that got the main team in Europe, where every country has its own language, sometimes even two or three, and in all such systems, multilanguage support is piece of cake, just click in the admin, what languages you want, and if it would be on separate domain, subdomain or with someting after .TLD/. They do not add any extra tables or complexity, simple every translaable item in DB (posts, taxonomies, fields), got language column.
      Loooong after this i would like build in custom fields setup, but this has very nice and easy programers way, how to do it (except some easy way how to setup the field input type, its saving to db and retrieving, what is too complex), and it has two or three very good plugins, that do not add extra complexity and which use default wp tables without any hacks.
      So please – MULTILANGUAGE! Do not listen to WP discussions where there are 99 % of americans or people, who do not need more then one language – people who need more than one language are very often simple not use WP, because of this lack of languages support.

    • b-rad 8:13 pm on August 19, 2015 Permalink | Log in to Reply

      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.

      And a way to disable that new 4.3 option of formatting shortcuts.

      • Jeremy Ward 9:26 pm on August 19, 2015 Permalink | Log in to Reply

        This is a great suggestion.

      • trailness 9:52 pm on August 19, 2015 Permalink | Log in to Reply

        +1 role management
        +1 media manager

        I am tired of using klunky plugins for both tasks.

      • Justin Tadlock 10:50 pm on August 19, 2015 Permalink | Log in to Reply

        Group management of posts? That sounds pretty cool. I might sit down at the drawing board and see how that would work as a plugin. I’d love to hear more about how you think this should work.

        • ckluis 12:03 am on August 20, 2015 Permalink | Log in to Reply

          I like the way some crms/project management solutions work with this where you can click on individuals or groups to assign them to a task/page/item.

          Also being able to assign notifications on updates seems like a win in those larger installs.

      • Stefano Aglietti 9:46 am on August 20, 2015 Permalink | Log in to Reply

        +1 on groups

      • Ipstenu (Mika Epstein) 2:49 pm on August 20, 2015 Permalink | Log in to Reply

        User Management also needs granular control over roles.

        Right now all plugins that do this have to edit directly in your database, which means when (and yes, when) things get messed up, you have to reset by finding a copy of the original settings and pasting them into the DB. I do this regularly for customers. There needs to be a better way.

        In addition, we need a BLOCKED user role. For people who were members and are now blocked for being idiots. There’s no real way to do that.

        • Doug Smith 3:26 pm on August 21, 2015 Permalink | Log in to Reply

          I’d also love to see the multiple roles per user that is already under the hood brought out to the UI.

        • Justin Tadlock 10:01 pm on August 22, 2015 Permalink | Log in to Reply

          I’d love to hear more about what type of trouble you’re seeing when things get messed up. I can count the number of times on one hand when a user of my role plugin has had to do a complete reset in the past 6 years (one of those people was me during testing when I accidentally locked myself out of my own site).

          • Ipstenu (Mika Epstein) 3:05 am on August 23, 2015 Permalink | Log in to Reply

            Never once have I seen it with your plugin, Justin. Other plugins let you edit the admin role, however, and users often have no idea what on earth it means to edit that role :/ In combination with other management plugins, where they try to make multiple roles for people, like store owners and management and members, it’s easy to get it all messed up very fast.

            The normal error they make is editing the default roles instead of making their own.

            The average roles people are missing and complain about:

            • Sidekick Admin – Someone who has access to all blogs on a multisite, but not to install plugins/themes
            • Moderator – Someone who can approve or spam or pend comments and nothing more
            • Moderated – Someone who always has to have all things (comments) approved.
            • Blocked – An account that has no access, no comments or anything (for people who were trolls/broke rules)
            • Stagger Lee 4:40 pm on August 24, 2015 Permalink

              @Mika, “BLOCKED” is the same as deleted account, unless it is time based.
              Or at least same as one simple list with blocked email adresses, principle is the same as “blocked” role.

              Blocked by 24 hours, by 1 day, by 1 week, by 1 month, etc…is needed together with “blocked” role in some manageable way.
              This is specially needed for bbPress forum too.

            • Stagger Lee 4:41 pm on August 24, 2015 Permalink

              Sorry for lapsus, 12 hours, one day.

            • Ipstenu (Mika Epstein) 5:18 pm on August 24, 2015 Permalink

              @stagger-lee – No Blocked is not equivalent to deleted, though I understand why people think it is.

              Deleted means the email can be used to make a new account. Blocked means that user gets told “You have no rights to this site.”

              Time based for blocking a user would be a nice thing to add on, and a filter could help if we had a role that was ‘disabled’ or blocked or whatever.

    • Mike Schroder 8:29 pm on August 19, 2015 Permalink | Log in to Reply

      I’d love to help out/guide RICG’s review and potential merge as needed, as part of that, tackle #15311, with an added queue for background image generation.

    • Adam Silverstein 8:33 pm on August 19, 2015 Permalink | Log in to Reply

      I’m going to continue plugging away at the revisions component and my effort to get revisioning of post meta into core.

    • scalopus 8:36 pm on August 19, 2015 Permalink | Log in to Reply

      == For Plugin Developer ==

      • composer

      This is pain situation, currently composer are use widely now, but I think if the plugin gonna use it, it will become dependency hell. we have to make better approach for plugin to work with composer and dependency package.

      == For User ==

      It is painful to know which plugin still active / no longer active, it should have status of plugin in the installed plugin page, or at least suggest similar plugin if the plugin no longer active.

    • davemacd 8:52 pm on August 19, 2015 Permalink | Log in to Reply

      Meta fields for custom taxonomy terms. That’s it for me.

    • Dave Navarro, Jr. 9:02 pm on August 19, 2015 Permalink | Log in to Reply

      AJAX support for post editing. It’s just about everywhere else and it’s a PITA to wait each time you hit submit on a post or page.

      • daronspence 11:23 pm on August 19, 2015 Permalink | Log in to Reply

        You would still have to wait even if they implemented an AJAX save as they wouldn’t want to allow anything to be edited while the save is unconfirmed. Also, this would probably create a big headache for plugins that add metaboxes based on the values of what’s on the edit screen.

    • TomHarrigan 9:08 pm on August 19, 2015 Permalink | Log in to Reply

      Fields API

      Post Formats 2.0

    • Ahmad Awais 9:08 pm on August 19, 2015 Permalink | Log in to Reply

      Congrats Scott!

      About the Wish List, here you go

      — UI enhancements in Dashboard (More of a CSS refresh, more modern and subtle)
      — WP REST API
      — Fields API – It can help developers get rid of a lot of bloated frameworks, which can bring a much bigger change than expected

      That’s all for now.

    • Julio Potier 9:11 pm on August 19, 2015 Permalink | Log in to Reply

      Hey congratz!

      In 4.4 why not theming the admistration side 😀

      • J.D. Grimes 9:22 pm on August 19, 2015 Permalink | Log in to Reply

        The REST API would go beyond that and allow for the site to be administered from any custom back-end. But theming the admin could be useful too, for smaller changes.

      • Ahmad Awais 9:25 pm on August 19, 2015 Permalink | Log in to Reply

        REST API will solve that problem in pretty innovative way.

    • Dave Navarro, Jr. 9:12 pm on August 19, 2015 Permalink | Log in to Reply

      I currently use Theme My Login to keep users out of the back end of the web site, but most of that functionality should be in WordPress itself. The ability to separate Admin from Front end for most users is critical as more and more plugins don’t allow defining roles for their actions.

    • Michael Beil 9:26 pm on August 19, 2015 Permalink | Log in to Reply

      • REST API
      • RICG
      • Shortcake
    • CotswoldPhoto 9:27 pm on August 19, 2015 Permalink | Log in to Reply

      Maybe enqueue for fonts. And enqueue the assets for the login screens (the admin assets).

    • Marko Heijnen 9:28 pm on August 19, 2015 Permalink | Log in to Reply

      I would like to see this release for WordPress to stop focussing on adding new features and work on looking at fixing bugs that got added in the previous releases. Currently we are at 3910 open tickets and we need to make a plan to reduce that.

      One thing that comes to mind is fixing broken/imperfect code like the changes made in 4,3 to the Site Icon feature. Also added .ico support would be a nice feature which could have been added in 4.3.

      I know we don’t refactor code just because we can but if we would have looked more at the customizer code then the Site Icon feature would be easier to add and we wouldn’t needed to add questionable code in 4.3

    • itonstandby 9:54 pm on August 19, 2015 Permalink | Log in to Reply

      WordPress additions for 4.4 I’d like to see implemented:

      • A way to roll back major actions such as WordPress, theme, and plugin updates. Hooks that would allow custom roll backs would be a plus for developers too. At the very minimum, allow a WordPress version rollback right after an update or upgrade. Restoring a site from backup is beyond most site owners and they end up crowdsourcing or hiring the work done when a core update or upgrade breaks their site. A core rollback would be much more sensible and would further the credibility of the WordPress platform.
      • An editor for the maintenance mode display the public sees. Having to use a coming soon plugin just to display a nice looking page while the site is in development or in maintenance mode is really absurd at this point for such a robust product as WordPress
      • The ability to use one WordPress dashboard to manage multiple WordPress sites. If I own one or two WordPress sites, no big deal to login to each one to do maintenance. But if I own five, it gets laborious and confusing. Just to be clear, I’m aware of multi-site WordPress. That’s not what I’m referring to here. Standalone sites should be able to be managed by the site owner from a central location without having to use buggy plugins or high priced services – some of which are not usable on all hosts such as managed WordPress environments.
      • More security. At a minimum allow the site owner to change the login URL to something unique. This is in most security plugins and is a huge boost toward securing a site. Take a look at the popular security plugins and you’ll notice they all have a firewall. How about adding a basic firewall to WordPress core? Then if more functionality is needed let the security plugin makers add it. But a basic firewall and security footprint is essential to keeping sites from becoming so easily hacked.
      • STOP – I repeat – STOP supporting old browsers. Make it optional by the site owner, of course, but I really don’t want Firefox v4 hitting my site. Nor do I want Windows XP users using IE6. Let’s stop them at the gate and redirect to a gracefully worded “your browser is too far out of date for this site” page.
      • chriscct7 4:31 pm on August 20, 2015 Permalink | Log in to Reply

        When a core update causes a fatal error, WordPress already automatically rolls back. Plugins and themes that cause a detectable PHP fatal error are blocked from actually being committed to WordPress.org as it is.

        WordPress core doesn’t support old browsers already, and in fact if you have an old browser and login to a WordPress install, you’ll see a browse happy notice, since WordPress 3.2

        The rest of these other suggestions fall well below the “design for the majority” standard it seems

        • Ipstenu (Mika Epstein) 7:58 pm on August 20, 2015 Permalink | Log in to Reply

          To tack on here, it’s incredibly hard to detect if a plugin is ‘going to’ break your site. 35k plugins. You can try and math out the possible combinations of using them on someone’s site, but the number is (to quote a mathematician) “Very large, buy me a beer.”

          Also the real issue with broken plugins is they generally require manual effort to roll back so automating is hard.

    • Arnan de Gans 10:04 pm on August 19, 2015 Permalink | Log in to Reply

      No new features (or nothing major) but just optimisations, speed increases, efficiency things.
      This can include dashboard improvements or better widget UI. But a bunch of under-the-hood improvements to make things faster and more lightweight on for example MySQL would be fun/useful.

      Some things I’d like to see;

      • Move transients out of wp_options into their own table.
      • A more intuitive UI for widgets.
      • Faster update checking where possible (not a WP problem per-se).
      • General speed increases for the dashboard (especially on larger sites).
    • Brian Bourn 10:06 pm on August 19, 2015 Permalink | Log in to Reply

      I’m not sure if a ticket for this exists or not, but I’d like to suggest a small UX improvement to the taxonomy term edit screen. Currently when a taxonomy term is edited then saved, the user is redirected back to the main taxonomy screen with the message: “Category updated.” (or other tax name).

      This can be confusing to navigate when there are hundreds of terms and someone wants to check the changes of the recently updated term.

      I believe it would be better for most users that upon save of the taxonomy term, they stay on the same screen and the same success message “Category updated.” is shown along with a link “View category” (or other tax name) similar to when posts or pages are updated.

    • Patrick Hesselberg 10:16 pm on August 19, 2015 Permalink | Log in to Reply

    • wido 10:40 pm on August 19, 2015 Permalink | Log in to Reply

      The Shortcakes, Fields Api and Rest Api would be great.

    • Peter Wilson 10:45 pm on August 19, 2015 Permalink | Log in to Reply

      Here’s a big long list. The comments stuff is most important, the rest are nice to haves.

      COMMENTS

      • Front end comments-reply.js is obtrusive and can throw errors on slow loads/large pages.Let’s make it unobtrusive #31590 (ego ticket)
      • This would be a good first step for ajaxafying them down the trac – probably after the Rest API goes in

      JQUERY & BUILD TOOLS

      • Dev version of jQuery included for SCRIPT_DEBUG – #32358
      • Merge jQuery & jQuery migrate into one file for performance – #32793
      • Add noConflict to jQuery as part of the build process – #32831

      PERFORMANCE

      • Preconnect headers for emoji – #33210 (worth adding for google fonts if used)
      • Single CDN for all/as many as possible externally hosted assets – #31801
    • MRWweb 11:03 pm on August 19, 2015 Permalink | Log in to Reply

      Separate capabilities for manage_widgets and manage_nav_menus!

      +1 for Post Formats 2.0, grandchild themes, and Media tags

    • Felix Arntz 11:07 pm on August 19, 2015 Permalink | Log in to Reply

      Beside the REST API of course and the Fields API, I would love to see:

      Use-case for my second point: for example, if you switched your site’s domain name, all image URLs and internal links would still work without running additional search/replace scripts for the database which is probably too complicated for the average user. The required behavior could be achieved by using some kind of shortcodes instead of the full URLs in the content.

    • aidanlane 11:31 pm on August 19, 2015 Permalink | Log in to Reply

      REST API and Shortcake please.
      Then step back and watch theme and plugin developers get creative, it’s going to be amazing!

    • lpghatguy 11:31 pm on August 19, 2015 Permalink | Log in to Reply

      I’d like to see ARIA roles on things like navigation menus — it was proposed before using the wrong ARIA role (menu/menuitem) and was immediately marked invalid. It’d be nice to have role=”navigation” and role=”navitem” on items out-of-the-box.

    • menkom 11:40 pm on August 19, 2015 Permalink | Log in to Reply

      I would personally like to see greater control over permissions and custom roles, dont see how a plugin is needed for this when Drupal has this as part of core and is one of its major strengths.

    • Luis Rodrigues 11:53 pm on August 19, 2015 Permalink | Log in to Reply

      Now that the term_id vs term_taxonomy_id mess is (one hopes) about to be sorted, I think it’s high time to get term meta moving.

      Support for screens of multiple sizes and pixel densities is a pressing issue, so giving the RICG plugin a boost would great.

      There are a few rather severe performance issues in multilingual installs that could be resolved by caching MO files (there is a plugin, but the optimization really belongs in core) and using PHP’s native gettext extension (#17268).

      Finally, having the WP REST API in core would be nice, but it’s not like the plugin is going anywhere. I’m awfully excited about it, but public APIs are a serious long-term commitment, so I’d try to learn as much as possible from early adopter use in the coming months before rushing it into the core.

    • fsylum 12:47 am on August 20, 2015 Permalink | Log in to Reply

      I would love to have the post status API been properly implemented (all the quirks surround the register_post_status).

      Another vote for REST API

    • seanbennick 1:37 am on August 20, 2015 Permalink | Log in to Reply

      May be a bit ambitious, but I would love to see child theme creation with a click.

    • dmccan 1:46 am on August 20, 2015 Permalink | Log in to Reply

      A voice in the wilderness … :)

      • Some type of comment love. There is a lot of dissatisfaction and many improved ways for handling them floating around. If we focus in core on things that 95% of people use, well, this is one of those areas. Even if it is just incremental improvements.
      • Easier migration from dev to production. We tell people to develop locally but it is a pain to move a site from dev to production. This is a frequently asked question (how to) in WordPress forums on Reddit and LinkedIn. Perhaps a setting that will switch from absolute to relative URLs and then when set off will pick up the new domain name and switch back? Or, will auto-magically run the script that changes the database serialized URLs?
      • Front end editing. Let’s not wait for 1000 different premium implementations. The features plugin stalled and it would be great if it was resurrected. This is a feature that would help WordPress maintain its leadership position.
      • Personal peeve: Custom post type editor in core. Understanding how WordPress handles CPTs was the biggest WTF disconnect for me when moving from Drupal to WordPress. In Drupal there is an editor to create them and specify the fields that get output when the page is viewed.

      Thanks for asking!

    • Scott Grant 1:47 am on August 20, 2015 Permalink | Log in to Reply

      Would love to see #16979 and WP_Comment get some ❤️️. Excited for 4.4! :)

    • Nilambar Sharma 3:45 am on August 20, 2015 Permalink | Log in to Reply

      My wishlist:

      • REST API
      • Term Meta
      • Improved Customizer Performance
      • Fields API
      • Built-in Multilingual feature
      • Image (or Media) Widget
      • Template tag for breadcrumb

      Also can we please look at these tickets?
      https://core.trac.wordpress.org/ticket/32972
      https://core.trac.wordpress.org/ticket/32668

    • Junrill Galvez 4:04 am on August 20, 2015 Permalink | Log in to Reply

      Would like to see REST API integrated and is there a chance of moving wordpress to a MVC Structure?

    • szaqal21 5:11 am on August 20, 2015 Permalink | Log in to Reply

      Add hook to print extra buttons (similar to Add new) in H1 tag for post.php and post-new.php screens, now it has to be done by JS.

    • Archie22is 5:40 am on August 20, 2015 Permalink | Log in to Reply

      Hey guys,

      I think the ability to be able to hide basic Php errors would be nice. I know it’s not ideal but I think it might come in handy for a couple of users and developers out there.

      At the moment I use a plugin called: https://wordpress.org/plugins/0-errors/ – mostly for small to mid-sized projects that do not have staging environments.

    • Pascal Birchler 7:03 am on August 20, 2015 Permalink | Log in to Reply

      I’ve been working on the oEmbed feature-as-a-plugin for quite some time now and it’s working very well so far — with and without the REST API. It only needs more users (perhaps on dotcom at some point) and some bug fixes.

      So what does it do exactly? Well, it makes WordPress an oEmbed provider. If you have that plugin active, people can embed any blog post from you on their site. Just like tweets or YouTube videos.

      Of course implementation is very strict because of security. Only sandboxed iframes are allowed etc.

      I’m pretty sure this can make it into WordPress 4.4 and I’ll work hard to get things done for the merge window.

    • Florian Girardey 7:06 am on August 20, 2015 Permalink | Log in to Reply

      Hi,

      First of all, thank you for asking us :)

      • A thing that seems to me very important is to make WordPress easier to use as an independent package, giving WordPress its own directory. I heard that using Composer is impossible because of the WordPress PHP version support, okay, but maybe there is something to do at least for the WordPress directory.
      • PHP version update… I know it’s a no but seriously everyone is asking for…
      • A native way to handle environments (staging/production) ?
      • Fields API
    • Ross Wintle 9:15 am on August 20, 2015 Permalink | Log in to Reply

      As a developer I support the following (bizarrely most of what Florian said directly above):

      • PHP version update – let’s move on please!
      • Environments – I guess this is achievable using wp-config, or actual server environment variables, but how about environment-specific options? So I can have a Google Analytics ID in my live environment only?
      • Fields API

      PLUS

      • Post relationships !!! Some API for defining relationships between post types and then querying based on that. I’d love to see:

      register_post_relationship([
      ‘from’ => ‘post’,
      ‘to’ => ‘country’,
      ‘type’ => ‘many-to-one’
      ]);

      and then

      $query = new WP_Query(
      [
      ‘post_type’ => ‘posts’,
      ‘posts_per_page’ => 10,
      ‘related_to’ => [
      ‘post_type’ => ‘country’,
      ‘post_id’ => get_the_ID(),
      ]
      ]
      );

      This, for me, is the key limitation of WordPress’s data model and there isn’t really any point in having a REST API until this kind of thing exists.

      On the REST API, I don’t think it’s a good idea to have it in core at present. WordPress isn’t an application framework, and I think having REST API in core means that you will see UI fragmentation which would lead to confusion for users. Plus, at the same time as we’re considering this, the BackPress revival is thinking about splitting up WordPress into constituent parts. We need to make a call: are we de-coupling all the things? Or are we implementing as much as possible in core?

      As a user and someone who recommends WordPress to other users I’d love to see:

      • Theme and Plugins editors disabled by default
      • Built-in brute-force security (could brute-protect be in core?)
      • I love the suggestions above of a roll-back ability for updates
      • Screen-width option in the customiser, so I can view my customisations in a width of my choosing (currently, on my laptop, when the customizer is visible, most sites drop into a tablet-view)

      Err…I think that’s all. Hopefully some useful ideas there.

    • atomicjack 9:25 am on August 20, 2015 Permalink | Log in to Reply

      Here’s mine… based solely on ideas suggested by the community:

      Clean up deprecations: https://wordpress.org/ideas/topic/time-to-remove-legacy-code-to-speed-up-wordpress

      Add Cookie Notice (this is law in the EU and should be easy for new blog owners to add the notice): https://wordpress.org/ideas/topic/add-core-functions-to-comply-with-eu-cookie-law

      Make email templates themeable: https://wordpress.org/ideas/topic/implement-all-system-emails-in-html-improve-look-and-feel

      • dshanske 5:20 pm on August 20, 2015 Permalink | Log in to Reply

        Re the templates…I think the current automated emails could be better broken up into pieces to make this work better. The plugins should handle the customization, but I think core could assist with it

      • colomet 9:13 pm on August 20, 2015 Permalink | Log in to Reply

        ++++ COOKIE IS NECESARY

    • Stefano Aglietti 9:44 am on August 20, 2015 Permalink | Log in to Reply

      • Rest API
      • Starting relationship between elements (post to post etc) relationships between termes I suppose need the revision of terms table completed
      • A method to purge and generate on the fly new image size, would be nice to have a choise to generate or not all registered dimension on upload if not when we request a dimension this is generated on the fly (like using photon but locally
    • Manny Fleurmond 12:10 pm on August 20, 2015 Permalink | Log in to Reply

      REST API and by extension standardized Backbone models and collections for posts and terms. This was already done for attachments when the media modals were created but it would really be nice to have once the REST API comes into core.

    • matthewgfc 1:04 pm on August 20, 2015 Permalink | Log in to Reply

      I would certainly appreciate a purge all comments button. I can’t tell how many times clients have abandoned management of their site and I find 5,000+ comments polluting the database.

    • stickypod 1:08 pm on August 20, 2015 Permalink | Log in to Reply

      Distinct Multisite WordPress Core

      1. Allow multiple websites with unique databases
      2. Build out the stylesheets, javascripts and possibly core to be served from a central location (CDN)
      3) Design propagation updates
      4) Build central social network platform distribution (RSS)

      My proposal is different from the current multisite because it requires each site to have it’s own unique database. Why? Because each site, though under the umbrella of one company, has it’s own unique data sets.

      For example, a car dealership can have one owner, but 7 different brands. While the dealership requires the same look across all it’s websites, the work involved to build and maintain 7 different sites is overwhelming.

      If the stylesheets, javascripts and possibly the core were served from one central location (CDN) the overall look can be updated from one central admin.

      When updates are required, the updates would occur centrally, and propagate through to the multiple sites.

      Social networks would need a central admin for distribution. For example, writing articles for one car brand will not work for another, but the ability to push the articles from a central location would be vital for workflow.

    • docflo 1:18 pm on August 20, 2015 Permalink | Log in to Reply

      I’d really like to see editable archive pages for custom post types, like “Posts Page” for posts. To be set in Settings > Reading Settings.

    • Andre 1:25 pm on August 20, 2015 Permalink | Log in to Reply

      For multi-network installations I’d love to see a Network Admin role added between Super and Site admin roles.

      I’d also love to see a cleanup feature that is multi-site and multi-network aware that can cleanup leftover database entries and files from deleted plugins, sites, and networks.

    • Torsten Landsiedel 1:54 pm on August 20, 2015 Permalink | Log in to Reply

      It’s a very small thing: extending blockquote with cite tag in TinyMCE @azaozz

    • Greg Ross 2:11 pm on August 20, 2015 Permalink | Log in to Reply

      How about removing JetPack and Hello Dolly from the distro, or at least not REINSTALL them after every upgrade!

    • Jacob N. Breetvelt 2:16 pm on August 20, 2015 Permalink | Log in to Reply

      I would like to have a re-install link for plugins, like you can re-install wp.
      I do not care if the de-activation and / or activation hooks are triggered, as long as it does what it says.
      If it says ‘plugin successfully re-activated’ it should use the activation hook etc.

      If such a link exists, it would greatly simplify support on plugins.

      • Michael Beckwith 11:17 pm on August 20, 2015 Permalink | Log in to Reply

        I agree with reinstall, but I already had a ticket shot down because you can just delete and re-install that way. Sadly I don’t think that one will fly.

    • seanbennick 2:16 pm on August 20, 2015 Permalink | Log in to Reply

      1) Better handling of the Media Library
      2) An auto pagination system of some sort that allows articles to be split into multiple pages based on:

      • # of words
      • # of paragraphs
      • Percentage of article (auto breaks into X pages of fairly equal length)
    • KARTHOST 4:33 pm on August 20, 2015 Permalink | Log in to Reply

      Here are my lists:
      1) REST API (like yesterday)
      2) Switch from Full http:// to https:// in Settings and make all needed changes site wide if site is already active (note: if some one needs partial https the various plugins can handle that easily enough)
      3) Permissions of Users (Admin and Editors) to allow access to only certain Pages and Posts/Categories and custom posts.

    • Ryan Boren 4:49 pm on August 20, 2015 Permalink | Log in to Reply

      • David Lingren 7:45 pm on August 20, 2015 Permalink | Log in to Reply

        I’d like to comment on your “Retiring media-new.php” proposal.

        In addition to the browser uploader, media-new.php offers a number of hooks that allow plugin developers a way to extend its functions.

        My plugin, Media Library Assistant (https://wordpress.org/plugins/media-library-assistant/), adds a form below the drag-and-drop area on the Media/Upload New Media screen. The form allows users to set defaults for standard fields, taxonomy terms and custom fields that are applied to items as they are uploaded. It uses the ‘upload_post_params’ and ‘post-upload-ui’ hooks provided in media-new.php.

        I have not developed an alternative approach to this feature that works in the grid view or Media Manager Modal Window (MMMW). I have found it very difficult to extend grid view and MMMW, and I am concerned that a media-new.php replacement will have similar issues.

        I hope you will think through and meet the needs of plugin and theme developers in any media-new.php replacement effort. Thank you for your consideration.

      • nikeo 7:06 am on August 21, 2015 Permalink | Log in to Reply

        +1 for Support opening images in a modal

      • Paal Joachim Romdahl 8:59 pm on August 22, 2015 Permalink | Log in to Reply

        +1 on opening images in modal.
        + 1 Toolbar revamp.

    • enshrined 4:49 pm on August 20, 2015 Permalink | Log in to Reply

      I’d love to see some movement on getting SVG uploads integrated at some point.

      https://core.trac.wordpress.org/ticket/24251

    • Fabrizio Azzali 5:55 pm on August 20, 2015 Permalink | Log in to Reply

      My Wisher in order

      • Multilingual
      • Cache built in
      • Meta SEO
      • Child Theme
      • Captcha on comment
      • Gallery as a stand alone item
      • Multiple sidebar
      • SVG upload
    • schlimpf 7:11 pm on August 20, 2015 Permalink | Log in to Reply

      Regarding the Media Library:
      What I am really missing is the possibility to structure the files uploaded. It can get really messy when having many uploads. Adding folders would really help….

    • David Anderson 7:26 pm on August 20, 2015 Permalink | Log in to Reply

      Make plugin and theme uploads able to upload in chunks, so that they’re not subject to PHP’s maximum upload limit. Nobody likes to upload a plugin to find it’s “too big”, and this is the sort of “just make it work” change that belongs in core. WP’s media library already supports chunked uploading. Here’s a plugin that does this for plugins: https://wordpress.org/plugins/upload-larger-plugins/

    • _ck_ 8:01 pm on August 20, 2015 Permalink | Log in to Reply

      Please read my proposal for 4.4 as a developer:

      https://ckon.wordpress.com/save-wordpress-future/

      It could really make a huge difference for WordPress performance.

    • Stanko Metodiev 8:10 pm on August 20, 2015 Permalink | Log in to Reply

    • closemarketing 8:56 pm on August 20, 2015 Permalink | Log in to Reply

      Edit Taxonomy and Categories admin pages with the full editor, and options.

    • Maciej Krawczyk 9:01 pm on August 20, 2015 Permalink | Log in to Reply

      Prevent bricking website during upgrade when browser tab is accidentally closed.
      https://core.trac.wordpress.org/ticket/33287

    • colomet 9:05 pm on August 20, 2015 Permalink | Log in to Reply

      prevent the upgrade of plugins

    • colomet 9:09 pm on August 20, 2015 Permalink | Log in to Reply

      export categories and tags

    • colomet 9:10 pm on August 20, 2015 Permalink | Log in to Reply

      Posibility of multilingual

    • colomet 9:18 pm on August 20, 2015 Permalink | Log in to Reply

      Maybe we do not need more features, just increase the general cuality of the site (speed and bugs and scalability)

    • Ben Hansen (ubernaut) 10:46 pm on August 20, 2015 Permalink | Log in to Reply

      probably a good idea to think about sunsetting support for blip oembeds since they are shutting down today.

    • Greg Raven 11:32 pm on August 20, 2015 Permalink | Log in to Reply

      Short of hosting with WP Engine or one of the hosts at that level, optimizing WordPress for speed continues to present a lot of challenges. I would love it if there were built-in speed optimization tools that actually worked on … say … Bluehost reseller accounts, and other “generic” hosting packages. Setting up W3 Total Cache and other similar plug-ins is about as fun as being turned inside-out very slowly.

    • Hussam Al-Tayeb 11:47 pm on August 20, 2015 Permalink | Log in to Reply

      Lower memory usage when displaying posts and pages especially 404 page not found requests. WordPress is getting hungry on memory even with just akismet as enabled plugin.

    • Michael Beckwith 12:12 am on August 21, 2015 Permalink | Log in to Reply

      @ error control operator hides fatal error on mysql_fetch_object – https://core.trac.wordpress.org/ticket/21870
      Performance Increase in apply_filter() (~11%) – https://core.trac.wordpress.org/ticket/26640
      We need a way to programmatically tell if we are in a sidebar – https://core.trac.wordpress.org/ticket/16443
      do_action/apply_filters/etc. recursion on same filter kills underlying call – https://core.trac.wordpress.org/ticket/17817
      deprecate category_description() in favor of get_category_description() – https://core.trac.wordpress.org/ticket/9927
      Parse shortcodes in text widgets by default – https://core.trac.wordpress.org/ticket/10457
      Performance enhancements for esc_url() – https://core.trac.wordpress.org/ticket/22951
      Encourage people to change default tagline – https://core.trac.wordpress.org/ticket/6479
      When deleting users without any links/posts, don’t ask to whom they should be reattributed – https://core.trac.wordpress.org/ticket/6405
      Allow Plugin/Theme updates from a uploaded .zip file. – https://core.trac.wordpress.org/ticket/9757
      Implementation of %my_taxonomy% in permastructs is incomplete – https://core.trac.wordpress.org/ticket/10786
      Pages whose ancestors are not all “published” cannot be used as parents for other pages. – https://core.trac.wordpress.org/ticket/11235
      Provide easy way to return url of thumbnail image – https://core.trac.wordpress.org/ticket/11571
      Trashed items interfere with page/post slug generation – https://core.trac.wordpress.org/ticket/11863
      Make the post thumbnail size filterable for the Featured Image meta box – https://core.trac.wordpress.org/ticket/28512

    • galbaras 12:26 am on August 21, 2015 Permalink | Log in to Reply

      Hi Scott,

      Congratulations and best of luck. You’re one important man now, along with quite a bit of pressure.

      To me, the current admin bar is more of a designer bar, because it focuses on activities related to building and styling the site, but not to administering it on an ongoing basis.

      For example, the admin bar contains a link to themes, but not to plugins. On average, WordPress sites probably have 25 plugins and only 1 theme, and plugins are updated far more frequently than themes are.

      Similarly, there are links to various ways of customizing the theme (menus, background, etc), but not to users or comments.

      A radical idea would be to replicate the admin menu used “inside” WordPress to make everything accessible from the front end via the admin bar. This way, each site’s unique combination of tasks and each user’s unique role will determine what is available.

      This approach has the advantage of making plugin-specific items available without any special code in the plugins.

      Alternatively, the admin bar should be redone based on the most common administrative tasks performed across WordPress installations. I’m sure wordpress.com can provide those stats.

      Happy to discuss via https://wordpress.org/support/topic/make-admin-bar-more-useful

      Best regards,
      Gal

    • Knut Sparhell 12:32 am on August 21, 2015 Permalink | Log in to Reply

      • Add Media (image) widget
      • Dependency management for plugins and themes
      • Private/non-upgradeable plugins (not allowed on the repo)
      • Term meta, table and API
      • Multilingual minimal support for posts
      • More flexible image sizes, multi sized
      • Fields API
      • Shortcake
      • Authors allowed to edit and publish own pages, like for posts
      • Install multiple plugins in one go
      • Remove Links Manager and add the code to the plugin
      • Settings reduction
      • Default featured image, as either first embedded or picked from media library
      • Better handling of posts statuses
      • Custom comment types
      • Widgets in posts table by default, as first class content
      • Multisite: Allow site admins to add users to site
      • Multisite domain mapping
      • Plan and time set for minimal PHP bump
      • J.D. Grimes 1:14 pm on August 21, 2015 Permalink | Log in to Reply

        +1 for dependency management. It really needs several releases worth of planning and discussion though. And I think that before we can think seriously about it we need to fix a lot of other things surrounding plugins and themes. There really needs to be a plugins working group, no?

      • Brent Jett 2:12 pm on August 21, 2015 Permalink | Log in to Reply

        +1 For Batch Install Plugins, particularly from the “Favorites” tab.

      • Naser Mirzaei 7:33 am on August 23, 2015 Permalink | Log in to Reply

        +1 Custom comment types
        it seems good to add comment_type field like post_type to implement something like ratings or reviews on comments

    • swalkinshaw 2:18 am on August 21, 2015 Permalink | Log in to Reply

      My only wish is that https://core.trac.wordpress.org/ticket/24152 gets reviewed since it’s been 6-7 months.

    • Anthony Hortin 2:48 am on August 21, 2015 Permalink | Log in to Reply

      Number one choice would a Customizer redesign. Very few people like the existing Customizer, as can be verified by the amount of discussion about it over the last few of months. If you want the Customizer to become more universally accepted among developers and end users, it needs to be redesigned and made significantly wider (whether that’s by allowing it to be ‘undocked’ or just generally wider). The single column layout leads to extremely long columns which means pages and pages of scrolling, which is horrible. The Customizer should be redesigned before anything else is added to it.

      I’d also love to see the ability to make folders in the media manager. Finding images on sites that have a huge amount of media, is extremely frustrating.

    • Michael Martinez 3:33 am on August 21, 2015 Permalink | Log in to Reply

      PAIN POINT FOR USER: When editing a long post that makes extensive use of BLOCKQUOTE, switching from TEXT to VISUAL mode for any reason results in WordPress just randomly repositioning the closing BLOCKQUOTE element and destroying the spacing of the paragraphs. It takes a lot of work sometimes to clean up this mess. The problem has persisted through several iterations of WordPress.

      PAIN POINT FOR USER: Having to scroll through pages and pages of listings of comments, feedback, posts, pages, etc. because everything is blocked in groups of 20. Would LOVE to see this become a configurable parameter. Better yet, would love for Core WordPress to make these collapsible entries. I do NOT want to see infinite scrolling. I just want to be able to see a list of titles that I can click on to expand and be able to change from 20 to 50 to 100 items. I hate having to install plugins to do this.

      • Michael Martinez 3:35 am on August 21, 2015 Permalink | Log in to Reply

        PAIN POINT FOR USER: Would also like the ability to sort the spam comments by IP address. Even better, the ability to export the comments’ IP addresses as a simple list. That makes it easier to see where the spam is coming from.

      • Sergey Biryukov 2:27 am on August 27, 2015 Permalink | Log in to Reply

        Number of items per page is configurable on Screen Options tab in top right corner.

    • fabianhenzler 5:08 am on August 21, 2015 Permalink | Log in to Reply

      Oh man it’s the REST API :)
      Blazing fast and easy to extend. Getting a 1000 posts in one batch in 100ms and easy extandability of custom routes and stuff would be awesome =D

    • Torsten Landsiedel 7:53 am on August 21, 2015 Permalink | Log in to Reply

      And it would be great if someone would spend some time on this one:
      https://core.trac.wordpress.org/ticket/17268

      (using native gettext would decrease memory usage)

    • stesod 8:32 am on August 21, 2015 Permalink | Log in to Reply

      It would be nice with support for changing upper or lower case from the context menu when editing a post.

    • pixelverbieger 9:18 am on August 21, 2015 Permalink | Log in to Reply

      a) better media management (folders, tags, groups or whatever)
      b) change the standard table prefix from “wp_” to something dynamic, like “wp_4dh6Bv3_”

    • woltis 9:23 am on August 21, 2015 Permalink | Log in to Reply

      What is really necessary:

      • A real good date-picker for posts and pages

      It’s really not state of the art to select the post date and time by manual entry of the date and a month-dropdown. I often have to look up the day for e.g. next monday in my computer calender, to enter it into WordPress. A small calendar in WordPress to select a special day really should be implemented.

    • Daisuke Takahashi 10:14 am on August 21, 2015 Permalink | Log in to Reply

      Please merge “WP Multibyte Patch”!
      https://wordpress.org/plugins/wp-multibyte-patch/

      WordPress has a lot of broken points for multibyte users without this plugin!

    • Adrian Pop 10:40 am on August 21, 2015 Permalink | Log in to Reply

      My wishes for 4.4 are:

      • Multilingual from core
      • Native reordering support for pages and taxonomies (drag&drop/numbering)
      • Shortcake
      • Fields API
      • Full SVG support
      • Better media library organisation (folders/filters/tags/dynamic search) and dynamic media resizing (for raster images)
      • Better UI for Customizer with Typography and Color support
      • Stagger Lee 10:03 am on August 22, 2015 Permalink | Log in to Reply

        You reminded me about this.

        I would like to see “Plugin organizer” and “Dynamic Widgets” adapted, changed and implemented in the core. At least as featured plugins first.

        While I dont use Dynamic Widgets on most simple webistes, with simple company presentation, I do use “Plugin Organizer” plugin on ALL websites. And it works, never failed.

        For now plugin is enough, but it is just one man, one plugin, and can dissapear. Some speed up of plugin would be also nice if it is in the core.

    • kraftner 10:42 am on August 21, 2015 Permalink | Log in to Reply

      And please finally fix the broken hook system for nested calls:
      https://core.trac.wordpress.org/ticket/17817

    • rkoller 11:08 am on August 21, 2015 Permalink | Log in to Reply

      Timber (http://upstatement.com/timber/) in the core would be neat.

    • Alvaro Gois dos Santos 11:35 am on August 21, 2015 Permalink | Log in to Reply

      A simple backup procedure included in the updates screen would be great. Even if there’re several backup plugins, average user would benefit a lot from a simple backup – instead of a message telling him to backup and pointing him to WordPress.org!

      I’m aware that WordPress can’t anticipate the numerous server and site configs, therefore maybe an elaborated backup system (like some plugins and services offer), with roll-back implementation, is asking for the impossible. But at least a simple way to backup the database and revert to that saved version. I guess it’s the minimum we should expect from a 50% marketshare CMS.

    • hexified 12:49 pm on August 21, 2015 Permalink | Log in to Reply

      I’d like the ability to export my wordpress site into more formats than just XML. (PDF, DOCX, CSV, etc). PDF and DOC would especially be useful.

    • chrisedmo 1:26 pm on August 21, 2015 Permalink | Log in to Reply

      I would like to see more work on the Api – or to have it included in this release :-) And I would like to see more work done in the image editing area. WordPress is massively lacking in this area. To have something like Glide (http://glide.thephpleague.com) included would bring WordPress to the current era. this is now more important than ever, especially with retina screens and the picture element in HTML/CSS. We need easy ways to spit out different sized images and to be able to handle compression etc would be a bonus.

    • Howdy_McGee 2:18 pm on August 21, 2015 Permalink | Log in to Reply

      If `/wp-includes/canonical.php` stopped throwing errors in my debug log for unchecked indices i’d be so happy… https://core.trac.wordpress.org/ticket/32229

    • Helen Hou-Sandi 3:13 pm on August 21, 2015 Permalink | Log in to Reply

      I’d like to rethink the publishing workflow – the metabox is overbearing and there are UI-induced problems, like how “status” and “visibility” are separate even though they are the same field (still just status). It’s also removed from the flow of composing a post – since we “dock” the bottom of the editor now, I think it would make far more sense to be there, and use the split button UI from Press This. There are lot of other considerations to be made (post types without an editor, what kind of label the current “publish” metabox gets instead, what happens if we ever manage to properly have custom statuses, etc.), but that’s a rough idea to start from.

    • HoaSi 4:04 pm on August 21, 2015 Permalink | Log in to Reply

      RICG Responsive Images
      Term meta

    • thomask 4:22 pm on August 21, 2015 Permalink | Log in to Reply

      One more idea (but still the multilanguage support is the most important for me) – migrating tags to posts, if not fully in DB, than at least the tag table view and edit view, so that they would use the same edit.php table and post-new.php table (of course with some widgets missing).

      It would have huge advantages – it would be easy to add extra custom fields to the tags the same easy as for posts, it would standardise it all so it would save a lot of that extra development for two different “item types”, and if it would be really considered the same “item”, with only different fields, it would allow also “post to post” relations (e.g. typicaly “actor” for “film”, or “author” for “book”) or “taxonomy to taxonomy” relations (e.g. “country” and “popularity”.

      and another idea: one extra column for custom fields. Currently all fields are onedimensional – key+value. But if you need twodimensional field (table of values with rows and columns), it is very hard to do it and you need extra plugins.

      and third thing, that I really hate with developing anyting in wordpress – missing form field definitions. So you have to always type e.g. input type = text, value …, so there is no standardised form field, with standardised look, standardised value check, standardised saving procedure etc. It would be great if all form fields would have their function, e.g.
      form_text(name, value, array(optionals: class, id, …), that would result in input type=text …
      form_number (name, value, array) -> input type=number
      form_input (name, value, array) -> generic input (without optional type it equals to form_text)
      form_textarea (name, value, array) -> textarea
      form_select(name, value, array values, array) -> select

      It would help all developers and plugin developers standardise the look and experience for customers, and faster the development

      • J.D. Grimes 7:08 pm on August 21, 2015 Permalink | Log in to Reply

        Re: form fields: See the Fields API

        • thomask 1:00 am on August 22, 2015 Permalink | Log in to Reply

          thx, i have seen it before but forgot it :-) This seems to be far more complex ten my proposal, and this OOP way is not typical for WP, but it seems it do what i was proposing. But it should also consist of the second step – rewrite all the WP forms, so that they will use the new fields API – this would assure, that i can really do all the fields everywhere. Because from what i see with my limited knowledge it seems, that this fields api can be used only in few preselected areas, so e.g. if i want to add another select with another filter next to the other filters above the post list table, it will not help me anyhow.

    • leemon 5:30 pm on August 21, 2015 Permalink | Log in to Reply

      https://core.trac.wordpress.org/ticket/10142 – Add metadata support for taxonomy terms
      https://core.trac.wordpress.org/ticket/21734 – Completely remove global terms
      https://core.trac.wordpress.org/ticket/14310 – Make template hierarchy filterable
      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/13310 – Extend option_name to varchar(255)
      https://core.trac.wordpress.org/ticket/32101 – Ability to mark plugin as unmanaged
      https://core.trac.wordpress.org/ticket/22942 – Remove Post by Email

    • Paal Joachim Romdahl 6:12 pm on August 21, 2015 Permalink | Log in to Reply

      Here are some of my ideas.

      • Reordering of all posts and all pages similar to how menus are handled. (very important as it is very tedious how ordering of posts is today.)
      • Media library sorting, replace image with another image and a download image library content button.
      • Better plugin handling. There was a suggestion some work on this earlier but I do not know what happened to the discussion.
      • Media Widget and TinyMCE widget. A remove active widgets button. Enable and disable widgets.
      • Better content creation is sourly needed. A visual grid/table/columns for an easy way to add content.
    • Randy Douglas 6:58 pm on August 21, 2015 Permalink | Log in to Reply

      We are pushing the limits of WordPress to make it a documentation CMS. We struggle with user dissatisfaction over the editor. They are comparing to Word/dreamweaver/visual studio. Anything you can do to make the editor better w/r/t the following would help:

      1) Continue to make it even easier to drop in word or PDF content and get rid of tags and work better with the tags it does not strip.

      2) Make the editor better. It has some of the following problems:

      a) Switching between tabs cause code to change or to lose changes
      b) WordPress introduces some code bloat on it’s own
      c) List positioning doesn’t work all that well
      d) It is not as good as some other live html editors
      e) Grammar/spell checking could be better out of the box
      f) It eliminates too much code. For example, sometimes you **really** need a
      tag. But WP assumes you meant to have a space, which cause the graphics to stay on the same line as the previous text line in many cases. There should be a built in break tag that sticks. You shouldn’t have to fool it by adding a blank class to the break tag. Similarly, it should not eliminate

      . I know that sometimes this is a mistake, but most commonly it is not. It should be easy to turn off this kind of heavy-handed code bloat stripping.
      g) The visual editor should work more like dreamweaver.
      h) There should be a setting where the editor may determine whether tag stripping occurs on save draft/publish or whether it keeps the text verbatim.
      I) Switching tabs should never change the content.

      Thanks for all your work. We really like WP overall.

      • Randy Douglas 7:03 pm on August 21, 2015 Permalink | Log in to Reply

        I forgot to mention that we have tried the default editor and are using the TinyMCE Advanced editor currently. I realize that some items could be introduced by these enhancements, but overall this editor seems to function like the original with extra features. This may be the most popular plugin (seems to be what most people use), so that may be consideration when working on the default editor.

    • JenniferBourn 7:02 pm on August 21, 2015 Permalink | Log in to Reply

      Thanks for asking for feedback and suggestions! One thing I would LOVE to see, is the Preserve Editor Scroll plugin (https://wordpress.org/plugins/preserve-editor-scroll-position/) rolled into core. It would make saving and editing your work so much easier. Right now every time I save what I’m writing or editing it jumps me back to the top and I have to scroll back down to where I was … I can’t be the only one who gets frustrated by this :) I think lost of users would benefit from this.

    • Patty J. Ayers 7:31 pm on August 21, 2015 Permalink | Log in to Reply

      All I ask:
      (1) Get rid of need for Kitchen Sink button
      (2) Change “Cheatin’ Uh?” to a real error message

    • Dave Navarro, Jr. 7:57 pm on August 21, 2015 Permalink | Log in to Reply

      Bring back “sorting” when searching the repository for plugins and themes. I’d like to sort them by number of installs and filter out anything that hasn’t been updated in a while.

      Also, I know this was briefly discussed, but you PLEASE indicate which plugins are free and which are “freemium”. The only people opposed are those who sell freemium plugins.

    • dryanpress 8:44 pm on August 21, 2015 Permalink | Log in to Reply

      Built-in concatenation method with minification would be nice to have as an alternative to enqueuing registered scripts. Running lots of plugins is typically discouraged, and while there are a host of reasons… WordPress’ and lower shouldn’t look like a firing squad aimed assets at an end-user’s machine. There are a handful of plugins that do this, perhaps one of them might serve as inspiration.

      + REST API
      + FIELDS API
      + SHORTCAKE

    • Fernando Tellado 11:23 am on August 22, 2015 Permalink | Log in to Reply

      :)

       REST API
       SHORTCAKE ++++
       GET RID OF AKISMET AS DEFAULT PLUGIN
       MULTILINGUAL SUPPORT
       SEO SETTINGS
       COMMENTS SYSTEM WITH SOCIAL INTEGRATION
       LIVE EDIT

    • Nathan Shubert-Harbison 6:29 am on August 23, 2015 Permalink | Log in to Reply

      For ease of deployment and migration, no longer store the site url in the database. Drupal, for all its shortcomings, doesn’t store the url in the database and migration is easier for it. It would be great if WordPress made this move.

    • Naser Mirzaei 8:38 am on August 23, 2015 Permalink | Log in to Reply

      • JSON Rest API
      • Fields API
      • Media Tag and Category
      • Remove Akismet and Hello Dolly from plugins
      • Update core with new features, make WordPress settings totally handle with Fields API.
      • Force new plugin developers to use core features, not their own.
      • Add a warning for plugins that tested and now used in core. like favicon
      • separate more features from core and add them as official plugins. like comments, multisite.
      • enable to set password on user registration and send activation email instead of password email
      • built-in minify and combine for html, css,js
      • Ability to add template for admin pages in theme
      • User Groups
      • More Ajax in admin
      • Email Templates

      Some of features that i and others requested should not be built-in, but its better to tag some plugins as official by WordPress development team

    • trickywinger 11:15 am on August 23, 2015 Permalink | Log in to Reply

      I’d truly love to see an easier way to change headers i.e. inserting sliders without having to change code. I can’t believe given so much is made of drag and drop, ease of use, anyone can do it blah blah blah… its not here already frankly. Sorry to whinge its just a major gripe, particularly if you’re not a WP expert. Simply stops me loving this software :)

      • trickywinger 11:32 am on August 23, 2015 Permalink | Log in to Reply

        Sorry Scott, just read my post and it really is grumpy… apologies mate. I do truly want to love WordPress, but I just can’t – yet. It simply doesn’t do what it claims – yet – unless you understand and more importantly keep up with the technology. I’ve read many of the posts on here and though they are pretty much all valid, they just read as if they are from people that love WP or the internet or computers etc. I haven’t seen a single ‘plain English’ comment. And in no way do I mean that as an insult guys, its just if its only you clever people that are developing WP it will continue to go the ‘isn’t this a neat idea’ route and too slowly towards the truly practical website building tool for the world, which this clearly should be (and somehow probably is at the moment).

        I’m reminded of the space race story of the Americans spending millions of dollars to develop a pen that would work in zero gravity while the Soviets used a pencil. Sometimes these things can be just over thought. Anyway enough said. I do love WP despite these comments, I’d just like to love it more!

        And before you ask, I’m a business consultant, have been for many years to some of the biggest companies in the world, have worked on Apple systems since it started and PC’s with DOS before that, so I’m not a newbie. I now run a local newspaper in Southern England, look after the odd website for friends and colleagues while playing as much guitar as I can.

        Once again sorry for being so grumpy Scott and the very best of luck going forward.

        :)

      • medical-hero 7:53 am on August 26, 2015 Permalink | Log in to Reply

        I really understand that only half way, I’m sorry. If you’re not an expert user you can have hardships with WP when it comes to special tasks. It’s because the audience developed itself. At first it’s coded for really fast posting without anything special. Then it was merged with the idea of a content management system (cms). So it’s neither fish nor fowl for many people. For simple bloggers WP is oversized. For others too limited without plugins so they load a bunch of them. I do so too because I can’t code PHP but want to expend it to a fully-fledged cms like typo3 in a easy way.

        My background: My very first internet project was in the late ’90ies. Later I served small online shops with osCommerce or a portal with php-nuke. Now I want (or have) to build advanced portfolio sites without needed coding knowledge or specialised plugins – that has hardships all the time but I love WP more. It’s like a long time marriage: My wife WP jerkes dinnerware at me and I have to buy some flowers… And then come my brother-in-law WPML, my sister-in-law Toolset and her step-sister PODS with their own families for x-mas… Help me, father, I’ve sinned! 😉

    • Kent McDonald 12:01 pm on August 23, 2015 Permalink | Log in to Reply

      When placing a link that directs to an outbound URL I would like action to DEFAULT to a new tab or window so my user is not yanked from my site. Currently I have to click an option box. I prefer my users to keep my original site open and have an option to read the destination link on a separate tab.

    • Glen Charles Rowell 3:52 pm on August 23, 2015 Permalink | Log in to Reply

      Can the galley link images to custom URLs yet?

    • Glen Charles Rowell 3:55 pm on August 23, 2015 Permalink | Log in to Reply

      Smarter responsive menus with an option to change the level of responsiveness would be great.

    • Leo_Nel 8:38 pm on August 23, 2015 Permalink | Log in to Reply

      Native support for replacing media without having to use a plugin such as https://wordpress.org/support/view/plugin-reviews/enable-media-replace

    • programmin 11:55 pm on August 23, 2015 Permalink | Log in to Reply

      It may not be related to WP directly but more for hosting, but have you started considering the implications of setting up WordPress sites with HTTP3?

    • chrishoward 2:48 am on August 24, 2015 Permalink | Log in to Reply

      Filter plugin searches by WP version

    • jakkub 2:12 pm on August 24, 2015 Permalink | Log in to Reply

    • buurtaal 2:42 pm on August 24, 2015 Permalink | Log in to Reply

      A better search

    • birder 4:49 pm on August 24, 2015 Permalink | Log in to Reply

      1. An easy way by a checkmark and Cat ID posts a single category on the front page display.
      2. Additional category pages display as under (1) above for Home
      3. Category archives only with the date and title, regardless of the number of contributory display on the other pages

      . At least 1 +2 pts my wish will be possible already, but given a tinkering in php is needed, which I – frankly -‘m too stupid. But I like to bet that this is not just me geht.Und my English comes from Google Translator, so please make allowances …

    • davert318 5:59 pm on August 24, 2015 Permalink | Log in to Reply

      First… endorsements:

      Ticket 31467 Images should default to not linking
      RICG Responsive Images
      Better searches

      Second, my own requests:

      I would like performance gains!
      I would like the featured image to be automatically set if none is specified, as it is with a plugin now

      It would be nice if the featured image could be chosen from a library of external images which have already been resized and used as featured images, if that makes sense. I often use image links because WordPress is only part of my site, not a standalone. When I do this, WordPress obviously makes a smaller version but I can’t select that from the media library.

    • primaryimage 10:58 am on August 25, 2015 Permalink | Log in to Reply

      Me (& my users!) would love to have a UI for columns in the WordPress back-end. I know Shortcode UI offers potential with this (+ there’s already visual editors available). but I think there’s an opportunity to have something relatively simple that’s standardised in core. At the moment different themes all use their own shortcode conventions and, even for straightforward two column layouts, it can get quite messy on the screen!

    • Marcus 1:25 pm on August 25, 2015 Permalink | Log in to Reply

      I’m all for the idea of fixing past tickets and JSON Rest API.

      As an idea though what about a Safe Mode? I just had to deal with this today, it’s an inevitably common scenario:

      Them: Hey, my site went blank, what gives?
      Me: Sounds like a plugin or theme update screwed up your site. Please disable your plugins via FTP.
      Them: What’s FTP?

      Wouldn’t it be awesome if there was an easy way for users to go in via a safe mode and disable plugins/themes. It could come with a default skeleton theme in the event there’s no default WP theme (or it has been modded). Additionally, maybe a limited number of logins since security plugins will be disabled too.

      A plugin that has this is – https://wordpress.org/plugins/safe-mode/ – awesome idea but the crux is most people need it when they can’t actually install it!

    • Ben Huson 2:16 pm on August 25, 2015 Permalink | Log in to Reply

      Better support for taxonomy fields in Medial Modal. See #28053, #22938 relating to implementing category checkboxes in the modal and #31691

    • DenverEric 5:11 pm on August 25, 2015 Permalink | Log in to Reply

      It would be great to see more of the most popular, low weight features migrated from Jetpack into the core like was done with the site icon in 4.3.

      Ideas for inclusion:
      -Widget Visibility
      -Contact Form
      -Carousel & Tiled Galleries
      -Extra Sidebar Widgets

    • Gabriel Mariani 5:41 pm on August 25, 2015 Permalink | Log in to Reply

      I don’t get what all the excitement is over the REST API, but what I would like is the silly ability to just upload a theme/plugin an overwrite the existing just like any other update would. Instead of uninstalling and reinstalling or uploading over FTP.

    • medical-hero 6:54 pm on August 25, 2015 Permalink | Log in to Reply

      My wish list – highest priority for me have the following points:

      • Native networks with domain mapping
      • Multi-language support (I won’t use WPML forever, way too expensive over the time for personal usage)
      • Native reordering support for pages and taxonomies (drag&drop and numbering)
      • Shortcake
      • Fields API
      • Full SVG support
      • media library (folders, filters, tags, ajax search and dynamic image resizing
      • REST API
      • Term Meta
      • Posts2Posts, Post2Pages, Pages2Pages, Pages2Posts, Post2CPT, Pages2CPT, CPT2CPT and so on
      • one2one, one2many, many2many bidirectional relationships and magic tags (pods)
      • And lastly better cms like workflows for professional admin and editorial groups as core plugin

      — more complex reviews like approval of one or several persons in different roles and processing steps
      — managing ideas, tasks and assignments in several steps to the final version of articles or other post types
      — reference plugins: Oasis Workflow, Edit Flow and Contenido

    • dunkelangst 7:17 pm on August 25, 2015 Permalink | Log in to Reply

      Please delete all emojis!!

    • wolf99 1:04 pm on August 26, 2015 Permalink | Log in to Reply

      Preventing the creation of users with the same nickname as username (Or an admin option to enable this) would be a nice quick little security improvement perk :)

      (In case you didn’t know, a lot of the automated attacks recently on WP scrape posts for publishing author names and then use those as user names in brute force attempts on the password gate. Preventing user names from being the same as author names closes of this avenue quite simply, by keeping usernames “internal” to a WP install).

    • Jacob N. Breetvelt 1:38 pm on August 26, 2015 Permalink | Log in to Reply

      Two more wishes:

      • wp_delete_post( $postid ); To also delete references to the post in any menu, active or not.
      • A way to add a stacktrace, especially to wp deprecated error messages, so you can easily find which plugin / widget is outdated.
    • closemarketing 2:28 pm on August 26, 2015 Permalink | Log in to Reply

      Fully support to responsive images. Make add_image_size, support diferent sizes depending of device, or the function wp get attachment support responsive images.
      Thanks!

    • mumbomedia 6:50 am on August 27, 2015 Permalink | Log in to Reply

      Opportunity to make custom folders in the media libary.
      This would come in handy if e.g. you have a large woocommerce shop with a great amount of product images. If you could make custom folders in the media libary you could make a folder for each product allowing you to easily find images which refers to deleted products and therefore you could delete these picture absolutely sure that they’re not used anywhere else.

    • galbaras 8:27 am on August 27, 2015 Permalink | Log in to Reply

      Hey Scott,

      One more wish: at the moment, the function check_comment() excludes trackbacks from automatic approval, because there’s no author email or author IP. However, when the author URL contains the current site, this should be pretty safe to approve automatically.

      Options:

      1. Always approve trackbacks from same site
      2. Add a new discussion setting to decide whether to do this or not
      3. Add a filter to override the return value of check_comment()

      Thank you,
      Gal

    • moritz.klassen 9:48 am on August 27, 2015 Permalink | Log in to Reply

      *BETTER PREVIEW MODE*

      It would be nice to be able to set the WHOLE website into a kind of “PREVIEW MODE”. So that you can see for example how a new article would effect the startpage or listing views.
      At the moment you can just preview a new article but sometimes its really difficult to calculate all sideeffects. So you never know how your startpage looks like after publishing.

      Thanks,
      Moritz

    • Sam wc 3:08 pm on August 27, 2015 Permalink | Log in to Reply

      WordPress team not looking at Frame work such as laravel,Yii,cakephp etc.Please make it very powerful such as this frame work. Because we love wordpress never wan’t to down when compare with these frameworks .

    • Sam wc 3:09 pm on August 27, 2015 Permalink | Log in to Reply

      (1)Could you please add some more functions that assist in working with forms.

      (2)Captcha support by default

      (3)Could you please add some more permalink structure tags like %taxonomy%,%sub-taxonomy%,%sub-category% and way to arrange them

      (4) great pain is trying to make WP work with Angular.js or similar for building web apps.

    • Matthew 4:10 pm on August 27, 2015 Permalink | Log in to Reply

      Just one thing. Fix bugs.

  • Scott Taylor 8:55 pm on January 28, 2015 Permalink  

    Trac Tickets – the band’s taking requests 

    At the beginning of the past few releases or so, we’ve put a call out for community priority tickets. There are over 3000 tickets in Trac. If there’s a ticket you feel is neglected or should have light shined upon it: leave a comment here with a link so we can triage it. Help us help you.

     
  • Scott Taylor 9:54 pm on January 22, 2015 Permalink
    Tags: , ,   

    The Case for JS Modules 

    I originally posted some of this content here: Split javascript files in media into modules

    The patch on that ticket breaks up the Backbone classes in media-models.js, media-views.js, media-audiovideo.js, and media-grid.js into modules and injects them via Browserify on build/watch into a built file. Let’s start at the beginning.

    Brain overload

    Files that are 1000s of lines long are hard to consume. We try to alleviate this by adding copious amounts of docs. Still, it’s a lot to look at. Ideally, we would break our files into smaller modules and then somehow join them together in a build process.

    It is common practice to serve (sometimes very large) minified files for JS and CSS that have concatenated many smaller files together and uglify’d (minified/obfuscated) them. It is no longer common or best practice to develop with huge files. We can learn a lot from emerging front end development trends, especially those from the Node/NPM community. In some cases, we can even share code.

    We’ll use Media as the main culprit, but this could apply to any “manifest” – a term I use to describe files that contain the entire public API for a feature. Something like media-views.js, it might be nice to bounce from view to view in the same file, provided you know exactly what you are looking at, what depends on what, etc.

    I have found, it is completely overwhelming for almost everyone. It would be great if each discreet piece could be viewed in isolation with its dependencies clearly stated.

    There are many ways to accomplish the splitting of large files. I want to focus on 2 of the most common.

    Vocabulary

    Backbone is one of a growing number of MV* frameworks for JavaScript. A large majority of the code related to media either belongs to a handful of Models or to the increasingly large library of Views and View Templates.

    Views are the building blocks for the presentation of Media (you know, “the Media Modal” or 4.0’s “Media Grid”).

    The main canvas on which these Views are stitched together are called Frames, which are themselves Views – tilting our use of Backbone more towards MVP, P standing for Presenter.

    We have Controllers, which are called States, but they belong to a Frame (Presenter! also a View!), so anyways…. for now….

    When we create new UIs, we are more than likely adding new Views/Templates, or updating existing Views.

    If we wanted to move from one large file to many files that each contain a class, we would create Modules.

    Grunt is a task runner. We use Grunt to build our src directory into our build directory.

    Require

    Require is a great tool for converting AMD modules into built files. Require leans on Dependency Injection in its syntax:

    define([
        'models/taco',
        'models/burrito',
        'controllers/meal'
    ], function (Taco, Burrito, Meal) {
        var Dinner = Meal.extend({
            // taco-related code
        });
        return Dinner;
    });
    

    This syntax works great, unless you have way more dependencies. Refactoring code could unwind a module that has a lot of dependencies, but if you are just trying to convert legacy classes into a module, Require starts to get a little weird. Concrete example: Frames have a TON of dependencies.

    Require becomes a Grunt task to make one big file by recursing the dependency tree in an initial manifest. Require, by default, loads JS asynchronously, which can cause race conditions with plugins or themes that expect code to be registered on $(document).ready() or window.onload.

    Require works even if you don’t build via Grunt.

    Browserify

    Browserify is a tool that allows you to use Node-style modules and run them in a browser without changing from the Node syntax. Browserify requires a build for this to work.

    Using our example from above, this is the syntax for Browserify:

    var Taco = require( './models/taco.js' ),
        Burrito = require( './models/burrito.js' ),
        Meal = require( './controllers/meal.js' ),
        Dinner;
    
    Dinner = Meal.extend({
        // taco-related code
    });
    
    module.exports = Dinner;
    

    Browserify leans more towards the Service Locator pattern.

    Browserify scans the abstract syntax tree (AST) of your JS code to compile dependencies. Your modules themselves get wrapped in their own scope like so:

    (function (require, module, exports) { 
        .....YOUR_MODULE..... 
    })

    After spending a lot of time messing around with both: I think we should use Browserify.

    Converting “Legacy” Code

    The media JS code is some of the most “modern” code in WordPress, but it still clunkily lives in huge files. To convert the code into modules, we need to make a lot of individual files (one for each Backbone class).

    We also need to make sure we maintain the existing wp.media namespaces for backwards compatibility. We don’t want any existing functionality to change, we just want to build the files differently.

    Even though the code is defined differently, wrapped in a new scope, and looks different when “built”, we can still maintain our current API design: what is publicly accessible now will remain publicly accessible.

    In the patch

    Disclaimer: this patch is for experimentation only. It will go stale probably before this post is published. It works, but it is only a playground for now. If this moves forward, it will be a laborious Subversion process to create a bunch of new files.

    I have added a folder to wp-includes/js, media, that contains the modules and the built manifests. My patch adjusts script-loader.php to use these new paths.

    media contains the following files/folders:

    controllers/
    models/
    routers/
    utils/
    views/ (with another round of subfolders)
    audio-video.manifest.js
    grid.manifest.js
    models.manifest.js
    views.manifest.js
    

    The build pipeline

    If you are following along with that patch and want to see this in action, run in the project root:

    npm install
    

    Afterwards, run:

    grunt watch
    

    *.manifest.js files get built into *.js files when you change a file in media/*, provided you are running the grunt watch task. The watcher will automatically call browserify:media and uglify:media when those files change. This allows you to run your site from src or build, and you will still get Browserify’d files. SCRIPT_DEBUG will either run *.js or *.min.js, just like any other minified JS in core.

    This is a proposal

    I would like to hear feedback from the overall community and certainly from our fair share of JS-trained ninjas. A common reason to *not* do something like this is the barrier to entry for new developers. I would argue in this case that the code becomes MORE readable and understandable. I was shocked myself to see how much simpler it was to absorb one piece at a time once the code was laid out in modules.

     
    • deltafactory 10:07 pm on January 22, 2015 Permalink | Log in to Reply

      As someone who was trying to wrap my head around wp.media as recently as yesterday (with little success), I strongly support this from a development and maintenance perspective.

      • Primoz Cigler 6:12 pm on January 23, 2015 Permalink | Log in to Reply

        +1!

        I attempted several times to ‘load’ these enormous JS files to my brain in last few months. Every time with little to no success. As I am using RequireJS I would be more font of the later, but I absolutely agree with your foreseen troubles it would bring. So browserify + grunt it is, hurray!

    • Daniel Bachhuber 10:13 pm on January 22, 2015 Permalink | Log in to Reply

      I strongly support breaking apart our JavaScript. Browserify has become a new standard for the projects I’ve been working on.

    • Luis Rodrigues 10:22 pm on January 22, 2015 Permalink | Log in to Reply

      I for one applaud this initiative. There may be a couple of extra hoops to jump through, but they become virtually irrelevant with a properly configured Gruntfile to handle watching and building modules into the project.

      Big fan of Browserify, too. Browserify will handle AMD modules if you need them (using plugins like `deamdify`) and coexists with non-module dependencies much, much better than RequireJS. (Last time I got RequireJS and WP to work together, I had to mess with WP’s enqueue mechanism because the loader is rather sensitive to scripts that alter the DOM.)

    • K.Adam White 10:28 pm on January 22, 2015 Permalink | Log in to Reply

      Music to my ears, @wonderboymusic! Regarding the “barrier to entry” argument, in my experience the biggest barrier I’ve seen people hit while working with modules has been that in almost all circumstances, the complexity of setup and configuration required by a system like Require results in a front-loaded learning curve. Coming onto an existing project with a modular system is, by point of contrast, generally a pleasant experience because it is much more obvious where any particular piece of code lives.

      I’d throw in my $0.02 that since we’d need a build process anyway to ship production files, we should optimize for ease of development: whichever system requires the least work when adding a file. Webpack’s a good build tool that we’ve been using which supports both AMD and Node-style modules, as well.

    • Solinx 10:41 pm on January 22, 2015 Permalink | Log in to Reply

      Like K. Adam I found that working with modules does increase the initial barrier a bit for developers who rarely use javascript, but certainly not by much. And once the required code to work with modules is understood it makes things easier due to the clear structure and focussed content of each module.

      Currently we use AMD (require.js) and build our combined js file with Almond, but we’re strongly considering to switch to Browserify or Bower. AMD isn’t as widely supported by packages as we’d like, and Require.js appears to clash with our new general purpose build tool, Gulp.js.

    • Mike Schinkel 11:14 pm on January 22, 2015 Permalink | Log in to Reply

      I have nothing but support for this proposal. Great work!

    • faction23 1:09 am on January 23, 2015 Permalink | Log in to Reply

      Having the js broken up into modules will be great! Have you tested/considered your third option, the use of native es6 modules and then something like webpack with the 6to5 loader (es 6 to 5 transpiler)? es6 modules are finalized since last august – es6 was fully feature frozen then -and I’ve been working with 6to5 for a little bit and its rock solid. The main reason would be longer term viability. es6 modules are going to be here to stay guaranteed, plus they pretty well supersede common/amd modules…

    • Mike Schroder 1:41 am on January 23, 2015 Permalink | Log in to Reply

      This sounds most excellent.

      Thanks for putting this together!

    • Helen Hou-Sandi 4:06 pm on January 23, 2015 Permalink | Log in to Reply

      Really looking forward to some sanity in this area. Concerns I typically have about barrier to entry are mostly irrelevant here – components such as media already require a high level of understanding and some amount of experience, which makes familiarity with build tools as a requirement of development much more likely. As I’m understanding the proposal, build/watch won’t be needed if you don’t touch any involved JS.

    • Aaron Jorbin 8:42 pm on January 23, 2015 Permalink | Log in to Reply

      My concerns are the same as others, that this increases the barrier to entry. I think that as long as some documention get’s written for the core handbook that we can also reference and point to about how and why (with this post serving as a great foundation).

      One thing we will want to consider, if a file like wp-includes/js/media/models.js is going to be a generated file, we should exclude it from jshint.

    • Ben Doherty (Oomph, Inc) 12:42 am on January 25, 2015 Permalink | Log in to Reply

      You have my +1 in this effort. The media-* files are just too much to wrap one’s head around effectively, and in general we are in dire need of organization and better documentation for the entire Media Manager API so that developers can write better integrations. I don’t believe there will be much increase in barrier-to-entry by splitting these files up. As Helen said, developers who dig into this are likely to already be familiar with the build toolchain, but may not need even it when using the files for reference.

    • nikeo 3:04 pm on January 25, 2015 Permalink | Log in to Reply

      +1. Those types of workflows + tools have to be democratized. I don’t think there will be much increas in barrier-to-entry as well.
      Thanks!

    • lmartins 10:16 pm on January 25, 2015 Permalink | Log in to Reply

      Common JS with Browserify or similar every time. Any front-end person deals with them these days, so I imagine quite accessible to any dev.

    • Per Soderlind 11:13 am on January 28, 2015 Permalink | Log in to Reply

      + 1, understanding (your) wp.media code today is hard.

    • Andrew Ozz 6:07 pm on February 2, 2015 Permalink | Log in to Reply

      Don’t think this is going to make huge difference. Generally whether you edit few places in a single file or have to open and edit several files doesn’t make a difference. Your IDE should handle both cases transparently :) However agree that it is better to have a nice file structure that somewhat matches the JS structure.

      In my mind it is more important to improve/fix the “JS structure”, i.e. this:

      The main canvas on which these Views are stitched together are called Frames, which are themselves Views – tilting our use of Backbone more towards MVP, P standing for Presenter.

      We have Controllers, which are called States, but they belong to a Frame (Presenter! also a View!), so anyways…. for now….

      I’m hoping we will get that opportunity when implementing the image flow changes.

    • Dwain Maralack 9:25 pm on February 8, 2015 Permalink | Log in to Reply

      +1 for a more logical file structure. Most of the files here will most probably only be changed by experienced / core dev’s so the barrier to entry is not a major concern. The entry barrier can easily be solved by supporting documentation.

  • Scott Taylor 9:45 pm on October 1, 2014 Permalink
    Tags:   

    4.1: Call for Tickets 

    What tickets would you like us to look at in 4.1? (Extra points if it already has a patch.)

    Since the release is officially underway, now is a great time for us to prioritize work and make sure our pet projects/tickets get some airtime. The priorities of the community matter. Let us know below what you would like to see in WordPress 4.1.

     
  • Scott Taylor 2:07 am on August 29, 2014 Permalink
    Tags: , ,   

    A more powerful ORDER BY in WordPress 4.0 

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

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

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

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

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

    Both will produce an ORDER BY clause like:

    ORDER BY post_title DESC
    

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

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

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

    ORDER BY post_title, post_author DESC
    

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

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

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

    Enter [29027].

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

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

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

    ORDER BY post_title DESC, menu_order ASC
    

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

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

    Happy WP_Querying!

     
  • Scott Taylor 5:49 pm on June 20, 2014 Permalink
    Tags: , , , ,   

    like_escape() is Deprecated in WordPress 4.0 

    @miqrogroove has written a blog post on his personal blog explaining why like_escape() has been deprecated in WordPress 4.0. It has been reposted below.

    Plugin authors and website developers who work with WordPress database queries should notice an important change coming in WordPress 4.0.

    The function like_escape() is no longer used in WordPress core code. It is still available as a deprecated function, so it still works in any existing plugins that rely on it. However, a new and different function is available that should be used in all new code.

    Deprecated means that anyone using code that calls like_escape() with WP_DEBUG enabled will see an error message. If WP_DEBUG_LOG is also enabled, the error message will appear in the /wp-content/debug.log file.

    Let’s look at an example of core code where I removed like_escape() and implemented the new function $wpdb->esc_like().

    3.9 Old Style

    $search_orderby_s = like_escape( esc_sql( $q['s'] ) );
    $search_orderby .= "WHEN $wpdb->posts.post_title LIKE '%{$search_orderby_s}%' THEN 1 ";
    

    What did this do? It was an old snippet from /wp-includes/query.php that set up a search for post titles. The input $q['s'] was escaped using two functions before it was added to the post_title LIKE expression. Now let’s see how I replaced that snippet in the next version.

    4.0 New Style

    $like = '%' . $wpdb->esc_like( $q['s'] ) . '%';
    $search_orderby .= $wpdb->prepare( "WHEN $wpdb->posts.post_title LIKE %s THEN 1 ", $like );
    

    There are two important differences to notice.

    • I changed the like_escape() call to $wpdb->esc_like().
    • I changed the esc_sql() call to $wpdb->prepare().

    The second change is important because esc_sql() is not secure if it is called before, or inside, the call to the new function $wpdb->esc_like(). By relying on the preferred style of the function prepare(), I can easily see that each instance of $wpdb->esc_like() will run first instead of last.

    4.0 Alternative Style

    Here is something that still works, but I avoided using it. Notice the old query is unchanged. It is critically important to call the two escaping functions in the correct order when using $wpdb->esc_like().

    $search_orderby_s = esc_sql( $wpdb->esc_like( $q['s'] ) ); // This is the correct order.
    $search_orderby .= "WHEN $wpdb->posts.post_title LIKE '%{$search_orderby_s}%' THEN 1 ";
    

    How Should I Get My Code Ready for 4.0?

    The nice thing about deprecated functions is that you can still use them and they don’t change. Your existing code should work fine.

    When you write new code, remember that using $wpdb->esc_like() is not compatible with WordPress 3.9. This should be avoided if you need compatibility with old versions. When you are ready to adopt 4.0 as your minimum version, consider using the new function.

    If you have a specific need for the new function in old versions of WordPress, I suggest copying the new function into your plugin under a different name. This would be the simplest solution, but rarely necessary.

    Why Did like_escape() Change to $wpdb->esc_like()?

    There were several problems with the old function that could not be fixed.

    • Documentation said the function’s output was safe to use in SQL queries. That was not correct.
    • The function’s output was not fully compatible with LIKE expressions in MySQL.
    • The function had been used many different ways in core code, some of which were incompatible with the desired output.
    • Changing the old function instead of creating a new one would have caused many security problems in plugins.
    • The function was related to $wpdb because of its MySQL syntax, which does not work on other databases.

    Is There a Security Problem with like_escape()?

    The old function like_escape() was not intended to be used in any security sensitive context. There are no security problems when it is used correctly.

    With that said, I am concerned that plugin authors frequently confused the old function like_escape() with esc_sql(), which was used for security. The documentation for like_escape() was misleading and very confusing about this point.

    Just remember, like_escape() does not provide any security for your database!

    So What Does $wpdb->esc_like() Do Anyway?

    Whenever user input or other raw data are copied into a WordPress query, the data must be escaped using $wpdb->prepare() or esc_sql(). This prevents certain characters, such as quotes, from getting confused with SQL commands.

    In a LIKE expression, there are additional special characters that are used as wildcards to search for partial matches in the database. Those wildcard characters have to be escaped from the user input so that they are not confused with the wildcards added by the programmer.

    Before adding user input to this type of search query, $wpdb->esc_like() should be called for compatibility, and then $wpdb->prepare() must be called for security, in that order.

    How to Use $wpdb in Functions

    It is very rare to use $wpdb->esc_like() without also running a query. But just in case you want to …

    function my_search( $input ) {
        global $wpdb;
        $escaped = $wpdb->esc_like( $input );
        ...
    }
    

    … remember to reference $wpdb as a global variable.

     
    • Mike Schinkel 6:08 pm on June 20, 2014 Permalink | Log in to Reply

      Nice writeup.

      Note there’s a code type in your “40 Alternate Style”: $wpdb->esc_like( $q[‘s’] )

    • JasWSInc 6:09 pm on June 20, 2014 Permalink | Log in to Reply

      I hope we will see an `esc_like()` function to serve as a wrapper for this wpdb class member like all the others (i.e. `esc_sql()`, `esc_attr()`, `esc_html()`, etc). Not a big deal to call it through the class instance, but it would be nice to have the function also; i.e. `function esc_like()`

    • Michael Adams (mdawaffe) 8:30 pm on June 25, 2014 Permalink | Log in to Reply

      Nice.

      $wpdb->prepare( "SELECT * FROM `$wpdb->posts` WHERE `post_title` LIKE %L", "Something%" ) would be cool.

      • Robert Chapin 11:38 am on July 9, 2014 Permalink | Log in to Reply

        We wouldn’t be able to interpret the % chars in a meaningful way with that syntax. By running $wpdb->esc_like() first, you still have the power to add % chars that are not escaped before preparing the query.

        • Michael Adams (mdawaffe) 9:37 pm on July 14, 2014 Permalink | Log in to Reply

          You’re right. My example was bad. Thanks.

          The following would work:


          $wpdb->prepare( "SELECT * FROM `$wpdb->posts` WHERE `post_title` LIKE %L%%", "Something" )

          Which would be the same as:


          $wpdb->prepare( "SELECT * FROM `$wpdb->posts` WHERE `post_title` LIKE %s%%", $wpdb->esc_like( "Something" ) )

          Which is the same as:


          $wpdb->prepare( "SELECT * FROM `$wpdb->posts` WHERE `post_title` LIKE %s", $wpdb->esc_like( "Something" ) . "%" )

    • rajlaksh 5:36 pm on August 9, 2014 Permalink | Log in to Reply

      Thanks for This Valuable Post.

      But i found it little difficult so i swift $WPDB to MySqli.

      MySqli easier than $WPDB. :)

  • Scott Taylor 8:46 pm on June 7, 2014 Permalink  

    Community Priorities 

    Triaging tickets takes a lot of time and is often thankless work. Testing patches and making sure they are committable is equally as time-consuming. Being a gatekeeper to those tickets going into core is also tough – sure, you can commit anything, but you are also the first person responsible when it breaks or there weren’t unit tests in place (when there should have been).

    As a community, we often have 2 major goals:
    1) Fix everything
    2) Make everything better

    Since we are still in the midst of defining what 4.0 will ultimately be, I would like to ensure that the community once again has a voice as far as “priority” tickets go, outside of dev chat.

    If there is an important ticket that you feel has been neglected, comment below. Seriously. There is always frustration from those who say “my ticket never gets looked at!” – for anyone feeling especially disillusioned, remind us publicly to give you some feedback. This does not mean that every ticket deserves to ultimately go in right away, but let’s talk about it.

    Speaking for myself, I often sit down at the computer and say “my goal today is to commit 100 tickets!” – I usually end up committing 8, over the course of 5 hours. And most of those tickets haunt me for weeks. Everyone is held to a high standard and expected to follow through when they make a decision for everyone else.

    We ALL want the same thing. Let’s work together to get there!

     
    • Robert Dall 8:53 pm on June 7, 2014 Permalink | Log in to Reply

      This has a patch it just needs a review… 
      plugins cannot filter `the_content` for Gallery post format on index views

      https://core.trac.wordpress.org/ticket/25335

      It has been debated whether is it worthy to patch something so “trivial” but if it is still a default theme and bundled with core then I think it is something that should be fixed…

    • Jonathan Brinley 9:00 pm on June 7, 2014 Permalink | Log in to Reply

      Thanks for asking, Scott. It’s hard to get attention to a patch without coming across as a whiny attention seeker. I appreciate having this forum. Without further ado…

      https://core.trac.wordpress.org/ticket/17817 – Fixing filter/action recursion

      Has a patch, has unit tests, has performance tests, has plenty of community feedback, and it fixes a bug that’s lived in core for seven years.

      The ticket itself had a fair amount of feedback for a while, but now that all the concerns have been addressed, it’s gone silent. Is there anything else I can do to help advance this ticket?

    • Niklas 9:31 pm on June 7, 2014 Permalink | Log in to Reply

      I’m unsure whether or not there are tickets on all of these subjects and my trac-fu is not good today… But here are some wishes:

      • The ability to use TinyMCE in widgets.
      • The ability to prevent plugins from breaking when WP auto-updates. I know the fault does not lie with WP, but sometimes plugins break things, and when the break things during auto-update things get worse because you are not there to discover it right away. Some setting to only allow auto-update if all enabled plugins are marked as compatible with the new version would be awesome!
      • Combine/compress CSS/JS files. This one I found a four year old ticket for (https://core.trac.wordpress.org/ticket/11453) but I believe this might be reconsidered now that a CSS preprocessor has been impleneted (https://core.trac.wordpress.org/ticket/22862). What do you say? The code is already there to sort JS files correctly according to dependencies.

      • Marius Jensen (Clorith) 5:20 am on June 11, 2014 Permalink | Log in to Reply

        Regarding plugin breakage from automated updates, I don’t see this as something that should be a problem for the default behavior. The default behavior of the updater is to only apply minors which generally mean security and bug fixes for the most recent version.

        I guess this does become a whole other question if you enable automatic major updates, perhaps adding a new configurable option alongside major updates to check compatibility of existing enabled plugins? (this should ONLY apply for manually enabled major updates, I think it’s important to maintain the default behavior of potential security patches etc be handled as they are; “instantly”)

        • Niklas 12:53 pm on June 14, 2014 Permalink | Log in to Reply

          I’ve had a dozen or so things break over the last year and a half on minor updates, there have been three types of error:

          a) It breaks because caching plugins (W3 TC, and WP Super Cache, I’m looking at you… :) ) does not update their cache properly.
          b) A plugin author has created a work-around for a bug that was fixed in the minor update and the two fixes now collide.
          c) The plugin author depended (for some stupid reason) or otherwise made code assumptions on the erroneous behaviour and therefore the update broke the site.

    • @ubernaut 10:04 pm on June 7, 2014 Permalink | Log in to Reply

      heres mine:

      https://core.trac.wordpress.org/ticket/11302

      basically ht issue is that in bulk editing mode there is no way to remove categories which can make for an incredibly arduous manual process of removing the categories one by one. i believe all the ui issues have been resolved at this point and there is also end user interest on this one:

      https://wordpress.org/ideas/topic/deselect-categories-in-bulk-edit

    • Bryan Petty 10:50 pm on June 7, 2014 Permalink | Log in to Reply

      You asked me to list all of my high priority tickets in the IRC channel. Nobody actually cares, but I built a whole report for it. I honestly feel like most of the 600+ tickets here have been terribly neglected:
      https://core.trac.wordpress.org/report/46

      Seriously… This report contains roughly the same number of unreviewed patches now as it did when I wrote the Bug Gardening guide two years ago. There’s patches in here that go for years without any feedback from the core team at all, not even to say that it’s not acceptable, or to even suggest that it could use some improvements. This report should only contain new patches submitted in the last couple weeks. Everything else should have either been rejected (with explanations), or committed.

      I’m not going to sit here and list off all of my open patches that have been neglected (and yes, I do have some). That’s not fair to anyone else that also submitted patches to Trac that isn’t here to speak for themselves. You aren’t asking them, and that’s part of the problem itself. Just the mere fact that a patch is uploaded and submitted to Trac *is* the indication that it’s important to someone in the community, and that the contributor thinks it’s important enough to donate their work to the entire community.

      • solarissmoke 12:44 pm on June 8, 2014 Permalink | Log in to Reply

        +1

        Come here to say exactly this! There are tickets in that report which (at the time) had working patches, and were even tagged for commit, but were ignored. Some of them are now 7 or 8 years old.

        Would be very, very happy to see a more systematic trac process, so that each ticket is funnelled through a review process within a specified timeframe (during which it is either accepted and actively wrangled, or rejected with reasons). That way we would not end up with hundreds of abandoned tickets (and just as many disillusioned contributors).

      • Helen Hou-Sandi 1:43 pm on June 8, 2014 Permalink | Log in to Reply

        Patch review from anybody in the community, particularly those who have more patches under their belt, is immensely helpful. While I wouldn’t expect that to fix the issue of ticket and patch rot completely, as I don’t think any one thing can, it really does go a long way toward helping ease the bottleneck that comes from an expectation that every single patch be reviewed by whatever is defined as the core team.

        • Bryan Petty 2:58 pm on June 8, 2014 Permalink | Log in to Reply

          This report is filtered specifically down to bugs only. There’s actually another 750 tickets with unreviewed patches for enhancements and new features. The reason the list is filtered, and why this is a high priority report is because assuming the core team doesn’t have the time to review everyone’s patch, it’s not a problem, features can still go in a plugin most of the time. I don’t expect the team to review every single patch. However, you can’t do that with bug fixes, and if developers with commit access can’t even keep up with reviewing bug patches (which account for less than 50% of the unreviewed patches), the team needs some serious reform.

          It’s one thing to ignore a bug report because you don’t have the time or required information to investigate it (and I get that), but it’s not acceptable when those with commit access on an open source project can’t be bothered to review patches. It’s literally the only job developers with commit access are absolutely required to do because no-one else can do it. Anyone else can fix the same issues and develop the same new features the core team has been working on if they’d let them. What the community can’t do is review and commit patches.

          It’s pathetic because someone else already did most of the heavy lifting, and it’s arrogant because the team assumes that only those with commit access have the ability to write quality patches. Above all else though, it’s a terrible cycle of abuse that WordPress is stuck in because someone invested a lot of their own (and their company’s) time writing it, and by ignoring it, the core team has consistently discouraged new contributors from getting involved. It’s also telling companies that hiring contributors or giving their developers extra time to contribute is just a waste of time and money. And without those dedicated long-term contributors, it becomes even more difficult to find worthy developers to grant commit access, and the team fails to find the time to review more patches yet again.

          You’re assuming that patch rot is a regular and normal thing in an open source project, and that’s partly true, but not to this extent. There’s a serious problem here, and there *are* solutions to that problem that the core team isn’t adopting.

          • Eric Andrew Lewis 4:20 am on June 9, 2014 Permalink | Log in to Reply

            I think you do have a point, but I don’t think grandstanding and talking trash at length about the process is productive.

            • Denis de Bernardy 9:26 pm on June 14, 2014 Permalink

              Imho, he’s absolutely not talking trash. He’s simply laying things out as they are. The issue got raised every year or so since 2005, and things haven’t changed to date except for the addition of extra committers — something yours truly vocally fought for. Fixing bugs is still lowest priority for all intents and purposes, and it’s shameful. I’m not holding my breath for things to change this year any more than it did when I abandonned the idea of contributing to WP in any material manner, but seeing a committer, however junior, actually initiate the discussion is a very welcome ray of light imho.

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

          I agree with Bryan. This is an area where the community has made incremental yet inadequate changes over the years. We have a well-organized Trac, unit testing to prevent old bugs from returning, and a core team willing to listen now, but bug fixes still take the absolute last priority in WordPress. The untapped potential of this community is mind boggling.

    • Tom Lynch 11:05 pm on June 7, 2014 Permalink | Log in to Reply

      I have been advocating changes to the Settings API and actually using it or providing hooks or something to the Admin settings and Network admin settings for years and it seems like someone higher up needs to make some decisions and garner support for it, because people have submitted patches only to be told we need to do XYZ… It’s hard to believe core still uses table based forms.

    • prionkor 6:48 am on June 8, 2014 Permalink | Log in to Reply

      Here is mine :) do_shortcode() for caption text. Was mentioned in dev chat.

      https://core.trac.wordpress.org/ticket/24990

    • leemon 8:16 am on June 8, 2014 Permalink | Log in to Reply

      https://core.trac.wordpress.org/ticket/5809 Updating a term in one taxonomy affects the term in every taxonomy
      https://core.trac.wordpress.org/ticket/23292 Media uploader loads full size image and slows down, please change to thumbnails.

    • Torsten Landsiedel 12:38 pm on June 8, 2014 Permalink | Log in to Reply

      It is not my ticket, but I think it would be hilarious to fix these: https://core.trac.wordpress.org/ticket/17268

      It seems to be a little bit tricky to check if the server does provide the right languages and modules, but maybe these plugins help to bring this into core:
      https://wordpress.org/plugins/native-gettext-diagnosis/
      https://wordpress.org/plugins/wp-performance-pack/

      Less memory usage and faster sites for non-english WP installations is maybe not important for many english developers and so it this seems to be lost in the last 4 years. Would be cool if this would gain more community power 😉

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

      Wouldn’t it be nice if 4.0 was a community-driven quality assurance release?

      #10041
      This is my highest priority and must not wait for betas.

      These were punted from 3.9:
      #23185
      – NBSP compat for dashes.
      #27587
      – NBSP compat for smilies.
      #27588
      – NBSP compat for shortcodes.
      #19550
      – Filter wptexturize.

      I have several patches for problems that are being caused by wptexturize:
      #12690
      Do not texturize HTML and shortcode elements! (Fixes several tickets)
      #19308
      Do not texturize hexadecimal expressions.
      #8775
      Fix curly quotes around numbers.
      #22823
      Fix possesive numbers.

      The wptexturize tickets below can be ready for 4.0, but I’m not going to waste time on them if we can’t get the above tickets finished first.
      https://core.trac.wordpress.org/ticket/28483 Stack errors in wptexturize.
      #20342
      Allow dashes before curly quotes.
      https://core.trac.wordpress.org/ticket/6969 Duplicates several other tickets, just needs review.
      https://core.trac.wordpress.org/ticket/4539 Duplicates several other tickets, just needs review.
      https://core.trac.wordpress.org/ticket/17571 Probably invalid.

    • Till Krüss 1:11 am on June 9, 2014 Permalink | Log in to Reply

    • Lachlan MacPherson 9:13 am on June 9, 2014 Permalink | Log in to Reply

      Would really love to see this ticket looked at: https://core.trac.wordpress.org/ticket/17379 (Filtered exports drop attachments and featured images).

      It’s something that I encounter many times a week.

    • Chris Van Patten 12:28 pm on June 9, 2014 Permalink | Log in to Reply

      Not my ticket, but I’d kill (not literally) for #21195: https://core.trac.wordpress.org/ticket/21195 As far as I can tell, there’s currently no clean way to get an avatar URL without leaning on regex, which is not fun.

    • Rodrigo Primo 1:49 pm on June 9, 2014 Permalink | Log in to Reply

      Thanks for asking Scott.

      The highest priority ticket for me is a better algorithm for listing hierarchical post types in the admin. This ticket has a patch and is waiting for core developers feedback.

      https://core.trac.wordpress.org/ticket/15459

    • Aubrey Portwood 4:03 pm on June 9, 2014 Permalink | Log in to Reply

    • Amanda Rush 6:26 pm on June 9, 2014 Permalink | Log in to Reply

      I think it would be great if 4.0 were a release that focused on accessibility. The media library has several problems just by itself, and we have of course been working on this along with testing core features for accessibility. Plus, by making 4.0, (or some other release if that’s not possible), an accessibility release, more credibility would be lent to WordPress as a platform that is serious about accessibility.

    • Knut Sparhell 10:32 pm on June 9, 2014 Permalink | Log in to Reply

      It’s a bit late to change the focus for 4.0 now. I would like to suggest 4.1 to focus on fixing bugs, bringing down the number of open tickets, and continue making internationalisation, password handling, multisite and taxonomies better according to the roadmaps lined out on this blog.

      My only open ticket with a patch is https://core.trac.wordpress.org/ticket/27951

    • Jesper Johansen (jayjdk) 8:12 pm on June 10, 2014 Permalink | Log in to Reply

      I’d love to get some kind of feedback on my patch on https://core.trac.wordpress.org/ticket/16784

    • Patrick Hesselberg 8:15 am on June 11, 2014 Permalink | Log in to Reply

      Adding a composer.json to WordPress core would still be awesome. *bump*
      https://core.trac.wordpress.org/ticket/23912

    • Ben Huson 11:15 am on June 11, 2014 Permalink | Log in to Reply

      Would appreciate any devs who have a good knowledge of how the Media Modal works giving their input/views/suggestions on this: