WordPress.org

Make WordPress Core

Updates from April, 2016 Toggle Comment Threads | Keyboard Shortcuts

  • Eric Binnion 2:39 pm on April 27, 2016 Permalink |
    Tags: ,   

    Week in Core, Apr 19– Apr 26 2016 

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

    Ticket numbers based on trac timeline for the period above.

    Code Changes

    Build/Test Tools

    • Build/Test Tools: Reset the PHPMailer mock in Tests_Mail::tearDown(). [37307] #36609
    • Tests: Use the same incrementor for all fields belonging to a given text fixture. [37299] #35199
    • Don’t announce PR builds in Slack. People may submit a PR to our travis build repo, we shouldn’t notify slack when that happens. [37268] #36607
    • Tests: Allow override of MULTISITE and SUBDOMAIN_INSTALL constants [37266] #36567

    Canonical

    • Use get_the_terms() to verify that a post belongs to the requested %category%. The get_the_terms() wrapper provides cache support, and saves a database hit
      on sites with a persistent cache backend. [37262] #36602
    • Tests: After [37260], use WP’s setUpBeforeClass() wrappers. This ensures no leakage between tests of fixture IDs. [37261] #36602
    • Add tests for permastruct containing /%category%/. [37260] #36602

    Comments

    •  Add a $comment parameter to get_comment_author_url_link(). Add unit tests (none exist). [37305] #36573
    • Add unordered list styling to Comments List Table rows and Moderate Comment screen. [37304] #36160
    • Keep comments safe in the Edit Post screen. Warns users that have added a new Comment or began editing an existing without saving their changes, before they press the “update” button which would wipe out their comment changes. [37303] #32818
    • Dashboard: toggle the “View” link for comments when Approving / Unapproving from the Dashboard widget. [37302] #35518

    Database

    • Suppress connection error messages when WP_DEBUG isn’t enabled. This is a partial revert of [35860], which has been causing un-catchable warnings to be generated on some server configurations. [37293] [37292] #36629, #21870

    Date/Time

    • Tests: Pre-declare the $year_url property before initialization in Tests_Get_Archives::setUp(). [37271] #36611

    Docs

    • Add missing return descriptions for WP_Filesystem_SSH2::chown() and WP_Filesystem_SSH2::run_command(). [37270] #30989
    • Clarify the return descriptions for get_the_time(), get_post_time(), and get_post_modified_time() to specify when an integer in the form of a Unix timestamp should be expected. [37265] #30989
    • Clarify return descriptions in the DocBlocks for set_user_setting() and delete_user_setting(). [37264] #30989
    • Clarify parameter and return descriptions in the DocBlock for wp_set_all_user_settings(). [37263] #30989
    • Capitalize URL – an acronym for Uniform Resource Locator – when used in the context of inline docs in wp-includes/link-template.php. [37259] #30406
    • Notate more optional parameter defaults for a variety of function DocBlocks in wp-includes/link-template.php. [37258] #30406
    • Notate optional parameter defaults for a variety of function DocBlocks in wp-includes/link-template.php. [37254] #30406

    Editor

    • TinyMCE: prevent showing the placeholder URL when adding a link and clicking more than once on the Insert Link button. [37301] #36637

    Emoji

    • Smilies: Move convert_smilies to happen later in the the_content filter. [37298] #36306
    • The :roll: smiley is now an emoji. [37296] #36365
    • The diversity support test was incorrectly passing on all browsers. [37257] [37256] #36604

    Feeds

    • Revert [36230] which removed the rss-http feed content type. Removing this means that any feeds which are using this feed content type are now being served as application/octet-stream instead of text/xml. [37284] [37282] #36620

    General

    • Customize/Formatting: Move sanitize_hex_color(), sanitize_hex_color_no_hash(), and maybe_hash_hex_color() from class-wp-customize-manager.php into formatting.php. Adds missing braces. [37283] #33413, #27583
    • Administration: Introduce admin_print_footer_scripts-$hook_suffix", a dynamic version of the admin_print_footer_scripts hook. This is now more consistent with the generic admin_print_scripts and the dynamic admin_print_scripts-$hook_suffix hooks fired in wp-admin/admin-header.php. [37279] #34334

    Media

    Networks and Sites

    • Tests: Account for flexible IDs in main network deletion test. [37300] #36566
    • Tests: Exclude ms-files test group from default PHPUnit config. [37269] #36566
    • Tests: Add speedTrapListener to multisite’s PHPUnit config [37267] #36566, #30017

    Posts, Post Types

    • Add parameter documentation for ‘post_category’ to wp_insert_post(). [37255] #36601

    Post Thumbnails

    • Fix logic bug and tests from [37308] where post-thumbnails support wasn’t added if there were no previous post_types with support already. [37313] #22080
    • When using add_theme_support( ‘post-thumbnails’, array( $post_types) ) merge the supported post_types. [37308] #22080

    Query

    • Tests: More explicit fixture content when testing s=0 query string. After [36647], the unit test generator sequence can put a 0 into the
      ‘post_excerpt’ field of a post fixture, causing false positives. [37280] #36622

    Rewrite Rules

    Taxonomy

    • Docs: Move the clarification of is_tax() and WP_Query::is_tax() return value added in [37235] to @return description. [37281] #36331

    Text Changes

    Themes

    Upgrade/Install

    • Clear plugin/theme caches directly after a plugin/theme has been updated. This is a follow-up to [34751]. [37272] #34029, #36383

    Users

    • Remove the “Name” column of the Users table from appearing sortable. [37314] #28064
    • Docs: Reflect the new 'user' option for wp_new_user_notification()‘s $notify parameter added in [37276] in wp_send_new_user_notifications() docs as well. [37278] #36009
    • Add a unit test for [37276]. [37277] #36009
    • In wp_new_user_notification(), sdd 'user' option for the $notify parameter, which allows for sending notification only to the user created. [37276] #36009

    Thanks to @akibjorklund, @alexkingorg, @flixos90, @rachelbaker, @azaozz, @boonebgorges, @davewarfel, @downstairsdev, @DrewAPicture, @flixos90, @grapplerulrich, @helen, @iseulde, @jeremyfelt, @jesin, @jmichaelward, @joemcgill, @johnbillion, @jorbin, @juanfra, @Latz, @mpol, @ocean90, @pbearne, @pento, @polevaultweb, @rachelbaker, @rmccue, @SergeyBiryukov, @spacedmonkey, @swissspidy, @tfrommen, @tollmanz, @Unyson, @welcher, @westonruter, @WiZZarD_, and @wonderboymusic for their contributions!

     
  • Dominik Schilling (ocean90) 9:24 pm on April 14, 2016 Permalink
    Tags: ,   

    WordPress 4.6: What’s on your wish list? 

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

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

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

     

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

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

      The old @scribu plugin posts2posts

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

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

        YES!!!

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

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

        +1 😀

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

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

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

        +1 😀

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

        +1

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

        +1
        Yes! Yes! Yes!

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

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

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

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

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

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

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

      Groups.

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

      And a better media manager.

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

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

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

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

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

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

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

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

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

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

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

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

      This is critical for building out more complex sites.

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

      3. Incorporate and improve functionality / control of user login/registration/lost password forms and email notifications like “Theme My Login” does.
      https://wordpress.org/plugins/theme-my-login/

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

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

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

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

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

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

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

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

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

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

        +1

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

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

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

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

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

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

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

      Also, two big ‘ole scary topics:

      ✨ Custom post statuses
      ✨ Native multi-author support

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

      #34292 – Support For DNS Prefetch

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      1) Sidebar Widget Style Dashboard Widgets

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

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

      2) Configurable ‘maintenance mode’ page.

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

      3) Editable ‘Credits’ page

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

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

      4) Simultaneous Multi User Editing of Pages

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

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

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

        > 2) Configurable ‘maintenance mode’ page.

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

        > 3) Editable ‘Credits’ page

        wp-admin/credits.php already exists.

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

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

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

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

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

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

              That’s not user friendly.

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

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

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

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

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

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

            That’s close to what I mean.

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

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

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

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

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

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

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

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

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

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

              https://wordpress.org/plugins/humanstxt/

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

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

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

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

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

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

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

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

      Improvements on HTTPS. Let’s Encrypt has recently left beta and encryption is becoming more and more important. There’s a bunch of tickets with keyword “https” in Trac, which could be tackled in this release.
      https://core.trac.wordpress.org/query?status=!closed&keywords=~https

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

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

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

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

        +all the 1s

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

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

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

        Digging the media widget proposal!

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

        +1 for media widget. Seriously!!

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

        +1 for better “page as front” UI

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

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

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

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

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

        +1 on all of these!

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

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

        #34923: Introduce basic content authorship in the Customizer

        As for:
        #32417: Add new core media widget

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

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

        yes, yes, and yes.

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

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

        +1 for media Widget. With optional link please 🙂

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

        +1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      https://github.com/FacetWP/use-child-theme

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

      https://wordpress.org/plugins/wordpress-importer/

      Thanks for asking!

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

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

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

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

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

          +1

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

          +1

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

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

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

          +1

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

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

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

          +1

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

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

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

          + 1

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

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

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

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

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

        + 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

          +1 Fields API 🙂

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

          +1 Fields API

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

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

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

          +1 Fields API

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

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

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

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

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

      Background image generation:
      https://core.trac.wordpress.org/ticket/30874

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      My wish list :

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

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

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

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

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

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

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

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

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

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

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

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

        +1 on the install url.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      • Shortcode UI
      • Posts to posts
      • Updated Rewrites

      And some rewrites in terms of code:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      New modern admin UI

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

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

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

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

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

      Visual shortcodes.

      By default having the TinyMCE kitchen sink active.

      Adding a CSS editor and additional edits into the customizer.

      A better content creation experience.

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

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

        > By default having the TinyMCE kitchen sink active.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      As a user these are my annoyances / wishlist:

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

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

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

      SMTP setup without using external plugins.

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

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

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

        +1

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

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

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

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

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

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

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

      +1 Merge of Fields API

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      Screen Options -> Custom Fields

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

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

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

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

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

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

      Even now thanks for your job @ocean90

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

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

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

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

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

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

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

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

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

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

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

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

      Would love to see some focus on this: #15955

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

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

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

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

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

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

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

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

      https://core.trac.wordpress.org/ticket/18375#comment:21

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

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

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

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

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

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

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

      Is any of this real?
      Thanks
      http://www.SvetZitrka.cz

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

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

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

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

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

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

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

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

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

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

        +1

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

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

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

      I came across this age old widgets per page/post trac ticket:
      https://core.trac.wordpress.org/ticket/4280

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

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

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

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

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

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

      Autoloader in core!!!

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

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

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

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

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

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

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

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

      *Speed
      *Bugs

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

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

      Ā ā
      Ē ē
      Ī ī
      Ō ō
      Ū ū

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

      My wishlist,

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

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

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

      … I now use this plugin on ALL my sites

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

      //Lars, Copenhagen

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

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

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

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

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

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

      Site language
      Admin language (or Backend language)

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

      I hope you can see my point

      Best regards from Lars, Copenhagen

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

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

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

  • Adam Silverstein 5:09 am on March 25, 2016 Permalink |
    Tags: ,   

    Core Dev chat notes for March 23 

    Agenda

    Schedule Notes, Status Updates, RC Triage.

    Schedule Notes

    • Release Candidate 1 will go out today, as per the release schedule.
    • April 12 is the target release date for WordPress 4.5.
    • Release Candidate means a soft string freeze, except the About Page.
    • Also, every commit must be approved by two leads or permanent committers, and only regressions or blockers are addressed.
    • In other logistics, @jorbin had a couple of comments regarding the field guide:
      • There is a firm deadline of Monday 16:00 GMT for the two remaining posts (@rmccue on the Rest API and @iseulde on Editor Shortcuts).
      • He’s planning on posting the field guide on Monday, following that deadline.

    Status Updates

    • Image Improvements: @joemcgill
      • Not much to report. All the remaining tickets from the Media component have been cleared. It looks like there was some movement on #36191.
    • Theme Logo Support: @obenland
      • We have 2 open tickets in the queue, both possibly fixed by the same commit.
      • The goal is to make theme support arguments be closed to custom_header and remove the necessity to create a custom image size.
    • Editor: @azaozz, @iseulde
      • Everything looking good, squashing some minor bugs.

    RC Triage

    Ticket triage continued addressing tickets in preparation for Release Candidate 1.

     

    Full meeting logs in Slack.

     
  • Gary Pendergast 4:31 am on March 7, 2016 Permalink |
    Tags: , reactions   

    Reactions 

    What are Reactions?

    If you’ve used Slack or Thefacebook recently, you’ll have noticed a new way of interacting and providing feedback – emoji reactions. It works much the same way as a Like button, but provides a wider range of reactions, so readers can give more nuanced feedback, without needing to go to the effort of leaving a comment. This also allows for readers to provide the same level of interaction in situations where a “Like” is an inappropriate message to send, as Eric Meyer describes in his post about Inadvertent Algorithmic Cruelty.

    What does it do?

    The reactions plugin currently has the following features:

    • Allows for reactions to posts
    • REST API endpoints for storing and retrieving reactions
    • An exceedingly ugly emoji selector

    What is still being worked on?

    Pretty much everything!

    In its current state, the plugin is mostly a proof of concept, in need of significant work improving edge cases, design and User Experience.

    Your first step is to install the plugin, as well as the WP-API plugin (the WP-API plugin is currently a requirement to avoid code duplication, that will likely be re-evaluated based on when each plugin might be merged into Core).

    Please report any issues on the Github repository, or drop in the #feature-reactions channel in Slack to ask questions or give feedback. It’s also where we have our weekly chats, on Wednesday 23:00 UTC. Thank you!

     
    • Jeremy Felt 5:04 am on March 7, 2016 Permalink | Log in to Reply

      💯💯💯

    • jeffmcneill 5:16 am on March 7, 2016 Permalink | Log in to Reply

      It would be helpful, besides extending comments or adding “reaction” metadata to pages/posts, to enable for smilies and/or emoji. The limited range of reactions, especially in the age of the chat sticker/emoji sets, seems already out of date.

      • Gary Pendergast 5:55 am on March 7, 2016 Permalink | Log in to Reply

        This would be an interesting direction to take it – I’m not sure that there’s a good way to make a usable, extendible system, but it’s definitely worth exploring. 🙂

    • Mark-k 5:46 am on March 7, 2016 Permalink | Log in to Reply

      WTF is this stupid horrible idea? is everybody on the internet has the expression skill of a 5 year old child that we need to “help” them express themselves? Did wordpress change its motto from “democrizing web publishing” to “dumbing down the web”

      [edited for language]

      • Helen Hou-Sandi 3:21 am on March 8, 2016 Permalink | Log in to Reply

        I have untrashed this comment. It is extraordinarily rude (even more so before I edited it) and I am almost impressed at how non-constructive it is, but so long as you continue to make such comments I think the ones that stay away from personal attacks might as well stand on display for others to judge as they might, especially in aggregate. I will not be restoring the comments from yourself and another party that are both rather irrelevant to the actual topic at hand and personal in nature.

        As for your question “is everybody on the internet has the expression skill of a 5 year old child that we need to ‘help’ them express themselves?”, your comment itself answers that question quite well. A simple thumbs down would have sufficed, I think.

        • Mark-k 12:59 pm on March 8, 2016 Permalink | Log in to Reply

          The other part which is censored now, was also not rude at all. I tend to not be rude towards people I don’t know. If it is not constructive to say that wordpress site owners do not need yet another bloated feature built on the bloated an incomprehensible emoji, then I am not sure what kind of constructive discussion is expected here.

          OK I will mind my language from now on, or even better, just avoid commenting since it is apparent there is some hidden code of conduct which is on a “need to know” base, and I do not rank high enough to know it, but you can’t say that on Otto, and his comment is still trashed.

          There was another comment that was deleted and the only commonality between them is that they were against the idea of such a thing getting to the core, 3 different people using 3 different ways to express themselves. What I get from this episode is that wordpress core developers use the posts on “make” just as a lip service to community involvement, but true community involvement not really desired.

    • modemlooper 5:53 am on March 7, 2016 Permalink | Log in to Reply

      I have to agree with the comment that was deleted, this seems like something for a child. Why is this even a consideration?

      • Gary Pendergast 5:59 am on March 7, 2016 Permalink | Log in to Reply

        Right now, it isn’t being considered for Core – it’s being explored as possible feature in the future. The idea still has to prove itself in terms of usefulness, usability, and general appeal. In terms of how close this is to landing in Core, it’s about the same as a new ticket being opened on Trac.

        Regarding the deleted comment, everyone is welcome to share their opinion, positive or negative. Aggressive and offensive comments will not be tolerated under any circumstances, however.

        • Mike 7:40 am on March 7, 2016 Permalink | Log in to Reply

          Why are comments being deleted? If you must, please invite the “offender” an opportunity to rephrase.

          • Gary Pendergast 7:51 am on March 7, 2016 Permalink | Log in to Reply

            Nobody has been banned, everyone is welcome to rephrase their feedback and resubmit.

            Just as I wouldn’t walk into someone’s workplace and abuse them, i expect the same courtesy in my (virtual) workplace.

            • Mike 10:04 am on March 8, 2016 Permalink

              Did I say banned? No.
              BTW this is the WordPress.org workplace.
              And as Helen pointed out he didn’t engage in a personal attack.
              Anyway I don’t have an opinion but I am better informed now.
              Bring back frameworks!

    • Hans-Helge Buerger 8:44 am on March 7, 2016 Permalink | Log in to Reply

      Great idea. I recently found this https://emoji.rodeo/ and though about putting this into a plugin. Maybe this might be an inspiration for you and a good UI.

      I also would like to see that for comments. This would be very useful to mark good or bad comments so users can easily identify them.

      • Gary Pendergast 8:47 am on March 7, 2016 Permalink | Log in to Reply

        emoji.rodeo is super cool (and an amazing domain name!) – thanks for the link, I’ll check it out!

        Comment reactions is definitely on the list, good to hear that you’re interested in it!

    • petermolnar 9:49 am on March 7, 2016 Permalink | Log in to Reply

      Some of us implemented “reacji” as regular comments with a single emoji as content, using this library:
      https://github.com/dissolve/single-emoji-recognizer

      You might find it useful for emoji detection in, for example, pingbacks.

    • andreasnrb 10:04 am on March 7, 2016 Permalink | Log in to Reply

      This sounds like a good case for a stand alone plugin. And about seeing this as a equivalent of a new track ticket. Please, really? Id say publishing this on make marks its status as way beyond a mere new trac ticket.

      • Gary Pendergast 10:08 am on March 7, 2016 Permalink | Log in to Reply

        This sounds like a good case for a stand alone plugin.

        That’s absolutely a potential outcome – one of the original ideas of feature plugins is that they may never be merged into Core – we just end up with a high quality plugin that folks can use. I’m quite okay with that happening, but we won’t know until we investigate further. 🙂

      • Utkarsh 11:11 am on March 7, 2016 Permalink | Log in to Reply

        I agree with stand alone plugin.

    • Tammie 12:16 pm on March 7, 2016 Permalink | Log in to Reply

      I really love this idea simply because it allows people to be more human. It won’t be something everyone will want, but that’s not the point. Any chance we get to encourage and allow more natural interactions in plugin or core, we should.

      There are a lot of reason emoji reactions work for humans and are used so easily and frequently. There’s some really interesting psychological theory behind it. Yes writing is human but emojis often work because a picture does say 1000 words. We connect with emojis.

      I have no opinion on if this is a plugin or should be in core. I’m just grateful and delighted it exists 🙂

    • Slava UA 12:39 pm on March 7, 2016 Permalink | Log in to Reply

      Agree with @modemlooper. Don’t see any reasons to have this in core. IMO.

    • George Stephanis 3:16 pm on March 7, 2016 Permalink | Log in to Reply

      I like this being aimed for core, if for nothing other than its inadvertently fleshing out the ability to build ‘Custom Comment Types’ to match the internal paradigms for custom post types and taxonomies.

    • George Stephanis 3:19 pm on March 7, 2016 Permalink | Log in to Reply

      Also, if we are going to use an emoji picker, this looks like a solid option —

      https://github.com/needim/wdt-emoji-bundle

    • chatmandesign 3:20 pm on March 7, 2016 Permalink | Log in to Reply

      I have to agree with what rapidly seems to be becoming the general consensus: Great idea for a plugin – if I ever setup my own personal blog, I might even use it – but I can’t imagine why this would be considered for Core. I would end up having to disable it on nearly every website I build, which are primarily business websites where this sort of goofy element would simply be inappropriate.

      • Abolfazl Ahani 2:54 pm on March 9, 2016 Permalink | Log in to Reply

        I agree with stand alone plugin.
        I would end up having to disable it on nearly every website I build, which are primarily business websites where this sort of goofy element would simply be inappropriate.

    • kimstuart 4:23 pm on March 7, 2016 Permalink | Log in to Reply

      I would also say this is not core material, but would probably get some traction as a stand alone plugin. We really should be focused on keeping core as compact and to the point as possible these days, and if we’re meant to be competing with Wix, Squarespace, Weebly, etc then the real focus should be on providing small business solutions.

    • Aaron Jorbin 6:01 pm on March 7, 2016 Permalink | Log in to Reply

      This seems like it could have amazing potential for core (and if it doesn’t make it, will at least be a great plugin). It’s innovation like this that shows why WordPress has the highest Net Promotor Score amongst small business owners.

    • Darren Ethier (nerrad) 7:19 pm on March 7, 2016 Permalink | Log in to Reply

      Love the idea! One way to address concerns of people having this in core, is to make it so themes register support for it. `add_theme_support( ‘wp_emojii_reactions’ )`

    • Pascal Birchler 9:37 pm on March 7, 2016 Permalink | Log in to Reply

      I’ve often been reading about emoji reactions in WordPress. Great to hear there’s something going on! Some screenshots would be nice though.

    • Alex Mills (Viper007Bond) 11:04 pm on March 7, 2016 Permalink | Log in to Reply

      Awesome! While this doesn’t seem like core material to me, a canonical and well maintained plugin for handling stuff like this would be great for the community at large.

      It’s always bummed me out that we don’t have more (any?) core plugins.

    • Primoz Cigler 8:15 am on March 8, 2016 Permalink | Log in to Reply

      I wish this never makes to core. Just another plugin, ok, I don’t care. But WHY is this discussed here? So if I make a new plugin can I now post a release notes here and spam everyone who’s subscribed to core newsletters?

    • Morten Rand-Hendriksen 1:28 am on March 9, 2016 Permalink | Log in to Reply

      Super late to the game, so I’ll just say these things:

      • This is plugin territory, useful for a subset of users, but not something I would think could pass an 80/20 test
      • If it is included in core, it should be easy to enable/disable both programmatically and through Admin/Customizer
      • In the spirit of democratization, accessibility, and internationalization, any character/emotion/emjoi set offered must be extensive, inclusive, and extendable, and provide sufficient accessibility features to ensure proper communication even when emotions are not displayed

      My concern (though not a blocker) with the introduction of emoji-style reactions is they are highly contextual and cultural. This is poorly reflected in current emoji implementations and causes some significant communication gaps, misunderstandings, and failures when messages cross cultures. A superficial primer: http://www.wired.com/2015/05/using-emoji-wrong/

      There is significant research being done on communication through emoji, and the preliminary results indicate these symbols create more confusion than anyone anticipated due to emotional, linguistic, national, and cultural differences between the person posting the icon and the person perceiving the icon.

      It’s complicated. I’m conflicted. I’d love to see this evolve into something useful, and I’m curious to see how people would end up using it.

    • Ryan McCue 1:50 am on March 9, 2016 Permalink | Log in to Reply

      FWIW, I love emoji reactions (and have my own plugin for them), but I don’t think they’re core material. I think it’d make a great plugin, or work well as part of Jetpack/WP.com’s Likes feature, but I don’t see them working as part of WP core itself.

    • lenwbrown 6:43 am on March 9, 2016 Permalink | Log in to Reply

      Personally, I like reactions and frequently use them on FB. Coming from old-school text-only chat, I recall many misunderstandings and plenty of frustration when it came to trying to interpret the sender’s intent in a text-only world. Reactions, like general-use emoticons, does help convey a swift and reactive (hence reaction) way of relaying a feeling or non-written observation.

      That said, this is something I feel is exclusively the territory of an optional plugin and not a core feature. As a plugin, I’d certainly be happy to have it. Even better, if you MUST include it, then replace the dang “Hello Dolly” useless plugin millions have already been very vocal about hating so much with this one. At least this way more than one in a million people would actually use the ‘included’ plugin. 🙂

    • DesignWall 9:58 am on March 9, 2016 Permalink | Log in to Reply

      It seems this feature should be developed as a plugin.

    • Helen Hou-Sandi 12:17 am on March 10, 2016 Permalink | Log in to Reply

      Projects like this are extremely valuable in what they expose (and hopefully therefore push to improve) in underlying APIs and related UI. In this case, there are a number of interesting things around custom comment types along with the general UX and various UIs around comment management that will need some pretty significant work.

      I am not yet of the thought that emoji reactions themselves are a core thing. They are very valuable in real-time conversations (e.g. Slack) where they can reduce noise, and can be used in interesting ways like for polls (including this post!), but I’d have to be convinced that this would see widespread and likely fairly consistent usage. To say nothing of the actual implementation itself. 🙂

      Furthermore, I don’t really understand why this was posted on Make/Core at all. I recognize that proposing a feature plugin is still a little bit of a nebulous process (which I am working on), especially when there isn’t a feature plugins response post to reply to or a meeting scheduled. However, given that posting here is not open to all and carries a certain weight, it seems rather inappropriate and very much unfair to have used this as a venue. I have encouraged other people with posting privileges to push proposed posts off onto their personal blogs a number of times when asked for feedback – I would have done the same here.

      • Joachim Jensen - Intox Studio 11:59 pm on March 10, 2016 Permalink | Log in to Reply

        I agree with all of this.

        This project looks interesting to me; not because of what it does, but because of how it does it.

        While I also think it shouldn’t be in Core, it seems like a nice, fresh way to:
        1) show new users how simple and easy it is to extend and customize WordPress
        2) give developers a glance of the new powerful APIs in WordPress

        Perhaps it could be shipped with WordPress instead of the “Hello Dolly” plugin.

    • leemon 8:12 am on March 10, 2016 Permalink | Log in to Reply

      This is plugin territory

    • carlhancock 2:59 pm on March 10, 2016 Permalink | Log in to Reply

      I like the concept. I actually like Facebook’s implementation of the emoji reactions. It’s clean, simple and easy to use. I also like that it limits me to only selecting the emoji reactions Facebook has implemented. In fact, iI’d even use something like this on a site I plan on building as it would be perfect for what i’d like to do.

      However, it’s definitely plugin territory for a variety of reasons. A big one of these being the whole decisions not options ethos. I like Facebook’s implementation because it actually limits you to a subset of emoji reactions.

      But even though I don’t think it’s ideal for core, I think putting the infrastructure in place in core (ie. custom comment types) to support it would be a good idea.

      If I were to implement something like this on a WordPress site I would want to do what Facebook does and limit the subset of emoji that are available to the user for consistency rather than letting them choose from the laundry list of emoji’s. This way I can then use this data to list only posts people have “liked” with a specific emoji, etc.

      Because of this and how I imagine others would use it this means i’d expect any WordPress solution for adding emoji reaction functionality would also have a UI for me to select only the emoji that I want to make available for the users to choose from. Not a hook or filter, but a UI in the admin.

      Which brings us to the issue of why this isn’t ideal for core…

      The first being the “decisions, not options” ethos. It would be unlikely that an emoji settings UI would be added to the WordPress Dashboard along with this as a core feature. I’m guessing it would be all or nothing and be left to hooks to customize it’s behavior. IMO this is something that demands an admin UI and I don’t see that happening in core.

      This combined with the 80/20 rule as it relates to adding features to core means as they would say on Shark Tank…

      “I’m out. But I love the idea, keep up the great work and i’m sure it’ll make a great plugin. You’ll already have a customer in me!” – Mark Cuban

    • Sergio Santos 3:12 pm on March 10, 2016 Permalink | Log in to Reply

      Agree with @rmccue. This should be part of Jetpack, not in the core.

    • Justin Tadlock 3:44 pm on March 10, 2016 Permalink | Log in to Reply

      While I could never see something like this being in core itself, it might be worthwhile to explore this as a core plugin (whatever happened to those?).

      Ultimately, I think the most important things in this plugin deal with custom comment types. Now that post types, taxonomies, term meta, and other really nice dev tools have been added to core, it’d be nice for us to flesh out comment types in WP. Developing an API without something fun to do with it is not much fun at all. This plugin would probably make the perfect test case for custom comment types. I’d love to see that happening with the support of the core leads.

    • wturrell 6:02 pm on March 11, 2016 Permalink | Log in to Reply

      Plugin, not core – given every other commenting feature is built as a separate plugin (including akismet, even though it’s distributed by default.)

      Incidentally, I took the time to install it and see what how it worked. Doesn’t do anything for me (literally – none of the buttons are added), so readme file will need editing if further steps are needed. WP 4.4.2, twentysixteen, PHP 7.0.4, commenting enabled, wp-api installed.

  • Grant Palin 9:09 pm on March 2, 2016 Permalink |
    Tags: ,   

    Week in Core, Feb. 23-Mar 1 2016 

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

    • 128 commits
    • 52 contributors
    • 115 tickets created
    • 19 tickets reopened
    • 135 tickets closed

    Ticket numbers based on trac timeline for the period above.

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

    (More …)

     
  • Eric Binnion 4:36 pm on February 17, 2016 Permalink |
    Tags: ,   

    Week in Core, Feb. 9-16 2016 

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

    • 35 commits
    • 37 contributors
    • 67 tickets created
    • 3 tickets reopened
    • 52 tickets closed

    Ticket numbers based on trac timeline for the period above.

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

    Code Changes

    Accessibility

    • Reduce the WordPress shades of grey, first part. [36537] #35783
    • Improve the color contrast ratio for the TinyMCE button icons. Also, tries to use the new grays from the Design Handbook wherever applicable. [36528] #35604

    Build/Test Tools

    • Make sure fixtures have empty post_content in search test. Introduced in [36278]. [36520] #3102
    • Improve Automated Feed Tests [36519] #35160
    • Unit test for wp_get_comment_fields_max_lengths(). This adds tests for the comment form field lengths returned by wp_get_comment_fields_max_lengths(). Replaces unit test removed in r36514. [36515] #10377

    Comments

    • In the comments list table, only link rows inside the “Submitted On” column to the comment if it is publicly viewable. [36521] #35279
    • Change wp_get_comment_column_max_length() function to wp_get_comment_fields_max_lengths() for consolidation and better fallbacks. [36514] #10377
    • Set the $comment global in comment_form_title(). [36512] #35624

    Customizer

    • Add a user-friendly way to preview site responsiveness for desktop, tablet, and mobile. [36532] #31195
    • Ensure that nav menu items can be shift-clicked to edit in secondary instances of the same nav menu. Amends [36383]. [36523] #32681
    • Hide widgets re-order button when no re-ordering is possible. [36522] #35533
    • Reduce the spinner re-painted area to the smallest possible one. [36518] #35649

    Editor

    • Introduce {$taxonomy}_term_edit_form_top action to edit-tag-form.php. This new action gives developers a place to output content at the beginning of the form element on edit-tags.php. [36526] #35252

    i18n

    • Prevent is_textdomain_loaded() from returning true even if there are no translations for the domain. [36538] #21319
    • Allow larger menus to be created in the Edit Menu screen. This was attempted previously in [36506] which was reverted in [36507]. Some form fields were not being slurped into the form’s JSON representation, and it did not scale for a site with many posts. This approach [36510] #14134

    Meta

    • In delete_metadata(), only invalidate cache for affected objects. [36511] #35797
    • Don’t double-unslash meta key when update_metadata() falls back on add_metadata(). [36509] #35795

    Query

    REST API

    • Apply rest_post_dispatch to embedded responses. [36536] #35628
    • Allow explicit HEAD callbacks. HEAD callbacks can now be registered independently, with the GET callback still used as a fallback. [36535] #34841
    • Add routing args to rest_dispatch_request filter. This allows requests to be hijacked via the filter more easily. [36534] #35507
    • Add support for CURIEs. [36533] #34729
    • Don’t display errors during REST API requests. [36530] #34915
    • Add helper function to get server instance. This allows using rest_do_request() outside of the API itself easily. [36529]

    Taxonomy

    • Introduce publicly_queryable taxonomy argument. If not provided explicitly, the value of publicly_queryable is inherited from public. [36525] #34491
    • Bail from get_term() if a filter returns an object that is not a WP_Term. This prevents fatal errors in certain cases. [36516] #35808
    • Remove unused variable from get_terms(). Unused since [31284]. [36508] #35784

    Themes

    • Use the attachment ID as the key in get_uploaded_header_images(). Prevents missing header images when an image has the same name as another header image. [36539] #31786

    TinyMCE

    • Fix removing a space before inline tags when applying formatting shortcuts. [36513] #35798

    Props

    Thanks to @danielbachhuber, @adamsilverstein, @afercia, @azaozz, @boonebgorges, @celloexpressions, @Chouby, @d4z_c0nf, @danielbachhuber, @DrewAPicture, @ericlewis, @Fab1en, @flixos90, @folletto, @jdgrimes, @joehoyle, @joelerr, @jorbin, @jrf, @michaelarestad, @nacin, @neoxx, @ocean90, @rabmalin, @rachelbaker, @rahalaboulfeth, @rmccue, @rockwell15, @sirbrillig, @stevenkword, @swissspidy, @TimothyBlynJacobs, @tmuikku, @valendesigns, @welcher, @westonruter, and @WisdmLabs for their contributions!

     
  • George Stephanis 7:15 pm on February 16, 2016 Permalink |
    Tags: , application-passwords, authentication,   

    API Authentication discussion! 

    I was chatting with @rmccue and we though it’d be a good decision to have an open discussion regarding potential avenues for API Authentication on Thursday, February 18th at 22:00 UTC in the #core-passwords channel in Slack.

    We’ll be addressing everything from OAuth 1.0a, OAuth 2.0, Application Passwords, and what limitations should be used to scope assorted tokens.

    Relevant background reading: http://stephanis.info/2016/02/14/on-core-rest-api-authentication/

     
    • simonrcodrington 8:04 pm on February 16, 2016 Permalink | Log in to Reply

      Interesting article, thanks for sharing your thoughts.

      When it comes to the API and how it should work going forward, I’m happy with both of these scenarios:

      1 – Once you’re athenticated you can hit all endpoints and perform all admin actions (the onus can be on the user to a accept the risk)
      2 – The user authorises connections only to set API endpoints that could be organised by potentially their risk / importance

      Either way, I’m happy progress with the API is making it into core

  • Adam Silverstein 4:58 pm on February 5, 2016 Permalink |
    Tags: ,   

    REST API meeting summary, Feb 4 

    The core REST API team, members of the WordPress.com API team, and other interested developers met to discuss the REST API.  Full logs of the meeting are available on Slack.

    Existing endpoints

    The meeting opened with a discussion of the existing endpoints: what is and isn’t ready. @rmccue summarized:

    • The main focus has been on the 4 “core” objects in WordPress: posts, terms, comments, and users.
    • Posts
      • Password-protected posts are going to be ignored from the API until we have a good solution.
      • Meta
        • Post (and other) meta has been pushed out into a separate feature plugin led by @jeremyfelt. Discussion is on the github repo.
        • The main issue is that there’s no differentiation between meta fields. Meta could be added via the Custom Fields meta box, or by a plugin.
        • Enhancing register_meta() in core would allow opt-in to the meta REST API – requiring some core work. See the patch on #35658 for details.
        • There is no current way to explicitly register meta as public.
        • We need to support object meta (post, user, comment, term) and object types (custom post types, etc)
      • Media
        • Mostly complete (it’s a custom post type).
        • Some special handling around uploading media.
      • Autosaves and post previews
        • Tricky, but we think we have a solution for that moving forward.
        • Working on them in a separate feature plugin instead.
        • This will be an enhancement to the API in the future, and doesn’t block compatibility.
    • Terms
      • Work great.
    • Users
      • Works great; undergoing final review.
    • Comments
      • Works; custom comment types are harder until core better supports them.

    Merge proposal and discussion

    An extensive discussion ensued regarding the possibility and appropriateness of merging the endpoints into core. The discussion continued for over an hour; mainly covering whether we should merge the 4 core endpoints, or wait for a complete API before merging…  and what the definition of a complete API is.

    The REST API team’s proposal is that we merge the 4 core objects in the REST API with full read, create, update, delete support, then add more peripheral features when they’re ready. 

    @matt argued that we wait until the API supports everything you can do in wp-admin before merging.

    The discussion revolved around these proposals and what is best for the WordPress project. Would merging the existing well developed endpoints sooner help or hinder developer adoption, and further iteration/improvement? Would delaying the endpoint merge help or hinder progress?

    Here are some key comments from the discussion.

    • @rmccue  The approach to the API needs to change from “the API team creates all of the API” to “the API team controls the general shape of the API, and each team works with it”
    • @danielbachhuber Options / a Site Resource is more easily viable, as are Plugins and Themes. Widgets and Menus essentially need to be reinvented before they’ll work in a REST API
    • @jnylen It’s a question of when, and how much testing can be done first. Shipping an API that is read-only and incomplete in several key areas feels like a big mistake.
    • @kadamwhite we’re shipping an API with write capabilities but only cookie-based auth will be supported OOTB.
    • @matt  I would be pretty skeptical of merging a partial API into core…  no partial endpoints in core. let’s design a complete API, not half-do it.
    • @rmccue The API is specifically structured around progressive enhancement
    • @jorbin I think only supporting the four core object types allows for some amazing themes and amazing content editors to be created, but doesn’t allow for full wp-admin replacements. I’m ok with that.
    • @jnylen From what I’ve seen so far, I’m most concerned about shipping individual endpoints with missing features.
    • @jorbin I think the best way to pick up the pace is to get key things locked up and get the four core object types in core. This would help core develop API-first for those features
    • @codebykat On the WPCOM side, we’re committed to taking the plunge, but we’re not there yet which means things are untested.
    • @jnylen I think this needs more testing at large scale before shipping, including some of the more difficult and obscure features of WP.
    • @drew Shipping with full wp-admin replacement capability is unrealistic, imo. We need something flexible and stable that developers can use as solid jumping off point. All the rest can get separately iterated.
    • @mike I think that, realistically, to ship the API… we need an MVP, and I don’t think that defining our goalpost as “all of wp-admin” fits that criteria.
    • @matt Full wp-admin coverage is a firm goalpost, it gives us a super clear criteria for when it should be merged into core. is everything possible in wp-admin, possible through the API?
     
    • Matt Mullenweg 7:12 pm on February 5, 2016 Permalink | Log in to Reply

      We got on a bit of a rabbit hole on file editing in WP, and whether that should be in any API.

      I’m inclined toward no, but I think decisions about what we’re not going to support in the API should be made as deliberately as if we were removing the feature from WP itself. We should make that sort of decision explicitly and proactively, not allow things to die on the vine of existing in wp-admin but not the API.

      It’s also going to be difficult because there is often a big gap between what developers do and what people for whom WP is their entire interface do, which file editing accidentally illustrates very well. (What developer would trade their IDE or text editor for a form on a web page?)

      It might be easier to actually build out APIs for everything first and then choose whether to ship them or not than argue about whether they should be built in the first place, which is inevitably a realm of opinion, values, and sparse data.

      • Omaar Osmaan 7:47 pm on February 5, 2016 Permalink | Log in to Reply

        Absolutely- I like the idea of having API in core that allows to replace WP-Admin without loosing any feature it has. While so far I do have the itch of “get it in core faster”, but I really think your strategy is appropriately sound.

        It’s great to see the arguments- and for sure it all would make it only better in the end.

        My 2 cents.

    • Justin Sternberg 8:11 pm on February 5, 2016 Permalink | Log in to Reply

      Agree on iteration/MVP approach. Full wp-admin coverage, to me, is way overkill for initial merge to core. There is value in “paving the cow paths”… Let’s get the MVP working 100% and merged, and figure out what the next most valuable addition will be. Rinse and repeat.

    • K.Adam White 9:05 pm on February 5, 2016 Permalink | Log in to Reply

      The wp-admin parity argument caught me off-guard, which I believe stems from there being two basic types of use-case. Both types of usage are (and should be) valid:

      We (Bocoup, a non-WP-oriented company) have used the WP-API project to take advantage of the existing wp-admin editing interface, and has used the API solely to flow WordPress-authored data into or out of other applications. Without the API we would never have considered using WordPress for these projects: but the existence of a RESTful/non-XMLRPC interface made WP a big win for both us and our clients.

      Matt’s / Automattic’s experience is the complement to ours: Maintain the existing theme/plugin front-end, but put a custom admin interface behind it.

      The original “json-api” plugin was created by MoMA to flow WP data into a Ruby project; We’ve used the API to flow data into Node applications, and Java and C# clients for the WP-API are also under development. Our use-case is not new, and I believe it represents a significantly larger _potential_ target audience than any wp-admin re-skin does (at present). Daniel Bachhuber hypothesized recently that the way we’ll get WP to “100% of the web” isn’t by moving those sites to WordPress, but rather to allow WordPress to be integrated with existing platforms where appropriate.

      Waiting for API parity with wp-admin suits the Calypso use-case, but delaying core integration of API endpoints for basic WP data types will effectively block a significant group of potential adopters coming from external platforms. Right this second may not be the time, but unless we roll the API into core progressively (hopefully no later than 4.6/4.7) I think we are missing a tremendous opportunity.

      “ — Thank you to everyone involved with the project for being involved in this discussion.

      • Jeremy Clarke 5:33 pm on February 15, 2016 Permalink | Log in to Reply

        +1 Thoughtful and vital reply. I agree that getting the core types in is really valuable, and that seeing the situation from all angles (backend-simulation+frontend-simulation) leaves me feeling like waiting for full wp-admin support is very biased towards certain uses and not others.

        FWIW at Global Voices we have a third use-case that I think is really valuable: Communication between WordPress sites which each use wp-admin+themes in the normal way.

        We rebuilt our translation system, which lets separate WP sites translate each others content, to use the old 0.x version of the feature plugin. Our users create a draft and give it the URL of the post they will be translating, then the API negotiates the translation and delivers the post content which is inserted into the new draft. It works great and replaces a kludgy+insecure old trackback-like system we were using. We didn’t want to hitch ourselves to a plugin for such a vital tool, but the feature plugin felt safe and we knew it would be in core eventually.

        Fast forward and many versions later we’re still waiting, and are seeing multiple, incompatible versions of the plugin coming out. For now we’re still using legacy version and waiting for the endpoints to drop into core before refactoring all our work. In our case the 4 proposed endpoints would be perfect for our needs, so getting them into core ASAP would be a huge boon and make us feel a lot more confident. It would also be really nice to formalize the underlying concepts so any new endpoints we create are modeled after how core will be doing it.

        As with K.Adam infinite thanks to all those actively working on this!

    • Mike Nelson 4:44 am on February 6, 2016 Permalink | Log in to Reply

      > I would be pretty skeptical of merging a partial API into core… no partial endpoints in core. let’s design a complete API, not half-do it.

      Did @matt suggest that thinking it would be easier to iterate the API as a plugin than in core? Or what’s the motivation for this suggestion? I think lots of us give his suggestion a lot of weight, but because I wasn’t at the meeting I don’t understand it

      • Matt Mullenweg 9:30 pm on February 8, 2016 Permalink | Log in to Reply

        I’m 100% for continued iteration, and yes I think that would be easier as a plugin than in core.

        Everyone who wants the functionality today can have it in the plugin with just a few clicks, and we can update that with new functionality as much as often as we want, and if something goes wrong in only affects ~10k users. We know that most WP sites have 5 or 6 active plugins, with professionally-developed sites typically 2-3x that.

        In core we can only do major updates 3 times a year, at most, bundled with lots of other things and concerns that go into a major release, and those updates go out to tens of millions of sites. If we break something it’s in the mainstream tech news. What’s included or not depends on the release lead.

    • Philip Arthur Moore 11:03 am on February 6, 2016 Permalink | Log in to Reply

      I haven’t been involved in the development of this at all, but as a plugin/theme/custom web solutions developer I’d have to strongly agree with @matt with regard to setting full /wp-admin/ coverage as a firm goalpost before inclusion. What’s been keeping me from diving into the API and using it over what we have now is that I’m afraid of changes that may break things and not really sure what I can do with /wp-admin/ that I can’t do with the API. If there’s full parity then I can confidently jump into using the API; until then I feel largely like a spectator seeing how the development of the API plays out before overcommitting our resources to learning it and developing for it.

      • Jeremy Clarke 5:37 pm on February 15, 2016 Permalink | Log in to Reply

        This can swing both ways though. You don’t want to use the API if it’s still in flux, but a constantly-developed plugin will be in flux by default.

        For those of us already using it (the oxygen an API needs to grow and evolve) having a stable platform to work with (even if it’s limited) is really important. Getting the main endpoints into core and having them be treated with the usual obsessive back-compat would make our lives easier and increase the number of people willing to invest time and money into using it.

    • Mike Nelson 1:04 am on February 9, 2016 Permalink | Log in to Reply

      I didn’t think [putting the WP API scaffording in core would] increase the plugin usage, I thought it would increase plugins registering their own APIs, because they hadn’t before because of cross-plugin dependency see https://wordpress.slack.com/archives/core-restapi/p1454633785001643

      I don’t know about other plugins, but at least at Event Espresso we put our REST API, which depends on the WP API infrastructure, into our main plugin directly as a result of putting the WP API infrastructure into WP core 4.5. (See https://eventespresso.com/2016/01/rest-api-now-in-ee4-core/)

      We had some reservations though, thinking that maybe we would wait until the WP API endpoints were also in core (because that would be proof the WP API infrastructure would be more solid and less likely to break). It’s possible other plugins are having the same reservation?

      What’s more, the Event Espresso REST API is a little unique in that we’re using a LOT of custom tables, and our functionality is quite independent of WordPress’ posts etc, and so our REST API can exist quite happily without the WP API’s endpoints. I suspect most plugins’ APIs are much more dependent on WP API’s endpoints in order to work. Eg, there’s not much point in a YARPP REST API without WP API. Meaning, if WP API’s core endpoints are still in a plugin, their users STILL need to use the WP API plugin in order to use their plugin’s API… so just adding the WP API infrastructure isn’t much help to them: they need the endpoints too.

    • rclilly 7:18 pm on February 12, 2016 Permalink | Log in to Reply

      After reading this summary, as well as the entire discussion in Slack, I get the sense that, to a certain extent, people are talking past each other.

      @matt, I really don’t understand why you insist on ALL possible endpoints being completely ready before ANY endpoints can be merged into core.The four that are proposed cover a huge part of what many want the REST API for in the first place. I definitely think those four make for a minimum viable product, assuming they are, indeed, ready for prime time. The ability to completely replace the wp-admin goes way beyond an MVP for a REST API.

      My two cents: If there are endpoints ready for prime time, merge them. Let the others remain in the plugin.

  • Eric Binnion 3:20 pm on January 20, 2016 Permalink |
    Tags: ,   

    Week in Core, Jan. 12-19 2016 

    Welcome back to the latest issue of Week in Core, covering changes from January 12th – January 19th, 2016, changesets [36269][36350]. Here are the highlights:

    • 81 commits
    • 38 contributors with props
    • 127 tickets created
    • 19 tickets reopened
    • 100 tickets closed

    Ticket numbers based on trac timeline for the period above.

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

    Code Updates

    Accessibility

    • After [36333] correctly use esc_attr() instead of esc_attr__(). [36334] #35313
    • Remove title attributes from the Posts list table. [36333] #35313, Media Library list table. [36331] #35136 & the Comments screen. [36298] #35304
    • Improve focus handling on the Taxonomies Quick Edit. Moves focus back to a proper place when saving or closing the form. [36304] #35460
    • Improve focus handling and audible feedback on the Posts Quick-Bulk Edit. Avoids a focus loss when saving or closing the form moving focus back to a proper place. Uses wp.a11y.speak() to dispatch successful edits and error messages to screen readers. [36303] #34756

    Administration

    • CSS: Reference the original location of the CSS rule being overridden. [36342] #35229
    • CSS: Stop using wp-admin.min.css and instead queue the individual stylesheets up through load-styles.php. We still generate the wp-admin.* files for compabitility purposes, however they only include the @import() lines. [36341] #35229
    • List Tables: Use the $GLOBALS array when unsetting the global post and comment in WP_Comments_List_Table::single_row(). [36339] #35506
    • Allow searching for 0 throughout the admin. [36302] #31025
    • Add a “Drag boxes here” message to empty dashboard meta boxes so it’s clear to users that it’s possible to drag meta boxes into empty spaces. [36295] #26399
    • Support searching for '0' in WP_Query. [36278] #31025

    Build/Test Tools

    • Build/Test Tools: Move PHP factory classes into their own files. [36347] #35492\
    • Build Tools: Append the timestamp to $wp_version instead of only the current date. [36315] #28722

    Canonical

    • After [36280] remove the unit tests which are no longer supported for 4.4. This also removes the is_feed() code to avoid confusion – only pages & embeds will be redirected. [36281] #35344
    • Restore the is_404() check in wp_old_slug_redirect() which was removed in [34659]. This reverts part of [34659] due to excessive canonical problems it’s caused in 4.4.x. [36280] #35344, #21602

    Comments

    • Ignore false values of ‘search’ in WP_Comment_Query. [36345] #35513
    • Remove unused $default_comments_page variable in get_comment_link(). [36343] #34073, #35511
    • Correct description of comment_author property in WP_Comment class. The comment_author property is the comment author’s name, not an ID. [36332] #35464
    • Respect all post-related filters in WP_Comment_Query. [36326] #35478
    • Use TEXT column type in fallback for wp_get_comment_column_max_length(). [36325] #10377
    • Respect custom pagination params when using wp_list_comments() in a query loop. [36324] #35402
    • Remove unneeded $req variable in comments_template(). [36322] #35473
    • Add a new pre_wp_update_comment_count_now filter. [36318] #35060
    • Use assertEqualSets() in comment_author test. The previous assertion was too specific, resulting in race conditions. [36279] #35377
    • Use the post-filter WHERE clause when querying for comment descendants. [36277] #35192
    • Always respect $comments array passed to wp_list_comments(). [36276] #35175, #35356
    • Ignore hierarchy in pagination calculation when comment threading is disabled. [36275] #8071, #35419
    • Restrict the maximum characters for input fields within the comments template. [36272] #10377

    Customizer

    Embeds

    • Allow embedding static front pages and pages having a child page with an embed slug. This makes embed a special slug that can’t be used for new pages/posts. When https://example.com/foo/embed/ is an existing page, embeds fall back to https://example.com/foo/?embed=true. Adds unit tests. [36307] #34971

    Filesystem API

    Formatting

    • Emoji: adjust $wpsmiliestrans. Swap simple-smile.png with SLIGHTLY SMILING FACE and frownie.png with SLIGHTLY FROWNING FACE [36336] #31710

    HTTP API

    • Add response status code aliases on WP_Http for convenience. These provide a more descriptive way to set response codes elsewhere, so it’s readable and less chance for the wrong response code to be used such as 401 vs 403. [36294] #35426
    • Add missing HTTP status code descriptions (specifically 308 and 421.) [36274]
    • Add support for 451 http status code (Unavailable For Legal Reasons.) Though this is technically still in the proposal stage, there is support from the core team and precedent in #16914 [36273] #16914, #35333

    I18n

    • Introduce tests for WP_Locale. [36292] #34688
    • Correct an argument description and return value for wp_dropdown_languages(). [36290] #35294

    JavaScript

    • In wp.Backbone.Subviews, extract subviews with proper Underscore.js functions. [36305] #34350
    • jQuery: Replace use of deprecated methods and events. [36288], [36287], and [36286] for #35380,
    • External Libraries: Update jQuery to 1.12.0 and jQuery Migrate to 1.3.0. [36285] #35380

    Media

    • Update some attach/detach strings in the columns view. [36328] #33237

    Multisite

    • Add initial tests for the allowed_themes filter. [36350] #28436

    Network and Sites

    • Clarify the docblock for get_current_site() so it’s clear that it returns the current network object, not anything to do with the current site. As a further exercise, the reader is invited to fix the nomenclature surrounding blogs, sites, and networks in WordPress. [36293] #35414

    Performance

    • Share post fixture in WP_Comment_Query tests. [36346] #30017
    • Script Loader: Add Etag: $wp_version header in load-scripts.php and load-styles.php. This improves performance since browsers won’t re-download the scripts and styles when there was no change in $wp_version. [36312] #28722

    Plugins

    • Prevent a warning when searching in the plugins list table. [36301] #35461
    • Make sure the ‘Beta testing’ tab is first in the plugin installer. This makes feature plugins more discoverable for people running development builds. [36297] #29631
    • In _get_plugin_data_markup_translate() remove the fallback to the “default” textdomain for Akismet. Akismet has its own language files since WordPress 3.9. [36283] #35436

    Posts, Post Types

    Taxonomy

    • Don’t double-escape the ‘name’ param in get_terms(). [36348] #35493
    • Populate term cache with proper clone of term objects. [36323] #35462
    • Fix unit tests after [36308]. [36309] #34988
    • Introduce wp-admin/term.php for editing single terms. [36308] #34988
    • Correct the accetped types for the taxonomy element in the arguments passed to wp_dropdown_categories(). [36289] #35446

    Themes

    • Show template loading error to users with switch_themes cap. [36344] #21931
    • Only users with proper capability should see theme errors. [36338] #21931
    • Show an error message to logged-in users if a template file isn’t loaded. [36335] #21931
    • Clear floated theme cards on Themes page. Also maintains visual separation for Broken Themes table on searches that return no results. [36270] #26646

    Upgrade/Install

    • Add a locking mechanism to avoid two concurrent updates of WordPress occuring. [36349] #34878

    Users

    • Always return $current_user in wp_get_current_user(), never a boolean. [36313] #19615
    • Deprecate the get_currentuserinfo() pluggable function. [36311] #19615
    • Decode special characters in password and email change notification emails. [36306] #35283

    Props

    Thanks to @5um17, @adamsilverstein, @afercia, @andizer, @berengerzyla, @boonebgorges, @chriscct7, @danielbachhuber, @dd32, @DrewAPicture, @ericlewis, @firebird75, @grapplerulrich, @iseulde, @ivankristianto, @jeremyfelt, @jmdodd, @joehoyle, @johnbillion, @jrf, @kraftbj, @Latz, @meitar, @MikeHansenMe, @obenland, @ocean90, @peterwilsoncc, @rachelbaker, @realloc, @rmccue, @scribu, @sebastianpisula, @sergejmueller, @SergeyBiryukov, @swissspidy, @valendesigns, @westonruter, and @xavortm for their contributions this week!

     
  • Mike Schroder 10:22 pm on December 30, 2015 Permalink
    Tags: ,   

    WordPress 4.5: What’s on your Wishlist? 

    A few weeks ago, I put out an initial call for volunteers for 4.5.

    In the spirit of the much-commented @wonderboymusic 4.4 Wishlist post, I’d like to extend the call a bit more.

    • What are you most interested in seeing in WordPress 4.5 — big, or small?
    • What are your or your users’ biggest pain points?
    • What do you see as the most important UX or performance low-hanging fruit to be solved?

    Look forward to hearing from you in the comments!

    The WordPress 4.5 kickoff chat will be next Wednesday, January 6, 2016 16:00 UTC-5.

     
    • Rami Yushuvaev 10:23 pm on December 30, 2015 Permalink | Log in to Reply

      Unifying permission error messages – https://core.trac.wordpress.org/ticket/34521

    • Patrick Daly 10:27 pm on December 30, 2015 Permalink | Log in to Reply

      Editorial Workflow…

      https://core.trac.wordpress.org/ticket/23314 – Allow published posts to be revised without being updated immediately

      https://core.trac.wordpress.org/ticket/12706 – Custom post status bugs in the admin

      • Andrew Nacin 2:54 am on January 3, 2016 Permalink | Log in to Reply

        Both great ideas. Both require a lot of careful planning, decision-making, and implementation. Proposals welcome (from everyone).

    • Mike Schinkel 10:36 pm on December 30, 2015 Permalink | Log in to Reply

      PHP7 as base requirement? 🙂

      • Michael Beckwith 10:39 pm on December 30, 2015 Permalink | Log in to Reply

        If only

      • Matt van Andel 10:50 pm on December 30, 2015 Permalink | Log in to Reply

        I’d wholeheartedly support a bump to 5.3, though.

        • Max Foundry 10:58 pm on December 30, 2015 Permalink | Log in to Reply

          Ditto and +1

        • Jeff Farthing 11:00 pm on December 30, 2015 Permalink | Log in to Reply

          This.

        • rkoller 11:02 pm on December 30, 2015 Permalink | Log in to Reply

          hm but 5.3 as well as 5.4 are already end of life. http://php.net/supported-versions.php . Wouldn’t it be a reasonable move to only support versions with an active support or at least with provided security fixes?

          • Matt van Andel 11:42 pm on December 30, 2015 Permalink | Log in to Reply

            The issue is hosting services that hold onto old versions of php far longer than they should. At this point both 5.3 and 5.4 should be supported by almost all of them precisely because they are so old. With that in mind, I think it’s time we officially bump the requirements.

            • Sybre Waaijer 4:21 pm on December 31, 2015 Permalink

              I think if WordPress would makes this call — as it’s a dominating factor on the internet — hosting providers will be sure to update ASAP to maintain good customer support and reliability. Or create i.e. specific WordPress Hosting Packages which abide to this standard.

          • Erlend Sogge Heggen 3:33 pm on January 1, 2016 Permalink | Log in to Reply

            As a gentle nudge from WordPress’ side, I think it’d be cool if WordPress installs running on EOL PHP versions (5.2, 5.3, 5.4) would show an infobar on the wp-admin.php page, just telling users something like:

            “psst! It seems like you’re using a version of PHP which is at [“end-of-life”](exampe.com/read-more). No need to worry, your WordPress install will continue to work just fine, but you might want to ask your hosting provider if they’re planning to upgrade to a newer version of PHP soon”

        • Daniele Scasciafratte 11:26 pm on December 30, 2015 Permalink | Log in to Reply

          +1

      • Ipstenu (Mika Epstein) 11:31 pm on December 30, 2015 Permalink | Log in to Reply

        Not trolling. Is there a technical reason we need to?

        • Mike Schinkel 1:02 am on December 31, 2015 Permalink | Log in to Reply

          No real reason other than performance and ability to leverage new features like null coalescing, anonymous classes, etc.

          I know it would be a non-starter for backward compatibility though. Just wishing out loud, since he asked. I guess I was really the one trolling, but hopefully not viewed in a bad way. 🙂

          • Ipstenu (Mika Epstein) 1:45 am on December 31, 2015 Permalink | Log in to Reply

            I was legit wondering if there was a feature or such I’d missed that we need 🙂

            Backcompat aside, that’ll be your driving factor. When we have a legit need for 5.4 or 7, it’ll happen 🙂

            • Terence 12:35 pm on January 3, 2016 Permalink

              How about with PHP 7 your apps see up to 2x faster performance and 50% better memory consumption than PHP 5.6, allowing you to serve more concurrent users without adding any hardware? I should have thought that PHP 7 allowing the system to execute twice as many requests per second in comparison with the PHP 5.6, was reason enough.

            • Ipstenu (Mika Epstein) 3:28 pm on January 3, 2016 Permalink

              @pubdirltd – that’s not a feature WordPress needs. It’s one users want, and I want, but it’s in no way preventing the development of WP. Which works fine on 7. So again, if someone has a technical feature of 7 that we actually NEED, I’m all ears.

              Until then, we’re only 25% of the for million sites on the Internet. It’s a lot bigger ocean than just WP.

        • J.D. Grimes 2:27 pm on December 31, 2015 Permalink | Log in to Reply

          Yes. It allows us to more easily build OO code that can take advantage of autoloading. (Technically can be done now, but autoloading can be disabled below 5.3 so there has to be a backup plan for such cases.)

          Test and build tools and Travis CI will all be moving on. Travis already dropped support for 5.2 once and only brought it back mostly for WordPress.

          Neither of these things are necessities, but the extra burden on us all for supporting 5.2 is at some point going to surpass the burden of not supporting it. Maybe we aren’t there yet but waiting another year and a half for the number of site on 5.2 to drop to ~0 probably isn’t worth it.

        • Marcel Pol 11:17 am on January 4, 2016 Permalink | Log in to Reply

          To guard the users against security issues in PHP 5.2.
          Supporting 5.2 sends the message that is is a good idea to use it. Not supporting it anymore will make hosters upgrade their PHP and its security issues.

          • Scott Kingsley Clark 11:20 am on January 4, 2016 Permalink | Log in to Reply

            Text on Requirements page currently says:

            To run WordPress we recommend your host supports:
            PHP version 5.6 or greater
            MySQL version 5.6 or greater

            There are notes further below about support for 5.2.4+ but explicitly saying it exposes your site to security vulnerabilities.

            • summoner 11:37 pm on January 18, 2016 Permalink

              Well actually even PHP 5.5 is near its EOL so i think WP 4.5 should be able to check the server’s PHP version do the following:

              • upon WP’s installation process it should prompt the user that their server uses an EOL PHP version which technically is enough but may have security issues and the user should contact the hoster
              • when an already installed WP gets updated to WP 4.5 it should display a message with a link to detailed info. Similar to cookie notification bars. I would turn it on by default so that a very large number of WP users would contact their hosters (naturally this notification must be turned off extremly easy if the hoster just does not do anything)

              Here is why:

              • most average people will just try to install WP on their own and they will not ever read the requirements page on wordpress.org. So they will not know about security concerns of EOL PHP versions until their site gets hacked…
              • WP is the most widely used CMS and hosters are actually payed to maintain their services. Hosters who have PHP 5.2, 5.3. 5.4 installed should really have their investments payed back by now by their users so they really should be able to upgrade to at least PHP 5.6 (or even to 7) both technically and financially.

              Actually you can not sell a car if you KNOW that the safety belt is not strong enough and will be torn in case of an accident. Hosters who have only EOL PHP versions available do the exactly same thing and without some pressure they will be happy to continue that while collecting some more money from their customers.

            • summoner 12:10 am on January 19, 2016 Permalink

              Sorry, need to be some more exact:
              On upgraded installations the notification bar should be displayed even on the FRONT-END. That is why i compared it to a cookie notification bar. 😉

              I know that might sound as a no go for many of you, but that is why it should be extremly easy to turn off (ex under Settings->general). Otherwise hosters simply will not react as they did not even until now.

          • Ipstenu (Mika Epstein) 4:53 pm on January 4, 2016 Permalink | Log in to Reply

            Not supporting it anymore will make hosters upgrade their PHP and its security issues.

            I disagree. I think it’ll just make the users, not the web hosts, upset that they can’t use WP for reasons they don’t understand.

          • Jonathan Hefner 10:29 pm on January 6, 2016 Permalink | Log in to Reply

            Agreed. I also think that if it is *possible* to run WordPress on an unsupported PHP version, some hosts *will* do it, regardless of the security risks. And users will likely not know any better. And when said users are compromised, it is possible they will ignorantly blame WordPress itself.

            So +1 for bumping PHP version requirement (and even enforcing it with a version check).

        • jrf 2:48 am on January 6, 2016 Permalink | Log in to Reply

          Not so much PHP7, but a technical reason case can easily be made for moving up to PHP5.4, preferably 5.5 as that would provide access to the Intl extension which will enable much improved localization and internationalization functionality as well as better utf-8 support.

      • Sisir 8:54 am on December 31, 2015 Permalink | Log in to Reply

        +1 🙂 Although I don’t see it happening. -_-

      • askoxyz 10:58 am on December 31, 2015 Permalink | Log in to Reply

        Impossible for now, but a bump in requirements would be awesome.

      • Joost Abrahams 9:53 pm on January 5, 2016 Permalink | Log in to Reply

        As end user, non coder, small blogger, wide support for PHP is priceless. No hassle, just works.

    • Ryan Kanner 10:42 pm on December 30, 2015 Permalink | Log in to Reply

      Definitely adding orderby metadata for taxonomy -> https://core.trac.wordpress.org/ticket/34996
      Also would like to see some movement on the shortcake plugin. I think it’s pretty important for the future of shortcodes.

    • sosensible 10:43 pm on December 30, 2015 Permalink | Log in to Reply

      First, LOL Mike… I like the thought but that will be a few years before it happens.

      : : Seeing in 4.5 Notes : :

      • Shortcake plugin as part of the core.
      • Complete RESTful API

      : : Biggest Pain Points : :

      • WP_Query lacks rich relational function.

      : : UX : :

      • Any feature that runs slow is bad. Most companies who extend the page editor to the front side, outside the ADMIN are painful slow. Any speed gains in this area are big wins. While I am open in spirit we should make core perform so well those slow plugins are either dropped or fixed. 🙂
    • Dave Navarro, Jr. 10:44 pm on December 30, 2015 Permalink | Log in to Reply

      When adding new plugins and themes from the repository, I’d REALLY like to have the feature back where I can sort the search results by date, last-date-updated, number-of-installs, ratings, etc… I REALLY REALLY miss that functionality.

      If I upload a plugin or theme ZIP file and the plugin/theme already exists, instead of an error messages, can I be prompted to replace the existing plugin? I have several plugins from third-parties that I get by ZIP file.

    • J.D. Grimes 10:45 pm on December 30, 2015 Permalink | Log in to Reply

      Several tickets I’d like to see action on (no particular order):

      #31281 #34114 #33472 #25137 #27770

    • Matt van Andel 10:49 pm on December 30, 2015 Permalink | Log in to Reply

      I REALLY want to get #16031 finally taken care of. I have a very comprehensive patch uploaded as of last August that does the trick admirably. The alternative is an even more substantial refactoring of the admin screens to merge handling and redirect behavior into the WP_List_Table class(es). I’m happy to work toward the latter solution if necessary, but I think the previous patch is peachy keen as-is.

    • Howdy_McGee 10:53 pm on December 30, 2015 Permalink | Log in to Reply

      I’m a developer who, when I deploy and monitor a theme, like to keep `debug.log` on so I can continually keep any active themes in tip-top shape. My **biggest** peeve is when simple conditionals throw out general `non-object` errors from core `query.php`. There’s a pretty large list which can be found on trac but it doesn’t seem to have gotten a ton of notice ( https://core.trac.wordpress.org/ticket/29660 ).

      The biggest problem is it isn’t just one error, when one of these issues happen there’s at least 4 errors together which spam my error logs like crazy and I have to really hunt down what specifically is causing the issue in my theme. It’s a trial and error process to fix what should be non-issues which I would love to see go away.

    • Pascal Birchler 10:53 pm on December 30, 2015 Permalink | Log in to Reply

      A short list of things I’d be interested in working on:

      • Notifications API — @johnbillion mentioned this first and @rmccue is interested as well. To quote John: “I’m going to kill wp_mail() and replace it with an API.”
      • Improving support options in core: Send anonymous crash reports, search help resources from inside the admin, show videos from WordPress.tv, leveraging WordPress.org as an OAuth provider, etc.
      • Embeds template improvements
      • chriscct7 11:58 pm on December 30, 2015 Permalink | Log in to Reply

        I’d love to help out with Notifications API as well

      • Michael Beckwith 1:48 am on December 31, 2015 Permalink | Log in to Reply

        There’s already early work going on to do something similar with regards to email in BuddyPress. Very exciting.

      • Peter Wilson 4:00 am on December 31, 2015 Permalink | Log in to Reply

        I can help out on embed templates, Pascal.

      • J.D. Grimes 2:27 pm on December 31, 2015 Permalink | Log in to Reply

        +1 for notification API

      • mrjarbenne 4:59 pm on January 1, 2016 Permalink | Log in to Reply

        Has there been any thought to creating embed templates for post formats? Currently text is well supported, but post formats like video and audio create an embed with the post title only. I acknowledge the difficulty in this may be that the majority of these types of of posts are embeds from other sites (YouTube, Soundcloud, etc) which creates an embed of an embed.

      • dmsnell 6:05 pm on January 4, 2016 Permalink | Log in to Reply

        After having done work with notifications at Automattic, I’d be happy to help. Please feel free to ping me in Slack 🙂

    • Aaron Brazell 10:54 pm on December 30, 2015 Permalink | Log in to Reply

      Indexing of meta tables. I’d say that postmeta and usermeta (probably now tax meta) are increasingly important for complex client deliveries

    • petermolnar 10:54 pm on December 30, 2015 Permalink | Log in to Reply

      webmentions (https://wordpress.org/plugins/webmention/) as featured plugin as a future replacement for pingback.

      • dshanske 11:06 pm on December 30, 2015 Permalink | Log in to Reply

        As someone who has contributed to that plugin, made a general nuisance of myself trying to improve trackbacks and pingbacks as well to the point that people wanted to use linkbacks again….+1 if there is such an option. I’m a mediocre programmer, but I would work on such a feature plugin with a strong lead.

        • Daniele Scasciafratte 11:27 pm on December 30, 2015 Permalink | Log in to Reply

          maybe a pingback vs webmention explanation will be improve the propose to a feature plugin.

          • dshanske 12:22 am on December 31, 2015 Permalink | Log in to Reply

            A pingback is an XML-RPC request advising that another site has linked to your site. Your site then goes back and checks the accuracy of that request. The presentation of pingbacks in WordPress, quite frankly, is lacking. The […] presentation is pretty useless.

            Webmention is an update to that, using only HTTP and x-www-form-urlencoded content. (http://indiewebcamp.com/webmention-spec).

            Now part of this goes to the idea of improving Linkbacks, which have become a spammy cesspool that people do not want to play with. But it has a lot of potential.

            In practice, sites that receive webmentions look for microformats markup(or optionally other parsed elements) and use this to render a better response. The Semantic Linkbacks plugin(https://wordpress.org/plugins/semantic-linkbacks/) does this for all types of linkbacks.

    • rkoller 10:55 pm on December 30, 2015 Permalink | Log in to Reply

      Two of my biggest pain points are summed up by Jeff Eaton in the back-end part of the toast redesign article: http://responsivewebdesign.com/toast/backend/

      • The current templates are spaghetti code and could use some sanity with something like Timber/Twig
      • WordPress is badly missing the ability of structured data. You have to use Advanced Custom fields but the content is encoded only as text in the post meta table anway.
      • petermolnar 10:58 pm on December 30, 2015 Permalink | Log in to Reply

        +1 for a Twig based “official” theme.

      • davidshq 3:59 am on December 31, 2015 Permalink | Log in to Reply

        +1 for Twig
        +1 for more ACF functionality. Maybe just buy it out, if he’s willing? 🙂

      • Scott Kingsley Clark 4:55 pm on January 3, 2016 Permalink | Log in to Reply

        Structured data registered via Fields API would be a great next step, there are also plugins that let you create tables for your post type(s) and store those custom fields in a correctly typed DB column.

        • rkoller 12:40 am on January 5, 2016 Permalink | Log in to Reply

          i agree. but wouldn’t it be a reasonable move not to rely on plugins to create tables for the post types with the correctly typed DB columns for the custom fields; instead update the core db schema for wordpress? i know it would extend the scope of the fields api project. but if the fields api would take care of the proper encoding and db storage you would ensure to have a solid, stable and especially more performant foundation for the fields api as well as wordpress in general. better to have that kind of functionality in core than in a plugin?

          • Scott Kingsley Clark 5:37 pm on January 5, 2016 Permalink | Log in to Reply

            I definitely won’t be able to tackle database structures in the Fields API project, that’s far outside of the scope and there’s plenty of debate to be had that I’d rather keep out of 🙂

            Related though, I am the lead developer of the Pods Framework, a content development framework that allows you to create new / extend content types for WP. One of the options is to create a table for your custom fields which get their own DB columns correctly typed — or have a completely custom table outside of the Posts area called an Advanced Content Type.

            I know a thing or two about this, and there’s little or no inkling that the WP core team will be heading in a direction of table manipulation or db restructuring for custom fields in the near future.

            • rkoller 11:13 pm on January 5, 2016 Permalink

              yep i am aware that it is out of the scope of the fields api project; but i wanted to bring it up again in the 4.5 wishlist discussion so maybe some wp core team members might chime in and give it a second thought. cuz if all the new field types are brought in it would be a huge step in the first place but you would still have the issue jeff eaton brought up in the article with acf at the moment: “This isn’t a problem if you’re only using custom field data when a post is loaded and displayed. If you plan to use these custom fields to handle complex relationships—connecting a post to multiple authors, say—the SQL queries to handle that data will be punishingly slow.” but i will give the pods framework a try and see how things are handled there and how it goes with acf pro at the moment. thanks for the headsup. 🙂

      • Jonathan Hefner 10:33 pm on January 6, 2016 Permalink | Log in to Reply

        A huge +1 for both points. The article you linked was very insightful. Someone else in this thread mentioned #33472, which is relevant.

    • seanbennick 11:03 pm on December 30, 2015 Permalink | Log in to Reply

      Improved image management. WordPress is not just a blog anymore, so the date organization structure doesn’t work. Adding categories and maybe even tags for images would solve a lot of issues.

      • petermolnar 11:07 pm on December 30, 2015 Permalink | Log in to Reply

        You could add custom taxonomy for attachments.

        As for the filesystem layout, I’m already moving the genarated images away from the upload directory and I’d welcome this change to WordPress itself to keep the upload dir clean.

      • davidshq 3:59 am on December 31, 2015 Permalink | Log in to Reply

        +1 The Enhanced Media Library plugin is a great place to look to see some of the missing functionality.

      • vherring 5:42 am on December 31, 2015 Permalink | Log in to Reply

        My biggest wish for WordPress is some real work be done on the media library, it’s barely adequate and the management of hundreds of photos is difficult and you absolutely have to resort to a third party to manage thousands. The average blogger has that now days.

      • szabesz 7:34 am on December 31, 2015 Permalink | Log in to Reply

        +1 for this. I should also mention that storing the actual image files in one folder or in folders generated based on the month in which they were uploaded is just not enough. We should have more options, for example: images stored in folders we want to put them into. We should be able to define our own folder structure.
        Another thing is all those resized versions of the images. Other CMS’es store them in a subfolder like “_resampled” or similar. But WordPress makes a big mess by storing them alongside the original.
        And the third thing is gallery management, which is extremely basic. There is a lot of room for improvement is this area. No wonder every week a new gallery plugins is released… Developers are trying to solve it on their own way.

      • Paal Joachim Romdahl 9:48 pm on January 1, 2016 Permalink | Log in to Reply

        A big +1 to better media management!

      • MHagemeister 9:38 am on January 2, 2016 Permalink | Log in to Reply

        That’s my biggest issue with WordPress as well at the moment. I have a huge library with tons of images and the filesystem structure is a mess. Like others have already mentioned, I’d love to keep the uploads folder clean and put all resized media in a seperate “resampled” folder (or whatever it should be called)

      • taloweb 10:44 am on January 2, 2016 Permalink | Log in to Reply

        yes +1 also for me!
        A better media manager without plugins is a must now!
        A tight relation btw posts and media items and no more html insertion (by now to find where is used an image we have to use regexp on html), a robust cache sistem without resized images with size in filenames (when you change theme it is a pain), an easy way to find unused images to clear filesystem and so on…

      • danielgoze 10:08 pm on January 4, 2016 Permalink | Log in to Reply

        +1 Fully agree. Image Categories seem like a must for a site with more than 10 items in Media. Enhanced Media Library does have some great tools.
        Some Ideas I’ve had over the years:
        • Bulk edit to apply/remove image categories.
        • Possibly breakup Media into “views” of Images, Downloads & Video (in the menu rather than the pulldown filter) so that clients can find things easier.
        • Sometimes I hide images that I don’t want the client to change in the theme or a plugin, with the new site icon tool in the customizer, I wouldn’t want the client to go in and put in a much lower res file in when they feel like it, something like a checkbox for “admin only” for any images that the site relies on.
        • Crop for any size – I’ve seen the crop for thumbnail, but sometimes one size needs just a slightly different focus (example: a person is halfway cropped and if the crop started more to the left), especially now with the responsive images.
        • Other plugins already handle this, but regenerating thumbnails, renaming actual files, replacing files with a new file, and cleaning file names as a standard feature would really be appreciated.

      • htrex 11:06 am on January 5, 2016 Permalink | Log in to Reply

        +1 yes, an enhanced media library taxonomy is really needed

      • Anthony Hortin 5:05 am on January 7, 2016 Permalink | Log in to Reply

        +1 for this. Managing a large amount of images is so cumbersome and time consuming. The images library needs the ability to create folders along with being able to drag/drop images into those folders. The current Grid/List UI also needs to be fixed. There’s two completely different workflows, depening on whether you’re loooking at the Grid view or the List view and it’s makes the UI confusing. i.e. there’s multiple screens that perform the exact same function

      • Claude Martin 12:52 pm on January 7, 2016 Permalink | Log in to Reply

        +1 Media management needs improvementS. And thanks for all

    • Jeff Farthing 11:06 pm on December 30, 2015 Permalink | Log in to Reply

    • Dave Navarro, Jr. 11:08 pm on December 30, 2015 Permalink | Log in to Reply

    • Ipstenu (Mika Epstein) 11:16 pm on December 30, 2015 Permalink | Log in to Reply

    • Daniel Bachhuber 11:17 pm on December 30, 2015 Permalink | Log in to Reply

      As a co-maintainer of the Shortcake Feature Plugin, I’d like to get Official Core Direction on shortcodes and shortcode UI before we spend too much more time on it.

    • Daniele Scasciafratte 11:25 pm on December 30, 2015 Permalink | Log in to Reply

      Add get_post filter: https://core.trac.wordpress.org/ticket/12955 the patch is ready with case study and example use
      Introduce helper function for AJAX checks: https://core.trac.wordpress.org/ticket/25669 standardize the check of is an ajax request. patch ready
      Add hook for custom post.php actions: https://core.trac.wordpress.org/ticket/27056 help the plugin developers, patch ready

    • j-falk 11:27 pm on December 30, 2015 Permalink | Log in to Reply

      My wish-list:

    • Giorgos Sarigiannidis 11:29 pm on December 30, 2015 Permalink | Log in to Reply

      My list, starting from the most feasible and moving to the most controversial / impossible to happen:

      1. Better plugin management at the WP Dashboard, taking advantage of your wordpress.org favorites collection. For example, order your favorite plugins based on those that you install more often and allow batch install and activation of multiple plugins at once.

      2. Allow (and perhaps encourage) security adjustments during WP install, like setting a login url other than wp-login.php, disable XML-RPC, disable pingbacks, disable comments etc.

      3. Adding native support for content translation.

      4. Absorb CMB2 to the core.

      5. During WP install, allow us to choose our theme between twenty-whatever and underscore_s.

      6. Add “Child plugin” support, to allow overriding a plugin’s settings the same way we do it in themes, with child themes.

    • Jon Brown 11:29 pm on December 30, 2015 Permalink | Log in to Reply

      So many things… but
      #1 land the Fields API. It’s _long long long_ over due.
      #2 Finish out the REST API.
      #3 Improvements to media management (better CORE tools for organizing and managing large asset libraries).
      #4 Improved image editing and flow. I for one didn’t really like the direction Image Flow was going, but incremental improvements would be welcome.

    • andreasnrb 12:01 am on December 31, 2015 Permalink | Log in to Reply

      #1 custom comment types

    • simonrcodrington 12:29 am on December 31, 2015 Permalink | Log in to Reply

      I’m always pretty keen for additional hooks and filters in the admin area to customize the way the UI works. For example adding new hooks into the new media modal window (https://core.trac.wordpress.org/ticket/35205)

      I’m keep to chase this up (as literally it’s just a quick edit to a few template files in core).

      Love to see more hooks and filters that give me the power to change up and extend the way WordPress does stuff.

    • davetgreen 12:34 am on December 31, 2015 Permalink | Log in to Reply

      Add a ‘Last Updated’ timestamp for each and every plugin in the list of installed plugins, so that admins can see at a glance how long it has been since an update. This way they can make an informed decision as to whether the plugin needs to be replaced by an alternative or not. The security implications of reducing the number of extremely outdated plugins are obvious. 🙂

      A nice to have would be a check carried out by WordPress that alerts the user if the plugin hasn’t been updated in X time frame: possibly 2 years as per the .org repo warning.

      I plan on working on this early in 2016 as my first WP commit proposal. 🙂

    • mbrsolution 12:49 am on December 31, 2015 Permalink | Log in to Reply

      I am sure many have asked this before or it maybe included already in the next version. I would really like the ability to upload an image or photo to the profile without using a plugin, a function and or without having to sign up to gravatar under discussion -> Avatars. …..sorry for this basic request.

      Thank you all for the great work you all put in with developing WordPress…….

    • ChokDK 1:32 am on December 31, 2015 Permalink | Log in to Reply

      I wish there was some kind of help for the “pro theme makers” so adjustment of 3/3 columns spacing/width would be easy and still responsive.
      For now, they don’t dare to make it user adjusted.

      I also wish the Soundcloud pre-picture for 1/3 columns could be resizeable instead of disappearing (as it is working now)

    • Amanda Rush 1:33 am on December 31, 2015 Permalink | Log in to Reply

      I’d like to see post formats given some serious attention. I don’t think they should be left up to theme authors without any kind of guidance as to how they should be handled, ETC. I’d be willing to work on this as I use them quite frequently.

    • KARTHOST 2:10 am on December 31, 2015 Permalink | Log in to Reply

      You asked for a Wish list here it is:

      1) Finish Rest API

      2) SIMPLE SSL Set up, example:
      In Settings
      [ x ] No HTTPS
      [ ] HTTPS Admin Only
      [ ] HTTPS Entire Site

      Make it that simple for the end user.

      3) Built in SMTP to allow site owner to set up a 3rd Party SMTP service (allow SSL Port 465 as well) and disable wp-mail.php or just use wp-mail.php (you can default to wp-mail.php, but email sending should be something related with core and have a choice as to what type service to be used.
      3a) Create email template and allow end user the ability to customize the content in the default emails WordPress install sends out and the email headers.

      Thanks for all considerations

      Roy Randolph

      • J.D. Grimes 2:30 pm on December 31, 2015 Permalink | Log in to Reply

        +1 for better SSL support. It seems like a black box to me, and I’m a dev. 🙂

      • Nico 11:08 pm on January 1, 2016 Permalink | Log in to Reply

        With HTTP/2 only working over SSL I suggest people move to HTTPS only and drop http and set their servers/move hosts if necessary for it.

        There is a useful wp-config setting `define(‘FORCE_SSL_ADMIN’, true);` with that setting it would prevent insecure admin in case of a mis-configured server. This is basically your `[ ] HTTPS Admin Only`.

        As for SSL config its pretty much a server setup thing that has nothing to to with WordPress, you setup your server to server over SSL and then switch the site URLs in the WordPress config from http to https. So I see no need for WordPress to do more then its already doing.

      • thomaswm 5:14 pm on January 2, 2016 Permalink | Log in to Reply

        +1 for simple SSL support. It will become really important now that Let’s Encrypt is handing out free SSL certificates.

        https://core.trac.wordpress.org/query?status=!closed&keywords=~https

      • nathangraham 4:56 am on January 3, 2016 Permalink | Log in to Reply

        +1 for simplifying SSL set up

    • chrishoward 2:17 am on December 31, 2015 Permalink | Log in to Reply

      • Media categories. Pleeeaasse!
      • Hooks on the post listing and post editor screens for displaying instructions or other info to users. This is especially useful for custom post types. Currently I hack into the views-edit-{cpt} and edit_form_after_title hooks, but that’s not tidy.
      • More and better use of contrast and colour in the admin UI. I know minimalism is all the rage, but that doesn’t make it good UX. e.g. The post editor meta boxes could do with stronger headers as almost every thing in the post editor is black/grey on white. The visual hierarchy of WP admin varies from minimal to too subtle.
    • Ben Hansen (ubernaut) 2:19 am on December 31, 2015 Permalink | Log in to Reply

    • Mike Schinkel 2:48 am on December 31, 2015 Permalink | Log in to Reply

      Definable Image Types and associates sizes for those types.

      Rather than have all images have all sizes, frequently is is helpful to design a `’hero’` as having one set of sizes and a `featured-story` as another set of sizes and so on.

      • Andrew Nacin 11:49 pm on January 1, 2016 Permalink | Log in to Reply

        I’ve always liked this in theory, but I’m not sure how you’d auto-magically choose which image gets which treatment. (Beyond say featured image, which has its own UI.)

        I’d be more inclined to spend time to make it so WordPress creates crops only when we need them, and not on upload. We could create a thumbnail and a silver master that is a bit smaller and thus easier to work with from the original, and then generate crops when we need them. (We can even fake non-proportional crop previews using canvas or something else.) This is something we’ve talked about extensively, and notably, @mikeschroder happened to be one of the people who instigated those conversations (and who shepherded WP_Image_Editor into core).

        • heintore 3:00 pm on January 5, 2016 Permalink | Log in to Reply

          @nacin – we’re using the OTF Regenerate Thumbnails plugin extensively on our clients’ sites. It works exactly as advertised by generating images on the fly. No custom functions needed, all calls to the_post_thumbnail and other thumbnail functions are handled automatically.

          There may be plenty of reasons why this particular approach is a terrible solution for WordPress core, but I’m much preferring this plugin over how WordPress handles crops now 🙂

          https://wordpress.org/plugins/otf-regenerate-thumbnails/

      • Joe McGill 9:46 pm on January 2, 2016 Permalink | Log in to Reply

        I’ve thought about having a custom image size created when an image is added as a featured image to a specific post type. Maybe something like that could work?

      • Brad Touesnard 12:38 pm on January 7, 2016 Permalink | Log in to Reply

        +1

        #11895 is related to this and I suggested the same solution:

        > I think there is certainly a need for a “treatments” concept that is independent of size though. For example, it’s pretty common to want to crop a photo a certain way for display on a listing page (e.g. post archive page) but display the uncropped version on the detail page (e.g. single post page). I’m guessing that was the original intention of the “Apply changes to:” feature, but it never really hit the mark.

    • dryanpress 3:13 am on December 31, 2015 Permalink | Log in to Reply

      • SVG Dashicons
      • Update on direction of shortcodes in core and Shortcake
      • WP Admin Toolbar Improvements (https://core.trac.wordpress.org/ticket/32678). Proposed i10 changes look great, love increased negative space, but even fewer sites would be listed in view. A live search and list of recently updated and/or pinned sites would go a long way in moderate and large networks.
      • Native multiple authors for Posts. Co-Authors-Plus may add this in plugin territory, but subsequent integration into a theme requires complicated overriding or child theming. Giving non-developers the ability to add multiple authors on Posts, Books, Report Chapters, Music Videos, etc is important.
    • Peter Wilson 4:08 am on December 31, 2015 Permalink | Log in to Reply

      My wish list/hobby horses:

      • #35206 to control white space in menus, as a follow up to #27762 in 4.4 and later reverted.
      • #32793 to combine jQuery and jQuery migrate and reduce HTTP requests.

      Otherwise, some of the tickets around HTTP2 would be lovely to get in.

    • WP Sites - Brad Dalton 7:11 am on December 31, 2015 Permalink | Log in to Reply

      1. I’d like to be able to wrap opening and closing php tags in code tags using the text editor and 2. link gallery images.

    • Marius (Clorith) 7:39 am on December 31, 2015 Permalink | Log in to Reply

      I’d love to see some kind of merge between #20578 (the option to not trigger `uninstall.php`) and #9757 (better handling of uploads when the theme/plugin exists).

      As it stands it’s painful having to change to a different theme to update a custom theme. The process was made slightly better by core remembering widgets, but you still need to change the look of your site for a period of time while uploading and re-configuring and it is a terrible user experience.

      Of course, premium themes often leverage some filters to apply updates, but imagine the sites that run old premium stuff that are avoiding updating because it’s a tedious process, and the presumably large amount of them that don’t have this filter interaction any way.

    • Rian Rietveld 7:51 am on December 31, 2015 Permalink | Log in to Reply

      The Accessibility team focusses for this release on:

      • Make the colors of the default Admin scheme conform to WCAG 2 AA (tickets are labeled #a11y-color)
      • Remove title attributes from links
      • Improve the accessibility of the customizer (for keyboard only, screen readers and for color contrast)

      Help with this is very welcome.

    • leemon 8:22 am on December 31, 2015 Permalink | Log in to Reply

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

    • Sisir 8:32 am on December 31, 2015 Permalink | Log in to Reply

      I would love to see my reported bugs are resolved 🙂

      1. https://core.trac.wordpress.org/ticket/24990
      2. https://core.trac.wordpress.org/ticket/35216
      3. https://core.trac.wordpress.org/ticket/32920

      I don’t have #slack account. Never got my invitation. #2 is most critical if not all 😀

    • Martin Stehle 11:09 am on December 31, 2015 Permalink | Log in to Reply

      Please make Google Fonts in the backend and Emojis available only by activated checkboxes. Both features are on by default and generates dispensable traffic.

      More about the Google Fonts issue at ticket https://core.trac.wordpress.org/ticket/26072

      • askoxyz 11:17 am on December 31, 2015 Permalink | Log in to Reply

        +1

      • petermolnar 12:23 pm on December 31, 2015 Permalink | Log in to Reply

        YES, PLEASE.
        ( And that same for EVERY feature that is addon-level, like embed )

      • Last Rose Studios 3:43 pm on January 4, 2016 Permalink | Log in to Reply

        +1 Get rid of emojis – the fact that there area bunch of plugins and how-tos on how to remove them should be a clear indication that people don’t want them. There is no reason something like that should be in the core. At the very least, make it optional (activated only by checkbox).

    • Martin Stehle 11:25 am on December 31, 2015 Permalink | Log in to Reply

      Please make tags hierarchical like categories

    • Gerard Canters 12:20 pm on December 31, 2015 Permalink | Log in to Reply

      RFC:

      WP 4.3 accepted shortcodes with a tag containing a space, WP 4.4 does not. Also, you don’t get an error message or indication.
      Suggest to have add_shortcode funtion return a true result or an error-indication.
      In general should all functions return a true result or error.

    • benoitchantre 1:26 pm on December 31, 2015 Permalink | Log in to Reply

      I would like to see responsive image header and a drag and drop UI to reorder pages and custom post types.

    • Andrea Fercia 1:45 pm on December 31, 2015 Permalink | Log in to Reply

      1) Settings API: get rid of the tables and UI/accessibility improvements
      https://core.trac.wordpress.org/ticket/18801
      https://core.trac.wordpress.org/ticket/16413

      2) Re-think `$content_width`
      We’re in a “responsive era”, maybe re-think the whole idea of `$content_width` ? Some comments collected in the past months:
      https://core.trac.wordpress.org/ticket/21256#comment:25
      https://core.trac.wordpress.org/ticket/23863#comment:10
      https://github.com/Automattic/_s/issues/100#issuecomment-40746610
      https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2013-04-11&sort=asc#m593089

      3) Add a “typography” focus on Trac 🙂

      • Nico 11:20 pm on January 1, 2016 Permalink | Log in to Reply

        Totally agree with $content_width. I always hated that thing, even when not thinking about responsiveness.

      • robertwhitis 8:15 am on January 4, 2016 Permalink | Log in to Reply

        Along the lines of eliminating tables, the admin CSS classes need support for columns. An example would be the use of a jQuery repeater for a row of fields. There’s not really any built in support for a go-to way to handle columns currently that I am aware of.

      • Ahmad Awais 5:40 pm on January 4, 2016 Permalink | Log in to Reply

        +1 for #2.

    • tomdxw 2:21 pm on December 31, 2015 Permalink | Log in to Reply

      How about bcrypt? https://core.trac.wordpress.org/ticket/21022

      It’s a one-line change and it’ll make a huge difference to the security of 89% of WordPress sites (PHP 5.2 doesn’t support bcrypt, but PHPass falls back to using the old algorithm in that case).

    • Dave McHale 3:53 pm on December 31, 2015 Permalink | Log in to Reply

      One of the biggest complaints I hear from my users is the menu management tools in the admin. A CMS website with a moderate number of pages quickly becomes incredibly difficult to manage. An overhaul there is long overdue IMO.

      The classic widget management tools are equally frustrating to work with, but I think core is already on a path towards getting away from that screen as much as possible – so I don’t know if updates there are really worth time/attention.

      • Andrew Nacin 11:30 pm on January 1, 2016 Permalink | Log in to Reply

        I think a new exploration in menu management would require building an update as a plugin using the feature plugin model.

        Have you looked at menu management in the customizer? I feel like I prefer it. I agree it still becomes tough to work with, with a lot of pages, but have you ever used a menu-building experience that works well with a lot of pages? Actually, have you ever used a menu (as a user) with a lot of pages?

    • Najum Rahim 4:17 pm on December 31, 2015 Permalink | Log in to Reply

      My wishlist
      WP REST API

    • Scott Kingsley Clark 5:16 pm on December 31, 2015 Permalink | Log in to Reply

      I’m totally all about Fields API, there’s just a little bit more left to do and I’ll have it in a place where it’s ready for core proposal!

    • colomet 5:32 pm on December 31, 2015 Permalink | Log in to Reply

      If Photon can not refresh the pictures (in case we do changes). I preffer not to have photon and to have my own CDN.

    • colomet 5:33 pm on December 31, 2015 Permalink | Log in to Reply

      · Speed
      · Lower use of resources

      • Andrew Nacin 11:32 pm on January 1, 2016 Permalink | Log in to Reply

        These are nice wishes, but we realistically need concrete proposals for how to get there. For example, I pull up WordPress in KCacheGrind quite often when contributing, to identify bottlenecks and potential areas for improvement.

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

    • askoxyz 6:12 pm on December 31, 2015 Permalink | Log in to Reply

      Move WP Comment Humility (https://wordpress.org/plugins/wp-comment-humility/) to core, which moves the Comments top level menu under Posts top level menu, where it belongs now that comments are off on Pages by default.

      • Andrew Nacin 11:38 pm on January 1, 2016 Permalink | Log in to Reply

        I saw this proposal on Twitter the other day. I actually like it in theory, but:

        • It would probably be jarring/confusing for a lot of people who don’t know where their comments menu went. (This is a solvable problem, of course.)
        • If a custom post type supported comments, then what? (It could always move back. There’s of course been talk that comments should possibly be moderated per post type, but that gets annoying when all you have is posts and pages and you do use comments on pages — admittedly rare.)

        This absolutely could only be done if there was extensive usability testing with various scenarios that can back up the decision.

    • Ipstenu (Mika Epstein) 7:33 pm on December 31, 2015 Permalink | Log in to Reply

      Posts like this very one make me think that Emoji Reactions should be a thing. If we could all click an emoji +1/-1 (thumbs up/down) to vote, it would be so lovely.

      https://wordpress.org/plugins/emoji-reactions/ ? Pull that in? 😀

    • George 5:40 am on January 1, 2016 Permalink | Log in to Reply

      https://wordpress.org/plugins/custom-upload-dir/

      Add similar functionality to core.

    • luciole135 8:38 am on January 1, 2016 Permalink | Log in to Reply

      Hello,
      I hope to ask the right place unless I should not open a ticket for this?
      Some hosts including mine do not allow REWRITE RULES in the .htaccess file.
      It would be good to check before writing to it if the mod_rewrite is enabled before writing in the .htaccess because it induces 500 errors.

      • John Blackbourn 6:07 pm on January 4, 2016 Permalink | Log in to Reply

        Please open a ticket on core.trac.wordpress.org for this, with as many details as you can. The .htaccess handling code has been in WordPress for the best part of a decade, so it should be pretty stable by now, and there are lots of failsafes in place to prevent such 500 errors.

    • Ulrich 9:56 am on January 1, 2016 Permalink | Log in to Reply

      #32802: Update Masonry (v3.3.2) & imagesLoaded (v3.2.0) package
      #30797: New function for parent theme stylesheet uri
      #33407: Theme tags overhaul
      #26695 Themes: add support for multiple screenshots in themes
      #21256 New theme feature – add_theme_support( ‘content-width’, $defaults )

    • benoitchantre 1:13 pm on January 1, 2016 Permalink | Log in to Reply

    • szaqal21 1:21 pm on January 1, 2016 Permalink | Log in to Reply

      Add filter for _get_list_table() to allow using extended WP_Posts_List_Table class for edit screens, now it is hardcoded!

    • szaqal21 6:11 pm on January 1, 2016 Permalink | Log in to Reply

    • Maren-Reinecke 9:00 pm on January 1, 2016 Permalink | Log in to Reply

      1) I would very much appreciate a file manager for the media! As a photographer I have quite a lot of media and it´s not usefull to have them monthly organized…
      2) For the meta tags an opportunity to add noarchive, my old website worked with index, follow, noarchive, because I don´t want my media in google archives.

      Thanks for taking notice 🙂

      Maren

    • Paal Joachim Romdahl 9:53 pm on January 1, 2016 Permalink | Log in to Reply

      Thanks for asking Mike!

      Drag & drop of All posts/pages/categories.
      Finally getting this trac ticket feature in place: https://core.trac.wordpress.org/ticket/2702

      Additional field options in the customizer. Adjusting site title, description menu etc. As it would make simple design adjustments easier for the beginner without having to get into coding

      That’s all I can remember off the top of my heard right now!

      Happy New Year to everyone!!..:)
      What an awesome year this will become!!

    • davidperez 9:57 pm on January 1, 2016 Permalink | Log in to Reply

      Hello, Have a Button to Update everything: Plugins, Themes and Languages.

      Nice Work!

    • davidperez 10:02 pm on January 1, 2016 Permalink | Log in to Reply

      Another Idea would be Edit Taxonomies as full editor: Thumbnail, WYSIWYG Editor, …

    • christinecooper 10:39 pm on January 1, 2016 Permalink | Log in to Reply

      My wishlist for 4.5 is mainly implementing the fixes that have already been provided to numerous bug tickets.

      For example, view the following ticket:
      https://core.trac.wordpress.org/ticket/15448
      Which I outlined here:
      http://wordpress.stackexchange.com/questions/191923/sending-multipart-text-html-emails-via-wp-mail-will-likely-get-your-domain-b

      That’s only an example. There are too many tickets like these which have been laying there, with completely appropriate solutions, and no sight in adding these fixes to core.

    • luciole135 6:43 am on January 2, 2016 Permalink | Log in to Reply

      Add a third markdown text editor next to the two existing.

    • bonger 9:15 am on January 2, 2016 Permalink | Log in to Reply

      Bugs. 4.4 squashed around 600 gross. A similar drive now would be very worthwhile.

    • Frank Bueltge 1:23 pm on January 3, 2016 Permalink | Log in to Reply

      Wishs are fine, but goals are important.

      • Multisite Maintenance

      ** Like Settings API and much more equally single core.

      • Fields API
      • Notification API ( kills wp_mail() )
      • Working with priority on open bugs.
      • Relationship table, Post2Post – also about the network of Multisite
    • seanbennick 1:31 pm on January 3, 2016 Permalink | Log in to Reply

      I would also like to see Widgets that can be created once and used across multiple sidebars, footers, etc. Widget Builder – https://wordpress.org/plugins/widget-builder/ takes a decent step towards this, but I think this would be a solid addition to the core.

    • Pam Blizzard 7:45 pm on January 3, 2016 Permalink | Log in to Reply

      Please give me an option to hook and/or filter the Cheatin’ eh message. When delivering WP as a CMS, it’s too perplexing for the users and they don’t know what to do next. Give me an option to put meaningful instructions for my users on how to move forward or get help.

      • J.D. Grimes 5:01 pm on January 4, 2016 Permalink | Log in to Reply

        See #14530

        • Pam Blizzard 12:47 am on January 5, 2016 Permalink | Log in to Reply

          I respectfully disagree that it’s fixed, if the message, “Cheatin’, eh?” displays anywhere on a website that doesn’t belong to a WordPress developer.

      • John Blackbourn 6:11 pm on January 4, 2016 Permalink | Log in to Reply

        Do your users regularly see this message? If so, the root cause should be investigated because ideally no user should ever see this message.

        • Pam Blizzard 12:53 am on January 5, 2016 Permalink | Log in to Reply

          No, not regularly, but once is too much IMO. I have had clients email me from time to time upon receiving it and it’s embarrassing, when I have to explain that it’s considered “funny”. I get the joke, but they don’t. The message is not truly helpful, in any way. I know we can do better, and I’m willing to help in any way that I can.

          • Ipstenu (Mika Epstein) 5:33 pm on January 5, 2016 Permalink | Log in to Reply

            Pam, how/when/where are they seeing this?

            Becuase John’s point is that they NEVER should be able to see that. And it indicates something serious is behaving in an unexpected way 🙂 While agreeing that the message should be filterable, we still want to understand the circumstances that make it happen so we can possibly fix THAT too.

            (Of course if it’s ‘a plugin is doing something daft, we may not be able to, but it helps us understand the root cause.)

            To quote Nacin from the trac ticket:

            This warning should never be accessible via the UI. These are nothing more than sanity checks. If they can be accessed in a normal setup via the UI then that is a bug.

            So while it perhaps should be filterable, there’s an underlying bug there. That’s why the initial trac ticket was resolved with “Provide more helpful feedback than just “Cheatin’ uh?” for permission errors in wp-admin/js/customize-controls.js.”

            The bug, the part where people could legit click a link and get there, was fixed.

            Where are you running into this? What are your users doing?

            • Pam Blizzard 5:16 pm on January 6, 2016 Permalink

              I myself got it 3 days ago, when my browser hung after deleting a theme, and I hit refresh. Being experienced, I knew what it was and what the next step was. However, I’ve had 3 phone calls from clients about it in the last year, (prefer not to detail what caused it here, but can if really necessary) they just didn’t know where to go next.

              I searched Twitter, wpStackExchange and WP.org support on that term and found people posting about it within the last few months. The point is, it does appear.

              I’m trying to understand why it’s hard coded 34 times, http://bit.ly/1mGhBwp if it’s not needed, and “shouldn’t appear in the UI”

              Again, I’m willing to help out in any way I can. I’m not just kvetching, I’m here to learn and help.

          • Ipstenu (Mika Epstein) 5:21 pm on January 6, 2016 Permalink | Log in to Reply

            I myself got it 3 days ago, when my browser hung after deleting a theme, and I hit refresh.

            Yeah, that’s one of those cases where we can’t really avoid it. Let me guess, you force quit the browser and reopened with extant tabs? So WP tried to reload with an expired nonce. (Which is personally why I think this message should be filterable/customizable – unavoidable browser crashes happen. We didn’t used to have our browsers be able to reopen all tabs when restarting… Ahh the old days.)

            Can you tell us, in general terms, what the users were doing? Uploading a file, trying to use a specific plugin? I totally get that you can’t give us details 🙂 But if we can narrow down if a plugin is derping or if there’s a legit bug in WP, it helps.

            • Pam Blizzard 12:54 pm on January 7, 2016 Permalink

              I appreciate very much that you’re willing to troubleshoot the problem, and another venue like the support forums is probably more appropriate, and I will open a thread there. My point for the Wish List: The error message displays and is not worthwhile in any way, and in fact detrimental, because “Cheatin’, eh/uh?” is cutesy, flippant, accusatory and snarky and not indicative of the professional tool that WordPress is. If those 34 instances of that literal exist, let’s at least replace them with something like, “something unexpected happened, please return to your Dashboard or contact your support resources.” or something similar that helps the user go to the next step.

    • Spacedmonkey 8:11 pm on January 3, 2016 Permalink | Log in to Reply

    • Knut Sparhell 10:45 pm on January 3, 2016 Permalink | Log in to Reply

      Core framework for multi-language
      Fields API
      Continued Multisite cleanup
      Remove Post-by-email in favor of plugins
      Tool to convert Links to Menus, in preparation for removing Links in a later release
      Continued user facing options cleanup
      Unmanaged/private plugins marker
      Install multiple plugins
      Implement REST API endpoints
      New strategy for bumping requirements
      Framework for 2-factor authentication
      Better password hashing
      Frontend editing of posts (text)
      Customizer: Point at any customizable element to open it
      Customizer: Partial refresh

    • robertwhitis 8:27 am on January 4, 2016 Permalink | Log in to Reply

      I’m always happy to see work put into multisite.

      Domain mapping in core would be huge.

    • rgllm 11:02 am on January 4, 2016 Permalink | Log in to Reply

      User roles.

    • nealumphred 1:35 pm on January 4, 2016 Permalink | Log in to Reply

      Return the VIEW POST option to the Admin Panel so that it can be seen and used after a post has been published.

      • John Blackbourn 6:13 pm on January 4, 2016 Permalink | Log in to Reply

        There are already two (or three, depending on the action) links to view the post from this screen. The ‘View Post’ link in the admin toolbar, and the permalink itself. Removing it was intentional. See #18306.

    • Ahmad Awais 5:54 pm on January 4, 2016 Permalink | Log in to Reply

      Late to the party. I’m looking forward to so many things in 4.5.

      — WP REST API (Of-course!)
      — Fields API (This is a long time coming and is a much-needed improvement)
      PHP Templating Engine Twig could be perfect
      Safe Mode Run
      — Weston Ruter’s idea of adding Add New Post/Page to the customizer
      — UX: I like how easily we can drag & drop images to upload them (Media -> Add New) Screenshot ,maybe we can have a similar drag & drop plugin and theme installer (Plugins -> Add New area)

      That’s all for now.

    • whizadree 5:54 pm on January 4, 2016 Permalink | Log in to Reply

      would like to see 2FA, Recaptcha as core spend much more time with user security and encrypting data within the database (no plain text info ) , more Customization for Admin without plugins , ( customize menus , custom links , hide unused ) , a core file manager with option for changing permissions and warning of security risks for both files and folders as core (with additional plugins to increase usage ) , better admin of sites using mobile devices such as a full WordPress mobile app the manage the system and install plugins from qr codes , and find a proper way to stop fake accounts / users

    • freetheweb 6:19 pm on January 4, 2016 Permalink | Log in to Reply

      • Custom CSS editor in the Customizer instead of having to install Jetpack
      • Enhanced Admin UI
      • Now that WordPress has established itself as a full CMS for the web, I think we should have custom taxonomies as part of the default admin options instead of having to install third party plugins to set them up, which is often confusing
    • Arunas Liuiza 7:16 pm on January 4, 2016 Permalink | Log in to Reply

      My biggest pain point is not in the features/code at the moment, but in the lack of documentation, particularly, on the JavaScript part of things – WP Editor, Media Manager, etc.

      On the code part of things, I’d love for wp_editor to have a flag to return its content instead of echoing everything all the time. I get tired of playing with `ob_start()` and friends every time I need to use it in some callback function or other.

    • calendarboy 12:38 am on January 5, 2016 Permalink | Log in to Reply

      I would like to be able to sort users by name, or by address

      On the Users page it appears you can sort by name, but it does not work. Instead, selecting Name actually just sorts on Username.

      I would like to be able to sort users by Name and by address.

      I have deleted over a thousand bogus “users” created by bots (despite using a catcha) over the past two days. It has taken hours and I’m nowhere near being done.

      With the ability to sort Users, I could have deleted all of the bogus entries in minutes.

    • Andrew Wilder 1:24 am on January 5, 2016 Permalink | Log in to Reply

      Right now, comments can only by linked to by using an anchor tag, and if the pagination is ever changed, then the anchor reference will be broken.

      I’d like to see comments get their own permalink structure — so links to specific comments will stay valid if the pagination ever changes. (I’ve run into changed pagination many times… maybe a site owner changes the comment display order, or changes the number of comments per post, or some comments get deleted, shifting them up to a new page…there are lots of ways the structure of http://oursite.com/blog-post/comment-page-5/#comment-12345” can break over time.)

      https://core.trac.wordpress.org/ticket/26133#comment:3

    • Daniel Llewellyn 4:31 am on January 5, 2016 Permalink | Log in to Reply

      selfishly I’d like #29325 to be merged, so I can wear a new contributor badge with pride 😀

    • Marko Heijnen 6:49 pm on January 5, 2016 Permalink | Log in to Reply

      • More control for images

        • Ability add more information for an image size like quality or zoom
        • Add the image size to the filters for responsive images. width/hight simply doesn’t work
        • Ability to auto generate images and to stop them from getting generated. Internal API which by default is off. Will makes things easier for plugins since internal APIs need to be changed.
        • non web image like Tiff converting to JPG (imagick).
        • Other cool imagick tricks to generate a thumbnail for PDF’s for example
      • XML-RPC component cleanup. What can still be done or where will the REST API be good enough. Making hard cuts.
    • benoitchantre 10:03 pm on January 5, 2016 Permalink | Log in to Reply

      #29783: User Admin Language

    • Nicolas Juen 10:22 am on January 6, 2016 Permalink | Log in to Reply

      More modern tools support :

      • Composer
      • Namespacing
      • Autoloading

      And potential muliple levels of themes, at least allow locate_template working on more than 2 folders with a hook to edit the paths available.

      • Nicolas Juen 10:24 am on January 6, 2016 Permalink | Log in to Reply

        And at least unified fields management (options,users, * meta ) with the currently developping Field API 🙂

    • Zwaar Contrast 2:10 pm on January 6, 2016 Permalink | Log in to Reply

      I’d like to be able to hook into the image editor!

    • Mel Choyce 7:20 pm on January 6, 2016 Permalink | Log in to Reply

    • Ryan Boren 8:11 pm on January 6, 2016 Permalink | Log in to Reply

      Some usability focused wishes.

      We’re WordPress and all about the open web. The open mobile web is rather a mess. The open web needs to be great on mobile, and WordPress can help make that happen.

      https://make.wordpress.org/flow/2015/06/13/the-top-5-impediments-to-flow-on-touch-devices/

      I arrive at WP sites through Twitter and other apps on my touch devices. Lots of people do. We come out of our apps, land on a site, touch an image, and get a bad experience. WP sites have poor media touch flow.

      https://make.wordpress.org/flow/windmills/#carousels-and-touch-media
      https://make.wordpress.org/flow/2015/02/26/core-support-for-wordpress-images-to-open-in-a-modal-window/

      The toolbar is overdue for an update. I like where this ticket is going.

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

      Retire media-new.php.

      https://make.wordpress.org/flow/2015/01/29/retiring-media-new-php/

      Continue reducing settings.

      https://core.trac.wordpress.org/ticket/32396
      https://wordpress.org/plugins/wp-core-settings-reduction-project/

      Keep advancing the customizer and live preview.

    • Grant Palin 10:44 pm on January 6, 2016 Permalink | Log in to Reply

      • native post relationships
      • ability to regenerate specific image thumbnails and not the whole lot
    • Rich Tabor 11:48 pm on January 6, 2016 Permalink | Log in to Reply

      How about a drag-and-drop-in-place element for the Featured Image metabox (like what we have for the post editor)?

    • Anthony Hortin 5:38 am on January 7, 2016 Permalink | Log in to Reply

      • Redesigned/improved Image Library along with the ability to create folders.
      • Fix the Image Library Grid/List UI so there’s not multiple screens that perform the exact same function. The whole Gird/List UI has been a mess since the Grid layout was introduced.
      • Customizer redesign including the ability to default to wider 2 column layout so you’re not scrolling for pages and pages when there’s heaps of options.
      • Better consistency with Customizer UI. Sometimes you click a button and more fields appear below it. Other times you click a button and a panel slides in and out of view. Sometimes when you click a button, the panel slides to the left, other times it slides to the right. Users shouldn’t have to wonder what’s going to happen when you click a button.
      • Better notification experience. Too many plugins/themes are cluttering up the WordPress Dashboard with multiple and constant notifications.
      • Redesign of the Show Password/Hide/Show/Cancel/Generate Password buttons on the User Profile screens. The UI is confusing and there are too many unnecessary buttons.
      • Anthony Hortin 6:45 am on January 19, 2016 Permalink | Log in to Reply

        Adding to my list above…

        • The ability to be able to upload AND overwrite existing plugins. So Annoying not being able to upload newer plugin versions through the dashboard and simply overwrite the old version
    • Ross Wintle 9:41 am on January 7, 2016 Permalink | Log in to Reply

      • Any movement towards an efficient API for post-to-post relationships
      • Now that the REST API is (nearly) here, we should start improving the core UI. Could we start by using AJAX for pagination/sorting/filtering on list tables
      • TWIG-like templating. Or at least, some API that enables us to better separate logic and display. Currently I can use things like the query var to pass data to a template (as documented in the codex page for get_template_part: https://codex.wordpress.org/Function_Reference/get_template_part#Passing_Variables_to_Template) but it would be nice to have a data API or some way to pass data to templates. WP isn’t MVC so I’m not entirely sure what this would look like.
      • Ability to both install and upload multiple plugins in one go, and to overwrite existing plugins (for when you’re uploading an update to an existing plugin)
      • Ability to set login/dashboard URL as part of core
    • Lisa 1:49 pm on January 7, 2016 Permalink | Log in to Reply

      Let’s make notifications a thing of delight for the user.

      Can we have a universal inbox for them, and maybe add Wapuu or something that makes people smile. Like – https://cloudup.com/cQtJsMhtf0L

    • HoaSi 11:07 pm on January 11, 2016 Permalink | Log in to Reply

      Further improvement to https://core.trac.wordpress.org/ticket/26937 would be nice.

    • Tim 1:58 pm on January 12, 2016 Permalink | Log in to Reply

      The top pain point for me and my clients is probably management of the media library (as mentioned by lots of others); I’d love to see that a priority.

      Other things I routinely install plugins for, and would love not to have to:

      • Tree view and drag-and-drop sorting of pages (and posts and other types)
      • Global disabling of the comment system for sites where comments are irrelevant
      • Adding featured images to taxonomies
      • Using a visual editor for taxonomy descriptions

      Nice as it would be to have multi-language and page-by-page permissions in core too, I do realise that these are huge endeavours and the core team probably wishes to leave them to third party plugins, even though those plugins are far from perfect. 🙂

    • Ipstenu (Mika Epstein) 9:44 pm on January 12, 2016 Permalink | Log in to Reply

      I’m going to sneak add https://core.trac.wordpress.org/ticket/35429 – Since I upload a LOT of plugins for testing, this would save me oddles of time 🙂

    • shackep 1:53 pm on January 14, 2016 Permalink | Log in to Reply

      I think “enable-media-replace” https://wordpress.org/plugins/enable-media-replace/ should be added to core. Such a simple handy plugin. And perhaps something like https://wordpress.org/plugins/media-item-url/ while we are at it. Small things that many people could find useful.

    • The-Dude 2:57 pm on January 14, 2016 Permalink | Log in to Reply

      Native TOC-Support working together with Pagebreak would be very helpfull! 🙂

    • Damir Calusic 11:02 am on January 17, 2016 Permalink | Log in to Reply

      We really need this simple fix https://core.trac.wordpress.org/ticket/28381

    • summoner 10:35 pm on January 18, 2016 Permalink | Log in to Reply

      +1 for LOT of enhancements in media library (ordered by complexity):

      • Media categories;
      • “enable-media-replace” as mentioned by shackep;
      • Different sizes in different folders;
      • Adding a per file generated pre- or suffix to original file names so that people can not harvest others’ original images by simply deleting some characters of the thumbnail url…;
      • Maybe even some content protection functionality Galleries are great but FB like photo albums would be welcome as well (see in: https://wordpress.org/plugins/simple-photo-albums / this one does not add any new menu items which is great);
      • Image focal points as mentioned by chrishoward;

      +1 WP simply MUST support multilanguage content out of the box (as even personal blogs tend to need that, not to mention business sites)

    • itsnotrocketsurgery 2:45 pm on January 25, 2016 Permalink | Log in to Reply

      A mechanism for tagging and filtering themes would be useful. When I provide my themes/child themes to end users, it would be useful for me to tag them with their colours and be able to provide a filter at the top of the theme selection page.

      I’m not aware that anything like this already exists and I’m not a developer, but it would be handy to freely tag themes somehow, even just from within the theme CSS header.

    • camelotcamel 11:12 am on January 28, 2016 Permalink | Log in to Reply

      It’s all been said before, but anyway:

      Better media management!

      • upload to user defined folders
      • “add from server” functionality
      • media categories
      • media replace
    • Settler11 8:38 am on February 2, 2016 Permalink | Log in to Reply

      The Duplicate Post plugin! Almost a million downloads.
      And media management; but that’s been said a thousand times I think. 🙂

    • ledgoti 3:53 pm on February 4, 2016 Permalink | Log in to Reply

    • MarieDi 9:04 pm on February 14, 2016 Permalink | Log in to Reply

      1- PLEASE! a multilanguage core.
      2- Please add a one-click-child-theme generation button. I’m no tech, but wouldn’t that be actually easy?
      3- Please move the “Delete Theme” command back to OUTSIDE the theme lightbox. Bring it back as a third button to the right of Activate and Preview. I can’t understand why we can’t delete a theme without having to preview it first!
      4- Please bring back a List view option for plugins and themes
      5- Please add an advanced search feature that would allow us to choose themes both on, say, number of sidebars AND highest rated, for instance.

      🙂

    • nielsverwaal 9:26 am on March 18, 2016 Permalink | Log in to Reply

      What are you most interested in seeing in WordPress 4.5 — big, or small?
      1. Better native media management (for images like NextGen by Photocrati)
      2. Native drag/drop page, post, cpt or any other post type ‘ordering’
      3. Build in CPT and Custom Field creator (like ACF)
      4. Core: More speed and Content: Optimization capabilities build in.
      5. Plugin search results, sort by relevance, Score, Usage, Premium, Free

      What are your or your users’ biggest pain points?
      Point 1 and 2 are my customers biggest pain points.

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel
Skip to toolbar