Make WordPress Core

Updates from Aaron Jorbin Toggle Comment Threads | Keyboard Shortcuts

  • Aaron Jorbin 8:03 pm on May 4, 2015 Permalink |

    Bug Scrubs for the Week of May 4 – 10 

    tl;dr;  Bug Scrubs in the #core slack channel on Tuesday, May 5 2015 11:00am EDT and Wednesday, May 6 2015 8:00pm EDT.

    Full Text:

    Last week, there was a call for tickets that people wished for eyes on during the 4.3 cycle. Many of the tickets have received comments and attention thus far, but some have still gone months without a comment. This week, there will be two bug scrubs where we look through this list of tickets. Scrubs are a concentrated period of time for contributors to triage Trac tickets while other people are around at the same time.

    Right now, I’ve created an Custom Trac Query that includes every ticket linked to on the call for tickets that isn’t already in the 4.3 milestone grouped by type. This is the query we will work off for the bug scrubs this week. We will start with bugs, and then move on to the other ticket types.

    Tuesday, May 5 2015 11:00am EDT and Wednesday, May 6 2015 8:00pm EDT are the two times that I’ve chosen.   These two times do not conflict with any of the other currently scheduled chats and are at different points in the day so that no matter where on the planet you are, you can hopefully participate in at least one.

    Never been to a bug scrub before? Join us in the #core slack channel!

  • Aaron Jorbin 10:06 pm on April 29, 2015 Permalink |

    Hop on the WordPress 4.3 Train: Open Call For Tickets 

    There comes a time in every great WordPress release that we ask everyone to share a ticket that is a priority to them. That time is the beginning, and that time is now. In WordPress 4.2, there were 231 defects fixed that had been opened against previous versions of WordPress, in large part do to people championing the issues important to them. Please post a link to a ticket you think needs some more eyes on it.

    Scott Taylor put it well at the start of the WordPress 4.2 cycle, so I’ll steal his genius words: “There are over 3000 tickets in Trac. If there’s a ticket you feel is neglected or should have light shined upon it: leave a comment here with a link so we can triage it. Help us help you.”

  • Aaron Jorbin 4:15 am on April 23, 2015 Permalink |
    Tags: ,   

    WordPress 4.2 Field Notes 

    WordPress 4.2 includes both new and improved features. It also includes changes under the hood.  While I’m sure you’ve been testing your themes, plugins, and sites in preparation for the release, you may have missed the announcements of all the changes. Here is a quick rundown of developer related things you should know:

    Additionally, the bundled version of jQuery UI has been upgraded from 1.11.2 to 1.11.4 and jQuery to 1.11.2.  The team also fixed 231 defects reported againgst previous versions of WordPress.  Please continue testing in preparation for the imminent 4.2.0.   WordPress wouldn’t be where it is without you.

    UPDATE: Add information on spinners and admin notices.

  • Aaron Jorbin 3:52 pm on March 31, 2015 Permalink |
    Tags: , ,   

    Screen Reader Text in output of comments_popup_link 

    As of WordPress 4.2, the output of comments_popup_link now uses .screen-reader-text in themes using the default strings in calls to comments_popup_link. The accessibility team has put together a post on hiding text for screen readers that includes sample code to use in your themes.

    I recommended that all themes include the .screen-reader-text class. This change was announced by the on the theme team blog in January. In the future, there may be more changes to output that relies upon the presence of the .screen-reader-text class.

    Related Ticket:

  • Aaron Jorbin 7:49 pm on December 16, 2014 Permalink
    Tags: ,   

    WordPress 4.1 Field Notes 

    The release of WordPress 4.1 is imminent. By now, you should have already been testing and preparing your plugins and themes. I wanted to highlight a couple of posts here over the last few months on changes in WordPress 4.1.  This is by no means a complete summary of everything that has changed, but will give you a sense of what you have coming to you in the next few days.

    This version of WordPress features some new template tags in a continued attempt to improve core’s Theme APIs.

    Taxonomy, Date, Meta and Comment queries all have been updated and improved.

    As a part of the taxonomy roadmap, When a term is created with a matching slug as an existing term, we now create a new entry in wp_terms.

    Distraction-free writing has received a full revamp.

    Themes now can have better support for the <title> tag

    There have been several improvements to the Customizer API, including contextual panels and sections, and JavaScript templates for controls.

    Please continue testing your sites, plugins and themes. WordPress wouldn’t be where it is without you.

  • Aaron Jorbin 4:50 pm on October 28, 2014 Permalink
    Tags: ,   

    WordCamp San Francisco User Testing Results 

    WordCamp San Francisco, @johnbillion and I conducted some user tests.  We focused on three feature plugins planned for 4.1: Focus, Author Select, Session Manager.  When possible, we created an editor account for users and had them participate on there own device.  When they didn’t have a device, they participated on one of our laptops.

    Below are the notes.

    Dan – developer. using a macbook

    “Wow” was first reaction to focus. Kind of felt like it was shocking and he needed some frame of reference. Maybe keep 5px or so of menu so you know you can go back to it. Fading of buttons kind of make it feel like they are disabled.
    Author select – Immediately knew what to do. super natural
    “Where are you logged in” – knew to go to profile page, found the panel right away.

    Michelle – designer/developer. using a macbook

    It’s disconcerting not to see all the things. “If the point of things is to be distraction free, it’s weird not to see publish since that is what people want to do”. Fading of buttons seems a bit weird. Not sure she like automatically going into distraction free. It’s jarring.
    Author select -didn’t search, just selected.

    Janneke – Developer. using an iPad mini

    Author select on iPad mini – Super hard to use. Can’t really scroll down. Not at all intuitive.
    Profile manager – Looks horrible on iPad mini
    Focus – She is building it, so I didn’t test it :)

    Josh – Developer. using a macbook

    Likes not having the sidebar menu. Losing the meta boxes seems odd. Might be weird for some people.
    Author select. Select 2. Using display name instead of user name. Seems odd.
    First looked to tools to find where he was logged in.

    Joe – Developer. using a macbook

    Lag on the editor screen makes things feel slow and confusing.
    Author – Not used to to having it enabled by default is different. Seems to be able to use

    Cory – WP business owner. using his macbook

    Loves the focus. Seems super natural.
    Author – Very usable.
    Profile – Didn’t quite understand question at first, but once he did, made it and found that info right away.

    Mel – designer. using our laptop

    Focus – It’s weird that it’s not centered. Less things on the page makes it harder to focus.
    Author – “I heart Select2″

    Jen –  Freelance writer and photographer. Has her own blog, using a MacBook.

    Initially wasn’t enthusiastic about the fact that the meta boxes and menu disappeared, “oh, what’s going on?”. Was confused about how to get them to re-appear, erroneously clicked an unrelated button in the browser in an attempt to get the UI to reappear. After figuring out that the UI re-appears when you move your mouse or tab away, actually very much liked the behaviour.

    I mentioned that we were considering adding a feature pointer pointing to the DFW button. Jen said she thinks this will be important. User has no other idea of what’s going on otherwise.

    Couldn’t find where the user sessions may be listed. Mentioned that she is the only user on her site so she would have no interest in it. Expected it to be on the dashboard, or on the same screen as Jetpack analytics.

    Christen –  blogger

    “Create a new post” – First went to quick draft. When I sent her to the regular draft screen, it seemed natural to her. She liked the “Distraction free writing”. It felt natural to her. Once it was in place though, she didn’t really look for anything else on the page.

    Andre – Theme Builder. Design and build.

    Focus Was natural. Really liked and it seemed 100% natural to him.
    Author – Select two was a natural choice and he really likes it.
    Went to tools page to find sessions.

    Matt – developer and project manager

    Not enthusiastic about using the editor focus improvements himself, but said he would leave it enabled for his clients who write more long form content than he does. Suggested that some form of A/B testing may be desirable if we have the time. No other feedback.

    User session list will be of interest to him as a project/site manager, not so much use to his clients themselves. Suggested that we could implement a dashboard widget which displayed the “last accessed” time for the current user, or listed other current sessions if there is more than one. Also suggested adding an “active sessions” column to the user list screen, visible to site admins.

  • Aaron Jorbin 5:26 pm on October 24, 2014 Permalink

    Feature Testing at WordCamp San Francisco 

    Getting feedback from real users is incredibly valuable, and WCSF occurs at a great time in the 4.1 dev cycle to do that. We will have a space next to the happiness bar to solicit feedback on upcoming features. In order to accomplish this, if you will be at WordCamp SF this weekend and want to get feedback on a feature that you are working on, please comment below.

    I will setup some test sites with trunk and the trunk version of the feature plugins (along with some test data) to help expedite this. The plugins I am planning on having are:


    If you can help with staffing this area, please comment below.

    • Drew Jaynes (DrewAPicture) 5:33 pm on October 24, 2014 Permalink | Log in to Reply

      I’m in to help test for a while.

    • Daniel Bachhuber 6:08 pm on October 24, 2014 Permalink | Log in to Reply

      I’ll co-opt people who come to visit me at the Happiness Bar to do some testing.

    • Avryl 6:14 pm on October 24, 2014 Permalink | Log in to Reply

      I can help too.

    • Ipstenu (Mika Epstein) 10:59 pm on October 24, 2014 Permalink | Log in to Reply

      I can help

    • Luke Carbis 1:35 pm on October 25, 2014 Permalink | Log in to Reply

      Happy to help staff the area. @lukecarbis

    • Nick Halsey 5:38 pm on October 25, 2014 Permalink | Log in to Reply

      I’m not there, but it would be cool if you have enough interest to test some of the non-4.1 plugins like the Front End Editor and Menu Customizer as well.

    • Ryan Boren 11:40 pm on October 26, 2014 Permalink | Log in to Reply

      Feature plugins should be updated every week in the plugin repo (every day would be even better). With the beta tester plugin, auto updating to each nightly is effortless. Following feature plugin development should be as convenient.

      • Knut Sparhell 1:57 am on October 28, 2014 Permalink | Log in to Reply

        I have the beta tester plugin, but not Twenty Fifteen. I have the session management plugin from Github, but not a one click update for it. I’m the dog and wordpress.org is the dogfood here.

    • Ryan Boren 1:02 am on October 27, 2014 Permalink | Log in to Reply

      Instead of just testing new stuff, have them show how they usually work. Capture real flows. Be an Alan Lomax of flow. Seeing how people work with and around our interfaces is very interesting. For example, Android users use the Android sharing mechanism to push images to the media library through the Android app. Later, they create galleries from wp-admin on the desktop. Why? Because creating galleries is impossible in the apps and painful on the mobile web due to things like lack of multi-select and aggravating tab switching in the media modal. Another example, some use upload.php to edit image meta because they can’t use the small input fields in the sidebar of the media modal. Those are revealing flows.

  • Aaron Jorbin 8:08 pm on September 29, 2014 Permalink

    Core Build/Test tools chat 

    I’ll be hosting a chat for Build and Test tools on Wednesday, October 8, 2014 2:00am UTC . The goal will be to triage and discuss the existing tickets along with identifying enhancements, new initiatives, and other improvements.

    Please comment below if you have any suggested build/test improvements that are not currently in a ticket.

    Note, that this may not be the permanent time for Build/Test tool chats. I know it isn’t ideal for everyone (especially Europe).

    • Rodrigo Primo 10:13 pm on September 30, 2014 Permalink | Log in to Reply

      Last WCSF during Contributor Day I worked with Bryan Petty to configure Travis CI on his fork of WordPress:


      The configuration file we created was incorporated into the official repository (https://core.trac.wordpress.org/ticket/26364). Any progress has been made after that towards having an official CI solution for WordPress?

      People are still using Bryan account for Travis CI or there is another CI service being used?

    • Rodrigo Primo 1:05 pm on October 2, 2014 Permalink | Log in to Reply

      Having an official CI service running somewhere would be great. But anyway it is good to know that you have configured Travis CI based on a mirror of the official repository. This is already very useful.

      I will try to attend the meeting next week. I’m available to help with build and test tools but I don’t know where to start.

    • Stephen Edgar 10:59 pm on October 5, 2014 Permalink | Log in to Reply

      Agenda Items: Tabs vs Spaces indentation for JSON files https://github.com/FlagshipWP/Compass/pull/11

    • Gary Jones 12:40 am on October 6, 2014 Permalink | Log in to Reply

      I’d really like to see configs agreed for the WP community as programmatic definitions of WP Coding Standards, even if they cant be used in core yet. Having them agreed means themes and plugins can be using them. Examples:

      Hopefully plugins and themes would adhere to these configs, but could always use theme as starting points if they needed to adapt them to their own situation. Having it seen as come from core gives it more weight than individuals doing their own (individual) thing.

      To clarify – I know WP core isn’t in a position to use all these, but I’d hope that this group discussion could get some technical agreements made for the benefit of the wider community, which core could then use at a later date.

      Instead of a single Gruntfile.js, I’d like to see a more modular approach, with each task put into it’s own file, such as seen in https://github.com/FlagshipWP/Compass/tree/master/grunt/config – the benefits are code that is easier to read, cleaner version control history, and potential code re-use. The Gruntfile.js then becomes setting up of paths and files variables, meaning a module like checking JSHint checking could be used in core and in plugins or themes, with no or few changes – setting a good example for the wider community.

      As it’ll be 3am in the UK, I’ll be unable to attend, but I hope my thoughts here can be considered.

    • K.Adam White 1:44 am on October 6, 2014 Permalink | Log in to Reply

      I may be unable to attend this chat due to a work meeting conflict, but I second most of what Gary says above: blowing the gruntfile into separate task files is definitely best practice, and I’ve been generally impressed with JSCS as a style-oriented complement to JSHint. We’ve got lots of fun opportunities to make working with the codebase easier!

    • Gary Jones 7:30 pm on October 6, 2014 Permalink | Log in to Reply

      Just to add to my earlier comments regarding discussion and potential agreement around configurations, particularly for coding standards and style, I think there should be two configs for each tool or area:

      1. An ideal-world configuration for tool X, that WordPress core and plugins and themes should ultimately be aiming to satisfy for coding standards and coding style.
      2. A real-world “this is what we can manage right now” config that WP core can satisfy in the short term, and a plan for how to get from here to the ideal config.

      Once the first is formally decided (ignoring the current state of any code), then these config files along with the verbose descriptions and examples can be added to the Handbooks, enhancing and filling in the gaps in the existing standards.

      As an example, an ideal config might say that each PHP class should go into it’s own file, to keep declarations and side-effect-causing code separate, as per PSR-1. Realistically WP might never manage that, and the real-world config committed to develop would reflect that, but having the endpoint agreed means that:

      • Plugins and themes, especially new ones, should aim for one-class per file.
      • New commits to core should follow one-class per file.

      I think it’s important to identify what we’d like the code in the WP community to be like, and how to programatically test against it, even if WP core itself isn’t going to get there in the foreseeable future.

    • Aaron Jorbin 1:59 am on October 8, 2014 Permalink | Log in to Reply


      • Tabs vs Spaces indentation for JSON files
      • Spliting up Gruntfile.js
      • css linting #29792
      • JSCS
      • Config files for additional tools
      • Open Tickets
    • Gary Jones 8:10 am on October 8, 2014 Permalink | Log in to Reply

      Chat logs: https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2014-10-08&sort=asc#m935953

      I wanted to write this post to record the type of thing I would have replied, if I had been able to make it.

      > I would want to see how badly we fail running jscs before knowing if it makes sense to include it or not

      I’m reading that as “If we suck at our own standards so much, we won’t bother trying to fix it”.

      > Would need to look at those Compass .jscsrc rules and compare with WP Core standards and see where there at for starters

      Definitely. I’ve explained above how that file is sectioned, and some rules are what I think are good practices but are not covered in the current textual description of the JS CS. Having a group of people look at it, decide which rules code in the community should be following and publishing that means themes (and plugins) like Compass can update their own .jscsrc to match and update their code accordingly.

      > In general, I don’t think we should include config files for tools we aren’t using in core

      I would agree with that; I never said that the discussion and agreement of various config files should result in them being added to core. As per my earlier comment above, what I propose is ideal world configs that everyone should be aiming at, and then each project (Core included) can just include / use the ones they want or are able to.

      > we shouldn’t tell plugin/theme developers what standards they should follow

      Disagree. As a community I believe we should be coming up with code standards configurations that are programatically testable and making an opinionated statement of CS that is applicable to all code within the community. Plugin and theme authors are free to ignore these standards if they wish, as some already do.

      The WP CS for PHP says:
      “Keep the following points in mind when writing PHP code for WordPress, whether for core programming code, plugins, or themes.”

      The WP CS for JS says:
      “JavaScript has become a critical component in developing WordPress-based applications (themes and plugins) as well as WordPress core. Standards are needed for formatting and styling JavaScript code to maintain the same code consistency as the WordPress standards provide for core PHP, HTML, and CSS code.”

      Both of those imply that the standards are intended to apply to all code in the WordPress community, not just core. The chat logs mention bbPress and BuddyPress both attempting to follow the standards too.

      > unless we are going to hold ourself to the same standards

      Core doesn’t follow it’s own PHP and JS standards, yet they are defined in the Handbooks. The point about having configs for PHPCS, JSCS, CSSLint/CSSComb are that these make the standards automatically testable, and cover ambiguous holes in the current wordy-descriptions of the standards.

      Core is just another project within the WP community, albeit the main one, so by having testable standards agreed *for the community*, Core can gradually and incrementally work towards satisfying those in it’s own time, the same as any plugins or themes that also want to work to them (and should be encouraged to).

      > I think we should move the discussion back onto make/core since at this point it is all hypothetical

      Aaaaand I think I’ve discovered the source of my frustration with this. Jorbin (quite rightly) is considering the practicalities of *Core* build and test tools. There doesn’t seem to be an obvious group of folks who are making decisions about standards at a higher level, for the whole community. Maybe my points here have missed the mark because of it. I’d like to help out with any such group, because I feel there is value in having testable code standards across all code in the community, that is not limited by the current situation of the main project.

  • Aaron Jorbin 5:28 pm on January 3, 2014 Permalink  

    #26669: wp-admin.css should be broken up into modules 

    During 3.8, we started to work on Adding a CSS preprocessor by using SASS for the color schemes in WordPress Core. We also had some great discussion about using a CSS preprocessor.

    Most of the ideas for where we want to end up (Either using a pre-processor like Sass or a post-processor like Autoprefixer) depend upon our CSS not being in a single file with over 13k lines.

    Something like this needs to be done early in a release cycle since it will 1) invalidate patches that are currently based on a single wp-admin.css file (though MP6 already invalidated almost all of them from before 3.8) and 2) creating a patch like this is time consuming and relies upon wp-admin.css not changing while the patch is being created.

    I’ve created ticket number #26669 and uploaded a patch which shows the grunt and script-loader changes necessary. These changes make it so the only difference you see when running WordPress from /src are that you have more css files being loaded in the browser. It will still work smooth.

    Please share your thoughts on splitting wp-admin.css up. Ideally we can make a decision on this during or before the January 8 Dev chat in order to get this in for 3.9.

    • Mel Choyce 5:33 pm on January 3, 2014 Permalink | Log in to Reply

      Yes please. I feel like splitting up the files would make it SO much easier to find where particular styles live, and definitely would have made me feel much more confident poking through the files when I started contributing to core.

    • bobfox321 5:45 pm on January 3, 2014 Permalink | Log in to Reply

      I think it necessary to make it easier for non or neophyte WordPress coders to figure out what works and what doesn’t in CSS. I really rely on examples from my use of TablePress. When I do my pre-modification review (faqs, forums, manuals, etc) to my tables I usually find answers. When I apply answers, particularly in CSS, they sometimes work and sometimes not. That is easier to understand than when they work one day and stop working the next.

      TablePress is an outstanding product but as always there are features I want that makes a difference.

      I understand the many conflicts between plugins and WP releases but something has to be done for us common WP affectionados that just want an outstanding Internet presence with our message.

      SO, please keep us in mind and make it easier and less technical so I do not have to hire expensive consultants.

      Thank you

    • Bryan Petty 5:47 pm on January 3, 2014 Permalink | Log in to Reply

      There was still some hesitation about making this move just yet until source maps were more widely available to use. We’re using grunt-sass now, and libsass only just recently merged in adequate support for sourcemaps, meaning it might still be a bit of time before it makes it into a stable release of grunt-sass. Not long mind you, likely just one more release cycle for WP.

      I’d say go ahead and start testing out your approach and coming up with your plan of attack, but I wouldn’t plan on it being merged in 3.9. There’s no need to rush everything.

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

        Where did you see concerns about concatenation and source maps?

      • Aaron Jorbin 5:58 pm on January 3, 2014 Permalink | Log in to Reply

        I don’t think source maps are a blocker to splitting up our css if you take a look at my approach. In order to make a change and test the un minified CSS, you would define script_debug to be true. From there, you would be served all the individual files (and thus have no need for a source maps).

        This is just the first step to make it so that when we decide on the next step (whether it is SASS, Autoprefixer or an entirely different approach), our code is already

        That said, we could use https://github.com/kozy4324/grunt-concat-sourcemap to generate sourcemaps. Though I’m not sure we want to ship the production version of WP with sourcemaps. We already don’t ship the ones that come with jQuery.

    • jackreichert 5:59 pm on January 3, 2014 Permalink | Log in to Reply

      On a similar note, if the CSS will be broken up, it would be nice to modularize it with OOCSS principals. Building in the back-end is somewhat frustrating since there are so many similar visual concepts being used, but not many styles that can be used across the board.

      • Aaron Jorbin 6:05 pm on January 3, 2014 Permalink | Log in to Reply

        A complete switch to something like OOCSS is out of scope for this ticket and change, but I think if we do it, moving in that direction would become much easier.

    • Dominik Schilling (ocean90) 7:19 pm on January 3, 2014 Permalink | Log in to Reply

      I’m fine with splitting this huge file up,..
      …but what are the real benefits of a interim stage – splitting one CSS into multiple CSS files – and not going directly into Sass partials? Just splitting it up because we can merge it later again doesn’t make sense for me.
      And maybe we should do a step back first and review our existing CSS rules, since there are some places with repeating style declarations. I’m sure, having multiple files with the same styles won’t make it easier.

      • Aaron Jorbin 7:56 pm on January 3, 2014 Permalink | Log in to Reply

        I think the benefits are:
        1) That it will be easier to work with, both for new and for existing developers since extremely large files are harder to work with.
        2) It will make it easier to move these into partials if we decide to go that route.
        3) Once we are in smaller files, we can look into tools such as csscss and csslint to find ways to optimize our CSS. Right now, running those tools on the single file produces so much content that it is almost impossible to be useful.

    • Bryan Petty 8:44 pm on January 3, 2014 Permalink | Log in to Reply

      I really do like this idea, and I’d love to see it happen, but feel the need to make a point about something that’s been bothering me lately since you brought this up. I can’t just create a new post, so I’m sorry I have to hijack your thread for it, even though it has nothing to do with wp-admin SASS.

      It would be nice if people had this kind of enthusiasm for basic maintenance tasks we’re way farther behind on, but made decisions on more than a year ago in some cases. For example…

      • What happened with reviewing @codebykat‘s GSoC work and finally resolving #22942 (Deprecate Post by Email)? At least it’s been in a merge-ready patch form since before the 3.8 cycle even started, and just appears to be stuck in the punt-cycle now. Kat dedicated months of (blessed) full-time work, and did an amazing and job on this, and it’s just being wasted now.
      • How about actually removing the link manager (#21307)? It’s been disabled by default since 3.5, and there used to be a progressive plan for having it completely removed and added to the official plugin replacement by 3.7 or 3.8 (and I’d link to that plan, but it’s buried deep in the recesses of IRC logs somewhere in a meeting I can’t find if my life depended on it). @wonderboymusic even had a full patch with a first pass ready for review 17 months ago too. But now that first step that was supposed to happen in 3.6 still hasn’t happened and everyone still just wants to talk about new features in 3.9 instead. Now that it’s disabled, no-one cares, but in case anyone hadn’t noticed, we’re still maintaining code and fixing bugs in the link manager.

      One of my complaints with these types of posts is that even though you did write a patch and created a Trac ticket for this, you haven’t even given it more than a couple weeks to soak before spamming everyone with it on the core P2, something most patch authors don’t have the ability to do. You’re dictating what tickets you think deserve the extra attention and should be a higher priority by announcing it here (and surprise, it just happens to be your own), all while tickets like the ones I mentioned above have been entirely neglected, and honestly, wp-admin SASS was going to get that attention regardless. It didn’t need this post for that to happen.

      Trac is literally a graveyard where patches go to die, and not because they’re bad patches. It’s because no-one will even spend the time to review them, let alone improve, and follow through with them. One of the reasons I’m convinced this happens is because everyone keeps getting distracted by whatever new shiny and exciting feature is being proposed on the P2 here. Why do you suppose you felt the need to repeat everything you covered in the Trac ticket here otherwise? It’s posts like this that are just discouraging anyone from actually taking the time to follow the activity and discussion on Trac itself rather than here. Everyone now feels like they can just post comments here instead, and they do as evidence of the 4 people already discussing it here without anything posted to the ticket still. Ideally, we shouldn’t even need a post here just for a Trac ticket to get some attention.

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

        Let’s not hijack threads. If you want to have a conversation about this, feel free to bring it up in IRC. I’m always happy to talk.

        Jorbin made this post because to move this forward, it requires a discussion and decision about modernizing our development tools and workflows. That’s a very good use of make/core and it is something we’ve used make/core for for the past six months consistently. In these situations, Trac is more about proof-of-concept and later final implementation, not the higher-level discussion of which direction we want to take things, which touches on the needs and wants of designers and developers, tactics for deployment and testing, how it will impact contributions (methods and barriers), etc etc. Incidentally, Jorbin was also pointed here independently by me, Helen, and Koop, three people who have authored previous development workflow posts.

        Jorbin has been focusing on JavaScript tools and testing for some time now, so his time/focus/energy spent on this has little to nothing to do with any of the other tickets you bring up, and isn’t slowing down anything else.

        The Link Manager is still used by potentially millions of users and I don’t think we’ve spent more than a few commits maintaining it going back two or three years. If we’re going to remove it, we’re probably going to need to install and activate the replacement plugin on upgrade, which is not something we’ve done before and isn’t a fun thought. Post by Email probably requires the same thing. These things aren’t being neglected — 90% of it is done (Link Manager is off by default and there’s a new, better Post by Email plugin out there). It’s the final 10% aren’t priorities because we’re a little trigger-shy about the repercussions of ripping them out.

        In terms of Trac being a graveyard: Sergey made 5,022 comments to Trac in 2013. You made 184. Be the change you wish to see.

        • Bryan Petty 12:32 am on January 4, 2014 Permalink | Log in to Reply

          You know this isn’t the type of discussion that you can just casually knock out over IRC, and that asking me to attempt it is really just the same as asking me to shut up and go away. If that’s the way you feel, just say it. You’re telling me I can’t discuss how I feel about posts like this (on the post itself), but wonder why I don’t leave comments more often. Please don’t condense my project involvement down to comment count, against someone no-one else has ever been able to keep up with, who’s also had commit access for the last year. I wasn’t writing a personal attack against Jorbin.

          We already knew this was going to happen, and built the infrastructure to do it during the 3.8 cycle, there’s nothing left in terms of “modernizing dev tools and workflows” or deciding on any direction it needs to take anymore. We discussed, decided, and implemented all of that entirely already. All that’s left is how the admin SASS is going to be organized, who’s going to do it, and when (not if, and not how). That can all be done on the ticket, and if it can’t, the least Jorbin can do is let the ticket sit for as long as everyone else has to wait for their patches to be reviewed to find out before deciding it was time to escalate it here to pull in more help. Maybe it would be relevant for the P2 if it was about discussing SASS coding conventions going forward, but Jorbin didn’t even mention that.

          Regarding post by email and link manager, I’m fully aware of the implications of the decision to install and activate a replacement plugin on upgrade, and so was everyone else when it was decided that we would still do it before @codebykat‘s project was ever approved. Why would we even bother letting her spend months of work on it if we knew it was never going to be used anyway, especially as opposed to making room for another student with a project we could use? Are you saying her project was completely pointless after all now? Maybe you should tell her that, she’s just been sitting there waiting for a review on the Trac ticket, and no-one has told her otherwise, or explained why it keeps getting punted, so she’s still spending the time refreshing her patch as usual – expecting it to be applied anytime now.

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

        Some of this is a red herring. The people who would work on the aforementioned tickets/issues are by and large not the same people who would be involved in this kind of initiative. I agree in some ways about splintering discussions and who can initiate a P2 post vs. a Trac ticket vs. a mailing list discussion, but I disagree that this was going to get attention no matter what.

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

      During today’s dev chat, the decision to do this was made. After 3.8.1 I will be updating the patch and coordinating with Helen to get it committed.

      Thanks everyone for your comments and feedback!

      Chat – https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2014-01-08&sort=asc#m767547

  • Aaron Jorbin 9:10 pm on September 13, 2013 Permalink
    Tags: ,   

    JavaScript Unit Tests for Core 

    Recently WordPress added QUnit as a JavaScript unit testing framework and added its first JavaScript unit tests. I thought I would walk through how to run the tests and how to write tests so that we can increase our JavaScript test coverage. All of these are based upon using the develop.svn.wordpress.org checkout which is where the JS unit tests live.
    (More …)

    • Ryan McCue 1:37 am on September 14, 2013 Permalink | Log in to Reply

      For anyone who’s wondering what the hell is going on on Windows: You have to run grunt via the Windows command line, and you cannot run it via Cygwin. If you do run it via Cygwin, you’ll see random inexplicable errors and missing output. It’s pretty annoying (in fact, it stops me from using Grunt), but you can’t really do anything about it.

    • adamsilverstein 6:17 pm on September 14, 2013 Permalink | Log in to Reply

      Great post, thanks for keeping this moving!

    • K.Adam White 5:50 pm on September 16, 2013 Permalink | Log in to Reply

      For those on Windows, the “msys” shell that installs as “Git Bash” when you download the official Windows build of Git should work fine once you install the Windows build of Node.

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
Skip to toolbar