Ready to get started?Download WordPress

Make WordPress Core

Updates from November, 2013 Toggle Comment Threads | Keyboard Shortcuts

  • Mike Schroder 2:46 pm on February 4, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Last week in WordPress core 

    Welcome back to Last Week In WordPress Core, for the week of January 27-February 2. Big list this time! First, a summary of the major changes; then a roundup from the various 3.9 teams:

    Enhancements and hooks

    Database changes

    • Initial patch to reconnect when the MySQL server “goes away” has landed, with a request for feedback on how to make the solution more fool-proof on #5932.
    • Improved Compatibility with MySQL 5.6, which has stricter default SQL modes.
      Disables NO_ZERO_DATE, ONLY_FULL_GROUP_BY, STRICT_TRANS_TABLES, STRICT_ALL_TABLES, TRADITIONAL. Introduces filterable wpdb::set_sql_mode(), with incompatible_sql_modes filter for plugins. #26847
    • We now throw a notice when wpdb::prepare() is called without a placeholder. #25604
    • In wpdb::db_connect(), allow the loading of a translatable custom database error template. #25703

    Miscellaneous, including library updates

    3.9 status reports

    Here are roughly where each of the 3.9 teams/tasks stood as of last week’s meeting:

    Media/editor related:

    • Media Modal: “Initial version of the single image editor landed, which includes the ability to replace the image and update the main set of attributes (e.g. caption, alt, alignment, link).” (@gcorne) (#21811)
    • Image Editor: “have a proof-of-concept plugin ready awaiting input on how to modularize the Editor and make it extensible and flexible. Working on a patch that introduces a few well-placed hooks.” (@tomauger) (#21811)
    • Rendering in the editor: “Going to dig into rendering galleries in the visual editor using a wpview and building on some of the work that i did in https://github.com/gcorne/gallery-editor.” (@gcorne) (#26628, #26959)
    • TinyMCE: All looks good on this front, #24067. “We’ve also started looking at restyling TinyMCE modals to match the admin, #26952″(@azaozz, @melchoyce)
    • Audio/Video: There’s an update post by @wonderboymusic.

    Other UI work:

    • Widget Customizer: “We’re running more users tests; Working on keyboard accessibility features; Trying to figure out support for wide widgets; Asked for some code review/notes; And digesting feedback from our recent p2 post.” (@shaunandrews)
    • Settings screens: “We had a meeting yesterday to divvy up the redux. I’m looking at reordering of information across screens, @melchoyce is experimenting with UI approaches, and @Ipstenu is looking at cleaning up the multisite ‘edit site/settings’ view. We hope to be posting sketches/wireframes [this] week.” Also, they’re again looking at lifting post by email from core. (@jenmylo)
    • Accessibility: we are testing 3.8.1 admin screens for keyboard accessibility. (@joedolson)
    • Autocomplete: After the new site email address autocomplete landed (#25348), now looking into other areas — users (#19867) and pages (#9864). (@helen)
    • CSS: Work continues on the colors.css merge to prep for splitting up wp-admin.css. (@helen, #18380, #26669).

    Fun with internals:

    • Multisite: “Our tickets are focused. [As in, reorganized into the 'multisite' focus.] I’ve been digging through ms-load.php, ms-settings.php, etc in prep for some fun domain routing work. Would like to compare thoughts on approach soon and get moving on that.” (@jeremyfelt)
    • New Grunt-based Patching Tool: “I’ve been using it locally and haven’t run into any issues. Will be opening a ticket on Trac with a patch and instructions in the next few days.” (@jorbin)
    • Taxonomy: Hope to start with the first few tickets on the roadmap this week. (@nacin)

    Housekeeping items last week included a call for GSoC participation from @jenmylo, and trac component reorganization proposal from @nacin. The reorganization was approved during the chat on Wednesday and is well under way. Additionally, there’s now a new Trac reports overlay and Trac’s navigation got overhauled.

    For the complete changelog commits to trunk, check out the log on Trac.

    More than three dozen contributors had a hand in last week’s efforts. Want to help out this week? Write or test a patch for 3.9.

    Thanks for contributions this week from atimmer, aubreypwd, azaozz, c3mdigital, cmmarslender, coffee2code, Denis-de-Bernardy, DrewAPicture, empireoflight, gcornehelen, ippetkov, jeremyfelt, joehoyle, johnjamesjacoby, JoshuaAbenazer, kovshenin, kpdesign, kraftbj, mark8barnes, markjaquith, MattyRob, mdbitz, melchoyce, nacin, neoxx, nofearinc, ocean90, olivM, oso96_2000, ounziw, pento, romaimperator, sbruner, SergeyBiryukov, soulseekah, TobiasBg, toszcze, wonderboymusic, and yoavf!

  • Mike Schroder 2:02 pm on January 27, 2014 Permalink | Log in to leave a Comment
    Tags: , ,   

    Last week in WordPress core 

    And now, for the first in a series of synopsis posts outlining what’s going on in WordPress core. The idea behind these posts is to highlight technical changes in WordPress 3.9 as it progresses, with the hope of keeping the community informed. If you have suggestions for content you’d like to see, please comment below!

    Last week, we kicked off 3.9, and released 3.8.1 (yay!). There were a lot of changes that occurred in 3.8.1, and @nacin provided an overview. These were all added to trunk and will be in 3.9.

    Here are a few highlights from last week’s commits:

    @nacin also added a small enhancement to Trac to point users in the right direction when they end up on a ticket that was fixed in a released version of WordPress:
    This ticket was closed on a completed milestone. If you have a bug or enhancement to report, please open a new ticket.

    Other housekeeping items included new Trac “focuses”.

    For the complete list of 51 commits to trunk, here’s the changelog. Thirty contributors had a hand in last week’s efforts. Want to jump in this week? Write or test a patch for 3.9.

    Thanks for efforts from yurivictor, cojennin, iammattthomas, mdbitz, kraftbj, dd32, c3mdigital, jorbin, adamsilverstein, Otto42, JayCC, johnbillion, nacin, xknown, mattheu, nbachiyski, undergroundnetwork, morganestes, matveb, SergeyBiryukov, azaozz, joedolson, alex-ye, ciantic, MikeHansenMe, batmoo, Corphi, Marventus, ocean90, and DrewAPicture.

  • Andrew Nacin 12:39 am on January 24, 2014 Permalink
    Tags: ,   

    3.8.1 auto update rollout 

    I’ll be using this thread to track the rollout of automatic background updates for 3.8.1, released earlier.

    The WP.org API is now sending update instructions to about 1 in every 128 sites. This is for all locales (not just English). 3.8.1 was released about four hours ago and I’d like to have the rollout complete in the next six hours or so. Sites check WP.org every 12 hours, but this timetable means all sites should be updating within one day of the initial release.

    So, why a slow rollout? Well, we’re monitoring a number of things that would cause us to put a pause on auto-updates, such as whether there were any critical issues in 3.8.1, whether update failure rates are higher than usual, how WP.org is handling the load, etc. The rollout is happening much faster this time than last time (3.7.1), and yes, the goal will be to eventually push out auto-update instructions immediately.

    So far, we’ve seen a 100% success rate for about a thousand auto-updates to 3.8.1, and north of 99% for one-click updates. (A reminder: a failure only means the site couldn’t update, not that it broke.) I’ll comment to this thread with more numbers as the rollout continues.

    • Andrew Nacin 12:45 am on January 24, 2014 Permalink

      In case you’re curious as to how this 1-in-128 is calculated, we take the first three characters of the md5 of the site’s URL and convert it to base 10. md5 is hexadecimal (base 16), so the three characters mean 4096 possibilities. It’s now serving sites where this base 10 number is 0 to 31.

      Just randomly serving an instruction every 128 requests wouldn’t work. We do it this way to ensure a site receives a consistent response with repeated API calls.

    • Jeff Rose 12:46 am on January 24, 2014 Permalink

      I’ll cop to being one of those one-button failures. My Digital Ocean test install had bad permissions. Not WordPress’s fault.

      • Andrew Nacin 12:50 am on January 24, 2014 Permalink

        What’s cool is we are actually able to break it down by error code. Bad permissions is what we’d consider a non-critical failure. The only time a “critical” failure occurs is if WordPress started to copy files over, but couldn’t verify we copied them all successfully. It’s still probable everything is fine with the site, and quite possible the update completed anyway.

        If an error occurs at any point before we start to copy files (such as a permissions error, which is a pre-flight check now), WordPress simply declines to continue. The vast majority of the less than 1% of errors we’re seeing from one-click updates are these kinds of errors.

    • Ipstenu (Mika Epstein) 12:47 am on January 24, 2014 Permalink

      Mine had a bad timing for an auto-update (yes, auto update WHILE I’m messing with files, that’s smart ;) ). Stopped messing with files. It re-ran later and worked.

    • Andrew Nacin 12:59 am on January 24, 2014 Permalink

      Bumped to one out of every 64 sites.

    • Andrew Nacin 2:36 am on January 24, 2014 Permalink

      Now at one in every two sites. Will be holding steady here for possibly a few hours.

    • Andrew Nacin 4:11 am on January 24, 2014 Permalink

      Things are looking great, so all sites are now receiving auto-update instructions. The rollout is complete. We’ve seen about 100,000 successful updates in the last few hours.

    • Andrew Nacin 8:11 am on January 24, 2014 Permalink

      We briefly dialed it back to about 75% of sites after seeing hundreds of updates a second from installs set to UTC. We’ll bump it back up soon.

    • marvila 10:24 am on January 24, 2014 Permalink

      One quick doubt. I have a monitor on my system that alerts me whenever a file is changed on wordpress and, of course, it started to show me lots of file changes.

      Is there a place to see whether the auto-update is still happening? Just to be sure the alerts are really for the auto-update (although everything seems to indicate so).


      • Andrew Nacin 10:10 pm on January 24, 2014 Permalink

        Once you get a success email, the update is complete.

    • Knut Sparhell 11:39 am on January 24, 2014 Permalink

      All but one of the 35 sites I manage are localized (nb_NO), and they all have the “Advanced Automatic Updates” plugin with at least minor updates turned ON (most have ALL options ON). Some sites now has been background updated to 3.8.1 (no available updates indicated), but some has been updated to 3.8.1, but still waits for 3.8.1-nb_NO (says such update is available in the admin).

      May I expect all sites to update to 3.8.1-nb_NO, or do I have to “update” from 3.8.1 to 3.8.1-nb_NO by clicking the Update button on each site? For 3.7 to 3.7.1 no localized sites was fully updated and I had to do the last part, to nb_NO, myself.

      BTW: Tomorrow is WordCamp Norway!

      • Andrew Nacin 10:10 pm on January 24, 2014 Permalink

        If the site is running the 3.8 English package, it’ll update to 3.8.1 in English, even if the locale is set to nb_NO. It requires A) for an nb_NO package to exist, and B) for your version.php file to have $wp_locale_package = ‘nb_NO’, for it to update to the Norwegian package. I hope to make this better in the future.

        Have fun at WordCamp Norway. :-)

    • driveroll 12:53 pm on January 24, 2014 Permalink

      I’ve noticed these auto-updates on several of my sites, this is the first time it happens like that, automatically. I usually would prefer to update wordpress manually to take care of any possible conflicts with themes or plugins that aren’t ready for the update… I actually haven’t checked if any of these actually occurred on some of those sites. Is there a way for the auto-updates to notice if the site breaks for incompatibility reasons? Is there a way to choose not to run the auto-updates?


    • Gary Jones 2:50 pm on January 24, 2014 Permalink

      I had an interesting issue, which I can only put down to the 3.8.1 auto-update, as I’ve not edited code or content on my site for a few days.

      Others said that my site had lost its style. When I cleared my cache, yes, the style sheet link reference was broken:


      That’s the child theme name missing, and the version has reverted to the parent theme (Genesis Framework).

      I cleared the Varnish Static, Varnish Dynamic and Memcache caches in SiteGround User Area, and it’s all back up fine.

      My other sites on the same SG account, with different WP installs, all running child themes of Genesis 2.0.2, all look to have gone through perfectly fine. The affected site *only* has Genesis and the child theme installed (no Twenty* themes), but then that’s the same for the other installs as well.

      I can’t explain it.

      • Gary Jones 2:53 pm on January 24, 2014 Permalink

        The full link was:

        The ID there indicates that Genesis thought the child theme was still active (as it should have been), but somehow, the name and version number couldn’t be retrieved from it (file read issue?)

      • Ipstenu (Mika Epstein) 5:36 pm on January 24, 2014 Permalink

        Is the child theme still installed on the site?

        The upgrade should NOT delete any theme files. Actually … it can’t delete theme files, unless you named the child theme ‘twentyten’ or something.

        • Gary Jones 8:06 pm on January 24, 2014 Permalink

          The child theme was still installed, and apparently not touched (correct). A clearing of the host caches brought everything back up correctly.

      • Samuel Wood (Otto) 5:46 pm on January 24, 2014 Permalink

        Could be an issue with the files for the theme being temporarily unavailable. I’d check the filesystem on that particular server (or ask the host to do so). Also make sure you have an up-to-date backup of the site.

        There is a function called “validate_current_theme” that runs on the wp-admin/themes.php page. It checks that the relevant theme files exist. If they don’t, then it tries to switch the theme back to the default theme, which is currently twentyfourteen.

        In that switch process, if the default theme isn’t there either, then a quick read of the code seems to me that it could set the theme to a blank value, which would give the results you’re seeing.

        We’ve seen this in the past on some hosting setups where the filesystem was having intermittent failures. Users would say that it “randomly” switched back to the default theme. The theme validation check isn’t nearly as aggressive as it used to be, I think, but this is one possible way that it could happen.

        • Gary Jones 8:26 pm on January 24, 2014 Permalink

          That consequential explanation sounds viable.

          Lots of the files (in wp-includes, theme files, etc.) of the affected site are now 0755. As most files weren’t touched, that is likely from the initial install via Softaculous in cPanel, but it presumably rules out any file permissions issue.

          I’ve just checked the version.php of the other installs (the affected site was the root site, while others are add-on domains), and they still say 3.8, so they actually haven’t been touched.

          What’s more fun, is that version.php of the affected site says 3.8.1, yet I’m still getting an update notification in the WP admin.

          I’ve got one 3.8.0 install where the theme files are 0644 and folders are 0755, with twentyfourteen also present, another the same but without twentyfourteen present, and a third where the theme files are 0755. I’ll keep track and see if any break.

          I’ve commented out define( ‘WP_AUTO_UPDATE_CORE’, false ); which was added to wp-config.php by SiteGround Autoupdate, so that WordPress handles things itself.

          • Andrew Nacin 10:08 pm on January 24, 2014 Permalink

            validate_current_theme() won’t do anything unless you visit wp-admin/themes.php. This appears to be a hosting problem.

    • Gary Jones 2:54 pm on January 24, 2014 Permalink

      link rel=’stylesheet’ id=’child-theme-css’ href=’/wp-content/themes//style.css?ver=2.0.2′ type=’text/css’ media=’all’

    • KirkM 3:59 pm on January 24, 2014 Permalink

      I’m running 2 WordPress powered sites, the first being a rather ancient (going on 8 years on original install) but still viable personal blog and a newer (4 years) test site. The old personal blog updated automatically updated to 3.8.1 from 3.8 without a problem but I had to manually update the test site. The test site via the admin Update page. It did show that the 3.8.1 update was available though. Perhaps the auto-updates hadn’t gotten around to the test site yet or maybe the security plugin is keeping the auto-update from happening (see list of plugins for the test site). I have no way to be sure. No big deal though.

      Just for information purposes, the old personal blog site has the following plugins activated:

      All In One SEO Pack
      Artiss Transient Cleaner
      Better WP Security
      Clean Options
      Google Analytics for WordPress
      Lightbox Plus ColorBox
      P3 (Plugin Performance Profiler)
      Spam Free WordPress
      Subscribe to Comments Reloaded
      WP Revisions Control
      WP Robots Txt
      WP Super Cache

      And I’m running Weaver II Pro as a theme.

      The test site has the following plugins activated:

      Acunetix WP Security
      Clean Options
      Lightbox Plus ColorBox

      This site also runs the Weaver II Pro theme.

      So, no problems here really. No errors seen in any of the error logs for personal blog in regards to the auto-update. Considering how old the WordPress install is and what I’ve put the site through over the years, I’m glad to see the auto-update work so well. I do keep the site in good repair but still…great job to all!

    • Debbie Doglady 4:05 pm on January 24, 2014 Permalink

      I couldn’t do the one-click update. Got at “500 Internal Server Error”.

    • Xavier Borderie 4:41 pm on January 24, 2014 Permalink

      Automatic background updates is still not quite well-known among regular users: we (WPFR) received one e-mail from the owner of the (unknown to us) owner of a permanent makeup website running WP, about having received “quite a strange message”, with a copy of the “Congratulations on your auto update!” e-mail, and a question: “How come WordPress feels the right to update my site without my knowledge?”

      I told him everything about the feature, plugins to disable it and links to the Codex, and he answered with:

      Well let me thank you for showing to us that you can remotely control our site without our permission and without having been personally given access to the administration.

      Free software does not rhyme with abuse of rights.

      One final e-mail from me reassuring that no one ever touched his site, that it was all automatic and everything. No answer since then.

      But still. If one guy takes the time to complain about it, that means heaps of others are confused about it. It might be warranted to put more informational text in the e-mail sent on successful and failed updates.

      • Xavier Borderie 5:05 pm on January 24, 2014 Permalink

        Aside 1: his website is not even live yet, it’s apparently a test version for a forthcoming new version of their previously full-HTML site. I can understand the fury.

        Aside 2: a commenter on the FR announcement says he hopes his 3.6-using site (kept this way because it uses a 3.7+-incompatible plugin) will not be “brutally” updated to 3.8.1, and fears about update failures when the webmaster is unavailable for days (holidays).

        It’s all about education and good copy.

      • Ipstenu (Mika Epstein) 5:43 pm on January 24, 2014 Permalink

        Sadly this is an application of Zeno’s dichotomy paradox in action. We cannot ever alert 100% of the world.

        I would suggest you do a blast email (or a post on your site) explaining this to your customers. We did that at DreamHost and had a crazy small number of people who even blinked when they were upgraded. We told them it was coming beforehand, pointed out they COULD opt out, but we suggested they would not, and provided directions. The majority of people were fine with it (though I admit we already do upgrades for anyone who used our one-click upgrader), and the few who were not were glad to have the information on how to opt out.

        • Xavier Borderie 7:53 pm on January 24, 2014 Permalink

          Ah, but they’re not customers of ours :) I’m the fr_FR translator, and WPFR is the non-profit entity for that hosts the FR support forum and organizes the Paris WordCamp, so there’s no way we can e-mail everyone. That being said, we could tweet and write a blogpost about this beforehand, true, true… Thanks for the tip!

    • rossagrant 4:44 pm on January 24, 2014 Permalink

      Hey Andrew!

      Just a quick question.

      I woke up to an email this morning from my staging site saying that it had been updated to 3.8.1 automatically.

      My production site which is on the same server and is basically a duplicate of staging didn’t auto-update.

      I was already logged into my dashboard, hit refresh and then saw the manual update flyout. I hit it and it updated no problem.

      Another WP install on a sub-directory of my production site DID update automatically, so 2 out of the 3 sites on the same server basically.

      Is there anything I should look out for as to why the main production site didn’t auto-update?

      What are the triggers for the update? Did it matter that I was logged in as admin at the time?

      Would love to understand what triggers this.

      Thanks :)

    • ElleJG 7:09 pm on January 24, 2014 Permalink

      Holy komoly. Call me a control freak but I don’t like arbitrary updates. An auto update from 3.8 to 3.8.1 came as a complete surprise!

      Can someone confirm that this can only happen within versions? As in I won’t someday find that all of my sites have jumped from 3.8 to 3.9 without me deciding it was safe to do so? And should I decide that I would like to update all by my little self when I know it won’t break anything – how do I do that?

      Until every WP plugin developer is forced to update along with WP core – which can’t and won’t happen – I personally think auto updates are a bad idea. But hey, that’s just my opinion. :)

      Thanks guys. Would appreciate the info. I’m already trying to figure out a site problem today, and having this happen at the same time did not make me happy.

    • stevenhong 8:28 pm on January 24, 2014 Permalink

      Ok. My website broke based on this automatic update. I was on my site before lunch, and came back and when I hit my site again, it was in maintenance mode. Looked at the timestamp of the file and it was 8 minutes ago. Deleted .maintenance, and the site is broken.

      Fatal error: Class ‘WP_Query’ not found in /home/steveho/public_html/wp-settings.php on line 251

      is all I get, both on the front end, and when I try to log in via wp-admin.

      I thought it might be a conflict in plugins, so I went and removed all active plugins (via phpmyadmin) and it still doesn’t work.

      What did work was for me to copy all the 3.8.1 files onto my server, and follow the install instructions. Entire site is back and running with all the data intact.

    • keeperbay 9:44 pm on January 24, 2014 Permalink

      UPDATE. Have installed the “Disable Auto Update Patch” on 45 WordPress blogs today.
      Have 120 more to go.
      More orders rolling in.
      THANK YOU WP CORE!!! Once again you have kept me gainfully employed. I’ve never received so many orders in one day.

    • Andrew Nacin 10:03 pm on January 24, 2014 Permalink

      IF YOU NEED ASSISTANCE, USE THE SUPPORT FORUMS. I’m closing comments on this thread.


    • keeperbay 10:20 pm on January 24, 2014 Permalink

      Here are the problems:
      Problem #1. WP Core thinks that posting a link to Codex will help, but Most Bloggers Know Nothing About Code!

      Problem #2. Auto Updating assumes that all plugins are going to automatically work with the new version of WP – When has that EVER Happened?

      Problem #3. When Problem #2 occurs, those bloggers who fall into the category of Problem #1 are stuck paying to have their sites restored, fixed or rebuilt.

      • Andrew Nacin 10:51 pm on January 24, 2014 Permalink

        1. Bloggers shouldn’t need to rush to update their site to keep it secure and stable. If WordPress can take care of that, we should take care of that. They shouldn’t need to even go to the Codex for this. It “Just works.”

        2. We don’t break plugins in minor versions. Auto updates are for minor versions. We take a lot of precautionary steps. All we’re doing is fixing a few bugs and any security issues.

        3. I’ve yet to see a site break due to an auto update.

    • rossagrant 10:55 pm on January 24, 2014 Permalink

      @nacin used the update tester on production and all is well – thanks! :)

  • Andrew Nacin 9:03 pm on January 22, 2014 Permalink | Log in to leave a Comment

    Possible tasks for WP 3.9 

    During last week’s dev chat, we decided on a schedule. We also chatted about a major focus in 3.9 on improving workflow for new and current contributors alike. If there are further suggestions on changes we can make to workflow to make core easier to contribute to, let us know.

    Below is a rundown of what features/enhancements/ideas were discussed as possible for 3.9, including potential volunteers to take point on different tasks. This is all tentative. Thanks @DH-Shredder for compiling this.

    In today’s chat, let’s continue to build this out. If you have something you’d love to work on during the release, join us!


    There are two widget-related feature plugins to review: Better Widgets and Widget Customizer. Decisions on what we’re merging should come by next week, per the schedule. Expect a post from @shaunandrews soon explaining both and requesting help reviewing them.

    TinyMCE improvements (@azaozz, @gcorne, @lgladdy)

    • TinyMCE 4 inclusion and troubleshooting
    • Improving editing/positioning images after insertion into the editor

    Editor-related media improvements

    • Bringing the image editor into the media manager (@melchoyce, @johnbillion)
    • Allow a user to drop an item for upload on the post screen. This would then open the media modal (as an initial first step).

    A better themes experience, part 2 (@matveb)

    • Taking our new experience to the theme installer (this may be started as a plugin)
    • Supporting multiple screenshots, left out of 3.8
    • Backbone routing and subview backend improvements

    Improved audio/video support (@wonderboymusic) (see this post)

    • Playlists, subtitles, metadata generation
    • Media manager documentation

    JavaScript and CSS


    • Aaron Jorbin 9:32 pm on January 22, 2014 Permalink | Log in to Reply

      RE: Grunt tool for patches

      It now is working for:

      patches you have in your local repository
      when you enter a ticket number
      when you enter a ticket url
      when you enter an attachment url
      when you enter a raw attachment url

      My next step is to add some more tests and write up documentation. Once that is in place, I would love to have some extra help testing. I most likely have some error messaging to improve and the like. I’ll post on make/core within the next week with info on how to help test/get involved.

      development is happening at https://github.com/aaronjorbin/grunt-patch-wordpress

    • Andrew Nacin 3:04 am on January 23, 2014 Permalink | Log in to Reply

      Some more things to add, from the meeting today:

      • @drewapicture is doing a mockup of a potential new tools screen he’s been talking about.
      • @gcorne is looking into syncing caret positions between the visual and text editors.
      • @obenland and @helen discussed including markup changes as part of the admin settings audit proposed by @jenmylo and @melchoyce. @Ipstenu and @ryelle are additionally interested in the UX side of things.
      • @helen proposed looking into better insert from URL handling in the media modal. This also ties into oEmbed insertion, and oEmbed previews / MCE views, which @gcorne has mentioned before.
      • @adamsilverstein brought up a post meta revisioning API. It happened in 3.6 but it was baked into post format UI stuff, and got pulled. It should be attempted again.
      • @TomAuger will be helping with image editing UIs, and posted work he’s been doing on #21811.
      • Manuel Schmalstieg 3:12 pm on January 23, 2014 Permalink | Log in to Reply

        > @gcorne is looking into syncing caret positions between the visual and text editors.
        Wow, that’s a wonderful idea! Improved preservation of whitespace when switching between visual/text modes would also be a major editing help.

      • Jen Mylo 5:46 pm on January 27, 2014 Permalink | Log in to Reply

        As I hear it, @ryelle is actually interested in the dev & API side of things.

    • RicaNeaga 10:25 am on January 23, 2014 Permalink | Log in to Reply

      So no plans in 3.9 for mysqli via #21663? Or hopefully full and official MariaDB support? Please reconsider, many are not happy (right now) to see only MySQL mentioned in the wordpress requirements page.

    • StyledThemes 12:54 am on January 24, 2014 Permalink | Log in to Reply

      Speaking of widgets, and something I am really amazed this is not part of the core…the ability to disable widget titles with each widget. There are many times where the title is needed for reference in the admin, but needs to be removed from the front-end. That’s one thing…the other would be a method to publish widgets to select pages/posts without having to install a plugin for this. Cheers!

    • Pippin Williamson 4:05 pm on January 24, 2014 Permalink | Log in to Reply

      I’d love to see the password generator enhancements get considered again, https://core.trac.wordpress.org/ticket/24633 – It’s mostly waiting on additional feedback. It was originally slated for 3.8 but then got pulled due to lack of feedback.

    • RENAUT 10:56 am on February 4, 2014 Permalink | Log in to Reply

      for TinyMCE improvements ability to deactivate fullpage icons and shortkeys for plugins using tinymce (in the simplest way) thank you

  • Andrew Nacin 6:49 pm on January 15, 2014 Permalink | Log in to leave a Comment

    Git mirrors for WordPress 

    I’m pleased to share we now have an official Git mirror for the WordPress core development SVN repository.

    git clone git://develop.git.wordpress.org/

    Read-only mirrors are also set up for a few other WordPress.org repositories, including BuddyPress, bbPress, and the old core.svn “build” repository:

    git clone git://buddypress.git.wordpress.org/
    git clone git://bbpress.git.wordpress.org/
    git clone git://core.git.wordpress.org/
    git clone git://glotpress.git.wordpress.org/

    Make sure you use the git protocol (not http) and include the trailing slash.

    Can you use develop.git.wordpress.org for core development? Yes! For all practical purposes, the SVN and Git repositories are now equals. Pick your poison; use whatever you’d like for all your development and deployment needs.

    For creating patches: If you’re into the command line, simply use git diff — to be specific, git diff --no-prefix is ideal. This format is easily applied with patch, just like SVN diffs. For more, check out scribu’s post on contributing using git. Might also be a good time to plug grunt-patch-wordpress, a work in progress — help make it awesome, if you can.

    With this mirror, we’ve applied some lessons we learned from previous experiences:

    • Tags for major releases receive an extra .0 (“3.8.0″, not “3.8″), making them compatible with tools requiring semver-like version numbers, and allowing branches to have their own namespace (“3.8″, not “3.8-branch”).
    • Committer data is pulled from WordPress.org.
    • The SSL versions of the SVN repositories are used.

    Note that these Git repositories have different hashes than anything currently mirrored on GitHub. We never did break these hashes as promised a year ago. Next steps will be to figure out how to best mirror these to GitHub (and replace what’s there), which is complicated by now having old and new repositories for core development. Additionally, I’m sure we’ll find at least one glitch in this in a matter of a few days, so consider the next week or so a beta test.

    Edit: Well, I mentioned the next week would be a beta test. We found an error (that didn’t take long) in how authors got synced over, so we’ll be breaking the hashes tonight.

    There are a lot of other repositories on WordPress.org not yet mirrored. Notably: plugins and themes. These are massive multi-project repositories and will require a bit more investment.

    • Amy Hendrix (sabreuse) 6:51 pm on January 15, 2014 Permalink | Log in to Reply


    • Boone Gorges 6:52 pm on January 15, 2014 Permalink | Log in to Reply

      OMG. git-svn, I will not miss you. Thanks @nacin!

      • Andrew Nacin 6:56 pm on January 15, 2014 Permalink | Log in to Reply

        To clarify, as I think I chopped out an sentence when editing this: It’s still a read-only mirror. “For all practical purposes” was meant to apply to everyone but committers. So for the committers to these repos that want to use Git, you’ll still need to use git-svn, for the moment.

    • Travis Northcutt 6:52 pm on January 15, 2014 Permalink | Log in to Reply


    • Ionel Roiban 6:53 pm on January 15, 2014 Permalink | Log in to Reply

      Great! How about an official repo on Github?

      • Andrew Nacin 6:58 pm on January 15, 2014 Permalink | Log in to Reply

        We’ve had an official mirror there for a long while now. But this is subject to some changes; see the second-to-last paragraph in this post.

        • Ionel Roiban 7:20 pm on January 15, 2014 Permalink | Log in to Reply

          Thank you. I did actually have that Github repo watched but its description makes it clear that it is just a mirror (from svn) and not a place where anyone can submit their contributions to. What’s the plan on accepting pull request directly on Github, if any?

          • Andrew Nacin 7:25 pm on January 15, 2014 Permalink | Log in to Reply

            I’ve been studying how some other projects do or don’t do this. Something to discuss in a few months, I imagine.

            • Weston Ruter 11:12 pm on January 15, 2014 Permalink

              @nacin yeah, it is amazing to see that Symfony2 recently (and rightfully) boasted about having over 10,000 pull requests on their GitHub repo: https://github.com/symfony/symfony/pulls

              I can’t imagine how many Core pull requests would come in if WordPress accepted them on GitHub.

            • Mike Schinkel 8:18 pm on January 19, 2014 Permalink

              @Weston – LOL. Too many pull requests might be a “be careful what you wish for” concern than that the core team might want to avoid! :)

    • deltafactory 6:54 pm on January 15, 2014 Permalink | Log in to Reply

      Please excuse me if this had been answered previously:

      What’s the roadmap, if any, for deprecating SVN for core development and/or plugins?

      • Andrew Nacin 7:04 pm on January 15, 2014 Permalink | Log in to Reply

        If you or your tools want to use Git, you should be able to. If you or your tools want to use SVN, you should be able to. You could think of it as a desire to be VCS agnostic. Whether one commits to SVN or pushes to Git is ideally a decision that should rest with individual plugin developers. Or for the case of these repos, the group of committers. When the infrastructure is there for this, of course.

    • Thomas van der Beek 6:57 pm on January 15, 2014 Permalink | Log in to Reply

      Yippie-kai-yay! Can’t wait for plugins and themes repo’s!

    • Drew Jaynes 6:58 pm on January 15, 2014 Permalink | Log in to Reply

      This is great news! If/when plugins and themes are mirrored over, it will be a huge boon as well. Thanks for all your work on rolling this out :)

    • Bryan Petty 7:12 pm on January 15, 2014 Permalink | Log in to Reply

      For anyone that wasn’t currently aware, there has been a large on-going effort to do the same for plugins for the last year already, currently mirroring up to GitHub: Plugin Mirror

      It’s still more of an experiment and utility than an officially supported workflow though.

    • Cor van Noorloos 7:20 pm on January 15, 2014 Permalink | Log in to Reply

      Probably in too much of a hurry, but will http://svn.automattic.com/wordpress-i18n/pot/trunk/ also receive its git mirror?

    • Andrew Nacin 7:24 pm on January 15, 2014 Permalink | Log in to Reply

      The post makes clear that these operate over git://. The reason is this is simply being served using git-daemon. We’ll work on support for http-based communications in the future. If your organization blocks git and requires http or https, you can easily mirror this yourself for the moment (and stay tuned for these to be pushed to GitHub).

    • Julien 7:30 pm on January 15, 2014 Permalink | Log in to Reply

      Aaah so awesome! Thanks for making this happen !

    • Mike Schroder 7:44 pm on January 15, 2014 Permalink | Log in to Reply

      Woohoo! I’d been waiting for this. Thanks muchly!

    • Andrew Nacin 7:49 pm on January 15, 2014 Permalink | Log in to Reply

      So, I did mention the next week would be a beta test. We found an error (that didn’t take long) in how authors got synced over, so we’ll be breaking the hashes tonight.

      • Daniel Bachhuber 10:19 pm on January 15, 2014 Permalink | Log in to Reply

        Just to clarify: this means github.com/WordPress/WordPress will be broken (or worse, incorrect) for everyone that’s added it as a submodule in their projects? Or am I missing something?

        • Andrew Nacin 10:34 pm on January 15, 2014 Permalink | Log in to Reply

          Sorry, I meant the hashes of these git.wp.org repositories. We haven’t figured out what the plan will be for the GitHub repository yet. We already signed off on breaking those hashes in the past, but I don’t know how feasible that is. Options include moving wordpress/wordpress to wordpress/wordpress-build (and then optionally breaking the hashes and having it mirror core.git) and then adding a new wordpress/wordpress-develop for develop.git (one downside being the watchers and stars wouldn’t carry to the new “canonical” repo, but not a big deal). Suggestions welcome.

        • Daniel Bachhuber 10:42 pm on January 15, 2014 Permalink | Log in to Reply

          Phew :) Glad I don’t have to work late tonight. I don’t have any good suggestions at the moment.

    • WebSharks 8:08 pm on January 15, 2014 Permalink | Log in to Reply

      This is awesome! Hooray :-) Can’t wait to see this extended to plugins/themes.

    • Gregory Cornelius 8:12 pm on January 15, 2014 Permalink | Log in to Reply

      You made my day.

    • Stephen Edgar 9:04 pm on January 15, 2014 Permalink | Log in to Reply

      Very Cool, Thanks. :)

    • Pippin Williamson 9:04 pm on January 15, 2014 Permalink | Log in to Reply


    • Rafael Funchal 10:33 pm on January 15, 2014 Permalink | Log in to Reply

      This is really awesome.

    • Nashwan Doaqan 10:21 am on January 16, 2014 Permalink | Log in to Reply


    • Frank 4:36 pm on January 16, 2014 Permalink | Log in to Reply

      Great to see, that WordPress opens for git.

    • Chuck Reynolds 5:20 am on January 17, 2014 Permalink | Log in to Reply

      big step.. love it.

    • Eduardo Reveles 11:48 pm on January 17, 2014 Permalink | Log in to Reply


    • avoryfaucette 10:35 am on January 18, 2014 Permalink | Log in to Reply

      Omg so exciting! I’m really stoked to hear that WordPress is moving in the direction of fully supporting Git and maybe eventually GitHub.

      I have a question that I hope isn’t too newbie for here. I understand the issues above with GitHub and I can handle using the command line. However, I’m new to open source contributions and would like to start with working on small WordPress bugs. I have a GitHub profile and have installed GitHub’s software to my Mac to keep track of my forks locally. So I have two questions:

      1) For my local purposes, does this mean I could theoretically keep track of my own work in the GitHub software, even though I can’t actually use GibHub to submit patches? If yes, would I just follow scribu’s instructions through step 3 (make a feature branch) and then locally save the clone of the WordPress source files so my GitHub software can see it?

      2) For “having things on my GitHub profile purposes,” once I’ve followed to command line steps to submit my patch, would I just use the usual process to send the patch to GitHub but not actually create a pull request?

      Thanks for helping out a new contributor!

      • Andrew Nacin 11:02 pm on January 18, 2014 Permalink | Log in to Reply

        Right, you can still create a feature branch, commit to that branch, and push that branch to your own fork on GitHub. You just would not actually create and send a pull request. Note that you can also get a patch from GitHub by adding “.diff” to the end of any commit URL.

    • Todd Lahman 1:08 am on January 25, 2014 Permalink | Log in to Reply

      Looking forward to the day when the plugin repo is gitified.

    • Denis de Bernardy 6:22 am on January 31, 2014 Permalink | Log in to Reply

      git clone git://buddypress.git.wordpress.org buddypress
      Cloning into ‘buddypress’…
      fatal: unable to connect to :
      [0: ::1]: errno=Connection refused
      [1:]: errno=Connection refused

      • Denis de Bernardy 6:25 am on January 31, 2014 Permalink | Log in to Reply

        Also, when I clone the same using http, I get:

        $ head readme.md

        1. WordPress for Android #

        i.e. not the correct repo.

      • Andrew Nacin 6:26 am on January 31, 2014 Permalink | Log in to Reply

        You need a trailing slash in addition to the git protocol.

        • Denis de Bernardy 9:14 am on January 31, 2014 Permalink | Log in to Reply

          OK, that works. A redirect or a more meaningful error message would be welcome… As would making the http version of the repo serve the correct repo. :-)

          • Andrew Nacin 9:17 am on January 31, 2014 Permalink | Log in to Reply

            I’m not sure why the slash is needed, but based on the error I presumed it was at the git client level, not something on our end. I honestly have no idea.

            The git protocol is served by the git daemon. The http protocol is served by gitolite, which was never actually deployed; I’ll get that turned off for now to alleviate confusion.

    • helgatheviking 3:13 pm on April 1, 2014 Permalink | Log in to Reply

      I too am seeing the fatal error. I was able to clone ok, but now when I need to pull:

      fatal: unable to connect to develop.git.wordpress.org:
      develop.git.wordpress.org[0:]: errno=No error

  • Andrew Nacin 10:19 pm on January 9, 2014 Permalink | Log in to leave a Comment
    Tags: notifications,   

    New Trac notifications feature 

    Monday’s long list of improvements to Trac was just the first course. Introducing per-ticket notifications.

    Just above the comment box, you’ll see a new notifications pane. Here, you can watch/unwatch tickets.

    This means Trac’s terrible email address CC feature is gone. (Last night, I migrated over about 15,000 CCs going back nine years.) Old comments that are just CCs are now hidden via JS, which makes a few of the busier or popular tickets easier to skim.

    You can also click the star next to the ticket number at the top:

    Screen Shot 2014-01-09 at 4.38.22 PM

    Watching a ticket adds it to some new reports: open tickets I’m watching and all tickets I’m watching. Now your list of starred tickets are all in one place.

    Coming soon: You’ll be able to watch/unwatch a ticket directly from a report, like starring conversations in a Gmail inbox (edit: added). You’ll also be able to subscribe to entire components and milestones (here’s a sneak peek). And, @-mentions will let you add someone to a ticket.

    A note on how this is implemented: isn’t just subscribe/unsubscribe. “Watch” can also be thought of as “Vote” or “Star” or “Favorite”. We’ll soon add a star count to reports (next to the new Comments column — edit: added). If you’re watching a ticket, you’ll always get notifications. If you’re not, you might still get notifications if you reported the ticket, or are subscribed to that ticket’s component or milestone, or if you’ve been mentioned (and the notifications box will tell you that). From there, you have the option to actively “Watch” the ticket, passively continue to receive notifications, or specifically mute/block notifications coming from that ticket.

    Follow-up question from @sabreuse, about watching/voting/starring/favoriting: If you subscribe to the “firehose” (wp-trac mailing list) and receive all notifications anyway, should you star tickets anyway as an indication of interest? Yes, I’d say so! (If you receive the mailing list to the same email address as your WP.org profile, you’ll only receive one email. It’s possible your mail client could ascertain you received it as a BCC versus just via a mailing list, though I’m not sure.)

    Feedback, ideas, suggestions are very much appreciated. Also, all of this code is open source (a lot of it is a WordPress plugin).

    Edit, bonus: @ocean90 converted most icons on Trac into Dashicons.

    • Janneke Van Dorpe 10:26 pm on January 9, 2014 Permalink | Log in to Reply

      Awesome! What about notifications that are set on profiles.wordpress.org? :D

      • Andrew Nacin 10:32 pm on January 9, 2014 Permalink | Log in to Reply

        For @-mentions and such? Yeah, I’m going to try to pipe mentions through that. That said, what should the emails look like? Should they be Trac content piped through the HTML emails, or should you receive a Trac email? I think it’ll end up being Trac-style emails for @-mentions but the HTML emails for other string matches… Still trying to figure out how I’m going to tackle it.

        • Janneke Van Dorpe 10:44 pm on January 9, 2014 Permalink | Log in to Reply

          I’d be really nice if they’re all HTML emails, converting Trac’s markdown. But some people probably prefer plain text.

          • Andrew Nacin 10:49 pm on January 9, 2014 Permalink | Log in to Reply

            I just meant they are two completely different templates – mentions emails and Trac emails. Which one to use?

            • Janneke Van Dorpe 9:34 am on January 10, 2014 Permalink

              I don’t know, but I’d use the same one for all kinds of notifications.

            • Mel Choyce 6:59 pm on January 15, 2014 Permalink

              My vote would be for using the current mentions emails for trac, if only because having an email that’s more designed makes it easier to scan and understand.

              (I’d also be game for redesigning the mention emails.)

    • Pippin Williamson 10:29 pm on January 9, 2014 Permalink | Log in to Reply


    • keoshi 10:35 pm on January 9, 2014 Permalink | Log in to Reply

      This is awesome! Great work.

    • Jose Castaneda 10:38 pm on January 9, 2014 Permalink | Log in to Reply


    • Amy Hendrix (sabreuse) 10:41 pm on January 9, 2014 Permalink | Log in to Reply

      Yay! I’m really liking all of these improvements. Trac is feeling both friendlier and more usable already.

      I’ve pretty much stopped using ticket cc’s since I sacrificed my inbox to the firehose — what you say about using star counts as votes suggests that it might be worth starring to indicate interest even though I’m already notified?

    • Kim Parsell 11:14 pm on January 9, 2014 Permalink | Log in to Reply

      Thank you for all of the hard work – Trac is so much better to work with now. :)

      I’ve got several tickets from a few years ago with CCs for an old email address that will be going away soon. Do you want to remove those CCs so you don’t get the email bounces from them, if there would be any activity on them?

      • Andrew Nacin 11:28 pm on January 9, 2014 Permalink | Log in to Reply

        I managed to map every email address CC to the corresponding user account (took me about five hours to script it then manually go through about 200 unknowns). I then imported all of them into the new notifications system, which is based on usernames. Then I literally emptied every CC field across all tickets. So those old tickets are now linked to directly to your username and profile email. :-)

    • Brad Touesnard 12:33 am on January 10, 2014 Permalink | Log in to Reply

      Well done sir!

    • Lance Willett 3:16 am on January 10, 2014 Permalink | Log in to Reply

      This is really cool—makes Trac even more user friendly and useful for both newbies and veterans alike.

    • Rami Yushuvaev 9:29 am on January 10, 2014 Permalink | Log in to Reply

      Looks great!

    • Marcus 11:50 am on January 10, 2014 Permalink | Log in to Reply

      bravo, removing cc is a welcome feature :)

    • Lance Willett 6:42 pm on January 10, 2014 Permalink | Log in to Reply

      @nacin — Got my first email for Bundled Themes, nice! It was a notification for #26782.

      One question: I noticed the Reply-To is wp-hackers@lists.automattic.com — is that still correct?

      • Andrew Nacin 6:48 pm on January 10, 2014 Permalink | Log in to Reply

        Yeah, Trac emails have always been set up for that. Mostly to prevent replies from trying to go to the wp-trac list, which is announcement only.

        • Lance Willett 6:51 pm on January 10, 2014 Permalink | Log in to Reply


        • Lance Willett 6:51 pm on January 10, 2014 Permalink | Log in to Reply

          Crazy idea: what if an email reply made a new comment on the ticket?

          • Helen Hou-Sandi 6:56 pm on January 10, 2014 Permalink | Log in to Reply

            I thought about asking about that once, and then thought about how often using that feature on Basecamp leads to forgetting and/or ignoring context. It’s also good to actually visit tickets sometimes, as not everybody knows that uploading attachments doesn’t trigger any notifications.

            • Andrew Nacin 7:09 pm on January 10, 2014 Permalink

              GitHub supports this and every once in a while you can tell someone used it because some quoted text sneaks in. I think that ultimately, it’s a pretty edge feature. The cost of implementing this far outweighs the limited benefit.

              It doesn’t look like there are any decent Trac plugins that implement this. Even if they did, it sounds like it’d be a nightmare even just to configure and get working. It’s still a cool idea, of course, just not worth the energy.

    • Robert Dall 6:59 pm on January 10, 2014 Permalink | Log in to Reply

      @nacin When you click on next ticket… It stays in the same report now! Cool!!!

  • Andrew Nacin 7:47 pm on January 6, 2014 Permalink | Log in to leave a Comment

    Lots of improvements to Core Trac 

    Over the holidays, I was sick for two weeks (boo). While resting and recovering, I took to working on our tools (yay). Specifically, Trac. Here’s an overview of the added features, enhancements, and bug fixes. There’s a lot (and more on the way), so I’ll try to keep each point brief. If you have any questions I’d be happy to elaborate in the comments.
    (More …)

  • Andrew Nacin 7:51 pm on January 3, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    The email used for notifications on Trac is currently specified in Trac preferences. I’m changing this to pull automatically from your WordPress.org profile. After this change, there will not be a way to have a separate email address for Trac and any manually specified email address will be overridden.

    We need to make this change because, very simply, it’s a better user experience. By killing this extra user preference, it’s one less step users need to set up in order to receive notifications. (And a tighter feedback loop could possibly boost engagement.)

    That will affect about a thousand users we have in the system, probably incidentally for most. But, about 50-100 users might have been deliberately declaring a separate email address; for example 50 users had “trac” appear specifically in their email. Even without a dedicated email, it is trivial to filter Trac emails; you just might need to make some adjustments.

    As you may have noticed, this is part of a series of changes I’ve been making to Trac. I’ll be doing a summary post in a few days outlining everything that has changed.

    NOTE: This does not affect wp-trac@lists.automattic.com. If you subscribe to the “firehose” this is not affected.

    Edit, 20:23 UTC. This is now enabled. For the moment, the email address will sync when you next visit Trac. Please find me if you have any questions.

    • Ionel Roiban 7:55 pm on January 3, 2014 Permalink | Log in to Reply

      Sounds good.

    • Ryan Duff 7:57 pm on January 3, 2014 Permalink | Log in to Reply

      Is there an ETA on the time this will be changed?

      I’ll have to update my email filters on my .org acct and would like to have it ready to test so my phone doesn’t blow up some night when I’m sleeping.

      That’s why I used a specific “list” acct ;)

      • Ryan Duff 7:59 pm on January 3, 2014 Permalink | Log in to Reply

        Err wait, this is the notification email, not the list email. I may be fine as I think that goes to the same email on my .org profile already.

        Heads up may still be nice for the handful that will have to adjust though.

      • Andrew Nacin 8:00 pm on January 3, 2014 Permalink | Log in to Reply

        Sometime in the next 1-72 hours.

        Note — you have the same email address in both Trac references and your WordPress.org profile. If you were referring to the firehose mailing list, that’s not affected. I’ve added a note to the bottom of the post.

        • Ryan Duff 8:13 pm on January 3, 2014 Permalink | Log in to Reply

          Yup. I’m using a separate address for the svn/trac mailing lists. When I went to verify email filters I realized that the ones that come through as trac notification went to the email on file for .org.

          This week has been a bumble from the start. At least it’s Friday. Thanks for following up!

    • Andrew Nacin 8:08 pm on January 3, 2014 Permalink | Log in to Reply

      Here is a short list of names I recognize who this will affect: @westi @dd32 @viper007bond @sterlo @coffee2code @chmac @eddiemoya @kawauso @lloydde @mrmist @ptahdunbar.

      In most cases, though, the user updated their WordPress profile but never bothered to update Trac. That’s why we’re doing this!

    • Eddie Moya 7:38 am on January 4, 2014 Permalink | Log in to Reply

      I did use “+trac” in my email address to filter for it, so I really appreciate that you went through the effort of figuring out who might specifically affected by it. Otherwise I would have been confused about why my filters stopped working, since this is something I haven’t touched in a very long time.

      Idk if the list is just really that short of people affected – but maybe it would make sense to send out a blast email on trac to let everyone know that way in case they aren’t lucky enough to be the 11 names you listed. Just a thought.

      Thanks again for the heads up.

  • Andrew Nacin 9:26 pm on December 31, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    Commit announcements for 3.9 

    Lots of news to share! First: Helen Hou-Sandí has had guest commit for the past three release cycles. She’s been spending the last year reviewing contributions, mentoring contributors, and working on some of our larger UI projects. I’m proud to announce @helen is now a permanent committer to WordPress!

    We’ve invited John Blackbourn (@johnbillion) to be a committer for the 3.9 cycle. His strong, consistent contributions have been backed by excellent judgment and temperament.

    Matt Thomas, who led the dashboard redesign in 3.8 (and 3.2, and 2.7, etc.), will keep his commit to continue to maintain and improve WordPress UI. He’s been a great mentor to many contributing designers and his long-term impact is indelible.

    For the last few years, we’ve been granting commit access on per-cycle basis, sometimes for a particular component, feature, etc. Generally, after about a year, a guest committer can be considered for permanent commit access. Dominik Schilling, Sergey Biryukov, Drew Jaynes, and Scott Taylor have all had their commit extended for 3.9.

    Drew (@DrewAPicture) was given temporary commit for inline documentation starting with 3.7. He’s been heading up the long-running initiative to document every hook in WordPress. Scott (@wonderboymusic) also started committing during 3.7, and has a particular penchant for digging deep into the query and taxonomy APIs. And Sergey (@SergeyBiryukov) and Dominik (@ocean90), well, they are forces of nature.

    (@aaroncampbell was also given guest commit in 3.7, but he ended up not having much time to use it.)

    Here’s a full list of those with permanent commit: @markjaquith, @ryan, @westi, @matt, @azaozz, @dd32, @koopersmith, @duck_, @helen, and me (@nacin); @lancewillett for bundled themes; @iammattthomas for UI. You might have also seen commits before from @josephscott (XML-RPC), @nbachiyski (internationalization), and @mdawaffe (secret weapon for really tricky problems).

    Next weekly meeting is January 8. Happy new year, everyone. Here’s to a great 2014.

  • K.Adam White 7:58 pm on November 13, 2013 Permalink
    Tags: Build Tools, , JSHint   

    Finding and Fixing JavaScript errors with JSHint 

    The JavaScript Coding Standards have been updated, so it’s time to move on to tackling our JSHint errors!

    JSHint is a tool to check for errors in JavaScript code. As was discussed last week, we’re kicking off a small effort to work through our core JavaScript files. To get through the errors revealed by JSHint as quickly as possible, we’re following the model established by the Inline Docs team and posting a list of files with issues so that people can “claim” the files they’d like to fix!

    At the bottom is a list of every file in core that is displaying JSHint errors. Files with a checkmark have been patched and should now be passing lint. Files marked with (@username #xxxxx) are already claimed, and being worked on.

    Please read and understand the process we’ll be following to address these issues! Many thanks to @azaozz, @nacin and @jorbin for helping identify the safest way to approach fixing these errors, and to @rzen for posting the Inline Docs article on which we based this guide.

    How to contribute:

    1. Leave a comment on this post with the file* you’re about to edit (check the list first to make sure it hasn’t already been claimed).
    2. Update your local WordPress SVN to the latest version of WordPress trunk (currently 3.8-alpha).
    3. Create a new ticket on Trac for the file.
      JSHint-related trac ticket settings

      • Format the title as “jshint shouldn’t throw errors – path/to/file.js”.
      • Assign the ticket to the “Build Tools” component.
      • Make sure your email is stored in Trac’s preferences

      If you are logged in, you can click this link to automatically open a ticket with the right settings.

    4. Edit the file, and make a patch. Please make sure you create the patch from the root directory of your WordPress SVN checkout. If you are working on a large file, consider making multiple patches for each type of change.
    5. Upload your patch to the Trac ticket you created, and add the keyword “has-patch”.

    *Note: We strongly encourage you to work on one file at a time. These shouldn’t take very long, but if you call a bunch at once and get tied up, we won’t be able to get through these as quickly as possible. To quote @rzen from the inline docs effort, “your edits should be made and patched swiftly so that they aren’t invalidated by (or don’t invalidate) another patch.”

    Keeping Discussions Focused:

    Any discussion about the specifics of a patch itself should happen on Trac. Discussion about the overall effort should take place during our standing weekly meeting, on Wednesdays at 1900 UTC in #wordpress-dev*.

    Files needing patches:

    Checked files are now passing JSHint

    See all open tickets in the Build Tools component

    For tips on dealing with global variables, inlined third-party code within first-party scripts, etc, see the JSHint tips in the JavaScript Coding Standards

    For the curious, this list was created with a jazzy little command @nacin came up with to pipe Grunt output through ack:

    grunt jshint --force | ack '^Linting src/' | ack -o 'wp-.*.js' | sort | uniq -c | sort

    What we’re NOT doing

    The two JSHint options called out in the earlier post, “curly” and “eqeqeq,” would ordinarily make up the vast majority of the errors JSHint reports in our files. We’ve currently set Grunt and JSHint to ignore these two types of errors when JSHint is run against core. While these are best practices, we’ll come back to them once we address the more significant code smell issues like undefined variables.

    Also note that we’re not tackling whitespace or non-JSHint-related refactoring during this effort. We’ll get there, but we have to mitigate the risk to core as much as possible so we don’t interrupt the 3.8 cycle. Keep your changes focused on passing JSHint this go-around.

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