Ready to get started?Download WordPress

Make WordPress Core

Recent Updates Page 4 Toggle Comment Threads | Keyboard Shortcuts

  • 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


      $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" ) . "%" )

    • rajlaksh 5:36 pm on August 9, 2014 Permalink | Log in to Reply

      Thanks for This Valuable Post.

      But i found it little difficult so i swift $WPDB to MySqli.

      MySqli easier than $WPDB. :)

  • Mike Schroder 6:03 am on June 19, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Last Week(s) in WordPress Core 

    Hi Everyone! It’s time for another update. This edition covers through Sunday, June 15th, and has taken a while due to travel, but @swissspidy & @designsimply have joined the team, helping to gather the information to bring us up to date. Hopefully this will help these updates be a bit more sustainable over time. If you’re interested in pitching in with these updates as well, please let me know in the comments below!

    Especially of note are the first pass of the grid view for the media library, several SSL and oEmbed updates, and a new ‘Beta Testing’ tab on the Plugins screen.


    • Plugins Screen: Add a new ‘Beta Testing’ tab on the plugin installation screen, for features as plugins such as Press This. [28749] #28513
    • Media Library: Grid view for the media library, first pass. This is alpha; expect imperfection to start. [28682] #24716


    • Forcing SSL logins now forces SSL for the entire admin. [28609] #10267
    • Force SSL on the frontend when the home URL uses HTTPS. [28610] #27954
    • Force SSL admin when siteurl is explicitly configured with HTTPS. [28674] #27954
    • Use a secure logged_in_cookie when the home URL is forced HTTPS. [28627] #15330
    • Deprecate url_is_accessable_via_ssl(). [28709] #19555


    Themes and Templates

    • Add a filter to human_time_diff() to allow more detailed depictions of time differences. [28670] #27271
    • Allow simple modification of sections of the title by adding a wp_title_parts filter to wp_title(). [28669] #17877
    • Add CSS rules to ensure that videos will be responsive, regardless of theme. [28650] #28414
    • Replace TEMPLATEPATH and STYLESHEETPATH with get_template_directory() and get_stylesheet_directory(). These constants are now deprecated [28563] #18298
    • Update Twenty Thirteen and Twenty Fourteen to Genericons 3.0.3. [28692] [28693]


    • Improve keyboard accessibility for the media modal. [28607] #23560
    • Add screen reader labels to the date inputs on the post editing screen. [28730] #25461


    • When parsing the main query, if s is set to empty: ?s= and $this->is_main_query() && array_key_exists( 's', $this->query ) – kill the query instead of loading the homepage. This will load the search page with no results. [28612] #11330
    • Kill queries that explicitly pass empty arrays to category__in, tag__in, tag_slug__in, and author__in to WP_Query. [28664] #28099
    • Fix SQL generation when meta_query has an 'relation' => 'OR' for its queries and wants to 'orderby' => 'meta_value'. [28659] #25538
    • Allow users to sort posts by type in WP_Query. [28605] #28214
    • Add access modifiers to WP_User_Query Add magic methods for BC: get(), set(), isset(), unset(), and call(). [28528] #27881, #22234


    • Wide-reaching changes to do away with many instances of variable-variables. See #27881 for full list of changes.
    • Eliminate use of extract() within WordPress. #22400
    • Fix curly quotes around numbers when applicable. [28721] #8775
    • Only include relevant post authors in WXR exports. [28731] #20206
    • Append the date to $wp_version in the build output, for nightly packages. [28611] #26751.
    • Update wp_insert_comment() and wp_new_comment() with a check for successful database insert. [28672] #28254
    • Use get_pages() instead of a raw SQL query in get_body_class(). [28696] #28159
    • Pre-populate the selected URL or mailto:<email-address> when “Insert/edit link” is clicked. [28705] #19992
    • Live update the menu item title when the user is editing the “Navigation Label” field. [28707] #23076
    • Deprecate get_all_category_ids(). Suggest get_terms() as a replacement. [28679] #21200
    • Deprecate like_escape() and replace with $wpdb->esc_like(). [28711] #10041
    • Redirect edit.php?post_type=attachment to upload.php to avoid an empty list table. [28729] #27951



    • Update TinyMCE to 4.0.28. [28606] #28391, #27941
    • In iOS, fix placing the caret at the bottom of longer posts when the keyboard is open and disable resizing on switching editors and on show/hide of the kitchen sink row. [28626] #28242
    • Fix problems with undo/redo after resizing an image several times. [28614] #28389
    • Fix saving the editor content on switching from Visual to Text. [28576] #28353

    Thanks to @aaroncampbell, @adamsilverstein, @alexander.rohmann, @aliso, @atimmer, @avryl, @azaozz, @boonebgorges, @bramd, @celloexpressions, @clifgriffin, @coffee2code, @danielhuesken, @DavidTheMachine, @DeBAAT, @donncha, @DrewAPicture, @eddiemoya, @edwin-at-studiojoyo.com, @ericlewis, @filosofo, @frank-klein, @Funkatronic, @garhdez, @gauravmittal1995, @gcorne, @georgestephanis, @ghost1227, @grahamarmfield, @harrym, @helen, @iamtakashi, @iljoja, @issuu, @ixkaito, @jackreichert, @JanHenkG, @Jayjdk, @jdgrimes, @jeffstieler, @jeremyfelt, @jesin, @jgadbois, @jjeaton, @jkudish, @joedolson, @johnbillion, @johnjamesjacoby, @johnzanussi, @jtsternberg, @kitchin, @knutsp, @kovshenin, @kpdesign, @kraftbj, @kurtpayne, @kwight, @lancewillett, @lessbloat, @markoheijnen, @mdbitz, @MikeHansenMe, @mikemanger, @miqrogroove, @mrmist, @MuViMoTV, @nabil_kadimi, @nacin, @nd987, @Nessworthy, @netweb, @niallkennedy, @ocean90, @obenland, @pdclark, @pento, @purzlbaum, @rclations, @redsweater, @ruudjoyo, @schoenwaldnils, @scribu, @senlin, @SergeyBiryukov, @sharonaustin, @shaunandrews, @simonwheatley, @sixhours, @slimndap, @solarissmoke, @tar.gz, @tillkruess, @topher1kenobe, @torresga, @UmeshSingla, @winterDev, @wonderboymusic, @wpsmith, @zamfeer, and @duck_ for their core contributions!

    Thanks to @swissspidy & @designsimply for their help with compiling this post.
    Revisions covered: [28528] to [28757]. For the complete list of commits to trunk, check out the log on Trac.

    Interested in joining in? Write or test a patch for 4.0.

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

    6/18 agenda, 6/11 meeting summary 

    Proposed agenda; as always, please comment below with any additions you may have. Apologies for the late post today.

    • i18n: #28571 (Language updates problems), #28577 (Allow language to be chosen during initial install), next steps.
    • Customizer component.
    • Editor experience.
    • Plugins page improvements (UI/UX prompt post).
    • Schema changes.
    • #22023: Remove UNIQUE for slug in wp_terms.
    • SSL: #12609: Enabling FORCE_SSL_ADMIN breaks wp-cron.php

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

    (More …)

  • Mel Choyce 9:25 pm on June 17, 2014 Permalink | Log in to leave a Comment

    Improving the Plugins Page: Follow-up 

    Following up on this earlier post: http://make.wordpress.org/core/2014/05/28/improving-the-plugins-page/

    After chatting a bit with Alex Shiels, Nacin, and Helen, I’ve put together a first pass at what an improved “add new plugin” page could look like:

    I based the new page off of the updated “add new theme” page. Instead of going with filters you can add together to search results, I’ve opted to use some broad categories. Filtering doesn’t really work with plugins, especially filters outside of different categories — if you check “backup” in security and “galleries” in media, you’re not likely to get any results. Clicking on a category would bring up results weighted by # of downloads, popularity, reviews, etc. If we did end up adding some additional filters, they could be for things like version compatibility or language.

    We’ve already talked a bit about how a visual might not be the best way to scan for new plugins, and how we need to highlight plugin descriptions more. We also talked a bit about the possibility of having a better landing page if you don’t have any plugins installed on your site, that would show a mix of featured/popular plugins and categories to browse through.

    This doesn’t affect installed plugin management — we were thinking that would remain mostly the same, maybe with some minor updates.

    One thing we really want to nail down is the average plugin install workflow: “I want WordPress to do X. It doesn’t seem to do X. Maybe a plugin can help me! Here’s how I would look for that plugin. Here’s how I would evaluate and compare the plugins returned by how I looked for them. Here’s how I would install it/activate it.” What does your workflow look like?

    • Dovy Paukstys 9:29 pm on June 17, 2014 Permalink | Log in to Reply

      Also want to show in the summary view number of downloads at a glance. That gives more confidence than stars. Also, perhaps, last updated to the right of the title too (float). That way we can know how recent it is.

      Perhaps (lastly) a little corner graphic showing if it’s tested to work with your version of WordPress or not, etc.

      All small changes, but can really reduce the effort a user goes through to evaluate plugins.

      • Dovy Paukstys 11:13 pm on June 17, 2014 Permalink | Log in to Reply

        Also, I REALLY would love for every version of plugin be backed up once. That way if a user deletes a version they need, or the new version destroys their site layout, they can rollback. It would be a simple act of backing up the directory before you delete. And it could easily be a setting for the system.

        This would go a long way in user support and 99% of plugin issues I’d say.

        • Dovy Paukstys 11:14 pm on June 17, 2014 Permalink | Log in to Reply

          What I mean, before you update or override a plugin, WP does a backup of the existing plugin and you can rollback your installed plugins from the plugins screen.

        • Jon Brown 1:04 am on June 18, 2014 Permalink | Log in to Reply

          This has been requested and discussed elsewhere. Plugin rollbacks are far too complicated to do reliably. Many DB changes are one way and there is no infrastructure in the WordPress API to handle that scenario.

          The “correct” way to do this is to freeze the site, backup the entire site including DB, update the plugin, test it works, unfreeze the site or restore from backup.

          Or test it on staging/development and then deploy live… either way you need a DB backup to reliably roll back.

        • Ipstenu (Mika Epstein) 1:16 am on June 18, 2014 Permalink | Log in to Reply

          Given that you don’t ever EDIT plugins (right? ;) ) this would be better as a ‘revert to previous version’ if anything. Store the previous version from the readme in the DB, use that to install an old version. Sadly it depends on the plugin devs properly using SVN, which is pretty rare.

    • Casey Picker 9:30 pm on June 17, 2014 Permalink | Log in to Reply

      I’d be interested to know if there are there any guidelines or transparency around what plugins are “featured.”

    • Shane Pearlman 9:32 pm on June 17, 2014 Permalink | Log in to Reply

      I get popular and favorites (and would be curious to see how those algorithms get defined). What do you have in mind for featured?

      seconding Dovy’s comment – download count within a set window of time (like last 12 months). Full historical download count is super deceiving. Be even better if you could extract new downloads from updates, but I don’t think that is available from .org yet is it?

      • Jon Brown 1:07 am on June 18, 2014 Permalink | Log in to Reply

        Download count should be minimized in favor of “active install count”. Many have talked about this but it requires self-hosted sites reporting to .org what is being used… which is obviously a sensitive subject. I know wp.com stats collects this, but that seems like a small sample to base this off of.

        I suspect it’s still impractical, but a .org API for reporting on plugins that was opt-in would be killer.

        • Ipstenu (Mika Epstein) 1:17 am on June 18, 2014 Permalink | Log in to Reply

          They don’t have stats on active install, I don’t think. I know downloads/installs can be tracked via the API, but there’s no phone home allowed on activations, so how would you know?

          Simple to add? Sure/ Should we add that level of tracking? eeeeeeeeeeee I say no.

          • tomdryan 2:50 am on June 18, 2014 Permalink | Log in to Reply

            The plug in update function should be able to keep track how many unique plug in updates it serves. Also, don’t WP installs need to send the update server a list of installed plugins so that it can determine if there are updates available? This mechanism should be able to be modified to determined the number of active installs.

            This same mechanism could also be used to determine if a plug in is compatible with a particular version of WP, instead of the manual “is compatible with” function that no one seems to update.

            • Ipstenu (Mika Epstein) 3:34 am on June 18, 2014 Permalink

              Just because a plugin is updated doesn’t mean it’s ACTIVE though. Seriously, I look at hundreds of sites a day, people have inactive ones all over.

              don’t WP installs need to send the update server a list of installed plugins so that it can determine if there are updates available

              Kind of. The API query checks if the version installed is less than the one on wporg and pings for updates when needed. So .org only knows ‘No match’ and isn’t keeping a log of what version you have.

              And that’s still only going to tell you how many sites have the plugin installed. The yummy pie chart we used to have saying what version was on installed was horribly innacurate because of that :)

      • Syed Balkhi 11:57 am on June 18, 2014 Permalink | Log in to Reply

        Yup. I’d be interested to see if the featured list is going to to be heavily moderate and change regularly… the current one has barely changed since 2011


        Looking forward to the new algorithm, but if we’re keeping everything the same then I feel that perhaps Popular should be the main tab instead of featured.

    • Charleston Software Associates 9:36 pm on June 17, 2014 Permalink | Log in to Reply

      Please bake in plenty of hooks and filters to allow themes or plugins to easily extend the interface. It would be great if the plugin system API on the server side of things were more accessible via documented API calls. I wrote a “Plugin Search Filter” called “Plugin Intelligence” that does a sort-of brute force interception of the plugin directory communications in an effort to show “only plugins with 4+ stars” or similar filters. This would be a LOT easier to extend the plugin discovery process with the hooks/filters and API changes.

      That will allow site admins to install a plugin that provides things like “download count”, “number of ratings / rating details”, and “hover for last 3 reviews” features without bloating core.

    • daveshine (David Decker) 9:36 pm on June 17, 2014 Permalink | Log in to Reply

      Looks easier to use!
      Wouldn’t that require that every plugin has a header image on .org? — Or at least add a *nice* placeholder for those that have a header image yet…!

      Also, when you’re at it, please add some kind of bulk installing plugins or some kind of “plugin cart” where I could collect for example 5 plugins from different searches and then install those 5 at once. PLEASE!

      Thanks a lot for this stuff!

      • daveshine (David Decker) 9:37 pm on June 17, 2014 Permalink | Log in to Reply

        I meant a *nice* placeholder for those plugins that have NO header image yet… :)

      • Michael Arestad 10:36 pm on June 17, 2014 Permalink | Log in to Reply

        It wouldn’t be tricky to just show the short description if no header has been added.

        I think a visual search can work well for plugins if the image is available. Even if it isn’t, using the short description would still be nice. My concern is how the header will be “cropped.” It might be better to add a second header with this in mind. Maybe something like header-alt.jpg…

        I would also have the name of the plugin at the very top as it’s the single most important thing when scanning through plugins.

        • Mel Choyce 4:42 pm on June 18, 2014 Permalink | Log in to Reply

          It wouldn’t be tricky to just show the short description if no header has been added.

          For sure — I’m think we should add a description for every plugin, actually.

          My concern is how the header will be “cropped.” It might be better to add a second header with this in mind.

          My goal with this particular set of wireframes was to keep it proportional to what exists now (for example: http://wordpress.org/plugins/buddypress/). There’s been some talk of adding a 100x100px image to use in plugin search results, which I’m personally not a fan of.

      • Mel Choyce 4:40 pm on June 18, 2014 Permalink | Log in to Reply

        Wouldn’t that require that every plugin has a header image on .org? — Or at least add a *nice* placeholder for those that have a header image yet…!

        Nah, was thinking we’d contain the plugin title on a grey background. It would hopefully incentivize plugin authors to include an image, but would be okay without.

        Also, when you’re at it, please add some kind of bulk installing plugins or some kind of “plugin cart” where I could collect for example 5 plugins from different searches and then install those 5 at once. PLEASE!

        This is out of scope for this current project (at least my involvement in it), but maybe for a future iteration?

    • demoman2k10 10:33 pm on June 17, 2014 Permalink | Log in to Reply

      I personally would find it useful to be able to sort plugin’s my the most recently UPDATED as well. So that we can quickly sort out those that are not keeping their plugin’s up to date with the latest Cord Updates.

    • Todd Lahman 11:00 pm on June 17, 2014 Permalink | Log in to Reply

      When sorting through plugins the existing format is perfect. Plugins are not at all like themes, so the big tiles makes it much hard to sort through a large number of plugins, and read the details about each. If the plugin page was meant to sell plugins, I could see the value of big tiles. I do however, like the search box and browse categories, since that can aid in finding a plugin faster.

      What does need improvement are plugin uploads.

      First, the media uploader needs to be applied to plugin uploads, so a plugin drag and drop upload would be possible. A lot of people do not understand how to find a .zip file in their local directory structure, but they might have the file sitting somewhere they can drag and drop it.

      Second, already installed plugins should be overwritten when a zipped copy of it is uploaded, instead of giving an error message.

      The Plugins page should be about user experience, and making important tasks like installation, easier to perform.

      I don’t think the current Plugins page format needs to be changed, but the plugin uploads needs work.

      • Dovy Paukstys 11:11 pm on June 17, 2014 Permalink | Log in to Reply

        Or at least ask the user if they want to override them when they are found, like a confirmation. I think that would make everyone happy.

        But I think if you override, you should always store a backup so you can fall-back.

      • Mel Choyce 4:49 pm on June 18, 2014 Permalink | Log in to Reply

        First, the media uploader needs to be applied to plugin uploads, so a plugin drag and drop upload would be possible. A lot of people do not understand how to find a .zip file in their local directory structure, but they might have the file sitting somewhere they can drag and drop it.

        Totally agree. Now that we’ve started doing that with media uploading, it would be cool to extend drag & drop to theme and plugin uploading. Not sure that’ll happen for this cycle (though it would be cool if it did! Any developers want to step up?) but I think it’s a logical next step.

        Second, already installed plugins should be overwritten when a zipped copy of it is uploaded, instead of giving an error message.

        How often do you find yourself doing this task? (Just curious, because I’ve never actually encountered this)

        • Ipstenu (Mika Epstein) 7:52 pm on June 18, 2014 Permalink | Log in to Reply

          When I’m de-hacking a site, fairly regularly.

          (I think wp-cli has a –force command for it)

        • Todd Lahman 3:50 am on June 19, 2014 Permalink | Log in to Reply

          When I need to replace a plugin that is not available as an automatic update, either from my site or from wordpress.org, and the plugin cannot be deactivated on the site because it serves a critical function, I have to put the site into maintenance mode, then delete, and replace the plugin using FTP or SSH. I’d use the plugin page to delete the plugin, but I may not want to delete the data when uninstalling. I’d like to see an upload routine similar to the automatic updates, with one exception. Allow the choice to reinstall if the plugin already exists, so the previous installation is removed, and the new .zip is installed without losing data.

          There have been automatic installations over the years that result in an empty plugin folder. Uploading a zip with the same plugin folder name results in an error. In this situation, that folder should be overwritten.

          The default behavior should be for the .zip upload to overwrite the existing folder or plugin installation. A dialog window could warn the uploader that the plugin already exists, but that same dialog window should not appear if the folder exists but is empty.

          When the user runs into a new situation, like one of the above, and WordPress just performs the task in a smart way, because we already built a solution for that into the core, the user walks away feeling like a genius, and is very satisfied with their experience. That’s good software.

          I deal with this regularly, sometimes several time in a day.

    • samuelsidler 12:58 am on June 18, 2014 Permalink | Log in to Reply

      I like these mockups.

      My only comment would be that I think it’s fine for you to not use plugin banners and instead create a new size of image for plugins to use. We would, of course, want to mirror that icon in the search results on WordPress.org as well. Banners take up a lot of space and it’d be nice to get more plugins per page on search results.

      • Jon Brown 1:08 am on June 18, 2014 Permalink | Log in to Reply

        Smaller banner/icons for sure. The banner is pretty, but it’s really unimportant information. I’d far rather see description excerpt and reviews.

      • Helen Hou-Sandi 4:10 am on June 18, 2014 Permalink | Log in to Reply

        I’m not super convinced that icon creation by plugin developers is going to go well; I for one would probably create something terrible. I am waffling between whether or not banners will actually be useful in a list context, though. The visual cue is very helpful, but it does encroach on space for other information that is just as or more helpful than the banner.

        • Ipstenu (Mika Epstein) 4:44 am on June 18, 2014 Permalink | Log in to Reply

          We can always try it with banners and kill them if they look ugly. But I know I won’t be able to design a meaningful small button either.

          • Mel Choyce 4:53 pm on June 18, 2014 Permalink | Log in to Reply

            It’s much easier to add a feature than to take it away, so I have a sinking feeling that if small graphics went in, we’d be stuck with them f-o-r-e-v-e-r

        • Mel Choyce 4:52 pm on June 18, 2014 Permalink | Log in to Reply

          I’m not super convinced that icon creation by plugin developers is going to go well

          I agree — at a small size like 100×100, which was suggested previously, plugin authors would face some serious design constraints. I’m having nightmarish visions of poorly set type on top of gradients.

          I’m also kind of waffling on banners, honestly. It might be easier to judge when mocked up, rather than just wireframed.

    • Helen Hou-Sandi 4:05 am on June 18, 2014 Permalink | Log in to Reply

      I typically find myself on one of two paths in the install plugin flow:

      1. I already know what I want, so I try to search for it in a way that will successfully get me the result I want up toward the top of the results. Sometimes I don’t actually remember the name of the plugin and it takes getting into the details box to figure out if it’s the one I’m looking for. Visual cues seem like they could be helpful here with quickly identifying a plugin you’re specifically looking for.

      2. I have something I want to accomplish that core doesn’t do, and I’m hoping a plugin will do it. Lately I have found myself searching on .org itself because more metrics are available there, and it is way easier to open a bunch of browser tabs with different plugins to compare details than the tedium of the details box in the WP admin. After finding the plugin I want on .org, then I essentially follow what I would do in the previous described path of looking for an existing plugin. In this case, a consistent visual cue (banner, icon, whatever) would be even more helpful in bridging between .org and the WP admin.

      Both of these paths center around search. I do not find myself browsing nor using favorites. I can definitely see value in both of those, the former for newer users and the latter for experienced ones. I think grouped and more curated categories would make the browsing experience much more useful. I also think that the “add new” landing page could better guide into various paths visually and with words – it’s pretty terrible right now. I’d also rather just put the uploader right there on that screen and stop separating it off into its own world. It does not take up a lot of room.

      For other filters, I think it would be useful to have simple checkboxes for showing plugins that are available in your language (possibly on by default, depending on i18n efforts) or labeled as working with your version of WP (also possibly on by default). There may be more that we’re not thinking of at the moment.

      In evaluating plugins, I look at changelogs / updated dates, contributors, and screenshots in particular. I also check out reviews, not just the stars and content, but also the relative volume, knowing that overall review volume is low and that drive-by complaints are pretty typical in any review system. Reviews and contributors are not currently available in the admin, and changelogs are not standardized in any way (I think they should be, FWIW), so it can be a crapshoot. For comparison, I do almost exactly the same thing when perusing the iOS App Store, and heavily rely on reviews on Amazon.

      As mentioned in IRC and on that original post, I think it would be really interesting to try a browse-details mode for a results list the way themes does. Having data at a glance is important too, but if I’m doing more than quickly searching for and installing a specific plugin I already have in mind, I want to do more detailed comparison between them and being able to quickly navigate between detail views seems like it would be helpful.

      Other flow thoughts, not all necessarily for right now:

      • When searching installed plugins and nothing is found, prompt the user to run the search on the plugins repo.
      • “Add New” language feels super wrong here, even though it’s consistent with other things in the admin.
      • Install in place (AJAX).
      • Activate a plugin that’s already installed from the search results. Right now it just tells you it’s installed. If we did install-in-place, then you could also activate-in-place. :)
      • Todd Lahman 8:32 am on June 18, 2014 Permalink | Log in to Reply

        Search by … popular, featured, newest, relevance.

        Currently there are different screens for categories like popular. It would be useful if categories like popular could be searched for key words like “SEO” for example. This way you would be searching for what you’re already looking for to narrow the search results further.

        More work should be done on the search algorithm to return more relevant search results. A search ranking system should be setup much like google. The ranking should include ratings, links to the wordpress.org plugin pages, if the plugin title contains the searched for words, etc., to create a fair and relevant search result, even if search for popular the ranking algorithm should be applied. The ranking system should apply different weight to different items. For example, ratings may not always reflect a plugin’s relevance, so that weight should be 0.1, but links to the plugin page, depending on what type of site is linking, would hold a higher weight to help determine the relevance of the plugin in the search results.

        • Helen Hou-Sandi 2:46 pm on June 18, 2014 Permalink | Log in to Reply

          Work is being done on search results on the .org side – see the previous post from @tellyworth. As far as sorting of search results goes, typically I like having lots of controls, but I think I’d rather start with a smart default (that is, better search results). As it is, newest is kind of meaningless.

    • Tareq Hasan 7:46 am on June 18, 2014 Permalink | Log in to Reply

      I like the current listing the way it is. Displaying themes like this is okay, but plugins? NO.

    • Nashwan Doaqan 7:48 am on June 18, 2014 Permalink | Log in to Reply

      I really liked the new UI .. it’s more modern and interactive! but..

      1- The plugins cover image is not very helpful!, I think it’s more important to show more information like Description, Update Data, Downloads Count..etc

      Maybe it’s a good idea for the “Featured Plugins” but when I perform a search query I prefer to see many results as fast as possible.

      2- I can’t see the “Newest” plugins tab?!

    • Stagger Lee 9:14 am on June 18, 2014 Permalink | Log in to Reply

      I have few suggestions.

      • Make Favorites in plugin page searchable. (saves time if you have many favorites)
      • Give us option to bulk disable all marked plugins, but also one option to enable them back (same marked plugins). Some sort of option that remembers last change. This mainly for developing. How many times people have some conflict and dont have easy option to disable all (or marked) plugins to test on clean install. Disable/enable one by one doesnt work if that situation is on live server (difficult on localhost either).

      So you see, if we need to make non functional live website to check if it is some plugin conflict, give us option to make it less painfull and with less risk any visitor will see it for that so short time (few seconds).

    • Junko Nukaga 9:57 am on June 18, 2014 Permalink | Log in to Reply

      I like the new UI.
      I want to display date updated. I think it is important.

    • michalzuber 1:47 pm on June 18, 2014 Permalink | Log in to Reply

      Could be switchable, for default would be this layout with images, but could switch (http://i.imgur.com/b0JwUtL.png) back to the old one? Bulk actions could be a missing feature with this new layout.

      • Helen Hou-Sandi 2:39 pm on June 18, 2014 Permalink | Log in to Reply

        As noted in the post, this would be for installing plugins, not management. The management screen would largely stay the same. Bulk actions are not available for installing plugins.

  • Jen Mylo 11:32 pm on June 12, 2014 Permalink | Log in to leave a Comment
    Tags: , , wcsf2014   

    WCSF 2014: Are You Coming? 

    Heads up, core team! We’re getting ready to publish details about the plans for WordCamp this October (which includes a mini team meetup), so if you’re thinking of attending, please read the post at http://make.wordpress.org/updates/2014/06/12/wordcamp-san-francisco-travel-contributor-days/ and take the short survey linked at the end of it so I’ll know how many team members to plan for (don’t worry, this isn’t a commitment or anything, I just need to get some rough numbers for budgeting purposes). Thanks!

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


  • 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

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