WordPress.org

Make WordPress Core

Search Results for: gallery Toggle Comment Threads | Keyboard Shortcuts

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

    Gallery 

    28 open tickets. Last 7 days: +1 ticket

    28 open tickets defect (bug) enhancement feature request
    Awaiting Review 9 5 2
    Future Release 8 3 1
     
  • Joe McGill 3:15 pm on August 26, 2016 Permalink |
    Tags: ,   

    Media Kickoff Meeting for 4.7 

    We’re planning to have weekly meetings in the #core-images Slack channel throughout the 4.7 release cycle. The kickoff meeting is set for today, August 26, at 19:00 UTC. We will use these meetings to keep projects moving forward and to discuss any priority tickets that require discussion.

    Meeting Agenda

    The main purpose of the kickoff meeting is to identify the priority projects for 4.7 and to determine who is available to work on those projects. We will also review the current meeting schedule to see if a different time would be better for those wanting to be involved.

    Potential Focus Areas for 4.7

    • Improve media library management (#22744, explore default taxonomy structure, UX issues)
    • Better PDF management (#31050)
    • Create a standard WP_Image or WP_Attachment class (#23424)
    • Better optimization of full size images (#37840).
    • Core media widget (#32417)
    • Address HTTPS issues with media (#34109, #25449, #35182, etc.)
    • Improve responsive image defaults.
    • Support responsive images in WP_Customize_Media_Control (#36191)
    • Support responsive images in the editor.

    Wishlist Tickets

    Additional issues that were mentioned in the comments of the 4.7 wishlist post include:

    • Return option for media_sideload_image()  (#19629)
    • Add hook in wp_ajax_save_attachment() for additional attachment fields (#23148)
    • Updating link URL on image within admin with gallery (#13429)
    • Accents in attachment filenames should be sanitized (#22363)
    • Reconsider SVG inclusion to get_allowed_mime_types (#24251)
    • Dynamic image sizes in the editor (#35094)
    • Paste images into content area (#27970)
    • Add a drop zone to the the featured image meta box.
    • Revisit the Image Flow project.
    • Improve documentation/instruction for the WP media modal.
    • Address inconsistencies in the media library UI (see comment).

     

     
  • Grant Palin 7:00 am on August 25, 2016 Permalink |
    Tags: ,   

    Week in Core, August 16 – 23, 2016 

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

    • 72 commits
    • 40 contributors
    • 100 tickets created
    • 9 tickets reopened
    • 96 tickets closed

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

    Code Changes

    Administration

    • Allow for .nav-tab-wrapper class to be used on elements other than h3 to increase flexibility for custom settings pages. [38306] #37257

    AJAX

    • add a new function, wp_doing_ajax(), which can replace… (wait for it…) DOING_AJAX checks via the constant. [38334] #25669

    Bootstrap/Load

    Cache

    • in WP_Object_Cache, $cache_misses is public, but $cache_hits is private. They should both be public, because they’re useful for debugging purposes. [38335] #37726

    Comments

    • in wp_handle_comment_submission(), $_wp_unfiltered_html_comment is passed as part of $comment_data, but is not used locally. [38313] #37771
    • in WP_Comment_Query::fill_descendants(), continue if there is an empty array in the loop. [38298] #37416
    • in WP_Comment_Query::fill_descendants(), compute count() in the first for expression so that it does not run on each iteration. [38297] #37416

    Customize

    • Ensure a newly-added custom link nav menu item has the appropriate CSS class names. [38301] #37575

    Database

    • WP_Network, WP_Network_Query, and WP_Site_Query call wpdb::_escape(), thus requiring it to be public. It previously had no access modifier. _ at the beginning of a method, believe it or not, does not enforce visibility constraints. [38314] #37771

    Docs

    • Update jsdoc in customize-nav-menus.js to remove references to Menu Customizer plugin. Also fix @param for updateAssignedLocationsInSectionTitle. [38300] #37520
    • Update outdated phpdoc for WP_Customize_Manager::validate_setting_values() to reflect changes in [37942]. [38299] #37247, #37759
    • Correct usage examples for wpdb::prepare(), which should not be called statically. [38289] #37744
    • Fix typo in load_plugin_textdomain() parameter description. [38284] #37318

    Embeds

    • In get_oembed_endpoint_url(), avoid inadvertent stomping of the $format parameter passed to oembed_endpoint_url filter. [38321] #37751

    External Libraries

    General

    • remove variable set needlessly in wp_check_jsonp_callback(). [38308] #37771

    Hooks

    • Standardize naming of dynamic hooks to use interpolation vs concatenation. [38307] #37748

    HTTP

    • in WP_HTTP_Response, the @param declarations for $status and $headers were swapped. Let us correct this. [38315] #37771

    I18N

    • Add translator comments for strings in wp-includes/functions.wp-scripts.php. [38345] #37803
    • Add translator comments for strings in wp-includes/functions.php. [38344] #37802
    • Add translator comments for strings in wp-includes/deprecated.php. [38343] #37797
    • Add translator comments for strings in wp-includes/class-walker-comment.php. [38342] #37796
    • Add translator comments for strings in wp-includes/author-template.php. [38341] #37795
    • Add translator comments for strings in wp-includes/admin-bar.php. [38340] #37794
    • Remove unnecessary context for two strings on “Add New User” screen. [38329] #37784
    • Remove unnecessary context in wp_post_revision_title_expanded(). [38327] #37781
    • Use a consistent context for “Add New” submenu strings in admin bar (Toolbar). [38326] #37780
    • Allow for WordPress Plugin/Theme Directory URLs to be localized. [38325] #37501
    • Replace unnecessary context with translator comments in wp_post_revision_title() and wp_post_revision_title_expanded(). [38324] #37778
    • Replace unnecessary context with a translator comment for %s Sites string in network_step1(). [38323] #37777
    • Replace unnecessary context with a translator comment for %s KB string on Network Settings screen. [38322] #37496
    • Add translator comments for Edit Site: %s string in network admin. [38320] #37776

    Locale

    Login

    • retrieve_password() does not need to import 2 globals that it does not use. [38304] #37699

    Mail

    • If post-by-email functionality is disabled, wp-mail.php should return a 403 Forbidden status code instead if 500 Internal Server Error. [38332] #37572
    • Don’t set Sender field when setting From. Merges [38286] to the 4.6 branch. [38287] #37736
    • Don’t set Sender field when setting From. [38286] #37736

    Media

    • remove function_exists() call for ini_get() in _load_image_to_edit_path(). [38333] #37681
    • remove unnecessary variable assignment in gallery_shortcode(). [38309] #37771
    • add a function, wp_get_additional_image_sizes(), that wraps the retrieval of the global $_wp_additional_image_sizes. Removes 6 global imports. [38303] #37699
    • fix unit test after [38296].
    • use wp_get_attachment_metadata() instead of get_post_meta() where appropriate. [38296] #36246
    • wp_get_attachment_link() fails to output text for non-images if the attachment post doesn’t have a title and $text (argument #5) was not passed to the func. In this case, use the filename. [38295] #5, #37343
    • when calling pathinfo(), also pass a PATHINFO_* constant to avoid array notices for unset keys. [38294] #37608
    • Add some docs to media-gallery.js RIP. [38293] #37717

    Multisite

    • Fix copy/paste issue in id attribute for a dismissible message on Sites screen. [38305] #37764

    Nav Menus

    • remove unnecessary variable assignment in wp_nav_menu_item_post_type_meta_box(). [38311] #37771

    Query

    • use correct description in the docblock for $number in WP_Comment_Query, WP_Network_Query, and WP_Site_Query. [38336] #37621
    • Non-scalar and negative values for ‘p’ should always result in a 404. [38288] #33372
    • use composition for $db in WP_Date_Query, removes need to import global $wpdb in multiple methods. [38280] #37699
    • use composition for $db in WP_Query, removes need to import global $wpdb in multiple methods. [38279] #37699
    • add a protected field, $db, (composition, as it were) to WP_*_Query classes to hold the value for the database abstraction, instead of importing the global $wpdb into every method that uses it. Reduces the number of global imports by 32. [38275] #37699

    REST API

    • remove unnecessary variable assignments in rest_handle_options_request(). [38310] #37771

    Taxonomy

    • in get_terms(), do not assume that legacy args are being passed when the only params are top-level meta_* values. Add keys in WP_Term_Query::__construct(). Adds unit tests. [38337] #37568
    • remove unnecessary break in WP_Term::__get(). [38312] #37771
    • In is_object_in_term(), return error object rather than caching it. [38277] #32044, #36814, #37721
    • Allow attachment taxonomies to be fetched as objects. [38292] #37368

    Tests

    • Fix incorrect variable name from [38330]. [38331] #37630
    • Attachment create() method should match signature of other create() methods. Legacy argument format continues to be accepted. [38330] #37630
    • Move some utility classes to their own files. [38285] #37523
    • skip checking the value in Tests_User:test_user_properties for db. Casting to array is not the most elegant thing here, and various versions of PHP key protected/private fields differently when objects are cast. [38278] #37699
    • Introduce tests for get_attachment_taxonomies(). [38291] #37368
    • Introduce tests for get_object_taxonomies(). [38290] #37368
    • Add wordpress-importer tests demonstrating slashed data behavior. [38283] #21007

    TinyMCE

    • make sure the temporary id is removed when using the default image dialog and inserting an external image. [38328] #37467

    Users

    • after [38317], use a @property annotation, instead of a public field. [38319] #37771
    • $user_level has been publicly-accessed on instances of WP_User since version 2.0, but is has never been declared. [38317] #37771

    Widgets

    • $option_name and $alt_option_name have been used as members ever since WP_Widget became an object in 2.8, but never declared. [38318] #37771

    Props

    Thanks to @afercia, @Akeif, @azaozz, @bcole808, @boonebgorges, @Clorith, @codemovementpk, @danhgilmore, @danielbachhuber, @dd32, @deremohan, @dlh, @DrewAPicture, @flixos90, @fomenkoandrey, @Frank, @gma992, @henrywright, @iandunn, @imath, @JaworskiMatt, @jipmoors, @Jonnyauk, @jorbin, @JorritSchippers, @Klein, @kouratoras, @Mte90, @Presskopp, @ramiy, @rpayne7264, @sebastianpisula, @SergeyBiryukov, @swissspidy, @tivnet, @TJNowell, @tomdxw, @vishalkakadiya, @westonruter, and @wonderboymusic for their contributions!

     
  • Helen Hou-Sandi 7:44 pm on August 17, 2016 Permalink |
    Tags: , wishlist   

    WordPress 4.7: What’s on your mind? 

    Trunk has been open for 4.7 commits for a couple weeks now, with 4.7 formally kicking off next week – more on that to come shortly. To help get an understanding of what people want to see in 4.7 (and beyond), chime in below with pet tickets, projects, and other wishlist items. If you’re able to work on your suggestion, please also indicate that. As both the release lead and a lead developer, I have plenty of thoughts of my own, but right now I want to hear yours.

    Disclaimer: Comments do not constitute binding contracts. 🙂

     
    • Jonathan Brinley 7:48 pm on August 17, 2016 Permalink | Log in to Reply

      What can I do to help https://core.trac.wordpress.org/ticket/17817 move forward in 4.7?

    • Scott Kingsley Clark 7:48 pm on August 17, 2016 Permalink | Log in to Reply

      Fields API, amiright?

    • Tom Ryan 7:49 pm on August 17, 2016 Permalink | Log in to Reply

      Focusing on a better, more consistent UX, especially for new/novice WordPress users.

    • Retrofitter 7:58 pm on August 17, 2016 Permalink | Log in to Reply

      widgets stored in a custom post type instead of options. https://core.trac.wordpress.org/ticket/35669

    • b-rad 7:58 pm on August 17, 2016 Permalink | Log in to Reply

      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.

      Groups please.

      • Pascal Birchler 8:17 pm on August 17, 2016 Permalink | Log in to Reply

        The vast majority of WordPress sites only have a handful of users. Including a huge thing as user groups in core doesn’t make sense as only few people actually have a need for this. In my eyes it’s plugin territory and I’d recommend you to check out plugins like WP User Groups (https://wordpress.org/plugins/wp-user-groups/) to accomplish this.

        • b-rad 8:37 pm on August 17, 2016 Permalink | Log in to Reply

          So you’re saying that because you think most sites have a few users that we shouldn’t add a powerful feature that countless groups, businesses, and organizations can use? And one that’s already got a solid plugin (co-authors plus) which was co-developed by Automattic? So should we never add powerful features to WordPress based on that login?

          WordPress’ audience continues to grow daily and in order to be able to meet the needs of organizations large and small, groups would be integral part. If a company uses WP and the IT group maintains an outages page, who should control it? Just one person? Why shouldn’t a group of users in the IT department be able to manage content? That’s just one very simple example.

          And what makes you think that this is a “huge” thing? It would be extremely useful and powerful yes, but it wouldn’t negatively impact WordPress at all. Please don’t be so dismissive especially when plenty of other users have agreed that this is a very useful feature.

          Do you have a survey or stats to back up your claim for “only few people actually have a need for this”? The WP User groups plugin you suggested doesn’t come close to what I’m suggesting so maybe I’m not being clear enough. See the co-authors plus plugin for a better example.

          As a true CMS this is a big void for WordPress.

          • wpdevco 10:48 pm on August 17, 2016 Permalink | Log in to Reply

            +1

          • Pascal Birchler 12:36 pm on August 19, 2016 Permalink | Log in to Reply

            I’m sorry, I should have explained my thoughts better. That’s definitely not what I’m saying and I certainly didn’t want to be dismissive.

            I understand the benefits of better user management, just like I understand that lots of people want better media management.

            Such a new feature usually needs more information about how and why it should be implemented (see Helen’s comment below). Depending on that it might align with WordPress’ philosophies or not.

            In addition to that, there’s currently a technical limitation to properly support things like user groups, see #37686 for a recent example. That means such a feature would take more than just 1 release to be implemented and should probably start off as a feature project first.

        • Doug Wollison 12:17 pm on August 18, 2016 Permalink | Log in to Reply

          With that argument we should never have merged MU into core because only a fraction of the userbase wants it. And MU is way bigger than groups.

          Also, I’m pretty sure a good chunk of sites don’t actually use the comments system, or even the posts system; they just want pages they can edit for their brochure-style site. Extending your argument (and ignoring backwards-incompatibility-insanity), we should move those systems to plugins so they aren’t bloating up the core.

      • seanbennick 8:42 pm on August 17, 2016 Permalink | Log in to Reply

        +1

      • catchmyfame 9:22 pm on August 17, 2016 Permalink | Log in to Reply

        Agree 100%. Would love this feature.

      • rkoller 10:00 pm on August 17, 2016 Permalink | Log in to Reply

        +1

      • Mike Schinkel 10:07 pm on August 17, 2016 Permalink | Log in to Reply

        +1 for Groups

      • Helen Hou-Sandi 12:46 pm on August 18, 2016 Permalink | Log in to Reply

        I would like to avoid bickering and “well what about” arguments, as they are not very constructive. Let’s please stick to explaining why something is beneficial or detrimental for now, thinking about inclusion based on usage is getting ahead of ourselves.

        • Mike Schinkel 8:13 am on August 22, 2016 Permalink | Log in to Reply

          What would be especially helpful for Groups is for core to start to define a fundamental group building block so that any plugins that want to provide group functionality can build on a common base. So for 4.7, something very simple. And then over subsequent versions we could add more functionality to groups as the use cases more clearly emerge.

    • Bryan Cady 7:59 pm on August 17, 2016 Permalink | Log in to Reply

      Can the organization of the widgets section be looked at. I have one user who consistently changes and reuses widgets throughout the year so they keep a lot of inactive ones plus they have several active and keeping everything organized is difficult as laid out now.

      • Doug Wollison 12:22 pm on August 18, 2016 Permalink | Log in to Reply

        +1

        On that subject, what about adding a global interface on all widgets that lets you control what pages it shows up on? Some might want widgets in a particular sidebar that’s global but only want that widget to appear in it on certain pages. It’s something that can easily be argued as not the widget nor theme’s responsibility to offer. The controls for it could be difficult to make user friendly though.

        • Dave Clements 2:07 pm on August 18, 2016 Permalink | Log in to Reply

          Jetpack’s Widget Visibility is a good starting point. I use it with a number of clients and they don’t have much trouble figuring out how to use it.

      • Mark Root-Wiley 8:36 pm on August 19, 2016 Permalink | Log in to Reply

        Possibly related: #36532 “Allow Reordering of Available Widgets”

        A core implementation of something like “Duplicate Widget” might be awesome too.

      • Shaped Pixels 11:36 pm on August 24, 2016 Permalink | Log in to Reply

        I agree on better widget management. But the one thing I’ve been trying to get the core to do is add a simple functionality of disabling the widget title from the front-end. As sites get bigger and more into full cms territory, the widget management needs a revamp.

    • Jake Spurlock 8:02 pm on August 17, 2016 Permalink | Log in to Reply

    • dartiss 8:04 pm on August 17, 2016 Permalink | Log in to Reply

      Two factor authentication and some of the excellent changes put into the UI Labs plugin

      • Helen Hou-Sandi 12:53 pm on August 18, 2016 Permalink | Log in to Reply

        Which changes and why? I have never personally used the plugin and the screenshots don’t seem quite correct, so I am unfamiliar with it.

        • Ipstenu (Mika Epstein) 3:09 pm on August 18, 2016 Permalink | Log in to Reply

          https://wordpress.org/plugins/ui-labs/

          Current maintainer here. Sorry I’m lazy and didn’t update the screenshots.

          The only thing from it I’d love to see in core is the code that shows out of date plugins, and the stuff that shows post status in a more visual way (green yellow etc etc).

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

            Colors for post statuses as the row background color was asked for in #26928, which I declined. Using colors as an enhancement to other methods of indication (such as what we have now) would be more possible, however my concerns around non-universal meanings of colors still stand.

            • dartiss 9:32 am on August 20, 2016 Permalink

              I understand, although this is the particular feature I would have liked! As for the out-of-date plugins, I’ve had some issues with performance (which Mika is aware of) but, otherwise, it’s a good idea too.

              The only other feature I use is the server identification but I’m guessing that may fall into your previous “universal meanings of colors” argument 🙂

            • Hugo Baeta 8:15 pm on August 24, 2016 Permalink

              Using colors as an enhancement

              This could also be a potential issue for Accessibility, as people with certain color blindness might have a hard time perceiving red/green.

            • Rick Beckman 5:23 am on August 25, 2016 Permalink

              Wouldn’t have to mark up-to-date plugins with any color, but maybe showing plugins that are a minor version out of date with yellow and major version out-of-date plugins in red could be done?

              Red almost always means stop, judging by traffic lights around the world, so it may not be that bad to use, plus it removes the problem of color blindness and makes it simply a question of adequate contrast between the yellow and red.

    • pro99 8:04 pm on August 17, 2016 Permalink | Log in to Reply

      Built in 2-factor authentication would be awesome.

      • Pascal Birchler 8:25 pm on August 17, 2016 Permalink | Log in to Reply

        • CotswoldPhoto 2:16 pm on August 18, 2016 Permalink | Log in to Reply

          I think that project is dead Pascal. No obvious signs of activity for months; since Feb 2016. It was targeted for 4.5, so I would say it is dead. No point in extra security for WP anyway, it is never hacked nor the object of any hacking attempts. Besides, there are plenty of plugins with it out there, none of which are supported by other plugins, and as such are pretty useless.

      • Aaron Jorbin 5:55 am on August 19, 2016 Permalink | Log in to Reply

        2-factor has a couple of issues that make me think it isn’t a great decision for core. 1) It’s not user friendly. Balancing security and usability is hard.

        2) A smartphone based system isn’t realistic. The expectation that a user has a smartphone isn’t realistic.

        3) Many sites can’t reliably send email. This means that it can’t be relied upon for that form of 2-factor.

        4) Many sites are just a single user. How should lockouts be handled?

        I think for the sites where 2-factor makes sense, a plugin is the right chose.

        • Benoît Chantre 1:03 pm on August 20, 2016 Permalink | Log in to Reply

          Would it be possible to turn the 2-factor feature project into a finalized and maintained plugin by wordpress.org? Something like the WordPress Importer Plugin.

    • pepe 8:06 pm on August 17, 2016 Permalink | Log in to Reply

      Some love for bringing the Media API to plugin developers: More hooks (for saving custom Attachment Details for example), more documentation. When 3.5 introduced the new Backbone.js API, there was a promise of tutorials “coming soon”, but those never materialized. Let’s change that in 4.7!

    • modemlooper 8:06 pm on August 17, 2016 Permalink | Log in to Reply

      API endpoints

    • Ipstenu (Mika Epstein) 8:06 pm on August 17, 2016 Permalink | Log in to Reply

      I’d like to modernize the sample page (and have some ideas to that end) and make it more relevant to 2016.

      • Jon Brown 11:34 pm on August 17, 2016 Permalink | Log in to Reply

        Interesting. Not sure what your ideas are, but I tend to replace the sample page with a theme style guide showing content formatting (H1-6, ul, blockquote, etc…). I use it for theme dev, but clients later use it as a reference. IMHO it’d be very cool to have a simple style guide that synchronized with a simple editor-style.css (in defaults themes) instead of the boring “This is a page”. The content could be both informative in its copy, as well as its formatting….

        • Ipstenu (Mika Epstein) 12:09 am on August 18, 2016 Permalink | Log in to Reply

          I wouldn’t want to make it boring, for sure. I wanted to make it have modern examples of kinds of pages. Having some formatting (h1, blockquote, etc) sounds like a great idea too. It doesn’t need to be an HTML primer, but showing what it can do is a good idea.

    • Jeroen Sormani 8:09 pm on August 17, 2016 Permalink | Log in to Reply

      Here are some things that are on my mind:

      • Admin: notice API

      Would be good to have a unified and simple way of adding notices. This should make it easier to add notices, make them dismissable in a unified way instead of every developer having to figure out its own way of doing so.

      • Admin: Image drop for featured image

      We can easily drop images in the content field, why not in the featured image box 🙂

      • Admin: Paste images

      Say you’ve taken a screenshot or just copied a image from your pc, allowing a direct paste in the tinyMCE field would be crazy awesome!

      I haven’t made any tickets for these points (yet)

    • HoaSi 8:13 pm on August 17, 2016 Permalink | Log in to Reply

      Security and caching out of the box. Why should you need to use a plugin to secure a site? Granted, Core shouldn’t do everything, customisation is the purpose of plugins etc. I get it. Still, there could be more emphasis on security and speed by default.

      • Ihor Vorotnov 1:34 am on August 18, 2016 Permalink | Log in to Reply

        But Core is secure and fast out of the box. Some plugins are usually a problem. Especially when there are dozens of them installed. Caching – WP has object caching built-in, you just need to drop a class for _your_ caching engine on _your_ server. They are available as plugins for all caching engines. Other types of caches are gazilions of options and setups – not suitable for Core feature.

        • HoaSi 4:14 pm on August 18, 2016 Permalink | Log in to Reply

          Yes, you are right, and we agree on your points. This is more what I had in mind however -> https://make.wordpress.org/core/2016/08/17/wordpress-4-7-whats-on-your-mind/#comment-30607

        • FolioVision 12:44 am on August 19, 2016 Permalink | Log in to Reply

          Ihor, at this point it’s clear that WordPress users use plugins. Hence some kind of security system which takes into account plugins as well would be both welcome and appopriate. There’s all kinds of wonderful tweaks which could be made to make WordPress core more secure. Having to install and fight security plugins coded more for commercial advantage than for simplicity and efficiency is not a joy.

          It’s a waste of time. Security is a friction point where WordPress core could really help.

          Caching is more complex as advanced caching is very environment dependent. Core WordPress out of the box is not fast. Basic bulletproof caching (80/20) principle should be included. If that means there has to be a checkbox to turn it off for the ultra advanced so be it. There’s a few sites where I’d continue to use custom caching solutions but for the majority of our clients I’d be delighted to be able to serve the well made and simple basic caching.

          • Ihor Vorotnov 2:18 pm on August 19, 2016 Permalink | Log in to Reply

            Alec, with all the respect..

            > tweaks which could be made to make WordPress core more secure

            If the core itself is secure, and 99.99% of insecure code comes with plugins, how any kind of tweaking in core can fix those plugins? What kind of “security system” you mean? Can you give at least one solid example?

            Look. It’s not working this way. Not “install insecure plugin then install some security plugin to fix the insecurity”. You don’t use the insecure plugin in the first place. Probably, better .org repo plugin checks may help, but we all know that our volunteers at PRT are already trying to do their best.

            > Security is a friction point where WordPress core could really help.

            How? Examples, please.

            > Core WordPress out of the box is not fast.

            Core is ~10-15ms on PHP 7 on popular VPS plans with 1GB RAM, those that are $5-$10/m. Without caching. 10ms is fast.

            > Basic bulletproof caching (80/20)

            What do you mean by this? What it should be? Basic caching (object caching) is already there, just drop the class in for the caching engine you use, it works out of the box. Any other caching is env dependent, as you’ve said.

            • B0RG 2:25 pm on August 20, 2016 Permalink

              A good start could be to create a test pipeline for the first source of problematic plugins, the wordrpess repo. There are still many plugins that break wordpress and should be simply removed by an automated testing infrastructure. And of course this infrastructure must be guarded by paid professional developers, not by some hobbyists.
              This is how it works.

      • Aaron Jorbin 5:56 am on August 19, 2016 Permalink | Log in to Reply

        What do you mean by security out of the box?

        • summoner 1:18 pm on August 19, 2016 Permalink | Log in to Reply

          Bad login throttling at the very least…
          Using mysql connection just as a last resort not as default and only option, etc.
          (And actually not selling a major security patch as emojis…)

          • Ipstenu (Mika Epstein) 1:56 pm on August 19, 2016 Permalink | Log in to Reply

            What would we use instead of MySQL? I’m assuming you don’t mean a ‘no database’ WP.

            As for emojis, if you saw Nacin’s talk or read the articles, you’d understand why the approach was taken as it had to do with making sure people got fixed before we threatened the security of 20% of the Internet with no fix.

            • summoner 7:14 pm on August 19, 2016 Permalink

              I did not speak of MySQL databases but mysql connection. That is a huge difference. Why is it not possible to check the server (at least when installing WP) if it can handle mysqli or pdo connection instead of mysql, that should be only used as a last resort. (I am actually quite conservative in this question as there are folks who would like to change for MariaDB or some even for SQLLite).

            • Ipstenu (Mika Epstein) 10:05 pm on August 19, 2016 Permalink

              WordPress works fine with MariaDB (I’m using it myself).

              And unless I’m misreading https://core.trac.wordpress.org/ticket/21663 – we DO support PDO.

              So … you’re just saying that on instal WP should re-prioritize the order of preference?

            • summoner 12:08 am on August 20, 2016 Permalink

              Exactly.
              And core should contain at least some kind of login throttling as well because there are simply sooo many login attacks that they would succeed if i did not have plugins with throttling feature.

            • summoner 12:17 am on August 20, 2016 Permalink

              Actually i am always using the plugin (and i prefer mysqli) mentioned in that ticket (https://wordpress.org/plugins/wp-db-driver/). What if that plugin would succeed into core and if both mysqli and PDO is available on a server, then the admin could choose which one to use. If only one is available there is no need for a choice. And if neither one is available, only then would WP fall back to mysql.

        • HoaSi 3:10 pm on August 19, 2016 Permalink | Log in to Reply

          Apologises if it was not well worded. I meant that a security plugin should not be mandatory. Yet it is not uncommon for a new site on a clean install, without any plugins, to get attacked. In fact, spammers will attack a new site running on fresh install right away. These attacks are not always “dangerous”, most don’t even prevent a site from “working”. And that’s the point. Usually users do not even realise when it happens. And when they do, it’s a hassle. So anything to strengthen security even more is good for WordPress and for all users. Especially for people who would rather not install plugins. And those who will not care about upgrades, check the plugins they install etc. Besides, security plugins can carry vulnerabilities as well—this happened before. As for speed, most people agree that site speed is of the essence. Any implementation on that front is good too.

          As an example, right now I’m not using plugins except WordFence. I run two sites with a good host both on PHP7, not on shared servers. Both sites attract what you could call a confidential audience. And yet the amount of attack is staggering. If anything, spammers and bots are messing with the login page and XML-RPC all the time.

    • Robert Dall 8:19 pm on August 17, 2016 Permalink | Log in to Reply

      I would love to see https://core.trac.wordpress.org/ticket/32417 Add new core media widget.

      This would be a great addition to WordPress and the vast amount of poorly coded widgets available in the Plugin library would be redundant with this addition.

      I built my own for a larger client. But the vast amount of people who want linkable image widgets with (or without) titles is huge. IMHO.

    • Howdy_McGee 8:20 pm on August 17, 2016 Permalink | Log in to Reply

      Shortcode UI for regular users. Easier shortcode integration into TinyMCE.

      • Marius L. J. (Clorith) 8:33 pm on August 17, 2016 Permalink | Log in to Reply

        There’s already a feature project aimed at this which may be of interest to you https://wordpress.org/plugins/shortcode-ui/

        • Helen Hou-Sandi 1:01 pm on August 18, 2016 Permalink | Log in to Reply

          Leaving aside the oft-repeated “where’s the intersection with wishing for content blocks”, my personal major objection was and has always been (since an early conversation at WCSF 2014) that text is not editable inline but rather requires you open a modal, thereby removing context and making the live previewing aspect significantly less convenient. A lot of people seem to read this thread, so I thought I’d state it here 🙂

        • Bradley 8:42 am on August 24, 2016 Permalink | Log in to Reply

          Having used Shortcake (Shortcode UI) on a production project, I really would like to see something similar merged into core – Sure it could do with improvements (i.e. to allow inline editing), but the fact that anything other than text/ images/embeds requires users to either remember shortcodes, or for developers to replace the content editor with other field groups (e.g. using ACF) feels wrong.

      • pepe 9:42 pm on August 17, 2016 Permalink | Log in to Reply

        +1

      • pepe 7:42 am on August 18, 2016 Permalink | Log in to Reply

        Not quite the same thing, but Ticket 37183 (https://core.trac.wordpress.org/ticket/37183) would also help with integrating shortcodes with core components (specifically ). And a way to hook deeper into the wpeditimage plugin for TinyMCE would be nice (there are some custom events, but only for editing the image details, not for the actual shortcode stuff).

    • Luke Cavanagh 8:28 pm on August 17, 2016 Permalink | Log in to Reply

      Better comment management and new user experience. I guess trying to make things easier for new users would be a big one.

    • Pascal Birchler 8:28 pm on August 17, 2016 Permalink | Log in to Reply

      Besides some under the hood changes for developers, I’d love to take another stab at user-level timezones (https://core.trac.wordpress.org/ticket/18146), implement Shiny Updates V3, fallback locales and maybe even JavaScript i18n (https://core.trac.wordpress.org/ticket/20491). The latter being a rather large project though.

      • Drew Jaynes 9:09 pm on August 17, 2016 Permalink | Log in to Reply

        Shiny Updates v3 ideas:

        1. Upload a plugin or theme zip to update
        2. Turn the entire Plugins/Themes pages into drop-zones where you can drop a plugin/theme zip to install
        3. Install multiple plugins or themes via zip at once, possiblly as an enhancement to 1 and 2 above
      • Joachim Jensen - Intox Studio 9:46 pm on August 17, 2016 Permalink | Log in to Reply

        +1 for user level time zones, then later remove the post_time column from wp_posts and keep everything saved in gmt for standardization.

        • Pascal Birchler 1:11 pm on August 18, 2016 Permalink | Log in to Reply

          One thing that I learned is that storing the timezone information for dates is very important, otherwise you will get into trouble. When you store everything in UTC and change the timezone setting in WordPress, you’ll lose the timezone information of each post and all the dates will be incorrect. I’d rather remove the `post_date_gmt` column.

          • Joachim Jensen - Intox Studio 2:27 pm on August 18, 2016 Permalink | Log in to Reply

            Not sure I am following that. If everything is stored in the same timezone (gmt), then we can use user/site timezone to display it correctly for each user and visitors. If a user then changes the timezone, it doesn’t change the time of his (all) content, only the display time.

            Anyway, definitely introduce user time zones as a first

            • Pascal Birchler 12:45 pm on August 19, 2016 Permalink

              Let’s say I write a post today and the date gets stored in UTC. MY current timezone is UTC+1. A few years pass by, I travel around the world and change my timezone all the time. Eventually I set it to UTC-7. Now I don’t know exactly when my post from today was published. Was it morning? Afternoon? I’ll never know, because the timezone is missing.

              > Anyway, definitely introduce user time zones as a first

              Agree 🙂

      • Stephen Edgar 2:37 am on August 18, 2016 Permalink | Log in to Reply

        “user-level timezones” <- These would be fantastic

      • nathangraham 1:09 pm on August 25, 2016 Permalink | Log in to Reply

        +1 User-level timezones

    • seanbennick 8:29 pm on August 17, 2016 Permalink | Log in to Reply

      Better organization handling for media, including categories and tags would be helpful.

      • leemon 8:45 pm on August 17, 2016 Permalink | Log in to Reply

        +1

      • davidshq 1:07 am on August 18, 2016 Permalink | Log in to Reply

        +1 Can this including renaming media files and having references to them update appropriately? 🙂

      • Helen Hou-Sandi 4:31 pm on August 18, 2016 Permalink | Log in to Reply

        I’ve been talking to some people about this – do you think of it as organization or is it more like findability? FWIW I think of it as the latter, and would want to structure work in that area as “more easily find the media you’re looking for” (filter and search behaviors).

        • summoner 1:45 am on August 19, 2016 Permalink | Log in to Reply

          Well i happen to know this ticket: https://core.trac.wordpress.org/ticket/23594
          You really have to think different about mediahandling if you want to solve this demand.
          I mean until only devs can add custom code even for really basic media organization by custom code (as there is no UI for the same purpose despite even that would need the very same code), there is simply no way to improve just on findability. Not even by custom coding as most sites simply do not have any media organization data you could probably search for.

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

            I am not sure what you are going on about – the two things I currently have in mind as a first step are better search results for media (#22744) and a taxonomy as proposed by the ticket you mentioned (requires UI for assignment and filtering, the taxonomy itself is the “easy” part). The two enhancements together constitute better findability of your content. There are also other benefits and use cases that will surely arise from that, but I prefer to define the problem first.

            • summoner 12:04 pm on August 19, 2016 Permalink

              You are right, these 2 would be good enough to start with and actually there is already a UI for post category assignment. Many users, including me would love to see these 2 in WP 4.7.
              For defining the problem further (just in short):

              • ability to replace already uploaded files (i mean without deleting them before)
              • different sizes in different folders (i.e. filestructure could look like /year/month/SIZESLUG/CATEGORY/foo.jpg or similiar this would also add a ton information on which a decent search function could be based)
              • per file generated pre- or suffix to original file names so that people can not harvest others’ original images by simply deleting some characters of the thumbnail url (this may sound marginal at first and for thumbnails it is not a problem, but in reality it is quite an issue for originals)
              • image-focal points
            • nathangraham 1:30 pm on August 25, 2016 Permalink

              +1 on better search results for media, and assignment and filtering

        • seanbennick 5:40 am on August 20, 2016 Permalink | Log in to Reply

          I think it’s about both really. Think about the way we structure everything else in WordPress. We’re using Categories to organize items and we’re using Tags to search for items. Why don’t we apply that same logic to the Media library?

          When I’m storing assets for a site, I may handle it differently depending on the site needs.

          Photography Site:

          • Landscapes
          • Portraits
          • Corporate
          • Wedding
          • Real Estate

          Allowing the user to set up their own categories for each of those five and the use tags for the individual descriptors (say the names of the bride and groom, company, place, etc.) would make finding media much easier and would improve SEO as well. If a user is working on a piece about Yellowstone National Park and they want to locate a particular photo but they can’t remember the name or when it was uploaded, the date structure is useless. A tiered Category Structure would make things so simple, or even a Category and Tag system.

        • Ella Iseulde Van Dorpe 6:11 pm on August 21, 2016 Permalink | Log in to Reply

          Maybe something that feels like albums? When you drop 20 audio files in WordPress there is nothing that “binds” them together. So if you want to reinsert an album as a playlist at some later time you have to look for all of them again. Same for images really. This would also keep the library organised if you only display the albums, and in there the items.

          I also like the idea of trying to fit them together based on the post they are uploaded to, or if they are uploaded in bulk, or if a gallery/list is made, with the user having the ability to change these things of course.

      • csjWP 6:27 am on August 19, 2016 Permalink | Log in to Reply

        +1… And just a small thing, but I’ve always found it counter-intuitive and in my eyes not very practical that media galleries are apart of the_content(); I think that they should be separated.

      • amijangos 3:28 pm on August 19, 2016 Permalink | Log in to Reply

        +1

    • leemon 8:30 pm on August 17, 2016 Permalink | Log in to Reply

      https://github.com/sc0ttkclark/wordpress-fields-api: Fields API
      https://core.trac.wordpress.org/ticket/13429: Updating Link URL on image within Admin with Gallery
      https://core.trac.wordpress.org/ticket/12718: Better structure for admin menu
      https://core.trac.wordpress.org/ticket/22363: Accents in attachment filenames should be sanitized
      https://core.trac.wordpress.org/ticket/20901: Taxonomy descriptions should be TinyMCE editable
      https://core.trac.wordpress.org/ticket/32101: Ability to mark plugin as unmanaged
      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/23421: Add sortable to taxonomy column
      https://core.trac.wordpress.org/ticket/20842: Buttons are not on the same line when saving a post as pending (RTL)
      https://core.trac.wordpress.org/ticket/14877: Ability to create exclusive custom taxonomies
      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/22355: Template stack – Beyond parent/child theme relationships
      https://core.trac.wordpress.org/ticket/22942: Remove Post by Email
      https://core.trac.wordpress.org/ticket/9777: Usability : add delete button to edit-tags.php
      https://core.trac.wordpress.org/ticket/19834: More Robust Capabilities for Attachments

    • Drew Jaynes 8:33 pm on August 17, 2016 Permalink | Log in to Reply

      I’d be interested in working to collect opt-in, anonymized usage data in the admin to enhance our ability to make data-driven decisions as WordPress evolves.

      • Pascal Birchler 8:34 pm on August 17, 2016 Permalink | Log in to Reply

        +100!

        IIRC there were some discussions about this at WCUS last year. Let’s make it happen.

      • Richard Tape 8:43 pm on August 17, 2016 Permalink | Log in to Reply

        I’m keen on this suggestion, too. It could help drive future projects and let us know how and where we’re going wrong (or right). I’d be keen to work on this – have done something similar as a WP plugin for a Learning Record Store integration. (Although I’m torn because if it’s opt-in, it could just as easily be a separate plugin, would this need to go in core)

      • seanbennick 8:45 pm on August 17, 2016 Permalink | Log in to Reply

        This would be brilliant

      • Dion Hulse 10:20 pm on August 17, 2016 Permalink | Log in to Reply

        I’ve been in many discussions of this topic over the years, and yep, I’m in!

      • Dave Clements 2:14 pm on August 18, 2016 Permalink | Log in to Reply

        +1

      • summoner 2:15 am on August 19, 2016 Permalink | Log in to Reply

        Well…well…well…
        Do you know what all that means?
        Such things tend to become not just an opt-in and not just anonym and would slow WP sites further down. All these would drive lots of WP users away. Then the collected data should be stored somehow for a longer period of time (without that you could not evaluate trends and make decisions).
        Actually even now there are plug-in statistics. If that date would be evaluated, it would be no question in which direction WP is be improved. If you do not evaluate that data why do you need more data to be evaluated??

        • Helen Hou-Sandi 5:28 am on August 19, 2016 Permalink | Log in to Reply

          FUD and misdirection is not appreciated here. This is an open source software project, and as such, any code that collects and sends data is available for all to see. It is also a requirement from me (and supported by many others, if not everyone) that any and all data collected be publicly available, and therefore free of any individually identifying data.

          Plugin statistics do not help make decisions about, say, whether an overwhelming set of options can be changed or reduced to something more usable based on actual usage of those options, or if users are frequently clicking the same wrong things in search of an action they are looking to take.

      • Ella Iseulde Van Dorpe 6:41 pm on August 21, 2016 Permalink | Log in to Reply

        @ericlewis and I once started making a plugin for this… 🙂

    • Ronald Huereca 8:35 pm on August 17, 2016 Permalink | Log in to Reply

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

      I’d like more discussion over debug emails as more people turn on automatic updates.

    • Ramanan 8:40 pm on August 17, 2016 Permalink | Log in to Reply

      Have the ability in theme customizer to see all files and folders.

    • Drew Jaynes 8:54 pm on August 17, 2016 Permalink | Log in to Reply

      More ideas:

      • Enable oEmbed in comments
      • Make comments embeddable
      • Modularize make_clickable() with a filter: #32787
      • Media widget: #32417
    • Dave Navarro, Jr. 8:54 pm on August 17, 2016 Permalink | Log in to Reply

      Native support for .SVG images and the ability to use .SVG images as Admin Icons.

    • Dave Navarro, Jr. 8:57 pm on August 17, 2016 Permalink | Log in to Reply

      Ability to upload a ZIP file to UPGRADE a plugin.

      When adding a new plugin from the repository, ability to sort results by Downloads, Last Update and other criteria.

    • Dave Navarro, Jr. 9:03 pm on August 17, 2016 Permalink | Log in to Reply

      Under Appearance->Widgets add “Dashboard Widgets”.

      • Helen Hou-Sandi 5:01 pm on August 18, 2016 Permalink | Log in to Reply

        What is a “Dashboard Widget”?

        • Knut Sparhell 6:03 pm on August 18, 2016 Permalink | Log in to Reply

          There is even an API for it https://codex.wordpress.org/Dashboard_Widgets_API
          Or “Boxes” as they are officially called under Screen Options. What is the WP Admin Dashboard if not widgets/boxes?

          But you sure already know that, so this is probably a rhetorical question I just couldn’t grasp.

          But adding widgets designed for the front end in the admin area may not be a good solution.

          • Helen Hou-Sandi 6:44 pm on August 18, 2016 Permalink | Log in to Reply

            I am asking in the context of the request, the boxes on wp-admin/index.php don’t make sense to me and I don’t really know what “under Appearance->Widgets” means (in the admin menu or in the management UI?), so I can’t quite figure out what “Dashboard Widgets” means.

            • Aaron D. Campbell 11:46 pm on August 21, 2016 Permalink

              I think the suggestion is do add “Admin Dashboard” as a sidebar, and the widgets that go there as widgets that can be moved around. Basically, letting people adjust their admin dashboard in the widgets area.

              While I agree that the dashboard could use some love (or a complete rethink), I actually disagree with this particular path. While the widgets themselves aren’t technically that different, the types of widgets, their functionality, what they’re for, etc is drastically different. Not to mention that I’m not 100% sold on widgets being the best dashboard solution, and I worry about doubling down on an interface that might need to be replaced rather than simply improved on.

    • pro99 9:09 pm on August 17, 2016 Permalink | Log in to Reply

      Also AMP and Facebook Instant Articles built-in support. The outputted content of a CMS as popular as WordPress should be natively compatible with these new ‘standards’. Right now neither plugin work reliably, which would be a first step.

      • DanYork 10:25 pm on August 17, 2016 Permalink | Log in to Reply

        This would be great to have. (Having said that, because of the changing nature of those specifications it would be understandable to keep as a plugin for a bit.)

        • Dave Clements 2:16 pm on August 18, 2016 Permalink | Log in to Reply

          Agreed. Not sure this is yet stable enough for core inclusion, but a good idea for down the road.

        • Helen Hou-Sandi 5:05 pm on August 18, 2016 Permalink | Log in to Reply

          Correct, shipping something in core that is vulnerable to the whims of third party services who have not exactly shown developer friendliness is a risky and unappealing proposition. It’s also not always applicable to the content of a given site. Are there other services or software out there doing this already?

    • Xavi Ivars 9:09 pm on August 17, 2016 Permalink | Log in to Reply

      I’d love to see https://core.trac.wordpress.org/ticket/33472 implemented. Having a template language to build themes on top of would be great, and Timber (based o Twig) seems a really good approach (taking into consideration that Drupal8 and also MediaWiki support Twig as a template engine).

    • Mel Choyce 9:09 pm on August 17, 2016 Permalink | Log in to Reply

      A couple I’ve had floating around:

      • Group most 2-4 popular/widely used widgets at the top of the list. (Or even just one: Text Widget)
      • Media widget 😉
      • Improve some of the settings UI to be more visual
      • Improve what happens when you switch themes, such as reassigning menus. (Maybe this just means standardizing “primary” menu location names from the Theme Team side of things so that your main menu easily remaps when you switch themes)
      • Better “page on front” flow
      • Twenty Seventeen
      • FolioVision 12:51 am on August 19, 2016 Permalink | Log in to Reply

        +1 for standardising menu structure to make it easier to switch themes successfully without rebuilding menus.

      • Benoît Chantre 1:30 pm on August 20, 2016 Permalink | Log in to Reply

        +1 for Media widget, Improve some of the settings UI and standardizing “primary” menu location (Theme Handbook, Underscores, Theme review).

    • Thorsten Frommen 9:12 pm on August 17, 2016 Permalink | Log in to Reply

      I really would love to see https://core.trac.wordpress.org/ticket/26511 being tackled (again).
      I just refreshed the patch for 4.7 and also added some minor improvements.

      Once this is done, going over with https://core.trac.wordpress.org/ticket/29783 would be awesome.

    • davidperez 9:13 pm on August 17, 2016 Permalink | Log in to Reply

      Widgets in content, as pagebuilder siteorigin does. New web pages are now a composition of widgets.

    • Drew Jaynes 9:16 pm on August 17, 2016 Permalink | Log in to Reply

      Core REST API endpoints with meta support. Doesn’t have to be everything currently in-progress in REST API v2, we could start with posts or pages or a single endpoint and work outward.

    • DrProtocols 9:25 pm on August 17, 2016 Permalink | Log in to Reply

      Option for Media Upload to transliterate all international characters in upload filenames to only use the portable filename character set as per the IEEE/Open-Group specification http://pubs.opengroup.org/onlinepubs/9699919799/ and specifically Section 3.278

      More generally, options to name upload files by some defined scheme (using portable filename character set) either replacing the original name or prefix/suffix or similar to a transliterated filename.

      Even further restrictions such as only allowing lower-case and not mixed-case would help with site portability between case-sensitive and case-insensitive filesystems .

    • Aaron Jorbin 9:25 pm on August 17, 2016 Permalink | Log in to Reply

      I would love if there were REST API endpoints for Posts, Comments, Taxonomies and Users in Core.

    • Ross Wintle 9:27 pm on August 17, 2016 Permalink | Log in to Reply

      Would love to see https://core.trac.wordpress.org/ticket/36934 sorted out. On-demand excerpts for a given post ID would make my life a bit easier.

      Would love some more security built in. Disabling editors, some comment and registration spam-prevention features, brute force protection and disabling XML-RPC are pretty much essential. Can we start to build some of these things in?

    • Joachim Jensen - Intox Studio 9:31 pm on August 17, 2016 Permalink | Log in to Reply

      Deprecate PHP5.2.

      Then remove it in WP4.8 or 4.9. That will give hosts 4-8 months to migrate the small fraction of users still running on their mechnical steam-powered servers.

      • Xavi Ivars 10:36 pm on August 17, 2016 Permalink | Log in to Reply

        Yes!

      • Asgaros 10:52 pm on August 17, 2016 Permalink | Log in to Reply

        +1

      • rkoller 11:03 pm on August 17, 2016 Permalink | Log in to Reply

        +1

      • schlessera 11:20 pm on August 17, 2016 Permalink | Log in to Reply

        +1

      • davidshq 1:08 am on August 18, 2016 Permalink | Log in to Reply

        +1

      • Stanko Metodiev 6:42 am on August 18, 2016 Permalink | Log in to Reply

        yes, please

      • pepe 7:37 am on August 18, 2016 Permalink | Log in to Reply

        Yes, please!

      • Marko Heijnen 10:17 am on August 18, 2016 Permalink | Log in to Reply

        Small fraction? We still talk about 100k+ sites. Sometime you already have that amount at 1 host.

        • Jory Hogeveen 12:46 pm on August 18, 2016 Permalink | Log in to Reply

          Still, it would make it a problem for the hosting providers. It’s time those providers woke up and update these ancient servers.
          5.2 isn’t supported anymore for over 5 years… Heck, 5.5 isn’t even supported anymore since 21 Jul 2016.

        • Joachim Jensen - Intox Studio 2:32 pm on August 18, 2016 Permalink | Log in to Reply

          Still a small fraction compared to other PHP versions. And hosts have had years already to migrate. Also note that if the sites are just running (newer versions) of WordPress, migration should be painless.

          Keeping this backwards compatibility is starting to impede overall progress. Feature plugins are often built for PHP5.3+

        • FolioVision 12:53 am on August 19, 2016 Permalink | Log in to Reply

          Marko, I don’t know if you are aware that security updates are available back to v 3.7.18 (or whatever the number is now). There is no reason that modern WordPress has to carry deprecated PHP around its neck like an albatross. Security updates are enough for legacy installs.

      • Jory Hogeveen 12:40 pm on August 18, 2016 Permalink | Log in to Reply

        +1 YES!!!

      • Ipstenu (Mika Epstein) 3:15 pm on August 18, 2016 Permalink | Log in to Reply

        -100

        I wouldn’t be opposed to a warning at this point, but what is there to ‘remove’? Is there some secret 5.2 only code out there?

        And I stand by my arguement that until there is something we cannot do in the current supported code bases, forcing everyone to upgrade when their hosts don’t support it means we will hurt a large number of our users and provide them with no recourse except to move their sites. For people posting here, that’s a ‘meh’ moment. For someone on a low budget, small host, this is way out of their league.

        The major players (everyone on the hosting page) already ditched it. The minors are the problem, and their users will be the one left in the cold.

        • Dirk Weise 6:27 pm on August 18, 2016 Permalink | Log in to Reply

          This discussion comes up every release and wastes many peoples time. Maybe it’s time to decide on something and make a transition plan.

          I understand the problem of leaving users alone who probably have no real idea about PHP and versions (if they had they were most likely already nagging or switching their hosts). Leaving people alone in the cold is no option.

          I think displaying a warning that there is a PHP version running that doesn’t receive _official_ security updates anymore is a very good idea. Maybe even with a date since when. People will contact their hosts, they will get annoyed and change things.

          Maybe this should be acompanied with a statement that on a certian release well in the future a certain PHP version will be required. If you you choose maybe the first or second release in 2018 (before EOL of PHP 5.6 and 7.0 as of http://php.net/supported-versions.php) everyone should be able to prepare.

          There is something that I have the impression of that it cannot be done right with stone age PHP versions: Add autoloading support for plugins and template developers to handle plugin dependencies. That’s why I’m advocating to depreciate old PHP at least in a foreseeable future that seems far away now but will come quickly. The transition has to be slow and will take a lot of time so it’s time to start it.

        • Joachim Jensen - Intox Studio 12:23 am on August 19, 2016 Permalink | Log in to Reply

          My “deprecation” here would be a notice for all users running PHP5.2.
          As for remove, I mean remove support.

          I get your concern about leaving users behind, but as it is now, ~7% are running PHP5.2. How much lower does this number need to be? As already said, hosts have had years to do this. Migrating from PHP5.2 to PHP5.3 is really not an advanced task that will require more hardware or a bigger budget. At this point in time, I think it’s more about lazyness or naivety (I have no data to back this up). And because WordPress already supports later versions, installations shouldn’t break.

          PHP5.2 is not maintained and is not secure, imo that should be enough reason to stop supporting it. But there are also features that eg. can make the architecture of core, plugins and themes better.

          I would be happy with a notice in the admin dashboard for WP4.7, then evaluate how much effect it has had on the release of WP4.8 and decide what to do for WP4.9.

          Most importantly, there needs to be a roadmap for how to end the support for PHP5.2 in WordPress.

      • Guido Scialfa 3:46 pm on August 18, 2016 Permalink | Log in to Reply

        +1

      • bonger 10:07 pm on August 20, 2016 Permalink | Log in to Reply

        It’d be interesting if the stats are available to know what the subversion breakdown of the sites on 5.2 were – in particular how many are on the lowest supported version 5.2.4. Even going from 5.2.4 to 5.2.5 would have developmental benefits (for instance 5.2.5 comes with PCRE 7.3, which supports verbs and is RFC 3629 compliant).

    • Daniele Scasciafratte 9:51 pm on August 17, 2016 Permalink | Log in to Reply

      • Aaron Jorbin 6:23 am on August 19, 2016 Permalink | Log in to Reply

        1) Pinged someone to take a look.
        2) comment 37 seems to still be accurate.
        3) Looks like that is already moving forward
        4) Pinged two committers to take a look.
        5) commented
        6) Pinged a commiter.
        7) Commented.
        8) Can you post a summary? 200+ comments is a lot to read through to understand everything
        9) Commented.

    • Ahmad Awais 9:58 pm on August 17, 2016 Permalink | Log in to Reply

      1— Fields API
      2— REST API Core Endpoints
      3— Customize Posts?
      4— Option to make all the links in a post (which do NOT belong to the parent domain) open in new tab. With new link UI even if you select one link to be like that, the very next link add doesn’t retain the earlier state, which is quite frustrating.

      • Jon Brown 11:51 pm on August 17, 2016 Permalink | Log in to Reply

        +4 — we really need to meet someday because I think we might be sharing one mind..

        • Ahmad Awais 1:11 am on August 19, 2016 Permalink | Log in to Reply

          Jon, couldn’t agree more. .

          @schlessera I think it would be a much better in terms of a11y as compared to what it is now. These days, I am writing about more than 50,000 words every single week! And I am frustrated by having to click through each link and check mark the open in new tab checkbox. The UX flow is broken. An article with 30 links means you get to waste more than 15 mins. Unless until you have Sublime configured to edit HTML part for you. But that’s a less than ideal solution.

      • schlessera 11:52 pm on August 17, 2016 Permalink | Log in to Reply

        Number 4 is problematic because it is both an issue in terms of a11y and a security vulnerability.

        • Jon Brown 12:13 am on August 18, 2016 Permalink | Log in to Reply

          #4 doesn’t introduce any a11y or security concerns that aren’t already there without clicking through the multiple dialogs to tick “open in new tab” does it? It just makes it easier for authors to do what they’ve long been doing for external links. Author who I hear complain a great deal lately about adding open in new tab to links in content they copy/paste into the editor…

          #4 also doesn’t exclude the idea of doing it in the most a11y friendly way. Perhaps with a warning/intersistial that it’ll open in a new tab (w3c G200/201), or an indicator.

        • Ahmad Awais 1:12 am on August 19, 2016 Permalink | Log in to Reply

          @schlessera I think it would be a much better in terms of a11y as compared to what it is now. These days, I am writing about more than 50,000 words every single week! And I am frustrated by having to click through each link and check mark the open in new tab checkbox. The UX flow is broken. An article with 30 links means you get to waste more than 15 mins. Unless until you have Sublime configured to edit HTML part for you. But that’s a less than ideal solution.

      • Helen Hou-Sandi 3:05 am on August 19, 2016 Permalink | Log in to Reply

        Customize Posts absolutely requires that holistic UX+UI explorations of live preview handling be done. The plugin assumes the existence of the customizer in its current state without having proven that it is, in fact, the experience that best suits the purpose. Until then, it is not even up for consideration. Improvements stemming from it may happen earlier, however.

        An option to degrade the UX for site visitors by default will not go into core. If opening all links in a new window is a thing that somehow is needed for a site, it must be a deliberate decision, which is best served in the plugin model, not as a core option.

        • Ahmad Awais 11:33 am on August 22, 2016 Permalink | Log in to Reply

          >An option to degrade the UX for site visitors by default will not go into core. If opening all links in a new window is a thing that somehow is needed for a site, it must be a deliberate decision, which is best served in the plugin model, not as a core option.

          I was not able to clearly explain the problem. Let me elaborate.

          — You are writing a post in the WP editor, and you need to add a link.
          — Link goes to a third party site, so you’d like for it to be opened in a new window so that it doesn’t break the UX flow for reading that article
          — You select a word “Link” to be associated with a URL “/” and press ⌘ + K
          — New link handler pops up (Screenshot http://cloud.ahmda.ws/5csM9L4)
          — To make the link open in a new window, I have to click the gear button wait for the old pop up where I can check mark the box against “Open in a new window” (Screenshot http://cloud.ahmda.ws/4oJd7g8)
          — Now when I have to add another link, WordPress used to retain the state of my choice i.e. any new links I add will open in a new window. That’s not the case anymore

          Complimentary GIF to explain this situation better http://g.recordit.co/f5ZPM166Wk.gif
          Even after saving the draft, these two modals are unable to communicate with each other and also unable to retain user’s choice of keep all the new added links check marked to be opened in a new window. This used to be the default UX flow. Sadly, it is broken. Two many modals, too many clicks just to make sure every next link has the box check marked.

          I hope I get the point across this time.

          • Helen Hou-Sandi 4:44 pm on August 22, 2016 Permalink | Log in to Reply

            I think we may be talking at cross-purposes here – I do understand what you are asking for. When I call this a degraded UX, I mean that forcing a link to open in a new tab is generally considered to be a poor user interaction for the reader, where it should be their choice to decide to open something in a new tab and is very disruptive for some navigation methods. There are times where it may make sense to open something in a new tab, and there may be business decisions or requirements at play as well, but as I said, in those cases it should be a deliberate decision, which in this case is enforced by leaving such behavior to a plugin.

            • Ahmad Awais 4:12 pm on August 23, 2016 Permalink

              Thanks for the detailed response. I am not asking for “Open in new window” check marked by default. I am talking about the UX for a writer, who is writing in the WP Editor. WP Editor used to retain its state. If I had chosen one link to open in a new window, every other link I add to the same post will have the RETAINED STATE of “Open in new window” already check marked. This is not the case now. Which is very disturbing. I write more than 50K words every single week. Believe me, it’s cumbersome. This started to happen since the introduction of new link modal. It’s like the new modal is not communicating with the old one, which is why the state (the choice I made since the first link) is not being retained.

              The issue here is that WP Editor is not retaining the choice i.e. Open in a new window for any new links after I have selected it once.

              E.g. If you upload a picture and chose it to be “Full Size” and “Centered” every other picture you upload in that post will retain your choice. Imagine having to set these options again and again after every image upload for the same article. That’s what’s wrong with the links.

              IMHO This is a UX flow problem and it should be addressed inside the core instead of a plugin.

    • Mike Schinkel 10:11 pm on August 17, 2016 Permalink | Log in to Reply

    • Brian Hogg 10:20 pm on August 17, 2016 Permalink | Log in to Reply

      Better handling if nonces expire in admin (ie. leaving the post edit screen open in another tab while writing a long post). We can do better than -1, “Cheatin’ uh?” and “Are you sure you want to do this?” 🙂

      • Aaron Jorbin 6:26 am on August 19, 2016 Permalink | Log in to Reply

        In my opinion, the solution is that nonces should always get refreshed through the heartbeat which is something that perhaps @mikeschroder would have some thoughts on.

        • Mike Schroder 10:00 pm on August 19, 2016 Permalink | Log in to Reply

          As far as I’m aware, WordPress already refreshes nonces in Edit Post when it is connected, even if it’s in a tab you don’t have active (but the browser is open).

          Chatted with @azaozz briefly on it, and he notes that if it’s more than 24 hours that your computer is not connected, this could be an issue (the nonces are refreshed once every 12 hours).

          In that case, WordPress should prompt you to log in again, and you should have the post_content saved in local storage in case something goes wrong.

          If you’ve been online during that time, and you’re getting an error like that (rather than a prompt to log in), there is likely a bug here, a host is blocking heartbeat from happening when it should, or there could be a theme or plugin that is causing an issue.

          If the others are ruled out, a trac ticket with details would be great, so that we can dig into the problem.

          • Mike Schroder 10:15 pm on August 19, 2016 Permalink | Log in to Reply

            On further chatting with @azaozz, sounds like as long as your login is valid, the core nonces for post edit *should* be updated by heartbeat automatically (without a re-login).

            So the design would be that a user would only see the login box pop to refresh the login session.

    • Andrew Taylor 10:43 pm on August 17, 2016 Permalink | Log in to Reply

      I would love to see configuration management in WordPress core. Being able to store configuration items in code and import/export them to the database makes managing configuration easier, deployment between environments smoother, and allows for version control.

      The WP-CFM plugin is a good start but doesn’t encompass all configuration. Drupal 8 does configuration management really well and it would be great to see something similar in WordPress.

      • Joy 5:26 pm on August 21, 2016 Permalink | Log in to Reply

        This sounds sort of similar to what I was thinking: saving custom post types’ configuration in the database instead of needing code to run to register them each time. The core needs to have UI to define custom post types and custom taxonomies, and the way to do this is to store the options instead of registering with a function call. When you add a user role, the code is run once and options are stored. It should be the same for post types and taxonomies, so that you can use different plugins for the same data. (I have tried several plugins that create custom posts for you, but they store the options differently, so you can’t switch between them.) Then exporting/importing could be as code.

      • Pascal Birchler 7:34 pm on August 21, 2016 Permalink | Log in to Reply

        You might want to check out https://github.com/danielbachhuber/dictator in the meantime

    • Jon Brown 12:01 am on August 18, 2016 Permalink | Log in to Reply

      The dashboard sidebar for administrators on nearly every site I work with has became me a garbage pile. Plugins are adding top level menus, plugins are adding themselves to settings or tools or God knows where with what seems to be based on rolling dice. What could be done to help tame this? Could we come up with some thing better (maybe there is a trac ticket for something related, I’m on mobile and searching for that would be a PITA ATM). Maybe the dashboard splits into two content creation and admin settings? Maybe three content creation, appearance and settings. Maybe there could be better guidelines for what and where new menus should go (unlikely to be followed, but right now I know of nothing official-ish).

      • Drew Jaynes 12:43 am on August 18, 2016 Permalink | Log in to Reply

        One thing I think is part and parcel to this discussion is whether third-party extensions should continue to live on the same level as core components – at least from a first-impression standpoint. They’re certainly treated as equals from a code sense. Either way, there’s upsides and downsides, the biggest upside being the ability to appear more integrated with core. The downsides as outlined by you and others – visual clutter.

        One idea that may be unpopular for obvious reasons would be to rewrite the admin menu (#12718) and demote any non-core extensions to sub-menus. This of course raises the question of where those things would go. Since we already have an “extensions” page in the form of “Plugins”, perhaps a new view there for configuration pages would be worth exploring. You already go there to install and manage plugins, why not configure as well? Any other non-configuration things that may be hooked into WordPress would continue to work as before, just not in the form of top-level menus.

        Corollary to a new “Plugins” view is deciding what to do with Tools. I think it would be very interesting to experiment with consolidating Tools and “Plugins”, the former of which is still an as yet undefined area of the admin. Tools in core is basically a subset of plugins after all (save for Press This) – a place for importers, exporters, categories and tags convertor, and Press This to live. Other third-party extensions have decided the belong in tools as well. I’d love to see the purpose of the Tools screen clearly defined and a concept for combining a consolidation of third-party extensions and Tools into a single cohesive workflow.

        • Felix Arntz 3:31 pm on August 18, 2016 Permalink | Log in to Reply

          I don’t think creating a separate area for plugin UI is the right response to several plugins cluttering the admin. Plugin developers should be educated (which is obviously easier said then done) about how they should integrate their interfaces into the WordPress admin.

          I really like that it’s possible for plugins to integrate well into WordPress, and I personally don’t use plugins that do their own thing, just for better branding or similar. In my opinion it’s fine to use your plugin’s name (brand) on the actual admin page (and if you really really need to, put a banner there), but the rest should completely integrate as if it was part of Core. If the plugin needs a top level item (for example for a post type), that should be labelled after the post type and not contain a brand name or logo. Using UI components that Core provides goes along with that.

          If we prevent plugins to use the regular admin, things are likely to get worse, as we’ll even keep those who “play by the rules” out, basically encouraging them to create alienated user interfaces in any layout and design they like. There will always be plugins that misuse the admin (unfortunately), but these shouldn’t affect the standard for all.

          I think we should investigate and come with clearer guidelines on how plugin UI should look – maybe even as acceptance criteria for the plugin repository.

    • schlessera 12:15 am on August 18, 2016 Permalink | Log in to Reply

      Would be nice to reevaluate the feasibility of an autoloader https://core.trac.wordpress.org/ticket/36335 .
      Early on in the cycle, what are the chances of just committing a flexible Composer autoloader, that lets us put the clean classes into the autoloading queue as they are ready? No need to do them all at once or for one single release, no need to break anything…

      • Richard Tape 6:56 pm on August 24, 2016 Permalink | Log in to Reply

        +1 The conversation on trac was fruitful, but seems to have slowed. I think looking at this early in the 4.7 cycle could be hugely beneficial.

    • Knut Sparhell 12:43 am on August 18, 2016 Permalink | Log in to Reply

      • Better password hashing
      • Post metaboxes cleanup and reorganizing (all closed by default)
      • Remove sending trackbacks (to plugin)
      • Core framework for user groups (no UI)
      • Core framework for multi-language
      • Implement Fields API
      • Continued Multisite enhancements
      • 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 settings cleanup
      • Unmanaged/private plugins marker
      • Implement REST API endpoints
      • Framework/API for 2-factor authentication
      • Preview post on different emulated screen sizes
      • Front-end editing of post content
      • Make a new strategy for bumping PHP minimum version requirement

      But don’t add new complex and ready-to-use features with an UI, like user groups, multi languages and such. Focus on the APIs and make it easier for plugins to add great features and user intefaces. But the editor, is the main workplace for end users. Continue the enhancements.

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

      • David Shanske 3:56 am on August 18, 2016 Permalink | Log in to Reply

        As the Pings component maintainer, I am not against removing trackbacks if that is what people want because there is no source verification, making it vulnerable. Pingback is a successor to Trackback and does have verification. So, basically, we’re not losing features.

        At some point, I’d like to go to Webmention, which is the successor to Pingback…but one thing at a time.

    • cramdesign 1:12 am on August 18, 2016 Permalink | Log in to Reply

      I still think there could be a better way to handle more complex content: https://core.trac.wordpress.org/ticket/29724

    • Chris Van Patten 1:38 am on August 18, 2016 Permalink | Log in to Reply

    • Andy Mercer 2:07 am on August 18, 2016 Permalink | Log in to Reply

      Would love virtual folders in the media uploader/admin page, based on taxonomy.

    • Stephen Edgar 2:34 am on August 18, 2016 Permalink | Log in to Reply

      I’d love to see the Export API given the green light, it has a patch, it’s already included in wp-cli, yay or nay from lead devs seems to be the only thing holding it up https://core.trac.wordpress.org/ticket/22435 ❤️

    • Doug Wollison 2:40 am on August 18, 2016 Permalink | Log in to Reply

      There are probably tickets about these already but…

      1) Page Order UI: native support in the admin for drag-n-drop ordering of pages and other post types that support menu order. This could be done either from the list screen or a separate screen that displays all items.

      2) Custom Index Pages: We have a page_for_posts option, but what about adding that for post types that support archives? Have custom pages serve as the index for custom post types. The option storing each page ID could be named in a format like “page_for_{$post_type}_posts”.

      3) Parent Filtering: Add a filter to the page list to let you filter by parent, including root.

      • Drew Jaynes 2:29 pm on August 18, 2016 Permalink | Log in to Reply

        I think a good place to start on 1) would be to look at merging Simple Page Ordering into core. It’s already an incredibly popular solution. Lots of discussion on a 10-year-old ticket too: #2702. Lots of interest, pretty much needs somebody to drive.

        For 3), don’t think I’ve ever seen a ticket for that. So basically filter by child of?

      • onetrev 5:06 am on August 24, 2016 Permalink | Log in to Reply

        Totally agree on item #1 -> Page Order UI. It needs improvement. Big time. Yes I know there is a lot of emphasis on the customizer, and thus using WP Nav Menu, but the Pages UI still needs to be brought up to date. It’s very much still looking and feeling like 2008.

        Yes there are plugins to support this, and I agree with the philosophy of plugins where possible to extend WP, but when we are talking changing the WP admin UI that should be core territory.

        I’d love to see something like the page management in this plugin, that allows to you to easily add multiple pages / child pages at one time. https://wordpress.org/plugins/wp-nested-pages/

    • Nick Halsey 2:49 am on August 18, 2016 Permalink | Log in to Reply

      I should have quite a bit of time to contribute to 4.7, so my lists are a bit longer 🙂 I’ll note here that I can make the weekly dev chats this cycle but will typically be around 15 min. late each week. I’d also like to take another stab at running weekly customize component meetings, this time with regular agendas and notes posted. My wishlist/priorities are sorted by my anticipated level of involvement:

      Personal Priority Projects for 4.7 (leading development, outreach, iteration efforts):

      • Content authorship in nav menus – #34923
      • A new experience for discovering, installing, and previewing themes in the customizer – #37661
      • Code-editing gateways for users, via custom css in the customizer – #35395
      • Improving contrast and UI consistency in the customizer – #29158
      • General smaller customize component enhancements, with a focus on user-facing changes
      • Do something about custom backgrounds, I’m currently leaning toward removing all of the property options – #22058
      • Customizer outreach and documentation, and an emphasis on coordinating with the theme review team to ensure that themes use the customizer appropriately. For example, #37335.

      Projects that I anticipate being involved with but not leading:

      • Customizer browser history – #28536
      • Customize snapshots/transactions – #30937
      • Customizer notifications center – #35210
      • Refactoring sliding panels UI in the customizer – #34391
      • Twenty Seventeen theme, especially the customizer integrations (particularly if it’s developed as part of core as twenty ten through fifteen were)

      4.7 wish list items that I probably won’t assist with beyond occasional design feedback:

      • Toolbar experiments – #32678
      • Restructuring tinymce buttons – #27159
      • Better pdf handling – #31050
      • Media widget – #32417

      It’s looking like 4.7 will be a fun release!

    • David Shanske 3:59 am on August 18, 2016 Permalink | Log in to Reply

      I’d like to get custom comment types and statuses in as a project and start making it so the responses to posts can be customized to the extent posts can.

    • BackuPs 4:36 am on August 18, 2016 Permalink | Log in to Reply

      Hi

      I would like to see this gets fixed https://core.trac.wordpress.org/ticket/34722

      Please add it to the to fix list for 4.7

      Thank you

    • Ulrich 5:22 am on August 18, 2016 Permalink | Log in to Reply

      Related to themes the tickets I would like to be looked at would be:

    • Nicolas Juen 7:35 am on August 18, 2016 Permalink | Log in to Reply

      • Composer or at least autloading.
      • Stop adding classes for the sake of adding classes into the core, use KISS and SOLID.
      • Fields API all the way
      • Infinite child themes
    • Martin Šnajdr 8:10 am on August 18, 2016 Permalink | Log in to Reply

      Media library folders – or some different way to organize media. I really like the Enhanced Media Library plugin. I think it should be a part of the core.

    • mattrad 8:46 am on August 18, 2016 Permalink | Log in to Reply

      I’m thinking big thoughts here, but:

      Replace native spinners and loading GIFs with either SVG/PNG fallback or pure CSS spinners. If you change the background for wp-login-php and some other pages, you can see pixellation around the images, images/loading.gif in particular looks terrible. See http://austin.passy.co/2014/native-wordpress-loading-gifs/ and try changing the article background.

      Given how widely used spinners and loaders are, I imagine this is more work than it appears.

    • Stefano Aglietti 9:19 am on August 18, 2016 Permalink | Log in to Reply

      Now that reordering for taxonomies table is done wI’d like to see first step for “elements” relationships (posts, pages, taxonomies etc) to evolve more wordpress we need something like post2post (that is nto more in developping state) in core actualli people use post2post with it’s bugs, or make some custom lib to manage relationship from CPT, Taxonomies users etc. A new data table to manage this, and a first version for an API would be welcome

      • Daniele Scasciafratte 10:00 am on August 18, 2016 Permalink | Log in to Reply

        +1 only for mention post2post

      • Jory Hogeveen 12:36 pm on August 18, 2016 Permalink | Log in to Reply

        Not sure if I would say this is a core-thing but it still would be handy.

        Just for info: Pods supports all kinds of object relationships (pretty mutch any WP object you can think of) for a long time now and it works quite similar as you are describing.
        https://wordpress.org/plugins/pods/

        • Stefano Aglietti 6:44 pm on August 18, 2016 Permalink | Log in to Reply

          pods is a solution for no expirience user of for fast simple sites having han API allow dev to write their pliugins with the logic for connection that likes etc. post2post was a fly pods is an elephant. I have my simple muplugins fro CPT and taxonomies, my classes for custom fileds etc i build custom solution often hiding insede mupluings all things that an enduser admin should break. WIth no admin interface the code is simple to mantain and lightweight. WP as a CMS needs some things like relationships, groups and some love to users management.

      • Helen Hou-Sandi 5:05 am on August 19, 2016 Permalink | Log in to Reply

        See #37686

    • Torsten Landsiedel 11:53 am on August 18, 2016 Permalink | Log in to Reply

      I would like to further explore the PHP side of https://core.trac.wordpress.org/ticket/30130
      I think @gitlost would like to work on the JS side. There are already plugins in the repo that could be feature projects/plugins for this.

      • bonger 4:01 pm on August 19, 2016 Permalink | Log in to Reply

        +1 hi, I’ll post on the ticket soon (probably tomorrow) (PS I’m also interested in the PHP side!)

    • Ben Dunkle 12:08 pm on August 18, 2016 Permalink | Log in to Reply

      I’d like to see progress on converting dashicons from a font to an SVG sprite. See #design-dashicons in slack, https://github.com/ryelle/WordPress and https://make.wordpress.org/core/2015/06/11/moving-dashicons-from-an-icon-font-to-svg/
      A lot of work needs to be done, but it will be worth it!

    • Rodrigo Primo 1:35 pm on August 18, 2016 Permalink | Log in to Reply

      Improve algorithm for displaying a hierarchical list of post objects in the WP_Posts_List_Table: https://core.trac.wordpress.org/ticket/34982
      Require confirmation on email change on single site installs: https://core.trac.wordpress.org/ticket/16470

    • David Favor 2:05 pm on August 18, 2016 Permalink | Log in to Reply

      Unzip pre/post hooks in wp-admin/includes/file.php unzip_file().

      Also refactor _unzip_file_pclzip() + _unzip_file_ziparchive() to merge duplicate code.

    • thomaswm 2:05 pm on August 18, 2016 Permalink | Log in to Reply

      https://core.trac.wordpress.org/ticket/34316 and https://core.trac.wordpress.org/ticket/34615

      The first ticket is about the users database table having different fields in multisite and single-site. The second ticket is about introducing a possibility to disable user accounts.

    • Brent Jett 2:06 pm on August 18, 2016 Permalink | Log in to Reply

      Plugin Groups – I’d like to see some exploration around plugin dependencies where “add-on” style plugins can auto disable when their required parent plugin isn’t available. This would also allow some UI exploration into adding “groups” of plugins on the plugins screen. Sorting plugins alphabetically is fine for distinct functionality, but when you start having 1 or more add-on type plugins they really should stay near their parent regardless of their name.

    • Drew Jaynes 3:49 pm on August 18, 2016 Permalink | Log in to Reply

      Improve messaging around core updates to directly suggest deactivating all plugins before update instead of vaguely linking off to the Updating WordPress page in the Codex. Maybe even add an update checklist that further stresses steps that should be taken before update, i.e.

      • Chris Van Patten 4:22 pm on August 18, 2016 Permalink | Log in to Reply

        Encouraging backups is great, but suggesting plugin deactivation directly seems like a recipe for disaster. There are plugins that remove data in their deactivation routine, some themes that require certain “helper” plugins to be active, etc.

      • Ipstenu (Mika Epstein) 5:25 pm on August 18, 2016 Permalink | Log in to Reply

        I have to back Chris on this one. Way too many plugins remove data on deactivation (yes, I tell them not to on code reviews, but if they add it in later…). Also I can honestly say I’ve not disabled a plugin before upgrade since Pre 3.0.

        Serious question: What’s the problem we’re trying to solve by telling people to deactivate plugins pre upgrade?

        • Knut Sparhell 5:53 pm on August 18, 2016 Permalink | Log in to Reply

          Deleting data on deactivtion is a terrible experience in general and specifically makes it hard to debug problems. Those plugin authors deserve the negative feedback.

          And Jetpack now disconnects from WodPress.com upon deactivation.

          • Ipstenu (Mika Epstein) 7:47 pm on August 18, 2016 Permalink | Log in to Reply

            Sure they do, but that doesn’t solve the problem that we would knowingly screw people over. And I for one am massively against that. We KNOW its a problem, and auto-disabling (or requiring it) would make a worse experience.

            I vote -100 for disabling plugins before upgrades, given the current landscape.

      • Knut Sparhell 5:49 pm on August 18, 2016 Permalink | Log in to Reply

        Deactivate all plugins not tested up to the version you are upgrading to.

        • Ipstenu (Mika Epstein) 7:49 pm on August 18, 2016 Permalink | Log in to Reply

          Not enough plugins update in time for that to be beneficial. A warning that explained things to people…

          Of your 45 plugins installed:

          • 10 are tested up to the latest version of WordPress
          • 20 are not
          • 15 have not been updated in over 2 years
      • Pascal Birchler 1:00 pm on August 19, 2016 Permalink | Log in to Reply

        Maybe we can improve some parts of this with Shiny Updates V3. I’ll keep it in mind.

    • Felix Arntz 3:58 pm on August 18, 2016 Permalink | Log in to Reply

      I’d like to work on introducing true network-wide roles so that we can precisely handle capabilities on a network level, beyond just `is_super_admin()`. The existing super admin system should be used in special cases, for example to hard-code users that should have all access. There need to be network-wide roles which are also stored in the usermeta table in network scope. Closely related, we need to clearly make a distinction between a Network Administrator and a Super Admin. See #37616 and #37593

      Other tickets I would like to get some progress (or get done):

      • Improve plugin bootstrapping processes – #37656
      • Network admin should have its own settings API – #15691 (related are #18088 and #35379)
      • Use `WP_Term_Query` for `wp_get_object_terms()` – #37198
      • Handle post type support in `WP_Post_Type` – #37667
      • Introduce helper function `wp_list_sort()` (that’s an easy one, question is: Do or don’t?) – #37128

      And then there are several tickets (many of which are small) that will built upon enhancements in 4.6: #33899, #37053, #37061, #37102, #37217, #37218, #37413, #37414, #37553

    • Luke Cavanagh 6:16 pm on August 18, 2016 Permalink | Log in to Reply

      Any chance of trying to have the media library use relative instead of absolute url’s. So the link when an image is inserted in a post or page just uses the upload url path, then the root url comes from the set site url in the options db table. So then you can change the site url, without all of the image links breaking and not having to run and find and replace on the site db.

    • daretoeatapeach 6:17 pm on August 18, 2016 Permalink | Log in to Reply

      My biggest wish for WordPress would be for them to focus more on engagement and discovery. Steps to make other blogs more easily repostable were a step in the right direction. However, when I login to WordPress, the dashboard landing page is mostly not useful. That space should offer highlights from similar or followed blogs. This is how it works in wildly successful platforms such as Tumblr: when you login you see posts from people you follow. This builds brand loyalty the platform itself, and helps generated readers for those posts.

      I keep trying to understand the popularity of Medium, and it seems 100% due to their ability to get the best content spread around and shared amongst Medium’s base. Whereas every WordPress blog is it’s own separate world. Any community between blogs is built externally, not through WordPress’s structure and design.

      There is no single feature WordPress could add at this point that would benefit them as much as improving community engagement. WordPress already has the best features and is the most customizable. But it will continue to lose bloggers who find community engagement is easier elsewhere.

    • boogah 6:27 pm on August 18, 2016 Permalink | Log in to Reply

      [insert suggestion of putting training wheels on the plugin & theme editor here]

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

    • Stefano Aglietti 6:54 pm on August 18, 2016 Permalink | Log in to Reply

      With metadata for taxonomies the categories/tags/taxonomies management screens need a redesign to allow having complex custom fields forms and a better and simple navigation and management interface. I’m thinking about something more similar to post/page or user management with a table to view and filter them and a specific screen or in place editing . The current 2 columns layout can make a special complex taxonomies with lot of metadata really long with a lot of scroll to do and with few way to customize it

      • Aaron Jorbin 5:29 am on August 19, 2016 Permalink | Log in to Reply

        This might be good to mention on the Design Wishlist. I think it’s been a long time since these pages have been refreshed, so doing an examination of what they need and coming up with some concepts for discussion certainly makes sense to me.

    • tommcfarlin 8:05 pm on August 18, 2016 Permalink | Log in to Reply

      I’d rank this a bit lower (because I know NUX is a big push for this release), but I really do like the ideas for this ticket: https://core.trac.wordpress.org/ticket/37646

      From both a development, configuration, and deployment standpoint, I think it provides a more practical way for those of us who do lots of development and deployment for various clients.

      Again, I recognize this is likely lower but I wanted to toss it into the ring just in case. (And if this has been mentioned earlier in the comments, I don’t mean for a duplicate post — I search the comments for the URL, JJJ’s name, and the ticket ID).

      • Aaron Jorbin 5:27 am on August 19, 2016 Permalink | Log in to Reply

        This is a real interesting concept. It’s one that I think really requires a lot of thought, especially around forward compatibility. Making the bootstrap process more pluggable may make it harder to make changes the bootstrap process going forward.

        • tommcfarlin 11:06 am on August 23, 2016 Permalink | Log in to Reply

          > This is a real interesting concept. It’s one that I think really requires a lot of thought, especially around forward compatibility.

          Agreed! It’s certainly something that should be planned, discussed, and considered far more than just the next release.

          Sure, it’d be nice to see, but it carries a lot of implications for the future of that process alone.

          Even if it’s not something for this release or the next four releases, it’s something that I think is worth remembering for a future release if nothing else.

          > Making the bootstrap process more pluggable may make it harder to make changes the bootstrap process going forward.

          Makes sense. It’s much easier to think about the advantages of it from where I sit now versus how it may impact something in a couple of years.

    • Jose Castaneda 8:07 pm on August 18, 2016 Permalink | Log in to Reply

      I would love to see a bit of work on https://core.trac.wordpress.org/ticket/26695 ( multiple theme screenshots )

      Does also sort of go with NUX

    • Morten Rand-Hendriksen 8:33 pm on August 18, 2016 Permalink | Log in to Reply

      Add support for async and defer attributes when enqueueing JavaScripts. With HTTP/2 async scripts is the recommended best practice (unless you choose to defer them) for performance optimization. There’s already a ticket: https://core.trac.wordpress.org/ticket/12009

      • Aaron Jorbin 5:17 am on August 19, 2016 Permalink | Log in to Reply

        Something that could really help with this in my eyes is to use them in core for wp-admin. For now, while HTTP/2 is still not used heavily enough that I think core can default to it, but a filter to enable http/2 assets and do things like not concatenating files and using proper async and defer attributes would be nice.

        It’s always best for core to use an API that it is adding/changing.

        • Morten Rand-Hendriksen 6:04 am on August 19, 2016 Permalink | Log in to Reply

          async and defer are not HTTP/2 features, but HTML5 features. With or without HTTP/2, they do improve performance. But with HTTP/2, that performance is further improved thanks to multiplexing. Either way, being able to define an enqueued script as async or defer would enable theme and plugin developers to develop more performant code.

          As for core, scripts should follow current best practices, which for the most part is async. The good thing is if the browser does not support either of these attributes, it just ignores them.

    • Morten Rand-Hendriksen 8:36 pm on August 18, 2016 Permalink | Log in to Reply

      Post Type Templates. This has been sitting in limbo for 5 years and seems like a simple enough upgrade that extends existing functionality without causing issues for the end-user while giving developers something they’ve been asking for for a long time.

      Ticket: https://core.trac.wordpress.org/ticket/18375

    • Morten Rand-Hendriksen 8:40 pm on August 18, 2016 Permalink | Log in to Reply

      And of course, restart ImageFlow. The user research and AI has been done. A rethink of the media module is overdue, especially after the introduction of a responsive back end and RICG images. Piecemal changes and modifications of the current interface will not get us where we need to go. Let’s take what the original team spent a year working on and build better functionality for image and media handling!

      • Morten Rand-Hendriksen 8:43 pm on August 18, 2016 Permalink | Log in to Reply

        Somewhat related: Replace static with Dynamic Image Sizes for inserted images https://core.trac.wordpress.org/ticket/35094

      • FolioVision 1:02 am on August 19, 2016 Permalink | Log in to Reply

        Full support of multiple pixel density devices and screens with no hacks or workarounds would be fabulous Morten. There’s been a lot of good movement in media management improvement of late but it would be great to get ahead of the curve and lead the way in terms of image management and image display. Without having to install and juggle half a dozen plugins.

        Not sure we need all the built-in image editing functions which ImageFlow originally contained though. Image manipulation is very server intensive and could make a lot of enemies in shared hosting environments.

        • Morten Rand-Hendriksen 4:11 pm on August 22, 2016 Permalink | Log in to Reply

          ImageFlow was a UX/UI rework of existing functionality only. We took what WordPress already does and changed the interface to make it mobile friendly and more easily understandable. All the editing features showcased in ImageFlow already exist in core, but are either not working well or hidden to the point people are not even aware they exist.

          The only added feature was the ability for plugin authors to extend the native image editing capabilities.

      • summoner 2:29 am on August 19, 2016 Permalink | Log in to Reply

        + 60 million for that
        Current media implementation is only for lazy core devs enough.

        For people who sell or administer WP sites (maybe just as casual users) it is simply not enough in any sense. It is a major pain if a site has more than about 60 images. No means for media organization (just by extra plugins) and we are still just sratching the surface.

        • Helen Hou-Sandi 5:10 am on August 19, 2016 Permalink | Log in to Reply

          Calling people names is not exactly a great motivator, and declaring other people’s thoughts for them is rude, especially when they can speak for themselves. Let’s all please stay away from inserting that kind of thing into what’s otherwise been a constructive and informative thread.

          • summoner 12:29 pm on August 19, 2016 Permalink | Log in to Reply

            Sorry, did not knew there is somebody called Lazy Core Devs in the team 😉
            Just tried to depict how frustrating is the current media implementation for practically all the users.

    • geimist 9:21 pm on August 18, 2016 Permalink | Log in to Reply

      customizing the Style of the integrated MediaElement.js (Theme, Style …)

    • ak-web 7:00 am on August 19, 2016 Permalink | Log in to Reply

      More options like:

      • Deactivate the post-type “post”
      • Deactivate the archive pages
    • Jacob Peattie 7:44 am on August 19, 2016 Permalink | Log in to Reply

      Better Media Library organisation. Have many clients where it would be very useful to organise media so that it’s easier to browse just images relevant to certain contents. Some examples:

      • Browsing only Product images for an eCommerce site.
      • Browsing logos used for a testimonial plugin or partners page/section.
      • Browsing only promotional banners.
      • Browsing/excluding sample media.

      List goes on. Whether it’s folders or tags I’m not particularly fussed, but some way of organising the media library is sorely needed. I’m aware there’s plugins, but I’ve had bad experiences and think it should be part of core regardless.

    • Stagger Lee 9:54 am on August 19, 2016 Permalink | Log in to Reply

      Here is a list of things I personaly use on all websites, or almost all. Dont know what can be done to make them as options, improved workflow, etc:

      1. Make some specific Page titles non-editable for all except Administrators. (Google SEO, slugs, etc..Actually it tends towards I make all of them non-editable with specific snippets. So it is reality. For Editors.)

      2. Limit number of revisions.

      3. Disable attachment page, link attachment to Post.

      4. Default featured image, if none exist.

      5. Settings – Permalinks can have one checkbox to set Expire Headers in .htaccess file, and maybe time length. This one would attract you many more Users, as they would feel websites load faster. Not only feel, they would load faster.

      Maybe some others, cannot remember now.
      They are used on all my websites. I understand not all people use it allways.

    • Stagger Lee 10:00 am on August 19, 2016 Permalink | Log in to Reply

      One nice improvement would be some easy way to add Youtube videos to “Help” tab in backend.
      There are plenty simple 1080p tutorials how to add and manage WP galleries, posts and every other aspect of WordPress.

    • Andreas Beer 12:06 pm on August 19, 2016 Permalink | Log in to Reply

      What I really miss in the multisite dashbord is a dropdown sitelist that doesn’t continue into netherworld when the lower screen rim is reached. Couldn’t that please open in columns or be scrollabel? Also in multisite it would be great if I could switch directly from the admin area of own site – say, settings or menu or widgets – to the corresponding admin area of another site.

      • DanYork 4:37 pm on August 19, 2016 Permalink | Log in to Reply

        So for this:

        > Also in multisite it would be great if I could switch directly from the admin area of own site – say, settings or menu or widgets – to the corresponding admin area of another site.

        you want the option to NOT have to go to the Dashboard first, and then switch to that panel, correct?

        Right now if I am on the widgets panel of Site A, I can go up to “My Sites” and go down to Site B, but then the fly-out menu only gives me four options:

        • Dashboard
        • New Post
        • Manage Comments
        • Visit Site

        To get to the Widgets panel of Site B, I have to go first to the Dashboard and then to Appearance -> Widgets.

        I understand how this could be useful. I guess I don’t personally make that switch enough between sites that the extra step of going to the Dashboard annoys me. But I could see for people who frequently switch between sites that this could be very helpful.

    • DanYork 4:41 pm on August 19, 2016 Permalink | Log in to Reply

      As a true wish-list item, I would love to see the editorial calendar functionality of EditFlow – http://editflow.org/ – baked into the core functionality. For people using WordPress and planning out their posts, this functionality is critical. When I’ve shown people my sites with EditFlow installed, a frequent response has been “why isn’t that just part of the basic features?” (Having said that, I would not have the cycles in the 4.7 timeframe to actually help with this, although I would be able to help in testing.)

    • Mark Root-Wiley 9:03 pm on August 19, 2016 Permalink | Log in to Reply

      In line with the NUX focus, rethinking screen options and trying to make them findable by new users would be a big win. #21583 is relevant though possibly so old that a new ticket should get started.

      One simple idea would be to have them open by default once per screen (maybe only for the Dashboard, New Post, and All Posts screens?) for a new user, after which they return to the normal default collapse.

      Screen Options are so important to help new users hide what they don’t want and find some things they do. (Can we make Excerpt checked by default?) Whenever I train users, it’s one of the first things I show them, and there’s no way they’d find it otherwise.

      • summoner 9:25 pm on August 19, 2016 Permalink | Log in to Reply

        I understand your point but what if core just made some video tutorials (similar to the new features in each release). I mean you really can not always develop with newbies in mind and there is simply no enough room to fit somehow all the possible options on 1 single screen.
        If you still do so, then at the end you will only have newbies and dummies who use WP.
        There is nothing wrong with newbies or dummies, they simply need some help to learn basic things but in a way that is not annoying for experienced WP users, and the worst thing could happen is fit UI to the needs of newbies even by dropping UI for some features or not implementing UI for new features as they would “overhelm” UI.

        • Mark Root-Wiley 10:30 pm on August 19, 2016 Permalink | Log in to Reply

          I’m really just talking about the specific UI of the “Screen Options” tab and making sure that new users are aware of what’s there: both that it adds/removes elements on the screen and that the options change from page to page.

    • kevinwhoffman 9:22 pm on August 19, 2016 Permalink | Log in to Reply

      Customizer styles in the visual editor. We currently have add_editor_style() for adding theme styles to the TinyMCE editor, however that functionality stops short of reflecting colors, fonts, and other theme_mods defined by the user in the customizer. This results in a disconnect between the styles seen in the customizer and front-end of the web site versus those seen when editing content.

      With Otto’s help, Matt Cromwell and I have a working prototype that allows for a one-to-one reflection of customizer styles in the visual editor. Matt and I think this could make a great addition to Twenty Seventeen as it creates a more consistent presentation of content throughout WordPress. It would also better meet expectations in the New User Experience, where users expect their content to be styled the same regardless of whether it’s in the front-end, customizer, or visual editor.

      See Matt’s summary of our progress at https://www.mattcromwell.com/dynamic-tinymce-editor-styles-wordpress/.

      • Paal Joachim Romdahl 1:33 am on August 20, 2016 Permalink | Log in to Reply

        This is very interesting! A better integration between the Customizer and the TinyMCE editor. Making visual adjustments in the Customizer should be seen while working in the TinyMCE editor and this approach really outlines this possibility! Awesome!

    • Mark Root-Wiley 10:47 pm on August 19, 2016 Permalink | Log in to Reply

      Getting some type of roadmap out of #27159 would be incredible.

      This might tie into @drewapicture‘s comments suggesting data collection (e.g. how many people are underlining text?) and/or @ipstenu‘s suggestion to overhaul the Sample Page (possibly tell people how formats were made).

      I understand the need not to completely overhaul the editor in one version, but even some button reordering could go a long way toward improving peoples’ editing habits. Encourage proper use of headings, removing full justification and underline, etc. could make a meaningful improvement to web usability over time. WordPress.com has made similar changes to the editors, so we know this is possible without blowing up the web.

      Here’s my theory of change roadmap for why this matters:

      1. Change the order of (or remove) buttons
      2a. Fewer buttons = faster onboarding for new users
      2b. Better buttons = More semantic formatting (headings, blockquotes, bold, italic, remove underline)
      3. Improve a11y and content portability on the web (between themes, into RSS, with read-it-later apps, etc.)

      p.s. Making the TinyMCE formatting shortcuts filterable (#36890) would be super sweet. I have lots of ideas!

    • summoner 11:26 pm on August 19, 2016 Permalink | Log in to Reply

      Okay, but why just remove any buttons in favor of newbies as you tell in 2a ??!!
      Excusme but i am not a newbie and simply do not want to use always text mode and input ftml tags to achieve the same thing that i could before removing buttons from tinyMCE editor. Actually it would be really frustrating as if you switch between graphical and text modes…erll some nifty autoformatting happens regardless if you want it or not.

      PLEASE, PLEASE JUST FORGET DOING EVERYTHING IN FAVOR OF NEWBIES THEY ARE STILL NOT THE MAJORITY AND WHY HAVE OTHERS ALWAYS S**K (sorry…) BECAUSE OF SOME DEVS DO THINK NEWBIES ARE COMPLETE IDIOTS? THEY ARE NOT AND CAN USE/RECOGNIZE BUTTONS!

      • Ipstenu (Mika Epstein) 6:33 pm on August 21, 2016 Permalink | Log in to Reply

        This is not the first time you’ve heard this, but summoner, please watch your tone.

        All caps is shouting on-line, and the language and manner in which you’re expressing yourself is confrontational and implies a large disrespect to everyone. Core developers are humans too. Please try to be a little more polite and humane.

        • summoner 1:11 am on August 25, 2016 Permalink | Log in to Reply

          Now this is just great… “the language and manner in which you’re expressing yourself is confrontational and implies a large disrespect to everyone”
          Do you mean people are only allowed to write their opinion only if they agree with the completely wrong tendency of removing items from the UI? Removing items from the UI is the last what newbies or advanced users want. There are only devs who think newbies are complete idiots (otherwise they would not want to remove graphical buttons just beacuase there are more than 3 of them in tinyMCE). But some devs are really polite and humane by just thinking that way but not actually telling it, just removing those buttons. Okay then let them just downgrade WP to a level where neither newbies nor advanced users can easily use…guess you what…the texteditor.

          If i wrote devs are idiots or newbies can not use more than 2 graphical buttons then you would be completely right by telling me i am “confrontational” and i show “large disrespect to everyone”. If you look carefully enough you will discover i wrote quite the contrary.

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

            Ipstenu did not say anything about the content of your actual opinions, issue is being taken with things like all-caps and calling core devs “lazy”. This is also the second time in this thread you’ve completely misrepresented something for the sake of FUD. You do yourself no favors by distracting from whatever it is you are saying that is actually relevant to a wishlist.

    • brewonehelp 7:36 am on August 20, 2016 Permalink | Log in to Reply

      Improve search results for front end users.

    • dartiss 9:42 am on August 20, 2016 Permalink | Log in to Reply

      It would be nice to have some further features for plugin developers, in particular to reduce the amount of code that’s added to most plugins. So, to as an example, I had some one line “tweaks” that I use for all my sites. They’re useful and I decided to share them as plugins. Those 1 lines suddenly turned into much bigger pieces of code by release although, at heart, it was doing the same thing. It’s removing all that extra code, that many plugins will make use of. So, 4.6 added just-in-time loading for translations which was one chunk of code less for any plugin.

      So, as an initial idea – many plugins add extra links to the plugin data listed in a WP installs’ plugin list. They may be donation, support or settings links. This adds a bigger chunk of code to a plugin but could they be added as further fields, instead, to the plugin root file header – donation links can be added to the README but not to the plugin header (well, okay you can, but it doesn’t do anything). So maybe we could make better use of this header data to add these links?

      I’m sure there are other things similar to this that could be done – I’m sure Mika has a better idea of what pieces of code she sees all the time in submitted plugins 🙂

    • Rami Yushuvaev 12:02 pm on August 20, 2016 Permalink | Log in to Reply

      https://core.trac.wordpress.org/ticket/36574 – Redesign Term Pages
      https://core.trac.wordpress.org/ticket/35736 – Replace ‘Lost Password’ phrase with ‘Reset Password’
      https://core.trac.wordpress.org/ticket/37492 – Unifying translation strings in wp_die()
      https://core.trac.wordpress.org/ticket/35774 – WordPress admin structure<br /> <a href="https://core.trac.wordpress.org/ticket/37257" rel="nofollow">https://core.trac.wordpress.org/ticket/37257</a> – Minor CSS fix on “.nav-tab-wrapper” class<br /> <a href="https://core.trac.wordpress.org/ticket/33045" rel="nofollow">https://core.trac.wordpress.org/ticket/33045</a> – New conditional tags for child/parent pages<br /> <a href="https://core.trac.wordpress.org/ticket/36098" rel="nofollow">https://core.trac.wordpress.org/ticket/36098</a> – WP install: The “Repeat Password” field is marked as required. It’s not.

    • Frank Klein 1:10 pm on August 20, 2016 Permalink | Log in to Reply

      I consider that the WordPress testing framework, as well as the tests themselves could benefit from a concerted effort towards improving them. There is lots of low-hanging fruit, which could be a good entry point for new contributors. There are also a couple of topics that would need to be discussed among contributors, especially those with lots of testing experience.

      In my opinion, every minute invested into making the tests and the framework better will result in extra-ordinary time savings down the line. Testing is essential to keep WordPress stable while extending and refactoring the code base. And as tests are required for all new code, making the testing framework as stable and accessible as possible is paramount.

      Here’s a list of things that would need to be worked on, in no particular order:

      • Introduce guidelines for organising tests: Currently finding existing tests, or adding a new test in the right place is not easy, as there are no guidelines for how test files are organised. A related ticket is #26999, but it is focused on changes. Before we get to the point of actually modifying the existing layout, we would need to find a fool-proof set of guidelines which indicate in which folder tests get placed, and how the individual files, and tests, are to be named.
      • Improve file layout: Some files contain a mix of classes and functions. We should move those to their own files, as was done in #37523 as an example. This task is similar to #33413.
      • Add PHPDoc comments: The test files, classes, and methods, as well as helper classes and functions almost all lack proper documentation in the form of PHPDoc comments. This makes it much harder to write tests, and understand existing tests. We would need to add documentation to all code elements, starting with the testing framework, because that’s the most important thing. Tests should at least have a ticket reference, but preferably also a description of what the test covers. Some tickets are really long, and it’s often not obvious why a particular test was added.
      • Introduce a procedure for deprecating code: During the work on the testing framework, there will be code that is no longer valid or needed, but that needs to be kept for backwards-compatibility reasons. There would need to be a procedure on how to handle such code, see #37521.
      • Review Factory classes: Factory classes for posts, terms, etc. all inherit from WP_UnitTest_Factory_For_Thing. However it is my experience that not all child classes implement the parent methods, see for example #37630. Let’s review all factory classes, and ensure their implementations are complete, and working.
      • Use PHP5 property declarations: Some test classes, like Tests_Dependencies_Style still use PHP4 style property declarations, so those should be modified to use the PHP5 declaration style, with the right level of visibility.
      • Introduce mocking: Running the tests is slow, and #30017 tries to optimise the slowest tests. However I would consider that you can optimise things all you want, as long as you only use integration tests, which rely on a database, things are always going to be slow. There are libraries like BrainMonkey and WP_Mock that allow to mock the needed code elements. This allows developers to write true unit tests, which run a lot faster. I really see no downside to this, as you can combine integration and unit tests to get full coverage.
        An example would be the get_post() function, which is used by a lot of functions, usually when no post object gets passed, and the current global $post variable is used. Once you have covered get_posts() with integration tests to ensure that it works correctly, there’s no point in having to run that code again to test functions using it internally, just mock the needed return value. This will result in real speed benefits, as you can often bypass the database entirely.

      In addition, I would propose an experiment to the interested contributors, and that would be to write the tests for new functions or classes before you actually write the tested code.

      In my experience, this leads not only to code that is easier to test, but also to better thought out APIs. In addition, tests written after new code has been added are often written with a “Told you this works right” mindset, as in you only want to confirm that the code is working. This leads to poorer tests, as you won’t accidentally discover edge cases you haven’t considered.

    • B0RG 2:21 pm on August 20, 2016 Permalink | Log in to Reply

      More on infrastructure: please finally implement a testing pipeline for the wordpress plugin graveyard. It is still a catastrophe to see how many unmaintained, old and broken code is advertised on the wordpress plugin site. Please just TEST plugins on every new release and remove plugins that cause errors. Thanks.

    • Benoît Chantre 2:37 pm on August 20, 2016 Permalink | Log in to Reply

      • settings improvements (#22198, #27111, #32396)
      • site title link should point to home url (#34625)
      • ability to mark plugin as unmanaged (#32101), same for themes (#14179)
      • get Menu name with wp_nav_menu() (#13910)
      • hierarchical meta box display issues when messing around with new terms (#26475)
      • allow themes to pre-register multiple custom backgrounds (#18623)
      • 2-factor authentication (in core or as a wordpress.org plugin)
    • Joy 6:33 pm on August 21, 2016 Permalink | Log in to Reply

      I would like to see the details filled in. As WordPress evolves, the UI changes and some details and options get lost. An example is in the UI for adding a gallery to a post, it doesn’t let you do a generic shortcode. My default usage is , but that can’t be done using the UI. It also doesn’t handle the order and orderby attributes, having just one checkbox for “random order”.

      Another example is the Customizer has overtaken a lot of Appearance. I can no longer set my header image separately, or my background separately, without the bloat of loading the Customizer and the Live Preview. I think I read somewhere that those were probably going away anyway, but why? Not all of us want to use the Customizer. The Live Preview should at least have a toggle.

      Another example is the Media Library, which has inconsistencies between List view and Grid view. Grid view shows only images, no details even on hover. List view shows lots of information and ways to manipulate it, but some of the thumbnails are missing for images I added after the others (not sure what this is, but could be a plugin to reduce thumbnail generation).

      Another example is the buttons available in the editor — they are very different in Visual mode and Text mode (number, look, order).

      I guess the overriding concern is consistency and thoroughness. Another commenter mentioned the lack of standards for where plugins add menu items. I wouldn’t want to restrict plugins to submenus, but some way to keep things consistent is needed. I have a Post Type plugin that makes a top-level menu with Settings, Edit, and Utilities as submenus. But a gallery plugin put a submenu under Settings, and a top-level menu item with two submenu items for manipulating the gallery and skinning them. Very inconsistent.

    • David A. Kennedy 1:34 pm on August 22, 2016 Permalink | Log in to Reply

      I’d love to see #19627 worked on, especially how it relates to new user experience and integration for Twenty Seventeen.

    • Alexander Gounder 1:40 pm on August 22, 2016 Permalink | Log in to Reply

      I’d like to see the next page quicktag added a button in the editor #32895 which was removed a long while ago to reduce clutter and now the feature is mostly forgotten see #1345

    • Carolina Nymark 3:05 am on August 23, 2016 Permalink | Log in to Reply

      The most important for me is that the Theme Review Team are included in the discussions regarding major theme changes.

    • Paal Joachim Romdahl 11:19 am on August 23, 2016 Permalink | Log in to Reply

      It would be great to continue to work on the Top Admin Toolbar project: https://core.trac.wordpress.org/ticket/32678

    • daniyalahmedk 9:42 pm on August 23, 2016 Permalink | Log in to Reply

      I think we should include all Media Functions for example getMediaTitle etc, like here : https://core.trac.wordpress.org/ticket/37801

    • Djib's 10:36 pm on August 23, 2016 Permalink | Log in to Reply

      A nice feature would be to change the permalink structure without changing the url of older articles.
      Many users complain of having 404 errors on old articles. This causes problem when there are dozens or hundreds of articles.

      Many users complain of having 404 errors on old articles. This poses problem when there are dozens or hundreds of articles

      Not everyone has the comptences to manage the redictions

    • Djib's 10:37 pm on August 23, 2016 Permalink | Log in to Reply

      A nice feature would be to change the permalink structure without changing the url of older articles.
      Many users complain of having 404 errors on old articles. This causes problem when there are dozens or hundreds of articles.

      Not everyone has the comptences to manage the redirections

    • Bradley 9:19 am on August 24, 2016 Permalink | Log in to Reply

      On the whole I would like to see old features improved, rather than new features added. That said there are a few frequent pain points I come across:

      • More fine grained capabilities. I’m totally fine with requiring a plugin to create new roles, and edit capabilities, but far to much sits under the ‘manage_options’ cap. It would be great if you could split it into multiple permissions. (This is also a frequent annoyance with plugins – e.g. wanting a user to edit Analytics settings, without having access to site settings.)
      • Better handling of assets, including the ability to add extra attributes (e.g. async on scripts). It would also be good to have an automated way to update the version numbers. (At the moment I manually set the version numbers based on the file updated time, but a core way to do this might be possible).
      • Easier ways to turn off front-end assets loaded by WordPress. I understand that for most people the scripts for embeds, emoji, jQuery migrate are fine but turning them off is a bit of a faf. Maybe improved documentation around this would be enough?

    • Loombago 10:52 am on August 24, 2016 Permalink | Log in to Reply

      In core Individual widgets for post, pages and CPT like this: https://wordpress.org/plugins/wp-page-widget/

    • Destac 10:02 pm on August 24, 2016 Permalink | Log in to Reply

      I think post formats need a review. Currently, the way we handle “video” for example makes no sense. If I have a theme and add a YouTube video for instance and then switch themes that also uses video it won’t carry over.

      There needs to be a unified way (like how we handle featured images) to handle these types of embeds whether it is image, video, or audio this will solve one of the primary issues with Post Formats and keep them relevant and make them more streamlined across themes.

    • Shaped Pixels 11:52 pm on August 24, 2016 Permalink | Log in to Reply

      WOW…very popular post and comments a mile long. Here’s my common sense ideas that focus more on users wanting easier/more functionality without having to install a million plugins….

      1. Ability to enable/disable widget titles from the front-end
      2. Ability to show widgets on select pages
      3. A better method for a user to grab an image File URL
      4. Fix the editor from adding p and or br tags after nesting shortcodes on new lines (ANNOYING) This should be core.
      5. Add a text field to the bottom of every widget for entering in a custom class
      6. Stop the editor from deleting empty span and italic tags which often are used for font icons. This should be core as well.

      I know the core will say (as they always do), there are plugins that can do all of the above. Yes there is, but why should the end-user have to install several plugins to handle the above when it really should be in the core.

      One other thing which I know will never happen….I’d love the customizer to be kept to theme options only. It’s getting to a point where the whole admin is being moved into the customizer. Managing menus and widgets can be a nightmare for larger sites.

      • Shaped Pixels 11:56 pm on August 24, 2016 Permalink | Log in to Reply

        OK that is annoying, some things stripped out of my post…some html tags. Where’s the reference to post lists, code, etc. for the comments here?

        • Destac 2:04 am on August 25, 2016 Permalink | Log in to Reply

          I agree that he customizer should be theme options only its intention “Customizer” is to replace theme option panels and to make the process of creating the site and making it look nice in real time. It’s not for content creation.

        • summoner 3:00 am on August 25, 2016 Permalink | Log in to Reply

          Customizer…IMO nobody who understands the differences between front-end and back-end would ever want to see the front-end right within the back-end. Simply do not understand why there are intentions to let customizer take control of already existing and much better UIs. And if they want it at any cost why exactly do it in core and not as plugins?! (while always telling us for more useful features that those should remain plugins territory…)

        • Ipstenu (Mika Epstein) 4:22 am on August 25, 2016 Permalink | Log in to Reply

          The code tag or

          <code>Code here</code>

          using shortcodes will work…

          Yeah, that works. So [ code] code here [/ code] Without the spaces.

      • Shaped Pixels 4:07 am on August 25, 2016 Permalink | Log in to Reply

        Just to reiterate about the editor and shortcodes being as my previous post had some html stripped out….the editor adds paragraphs with new lines of nested shortcodes. I cannot count how many times people have been frustrated trying to figure out how to remove the tags being added. I’ve added code to my themes to prevent that, but get told to remove it as this is plugin territory. This should not be plugin territory. So I seriously hope the core devs consider solving this problem as it does drive people nuts.

    • WebHeer 11:30 am on August 25, 2016 Permalink | Log in to Reply

      Hi, I would like to be less depended of plugins. So cache, seo, lightbox, security, social icons, editor, editor in widgets, contact form, etc, should be in the core i think.

      Regards

    • WebHeer 11:33 am on August 25, 2016 Permalink | Log in to Reply

      Hi, I would like to see the media items in maps just like in windows explorer.

      Regards

    • J. 12:22 pm on August 25, 2016 Permalink | Log in to Reply

      I’d love a much easier way to create custom permalink structures for CPT’s and taxonomy.

      For example, http://www.example.com/custom-post-type/custom-taxonomy/post.

      If that makes sense?

      I’m not skilled enough to build this so someone else would have to do it.

    • Paul Bearne 5:11 pm on August 25, 2016 Permalink | Log in to Reply

      Can throw this into the list https://core.trac.wordpress.org/ticket/36591 I would like to see this to fixed

    • Aumkar 5:42 pm on August 25, 2016 Permalink | Log in to Reply

      Inbuilt page builder or allowing customizer to create page content.

    • Helen Hou-Sandi 3:10 am on August 26, 2016 Permalink | Log in to Reply

      A wishlist item from me! #14877 – adding some callbacks for different post edit taxonomy term selection meta boxes (radio, select, etc.) and making the current ones each work for both hierarchical and non-hierarchical.

    • benoitcrt 8:49 am on August 26, 2016 Permalink | Log in to Reply

      An idea for 4.7?
      Just a directory features in media database. With real and virtual directories.
      For example, for each page/article/custom content, I cant find a virtual directory with all the medias for this page.
      But if I want, I can also create my own manual directory to store my global medias, pdfs, and others pictures.

      Maybe with this feature, we can set (administrators) a quota limit for each article, for example. 🙂

      Because actually, the media database is a real mess when you have few pages and articles.

    • dartiss 12:41 pm on August 26, 2016 Permalink | Log in to Reply

      One further thing I’d like to see is something similar to what this plugin provides… https://wordpress.org/plugins/version-info/, which is some basic system information in the footer of admin. Incredibly handy, particularly for support purposes and it would be great to have this as default.

    • Adam Silverstein 3:53 pm on August 26, 2016 Permalink | Log in to Reply

  • Andrew Ozz 2:00 am on July 29, 2016 Permalink |
    Tags: , , , ,   

    Editor changes in 4.6 

    In WordPress 4.6 TinyMCE is upgraded from version 4.3.10 to 4.4.1. There are numerous bug fixes and several new features, most notably a new inline theme (changelog).

    The wpview editor plugin (that is responsible for showing gallery, video, audio, and oEmbed previews) was updated to use the TinyMCE API for non-editable elements. This brought some small changes and improvements in the UI, for example “views” are draggable now. On the back-end the wp-mce-view-unbind event was removed as it doesn’t exist in the API. It was intended for cleanup/unloading but was never very reliable. If a plugin needs to unload instance dependent scripts, it can use mutation observer to monitor when the view node is deleted. See #36434 for more information.

    wpview remains an experimental API, though with each iteration it is getting closer to being finalized. As an experimental API, breaking changes are expected. As always, please test your plugin now if it modifies or depends on the editor, especially if you use experimental features like wpview.

     
  • Matt Miklic 3:14 pm on July 7, 2016 Permalink |
    Tags: , , ,   

    Native Fonts in 4.6 

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

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

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

    The Font Stack

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

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

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

    Details

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

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

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

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

    Screenshots

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

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

    ImageMagick Vulnerability Information 

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

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

    How is WordPress affected?

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

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

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

    How do I know if my site is vulnerable?

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

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

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

    How do I patch the vulnerability?

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

    ImageMagick 6.9.3-10

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

    Further reading

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

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

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

    Font Natively 

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

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

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

    Current Status

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

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

    Participants

    Example screenshots (more needed)

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

    Version 4.6 

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

    Schedule, Focus, Features

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

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

    Community Wish List

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

    Tickets by Committers/Component Maintainers

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

      Redesign term pages