Make WordPress Core

Tagged: 3.3 Toggle Comment Threads | Keyboard Shortcuts

  • Jen 3:39 pm on November 16, 2011 Permalink
    Tags: 3.3,   

    Time to shoot for beta 4, hopefully last beta on 3.3 cycle. Shooting for beta 4 to happen tomorrow, so today should be full-on milestone scrub day. Dev chat today at 21:00 UTC can be quick status check so as not to derail work. Plan on check-ins tomorrow morning/lunchtime/afternoon/evening depending on timezone to get things moving.


    • 3.3 task status reports – core team, contributors
    • review blockers
  • Jen 5:41 am on October 20, 2011 Permalink
    Tags: 3.3, ,   

    Beta 2 is out.

    There are currently more than 150 open tickets. Many need patches, many have patches that need testing. If you want to help, head over to https://core.trac.wordpress.org/report/6 and look for a ticket (or several) that you think you can help with. Many of them are not overly complicated, they just need people to give them some love.

    Remember, if you find something in beta 2 that you think is a bug, report it! You can bring it up in the alpha/beta forum, you can email it to the wp-testers list, or if you’ve confirmed that other people are experiencing the same bug, you can report it on the WordPress Core Trac. (We recommend starting in the forum or on the mailing list.) If you’ve never reported a bug before, check out the Codex article on how to report bugs.

    • arena 10:12 am on October 20, 2011 Permalink | Log in to Reply

      see #18949 & #18997

      • Jane Wells 11:19 am on October 20, 2011 Permalink | Log in to Reply

        Calling out these tickets in a comment on a post asking people to help get 3.3 finished is the equivalent of bumping. Please don’t do that — keep comments relevant to the post. Sometimes there are posts asking people to call out tickets that they want to get more eyes on, but this wasn’t one of them. That said:

        #18949: If every person who wanted to give their preferred design approach opened a new ticket for it, we would be flooded. I vetoed that request in any case for UX reasons, but you should have put it on the regular admin bar ticket, not created a new one.

        #18997 – Valid as a ticket, but long past the time when new feature requests are being accepted into 3.3. We are in bug squashing mode. This won’t be considered until we start scoping for 3.4.

  • Jen 4:31 pm on October 19, 2011 Permalink
    Tags: 3.3,   

    Yoav usually helps with RTL issues around this time in the dev cycle, but he’s not around for a few weeks, as he is a proud new father. (Congrats, Yoav!) If anyone is able to look in on, test, help refine, etc the remaining RTL tickets for 3.3 (we could especially use help from Arabic native speakers), that would be awesome.

  • Ryan Boren 10:17 pm on October 17, 2011 Permalink
    Tags: 3.3,   

    Activity since beta 1:

    • The blue theme is looking much better thanks to @ocean90.
    • @azaozz fixed IE7 and RTL support.
    • Flyout menu styling is more spiffy and less glitchy.
    • Pointers are pretty much done thanks to @dkoopersmith.
    • WP_Screen and contextual help improvements from @nacin.
    • Various bug and styling fixes from everyone.
    • The “blog front menu” in the admin bar returned to a small snack menu from the full menu we trialed in beta 1.
    • Bug scrubs started up again today to finish cleaning up the 3.3 milestone.
    • Almost 50 commits since beta 1.
  • Ryan Boren 5:32 pm on October 5, 2011 Permalink
    Tags: 3.3,   

    We’re getting 3.3 ready for beta. Here’s the gist of how things stand:

    • We’re doing daily (almost) bug scrubs in #wordpress-dev to drive down the ticket count.
    • Nacin is finishing up WP_Screen and the media button merge.
    • Koopersmith is finishing up tabbed help and flyout menu styling.
    • Pointers need some styling fixes to be called done enough for 3.3. Pointers will probably be for core only use in 3.3.
    • Admin bar needs final walk through and tweaks.
    • Welcome box and about this version page need final feedback and tweaks.
    • Some of the responsive admin work will be pushed to 3.4 so we have more time to get large screens looking the way we want. Ozz and Jaquith are on it.
    • Jane will check all UI/UX feedback tickets and leave comments.
    • All task (blessed) tickets should be updated with a comment on current status by the end of the day.
    • I will stroke my beard in a diabolical manner while everyone else works.
    • Okay, besides that I will be scrubbing bugs, working on more unit tests, and getting coffee for the JS guys.
  • Jen 3:58 pm on October 5, 2011 Permalink
    Tags: 3.3, , usability   

    3.3 Pre-Beta User Feedback (aka Testing Results) 

    Last week I did a bunch of testing, 20 participants (and had done some in Portland as well during WCPDX). I ran people through the new stuff, some screenshots, and watched them using their current sites as well. Did a combination of using my test site (or their site if they had beta tester plugin activated) on my laptop and going to participant homes. Mostly the former, for logistical reasons. I’d wanted to experiment with some long-distance testing using skype and screenshare as well, but ran out of time due to a bout with food poisoning, so am still planning to test out that technique with some of the people who volunteered (on this post on my blog about testing) in the future, maybe before beta2.

    Flyout Menus

    Universally liked, and no one was really bothered by the loss of ability to leave sections open once they got used to it (a few lamented loss of permanently open specific sections at first), which took an average of 3 screens. Most common complaint was the styling, that it wasn’t clear enough which section was in focus. I had talked about this with MT when they first went in, so will circle back with him to give it more delineation and contrast. I want to get rid of that fade for sure, it’s not a design element we use anywhere else, and it didn’t make anyone say, “ooh, that’s pretty,” which would be the one thing that might have swayed me (I like it when people think the UI is pretty). A few people (6) mentioned the animation without prompting and thought it was too slow. The rest were asked afterward if they thought the animation was too fast, too slow, or just right, and the responses were 0 for too fast, 12 for too slow, and 2 for just right.


    • Ditch the animation and make flyouts appear instantly before beta 1.
    • Change styling during beta 1 to be higher contrast and more in line with current UI.


    The uploader changed a little during testing (early results -> try a fix -> more sessions, etc) so I don’t have numbers that are consistent here for opinions. Overall, everyone liked the new uploader, though some were confused by it at first. The initially really big dropbox was reduced in height to see if that would help, and it did. Even in the shorter dropbox, though, the small text centered in the middle made a few people wonder if there was a bug. “[] Scale images to max width 1024px or max height 1024px” was overlooked by most, and the few who noticed it wondered where the number came from. All guessed it was probably set by the theme, but weren’t sure where it would be used at that size.

    Moving to a single ‘add media’ icon (from 4) confused people during testing because the icon in place was for video, not the multimedia icon from the Media Library as had been requested, so people wondered if the image upload was broken. When the intended icon + making ‘Upload/insert’ clickable was explained, participants were in favor of the change.

    Gallery and post-upload image management still considered painful by 8 of 20 participants. 7 participants didn’t have a strong opinion as they don’t typically edit images/metadata after uploading or use galleries for multiple images in posts. 5 thought it was fine, though my guess is that they’re just so used to it they’ve stopped caring.

    “From URL” upload was changed only for the last handful of participants, but all responded positively (only one even noticed the change).


    • Adjust styling/layout of uploader popup (bigger text in dropbox).
    • Provide explanatory text near “[] Scale images to max width 1024px or max height 1024px” and add to help text.
    • Make ‘Upload/insert’ text clickable and replace video icon with camera+note icon from left menu.
    • On From URL tab, move “Insert media from another web site” to where it currently says “Add media file from URL” but make website one word per our convention.
    • On From URL tab, make “Images” be “Image” and make “Audio, Video, or Files” be “Audio, Video, or Other File” since they can only do one file at a time.

    One Header to Rule Them All

    The combination of the wp-admin header and the admin bar in the dashboard is something I was expecting more pushback on (I remember some people complaining the header font got too small in 3.2, and in this new approach, it’s not there at all), but people seemed to like it and think it was cleaner. No one mentioned the gain in vertical real estate, but 17 mentioned it looking cleaner and appreciating the reduction of duplicated info/links. I tested a few different colors (used comps from UI group and Chelsea) and a few different orders/labels/items for the bar itself based on the discussion on the Trac ticket.

    Size and placement: It’s fine!

    Colors: In the default dark bar currently on trunk, the font needs to have more contrast. In the lighter comps, the fonts needed to be darker for same reason. Thought people might equate the lightest version with browser chrome, but no one did. People did not have a strong preference for the darker or lighter versions, and when forced to choose one, it was split evenly (except for 3 people who suggested making it an option in Writing Settings (where they seemed to think Profile Personal Options would be located, to a man (and one woman)). We can just choose whichever wins the core team + Matt vote (guessing it will be dark).

    Content: Addition of W menu liked by 16, not cared about by 4 (“I doubt I’d ever use it.”). Links included were fine with all, adding the other footer links was seen as a good idea. About evenly split as to if About [version] and credits should be combined (proposed as tabs in one screen with a sketch) or should have it’s own link in the menu.

    The change in behavior for title being used as link between front and back confused 4 people at first. 2 people figured it out on their own after clicking bak and forth a couple of times, 1 person asked for confirmation that it was intended behavior (and was cool with the answer), and 1 person thought that in the dashboard there should be a dropdown that says “View site” to be consistent with the dropdown to Dashboard on front end. Though I want the title to remain clickable to the other side, making that dropdown isn’t a bad idea, could also include shortlink to the homepage when shortlinks in use (wp.com has shortlinks here).

    When on front end, tested variations for title dropdown that included a full wp-admin nav (left side in dash) and an abbreviated version with the links in current admin bar. There was no strong preference based on design, as most people said they mostly just wanted access to the screens they used most, which were variable.

    The Updates circle being the brightest thing was seen as weird, most thought it should be on par with comments number, and several suggested we give it an icon like comments has. Worth considering, would make it prettier and more consistent.

    Multisite variation. Tested with 6 people who currently use multisite, so were familiar with Network Admin, had others look at options also. Tested variations of where the Network Admin link and the list of sites should go. Tried all under name link, tried all under W (i.e. “your WP install” instead of WP resources), tried as one combined link (and tried both Network Admin and My Sites as labels), and tried as two separate links. Tried the top-level link on left and on right. (Thank you Chelsea for whipping out a ton of comps for this.) In general, this was too many choices for testing. In future should narrow it down to just 2 or 3 variations. That said, 3 people chose having sites under name (2 of these were .com users) but network admin as own link, 2 chose having each as a top level link, 1 chose having both under name link, 2 chose under W (1 of these was conflicted because she also liked the resources links), and 12 chose to have both under one top level link — 10 said under My Sites and 2 said Network. Placement between W and current site name got the most votes.

    Search. No one minded it being missing on dash side.

    Help. New layout underwent some construction and style updating during testing, so I don’t have numbers for voting etc. Current state is based on iterative adjustment during test period. The breakdown into shorter section with persistent links on right was universally liked. Several people suggested embedding images and/or video now that there felt like there was more room. Also tested placing help in left section (related to blog name) and right section (related to person name), 17 out of 20 voted for left section (but of these 3 said it would be tidier on right with a ? instead of word Help a la search/magnifying glass on front end)


    • Choose light or dark (prob dark) color scheme and make font/icons lighter for better contrast.
    • Keep W menu, add the other footer links into it and ditch them from footer (Credits, Freedoms, Documentation is already there, Feedback).
    • Add My Sites top-level between W and current site name, make Network Admin the first site and give it a different background shade, then list all sites in network.
    • In dash, add View Site and Shortlink submenu items to site title.
    • Need to choose between full list of nav link or snack menu under site name in front end. Choose one to get in before beta 1, adjust to optimize ux before beta 2 if we go with snack menu.
    • Get icons for Add New (+), Updates (up arrow?), Help (?) to provide consistency and make more scannable. Could alternately reduce to icons (+numbers) and show labels on hover if there are concerns about space (must ensure keyboard accessibility of all dropdowns/flouts, btw).

    New Feature Pointers

    Universally liked. Also tested yellow alert version from John O’Nolan; 9 said it stood out more but of those 9, 7 didn’t think it was very friendly because they associated the color with a dashboard alert.


    • Do beta 1 as is and improve styling before beta 2. The new Pandora has some snazzy new feature pointer styling, let’s take a cue from that but give it our own palette etc.

    Post-update Version Screen

    Universally liked. Requests for links to more info — and including video walkthroughs when applicable — common among participants.


    • Start putting in more structured info and linking up to Codex. Make prettier.

    New Install Welcome Box

    Tested this with sketches for concept, then asked participants to make list of what they would want to see in this box. Concept universally liked, though several thought it might be more useful if paired with maintenance mode during initial setup with a ‘go live now’ button or something. Preferred advice/links varied based on experience level, with most including some settings (tagline, display name, discussion options most common), deleting default post/page/comment, editing profile, and creation of one of most things (a text widget, a post with an image in it, an about page).


    • Get the box in there with some default links, take a poll during beta 1 on wordpress.org blog of what things people would find most useful for 1st time installs, and launch final version in beta 2.
    • Jane Wells 4:17 pm on October 5, 2011 Permalink | Log in to Reply

      I forgot to mention: 12 were on mac, 8 on PC. All used either ff or chrome as their default browser. Will need to be extra remembery to check on performance in IE, Opera, Safari, and should check on Linux users also.

    • Jane Wells 4:21 pm on October 5, 2011 Permalink | Log in to Reply

      Also, ran out of time before dev chat was starting to include results of responsive admin (dashboard and add new post screen). Overview: the idea got initial oohs and aahs, but when participants actually used it (my 13″ laptap, my 17″ laptop, or their own laptop or monitor ranging from 11″ to 27″), it wasn’t well-liked. Will discuss particulars in dev chat, may want to consider pulling and restructuring approach for 3.4.

    • Daniel Chatfield 4:24 pm on October 5, 2011 Permalink | Log in to Reply

      Thanks for the update – if you need any more testers I am more than willing to help out.

    • Eric Mann 4:27 pm on October 5, 2011 Permalink | Log in to Reply

      The one bit of feedback I have on the feature pointers is based on using 3.3 in production (I know, shh!) for the past few weeks … and now that WordPress SEO is adding pointers, they’re a bit annoying. When I update WordPress to stay in line with Trunk, I get a pointer on the top nav bar and a pointer on the admin sidebar at the same time.

      Having to clear them both out is a little annoying. Minor, but once other plugins/themes start implementing the tool I can see how my dashboard might get hijacked by all of the “check out this new feature” messages.

      Other than that, I’m in agreement with just about all of the findings above. The team has done great work, and I’m hugely impressed with all of the changes!

      • Mika "Ipstenu" Epstein 4:44 pm on October 5, 2011 Permalink | Log in to Reply

        I noticed that with WordPress SEO too, and wasn’t happy with the ‘stop tour’ button (reminds me to tell Yoast directly) because I clicked ‘close’ and the damn thing came back.

        Maybe an option I can toss in wp-config: Shut up with the pointers already 😉 For experienced users only.

        • Joost de Valk 5:51 pm on October 5, 2011 Permalink | Log in to Reply

          To be fair Mika, it explains that quite well on the first pointer: close just closes, stop tour closes the entire tour. Might need work, agree there. Also will switch it to “No Tour” and “Start Tour” before 3.3 is released so you only have to click once for real.

        • Mika "Ipstenu" Epstein 6:15 pm on October 5, 2011 Permalink | Log in to Reply

          Clearly I wasn’t hugely UN happy, Joost 🙂 I adore the plugin, it just was a moment of ‘Huh? I clicked CLOSE!’ And now I don’t have to hit send on one of the 6 draft emails I have up! 😉 (It was a too many buttons thing. Close should be ‘close and done.’ not ‘close and come back when I refresh.’)

      • John Blackbourn 4:52 pm on October 5, 2011 Permalink | Log in to Reply

        Once other plugins/themes start implementing the tool I can see how my dashboard might get hijacked by all of the “check out this new feature” messages.

        The pointers are great and I was initially in favour of a pointer API so plugins could utilise them, but I too suspect that we’re going to see an avalanche of plugins that add pointers and I’m going to end up hating them.

        • DrewAPicture 4:55 pm on October 5, 2011 Permalink | Log in to Reply

          Me three. I can see this getting annoying really quickly. Just keep them core-specific.

        • Joost de Valk 5:13 pm on October 5, 2011 Permalink | Log in to Reply

          Feedback i got on my pointer-tour in WordPress SEO has been very good so far, note that I changed the design slightly because people didn’t see them at first.

          I can see why you would want to restrict but I don’t think a whole lot of plugin authors will use this, only those with bigger plugins…

        • John James Jacoby 5:16 pm on October 5, 2011 Permalink | Log in to Reply

          I think the hate will go away the first time you install a plugin you’ve never used before, and that plugin installs itself seamlessly inside WordPress instead of creating a top level menu.

        • Jane Wells 5:41 pm on October 5, 2011 Permalink | Log in to Reply

          I wanted them to be core only for 3.3, make plugin-ready in 3.4 after we’ve worked out any kinks and people have gotten over the thrill.

        • Joost de Valk 5:52 pm on October 5, 2011 Permalink | Log in to Reply

          Jane: making them core only won’t work, once you set a precedence, plugin authors will use it too. It’s not like we / they need to wait for core to do it, this is your only chance to make sure people will use the same API.

        • Daniel Chatfield 6:00 pm on October 5, 2011 Permalink | Log in to Reply

          I’m sitting on the fence on this one. I think it is a great feature that could become horrible. Some good guidelines will need to be given to plugin authors.

        • Eric Mann 6:46 pm on October 5, 2011 Permalink | Log in to Reply

          Joost – Normally I’d agree that only the “bigger” plugins will use this … but that’s also what I used to think about custom admin pages and theme options pages.

          Don’t get me wrong, I love the feature … I’m just concerned that if more than 1 plugin tries to use it at once (in addition to core) that many users will be overwhelmed.

        • Jane Wells 7:51 pm on October 5, 2011 Permalink | Log in to Reply

          And to Eric Mann’s point, if multiple plugins use it to point to the same thing (5 pointing at Settings menu, etc) there will be conflicts. We didn’t have time to work out all that logic for 3.3, which is why it’s meant to be core only for now. If plugin authors are in love with the idea and want to hand-crank their own pointers now instead of waiting until we roll out an API we’re actually happy with and want to promote them using, they can always change it later.

          Really, all of new features like this should be starting life as a plugin then moving into core after we’ve had a release of people using it/building off it, but we’ve been doing it backwards. That leads to conversations in the dev cycle after a new feature is introduced that go something like this:

          Dev 1: “So, we should fix x to be better, and do blah blah blah.”
          Dev 2: “Totally. Except a bunch of plugins are using it now, and if we change it, they’ll break. So we can’t.”
          User A, next release: “Why haven’t they made x better?”

    • DrewAPicture 4:49 pm on October 5, 2011 Permalink | Log in to Reply

      On the scale images discussion, why not have an (unchecked) checkbox with Resize image(s) before uploading followed by helper text if they check the box?

      Unchecked (default):
      [ ] Resize image(s) before uploading

      [ ] Resize image(s) before uploading

      • Images will be scaled to a max width or height of 1024px. You can change this setting in foo
    • judas 4:52 pm on October 5, 2011 Permalink | Log in to Reply

      I don’t know if this is the right place, but if you need Linux testers I could give a hand.

    • Kel 6:57 pm on October 5, 2011 Permalink | Log in to Reply

      Since I wasn’t part of the feedback teams, I’ll just give one minor suggestion re: Admin/Header bar.
      Seems like the items under the “Add New” dropdown menu might mimic the order of what’s in the sidebar menu?

      Add New >>



      Or… swap the items in the left menubar to match the Add New dropdown 🙂

      Otherwise I’m finally a convert to the admin / header bar.


    • mbijon 9:56 pm on October 5, 2011 Permalink | Log in to Reply

      The new Help layouts just take HTML, so they already support images/video embeds.

      There’s no guidance or existing examples of using media (understandable since the layouts aren’t locked down yet). Would it be better to recommend how plugin developers should format media in the docs, or should a designated “media container” be added?

    • Thomas Scholz 12:42 am on October 6, 2011 Permalink | Log in to Reply

      Did all of your testers use a mouse?

      • Jane Wells 1:03 am on October 6, 2011 Permalink | Log in to Reply

        [Checks notes.]
        Nope. 6 used a mouse, 13 used laptop trackpad, 1 used magic trackpad. Of those, 2 also used keyboard shortcuts and some tabbing to bounce around screen at times (both were laptop trackpad users).

    • Pete 1:36 am on October 6, 2011 Permalink | Log in to Reply

      So awesome to read this. If you ever find a volunteer willing to be videoed (with screen capture) while you do the tests, I’d love to see it.

      • Jane Wells 1:46 am on October 6, 2011 Permalink | Log in to Reply

        I usually do video sessions for reference, then delete them afterward because whenever possible I have people do testing on their own sites, and it’s personally identifiable, etc etc. That said, I’m planning to do a broader baseline test at some point later in the cycle or possibly between the launch of 3.3 and the beginning of 3.4 to gather some baseline metrics for time on task etc. That would be utilizing volunteer moderators, also, so having the exact same environment for all participants would be best to allow for easier analysis. For baseline tests, I like to use a test install instead of personal installs, so that everyone has the same setup (no slowdown or weird nav due to plugins, etc, throwing off the times). In cases like that, the video is generally pretty anonymous, so could be posted.

    • Syed Balkhi 4:11 am on October 7, 2011 Permalink | Log in to Reply

      I love the overall UI. The admin bar / wp-admin head is very cool looking. The only thing that I don’t like is the flyout menus. My settings thing is too long, so flyout makes it look ugly and really hard to navigate to. I guess this won’t be the concern for most folks… but some of us have a lot under the settings tab…

    • Adam W. Warner 10:18 am on October 7, 2011 Permalink | Log in to Reply

      Thanks for your detailed testing and reporting Jane. Many of these changes are welcomed. I am an avid Multisite user and am interested in helping test both versions. I will send you a direct contact (or feel free to contact me through this email).

      To all others on this thread please know that you are ALL making the world able to communicate better through the freedom of self publishing and you should be proud;)

    • arena 4:37 pm on October 14, 2011 Permalink | Log in to Reply

      on admin bar (monosite installation)

      • 3.2 was white, 3.3 is black … (prefer white)

      Some inconsistencies when hovering, clicking on admin bar :

      • when hovering WordPress icon, bckground color turns white, several options displayed

      i think some text of readme.html should be recycled in this menu

      when hovering Blog name, bckground color turns white, two options 1) click on blog name 2) visit site these two options seems redundant …
      When hovering Comments, bckground color remains black (?),nothing happens (ok). the number of pending comments on the side of the grey bubble (bug ?) (using FF7).

      Redundant with the menu. I think it would be cool to remove it from admin bar and have a specific menu icon when comments are pending.

      • When hovering ‘Add New’ , bckground color turns white, something like the ‘File’ menu displayed

      clicking on ‘Add New’ goes to New Post …

      • When hovering ‘Help’ , bckground color remains black (?), nothing happens …

      When clicking on it some context options displayed
      I would rename this option ‘About Screen’ or just ‘About’

      • At the right of admin bar, the profile menu.

      when hovering ‘Howdy’, bckground color turns white,
      profile name & gravatar appears (again, already in admin bar))
      Log Out should be always the last option with a separator and a grey background (like ‘Add New’ User option)
      see ticket #18949 (including capability to includes plugin options thru apply_filters)

  • Andrew Ozz 6:47 am on September 23, 2011 Permalink
    Tags: 3.3,   

    Javascript changes in 3.3 

    Now that WordPress 3.3 is in feature freeze, it’s time to have a look at some new Javascript goodies for developers:

    • jQuery 1.6.4 and jQuery UI 1.8.16. And that’s the full UI including widgets and effects. This will make it a lot easier and simpler for plugins using UI components that are not used in core as they will be able to just enqueue whatever they need.
      Note: there is a known bug/regression in UI Draggable since version 1.8.13. When connecting a draggable item to a sortable container, the HTML ID of the item is removed, #17952.
    • WordPress Editor API. This is an updated API for both TinyMCE and Quicktags that outputs all parts of both editors in the same way as used on the Add / Edit Post screens, #17144. Plugins will be able to use the WordPress editor anywhere including the Visual/HTML tabs and the links to upload files and show the media library.
    • Quicktags refactoring. This was necessary in order to make it fully multi-instance compatible, #16695.
      Note: if your plugin adds a Quicktags button please enhance it to use the new methods in quicktags.js.
    • New multi-file uploader. Plupload was included as a result of Google Summer of Code project, #18206. It’s more stable and has a lot more features as well as chooses the best available interface that the current browser supports: HTML 5, Silverlight or Flash.
      Note: two actions that were specific to SWFUpload were renamed and there is a new filter ‘plupload_init’ that gives access to all initialization options.
    • Other enhancements: wp_enqueue_script() now works mid-page and prints the late enqueued scripts in the footer #9346, wp_localize_script() uses json_encode to properly escape and output all strings, #11520.
    • Scott Kingsley Clark 2:18 pm on September 23, 2011 Permalink | Log in to Reply

      We were using a very early version of #2 and it’s been working great, excited to integrate the full 3.3 Editor API and have it work to the full extent we and plenty of other hungry developers have waited for 🙂

    • Conor Hughes 2:00 pm on September 26, 2011 Permalink | Log in to Reply

      Question about plupload, Does it include the option to spilt the upload in to samller chunks? So basicly does core included all the feature of the wplupload plugin https://wordpress.org/extend/plugins/wplupload/

      • Andrew Ozz 7:17 pm on September 28, 2011 Permalink | Log in to Reply

        No that’s not enabled by default but can be set by a plugin. Seems only Chrome handles splitting the file into chunks properly at the moment. It would have been nice to remove the upload size limit 🙂

        When more browsers start to support this reliably we can enable it by default, probably 3.4.

        • Conor Hughes 7:39 pm on September 28, 2011 Permalink | Log in to Reply

          Currently using the plugin and file spliting works in opera and Firefox 6+, However I am using the flash runtime not HTML5.

    • Stas Sușcov 7:47 pm on September 27, 2011 Permalink | Log in to Reply

      Great news on Editor API and `wp_localize_script()`!!!

    • Jason Penney 8:05 pm on September 28, 2011 Permalink | Log in to Reply

      Glad to see the full jQuery UI (also, looks like I picked the correct script names in Use Google Libraries way back, so I won’t need to make changes in there when 3.3 comes out).

    • Joerg 9:59 am on September 30, 2011 Permalink | Log in to Reply

      I hope the TinyMCE editor will offer tables in WP by standard so that I would not need to install any plugins anymore….

      • Andrew Ozz 4:10 pm on September 30, 2011 Permalink | Log in to Reply

        No, the default TinyMCE configuration in core has not changed. Most functions related to it were combined in WP_Editor class.

    • Max 9:14 am on November 4, 2011 Permalink | Log in to Reply

      Too late for jQuery 1.7?

  • Jen 2:34 am on September 22, 2011 Permalink
    Tags: 3.3,   

    Freeze (just in time for fall!) 

    It’s that time in the dev cycle again: feature freeze. As usual, we are running a bit behind. We were supposed to have freeze a week ago for everything being worked on by contributors, then a week for the core team to do a scrub and commit or punt all those enhancement/feature request tickets as well as finishing up their own 3.3 feature dev before full on freeze today. We gave contributors some extra time at last week’s dev chat as there were some features not quite ready (HTML emails, Settings CSS, etc). Sadly, the extra time didn’t lead to commits, and now we’re just a week behind. So!

    This is freeze.

    1. All enhancements and feature requests that do not have a ready patch will be punted.
    2. All enhancements and feature requests that have a patch but no comments showing that the patch has been adequately tested will be punted.
    3. All enhancements and feature requests that have a patch that has been adequately tested will be reviewed by the core team and either committed or punted.
    4. No more enhancements or feature requests will be added to the 3.3 milestone.
    5. The core team will commit their remaining new features, and Jane + some UX volunteers will do some testing of UI changes over the coming week. Core team (and anyone who volunteers to help) will revise UI of new features based on findings during testing on a rolling basis.

    Then comes beta, during which we’ll be in bug-fix-only mode. Yes, there is such a thing as a UI “bug,” but “we should have done this sooner” is not a bug.

    This cycle has already seen two deadline pushes, so from now on we’re going to do our best to be mercilessly strict with the deadlines, even if it means cutting things. Anything that isn’t ready will be cut. “not done” is not the same as “has bugs,” and we need to be better about respecting that difference. We had plenty of time to get these things in; we all made decisions about priorities over the last few months.

    It is now too late to ask us to get something in for 3.3. Start working on it for early 3.4.

  • Jen 4:17 pm on August 17, 2011 Permalink
    Tags: 3.3, ,   

    Commit This 

    It is with great pleasure (not to mention optimism, satisfaction, and many other adjectives) that I officially announce the addition of Jon Cave (aka duck_, or said aloud as “duck undah”) to the WordPress version 3.3 commit team. Duck’s consistently good code, communication skills, eye for security, and tireless efforts made it a natural choice to give him a more official role with this release cycle. Also, @ryan is just sick of having to commit his patches. 🙂

    duck_ joins permanent committers @nacin, @dd32, Nikolay, and Joseph Scott, as well as @dkoopersmith, whose 3.2 commit stint has been re-upped.

    Congrats, you deserve it!

    Jon Cave aka "duck_" at WordCamp SF 2011 — photo by Mark Jaquith

  • Jen 5:21 pm on July 20, 2011 Permalink
    Tags: 3.3   

    3.3 Schedule is posted.

    • youngmicroserf 8:26 pm on July 23, 2011 Permalink | Log in to Reply

      Is this the post to post ideas for 3.3 to?

      Here are my ideas / things that bug me most about WP at this point:

      user profiles:

      custom fields – https://core.trac.wordpress.org/ticket/16911
      local avatars / profile pictures – the empty admin bar icon for non-gravatar using members is ugly
      BuddyPress X-profile integration, no more redundancies.

      general option pages:

      • redesign

      nav menus:

      • adding a hook in the UI so additional fields can be used to filter the menu (can be done in rel or class fields, of course, but it’s hacky and the addition seems simple (writing a conditional nav menu plugin at the moment))

      Post Status:

      custom statuses
      allow scheduled *unpublishing*
      include content holding posts/pages/post types with according status: Content is published but without a URL of its own, can only be accessed through specific queries.

      Custom fields:
      *field type selector, better UI (IE simple fields plugin)

      editing pages:
      AJAX, drag and drop, reordering, collapsable hierarchies (eg CMS tree view)

      Quick edit:
      Allow to add custom fields (there’s a bug in the respective walker, has been discussed on WP-Hackers, I think).

      • Jane Wells 12:49 pm on July 25, 2011 Permalink | Log in to Reply

        You con check the IRC logs from the dev chats to see which features we’re targeting for 3.3.The scope of 3.3 will be confirmed by the lead devs at this week’s dev chat.

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