Make WordPress Core

Tagged: 3.4 Toggle Comment Threads | Keyboard Shortcuts

  • Jen 10:45 pm on June 10, 2012 Permalink
    Tags: 3.4, ,   

    Updated Credits 

    Each release cycle, we try to recognize those core contributors who’ve made the greatest impact, ramped up the quickest, and/or been the most reliable.

    In the Contributing Developers category, mainstays Sergey Biryukov, Dominik Schilling (Ocean90), and Cristi Burcă (Scribu) are joined by Aaron Campbell and Helen Hou-Sandi. Aaron has been contributing for several years, but his work this cycle on improvements to custom headers stood out. Helen, who was a Recent Rockstar in 3.3, stepped up with improvements to the theme screen, UI/CSS fixes, and general helpfulness as fixes of all sorts were made through the later stages of the cycle.

    The Recent Rockstars section is mainly aimed at recognizing newer contributors and/or contributors who’ve been around for awhile casually but have recently increased their involvement. In this category, Amy Hendrix worked (with Aaron Campbell) on the improvements to custom headers with great success. George Stephanis worked on css and improving the mobile experience. Stas Sușkov contributed to the thinking behind HTML captions, a feature that has been waiting patiently on Trac for years. Max Cutler and Marko Heijnen both worked on updating aspects of XML-RPC, and Kurt Payne contributed to dozens of tickets including the refactoring of admin-ajax.php.

    Thank you all for your increased efforts, and congratulations on having your picture in the credits!

  • Andrew Nacin 2:35 am on June 7, 2012 Permalink
    Tags: 3.4,   

    WordPress 3.4 Field Guide for Developers 

    WordPress 3.4 Release Candidate 2 due to drop any moment, and we’re aim to do a final release of 3.4 early next week. Developers, this is your last pre-release opportunity to test your plugins and themes.

    For 3.3, I wrote up a field guide of things developers need to know. For 3.4, I get to crowd-source it:

    Custom Headers and Backgrounds. Chip Bennett posted a great summary of the API changes on the make/themes blog. Amy Hendrix posted about flexible custom headers. If you are a theme developer, I would strongly suggest you follow the make/themes P2.

    Live Previews (The Customizer). You’ll want to read Otto’s definitive post on the subject, How to leverage the Theme Customizer in your own themes.

    New WordPress XML-RPC API. If you’re interested in the new APIs for custom content types and taxonomies, check out the Codex page, put together by Max Cutler. Max also recapped the bug fixes, test coverage, and other changes on his blog.

    Internationalization/Localization Changes. There’s a document on the translators P2 that outlines the numerous changes here.

    That’s all we have for now! If there’s something we missed that deserves a writeup for developers, leave a comment and I’d be happy to make sure it gets written up here (under the field guide tag).

  • Jen 3:57 am on June 5, 2012 Permalink
    Tags: 3.4, ,   

    What’s Your Name? 

    It’s that time in the release cycle, folks… credits! Here is a recycle of the post telling you to update your name for the credits screen. 🙂

    Did you have at least one props on a commit in 3.4? If so, you’re listed on the Credits screen in the WP dashboard.* In the listing, your name links to your wordpress.org profile. Some people are shown as their real names, while others show as their trac/.org usernames. Now, if you’re all about the alias and you go by your trac/irc handle everywhere and want to keep it that way, that’s fine. But, if you would like people (curious users, colleagues, potential clients or employers, etc) to see your real name, all you have to do is add it to your profile.

    Note 1: You may say, “But my username is my name, just without spaces and capital letters/a last name.” You’re still on the list, because it’s in username format.

    Note 2: You may say, “Yes, I would really like people who google my real name to find my WP profile, but within the community, everyone knows me as my username. Quandry!” Not really. Take a page from some of the other people in your situation and put your username in parenthesis after your last name. In the coming year we’ll be making improvements to the profiles section, and having an optional way to display your username will hopefully be added.

    Below is a list of everyone is the 3.4 credits that is listed by username rather than regular name. If you see your username on this list, click on it to go to your wordpress.org profile. Log in. Edit links will appear. Click the one in the top section that controls name and description, put your real name in the Name field, and save it. Voil , your real name will show up on the credits page.

    Billy (bananastalktome),
    Kuraishi (tenpura),
    Rami Y,
    The Z Man,

    We haven’t updated the photo sections of the credits screen yet, if you go looking.

  • Jen 8:20 pm on May 23, 2012 Permalink
    Tags: 3.4,   

    Pre-RC Dev Chat 5/23/2012 Live Blog 

    • #16079 Automatic excerpts don’t work well with Chinese txt (word counting): Nacin is handling. Westi closed for 3.4.
    • #20703 wp.getComments logs in the user (1 + #comments) times: Unit tests = fast track to commit. Ryan doing so.
    • #20699 AJAX Actions now pass the action name as an arg: reverting to 3.3 behavior, Ryan will handle it. Re-assess for 3.5.
    • #20448 Update Twenty Ten and Twenty Eleven to use 3.4 features: Koop and Nacin to review Lance’s patch.
    • #20554 3.4 Feature Pointers: Change position of the one on Headers to be side pointer. Jane talking to Ryan Ozz.
    • #19599 Localizations should not need to worry about the default secret key: Nacin’s top priority.
    • #8759 Word count function doesn’t work in several languages: Nacin is handling. Westi closed for 3.4, wants new tickets for 3.5 as needed.
    • #20737 Improve appearance of “choose from library” link for headers and backgrounds: Wait and standardize in 3.5.
    • #20507 3.4 Preview/Customize page “Return to Manage Themes” link doesn’t work as expected: Koop says nacin is handling.
    • #20600 Customize and display_header_text(): Koop will fix, patch needs some more love before committing. (Don’t we all.)
    • #20692 Handle unsaved changes in the customizer: change to button style per Jane’s comment on ticket. Helen will try patching.
    • #20736 Move customizer to wp-admin/customize.php: Nacin.
    • #20582 Theme Customizer: IE 8/9 compatibility: @ryan‘s top priority
    • #20733 Theme customizer doesn’t order sections based on order added: @dkoopersmith couldn’t reproduce, others could. Jane suggested punting, but Koop/Ocean90/Sergey looking and will fix if a simple one. Otherwise, a nicety that can wait for 3.5.
    • #20423 About WordPress page for 3.4: Closed. Reopen if any typos, credits will be updated from wordpress.org .

    Tally for remaining ticket assignments:

    • Nacin – 6
    • Koop – 3 + 2 reviews
    • Ryan – 3
    • Helen – 1
    • Ozz – 1
    • Ocean/Sergey – 1
  • Jen 5:24 pm on March 28, 2012 Permalink
    Tags: 3.4, ,   

    Dev Chat Plan 

    This week we wanted to declare beta. But things are still being committed that are not just bug fixes! And things with patches are still waiting for review! And half the core team is out of town today! What to do?!

    • Koop more or less wrapped up theme previewer last night.
    • Before we do another check on where our planned features stand, I’d like the queue of has-patch tickets to be cleared. Any/all commit-level developers in chat today should divvy up the tickets for the commit/punt roll call until there are no more patches waiting in the 3.4 milestone. Tomorrow we can do a check in of the planned features and punt the things that just didn’t make it in time despite valiant efforts. Maybe Friday we could call beta, or that could be Monday (not sure when Ryan gets back). Nacin is driving in dev chat today.
    • arena 9:03 pm on March 28, 2012 Permalink | Log in to Reply

      Dev (schit) plan
      ticket #18997 was opened 5 months ago, I posted a patch…. happy to contribute to this wonderful project called wordpress !
      And … has been arbitrarily postponed today for future release … with the following comment …

      A good idea, but too late for 3.4.

      are you looking for volonteers ?

      • Aaron D. Campbell 5:01 am on March 29, 2012 Permalink | Log in to Reply

        We’re always looking for volunteers! And we very much appreciate the feature request AND the patch. Unfortunately, in order to get versions out on time (and we’re already behind schedule on this one) we have to draw a line somewhere. Even with the patch already written, it needs to be reviewed, tested, checked for potential security issues, checked for backwards compatibility, etc.

        Additionally, this release is specifically focused on giving the site owner the ability to make their site look how they want (mostly theme enhancements). This doesn’t particularly fit with that and we need to try to stay focused so we can accomplish as much as possible. Your idea hasn’t been rejected, just postponed.

  • Jen 9:42 pm on March 21, 2012 Permalink
    Tags: 3.4, ,   

    Dev chat summary:

    • Two more days of wrap-up on features
    • Weekend review by people with commit access
    • Major puntfest begins now, things that were thisclose can be targeted for early 3.5
    • Hoping for Beta 1 next Wednesday.

    For complete transcript including team-by-team updates, see the IRC transcript.

    • Mr. Roy Arellano 10:10 pm on March 21, 2012 Permalink | Log in to Reply

      Ok, stupid question, what is the definition of “puntfest.” Absolutely have never heard the word use in over 14 years of IT experience. LOL. Sorry.

      • Jane Wells 10:31 pm on March 21, 2012 Permalink | Log in to Reply

        A fest(ival) of punt(ing) tickets that didn’t get committed in time.

        • Chris Clayton 10:45 pm on March 21, 2012 Permalink | Log in to Reply

          Roy, Punting is the term they use to basically kick (punt) the ticket to a future release. (took me a while to figure that out despite hearing the word over and over again. lol)

        • Chris Clayton 10:47 pm on March 21, 2012 Permalink | Log in to Reply

          fail. by kick, i mean drop… “drop the ticket to a future release.”… i need sleep.

        • Jane Wells 10:47 pm on March 21, 2012 Permalink | Log in to Reply

          @Chris: you were right the first time. It’s definitely a kick, not a drop.

        • Chris Clayton 10:52 pm on March 21, 2012 Permalink | Log in to Reply

          lol, got myself confused after posting the first comment “wait, is kicking, or dropping the right word”. lol Anyways, in total english for thoes still not ‘up’ with development terms (since it is confusing unless you have been around for a while) is that every ticket that is not 100% ready is being kicked out of 3.4 and into 3.5.

          • Mr. Roy Arellano 10:56 am on March 22, 2012 Permalink | Log in to Reply

            Thank you Ms. Wells and Mr. Clayton. I appreciate that. I’ve worked in IT for 14 years, to include 4 years in Software Development, 6 years in Project Management, and honestly I have never heard it used in this way, but after the explanations provided I understand. Thank you.


  • Andrew Nacin 5:25 pm on March 19, 2012 Permalink
    Tags: 3.4   

    r20212 introduced new methods for registering custom headers and custom backgrounds. Everything now wraps add_theme_support(), and the various HEADER_ and BACKGROUND_ constants are gone.

    This is ideally backwards compatible (I am cautiously optimistic), but because of the many factors at play here — child theme inheritance, constants, and theme support — it is very difficult to test.

    I am going to come up with some sort of a testing protocol in the hope that we can crowd-source testing the WP.com themes that implement custom headers or backgrounds. For now at least, if you are running a theme with custom header or background support, please test and make sure functionality did not change.

  • Andrew Nacin 8:01 pm on March 14, 2012 Permalink
    Tags: 3.4,   

    Starting next week, the dev chat is moving to 20:00 UTC to follow the schedule of daylight saving in the U.S. Since we forgot about daylight savings, and every person on the core team is either traveling or busy at some point over the next two hours, we’re going to be in a working session (see earlier post) — triaging teams, tasks, and tickets on the road to 3.4 Beta 1. See y’all in IRC.

    I’ve updated the sidebar to reflect the new time starting next week.

    • Aaron D. Campbell 5:37 pm on March 19, 2012 Permalink | Log in to Reply

      Back from vacation today and I saw this. It’s a bad time for me now (my son gets out of school right in the middle of the dev chat), but assuming it’s good for everyone else I’ll make it work.

  • Jen 6:27 pm on March 14, 2012 Permalink
    Tags: 3.4,   

    Dev chat at the usual time today, but since half the core team is at and/or on their way home from sxsw, might be more of an ‘anyone who’s around can talk bugs and progress’ than a regular meeting.

  • Jen 6:39 pm on March 7, 2012 Permalink
    Tags: 3.4, , ,   


    Normally we don’t start talking about the next release until the current one is out the door, or at least in beta/RC, so this post jumps the gun a bit, but for a good reason: the GSoC deadline. There are two approaches we could take toward our participation in GSoC this year, and one of them is tied closely to 3.5.


    • Good GSoC mentoring takes time. Time is hard to come by at the best of times, even harder for many during the summer.
    • Many of our previous GSoC mentors have held the position for several years and could use a break from trying to mentor while simultaneously working on features for a regular release.
    • Almost none of our GSoC projects have actually made it into core. A few because they were plugins, but most because once GSoC is over there hasn’t been a concerted effort to follow up on these projects.
    • We often run late on dev cycles.

    Since 3.4

    • We have ramped up several core contributors to more responsible/trusted roles as a result of the 3.4 process experiment (teams, cycles, updates, etc). This could mean more mentors.
    • We are running late in our dev cycle, and with SXSW about to eat a week, I’m thinking we’re about to get even more behind. My guess is we’re looking at a May launch, not April.
    • The stated intention of having all feature dev for the cycle tied to a central goal of making it easier to customize your site didn’t really happen. There were at least 3 teams working on features that had nothing to do with this, and another couple that were related, but not smack in the middle of it. Good features all, but we failed in sticking to that goal as a unifying concept.


    What if for 3.5, instead of it being a “regular” cycle, we made it a mentoring cycle tied to the GSoC schedule (shorter than normal)? If we assume 3.4 will launch sometime at the end of April or early May (and if it does happen earlier, awesome), that would put us in a position to start working on 3.5 right when the GSoC accepted students are announced.

    If we chose a “release concept” (like customizing your theme, but something different) and outlined every feature/enhancement/bug that’s related, we could make those things be the potential GSoC projects. We could work in teams like in 3.4, but in this case each team would have a student or two working on things with them closely. Since these would be the only features being worked on (additional bug-fixing always ongoing, obviously),

    • Students would be guaranteed mentor attention and working with core
    • We would be more likely to do the work necessary to get student work to commit-worthy status
    • We would target a launch for late August to coincide with the end of GSoC (so we could do one more small release before end of year)
    • We could do additional outreach to include new contributors who do not qualify for GSoC (too young, too old, not in college, etc), improve our mentoring skills and processes
    • At the end of this mentorship-focused summer, we would not only have the features developed by mentees, but we would have an ideal pool of people to help us create documentation to help new contributors.

    I’m thinking that what might make sense would be for there to be a team or two that doesn’t mentor or work on a feature for 3.5, but begins working on one of the more complex things we keep putting off, so that it could be the first thing into 3.6 (like gallery management or something similar).

    Deciding on a release concept that could be done in a 2.5-3 month cycle would be important. I’m thinking maybe it could be the feedback loop — improving comments and communication with readers via html emails, forms, etc on the front end and a UI facelift of the comments/related screens on the back end, putting something cool into Twenty Twelve around this (or just support for something in core related to same), etc. There are a number of projects around this that have been done in the past that could be looked to for inspiration and/or what not to do, it’s needed attention for some time, and it’s not as complicated as something like media or multisite.

    Thoughts? Specifically, thoughts on:

    • Doing a mentorship-focused release timed to GSoC
    • Potential areas of focus for 3.5 if we were to do this
    • Mentoring in teams like 3.4
    • Wanting to mentor in this case
    • How many students you think we could take on if we used teams like in 3.4

    Comment here today, and tomorrow I’l round up the core team to see what people think based on the conversation so we can make a decision and I can update our application before the application deadline if needed. If we don’t do something like this, then I’m planning on reducing our GSoC student allotment to 5-6 students (we’ve asked for up to 15 in the past) to ensure enough mentors and adequate attention/follow-up on projects.

    Thanks for your input!

    • Jane Wells 6:50 pm on March 7, 2012 Permalink | Log in to Reply

      We could theoretically extend the idea of a mentorship summer to other groups:

      • UX/UI… could help with gallery management ideas and comping/wireframing for the non-gsoc teams
      • Forums… could write up a handy guide to solving common support requests and mentor new volunteers
      • Theme Review Team ditto
      • etc etc
    • Justin Shreve 6:53 pm on March 7, 2012 Permalink | Log in to Reply

      I think it’s a great idea. I agree that one of the biggest problems of GSoC in the past has been pulling things back into core. One of the reasons like you mentioned is time and the summer ending. I also think a lot of the projects are not appropriate for core. Most are better suited for plugins/themes anyway. If we really want GSoC projects to benefit core then we should have all of the projects be core projects.

      Since this is a little different from previous years I am thinking we shouldn’t use up all 15 spots. Maybe 8-10 students. The fewer students we use, the more attention/mentors they can get. I think last years GSoC of having multiple mentors worked pretty well.

      I’d love to help/mentor with GSoC again. Especially so if we do something with the feedback loop.

      • Jane Wells 7:20 pm on March 7, 2012 Permalink | Log in to Reply

        We don’t automatically get 15 spots, I just gave that as an example. Here are our numbers for previous years (passed/total):
        2011: 10/12
        2010: 13/15
        2009: 6/8
        2008: 6/8
        2007: 10/10

    • Mert Yazicioglu 7:08 pm on March 7, 2012 Permalink | Log in to Reply

      Even though I developed a WordPress plugin as a GSoC proejct last year, I agree that GSoC projects should contribute more to the core.

    • Travis 7:09 pm on March 7, 2012 Permalink | Log in to Reply

      Fantastic idea, Jane. I think this would be a much better experience for students, and result in better production of things that would/could make it into core.

      I also really, really like the idea of reaching out to non-students to be mentored. That might be the motivation I (and people like me) need to get more involved with contributing.

    • Ahmad Awais 8:12 pm on March 7, 2012 Permalink | Log in to Reply

      I am willing to participate in GSoC this year through WordPress , keep me posted.
      I am a beginner , will it be hard for me to adopt the core? I am into plugin development basics

    • Andy Skelton 8:18 pm on March 7, 2012 Permalink | Log in to Reply

      Excellent idea.

    • Erlend 8:26 pm on March 7, 2012 Permalink | Log in to Reply

      Like I believe I suggested last year, I think WordPress’ sister projects, mainly the “BBs” (bbPress & BuddyPress) could benefit greatly from a cycle dedicated to them alone.

      WordPress itself doesn’t have any big publicity gains through GSoC, as it just feeds on its existing userbase. The BBs however could use the extra attention directed their way, seeing as a huge amount of WP users & even developers still don’t know exactly what these projects can do and how far along they’ve come.

      • Jane Wells 8:31 pm on March 7, 2012 Permalink | Log in to Reply

        Yes, but it is WordPress that Google gives the allotment to, not bb or Buddy. We include the plugins, but the limiting factor there is appropriate mentors. J-trip is only one guy, and even with Boone and Paul (and we’ve never had all 3 at once) that’s very few mentors compared to the number of people capable of mentoring WordPress. bbPress and BuddyPress could also apply to GSoC as separate projects, but have not wanted to in the past, so that they could take advantage of the support offered by being under the WP umbrella.

        Realistically, though, GSoC is not about teaching users and developers about projects. It’s about grooming new contributors and creating more open source code.

    • Paul Gibbs 8:36 pm on March 7, 2012 Permalink | Log in to Reply

      So, I’ve been looking forward this summer to seeing if I can get involved with GSoC. I’m interested in mentoring, and what BuddyPress can get from it — I’m definitely inspired by what Stas and Boone did in previous year(s). WordPress core doesn’t hold the same sort of social focus that attracts me to working on BuddyPress.

      I get the sense that the idea is to change the outputs away from generating a ton of new or specialised plugins, and onto WordPress core, which I agree is a better way for wporg to be participating in the GSoC. I would obviously prefer for this to not be at the detriment of possibility of a project for BuddyPress (or bbPress, or GlotPress, or any of the mobile phone apps, for example).

      • Mert Yazicioglu 8:40 pm on March 7, 2012 Permalink | Log in to Reply

        I wonder if we could have something like the following:

        5 seats for WordPress core
        3 seats for BuddyPress
        2 seats for Mobile Apps

        • Jane Wells 8:53 pm on March 7, 2012 Permalink | Log in to Reply

          We have NEVER EVER EVER turned away a mobile, bbPress, or BuddyPress application due to lack of spots. Every single year, those specific projects are chosen by the mentors who want to work on them. So if this year Boone, Paul, and J-trip said they didn’t want to mentor, there probably wouldn’t be bb/BP projects. They get to choose which ones are worthy/that they want to work on. Every year I’ve donated spots back to the common GSoC pool because the mentors have chosen to focus on fewer projects with the most impressive applicants, because mentoring is a serious obligation and they don’t have unlimited hours in a day. If people want to see more GSoC projects in the areas of mobile, bbPress and BuddyPress, the first step is to go get more regular contributors to those projects who would then be qualified to mentor GSoC students in the future.

        • Mert Yazicioglu 9:18 pm on March 7, 2012 Permalink | Log in to Reply

          I’m so sorry, my bad. After seeing Paul’s post, for a split second I thought we were talking about allocating all seats to the WordPress core. After sending the comment I realized that is not the case, but it was too late. Shouldn’t have rushed to comment, sorry for any inconvenience I caused.

      • Jane Wells 8:48 pm on March 7, 2012 Permalink | Log in to Reply

        Mobile apps, bbPress, and BuddyPress have always had mentors from their own group of committers. This post really applies to those coming from the WP core contributor group.

    • Eric Mann 9:28 pm on March 7, 2012 Permalink | Log in to Reply

      Fantastic idea overall. Working in teams definitely makes the workload a bit easier (particularly if team members are in different time zones). And scheduling the 3.5 cycle to include GSoC will make things easier on core developers.

    • Wojtek Szkutnik 10:35 pm on March 7, 2012 Permalink | Log in to Reply

      A few thoughts:

      100% in for fewer spots with more focus. There are several projects from earlier GSoC editions awaiting to be merged in some part with the core – if we were able to give them more focus earlier, they would probably be already there. I still find my GSoC 2010 patches merged to the core every few weeks.

      @outreach – great idea! From my GHOP/GCI experience, people in high school have far more free time to contribute to open source. We could prepare fliers, presentations etc and try to reach them. Also, GCI mentoring requires more time but probably less skills, so if we were to participate in GCI next year it would be easier to find mentors (I, for one, would happily devote some time to be a GCI mentor again and won’t give up my GSoC student status this year for Summer of Code mentoring 😉 )

      On a side note, I would really like to see unit tests for both JS and backend in this year’s tasks. I would definitely apply! 🙂 Testing may require some additional knowledge but brings great profits and I believe that unit tests would be very helpful – the sooner we improve this part of WP development, the less backward regressions we’ll experience in the future.

    • Conor Hughes 11:13 pm on March 7, 2012 Permalink | Log in to Reply

      I am but a lowly user of wordpress but I really like the sound of this. Keeping it teams makes it fun for all of us outside the dev comunity.

    • Mark Barnes 1:25 pm on March 8, 2012 Permalink | Log in to Reply

      This makes great sense to me. Improving core should always be the priority of the core developers.

    • Jane Wells 11:15 pm on March 9, 2012 Permalink | Log in to Reply

      I corresponded with Carol (the administrator of the GSoC program overall) and she said the approach sounded good. She said putting students onto teams with mentors and/or other students would be fine, as long as we were grading them on their own code. Since everyone starts out writing their own patches before the back-and-forth revision process kicks in, I think this seems pretty easy to ensure. Will discuss more with the people in Austin this weekend (Jaquith, Nacin, Koop, etc) but am thinking that we’ll give it a try.

    • Gustavo Bordoni 5:33 am on March 12, 2012 Permalink | Log in to Reply

      So I would like to know how to submit a project/idea to be part of the GSoC program with WordPress Core improvement?

      • Jane Wells 3:45 pm on March 12, 2012 Permalink | Log in to Reply

        Student applications aren’t accepted until Google opens the application period, and for that matter, we haven’t been approved as a participating organization yet. That said, getting involved early definitely increases the chance of being selected. Submitting patches for core bug tickets before applying is important. You can also talk to WP devs in #wordpress-dev on freenode.

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