WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Recent Updates Page 2 Toggle Comment Threads | Keyboard Shortcuts

  • Alex Shiels 2:24 am on June 28, 2014 Permalink | Log in to leave a Comment  

    Update on the Plugins page work 

    A quick update on the Plugins page (previously: here and here). The three major areas of work are the Detail modal view; the plugin-install.php landing page; and the plugin list views. Some progress so far:

    #22599 has a minimal patch for displaying plugin reviews and ratings in the Detail modal. More work is needed.

    #27440 now has API support for image banners in the Detail modal.

    @stephdau is working on the next steps for the modal, which will probably include experimenting with removing or replacing the Thickbox code, and iterating on the UI.

    I’m working on the plugin-install.php page. There’s no specific ticket for it yet, but step 1 will be a basic overhaul incorporating some of the ideas in @melchoyce‘s thread in a rudimentary fashion.

    The plan is to get these minimally functional with API support very soon, and then experiment from there with the UI and incremental improvements.

    Some closely related tickets and posts:

    #28646 and #17902 suggest some improvements to the list views, both related to unifying the search list and the installed plugins list.

    #20002 suggests API improvements related to querying multiple plugins.

    This post includes screenshots of many web/app stores, which suggest some design cues. If you’d like to help out, we could use feedback and incremental patches on those tickets; and of course the Plugins component has many other tickets in need of attention.

     

     

     
    • Pippin Williamson 2:59 am on June 28, 2014 Permalink | Log in to Reply

      I love see these kind of updates. They make me so happy :)

    • Gustavo Bordoni 11:03 am on June 30, 2014 Permalink | Log in to Reply

      +1 for these, there is a lot of love for the Plugins!

    • Paal Joachim Romdahl 7:16 pm on July 1, 2014 Permalink | Log in to Reply

      Clicking the details of a plugin opens a modal box. If one wants to check the next plugin in the search list one has to first close the existing modal box and then click the next plugin details. What about including arrows to signal a forward and backward through the detail list of plugins one made a search for? (Similar to the themes screen.)

  • Eric Andrew Lewis 1:39 am on June 28, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Media Grid Update 

    Media Grid started as a standalone plugin by Shaun Andrews, which was a reimagining of the UI as an alternative to the traditional post list view in the Media Library. The argument was that images are the ubiquitous media type in most users’ libraries, so we should provide an interface to browse media visually.

    I joined the project in late April, attempting to integrate existing Media modal code. This work was merged into the standalone plugin, and into trunk(see #24716) in early June. In the process, I created documentation for the Media code, which is the most comprehensive resource for untangling the Backbone wires in media.

    Questions were raised about what problem the grid was solving, so in order to get a more hands-on understanding of user engagement with the Media Library, Jerry Bates performed user interviews. These confirmed our assumption that images are the pervasive media type, but also surfaced the fact that users identify media in different ways – some by the thumbnail, some by what post a media item is uploaded to, some by title.

    After a good amount of UX/UI chatter in weekly meetings, we decided we could serve users better by making a few changes to the original implementation merged into trunk. We’ve landed on mock-ups for a quick pivot, which I’m working on implementing . I’ll be dropping diffs for y’all Javascript Jedis to peruse on #24716, feedback welcome and appreciated. I hope to have merge-ables by Monday morning, and then to progress to user testing.

     
  • Helen Hou-Sandi 2:42 am on June 27, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Summary of 6/25 dev chat (IRC log):

    General

    • Beta 1 is being pushed back to July 9 from July 2, with each successive beta and RC 1 also pushing back a week. The schedule has been updated.
    • oEmbed (@azaozz), i18n / language packs (@nacin), media grid (@ericlewis), and plugin installer (@tellyworth) should each have an update post published here before the weekend, outlining what has been done thus far, next steps, points needing discussion, and relevant tickets.
    • Each of the above should have a new patch ready by Monday. Across the board, it would be nice to see more work-in-progress patches — props @ericandrewlewis for recent patches on the media grid ticket
    • Daily scrubs in #wordpress-dev happening at 15:00 UTC.
    • @johnbillion would like to help coordinate people who are given time by their employers to work on WP; Make/Core post forthcoming.

    oEmbed

    • Recent updates to oEmbed: previews in the editor, media modal, added a bunch of providers
    • Todos: SSL, script sandboxing, caching improvements, UI/UX tweaks
    • Two thirds of our supported providers don’t support SSL: #28507
    • @sams suggested SSL should be a requirement for oEmbed providers going forward (have since revised to an important consideration for the time being).
    • Insecure iframes and/or insecure contained content will be blocked by newer Chrome and Firefox.
    • Two options: placeholder or a nonced, authed, proxied iframe.
    • For Monday: Placeholder fallback for SSL admin and non-SSL oEmbeds.

    i18n

    Media Grid

    • A quick phase 2 of the media grid is going forward
    • Media Grid needs a fair amount of work, not user testable yet.
    • Reminder: watch out for strings like “Edit Media” (#) won’t work well for long translations, i.e. ru_RU.
    • @ericandrewlewis asked for feedback on the JavaScript application structural decisions around Media Grid. This is likely worth a separate discussion.
    • For Monday: A user-testable patch.

    Plugin Installer

    • Screenshots for possibly comparable things.
    • @tellyworth is working on plugin-install.php and @stephdau is working on the details modal / page.
    • Next: Need to discuss what kind of data is most helpful to display for users when they are trying to figure out which plugin it is they want.
    • For Monday: @tellyworth and @stephdau will post patches in progress.

    Other

    With thanks (again) to @designsimply for note collation.

     
  • Helen Hou-Sandi 3:30 pm on June 26, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Daily scrubs for 4.0 

    Let’s do daily scrubs / ticket triage for the duration of the 4.0 release cycle at 15:00 UTC in #wordpress-dev. Fellow committers and component maintainers, please comment below if you can pledge to be there at least once or twice a week, and potentially help drive that particular scrub.

    For those who aren’t as familiar with scrubs / scheduled ticket triage sessions, they aim to provide some structure and a known time to focus on existing Trac tickets. At least one committer should be around for each one for rapid feedback. If you are unable to make the time, that’s okay – there are often contributors at various hours in the #wordpress-dev IRC channel who can give feedback and look at tickets, and ad hoc scrubs are very much encouraged. Those who are interested in reviewing patches and triaging tickets are especially welcome, and anybody is welcome to bring a ticket for eyes. If no specific tickets come up, we’ll move to reports, such as that for the next major release or ancient tickets.

     
    • Konstantin Obenland 8:28 pm on June 26, 2014 Permalink | Log in to Reply

      please comment below if you can pledge to be there at least once or twice a week

      I should be available at least once or twice a week.

    • Weston Ruter 8:36 pm on June 26, 2014 Permalink | Log in to Reply

      I have standing client meetings during this time every weekday, except for Monday and Tuesday (thanks to Canada Day :-) ). So I can be there next week. #widgets #customize

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

    Agenda for today’s dev chat:

    • Beta timing – on schedule for next week, 7/2.
    • Organize and rally around pushes on features: oEmbed, i18n, plugin install experience, media grid.
    • #22023: Remove UNIQUE for slug in wp_terms.
    • Texturize/formatting.

    Please propose other items in the comments below.

     
    • Robert Chapin 7:32 pm on June 25, 2014 Permalink | Log in to Reply

      Texturize is going well. #28564 started a bit of a debate about exotic forms of shortcode and HTML nesting. I’ve ensured that most HTML can still go inside of shortcodes. Several old issues about inline comments, escaped shortcodes, and [ and ] in hyperlinks have been resolved and unit tested. A few performance issues were fixed.

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

      Let’s talk about whether the findings of #28507 is going to be a problem sandboxed oEmbeds

    • helgatheviking 9:28 pm on June 25, 2014 Permalink | Log in to Reply

      Is this ticket Menu Item limits: https://core.trac.wordpress.org/ticket/14134 getting any love for 4.0 or is it relying on the results of the GSOC? If I ever wanted to take a crack at it, is it safe to rely on javascript for things? The entire admin requires it right?

  • Ryan McCue 2:01 am on June 23, 2014 Permalink | Log in to leave a Comment
    Tags:   

    JSON REST API: Version 1.1 

    I’m happy to announce the availability of version 1.1 of the JSON REST API.

    This release is a bit of a smaller, more focussed release as we work on increasing test coverage and squashing bugs. Here’s the juicy details:

    • Add new routes for taxonomies and terms.

      Taxonomies and terms have now been moved from the /posts/types/<type>
      namespace to global routes: /taxonomies, /taxonomies/<tax>,
      /taxonomies/<tax>/terms and /taxonomies/<tax>/terms/<term>

      Test coverage for taxonomy endpoints has also been increased to 100%.

      Deprecation warning: The /posts/types/<type>/taxonomies endpoint (and
      sub-endpoints with the same prefix) have been deprecated in favour of the new
      endpoints. These deprecated endpoints will now return a
      X-WP-DeprecatedFunction header indicating that the endpoint should not be
      used for new development, but will continue to work in the future.

      (props @kadamwhite, @rachelbaker, @rmccue, #198, #211)

    • Allow customizing the API resources prefix

      The API base (typically wp-json/) can now be customized to a different
      prefix using the json_url_prefix filter. Note that rewrites will need to be
      flushed manually after changing this.

      (props @ericandrewlewis, @rmccue, #104, #244, #278)

    • Give null as date for draft posts.

      Draft posts would previously return “0000-00-00 00:00:00″ or
      “1970-01-01T00:00:00″, as draft posts are not assigned a publish date. The API
      now returns null where a date is not available.

      Compatibility warning: Clients should be prepared to accept null as a
      value for date/time fields, and treat it as if no value is set.

      (props @rmccue, #229, #230)

    • Fix errors with excerpt.

      Posts without excerpts could previously return nonsense strings, excerpts from
      other posts, or cause internal PHP errors. Posts without excerpts will now
      always return an excerpt, typically automatically generated from the post
      content.

      The excerpt_raw field was added to the edit context on posts. This field
      contains the raw excerpt data saved for the post, including empty
      string values.

      (props @rmccue, #222, #226)

    • Only expose email for edit context.

      User email addresses are now only exposed for context=edit, which requires
      the edit_users permission (not required for the current user).

      The email address field will now return false instead of a string if the
      field is not exposed.

      (props @pkevan, @rmccue, #290, #296)

    • Correct password-protected post handling.

      Password-protected posts could previously be exposed to all users, however
      could also have broken behaviour with excerpts. Password-protected posts are
      now hidden to unauthenticated users, while content and excerpts are shown
      correctly for the edit context.

      (Note that hiding password-protected posts is intended to be a temporary
      measure, and will likely change in the future.)

      (props @rmccue, #286, #313)

    • Add documentation on authentication methods.

      Full documentation on authentication
      is now available. This documentation explains the difference between the
      various available authentication methods, and notes which should be used.

      (props @rmccue, #242)

    • Include new client JS from github.io

      The WP-API Javascript library is now loaded dynamically from
      wp-api.github.io to ensure it is always up-to-date.

      (props @tlovett1, #179, #240)

    • Don’t allow setting the modification date on post creation/update.

      As it turns out, WP core doesn’t allow us to set this, so this was previously
      a no-op anyway. Discovered during test coverage phase.

      (props @rachelbaker, @rmccue, #285, #288)

    • Check post parent correctly on insertion.

      Posts could previously be added with an invalid parent ID. These IDs are now
      checked to ensure the post exists.

      (props @rmccue, #228, #231)

    • Make sure the type is actually evaluated for json_prepare_${type} filter.

      This value was previously not interpolated correctly, due to the use of the
      single-quoted string type.

      (props @danielbachhuber, #266)

    • Return WP_Error instead of array of empty objects for a revisions
      permissions error.

      Previously, when trying to access post revisions without correct permissions,
      a JSON list of internal error objects would be returned. This has been
      corrected to return a standard API error instead.

      (props @rachelbaker, @tlovett1, #251, #276)

    • Flip user parameters check for insert/update.

      Previously, you could add a user without specifying username/password/email,
      but couldn’t update a user without those parameters. The logic has been
      inverted here instead.

      (props @rmccue, #221, #289)

    • Add revision endpoints tests

      (props @danielbachhuber, @rachelbaker, @rmccue, #275, #277, #284, #279)

    • Add post endpoint testing

      Now at >54% coverage for the whole class, and >80% for the main methods. This
      figure will continue to rise over the next few releases.

      (props @rachelbaker, @rmccue, #99)

    • Separate helper functions into global namespace.

      WP_JSON_Server::get_timezone(), WP_JSON_Server::get_date_with_gmt(),
      WP_JSON_Server::get_avatar_url() and `WP_JSON_Server::parse_date() have
      all been moved into the global namespace to decouple them from the server
      class.

      Deprecation warning: These methods have been deprecated. The new
      json_get_timezone(), json_get_date_with_gmt(), json_get_avatar_url() and
      json_parse_date() methods should now be used instead.

      (props @rmccue, #185, #298)

    As always, we’ve got a full list of all the changes and a longer changelog. Here’s who contributed to this release:

    $ git shortlog 1.0...1.1 --summary
         8  Daniel Bachhuber
        12  DrewAPicture
         3  Eric Lewis
         2  JDGrimes
         9  K.Adam White
        54  Rachel Baker
       128  Ryan McCue
         4  Taylor Lovett
         1  jeremyfelt
         1  pkevan

    Version 1.2

    We’ve already started work on 1.2, and as always, we’re looking for help!

    With version 1.2 and onwards, we’ll be tackling a bunch of extra testing for our endpoints, with the aim of eventually reaching >90% coverage. As always, we’ll also be adding new features and fixing bugs.

    We’re also working on improving the new documentation site, and expect to see the majority of documentation migrated over there. Thanks to Sarah Gooding for helping out on the documentation side.

    Core Integration

    In case you missed it, the API is now slated for integration in WordPress 4.1. WP Tavern has a great writeup on the details.

    As always, we look forward to seeing you at the team o2 and on GitHub. Now’s also a great time to remind you that you can get support for the plugin on WP.org, or by tweeting at me. Thanks to everyone who made this release great, and thanks to everyone using the plugin!

     
    • Ian Dunn 4:14 pm on June 23, 2014 Permalink | Log in to Reply

      Include new client JS from github.io

      Is this intended to be a permanent change? I could be wrong, but I think Core’s policy (and also the wporg plugin directory’s) is that assets should be local.

      (Open Sans is an exception, because it’s very difficult to reproduce everything that Google’s API does locally.)

    • Stephane Daury (stephdau) 6:20 pm on June 25, 2014 Permalink | Log in to Reply

      Awesome work, gang.

  • Scott Kingsley Clark 6:06 pm on June 22, 2014 Permalink | Log in to leave a Comment
    Tags:   

    WP Metadata API / UI office hours this Friday 

    We will continue our weekly meetings this Friday. As no other suggestions have been made, it will remain at 18:00 UTC on Fridays in #wordpress-core-plugins on Freenode IRC.

    We may be transitioning from meeting into office hours as we haven’t had as many contributors joining us at the meetings as we had hoped. We will continue developing some awesomeness over at https://github.com/wordpress-metadata/metadata-ui-api

    Feel free to hop into the issues and take ownership of new field types or documentation. We’re also looking for help with styling of the form fields and JS in relation to support for repeatable fields.

     
    • Slobodan Manic 7:47 pm on June 22, 2014 Permalink | Log in to Reply

      Fridays work for me. I can continue working on field types, submitted a PR with four new input fields (email, range, number, color).

    • nofearinc 7:56 pm on June 22, 2014 Permalink | Log in to Reply

      9pm EEST on Fridays is not really the best timing for some of us either, which is 8pm for CEST (Central Europe) folks too (sorry for not being available, but that timing is a bit off here).

    • Ryan McCue 1:21 am on June 23, 2014 Permalink | Log in to Reply

      We may be transitioning from meeting into office hours as we haven’t had as many contributors joining us at the meetings as we had hoped.

      I think that’s just a common thing with feature-as-a-plugin teams; don’t be disheartened! :)

    • deltafactory 2:06 pm on June 23, 2014 Permalink | Log in to Reply

      Was last week’s cancelled? I was there and tried to get the conversation started but no one answered.

      • Scott Kingsley Clark 2:11 pm on June 23, 2014 Permalink | Log in to Reply

        Saw you and someone else were there, unfortunately Mike couldn’t make it and I was stuck in traffic trying to get home. We are all currently planning to be there this Friday, I won’t be cutting it so close with my plans on Friday either :)

    • Scott Kingsley Clark 8:32 pm on June 27, 2014 Permalink | Log in to Reply

      It turned out that Mike Schinkel couldn’t make it this week and I once again was stuck in traffic trying to get back from a WP lunch meetup.

      I think we’re going to try and push the ‘office hours’ a little earlier in the day so we can get some of our european contributors more involved.

      But going forward, I think in general, Fridays in #wordpress-core-plugins, I’ll be in there, and if you want to chat, we can chat, not sure if an hour long meeting slot is best while we’re in the current stage, until we have more movement and planning to be done as a group. Right now we’re just executing plans as we’ve laid them out.

  • Helen Hou-Sandi 4:38 am on June 22, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Summary of 6/18 dev chat (IRC log):

    Thanks to @designsimply for her help with notes and summaries this release!

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

    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.

    Registration

    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__.

    __FILE__
    /myshortcode
    	/template.php
    	/register.js
    	/preview.js
    	/edit.php
    

    template.php

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

    register.js

    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 );
    

    preview.js

    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.

    edit.php

    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

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

      to:

      thecontent
      thecontent
      • 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:

      http://www.tinymce.com/tryit/inline.php

      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.

  • Scott Taylor 5:49 pm on June 20, 2014 Permalink | Log in to leave a Comment
    Tags: , ,   

    like_escape() is Deprecated in WordPress 4.0 

    @miqrogroove has written a blog post on his personal blog explaining why like_escape() has been deprecated in WordPress 4.0. It has been reposted below.

    Plugin authors and website developers who work with WordPress database queries should notice an important change coming in WordPress 4.0.

    The function like_escape() is no longer used in WordPress core code. It is still available as a deprecated function, so it still works in any existing plugins that rely on it. However, a new and different function is available that should be used in all new code.

    Deprecated means that anyone using code that calls like_escape() with WP_DEBUG enabled will see an error message. If WP_DEBUG_LOG is also enabled, the error message will appear in the /wp-content/debug.log file.

    Let’s look at an example of core code where I removed like_escape() and implemented the new function $wpdb->esc_like().

    3.9 Old Style

    $search_orderby_s = like_escape( esc_sql( $q['s'] ) );
    $search_orderby .= "WHEN $wpdb->posts.post_title LIKE '%{$search_orderby_s}%' THEN 1 ";
    

    What did this do? It was an old snippet from /wp-includes/query.php that set up a search for post titles. The input $q['s'] was escaped using two functions before it was added to the post_title LIKE expression. Now let’s see how I replaced that snippet in the next version.

    4.0 New Style

    $like = '%' . $wpdb->esc_like( $q['s'] ) . '%';
    $search_orderby .= $wpdb->prepare( "WHEN $wpdb->posts.post_title LIKE %s THEN 1 ", $like );
    

    There are two important differences to notice.

    • I changed the like_escape() call to $wpdb->esc_like().
    • I changed the esc_sql() call to $wpdb->prepare().

    The second change is important because esc_sql() is not secure if it is called before, or inside, the call to the new function $wpdb->esc_like(). By relying on the preferred style of the function prepare(), I can easily see that each instance of $wpdb->esc_like() will run first instead of last.

    4.0 Alternative Style

    Here is something that still works, but I avoided using it. Notice the old query is unchanged. It is critically important to call the two escaping functions in the correct order when using $wpdb->esc_like().

    $search_orderby_s = esc_sql( $wpdb->esc_like( $q['s'] ) ); // This is the correct order.
    $search_orderby .= "WHEN $wpdb->posts.post_title LIKE '%{$search_orderby_s}%' THEN 1 ";
    

    How Should I Get My Code Ready for 4.0?

    The nice thing about deprecated functions is that you can still use them and they don’t change. Your existing code should work fine.

    When you write new code, remember that using $wpdb->esc_like() is not compatible with WordPress 3.9. This should be avoided if you need compatibility with old versions. When you are ready to adopt 4.0 as your minimum version, consider using the new function.

    If you have a specific need for the new function in old versions of WordPress, I suggest copying the new function into your plugin under a different name. This would be the simplest solution, but rarely necessary.

    Why Did like_escape() Change to $wpdb->esc_like()?

    There were several problems with the old function that could not be fixed.

    • Documentation said the function’s output was safe to use in SQL queries. That was not correct.
    • The function’s output was not fully compatible with LIKE expressions in MySQL.
    • The function had been used many different ways in core code, some of which were incompatible with the desired output.
    • Changing the old function instead of creating a new one would have caused many security problems in plugins.
    • The function was related to $wpdb because of its MySQL syntax, which does not work on other databases.

    Is There a Security Problem with like_escape()?

    The old function like_escape() was not intended to be used in any security sensitive context. There are no security problems when it is used correctly.

    With that said, I am concerned that plugin authors frequently confused the old function like_escape() with esc_sql(), which was used for security. The documentation for like_escape() was misleading and very confusing about this point.

    Just remember, like_escape() does not provide any security for your database!

    So What Does $wpdb->esc_like() Do Anyway?

    Whenever user input or other raw data are copied into a WordPress query, the data must be escaped using $wpdb->prepare() or esc_sql(). This prevents certain characters, such as quotes, from getting confused with SQL commands.

    In a LIKE expression, there are additional special characters that are used as wildcards to search for partial matches in the database. Those wildcard characters have to be escaped from the user input so that they are not confused with the wildcards added by the programmer.

    Before adding user input to this type of search query, $wpdb->esc_like() should be called for compatibility, and then $wpdb->prepare() must be called for security, in that order.

    How to Use $wpdb in Functions

    It is very rare to use $wpdb->esc_like() without also running a query. But just in case you want to …

    function my_search( $input ) {
        global $wpdb;
        $escaped = $wpdb->esc_like( $input );
        ...
    }
    

    … remember to reference $wpdb as a global variable.

     
    • Mike Schinkel 6:08 pm on June 20, 2014 Permalink | Log in to Reply

      Nice writeup.

      Note there’s a code type in your “40 Alternate Style”: $wpdb->esc_like( $q['s'] )

    • JasWSInc 6:09 pm on June 20, 2014 Permalink | Log in to Reply

      I hope we will see an `esc_like()` function to serve as a wrapper for this wpdb class member like all the others (i.e. `esc_sql()`, `esc_attr()`, `esc_html()`, etc). Not a big deal to call it through the class instance, but it would be nice to have the function also; i.e. `function esc_like()`

    • Michael Adams (mdawaffe) 8:30 pm on June 25, 2014 Permalink | Log in to Reply

      Nice.

      $wpdb->prepare( "SELECT * FROM `$wpdb->posts` WHERE `post_title` LIKE %L", "Something%" ) would be cool.

      • Robert Chapin 11:38 am on July 9, 2014 Permalink | Log in to Reply

        We wouldn’t be able to interpret the % chars in a meaningful way with that syntax. By running $wpdb->esc_like() first, you still have the power to add % chars that are not escaped before preparing the query.

        • Michael Adams (mdawaffe) 9:37 pm on July 14, 2014 Permalink | Log in to Reply

          You’re right. My example was bad. Thanks.

          The following would work:


          $wpdb->prepare( "SELECT * FROM `$wpdb->posts` WHERE `post_title` LIKE %L%%", "Something" )

          Which would be the same as:


          $wpdb->prepare( "SELECT * FROM `$wpdb->posts` WHERE `post_title` LIKE %s%%", $wpdb->esc_like( "Something" ) )

          Which is the same as:


          $wpdb->prepare( "SELECT * FROM `$wpdb->posts` WHERE `post_title` LIKE %s", $wpdb->esc_like( "Something" ) . "%" )

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