WordPress.org

Make WordPress Core

Search Results for: gallery Toggle Comment Threads | Keyboard Shortcuts

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

    Gallery 

    25 open tickets. Last 7 days: +0 tickets

    25 open tickets defect (bug) enhancement feature request
    4.5 1 0 0
    Awaiting Review 6 6 1
    Future Release 7 3 1
     
  • Mike Schroder 10:22 pm on December 30, 2015 Permalink |
    Tags: ,   

    WordPress 4.5: What’s on your Wishlist? 

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

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

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

    Look forward to hearing from you in the comments!

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

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

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

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

      Editorial Workflow…

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

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

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

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

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

      PHP7 as base requirement? 🙂

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

        If only

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

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

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

          Ditto and +1

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

          This.

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

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

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

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

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

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

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

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

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

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

          +1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

            Text on Requirements page currently says:

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

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

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

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

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

              Here is why:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      : : Seeing in 4.5 Notes : :

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

      : : Biggest Pain Points : :

      • WP_Query lacks rich relational function.

      : : UX : :

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

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

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

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

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

      #31281 #34114 #33472 #25137 #27770

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

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

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

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

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

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

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

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

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

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

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

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

        I can help out on embed templates, Pascal.

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

        +1 for notification API

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

        +1 for a Twig based “official” theme.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

        You could add custom taxonomy for attachments.

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

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

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

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

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

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

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

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

        A big +1 to better media management!

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

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

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

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

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

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

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

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

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

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

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

        +1 Media management needs improvementS. And thanks for all

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

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

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

    • Daniel Bachhuber 11:17 pm on December 30, 2015 Permalink | Log in to Reply

      As a co-maintainer of the Shortcake Feature Plugin, I’d like to get Official Core Direction on shortcodes and shortcode UI before we spend too much more time on it.

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

      Add get_post filter: https://core.trac.wordpress.org/ticket/12955 the patch is ready with case study and example use
      Introduce helper function for AJAX checks: https://core.trac.wordpress.org/ticket/25669 standardize the check of is an ajax request. patch ready
      Add hook for custom post.php actions: https://core.trac.wordpress.org/ticket/27056 help the plugin developers, patch ready

    • j-falk 11:27 pm on December 30, 2015 Permalink | Log in to Reply

      My wish-list:

    • Giorgos Sarigiannidis 11:29 pm on December 30, 2015 Permalink | Log in to Reply

      My list, starting from the most feasible and moving to the most controversial / impossible to happen:

      1. Better plugin management at the WP Dashboard, taking advantage of your wordpress.org favorites collection. For example, order your favorite plugins based on those that you install more often and allow batch install and activation of multiple plugins at once.

      2. Allow (and perhaps encourage) security adjustments during WP install, like setting a login url other than wp-login.php, disable XML-RPC, disable pingbacks, disable comments etc.

      3. Adding native support for content translation.

      4. Absorb CMB2 to the core.

      5. During WP install, allow us to choose our theme between twenty-whatever and underscore_s.

      6. Add “Child plugin” support, to allow overriding a plugin’s settings the same way we do it in themes, with child themes.

    • Jon Brown 11:29 pm on December 30, 2015 Permalink | Log in to Reply

      So many things… but
      #1 land the Fields API. It’s _long long long_ over due.
      #2 Finish out the REST API.
      #3 Improvements to media management (better CORE tools for organizing and managing large asset libraries).
      #4 Improved image editing and flow. I for one didn’t really like the direction Image Flow was going, but incremental improvements would be welcome.

    • andreasnrb 12:01 am on December 31, 2015 Permalink | Log in to Reply

      #1 custom comment types

    • simonrcodrington 12:29 am on December 31, 2015 Permalink | Log in to Reply

      I’m always pretty keen for additional hooks and filters in the admin area to customize the way the UI works. For example adding new hooks into the new media modal window (https://core.trac.wordpress.org/ticket/35205)

      I’m keep to chase this up (as literally it’s just a quick edit to a few template files in core).

      Love to see more hooks and filters that give me the power to change up and extend the way WordPress does stuff.

    • davetgreen 12:34 am on December 31, 2015 Permalink | Log in to Reply

      Add a ‘Last Updated’ timestamp for each and every plugin in the list of installed plugins, so that admins can see at a glance how long it has been since an update. This way they can make an informed decision as to whether the plugin needs to be replaced by an alternative or not. The security implications of reducing the number of extremely outdated plugins are obvious. 🙂

      A nice to have would be a check carried out by WordPress that alerts the user if the plugin hasn’t been updated in X time frame: possibly 2 years as per the .org repo warning.

      I plan on working on this early in 2016 as my first WP commit proposal. 🙂

    • mbrsolution 12:49 am on December 31, 2015 Permalink | Log in to Reply

      I am sure many have asked this before or it maybe included already in the next version. I would really like the ability to upload an image or photo to the profile without using a plugin, a function and or without having to sign up to gravatar under discussion -> Avatars. …..sorry for this basic request.

      Thank you all for the great work you all put in with developing WordPress…….

    • ChokDK 1:32 am on December 31, 2015 Permalink | Log in to Reply

      I wish there was some kind of help for the “pro theme makers” so adjustment of 3/3 columns spacing/width would be easy and still responsive.
      For now, they don’t dare to make it user adjusted.

      I also wish the Soundcloud pre-picture for 1/3 columns could be resizeable instead of disappearing (as it is working now)

    • Amanda Rush 1:33 am on December 31, 2015 Permalink | Log in to Reply

      I’d like to see post formats given some serious attention. I don’t think they should be left up to theme authors without any kind of guidance as to how they should be handled, ETC. I’d be willing to work on this as I use them quite frequently.

    • KARTHOST 2:10 am on December 31, 2015 Permalink | Log in to Reply

      You asked for a Wish list here it is:

      1) Finish Rest API

      2) SIMPLE SSL Set up, example:
      In Settings
      [ x ] No HTTPS
      [ ] HTTPS Admin Only
      [ ] HTTPS Entire Site

      Make it that simple for the end user.

      3) Built in SMTP to allow site owner to set up a 3rd Party SMTP service (allow SSL Port 465 as well) and disable wp-mail.php or just use wp-mail.php (you can default to wp-mail.php, but email sending should be something related with core and have a choice as to what type service to be used.
      3a) Create email template and allow end user the ability to customize the content in the default emails WordPress install sends out and the email headers.

      Thanks for all considerations

      Roy Randolph

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

        +1 for better SSL support. It seems like a black box to me, and I’m a dev. 🙂

      • Nico 11:08 pm on January 1, 2016 Permalink | Log in to Reply

        With HTTP/2 only working over SSL I suggest people move to HTTPS only and drop http and set their servers/move hosts if necessary for it.

        There is a useful wp-config setting `define(‘FORCE_SSL_ADMIN’, true);` with that setting it would prevent insecure admin in case of a mis-configured server. This is basically your `[ ] HTTPS Admin Only`.

        As for SSL config its pretty much a server setup thing that has nothing to to with WordPress, you setup your server to server over SSL and then switch the site URLs in the WordPress config from http to https. So I see no need for WordPress to do more then its already doing.

      • thomaswm 5:14 pm on January 2, 2016 Permalink | Log in to Reply

        +1 for simple SSL support. It will become really important now that Let’s Encrypt is handing out free SSL certificates.

        https://core.trac.wordpress.org/query?status=!closed&keywords=~https

      • nathangraham 4:56 am on January 3, 2016 Permalink | Log in to Reply

        +1 for simplifying SSL set up

    • chrishoward 2:17 am on December 31, 2015 Permalink | Log in to Reply

      • Media categories. Pleeeaasse!
      • Hooks on the post listing and post editor screens for displaying instructions or other info to users. This is especially useful for custom post types. Currently I hack into the views-edit-{cpt} and edit_form_after_title hooks, but that’s not tidy.
      • More and better use of contrast and colour in the admin UI. I know minimalism is all the rage, but that doesn’t make it good UX. e.g. The post editor meta boxes could do with stronger headers as almost every thing in the post editor is black/grey on white. The visual hierarchy of WP admin varies from minimal to too subtle.
    • Ben Hansen (ubernaut) 2:19 am on December 31, 2015 Permalink | Log in to Reply

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

      Definable Image Types and associates sizes for those types.

      Rather than have all images have all sizes, frequently is is helpful to design a `’hero’` as having one set of sizes and a `featured-story` as another set of sizes and so on.

      • Andrew Nacin 11:49 pm on January 1, 2016 Permalink | Log in to Reply

        I’ve always liked this in theory, but I’m not sure how you’d auto-magically choose which image gets which treatment. (Beyond say featured image, which has its own UI.)

        I’d be more inclined to spend time to make it so WordPress creates crops only when we need them, and not on upload. We could create a thumbnail and a silver master that is a bit smaller and thus easier to work with from the original, and then generate crops when we need them. (We can even fake non-proportional crop previews using canvas or something else.) This is something we’ve talked about extensively, and notably, @mikeschroder happened to be one of the people who instigated those conversations (and who shepherded WP_Image_Editor into core).

        • heintore 3:00 pm on January 5, 2016 Permalink | Log in to Reply

          @nacin – we’re using the OTF Regenerate Thumbnails plugin extensively on our clients’ sites. It works exactly as advertised by generating images on the fly. No custom functions needed, all calls to the_post_thumbnail and other thumbnail functions are handled automatically.

          There may be plenty of reasons why this particular approach is a terrible solution for WordPress core, but I’m much preferring this plugin over how WordPress handles crops now 🙂

          https://wordpress.org/plugins/otf-regenerate-thumbnails/

      • Joe McGill 9:46 pm on January 2, 2016 Permalink | Log in to Reply

        I’ve thought about having a custom image size created when an image is added as a featured image to a specific post type. Maybe something like that could work?

      • Brad Touesnard 12:38 pm on January 7, 2016 Permalink | Log in to Reply

        +1

        #11895 is related to this and I suggested the same solution:

        > I think there is certainly a need for a “treatments” concept that is independent of size though. For example, it’s pretty common to want to crop a photo a certain way for display on a listing page (e.g. post archive page) but display the uncropped version on the detail page (e.g. single post page). I’m guessing that was the original intention of the “Apply changes to:” feature, but it never really hit the mark.

    • dryanpress 3:13 am on December 31, 2015 Permalink | Log in to Reply

      • SVG Dashicons
      • Update on direction of shortcodes in core and Shortcake
      • WP Admin Toolbar Improvements (https://core.trac.wordpress.org/ticket/32678). Proposed i10 changes look great, love increased negative space, but even fewer sites would be listed in view. A live search and list of recently updated and/or pinned sites would go a long way in moderate and large networks.
      • Native multiple authors for Posts. Co-Authors-Plus may add this in plugin territory, but subsequent integration into a theme requires complicated overriding or child theming. Giving non-developers the ability to add multiple authors on Posts, Books, Report Chapters, Music Videos, etc is important.
    • Peter Wilson 4:08 am on December 31, 2015 Permalink | Log in to Reply

      My wish list/hobby horses:

      • #35206 to control white space in menus, as a follow up to #27762 in 4.4 and later reverted.
      • #32793 to combine jQuery and jQuery migrate and reduce HTTP requests.

      Otherwise, some of the tickets around HTTP2 would be lovely to get in.

    • WP Sites - Brad Dalton 7:11 am on December 31, 2015 Permalink | Log in to Reply

      1. I’d like to be able to wrap opening and closing php tags in code tags using the text editor and 2. link gallery images.

    • Marius (Clorith) 7:39 am on December 31, 2015 Permalink | Log in to Reply

      I’d love to see some kind of merge between #20578 (the option to not trigger `uninstall.php`) and #9757 (better handling of uploads when the theme/plugin exists).

      As it stands it’s painful having to change to a different theme to update a custom theme. The process was made slightly better by core remembering widgets, but you still need to change the look of your site for a period of time while uploading and re-configuring and it is a terrible user experience.

      Of course, premium themes often leverage some filters to apply updates, but imagine the sites that run old premium stuff that are avoiding updating because it’s a tedious process, and the presumably large amount of them that don’t have this filter interaction any way.

    • Rian Rietveld 7:51 am on December 31, 2015 Permalink | Log in to Reply

      The Accessibility team focusses for this release on:

      • Make the colors of the default Admin scheme conform to WCAG 2 AA (tickets are labeled #a11y-color)
      • Remove title attributes from links
      • Improve the accessibility of the customizer (for keyboard only, screen readers and for color contrast)

      Help with this is very welcome.

    • leemon 8:22 am on December 31, 2015 Permalink | Log in to Reply

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

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

      I would love to see my reported bugs are resolved 🙂

      1. https://core.trac.wordpress.org/ticket/24990
      2. https://core.trac.wordpress.org/ticket/35216
      3. https://core.trac.wordpress.org/ticket/32920

      I don’t have #slack account. Never got my invitation. #2 is most critical if not all 😀

    • Martin Stehle 11:09 am on December 31, 2015 Permalink | Log in to Reply

      Please make Google Fonts in the backend and Emojis available only by activated checkboxes. Both features are on by default and generates dispensable traffic.

      More about the Google Fonts issue at ticket https://core.trac.wordpress.org/ticket/26072

      • askoxyz 11:17 am on December 31, 2015 Permalink | Log in to Reply

        +1

      • petermolnar 12:23 pm on December 31, 2015 Permalink | Log in to Reply

        YES, PLEASE.
        ( And that same for EVERY feature that is addon-level, like embed )

      • Last Rose Studios 3:43 pm on January 4, 2016 Permalink | Log in to Reply

        +1 Get rid of emojis – the fact that there area bunch of plugins and how-tos on how to remove them should be a clear indication that people don’t want them. There is no reason something like that should be in the core. At the very least, make it optional (activated only by checkbox).

    • Martin Stehle 11:25 am on December 31, 2015 Permalink | Log in to Reply

      Please make tags hierarchical like categories

    • Gerard Canters 12:20 pm on December 31, 2015 Permalink | Log in to Reply

      RFC:

      WP 4.3 accepted shortcodes with a tag containing a space, WP 4.4 does not. Also, you don’t get an error message or indication.
      Suggest to have add_shortcode funtion return a true result or an error-indication.
      In general should all functions return a true result or error.

    • benoitchantre 1:26 pm on December 31, 2015 Permalink | Log in to Reply

      I would like to see responsive image header and a drag and drop UI to reorder pages and custom post types.

    • Andrea Fercia 1:45 pm on December 31, 2015 Permalink | Log in to Reply

      1) Settings API: get rid of the tables and UI/accessibility improvements
      https://core.trac.wordpress.org/ticket/18801
      https://core.trac.wordpress.org/ticket/16413

      2) Re-think `$content_width`
      We’re in a “responsive era”, maybe re-think the whole idea of `$content_width` ? Some comments collected in the past months:
      https://core.trac.wordpress.org/ticket/21256#comment:25
      https://core.trac.wordpress.org/ticket/23863#comment:10
      https://github.com/Automattic/_s/issues/100#issuecomment-40746610
      https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2013-04-11&sort=asc#m593089

      3) Add a “typography” focus on Trac 🙂

      • Nico 11:20 pm on January 1, 2016 Permalink | Log in to Reply

        Totally agree with $content_width. I always hated that thing, even when not thinking about responsiveness.

      • robertwhitis 8:15 am on January 4, 2016 Permalink | Log in to Reply

        Along the lines of eliminating tables, the admin CSS classes need support for columns. An example would be the use of a jQuery repeater for a row of fields. There’s not really any built in support for a go-to way to handle columns currently that I am aware of.

      • Ahmad Awais 5:40 pm on January 4, 2016 Permalink | Log in to Reply

        +1 for #2.

    • tomdxw 2:21 pm on December 31, 2015 Permalink | Log in to Reply

      How about bcrypt? https://core.trac.wordpress.org/ticket/21022

      It’s a one-line change and it’ll make a huge difference to the security of 89% of WordPress sites (PHP 5.2 doesn’t support bcrypt, but PHPass falls back to using the old algorithm in that case).

    • Dave McHale 3:53 pm on December 31, 2015 Permalink | Log in to Reply

      One of the biggest complaints I hear from my users is the menu management tools in the admin. A CMS website with a moderate number of pages quickly becomes incredibly difficult to manage. An overhaul there is long overdue IMO.

      The classic widget management tools are equally frustrating to work with, but I think core is already on a path towards getting away from that screen as much as possible – so I don’t know if updates there are really worth time/attention.

      • Andrew Nacin 11:30 pm on January 1, 2016 Permalink | Log in to Reply

        I think a new exploration in menu management would require building an update as a plugin using the feature plugin model.

        Have you looked at menu management in the customizer? I feel like I prefer it. I agree it still becomes tough to work with, with a lot of pages, but have you ever used a menu-building experience that works well with a lot of pages? Actually, have you ever used a menu (as a user) with a lot of pages?

    • Najum Rahim 4:17 pm on December 31, 2015 Permalink | Log in to Reply

      My wishlist
      WP REST API

    • Scott Kingsley Clark 5:16 pm on December 31, 2015 Permalink | Log in to Reply

      I’m totally all about Fields API, there’s just a little bit more left to do and I’ll have it in a place where it’s ready for core proposal!

    • colomet 5:32 pm on December 31, 2015 Permalink | Log in to Reply

      If Photon can not refresh the pictures (in case we do changes). I preffer not to have photon and to have my own CDN.

    • colomet 5:33 pm on December 31, 2015 Permalink | Log in to Reply

      · Speed
      · Lower use of resources

      • Andrew Nacin 11:32 pm on January 1, 2016 Permalink | Log in to Reply

        These are nice wishes, but we realistically need concrete proposals for how to get there. For example, I pull up WordPress in KCacheGrind quite often when contributing, to identify bottlenecks and potential areas for improvement.

    • Justin Sainton 5:51 pm on December 31, 2015 Permalink | Log in to Reply

    • askoxyz 6:12 pm on December 31, 2015 Permalink | Log in to Reply

      Move WP Comment Humility (https://wordpress.org/plugins/wp-comment-humility/) to core, which moves the Comments top level menu under Posts top level menu, where it belongs now that comments are off on Pages by default.

      • Andrew Nacin 11:38 pm on January 1, 2016 Permalink | Log in to Reply

        I saw this proposal on Twitter the other day. I actually like it in theory, but:

        • It would probably be jarring/confusing for a lot of people who don’t know where their comments menu went. (This is a solvable problem, of course.)
        • If a custom post type supported comments, then what? (It could always move back. There’s of course been talk that comments should possibly be moderated per post type, but that gets annoying when all you have is posts and pages and you do use comments on pages — admittedly rare.)

        This absolutely could only be done if there was extensive usability testing with various scenarios that can back up the decision.

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

      Posts like this very one make me think that Emoji Reactions should be a thing. If we could all click an emoji +1/-1 (thumbs up/down) to vote, it would be so lovely.

      https://wordpress.org/plugins/emoji-reactions/ ? Pull that in? 😀

    • George 5:40 am on January 1, 2016 Permalink | Log in to Reply

      https://wordpress.org/plugins/custom-upload-dir/

      Add similar functionality to core.

    • luciole135 8:38 am on January 1, 2016 Permalink | Log in to Reply

      Hello,
      I hope to ask the right place unless I should not open a ticket for this?
      Some hosts including mine do not allow REWRITE RULES in the .htaccess file.
      It would be good to check before writing to it if the mod_rewrite is enabled before writing in the .htaccess because it induces 500 errors.

      • John Blackbourn 6:07 pm on January 4, 2016 Permalink | Log in to Reply

        Please open a ticket on core.trac.wordpress.org for this, with as many details as you can. The .htaccess handling code has been in WordPress for the best part of a decade, so it should be pretty stable by now, and there are lots of failsafes in place to prevent such 500 errors.

    • Ulrich 9:56 am on January 1, 2016 Permalink | Log in to Reply

      #32802: Update Masonry (v3.3.2) & imagesLoaded (v3.2.0) package
      #30797: New function for parent theme stylesheet uri
      #33407: Theme tags overhaul
      #26695 Themes: add support for multiple screenshots in themes
      #21256 New theme feature – add_theme_support( ‘content-width’, $defaults )

    • benoitchantre 1:13 pm on January 1, 2016 Permalink | Log in to Reply

    • szaqal21 1:21 pm on January 1, 2016 Permalink | Log in to Reply

      Add filter for _get_list_table() to allow using extended WP_Posts_List_Table class for edit screens, now it is hardcoded!

    • szaqal21 6:11 pm on January 1, 2016 Permalink | Log in to Reply

    • Maren-Reinecke 9:00 pm on January 1, 2016 Permalink | Log in to Reply

      1) I would very much appreciate a file manager for the media! As a photographer I have quite a lot of media and it´s not usefull to have them monthly organized…
      2) For the meta tags an opportunity to add noarchive, my old website worked with index, follow, noarchive, because I don´t want my media in google archives.

      Thanks for taking notice 🙂

      Maren

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

      Thanks for asking Mike!

      Drag & drop of All posts/pages/categories.
      Finally getting this trac ticket feature in place: https://core.trac.wordpress.org/ticket/2702

      Additional field options in the customizer. Adjusting site title, description menu etc. As it would make simple design adjustments easier for the beginner without having to get into coding

      That’s all I can remember off the top of my heard right now!

      Happy New Year to everyone!!..:)
      What an awesome year this will become!!

    • davidperez 9:57 pm on January 1, 2016 Permalink | Log in to Reply

      Hello, Have a Button to Update everything: Plugins, Themes and Languages.

      Nice Work!

    • davidperez 10:02 pm on January 1, 2016 Permalink | Log in to Reply

      Another Idea would be Edit Taxonomies as full editor: Thumbnail, WYSIWYG Editor, …

    • christinecooper 10:39 pm on January 1, 2016 Permalink | Log in to Reply

      My wishlist for 4.5 is mainly implementing the fixes that have already been provided to numerous bug tickets.

      For example, view the following ticket:
      https://core.trac.wordpress.org/ticket/15448
      Which I outlined here:
      http://wordpress.stackexchange.com/questions/191923/sending-multipart-text-html-emails-via-wp-mail-will-likely-get-your-domain-b

      That’s only an example. There are too many tickets like these which have been laying there, with completely appropriate solutions, and no sight in adding these fixes to core.

    • luciole135 6:43 am on January 2, 2016 Permalink | Log in to Reply

      Add a third markdown text editor next to the two existing.

    • bonger 9:15 am on January 2, 2016 Permalink | Log in to Reply

      Bugs. 4.4 squashed around 600 gross. A similar drive now would be very worthwhile.

    • Frank Bueltge 1:23 pm on January 3, 2016 Permalink | Log in to Reply

      Wishs are fine, but goals are important.

      • Multisite Maintenance

      ** Like Settings API and much more equally single core.

      • Fields API
      • Notification API ( kills wp_mail() )
      • Working with priority on open bugs.
      • Relationship table, Post2Post – also about the network of Multisite
    • seanbennick 1:31 pm on January 3, 2016 Permalink | Log in to Reply

      I would also like to see Widgets that can be created once and used across multiple sidebars, footers, etc. Widget Builder – https://wordpress.org/plugins/widget-builder/ takes a decent step towards this, but I think this would be a solid addition to the core.

    • Pam Blizzard 7:45 pm on January 3, 2016 Permalink | Log in to Reply

      Please give me an option to hook and/or filter the Cheatin’ eh message. When delivering WP as a CMS, it’s too perplexing for the users and they don’t know what to do next. Give me an option to put meaningful instructions for my users on how to move forward or get help.

      • J.D. Grimes 5:01 pm on January 4, 2016 Permalink | Log in to Reply

        See #14530

        • Pam Blizzard 12:47 am on January 5, 2016 Permalink | Log in to Reply

          I respectfully disagree that it’s fixed, if the message, “Cheatin’, eh?” displays anywhere on a website that doesn’t belong to a WordPress developer.

      • John Blackbourn 6:11 pm on January 4, 2016 Permalink | Log in to Reply

        Do your users regularly see this message? If so, the root cause should be investigated because ideally no user should ever see this message.

        • Pam Blizzard 12:53 am on January 5, 2016 Permalink | Log in to Reply

          No, not regularly, but once is too much IMO. I have had clients email me from time to time upon receiving it and it’s embarrassing, when I have to explain that it’s considered “funny”. I get the joke, but they don’t. The message is not truly helpful, in any way. I know we can do better, and I’m willing to help in any way that I can.

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

            Pam, how/when/where are they seeing this?

            Becuase John’s point is that they NEVER should be able to see that. And it indicates something serious is behaving in an unexpected way 🙂 While agreeing that the message should be filterable, we still want to understand the circumstances that make it happen so we can possibly fix THAT too.

            (Of course if it’s ‘a plugin is doing something daft, we may not be able to, but it helps us understand the root cause.)

            To quote Nacin from the trac ticket:

            This warning should never be accessible via the UI. These are nothing more than sanity checks. If they can be accessed in a normal setup via the UI then that is a bug.

            So while it perhaps should be filterable, there’s an underlying bug there. That’s why the initial trac ticket was resolved with “Provide more helpful feedback than just “Cheatin’ uh?” for permission errors in wp-admin/js/customize-controls.js.”

            The bug, the part where people could legit click a link and get there, was fixed.

            Where are you running into this? What are your users doing?

            • Pam Blizzard 5:16 pm on January 6, 2016 Permalink

              I myself got it 3 days ago, when my browser hung after deleting a theme, and I hit refresh. Being experienced, I knew what it was and what the next step was. However, I’ve had 3 phone calls from clients about it in the last year, (prefer not to detail what caused it here, but can if really necessary) they just didn’t know where to go next.

              I searched Twitter, wpStackExchange and WP.org support on that term and found people posting about it within the last few months. The point is, it does appear.

              I’m trying to understand why it’s hard coded 34 times, http://bit.ly/1mGhBwp if it’s not needed, and “shouldn’t appear in the UI”

              Again, I’m willing to help out in any way I can. I’m not just kvetching, I’m here to learn and help.

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

            I myself got it 3 days ago, when my browser hung after deleting a theme, and I hit refresh.

            Yeah, that’s one of those cases where we can’t really avoid it. Let me guess, you force quit the browser and reopened with extant tabs? So WP tried to reload with an expired nonce. (Which is personally why I think this message should be filterable/customizable – unavoidable browser crashes happen. We didn’t used to have our browsers be able to reopen all tabs when restarting… Ahh the old days.)

            Can you tell us, in general terms, what the users were doing? Uploading a file, trying to use a specific plugin? I totally get that you can’t give us details 🙂 But if we can narrow down if a plugin is derping or if there’s a legit bug in WP, it helps.

            • Pam Blizzard 12:54 pm on January 7, 2016 Permalink

              I appreciate very much that you’re willing to troubleshoot the problem, and another venue like the support forums is probably more appropriate, and I will open a thread there. My point for the Wish List: The error message displays and is not worthwhile in any way, and in fact detrimental, because “Cheatin’, eh/uh?” is cutesy, flippant, accusatory and snarky and not indicative of the professional tool that WordPress is. If those 34 instances of that literal exist, let’s at least replace them with something like, “something unexpected happened, please return to your Dashboard or contact your support resources.” or something similar that helps the user go to the next step.

    • Spacedmonkey 8:11 pm on January 3, 2016 Permalink | Log in to Reply

    • Knut Sparhell 10:45 pm on January 3, 2016 Permalink | Log in to Reply

      Core framework for multi-language
      Fields API
      Continued Multisite cleanup
      Remove Post-by-email in favor of plugins
      Tool to convert Links to Menus, in preparation for removing Links in a later release
      Continued user facing options cleanup
      Unmanaged/private plugins marker
      Install multiple plugins
      Implement REST API endpoints
      New strategy for bumping requirements
      Framework for 2-factor authentication
      Better password hashing
      Frontend editing of posts (text)
      Customizer: Point at any customizable element to open it
      Customizer: Partial refresh

    • robertwhitis 8:27 am on January 4, 2016 Permalink | Log in to Reply

      I’m always happy to see work put into multisite.

      Domain mapping in core would be huge.

    • rgllm 11:02 am on January 4, 2016 Permalink | Log in to Reply

      User roles.

    • nealumphred 1:35 pm on January 4, 2016 Permalink | Log in to Reply

      Return the VIEW POST option to the Admin Panel so that it can be seen and used after a post has been published.

      • John Blackbourn 6:13 pm on January 4, 2016 Permalink | Log in to Reply

        There are already two (or three, depending on the action) links to view the post from this screen. The ‘View Post’ link in the admin toolbar, and the permalink itself. Removing it was intentional. See #18306.

    • Ahmad Awais 5:54 pm on January 4, 2016 Permalink | Log in to Reply

      Late to the party. I’m looking forward to so many things in 4.5.

      — WP REST API (Of-course!)
      — Fields API (This is a long time coming and is a much-needed improvement)
      PHP Templating Engine Twig could be perfect
      Safe Mode Run
      — Weston Ruter’s idea of adding Add New Post/Page to the customizer
      — UX: I like how easily we can drag & drop images to upload them (Media -> Add New) Screenshot ,maybe we can have a similar drag & drop plugin and theme installer (Plugins -> Add New area)

      That’s all for now.

    • whizadree 5:54 pm on January 4, 2016 Permalink | Log in to Reply

      would like to see 2FA, Recaptcha as core spend much more time with user security and encrypting data within the database (no plain text info ) , more Customization for Admin without plugins , ( customize menus , custom links , hide unused ) , a core file manager with option for changing permissions and warning of security risks for both files and folders as core (with additional plugins to increase usage ) , better admin of sites using mobile devices such as a full WordPress mobile app the manage the system and install plugins from qr codes , and find a proper way to stop fake accounts / users

    • freetheweb 6:19 pm on January 4, 2016 Permalink | Log in to Reply

      • Custom CSS editor in the Customizer instead of having to install Jetpack
      • Enhanced Admin UI
      • Now that WordPress has established itself as a full CMS for the web, I think we should have custom taxonomies as part of the default admin options instead of having to install third party plugins to set them up, which is often confusing
    • Arunas Liuiza 7:16 pm on January 4, 2016 Permalink | Log in to Reply

      My biggest pain point is not in the features/code at the moment, but in the lack of documentation, particularly, on the JavaScript part of things – WP Editor, Media Manager, etc.

      On the code part of things, I’d love for wp_editor to have a flag to return its content instead of echoing everything all the time. I get tired of playing with `ob_start()` and friends every time I need to use it in some callback function or other.

    • calendarboy 12:38 am on January 5, 2016 Permalink | Log in to Reply

      I would like to be able to sort users by name, or by address

      On the Users page it appears you can sort by name, but it does not work. Instead, selecting Name actually just sorts on Username.

      I would like to be able to sort users by Name and by address.

      I have deleted over a thousand bogus “users” created by bots (despite using a catcha) over the past two days. It has taken hours and I’m nowhere near being done.

      With the ability to sort Users, I could have deleted all of the bogus entries in minutes.

    • Andrew Wilder 1:24 am on January 5, 2016 Permalink | Log in to Reply

      Right now, comments can only by linked to by using an anchor tag, and if the pagination is ever changed, then the anchor reference will be broken.

      I’d like to see comments get their own permalink structure — so links to specific comments will stay valid if the pagination ever changes. (I’ve run into changed pagination many times… maybe a site owner changes the comment display order, or changes the number of comments per post, or some comments get deleted, shifting them up to a new page…there are lots of ways the structure of http://oursite.com/blog-post/comment-page-5/#comment-12345” can break over time.)

      https://core.trac.wordpress.org/ticket/26133#comment:3

    • Daniel Llewellyn 4:31 am on January 5, 2016 Permalink | Log in to Reply

      selfishly I’d like #29325 to be merged, so I can wear a new contributor badge with pride 😀

    • Marko Heijnen 6:49 pm on January 5, 2016 Permalink | Log in to Reply

      • More control for images

        • Ability add more information for an image size like quality or zoom
        • Add the image size to the filters for responsive images. width/hight simply doesn’t work
        • Ability to auto generate images and to stop them from getting generated. Internal API which by default is off. Will makes things easier for plugins since internal APIs need to be changed.
        • non web image like Tiff converting to JPG (imagick).
        • Other cool imagick tricks to generate a thumbnail for PDF’s for example
      • XML-RPC component cleanup. What can still be done or where will the REST API be good enough. Making hard cuts.
    • benoitchantre 10:03 pm on January 5, 2016 Permalink | Log in to Reply

      #29783: User Admin Language

    • Nicolas Juen 10:22 am on January 6, 2016 Permalink | Log in to Reply

      More modern tools support :

      • Composer
      • Namespacing
      • Autoloading

      And potential muliple levels of themes, at least allow locate_template working on more than 2 folders with a hook to edit the paths available.

      • Nicolas Juen 10:24 am on January 6, 2016 Permalink | Log in to Reply

        And at least unified fields management (options,users, * meta ) with the currently developping Field API 🙂

    • Zwaar Contrast 2:10 pm on January 6, 2016 Permalink | Log in to Reply

      I’d like to be able to hook into the image editor!

    • Mel Choyce 7:20 pm on January 6, 2016 Permalink | Log in to Reply

    • Ryan Boren 8:11 pm on January 6, 2016 Permalink | Log in to Reply

      Some usability focused wishes.

      We’re WordPress and all about the open web. The open mobile web is rather a mess. The open web needs to be great on mobile, and WordPress can help make that happen.

      https://make.wordpress.org/flow/2015/06/13/the-top-5-impediments-to-flow-on-touch-devices/

      I arrive at WP sites through Twitter and other apps on my touch devices. Lots of people do. We come out of our apps, land on a site, touch an image, and get a bad experience. WP sites have poor media touch flow.

      https://make.wordpress.org/flow/windmills/#carousels-and-touch-media
      https://make.wordpress.org/flow/2015/02/26/core-support-for-wordpress-images-to-open-in-a-modal-window/

      The toolbar is overdue for an update. I like where this ticket is going.

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

      Retire media-new.php.

      https://make.wordpress.org/flow/2015/01/29/retiring-media-new-php/

      Continue reducing settings.

      https://core.trac.wordpress.org/ticket/32396
      https://wordpress.org/plugins/wp-core-settings-reduction-project/

      Keep advancing the customizer and live preview.

    • Grant Palin 10:44 pm on January 6, 2016 Permalink | Log in to Reply

      • native post relationships
      • ability to regenerate specific image thumbnails and not the whole lot
    • Rich Tabor 11:48 pm on January 6, 2016 Permalink | Log in to Reply

      How about a drag-and-drop-in-place element for the Featured Image metabox (like what we have for the post editor)?

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

      • Redesigned/improved Image Library along with the ability to create folders.
      • Fix the Image Library Grid/List UI so there’s not multiple screens that perform the exact same function. The whole Gird/List UI has been a mess since the Grid layout was introduced.
      • Customizer redesign including the ability to default to wider 2 column layout so you’re not scrolling for pages and pages when there’s heaps of options.
      • Better consistency with Customizer UI. Sometimes you click a button and more fields appear below it. Other times you click a button and a panel slides in and out of view. Sometimes when you click a button, the panel slides to the left, other times it slides to the right. Users shouldn’t have to wonder what’s going to happen when you click a button.
      • Better notification experience. Too many plugins/themes are cluttering up the WordPress Dashboard with multiple and constant notifications.
      • Redesign of the Show Password/Hide/Show/Cancel/Generate Password buttons on the User Profile screens. The UI is confusing and there are too many unnecessary buttons.
      • Anthony Hortin 6:45 am on January 19, 2016 Permalink | Log in to Reply

        Adding to my list above…

        • The ability to be able to upload AND overwrite existing plugins. So Annoying not being able to upload newer plugin versions through the dashboard and simply overwrite the old version
    • Ross Wintle 9:41 am on January 7, 2016 Permalink | Log in to Reply

      • Any movement towards an efficient API for post-to-post relationships
      • Now that the REST API is (nearly) here, we should start improving the core UI. Could we start by using AJAX for pagination/sorting/filtering on list tables
      • TWIG-like templating. Or at least, some API that enables us to better separate logic and display. Currently I can use things like the query var to pass data to a template (as documented in the codex page for get_template_part: https://codex.wordpress.org/Function_Reference/get_template_part#Passing_Variables_to_Template) but it would be nice to have a data API or some way to pass data to templates. WP isn’t MVC so I’m not entirely sure what this would look like.
      • Ability to both install and upload multiple plugins in one go, and to overwrite existing plugins (for when you’re uploading an update to an existing plugin)
      • Ability to set login/dashboard URL as part of core
    • Lisa 1:49 pm on January 7, 2016 Permalink | Log in to Reply

      Let’s make notifications a thing of delight for the user.

      Can we have a universal inbox for them, and maybe add Wapuu or something that makes people smile. Like – https://cloudup.com/cQtJsMhtf0L

    • HoaSi 11:07 pm on January 11, 2016 Permalink | Log in to Reply

      Further improvement to https://core.trac.wordpress.org/ticket/26937 would be nice.

    • Tim 1:58 pm on January 12, 2016 Permalink | Log in to Reply

      The top pain point for me and my clients is probably management of the media library (as mentioned by lots of others); I’d love to see that a priority.

      Other things I routinely install plugins for, and would love not to have to:

      • Tree view and drag-and-drop sorting of pages (and posts and other types)
      • Global disabling of the comment system for sites where comments are irrelevant
      • Adding featured images to taxonomies
      • Using a visual editor for taxonomy descriptions

      Nice as it would be to have multi-language and page-by-page permissions in core too, I do realise that these are huge endeavours and the core team probably wishes to leave them to third party plugins, even though those plugins are far from perfect. 🙂

    • Ipstenu (Mika Epstein) 9:44 pm on January 12, 2016 Permalink | Log in to Reply

      I’m going to sneak add https://core.trac.wordpress.org/ticket/35429 – Since I upload a LOT of plugins for testing, this would save me oddles of time 🙂

    • shackep 1:53 pm on January 14, 2016 Permalink | Log in to Reply

      I think “enable-media-replace” https://wordpress.org/plugins/enable-media-replace/ should be added to core. Such a simple handy plugin. And perhaps something like https://wordpress.org/plugins/media-item-url/ while we are at it. Small things that many people could find useful.

    • The-Dude 2:57 pm on January 14, 2016 Permalink | Log in to Reply

      Native TOC-Support working together with Pagebreak would be very helpfull! 🙂

    • Damir Calusic 11:02 am on January 17, 2016 Permalink | Log in to Reply

      We really need this simple fix https://core.trac.wordpress.org/ticket/28381

    • summoner 10:35 pm on January 18, 2016 Permalink | Log in to Reply

      +1 for LOT of enhancements in media library (ordered by complexity):

      • Media categories;
      • “enable-media-replace” as mentioned by shackep;
      • Different sizes in different folders;
      • Adding a per file generated pre- or suffix to original file names so that people can not harvest others’ original images by simply deleting some characters of the thumbnail url…;
      • Maybe even some content protection functionality Galleries are great but FB like photo albums would be welcome as well (see in: https://wordpress.org/plugins/simple-photo-albums / this one does not add any new menu items which is great);
      • Image focal points as mentioned by chrishoward;

      +1 WP simply MUST support multilanguage content out of the box (as even personal blogs tend to need that, not to mention business sites)

    • itsnotrocketsurgery 2:45 pm on January 25, 2016 Permalink | Log in to Reply

      A mechanism for tagging and filtering themes would be useful. When I provide my themes/child themes to end users, it would be useful for me to tag them with their colours and be able to provide a filter at the top of the theme selection page.

      I’m not aware that anything like this already exists and I’m not a developer, but it would be handy to freely tag themes somehow, even just from within the theme CSS header.

    • camelotcamel 11:12 am on January 28, 2016 Permalink | Log in to Reply

      It’s all been said before, but anyway:

      Better media management!

      • upload to user defined folders
      • “add from server” functionality
      • media categories
      • media replace
    • Settler11 8:38 am on February 2, 2016 Permalink | Log in to Reply

      The Duplicate Post plugin! Almost a million downloads.
      And media management; but that’s been said a thousand times I think. 🙂

    • ledgoti 3:53 pm on February 4, 2016 Permalink | Log in to Reply

  • Joe McGill 2:56 am on November 10, 2015 Permalink |
    Tags: , , ,   

    Responsive Images in WordPress 4.4 

    WordPress 4.4 will add native responsive image support by including srcset and sizes attributes to the image markup it generates. For background on this feature, read the merge proposal.

    How it works

    WordPress automatically creates several sizes of each image uploaded to the media library. By including the available sizes of an image into a srcset attribute, browsers can now choose to download the most appropriate size and ignore the others—potentially saving bandwidth and speeding up page load times in the process.

    To help browsers select the best image from the source set list, we also include a default sizes attribute that is equivalent to (max-width: {{image-width}}px) 100vw, {{image-width}}px. While this default will work out of the box for a majority of sites, themes should customize the default sizes attribute as needed using the wp_calculate_image_sizes filter.

    Note that for compatibility with existing markup, neither srcset nor sizes are added or modified if they already exist in content HTML.

    For a full overview of how srcset and sizes works, I suggest reading Responsive Images in Practice, by Eric Portis over at A List Apart.

    New functions and hooks

    To implement this feature, we’ve added the following new functions to WordPress:

    • wp_get_attachment_image_srcset() – Retrieves the value for an image attachment’s srcset attribute.
    • wp_calculate_image_srcset() – A helper function to calculate the image sources to include in a srcset attribute.
    • wp_get_attachment_image_sizes() – Creates a sizes attribute value for an image.
    • wp_calculate_image_sizes() – A helper function to create the sizes attribute for an image.
    • wp_make_content_images_responsive() – Filters img elements in post content to add srcset and sizes attributes. For more information about the use of a display filter, read this post.
    • wp_image_add_srcset_and_sizes() – Adds srcset and sizes attributes to an existing img element. Used by wp_make_content_images_responsive().

    As a safeguard against adding very large images to srcset attributes, we’ve included a max_srcset_image_width filter, which allows themes to set a maximum image width for images include in source set lists. The default value is 1600px.

    A new default image size

    A new default intermediate size, medium_large, has been added to better take advantage of responsive image support. The new size is 768px wide by default, with no height limit, and can be used like any other size available in WordPress. As it is a standard size, it will only be generated when new images are uploaded or sizes are regenerated with third party plugins.

    The medium_large size is not included in the UI when selecting an image to insert in posts, nor are we including UI to change the image size from the media settings page. However, developers can modify the width of this new size using the update_option() function, similar to any other default image size.

    Customizing responsive image markup

    To modify the default srcset and sizes attributes,  you should use the wp_calculate_image_srcset and wp_calculate_image_sizes filters, respectively.

    Overriding the srcset or sizes attributes for images not embedded in post content (e.g. post thumbnails, galleries, etc.), can be accomplished using the wp_get_attachment_image_attributes filter, similar to how other image attributes are modified.

    Additionally, you can create your own custom markup patterns by using wp_get_attachment_image_srcset() directly in your templates. Here is an example of how you could use this function to build an <img> element with a custom sizes attribute:

    <?php
    $img_src = wp_get_attachment_image_url( $attachment_id, 'medium' );
    $img_srcset = wp_get_attachment_image_srcset( $attachment_id, 'medium' );
    ?>
    <img src="<?php echo esc_url( $img_src ); ?>"
         srcset="<?php echo esc_attr( $img_srcset ); ?>"
         sizes="(max-width: 50em) 87vw, 680px" alt="A rad wolf">

    Final notes

    Users of the RICG Responsive Images Plugin should upgrade to version 3.0.0 now in order to be compatible with the functionality that included in WordPress 4.4.

     
    • Tomas Mackevicius 3:33 am on November 10, 2015 Permalink | Log in to Reply

      Can we say that from now on users will be encouraged to always include full sized image instead of one that fits the regular content width the best, like size Large?

      Another question is if this improvement will affect images in older posts that are already inserted with certain predefined width parameters.

      Thank you!

      • Joe McGill 4:38 am on November 10, 2015 Permalink | Log in to Reply

        Hi Tomas,

        Site authors will be able to include whichever size they feel is most appropriate, but now site visitors will get the benefit of downloading the best image source available to fit their needs, which could be larger or smaller, depending on their device capabilities.

        • Tom Belknap 4:10 pm on December 15, 2015 Permalink | Log in to Reply

          I’m not sure that this is entirely true: while in full-size view I can see the proportional size, in practice WP is putting the thumbnail in on small screens.

          Another question: if we override the default image placement (say, to use

          instead of captions), we’ll need to perform the above snippet of code to make it work, is this correct?
    • David Chandra Purnama 4:10 am on November 10, 2015 Permalink | Log in to Reply

      in wp we have “hard-crop” (such as thumbnail size), or soft-crop (like medium large sizes) or my fav is using fixes width, and very tall height to keep the image as is (resize, no crop)

      so how do WP check this images? what images WP uses?

      I don’t want to display my image content as thumbnail, when it shouldn’t be cropped (?)
      thank you.

      • Joe McGill 4:39 am on November 10, 2015 Permalink | Log in to Reply

        Hi David,

        WordPress will only include images that match the same aspect ratio as the image in the ‘src’ attribute.

    • Monika 8:06 am on November 10, 2015 Permalink | Log in to Reply

      I’m using WP 4.4 and twenty sixteen on my testsite.
      *only developer plugins are active

      *for “responsive image tests” I ‘m using always the same image and upload it again.

      *my last test was this morning.

      If I insert an image with 300×199 in a post,

      I can find all large sizes in source => this doesn’t make sense too me.

      example

      <img src="xx/media/2015/11/IMGP9685-300×199.jpg" alt="IMGP9685"
      width="300" height="199" class="aligncenter size-medium wp-image-750"
      srcset="xx/media/2015/11/IMGP9685-250×166.jpg 250w,
      xx/media/2015/11/IMGP9685-300×199.jpg 300w,
      xx/media/2015/11/IMGP9685-768×511.jpg 768w,
      xx/media/2015/11/IMGP9685-1024×681.jpg 1024w,
      xx/media/2015/11/IMGP9685.jpg 1029w" sizes="(max-width: 300px) 85vw, 300px"

      How can I avoid this?

      • Joe McGill 1:13 pm on November 10, 2015 Permalink | Log in to Reply

        Hi Monika,

        The larger sizes are included in the srcset attribute in order to account for screens with high density displays and only the most appropriate size will be used for any device, so this is the expected behavior. However, if you want to keep out all the large sized images from being included in your srcset attributes, you can filter the max_srcset_image_width, like this:

        function filter_max_srcset( $max_width, $size_array ) {
        if ( $size_array[0] === 300 ) {
        $max_width = 768;
        }

        return $max_width;
        }
        add_filter( 'max_srcset_image_width', 'filter_max_srcset', 10, 2 );

    • Mark-k 1:36 pm on November 10, 2015 Permalink | Log in to Reply

      To add to monica above, it seems like there is a missing option, a non responsive image. Lets say the image is a company logo and it should be displayed at exactly one size no matter what images WP generates for it an if it doesn’t stretch well on the screen.

      • Joe McGill 3:54 pm on November 10, 2015 Permalink | Log in to Reply

        Hi Mark,

        The responsive image markup should not change the display size of your image. Instead, it’s used to let the browser know which image source to use. For example, if you have a company logo that should be displayed at 300px wide, and you have a 300px version of the logo and a 600px version of the logo, you can identify both image sources in the `srcset` attribute and retina displays could use the 600px version so the logo looks crisp on all devices.

        Joe

        • Mark-k 5:54 pm on November 10, 2015 Permalink | Log in to Reply

          The point is that for whatever reason I don’t want to use anything except for the full size image, what should I do then. Possible (but maybe invalid) scenario is the ability to save the full size image on my local pc. If I give the browser the option to select whatever image is being displayed, what would be the image saved?

          Another related question that came into my mind is by what criteria the images are added to srcset? Are those all the images for which there is an add_image_size or is there some selectivity?

        • Mark-k 6:08 pm on November 10, 2015 Permalink | Log in to Reply

          Maybe I have a better real life question. Once images are compressed into about a file size of 30k it is hard to get any real reduction in size just by using lower dimension without terminally reducing the quality of the details of the image. Therefor I do not want to suggest to the browser to get any image smaller then 30k even if it fits better because the price I pay in bandwidth is not worth the quality reduction, and I would prefer to avoid another hit on the server just because the resolution was changed when flipping the device without making enough display space for a much better image.

          • Joe McGill 10:35 pm on November 10, 2015 Permalink | Log in to Reply

            Hi Mark,

            There may be valid scenarios where you would not want this functionality, and if so, you are free to use the included filters to modify/remove the default behavior. That said, I would suggest spending a bit of time getting familiar with the benefits of responsive images and how they work before making that decision, because generally, the benefits to your users (and your bandwidth) should be worth it. For a primer on responsive images, check out this blog series: http://blog.cloudfour.com/responsive-images-101-definitions/

            Cheers

            • Mark-k 7:43 am on November 11, 2015 Permalink

              1. It is really annoying to get from core developers the attitude of “we know better then you so trust us”. In this case since I am following the whatwg mailing list I am quiet sure I am aware of this feature history and how it is intended to be used and what were the objections to it that created the picture element in the end as much as you.

              2. Unlike oEmbed and REST API this is not a new functionality developed on empty slate and it has an impact on the behavior of all existing sites, therefor you can’t just say “it is easy to do with a filter” which might be very true but joe shmo that will upgrade from 4.3 to 4.4 doesn’t know that he is supposed to write a filter to keep his site functioning exactly as before.

              3. So this is my suggestion
              a. have an option to control whether this feature is inactive
              b. on upgrade from 4.3 set the option to true

              This follows what was done for link management so I am sure there is some efficient pattern to use here.

              People that want to opt in can use a simple plugin that should be run only once to do that.

            • Joe McGill 1:08 pm on November 11, 2015 Permalink

              Mark,

              Thanks for the feedback. Comments are not generally the best forum for long explanations and I was attempting to acknowledge that you may have valid reasons for turning these off without a long technical explanation. I can see how it would have come across as condescending, which was not my goal.

              I’ll add that we did ask for community feedback regarding whether this feature should be turned on by default or if we should toggle it on via a site option and the majority of people thought we should turn it on by default.

              Thanks,
              Joe

    • Travis Northcutt 8:51 pm on November 10, 2015 Permalink | Log in to Reply

      First off, awesome! Thanks, RICG team, for making this happen.

      > The medium_large size is not included in the UI when selecting an image to insert in posts, nor are we including UI to change the image size from the media settings page. However, developers can modify the width of this new size using the update_option() function, similar to any other default image size.

      One thought on this: does this mean that if the width of medium_large is changed, there won’t be any indication of that change (save, of course, for the actual images being generated at a different size)? If so, I wonder if that might make debugging a tad difficult, since it could lead to inconsistent behavior (old images at 768px, new ones at ____px) without a clear reason as to why, without looking directly at the database (something many/most people won’t/can’t do).

      That’s certainly not an argument in favor of a UI to change this, and is admittedly an edge case, but I wanted to at least mention it in case it bears further discussion.

      • Joe McGill 10:27 pm on November 10, 2015 Permalink | Log in to Reply

        Hey Travis,

        Good thought. For that size to change, a developer would have to intentionally run `update_option()`. I think it would be rare when that happens unintentionally, or that a future developer couldn’t check the size through a `get_option()` call in order to debug the issue. However, if we find out that leaving the option out of the admin UI causes a large amount of issues, we can certainly add it later.

        • Joe
    • Morten Rand-Hendriksen 10:04 pm on November 10, 2015 Permalink | Log in to Reply

      Probably a dumb question:

      Is `wp_make_content_images_responsive()` applied to posts by default ensuring that existing posts will receive responsive images? Or am I just misunderstanding the function of this function?

      • Joe McGill 10:29 pm on November 10, 2015 Permalink | Log in to Reply

        Hi Morten,

        Sorry that the post wasn’t clear. The `wp_make_content_images_responsive()` function is automatically hooked to the `the_content` filter and will automatically apply responsive image markup to all posts by default, regardless of when they were originally published.

        Joe

        • Morten Rand-Hendriksen 10:40 pm on November 10, 2015 Permalink | Log in to Reply

          OK. That’s what I suspected. So the purpose of the wp_make_content_images_responsive() function comes into play any time you want to apply the RICG markup to content that is not filtered through the_content then.

          • lamnt 8:19 am on November 11, 2015 Permalink | Log in to Reply

            I did installed RICG 3.0 on wordpress 4.3 but i don’t see it works. Is this compatible with these? I also check attributes in “the_content”, i don’t see the srcset, data-size or something like that of RICG.
            It seems doesn’t work filter and automatically apply responsive image.

    • Paal Joachim Romdahl 10:21 pm on November 10, 2015 Permalink | Log in to Reply

      Ehhh hmm not sure what to say here….
      How would this benefit the regular beginner user and designers?
      I am trying to grasp what your saying.
      If you could “dumb down” the language a bit that would help.
      Thanks.

    • programmin 4:10 am on November 11, 2015 Permalink | Log in to Reply

      This is exciting news! I wonder if there are any good developer tools for testing through these, as the Firefox Inspector doesn’t seem to give any special preview to the srcset or sizes attributes, just shows a very long attribute text.
      Thanks for the good work 🙂

    • FolioVision 4:43 am on November 11, 2015 Permalink | Log in to Reply

      HI Joe,

      This is wonderful! How does the srcset and sizes for responsive images fit in with Retina? Should we expect full retina support any time soon?

      Alec

      • Joe McGill 12:58 pm on November 11, 2015 Permalink | Log in to Reply

        Hi Alec,

        Browsers that support the `srcset` and `sizes` take into account the screen density when selecting an appropriate source, so this will provide full retina support as long as the original uploaded image was large enough to have the appropriate sizes created by WordPress.

        Joe

        • Jesse Heap 10:00 pm on December 9, 2015 Permalink | Log in to Reply

          Joe,

          Doesn’t that assume though that your theme is appropriately setup with image sizes that are 2x the size of the image?

          If I’m understanding correctly I think it still may make sense to use plugins like WP Retina 2x as that plugin will automatically create a retina image that is twice the resolution regardless of whether you have the appropriate image sizes setup in your theme.

          If I’m understanding correctly, using a plugin like Wp Retina 2x is potentially a better solution especially if you have varying image sizes as WP Retina 2x will dynamically create the 2x image based on the original image dimensions….

          Am I correct?

    • Dwain Maralack 1:04 am on November 12, 2015 Permalink | Log in to Reply

      Well done for getting the feature wrapped up Team!

    • David Chandra Purnama 1:26 pm on November 13, 2015 Permalink | Log in to Reply

      thank you for the explanation.
      is there possible performance and compatibility issue for filtering content with this complex parser? (vs the benefit for default content filter)
      here’s my full thoughts for this feature to help explain my question:
      https://shellcreeper.com/responsive-image-in-wordpress-4-4/

      • Joe McGill 3:05 pm on November 14, 2015 Permalink | Log in to Reply

        Hi David,

        Great write up about your experience testing the feature. Thanks for sharing.

        From a performance point of view, filtering the content to add responsive image support adds a bit of overhead, but many times, I expect users to benefit by downloading smaller images than they would have normally—making the small overhead worthwhile.

        On the compatibility side, I’m sure there will be some issues to work out. For example, the Jetpack team is working right now to make sure that Photon is compatible with this feature. As issues come up during the next few weeks, we’ll work to address what we can.

        Thanks,
        Joe

    • klihelp 10:27 pm on November 20, 2015 Permalink | Log in to Reply

      Thanks!

    • joost de keijzer 10:35 am on November 26, 2015 Permalink | Log in to Reply

      Hi, great feature!

      De srcset attribute doesn’t seem to be added by default to images in a gallery. Is this on purpose?

    • tornography 10:09 am on December 9, 2015 Permalink | Log in to Reply

      Please include the original size into srcset aswell. Otherwise the largest srcset is loaded, even if the original image is larger.

      Example:

      src = original.jpg // 1920*1200
      srcset = small-300.jpg 300w, …, large-1024.jpg 1024w
      sizes = (max-width: 1920px) 100vw, 1920px

      Window/Browser is 2084px wide, but large-1024.jpg is laoded. If srcset is extended by the original size:

      srcset = …, original.jpg 1920x

      the original sized Image is laoded.

    • jmy1138 3:01 pm on December 9, 2015 Permalink | Log in to Reply

      For those of us that are already using the RICG Responsive Images Plugin, is there any advantages to dropping this plugin and using the native responsive image feature?

      • Joe McGill 3:12 pm on December 9, 2015 Permalink | Log in to Reply

        Hi Jon,

        The plugin still includes a few features that are not found in core. Namely, advanced image compression, the Picturefill polyfill to enable responsive image support on older browsers, and some backward compatibility shims for people who were using early versions of the plugin that wrote `srcset` and `sizes` information directly to the markup saved in posts. If none of those issues are important to you then you can safely remove the plugin.

        Thanks,
        Joe

        • jmy1138 5:07 pm on December 9, 2015 Permalink | Log in to Reply

          Thanks for the feedback Joe. I can seeing compressing images before uploading to WP, enqueuing the Picturefill script, and making sure syntax is up to date would negate the need for the plugin.

    • Angristan 3:52 pm on December 9, 2015 Permalink | Log in to Reply

      Some images are loaded with the srcset attribute in HTTP and not HTTPS, so most browsers are blocking them on my website…

    • Eric Mathison 6:36 am on December 10, 2015 Permalink | Log in to Reply

      How will this behave with custom image sizes added with add_image_size? We’ve long adapted to not using the builtin WordPress Image sizes and create our own, which are easier to reference when adding into a post.

    • zjk 8:40 am on December 10, 2015 Permalink | Log in to Reply

      Hi,

      In my wordpress image are done with a structure of a div wrapper with classes like “preload” triggering the js process deferred after dom ready, also “loader” for getring a nice loading font awesome icon animation nicely centered in the container while the ressource is non obstruvisly loading. This allow me to get the best response time of default interface. Img src are are given in a data-src attribute of this div, and used by the js loading process. I just have in a noscript with default img src in case we have no js support. Please allow us to have your fonctionnality disabled by default as my manner of processing img is far better in term of support and frontend perfomance.

      cheers

    • stemie 3:13 pm on December 10, 2015 Permalink | Log in to Reply

      I have https enabled on my backend and since the WordPress 4.4 update my featured images in the backend display blank images. When I remove srcset image (with chrome developer tools) the featured image appears. The srcset image causing the problem is http while all my other images are https (or at least they begin with //). Any ideas how to get the featured image to show or enable https on the srcset?

    • thisisbbc 6:32 pm on December 10, 2015 Permalink | Log in to Reply

      Hi there,
      We’re struggling to get our product images to display the right size. They keep getting cropped for an unknown reason. Is there any known problems with WooCommerce?
      Thank you
      B

    • christoffer.alm 6:22 pm on December 11, 2015 Permalink | Log in to Reply

      Is there any way to implement this on background images, aka with image-set?

      background: -webkit-image-set( url(‘path/to/image’) 1x, url(‘path/to/high-res-image’) 2x );

    • Tim Berneman 7:40 pm on December 11, 2015 Permalink | Log in to Reply

      What’s the code to remove the srcset tags from my images? I have some custom code and WP4.4 is cause my images not to display. Here is my current code:

      global $post;
      if ( has_post_thumbnail( $post->ID ) )
        echo get_the_post_thumbnail( $post->ID, array( 180, 180 ) );
      ?>
      

      I tried the_post_thumbnail() and that didn’t work either.

      I just want to disable the new “srcset” tag in my code to get my images to display again!

      • Joe McGill 8:53 pm on December 11, 2015 Permalink | Log in to Reply

        Hi Tim, the easiest way to disable responsive images on your site is to add this code snippet to your functions.php or better yet through a separate plugin file.


        function disable_srcset( $sources ) {
        return false;
        }
        add_filter( 'wp_calculate_image_srcset', 'disable_srcset' );

        However, if your images aren’t displaying because of HTTPS mixed content issues, than you may want to keep an eye on this thread.

    • Bielousov 8:42 pm on December 11, 2015 Permalink | Log in to Reply

      I actually hope this doesn’t work, for I had to create a front-end analog to dynamically add srcset with respect to retina display, not just screen size and really really hope it won’t break with this new update.
      Nice try though WordPress, I was looking for this some time ago, but too late.

    • SnixyKitchen 3:08 am on December 14, 2015 Permalink | Log in to Reply

      I’m super excited about this update because I’ve been inserting images that are 2x the display width to optimize for retina, which is surely slowing down my site on other non-retina screens. One issue I’ve noticed though is that on iphone retina screens, it’s choosing a really low resolution image from the srcset making all the images SUPER blurry! Does anyone know why this is happening? Or is there a way to set a min size to include in srcset so it doesn’t have this one as an optin??

      • Joe McGill 1:11 pm on January 20, 2016 Permalink | Log in to Reply

        Hi SnixyKitchen,

        iPhones still on iOS8 suffer from a Safari bug that always chooses the first source in the `srcset` attribute. My advice would be do add the Picturefill polyfill for responsive images in order to fix this issue.

    • greenzilla 6:42 pm on December 17, 2015 Permalink | Log in to Reply

      I came across an issue where I would want to limit the srcset max width based on the images placement. IE: I don’t want a 100px w image placement to be able to grab a 300px w image. I would want to limit the srcset to a 200px w image. My phone (Droid Turbo 2) is pulling the 300px w image while the iphone 6 is pulling the 200px w image and desktop is grabbing the 100px image. My reasons to limit to 200px w is it looks ‘good enough’ and to save on bandwidth and decrease load times. This is where the invaluable ‘max_srcset_image_width’ filter comes into play. I can take the $size_array parameter and calculate ‘max_srcset_image_width’ for the desired image placement. Hopefully others will find this useful.

    • rcgordon 1:34 am on December 19, 2015 Permalink | Log in to Reply

      The responsive images break some posts on the iPad on http://www.theshelterblog.com. I lauded the Disable Responsive Images plug-in to stop it. One specific post that was showing a thumbnail image on iPad (either portrait or landscape) is http://www.theshelterblog.com/18-year-old-builds-debt-free-tiny-house-as-school-project/.

      The impacted image was only obtainable in a medium size (662×424).

    • donaldG2 4:01 pm on December 21, 2015 Permalink | Log in to Reply

      I for one am so incredibly stoked to have this as part of core! I do have a quick question: will the polyfill script ever be included in core? I can see how you’d want to leave that up to the different users depending on their needs instead of including one.more.script, ha. I was a bit confused until finding this thread, thinking that picturefill.js had been included but glad to have discovered the thread. Many thanks!

      • Joe McGill 1:15 pm on January 20, 2016 Permalink | Log in to Reply

        Hi Donald,

        We’re not planning to include the polyfill in core since many people prefer to be in control of their own front-end javascript dependencies. However, if your not able to add it to your theme yourself, you can install the RICG Responsive Images plugin, which still includes the polyfill.

    • chatmandesign 8:19 pm on December 23, 2015 Permalink | Log in to Reply

      Is there a filter to change the src attribute? I want to support retina, but I don’t want to fallback to an image that big for browsers that don’t support responsive images, so I’d like to override the src to a more middle-size image (say, targeted at 1366w).

    • thinkwired 12:23 am on December 29, 2015 Permalink | Log in to Reply

      I am seeing posts where some images have the additional srcset markup but other images do not (on the same post/page). These images were uploaded at the same time and all of them have various sizes in the upload folder. What would cause some images to display the responsive markup but, others not? I’m trying to diagnose the issue to no avail.

    • vovkasolovev 8:43 pm on January 19, 2016 Permalink | Log in to Reply

      Oh… I got two problems with this update. I already implement responsive images in my theme myself with default Large size. My Large size width 975px, and I don’t need Medium_large. Also, after update checking for original image size is broken now.

      Example:
      In UI Large image set to 975 and 0. Uploading image.jpg with 975px width and 731px height:
      Before 4.4 update: WordPress upload it as image.jpg (without additional Large image size).
      After 4.4 update: WordPress upload it as image.jpg, create Large image-975×731.jpg and Medium_large image-768×576.jpg. So I got 2 similar files and one almost similar in Uploads.

      How to change default medium_large size to 975px in functions.php?
      How to prevent WordPress to generate image with exact similar image size?
      Please, help, there no examples in docs right now.

      • Joe McGill 1:09 pm on January 20, 2016 Permalink | Log in to Reply

        Hi vovkasolvev,

        Sounds like you’re suffering from a known bug with image sizes (see: #32437). Here’s a good example of how to enforce image default image sizes from your functions file.

        • vovkasolovev 3:02 am on January 21, 2016 Permalink | Log in to Reply

          Thank you! You right, this is exactly that bug.
          I will try method you suggest.

        • papijo 10:41 am on January 26, 2016 Permalink | Log in to Reply

          Hi Joe,

          I also suffer from that problem. Most of the images I upload to my wp site are 1024px wide. Upon uploading, my original images are “re-sized” to 1024px wide, thus creating useless duplicates.
          1.- Workaround: in Settings->Media->Large size replace the default 1024×1024 with 1025×1025.
          2.- It works, but a side effect is that now the newly introduced medium_large size (768px wide) is no longer generated upon uploading images.
          3.- And even if I revert Settings->Media->Large size to the default 1024×1024, still no medium_large size is generated! Is there a way to reset the Media settings?

          4.- It should be relatively easy and very useful to fix this bug as reported in https://core.trac.wordpress.org/ticket/32437. I will post to that ticket soon.

          • papijo 10:30 am on January 30, 2016 Permalink | Log in to Reply

            Further to my previous post, can anyone confirm my findings about the Settings>Media behaviour? If one changes ANY of the size settings, this will remove the generation of the new “medium_large” size files when uploading image files. And there seems to be no way to reset this!

    • Kerrie Redgate 1:38 am on January 23, 2016 Permalink | Log in to Reply

      This is terrible! I don’t have time for this, with 5 sites to maintain. Some of my major images are fuzzy now on retina screens. When I remove the dimensions that I had carefully planned to work well on all devices, the image is too large on normal screens and shrinks to a third of its size into a corner on retina screens. Why has WordPress done this? This is a major headache!

    • richarduk 1:19 pm on January 31, 2016 Permalink | Log in to Reply

      Although I’m getting srcset for images in posts, the header image uploaded through the media uploader and output using header_image () has no srcset. Is there a likely reason for this?

    • Martin999 3:21 pm on January 31, 2016 Permalink | Log in to Reply

      Hi Joe,
      at the moment I still use WP 4.3.2 for my site. It has a lot of relatively small images between 100 and 250 px width. They are perfect for non-mobile devices and become responsive by CSS (max-width: 100%; height: auto;) without any visible loss of quality. EACH IMAGE ONLY EXISTS ONCE, IN ONE SIZE.

      When installing WP I disabled cropping in media settings and also set all sizes there to “0”. Therefore WP didn’t generate additional images for different sizes when uploading an image. When uploading an image I choosed “link image: none” and “size: full size”

      I have two questions:
      1. Will the new responsive image feature “take” my images and give them srcset and size attributes, though there are no different image sizes in media library, due to my upload and media settings?

      2. What is the official recommended code for my functions.php to disable the new responsive feature of WP? Searching the web I find several codes, partly different ones. I’m mot a coder, just a webmaster.

      Thanks!

      • Joe McGill 4:11 am on February 3, 2016 Permalink | Log in to Reply

        Hi Martin,

        1. The responsive image functionality relies on the existence of the different image sizes created when your image is uploaded. If no extra sizes are created, `srcset` attributes won’t be added.

        2. The easiest way to disable the feature if you absolutely need to is to install this plugin: https://wordpress.org/plugins/disable-responsive-images/.

        • Martin999 4:30 pm on February 3, 2016 Permalink | Log in to Reply

          Hi Joe,
          thanks for your fast answer.

          I guess the plugin uses the same code you mentioned here (sorry, overlooked it).

          Btw, searching the web I found several dissenting comments about the new responsive feature taking also action on already existing images (with different sizes in media library).

          Could you please explain, what “already existing image” exactly means? Will images become responsive which were inserted in a post/page before WP-Update to 4.4? If not, what happens when editing the post/page (with image in it) and saving? Will it then become responsive, providing that the media library has several image sizes?

    • adijeff 5:14 pm on February 2, 2016 Permalink | Log in to Reply

      Having upgraded to WP 4.4 I have disabled the PB Responsive Images plugin I was using, but I’ve got a problem with many images in my posts that are missing a wp-image-XXX class. This class appears to be what makes the images responsive. Is there a way to fix these images without me having to go through hundreds of images? Thanks

      • Joe McGill 4:16 am on February 3, 2016 Permalink | Log in to Reply

        Hi adijef,

        Unfortunately, there’s not an easy solution that lets you add the ID class back to the image markup in your plugin. You could probably come up with a way to do a reverse lookup on each image URL to get the image ID and add the markup back to your posts, but that’ll take a bit of scripting.

    • g-niloo 2:10 pm on February 4, 2016 Permalink | Log in to Reply

      Actually I don’t really like the idea of 768px default width. All my high resolution images are saved with that width and have a terrible quality, unless they’re opened in another tab. What should I do to show the original image quality and save the original image from posts like before? I always add images with their original size and then for high resolution ones I resize them to 565px width and had no problem saving them with original quality!

    • TraciBunkers 7:45 pm on February 10, 2016 Permalink | Log in to Reply

      I just updated my wordpress, and now my images that are on Amazon S3 that are served through cloudfront don’t work. It’s not an issue of http/https for me. I had to add the code to my theme’s functions.php file to disable the srcset that I got from here: http://wordpress.stackexchange.com/questions/211375/how-do-i-disable-responsive-images-in-wp-4-4/211376#211376

  • Andrew Ozz 4:31 pm on October 14, 2015 Permalink |
    Tags: , ,   

    Shortcodes roadmap — clarifications 

    As mentioned in the initial shortcodes roadmap post, the main purpose of this roadmap is to find the best way for improving the shortcodes API and moving it forward. Currently it is slow, fragile, and attempts to handle a lot of edge cases. For this, the most important part is:

    • No shortcodes in HTML tags attributes.
    • No HTML in shortcodes attributes.

    There are a few things that deserve to be clarified. Simple shortcodes are great. They are easy to understand and be typed directly by the users. Example: [gallery].

    Unfortunately many plugins add complex shortcodes with many attributes and often with nested shortcodes. These are a nightmare for the users. They are not intended be typed directly and can be edited by some sort of UI. Using shortcodes to store this type of data in post_content is not a good idea. Since there is a UI for entering and editing, it would be better to use a simple shortcode to “hold the place”, and save all the data in post meta.

    Many of these complex shortcodes also include HTML tags in their attributes. To keep that functionality, the second roadmap draft proposed an extended syntax that allows the shortcodes “content” (the text wrapped by [shortcode] and [/shortcode]) to be additionally separated by delimiters. That would allow for shortcode attributes to contain HTML tags that are stored in the shortcode content.

    These delimiters are not intended to be typed directly by the users. They are intended for the plugins that have shortcode editing UI and cannot function without storing HTML in shortcode attributes.

    At first look this makes the syntax needlessly complex. However after looking at how complex shortcodes are used now, it is relatively the same: these shortcodes cannot be typed directly and are useless without some sort of UI.

    There have been questions about line breaks in shortcode content. It is possible to add support for this. However it will benefit only a very small amount of users. Since shortcodes “live” in HTML context, and line breaks are ignored there, typing in the Text editor and switching to the Visual editor will remove all line breaks. Typing in the Visual editor will add paragraph tags. So only users that never use the Visual editor and have to type long, complex shortcodes will see some benefit.

    The Shortcode API Roadmap meeting is in #feature-shortcode today at 17z, which is 2015-10-14 1700.

     
    • FolioVision 5:39 pm on October 16, 2015 Permalink | Log in to Reply

      This is a great summary Andrew.

      I’d say we should keep the simplest shortcode syntax possible even if it means that some plugins can no longer freestyle with shortcodes. John Godley wrote software years ago called Sniplets which is meant to allow developers to call PHP inside posts.

      Horses for courses. Shortcodes should not be Sniplets but relatively simple syntax. Certainly without html elements inside.

      Why not deprecate complex shortcodes now with removal in 4.6? That gives us developers lots of time to comply and adapt without making WordPress core software more complex (worse).

    • Jon Brown 11:07 pm on October 18, 2015 Permalink | Log in to Reply

      This is a great summary.

      I’ve mentioned many time over the years, without anyone seeming to think it was the great idea I do that there should be some sort of “smart image/media object”. My reasoning is I’ve long wanted a way in which images could be inserted in posts such that processing could occur at the time of page render. The major use case for me being wanting to insert an image that could call in media metadata (copyright, etc..) and have the meta data updatableble in the DB and then automagically update on page render, rather than hard coded in a short code (ie. gallery/caption). It seems however that this sort of things might also be useful for responsive images (RICG) that could literally point to a single database entry, but later at the time of page render be updated according the current theme settings, etc…

      Perhaps the way forward is an alternative “smart/advanced shortcode”. One which only inserted and manipulated through an advanced UI. The standard current short code could than be kept simple, with the few plugins that currently need advanced functionality moving forward.

      At the same time, perhaps this would be of help to RICG and others?

    • maxwelton 12:57 am on October 20, 2015 Permalink | Log in to Reply

      My initial thought (as someone who writes a lot of “one off” plugins to suit particular clients, some of which have long lists of configurable options per post) is wouldn’t it be nice if a user could:

      • Use a button next to the media gallery button to open a dialog where they can choose from a “nice names” list of registered shortcodes, and insert one of their choice
      • If that inserted shortcode has required parameters, a box similar to the “edit image” box opens automatically. This box is essentially a metabox containing fields defined by the developer in the same way a regular metabox would be added to a post, obviously on a special hook or filter…
      • User fills in their choices and clicks ok.
      • In the visual editor, shortcodes with parameters get an edit icon within their shortcode (or the entire shortcode is “hot” or an icon, and not discretely editable), which opens the parameters box again.
      • In the text editor, each shortcode with parameters will be shown with some sort of ID string matching the auto-generated ID (“gallery-7” or whatever) WP created when the shortcode was inserted. Using this ID allows users to find said metabox in a section below the editor (hidden in visual mode?), or perhaps the shortcode selection dialog can show both a list of available shortcodes and a list of those embedded in-page; clicking on the in-page ones opens the parameters dialog for that shortcode. Clicking on “delete” in the parameters box removes the shortcode from the editor (easy enough to say…)

      This would make the editor a lot cleaner and allow for complex parameters to be passed to the shortcode, including HTML markup, images via gallery dialogs, etc., etc.

      The shortcode handling function is passed the custom ID WP generated, which the function uses to retrieve the parameters from postmeta (I’m imaging core saving the contents of the parameters metabox to a single custom field with the same ID referenced above, as a serialized array).

      Obvious questions include “what happens when you delete a shortcode with opening and closing codes AND nested shortcodes?” and “what happens when a user in text mode alters a shortcode manually and it no longer meets the criteria for being “savable” (ie, either a shortcode which has no required parameters or one whose internal ID matches a metabox with those values filled in).

      Anyway, I might try this approach for my next complex plugin, if time allows, just to see if its workable.

    • Tom Belknap 7:46 pm on December 15, 2015 Permalink | Log in to Reply

      Just wanting a clarification: are we looking to end the practice of nesting shortcodes? Because I’ve found shortcodes to be helpful with creating blocks of post_content HTML without using actual HTML in the Editor screen. For example, I use custom shortcodes to create Zurb Foundation grid blocks within content.

      I’d hate to have to lose such functionalty. It allows me to create much more robust layouts simply. No, as Ozz points out, they’re definitely not for end users. But given how much of the Internet is powered by WordPress, I’d hate to think that we’re limiting ourselves unnecessarily?

  • Daniel Bachhuber 7:42 pm on October 5, 2015 Permalink
    Tags: , , , , ,   

    Shortcake (Shortcode UI) chat summary – October 5th, 2015 

    Present: @danielbachhuber, @goldenapples, @matth_eu

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

    • Matt’s making process on support for encoding HTML in attributes. Gallery functionality is also almost done, but there’s one small bug.
    • Than started work on trying to add some filters that can be used to handle floated/non-block previews. It still some work to go, as it’ll involve overriding some methods deep in mce.view.
    • Daniel will hit up the backlog when he has a moment, as there are a number of unanswered open issues.
    • We discussed inline editing and agreed upon an ideal abstraction .

    Next chat: same time and place

    Next release: v0.6.0 – Tuesday, November 3rd

     
  • Pascal Birchler 3:32 pm on September 28, 2015 Permalink
    Tags: , , ,   

    oEmbed Update: September 28th 

    As of today, the current version of the oEmbed feature plugin is 0.9.0. These are the biggest changes since last week:

    • There is now an is_embed conditional tag to more easily target embedded posts.
    • New: Support for embedding video and audio attachments.
    • You can now copy the whole embed code and not only the post’s URL in the sharing dialog.
    • There were major JavaScript improvements. It is more robust and also a bit faster too.
    • We now show a read more link instead of the word count in the excerpt.
    • Improved input sanitization.

    These were all areas discussed in last week’s chat and I’m happy with what we achieved. The plugin has been installed on WordPress.com, although it has been temporarily deactivated 🙁. Nonetheless I’m looking forward to publishing another post regarding the plugin tomorrow…

    There are only some smaller issues left, so now is a great time to test and review the plugin! Our weekly chat is today (September 28 2015 9pm UTC) in the #feature-oembed Slack channel

    Note: We received some feedback regarding weird link previews in Slack for WordPress.org links. This is a Slack bug and not our fault. We already reached out to them and hope it gets fixed soon.

    As always, the latest version of the plugin is available on the plugin repository. Errors and suggestions can be either reported on GitHub or our #feature-oembed Slack channel.

    Next chat: October 5 2015 9pm UTC

     
    • Scott Taylor 4:22 pm on September 28, 2015 Permalink | Log in to Reply

      Really cool – thanks for all of the great work!

    • Adam Silverstein 5:09 pm on September 28, 2015 Permalink | Log in to Reply

      This is a really fun & great feature, nice work!

    • Rami Yushuvaev 8:10 pm on September 28, 2015 Permalink | Log in to Reply

      @swissspidy, Can I embed attachments? Images, PDF files, and other file formats?

      • Pascal Birchler 8:54 pm on September 28, 2015 Permalink | Log in to Reply

        This feature is about embedding WordPress attachments on other sites. Media you upload to WordPress, like images, video, and audio. There is no PDF viewer in WordPress, so there is no PDF viewer in the embed.

        • Rami Yushuvaev 8:58 pm on September 28, 2015 Permalink | Log in to Reply

          What about images? can i embed attached images? if I paste the attachment URL on external site?

          • Pascal Birchler 7:36 am on September 29, 2015 Permalink | Log in to Reply

            > What about images? can i embed attached images? if I paste the attachment URL on external site?

            Yes, if that site has the plugin installed or you use the full embed code. I recommend trying it out to see what is currently possible.

    • funkygorilla 11:02 pm on January 19, 2016 Permalink | Log in to Reply

      Hi, I am loving oEmbed for a client site. They find each much easier to link across from another page on there site using a link or multiple links rather than me having to include a custom field. One thing I am puzzling over. I really want to not include .wp-embed-footer as this is on the same site, so the link isn’t really relevant. You mentioned customisation of the footer but I can’t find anything on how you actually do that. Do you have any documentation you can point me to?

  • Robert Chapin 4:18 am on September 4, 2015 Permalink
    Tags: , ,   

    Shortcode Roadmap Extended Discussion 

    We saw a great amount of feedback on the first draft of the Shortcode API Roadmap.  The resounding concensus was that the shortcode syntax we already know and love should not be replaced.

    Now we need to bring that enthusiasm and more feedback to the first official meeting to help create a second draft of the roadmap.

    On Wednesday at 17Z, which is 9 Sep 2015 17:00.

    It is scheduled in the #feature-shortcode channel.

    In case you can’t make it to the meeting, here are some of the items up for discussion.

    Parser Problems

    The biggest issue with keeping the BBCode style syntax is that we don’t have a scalable way to make these shortcodes work in PCRE.  The current pattern searches for all registered shortcodes by name, because searching for matching pairs of braces leads to backtrack limitations and segfaults.  If someone has an idea or knows a good library, now is the time to tell us!  With that said, we are also bringing some new proposals of our own.  One theoretical solution should make it possible to preview the first word of each shortcode tag so that the full search pattern then only includes the names of shortcodes already found in the input, rather than the names of all registered shortcodes.  This is the best idea so far and could be easy to implement.

    HTML vs. Shortcode Syntax

    We still want to expand the shortcode syntax to allow multiple enclosures.  So which new tags would work best internally and still look nice for users?  We are now thinking something more like this:

    [shortcode] HTML [=part2=] HTML [/shortcode]

    Let’s also have a brief discussion about preparing for the eventual removal of HTML-in-shortcodes and shortcodes-in-HTML combinations. As we saw in 4.2.3, it is better to plan for this rather than allowing it to become an urgent surprise update.

    Version Issues and Breaking Things

    We still need to plan out a change of filter priorities so that shortcodes will be processed first, before paragraphs and curly quotes. How much impact will this have on plugins now that we will be changing the way existing shortcodes work instead of adding a whole new system? Is it adequate to offer paragraphs and curly quotes as an opt-in only feature?

    Will we need weekly meetings after this first one?

    Are there other tickets or features, such as nested shortcodes, that need to be roadmapped?

     
    • leehodson 5:33 am on September 4, 2015 Permalink | Log in to Reply

      Two ideas:

      Backwards Compatibility

      a) WordPress records page creation dates and page update times. Leave the existing parser, though deprecated, to parse shortcodes in any content that was last updated before the new parser’s release.

      b) Deter use of the old style shortcode syntax by displaying a popup warning (or by highlighting text) in the content editor when old style tags are suspected of being added to new content or when old content is updated. This would double as a public information notice to alert editors to the new shortcode syntax.

      c) Provide a plugin to detect known old shortcodes and suspected unknown shortcodes. Editors and admins can then manually update them to the new syntax or risk automatic update. I guess a ‘shortcode updated’ flag could be added to page metadata to determine use of the new shortcode parser.

      New Syntax

      Yesterday I suggested back-to-back square brackets e.g [ and this ] used together like this [] be used as the new shortcode delimiter. This is easy to remember, easy to look at and shouldn’t cause too much damage to content readability wherever single brackets that are used to encase regular text are automatically converted erroneously into the new shortcode delimiter syntax.

      Self closing (two forward slashes at the end)

      []tag[//]

      Encasing (single forward slash)

      []tag[/] content [/]tag[]

      Nested

      []tag[/] content [] nested self closing [//] more content [/]tag[]

      []tag[/] [] nested self closing [//] [/]tag[]

      Question:

      What if a maximum tag name length were introduced? That should help reduce work performed by the new parser.

      • chriscct7 6:34 am on September 4, 2015 Permalink | Log in to Reply

        Under the back the drawing board discussions, a new syntax isn’t needed, except where HTML is in shortcode attributes which will use the multiple enclosers to continue being able to take in HTML via shortcodes as shown above. The consensus of Draft 1 was if at all possible not to replace the new syntax

      • kjbenk 4:43 pm on September 4, 2015 Permalink | Log in to Reply

        I love the idea of creating a new plugin that will notify site owners that there post contains deprecated shortcode tags and what also what posts they are. Would you consider developing this / would you want some help?

        • leehodson 8:59 pm on September 5, 2015 Permalink | Log in to Reply

          Please do run with it. I have little free time at the minute but I’m happy for you to build the idea into a plugin.

          I’m surprised WordPress doesn’t yet have a compatibility settings page for enabling / disabling deprecated features. Would make it easier to manage backwards compatibility and allow faster evolution of WP core.

    • Weston Ruter 6:02 am on September 4, 2015 Permalink | Log in to Reply

      The biggest issue with keeping the BBCode style syntax is that we don’t have a scalable way to make these shortcodes work in PCRE.

      Maybe we’re doing it wrong by using regular expressions in the first place. If regular expressions shouldn’t be used to parse [X]HTML, per the famous stackoverflow answer, should they be used to parse shortcodes either? HTML with shortcodes is not a regular language but a context-free one (ish).

      What if instead of using regular expressions we used PHP’s own HTML parser in DOMDocument This would, nevertheless, require an initial regular expression replacement to convert shortcodes into HTML tag syntax. The add_shortcode() function would also need to allow shortcodes to be registered indicating whether they are empty or not.

      So then take a look at this gist which has a proof of concept for the initial parse of the post_content containing raw shortcodes: https://gist.github.com/westonruter/27307ea745701b6abf88

      So then you’d have a DOMDocument with span[data-shortcode] elements which could then be traversed over the DOM tree and for each element, starting with the inner-most nested (depth-first), it could send the content off to the shortcode handler and then the response could then replace that DOMElement. The tree walker would then step up the tree and handle any shortcode that wrapped that shortcode, also replacing that placeholder span element with the output from the shortcode handler.

      I note some dovetailing here between shortcodes and Web Components.

      • Nick Haskins 11:49 am on September 4, 2015 Permalink | Log in to Reply

        This was my initial thought as well after reading todays post. It seems to me that finding a better way to parse would be far more easier, and a lot less time consuming vs introducing new syntax, educating, rewriting docs, and dealing with the fallout from such a large change.

      • Robert Chapin 12:29 pm on September 4, 2015 Permalink | Log in to Reply

        If we have reasonable benchmarks and some way to roadmap this after disallowing the HTML/shortcode combinations, then yes. So, my main concerns are whether it runs as fast as PCRE, and that we can’t convert shortcodes to HTML placeholders in the current system. Also, the “initial regular expression replacement to convert shortcodes into HTML” implies a strange level of redundancy. If we are parsing by PCRE then what’s the point of the conversion?

    • Pascal Birchler 8:37 am on September 4, 2015 Permalink | Log in to Reply

      As per this comment by nacin, I’d love to see this happening with the updated shortcode system:

      (Random thought, if anyone wants to have some fun, we should rewrite the API to use hooks under the hood, and ditch $shortcode_tags. And then break everyone reaching directly into $shortcode_tags.)

    • Greg Ross 1:28 pm on September 4, 2015 Permalink | Log in to Reply

      Parser Problems:

      I agree with @WestonRuter, PCRE is probably not be the solution to parsing shortcodes. However if there is still a desire to use them and a need to make them unique, perhaps something like:

      `[wp] html [/wp]` or `[sc] html [/sc]`

      makes more sense than some of the current complex proposals.

      Just to make it clear, I’m still all for keeping the current syntax.

      HTML vs. Shortcode Syntax

      Here’s a question, why do you want to expand the syntax to include multiple enclosures? What problem are you trying to solve?

      The most obvious one would be using that syntax as a type of if/else to conditionally display content. It would seem to make more sense to wrap the content in divs with classes and then conditionally set the class styles to display/hide them.

      Is there a better way than multiple enclosures to solve the problem?

      If that is still the way to go, perhaps a syntax like:

      `[shortcode] HTML [\part2] HTML [/shortcode]` or `[shortcode] HTML [part2 \] HTML [/shortcode]`

      (I like the flow of the first better but the second is more consistent)

      Version Issues and Breaking Things

      If it comes down to not being able to fix the real issues with shortcodes while maintaining the current syntax without breaking the old shortcodes, I would be in favour of using a new syntax rather than break the old shortcodes.

      Shortcodes are embedded in far too much content to break without giving users lots of time to address it.

      This would seem to be a great use of the feature plugin system to flesh out what a new shortcode system would look like and what impacts it would have on sites.

      Here’s what I’d suggest, WP 4.4 should include enough hooks in the shortcode parser to allow for a plugin to completely replace it (maybe it already does, haven’t dug that deep in to it).

      Then a new feature plugin is created to start working out the technical implementation of the new shortcode system. One of the core tenants of the plugin must be that it doesn’t break the old shortcodes. Either by using the same syntax and just extending it or by using a new syntax altogether.

      Once the plugin is mature, merge it in to core.

      If a new syntax for shortcodes is used, start alerting users as they edit content and use the old syntax of the new syntax.

      Then, at some point in the future, a discussion can be had about when or if the old syntax should be deprecated.

    • chatmandesign 2:57 pm on September 4, 2015 Permalink | Log in to Reply

      If there’s value to distinguishing between self-closing shortcodes and shortcodes that contain other content, I think it would make sense to simply mimic XML syntax:

      [gallery/]

      This is a pretty small change that could be introduced as the strongly preferred syntax for self-closing tags, without necessarily eliminating support for the old style tags at all. Perhaps a very lightweight function could sweep through and handle all of these first, if that would cut back on the amount of work a beefier routine needs to perform. Just a thought, since the original proposal suggested it would be valuable to distinguish self-closing shortcodes.

      • Robert Chapin 7:57 pm on September 4, 2015 Permalink | Log in to Reply

        This already exists actually. Nobody uses it. 🙂 Kind of a moot point but I think this feature was not implemented correctly and now we are stuck with it.

    • Mark Root-Wiley 4:12 pm on September 4, 2015 Permalink | Log in to Reply

      A lot of this parsing stuff is over my head, but two ideas that I’ll throw out (and which probably won’t work, but what the heck):

      • What about as a new syntax? stuff for the unclosing variety. It’s fairly unique, similar to the old, and even subtly discourages nesting within html. I even wonder if this would be easier to work with if you move toward a different parser that likes HTML. This would also presumably mean broken shortcodes don’t get displayed on the front end (although I suppose the editor would escape those angle brackets?). This probably doesn’t work…
      • Also wonder if it would be possible to add a prefix to all shortcode tags as part of a solution, so [my-shortcode] has to become [wp-my-shortcode] or [shortcode-my-shortcode] or [wpsc-my-shortcode]
    • PhilipBarrington 5:55 am on September 5, 2015 Permalink | Log in to Reply

      Perhaps a lot would be less traumatic if there was a button on the TinyMCE panel that allowed you to insert shortcode and handled the code, whatever you decide it is going to be. Given the proliferation of shortcode in wordpress and plugins I suspect there needs to be a longer lead time. Part of me suspects that it is a little like replacing the car because the ash tray is full. I admit I don;t understand the problem.

    • Ipstenu (Mika Epstein) 4:37 am on September 6, 2015 Permalink | Log in to Reply

      Normally I’d just make my own blog post, this is long, but I think it’s appropriate here. Thank you again, Robert, for starting this discussion!

      Parser Problems

      PCRE stands for Perl Compatible Regular Expressions – Regular expressions is how we pattern search in code. (Not everyone knows all the jargon, don’t feel bad if you didn’t).

      Parser issues are huge. Yes. They’ve always been a mess. If you want to have a look at how messy, here’s https://wordpress.org/plugins/shortcode-reference/ – this will list all your shortcodes and may help some of us visualize the issue differently.

      We’re parsing to ‘detect’ shortcodes, though, correct? I suppose it would be too much to ask to have the API add it to an option in wp_options so all registered shortcodes are listed? And then that list is parsed before content is output? My gut suggests that would slow things down, especially on long posts, but SQL like that is my third weakest wheelhouse with WP.

      HTML vs. Shortcode Syntax

      I think I know what we’re addressing, but we should perhaps break down what we have shortcodes for today:

      1. No-option shortcodes [button] or – These have no input, we just toss it in and it works.
      2. Some options – These have limited input, maybe a URL or a size variable.
      3. Shortcodes as design elements (too complex to show) – These are the ones with HTML etc in them.

      The issue is not 1 or 2. Those are necessary evils right now when it comes to things like Multisite where we cannot insert iframes etc, and where embeds are sadly not appropriate. Also a shortcode should continue to work, even if I flip back and forth between GUI and HTML editors. In as far as that goes, the absolute death of shortcodes by firing them into the sun will always be stopped because TinyMCE eats HTML. I admit it makes me wonder why/how/what people are doing with these HTML-using shortcodes…

      Actually that’s a good point. Does someone have a really good example of a shortcode doing it ‘wrong’? Crafting a new API roadmap without every being on the same page as to what’s ‘intended’ and what was ‘wow, what are you doing?’ is bound to make a conversation go in circles.

      At its heart, and I know many of my peers detest shortcodes, they are perfect for what they were meant to be. Small, simple, easy to use short codes to insert content that would either be massively complex otherwise (gallery), impossible (embeds in a pre auto-embed world, iframes), or annoyingly repetitive. They do work quite well for that.

      The shift of short-code-for-design is where, I think, much of this has come up.

      Version Issues and Breaking Things

      We absolutely cannot use curly’s. That would kill 40% of the user base (if Nacin’s tweeted stats of non-English users is accurate). They don’t have easy access to them, and right now I feel like I should send cookies to all the coders who don’t have English keyboards.

      Breaking things is also something I have admittedly strong opinions on. We’ve been doing this too much, and we need to stop. Shortcodes are so wildly used, this is something I fear could break WordPress and chase off users for simpler platforms that are more restrictive. I know, we painted ourselves into a corner here and in the fight of ‘break vs secure’ I am a firm ‘Be more secure!’ proponent, but we saw the tip of the iceberg.

      That’s kind of why I would love to see a few examples of plugins we’re pretty darn sure WILL break. Let’s get a real world idea of who we’re going to destroy and maybe we can do something about it? I feel like we’re guessing, and I’m a little uncomfortable.

      I don’t want to name names like ‘you were wrong!’ just ‘You’re the wild west, now let’s see what you did so we can try to fix it!’ So I really hope everyone understands that one… It’s a hard thing to ask 🙁

    • bonger 10:09 pm on September 8, 2015 Permalink | Log in to Reply

      I think the pre-processor filter idea that’s been floating around that replaces stuff with numbered placeholders (same idea as the pre tag replacer at the start of wpautop()) could be the way to go to alleviate a lot of the parsing and other problems.

      For shortcodes it could use the full get_shortcode_regex() (with the first-word improvement) to parse all shortcodes and replace them with placeholders, eg “[shortcode_name n]”, where n is a unique number (I think this makes more sense than a HTML placeholder). This then makes parsing by filters down the line much more straightforward. It also eliminates the need for the current and planned restrictions on HTML input in shortcodes, restoring backwards compatibility (though this appears to be a contentious issue so I could be missing something here).

      The shortcode pre-processor could also restore the left-to-right processing of shortcodes by parsing for tags containing shortcode placeholders and replacing them in turn with placeholders, enabling them to be processed in-line by do_shortcode_tag() for KSES security. I’ve a prototype of this which I’ll post to the ticket https://core.trac.wordpress.org/ticket/33134 as a demonstration.

      Using the same structure other pre-processor filters could also be added, eg to replace HTML comments with placeholders (““), and then to replace blob-like tags (script/style/object etc) with comment-like placeholders (““) etc, simplifying the parsing (and lessening the intrusion in the case of wpautop()) for filters down the line.

      This still leaves the initial get_shortcode_regex() parsing issue, but the first-word search looks like a great improvement. Also for large alternations trie optimizations might be worth doing, as implemented by eg http://search.cpan.org/~dankogai/Regexp-Optimizer-0.15/lib/Regexp/Optimizer.pm (in Perl). Lots of plugins use prefixes to namespace their shortcodes so it could be a big win. Or not.

      The HTML parameter syntax looks good. Would the parts be named and passed through the atts array, eg “[=param1=]”? Could they be optionally introduced by the shortcode name, eg “[=shortcode param1=]”? (Verbose, but might be useful for nesting. Or not.)

      • bonger 10:12 pm on September 8, 2015 Permalink | Log in to Reply

        Sigh.

        I think the pre-processor filter idea that’s been floating around that replaces stuff with numbered placeholders (same idea as the pre tag replacer at the start of wpautop()) could be the way to go to alleviate a lot of the parsing and other problems.

        For shortcodes it could use the full get_shortcode_regex() (with the first-word improvement) to parse all shortcodes and replace them with placeholders, eg “[shortcode_name n]”, where n is a unique number (I think this makes more sense than a HTML placeholder). This then makes parsing by filters down the line much more straightforward. It also eliminates the need for the current and planned restrictions on HTML input in shortcodes, restoring backwards compatibility (though this appears to be a contentious issue so I could be missing something here).

        The shortcode pre-processor could also restore the left-to-right processing of shortcodes by parsing for tags containing shortcode placeholders and replacing them in turn with placeholders, enabling them to be processed in-line by do_shortcode_tag() for KSES security. I’ve a prototype of this which I’ll post to the ticket https://core.trac.wordpress.org/ticket/33134 as a demonstration.

        Using the same structure other pre-processor filters could also be added, eg to replace HTML comments with placeholders, and then to replace blob-like tags (script/style/object etc) with comment-like placeholders etc, simplifying the parsing (and lessening the intrusion in the case of wpautop()) for filters down the line.

        This still leaves the initial get_shortcode_regex() parsing issue, but the first-word search looks like a great improvement. Also for large alternations trie optimizations might be worth doing, as implemented by eg http://search.cpan.org/~dankogai/Regexp-Optimizer-0.15/lib/Regexp/Optimizer.pm (in Perl). Lots of plugins use prefixes to namespace their shortcodes so it could be a big win. Or not.

        The HTML parameter syntax looks good. Would the parts be named and passed through the atts array, eg “[=param1=]”? Could they be optionally introduced by the shortcode name, eg “[=shortcode param1=]”? (Verbose, but might be useful for nesting

    • bobbingwide 10:26 am on September 9, 2015 Permalink | Log in to Reply

      I’ve written a summary of my requirements for shortcode syntax, formatting and editing here

      http://www.oik-plugins.com/2015/09/shortcodes-requirements-for-input-editing-and-formatting/

      Please take these into account later today.

      Here’s a brief summary of my responses to the Extended discussion items above.

      If PCRE doesn’t satisfy the requirements don’t use it.

      First you have to document all the sensible ways that square brackets might be included in content and then decide a strategy for determining whether or not the stuff that follows is expected to be treated as a shortcode.

      Removing stuff – don’t do it; be really, really open about the security issues.

      Consider the usefulness or otherwise of the space character.

      Paragraphs and curly quotes and all other manner of strange filters should be revisited
      along with preventing the Visual editor from messing with my beautifully hand crafted content.

    • Jacob N. Breetvelt 9:03 am on September 10, 2015 Permalink | Log in to Reply

      Changing shortcode priority so that formatting is done after shortcode processing will be disastrous for my plugin wp photo album plus. I woulod rather see a possibility to add the priority as an option to add_shortcode(). Many plugins and themes run content filters that destroy the html generated by my plugin. An example here: https://wordpress.org/support/topic/first-image-of-gallery-not-aligned-with-rest?replies=6 where a content filter ‘my_formatter’ adds empty p tags in the midlle of my code. Running a slideshow on this site will copletely crash. Many times i was confronted with inline script function calls with completely damaged arguments, all due to formatting ( i.e. destructing ) content filters run with an higher priority than the do_shortcode priority.

      Changing the default priority of do_shortcode to be before formatting filters, without the possiblity of the proposed addition to do_shortcode might result in me quitting the wordpress development.
      PLEASE DO NOT DO THIS!!!

    • Jacob N. Breetvelt 4:21 pm on September 11, 2015 Permalink | Log in to Reply

      This is a screenshot when the priorities are ok:
      http://wppa.opajaap.nl/wp-content/wppa-pl/Screenshots/Prority-ok.JPG

      Here are two screenshots with do_shortcode priority = 9. The exact same page:
      http://wppa.opajaap.nl/wp-content/wppa-pl/Screenshots/Priority-faulty-1.JPG
      http://wppa.opajaap.nl/wp-content/wppa-pl/Screenshots/Priority-faulty-2.JPG

      So you can see the damage of wpautop()

    • Jacob N. Breetvelt 10:59 am on September 12, 2015 Permalink | Log in to Reply

      It is worthwile noting these two tickets about wpautop that cause the majority of problems:
      https://core.trac.wordpress.org/ticket/33834
      https://core.trac.wordpress.org/ticket/33840

  • Robert Chapin 10:10 pm on September 2, 2015 Permalink
    Tags: , ,   

    Shortcode Roadmap Draft One (Proposal – Request for Comments) 

    This is the first draft of the Shortcode API Roadmap. It describes in broad terms a new feature set and migration that might take place across versions 4.4 through 4.7. This roadmap gives notice to plugin developers that significant changes in plugin design may be needed for compatibility with future versions of the Shortcode API. This roadmap also identifies steps taken to minimize the impact on plugin developers to allow most plugins to continue working with only small changes.

    The decision to create this roadmap arose from specific needs that are not met by the old code. Our old [ and ] delimiters were easily confused with the way those characters are commonly used in English quotations and sometimes even in URLs. The proposal to use [{{ and }}] instead should allow a better balance between being able to type in the shortcodes and avoiding confusion with any other input. With these more unique delimeters, we will be able to process registered shortcodes more efficiently because we will not have to search for them by name. Unregistered shortcodes will have more consistency because we can find them more accurately.

    Old style delimeters also gave no strong indication whether or not a closing tag was required. The proposal to use }$] as the delimeter of a shortcode with a following closing tag increases the efficiency of regular expressions, because the search for a closing tag will only happen as needed.

    Adding the new style of shortcode syntax provides an opportunity to make significant API changes. One of those major changes is to ensure that shortcodes are processed before paragraphs and before curly quotes. This will lead to greatly simplified code in related functions that currently must find and avoid shortcodes every time they run. We also have an opporunity to re-think the way shortcodes are filtered, and to give plugin authors more control over those filters when registering their shortcodes.

    4.4 – Introduce New Syntax

    A new syntax and documentation of how it works will be created in the 4.4 development cycle. Support for the new syntax will be introduced, allowing plugins to register for extra features. Core shortcodes will use the new syntax in all new posts. The old syntax will not change. Old posts will not be affected. Initial work on the syntax concept follows.

    Proposed New Syntax

    Self-Closing:  [{{shortcode}}]
    
    Attributes:  [{{shortcode  attr1="value1"  attr2='value2'  "value3"  'value4'  value5}}]
    
    Enclosing:  [{{shortcode}$] HTML [${shortcode}}]
    
    Multiple Enclosures:  [{{shortcode}$] HTML [${encl2}$] HTML [${encl3}$] HTML [${shortcode}}]
    
    Escaped Code:  [!{{shortcode}}]
    
    Stripped Unregistered Code:  [{{randomthing}}]
    
    Stripped Unregistered Enclosure:  [{{randomthing}$]  Content also stripped.  [${randomthing}}]
    
    Stripped Empty Code:  [{{ }}]
    
    Ignored Orphan:  [{{shortcode}$]
    
    Ignored Orphan:  [${shortcode}}]
    
    Ignored Orphan:  [${encl2}$]
    
    Ignored Context:  [{{shortcode <br> }}]
    
    Ignored Context:  <a href="[{{shortcode}}]">

    4.5 – Deprecate Old Syntax

    Starting in 4.5, plugins that register shortcodes without declaring support for new features will raise debugging errors to alert developers that support for the old shortcode syntax is ending.

    Old posts will continue to work normally while the old syntax is deprecated.

    4.6 – Upgrade Old Posts

    Old posts will be automatically converted to the new shortcode syntax. The Shortcode API will continue to provide deprecated support for old syntax so that there is no disruption during the conversion process.

    The API should be adequately abstracted so that old plugins are not affected by this conversion. However, as the new syntax will not support HTML inside of shortcode attributes, there is no guarantee that every shortcode will work the same way in 4.6 as in earlier versions.

    4.7 – End of Support for Old Syntax

    Old shortcodes will stop working in 4.7. Plugins that still produce the old shortcode syntax will be ignored by the Shortcode API.

    The upgrade to 4.7 will include a second pass of the conversion of old posts so that any old syntax that was added to posts during 4.6 will still get converted.

    In 4.6 or 4.7, if necessary, a filter could be added to automatically convert any old syntax still being produced by old plugins when new posts are created.

     
    • Daniel Bachhuber 10:15 pm on September 2, 2015 Permalink | Log in to Reply

      Old posts will be automatically converted to the new shortcode syntax. The Shortcode API will continue to provide deprecated support for old syntax so that there is no disruption during the conversion process.

      What about shortcodes stored in other fields?

      • Muhammad 10:18 pm on September 2, 2015 Permalink | Log in to Reply

        Hopefully, we’ll have helper functions to convert those into new format.

      • Robert Chapin 10:38 pm on September 2, 2015 Permalink | Log in to Reply

        Unless there are alternative ideas, I think plugins that do things in non-core ways will be expected to follow the roadmap with their own upgrades. If there are certain fields that are very commonly used in plugins, we should consider doing a core conversion of those, but with much caution.

      • Robert Chapin 11:10 pm on September 2, 2015 Permalink | Log in to Reply

        One alternative would be to leave the old syntax parsers available for plugin filters, while removing them from default filters.

    • AmirHelzer 10:16 pm on September 2, 2015 Permalink | Log in to Reply

      Thanks for the advanced notice on this huge upcoming change. Aren’t you worried that this process will basically break 99% of all existing WordPress sites? Almost all sites use shortcodes in one way or another (like image captions). doing automated updates to CONTENT is certainly possible, but also prone to corner cases and errors.

      It’s great to have a new API. Is it critically important to deprecate the old one?

      Also, for authors, it’s a lot nicer to have a simple [ ] syntax rather than a more complex sequence of characters.

      • Robert Chapin 10:44 pm on September 2, 2015 Permalink | Log in to Reply

        I think the conversion process will be seamless for most sites. This will mainly depend on corner cases such as plugins embedding shortcodes inside of HTML attributes.

    • Nick Haskins 10:18 pm on September 2, 2015 Permalink | Log in to Reply

      The advanced notice is great, but IMO this is absolutely ridiculous. Are there any benchmarks on how much more efficient it is having users type in more characters for a shortcode? Any benchmarks with how much more efficient core will be from having this change made? This is a HUGE change that will affect a VERY large subset of users.

      • chriscct7 10:40 pm on September 2, 2015 Permalink | Log in to Reply

        This is partially about efficiency. This has a lot to do with security, and basically making 4.2.3 impossible as possible to re-occur

        • Nick Haskins 10:45 pm on September 2, 2015 Permalink | Log in to Reply

          I’d love to see benchmarks on the regex processing of the current implementation against the proposed implementation. Re: security; ATM I’m failing to see how [{{this}}] is more secure than [this]?

        • kevinwhoffman 1:13 am on September 4, 2015 Permalink | Log in to Reply

          If the proposal has positive effects on security, it should mention them. A brief summary or a link to the issues with 4.2.3 would help inform that discussion. As of now the only focus seems to be on theoretical improvements to efficiency while complicating the process of using shortcodes.

      • FolioVision 11:31 pm on September 2, 2015 Permalink | Log in to Reply

        This is an absolutely hideous proposal with dreadful syntax. Is the goal of this WordPress project of ours not to bring software to the people? Syntax like this will be the beginning of a new and much better simple CMS which doesn’t do things in the ugliest, most complicated way possible.

        Code better database upgrades, test them properly before releasing and please stop trying to ruin the software for the end users (those who actually use the software and pay all the bills for us to build it).

        • Travis Northcutt 3:54 pm on September 3, 2015 Permalink | Log in to Reply

          “Syntax like this will be the beginning of a new and much better simple CMS which doesn’t do things in the ugliest, most complicated way possible.”

          The sky is falling!

    • Scott Taylor 10:18 pm on September 2, 2015 Permalink | Log in to Reply

      Let’s all note the “Draft One” portion of the title, and let’s all actively give feedback and participate in any decisions on the table here.

      • Nick Haskins 10:21 pm on September 2, 2015 Permalink | Log in to Reply

        My main concern is that this isn’t easier for authors, and that this will affect a very large portion of users and active sites. If I’m understanding correctly, is this being proposed because it’s more efficient for core?

        • Scott Taylor 10:23 pm on September 2, 2015 Permalink | Log in to Reply

          I have the same concerns, and hate the syntax. I also know that the current situation with shortcodes and content-parsing is potentially unstable and unsustainable.

        • Justin Sternberg 10:33 pm on September 2, 2015 Permalink | Log in to Reply

          I’m in agreement here with the concerns. This will break a lot of things because the short code API has been around so long. There’s just no way to account for all the hacks, workarounds, etc, and doing a migration effort on a WP update sounds like a mighty scary prospect.

          • leehodson 10:37 pm on September 2, 2015 Permalink | Log in to Reply

            Should be able to use the existing shortcode parser to recognize old format shortcodes then make the necessary changes to update them. It recognizes shortcodes efficiently enough at the moment.

            Can imagine breakage but as long as the updater shows the changes site admins ought to be able to determine where hands-on intervention is required.

          • FolioVision 11:33 pm on September 2, 2015 Permalink | Log in to Reply

            It seems a make work project. Are there not some important areas where we could make some real progress like integrated multilingual and better native galleries/media management (NOT reliant on external Automattic services)?

            The upgrade process here and cross-version incompatibilities are more than scary.

          • galbaras 11:44 pm on September 2, 2015 Permalink | Log in to Reply

            Backward compatibility should take into account site-specific customizations, i.e. declaring shortcodes in functions.php of a (child) theme. Most site owners use a “build and forget” approach, or at least neglect their sites for long periods. If a new version contains no support for old-style shortcode declarations, sites will break all over the web.

        • Solinx 11:09 pm on September 2, 2015 Permalink | Log in to Reply

          Yes. How am I going to explain anyone that this syntax is an improvement?

          What specifically are the reasons for not using {{shortcode}} and {{shortcode}} {{/shortcode}}? Or [[shortcode]] and [[shortcode]] [[/shortcode]]?

          Other than that the improvements to the API sound good.

          • Robert Chapin 11:18 pm on September 2, 2015 Permalink | Log in to Reply

            Lone curly braces are easily confused with PHP and other C-style code snippets. The latter square brace example is incompatible with the old syntax and would cause migration problems.

    • Andrew Ozz 10:20 pm on September 2, 2015 Permalink | Log in to Reply

      Was just about to say that this is a proposal. Scott beat me to it (as usual) 🙂

    • Pippin Williamson 10:22 pm on September 2, 2015 Permalink | Log in to Reply

      I would assume the answer is “yes”, but have there been benchmarks done that compare the differences in various syntaxes?

      Why [{{shortcode}}] and not {{shortcode}}?

      Most of the proposed syntax seems sane (though still curious on question above), but this one concerns me:

      [{{shortcode}$] HTML [${shortcode}}]

      For most users, that will be exceptionally unintuitive and we will almost certainly see a high error rate with users not being sure where and when a $ is used.

      • Nick Haskins 10:26 pm on September 2, 2015 Permalink | Log in to Reply

        Pippin I have to agree. If we absolutely have to move, how about something as simple as [{this}] HTML [${this}] . it’s easier to digest, and easier to remember that a $ ends a closing statement.

      • webaware 11:19 pm on September 2, 2015 Permalink | Log in to Reply

        The whole proposal sounds pretty horrible to me, but this suggestion by Pippin sounds moderately less ridiculous.

        Re: {{…}}, I would assume that’s because they are already used heavily in non-WP templating, especially JS templating.

        Essentially, this “fix” is coming rather too late in the piece and I think it’ll break more things than it solves. As a plugin writer heavily dependent on shortcodes, I can only see a greater number of support requests from broken shortcodes in my future if this goes ahead.

        Only Shortcake can save us now! 🙂

        • idealien 2:33 am on September 3, 2015 Permalink | Log in to Reply

          “Only Shortcake can save us now!”

          Seriously! If Shortcake were to be brought into core along with this (draft) proposed change – it would go a LONG way to mitigating the concerns many have raised around complexity.

          Without Shortcake:
          “Look – we took this feature you love and made it harder to use….But it’s safer / faster / better”

          With Shortcake:
          “Look – we made is hella-easy to use shortcodes without having to remember syntax type things. Oh, and that syntax is also getting harder b/c it needs to be safer / faster / better.”

          Car metaphor time… With Shortcake: You’re getting automatic transmission and manual is just a little bit harder to use. Without Shortcake: Manual transmission is now harder to use.

          Shortcake FTW!

      • Robert Chapin 11:33 pm on September 2, 2015 Permalink | Log in to Reply

        If we could get this to work…

        [{{shortcode}} HTML {{shortcode}}]

        Is that better? Or still confusing?

      • Mario Peshev 4:16 pm on September 3, 2015 Permalink | Log in to Reply

        I do agree with Pippin’s example with the dollar signs. Seems incredibly easy to mess up by users. I also noticed another syntax including an exclamation sign, which adds an additional layer of complexity for each and every user.

        +1 on the benchmark question. Given the several different supported syntax proposals, I’m curious to see the regex that is parsing those in a sensible and timely manner.

    • AmirHelzer 10:23 pm on September 2, 2015 Permalink | Log in to Reply

      Also, we deal a lot with shortcodes in Toolset plugins. I can’t see any evidence of any user confusing the [ ] characters for anything else than shortcodes.

      Please, besides the code changes, please also consider the huge amount of documentation update that such a change will require.

      Run a quick Google search for “WordPress shortcodes”. A few pages come from wordpress.org, but the majority are old pages, blog posts and tutorials. Nobody is ever going to update them.

      So, after making such a change, people will see two sets of documentation – with new syntax and with old syntax. You know that Google favours ‘old’ content, so the old tutorials that are never going to update will still explain to use [ ]. I don’t think that this will work out well.

      • chriscct7 10:34 pm on September 2, 2015 Permalink | Log in to Reply

        The team working on this is committed to the documentation updates that are necessary.

        • Pippin Williamson 10:35 pm on September 2, 2015 Permalink | Log in to Reply

          Core documentation isn’t an issue. It’s every plugin / theme developer in the world that also has to update their documentation.

          I don’t disagree with updating docs, just making it clear that’s the issue @AmirHelzer is raising.

          Also have to keep in mind the thousands (millions?) of blog posts and tutorials out there.

          • AmirHelzer 10:49 pm on September 2, 2015 Permalink | Log in to Reply

            Exactly. I’m sure that the core team would be quick to update documentation on wordpress.org. I’m talking about the many pages on other people’s sites that will likely never be updated.

    • Scott Fennell 10:25 pm on September 2, 2015 Permalink | Log in to Reply

      Thanks for your work on this!

      I’m trying to understand what I would need to do in order to prevent about 1,200 live blogs from breaking when this syntax is no longer supported:

      [my_shortcode before='<div class="my_class">' after='</div>']

      Andrew offered a helpful suggestion here:

      https://make.wordpress.org/core/2015/08/30/shortcodes-roadmap/#comment-27368

      If I understand his suggestion correctly, I’d be on the hook to do a search and replace in the database, which will be quite scary and expensive for my company. We have literally thousands of posts on thousands of blogs.

      Please, let’s find a way to move forward with this that leaves the old format unscathed.

      • Scott Fennell 10:28 pm on September 2, 2015 Permalink | Log in to Reply

        Sorry, meant to provide the following code.

        http://pastebin.com/1CMN731H

        Is there a reference somewhere for the comment syntax so I can stop posting gibberish?

      • Robert Chapin 11:49 pm on September 2, 2015 Permalink | Log in to Reply

        If the situation doesn’t support

        [{{my_shortcode class="my_class"}}]

        Then the alternative proposed in the roadmap is

        [{{my_shortcode}$] Optional Content [${before}$]<div class="my_class">[${after}$]</div>[${my_shortcode}}]

        We will also likely encode any HTML in attributes during a migration, so you would have the option of decoding that in your plugin.. security implications could be significant though.

        • Scott Fennell 4:10 pm on September 3, 2015 Permalink | Log in to Reply

          “We will also likely encode any HTML in attributes during a migration”

          Can you explain what you mean by migration, exactly? My imagination is running wild a bit with what you might mean by that. Do you mean to propose that, upon this update, the new version of WordPress will automatically fix my post_content across many gigabytes of posts, without me having to do anything to the posts?

          • Aaron D. Campbell 4:29 pm on September 3, 2015 Permalink | Log in to Reply

            That’s definitely the goal. Basically using the existing parser to pull shortcodes and replace them with the new syntax.

            • Scott Fennell 7:43 pm on September 3, 2015 Permalink

              Sorry for sounding clueless here but that would be … amazing. Is there a precedent for this level of work in a similar update? I’m having trouble imagining how this would be possible given a very large database like mine. Would it run as a cron job perhaps?

    • leehodson 10:30 pm on September 2, 2015 Permalink | Log in to Reply

      The new syntax is very confusing to the eye. Users would find it complicated. I feel we could make it less confusing by using back-to-back opening and closing brackets.

      For example

      Self Closing:

      []shortcode[]

      Enclosing:

      []shortcode[] Content [/]shortcode[]

      Note the forward slash between the brackets of the closing tag on the enclosing shortcode.

      Is there a reason this wouldn’t work?

    • Peter Wilson 10:51 pm on September 2, 2015 Permalink | Log in to Reply

      I’d be happier with {{selfclosing}} and {{enclosing}} {{/enclosing}} or similar. Mixing the formats seems fraught.

      Upgrading old content is a necessary evil, backward compatibility on the deprecated format defeats the purpose somewhat. Seeing some benchmarking results would be great.

      As theme and plugin developers, we have been caught out by an ill-defined API and security problems in the past, a long term roadmap makes the best of a bad situation. I’d rather a two year defined process than a repeat of 4.3.2

      • webaware 12:46 am on September 3, 2015 Permalink | Log in to Reply

        [ignoring the double-moustache issue here…] but what signifies that the self-closing shortcode is self-closing? The problem is not merely one of mixed use, it’s the calling syntax that the regex needs to accommodate.

        • Peter Wilson 1:38 am on September 3, 2015 Permalink | Log in to Reply

          Okay, understood – that makes sense.

          {{selfclosing /}} and {{enclosing}} {{/enclosing}}, perhaps. That makes sense to me as a developer, so may be bad for a user.

          Could be double moustache, square, anything. Looking for the balance between performance and teaching.

        • Curtiss Grymala 3:44 pm on September 3, 2015 Permalink | Log in to Reply

          In HTML, what signifies that a self-closing tag is self-closing? Hint: it’s not the / at the end; that’s totally optional; in fact, even the closing HTML tag is optional in a lot of cases.

          For instance:

          <img src="/my-image.png" alt="">

          and

          https://gist.github.com/cgrymala/d61c3cacd6fb07bdcf9a
          (a complete HTML page that is 100% valid HTML)

          are both perfectly valid HTML code samples, even if they do make those of us accustomed to XHTML syntax cringe.

          In a perfect world, there would be some way to indicate when registering the shortcode itself whether or not it’s supposed to be self-closing, but that’s not always possible (I believe there are plenty of use-cases where a single shortcode works one way when it’s self-closing, and works a slightly different way when it’s wrapped around content).

          That said, I would definitely support the idea of at least trying to indicate that in the shortcode registration (for instance, if my shortcode is only ever written to be a self-closing shortcode, let me indicate that when I register it; if it’s only ever intended to wrap around content, let me indicate that when using add_shortcode()).

          • webaware 11:09 am on September 4, 2015 Permalink | Log in to Reply

            Yes, and a parser for HTML is a pretty complex piece of code, much more significant than a handful of regular expressions. Ultimately, a true parser might be needed if we want to keep shortcodes the way they are. But perhaps that discussion is better held on the new post

    • Scott Fennell 10:52 pm on September 2, 2015 Permalink | Log in to Reply

      Othe use case for shortcodes I’m hoping you don’t break: Shortcodes in widget titles and widget text fields. This has been a gloriously simple and helpful solution for our agency, and many others I’d suspect.

      • williampatton 12:36 am on September 3, 2015 Permalink | Log in to Reply

        Shortcodes can be parsed anywhere by passing it through `do_shortcode()` which is what I expect your themes are doing to make use of them in widget titles and content.

        Your use case should be just fine so long as the shortcodes used obey the newer syntax 🙂

    • KalenJohnson 11:10 pm on September 2, 2015 Permalink | Log in to Reply

      I’m most likely horribly biased since I’ve started the discussion about [https://core.trac.wordpress.org/ticket/33472 templating engines], but aren’t those shortcodes looking an awful lot like templating engine syntax?

      I’m mostly confused as to why users apparently would be able to remember all those different syntax’s, yet theme and plugin developers wouldn’t, or rather don’t have built in functionality to.

      Also, I also feel rather strongly that there are MANY options now that are much preferable to shortcodes. Things like ACF, Pods, etc. They are not built in to WP core like shortcodes, but really, shouldn’t we focus on getting the Fields API set up correctly rather than continuing to pursue having complicated layouts in one single WYSIWYG editor (not so much WYSIWYG when it’s littered with shortcodes).

      • Jonathandejong 5:52 am on September 3, 2015 Permalink | Log in to Reply

        I’m with this guy ^ Complicated layouts in a single WYSIWYG field just feels wrong. Altho I recognize there’s a lot more to it than just the editor (do_shortcode(), widget fields etc.).

    • Aristeides Stathopoulos 11:33 pm on September 2, 2015 Permalink | Log in to Reply

      I love it!
      It was about time we use something more unique for shortcodes…

    • nick6352683 11:51 pm on September 2, 2015 Permalink | Log in to Reply

      Priorities core developers, priorities. With so many things to still fix and add to the core, you are going to spend time and energy on this, and for the lamest excuse for doing so? Who uses square brackets for quotations? Way to break millions of web sites, for nothing!

      • webaware 12:48 am on September 3, 2015 Permalink | Log in to Reply

        [I hate to pop your bubble but] many people use brackets for essentially parenthetical in-sentence comments. 🙂

    • Jon Brown 11:53 pm on September 2, 2015 Permalink | Log in to Reply

      Shortcode API, yay! This is an exciting proposal, but I’ve got to echo others that the proposed syntax looks like a disaster. I get it, but I can’t imagine users will. I get avoiding the sane syntax of handlebars, angular, C, etc… but do we really have to be _that_ different. I really hope there is a better way.

      On core updating old shortcodes. I’m sorry but no, just no. Don’t you dare go changing _my content_ on a WP update. Worse still is only planning on updating post_content and ignoring all the other places shortcodes show up. Custom Fields for one, but also in PHP files.

      I’d humbly suggest two significant change to this proposal (beyond finding better syntax).
      1. Don’t plan on actually dropping support for the old shortcodes. Do show deprecated notices, just don’t stop supporting the old syntax until WP 6.0. Of all the deprecated cruft I’d love to see dropped, this will never be one of them.
      2. Build a separate utility/plugin a la the WordPress XML importer that can update old shortcodes in a user controlled fashion. Bonus if it actually scans PHP files and identifies shortcodes there. This could then either bulk update, or step through shortcodes one by one for the super paranoid.

      Summary: Simpler Syntax, No real deprecation, Separate plugin for converting old shortcodes.

    • Alex Mills (Viper007Bond) 11:56 pm on September 2, 2015 Permalink | Log in to Reply

      Going to be… interesting migrating SyntaxHighlighter over to this. Maybe this is the motivation I need to finally finish my rewrite from scratch.

    • Peter Chester 12:44 am on September 3, 2015 Permalink | Log in to Reply

      I love clarity. I love easily parseable content. However, this seems like it’s destined to cause WordPress sites around the world to break. I’m sure we’ll see heaps of bare old shortcodes from this change.

      I’m not sure I understand why it’s a problem to check that a shortcode is actually a shortcode before trying to convert it. Why are we doing this?

      Also, I have a hard time teaching people the existing simple shortcode. I expect the error rate will be quite high for people with a more complicated new format.

      > Our old [ and ] delimiters were easily confused with the way those characters are commonly used in English quotations and sometimes even in URLs.

      What are some examples? I haven’t run into this at all in all my years of working with WordPress.

      • webaware 12:59 am on September 3, 2015 Permalink | Log in to Reply

        Very common to have brackets in quotes, to fill in implied references, like this:

        “I won’t be rushing out to get my daughters vaccinated [for cervical cancer], maybe that’s because I’m a cruel, callow, callous, heartless bastard but, look, I won’t be.” Tony Abbott, November 9th, 2006

        Also for excerpted quotes, like this:

        […] We shall go on to the end, we shall fight in France, we shall fight on the seas and oceans, we shall fight with growing confidence and growing strength in the air, we shall defend our Island, whatever the cost may be, we shall fight on the beaches, we shall fight on the landing grounds, we shall fight in the fields and in the streets, we shall fight in the hills; we shall never surrender [… continued]

        For URLs, consider that PHP only handles query parameters as arrays when the parameter name has [] or [key], and some URLs pass such parameters.

    • Greg Ross 12:47 am on September 3, 2015 Permalink | Log in to Reply

      I agree with many of the above comments about the syntax, it’s cumbersome and confusing.

      HTML seems to get by just fine with a single character for it’s delimiters and I see no reason a shortcode can’t as well. Perhaps square brackets are too common, fine let’s change to something else (curly brackets seem reasonable).

      And don’t reinvent the wheel, HTML already has a standard for self-closing and encapsulated tags ( and ) use the same format for shortcodes ( {shortcode /} and {shortcode} {/shortcode}).

      This would also allow both shortcode API’s to run side by side as plugin authors and content creators updated to the new format. Perhaps even make the new syntax a feature plugin for the next few releases until it is merged in to core and then move the old API out to a plugin for several more releases.

      The timeline seems far to aggressive, shortcodes were added way back in WP2.5 and how you want to yank out the old format in just three point releases? The amount of code and content that will require updating is significant.

      My final thought is about the assertion in the proposal that shortcodes *should* only do certain things (like not pass in html as attributes). Keep shortcodes flexible, don’t artificially limit them to certain things. While it may take more to support that flexibility, it would seem to have paid off greatly in the past looking at all the things people have done with them.

      • Ben Huson 4:11 pm on September 3, 2015 Permalink | Log in to Reply

        Completely agree on not re-inventing the wheel for self-closing and encapsulated tags. Stick with the same convention as HTML using the trailing/leading slash within the syntax.

    • Justin Tadlock 1:00 am on September 3, 2015 Permalink | Log in to Reply

      On syntax:

      Users know shortcodes. WP wasn’t the first system to have them. Anyone remember the old BBCodes?

      Open bracket. Type short tag. Close bracket. Simple. Intuitive. Hard to break if you’re not doing anything crazy. Let’s make sure this simplicity is at the core of any discussion on the topic.

      I’d pretty much put the [{{shortcode}}] syntax into the non-starter category. I could get behind {{shortcode}} if we must change syntax, but mixing and matching brackets is destined to fail.

      On updating:

      One thing to watch out for when auto-updating old shortcode syntax in the post content is those of us who output code examples, especially those of us who write in Markdown and don’t need to convert our [ and ].

    • Maxime Jobin 1:04 am on September 3, 2015 Permalink | Log in to Reply

      My main problem is understanding what real problem does it solve ?

      The proposed syntax is really confusing. Isn’t there a way to simply “improve” the actual syntax instead of changing it like this ?

      Also, wouldn’t it a good idea to abstract the concept in the editor. That would mean displaying a visual representation of the shortcode. I would see that as Facebook highlights someone you tag in a status/comment.

      But, that would mean “forcing” developers to specify expected/accepted attributes.

      Aren’t we ready for something more powerful than writing shortcodes ? For devs, it’s perfect. But for non-tech, it’s hard to understand and use. Changing that would mean a lot of confusion.

    • Justin Busa 1:07 am on September 3, 2015 Permalink | Log in to Reply

      If custom fields aren’t going to be migrated to the new syntax, then it would be nice if there was some sort of filter that would allow plugin developers to migrate fields themselves.

      Also, in terms of sites breaking, it would be nice if there was some sort of constant that would enable the old API. Reason being, lets say a site has shortcodes defined in the theme or is using do_shortcode in theme files. Enabling the old API would instantly fix the site while allowing the developer time to update the theme’s code.

    • Ipstenu (Mika Epstein) 1:18 am on September 3, 2015 Permalink | Log in to Reply

      My major concerns have been raised already but I’ll stress if from a different angle.

      If we learned anything from the shortcode change to secure them, we cannot keep breaking users sites. I know that we’re talking about a long term plan to possibly remove shortcodes as we know them by 4.7, but even with all the notification in the world, we will break sites.

      We have 3 releases of WP a year. 4.7 is 18 months away at the outside. That’s a lot of information to get out there really fast and really clearly, AND a lot of code to fix.

      We have to consider:

      • All the plugins and themes on the planet we will break (because we will, they won’t read or test). We have to degrade them as gracefully as humanly possibly. Continuing to say “Well the developers were notified and should have updated” now that we’re as big as we are is not sustainable.
      • All the very (legitimately) angry end users who are broken because they didn’t upgrade plugins and themes (or the themes/plugins didn’t get updated). People were rightly angry last time. It’s the end users, not the developers, who will be hardest hit by this change.
      • Communicating clearly to the users that it’s now {{gallery}}. That’s going to be very hard. Incredibly hard. Updating their old posts (keeping in mind Justin’s Markdown caveat and those who use them as an aside – I know I know) is easier than making sure everyone knows what to do. At best we can keep tabs on the ones built into WP and perhaps use the logic we have in the visual editor NOW to convert them, but we have to figure out how to make sure everyone knows. This is nothing like the move of Menus to customizer. That was confusing, but the users could see what happened. This is a legit change, your old way is no longer going to work. That is huge.
      • The number of users who have premium themes and plugins that do not get update alerts. These people are simply not going to know they need to update and this is not their fault. We should never be breaking them if there’s possibly any alternative.
      • Users will be upgraded by their hosts vis-a-vis one-click installs and managed hosting so they will have up to date WP and out of date plugins/themes. So yes, many users will be on 4.7 and then a theme from 2014. It sucks, it’s the reality, we know it’s the reality, we cannot stick our heads in the sand.
      • Plugins that are already using {{template}} tags in their code. Yeah, I’ve seen it. Most of them use it for search/replace within their own code, but we’ll want to make sure we check for everyone in the repo who might be doing it on their own.
      • Gabe Shackle 1:55 am on September 3, 2015 Permalink | Log in to Reply

        This sums up my feelings perfectly: “we cannot keep breaking users sites”

        Ending support for the current style of shortcode syntax within 18 months will absolutely break sites and frustrate end-users, site owners, and developers in a huge way.

        The best way to make developers stop using a platform is to force them to repeatedly have to retrain their clients and refactor their code.

    • Jean-Francois Arseneault 1:19 am on September 3, 2015 Permalink | Log in to Reply

      Clients, you know, the small business owers, who we train to use their site, and the 3-5 shortcodes they might need, already have a hard time understanding these “square brackets”.

      The draft I read seems to me like the start of “pleasing the machine, and not the human”

    • Luke Carbis 1:20 am on September 3, 2015 Permalink | Log in to Reply

      I’m concerned about client-brain-backward-compatibility. Any changes to the shortcode syntax should still work with my clients brain.

      For example, I provide my client with a site, and teach them to use [button] to insert a button. We finish our contract, and I am no longer in touch with them.

      First the client updates WordPress to 4.4. Nothing changes. Then 4.5. They’re in a production environment, so they don’t see the warnings. Then 4.6. They don’t happen review old posts / pages, but if they do, they don’t realise that their shortcodes have changed.

      Then the client updates to WordPress 4.7, but unlike me, they don’t read the Make WordPress Core blog. They don’t know about the changes. They don’t know that what they’ve learned has become deprecated and now unsupported.

      The client publishes a new page, and they put the button in the way they’ve been taught, which has always worked. But now, it doesn’t work. It’s broken. They call me.

      The client is now angry because a WordPress update cost them money, and confused because the new syntax is much harder to understand.

      I recognise that there are always changes to WordPress, and that the nature of incremental releases is that a user must learn to deal with change. But as far as I know, these changes have always been easy enough for a reasonable user to intuitively navigate. i.e. changes to the menu design, or updates to the nav menu UI.

      I have three questions:

      1. Has there ever been a change to WordPress which could not be intuitively learned by a reasonable user?

      2. Is it okay to introduce unintuitive changes to WordPress?

      3. How can we make this change intuitive to a reasonable user?

      • Luke Carbis 1:29 am on September 3, 2015 Permalink | Log in to Reply

        Here’s a suggestion to answer my third question.

        • When the user enters a shortcode (with either the [simple] or the [{{new}}] format), check if the shortcode exists.
        • If it does, replace the text shortcode with a GUI placeholder element
        • Also, behind the scenes (i.e. in the HTML editor), replace the [simple] shortcode with the [{{new}}] format

        The user experience doesn’t get worse – it gets better. My client enters a shortcode as they always have. They see a visual indicator to show that it was recognised and accepted. Behind the scenes, the new format is saved.

        • Weston Ruter 5:52 am on September 3, 2015 Permalink | Log in to Reply

          Yeah, if this new syntax goes in then GUI placeholders (TinyMCE views) are going to have to be the answer, which also seems like Shortcake.

    • webaware 1:30 am on September 3, 2015 Permalink | Log in to Reply

      Upon some further thought, I think that really there are two problems that are presented:

      1. brackets are already commonly used elsewhere, e.g. quotations, URLs with array parameters

      I see this as being a problem only when developers register shortcodes for real words. Using a sensible prefix for shortcodes prevents this. Unfortunately, there’s been a push for shortcode portability which directly undermines that, e.g. by recommending shortcodes like [product …] for products. [and of course, that prevents combining plugins with similar intent on the same site, but whatever…]

      Has it actually been a problem thus far? I imagine that anyone writing “blah-de-blah [product name] de-blah” will quickly discover that they should use parentheses instead if they don’t want to trigger the shop plugin they’ve installed. Content editors learn. They already have stuff they need to learn, and this is a very simple one that they learn pretty damned quickly anyhow.

      Is it necessary to strip “unregistered shortcodes” when we can just assume that they are part of normal sentence structure? So some websites will display the odd shortcode when its code [e.g. plugin] isn’t active; so what?

      2. self-closing shortcodes don’t look like they are self-closing until they don’t have a closing shortcode

      … which is easily resolved by demanding that they close with /] similarly to XML and HTML.

      To me, this is THE performance problem, and it is easily resolved by not allowing self-closing shortcodes without a terminating /].

      Now, bear in mind also that cleaning up old code might require changing content in:

      • wp_posts.post_content
      • wp_posts.post_excerpt (some plugins / themes use it for rich text)
      • wp_postmeta.meta_value
      • wp_usermeta.meta_value
      • custom tables
      • code (e.g. directly calling `do_shortcode(‘[product …]’);`

      And it has to take into account all sorts of edge cases.

      There’s only so much auto-upgrading that can be achieved. The changes proposed WILL BREAK WEBSITES. Even simply requiring self-closing shortcodes to have /] WILL BREAK WEBSITES. All I can see coming from this proposal is pain. “There will be a great gnashing of teeth” etc. 🙁

    • Jean-Francois Arseneault 1:47 am on September 3, 2015 Permalink | Log in to Reply

      Pardon the pink-colored glasses for a second, but why does it seem that our only choice moving forward, to improve the state of shortcodes, is to change *how* shortcodes work, and not *if* there isn’t a better / newer way to accomplish the goal of inserting content into a page ?

      In the spirit of seing the forest from the trees, why are we still trying to desperately manage mixed-source content using text-based shortcodes ?

      Why are we still using a paradigm where the main content area (if talking about posts) is still an area where we can add content, but also perform layout decisions *within* the content? Where’s the separation of concerns in this way of doing things?

      I think Page Builders are the start of a better solution for managing all these different contents within a page, but perhaps forcing plugin authors to expose their functionality into native widgets and ‘page builder elements’, vs letting them add shortcodes anywhere to render content might be an approach that is easier to grasp, from a UI perspective, for *end-users*.

      Sure, developers, integrators… we can handle everything you throw at us, but in the end, the sites are built for end users, for real-life applications and business purposes. End users are the ones that matter.

      Simplicity always wins.

      • Peter Wilson 2:19 am on September 3, 2015 Permalink | Log in to Reply

        The Shortcake feature plugin covers providing a UI for shortcodes.
        https://wordpress.org/plugins/shortcode-ui/

      • Chris Van Patten 2:30 am on September 3, 2015 Permalink | Log in to Reply

        Although I’m generally in favour of this proposal, I think this merits some consideration too. Is there potentially a way to eliminate shortcodes — as in a manually entered bit of pseudo-tag-like code — altogether? I think Shortcake is an interesting approach, but it still depends on the shortcode API in the backend. What if shortcodes were deprecated, and replaced with an entirely new concept for inserting dynamic “chunks” of content that doesn’t fall back on parsing through plaintext?

        Replacing shortcodes is probably a much-longer term play, but it does mean that instead of patching the old they can be replaced with something newer, more flexible, and more in tune with the direction core has been moving already.

      • John Teague 1:53 pm on September 4, 2015 Permalink | Log in to Reply

        I totally agree. We need to be thinking of an intuitive replacement for shortcodes altogether. That provides incentives for developers and users to make the change.

        I really appreciate the hard work by @Robert Chapman and others putting a lot of effort into solving the increasingly unsustainable shortcode system. Sadly, I think the proposal in its current form, will confuse already error prone users, and likely break a lot of sites.

    • Chris Van Patten 2:36 am on September 3, 2015 Permalink | Log in to Reply

      As a supplement to my other comment (which was a nested reply), I’m generally in favour of this proposal. I think there’s merit in discussing completely new alternatives to shortcodes, but that’s a semi-separate issue.

      Like many others, I’m not sold on the suggested syntax, but it’s obviously still early days.

      One other thought: why not make escaped code the default, and make unescaped the exception with its own special syntax? Are there backcompat reasons that wouldn’t work? Seems like (potentially) an easy win for security.

    • Andrew Nacin 3:03 am on September 3, 2015 Permalink | Log in to Reply

      Thanks for your feedback, everyone. Developers, truly, honestly, really: Thank you for paying attention. I often feel that requests for comments usually fall on deaf ears, and I know I am not the only committer who feels that way. This has been one of the most substantial and productive threads on make/core I’ve seen, and it’s encouraging to see.

      Here are some thoughts on the proposal:

      • This was clearly labeled a “draft”. I am glad many of you noticed that this was not a decree, but a call for feedback. (And thank you again for obliging.)
      • The vision of shortcodes should be something like “it should be easy and intuitive for non-technical authors to embed and enrich their posts” (I have cribbed this from @matt).
      • This vision does not actually mean that shortcodes are the solution. I actually have a strong dislike for shortcodes. I think they are a terrible user experience, and that even something like Shortcake is still only a marginal improvement.
      • Some changes to shortcode parsing is absolutely necessary in order to keep WordPress secure. Yes, this is about security, not just general sanity.
      • The proposed syntax significantly clashes with the proposed vision. And given all of your feedback, we’re clearly going to have to go back to the drawing board. Please note that we still need to do something, but maybe we can think further outside the box.
      • And for goodness sake, PLEASE STOP RELYING ON HTML IN SHORTCODE ATTRIBUTES. This also does not align with the outlined vision, either, and it’s what largely precipitates proposals like these.
      • Thank you @miqrogroove for your incredibly hard work on this. Honestly, folks, many of you simply cannot see how much work Robert has poured into shortcodes over the last year, as it takes place in private security discussions. He’s been a tremendous asset to the project.

      I’m looking forward to future make/core threads getting this much high quality feedback. Now if only it can also carry over to more Trac tickets. 😀

      • Solinx 9:21 am on September 3, 2015 Permalink | Log in to Reply

        Thanks!

        “I’m looking forward to future make/core threads getting this much high quality feedback. Now if only it can also carry over to more Trac tickets.”

        I think this could be helped by making Trac more accessible and by providing a better overview of what is currently going on.

        1. Trac
        When I first heard of Trac I had to get there through google. The “Get Involved” page didn’t help at all. Why not add a link to both the tickets dashboard and the ‘next release’ tickets list at https://make.wordpress.org?

        And why not link to related tickets, github repo’s, slack groups, etc. at the bottom of these blog posts? That makes it a whole lot easier to get to the right places to get involved.

        2. Progress overview
        It is difficult to keep track of all that is going on. The blogs provide updates, but not an overview. Perhaps you could introduce something such as: http://dev.modern.ie/platform/status/adownloadattribute/

        Also here you could link to the related tickets, github, etc.

      • Nick Haskins 12:11 pm on September 3, 2015 Permalink | Log in to Reply

        “Now if only it can also carry over to more Trac tickets.”

        The problem with Trac, for me at least, is that it’s not part of my daily workflow. I’m a bit intimidated by Trac, not to mention making patches. I take part in conversations on Github all day, because that’s how we manage code and issues for my job. I suspect that if these conversations were on Github, with PR’s being allowed there would be a lot more participation. After all, I don’t know any developers outside of WordPress who use SVN in their workflow.

        • NateWr 2:08 pm on September 3, 2015 Permalink | Log in to Reply

          Thanks for outlining this response @nacin. I’d second thinking outside the box. I suspect a lot of the problematic uses of shortcodes stem from people trying to plug gaps in other kinds of functionality (layout, class assignment, conditionals). Maybe solving some of those problems would take a bit of heat off of shortcodes, and make them a smaller attack vector. Or maybe not. Can’t say I really understand the security implications of shortcodes.

        • John Teague 2:33 pm on September 3, 2015 Permalink | Log in to Reply

          Totally agree with you on this Nick. Think how moving to Git would invite solid developers to submit great fixes and features? It’s not that a lot of us can’t use Trac/SVN. It’s just who the hell wants to.

          • Helen Hou-Sandi 4:06 pm on September 3, 2015 Permalink | Log in to Reply

            I imagine that a lot of the workflow folks think of centers around GitHub and pull requests as opposed to Git itself, but just a note that there is a proper Git mirror that many people patch against, including a number of committers. https://make.wordpress.org/core/2014/01/15/git-mirrors-for-wordpress/

            • KalenJohnson 4:49 pm on September 3, 2015 Permalink

              Yes that’s very true, it is Github itself which has become such a boon for developers to be able to quickly and easily find issues, discuss them, and create pull requests. Trac seems very antiquated by comparison, and submitting patch files is not something the rest of the open source web development world does that I’ve seen.

              I can understand how large the move to Github would be for WP, but don’t underestimate that it could really remove WP from the silo it’s in and open up to better quality issues, more issue discussion (as Nacin is looking for), and possibly more patches as people are much more familiar and willing to make pull requests.

            • J.D. Grimes 6:15 pm on September 3, 2015 Permalink

              Yes, the workflow on Trac is needlessly complex. I’d +1 moving to GitHub, or something where we can have PRs instead of patches.

            • John Teague 1:58 pm on September 4, 2015 Permalink

              My bad. I meant github.

      • dlouwe 1:07 am on September 4, 2015 Permalink | Log in to Reply

        “This vision does not actually mean that shortcodes are the solution. I actually have a strong dislike for shortcodes. I think they are a terrible user experience, and that even something like Shortcake is still only a marginal improvement.”

        Very much this. Users shouldn’t have to learn syntax to make use of shortcode-like functionality. They can already use the Visual editor to insert and manipulate HTML without ever knowing what HTML is, and that should be a clear goal for whatever shortcodes end up being in the future. It doesn’t much matter what the new syntax looks like if the only people who are going to be editing it directly are people who have business doing so. As a developer, I don’t mind jumping through some extra hoops to make sure my users have an easy and intuitive experience!

      • raamdev 3:23 am on September 4, 2015 Permalink | Log in to Reply

        > The vision of shortcodes should be something like “it should be easy and intuitive for non-technical authors to embed and enrich their posts”

        I agree. That makes this a good time to redesign shortcodes from scratch, to rethink how we would create something that provides the same flexibility and power of the existing Shortcode API while also more accurately fulfilling the goal of being something that is “easy and intuitive for non-technical authors to embed and enrich their posts”.

        The ideas that came to mind while reading your comment were: Do shortcodes need to be something that is entirely configurable from within the post editor? What if they were instead something that pointed to a configuration, a configuration stored in the database that allowed a plugin or theme to determine what should be returned? (I’m thinking something like `[{{shortcode id=”plugin_slug_123″}}]`, i.e., something like a shortcode with a single attribute.)

        Then a new API could provide plugin and theme developers with a way of building a UI that would allow users to configure ‘shortcodes’ (the configuration being stored in the database, e.g., as `plugin_slug_123`), similar to the way the Plugin API allows plugins to register meta boxes for post types.

        My feeling is that creating something that is both easy and intuitive for non-technical users will require getting rid of syntax as much as possible and replacing that with a UI.

        Building a whole new feature to replace the Shortcode API would also make it easier to transition away from the current Shortcode API: Eventually WordPress Core could disable the old Shortcode API by default (allowing site owners to re-enable it, perhaps using an MU Plugin, with the knowledge that it’s no longer recommended) while plugin and theme developers could update their code to support the new feature (their motivation to do so will be that future versions of WordPress won’t have the old Shortcode API enabled).

    • markkaplun 5:48 am on September 3, 2015 Permalink | Log in to Reply

      [might not be needed after so many comments but…] I want to also voice my opinion against the proposed. I can see how software developer *might* be happy with this kind of syntax but this is very far from freely written text. The need to balance the number of braces is a no go, it is just too easy for my cat to erase one of them and making me waste an hour trying to figure out what is wrong because it will not look obvious. I actually don’t feel too strongly about the syntax of the complex variants, as they require some kind of programming state of mind, but the self closing one should be extremely simple.
      In addition, The use of the $ sign for anything in this context is ridiculous. In free written text it indicates some reference to money or value and the reason it used in regexp is because it is used in free text but rarely in programming.

      Proposals
      1. Whatever is the final syntax, syntax highlighting for shortcodes should be part of both the tinymce and the “text” editors. This will make it easier to identify shortcode and find broken ones.

      2. Since this will be such a big chagne, might as well fix [the lack of] permission checks. On a multi author site everyone can use all shortcodes. There is no reason why a contributor should be able to insert a contact form via a short code. Sure the editor is supposed to review and remove it, but there is no point in giving the ability in the first place.

    • umchal 6:21 am on September 3, 2015 Permalink | Log in to Reply

      The biggest problem of shortcodes from my view is that they remain in the posts even after the plugin which uses the shortcode gets uninstalled.

      I suggest using the HTML comment syntax.

      • HTML

      This way, users do not have to concern about removing them form the post. I suggested this a while back (https://wordpress.org/ideas/topic/commentcode-alternative-to-shortcode).

    • Florian Girardey 7:04 am on September 3, 2015 Permalink | Log in to Reply

      How can you possibly want to break a lot of websites with 4.7 with end of support of the current shortcode syntax and absolutely rejecting the idea of using a recent version of PHP…

      I like the idea of improvement and this roadmap is a good idea but i don’t understand the logic behind the WordPress team right now.

      • BrashRebel 12:43 pm on September 3, 2015 Permalink | Log in to Reply

        If you want to understand, read the whole discussion. In particular @nacin‘s comment https://make.wordpress.org/core/2015/09/02/shortcode-roadmap-draft-one/#comment-27484

        • Florian Girardey 5:51 pm on September 3, 2015 Permalink | Log in to Reply

          I understand why this roadmap is necessary and i absolutely agree.

          But the arguments advanced for such a changement are closely the same that a PHP version update, i don’t understand how the WordPress team can accept this roadmap but also refuse a PHP version update. That’s all

          • Ipstenu (Mika Epstein) 7:18 pm on September 3, 2015 Permalink | Log in to Reply

            While I understand the comparison, it’s a logical fallacy.

            A minimum requirement is just that. A minimum. WP’s minimum is PHP 5.2.4 and MySQL 5.0.15. We still say mod_rewrite is optional. Supporting older versions doesn’t make the codebase insecure in and of itself, and there is no external dependency update that can fix the current security issues with shortcodes.

            The point of this post is to ensure, when we do fix shortcodes, we do it in as graceful and as minimally intrusive a way as humanly possible. To not repeat the shortcode sins of the past. Your concern, while well meaning and valid, has a marked tendency to detract from that.

    • Cristian Antohe 7:10 am on September 3, 2015 Permalink | Log in to Reply

      We’re using Mustache template tags in both our plugins and I can tell you {{tag}} is in no way simpler then [tag]. Once you start adding {{!tag}} or {{^tag}} HTML {{/tag}} things start to go wrong fast. Users simply have a hard time understanding how that works.

      Start to mix up template brakes like [{{tag}}] and that’s just stupid. It’s un-intuitive and will give a lot of headaches to ALL plugin developers who also actively support their plugins.

      • Cristian Antohe 7:19 am on September 3, 2015 Permalink | Log in to Reply

        With these more unique delimeters, we will be able to process registered shortcodes more efficiently because we will not have to search for them by name. Unregistered shortcodes will have more consistency because we can find them more accurately.

        The new syntax is making it harder for users to use shortcodes for the sake of developers who have a hard time working around the constraints that come with using [tag].

    • leemon 7:25 am on September 3, 2015 Permalink | Log in to Reply

      Sorry to say this, but that new syntax is hideous. If this goes forward as it stands, I predict major breakages, lol

    • Mike Schinkel 8:08 am on September 3, 2015 Permalink | Log in to Reply

      Reviewed all the comments and did not see anyone suggest what @cfc suggested on @miqrogroove‘s blog post which just use Custom HTML Elements:

      http://www.miqrogroove.com/blog/2015/shortcode-v44/#comment-515

      They seem perfectly suited for this:

      http://w3c.github.io/webcomponents/spec/custom/#custom-element-lifecycle

      What would they look like?

      Old Shortcode: [foo]bar[/foo]

      New Shortcode: <wp-foo>bar</foo>

      One I saw that idea by @cfc everything else seemed like painful overkill. Besides, shortcodes are very closely aligned with the goal of the custom HTML element proposal with shortcodes being server-side and custom HTML element being client side.

      • Benny 5:56 pm on September 3, 2015 Permalink | Log in to Reply

        I like the idea of custom HTML elements / web components replacing shortcodes. But that still means we can’t phase out the old shortcode syntax because it would break so many sites. How would you suggest to solve that problem? Maybe by adding you’re “You are doing it wrong” notices (for ever)?

      • Michael Davis 10:53 pm on September 3, 2015 Permalink | Log in to Reply

        I hope this gets more discussion. Particularly, what would be potential shortcomings of this method compared to what the new syntax would bring.

      • Knut Sparhell 1:18 am on September 4, 2015 Permalink | Log in to Reply

        I like this idea of custom HTML elements. Registered elements gets executed either server-side or client-side. An advantage is that it’s quite obvious that such elements can’t be used in attribute values, and attributes can’t contain such elements.

        What has to be solved is the slow deprecation of the old shortcode syntax, and if old shortcodes should be replaced upon upgrade, at some point.

        I also look to the more tag and page tags, that are HTML comment tags. When shortcodes was first introduced I was surprised the HTML comment tag was not considered.

        Custom HTML elements seem very future proof, outright elegant, even if the draft never becomes a recommendation or they will never be supported by browsers (for the client side types).

      • webaware 11:09 pm on September 4, 2015 Permalink | Log in to Reply

        Much love. Was thinking about how NextGEN Gallery does its galleries these days (as a decorated image tag it parses out), but this sounds even better.

      • Braad 12:57 am on September 5, 2015 Permalink | Log in to Reply

        +1 for web components. Great idea Mike!

    • chrishoward 8:24 am on September 3, 2015 Permalink | Log in to Reply

      Sorry, I see these new syntax changes as ridiculous.

      The current syntax is untidy and cumbersome enough, and now you want to throw all these braces in it? We should be making shortcodes easier to use, not harder.

      Have you forgotten the user totally?

      These are great for coders. We love “mustaches” and parameters!

      But I pity the user having to key in a multiple-enclosured shortcode.

      Personally, I believe shortcodes should be invisible to the user, just as HTML is. Show the code in text mode, sure, but not in WYSIWYG. In WYSIWYG mode shortcodes should only be entered via a button and form, and then represented in full if possible (like the gallery shortcode) or by a clickable icon.

      For day-to-day users, this new syntax is a big step backwards.

    • asarosenberg 8:45 am on September 3, 2015 Permalink | Log in to Reply

      I agree with previous comments that this suggestion is very bad for users. People can understand shortcodes if they are somewhat familiar with HTML or online forums but the suggested syntax is unreadable to anyone who is not a programmer.

      An easier way to solve the problem with wanting to use brackets for other things is to allow people to escape brackets for example by ignoring brackets prefaced by backslash, star or whatever char that makes sense. If you want WordPress to be a CMS and not just a blog tool, shortcodes are more important than brackets in text.

      As for deprecation and conversion consider that there are shortcodes in meta fields. Many themes use page templates with multiple wp_editors and shortcodes. To avoid massive sudden breakage the old format should work for at least a year or two after the changes have been implemented and announced.

    • Arunas Liuiza 9:07 am on September 3, 2015 Permalink | Log in to Reply

      While I do get the technical reasoning behind this proposal, but I am really worried changes like that will soon make WordPress only usable for people with PhD in Computer Science. Seriously, I think something like 简shortcode简 would be easier to use and understand than the proposed syntax for the average WordPress *user*.

    • andreasnrb 9:27 am on September 3, 2015 Permalink | Log in to Reply

      The first thing I think that should be done before even touching or discussing syntax is to clearly define the purpose of shortcodes and come up with appropriate use cases.
      And just to ignore my first statement. Why not go in other direction and introduce custom HTML tags instead? You register your tag, what attributes it accepts with sanitation callbacks.
      <wp-button href=””>Click me</wp-button>
      register_tag(‘button’,array(‘href’=>’esc_url’))
      Even makes it possible to integrate with HTML5 custom tags later on.

      • andreasnrb 9:31 am on September 3, 2015 Permalink | Log in to Reply

        Yes I know it encodes when written in the HTML window. So it should be combined with a insert button in the menu.

    • HasinHayder 11:56 am on September 3, 2015 Permalink | Log in to Reply

      Now you need a Ph.D in CS to use WordPress 🙁

    • FolioVision 12:11 pm on September 3, 2015 Permalink | Log in to Reply

      I see that doing this will open new possibilities, but I think the basic shortcodes should stay without change:

      Self-Closing: [shortcode]
      Attributes: [shortcode attr1=”value1″ attr2=’value2′ “value3” ‘value4’ value5]
      Enclosing: [shortcode] HTML [/shortcode]
      Escaped Code: [[shortcode]]

      If you want to add more features (like nested shortcodes here), I think yout can do it without breaking too much stuff:

      Multiple Enclosures (this one should work if they could look for closing tag for [shortcode] – a regex won’t suffice though): [shortcode] HTML [encl2] HTML [encl3] HTML [/shortcode]

      I’m not sure about the rest though, but these special cases could probably use the new syntax:

      Stripped Unregistered Code: [{{randomthing}}]
      Stripped Unregistered Enclosure: [{{randomthing}$] Content also stripped. [${randomthing}}]
      Stripped Empty Code: [{{ }}]
      Ignored Orphan: [{{shortcode}$]
      Ignored Orphan: [${shortcode}}]
      Ignored Orphan: [${encl2}$]
      Ignored Context: [{{shortcode
      }}]
      Ignored Context:

      Do you see any issue with keeping the basic shortcodes unchanged?

    • jakeparis 12:46 pm on September 3, 2015 Permalink | Log in to Reply

      I think that the new syntax is difficult and burdensome to the average user. I would suggest:

      a) Make at least the basic “Self-Closing” shortcode operate without the brackers (just as it does now).
      b) The “Enclosing” style should close with a slash, not a $. There is not precedent for using a $ as a closer in any programming language that I know of — therefore that makes this difficult to remember. The slash it a much better choice.

    • J.D. Grimes 1:26 pm on September 3, 2015 Permalink | Log in to Reply

      I do not know how serious the security implications might be, but perhaps we could avoid removing the old syntax at all, and just disable it on new sites, like we’ve done with other deprecated features.

      I think the real lesson here though, is that shortcodes don’t need to be fixed, they need to be removed. We would still have to figure out how to maintain some amount of backward compatibility for old sites, but it might be more productive to work on a broader roadmap that would actually make shortcodes obsolete. Others, including @nacin, have hinted at this. Is a syntax overhaul really necessary as an intermediate step? Is it even plausible as an intermediate step? What if instead we approached it like this:

      1. Bring Shortcake (or some other “shortcode UI”) into core. This would still use the shortcode API, but would provide a UI for it so the user never has to directly manipulate the shortcode string.
      2. Start using an alternate, secure method of indicating the insertion points of the different content bits when this UI is used.
      3. Disable the shortcode API on new sites.
      4. Let the old sites get slowly broken and hacked over time, or break them ourselves all at once with an update.

    • JakePT 2:28 pm on September 3, 2015 Permalink | Log in to Reply

      I’ve got a couple of things I want to say. Firstly, I really need clarification on what these security issues with Shortcodes are. I read the post on the 4.2.3 change and it didn’t really help. Maybe it’s because it’s happening in an area of WordPress development that I just haven’t stepped into, but I’m having trouble understanding what contexts Shortcodes are a problem in. Isn’t their output defined by the plugin? Why isn’t the security problem with the *plugin*? Aren’t authors the only ones who can use them anyway? What could they do with them that’s so bad? I’m having trouble accepting such a drastic proposal when it doesn’t come with a clear rationale.

      But my biggest problem by *far* is that this would be so so so much easier to swallow if there was *any vision at all* for the future of the content editor. A single TinyMCE field just doesn’t cut it anymore. What happened to the content blocks idea that came up around 3.8/3.9? WordPress needs to address the problem of editing and creating more complex layouts, not breaking functionality that is only being abused because of this lack of vision and progress.

      Shortcodes suck, but don’t make them suck more without something better to replace them.

    • Stefano Aglietti 3:02 pm on September 3, 2015 Permalink | Log in to Reply

      I don’t know if someone already rised the question, but apart that making shortcode delimiter like the ones propose make user in a complicated situation.

      Maybe english people don’ìt know that { and } are not present in alla keyboards directly as the [ and ] are, in Italian keyboard [ and ] are generated using ALT-GR+è or ALT-GR++ and keyboards show ALT-GR basic sign like €@## and [ ].

      To get { and } you net to type ALT-GR+SHIFT+è and ALT-GR+SHIFT++. Most people don’t know about this combination (i think only who write code does) and the parentesys are not written on any key.

      This change would be a a really complication for italian users and i supect a lot of non english keyboard suffer from the same problem. Please when you think to change something like this for end users, use ALWAYS the KISS Method, [{{ is not KISS at alli suggest adding after the square bracket somthig that is awailable on alla keyboards like ! or ? or % or & but for sure nothing is really hide in system and that 99% of people ignore that existes or how to get it leke curly braces

    • Curtiss Grymala 3:04 pm on September 3, 2015 Permalink | Log in to Reply

      First of all, let me say “Thank you” for beginning the process of thinking about this issue.

      As we begin to move forward, has anyone thought about trying to identify where & how shortcodes are currently used, then trying to come up with the best solution for each of those situations? Maybe a shortcode isn’t the best solution for all of the situations in which it’s being used; it’s just the only viable solution we’ve had up until now.

      The bottom-line is, we are still going to need placeholders of some sort within WordPress. There are perfectly reasonable uses of placeholders, regardless of the syntax they use.

      Some are within HTML tags, such as <div class=”[my-custom-class extras=’one-third first’]”> or <img src=”[some-img-url]” alt=”This is my awesome image”/> or <a href=”[my-home-page]” title=”Return to [my-site-name]”>. There are perfectly valid & viable reasons to need to use some sort of placeholder inside of HTML (even if it’s not necessarily inside of the Visual Editor). If we stop allowing these sorts of things, then we’re going to end up with more plugins implementing silly things like [custom-html tag="a" href="{{home-page}}" title="Return to {{site-name}}"]Go Home[/custom-html] which will introduce potentially even bigger security issues and more usability issues for the users.

      Some stand on their own, such as We currently have [number-of-users] users on the site.

      Some output HTML, such as .

      Some are, IMHO, poor attempts to get around security restrictions in the editor, such as [iframe] (there are many plugins that implement this, by basically allowing the editor to enter an HTML tag in normal syntax, but replacing the < and > with square brackets).

      Some need to be nested in order to work properly, such as something like:
      [accordion]
      [accordion-title]My accordion item title[/accordion-title]
      [accordion-content]Some content to appear within the accordion item[/accordion-content]
      [/accordion]

      Some are also completely related to formatting the content, attempting to “fix” the problem of only having one content area, and trying to keep editors from needing to enter HTML on their own, such as the various implementations of column shortcodes (this is a very similar reason that implementations like the accordion shortcodes above exist, as well).

      There are many more perfectly valid & useful implementations of the current shortcode API.

      Each of these may have a completely different and much better solution than the others.

      Finally, as WordPress has evolved very, very far from a simple blogging platform, we need to stop thinking that post titles and post content are the only features that people are using.

      There are plenty of places where shortcodes might appear within the Options table, possibly even inside of serialized data. For instance, shortcodes could, potentially be used within widgets or theme options.

      Shortcodes could absolutely be used, within plain-text or serialized data, within the postmeta table (there are a ton of places that custom fields on a post could include shortcodes) or possibly even the usermeta table.

      The problem I see with the original discussion we had after 4.2.3, and the problem I see with some of the comments on this post, are that there still seem to be people saying “You shouldn’t have used shortcodes to do that; that was stupid, so it doesn’t matter if we break them.”

      The thing I appreciate about this original post, regardless of the fact that the proposed solutions are certainly more complicated than they should be, is that the core team is back to at least trying to solve the issue rather than continuing to feel like it’s okay to break sites just because they disagree with the use-case.

      Again, though, I want to thank @miqrogroove for bringing this to the table and beginning the process of trying to move forward.

    • Stanislav Khromov 5:01 pm on September 3, 2015 Permalink | Log in to Reply

      I’d like to echo the dismay most people feel with this proposed roadmap, and also stress that this can cause a fragmentation in the WP ecosystem.

      Consider that it’s easier than ever to not keep WordPress up to date with the latest version – security patches are backported all the way back to 3.7 and minor security fixes get applied automatically.

      By introducing big, “scary” changes that people feel uneasy about (which the comments prove include even seasoned developers), many will just not update. Consider the kind of fragmentation Python faced after they introduced syntax changes in version 3. Most people just didn’t want or need these changes. I feel the same way about this proposed roadmap.

    • Grant Palin 5:07 pm on September 3, 2015 Permalink | Log in to Reply

      One other gripe I have with the current shortcode syntax is that it sometimes confuses Markdown. Particularly when using within posts authored using WP-Markdown plugin. There’s a workaround, but still.

    • Jacob Santos 8:59 pm on September 3, 2015 Permalink | Log in to Reply

      Why was shortcodes added and what problem did they attempt to solve? What was their original purpose?

      The reason it is a bad idea is that it neglects the reason shortcodes were created and why they have the syntax they do. The history for the most part, I believe, was based in part on BBCode. If Handlebars existed and was more popular, then who knows.

      You will always have a security issue. Tough, but true. Introducing a wholly obtuse syntax will not change that and will make it more difficult for users and developers. Most likely you will just see an influx of plugins that put back the same behavior or those who move away from shortcodes altogether. It will also be a slap in the face once another security flaw is discovered.

      Unless you wish to remove the security issue by pushing people away from using shortcodes completely or creating their own solutions of various quality for security.

      The timeline is far too short. If you go back as far as 3.7, then you must follow that pattern. Deprecate it and update it if you can, but you must support the current until 2018 or 2 years after 4.4 is released.

      • Jacob Santos 9:06 pm on September 3, 2015 Permalink | Log in to Reply

        Lest my argument be misconstrued; I am saying that any syntax change is a bad idea. Solve the security problems with the current or work around them. The bed is made, you have to deal with it.

        Biggest problem I have is that it looks like you are creating a new template engine. There are already those that exist. It would be better if you used them as several have already been audited by security professionals or could be audited by security professionals. They also have a community and those that support it outside of WordPress.

        If you are going to introduce a template engine to WordPress posts, which in and of itself is charge to be warily, you are better off going with something developed by professionals.

        Shortcodes were supposed to be an easy replacement for plugins without a lot of features. When did it become the end all, be all to implement a feature?

        If anything, the RFC should formally suggest where shortcodes should and should not be used, deprecate those usages and at a later date, remove support for them. If advanced templating is required, move to an actual established templating engine. Oh my god, I can’t believe I’m writing this.

        I must be in shock, because the horror of this is just beyond comprehension. I can’t imagine the discussions or the problems that lead to, “hey, why don’t we create a template engine for posts?”

        I have to conclude that this is an early or late April Fool’s joke.

    • chriscct7 2:44 am on September 4, 2015 Permalink | Log in to Reply

      As an update, the team working on the Shortcodes Roadmap, has been working on a new draft proposal which will be posted to make at some point in the near future, which is significantly different than Draft 1. Also, there will be a weekly meeting that will be announced during the same post.

      • John Teague 2:10 pm on September 4, 2015 Permalink | Log in to Reply

        Thank you Chris. And to everyone working to find a solution on this. Hope people realize how much time and effort has to go into this.

    • Ustimenko Alexander 4:45 am on September 8, 2015 Permalink | Log in to Reply

      Users must not pay for developers weakness. If you want something stron-n-cool, then incorporate twig syntax here, but this all is for DEVELOPERS an dnot for users. This syntax is super-extra-bad-thing for end user.

    • renzms 11:57 am on September 17, 2015 Permalink | Log in to Reply

      I’d also like to join in to say that this is more of a step sideways rather than forward/backward with this proposed roadmap.

      Whether a seasoned developer, or just a regular user with no coding experience, these shortcodes aren’t in any way user or developer friendly.

      I understand this is a draft, and a new proposal will be made, especially after all the sentiment seen here. So thanks for the warning, and not changing anything right away as drastic as this. I know this proposed change is due to a security issue, but it causes more problems down the road that developers/users just might not use WordPress anymore to begin with. I do hope a simpler and more unified solution is found.

    • Tom Belknap 8:08 pm on December 15, 2015 Permalink | Log in to Reply

      This isn’t quite such a draft when you consider that 4.4 is already here and already, it’s messing up my shortcodes. Specifically the nested ones.

      This might be the worst proposal since the rightfully-maligned “Settings API,” an innovation the devs needed to ditch in favour of the Customizer. How error-prone is this syntax?

      `[{{shortcode}$] HTML [${encl2}$] HTML [${encl3}$] HTML [${shortcode}}]`

      I thought this double curly brace business must have meant that you were calling out the things we were supposed to change. Then I saw you were serious about it.

  • Ryan Boren 4:43 pm on September 2, 2015 Permalink
    Tags: , maintainership   

    Component Page Updates for 4.4 

    Now that 4.4 is underway, let’s update the component pages to reflect 4.4 activity. The Customize, Editor, and Press This pages serve as good templates, though they all need 4.4 updates. The component pages are targeted at beta testers. They should describe the component, list milestones (roadmap), and explain what needs testing and how to test it. Good component pages assist triage. For details, see the previous round of component page updates.

    Also, if your component has a corresponding Slack chat, link to the component page from the chat’s channel topic. This assists using Slack in beta testing flows.

    Component maintainers, here are your component pages…

    (More …)

     
  • Tammie 2:51 pm on August 25, 2015 Permalink
    Tags: , ,   

    Introducing Twenty Sixteen 

    WordPress 4.4 will see a brand new default theme; that’s right, today is time to meet Twenty Sixteen! The process of selecting the Twenty Sixteen theme was a long one, taking several months. Lots of themes were considered, eventually settling on the one you see below. It’s a perfect fit!

    00.twentysixteen

    Twenty Sixteen features a new, never-released design that has some really unique touches on a traditional blog layout. It adapts well to different devices and is a joy to use.

    Twenty Sixteen is a modernised approach of an ever-popular layout — a horizontal masthead and an optional right sidebar that works well with both blogs and websites. It has custom color options that allow you to make your own Twenty Sixteen. The theme was designed on a harmonious fluid grid with a mobile first approach. This means it looks great on any device.
    @iamtakashi

    Let’s take a look at more!

    We have the pleasure of welcoming back Takashi Irie as the designer of Twenty Sixteen. This year, the core team developing our new default theme will be myself and @iamtakashi — and you! We hope you can join us in getting Twenty Sixteen out to the world. Along with us, @iandstewart and @samuelsidler will be making sure the ship stays on course and giving us their wisdom as we charter the default theme seas.

    How can you get involved?

    There will be weekly meetings every Monday and Friday 16:00 UTC in #core-themes for half an hour. These weekly meetings will start once the theme has initially landed in core. If you are interested in contributing, subscribe to this blog (if you haven’t already), and leave your name in the comments. Once we’re ready, we will give everyone a ping and we’ll let you know on this blog too.

    Want to know more about default themes?

    There are some great links where you can find out more about past default themes.

    The road to releasing a new default theme is long, but we’re already well on our way! The next step is to commit the initial code to core. From there, we will begin testing and patching. We hope you join in the adventure of releasing Twenty Sixteen.

     
    • Nikhil Vimal 2:54 pm on August 25, 2015 Permalink | Log in to Reply

      I would be interested in helping!

    • Frankie Jarrett 2:57 pm on August 25, 2015 Permalink | Log in to Reply

      Pretty 🙂

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

      Congrats all around!

    • Ciprian 3:11 pm on August 25, 2015 Permalink | Log in to Reply

      I still think it looks a bit outdated. The default themes should be more modern, more 2016ish.

      • Mattias Tengblad 3:38 pm on August 25, 2015 Permalink | Log in to Reply

        +1

      • Paal Joachim Romdahl 4:55 pm on August 25, 2015 Permalink | Log in to Reply

        Agreed.

      • Arnan de Gans 6:21 pm on August 25, 2015 Permalink | Log in to Reply

        Yep, this looks like a 1998 html page 🙁

      • WTech 6:29 pm on August 25, 2015 Permalink | Log in to Reply

        +2 (imho 2014 is better)

      • Matt Mullenweg 11:52 pm on August 25, 2015 Permalink | Log in to Reply

        For the folks who think it looks old, definitely share some links to themes you think are more modern, it could be a good inspiration for twenty-seventeen (which is just around the corner).

        • waltson 5:37 am on August 26, 2015 Permalink | Log in to Reply

          Hi Matt .Really thanks for giving a chance to interact with you .I like wordpress, and i am working on it from few months .I like the 2016 theme. But please see the below points

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

          (2)Captcha support by default

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

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

          The most important ting is that please give some importance to https://wordpress.org/ideas/view/latest , because we only have this place to express our ideas . It would be very happy if we get correct reply and concentration from the wordpress team .

          I am looking forward to your reply.

          Thank you .

          • Paal Joachim Romdahl 8:12 am on August 26, 2015 Permalink | Log in to Reply

            Hi Waltson. A better place to post what you wrote would be in the “WordPress 4.4: What’s on your wishlist?” thread further down this page.

            • Sam wc 9:08 am on August 26, 2015 Permalink

              But Paal , these are some good ideas .Why we waiting for implement this in WordPress 4.4 . If these ideas make sense and it is important it can be implemented int he very next WordPress update.

            • Aparna123 9:25 am on August 26, 2015 Permalink

              Waltson is right

            • Sam wc 3:04 pm on August 27, 2015 Permalink

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

          • Aparna123 9:23 am on August 26, 2015 Permalink | Log in to Reply

            Good things Waltson.Generally there is lack of form handling and validating function in WordPress.Captcha is also important .

        • Adrian Pop 1:08 pm on August 26, 2015 Permalink | Log in to Reply

          I also think is kind of an oldish design – forget about sidebars! I really like Satellite (https://wordpress.org/themes/satellite/) and Ryu (https://wordpress.org/themes/ryu/) is one of my all-time favorite – Thaks Mr. Takashi 🙂

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

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

        • transl8or 5:11 pm on August 27, 2015 Permalink | Log in to Reply

          I don’t think it looks old.
          It’s very very classical, kinda puristic und could be quite elegant with good pictures.

          Nevertheless I have two concerns about this theme:

          • The Frame; especially when it’s black, the site could somehow look like a newspaper obiatury.

          So I hope the customizer options will support a checkbox or simular to switch the frame on or off.
          Or maybe even have it only left & right vs. top & bottom.
          Or just choose the frame color individually so that it will be the same as the background color.

          • The Primary Menu; especially in the desktop version.

          I’m often very unhappy with lot’s of menus within WordPress Themes because they seldom look kinda “design consitent” for the whole site nor for bigger websites with lots of pages (not blogs, with mainly posts and infinite scroll).
          The later comes mostly with horizontal menu.

          — —

          As a suggestion for this theme, I could imagine a “sidebar integrated” menu, like you can see it in the Ascetic theme see here:
          http://demo.alienwp.com/ascetica/
          Could be a challenge with a full-width page, or pages with full-width header-image though.

          Or a menu like the Materialist Theme uses, see here:
          https://wordpress.org/themes/materialist/
          But on the upper right side.

          I like simplicity of the menu in the Libre Theme and the Theme in general;
          but it still has the issue of going “white over white, or even over content” when you create a site with a menu that has loads of items and levels.

          — — —

          Talking about the Materialist Theme brings me to the next topic.

          A more modern design approach for Twenty Seventeen?!?

          How about Material Design, Semi Flat Design, more colorful options and/or a “lighter, thinner, more playful & transparent look” for the menu/navigation, input-form elements and fonts.
          Oh, and I’d like to see an option in the Customizer for the primary menu to either be a “fixed navigation bar” or not more often.

          Examples:

          http://www.nuabikes.com/

          http://www.brindisatapaskitchens.com/

          http://revelator.com/

          http://www.wonderfullywild.co.uk/

          https://niice.co/

          http://branding.cards/

          http://simplehonestwork.com/

          http://evandorlot.com/portfolio/naaataa-fashion-branding/

          Google Resources on “Material Design”:

          https://www.google.com/design/spec/material-design/introduction.html

          🙂

        • sonofara 2:46 am on August 28, 2015 Permalink | Log in to Reply

          20Sixteen is clean, responsive and is definitely a perfect startup template which can be transformed into an eye catching website.

        • wimfeijen 8:49 pm on October 29, 2015 Permalink | Log in to Reply

          Hi Matt,

          To me 2016 looks stylish, elegant and indeed a bit old-fashioned.

          Our customers especially like Big Point. For example see: http://ttcmobile.com/ . In our designs we like to look at websites like uber.com , airbnb.com and always apple.com . Meaning big pictures, clear menu, big header text explaining what the site is about and clear call to action button.

          Good luck in creating another awesome theme!

        • hussong 8:40 am on December 9, 2015 Permalink | Log in to Reply

          Chiming in a bit late here, I’d like to point out that twenty-sixteen looks a lot like the Cutline Theme from ten years ago (which I loved at the time): http://cutline.tubetorial.com/

          That being said, I’m really excited about 4.4 and what’s happening under the hood there (srcset in particular) and want to say thanks so much for keeping WordPress awesome!

      • chrishoward 5:50 am on August 26, 2015 Permalink | Log in to Reply

        Yes. Reminds me of 2012.

        I think the main prob is the sidebar. That sort of stuff is all in footers in modern designs.

        • chrishoward 5:51 am on August 26, 2015 Permalink | Log in to Reply

          I meant, reminds me of TwentyTwelve theme

        • WisTex 2:25 am on November 29, 2015 Permalink | Log in to Reply

          The sidebar is optional, but needed for certain types of websites, especially those with a large amount of interconnected content.

          You can get away without having a sidebar on a sales website, and websites that don’t have a lot of content, but navigation becomes a nightmare once you have hundreds or thousands of pages of content to navigate.

          If you are trying to direct people to a specific call to action, a website with no sidebars is better since it creates a flow. If you want your website to be sticky and people to stick around for hours, then properly used sidebars help tempt them into viewing more content.

      • stuk 3:22 pm on August 26, 2015 Permalink | Log in to Reply

        +1

    • Lara Littlefield 3:16 pm on August 25, 2015 Permalink | Log in to Reply

      I’m so excited to have photos displayed in such a unique way like this in a default WordPress theme. 2016 is beautiful!!

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

      Woohoo! I’ve still got that musician bias – like Twenty Fifteen, this looks like it can serve as a really solid base for portfolio sites, especially with some creative thinking around colors and content.

    • web2033 3:23 pm on August 25, 2015 Permalink | Log in to Reply

      Happy new 2016 ^_^

    • Mel Choyce 3:24 pm on August 25, 2015 Permalink | Log in to Reply

      <3

    • Matthew 3:26 pm on August 25, 2015 Permalink | Log in to Reply

      awesome stuff

    • Philip Arthur Moore 3:27 pm on August 25, 2015 Permalink | Log in to Reply

      Happy to help do some theme breaking. Can’t wait to see this land. Takashi’s designs…are they ever not amazing? Another hit; cannot wait to see this on millions of sites. Great work gang.

    • Ihor Vorotnov 3:35 pm on August 25, 2015 Permalink | Log in to Reply

      One more blog theme with a font that looks ok only with latin characters? Looks nice, but… Come on guys, there’s life outside US. There are other languages out there. WordPress is not only for blogs anymore.

    • Ajay 3:40 pm on August 25, 2015 Permalink | Log in to Reply

      This is definitely looking very clean. Twenty Fifteen was OK look wise, but this definitely looks like a worthy base for any new site.

    • Nick Halsey 3:48 pm on August 25, 2015 Permalink | Log in to Reply

      I’m honestly not a fan based on the screenshots, but that’s okay – even a default theme shouldn’t try to satisfy everyone. Something feels off with it for me.

      Based on the way the colors seem to work, again based on the screenshots, we should probably explore making the text colors auto-generate to light or dark based on the selected background color, for simplicity and to minimize contrast issues. The Fourteen Colors plugin for Twenty Fourteen does something similar.

    • Chrisdc1 3:51 pm on August 25, 2015 Permalink | Log in to Reply

      Looks good, I’d be interested in helping as well,

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

      I’d love to contribute.

    • Sakin Shrestha 4:03 pm on August 25, 2015 Permalink | Log in to Reply

      Looks really nice and clean. Would love to contribute… Thanks

    • Donna Fontenot 4:18 pm on August 25, 2015 Permalink | Log in to Reply

      This is exactly what WordPress does NOT need. Another boring, snoozefest old-school blog layout. Wake me when WP joins the rest of the world in 2015 and beyond. (BTW, I tried really hard to come up with a nice way to say that, and I just couldn’t, so here is the comment in all its straight-forwardness.)

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

      Let’s get some alt text in that image gallery! #a11y

      There are some really nice touches in the screenshots. I like the pull quote a lot (though wonder how it will be applied with the editor).

      At some point, I’d love to hear the core team be a little clearer on how the new theme is selected and why there have been two blog themes in a row. (It also might not be too late to add an interesting static front page option to Twenty Sixteen to make it more versatile!) I tend to follow this stuff and had no clue this process was happening. I certainly understand the need for fewer cooks in the kitchen, but at least letting some more people suggest ideas for priorities might be nice. Maybe even a poll or two.

      I’ve heard for years now many people clamoring for a “new Twenty Twelve” and still hope to see another “CMS” theme as a default soon. (It’s remained quite popular: https://docs.google.com/spreadsheets/d/1UV4UGFCdTdNhK8v7l9s6J0uI5Y-QMRocSET63NO3CVc/edit?usp=sharing)

      • Nick Halsey 7:11 pm on August 25, 2015 Permalink | Log in to Reply

        You’re not missing anything – there is a complete lack of transparency in the default theme process prior to the “announcement” posts. Even frequent contributors have heard absolutely nothing about it prior to today.

        My biggest complaint is that we have now had the same designer do the last three default themes. Takashi’s work is amazing, but it’s definitely time to give someone else an opportunity to fill this role as has been done in the past. Since the extremely outside-the-box Twenty Thirteen, we’ve gone back to progressively less and less compelling designs with each default theme.

        • MRWweb 8:59 pm on August 25, 2015 Permalink | Log in to Reply

          > Takashi’s work is amazing, but it’s definitely time to give someone else an opportunity to fill this role as has been done in the past.

          I agree. Even if Twenty Fifteen—which I like quite a bit—were by the objectively best designer in the world (that is not a thing, but for the sake of argument…) the core team should be doing more to promote and diversify the designers who show what WordPress can do and be. The idea that there aren’t other designs who can do this—and wouldn’t drop all sorts of other commitments if given the chance!—just doesn’t make sense.

          I hate being negative in what is an otherwise worthwhile celebratory post and call-to-action, but I really hope this can stop being so untransparent and homogenous.

      • wimfeijen 8:55 pm on October 29, 2015 Permalink | Log in to Reply

        +1 Nicely put! TwentySeventeen should be the new Twenty Twelve!

    • Felix Arntz 4:26 pm on August 25, 2015 Permalink | Log in to Reply

      Plain and simple – and great. Looking forward to replace Twenty Fifteen on my blog 🙂

    • Emil Uzelac 4:30 pm on August 25, 2015 Permalink | Log in to Reply

      So Fresh, So Clean!

    • Nilambar Sharma 4:31 pm on August 25, 2015 Permalink | Log in to Reply

      Simple and nice. I am willing to contribute… 🙂

    • voldemortensen 4:48 pm on August 25, 2015 Permalink | Log in to Reply

      Is there a way to get involved with this *before* it lands in core? I am a frequent core contributor and I have Slack open all day. I’ve heard nothing about this until literally a few minutes ago.

    • Shapeshifter 3 5:12 pm on August 25, 2015 Permalink | Log in to Reply

      “The theme was designed on a harmonious fluid grid with a mobile first approach. This means it looks great on any device.”
      @iamtakashi

      I like the concept !

      Is there any way to download the current alpha version of this, so I can upload it to my own website to preview it with my own personal content?

      I’m interested to know what the current Theme Customizer currently offers in Content (width) and Layout options.

    • Orangedrop 5:16 pm on August 25, 2015 Permalink | Log in to Reply

      For once purely based on screens I don’t know if I’m down this ! That said you can’t please everybody all of the time 🙂 I would love to get my grubby mitts on it and break it a few times so please count me in ! Thanks guys and as always keep up the awesome work.

    • Brent Jett 5:39 pm on August 25, 2015 Permalink | Log in to Reply

      I’d like to know more about how this theme will be implemented in terms of customizer fields, editor styles, custom widgets/shortcodes etc… I’m a big believer in designing themes for the WP user as much as the reader. Where are these discussions currently being had? Is this project on github somewhere?

    • dannybrown 5:54 pm on August 25, 2015 Permalink | Log in to Reply

      Yawn. Sorry, but this design (as far as looks goes) is so 2012.

    • dshanske 6:15 pm on August 25, 2015 Permalink | Log in to Reply

      I would be interested in ensuring that the theme is microformats compliant.

    • Gaurav Tiwari 6:20 pm on August 25, 2015 Permalink | Log in to Reply

      Make it look like commercial themes. If WP is no longer blogging focused CMS why should the default themes be?

    • LittleBigThings 6:36 pm on August 25, 2015 Permalink | Log in to Reply

      Cool and clean, a bit Twenty Twelve-like. Hope to see some unique features in the Customizer. I would love to follow it up and help out testing.

    • Tomas Mackevicius 6:41 pm on August 25, 2015 Permalink | Log in to Reply

      Looks great! Can we see live demo?

    • Karthikeyan KC 6:44 pm on August 25, 2015 Permalink | Log in to Reply

      To be honest, twentyfourteen looks better than twentysixteen. Anyways, it’s good for the default one. 🙂

    • Tomas Mackevicius 6:52 pm on August 25, 2015 Permalink | Log in to Reply

      But 2014 was not built on _s, I hope 2016 is.

    • WebMan Design | Oliver Juhas 7:07 pm on August 25, 2015 Permalink | Log in to Reply

      Looks great, very clean! I’d like to contribute too 🙂

    • SanjayaBhai 7:10 pm on August 25, 2015 Permalink | Log in to Reply

      Twenty sixteen.. Hope it will be great…. But please make this themes more modern/Beautiful … It’s seems classic .

    • Alex Mills (Viper007Bond) 7:25 pm on August 25, 2015 Permalink | Log in to Reply

      It’s been a long time since I’ve run a default theme but I’ll be switching for this one!

    • George Stephanis 7:28 pm on August 25, 2015 Permalink | Log in to Reply

      I’m pulling for twentyseventeen to be Kubrick redone responsively. 🙂

      • Ryan Hellyer 9:42 am on August 26, 2015 Permalink | Log in to Reply

        I’ve been toying with forking Kubrick like that for many years now, but never gotten around to it.

      • Drew Jaynes 8:41 pm on August 26, 2015 Permalink | Log in to Reply

        FWIW, I already did it. I created a child theme for Twenty Twelve called Nubrick, that created a responsive version of Kubrick. The header used CSS gradients and everything else was matched to a tee with some obvious improvements. Might have it laying around here somewhere, have to look.

    • Tarik Cayir 7:59 pm on August 25, 2015 Permalink | Log in to Reply

      That’s sweet and incredible!

    • Morten Rand-Hendriksen 8:14 pm on August 25, 2015 Permalink | Log in to Reply

      Sign me up. I’ve done a lot of work with pull-images of the kind proposed here and know some of the pitfalls. I’ll contribute what I can and where it helps.

    • Valeriu Tihai 12:14 am on August 26, 2015 Permalink | Log in to Reply

      Happy to help

    • WP Sites - Brad Dalton 1:37 am on August 26, 2015 Permalink | Log in to Reply

      How about a widgetized page template which can be used as the front page. Widgets in columns are popular and so are full width sections. The genesis sample child theme is hugely popular because you can easily add custom functionality unlike any of the default themes.

    • Matt (Thomas) Miklic 2:03 am on August 26, 2015 Permalink | Log in to Reply

      This is a beautiful theme and I can’t wait to use it myself.

    • Aaron Brazell 2:13 am on August 26, 2015 Permalink | Log in to Reply

      I like the image offset a lot and I want a one-column option, so glad to see that in there. Agree with previous commenters saying it looks a bit dated, but I also don’t think that’s twntysixteen per se… I think the “blog layout”, which is a guiding principal, is a bit dated. I’d love to see twentyseventeen place less emphasis on text content, top down, left-right, sidebar, header and more of a focus on rich media. Photographs, videos, etc… with natural integrations (no external APIs) with social content (and not just FB and Twitter)… it’s such a rich internet, but the blog approach to the project might be influencing the frontend a bit much and not keeping up. 🙂

    • nick6352683 2:38 am on August 26, 2015 Permalink | Log in to Reply

      Anything, and I mean anything would be better than 2013, 2014, and 2015. I prefer 2012 over those, and 2016 seems more or less in line with 2012. The whole discussion is pretty much mute for me, as I always opt to use “premium” type themes, with tons of bells and whistles, but I’m very biased as I develop my own themes, with extra functions and shortcodes.

    • webdevmattcrom 3:33 am on August 26, 2015 Permalink | Log in to Reply

      Definitely interested in contributing, sign me up!

      I love that this does feel like it’s heading back toward a cleaner Twenty Twelve feeling. I like that the sidebar is on the right by default, but especially considering RTL it would be nice to have a Customizer option to put the sidebar on either side. In that vein, since the Customizer is getting more and more prominence it would be great to see this theme really flaunt some great aspects of the Customizer as a strong example of “Decisions not Options” while still providing flexibility in look and feel.

      Looking forward to seeing this come to life.

    • Amit Kvint 6:32 am on August 26, 2015 Permalink | Log in to Reply

      Definitely interested in contributing, sign me up too!

    • Brian Krogsgard 7:12 am on August 26, 2015 Permalink | Log in to Reply

      Is Ian Stewart the default theme lead?

      There is obviously a lot of decision making going on in regard to default theme design that nobody really knows about, and it is really confusing. It is so different than the rest of WordPress development.

      So, how would someone go about getting involved earlier in the process (at the design level!), short of going to Matt Mullenweg? I might add that going to Matt on how to get involved (though he appears the primary gatekeeper on default theme design) is likely quite intimidating for most folks.

      A lot of talented designers would probably like to get involved in this process but don’t know it’s possible or how to start. Some information and light on the process itself would be most welcome, I’m sure.

    • Philip Arthur Moore 8:55 am on August 26, 2015 Permalink | Log in to Reply

      The fact that there are so many passionate responses here is pretty cool.

      History time:

      Default themes won’t be for everyone, and ultimately I share Brian’s thoughts above. I think it’d be GREAT for 10000% transparency around the default theme making, designing, and proposal stages before posts like this are made. (Honestly it makes no difference to me personally but the community seems to benefit quite well from feeling like we have a chance to contribute to such a public and front-facing piece of WordPress.)

      But that aside, however the theme came to be, I think the first drafts shared are quite nice and absolutely cannot wait to help break things once it lands into Core. I’ve no doubt that there are some pretty serious design and development challenges that will come out of these drafts, and it’s going to be exciting to take part in that.

    • Subharanjan 9:04 am on August 26, 2015 Permalink | Log in to Reply

      Clean and Simple !! Looks awesome 🙂

    • Fotis 9:20 am on August 26, 2015 Permalink | Log in to Reply

      Perfect.

    • Ryan Hellyer 9:46 am on August 26, 2015 Permalink | Log in to Reply

      I like this new design. Simple, yet elegant.

    • stuk 10:24 am on August 26, 2015 Permalink | Log in to Reply

      To me it seems quite outdated and useless as any default theme, is it not?
      Quite clear that their intention is not to add extra features to WordPress, and indeed the basic theme can support only a maximum basic options.

      But also simply bad design. If it’s the preview we let people install with the system, so it seems bad.
      Nothing to do with new design trends.
      Despite the WordPress developers insist that the system is already more than a blogging system infrastructure, they continue to release static templates without AJAX and without REST, and yet the basic theme is a theme of a blog, not a website.

      In one word: shame.

    • David Bennett 11:42 am on August 26, 2015 Permalink | Log in to Reply

      It reminds me of Linen from TheThemeFoundry, and it has the open, airy look of themes from ElmaStudio. I like it. The only thing I wonder about are the horizontal dividers in the sidebar. The Daily Dish theme from StudioPress has black sidebar dividers overpower the theme somewhat. The dividers in The Daily Dish are thicker but if a blogger has a lot of widgets it can start to look like the i Ching.

    • Elisa 12:19 pm on August 26, 2015 Permalink | Log in to Reply

      I like it 🙂

    • CYBERsprout 1:28 pm on August 26, 2015 Permalink | Log in to Reply

      Looks great! A very modern design.

    • ldbaldwin 2:43 pm on August 26, 2015 Permalink | Log in to Reply

      I would be interested in contributing on some leve, (testing, documentation, etc.). Thanks!

    • cramdesign 2:47 pm on August 26, 2015 Permalink | Log in to Reply

      I think it looks great. The structure is a traditional setup but I think that the overall design, typography and image handling is very current. I agree that the dividers in the sidebar might be a little too heavy but, then again, that is easily changed with css and let’s be bold every now and again.

    • firewatch 3:34 pm on August 26, 2015 Permalink | Log in to Reply

      I’m interested in contributing, thanks!

    • djsteveb 9:20 pm on August 26, 2015 Permalink | Log in to Reply

      Wish all the like and dislike comments could be removed here. Give specifics or save the screen space.

      Sorry ya’ll but the default theme does not need to be any one person’s idea of pretty or modern, it’s default and certainly not the only option for anyone running wp.

      What the default themes have been lacking since 2012(?) is documentation, transparency, and support.

      All that fancy responsiveness is fine if you like things as is. Simply trying to move the left sidebar to the right with 2015 is a nightmare – I miss the days of simply change float left to float right.

      Yes I know, “modern design” is beyond that – I have learned how to move things around with bootstrap, and foundation… moving things with 2014 / 15 is a joke. No documentation, no support – no transparency with updates.

      Either given backend option for the most common changes, or make it easier for people to change things with code. Having to make edits and then change screen sizes and search for ways to change rules for each media query is a joke, with no docs, and no warnings about updates.

      Given that the default theme is the only thing we can count on that will get any kind of support from buddypress, rtmedia and other plugins – many are indeed stuck with the default theme base – pretty or not – those things can be adjusted if the options are understood, documented, supported.

      My comment on takshi’s site still waiting moderation (August 25, 2015 at 12:37 am ) – maybe it’s akismet limbo. Support on the wp repo is total confusion – even other professional sites that created right sidebar child theme break with basic background color change – is it them? Is it the theme? Was it working then an update fixed something and broke others?

      I am happy to contribute what I can (20% through my php course!) – I was planning to make a video tutorial from the text how-to for making themes at themeshaper.com – however it states it’s outdated. I stumbled across a trello that has documentation for theming in the works – but that may be finished in 2017?

      Given that the default theme has total power over so many things WP – I prefer no java, nothing complex, basic – make it easy to mod it so people can make it prettier and modern on their own. Not left in limbo choosing no support, no docs with wp plugins that work (and look basic) – or get a theme that looks better is modifiable – but then does not work with plugins and gets no love or support from plugin systems.

      Frankly the older default themes were much easier to make better. Anything default that is complex is just going to shrink the amount of WP users that can actually mod something on their own without a degree in javascript and php. You might as well force us to use sass and less and bower. Really shrink the amount of people that can enhance a basic default theme.

      Maybe pull all the extra stuff out and make it an option plugin like some do with “jetpack features” – I just want BP to work with something that can be modded – either with lots of backend theme options (colors, sidebar on, sidebar off, move to footer – basic stuff really, or easy css that the average person can figure out or get basic support from the community to figure out. (please take out all third party bloat, eg- google fonts, gravatar, emoji and put them as optional plugins, pretty please!)

      Or convince BP and rtmedia (and others) to work with / provide support themes based on bootstrap and or foundation – then the default theme can be whatever it wants to be and we can peruse the documentation for those frameworks, and make adjustments easily.

      Sorry to long rant, (and I started with ‘save the screen space – seriously sorry, very frustrated with all this!) I want to see WP, and things associated with it continue to succeed, however I concur that many of the past two years’ not-so-transparent decisions have not made this easy for most of the average users IMHO.

      • rahul286 5:40 pm on August 28, 2015 Permalink | Log in to Reply

        I am from rtMedia team.

        I like your idea of themes using a base js/css framework like bootstrap and or foundation. But our reason for supporting default themes is they work nicely with BuddyPress as well as other plugins. Mainly because many plugin developers also check test plugins with default themes.

        That being said, our inability to support most themes is mainly because most themes are not tested with BuddyPress. In fact wordpress.org only shows 28 themes that claim to support BuddyPress – https://wordpress.org/themes/tags/buddypress/ and 1 of them is default theme and 1 other (rtPanel) is our theme.

        • djsteveb 9:52 am on August 29, 2015 Permalink | Log in to Reply

          @rahul286 – Thank you for chiming in on this issue. I don’t expect your team or any other to have the ability to support every edge case theme created for wp, and I am glad you guys at least make an effort to keep rtmedia working with whatever updates get pushed by automattic at least. Your media plugin is the only reliable way for buddypress users to get picture and other media uploads, so it’s continuing functionality is imperative.

          It is sad there are so few themes tagged to work with BP – of course there are many that do work with bp and yet they are not tagged that way in the repo – and there are several that are available outside the wp org system – however my experience has been that we can not count on other themes to work with bp and rtmedia properly no matter where they are from. I have tried 24 of those you mentioned 😉

          This is exactly why I feel a new default theme must be carefully considered, and it should be easier to modify than the past two – as we are indeed basically stuck using 2014 / 2015 /2016 for bp sites or gamble with lots of things not working – and no support or docs to fix things. This is not an rtmedia fault – it’s just where things have gone with bp in general I guess.

          There are some who think my thoughts on this are 100% wrong, at least one person replying to a similar comment I made in regards to these issues at wp-tavern – ( http://wptavern.com/first-look-at-the-twenty-sixteen-default-wordpress-theme#comment-72326 ) – however I think people have not seen the amount of support that has been needed to keep self hosted wordpress sites with plugins working properly with major updates and the basic issues that revolve around the default theme, and those that vary from it, is the starting point for almost every issue bp / rtmedia and many others plugins breaking with users sites.

    • Marcus Tibesar 11:26 pm on August 26, 2015 Permalink | Log in