Ready to get started?Download WordPress

Make WordPress Core

Search Results for: gallery Toggle Comment Threads | Keyboard Shortcuts

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


    26 open tickets. Last 7 days: +1 ticket

    26 open tickets defect (bug) enhancement feature request
    Awaiting Review 3 7 3
    Future Release 6 5 2
  • Janneke 8:45 pm on August 20, 2014 Permalink | Log in to leave a Comment  

    GSoC update 

    Monday was the “pencils down” date for GSoC, and here’s a post about what I have done so far. It’s all related to the editor, but it can be divided into three parts: work on core for the editor “views” and scrolling, work on the Editor Experiments plugin, which contains further enhancements and work on a complete rewrite of the Front-end Editor, which includes both work on core and the other plugin.

    Note that everything requires at least WordPress 4.0 beta 4 to try.


    View related tickets (#28595, #28195, #28788#28913#27971#28458 and other minor tickets), better thumbnail resizing for a responsive modal (#27423), editors scrolling (#28328) and other minor things added to core the past few months.

    Editor Experiments

    The goal of this project was to make it easier for plugins to add views in the editor, for example for their shortcodes. It’s been very difficult, however, to figure out the needs and support all different scenarios. Technically it’s also not easy, since we’re working in an iframe, all the changes are tracked by TinyMCE and the DOM can get rebuild.

    As for a UI, there are lots of options for an editing interface. WordPress should provide some options, but the experience should be customisable. Ideally it should be possible to edit views straight inside the editor. E.g. for a gallery view, it should be possible to edit captions inline and rearrange images. I decided to pick a popular shortcode and see what I can do. I picked a shortcode that can display a Google Map, and it ended up like this in the editor:

    Screen Shot 2014-08-20 at 13.04.06

    You search by address, or just drag and zoom the map, change the map type etc., and it will update the shortcode for you.

    I realise the is just one case, and there are a few more necessary to figure out an API. There are also a lot of improvements needed to the view plugin in TinyMCE. Currently it is not possible to have editable text fields inside the view. It is also not possible to drag views around, let alone drag and drop items inside a view, which would be a huge deal for shortcodes that let you add form elements for example. With the “Editor Experiments” it is possible to add an “inline” toolbar to manipulate the view. Of course, you still have the option to display your own modal and update the view after it closes.

    Another goal was to experiment with the concept of content blocks and inline editing. I made a TinyMCE plugin that adds a toolbar with formatting tools when you select something in the editor and that is extendible in the same way the default toolbar is. You can create your own buttons (like you did before) and add them to the toolbar, or just any existing one. In the future, we can change the buttons based on the selection.

    Screen Shot 2014-08-20 at 13.11.01

    Screen Shot 2014-08-20 at 13.12.14

    To add a block, you have to put your cursor in an empty paragraph and the following will show up:

    Screen Shot 2014-08-20 at 13.14.42

    Clicking on it renders the block toolbar:

    Screen Shot 2014-08-20 at 13.15.22

    And this toolbar too is extendible. You can add any TinyMCE button to it, but of course only buttons that insert something will be useful here.

    Front-end editor

    The original project was called “Front-end content blocks”, but we’ve changed the goals a bit at the start to focus on the back-end editor first instead, and it kind of felt like development on the FEE has stopped in the last few months. But that’s not entirely true. All these improvements can be implemented in the FEE too. That’s why I’ve also completely rewritten the FEE from scratch and added all this stuff. The improvements include:

    • An inline toolbar for text, images and views. The fixed and always-visible toolbar is gone.
    • The “add block” toolbar to insert content. Similarly you can add a featured image.
    • The kind of buggy “view” implementation is now completely replaced with the view implementation in core form 3.9 and all the improvements I did for 4.0.
    • The editor now loads instantly on the page. No page refresh anymore. Also no page refresh on save/publish. You can simply toggle the editor on and off. It was mainly this change that required most of the rewrite…
    • Fixed and improved lots of other stuff. It’s just better if you try it yourself… Go to GitHub and clone the plugin. :)

    Something else I’ve been working on, and that is currently in the FEE, is automatic markdown conversion as you type. Not that it would be useful in the current implementation for all the syntax, but for some things it is really useful. Typing *  or -  converts automatically to a list, 1.  to a numbered list and *word* or **word** to italic and bold. :)

    I’ll publish another post soon with more information about the Front-end Editor. I’d like to do a 1.0 release soon after the release of WordPress 4.0, and any help is really welcome.

    • Stephane Daury (stephdau) 8:53 pm on August 20, 2014 Permalink | Log in to Reply

      I, for one, have to mention how valuable your contribs were, and thank you profusely for them.
      Awesome work, J. :)

    • Gregory Cornelius 9:22 pm on August 20, 2014 Permalink | Log in to Reply

      Thanks for all your hard work! I hope that you learned a few things along the way and are able to continue contributing to WordPress.

    • Matt van Andel 10:29 pm on August 20, 2014 Permalink | Log in to Reply

      One use-case that I’d like to see addressed is the concept of content separation… or having “blocks” of content that are handled separately by the theme… either by loop or by loading specific named blocks.

      The reason for this would be to make highly structured template pages easily maintainable in the admin from a single edit screen. Here’s a quick-and-dirty experiment that demonstrates the concept… https://github.com/Veraxus/nv-plugins-content-blocks

      You can create new blocks in the editor wherever you like – similar to adding a “more” tag – and give them a name for reference. Those tags are then parsed out in the post object. The entire content can still be rendered out with the_content() but you can render specific blocks in the current loop with the_content_block($block_id) instead. This lets you create a structure-heavy page template and load specific chunks of content from the editor without exposing the admins to any complex, easily-broken underlying HTML.

      In other words, it helps keep the HTML in the theme templates and the raw content in the editor.

      Now my current approach may not be the best, but it addresses a problem that is becoming more and more common as WordPress gets ever more popular as a full CMS.

      • Janneke Van Dorpe 10:50 pm on August 20, 2014 Permalink | Log in to Reply

        Do you have a use case for that? Just not sure what the benefit would be.

        • camu 3:20 am on August 21, 2014 Permalink | Log in to Reply

          There’s already a very powerful plugin that does this. I use it all the time: Visual Composer. You can find it on CodeCanyon.

          • Matt van Andel 3:44 pm on August 21, 2014 Permalink | Log in to Reply

            Thanks for the heads up, but that’s nuclear-grade overkill what I’m asking.

            Example A:
            You are building a website for a business that makes and sells a specialized piece of computer hardware. As you scroll down the homepage, you give the visitor a tour of what makes this hardware special, from the inside out. As you scroll down the page, the entire system assembles itself on the left of the screen, with new hardware coming up from the bottom and being “stickied” to what is already there… motherboard, CPU, chipsets, case… with information appearing to the right of the hardware at each step.

            Example B:
            You have a page that is a detailed Timeline of an organization’s history. Each date is a full-width fluid box with a background image. Floating above that background image is a lightly transparent white box with the date and descriptive text. The admin should be able to adjust dates (post title) and copy, and change the image at any point… or add new points in the timeline.

            • * *

            Traditionally, anything with that amount of structure, animation, or other complex technical requirements would have to be entirely hand-coded in a theme template as TinyMCE is horrific at handling complex HTML, particularly when you want a client to be able to easily edit things in the visual editor, without worrying about any important HTML breaking.

            But how do we expose those individual blocks of copy to admins in an elegant, highly usable way… so that they can be easily updated at any time (without anyone needing to futz with template files)? Ideally, the admin user would be able to edit anything on the homepage simply by editing the Homepage and being presented with all the blocks, neatly separated, that can be edited… but this is not something that WordPress currently supports at all.

            One old hacky solution I’ve used for years is to set up each “block” as a sub-page of Home, and then load those posts on a case-by-case basis. I’m not a fan of this approach as it’s a usability nightmare (one page is built out of many sub-pages), although the specific mechanics (blocks become a special kind of child post) may work well as a technical solution if a plugin provides the right kind of admin UI to support it (including hiding child pages from list tables that are technically blocks and not standalone pages).

            Another hacky solution (the one I linked to earlier) uses the HTML comment <!–block–> to split content in the same editor into blocks, just like &lt!–more–> – but those can be loaded in the template individually or looped. The current version is inelegant and ugly as hell, and currently only identifies blocks by array index instead of a more flexible title or tag… but it keeps all of a pages content neatly in one place… the editor for that specific page, where it belongs. Then the theme can control how and where those blocks are displayed on the page.

            Hopefully that makes that more clear.

            • Janneke Van Dorpe 3:54 pm on August 21, 2014 Permalink

              I get the idea, but these seem to be very specific use cases. There is actually already a similar concept to what you’re describing with and that’s . You can access the array of blocks with the global $pages. It sounds like your plugin is doing exactly this, and nextpage is build in core. You just tell the user to separate the content with page breaks and add the button to the editor, since it’s not there by default.
              Other option is to add more instances of TinyMCE under each other, but that might be a bit of an overkill.

    • Fab1en 7:53 am on August 21, 2014 Permalink | Log in to Reply

      Thanks a lot Janneke for your great work !
      The possibility for plugin to add views to the TinyMce editor looks very promising. I can provide you some use case examples where a custom view is needed.

      The first use case is exposed is the following WPSE question : Adding more options to the instance of an image. The user wants to modify the markup inserted for an image without switching to Text view. So that requires to extend the default image view with more options.

      The second use case is for a shortcode provided by Aesop Story Engine. The need is to position an element with the mouse, so jquery ui draggable widget is needed. I managed to achieve this, but jQuery ui needs to be loaded inside TinyMCE iframe to make this work.

      • Janneke Van Dorpe 3:40 pm on August 21, 2014 Permalink | Log in to Reply

        Thanks for the feedback!

        For the first case, you should take a look at this plugin: https://wordpress.org/plugins/advanced-image-styles/
        There is already a “view” for images, and the image details modal gives you options to change it. It’s not really a view though. It has its own TinyMCE plugin to handle everything, since at the moment views can only block elements in the editor and can’t be aligned. It’s also no possible yet to edit text in a view (which would be required for the caption).

        Yes, jQuery UI draggable is tricky to use in iframes. It shouldn’t be necessary to enqueue it inside the iframe. I wonder how hard is would be for jQuery to fix this. Anyway, this is why views in the front-end editor or so much easier to handle. No iframes!

        I’ve tried to use Aesop Story Engine several times, but I could never figure out how it works. It just inserts a bunch of shortcodes?

    • Ryan McCue 4:22 am on August 22, 2014 Permalink | Log in to Reply

      This is hugely exciting. :) The inline buttons especially are awesome, but all the other parts rock too.

      • Janneke Van Dorpe 5:57 am on August 22, 2014 Permalink | Log in to Reply


        You asked me about using your JSON Rest API for the Front-end Editor a while ago, and I’m interested in using it. But I’m a bit hesitant to require another plugin. I also want to release the new editor soon after WP 4.0 is released, so there might not be enough time to switch over, but it would be cool to try it out. :) How is the project going, and do you still need other projects to try it?

    • Nick Halsey 1:39 am on August 24, 2014 Permalink | Log in to Reply

      Wow, great job Janneke!

      I think we should start looking into integrating FEE and the Customizer. Both are front-end-contextual, and I see the Customizer as the place to handle non-content whereas the FEE does content. At least initially, that helps to preserve the way WordPress separates content from layout & design for the UX.

      Interestingly enough, the FEE currently works within the Customizer preview. You’ve got a much smoother experience going with your plugin right now, without the need for a pageload, and that’s something we’d like the Customizer to also be able to do eventually.

      I envision a “post” panel in the Customizer, contextual to single views. If the panel is opened in the Customizer, the front-end editor would load in the preview. If the front-end editor is triggered from the front-end, it would load the editor and open the Customizer, to the post panel/context. This allows users to quickly access other customization tools such as widgets and menus while editing content, but keeps content separated from everything else by making it editable in the preview rather than alongside it. And with panels, the visible UI context is limited to post-related things.

      The “post” panel would essentially contain all of the metaboxes from post.php for a given post type, as accordion/customizer sections. While experimenting with making post metadata directly editable is intriguing, I think we really need to have a more obvious mechanism for adding and managing taxonomies, featured images (the current implementation just isn’t compatible with everything themes do), things in the publish metabox, etc. Putting that into the Customizer would keep things visually consistent with our other front-end-contextual UI, and implementing it as a Customizer panel rather than a Customizer look-alike integrates direct access to other site Customization tools while editing content. We could also pull in the metadata UI API if/when it’s merged into core and/or implement post meta into the Customizer API (maybe with a postmeta setting type).

      I know @westonruter has been experimenting with editing posts with the Customizer and two-way communication between the Customizer controls and preview lately too, so I imagine we’d be able to get something like this working from a technical perspective. It would definitely be a lot of work to build a fully-integrated solution, though.

      • Janneke Van Dorpe 3:29 pm on August 26, 2014 Permalink | Log in to Reply

        Yes, definitely. I don’t see why we shouldn’t experiment with this. That’s also one of the reasons I made the change to “instant” on/off, and I’m aware the editor works in the customizer. Shhht! :) I will add an item there to turn the editor on, and maybe some of the UI can move there when uncollapsed. We can experiment with both at the same time, there’s no need to make any decisions about that direction now. Personally, I prefer to use the editor when there’s no panel making the screen smaller and with access to all buttons etc.

    • danieliser 5:27 am on August 25, 2014 Permalink | Log in to Reply

      Just tested the new editor, love love love the block concept. What are the plans to incorporate this into core? Any thoughts on what milestone this may be included?

  • Janneke 11:39 pm on June 20, 2014 Permalink | Log in to leave a Comment

    GSoC: Editor Experiments #2 

    I meant to do a post last week, so this one is a bit late, but here it is anyway. I’ve mostly been working on the extendibility of views in TinyMCE and little improvements to the views themselves.


    I’m trying to find a way to make it as easy as possible for plugins to create a view for their shortcode (though it doesn’t necesarily have to be a shortcode). At the moment the biggest challenge is the handling of scripts for those views. Views with scripts are sandboxed in an iframe, but while this is great for a view that just displays external content (like a map or tweet), it’s not so great for normal content because the iframe doesn’t inherit the styles of its parent. Sure, we could “detect” some styles, but that’s not good enough. We could also put editor-style.css in each iframe, but that will break once you switch formats or categories, unless we change every iframe’s body class simultaneously. I wish all major browsers supported “seamless” frames. :(

    On the front-end, however, we wouldn’t have this problem. The content is not wrapped in an iframe, so scripts can be added where they normally would.

    The current registation of a shortcode and view looks like this. It will change a lot though.

    register_shortcode( 'my_shortcode', array(
    	'__FILE__' => __FILE__,
    	'content' => '',
    	'block' => true,
    	'attributes' => array(
    		'my_attribute' => array(
    			'title' => __( 'My Title' ),
    			'defaults' => ''
    	'scripts' => array( 'script-handle', ... ),
    ) );

    Notice that all the attributes must be defined here, unlike add_shortcode(). Now you’ll need to create a directory my_shortcode in the directory of __FILE__.



    This is what the shortcode will output on the front-end. This file receives the variables $attributes, $content and $tag.


    This file registers the view for the TinyMCE editor.

    ( function( $, views ) {
    	'use strict';
    	views.register( 'my_shortcode', {
    		getHTML: function( attributes, content, tag ) {
    			// Content goes here.
    		edit: function( shortcode, attributes, content, tag, node ) {
    			// This function is run when the user clicks on the edit icon.
    			// E.g. you could create a default modal (or create your own).
    			// This modal will display the `edit.php` template. You can provide a callback to do some crazy stuff.
    			// If edit.php is set up correctly, all the attributes will be filled in for you.
    			this.modal( node, callback );
    			// OR
    			// While the modal above will handle the update automatically when the user clicks on <input type="sumbit">,
    			// you can also do it manually.
    			this.refresh( attributes_or_shortcode, node );
    	} );
    } )( jQuery, wp.mce.views );


    A script to run with the view’s content. This could also go in a <script> tag inside the content. Both will trigger an iframe.


    An html template to display the input fields. This will be optional, by default it would just display input fields for all the attributes you registered. You can hide certain attributes and set up your own controls by providing a custom edit.php template and add JavaScript using the modal callback.

    The name attributes that match the registered shortcode attributes will be filled in automatically with the old shortcode attributes and the defaults when using this.modal().

    <input type="text" name="my_attribute" value"">
    <input type="submit" class="button button-primary">

    An example

    Eventually I’ll create several examples to illustrate all this. So far I’ve made an example for a map (a Google map). The code can be found in a child plugin: https://github.com/avryl/editor-experiments/tree/master/google-maps-block. You can see all the files I described when you enter the map directory.

    In the editor, it just looks like this.

    Screen Shot 2014-06-20 at 09.55.34

    The edit view looks like this. You can search, add a marker, drag and drop it, move the map, change it to satellite and save it all.

    Screen Shot 2014-06-20 at 09.59.06

    View for embed

    I’ve also been working a bit on the embed view for core. You can now paste an embeddable URL and it will automatically create a view for it. See #28195.

    View improvements

    I experimented a bit with the views themselves to make navigation and editing around them easier. Right now you can’t put your cursor right before or after a view. But with the Editor Experiments plugin you can! This is done by creating a fake cursor next to the view and detecting when the cursor enters and leaves the view. The cursor behaves exactly like a normal cursor (though the height is equal to the view), you can’t see the difference.

    Screen Shot 2014-06-19 at 14.54.34

    • Dinesh Kesarwani 5:48 am on June 21, 2014 Permalink | Log in to Reply

      It’s awesome.

      But how hierarchical shortcodes will be handled? For (basic) example

      [grid col="6"]thecontent[/grid]
      [grid col="6"]thecontent[/grid]


      • Florian Girardey 8:22 am on June 21, 2014 Permalink | Log in to Reply

        I love this Idea, i think that hierarchical shortcodes will be handled as they are actually. Each shortcode tag wrapp will render an html output.
        But i think that we need first to resolve the bug of nested shortcodes with the same tag :/

      • Janneke Van Dorpe 3:29 pm on June 21, 2014 Permalink | Log in to Reply

        If all the shortcodes that you nest belong to the same plugin, the plugin can easily handle that. Actually, there’s no need at all for shortcodes within the main shortcode, because you create the shortcode through a UI. You can simply output HTML. But it’s still possible.

        If there are shortcodes inside the content of a shortcode by another plugin, it’s up to that plugin to parse them or not. But you can’t have a view inside a view atm. I’m also not sure if that’s necessary. I’d like to see some use case for such a scenario.

    • J.D. Grimes 12:22 pm on June 21, 2014 Permalink | Log in to Reply

      This is exciting, especially the shortcodes. I would love to see that make it to core. I’ll definitely be following along here..

    • TV productions 1:44 pm on June 21, 2014 Permalink | Log in to Reply

      I really like the idea! Views for shortcodes is a thing that seperates WordPress from being a multicontent CMS. I hope there is some space for the overall layout, so that the flow for inserting/editing a shortcode will look (almost) the same for each shortcode. I will be keeping an eye on this project ;)

    • programmin 12:53 am on June 25, 2014 Permalink | Log in to Reply

      Cool! So this will be a consistent api for creating shortcodes with the edit/delete buttons like most wp-core shortcodes? (related to bug introduced in 3.9 – https://core.trac.wordpress.org/ticket/28169) That will be great – especially for Nextgen-gallery and others that awkwardly have a click-event on a preview image to go to edit special content.

      Btw when you say “I wish all major browsers supported “seamless” frames”, are you talking about how stylesheets don’t apply within the iframes in the page (like TinyMCE’s iframes)? Because the latest MCE4 releases have support for inline mode – which uses a contentEditable in the page, without iframes:


      Btw am I the only one seeing “Notify me of follow-up comments by email” on this comments form?

      • Janneke Van Dorpe 2:30 am on June 25, 2014 Permalink | Log in to Reply

        More or less, yes. I’m actually trying to make all of this work inline, so you’re in “edit mode” immediately when you click anywhere on the view. You could then add your own buttons inline to open a modal, or have all the controls inline.

        I don’t think it’s a good idea to use inline mode in the admin. With an iframe you create a sandbox for both CSS and JS, which makes it a lot easier to add something like editor-style.css without having to reset all the admin styles. I think TinyMCE is also going to use a seamless iframe for inline mode once it’s better supported.

    • Nick Haskins 6:18 pm on July 27, 2014 Permalink | Log in to Reply

      Really some great work on this Janneke! We’ve been watching the progress of this and wpview pretty closely, and have been waiting for this api to truly take advantage of it within our plugin.

      I see that this is labeled “experiment.” Am I correct in assuming that this codeset won’t be in 4.0? If it will be, in what form?


  • Eric Andrew Lewis 8:33 pm on June 12, 2014 Permalink | Log in to leave a Comment  

    Media Component Weekly Meeting Agenda 

    There will be Media component office hours June 13, 2014 1700 UTC  (and every Friday) in #wordpress-dev.

    Proposed agenda items:

    • Media Grid (#24716) check-in. @jerrysarcastic posted about the user interviews he did. We should talk about UI feedback specifically and where we should go from there.
    • Splitting up Javascript files for media (#28510). Not sure this will happen in 4.0 but I’d like to get a solid approach to this together soon.

    If you have anything you’d like to discuss specific in the Media component (specific tickets you care about or more abstract discussions), please add it to the comments.

    • Eric Andrew Lewis 11:21 pm on June 12, 2014 Permalink | Log in to Reply

      Media tickets mentioned in the comments of Scott’s round-up that we can touch on: #24990, #5809, #23292, #28053

    • Ryan Boren 3:51 pm on June 15, 2014 Permalink | Log in to Reply

      I’ll tack my media short list here.

      • make the media modal usable on phones
      • multi-select upload everywhere, including phones
      • allow viewing large images in both the modal and the library when clicking/tapping on a thumbnail
      • Eric Andrew Lewis 10:52 pm on June 15, 2014 Permalink | Log in to Reply

        Into it. Sidenote: has anyone successfully uploaded an image via iPhone? I get an HTTP error on my site when trying to upload via iPhone.

        • Ryan Boren 12:00 am on June 16, 2014 Permalink | Log in to Reply

          Once I wade through that unscrollable mess, I can upload an image successfully.

        • Ryan Boren 12:06 am on June 16, 2014 Permalink | Log in to Reply

          BTW, make/flow has several posts featuring mobile media. I’ll add a visual record for iphone5 media flow.

          • Eric Andrew Lewis 12:15 am on June 16, 2014 Permalink | Log in to Reply

            i dig. come to the next media IRC meeting, let’s roadmap this.

            • Ryan Boren 4:35 am on June 16, 2014 Permalink

              I’ll be there and hopefully not forget the passing of time while making pre-meeting tea like last time.

            • Ryan Boren 3:50 pm on June 17, 2014 Permalink

              Meanwhile, I’ll dump some of my mobile media thoughts.

              The media modal is not usable on phones. The Press This feature plugin currently uses direct upload on phones because the media modal is not presentable. The modal needs some quick fixes to make it useable and then some deep thinking. The modal was optimized for desktops and drag-and-drop, and it shows.

              Until very recently, there was no way to select multiple files during upload on a mobile device. The iOS app added multi-select, although at the temporary cost of video uploads. And since the iOS app doesn’t have a visual editor, a multi-select upload results in a face full of img markup. Not friendly. The lack of multi-select means a lot of scrolling through the camera roll, squinting at small thumbnails, and jumping back and forth with your photos app, where you can see bigger images. This is a horrible experience. In the media modal, the lack of multi-select further means having to switch from the media library tab to the upload tab after every image you upload. Competitors offer multi-select into a gallery, no fuss.

              Thumbnails are hard to differentiate, especially on phones. When uploading images and arranging galleries, I am constantly tapping thumbnails to get a better view and constantly cursing because that doesn’t work. The modal shows a slighter bigger image in the right sidebar when an image is selected, but this doesn’t help much. A quick fix here could be a View Image link in the right sidebar. This would also help in Media Grid. In the list table media view, there is a View link, which is something, but it takes you to a front-end attachment view when really all you want is a quick look at a larger size.

          • Ryan Boren 5:33 pm on June 16, 2014 Permalink | Log in to Reply

            My iPhone 5 lock button is kaput. Anyone want to do a visual record of the new post flow on an iPhone? Here’s an example record using an iPad Air.


  • Scott Taylor 8:46 pm on June 7, 2014 Permalink | Log in to leave a Comment  

    Community Priorities 

    Triaging tickets takes a lot of time and is often thankless work. Testing patches and making sure they are committable is equally as time-consuming. Being a gatekeeper to those tickets going into core is also tough – sure, you can commit anything, but you are also the first person responsible when it breaks or there weren’t unit tests in place (when there should have been).

    As a community, we often have 2 major goals:
    1) Fix everything
    2) Make everything better

    Since we are still in the midst of defining what 4.0 will ultimately be, I would like to ensure that the community once again has a voice as far as “priority” tickets go, outside of dev chat.

    If there is an important ticket that you feel has been neglected, comment below. Seriously. There is always frustration from those who say “my ticket never gets looked at!” – for anyone feeling especially disillusioned, remind us publicly to give you some feedback. This does not mean that every ticket deserves to ultimately go in right away, but let’s talk about it.

    Speaking for myself, I often sit down at the computer and say “my goal today is to commit 100 tickets!” – I usually end up committing 8, over the course of 5 hours. And most of those tickets haunt me for weeks. Everyone is held to a high standard and expected to follow through when they make a decision for everyone else.

    We ALL want the same thing. Let’s work together to get there!

    • Robert Dall 8:53 pm on June 7, 2014 Permalink | Log in to Reply

      This has a patch it just needs a review… 
      plugins cannot filter `the_content` for Gallery post format on index views


      It has been debated whether is it worthy to patch something so “trivial” but if it is still a default theme and bundled with core then I think it is something that should be fixed…

    • Jonathan Brinley 9:00 pm on June 7, 2014 Permalink | Log in to Reply

      Thanks for asking, Scott. It’s hard to get attention to a patch without coming across as a whiny attention seeker. I appreciate having this forum. Without further ado…

      https://core.trac.wordpress.org/ticket/17817 – Fixing filter/action recursion

      Has a patch, has unit tests, has performance tests, has plenty of community feedback, and it fixes a bug that’s lived in core for seven years.

      The ticket itself had a fair amount of feedback for a while, but now that all the concerns have been addressed, it’s gone silent. Is there anything else I can do to help advance this ticket?

    • Niklas 9:31 pm on June 7, 2014 Permalink | Log in to Reply

      I’m unsure whether or not there are tickets on all of these subjects and my trac-fu is not good today… But here are some wishes:

      • The ability to use TinyMCE in widgets.
      • The ability to prevent plugins from breaking when WP auto-updates. I know the fault does not lie with WP, but sometimes plugins break things, and when the break things during auto-update things get worse because you are not there to discover it right away. Some setting to only allow auto-update if all enabled plugins are marked as compatible with the new version would be awesome!
      • Combine/compress CSS/JS files. This one I found a four year old ticket for (https://core.trac.wordpress.org/ticket/11453) but I believe this might be reconsidered now that a CSS preprocessor has been impleneted (https://core.trac.wordpress.org/ticket/22862). What do you say? The code is already there to sort JS files correctly according to dependencies.

      • Marius Jensen (Clorith) 5:20 am on June 11, 2014 Permalink | Log in to Reply

        Regarding plugin breakage from automated updates, I don’t see this as something that should be a problem for the default behavior. The default behavior of the updater is to only apply minors which generally mean security and bug fixes for the most recent version.

        I guess this does become a whole other question if you enable automatic major updates, perhaps adding a new configurable option alongside major updates to check compatibility of existing enabled plugins? (this should ONLY apply for manually enabled major updates, I think it’s important to maintain the default behavior of potential security patches etc be handled as they are; “instantly”)

        • Niklas 12:53 pm on June 14, 2014 Permalink | Log in to Reply

          I’ve had a dozen or so things break over the last year and a half on minor updates, there have been three types of error:

          a) It breaks because caching plugins (W3 TC, and WP Super Cache, I’m looking at you… :) ) does not update their cache properly.
          b) A plugin author has created a work-around for a bug that was fixed in the minor update and the two fixes now collide.
          c) The plugin author depended (for some stupid reason) or otherwise made code assumptions on the erroneous behaviour and therefore the update broke the site.

    • @ubernaut 10:04 pm on June 7, 2014 Permalink | Log in to Reply

      heres mine:


      basically ht issue is that in bulk editing mode there is no way to remove categories which can make for an incredibly arduous manual process of removing the categories one by one. i believe all the ui issues have been resolved at this point and there is also end user interest on this one:


    • Bryan Petty 10:50 pm on June 7, 2014 Permalink | Log in to Reply

      You asked me to list all of my high priority tickets in the IRC channel. Nobody actually cares, but I built a whole report for it. I honestly feel like most of the 600+ tickets here have been terribly neglected:

      Seriously… This report contains roughly the same number of unreviewed patches now as it did when I wrote the Bug Gardening guide two years ago. There’s patches in here that go for years without any feedback from the core team at all, not even to say that it’s not acceptable, or to even suggest that it could use some improvements. This report should only contain new patches submitted in the last couple weeks. Everything else should have either been rejected (with explanations), or committed.

      I’m not going to sit here and list off all of my open patches that have been neglected (and yes, I do have some). That’s not fair to anyone else that also submitted patches to Trac that isn’t here to speak for themselves. You aren’t asking them, and that’s part of the problem itself. Just the mere fact that a patch is uploaded and submitted to Trac *is* the indication that it’s important to someone in the community, and that the contributor thinks it’s important enough to donate their work to the entire community.

      • solarissmoke 12:44 pm on June 8, 2014 Permalink | Log in to Reply


        Come here to say exactly this! There are tickets in that report which (at the time) had working patches, and were even tagged for commit, but were ignored. Some of them are now 7 or 8 years old.

        Would be very, very happy to see a more systematic trac process, so that each ticket is funnelled through a review process within a specified timeframe (during which it is either accepted and actively wrangled, or rejected with reasons). That way we would not end up with hundreds of abandoned tickets (and just as many disillusioned contributors).

      • Helen Hou-Sandi 1:43 pm on June 8, 2014 Permalink | Log in to Reply

        Patch review from anybody in the community, particularly those who have more patches under their belt, is immensely helpful. While I wouldn’t expect that to fix the issue of ticket and patch rot completely, as I don’t think any one thing can, it really does go a long way toward helping ease the bottleneck that comes from an expectation that every single patch be reviewed by whatever is defined as the core team.

        • Bryan Petty 2:58 pm on June 8, 2014 Permalink | Log in to Reply

          This report is filtered specifically down to bugs only. There’s actually another 750 tickets with unreviewed patches for enhancements and new features. The reason the list is filtered, and why this is a high priority report is because assuming the core team doesn’t have the time to review everyone’s patch, it’s not a problem, features can still go in a plugin most of the time. I don’t expect the team to review every single patch. However, you can’t do that with bug fixes, and if developers with commit access can’t even keep up with reviewing bug patches (which account for less than 50% of the unreviewed patches), the team needs some serious reform.

          It’s one thing to ignore a bug report because you don’t have the time or required information to investigate it (and I get that), but it’s not acceptable when those with commit access on an open source project can’t be bothered to review patches. It’s literally the only job developers with commit access are absolutely required to do because no-one else can do it. Anyone else can fix the same issues and develop the same new features the core team has been working on if they’d let them. What the community can’t do is review and commit patches.

          It’s pathetic because someone else already did most of the heavy lifting, and it’s arrogant because the team assumes that only those with commit access have the ability to write quality patches. Above all else though, it’s a terrible cycle of abuse that WordPress is stuck in because someone invested a lot of their own (and their company’s) time writing it, and by ignoring it, the core team has consistently discouraged new contributors from getting involved. It’s also telling companies that hiring contributors or giving their developers extra time to contribute is just a waste of time and money. And without those dedicated long-term contributors, it becomes even more difficult to find worthy developers to grant commit access, and the team fails to find the time to review more patches yet again.

          You’re assuming that patch rot is a regular and normal thing in an open source project, and that’s partly true, but not to this extent. There’s a serious problem here, and there *are* solutions to that problem that the core team isn’t adopting.

          • Eric Andrew Lewis 4:20 am on June 9, 2014 Permalink | Log in to Reply

            I think you do have a point, but I don’t think grandstanding and talking trash at length about the process is productive.

            • Denis de Bernardy 9:26 pm on June 14, 2014 Permalink

              Imho, he’s absolutely not talking trash. He’s simply laying things out as they are. The issue got raised every year or so since 2005, and things haven’t changed to date except for the addition of extra committers — something yours truly vocally fought for. Fixing bugs is still lowest priority for all intents and purposes, and it’s shameful. I’m not holding my breath for things to change this year any more than it did when I abandonned the idea of contributing to WP in any material manner, but seeing a committer, however junior, actually initiate the discussion is a very welcome ray of light imho.

        • Robert Chapin 4:44 pm on June 8, 2014 Permalink | Log in to Reply

          I agree with Bryan. This is an area where the community has made incremental yet inadequate changes over the years. We have a well-organized Trac, unit testing to prevent old bugs from returning, and a core team willing to listen now, but bug fixes still take the absolute last priority in WordPress. The untapped potential of this community is mind boggling.

    • Tom Lynch 11:05 pm on June 7, 2014 Permalink | Log in to Reply

      I have been advocating changes to the Settings API and actually using it or providing hooks or something to the Admin settings and Network admin settings for years and it seems like someone higher up needs to make some decisions and garner support for it, because people have submitted patches only to be told we need to do XYZ… It’s hard to believe core still uses table based forms.

    • prionkor 6:48 am on June 8, 2014 Permalink | Log in to Reply

      Here is mine :) do_shortcode() for caption text. Was mentioned in dev chat.


    • leemon 8:16 am on June 8, 2014 Permalink | Log in to Reply

      https://core.trac.wordpress.org/ticket/5809 Updating a term in one taxonomy affects the term in every taxonomy
      https://core.trac.wordpress.org/ticket/23292 Media uploader loads full size image and slows down, please change to thumbnails.

    • Torsten Landsiedel 12:38 pm on June 8, 2014 Permalink | Log in to Reply

      It is not my ticket, but I think it would be hilarious to fix these: https://core.trac.wordpress.org/ticket/17268

      It seems to be a little bit tricky to check if the server does provide the right languages and modules, but maybe these plugins help to bring this into core:

      Less memory usage and faster sites for non-english WP installations is maybe not important for many english developers and so it this seems to be lost in the last 4 years. Would be cool if this would gain more community power ;)

    • Robert Chapin 4:33 pm on June 8, 2014 Permalink | Log in to Reply

      Wouldn’t it be nice if 4.0 was a community-driven quality assurance release?

      #10041 This is my highest priority and must not wait for betas.

      These were punted from 3.9:
      #23185 – NBSP compat for dashes.
      #27587 – NBSP compat for smilies.
      #27588 – NBSP compat for shortcodes.
      #19550 – Filter wptexturize.

      I have several patches for problems that are being caused by wptexturize:
      #12690 Do not texturize HTML and shortcode elements! (Fixes several tickets)
      #19308 Do not texturize hexadecimal expressions.
      #8775 Fix curly quotes around numbers.
      #22823 Fix possesive numbers.

      The wptexturize tickets below can be ready for 4.0, but I’m not going to waste time on them if we can’t get the above tickets finished first.
      https://core.trac.wordpress.org/ticket/28483 Stack errors in wptexturize.
      #20342 Allow dashes before curly quotes.
      https://core.trac.wordpress.org/ticket/6969 Duplicates several other tickets, just needs review.
      https://core.trac.wordpress.org/ticket/4539 Duplicates several other tickets, just needs review.
      https://core.trac.wordpress.org/ticket/17571 Probably invalid.

    • Till Krüss 1:11 am on June 9, 2014 Permalink | Log in to Reply

    • Lachlan MacPherson 9:13 am on June 9, 2014 Permalink | Log in to Reply

      Would really love to see this ticket looked at: https://core.trac.wordpress.org/ticket/17379 (Filtered exports drop attachments and featured images).

      It’s something that I encounter many times a week.

    • Chris Van Patten 12:28 pm on June 9, 2014 Permalink | Log in to Reply

      Not my ticket, but I’d kill (not literally) for #21195: https://core.trac.wordpress.org/ticket/21195 As far as I can tell, there’s currently no clean way to get an avatar URL without leaning on regex, which is not fun.

    • Rodrigo Primo 1:49 pm on June 9, 2014 Permalink | Log in to Reply

      Thanks for asking Scott.

      The highest priority ticket for me is a better algorithm for listing hierarchical post types in the admin. This ticket has a patch and is waiting for core developers feedback.


    • Aubrey Portwood 4:03 pm on June 9, 2014 Permalink | Log in to Reply

    • Amanda Rush 6:26 pm on June 9, 2014 Permalink | Log in to Reply

      I think it would be great if 4.0 were a release that focused on accessibility. The media library has several problems just by itself, and we have of course been working on this along with testing core features for accessibility. Plus, by making 4.0, (or some other release if that’s not possible), an accessibility release, more credibility would be lent to WordPress as a platform that is serious about accessibility.

    • Knut Sparhell 10:32 pm on June 9, 2014 Permalink | Log in to Reply

      It’s a bit late to change the focus for 4.0 now. I would like to suggest 4.1 to focus on fixing bugs, bringing down the number of open tickets, and continue making internationalisation, password handling, multisite and taxonomies better according to the roadmaps lined out on this blog.

      My only open ticket with a patch is https://core.trac.wordpress.org/ticket/27951

    • Jesper Johansen (jayjdk) 8:12 pm on June 10, 2014 Permalink | Log in to Reply

      I’d love to get some kind of feedback on my patch on https://core.trac.wordpress.org/ticket/16784

    • Patrick Hesselberg 8:15 am on June 11, 2014 Permalink | Log in to Reply

      Adding a composer.json to WordPress core would still be awesome. *bump*

    • Ben Huson 11:15 am on June 11, 2014 Permalink | Log in to Reply

      Would appreciate any devs who have a good knowledge of how the Media Modal works giving their input/views/suggestions on this:

    • Vincent Mimoun-Prat 8:41 pm on June 11, 2014 Permalink | Log in to Reply

      I have submitted patches for that one and that would help plugins depending heavily on post meta. Query can go from hundreds of seconds to a few ms with that optimisation.


    • programmin 4:42 am on June 16, 2014 Permalink | Log in to Reply

      I consider this to be a serious regression in 3.9:

      In earlier versions the edit/delete buttons for shortcode placeholders were duck-punch-able to allow custom edit/delete behavior, but you must now resort to uglier workarounds in 3.9. Is there a good reason the developers don’t want the edit/delete buttons to be consistently used for shortcodes introduced by other plugins?

    • Tunbosun Ayinla 5:36 pm on July 13, 2014 Permalink | Log in to Reply

      I will appreciate a follow up for my patch https://core.trac.wordpress.org/ticket/24398

  • Alex Shiels 10:56 am on May 28, 2014 Permalink | Log in to leave a Comment

    Improving the Plugins page 

    The WordPress Plugins page has barely changed in 5 years or more – compare WP 2.7.1 with 3.9.1.

    The very first page seen by a new user who clicks on the Plugins tab is a list view showing two installed plugins. The main thing thing that has changed since 2.7 is that the way to find and install new plugins has become less obvious.

    Similarly, the plugin-install page has barely changed in that time: WP 2.7.1 and 3.9.1.

    The default page is very much geared towards maintenance by established users. The most common interaction is probably deactivating and reactivating plugins for troubleshooting – certainly a necessary task, but I think it misses a good opportunity for helping people to find and use the plugins they need.

    There are a number of improvements that could be made with relatively minor changes:

    Improve the experience for new and infrequent users.

    • The obvious fix here would be to make the path for discovering and installing new plugins much more obvious than the “Add New” link. Perhaps even go as far as making plugin-install.php the default page.
    • The Search Installed Plugins box on plugins.php is easily mistaken for a plugin directory search. Either make it less confusing, or use a unified search.
    • When searching for plugins in the directory via plugin-install.php, tailor the results to the current WP version. Give more weight to those that are compatible with the current version, and/or filter out those that are likely to be incompatible.

    Help users to discover the plugins they need, especially the most robust and well-maintained.

    • On the Add New page, the most common tags in the cloud are “widget”, “post” and “plugin”. It’s next to useless. Replace it with a well-defined list of categories more in line with common needs: “contact forms”, “image galleries”, “security” and so on.
    • Improve the quality of plugin directory search results generally. Incorporate things like ratings, support stats, age, usage stats, and update frequency in the relevancy scores.
    • Augment or replace version compatibility votes with stats based on active installs per WP version.
    • Re-evaluate the tabs on the Install Plugins page. Is “Newest” helpful? Should “Popular” or “Featured” have a summary on the main page?
    • Improve the algorithm used for averaging ratings, to smooth out errors for plugins with only a handful of ratings.
    • Change the columns displayed in Search Results. “Version” doesn’t need a column; but compatibility and age ought to be shown.
    • Also show compatibility for installed plugins #27699
    • Improve the ordering and filtering possible in the plugin search API #12696 and #27316

    Improve the way detailed information is given about plugins.

    • Either eliminate the thickbox for the plugin details, or make it more consistent with the theme browser (allow next/prev)
    • Add a Details view for installed plugins #17902
    • Show reviews in the detailed view #22599
    • Show contributors in the detailed view #19784
    • Show the plugin’s banner in the detailed view, and generally make it more consistent with what’s on the web site.

    Help and encourage developers to publish and maintain their plugins.

    • Support screenshots, logos, or banners in the search results, installed plugin list and plugin directory.
    • Do a better job of handling ratings, reviews, updates, and support stats, especially when determining search ordering and popularity.
    • Improve the profile page to list version compatibility, support stats, and other useful info for all your plugins.
    • Add a version requirement check and/or upgrade prompt #26909 and #27323

    And finally there are some other tickets suggesting improvements and fixes that could use a second look:

    • #28085 – Recently Updated plugins view (recently updated installed plugins)
    • #20578 – allow delete without uninstall
    • #27110 – allow filtering the plugin list
    • #26202 – bugfix for thickbox title truncation
    • #27623 – search results for a single space
    • #27994 – handling of automatic plugin deactivation in the event of an error

    I’m working on the API side, starting with improvements to search quality. There are tickets above for many of these items already. If you’d like to help out, keep an eye on the Plugins Component in trac, open and help with tickets. Or leave a comment here with your suggestions if you’re interested.






    • chriscct7 11:12 am on May 28, 2014 Permalink | Log in to Reply

      One thing that would also be really cool is if you could do like an ecommerce style cart in the plugin area. So an example would be I search for SEO plugins, find one I like and “add to basket”. Search for caching plugin, find one I like, add to basket. Search for cat shortcode plugins, find two I like in the results, add both to basket. Then at the end, I click an “install all plugins in basket”.
      This would solve an issue I have with the plugins area which is it takes forever to install more than say 4 WordPress plugins, because you have to either have a 4 tabs of plugin-install open to do them simultaneously, or go back to back to back to back which takes forever. Just a thought.

    • Ajay 11:17 am on May 28, 2014 Permalink | Log in to Reply

      I don’t think making the “Add New” page as the default is a good option. You’re more likely to visit the plugin page to view / disable / access links of the existing plugins rather than install new plugins.

      It would be good to have a single column with rating, no. of downloads, age, etc. rather than separate columns in order to give more width to the Description section.

      • chriscct7 11:19 am on May 28, 2014 Permalink | Log in to Reply

        I agree with Ajay. I don’t think Add New as default is a good idea

      • Brad Touesnard 12:02 pm on May 28, 2014 Permalink | Log in to Reply


      • Chip Bennett 3:33 pm on May 28, 2014 Permalink | Log in to Reply

        +1. The default Plugins page should be installed/active Plugins.

        If anything, the default Plugins page should aim toward facilitating Plugin management. Things I would like to see:

        1. Plugin Settings page link added by default
        2. Plugin categorization

        • Torsten Landsiedel 3:09 pm on May 30, 2014 Permalink | Log in to Reply

          +1 for default to installed plugins (to be consistent to other pages UI)

          +1 for adding the settings link by default

          and another +1 for categories for plugins :)

        • Torsten Landsiedel 3:23 pm on May 30, 2014 Permalink | Log in to Reply

          Speaking of plugins: What about making it possible to connect the support tab of a plugin with the international forums like xx.forums.wordpress.org instead of wordpress.org/support to make local/translated support possible. Or better: Make the whole plugin page multilanguage. This would be an huge enhancement for the plugin page in WP too.

      • michalzuber 4:21 am on May 29, 2014 Permalink | Log in to Reply


      • daveshine (David Decker) 3:01 pm on May 29, 2014 Permalink | Log in to Reply


      • The Portland Company 6:59 pm on May 29, 2014 Permalink | Log in to Reply

        That’s subjective. As a developer; sometimes I am deactivating, other times I’m installing. My customers are usually installing. And I’m sure there are other people groups with different applications as well.

        The most ambiguous model would seem to be an Option in the Screen Options (or Settings, whatever) that allows the User to configure the default page to their liking. Then, apart from that, it will remember what section/tab they were on so when they navigate away and then back again they can continue.

    • camu 11:23 am on May 28, 2014 Permalink | Log in to Reply

      Two words: plugin dependencies :)


    • Jacob N. Breetvelt 12:12 pm on May 28, 2014 Permalink | Log in to Reply

      I would like to add a feature request: the possibility of re-install without delete, i.e. forced update with the same version no.

      • crzyhrse 1:55 pm on May 28, 2014 Permalink | Log in to Reply


      • Ipstenu (Mika Epstein) 5:05 pm on May 28, 2014 Permalink | Log in to Reply

        https://wordpress.org/plugins/baw-force-plugin-updates/ can do that so it SHOULD be addable to core.

      • Dovy Paukstys 8:23 pm on May 28, 2014 Permalink | Log in to Reply


      • David Lingren 10:42 pm on May 28, 2014 Permalink | Log in to Reply

        Great idea. I would also support “forced update with the current stable version”. I have had a few occasions (my fault, of course) when I posted a new version, found a bug and reverted to the previous version. There are always a few folks who got the new version before I could recall it, and they are stuck with the higher version number.

        In addition, it might be useful to have a “go back to the previous version” option when an update causes a problem or just isn’t wanted.

        I realize both of these can be complicated by database changes, etc. but they are worth considering.

        • The Portland Company 7:03 pm on May 29, 2014 Permalink | Log in to Reply


          Furthermore we really need to require developers to clean up after their Plugins after an uninstall. I understand that sometimes Users want to keep their data but delete the Plugin to reinstall it, so developers don’t delete files/databases but, at the same time, there’s no option to delete everything when Users DO want EVERYTHING deleted. Leaving unnecessary files and such.

          A simple API for developers to hook into to PROVE they’re Plugin delete’s everything upon Delete – plus a “go back to previous version” option could solve the problem for both parties.

    • TheHandOfCod 12:25 pm on May 28, 2014 Permalink | Log in to Reply

      I think the main thing that would help is to improve the search. If you do a search on ‘Form’ for example the first plugin shown has a lower star rating then plugins displayed later in the list. As mentioned above the Tag Cloud leaves a lot to be desired also.

      Another idea could be to allow installed plugins to be associated with custom categories on the installed plugins page? And allow bulk activate/deactivate by category? Paging would be good as well, with the ability to change the number plugins seen per page. This would help with not losing the menu when scrolling through more than a few plugins.

      I think the ecommerce style approach could be confusing as it might look to ‘new’ users as though they were buying plugins rather than installing free plugins from the repository. However I do like the way that Pippin Williamson displays extensions for EDD https://easydigitaldownloads.com/extensions/, and maybe taking direction from this style could be a good idea.

    • earnjam 1:19 pm on May 28, 2014 Permalink | Log in to Reply

      Something else I’d like to see related to the plugins page is some discussion on #14569

      In multisite it’s pretty confusing having themes and plugins operate in different ways (activate vs network activate vs enable vs network enable). Any patch that deals with that would involve modifications to the plugins page. But well before that, I think there should be discussion about the merits of it and how it would be handled in the first place.

      • Ipstenu (Mika Epstein) 1:23 pm on May 28, 2014 Permalink | Log in to Reply

        That said, plugins and themes are vastly different on multisite in how they behave. If you network activate a theme, it’s available on all sites for possible use. If you network activate a plugin, it’s ON for all sites. But I would suggest this is out if scope for a plugin page cleanup.

        • earnjam 4:23 pm on May 28, 2014 Permalink | Log in to Reply

          That’s my entire point. WHY should they even be acting differently? If you can make themes available to only certain sites, why not make plugins function the same way?

          I agree that it’s beyond the scope of what was in the OP above (no mention of multisite), but as long as we’re talking about changes to the plugins interface, and we really want to pay more attention to multisite on this release cycle (as has been stated a few times), I think that this would be a valid discussion to have. Maybe not here, maybe IRC or trac, but definitely somewhere.

          • Ipstenu (Mika Epstein) 4:33 pm on May 28, 2014 Permalink | Log in to Reply

            WHY should they even be acting differently?

            Because… a theme is not a plugin. But the issue is language, not behavior here :) We have a trac ticket on this I thought, but can’t find it.

            You can only have ONE theme active on a site at a time, right? So a ‘Network Actived’ theme is actually a ‘Network available’ theme.

            On the other hand, you have 50 plugins on a network, and 10 should be permanently on for all sites (network active) and the other 40 should be available.

            So I feel it’s outside the scope of enhancing the plugins pages, because I feel the issue lies not in the activation and handling of plugins, but in the terminology used :)

            • earnjam 7:34 pm on May 28, 2014 Permalink

              Oh, I definitely agree that the language could use some improvement. I’ve seen that ticket somewhere too. Maybe the discussion on #18301 ?

              But I think seeing this only as a language problem is a narrow way of viewing it. Just because you have 50 plugins installed on a network doesn’t mean you want all 50 to be available to all of the sites. Just as if you have 50 themes installed, doesn’t mean you want all 50 themes available to all sites. With themes, you can enable their availability for activation on an individual or network-wide basis. With plugins, once they are installed, they are all available for activation all the time.

              Again, I agree it is outside the scope of the original post here, but I don’t agree that it is outside the scope of general enhancements to the plugins page because this pertains to what plugins are available for activation…which is exactly what shows on the plugins page. :)

            • Ipstenu (Mika Epstein) 8:30 pm on May 28, 2014 Permalink

              Ahh so you’re thinking the granual control.

              https://wordpress.org/plugins/plugin-commander/ type stuff?

              YES, that should be there. I thought you meant something else!

            • earnjam 8:39 pm on May 28, 2014 Permalink

              Yes! That’s what I’m talking about.

              https://wordpress.org/plugins/multisite-plugin-manager is a good example, though not a very nice UI.

    • Ipstenu (Mika Epstein) 1:24 pm on May 28, 2014 Permalink | Log in to Reply

      Have you seen the layout for Jetpack modules? That is nice and neat and would be kind of awesome. Imagine if a plugin could use the menu icon for the plugin page like that?

    • Paal Joachim Romdahl 1:45 pm on May 28, 2014 Permalink | Log in to Reply

      Sometimes I install plugins, activate them but they remain unused. When I want to clean up the plugins I wonder which plugins are not used and are alright to delete. It would be nice if there was a signal of some kind showing where and how a plugin is used.

      Also when a plugin requires other plugins or have add-ons it would be nice to add a drop down or something showing the connection of these “child plugins” in connection with the “parent” plugin.

      • michalzuber 4:20 am on May 29, 2014 Permalink | Log in to Reply


        • The Portland Company 7:07 pm on May 29, 2014 Permalink | Log in to Reply


          Though there is some serious consdieration that would need to go into how to identify that sort of thing. Maybe even an API required for developers to opt-into. There is such a variety of Plugins – many of which aren’t directly interacted with – that I can’t imagine a way we could measure their used-ness.

          But I agree!

    • Charleston Software Associates 1:49 pm on May 28, 2014 Permalink | Log in to Reply

      I think the API needs to be improved along with this effort. The info server should allow for results to be filtered and sorted. Sort by download count, last updated date. Filter by compatible with my version, etc. My initial investigation was that any filtering needs to first retrieve a search query THEN filter those results which is less than optimal.

      Helping users, whether newbs or WP gurus, find the right plugins would be a big step in easing “plugin frustration”. Anything that stops the typical plugin search pattern of “search, install, not what I needed/broken/insecure, uninstall, repeat” would be a BIG help for myself and many of my clients. Filtering and sorting searches from within the WP Plugin Add New page would be a step in the right direction.

    • hereswhatidid 2:05 pm on May 28, 2014 Permalink | Log in to Reply

      I’d like to see some classification of the plugins in the admin. Something like Front End, SEO, etc… Similar to the Tags list on .org but more generic. This is something that I’ve seen in a few other CMSs and it really helps with the UX when there are a lot of plugins/modules installed.

    • crzyhrse 2:09 pm on May 28, 2014 Permalink | Log in to Reply

      I’d like to see links on the WordPress Plugins page that go to each plugin’s WordPress plugin page. Most often as it is they go to the author’s web page(s).

      To make it easier to look for support, to rate, to donate, whatever…

    • Paal Joachim Romdahl 4:50 pm on May 28, 2014 Permalink | Log in to Reply

      (Originally posted by Spencer Hill http://make.wordpress.org/core/2014/05/06/summary-of-last-weeks-dev-chat-on-4/#comment-14298 )

      I’d (Spencer Hill) like to contribute to Plugin Installer enhancements with @nacin.

      More specifically I believe we need to rethink the visual architecture of that page. Here are a few examples of what I mean:

      Some Plugins *revise* Core features.
      Others *replace* Core features.
      Then some *extend* Core features.
      Others introduce entirely new features that will not, and should not, become apart of the Core.
      And, lastly, some *extend* or *revise* *Plugins* themselves. These are commonly referred to as Add Ons or Extensions (like WooCommerce Extensions).
      As a User, viewing the Plugins screen these all blur together and there’s no way to filter between them. I find myself accidentally installing Plugins with duplicate features. And there is no way to see the relationship between some Plugins like “Add On” Plugins (which are the ones that extend or revise Plugins themselves).

      I’ve prepared a mockup that can be viewed here: https://drive.google.com/a/theportlandcompany.com/folderview?id=0B8-MGuUsAa39dHdRa1I0SG9yZVE&usp=drive_web

    • Jon Brown 6:04 pm on May 28, 2014 Permalink | Log in to Reply

      Almost completely absent from this discussion seems to be “Getting better user feedback published back to the repo”.

      In order to “Help users to discover the plugins they need” we need better data published to .org.

      I’ve been pushing this for a while so realize there are auth issues in publishing reviews/compatibility reports directly from a .org install back to wordpress.org. However, I really think part of this push should be figuring out how to encourage plugin feedback or mining what data we can better. I do like the idea of reporting “Active Installs” for popularity instead of downloads, but we need to focus on this a bit and figure out what we can do.

      • Michael Beil 8:44 pm on May 28, 2014 Permalink | Log in to Reply

        I agree Jon.

      • The Portland Company 7:12 pm on May 29, 2014 Permalink | Log in to Reply

        +1 – @nacin mentioned he was responsible for this in an IRC a couple weeks ago.

        I don’t know how this could be done while respecting privacy, but I know that when I’m searching for a new Plugin I install, uninstall. Find a new one; install, uninstall. Find another; install, uninstall. Until I narrow it down to one or more. So if there was a way we could share that data with other users so they don’t waste time on crap-Plugins I think that would be valuable. But that may be beyond the scope of what we’re trying to do here and that’s understandable!

      • Andy McIlwain 9:20 pm on June 3, 2014 Permalink | Log in to Reply

        +1. I’m really interested in seeing some quantitative+qualitative feedback. Particularly if we can identify some standout pain points.

    • Arnan de Gans 7:10 pm on May 28, 2014 Permalink | Log in to Reply

      While I think there are some good points here, at the same time I’m also thinking the current listing of installed plugins doesn’t need fixing as it works perfectly fine as it is.

      • The Portland Company 7:16 pm on May 29, 2014 Permalink | Log in to Reply

        I have to disagree. I mean, it’s *functional* but has a few *major* issues relating to security and database optimization:

        • Many Plugins don’t clean up after themselves properly during Delete.
        • Users should know, on Delete, whether or not a Plugin is going to remove absolutely everything it created (database or files) or leave something behind.
        • - If it does Users need to be given the option to say “No, I want you to remove everything. Don’t force me to let you leave crap behind in my file structure and DB”.
        • Ipstenu (Mika Epstein) 3:11 pm on May 30, 2014 Permalink | Log in to Reply

          That is not all that easy. The way plugins clean up is via an uninstall script, and at this time, without a total overhaul of not just the plugin page but plugin install processes, it’s not feasable. Should we look to it long term? Maybe… It’s a messy idea, and that’s much of why we left it in the hands on the plugin devs.

          Sadly that’s also why it’s not as common as it could be.

          1) Plugins ALWAYS delete the plugin folder files on uninstall
          2) Plugins are ENCOURAGED to delete tables/options on uninstall
          3) Plugins RARELY delete the ‘other’ files it adds (like advanced-cache.php, extra uploads etc)

          Deleting the non-plugin-folder files is super messy and not something I’d want to see for all plugins. Like a gallery? Imagine if NGG nuked all your images on uninstall. You’d be livid :) That’s always going to be a manual call there for sanity.

          Deleting the tables? Even then, it has to be thoughtfully done per plugin. Take those role editor plugins. You would, theoretically, want them not to delete but to reset on uninstall.

    • Dovy Paukstys 8:14 pm on May 28, 2014 Permalink | Log in to Reply

      I’d like to see a safety feature built in. When you update a plugin, move it to a store directory. A cron task is setup to delete it in say 8 hours. If the user is not happy with the update or it breaks something, you can restore to previous. That would help the user side of things.

      • Greenweb 9:19 pm on May 28, 2014 Permalink | Log in to Reply

        That would assume that any data and or data schema related to the old version was not changed on activation of the new plugin.

        • Jon Brown 1:24 am on May 29, 2014 Permalink | Log in to Reply

          +1 – reversion is complicated.

          If a user needed/wanted to they can download an older version from .org and manually install.

        • Ipstenu (Mika Epstein) 3:14 pm on May 30, 2014 Permalink | Log in to Reply

          That’s actually less complicated. Since DB/data changes usually happen with an intentional click after upgrade it could be safe ‘enough.’

          There are plugins that make major db structure overhauls, and yes, that would be problematic. Still, a file dump to flip to the last version requires one thing we don’t have :) What was the OLD version?

          Copying the folder to a plugins-old or plugins-backup folder might do it, though we’d have to come up with a way to delete THAT after x time (NOT 8 hours, more like 5 days). Feasible, though. I’d love to see a plugin do that so we could experiment with it!

    • David Lingren 10:49 pm on May 28, 2014 Permalink | Log in to Reply

      I hope there will be a corresponding effort to improve the Plugin Repository as well. For example, a plugin-specific Support Forum “Search” facility that would only look at topics within the current plugin. The Repository-wide search is useless in many cases.

    • michalzuber 4:18 am on May 29, 2014 Permalink | Log in to Reply

      Would be cool to have Recommend (for example https://i.imgur.com/bLyfW4X.png from https://play.google.com/store/apps) showing what my friends favorited on WP.org

    • Dan Griffiths 8:10 pm on May 29, 2014 Permalink | Log in to Reply

      Agree with A LOT of the proposed changes… probably the single most useful I can think of would be the addition of native plugin dependency support. That said… we’ve already lost the install_themes_tabs filter (which I used)… please don’t lose the install_plugins_tabs filter too… or at least provide suitable replacements. It might not be common use, but there are valid reasons for needing to extend/modify the theme/plugin tab bars…

    • Josh Pollock 12:18 am on May 30, 2014 Permalink | Log in to Reply

      I had a user today report that my plugin couldn’t be installed via the theme installer since it didn’t have a valid style.css. This may seem silly to experienced users but how clear is the difference between plugins and themes to new users?

      It seems to me that as long as the plugin installer, should, if the uploaded file fails plugin validation, check if it passes theme validation and if so point the user to the right installer and the theme installer should do the same thing as well. This would take one pain point away from learning our platform and turn a frustration into a learning experience.

      • Ipstenu (Mika Epstein) 3:17 pm on May 30, 2014 Permalink | Log in to Reply

        The error message there should be a little better. “The zip you have attempted to upload does not appear to be a THEME.” and then possibly a check to see if it has plugin headers so we can correct people?

    • sffandom 10:29 pm on May 30, 2014 Permalink | Log in to Reply

      ” Incorporate things like ratings, support stats, age, usage stats, and update frequency in the relevancy scores.”

      That would be a very bad idea. If a new plugin is being frequently updated to compete with an older, more robust plugin, then the user would be misled into thinking the new plugin has an advantage.

      The same goes with ratings. How do you compare a 4-star rating based on 5 feedbacks with a 4-star rating based on 500?

      And given how some developers mark support threads as “Resolved” when they are NOT resolved, the support stats would be useless.

      You touched on this problem here: “Improve the algorithm used for averaging ratings, to smooth out errors for plugins with only a handful of ratings.”

      Yes, but ratings in general are an unreliable metric for quality, suitability, or matching user needs.

      Compatibility is really not very helpful in many cases. A lot of old plugins work just fine with the current version of WP. What would be helpful is a catalog of reported errors. If a plugin is really incompatible with a new version of WP there should be a way for people to report that and for the plugin dashboard to say, “400 users reported compatibility issues with this plugin from version X on up.” Not perfect, but much better than the current system.

      • Alex Shiels 5:48 pm on June 7, 2014 Permalink | Log in to Reply

        I agree that ratings are unreliable metrics. And that update frequency, download counts and active installs could lead to an undesirable feedback loop that unfairly promotes a limited subset of plugins.

        I’m not suggesting that any of those things be used as the sole metric for ranking search results. Merely that they be incorporated into the ranking algorithm provided that the end result does in fact improve search quality. We do have access to engines and expertise in that area.

    • Pete 11:09 am on July 25, 2014 Permalink | Log in to Reply

      The ability to categorise all my favorited plugins would be awesome. As it is now I have 10 pages of my favorited plugins with no ability to search/browse/categorise them in any meaningful way.

  • Ryan McCue 4:45 am on May 25, 2014 Permalink | Log in to leave a Comment

    JSON REST API: Version 1.0 

    I’m incredibly excited to announce the availability of version 1.0 of the JSON REST API.

    This version is a huge release and introduces a bunch of new features, such as user, revision and post meta endpoints. It also introduces our long-term backwards compatibility policy, aligning with WordPress core backwards compatibility.

    Here’s a selection of the new stuff:

    • Add user endpoints.

      Creating, reading, updating and deleting users and their data is now possible
      by using the /users endpoints. /users/me can be used to determine the
      current user, and returns a 401 status for non-logged in users.

      Note that the format of post authors has changed, as it is now an embedded
      User entity. This should not break backwards compatibility.

      Custom post types gain this ability automatically.

      (props @tobych, @rmccue, #20, #146)

    • Add post meta endpoints.

      Creating, reading, updating and deleting post meta is now possible by using
      the /posts/<id>/meta endpoints. Post meta is now correctly embedded into
      Post entities.

      Meta can be updated via the Post entity (e.g. PUT to /posts/<id>) or via
      the entity itself at /posts/<id>/meta/<mid>. Meta deletion must be done via
      a DELETE request to the latter.

      Only non-protected and non-serialized meta can be accessed or manipulated via
      the API. This is not predicted to change in the future; clients wishing to
      access this data should consider alternative approaches.

      Custom post types do not currently gain this ability automatically.

      (props @attitude, @alisspers, @rachelbaker, @rmccue, @tlovett1, @tobych,
      @zedejose, #68, #168, #189, #207)

    • Add endpoint for deleting a single comment.

      Clients can now send a DELETE request to comment routes to delete
      the comment.

      Custom post types supporting comments will gain this ability automatically.

      (props @tlovett1, @rmccue, #178, #191)

    • Add endpoint for post revisions.

      Post revisions are now available at /posts/<id>/revisions, and are linked in
      the meta.links.version-history key of post entities.

      Custom post types supporting revisions will gain this ability automatically.

      (props @tlovett1, #193)

    • Respond to requests without depending on pretty permalink settings.

      For sites without pretty permalinks enabled, the API is now available from
      ?json_route=/. Clients should check for this via the autodiscovery methods
      (Link header or RSD).

      (props @rmccue, #69, #138)

    • Add register post type argument.

      Post types can now indicate their availability via the API using the
      show_in_json argument passed to register_post_type. This value defaults to
      the publicly_queryable argument (which itself defaults to the
      public argument).

      (props @iandunn, @rmccue, #145)

    • Remove basic authentication handler.

      This breaks backwards compatibility for clients using Basic
      authentication. Clients are encouraged to switch to using OAuth
      . The Basic Authentication plugin can be
      installed for backwards compatibility and local development, however should
      not be used in production.

      (props @rmccue, #37, #152)

    • Require nonces for cookie-based authentication.

      This breaks backwards compatibility and requires any clients using cookie
      authentication to also send a nonce with the request. The built-in Javascript
      API automatically handles this.

      (props @rmccue, #177, #180)

    • Clean up deprecated methods/functions.

      Functions and methods previously deprecated in 0.8/0.9 have now been removed.
      Future deprecations will take place in the same manner as WordPress core.

      This breaks backwards compatibility, however these were marked as
      deprecated in previous releases.

      (props @rmccue, #187)

    • Only expose meta on ‘edit’ context as a temporary workaround.

      Privacy concerns around exposing meta to all users necessitate this change.

      This breaks backwards compatibility as post meta data is no longer
      available to all users. Clients wishing to access this data should
      authenticate and use the edit context.

      (props @iandunn, @rmccue, #135)

    • Add json_ensure_response function to ensure either a
      WP_JSON_ResponseInterface or a WP_Error object is returned.

      When extending the API, the json_ensure_response function can be used to
      ensure that any raw data returned is wrapped with a WP_JSON_Response object.
      This allows using get_status/get_data easily, however WP_Error must
      still be checked via is_wp_error.

      (props @rmccue, #151, #154)

    • Use version option to check on init if rewrite rules should be flushed.

      Rewrite rules on multisite are now flushed via an init hook, rather than
      switching to each site on activation.

      (props @rachelbaker, #149)

    As always, you can view all commits or the longer changelog.

    For those interested, here’s the list of contributors to this release:

    $ git shortlog --summary 0.9...
         1  Chris Marslender
         1  Eric Lanehart
         2  K.Adam White
         1  Kat Hagan
         2  Matth_eu
        41  Rachel Baker
       139  Ryan McCue
         5  Taylor Lovett
        10  Toby Champion

    There’s a few really important things to note with this release.

    Authentication Changes

    Authentication has changed significantly in 1.0. If you’ve been using Basic authentication previously, you’ll now need to install the Basic authentication plugin. This plugin is designed for local development, as Basic authentication requires sending your plaintext credentials over the wire, which is unsafe for production.

    Production users have two choices: built-in cookie authentication, or OAuth authentication. OAuth 1.0a is an authorization protocol that allows you to authorize clients to act on your behalf, and does not require giving your username and password to the client. It does, however, require a significantly more complicated authentication/authorization process, and clients are required to register on the site beforehand. We’re working on long-term solutions to this.

    Plugins and themes can also use built-in cookie authentication. This is the normal WordPress login process, however requires a nonce for authentication to the site. This is automatically handled for you when using the built-in Javascript client.

    Backwards Compatibility

    From this release forwards, backwards compatibility will not be broken. This includes both the internal PHP API, as well as the REST API we expose. New endpoints may be added, as well as new data, but responses will continue to be supersets of the current response.

    The exception to this is for security concerns. As we continue development, we may need to change some endpoints for security issues, as we did with post meta for this cycle. These will be announced well before release where possible.

    Please note also that this release has removed some previously deprecated methods and changed some internal implementation details. This only affects plugins or themes that extend the API.

    Core Integration

    We’re pushing hard for integration into 4.0 this cycle, and we need your help. Our core integration plan outlines the motivation behind the project and the specific plan for integrating it into core. We’re currently working on a comparison document for the API compared to the WP.com/Jetpack API and others, and will be publishing that soon.

    We need your help to make it into 4.0. Developers, we’d love to know what you’ve built with the API, whether public or internal (even vague details help!), and we’d especially love to see things built with the API. We’re currently in danger of not making it in this cycle, so anything you can do to help us here would be fantastic.

    As always, we’re also looking for help. The main API always needs help, and the other related projects do too. Both the WP-CLI client and Javascript client need help here.

    You’re always welcome over at the team o2, and our next meeting will be at Tuesday, 00:00 UTC; we’d love to see you there. If not, see you soon for version 1.1!

    • Nikola Nikolov 7:45 am on May 25, 2014 Permalink | Log in to Reply

      I’ve used the JSON API to make front-end submissions to a budgeting app I did for my family.
      I basically only use it for publishing entries in custom post types. I started using the plugin while it was at .6, or .7, so I had to extend it in order to get the endpoints and post meta handling that I needed, but it wall worked out just great.
      I haven’t had the time to update from 0.8 to the latest version, since I’m not sure how much code I’d have to change and I don’t really have lots of free time these days :)

      But in any case, it saves time(once you have it figured out), it’s reliable, well-written and I personally would love to see it in core. Because if it’s in core, more people would actually use it(which means having a more unified experience for developers). I’m sure almost everyone right now is using one of three methods in order to push/pull data via AJAX:

      • request to /wp-admin/admin-ajax.php
      • request to /wp-content/plugins/…./plugin-ajax.php
      • request to the current url, with a hook on init or something else

      — Nikola

    • Nashwan Doaqan 2:12 pm on May 25, 2014 Permalink | Log in to Reply

      Good work @ryan and all the team.. it’s really a big project :)

    • cemdev 3:17 pm on May 25, 2014 Permalink | Log in to Reply

      Please, please, please let this make it into 4.0. The xml-rpc API is soooooo crap. And insecure. Really looking forward to leveraging a modern, more secure API for our customers.

    • Mikel King 3:21 pm on May 25, 2014 Permalink | Log in to Reply

      Very cool! Thank you @ryan and the whole team I can’t wait to mess around with this! I would love to see a talk on this at WordCamp NYC in Aug…

    • Towfiq I. 3:48 pm on May 25, 2014 Permalink | Log in to Reply

      +1 this SHOULD be in core!!

    • memuller 11:47 pm on May 25, 2014 Permalink | Log in to Reply

      This is really, really impressive. curl’ing those API endpoints is a lot of fun.
      Will surely use in future projects, regardless of its inclusion on core. It’s superior to the Jetpack API, and clearly superior to the default one.

      As Nikola pointed out, the ways currently in use to perform data operations via AJAX are a little awkward. As someone that is frequently sough for WP-related advice, I would *really* appreciate if this was included on core, since them I could teach novices to use it for AJAX calls – if it remains as a plugin, it would be a little irresponsible to do so. I think that’s an important point – experienced developers will always be able to use this API as a plugin, regardless of its inclusion on core; but we can’t expect first-time wordpressers to depend on a plugin; they will just google for the “standard” way of doing things and will stick to it.

      I used to work in a local media conglomerate, heavily dependant on WordPress. At the time, I did a *lot* of integration between WP and other applications – a work that would have been a lot easier if this API already existed; specially since most of those apps were quite RESTfull (rails applications, sinatra and node middlewares and the like). It would have allowed us to keep a higher quality standard on our infrastructure – without it, we did some integrations with the Jetpack API, some with RPC, and some even by mucking with the database directly. This API would have provided us with a way that was so much better and easier than the alternatives, that no developer – regardless of skill level – would have been able to ignore it.

    • Eric Andrew Lewis 2:31 am on May 26, 2014 Permalink | Log in to Reply

      Will there be some kind of versioned usage of the API, so that breaking changes can be made in a new version, but the old version can still be supported?

      • Ryan McCue 4:07 am on May 26, 2014 Permalink | Log in to Reply

        Beau Lebens asked the same over on the o2, here’s my response:

        The plan for versioning, if it’s ever needed, is to use Content-Type headers to indicate the version, much the same way that GitHub versions their APIs. This doesn’t affect the current approach, so it’s not something needed at this point.

        • Eric Andrew Lewis 9:11 am on May 26, 2014 Permalink | Log in to Reply


        • Aaron Jorbin 6:05 pm on May 28, 2014 Permalink | Log in to Reply

          I don’t like this approach for a couple of reasons. 1) It makes it harder to use tools like Curl for testing. 2) It would make debuging by looking at server logs harder. 3) It also adds a higher barrier to entry for developers as not all developers know how to add headers. Yes this can be solved with education, but I don’t think every problem should be solved with education.

          I think we should add the version string into the url.

          • Mikel King 7:27 pm on May 28, 2014 Permalink | Log in to Reply

            I have to imagine that WP_Http (where adding headers is really rather trivial) is preferred over curl.

            • Aaron Jorbin 7:31 pm on May 28, 2014 Permalink

              I’m was talking about from the command line, not from php. Sorry that wasn’t clear.

    • Eric Lanehart 6:07 pm on May 27, 2014 Permalink | Log in to Reply

      We’ve been using WordPress as an API at sparkart for many of our projects, starting with the Americas Cup (http://sparkart.com/work/americas-cup) in 2012/13. That project used Dan Phiffer’s JSON API plugin in a manner similar to what he built that plugin to do for the MoMA: supply content to a Ruby-based server. Nowadays we use node.js (http://github.com/solidusjs) in the same fashion. This allows us to easily integrate data from other sources and simplify our production and development environments by removing a database dependency. Our production sites are essentially static, fronted by a CDN for fast performance around the world. Unlike static site generators content is refreshed as it expires.

      YoungMoney.com, official site of Lil Wayne, is using the JSON REST API plugin today. All sites in development also rely upon it. We’re actually planning to migrate all content from a legacy, proprietary CMS to WordPress. We began using the plugin as of 0.6, seeing a much clearer future than the existing JSON API plugin and appreciating the thoughtful design behind it. We also considered the Thermal API plugin but found it’s implementation, particularly around media, to be uneven. The response schema also seemed too much of an abstraction.

      This maybe isn’t the most compelling use case since we flout much of the WordPress ecosystem (themes, widgets, plugins, etc). But a new class of CMS’s have emerged in this time (Osmek, Contentful, Prismic.io) that are essentially the same proposition: content management without the presentation layer. The problems they solve around support for mobile apps and other non-browser based environments connected to the web is also tremendously valuable. The Quartz use case along with some examples of similar node.js-fronted sites like the WSJ, other Dow Jones properties, and Artsy have helped validate our approach in my mind. Except unlike Quartz we don’t need expensive WordPress VIP installations to scale to millions of visitors.

      As developers we’re all about the Unix philosophy of small, focused tools. We strongly prefer these tools to be open whenever possible, and this is one reason we continue to use WordPress despite the existence of these services.

    • paulkevan 9:55 am on May 28, 2014 Permalink | Log in to Reply

      Although we (metro.co.uk) haven’t used any the JSON api plugin, due to using WP.com VIP, we have built replica json endpoints so we can consume some of our post meta fields in other applications.

      The other area we use is the XML-RPC endpoints to push in images from our picture management system and as previously mentioned this isn’t the nicest method to use.

      I’d be happy to get involved in the testing of any post meta based endpoints and also the development of the media endpoints, in particular the extending of what data can be send through these endpoints for each media item.

    • K.Adam White 8:44 pm on May 28, 2014 Permalink | Log in to Reply

      We’re using the API as the content backend for an in-development Node.js website and several single-page applications; nothing I can share publicly yet, but the API project was the tipping point that let me convince my colleagues that WordPress was a suitable backend for a non-PHP application. We’re really excited about the work we’re doing and I look forward to sharing it later in the year.

  • Konstantin Obenland 1:55 am on April 15, 2014 Permalink
    Tags: , , , , ,   

    HTML5 Galleries & Captions in WordPress 3.9 

    WordPress 3.6 introduced HTML5 versions of popular template tags, starting out with comments, the comment form, and the search form. With the 3.9 release we add galleries and captions to that list. Now, when adding HTML5 support for those features, WordPress will use <figure> and <figcaption> elements, instead of the generic definition list markup.

    To declare that your theme supports these new HTML5 features, add the following call to your theme’s functions.php file, preferably in a callback to the after_setup_theme action:

    add_theme_support( 'html5', array( 'gallery', 'caption' ) );

    For forward compatibility reasons, the second argument with the specific parts can’t be omitted when registering support. Otherwise a theme would automatically declare its support for HTML5 features that might be added in the future, possibly breaking its visually because of it.

    For both galleries and captions not only the markup changes when a theme declares its support for them, there are also peripheral changes that come with it.


    By default, galleries will not include inline styles anymore when in HTML5 mode. This caters to the trend of disabling default gallery styles through the use_default_gallery_style filter, a filter that even the last two default themes used. With that, theme developers can always start with a clean slate when creating their own set of gallery styles.

    We also took the opportunity to remove the line breaks between rows of images. Not only did they encourage an inferior way of positioning elements, more importantly they were non-semantic html elements that are meant for presentational use, and they made it harder to style galleries.


    Up until now, captions received an additional 10 pixels of width, to keep text flowing around the caption, from bumping into the image. As @nacin put it, this has vexxed theme developers for years, and even resulted in the addition of a filter in WordPress 3.7 to manipulate the caption width.

    We were not able to completely remove the inline style in HTML5 mode, it’s still necessary to force captions to wrap, but we’re no longer the adding 10px of width. We also removed caption styles in the editor, bringing it on par with how non-captioned images are displayed:

    [gallery ids="10229,10230,10233"]

    Twenty Thirteen and Twenty Fourteen have been updated to support both features, while retaining backwards compatibility with older WordPress versions. There is a remote possibility however, that child themes that use element selectors to overwrite gallery or caption styles can lose those customizations. Please test your child themes with the current development versions of the last two default themes.

    If there are any questions about the current implementation, feel free to leave a comment below.

    • andrei1709 5:08 am on April 15, 2014 Permalink | Log in to Reply

      Awesome! Thank you very much for this update :)

    • Manuel Schmalstieg 12:07 pm on April 15, 2014 Permalink | Log in to Reply

      Glad to see that the HTML5 mode removes the BR tags from the gallery markup. That’s great news for responsive theme development!

    • Morten Rand-Hendriksen 3:12 pm on April 15, 2014 Permalink | Log in to Reply

      This is great and long overdue. I always say WordPress is at the forefront of web standards and the two thing that have been lagging behind are the galleries and comments. This is a major milestone that will change the way we think about built in features.

    • glueckpress 9:15 am on April 16, 2014 Permalink | Log in to Reply

      (goes updating themes)

    • Justin Kopepasah 6:43 am on April 17, 2014 Permalink | Log in to Reply

      This is great news. I was happy when the filter was introduced and now I am elated to see the ability to implement HTML5 galleries completely. Definitely adding this to my latest theme.

    • car57 6:52 pm on May 14, 2014 Permalink | Log in to Reply

      I am not a developer, so would you be so kind as to explain what is meant by:

      To declare that your theme supports these new HTML5 features, add the following call to your theme’s functions.php file, preferably in a callback to the after_setup_theme action:

      add_theme_support( ‘html5′, array( ‘gallery’, ‘caption’ ) );

      I have a functions.php file for a child theme. I don’t know what code to insert to have “a callback to the after_setup_theme action”


      • Knut Sparhell 12:39 am on May 15, 2014 Permalink | Log in to Reply

        A callback is a function (or class method) that is added to an action by add_action(). In this case add_action( 'after_setup_theme', 'my_theme_setup' );. Inside my_theme_setup() function you can add the theme support. It could also be added in other actions, like ‘init’ or ‘wp_loaded’, but not before ‘after_setup_theme’ has fired. If you just add the support in the outer scope of functions.php it may be executed too early in the load process. The internal data structures to receive this theme addition may not have been initialised before ‘after_setup_theme’.

        The outer scope of functions.php (and plugins) should only add actions and filters, nothing else. All things you want to do should be inside a “callback” (a function or a class method, to be precise).

        See http://code.tutsplus.com/articles/the-beginners-guide-to-wordpress-actions-and-filters–wp-27373

    • car57 7:56 pm on May 14, 2014 Permalink | Log in to Reply

      no matter how i add php to functions.php, this script is never run. Still getting old-style dl with inline css. Sigh.

    • paulinelephew 12:02 pm on July 23, 2014 Permalink | Log in to Reply

      Hi there,

      I am using the Argo theme and I have no caption displaying with galleries.
      I have tried about everything (including contacting the theme support a zillion times and they won’t get back to me).

      I inserted the lines below in function.php and nothing happens:

      add_action( ‘after_setup_theme’, ‘argo_setup’ );
      add_theme_support( ‘html5′, array( ‘gallery’, ‘caption’ ) );

      the website is http://www.terredalizes.fr

      If anyone can help it is greatly appreciated!



  • Konstantin Kovshenin 11:20 am on April 11, 2014 Permalink
    Tags: , , ,   

    Plupload 2.x in WordPress 3.9 

    Plupload is the library that powers most of the file upload interfaces in WordPress, and in 3.9 we’ve updated the bundled library to version 2.1.1 (#25663). Here are some of things that have changed, which may affect WordPress plugins and themes.

    If you’re using direct references to Plupload’s runtime .js files, such as plupload.html5.js, note that these files are now gone. The following script handles were removed: plupload-html5, plupload-flash, plupload-silverlight and plupload-html4. If you need to enqueue the Plupload library, just use the plupload handle.

    If you’re constructing your own Plupload settings array vs. using wp_plupload_default_settings() and/or the _wpPluploadSettings object, note that some of the arguments have changed, most notably:

    • flash_swf_url should point to the new Moxie.swf file (See update)
    • Similarly, silverlight_xap_url should use the new Moxie.xap (See update)
    • The multiple_queues argument is no longer used
    • The max_file_size key has been moved to the filters array
    • The filters array now supports multiple keys, and the list of file types array has been moved to its mime_types key

    To illustrate that with code:

    $settings = array(
        // ...
        'flash_swf_url' => includes_url( 'js/plupload/plupload.flash.swf' ), // Unchanged
        'silverlight_xap_url' => includes_url( 'js/plupload/plupload.silverlight.xap' ), // Unchanged
        'filters' => array( 
            'max_file_size' => $max_upload_size . 'b', 

    Plupload version 2.1.1 has also added some exciting new options and methods, which you can find in the updated documentation.

    As a result of this update in WordPress 3.9 we were able to add drag and drop upload support directly to our TinyMCE editor (#19845), and we’ve also added a new boolean flag to wp_editor(), which you can use to enable drag and drop upload support in your own instance of the editor (#27465):

    wp_editor( '', 'my-editor', array(
        // ...
        'drag_drop_upload' => true,
    ) );

    If you run into any problems with this update in 3.9, please leave a comment on this post and we’ll be happy to help you out!

    Update: I opened #27763 to address some of the compatibility issues around the update. We might be renaming the swf/xap files for backwards compatibility.

    Update, April 13: The original swf/xap filenames were restored.

    • Andrew Nacin 1:20 am on April 14, 2014 Permalink | Log in to Reply

      Post updated to reflect changes via #27763.

    • experiencedbadmom 11:54 am on April 18, 2014 Permalink | Log in to Reply

      Thank you for the link to the manual instructions. My blog is experiencedbadmom.com tho, not experiencedbadmom.com/wordpress/ – does that matter? Also, one of the steps says to deactivate plugins – how am I to deactivate plugins if I can’t even get into my dashboard? GoDaddy is my host – do I deactivate plugins somewhere on their servers?

    • Najeeb 6:16 am on April 21, 2014 Permalink | Log in to Reply

      Hello there,

      well I am using pluploader library in my plugin and when try ‘plupload’ handle to use shipped scripts it not applying to my uploader object, even I can see libraries are loading. Any help will be much appreciated.


      • Konstantin Kovshenin 7:32 am on April 21, 2014 Permalink | Log in to Reply

        Hi there! Can you please provide more details, like a code sample? Also, has it worked in 3.8 and broken in 3.9 or does it just not work in general? Thanks!

    • pbusardo 7:13 pm on April 21, 2014 Permalink | Log in to Reply

      Perhaps this is relevant. I believe the FLA gallery uses Plupload. When I try to upload multiple files to the gallery, the GUI no longer appears.

  • Mike Schroder 7:33 pm on April 9, 2014 Permalink

    Last Week in WordPress Core 

    Howdy everyone! This is Last Week in WordPress Core for the week of March 31-April 7. I’m including all of the commits up to RC1 this week, which was released yesterday. Things are looking good, with very few remaining tickets open.

    3.8.2 and 3.7.2 were also released with security fixes, and automatic updates are rolling out.

    Developers, please test with your plugins and themes and let us know if you find issues.

    TinyMCE: As a quick note, since I’ve seen this brought up in the forums — in this release, TinyMCE no longer uses wpdialogs. This means it now needs to be enqueued by any plugin that wants to use it. As of [28024], there is a clarified warning that will appear in the JavaScript console if you attempt to use it, and it’s not enqueued.

    IE8 & wpview: Due to IE7/8 compat being necessary in TinyMCE (to resolve caret issues), IE8 and wpview are not currently the best of friends. Post RC1, fixes landed for #27546 that make wpviews degrade more gracefully.


    • Playlists: Make elements in playlists responsive and fix playlist advancement on mobile. [27894] [27895] #27625
    • Playlists: Set preload='none' for the empty <audio|video> tag. [27974] #26779
    • Playlists: Make tracks keyboard-accessible. [28023] #27644
    • A/V Shortcodes: Remove support for a caption in audio and video shortcodes. This was part of a UX iteration for the related MCE views, but these captions have since been excluded. See [27640]. [27979] #27320
    • Edit Image Modal: Make the calculation of the aspect ratio more robust. [27942] [27948] #27366
    • Do not show featured images for image attachments; remove post_supports_thumbnails() and theme_supports_thumbnails() for now. [28051] #27673

    HTML5 Galleries:

    • Remove <br> elements for HTML5 galleries; see #26697. [27914] #27637
    • Twenty Thirteen and Fourteen: Update styles to support the new HTML5 line-break-less galleries. [27926] #27637


    Theme Installer:


    • Trigger jQuery events for widget updates. widget-added when a widget is added to a sidebar and widget-updated/widget-synced for widget soft/hard updates. [27909] [27969] #19675; #27491
    • In WP_Widget, introduce is_preview() method to allow widgets to check to see if they’re currently being previewed via the customizer. [27966] #27538
    • Widget Customizer: Improve compatibility with plugin custom scripts and styles for widgets. [27907] #27619
    • Widget Customizer: Rename inject_preview_css to print_preview_css. [27968] #27534
    • Widget Customizer: Use postMessage to highlight widgets in preview or sections/controls in Customizer. [27892] [27893] #27622
    • Widget Customizer: Refactor and clean up WidgetCustomizer as wp.customize.Widgets, and make available widgets panel a Backbone view. [27985] [27986] [27988] [27995] [28034] #27690


    • Update TinyMCE to 4.0.21. [27897] #24067
    • Image Details Modal Improve look-and-feel, and add a Custom Size option to the size drop-down that reveals fields for soft-resizing the inserted image. [27918] #27366
    • Image Details Modal: Move all advanced options under a single toggle, bring back the field for CSS Class, and optimize CSS for responsive layout. [27898] #27366
    • Drag and Drop Uploading: Add new argument to wp_editor() to enable. [27901] #27465
    • Gallery Views: Avoid JS errors when image attachments lack metadata. [28008] #27691
    • Return to loading /langs/[locale].js and /langs/[locale]_dlg.js from PHP to prevent errors with missing translation files when requireLangPack() is used without its second argument. Back to using ISO 639-1 (two letter) locales. #24067; [27922] #27610
    • Clarify error when wpdialogs is not enqueued. Add wp_enqueue_editor action fired when scripts and styles for the editor are being enqueued. [28024] #16284
    • Update translatable strings. [27927] #27453, #24067
    • Tighten up toolbar and tab styles. [27978] [27983] #27279
    • Expose toolbar keyboard shortcut in Help documentation for TinyMCE, and clean up TinyMCE help dialog, removing duplicated text and leaving only Keyboard Shortcuts. [28029] #27024; [28032] #27100


    • Fall back from ext/mysqli to ext/mysql if the connection fails. This allows us to avoid breaking a site that works under ext/mysql but is misconfigured for ext/mysqli. [27935] #21663
    • Add $allow_bail argument to wpdb::check_connection() to match the connect method. [27925] #27240
    • Don’t pass a second argument to mysqli_fetch_field(). [28002] #27693
    • Rename USE_EXT_MYSQL to WP_USE_EXT_MYSQL. [28022] #21663


    • Updates: Record Plugin & Theme update statistics like we do for Core updates. [27905] [27906] #27633
    • Pingbacks: Forward pingback IP during verification. [27872] #27613
    • Dashicons: [27989] [28005] [28013] #26936
      • New icons: .dashicons-external, .dashicons-editor-contract and .dashicons-universal-access-alt.
      • Updated icons: .dashicons-code, .dashicons-universal-access, .dashicons-arrow-x-alt and .dashicons-arrow-x-alt2.
      • Restores .dashicons-post-trash as an alias for .dashicons-trash, which is the new one.
      • Use new icons in Widget Customizer.
    • Don’t try to resolve symlinks for single-file plugins. plugins_url() should not be used in this context anyway. [27999] #16953
    • Remove old links_recently_updated_* DB options that never had a UI. [27916] #27649
    • Deprecate wpmu_current_site(). [28009] #27702

    Many thanks to @adamsilverstein, @andykeith, @avryl, @azaozz, @bramd, @chiragswadia, @davidmarichal, @dd32, @dpe415, @duck_, @DrewAPicture, @DrProtocols, @ehg, @eightface, @empireoflight, @gcorne, @helen, @jackreichert, @jdgrimes, @jeremyfelt, @jesin, @joedolson, @johnbillion, @jorbin, @jond3r, @kovshenin, @kpdesign, @leewillis77, @markjaquith, @matveb, @mcsf, @melchoyce, @michael-arestad, @nacin, @Nessworthy, @norcross, @obenland, @ocean90, @pento, @plocha, @rachelbaker, @rmccue, @sdasse, @SergeyBiryukov, @siobhan, @sonjanyc, @tellyworth, Tom Adams, @vancoder, @westonruter, and @wonderboymusic for their help this week!

    For the complete list of commits to trunk, check out the log on Trac. Since we’re getting very close to release, the best way to help is to test! Let us know if you run into problems in the Alpha/Beta forums or on trac.

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc