WordPress.org

Make WordPress Core

Updates from Helen Hou-Sandi Toggle Comment Threads | Keyboard Shortcuts

  • Helen Hou-Sandi 5:25 pm on September 14, 2016 Permalink |
    Tags: , ,   

    Dev Chat Agenda for September 14 (4.7 week 4) 

    This is the agenda for the weekly dev meeting on September 14, 2016 at 20:00 UTC:

    If you have anything to propose to add to the agenda or specific items related to the above, please leave a comment below. See you there!

     
    • Pascal Birchler 6:11 pm on September 14, 2016 Permalink | Log in to Reply

      I might not be able to attend today’s dev chat, so here’s an update on i18n:

      #29783 (User Admin Language): in good shape, but not much testing happening so far. We could do much more when #26511 is in core though…

      #26511 (`switch_to_locale()`): needs some much needed performance testing. If anyone runs a large WordPress site, I could use your help!
      Also since there are some similarities with `switch_to_blog()`, I’ll open a new ticket to suggest adding a `WP_State` interface for such switching functions. Think `WP_Site_State`, `WP_Locale_State`, `WP_Post_State` (see #19572), etc. Not a blocker, but worth keeping in mind for future compatibility.

      #20491 (JS i18n): I documented the current state in the tasks with responsibilities etc. As of tomorrow I’ll have more time to work on it (mainly on the GlotPress side of things). Also have been thinking about a `switch_to_locale()` function in JS via Ajax…

    • Ronald Huereca 6:24 pm on September 14, 2016 Permalink | Log in to Reply

      I’d like https://core.trac.wordpress.org/ticket/38024 discussed as I believe it to be a fairly major bug in regard to automatic updates for plugins and themes.

  • Helen Hou-Sandi 3:03 pm on September 9, 2016 Permalink |
    Tags: , ,   

    Say Hello to Twenty Seventeen 👋🏽 

    It’s that time again: time to build a new default theme for WordPress!

    WordPress 4.7 will launch with a brand new theme – Twenty Seventeen. Designed by Mel Choyce (@melchoyce), Twenty Seventeen sports a modern look and will make a good base for any business website or product showcase.

    twenty-seventeen-promo-png

    Check out the gallery below to preview our next default theme at full-size:

    (Higher resolution mockups)

    In addition to having a wide appeal, Twenty Seventeen will focus on providing a seamless initial theme setup so anyone can set up a website for themselves or their business with minimal hassle.

    Twenty Seventeen aims to show off some new core features and enhancements, such as:

    • A better flow for using a static page as your front page.
    • Visible edit icons in the Customizer, replacing the current hidden shift+click method.
    • Expanding custom header images to include video (think: atmospheric video headers!).
    • Dummy content for live previews.

    Mel will keep an eye on all things design during the creation of Twenty Seventeen. Laurel Fulford (@laurelfulford) and David Kennedy (@davidakennedy) will assist her, leading the theme’s development. Lots of opportunities exist this year for getting involved with Twenty Seventeen – we need your help, and lots of it! 🙏🏽

    Backing up the Twenty Seventeen team will be a team focusing on the core Themes API. This team is looking for new and experienced core developers with theme experience to help lead and contribute to specific features.

    Similar to feature projects, the initial development of the theme will be on GitHub. Once it’s usable and stable, the theme will be merged into core and the GitHub repo will be deprecated. After it’s merged, all issues should be reported to Trac.

    Twenty Seventeen will also use plain CSS — it won’t use preprocessors in the development of the theme. This will keep it simple, making the theme easier for everyone to understand, quicker for anyone to modify and better to maintain in the long run.

    Throughout the process of building Twenty Seventeen, the team will be collaborating with the Theme Review Team and the core development team to make sure it is up to core standards.

    How can you get involved?

    There will be weekly meetings every Friday at 18:00 UTC in #core-themes starting today. During that time, the focus will be on the theme itself. If you are interested in contributing, keep an eye out here for updates or join us in #core-themes in Slack.

    If you have some early thoughts on what would make this a great WordPress experience, or if you’re generally interested in participating, sound off in the comments. Please hold any design feedback for Friday’s meeting. where we can have a conversation about it in greater depth.

    Want to know more about default themes?

    Here are some links where you can find out more about past default themes:

     
  • Helen Hou-Sandi 6:24 pm on September 7, 2016 Permalink |
    Tags: ,   

    Dev Chat Agenda for September 7 (4.7 week 3) 

    This is the agenda for the weekly dev meeting on September 7, 2016 at 20:00 UTC:

    • Update on 4.6.1.
    • Components and features: any decision points to be made, things that are stuck, or calls for help.
    • Twenty Seventeen 🎉

    If you have anything to propose to add to the agenda, please leave a comment below. See you there!

     
  • Helen Hou-Sandi 5:39 pm on August 31, 2016 Permalink |
    Tags: , ,   

    Dev Chat Agenda for August 31 (4.7 week 2) 

    This is the agenda for the weekly dev meeting on August 31, 2016 at 20:00 UTC:

    • General reminder: as holidays or other conflicts come up, be sure to announce meeting moves or cancellations. For instance, next Monday is the US Labor Day holiday and the Monday after that is Eid al Adha.
    • Update on 4.6.1.
    • #36335: Autoloader and #37699: Globals – what could and should happen in order to be effective and move forward?
    • 4.7 project/feature proposals: who wants to work on what?
    • Triage of tickets marked early for 4.7 (milestoned and unmilestoned).

    If you have anything to propose to add to the agenda, please leave a comment below. See you there!

     
  • Helen Hou-Sandi 5:59 pm on August 24, 2016 Permalink |  

    Dev Chat Agenda for August 24 (4.7 week 1) 

    This is the agenda for the weekly dev meeting on August 3, 2016 at 20:00 UTC:

    • Quick recap of personnel and schedule
    • Potential focus areas
    • Teams and weekly updates
    • What’s up with the wishlist items?
    • Bug scrub announcements

    If you have anything to propose to add to the agenda, please leave a comment below. The floor will also be open for discussions after the meeting-proper. See you there!

     
    • Jeremy Felt 6:39 pm on August 24, 2016 Permalink | Log in to Reply

      Can we do a quick announcement of the 4.6.1 schedule?

      • Bug scrub on August 30 at 15:00 UTC. (all patches should ideally be in trunk)
      • Release candidate on September 1 (all patches are in 4.6 branch)
      • Release on September 7
    • Dave Clements 1:13 pm on August 25, 2016 Permalink | Log in to Reply

      August 3rd? 🤨

  • Helen Hou-Sandi 9:42 pm on August 17, 2016 Permalink |
    Tags:   

    WordPress 4.7: The Jump Off 

    WordPress 4.7 will formally kick off at next week’s dev chat on August 24, with an anticipated release date of December 6. Please take a look at the schedule on the release overview page, which has some other notes (including a hopeful goal from me) and schedule caveats.

    On the personnel front, I’m excited to introduce Jeff Paul (@jbpaul17) and Aaron Jorbin (@jorbin) as release deputies. Jeff is a team lead at XWP and comes highly recommended with lots of project management experience. I look forward to his help on that front and learning from him in an area that’s not my strength, and am really excited about doing some cross-agency collaboration on core. Jorbin is familiar to many of you, and will be helping on more of a technical/engineering management front, such as with bug scrubs. Having two release deputies serves a few purposes: it evens out availability, is a much better balance for including and mentoring somebody newer to contributing, and it’s a representation of the kind of skill diversity I want to see more of in core and in WordPress at large.

    In the run up to kick off, get your wishlist items in and don’t forget to fill out this survey if you systematically dedicate time to working on WordPress core. Looking forward to what we make together! 4️⃣⏺7️⃣

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

    WordPress 4.7: What’s on your mind? 

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

    Disclaimer: Comments do not constitute binding contracts. 🙂

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

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

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

      Fields API, amiright?

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

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

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

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

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

      Groups.

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

      Groups please.

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

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

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

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

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

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

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

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

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

            +1

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

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

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

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

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

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

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

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

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

        +1

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

        Agree 100%. Would love this feature.

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

        +1

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

        +1 for Groups

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

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

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

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

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

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

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

        +1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

              Using colors as an enhancement

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

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

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

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

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

      Built in 2-factor authentication would be awesome.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      API endpoints

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

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

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

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

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

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

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

      Here are some things that are on my mind:

      • Admin: notice API

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

      • Admin: Image drop for featured image

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

      • Admin: Paste images

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

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

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

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

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

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

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

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

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

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

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

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

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

            Alec, with all the respect..

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

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

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

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

            How? Examples, please.

            > Core WordPress out of the box is not fast.

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

            > Basic bulletproof caching (80/20)

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

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

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

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

        What do you mean by security out of the box?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

        +1

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

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

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

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

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

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

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

        Shiny Updates v3 ideas:

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

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

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

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

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

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

            Anyway, definitely introduce user time zones as a first

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

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

              > Anyway, definitely introduce user time zones as a first

              Agree 🙂

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

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

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

        +1 User-level timezones

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

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

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

        +1

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

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

        • eric2016 8:49 pm on September 1, 2016 Permalink | Log in to Reply

          Yes this is very important for me because freelancers do not name their photos correctly no matter how many times I tell them to follow guidelines.

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

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

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

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

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

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

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

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

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

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

            • fotoglut 10:43 am on September 6, 2016 Permalink

              +100 for Mediareplacement – On my Site about Music i get Infos for new Releases very early. At that Time there is mostly only a very small Cover out. Later the Cover comes in HighRes. Then its very Difficult to cange it…

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

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

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

          Photography Site:

          • Landscapes
          • Portraits
          • Corporate
          • Wedding
          • Real Estate

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

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

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

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

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

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

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

        +1

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

      https://github.com/sc0ttkclark/wordpress-fields-api: Fields API
      https://core.trac.wordpress.org/ticket/13429: Updating Link URL on image within Admin with Gallery
      https://core.trac.wordpress.org/ticket/12718: Better structure for admin menu
      https://core.trac.wordpress.org/ticket/22363: Accents in attachment filenames should be sanitized
      https://core.trac.wordpress.org/ticket/20901: Taxonomy descriptions should be TinyMCE editable
      https://core.trac.wordpress.org/ticket/32101: Ability to mark plugin as unmanaged
      https://core.trac.wordpress.org/ticket/22938: Presentation of hierarchical taxonomy in Media modal should be checkboxes rather than comma-separated tag list
      https://core.trac.wordpress.org/ticket/23421: Add sortable to taxonomy column
      https://core.trac.wordpress.org/ticket/20842: Buttons are not on the same line when saving a post as pending (RTL)
      https://core.trac.wordpress.org/ticket/14877: Ability to create exclusive custom taxonomies
      https://core.trac.wordpress.org/ticket/21165: Make categories widget work with custom taxonomies
      https://core.trac.wordpress.org/ticket/5034: Impossible to have duplicate category slugs with different parents
      https://core.trac.wordpress.org/ticket/22355: Template stack – Beyond parent/child theme relationships
      https://core.trac.wordpress.org/ticket/22942: Remove Post by Email
      https://core.trac.wordpress.org/ticket/9777: Usability : add delete button to edit-tags.php
      https://core.trac.wordpress.org/ticket/19834: More Robust Capabilities for Attachments

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

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

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

        +100!

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

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

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

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

        This would be brilliant

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

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

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

        +1

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

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

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

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

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

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

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

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

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

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

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

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

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

      More ideas:

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

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

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

      Ability to upload a ZIP file to UPGRADE a plugin.

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

      • Anthony Hortin 6:22 am on September 17, 2016 Permalink | Log in to Reply

        This! A thousand times, this! Pleeeeaaassse!! Ticket #9757 has been open for 7 years for this.

        And the ability to sort Plugin Directory results and also your own Favorites would be so handy as well.

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

      Under Appearance->Widgets add “Dashboard Widgets”.

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

        What is a “Dashboard Widget”?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      A couple I’ve had floating around:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      Deprecate PHP5.2.

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

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

        Yes!

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

        +1

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

        +1

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

        +1

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

        +1

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

        yes, please

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

        Yes, please!

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

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

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

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

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

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

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

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

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

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

        +1 YES!!!

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

        -100

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

        +1

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

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

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

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

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

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

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

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

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

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

          Jon, couldn’t agree more. .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

          I hope I get the point across this time.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      • Better password hashing
      • Post metaboxes cleanup and reorganizing (all closed by default)
      • Remove sending trackbacks (to plugin)
      • Core framework for user groups (no UI)
      • Core framework for multi-language
      • Implement Fields API
      • Continued Multisite enhancements
      • Easer way to display translated user roles
      • Remove Post-by-Email in favor of plugins
      • Tool to convert Links to Menus, in preparation for removing Links in a later release
      • Continued user facing settings cleanup
      • Unmanaged/private plugins marker
      • Implement REST API endpoints
      • Framework/API for 2-factor authentication
      • Preview post on different emulated screen sizes
      • Front-end editing of post content
      • Make a new strategy for bumping PHP minimum version requirement

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

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

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

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

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

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

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

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

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

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

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

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

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

      There are probably tickets about these already but…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      Projects that I anticipate being involved with but not leading:

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

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

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

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

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

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

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

      Hi

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

      Please add it to the to fix list for 4.7

      Thank you

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

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

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

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

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

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

      I’m thinking big thoughts here, but:

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

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

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

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

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

        +1 only for mention post2post

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

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

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

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

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

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

        See #37686

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

          And Jetpack now disconnects from WodPress.com upon deactivation.

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

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

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

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

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

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

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

          Of your 45 plugins installed:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      Does also sort of go with NUX

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      More options like:

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

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

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

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

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

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

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

      2. Limit number of revisions.

      3. Disable attachment page, link attachment to Post.

      4. Default featured image, if none exist.

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

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

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

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

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

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

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

        So for this:

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

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

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

        • Dashboard
        • New Post
        • Manage Comments
        • Visit Site

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      Improve search results for front end users.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      Not everyone has the comptences to manage the redictions

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

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

      Not everyone has the comptences to manage the redirections

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

          The code tag or

          <code>Code here</code>

          using shortcodes will work…

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

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

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

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

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

      Regards

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

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

      Regards

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

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

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

      If that makes sense?

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

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

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

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

      Inbuilt page builder or allowing customizer to create page content.

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

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

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

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

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

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

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

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

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

    • leemon 7:40 am on August 29, 2016 Permalink | Log in to Reply

      Better select, multi-select, and autocomplete/suggestion inputs in the admin – https://core.trac.wordpress.org/ticket/31696

    • Kreeger 8:43 am on August 29, 2016 Permalink | Log in to Reply

      • Duplicate post/page. If a simple plugin can do it, why WP cannot ?
      • Better media manager. We need folders please.
      • Media renaming/replacing. Make our life simplier for everybody…
      • SEO fields for each post/pages (custom meta title, meta description, main word). We are in 2016, why this basic tool does not exist in a CMS ?
      • SEO fields for social media (meta og, meta twitter,…).
      • Lighter admin UI. The current WP admin looks so old, dark and slow.
      • Maybe not in 4.7 but please, make the possibility to make multilingual websites. Why do we need heavy plugin like WPML to translate a website ?
      • Kreeger 8:34 am on August 30, 2016 Permalink | Log in to Reply

        One more thing.

        Better protection for the WP admin:

        • Give us the possibility to add a .htpasswd or to rename /wp-admin/.
        • Give us the possibility to ban some logins (“admin” and “administrator” should not be allowed by WordPress!)
      • Kreeger 11:14 am on August 31, 2016 Permalink | Log in to Reply

        • Add the “Preview” / “Save” button in a fixed header because it is boring to scroll up because the main buttons are out of screen.
    • Rahul DC 4:34 pm on August 29, 2016 Permalink | Log in to Reply

      Making WordPress embed are delivered via CDN like Cloudflare instead of our Hosting Bandwidth

      • Destac 4:59 pm on August 29, 2016 Permalink | Log in to Reply

        You can’t really do that since you are embedding the content of your page. You could try using full page caching with CloudFlare but there is nothing they can do with this as far as i can think of.

    • patr100 6:57 pm on August 29, 2016 Permalink | Log in to Reply

      I would really like to see “built in” , a quicker way to jump to edit any page from the admin eg as this plug in provides.

      https://wordpress.org/plugins/admin-page-spider/

      It would speed up the work flow so much.

    • patr100 7:03 pm on August 29, 2016 Permalink | Log in to Reply

      And/or a one button “sort all pages by date” to put the latest at top, and for it to stick for the next visit , rather than drop down> then select last month then > select filter every single time I go back and want to edit a recent draft or recent published page.

    • eddr 6:19 pm on August 31, 2016 Permalink | Log in to Reply

      Hi! Amazing and great to see how WP community works and how much effort you put into this

      1. The REST API, with the JS library. It could save lots of time for so many people and up the WP system. It’s obviously on track, but wanted to mention it.

      2. Performance (complex data of post types). Unless I’m missing something big, WP has a lacking performance for very dynamic sites with lots of custom and complex structured data. Handling queries on complex data that is currently resides in the post meta is not efficient (unless there are no lots of users really). However, working directly on the DB and creating new efficient tables and code is far from optimal WP-like experience.
      Many people working with plugins like ACF (which is great, currently), but it’s not really efficient for data manipulation and searching.
      If you want to make sure your server holds for more than few request, you really need to put a lot of effort for something that maybe could be easier and maintained in the core
      I’m not sure if many people needs it, but I have definitely needed it several times.

      3. Performance 2 : The ability to load minimal WP for Ajax request, with some wanted functionality. Scenario: Ajax call to update some data with relation to a user. You’ll need to load much of the WP core and check authentication.

      4. Easy way to choose which plugins load when, at least on the page template/post type level. Could help performance again.

    • eric2016 8:53 pm on September 1, 2016 Permalink | Log in to Reply

      As a community news organization, a better media manager is at the top of our list.
      Please add tags for images. Folders would be great as well.
      Media renaming/replacing is important because freelancers often do not follow naming guidelines.
      Please do something about media!

    • martychc23 1:33 am on September 3, 2016 Permalink | Log in to Reply

      When i upload a PNG the generated thumbnails are often a larger size than the original PNG despite having a smaller dimension. Would like to see this fixed.

    • fotoglut 10:45 am on September 6, 2016 Permalink | Log in to Reply

      1) a possibility to copy Posts / Pages (with all settings like Cat, Tags etc….)

    • Shaped Pixels 1:54 am on September 15, 2016 Permalink | Log in to Reply

      Here is something that is annoying and hopefully can be solved (easily too). When in the dashboard, and you disable the various boxes to clean up the home page of the dashboard, each box you disable leaves behind an empty box with a grey dashed border. Basically we disable the boxes to clean up the area, but it leaves behind these empty bordered areas, which is quite annoying.

    • Anthony Hortin 6:40 am on September 17, 2016 Permalink | Log in to Reply

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

    Commit announcements for 4.7 

    Happy 4.6 release day! Commit announcements for 4.7 are brief.

    Andrea Fercia (@afercia) is now a permanent committer. Andrea’s work with and on the accessibility team has helped WordPress make huge strides forward, and he’s wielded his commit powers quite effectively over the past few releases. Please join me in congratulating Andrea. 🎉

    All other guest committers have been renewed for the cycle. Looking forward to 4.7!

     
  • Helen Hou-Sandi 9:37 pm on August 2, 2016 Permalink |  

    Do you have dedicated time to work on WordPress core? In order to help core developers/maintainers get a sense of who works on core regularly and what might be expected of them (what is known in some places as “resourcing”), we are taking a survey of those who specifically dedicate time to WordPress core, whether voluntarily or sponsored through a company. If you do, please fill out this Google Form with information about how and when you contribute to core.

    The goal of this survey is to identify where people are coming from, to help each other find where we can be most effective, and to have information that can better inform decisions on where and when to spend extra effort.

    Please only respond if you systematically dedicate time to WordPress core, whether sponsored or not. All responses are recorded in a spreadsheet available to committers and release leads, with the possibility of some data being available publicly later. Personally identifying information will only be included in that data with the permission of the respondent.

     
  • Helen Hou-Sandi 11:30 pm on June 14, 2016 Permalink |  

    Feature projects “meeting” for June 14 

    In lieu of a real-time chat in an hour and a half, let’s use the comments below to asynchronously discuss the needs of various feature projects and any ideas folks have. Needs for projects may include setting meetings, refining statements, putting together a project overview page, and any blockers you may have. Also note that the next meeting (June 28) will not be a live chat either, due to WordCamp Europe travel.

    During the last meeting, concerns were noted around time and effort on top of what is already being given. While the things that were suggested as being a part of a successful process are derived from what has been effective for current and past features as opposed to being “additional requirements”, I am sensitive to the nature of volunteerism and where developer strengths don’t always align with items that are more project or product management-oriented. As always, I am here to facilitate where needed.

    Items needing discussion (not comprehensive)

    • REST API
      In need of a statement of purpose – who is this for and what does it enable and/or improve? While a bit after the fact and not some kind of blocker, it is harder to support decision making both within the API and how it is merged into core without a clear and consensual definition.
    • Trackbacks / Pingbacks
      What are the problems, who is affected by them, and how? Based on early discussions, this seems to center around content and admin UX as opposed to visual design.
    • Rewrites
      “Modernise the rewriting and routing system for the modern CMS and platform era of WordPress.” has been floated as the purpose. This is still leaning toward the how (modernise) – what are current problems in less-technical English, who does it affect, and how? (Do we sense a theme yet?)

     

     
    • chuckingit 2:35 pm on June 15, 2016 Permalink | Log in to Reply

      Hi Helen … when i read about your comment on the need for a REST API statement of purpose this came to mind ->

      The WordPress API provides an easy* and secure protocol to send and receive realtime data to and from other apps and sites.

      maybe you already have such language in place as i did not look around and just responding from email ping … thus just some e.riffing for your team’s consideration :>)

      cordially, chuck scott

      *perhaps “user friendly” instead of easy ..??.. i say this because ease to implement should be a touch point for north star focus akin to the famous WP install process … getting data to and from other site(s) should be low hanging fruit that low and moderate level WP site owners can implement … after all, in today’s unfolding world of the internet-of-things, being easy to get along with, data back and forth speaking that is, should be central to WP core imho …

    • Nick Halsey 2:52 am on June 16, 2016 Permalink | Log in to Reply

      Live Preview

      A call for ideas post has been drafted and shared with @helen @westonruter and @melchoyce for review as a google doc. Once we’re okay with it, the next step would be publishing that on make/core. From there, based on the feedback gathered, we could plan a kickoff meeting to start developing project goals, statements, scope, etc. The purpose of the call for ideas would be to get people thinking prior to refining the project’s direction.

      Does that sound like an appropriate plan? Are we ready to get that post published?

    • jipmoors 11:48 am on June 21, 2016 Permalink | Log in to Reply

      New Feature Project submission: XML Sitemaps

      We (at Yoast) believe firmly that XML Sitemaps should be part of -any- CMS.
      Where better to start than in WordPress.

      Full concept and argumentation:
      https://docs.google.com/document/d/1eKKmrpNVBxsEPsheARGac-M3AciScCT59LiNTBDw5D4/edit?usp=sharing

      Technical specs:
      https://docs.google.com/document/d/1Kb7eva2BNEFK0zBNlsdh-7j_fTzO149P9rK6QbrVYcI/edit?usp=sharing

    • Antti Kuosmanen 1:52 pm on July 7, 2016 Permalink | Log in to Reply

      New Feature Project submission: Plugin Update Previews

      The # 1 reason for WordPress sites going completely down or becoming partially broken is the bad install or an update of a plugin or a theme. I feel the safety of theme / plugin updates is definitely among the most important issues to solve for the future of WordPress security.

      I suggest we give the option for users to test plugin / theme installs and updates prior to applying them. This requires a sandbox feature, where the user can test plugin updates without affecting the live site.

      Related ticket: https://core.trac.wordpress.org/ticket/37301
      Related plugin: https://github.com/anttiviljami/wp-safe-updates

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