WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Updates from Andrew Nacin Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Nacin 6:54 pm on January 24, 2014 Permalink
    Tags: ,   

    Continuing the Trac component re-organization with "focuses" 

    Based on triaging a few hundred tickets in the General and Multisite components, we’ve added five components:

    • Bootstrap/Load — applies to wp-settings.php, ms-load.php, load.php, ms-settings.php, etc.
    • Login and Registration — useful for multisite, but applies to single-site too
    • Options and Meta — option.php, meta.php, etc.
    • Script Loader — WP_Scripts, WP_Styles, and script-loader.php
    • Networks and Sites — multisite only

    We also removed two components that (poorly) described the problem rather than the affected area of core. “Validation” ranged from from validation tickets to XHTML issues. HTML validation issues now belong in the affected component, like “Template” or “Administration.” “Warnings/Notices” contained tickets ranging from PHP warnings to providing feedback to users. The open tickets were moved to more appropriate components. Additionally, the remaining tickets in “AtomPub” were wontfixed and the component was removed.

    A new concept: Focuses

    We’ve also added seven new “focuses”ui, accessibility, javascript, docs, multisite, performance, and rtl. Focuses are about broad concepts and help break tickets down by specialties and skills, rather than functional areas of core. Multisite and RTL are widely general “modes” for WordPress, and each have contributors who focus strongly on those areas, but they are not well-contained “components” of core. Accessibility isn’t an area of core — it permates the entire user experience. A ticket about inline documentation should still receive the attention of developers for that area of core (say, comment.php), while those who focus on inline documentation should still be able to do so.

    “Focuses” is a new field in Trac. They’re like tags, and more than one can be assigned to a ticket. It can be queried using custom queries. And they have their own reports which we hope to properly expose and make better really soon — https://core.trac.wordpress.org/focus/accessibility.

    Guidelines to help with the transition

    The corresponding components for the new focuses have been removed. The “ui-focus” keyword has also been converted over. Overall, we gained five components but lost eight.

    This has the potential to be confusing at first and we’ll surely need to make some adjustments. Also, the component cleanup is not done yet — this is just the beginning. Here are some guidelines for how to use the new focuses.

    • The old RTL component — use the rtl focus and assign a relevant component. If it’s RTL issues with the media library, use the “Media” component. If it’s about the RTL build tools, then use the “Build Tools” component. If it’s more general, then use the “I18n” component.

    • The old Accessibility component — use the accessibility focus and assign a relevant component. For issues with the media library, use “Media.” For issues with activating a theme, use “Themes.”

    • The old Inline Docs component — use the docs focus and assign a relevant component. Hook documentation for user.php belongs in the “Users” component.

    • The old Multisite component — use the multisite focus and assign a relevant component. If it’s related to users, use “Users.” If it’s related to the loading process of multisite (choosing a site based on domain and path, etc.), use “Bootstrap/Load.” If it’s related to the installation process, use “Upgrade/Install.” network_admin_url() goes into the “Permalinks” component. get_site_option() is “Options and Meta.” The Network Admin still has its own component. (Choosing that component or “Networks and Sites” automatically assign the “multisite” focus for you.) @jeremyfelt recategorized about 110 tickets into about 15 different components.

    • The old Performance component — use the performance focus and assign a relevant component. Improving the performance of WP_Query belongs in “Query,” improving the performance of get_option() belongs in “Options and Meta,” etc.

    • The old Graphic Design component — use the ui focus and assign a relevant component. (This is probably going to be “Administration”, at least for now.)

    • The old ui-focus keyword — This has been removed. Simply use the ui focus.

    • The old JavaScript and UI components — these have not existed for some time. Use the corresponding focus and assign a relevant component.

    We may add more focuses over time. For example, the “Text Changes” component would probably make a better focus, for our wordsmiths.

    Any questions, suggestions, or comments?

    This is a summary and addendum of one section of this Wednesday’s weekly developer meeting. Logs.

     
    • Helen Hou-Sandi 7:06 pm on January 24, 2014 Permalink | Log in to Reply

      Really excited to see this happening. I think focuses will give us a really solid place to point new contributors, as not all of them (or perhaps not even many of them) have any idea what components of WordPress they might want to work on, but they do know they’re into UI making or JavaScript. I think it also conceptually just makes more sense – there are functional components of core, and there are concepts that apply to all areas of core and are not fundamentally separate, like accessibility and documentation.

    • Jeremy Felt 7:49 pm on January 24, 2014 Permalink | Log in to Reply

      Many +1s, this is great. Two things come to mind.

      1 – Is it clear (or is it true) that UI focus covers UX as well or should that still be handled via keyword? I assigned a couple to UI focus last night thinking that it would generally cover that.
      2 – We should try to distinguish what belongs in ‘Network and Sites’ vs ‘Network Admin’. I left a bunch that dealt with adding new sites in ‘Network and Sites’, but because it deals with `wp-admin/network/site-edit.php`, it may be better in Network Admin.

      • Jeremy Felt 10:48 pm on January 25, 2014 Permalink | Log in to Reply

        Another thought.

        If a cache issue is oriented around cron, should it be assigned the ‘Cache’ component with no focus, or the ‘Cron’ component with ‘Performance’ focus.

        It seems that many caching issues could be considered performance issues, but not all of them. They are closely related almost always though.

    • Xavier Borderie 12:36 pm on January 25, 2014 Permalink | Log in to Reply

      Piggybacking on a Trac-related post (sorry, and couldn’t figure if it was better suited for make/core or make/meta — since it’s WP-related, I feel it’s best posted here)…

      While talking about background updates and 3.8/3.9 being the only versions to receive any further updates, I’ve been pointed to the Trac roadmap, which still features milestones for 3.5.3 (one open ticket, for backporting reasons), 3.6.2 (one closed ticket) and 3.7.2 (13 tickets total).

      So, what should it be? Would a cleanup be needed in those tickets, or are there really remaining plans for branches 3.5, 3.6 and 3.7?

    • Umesh Kumar 6:34 am on April 17, 2014 Permalink | Log in to Reply

      Is there anyway in Tickets section to show my previous contributions? I can see the current open tickets but not the closed one.

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

      Thanks,

      • 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

      Hello!
      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?

      Best,
      David

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

      ‘/wp-content/themes//style.css?ver=2.0.2′

      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:

      Akismet
      All In One SEO Pack
      Artiss Transient Cleaner
      Better WP Security
      BruteProtect
      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
      Akismet
      Clean Options
      Lightbox Plus ColorBox
      WP-DBManager

      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.

      http://wordpress.org/support/

    • 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 11:58 pm on January 22, 2014 Permalink  

    WordPress 3.8.1 Release Candidate 

    Greetings! WordPress 3.8.1 RC1 is now available for final testing. Here’s a zip, or you can set the WordPress Beta Tester plugin to “point release nightlies.” (Trunk, which is 3.9-alpha, also has all of these fixes.)

    We hope to get this released to you as early as tomorrow, January 23. Once 3.8.1 is released, we’ll wait a few hours before turning on automatic background updates, which will then be gradually rolled out over about a day.

    It’s been nearly six weeks since 3.8, which has seen more than 9 million downloads. It’s now time to kick 3.8.1 out the door, especially since we’re now ramping up WordPress 3.9 development.

    Feel free to leave here any questions or comments about 3.8.1 in general, though if you have found a bug in WordPress, please report them on Trac.

    Below is a complete changelog. Each section is roughly ordered by priority. Also on Trac, you can also find the full changelog, a diff of the changes, and the list of 3.8.1 tickets.

    Embedding tweets:

    • Switch Twitter oEmbed to SSL due to a Twitter API change that broke embedding across all WordPress sites. [26969], #26844.

    WP_Query fixes:

    • Fix category handling in pre_get_posts when pretty permalinks are in use; fix handling of taxonomy queries in get_queried_object(). [26946], #26627, #26634.
    • Avoid a fatal error in wp_reset_postdata() if $wp_query global is not set. (Also affected 3.7.) [26951], #26775.

    Themes screen fixes and improvements:

    Fixes for the new dashboard design:

    • Fix the “dead zone” on submit buttons, so they actually click. [26998], #26700Chrome bug.
    • Prevent the admin color scheme from previewing when editing another user. [26937], #26607.
    • Update the styles for the media modal when used on the frontend. [26992], #26677.
    • Add a contrasting border to admin feature pointers. [26970], #26689.
    • Update Dashicons to latest. (The Updates icon now points in the right direction.) [26965], #26518.
    • OCD alignment updates on the Updates screen. [26938], #26699.

    Responsive admin fixes:

    • Prevent widget controls from going off the screen when editing extra-wide widgets on small devices. [26964], #26701.
    • When moderating comments, make sure the comment author is always visible. [26961], #26618.
    • Responsive improvements to submenus in the toolbar. [27009], #26720.
    • Improve keyboard accessibility for the admin menu when in responsive mode. [27010], #26639.
    • Prevent the toolbar from wrapping to a second line on narrow screen (multisite only). [26949], #26537.

    The new dashboard widgets:

    • Quick Draft widget: Don’t ignore default comment status and ping status. [26960], #26722.
    • At a Glance widget: Don’t link to Pages or Posts for Authors or Contributors (respectively). [27001], #26574.
    • Quick Draft widget: Break long words in Quick Draft content to prevent overflow. [26948], #26658.

    Miscellaneous:

    • Media: Fix directory permissions for new media upload directories. [26927], #26781.
    • RTL: Force LTR direction for code inputs. [26954], #26666.
    • RTL: Make sure half-stars in star ratings are filled on the correct side. [26953], #26814.
     
  • Andrew Nacin 9:03 pm on January 22, 2014 Permalink
    Tags:   

    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!

    Widgets

    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

    Miscellaneous

     
    • 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 8:05 pm on January 15, 2014 Permalink
    Tags:   

    WordPress 3.9 planning 

    We were supposed to discuss WordPress 3.9 during the weekly meeting last week, but in the absence of a decision on a release lead, and with a lot of 3.8.1 things to get through, it got pushed to today. 2100 UTC, #wordpress-dev (so, in an hour).

    I’ll be the release lead for WordPress 3.9. Expect some familiar faces helping me out, including Andrew Ozz, who will be overseeing all of the TinyMCE work already underway this cycle; Helen Hou-Sandí, who will be spending most of her time working on and advising ongoing feature plugins efforts; Sam Sidler, who will be helping with project management; and Mike Schroder, who will be backing me up for this release.

    Today we’ll be:

    • Setting a schedule. The tentative 2014 roadmap decided in December slated 3.9 for April 15. That’s 90 days from now, and sounds good to me.
    • Reviewing feature plugins. Lots of things in progress — let’s take a quick look.
    • Brainstorming on what this release should be focusing on. There are plenty of possibilities when it comes to iterating on existing features (especially those added in the last five releases — the customizer, media, audio/video, theme browser, admin UI), general bug-fixing, long-standing architecture and API improvements, and such.
    • Discussing changes to workflows. Changes to Trac, ticket reporting, re-doing our components tree, a new Git mirror, and such make this release look a lot like 3.7, when we kicked off the new core development repository. We could use continual help to identify how we can make it easier to contribute, break through bottlenecks, etc. We also need to tag some tickets as good-first-bug!

    Hope to see you today. Have any idea, thought, or suggestion about 3.9 or for today’s meeting in particular? Please leave a comment so I can prepare for it. Talk soon.

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

      Good to have you leading 3.9. Here’s a small patch that would make a big impact. Expanding on the custom template for database failures: https://core.trac.wordpress.org/ticket/25703

    • Jen Mylo 8:24 pm on January 15, 2014 Permalink | Log in to Reply

      Settings! Discussion Settings as a starting point. We didn’t touch them in 2.7, or 2.8, or 2.9, or ever since before I was even around core. They are super-confusing and seemingly contradictory with the checkboxes for options that appear mutually exclusive. I’d like to take point on redesigning that settings screen so that choosing your comment options are as easy as leaving a comment. As part of this project, we’d take a look at other settings screens and clean up any untidy bits/make them consistent. In the absence of the long-awaited settings API, I’d like this release to be the one where don’t let the perfect be the enemy of the better re settings and we switch from tables to css. If there’s a dev or two that wants to hit this with me (no codename, just “Improve Settings”), that’d be great.

      • Helen Hou-Sandi 8:31 pm on January 15, 2014 Permalink | Log in to Reply

        I’ve been thinking about this a fair bit recently, from two sides:

        1. Creating reusable form CSS, and then using that to switch off of tables on the settings screens.
        2. What are “Settings” vs. “Preferences” vs. “Options”? Can we do a sorting activity or something similar?

        As far as the comment moderations settings go, I think there’s a good starting point here, just needs somebody to weigh in on the option naming and upgrade routine: #23233

      • Ipstenu (Mika Epstein) 8:42 pm on January 15, 2014 Permalink | Log in to Reply

        Network Settings: The unholy cluster of “Shove everything on one screen and pray” would be nice to fix.

        • Jen Mylo 9:32 pm on January 15, 2014 Permalink | Log in to Reply

          Yep, that would fall under making other settings screens consistent and better. I started with Discussion as the pitch because it was driving me crazy the other day.

      • Manuel Schmalstieg 9:10 pm on January 15, 2014 Permalink | Log in to Reply

        Talking of Discussion Settings – I remember reading a ticket that proposed an easy function for disabling entirely all commenting functionality on a site (and thus removing all reference to comments from the admin UI). But that proposal disappeared from my radar and didn’t re-surface, can’t find the Trac entry anymore. Was I dreaming?

      • Konstantin Obenland 10:41 pm on January 15, 2014 Permalink | Log in to Reply

        I’d be happy to help out with creating patches!
        Would this project also include the custom header/background settings pages?

        • Nick Halsey 1:10 am on January 16, 2014 Permalink | Log in to Reply

          My guess would be no, but I’d love to separately get #25569 and #25571 (and their many media-related prerequisites) done in 3.9 so that we could streamline and eventually expand those features. I think leveraging the customizer would be a good way to cut down on the need for settings pages in general.

      • Nick Halsey 1:05 am on January 16, 2014 Permalink | Log in to Reply

        I’d love to help with this as well. I’ve been looking through the different settings pages, and realized that we could conceivably remove Reading by merging the rest of those controls to the customizer, removing them, and/or moving a couple to a different page. Looking more closely, there isn’t much in Writing either once post by email is finally removed. Permalinks could take up much less space too. Evaluating which options we really need and also addressing their organization could help reduce both the number of options and the number of pages, which seems like a solid/tangible goal. At the moment, though, Discussion is most certainly the worst.

      • Stefano Aglietti 8:31 am on January 16, 2014 Permalink | Log in to Reply

        On Settings removing the WordPress address and the site address leaving them just as wp-config option. This 2 settings are totally misunderstanded by tons of user and in italian forum there is question about what happened cause someone changed them “by mistake” or cause he/she was thinking to make something different

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

      With 3.5, 3.7, and 3.9, I seem to have a propensity for leading odd-numbered releases. However, this pattern also requires the initial number to be odd. :-) Already promised my wife 4.1 is out of the picture. Just saying.

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

      Excited to help out! Looking forward to the brainstorm session today, to get us on the way.

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

      Excited to be able to help out full-time this cycle.

      While not formally a feature-as-a-plugin, I created a little plugin to play around with rendering the gallery shortcode output inside the Visual editor. There is some overlap with the Front-End Editor plugin. I also want to experiment with wp.mce.view and see if we can create some sort of abstraction for bringing more inline editing of shortcode blocks into the Visual editor or at least some sort of easy to create preview mechanism.

    • Ozh 8:56 pm on January 15, 2014 Permalink | Log in to Reply

      Dudes, I already planned everything for you a couple months ago: http://planetozh.com/projects/wp-core-team-agenda/

    • Ansel Taft 10:27 pm on January 15, 2014 Permalink | Log in to Reply

      As someone who’s learning PHP, I’m excited by the good-first-bug! trac ticket designation, so maybe I can contribute to the CMS I love… though the core team will need to heavily scrutinize the code we first-timers push up, and feedback welcomed.

    • scotthack 11:21 pm on January 15, 2014 Permalink | Log in to Reply

      Guessing there is already a plugin that could be evaluated and promoted to look at. But I’d like to see a CPT and taxonomy manager ( with an import feature ) that will help keep that functionality OUT OF THEMES. That way if someone purchases a theme from a theme shop, they can import the CPTs and taxonomies and get the functionality that the theme is expecting. But if they change the theme, that data won’t go away.

    • markpack 11:41 pm on January 15, 2014 Permalink | Log in to Reply

      One tiny suggestion: it would be great to restore the option there used to be when adding a photo to a post to also make it the featured photo with just one tick box on the same add photo screen. It adds an annoyingly large number of extra clicks and a delay to have to add the photo to the post and then make it a featured image separately.

    • leemon 3:00 pm on January 16, 2014 Permalink | Log in to Reply

    • Dave Navarro, Jr. 1:31 am on February 18, 2014 Permalink | Log in to Reply

      I’d love to see links fixed so that jQuery Mobile can be used without going through hoops.

  • Andrew Nacin 6:49 pm on January 15, 2014 Permalink
    Tags:   

    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

      w00t!!

    • 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

      Awesome!

    • 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

      Fantastic!

    • 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

      Coool!

    • 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

      Nice!

    • 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: 127.0.0.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: 66.155.40.244]: errno=No error

  • Andrew Nacin 5:31 pm on January 10, 2014 Permalink
    Tags: reporting,   

    Brainstorming ticket reports 

    One thing I’d like to work on is improve our reports on Trac with the hope we can better manage the ticket queues. We currently have about 50 reports on Trac. Many of them were created in a push 5-6 years ago to build reports around keywords. A number of others are one-offs created in the last few years for specific use cases. In reality, few of these are ever used on a day-to-day basis.

    I checked the access logs to get an idea of the most popular reports. Besides the first six reports (my favorite “home base” is report 6), they are report 16 (“Needs Patch”), report 18 (“Blockers for Releases”), and report 21 (“Latest Tickets”).

    What I’d like to do is brainstorm all sorts of new reports we should have. How can we make what we have better? I’ll then go to work about implementing them. Dream big — if the data’s there, I’ll figure out the gnarly SQL required. We can also think about how we can improve columns, grouping, ordering, etc. If you have a concept for a report but aren’t sure how we’d query for those tickets, toss the idea out there and maybe someone will add to it.

    I’l probably design a new /report screen so it’s not just a list ordered by something random like when the report was created, and so we can highlight important reports, group similar reports together, and put less emphasis on some of the more specialized ones.

    Here are some half-baked ideas, to start us off:

    • Open tickets without a response. Find all tickets where no one has commented, or where only the reporter has commented. This would create a punchlist of tickets to review. (Ideally, the report should always be empty.) The ability to group or filter this by component would be helpful, for contributors who specialize in and want to take responsibility for different areas.
    • Report of “dead” tickets. Tickets that haven’t been modified in four years are ripe for action and/or closure. We should empty a report of this nature, then reduce it to 3.5 years, then 3 years, etc.
    • Good first bugs. A report of all tickets marked as a good first bug. (None yet, as the keyword is new.) Next steps: How can we best identify these kinds of tickets?
    • Report of “untriaged” tickets. Our milestones have gotten out of hand, which is something we should discuss. Tickets should immediately leave “Awaiting Review” once they’ve been initially reviewed, but then not forgotten about if they are shifted to “Future Release”. Let’s figure out metrics for what makes a ticket “untriaged”. We could create a simple UI to filter by component for a report like this. We currently have Tickets Awaiting Review which groups tickets by the “Version” they were reported against — maybe this is a good start.

    What’s your idea?

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

      Candidates for closure. Not 100% sure what this would look like beyond the “close” keyword (perhaps semi-related to “dead” tickets?), but could be a good report, especially for those getting into Trac gardening. Dreaming big!

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

        I’m not sure what this would look like either, hence this exercise. :-) Closing out tickets that shouldn’t be open any longer is always a fine idea! The keywords “close”, “2nd-opinion”, “reporter-feedback” are all good for this. Some kind of combination of Needs Reporter Feedback / Steps To Reproduce and Suggesting Close / Needs 2nd Opinion (that’s close to 200 tickets right there).

        Not sure what else — yeah, I’d say it’s related to “dead” tickets. Once “Awaiting Review” is under control again, it could be used to identify the oldest tickets still awaiting review.

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

      An “intelligent” report on a component. For a particular component, group and order tickets in a way that helps keep the component well-maintained. The first group would be “slated for the next release,” for example. Other groups could include “Tickets awaiting review”, “Tickets more than X years old”, “Tickets needing feedback,” “Tickets with patches,” and (if they don’t fit into another group) “Major bugs,” “Minor bugs,” and “Enhancements.” The report should probably also try to render the component’s ticket graph at the top so we can see changes over time.

      A report like this could be a prime home base for a contributor wanting to clean up and be responsible for a component. What other groups would make sense?

      • Jeremy Felt 6:04 pm on January 10, 2014 Permalink | Log in to Reply

        Somewhat out of scope… is there a way to relate a ticket to other components. When a major effort is taken in Administration, then a report of ‘Multisite tickets that could be affected’ would be interesting.

    • Morgan Estes 5:56 pm on January 10, 2014 Permalink | Log in to Reply

      Not sure what to call it, but something for patches submitted for a release but not responded to by the time of the release freeze. I have a couple like this that I’m unsure of the status (realizing that just because it’s submitted doesn’t mean it’s used), and are in Awaiting Review.

    • Jeremy Felt 5:58 pm on January 10, 2014 Permalink | Log in to Reply

      Along the same lines of dead tickets, I wonder if there’s use in a view of all tickets reported against a version X releases old. These should be ripe for verification as they may have been resolved unknowingly along the way.

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

      A report of tickets that have a patch uploaded to them no one has replied to yet. We’d do this by finding the most recent patch upload for a ticket, then seeing if there were any comments (by someone other than the uploader) that had been posted after.

    • Jeremy Felt 6:02 pm on January 10, 2014 Permalink | Log in to Reply

      Last modified might take care of this, but “Open tickets without a response in 30 days” or “Open tickets without a response in 2 releases”

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

        The report of “dead” tickets mostly covers this, I think. But taking it further: perhaps “without a response” are the operative words here. Response from whom? How about open tickets where the last person to reply is the reporter? That tells me they are waiting for a reply from someone else.

        • Jeremy Felt 6:10 pm on January 10, 2014 Permalink | Log in to Reply

          Not sure if we can get fancy with roles, but “without response from a lead developer” or “…from active component person” or “…from bug gardener” or “…from committer” could all be interesting.

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

            I was just thinking about that. Tickets without a response from any of X individuals is interesting. Of course, Sergey and I mostly cover the spread on that. :-) Maybe tickets where the last person to comment is not one of those people.

            We could probably come up with a way to do this on a per-component basis (so, all multisite tickets Jeremy has never looked at).

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

      I think there are some good opportunities to highlight “extremes”. For example: Which open tickets have the most comments?

      The most votes isn’t that useful of a metric yet (and also, because it’s mostly just long-standing tickets like post relationships), but what about comparing/contrasting votes and comments? It’s really interesting to see a really long ticket that has almost no interest. #22692 has 67 comments yet just one vote, which tells me it’s a bit of an edge case and a time suck. Compare that with 68 comments but 31 votes on #19393.

      High number of attachments is interesting. So could a ratio of comments to attachments? Dunno. Lots of possibilities here.

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

      From a docs perspective, it would be lovely to have a report that gathers needs-docs, needs-codex, and docs-feedback together. Right now we have:

      • Report 12 (needs-unit-tests/needs-docs)
      • Report 36 (needs-codex)
      • Report 37 (needs-unit-tests)

      Seems like that would also free up the needs-unit-tests duplication between reports 12 and 37.

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

        Should needs-docs, needs-codex, and docs-feedback all be different groups on this report? What would they be called? “Needs Inline Documentation”, “Needs Codex Documentation”, “Needs Feedback on Documentation”?

        • Drew Jaynes 7:04 pm on January 10, 2014 Permalink | Log in to Reply

          I’d probably group them separately, yes. And ouch on the verbosity, but I guess that’s probably necessary — we can’t expect everyone to understand Docs == Documentation ;)

          It just occurred to me that there also might be room for including tickets on the Text Changes component. Though text changes kind of serve a different master, it’s all documentation in one form or another in the end.

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

      For Twenty Thirteen and Fourteen development we used a verbose custom query along the lines of https://core.trac.wordpress.org/query?status=accepted&status=assigned&status=new&status=reopened&status=reviewing&component=Bundled+Theme&summary=~Fourteen&group=milestone&col=id&col=summary&col=status&col=owner&col=type&col=priority&col=milestone&order=priority (try searching the #wordpress-themes logs for it, it changed a few times too).

      It would be cool if we could create a report that achieves the same effect, allowing us to select a particular bundled theme’s open tickets.

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

        I wish I had heard about this. We could have made it a saved report with just a few clicks. :-)

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

        Nick beat me to the punch on this suggestion. But a total +1 on that.

        We could name it:

        “Current Default Theme Development”

        Or something like that…

    • Eric Andrew Lewis 6:49 pm on January 10, 2014 Permalink | Log in to Reply

      Some reports are also not 100% accurate, because tickets require a human-touch to change keywords. Sorry to go a bit tangential to this topic, but I’d like to suggest we improve report integrity by adding some automation here. There are a few ways we could approach this, I’ll just give one that’s been on my mind for a while, and I’m sure others’.

      Automated patch cleanliness testing, which could automatically toggle ‘has-patch’ // ‘needs-refresh’ keywords via a bot.

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

        This is doable! We could have a bot go through and apply the latest patch on a ticket. If it doesn’t apply, we could add needs-refresh. Any other ideas along these lines?

        • Jeremy Felt 6:55 pm on January 10, 2014 Permalink | Log in to Reply

          We could have a bot go through and apply the latest patch on a ticket. If it doesn’t apply, we could add needs-refresh.

          +1withmany0s

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

          If we did this, I feel we’d have this bot do a few other things too. So, apply the patch and run unit tests, for example. (This would need to be sandboxed. Even applying and reverting patches would need to be done carefully.)

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

            Was going to suggest running unit tests post-patch. +1 to that.

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

              I imagine it would not be too difficult to integrate Travis CI into all of this. @bpetty?

            • Bryan Petty 7:15 pm on January 10, 2014 Permalink

              We could potentially trigger patch builds by scripting up automated pull requests. It’d be a bit of work, but I’m pretty sure this would be easier to do from Jenkins CI. @kurtpayne still has a Jenkins CI setup running, it’s a little out of date (I don’t think he’s actually updated it to use the develop repo still), but he probably has a better idea of how we could automate it.

              http://jenkins.kpayne.co:8080/

            • Bryan Petty 7:18 pm on January 10, 2014 Permalink

              Another option might be to setup a copy of Gerrit working off a git mirror.

            • Bryan Petty 7:29 pm on January 10, 2014 Permalink

              For what it’s worth, MediaWiki uses a combination of both Jenkins and Gerrit, and uses Jenkins bot to make several different checks to automatically sign-off patches in Gerrit. Maybe in our case, just Jenkins + Trac is good.

              Good checks to make can include:

              • PHP lint check
              • CodeSniffer with WP rules (this can be iffy though where existing code base isn’t already entirely compliant).
              • Unit tests
        • Morgan Estes 6:57 pm on January 10, 2014 Permalink | Log in to Reply

          That’s excellent! I’ve wondered how needs-refresh gets applied, and this would be a good addition to the “has anyone seen this yet?” status.

          How would it handle multiple patches in a ticket that deals with multiple fixes for a solution?

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

            It wouldn’t be able to handle multiple patches, because it wouldn’t know the difference between an old patch (that is stale and has been updated) versus an alternate patch. I think that’s OK, this is definitely better than not having it at all.

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

          Automatically adding has-patch and triggering the notification for that would be good, since uploading attachments doesn’t. Would probably have to be a little smart about what’s a patch vs. not, but could be cool. False positives would be better than missed patches, in any case.

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

            It could look around for *.patch or *.diff uploaded and have been there for at least an hour. (If the person is going to comment, we can assume it’d be within an hour.) Then we can check if the report has has-patch. If it doesn’t, we can have a bot post a comment and add has-patch.

            Even if the person has commented, it’s possible they didn’t add has-patch. We could still add the comment in that case. That said, it’s possible their comment is to say “Ignore my patch, that won’t work.” How do you differentiate between a user who didn’t add has-patch accidentally, and a user who didn’t add it on purpose?

            So, new approach. Two different angles. One, a bot that goes around and adds has-patch if the user hasn’t commented with an hour. Two, some JS that looks to see if a patch was recently uploaded by the current user. If it has, it Clippy-prompts the user, letting them know to post a comment and add has-patch.

            Or, we could provide feedback after uploading a patch that tells you to post a comment and add has-patch to the ticket.

            “Hey, you’ve uploaded a patch! Be sure to *add a comment to the ticket*.” And that link will not only take them to the new comment form, but it’ll automatically add the has-patch keyword for them.

        • Mike Schroder 12:52 am on January 11, 2014 Permalink | Log in to Reply

          I really like this idea.

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

      Needs unit tests. Some contributors may just like writing unit tests. We used to say that a ticket would receive needs-unit-tests until they got committed. But now that tests and src are in the same repository, tests in most cases should be committed with the code they are testing. This is good, but means we need to tweak things a bit.

      So what we could do is this:

      • needs-unit-tests is added to an open ticket. This adds it to a report.
      • Someone writes unit tests. The keyword is removed, and it falls off the report. At some point, the tests are committed with the patch on the ticket, and things are good to go.

      And for closed tickets:

      • A ticket is closed, but it could still benefit from unit tests, so the needs-unit-tests keyword is added. This adds it to the same report, under a separate section probably.
      • Someone writes the unit tests. The keyword is replaced with “has-unit-tests”, and it is moved to another section on the same report saying “Tests Ready for Commit” (which would only list closed tickets with has-unit-tests).
      • Once committed, the has-unit-tests keyword is then removed.
    • John Blackbourn 7:44 pm on January 10, 2014 Permalink | Log in to Reply

      Plugin candidates. Open feature requests which have some comments or CCs but no patch or only stale patches. Candidates for someone to build the feature request as a plugin. Might also give us a chance to close the unwanted ones.

    • John Blackbourn 7:51 pm on January 10, 2014 Permalink | Log in to Reply

      Needs dealing with. Open tickets reported against versions more than two versions old that are marked as high or highest priority, or major/critical/blocker severity. Basically these need dealing with.

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

      Kind of off the wall, but I would love a report that scanned all patches to see if they add new JavaScript unit tests so that it was easy to review all potential JS Unit tests.

    • Kurt Payne 2:36 am on January 11, 2014 Permalink | Log in to Reply

      Responding to @Bryan Petty … I haven’t kept jenkins up to date. I do, however, have some scripts that may prove usefulf for this. The idea is this:

      • Create a clean development chroot
      • Check out wordpress, create a database, etc.
      • Apply the patch to the source
      • Run the unit tests
      • Display the output
      • Destroy the chroot

      It still takes a few mins to do, but it’s a very good way to get basic feedback on patches like “does it apply cleanly? does it break unit tests?” Let me know if you want to see. It has not been updated with the latest (3.7) svn layout.

      • Bryan Petty 6:25 am on January 11, 2014 Permalink | Log in to Reply

        As far as that goes, it’s way easier than it used to be with two checkouts, and I did get that all written for our Travis CI config. I just figured you’re much more familiar with Jenkins than I am, and might know how to best configure the build configs, and how to trigger Jenkins on Trac patch uploads. :)

        But I can certainly look into it myself too when I have the time.

    • Kurt Payne 7:16 pm on January 11, 2014 Permalink | Log in to Reply

      @bpetty I can help with Jenkins, sure.

      Travis is probably the best way to go for just unit tests.

      Jenkins is going to be more flexible for things like static analysis tools, customizing reports, integrating with other tools (e.g. Sonar is a popular dashboard), triggering downstream builds, potentially scaling by adding build slaves and potentially adding selenium tests (if wordpress ever has them).

      With regards to the “test the patches” script above … we can talk more offline about it … the important question is: Do we want something that automatically tests patches?

    • Sam Sidler 8:17 pm on January 14, 2014 Permalink | Log in to Reply

      A bit late to the party, but I’ve read through all the comments here and it seems like we have a bunch of good reports already that are hard to find. I think we should redo the Reports page to group together specific reports and make it easier to do specific component queries.

      The specific reports in each section might not be quite right in this mockup, but basically this is what I’m thinking: http://i.imgur.com/R7uNrJo.png

      (Even merged needs-docs, needs-codex, and docs-feedback together for a “Needs Docs Team” report.)

      For certain reports that are a combination of reports (like the Needs Docs Team report), we could easily list out what it includes underneath along with links to those specific reports.

      I’d also want to consider adding a “Open tickets by keyword” option on the right side, similar to the component one.

      All of this should be pretty easy to implement, it’s just a matter of deciding how much we want to round the corners of the boxes. ;)

  • Andrew Nacin 10:19 pm on January 9, 2014 Permalink
    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

      Fantastic!

    • 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

      Awesomesauce!!

    • 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

          Cool.

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

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

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