WordPress.org

Make WordPress Core

Updates from May, 2016 Toggle Comment Threads | Keyboard Shortcuts

  • Eric Binnion 2:39 pm on May 18, 2016 Permalink |
    Tags: ,   

    Week In Core, May 11 – May 18 2016 

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

    • 40 commits
    • 31 contributors
    • 74 tickets created
    • 12 tickets reopened
    • 78 tickets closed

    Ticket numbers based on trac timeline for the period above. The following is a summary of commits, organized by component.

    Accessibility

    • Make the tab order match the visual order in the Edit terms screens. [37439] #35664

    Administration

    • System font: The stack does not work with the font shorthand property. [37442] #36753
    • Credits: Add a missing closing tag. [37434] #35911
    • Admin font: Remove a redundant sans-serif declaration. [37419] #36753

    Bootstrap/Load

    Build/Test Tools

    Comments

    • Add $data parameter to include the comment data in the edit_comment action. [37423] #36427

    Customize

    • Change attachment condition in the site icon control to prevent errors. [37456] #36749
    • Include shortcut button in Custom Menu widget to edit the selected menu in the Customizer. [37437] #32683
    • Remove use of reserved word default in Underscore template which breaks IE8. Fixes #36793. [37450] [37417] #36793
    • Handle filtering sidebars_widgets when the underlying option is non-existent. Merge of [37352] to the 4.5 branch. Fixes #36660. [37453] #36389, #36660
    • Clean up media control CSS. Removes unnecessary wrapper elements and refactors class names to eliminate duplication of rule selectors. [37426] #30618

    Editor

    • TinyMCE: prevent showing the placeholder URL when adding a link and clicking more than once on the Insert Link button. Merge of [37301] to the 4.5 branch. [37454] #36637
    • Editor: Merge two strings. [37441] #27756

    Embeds

    Filesystem API

    • Don’t add '.' to the list of directories which need to be checked/created when extracting a file. [37421] #36570

    General

    • Docs: Standardize on ‘backward compatibility/compatible’ nomenclature in core inline docs. [37431] #36835

    HTTP API

    • Use prepared JSON data correctly. This was modifying a variable that was never used. Oops. [37444] #36358
    • Pass array-like object to http_api_debug. This was mistakingly passing the Requests_Response object, which caused fatal errors with debugging tools. [37436] #33055
    • Fix compatibility with cURL < 7.22. [37430] #33055
    • Add browser compatibility hook for 3xx redirects. [37428] used the wrong method of adding this hook, now corrected. [37429] #33055
    • Replace internals with Requests library. [37428] #33055

    I18N

    • In get_translations_for_domain() check if the global $l10n was set by _load_textdomain_just_in_time() before accessing it. [37440] #34114

    Media

    Networks and Sites

    • Tests: Set public to 1 in the default blog factory. [37418] #36566
    • Tests: Use factory method to generate fixtures for wp_unique_post_slug() tests. [37443] #20419

    Posts, Post Types

    • Fire a post_action_{$action} action for a custom post action request. [37424] #27056

    TinyMCE

    Upgrade/Install

    • Add changelog entries for when the classes were moved to its own file. [37432] #36618

    Users

    • List Tables: Pass the $which parameter to restrict_manage_posts and restrict_manage_users. [37422] #35307

    Widgets

    • Create WP_Widget_Mock as a mock of WP_Widget which can be used for widget tests. You cannot instantiate an abstract class. Not even in WordPress world. [37427] #35981
    • Make WP_Widget a real abstract class. [37425] #35981

    Thanks to @adamsilverstein, @afercia, @boonebgorges, @brianvan, @celloexpressions, @danielhuesken, @DrewAPicture, @dshanske, @helen, @iseulde, @jeremyfelt, @jfarthing84, @joemcgill, @johnbillion, @jorbin, @jrf, @martin.krcho, @mintindeed, @Mte90, @neverything, @ocean90, @pavelevap, @rachelbaker, @ramiy, @rmccue, @samantha-miller, @SergeyBiryukov, @sudar, @swissspidy, @tfrommen, and @westonruter for their contributions!

     
  • 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

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

      Ā ā
      Ē ē
      Ī ī
      Ō ō
      Ū ū

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

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

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

      My wishlist,

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

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

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

      … I now use this plugin on ALL my sites

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

      //Lars, Copenhagen

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

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

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

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

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

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

      Site language
      Admin language (or Backend language)

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

      I hope you can see my point

      Best regards from Lars, Copenhagen

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

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

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

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

    • Dwain Maralack 11:24 pm on May 3, 2016 Permalink | Log in to Reply

      This is a good plugin idea, but not for core inclusion.

  • 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: , , ,   

    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!

     
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