WordPress.org

Make WordPress Core

Updates from August, 2015 Toggle Comment Threads | Keyboard Shortcuts

  • Daniel Bachhuber 8:11 pm on August 24, 2015 Permalink |
    Tags: , ,   

    Shortcake (Shortcode UI) chat summary – August 24th, 2015 

    Present: @danielbachhuber, @goldenapples, @miqrogroove, @azaozz

    Logs: https://wordpress.slack.com/archives/feature-shortcode/p1440442841000013

    • We triaged the remaining issues for v0.5.0. Daniel will be picking them up over the next day.
    • A big project for v0.6.0 will be to go through core’s feature plugin guidelines and identify what we need to change to be valid.
    • Spent time discussing @miqrogroove summary of shortcode problems, and proposed solutions

    Next chat: same time and place

    Next release: v0.5.0 – this week (a bit overdue)

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

    WordPress 4.4: What’s on your wishlist? 

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

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

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

    It can be anything: big or small.

    As most of you know, I am leading WordPress 4.4

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

     

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      Congrats Scott.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

            • dantewaters 5:45 am on August 30, 2015 Permalink

              Agreed, it would be great if they could be sectioned off (where you still see them but they are sectioned by months). Similar to photos on IOS where the images are sorted by location.

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

          That would be useful!

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

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

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

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

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

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

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

          +1

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

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

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

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

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

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

        +1

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

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

      • chatmandesign 5:11 pm on August 28, 2015 Permalink | Log in to Reply

        Agreed. Folders, tagging, some way to sort Media is desperately needed.

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

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

      Also better mobile detection for mobile devices will be great.

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

      Term Meta would be great!

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

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

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

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

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

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

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

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

      My wish list is very developer

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

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

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

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

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

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

      Sanatize function for choice in customizer

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

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

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

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

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

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

          rkoller,

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

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

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

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

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

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

        Responsive Images are on my mind for 4.4

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

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

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

      Term meta

      Rest API

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

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

      Native multi-domain support for network installations.

      This feature is missing way too long now.

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

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

      Scaling Users on single installs as well as multisite.

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

      Custom comment types #12668

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      REST API in core! 🎉

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

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

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

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

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

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

      I would like to see:

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

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

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

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

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

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

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

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

          Feature plugin material for sure.

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

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

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

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

        +1 that would be super useful indeed!

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

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

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

      Would like to see improvements in these areas:

      • User profile screen.

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

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

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

      :)

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

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

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

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

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

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

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

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

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

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

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

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

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

      +1s for REST API and Fields API.

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

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

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

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

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

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

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

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

      My wishlist is short, but old.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      I’d also like to see about #30783.

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

      Obviously REST API in core.

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

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

      I would like to see a new default theme.

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

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

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

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

      And a better media manager.

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

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

        This is a great suggestion.

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

        +1 role management
        +1 media manager

        I am tired of using klunky plugins for both tasks.

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

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

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

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

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

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

        +1 on groups

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

        User Management also needs granular control over roles.

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

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

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

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

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

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

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

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

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

            The average roles people are missing and complain about:

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

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

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

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

              Sorry for lapsus, 12 hours, one day.

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

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

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

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

            • Justin Tadlock 1:22 am on August 29, 2015 Permalink

              Thanks for getting back to me. It’s always helpful to read about these sorts of things.

              FWIW, I always set up a “blocked” role on my sites. And, I set up a “spam” role to make a distinction between spammers and bozos. To really make this useful though in my own plugin, I need to create a UI for explicitly denying (not just removing) caps from those roles. It’s on the roadmap.

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

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

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

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

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

      == For Plugin Developer ==

      • composer

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

      == For User ==

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

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

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

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

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

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

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

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

      Fields API

      Post Formats 2.0

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

      Congrats Scott!

      About the Wish List, here you go

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

      That’s all for now.

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

      Hey congratz!

      In 4.4 why not theming the admistration side 😀

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

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

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

        REST API will solve that problem in pretty innovative way.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      Some things I’d like to see;

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

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

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

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

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

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

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

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

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

      COMMENTS

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

      JQUERY & BUILD TOOLS

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

      PERFORMANCE

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

      Separate capabilities for manage_widgets and manage_nav_menus!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      Another vote for REST API

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

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

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

      A voice in the wilderness … :)

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

      Thanks for asking!

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

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

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

      My wishlist:

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

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

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

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

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

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

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

      Hey guys,

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

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

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

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

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

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

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

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

      Hi,

      First of all, thank you for asking us :)

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

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

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

      PLUS

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

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

      and then

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

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

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

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

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

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

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

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

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

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

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

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

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

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

        ++++ COOKIE IS NECESARY

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

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

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

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

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

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

      Distinct Multisite WordPress Core

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

        +1 for Support opening images in a modal

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

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

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

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

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

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

      My Wisher in order

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

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

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

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

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

      Please read my proposal for 4.4 as a developer:

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

      It could really make a huge difference for WordPress performance.

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

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

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

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

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

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

      prevent the upgrade of plugins

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

      export categories and tags

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

      Posibility of multilingual

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

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

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

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

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

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

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

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

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

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

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

      Hi Scott,

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

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

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

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

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

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

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

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

      Best regards,
      Gal

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      (using native gettext would decrease memory usage)

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

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

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

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

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

      What is really necessary:

      • A real good date-picker for posts and pages

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

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

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

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

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

      My wishes for 4.4 are:

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

        You reminded me about this.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      RICG Responsive Images
      Term meta

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

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

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

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

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

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

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

        Re: form fields: See the Fields API

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

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

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

      https://core.trac.wordpress.org/ticket/10142 – Add metadata support for taxonomy terms
      https://core.trac.wordpress.org/ticket/21734 – Completely remove global terms
      https://core.trac.wordpress.org/ticket/14310 – Make template hierarchy filterable
      https://core.trac.wordpress.org/ticket/22938 – Presentation of hierarchical taxonomy in Media modal should be checkboxes rather than comma-separated tag list
      https://core.trac.wordpress.org/ticket/13310 – Extend option_name to varchar(255)
      https://core.trac.wordpress.org/ticket/32101 – Ability to mark plugin as unmanaged
      https://core.trac.wordpress.org/ticket/22942 – Remove Post by Email

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

      Here are some of my ideas.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      + REST API
      + FIELDS API
      + SHORTCAKE

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

      :)

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

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

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

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

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

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

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

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

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

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

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

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

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

        :)

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

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

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

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

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

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

      Can the galley link images to custom URLs yet?

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

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

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

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

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

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

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

      Filter plugin searches by WP version

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

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

      A better search

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

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

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

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

      First… endorsements:

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

      Second, my own requests:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      Please delete all emojis!!

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

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

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

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

      Two more wishes:

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

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

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

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

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

      Hey Scott,

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

      Options:

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

      Thank you,
      Gal

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

      *BETTER PREVIEW MODE*

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

      Thanks,
      Moritz

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

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

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

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

      (2)Captcha support by default

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

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

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

      Just one thing. Fix bugs.

    • Dieter_Z 7:45 am on August 28, 2015 Permalink | Log in to Reply

      There is one thing I often miss:
      That editors are allowed to edit the menus and the widgets. Clients often need to make changes to the main menu or side menus and the footer area also. I think it should be a core feature that you can easily allow editors to make changes there. Only menus and widgets, no further items of “appearance”.

    • chatmandesign 5:24 pm on August 28, 2015 Permalink | Log in to Reply

      Besides the REST API & improved media management, I think one of the biggest existing issues with WordPress is the search system. It’s really not very useful without adding a plugin like Relevanssi or SearchWP. While the full GUI for weighting keywords, indexing custom fields, etc., that comes with those plugins is probably overkill for core, at the very least search should provide features like keyword relevance sorting, fuzzy matching, and “did you mean” recommendations that are standard in most modern search engines. I also think there should be standardized flags developers can use when adding custom post types to specify metadata fields that should be indexed for that post type.

    • chatmandesign 5:27 pm on August 28, 2015 Permalink | Log in to Reply

      Here’s another improvement I’d love to see: Better integration between the post editor and menu building. I’ve never understood why selecting which menu a post or page should show up in isn’t as simple as making a selection in a metabox when creating or editing the page.

    • chatmandesign 5:51 pm on August 28, 2015 Permalink | Log in to Reply

      Here’s a biggie: Login security improvements. Most security plugins require making a lot of decisions that are over the heads of average end users, but I can think of two fairly simple steps that could be taken to dramatically improve security without significantly complicating anything for users:

      1) Automatic account lockout for a predetermined short period of time (say, 5-20 minutes) after a set number of failed login attempts (say, 5-10) within a set period of time (again, 5-10 minutes). This is fairly minimal, but would slow brute force attacks WAY down. Couple it with an unlock system based on emailing an authentication code (usable once per lockout period perhaps) and you basically get quick ‘n’ dirty temporary two-factor authentication for locked out accounts, which prevents lockouts caused by brute force attacks from keeping out the legitimate account owner.

      2) Get rid of the default “admin” username. You have to enter an email address when setting up WordPress already, right? Instead of the administrator account defaulting to “admin”, it should default to the first part of the email address entered. That way it doesn’t require the user to make any more decisions than they already do, because there’s still a default username set, but it’s a different default for every user; and since it’s based on their email address (not something random), it’s just as easy for the user to remember.

    • goldnerj 6:48 pm on August 28, 2015 Permalink | Log in to Reply

      For large scale orgs, a feature where administrators can “lock out” anyone who’s not an admin. During maintenance windows, outages or other problems where people need to be shut out.

    • Matt Mullenweg 8:59 pm on August 28, 2015 Permalink | Log in to Reply

      I’ve read all the comments up to this point, lots of interesting suggestions and things raised.

      I realize the make/core blog is developer focused, but I wanted to particularly thank people who brought up user perspectives on things, or thought about how features or functionality impacts a new user’s experience or the overall growth curve of WordPress itself.

      It’s worth thinking about everything proposed in three buckets:

      1. New features and iterations on existing functionality that make WP easier to use for new and non-technical users of WP. These are our “headline” features. When we do these right, people adopt WP because of them, or are more likely not to churn. These days these features tend to be javascript-driven.], and ideally can be done as feature plugins first.
      2. Behind-the-scenes new and iterated functionality targeted at developers, the people who build sites for the people in the bullet point above. Think APIs, optimizations, performance, data structures. Out of the box these might not change anything in WP’s user interface, or require code (plugin, config file change) to activate. Developers are more likely to adopt WP because of these. Almost always PHP. Some (like REST API) make fantastic plugins.
      3. Maintenance, triage, bugs, unintended “features” on certain platforms. This is the important janitorial work that is ongoing and key to a healthy project. Think of open tickets, bug gardening, automated tests, some performance and optimizations. These are usually edge cases, but the edge cases add up. You probably never notice these unless you run into one personally. Always core commits.

      A good release is usually about 50% user, 30% dev, and 20% maintenance. Occasionally we should do releases that are almost entirely (80%) maintenance, just like you might do a deep clean of your house once or twice a year, like Apple is doing with iOS9 and El Capitan this year.

    • Guizillanet 9:13 am on August 29, 2015 Permalink | Log in to Reply

      It would be great, if a fonction to create child-theme was created. Just a button. It creates folder, function.php and style.css with the code to join the themes.

    • nfuller52 2:57 pm on August 30, 2015 Permalink | Log in to Reply

      Built in support for multiple environments with development and production available out of the box and development being the default

  • Andrew Ozz 1:31 am on July 9, 2015 Permalink |
    Tags: , , ,   

    Editor changes in WordPress 4.3 

    The editor initialization was updated. The main change is that the content for both Visual and Text editors is prepared/escaped the same. We used to run the content through the PHP wpautop() when the default editor was TinyMCE. This is no longer needed as we run the textarea content through the JavaScript wpautop() before initializing TinyMCE.

    In that terms wp_richedit_pre() and wp_htmledit_pre() were deprecated together with the richedit_pre and htmledit_pre filters. They were replaced by format_for_editor() and the format_for_editor filter. For more information see #32425.

    Another change is the complete removal of the code for the old Distraction Free Writing mode. This code was disabled and has been unused since WordPress 4.1. We left it in core so the authors of plugins that were using it would have plenty of time to update.

    If this is essential for some plugins, the files from WordPress 4.2 can be reused. For more information see #30949.

    If you are the author of a plugin that uses any of the deprecated functions or filters, please update it now. If your plugin uses wp_editor(), please test it in the latest beta.

    As always, feedback is very welcome.

     
    • Samuel Wood (Otto) 1:39 am on July 9, 2015 Permalink | Log in to Reply

      FYI to support team members. Any major editor JS change causes massive issues, because of caching. Bottom line, adding a version to the JS files, like we do, doesn’t solve the problem for people like CloudFlare users and people with overly crazy caching situations. Expect that these changes will cause big upticks of reports of breakage and silly demands to revert. CLEARING CACHES WILL FIX IT. The trick is finding out what kind of cache they use, and then clearing that.

      Just saying. This always happens for every major JS change.

      • Andrew Ozz 3:32 am on July 9, 2015 Permalink | Log in to Reply

        Yeah, this used to be a really big problem some time ago. Lately the situation has been improving. We have been updating TinyMCE and the custom plugins in each new WordPress release. There are still some reports of editor JS errors, but far less than few years ago.

    • Leo Caseiro 2:08 am on July 9, 2015 Permalink | Log in to Reply

      Hi @azaozz believe the PHP function is wpautop()

    • crispinbalfour 7:56 am on August 21, 2015 Permalink | Log in to Reply

      I am not sure whether this is a place to ask this but I have posted a query and nobody is responding.

      I have updated to 4.3 and now the GT3 Page builder in Skew Theme is not working. The developer gave me a fix so I can at least see the content in the Text Area module, but there are no buttons for inserting/editing links any more.

      The developer indicated this was a bug with Tiny MCE in the latest release – is this the case? From what is written above Tiny MCE is no longer a part of things, and the GT3 is not going to work anymore?

      Thanks
      Crispin

    • hernangonzalez 9:49 pm on August 23, 2015 Permalink | Log in to Reply

      This change seems to be a headache for those who had chosen to no use wpautop() on their blogs (disabled via plugins or custom themes) and who want to control the HTML markup themselves.
      Sigh.

    • lokidude99 10:47 pm on August 26, 2015 Permalink | Log in to Reply

      Seems to have broken all my sites that used qtranslate plus a plugin that seems to have recently become unsupported.

      Debug mode throws no errors and the only error I see in the console is ..

      Uncaught TypeError: Cannot read property ‘canvas’ of undefinedb.closeAllTags @ quicktags.min.js?ver=4.3:1d @ editor.min.js?ver=4.3:1(anonymous function) @ editor.min.js?ver=4.3:1i @ tinymce.min.js?ver=4203-20150730:2m @ tinymce.min.js?ver=4203-20150730:2

      When you click on the visual tab in the editor.

      Any suggestions on where I should look to fix this?

      Urgently need assistance on this.

  • Konstantin Obenland 9:45 pm on May 20, 2015 Permalink |
    Tags: ,   

    Dev Chat Summary, May 20 

    Agenda, Slack log.

    Committers Update (#)
    @nacin
    New guest committers: @iseulde, @westonruter, and @obenland, renewed guest committers: @jorbin, @jeremfelt, permanent committers: @pento, @boone, and @johnbillion
    Also see https://make.wordpress.org/core/2015/05/20/new-committers-for-4-3/

    Editor (#)
    @azaozz@iseulde
    No update here. Will discuss goals for this week and next week outside of dev chat.

    Admin UI (#)
    @helen
    @helen is plugging away at some groundwork for the CSS roadmap, @stephdau should be taking a look at the first steps for list tables in the next day or so. Will discuss goals for next week in tomorrow’s UI meeting.

    Network Admin UI (#)
    @jeremyfelt
    They talked through aspects of the Edit Site and Add Site flows yesterday to help @hugobaeta with mock-ups. Hopeful to see a mock up of these soon. They have a couple flows in Make/Flow with more on the way. The 5s flow highlighted an issue with text inputs overflowing. There’s also an updated `WP_Network` patch.

    Things they want to have done by next week:

    • Android and iPad flows.
    • Conversation around updated `WP_Network` patch and a first attempt at `WP_Site`.

    Partial Refresh (#)
    @westonruter
    Now has support for refreshing menus changed by Menu Customizer: https://github.com/xwp/wp-customize-partial-refresh/pull/12/files
    It’s much simpler than partial refresh for widgets, and @westonruter thinks that maybe it could safely be on by default, instead of requiring opt-in as is currently done for widgets. The concern with on-by-default would be if menus get some dynamic behaviors added to them with JS, so maybe it’s just something that theme authors would need to account for.
    Also waiting on feedback and testing from the Menu Customizer, merging the corresponding PR for Menu Customizer, to then merge the PR for Customize Partial Refresh and do a new plugin release.

    Goals for next week: Take what was done for Menus and then abstract a level again to facilitate plugins easily adding their own partial-refreshing.

    Menu Customizer (#)
    @voldemortensen, @celloexpressions
    Lazy loading and error handling were committed. Will discuss goals for next week outside of dev chat.

    Better Passwords (#)
    @markjaquith
    They’ve been working on a mockup of the password UI: http://codepen.io/markjaquith/pen/GJjZbJ
    Probably best to create a temporary hook in core for the password-set UI in the profile, to allow the team to work on this as a plugin. @markjaquith can take care of that core change, and start the plugin on GitHub.
    #32428 is on hold until the Password UI is usable. @voldemortensen started work on expiring reset keys #32429, but hopes to get it showcase-able by the end of the week. @rmarks made a first pass at #32430 but it needs more work.

    Goals for next week:
    1. Hook in core to enable plugin for PW change UI.
    2. Working version of PW change UI on the Profile screen (that is, you can change your password with it… show/hide… back compat for the pw confirmation field… not promising the strength hint stuff yet).
    3. #32430 ready for commit.
    4. Working patch for #32429.

    Favicons (#)
    @johnbillion
    @johnbillion made a start on the site favicon manager. As discussed during dev chat last week and in #16434 it has an API so plugins/themes can register new sizes for favicons/touch icons/etc if the need arises. I’ll be pushed to a GitHub repo by tomorrow. The main thing that will need to be discussed is whether this should just be a customizer setting or not. @johnbillion will post about the repository location and meeting times on this blog.

    Other:
    @ocean90 is looking for feedback on #29783!

    Next chat will be on May 27 2015, 20:00 UTC

     
  • Konstantin Obenland 3:52 pm on May 20, 2015 Permalink |
    Tags: ,   

    Dev Chat Agenda for May 20 

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

    Time/Date: May 20 2015 20:00 UTC:

    1. Feature Updates
      1. Editor – @azaozz / @iseulde
      2. Admin UI – @helen
      3. Multisite Admin UI – @jeremyfelt
      4. Partial Refresh – @westonruter
      5. Menu Customizer – @celloexpressions / @westonruter / @voldemortensen
      6. Passwords – @markjaquith
      7. Site Icon – @johnbillion
    2. Component Updates

    Feature Leads: Let’s review last weeks goals and set new ones for next week.

    Recommended reading:

     
  • Konstantin Obenland 6:14 pm on May 14, 2015 Permalink |
    Tags: ,   

    Dev Chat Summary, May 13 

    Agenda, Slack log.

    Editor (#)
    @azaozz@iseulde
    @azaozz has been looking at the “WordPress integration” parts the last couple of days, a lot of things that can be improved there. It removes some of the oddities, like running the post content through wpautop() before outputting it in the textarea, but only when TinyMCE is expected to be loaded, etc. @iseulde is working on the mobile toolbar and is hopeful she can get a patch ready this week. By next week’s meeting they want to have the mobile toolbar working (except in iOS), as well as #31655, #30949, and maybe #31441 in.

    Admin UI (#)
    @helen
    @helen has largely been working on prepping things (tickets, examples, links, etc.) for Thursday’s UI meeting. More about the meeting (including agenda) can be found here: https://make.wordpress.org/core/2015/05/11/weekly-core-ui-meetings-for-4-3/

    Network Admin UI (#)
    @jeremyfelt
    Recap of Multisite office hours: https://make.wordpress.org/core/2015/05/12/multisite-office-hours-recap-may-12-2015/
    Things they want to have done by next week:

    • Mockups for the Edit Site / Add New Site improvements by @hugobaeta.
    • Having more flows posted to Make Flow for the network admin, via @sofiarose @kraft, and @ubernaut.
    • Get some decent progress on `WP_Site` and `WP_Network` with @jjj.

    Partial Refresh (#)
    @westonruter
    Weston hopes to add initial integration between Menu Customizer and Partial Refresh this weekend. Due to client projects he’ll have to work on Concurrency _concurrently_ with Partial Refresh so he doesn’t hold up Menu Customizer. By next week Partial Refresh should be abstracted enough for the Menu Customizer to work with.

    Menu Customizer (#)
    @voldemortensen, @celloexpressions
    Now that it’s object-oriented they’re ready to start ramping up work. They’ll be going through github issues and come up with the next milestone for possibly the end of the week. By next week they’re planning on getting lazy-loading of both all menu item controls and the add-menu-item panel done, as well as better error handling for duplicate menu names and the like.

    Better Passwords (#)
    @markjaquith
    By next week, Mark wants a HTML, CSS, JS working demo of the password setting UI, and tickets for that and all other items on their hitlist. If there’s time beyond that, they could knock off one of the easier ones like notifying users of their password/e-mail changes.

    Accessibility component update (#)
    @joedolson
    There’s been a ton of work done on the List Table class and associated areas. Joe has a set of 10 tickets with patches that he’d like to see committed by next week: #32150, #32254, #32255, #32028, #32152, #32147, #32189, #31654, #32253, #32170.

    Build tools component update (#)
    @jorbin
    QUnit update seems to have gone off without a hitch. There are 7 npm dependencies that need to be updated. 6 are ready to go. grunt-sass needs a bit more digging in. This week, @jorbin is going to update the build tools roadmap he wrote up after WCSF and then pester a lead (likely @helen) to give it a read so that it can finally be published.
    Not exactly build related, but test related: Bug scrub identified that we don’t have any tests for nav menus, especially around the classes we add. @johnbillion has agreed to write some tests there so that we can fix all the bugs around that.

    Favicons (#)
    @obenland
    Support for managing favicons seems like a rudimentary thing, and its absence in core does seem odd to some. We still need plugins to handle favicon and other media icons in the admin, there is currently no good way for users to do that. We’ve been talking about adding support for a favicon manager for a long time ( #16434 ), let’s make 4.3 the release that finally adds it. @johnbillion volunteered to lead the feature for 4.3, with help from @brandondove, @kraftbj, @sofiarose, and possibly @dh-shredder.

    Next chat will be on May 20, 2000 UTC

     
  • Konstantin Obenland 10:25 pm on May 12, 2015 Permalink |
    Tags: ,   

    Devchat Agenda for May 13 

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

    Time/Date: May 13 2015 20:00 UTC:

    1. Feature Updates
      1. Editor – @azaozz / @iseulde
      2. Admin UI – @helen
      3. Multisite Admin UI – @jeremyfelt (if available)
      4. Partial Refresh – @westonruter
      5. Menu Customizer – @celloexpressions / @westonruter / @voldemortensen
      6. Passwords – @markjaquith
    2. Component Updates
      1. Accessibility – @joedolson
      2. Build tools – @jorbin
    3. Site Icon feature proposal – @obenland
    4. Open Floor – Looking for dev feedback on a ticket? Use this part of the meeting to let us know!

    Recommended reading:

     
    • Nick Halsey 3:09 pm on May 13, 2015 Permalink | Log in to Reply

      I can’t make the meeting, but regarding site icons, if that feature does happen it should really go in the Customizer. Specifically, the “Site Title & Tagline” section should be renamed to something like “Site Identity” and icons should be added there after the two existing options. Seeing as those options are all used in browser contexts (and usually, but not always in the theme for title & tagline). In the process all three options should be previewed in the browser as well as the Customizer preview, at least as well as we can (actually site title and tagline are currently previewed whenever a refresh is triggered, but many themes postMessage those, so we may want to find a way to do it directly with JS).

      Also, we should work out a way to implement the RSS feed links that can be specified for Windows 8.1 tiles alongside the various site icons that are used in that context so that all WordPress sites get automatic live tiles out of the box. See https://wordpress.org/plugins/custom-windows-pinned-tiles/. A filter to change the post type that it pulls would be nice too.

  • Konstantin Obenland 10:09 pm on May 7, 2015 Permalink |
    Tags: ,   

    Dev Chat Summary, May 6th 

    Agenda, Slack log.

    Editor (#)
    @azaozz@iseulde
    Spent last week to go over the things they want to work on. @iseulde will work on the mobile editor toolbar first. They’ll milestone tickets as they get patches. For posterity and everyone who wants to follow up, the Editor game plan for 4.3 can be found here: https://make.wordpress.org/core/2015/05/01/editor-wish-list-for-4-3/

    Admin UI (#)
    @helen
    Not much to talk about yet as @helen was out last week and will be out for the next few days. She will schedule a meeting for next week, likely Thursday, May 14 1700 UTC. location to be determined.

    Network Admin UI (#)
    @jeremyfelt
    There was a good chat about NA UI on Tuesday. First steps are documenting pain points now and move forward with tickets, etc. Multisite chat summary: https://make.wordpress.org/core/2015/05/06/multisite-office-hours-recap-may-5-2015/

    Customizer (#)
    @westonruter
    Noteworthy from Monday’s chat is that Menu Customizer was added to the 4.3 roadmap for the Customizer, while Transactions were taken off it. No other news besides that: https://make.wordpress.org/core/2015/05/04/customizer-chat-summary/

    Better Passwords (#)
    @markjaquith
    Weekly meetings are on Mondays at 1700 UTC in #core-passwords. Right now they’re throwing ideas around, by Monday @mark wants to have gone through that and have a make/core post that outlines the major goals for this release, so they can get to work.

    Accessibility component update (#)
    @joedolson
    The accessibility team has spent a lot of time generating tickets for tabular data, based on user feedback gathered during the 4.2 cycle. It’s about 8 tickets right now, all prefixed with “List Table:”. They have also been focusing on establishing a new heading hierarchy for the admin. Resolving the H1 issue is fairly simple, but has broad impact across the admin; should probably get this in ASAP. It shouldn’t have much impact in normal usage, but e team is unsure what kinds of edge cases might be out there. There are two separate issues: implementing H1 across pages and addressing the hierarchy within pages; @joedolson suggested to handle just the primary H1 to start, then start looking at the internal issues.

    Build tools component update (#)
    @jorbin
    Started upgrading dev dependencies and our version of QUnit. @jorbin will finish those updates this week. People will likely need to do some npm installs to ensure they have the up to date versions.

    Next chat will be on May 13, 2000 UTC

     
  • Konstantin Obenland 6:18 pm on May 6, 2015 Permalink |
    Tags: ,   

    Devchat Agenda for May 6 

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

    A lot of people will be on traveling to LoopConf or the VIP Developer Workshop so I anticipate a rather short meeting.

    Time/Date: May 6 2015 20:00 UTC:

    1. Feature Updates
      1. Editor – @azaozz / @iseulde
      2. Admin UI – @helen (if available)
      3. Multisite Admin UI – @jeremyfelt (if available)
      4. Customizer – @westonruter
      5. Passwords – @mark (if available)
    2. Component Updates
      1. Accessibility – @joedolson
    3. Open Floor – Looking for dev feedback on a ticket? Use this part of the meeting to let us know!

    Recommend reading:

     
    • Ryan Boren 6:58 am on May 7, 2015 Permalink | Log in to Reply

      We have five feature teams. How about a feature team list along the lines of the one on the Feature Plugins Tracking page? I want a place to point contributors looking to help with a feature, beta testers in particular.

      • Samuel Sidler 1:56 pm on May 8, 2015 Permalink | Log in to Reply

        How is that different from the components page? A good example is the customize subcomponent, which includes the latest posts for the component as well.

        • Ryan Boren 10:57 pm on May 8, 2015 Permalink | Log in to Reply

          I forget the components pages exist until I’m reminded of them. They don’t have chat times or channels. There is nothing that associates the components pages to features and feature teams in 4.3. The top-level components page is not tailored to 4.3. Finding any information I care about requires drilling down through each component, once I figure out which components map to which feature. This assumes a lot of knowledge.

          One page that gives me background on 4.3 and shows me how to follow and help. A start: https://make.wordpress.org/core/4-3/

  • Konstantin Obenland 4:20 am on April 30, 2015 Permalink
    Tags: ,   

    Dev Chat Summary, April 29th 

    Agenda, Slack log.

    Editor (#)
    @azaozz@iseulde
    Want to concentrate on mobile improvements, especially the toolbar, other buttons around the editor, and ajax saving. @iseulde will publish a list of all items they’ll work on. We will need to test on many mobile devices in couple of weeks, so please join them in the #core-editor Slack channel where they’ll also have weekly chats on Tuesday, 20:00 UTC.

    Admin UI (#)
    @helen

    1. Better responsive list tables – this involves some PHP-side API changes as well as UI work. The base thought here is that a narrow screened device is also often a mobile device, which may have limited bandwidth. That’s exactly the situation in which you don’t want to have to load more pages to see important information, and our current strategy of truncation is in direct conflict with that.
    2. Getting rid of media-new.php and exploring what a better list table+upload experience might be, both for JS and no-JS.
    3. Getting started on the admin CSS clean up roadmap @helen will be spinning up a kick off for that as well.
    4. Screen-by-screen sweep on touch and small screen devices, grabbing low-hanging fruit like “the spacing is off here” or “font sizes are inconsistent”.

    UI chats are going to be spun up again to further this effort, stay tuned for when and where.

    Network Admin UI (#)
    @jeremyfelt

    • Piggyback on other Admin UI improvements. The network admin often seems quite a bit behind everything else. Responsive list tables would be fantastic.
    • Start looking at network admin screens on mobile. There are many places where workflow can be reimagined. @boren has shared some great thoughts previously, let’s have more conversation around that.
    • It may be possible to start working on what a future site switcher would look like. Especially on mobile, providing context can be tough when working on a network of many sites.
    • #22383-core and #31240-core for nicer ways of creating and editing sites. Might lead to some domain/path validation, which could be useful elsewhere and help address older tickets.
    • Under the hood, significant progress on WP_NetworkWP_Site, WP_Site_Query, and maybe WP_Network_Query would be nice.

    @jeremyfelt will come up with a consumable list of 4.3 priorities by next week. Regular multisite office hours are Tuesday, 20:00 UTC in #core-multisite.

    Partial Refresh (#)
    @westonruter
    This greatly improves performance of previewing changes in the Customizer for non-postMessage transport settings (JS-applied changes) by just refreshing the area of the page that has been changed. As such it eliminates some of the need to do postMessage in the first place, while also reducing the amount of duplicated logic that would have to be implemented in JS to mirror what is being done in PHP. This resurrects some code from the old Widget Customizer feature plugin developed for 3.9. Writeup and feature plugin are available at https://wordpress.org/plugins/customize-partial-refresh/

    Customizer Transactions (#)
    @westonruter
    A low-level re-architecture of the Customizer plumbing that has a lot of side benefits and bugfixes, introducing some exciting possibilities for future feature plugins like scheduled settings, setting revisions, and drafted/pending settings. Partial Refresh is a dependency for this. Pull request available, but needs refresh. See proposal at https://make.wordpress.org/core/2015/01/26/customizer-transactions-proposal/. This was previously worked on for 4.2.

    Customizer office hours are on Friday, 18:00 UTC in #core-customize.

    Better Passwords (#)
    @markjaquith

    1. Make “user chooses own password” non-default. We can generate better passwords than they can, and writing as secure password down on a sticky note is in general more secure than memorizing a weak password. So the default should be “give me a new password”, and “let me choose” should be something they specifically choose.
    2. When the use is generating their own password, we should encourage strong passwords more forcefully. Right now we just have a meter. We don’t tell them why it’s “weak”. We don’t tell them how to fix that. Simple feedback like “too short — add more characters!”, “Try adding some numbers and symbols!”. Not only that, we could actually make the addition for them. Show them their password attempt with some additions that would make it better.
    3. In order to help the user modify their chosen password, we need it to be visible. If they click “hide”, they can input it hidden for an “over shoulder” situation. Also gets rid of the annoying “enter twice” thing.
    4. Let’s not send passwords via e-mail anymore, it’s insecure. We’re not getting around “full access to e-mail means you can reset”, but we can stop passwords from sitting around in e-mail accounts forever.

    Discussions will happen in #core-passwords. Time and day for regular meetings TBA.

    Open Floor (#)

    @jorbin has set up a Call for Tickets. Please feel free to add the tickets you want to work in the comments there.

     
    • tronic69 7:12 am on April 30, 2015 Permalink | Log in to Reply

      Because I have no invite for wordpress@slack I will write my comments for #core-passwords here. Maybe someone can move it to Slack.

      1) Making a system-generated password default looks like paternalism for me and many people 😉
      A lot of people use strong passwords and password safes (e.g. KeePass or Lastpass).

      2) It would be nice to have settings for password complexity (like which classes have to be used, 3 out of 4 classes).

      3) The reverse option would be better and more secure: password is invisible during input and then you can check no one is watching you before you click “show”!
      More and more Apps, browser extensions or website do it this way in the last months.

      4) I see here two well-known procedures which are known and used by users since years for password reset:
      A: A “one time password” (valid only some hours) is send to the user and he has to change it on next login.
      B: A “password reset link” is send to the user which allows just setting a new password and nothing else!
      Both ways should be valid only for some hours to secure only the user can check them quickly.

      Just my 2 cent 😉
      Tom

    • Ryan Boren 5:17 pm on April 30, 2015 Permalink | Log in to Reply

      Better passwords: I really like having show/hide, but it can interfere with password manager form filling since enabling show/hide changes the input type from password to text. Is there a way to show/hide that gets along with password manager password filling?

      https://discussions.agilebits.com/discussion/24053/password-generator-doesnt-fill-new-password-on-wordpress-com-change-password-in

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel
Skip to toolbar