Ready to get started?Download WordPress

Make WordPress Core

Recent Updates Page 4 Toggle Comment Threads | Keyboard Shortcuts

  • Simon Wheatley 2:04 pm on June 12, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    In yesterday’s Weekly Developer Chat, various minor schema change tickets were discussed. We would want to address any changes in as efficient a fashion as possible, and have discussed using the pre_schema_upgrade() function rather than dbDelta(), so we can control the queries more precisely.

    Below is a list of the tickets discussed yesterday, along with which tables they affect. Please add any questions, concerns, additional tickets, or +1’s for this work in the comments.


    • comment_author_email #21435 – “wp-includes/comment.php line85 causes slow query due to the non-indexed column” raised by @matsubobo (proposes adding an index to comment_author_email)
    • multiple-column indexes #15499 – “Add an index for get_lastpostmodified query” raised by @simonwheatley (proposes adding an index on post_type, post_status, post_date_gmt and another on post_type, post_status, post_modified_gmt)


    • option_name #13310 – “Extend option_name to varchar(255)” raised by @scribu


    • post_name #10483 – Increase field length from 200 to 400. #21212 – Reduce index length to 191 for InnoDB.
    • guid #18315 – “Add an index to the GUID column in the posts table” raised by @alexkingorg
    • post_password – #881 – “Lengthen password field for protected posts” raised by @ScytheBlade1


    • slug #22023 – “Remove UNIQUE for slug in wp_terms” raised by @nacin (related). #16230 – Increase field length from 200 to 400. #21212 – Reduce index length to 191 for InnoDB


    • modify existing index #5034 – “Impossible to have duplicate category slugs with different parents” raised by @snakefoot (proposes adding an index on term_id, taxonomy, parent)
  • Helen Hou-Sandi 7:59 pm on June 11, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    For today’s dev chat starting shortly let’s Do… 

    For today’s dev chat starting shortly, let’s:

    • Do a quick check on any of the bigger features for resource needs or sticking points (media grid, i18n, plugins page, oEmbed).
    • Talk about shared terms.
    • like_escape(): #10041.
    • Do an open-ended bug scrub, building on the momentum @wonderboymusic kicked off with commits and this post. Will guide these with specific reports to be linked in dev chat.

    Other proposed items:

    • 3.9.2 status.

    Add yours here below.

    • John Blackbourn 8:02 pm on June 11, 2014 Permalink | Log in to Reply

      Headline features for 4.0 – what do we have?

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

      Unable to attend. Let me know if I can be of any help on 10041. :)

    • Scott Taylor 9:46 pm on June 11, 2014 Permalink | Log in to Reply

      texturize tests are failing:

      1) Tests_Formatting_WPTexturize::test_quotes
      Failed asserting that two strings are equal.
      — Expected
      +++ Actual
      @@ @@
      -‘Here is “a test with a link”’
      +’Here is “a test with a link“’


      2) Tests_Formatting_WPTexturize::test_quotes_before_numbers
      Failed asserting that two strings are equal.
      — Expected
      +++ Actual
      @@ @@
      -‘Class of ’99’s’
      +’Class of ‘99’s’


      3) Tests_Formatting_WPTexturize::test_other_html
      Failed asserting that two strings are equal.
      — Expected
      +++ Actual
      @@ @@
      -‘‘Quoted Text’,’
      +’‘Quoted Text‘,’


      4) Tests_Formatting_WPTexturize::test_entity_quote_cuddling
      Failed asserting that two strings are equal.
      — Expected
      +++ Actual
      @@ @@


      5) Tests_Paginate_Links::test_defaults
      Failed asserting that two strings are equal.
      — Expected
      +++ Actual
      @@ @@


  • John Blackbourn 5:52 pm on June 11, 2014 Permalink | Log in to leave a Comment  

    SSL taskforce 

    We’re hoping to make many improvements relating to SSL/HTTPS support in 4.0. Several fixes have already gone in over the last couple of weeks, and several are in progress.

    Below is an ad-hoc list of SSL related bugs and potential enhancements that I’ve experienced in one way or another. Please leave a comment with details of other SSL related issues you are aware of (whether they’re already in Trac or not). I’m going to be tackling as many issues as possible for this release. We may or may not find some time to discuss some of this during tonight’s dev meeting.

    Issues with HTTP front end and an HTTPS backend

    • Customiser previews break, site is requested over http
    • ‘url’ and ‘return’ links in customiser have incorrect scheme
    • Media inserted into posts gets the incorrect scheme
    • GUIDs use the admin scheme
    • Network admin, some mixed http/https issues – #14867, #27499
    • Idea: filter to enable plugins to specify URLs / post IDs / paths which should be forced to https?
    • Idea: filter to enforce front end over http? (excluding urls from above filter)
    • Arguments in favour of a front-end ajax handler: x-domain and x-protocol issues with domain mapping

    General issues with HTTPS on front end

    • Should we force https scheme on local content in post content, post excerpt, comment text, etc?…
    • Should we force https scheme using canonical? – fixed – #27954
    • Should we force https scheme for enqueued local scripts/styles?

    General issues with HTTPS backend

    • Mixed content in the editor – can we force https scheme for local content? What about CDNs etc?
    • XML-RPC does not enforce https – looks like a wontfix – #28424
    • Theme thumbnails aren’t loaded over https – fixed

    General HTTPS issues

    • No support for secure oEmbeds
    • wp_get_attachment_url() doesn’t respect scheme – #15928
    • HSTS – not something core should do – could be enabled with a filter but not enabled by default
    • “Update siteurl and home as well” on network admin loses https scheme

    Issues specifically with HTTPS everywhere

    • Not all cookies have secure flag set – #28427
    • Andrew Nacin 6:14 pm on June 11, 2014 Permalink | Log in to Reply

      I think HSTS could be enabled by a constant; this would handle XML-RPC forcing in the process (#28424).

    • Andrew Nacin 6:16 pm on June 11, 2014 Permalink | Log in to Reply

      I don’t think canonical is enough for forcing SSL. We probably need a new FORCE_SSL constant that handles everything over SSL and prevents any requests over HTTP (basically, weak application-side HSTS). The next logical extension to that would be having FORCE_SSL_HSTS that does both SSL + HSTS. Or, as said, a filter.

    • Zack Tollman 6:21 pm on June 11, 2014 Permalink | Log in to Reply

      I think keeping FORCE_SSL separate from the HSTS control is important as undoing HSTS is more complicated than toggling a constant. You need to set a new header.

      I never thought of setting HSTS via PHP, but I think this is a fantastic idea. We just need to consider undoing it by setting a header to cancel HSTS if necessary. I could see this being a confusing and frustrating problem for devs.

    • Dean Taylor 7:52 pm on June 11, 2014 Permalink | Log in to Reply

      Consider “blacklisting” and notification to admins of non-HTTPS embedded content. For example http://prezi.com/ embeds do not support HTTPS. Even if you change the embed URL to HTTPS ultimately it loads some content over HTTP causing mixed content warnings to users.

      The idea is to help existing WordPress sites with their transition to HTTPS.

      • Zack Tollman 6:12 pm on June 13, 2014 Permalink | Log in to Reply

        This is a good idea, but perhaps not ideal for core. I think that while this SSL efforts are underway, a plugin that provides this feature should be developed.

    • webaware 11:04 pm on June 11, 2014 Permalink | Log in to Reply

      I think you need to make any moves to force SSL an option. In the case of HTTPS backend, forcing SSL on content in the editor can break the frontend if the site certificate is self-signed, for example; visitors would see patches of missing content because the certificate is untrusted. If the frontend is set to HTTPS, however, then it is appropriate to force content to HTTPS too.

      I reckon the idea to handle HTTPS for enqueued scripts and stylesheets in core is terrific. If you’re doing that, you also want to handle media added to content dynamically, which you can do via the wp_get_attachment_url and upload_dir filters.

      You might as well enforce HTTPS for scripts and stylesheets whether local or non-local, since they are malware vectors and should either work or not — no “works if visitor allows it” nonsense. A failed non-local script load means some script doesn’t run, but an insecure content warning means the site looks unsafe to a visitor and can scare people away (and the script load fails anyway on any decent browser).

      Forcing HTTPS for non-local content must be an option, if done at all. Non-local content, including CDNs, may not have SSL hosting or may have self-signed certificates. Visitors can be warned (by their browser) that the site includes mixed content and then accept to view the “unsafe” content. It’s a bad smell, but it happens on some sites. Forcing HTTPS would effectively remove that content from the site.

      Before setting enforcement, it might be a good idea to check that WordPress can actually detect SSL:

      • reverse proxies often don’t pass through the HTTPS environment variable for SSL connections
      • some reverse proxies pass HTTP_X_FORWARDED_PROTO or another environment variable instead (but that can be spoofed)
      • some reverse proxies don’t pass ANYTHING identifying the connection as originating on SSL

      I have a dodgy fix for that last scenario, but it’s a stab in the dark thing and must be installed with intention by someone who has identified their problem: https://gist.github.com/webaware/4688802

    • Terence 4:57 pm on June 12, 2014 Permalink | Log in to Reply

      The problem is that for plain text Apache2 figures out which vhost you meant via the request. Plain text is easy.

      But for SSL based requests, Apache2 doesn’t even get the request to process until after the SSL encryption is established and by then you got the wrong VHOST and wrong cert.

      The old method just says send it to the first VHOST with SSL. That’s why *.qloudpress.com will work: the wildcard cert is fine for subdomains. When you want to use someotherdomain.com, Apache2 will still send you to the wrong VHOST and SSL cert. Previously, you bound SSL VHOSTS to separate IPs to get around that.

      That’s where SNI (Server Name Indication) Independent of IP comes in. It figures out the requested web site and VHOST before Apache2 starts processing the request. You ask for someotherdomain.com, you get sent to the correct VHOST and SSL certs. Apache2 serves the request using the correct certs and all is right in the world.

      SNI is definitely the way to go.

    • Jan Thiel 4:58 pm on June 16, 2014 Permalink | Log in to Reply

      If not covered by the other changes already, please finally approach https://core.trac.wordpress.org/ticket/20534 ;-)

      Nice to hear WP Core finally learns HTTPS!

      One more thing: I belive forcing HTTPS might not be the right way. The default way should be WP delivers its content with the protocol it was requestet. Quite simple for starters and enough to solve many problems right now.
      An option (just a simple one) to make the whole Blog or only WP-Admin HTTPS-Only would be a very nice addon. But after all, it might be much more itelligent to consider “Force HTTPS for Logged In users” instead of “Force HTTPS for WP-Admin”. Because WP-Admin at all is not that important to secure. It is the User and their credentials that has to be secured via transport! Combining that switch with the Secure- and HTTP-Only Cookie Flags should make kind of a dream team.

      Good hunting, brgds


    • John Blackbourn 5:01 pm on June 16, 2014 Permalink | Log in to Reply

      Thanks Jan, I’ll add #20534 to the list!

      Of course WP won’t be forcing any particular protocol on anybody. What we’re aiming to do is ensure that if someone does use SSL on their site, then everything that should be is served over SSL (and vice versa).

    • Just a guy 5:24 pm on July 10, 2014 Permalink | Log in to Reply

      Sorry, I’m late to the party, just saw this Also, I apologize if this has already been mentioned, but I haven’t seen it explicitly, so I’ll mention it just in case.

      On multisite networks where a wildcard certificate is used and SSL is forced in login/admin areas network-wide I’ve seen issues getting cookies to carry over from the https backend to the http frontend which results in the admin bar being unavailable on the front-end

      For hosting I use WP Engine, which is fairly widely used, so I assume it’s not just an issue with the host. As a work around I’m using WPMU DEV’s domain mapping plugin (based on Donncha’s original domain mapping plugin) and it’s a reasonable temp fix, but not ideal.

  • 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

  • Scott Kingsley Clark 4:00 pm on June 5, 2014 Permalink | Log in to leave a Comment

    WP Metadata API / UI team meeting hours vote 

    It was brought up that our current meeting time at 18:00 UTC on Fridays in #wordpress-core-plugins on Freenode IRC is not necessarily the best for everyone.

    What day would be better? Around what time would be better?

    This week’s meeting will continue as planned at the existing time on Friday, but next Friday’s meeting will be postponed due to a scheduling conflict with @mikeschinkel and I.

    • Slobodan Manic 6:25 pm on June 6, 2014 Permalink | Log in to Reply

      Hi. No one around for the meeting this week?

      • Scott Kingsley Clark 6:35 pm on June 6, 2014 Permalink | Log in to Reply

        We’re usually just hanging in #wordpress-core-plugins during that time frame, lately we’ve just been working through issues and code together. Not a whole lot of discussion during this period beyond “I’m working on this” :)

  • Helen Hou-Sandi 7:20 pm on June 4, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Proposed agenda items for today’s meeting:

    • State of .org APIs for plugins and i18n (@tellyworth and @nacin), where people can help with tickets, storyboarding, or otherwise.
    • Taxonomy roadmap: #17689 needs active discussion, please.
    • Media grid: #24716
    • oEmbed sandboxing: #28249

    Add anything in comments below.

  • Helen Hou-Sandi 9:44 pm on June 1, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Summary of 5/28 dev chat (IRC log):

    • @nacin and @tellyworth have been working on the .org API side for i18n and plugins page improvements respectively and should be ready for work on the core side soon. Be on the lookout for tickets and discussions.
    • @ericlewis has been working through the Media component in Trac and will be holding weekly scrub in #wordpress-dev alongside media grid chats, Fridays at 17:00 UTC.
    • @wonderboymusic has been evaluating various oEmbed endpoints as we add and remove them. Some services need some more evaluation: #28379.
    • Embed representations in wpview need an iframe sandboxing solution investigated to avoid script conflicts inside TinyMCE and the admin: #28249
    • The JSON REST API came a long way in the past week, especially on the documentation front, and is being placed onto the roadmap for the 4.1 release. From @nacin:

    1.0 is a great step in the right direction; let’s push it hard; let’s put it squarely, loudly, and officially on the 4.1 roadmap (I’m comfortable doing that); let’s get a lot of core contributors focusing on it for the final mile, especially when it comes to internals

    let’s get a lot of people to build things on it, including inside automattic, mobile apps, even wordpress.org stuff; let’s branch off 1.0 so we can decide paint and carpet colors on the master branch

    •  And finally, several people were added to various Trac components as component maintainers. You can be added at any time, or get on the road to becoming one by signing up for granular notifications on the components page.
    • Eric Andrew Lewis 10:35 pm on June 1, 2014 Permalink | Log in to Reply

      I think component maintainer gravatars should be surfaced to the components page, so we can see the core community at a glance rather than clickering into each.

  • Janneke Van Dorpe 2:13 pm on May 30, 2014 Permalink | Log in to leave a Comment

    GSoC: Editor Experiments 

    I’ve not posted on /core before, so, hello everyone! :) I’m Janneke and I’m currently working on my GSoC project. I’m from Belgium, but I currently live in Scotland and study philosophy at the University of Glasgow. This is something different entirely, but I started playing with WordPress a bit last year and enjoyed it a lot. :)

    The original proposal was focussed on the front-end editor and content blocks, but that has changed a bit. I’ll focus on the back-end editor first instead, though the work will likely be reusable for a front-end editor. I’ll also focus on a bit more than just “content blocks”, so that’s why I’ve titled this “Editor Experiments”.

    My general goals are to try to simplify and visualise the editor more, and to improve the workflow by providing as many tools as possible inline, at the right place and time. A lot of these ideas are not new, of course, and can be found in other editors and Joen‘s and Mel‘s mockups from last year. In order to visualise the editor more, I’ll try to make it easy for plugins to register shortcodes with previews for them, like there are now previews for a couple of media shortcodes such as galleries.

    I’ll post an update on this blog every Friday with the progress I’ve made. I meant to publish a post last Friday, but didn’t have access to this blog yet, so here’s one for both weeks. I’ve set up a GitHub repo, and for now that’s the only place where you can download the plugin.


    I’ve empty the TinyMCE toolbar, leaving only the most general tools, undo/redo, paste as plain text, remove format and help. On the other side we can control the the screen: switch between visual and text mode and activate fullscreen mode.

    Screen Shot 2014-05-30 at 13.35.31

    Instead of putting the title in a tiny box, I moved it to the editor as a first heading so it looks the same as on the front-end. Themes can style it appropriately.

    Screen Shot 2014-05-30 at 13.41.37

    Whenever you move the focus to an empty paragraph, a suggestion pops up to insert a “content block”.

    Screen Shot 2014-05-30 at 13.46.29

    To insert aligned images, you can put your cursor at the start of a paragraph.

    Screen Shot 2014-05-30 at 13.58.42

    Clicking on it gives you some kind of modal, where you can choose a block to add to your post. Of course, in the future plugins will be able to add their own blocks by registering shortcodes. So blocks can be block level HTML elements and block level shortcodes.

    Screen Shot 2014-05-30 at 13.49.21

    What happens after clicking on one of the blocks will depend on the block. Clicking on any of the media blocks will forward you to the media modal. Plugins can have a custom modal to configure the shortcode, which will likely also be used to edit it. Of course, blocks that require no configuration are added immediately (like a horizontal rule).

    To format text, you should select it, and a toolbar will pop up.

    Screen Shot 2014-05-30 at 14.03.56

    And let’s add a link.

    Screen Shot 2014-05-30 at 14.06.06

    That’s it for now. :)

    In the next two weeks I’ll work on the registration of views for shortcodes.

    Now I’d love to hear what you think! I really value your opinion and brilliant ideas. Please do try it, and file issues on GitHub.

    • andrei1709 2:21 pm on May 30, 2014 Permalink | Log in to Reply

      Hello and pleased to meet you!
      Your suggestion looks good, but wouldn’t this send too many GET requests to the server, thus making the text editor more laggy?

      • Janneke Van Dorpe 3:59 pm on May 30, 2014 Permalink | Log in to Reply

        For the previews? Currently galleries, playlists etc. are already previewed in the editor. They’re put together from templates, so the output of the shortcode is not requested. But yes, depending on the shortcode, it will always take some time to generate it, but not more than on the front-end.

    • Remkus de Vries 2:23 pm on May 30, 2014 Permalink | Log in to Reply

      I like where this is going. One thing we’d have to be careful with is not putting to much stuff in the modal pop-up. All the various media types would only need one button and take if from there to what we know now.

    • tomdryan 2:26 pm on May 30, 2014 Permalink | Log in to Reply

      Good stuff!

      I’ve wanted to see the registration of shortcodes, along with content blocks and I’m glad you are working on it. In your registration procedure/data structure, please include a description of the shortcode function, supported parameters and the source of the shortcode (which plugin created it).

      Also, it would be nice if you enabled standard widgets to be inserted anywhere and if you enabled any widgets to have a corresponding shortcode (there are plugins that do this now, but it should be included as part of your overall re-envisioning of content creation).

      Keep up the good work!

    • tomdryan 2:32 pm on May 30, 2014 Permalink | Log in to Reply

      Also, it would be nice if you put this in the form of a plug in at some point, so those of us non-coders can test it out and provide feedback.

    • Brad Touesnard 2:37 pm on May 30, 2014 Permalink | Log in to Reply

      Very cool, great work, looking forward to seeing more of this.

    • Eric Binnion 2:47 pm on May 30, 2014 Permalink | Log in to Reply

      Looks interesting! I went ahead and starred the Github repo and I look forward to playing with this :)

    • Christiaan Conover 2:56 pm on May 30, 2014 Permalink | Log in to Reply

      Great idea! I love seeing a new take on the way the editor functions to make it more flexible and extensible. I’ll definitely be trying out your solution!

    • Seth Rubenstein 3:25 pm on May 30, 2014 Permalink | Log in to Reply

      Great idea. Can’t wait to see what’s possible with the shortcode registration.

    • @ubernaut 3:32 pm on May 30, 2014 Permalink | Log in to Reply

      looking good.

    • camu 4:02 pm on May 30, 2014 Permalink | Log in to Reply

      It reminds me of Visual Composer (check CodeCanyon).

      • Janneke Van Dorpe 4:13 pm on May 30, 2014 Permalink | Log in to Reply

        The biggest difference is that Visual Composer is more like a page builder. If you just want to write something, it’s very confusing.

        • binarymoon 4:22 pm on May 30, 2014 Permalink | Log in to Reply

          that said – I’d love to see some visual composer style functionality built into this. Even if it’s just the ability to add additional shortcodes to the popup through a plugin.

          Regardless – I think this looks sweet. If you create a plugin for it so I can install through wp.org then I’d love to test it out.

    • Chris Reynolds 4:19 pm on May 30, 2014 Permalink | Log in to Reply

      I’d be really interested in seeing how this fares vs. the regular editor in user testing. It looks good, but I wonder about the lack of the WYSIWYG (or, more specifically, the stripped-down toolbar). For me, I use keyboard controls to do things like bold or italics, so selecting text and waiting for the pop up wouldn’t bug me much, but some of the other things (content blocks and links) might not be immediately intuitive. But I have no idea — would be great to see some testing :) and +1 for the pluginified version. You get a plugin for this and maybe the admin-help-come-user-testing team can maybe run some tests for it (or at least add it to the list).

    • Diego de Oliveira 4:49 pm on May 30, 2014 Permalink | Log in to Reply

      Just tested this plugin and… wow, it’s already awesome! Congratulations!

      I think that this approach could really solve the main issues of CEUX project and would integrate really good with the FEE. The editing experience reminds a lot of Medium editor, which is good. And I really liked the modal for content blocks, looks like a good solution for scalability of content blocks.

      One thing that the CEUX project had was the possibility to sort / reorder content blocks. Any plans for something like this? I know that drag / drop is naturally possible for media objects (and other possible views), but it would be cool if we could do the same with the usual elements, like paragraphs, lists, tables, etc.

      And please, keep the awesome work!

      • Janneke Van Dorpe 4:58 pm on May 30, 2014 Permalink | Log in to Reply

        Great! Thanks for giving it a try!

        Yes, maybe. I’ve experimented a bit with with drag and drop of direct children of the body, which is challenging, but could work. That be really cool. I know that arrow are really useful sometimes, especially on touch devices, but I really hate adding so much buttons/icons. :)

        • Diego de Oliveira 5:14 pm on May 30, 2014 Permalink | Log in to Reply

          Yeah, “less is more”, almost always! More buttons/icons = more cluttering, and a strong point for your approach is how clean is the process of editing content. But for touch devices… that’s would be challenging, for sure!

          There are some sortable js libraries that works on touch devices too, but I don’t know if it would work for a really long content that would be edited in a smartphone. Still, I would prefer drag ‘n drop instead of arrows. At least for me, it feels more intuitive.

      • Janneke Van Dorpe 4:59 pm on May 30, 2014 Permalink | Log in to Reply

        I’ve experimented a bit with with drag and drop of direct children of the body

        This sounds so weird out of context.

    • Paal Joachim Romdahl 5:12 pm on May 30, 2014 Permalink | Log in to Reply

      I am thinking beside the eye (visual) mode there can also be a grid icon. Turn on the grid to place elements in grid cells (kinda like table data cells). Click inside a cell and see the cell walls go darker blue. Write and add content into the specific cell. Turn off the grid to see how the content is aligned into nice columns and rows.

      Adding break points. Resize the browser and click somewhere to make a break point. At each break point redo any of the content. Easy way to create media queries directly inside the content creation area. Perhaps a way to turn break point view on or off.

      • Janneke Van Dorpe 5:18 pm on May 30, 2014 Permalink | Log in to Reply

        Yes, columns is a much requested feature… I’m not sure if something like this should added in the content itself. The theme should handle that. What if you divide your content into 2 columns and switch to a smaller width theme? :/

        I’m not sure what you mean in the second paragraph.

        • Paal Joachim Romdahl 5:33 pm on May 30, 2014 Permalink | Log in to Reply

          Ok instead of a grid it is important to add items to columns one can see. To directly see how it looks. A grid is basically about seeing how elements are together on a page.

          Another way to to drop/click an element next to another automatically creating a row of two elements.

          Break points to where the page changes to another layout. Here is an example on how it is done in Macaw: https://www.youtube.com/watch?v=lz7MlRSAR-I

          Creating visual media queries directly in the content screen instead of creating them through CSS (or having the option to do so).

          • Janneke Van Dorpe 5:51 pm on May 30, 2014 Permalink | Log in to Reply

            Break points to where the page changes to another layout. Here is an example on how it is done in Macaw: https://www.youtube.com/watch?v=lz7MlRSAR-I

            Creating visual media queries directly in the content screen instead of creating them through CSS (or having the option to do so).

            Why would you want to do that? Isn’t that something for the theme to handle? I don’t really want to make it more difficult for writers to write something in WordPress. I want to make it easier. :)

    • Juanfra Aldasoro 5:28 pm on May 30, 2014 Permalink | Log in to Reply

      Looking and working great :) I think that something like this (if it is coded with an extensibility approach) could normalize the diverse world the page builders are suffering these days. This way WordPress would have a final answer for the call on builders and shortcodes – as it did before with the customizer and options/settings for example.

    • Robert Chapin 2:09 pm on June 1, 2014 Permalink | Log in to Reply

      This is conceptually awesome. The editor is the soul of WordPress and yet is often neglected during discussions of new features.

    • bduclos 9:00 am on June 2, 2014 Permalink | Log in to Reply

      Looks really good!
      Is it planned for WordPress 4.0 or later?

    • PeterRKnight 11:27 am on June 2, 2014 Permalink | Log in to Reply

      Looks amazing already. I love where this is going.

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

      Really liking this, especially the inline text formatting.

      Have accessibility considerations been made for keyboard-only input?

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

        It wouldn’t be less accessible than the current toolbar. You can still use keyboard shortcuts to execute editor commands. The toolbar currently shows up when selecting content with your keyboard, but I’ll need to add a shortcut to move the focus to the toolbar. If you have any suggestions, feel free to share. :)

    • Manny Fleurmond 9:08 pm on June 10, 2014 Permalink | Log in to Reply

      Little iffy on the title being part of the editor but everything else is awesome. Having shortcodes being registered in your modal would be awesome for plugin developers. I’d probably find a way to merge your modal with the existing media modal, since all of the media buttons are repeated. Heck, it could be a chance to abstract the media modal to an “insert content block’ modal.

      I’m definitely keeping an eye on this. Great job.

    • morethinking 9:07 am on June 19, 2014 Permalink | Log in to Reply

      First of all, thanks for doing this. This is something that many people in the WordPress community have been wanting for a long time (as the popularity of page builders indicates).

      With that said, I would like to offer my two-sense worth on the issue of columns.

      You wrote:

      “Yes, columns is a much requested feature… I’m not sure if something like this should added in the content itself. The theme should handle that. What if you divide your content into 2 columns and switch to a smaller width theme?”

      In my opinion, columns are more often than not an issue of content and should be part of the editor. What’s more, I believe there are solutions to the issue that you raised. Take a look at the Live Grid Example here: http://getbootstrap.com/2.3.2/scaffolding.html.

      Beyond that, obviously a user needs to pick a theme that works with his or her particular content. If someone wants columns and a particular theme doesn’t work with their columns then they should either choose a different theme, modify the theme so that it fits in with their content or give up on using columns.

      What I don’t think should be done is to leave the option of users organizing their content into columns to theme developers (except in those cases where columns are being used more for design purposes). I also don’t see why the option shouldn’t be included because of those rare cases where a problem may develop.

      One last thought/point. It may be worth taking some time to look at the Squarespace layout editor to see what they have done in general as well as how they handle columns.

      With that said, once again thanks for the great work.

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

        When people talk about columns, the first thing I think of is splitting the whole content in two columns, but that’s not what they mean in most cases. That’s why I suggested that the theme should handle it, because in that case it makes sense.

        Sure, I can see why it’d be useful. I’m not sure if it can be done within TinyMCE, but I have some ideas. I’ll definitely give it a try at some point.

        I’ve looked at most editors on the internet, including Squarespace. :)

    • morethinking 9:07 am on June 22, 2014 Permalink | Log in to Reply

      I see that you have done your homework :).

      Glad to hear that you are willing to give it a try.

      Just one question, I’m not sure what you mean by ‘splitting the whole content in two columns’. What I have in what one might find on a home page — with different sections of the page divided into different columns to display the content differently. It would be nice if the end user could have control for laying out content like that.

  • Eric Andrew Lewis 3:50 pm on May 29, 2014 Permalink | Log in to leave a Comment

    Media component office hours 

    Weekly office hours (bug scrubbing and feature development chat) for the Media component will start tomorrow, combining with Media Grid’s weekly meeting.

    I’ve heard the Media component is “where tickets on trac go to die,” let’s see what we can do to thwart that status quo.

    Our Media Grid meetings have been held every Friday at 1700 UTC in #wordpress-ui. We’ll keep the same time, but move the meeting into #wordpress-dev.

  • Helen Hou-Sandi 7:16 pm on May 28, 2014 Permalink | Log in to leave a Comment
    Tags: , ,   

    Summary for 5/21, Agenda for 5/28 

    Summary of 5/21 dev chat (IRC log):


    • Posts like the i18n goals one serve as a great model for anybody who has ideas for a feature or component roadmap, whether that’s within one cycle or longer term: a list of concrete goals that can be divided up into specific tasks.
    • The make/* blogs should be used as much as possible for discussions and progress updates. Teams that have been using separate P2s but should consider using the make.wordpress.org instead for wider reach and more active participation from the community.
    • Keep in mind that plugins are supposed to encourage rapid and possibly wild experimentation – please do not discourage that.
    • Think of meetings as blocked out times where you can more reliably get a group together and get unstuck as needed, but we should take advantage of async (Trac, P2) and adhoc (IRC outside of meeting) discussion as much as possible.

    Team Updates

    • i18n goals for 4.0 have been posted, @nacin is seeking people to help with a lot of it. @yoavf, @kovshenin, @iandunn, @coffee2code, and @otto42 have done or will do some of the i18n tasks.
    • JSON REST API was given another week to collate a detailed compare-and-contrast with the other available APIs, including the JSON API plugin and Jetpack/.com’s API, and proven client implementations.
    • Media Grid has a narrowed scope for 4.0 inclusion: something more visually driven than the standard list table, much like theme browser brought to themes and is being investigated for plugins in 4.0. Will also fix some long-standing issues that were brought in with 3.5.
    • Editor improvement ideas: @markjaquith and @avryl have put together a proof-of-concept plugin that we should smooth out and make a decision on.

    Agenda for 5/28:

    • Make final decision on JSON REST API.
    • One sentence updates from various groups – i18n, media grid, plugins, oEmbed, etc. Come prepared.

    Please propose any other agenda items in the comments below.

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