WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Updates from Andrew Nacin Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Nacin 5:24 am on March 27, 2014 Permalink
    Tags: , , ,   

    TinyMCE 4.0 requires text/css for editor style files 

    As of TinyMCE 4.0, the visual editor iframe now has an HTML5 document type (<!DOCTYPE html>). In this scenario, CSS files must be served with the text/css content type. A server will serve a *.css file with the proper content type, but if you’re using a PHP file for an editor style file, you need to be the one to do it. It’s as simple as leading with:

    <?php
    header( 'Content-Type: text/css; charset=UTF-8' );
    

    So if you’re doing something particularly crazy with the editor and your styles aren’t loading in WordPress 3.9, you may just need a content type. Also, Chrome (and probably other browsers) throw a console warning when this happens.

    (via #27288)

     
  • Andrew Nacin 5:08 pm on March 12, 2014 Permalink
    Tags:   

    As a reminder, the weekly meeting continues to be at 21:00 UTC.

    Daylight Saving Time has started in the U.S., which means the meeting is at 5 p.m. Eastern time, 2 p.m. Pacific. We will revert to 20:00 UTC on April 2, after Europe enters Daylight Saving Time.

    Our agenda for today will be to go over all 3.9 tasks and get an idea where we need the most resources, to ensure we are in a good position to close out the beta period in less than three weeks.

     
    • Robert Chapin 6:06 pm on March 12, 2014 Permalink | Log in to Reply

      It looks like I can join at least the first half of the meeting. There have been several iterations of the patch for #22692. It should be a comprehensive fix at this point. It will adjust quotes, smilies, and shortcodes so that their behaviors are normal in the presence of NBSP chars and entities. It also paves the way for refreshing patches in #26842, #8775, #20342, #23185, and many others. We could potentially clear out half of the wptexturize tickets if this gets the attention it deserves.

  • Andrew Nacin 6:00 pm on March 3, 2014 Permalink  

    Daily ticket triage meetings at 1900 UTC this week 

    To help realize the goal of a WordPress 3.9 Beta 1 by week’s end, let’s have daily ticket triage sessions in IRC at 1900 UTC, or 2 p.m. U.S. Eastern time. (This is two hours before our usual weekly meeting.) If you’re able to join, see you in #wordpress-dev in one hour.

    We have 99 enhancement tickets open. They either need to be closed or moved out of 3.9 by the end of the week. Just 20 per day will empty that report.

    Of course, a number of us will be in IRC outside of these times as well, working on the same goal.

     
    • Robert Chapin 3:43 pm on March 4, 2014 Permalink | Log in to Reply

      Can we expect some attention on the early tickets?

    • KirkM 4:28 pm on March 6, 2014 Permalink | Log in to Reply

      Andrew – There appears to be a rather serious problem for theme authors who use the “mce-css”filter” to style TinyMCE using a .php file instead of a .css file. This filter was present in WordPress 3.8.1 as well as previous versions. Unfortunately, the “mce_css” filter has gone missing in builds of WordPress 3.9.

      A ticket has been submitted about this:

      https://core.trac.wordpress.org/ticket/27288

      Just FYI

  • Andrew Nacin 11:29 pm on February 20, 2014 Permalink  

    Friday Trac Sprint 

    I mentioned this in the dev chat on Wednesday: Join us tomorrow (Friday, February 21) for a sprint through Trac tickets that need a reply!

    A few weeks ago I said one goal of mine for the 3.9 cycle was to make contributing easier and more accessible. That’s why so much work has gone into improving our tools in the last few months. One task is to empty one particular report of tickets: tickets that need a response. After that, I’d like to keep it empty.

    As of this writing, there are 386 tickets on this report. (The report shows 441, as that includes another 55 opened by a committer.) Help us empty this report!

    To best coordinate a few dozen people all trying to comment on a few hundred tickets, please join us in #wordpress-dev in IRC. We’ll break these tickets into chunks, such as by age, component, or focus.

    We’ll have people in IRC all day to help you out if you haven’t triaged tickets or given feedback before. There is a whole set of guidelines in the comments below@SergeyBiryukov and @ocean90 will be around for morning in Europe, and I’ll be around starting at around 9 a.m. U.S. Eastern.

     
    • Andrew Nacin 7:53 am on February 21, 2014 Permalink | Log in to Reply

      The main goals here are to make sure that tickets and patches have received some form of initial feedback. That’s just the first step in a long process, of course, but it’s an important one. If you’re new to this, here’s some tips on how you might approach and handle a ticket:

      When giving feedback for a ticket:

      • Thank the individual for the report. Some of these tickets are quite old; for those, a simple “Thanks for the report nacin. Sorry you never got a response.” is fine.
      • If this was one of the reporter’s first tickets, it will tell you above the comment box. Be nice. :-)
      • If it’s a support request, you can refer them to the WordPress.org support forums and close the ticket as “invalid”.
      • If it’s a bug report that sounds like an enhancement, then change the ticket to an enhancement. Enhancements are a bit more difficult to triage (as the feedback is more subjective), so it’s much easier to start with bugs.
      • Consider a quick search to see if it is a duplicate of another ticket that may be farther along.
      • If there’s a component that is more appropriate for the ticket, feel free to move it.

      If it’s a bug report:

      • See if you can still reproduce it in trunk. (And/or try 3.8.1.) Some bug reports may have been invalid to begin with; others might have been fixed already.
      • If when reproducing it, you feel you can elaborate on the issue, or write clearer steps to reproduce, please do so.
      • If you can’t reproduce it, ask the reporter for more information and add the “reporter-feedback” keyword. If you think the ticket should be closed, you can mark it with the “close” keyword. (There doesn’t need to be a rush to close the ticket.)

      If it has a patch:

      • Test it out — does it fix the problem? How did you test it? Did you notice any side effects?
      • If the patch doesn’t apply cleanly (as in, it fails when you try), add the “needs-refresh” keyword.
      • If you’re a developer, consider doing even just a cursory code review.
      • If the “has-patch” workflow keyword is missing, add it. Or, if after review you don’t find the patch to be sufficient, you can set it to “needs-patch” instead.
      • If you feel the patch is ready to be reviewed by a core developer to be considered for inclusion in WordPress, simply say so.

      It might take only a few minutes to triage some of the more straightforward tickets, especially once you get the hang of it. You could easily spend twenty or thirty minutes on others, or even longer if there’s a lot to test or if you have a lot of feedback to give. Take your time; the post calls this a “sprint” but it’s not a race!

      If you come across a ticket you like and want to write a patch for it, that’s great! Feel free to leave feedback on the ticket and start working on a patch. If you end up working on just that for today, that’s totally fine — there are a lot of others working through this list of tickets, too. Triaging can be a great way to find tickets that interest you.

      A number of us will be in #wordpress-dev to help you out. So people don’t overlap, we’ll try to point you to a particular collection of tickets, based on your interests. If you’re unsure what to do for a particular ticket, feel free to move on. Or even better: Ask in IRC and we can talk through it.

      (If you are craving even more detail on triaging tickets, the contributor handbook has a whole page on bug gardening.)

  • Andrew Nacin 8:15 am on February 12, 2014 Permalink
    Tags:   

    Please suggest agenda items for the February 12 developer meeting.

    Aside from usual 3.9 stuff, we’re going to be using part of this meeting for brainstorming for GSoC.

    Here’s the agenda thread and meeting notes from last week, as a point of reference.

     
    • Jen Mylo 8:21 am on February 12, 2014 Permalink | Log in to Reply

      If people want to write up their ideas for GSoC projects in advance, that would be great in terms of keeping things going. I’ll be submitting our GSoC application immediately following the dev chat, so if anyone has ideas but won’t be at the meeting, go ahead and post them at http://codex.wordpress.org/GSoC2014. Thanks!

    • Rami Yushuvaev 12:20 pm on February 12, 2014 Permalink | Log in to Reply

      How about a “Road Map” for upgrading the minimum requirements to PHP 5.4 and MySQL 5.5 (or any other version you choose). The purpose of the roadmap is to set a time frame, not choosing technology.

      The roadmap should be spread over a long period of time (let’s say 2 years from now), enough time for web hosts to make the proper adjustments. WordPress has three major version per year, this means WordPress 4.4 will require the new minimum requirements.

      The road map will not be a binding, meaning that if core developers will decide to upgrade the minimum requirements in wp4.6 or wp4.8 the road map can be changed. BUT, setting a time table is important, for plugin developers, web hosts, and core developers. It allows everyone the get ready for the upcoming change.

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

        It’s been mentioned many times that we should not become “a protest piece at the expense of our users”, and this is specifically mentioned in regards to setting hard deadlines for bumping minimum server requirements. We cater to our users, not dictate what they need by abandoning millions of users at arbitrary points, especially if they still account for more than 10% of WP installations.

        We still haven’t dropped PHP 5.2 support, and given the rate of use shown in the stats, that still isn’t happening for another couple years. Dropping 5.3 is probably more than 5 or 6 years down the road, and isn’t even worth thinking about right now.

        When the time comes, you can be assured there will be plenty of notice, but it won’t even be necessary for most since it will only apply to less than 10% of users.

    • Dominik Schilling (ocean90) 3:11 pm on February 12, 2014 Permalink | Log in to Reply

      State of #27078 (Autoprefixer), #26669 (wp-admin.css split) and #26799 (Backbone update).

    • Daniel Bachhuber 3:29 pm on February 12, 2014 Permalink | Log in to Reply

      I’d like to discuss #316 if it’s not too big of a conversation.

    • Tom Auger 4:47 pm on February 12, 2014 Permalink | Log in to Reply

      Let’s talk about all the great things that are happening with the Image Editor and Media Modal. I’m seeing the following tickets which are all tangential to each other: #24409 (which is awesome), #26672, #24567, #18947, #26870 (thank the gods), #21811 (which has turned into a much bigger deal than I thought) and #21810 (which seems to be a refresh of #19889).

      This all seems like “a thing”. @wonderboymusic, @gcorne and others seem to have things well in hand, but I’d like to see a little more sharing around all the great things that are going on, and where help / discussion / review is needed.

    • Aaron Jorbin 8:54 pm on February 12, 2014 Permalink | Log in to Reply

      I’d love to find out if anyone else has comments on #27023 and if people think grunt-patch is ready for me to tag it in npm and for us to add it.

    • Andrew Nacin 8:56 pm on February 12, 2014 Permalink | Log in to Reply

      Agenda:

      • CSS/JS: Autoprefixer #27078, wp-admin.css #26669, Backbone update #26799
      • 3.9 status reports for teams/projects/tasks
      • Widgets Customizer merge: old style widgets + options API issue (details in the meeting)
      • Any other logjams or stuck situations we need to address
      • GSoC brainstorming

      We can hopefully get through all but the last point pretty quickly.

  • Andrew Nacin 3:06 pm on February 6, 2014 Permalink
    Tags:   

    Here’s a quick summary of yesterday’s meeting (IRC log), as a status report on WordPress 3.9:

    Beta 1 will now be the week of March 3, a week later. The rest of the schedule is unchanged. I felt the extra week of alpha would be helpful given all of forward momentum right now, and others seemed to agree.

    It was decided to green-light the widget customizer plugin for merge. If all goes well, it’ll be in 3.9 final. There’s still a lot to do: some UI polishing, deeper code review, etc. — and surely it will get a lot of testing.

    Quick hits raised in the meeting:

    • Settings review is in the ideas/sketch/wireframe stage. They have a meeting today. (@jenmylo, @melchoyce)
    • Lots of audio/video changes landed. Needs review on #27026 and UI feedback on #26631. (@wonderboymusic)
    • Work continues bringing the image editor into the media manager. #21811. (@gcorne, @tomauger)
    • TinyMCE/editor: modals are getting redesigned. #26952. (@melchoyce, @avryl) QUnit tests are being added. #27014. (@azaozz) @gcorne also sunk some time into MCE views, for gallery rendering.
    • THX plugin is being revived to take a crack at the theme install screen. If it works out, these patches could land in 3.9. (@matveb)
    • A Grunt patch tool needs testing. #27023. (@jorbin)
    • Some refactoring of the multisite bootstrap will begin this week. #27003. (@jeremyfelt)
    • Volunteer(s) wanted: If anyone wants to work on expanding autocomplete in core, there is some work in that area to be done. @helen will help shepherd.

    We have a few more weeks of alpha, so it’s a great time to help with writing or testing a patch for WordPress 3.9. We’ll be keeping the tempo quick. Expect lots of changes.

     
    • helgatheviking 2:58 pm on February 8, 2014 Permalink | Log in to Reply

      Is there any chance 3.9 will tackle the issues with nav-menus.php saving a lot of data? Apparently this is the reason for the hold up on adding action hooks to the admin menu UI (for adding additional meta to the menu items), which is a feature that has been requested (at least 4 duplicates that I can find) a few times. Plugins and themes that are replacing the custom Walker with their own would finally be able to work together.

  • Andrew Nacin 8:44 pm on February 5, 2014 Permalink
    Tags: ,   

    Fine-grained Trac notifications 

    Some housekeeping items to share so I don’t need to cover it in the meeting today:

    New notification preferences are live. On the notifications page, you’ll be able to subscribe to activity from all tickets in a particular milestone, component, or focus. You can also subscribe to only new tickets, in case you want to then selectively watch tickets as they come in.

    New greeting on make/core. Look up. Or if you’re viewing this post directly, check out the homepage. Right now the “Get Involved” menu item leads you to there, but it’d been tough to know where to go from there. This serves to introduce new people and get them information quickly: what this blog is, where to file a bug, how to start contributing; and provides some info about IRC and our meetings.

    New, simpler new ticket form: I simplified the new ticket form, cleaning up the warnings, text, and chrome (it had a lot of borders and fieldsets and such). It looks much less intimidating now.

    New ticket reports and component pages. These went live late last week — here and here.

    Create a new ticket This was also helpful because we shifted around where you can go to create a new ticket. You can now do it from search results, all ticket reports and the main reports screen, component pages, the icon in the navigation, and now from the make/core homepage. The new reports screen is a new entry point for Trac. You’ll note it actually duplicates the content of Trac’s home page (new ticket button there too), which you’ll have trouble finding a direct link to anywhere.

    Focuses/components: Component and focus triaging is pretty much done. (More than one thousand open tickets — 30% — have been modified in the last two weeks alone.) Still have some decisions to make about the Administration component, but I’m not worried.

    And with that, I actually have no more changes planned for core trac. Except for ticket smashing. It’s now time to start clearing these two reports: Tickets without a response and Tickets that are ancient and inactive. Who is with me?!

    Thanks also @ocean90 for replacing every last icon in Trac with a Dashicon. Love it.

     
  • Andrew Nacin 3:26 am on February 5, 2014 Permalink
    Tags: ,   

    Please suggest agenda items for the weekly developer meeting, Wednesday, February 5, 21:00 UTC.

    If there’s a task or ticket we need to work through, or need volunteers for, let’s get those spelled out now. Maybe we can even work through some of them pre-meeting.

    I’ll again be asking for a sentence or two (or more, if necessary of course) from each person/team working on a 3.9 task. You can also post those here if you’d like — please cross-reference any relevant tickets or discussions. Worked out great last week. For the state of things as of last week, see Mike’s weekly roundup.

     
    • Pippin Williamson 4:05 am on February 5, 2014 Permalink | Log in to Reply

      Not sure if there’s much discussion needed on them, but I’d love to see the remove/has_image_size() tickets shored up:

      https://core.trac.wordpress.org/ticket/26768
      https://core.trac.wordpress.org/ticket/26951

    • Jeremy Felt 4:19 am on February 5, 2014 Permalink | Log in to Reply

      I’d like to chat a bit about the direction of domain routing. I’ll be around pre-meeting as well.

      I opened #27003 last night with a patch that introduces `wp_get_network()` as a way to retrieve a network by it’s domain and path. This isn’t an absolutely necessary abstraction from `wpmu_current_site()`, but it does remove the functionality away from the `$current_site` global and focuses on retrieving just the requested information. In the process, `wpmu_current_site()` gets cleaned up quite a bit. It should be pretty straight forward to write unit tests that cover `wp_get_network()`.

      IMO, this is a first step toward cleaning up a bit of the load process. If we’re good with this direction, the next step will be to do the same thing for site discovery ($wpdb->blogs). I have more notes written up here on the multisite load process in general for anyone that wants an overview of how things are working.

    • Pippin Williamson 5:17 am on February 5, 2014 Permalink | Log in to Reply

      I’ll throw out another one. I’d LOVE to see further discussion on better custom comment types, per https://core.trac.wordpress.org/ticket/12668

    • Weston Ruter 8:14 am on February 5, 2014 Permalink | Log in to Reply

      There was a really good discussion today on #wordpress-dev regarding feedback for Widget Customizer. So I think we have a path forward for important issues to address. I’ve created a milestone on GitHub to track these issues: https://github.com/x-team/wp-widget-customizer/issues?milestone=4&state=open

    • Robert Chapin 11:27 am on February 5, 2014 Permalink | Log in to Reply

      3.9-early tickets, please

    • Manuel Schmalstieg 12:49 pm on February 5, 2014 Permalink | Log in to Reply

      For international users, improving the handling of accents/diacritics in file attachments would be a big win: https://core.trac.wordpress.org/ticket/22363 – the ticket has patches, and @markoheijnen has proposed it for 3.9 …

    • Tom Auger 7:59 pm on February 5, 2014 Permalink | Log in to Reply

      I’d like to discuss https://core.trac.wordpress.org/ticket/21811 and see if my patch / suggestions are salvageable, given the much bigger development effort around the entire Media Modal. The feature I was working on (prior to the whole Media Modal overhaul) was a very small, targeted, incremental enhancement that was kinda “shoehorned” in under that trac ticket, but really addresses something different and much smaller in scope.

    • Tom Auger 8:37 pm on February 5, 2014 Permalink | Log in to Reply

      Update: I see @gcorne has done some great work demonstrating how this could get integrated into Media Modal. I’ll continue this week and see if I can bring these things together. As for today’s meeting – we just got massively dumped on in Toronto, so I’ma head out of the office now and may not get back online in time to catch this week’s meeting.

  • Andrew Nacin 12:13 pm on January 29, 2014 Permalink
    Tags: ,   

    Please propose agenda items for the development meeting today at 21:00 UTC. Let’s try to keep it to under an hour, like last week’s.

    Some to start us off:

    • Consider the Widgets Customizer plugin for 3.9 merge. If you haven’t looked at it yet, please spend some time today before the meeting. Obviously, we all like the idea, but we need to study the implementation and provide feedback. Please comment on that post if you haven’t already.
    • I’d like to propose an initiative for cleaning up a group of 556 tickets during the 3.9 cycle. (It has details, will explain in the meeting.)
    • Quick situation reports for various 3.9 tasks. If you’re working on something, please come armed with a sentence so we can do these rapid-fire — or post it in the comments thread. Some things are moving forward quickly, some aren’t. Where can we help? Here’s a list of what was proposed for 3.9 (see also the comments, which were updated after the last meeting). We need to take the “proposed” label off soon…
    • I’d like to get moving on the Trac component re-organization; I’ll see if there are any questions. We will need some help to move around tickets (ideally adding feedback to them along the way), so I’ll be looking for volunteers and talking about what is needed.

    Aren’t familiar with how these meetings work? They’re especially good for breaking logjams — whether that means talking through a major sticking point, finding volunteers to help with something. We also use them to plan out schedules and tasks, make sure everyone is on the same page, and do release post-mortems to see how things went. (As 3.8.1 was released on Thursday, could be good to discuss this and 3.8.2, for example.)

    The meeting takes place in IRC on chat.freenode.net in the #wordpress-dev channel. See you then!

     
    • William Bowles 12:27 pm on January 29, 2014 Permalink | Log in to Reply

      I like it! One of the problems with WP has always been the amount of time spent moving between the various components that make up the site. I’d like to see a lot of the backend stuff move to the Customize sidebar and the popout access to other widget tools seems to work perfectly.

    • Tom Auger 2:06 pm on January 29, 2014 Permalink | Log in to Reply

      I have moved forward with https://core.trac.wordpress.org/ticket/21811. Still trying the time to upload an actual patch, but could use some eyes on the last two plugin ZIPs that were uploaded to see whether there’s any buy-in on my proof-of-concept approach to modularizing the Image Editor.

    • Tom Lynch 2:43 pm on January 29, 2014 Permalink | Log in to Reply

      I’d suggest considering talk around some of the older parts of wp-admin that have static coded HTML tables that don’t have any hooks or filters, nor use the Settings API to actually make it possible for people to develop management plugins.

    • John Blackbourn 3:11 pm on January 29, 2014 Permalink | Log in to Reply

      We should have a think about how we can start to build this new “easy first bug” report on Trac.

    • Jen Mylo 3:28 pm on January 29, 2014 Permalink | Log in to Reply

      GSoC 2014. I’ll post about it on this blog before the meeting, but would like to take a few minutes during the chat to discuss areas of interest for projects and people who’d be interested in mentoring/co-mentoring so I can get the application started.

    • Andrew Ozz 4:16 pm on January 29, 2014 Permalink | Log in to Reply

      Decide on JavaScript actions and filters, https://core.trac.wordpress.org/ticket/21170. We need JS hooks in core, either our own implementation or standardize on jQuery( document ).trigger( 'event-name' ). I know @koop had more thoughts on this but he hasn’t been around for a while.

    • tomdryan 4:17 pm on January 29, 2014 Permalink | Log in to Reply

      I may not be able to make it today, but I would like to propose creating a new task force that can look at existing plugins that would be good candidates to get moved into core. Most of the core efforts appear to be in developing new functionality, which is critical, but there are existing plugins that also fix gaps in the core feature set. The goal would be to identify those plugins and approach the authors to see what there interest level is in contributing their code to core. This approach unitizes WP excellent plug in architecture and plug in community to move WP core forward more rapidly.

      I love to hear comments about this idea (post here). I’ll try to make it to today’s meeting, but if not, I love to talk about this subject in the near future.

    • Bryan Petty 6:07 pm on January 29, 2014 Permalink | Log in to Reply

      I have an upstream update to PHPMailer in #25560. There are a couple decisions that still need to be made: include the full library, or strip it down without docs, tests, and examples (both patches are there), and a quick review of the approach on back-compat. This does need to in early in the cycle though, so about now is a good time, and hence why I bring it up now.

  • Andrew Nacin 9:01 pm on January 27, 2014 Permalink
    Tags: ,   

    Proposed Trac component reorganization 

    Warning, this long. tl;dr: I propose a reorganization of our Trac components. 34 top-level components with two dozen subcomponents. New tree at the bottom. First, an overview of some of our problems.
    (More …)

     
    • Helen Hou-Sandi 9:22 pm on January 27, 2014 Permalink | Log in to Reply

      I am particularly excited about how groups and maintainers will (hopefully) form around components and focuses. Anybody can comment on a Trac ticket or pitch an idea or create a potential roadmap, but there’s a real sense of empowerment when you really feel like you’ve got your head and hands wrapped around a specific area, and are perhaps even recognized for doing so.

      I know for me personally it’s been really gratifying to be entrusted to run with a particular area (what we can now define as the UI focus) and has made me feel more comfortable with interacting and pushing core forward. And not just when it comes to UI development and conception, but in other areas as well. I also might just dare hope that we can stop the worst of the ticket rot, with having both more bodies as well as a clearer idea for hopeful contributors as to where to go for more feedback or help.

    • nofearinc 9:23 pm on January 27, 2014 Permalink | Log in to Reply

      I’m curious about the Query branches of Comments and Users – too many tickets for these types of Queries or plans to extend a lot furthermore?

      Great list though, and the “hall of fame” with notes is awesome.

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

        I don’t think either is necessarily the case. The idea was to create a specific subcomponent under Users that those focused on Query (in general) could also specifically follow. Same for Comments. So in this case, it’s about granularity, not necessarily roadmap or ticket counts. Query is goofy, as I mentioned in the post — it’s a cross-section that would normally be good as a focus, but it actually covers functional areas of core (there just happen to be a lot of areas).

    • StyledThemes 9:24 pm on January 27, 2014 Permalink | Log in to Reply

      Give me a BIG Pot of coffee and I will ready this shortly…however, I saw the part of Bootstrap which caught my eye as I build my themes with it (well, parts of it). But from what I see in the list, looks interesting overall.

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

        Bootstrap is not Twitter Bootstrap, it’s the “loading” process of WordPress. I may rename this to Bootstrapping if it’s a problem.

        • StyledThemes 9:34 pm on January 27, 2014 Permalink | Log in to Reply

          ah… how about WordStrap :)

        • nofearinc 9:37 pm on January 27, 2014 Permalink | Log in to Reply

          That’s the initial association of many folks btw, even knowing what Bootstrapping is, the recent popularity of the Twitter’s thing is overlapping actively, just my 2¢

        • jack96161 10:26 pm on January 27, 2014 Permalink | Log in to Reply

          Agreed, Twitter commandeered “Bootstrap” for too many in the community these days — greybeards like me know what a real bootstrap is, but renaming it will eliminate more questions like this in the future. I always liked the “Progenitor Process”, we used in an early operating system at HP, but it will probably end up as something like “startup”, “init”, or other bland 2-syllable invention …

          • jack96161 10:34 pm on January 27, 2014 Permalink | Log in to Reply

            Just noticed on the 3.9 Trac pages that “Bootstrap/Load” is used as a component name — I’ll vote for that one and the Twitterites can just deal with it!

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

      One additional focus that may make sense is Unit-Tests. The use case I’m thinking of is a patch that just adds unit tests. It would go in the component that it most directly deals with as I think the test tools component is more focused on the tools of testing rather than the actual tests and receive the focus of Unit-Tests (and optionally the JavaScript focus if it is a javascript unit test)

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

        Ah, yeah, I forgot to mention this. This is also on my list. I’m still trying to figure out how it overlaps with keywords (needs-unit-tests and has-unit-tests), so I saved it for later. Does needs-unit-tests and has-unit-tests simply trigger the unit-tests focus automatically? If a ticket is opened specifically to provide unit tests for something, is that more of a has-patch situation? etc.

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

          I think needs-unit-tests and has-unit-tests should trigger the unit tests focus.

          Has-patch makes sense in the just adding unit tests case since it is fixing the reported issue (not having unit tests) while I think needs-unit-tests and has-unit-tests is more workflow oriented.

    • Jon Brown 12:15 am on January 28, 2014 Permalink | Log in to Reply

      This looks great. You’ve done a great job of making the parents obvious (fwiw, I’d keep bootstrap as bootstrap).

      Two things seemed non-obvious to me, and maybe that’s just unfamiliarity on my part, but worth mentioning.
      First – Formatting-Shortcodes/Charset. This seems non-obvious to me but I’m guessing this is processing raw content, essentially wpautop, it’s brethren and associated filters. Formatting sounds more like CSS to me than filtering/processing content.
      Second – There are separate top level categories for HTTP API & XML-RPC. It seems to me this could be a single top level “Remote/External APIs” component with sub-components for HTTP, XML-RPC, JSON, etc… Maybe that’s makes no sense though though since code wise they’re entirely separate.

      Again, great work sifting all this into these components, these are just comments as I read through and understand what’s group where, why and what each component covers.

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

        Formatting has been called Formatting, well, for as long as I’ve been around. It also centers around formatting.php. It might not be the best name, but yeah, it’s for processing raw content. We’ll make sure the description and search keywords for it are solid.

        For right now, HTTP and XML-RPC have pretty much zero overlap in form or function. We’ll need to revisit everything here anyway when the REST API comes into core. (Gut reaction would be a component for the server, and a focus to handle APIs specific to another component.)

    • Robert Dall 12:30 am on January 28, 2014 Permalink | Log in to Reply

      I am not sure if we want to confuse the themes & bundled theme anymore then they already are. When I gave a talk on trac and I explained why it is called bundled themes a couple light bulbs went off in the crowd. But yet they knew what default themes meant. It’s all semantics, but now that understand why themes and bundled themes are different.

      What I *REALLY* like is having a subcomponent for each theme in development. We could still use use the title to differentiate between Twenty-Thirteen and Twenty-Fourteen as is the current standard but having this and the easy of use sounds whole lot better and easier for query’s of trac etc…

      • Andrew Nacin 1:12 am on January 28, 2014 Permalink | Log in to Reply

        I’ve got no issue renaming Bundled Theme to Default Themes, and we can definitely nest individual components underneath it for each theme. The issue I see would be that if we added subcomponents for each default theme directly under the Themes component, where would a ticket go that affects more than one theme? (This isn’t entirely uncommon.)

        • Sam Sidler 4:19 pm on January 28, 2014 Permalink | Log in to Reply

          In the main Bundled/Default Theme component? I assume the components are still usable even when subcomponents exist.

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

            Sorry, I should have been more specific. Option 1, which is totally fine;

            Default Themes

            • Twenty Ten
            • Twenty Eleven

            Option 2, which I’d prefer (and which I thought RDall was hinting at):

            Themes

            • Appearance
            • Widgets
            • Nav Menus
            • Twenty Ten
            • Twenty Eleven

            My point was I’d like to merge “Bundled Theme” (or “Default Themes” or whatever) with “Themes” to make it even less confusing. But then I’m not sure where general default theme tickets (affecting multiple themes) would go — getting dumped in “Themes” means they may get lost.

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

          Does it need a subcomponent if it effects all themes? Or are subcomponents required when they exist?

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