Make WordPress Core

Tagged: testing Toggle Comment Threads | Keyboard Shortcuts

  • Jeremy Felt 7:24 am on June 5, 2015 Permalink
    Tags: , , testing   

    Help Test and Capture the Network Admin UI 

    One of the wider objectives of WordPress 4.3 is to improve on the Network Admin UI. This includes refining the experience on different device sizes. We first need to capture a baseline of existing screen flows and identify tickets from that.

    We need help capturing this data. 🙂

    Having access to a local, multisite WordPress installation is the preferred method, as you’ll have an easier time making changes, applying patches, and generally having control over the data. Here are some guidelines for testing locally:

    Realizing that installing and configuring multisite locally can be a barrier, a test server is available for anyone to access. This test server has two network installations, one for subdirectory and another for subdomain. Data will be reset on a regular basis. This allows anyone to go through the various network admin tasks.

    Both networks are running trunk as of about 20 minutes ago. I’ll be making an effort to automate the maintenance of that setup.

    If you’d like a super admin account to these networks, leave a comment below or ping @jeremyfelt anywhere. #core-multisite is preferred. I’ll create a matching username to your wordpress.org profile name and set you loose to capture and break things at will. 🙂

    Once you have a test network available, here are the things we need captured:

    • Add a new user to a site when the user does not currently exist as a network user.
    • Add a new user to a site when the user does exist as a network user.
    • Install, enable, and then activate a theme for a single site on the network.
    • Install a theme and enable it for use on a network.
    • Install and then activate a plugin for use on a single site on the network.
    • Install and then network activate a plugin.
    • Create a new site on the network.
    • Update a plugin.
    • Update a theme.
    • Edit the domain/path for an existing site on the network.

    Once captured, it’s great to share all of the data on the Make/Flow site, with a description of the screens tested and the device/browser configuration. If you need access to Make/Flow to post your results, leave a comment here or in #core-flow.

    Specific details on each of these screens should also be added to this spreadsheet that the overall Admin UI team is using to coordinate efforts. Feel free to capture one workflow or many.

    If you notice a bug in the screens you have captured, or in the screens captured by somebody else, it should be reported. Ask in #core-multisite or #core-flow on Slack if you need any help.

    • crplz 10:02 am on June 5, 2015 Permalink | Log in to Reply

      would love to contribute in this as almost 100% of the sites we manage are Multi-Site enabled. Have tons of experience facing problems managing several wp networks loaded with users/cpt/etc.

      Can I get a super admin account? #core-multisite

      • Jeremy Felt 6:31 pm on June 5, 2015 Permalink | Log in to Reply

        Great! You should have two emails with account information for the networks sent to the email used to leave this comment.

    • Sharon Austin 12:10 pm on June 5, 2015 Permalink | Log in to Reply

      I would love to be able to help out with this….as much as for some guidance on “how” to do a proper test as for any other aspect! Thank you for creating the opportunity!

      • Sharon Austin 5:31 pm on June 5, 2015 Permalink | Log in to Reply

        Sorry, not sure if I needed to be more specific in my request above. I would like a super admin account for user: sharonaustin for testing Network 1 and Network 2. Thanks again for doing this.

        • Jeremy Felt 6:32 pm on June 5, 2015 Permalink | Log in to Reply

          Thank you! You should have two emails with account information for the networks sent to the address used to leave this comment.

    • Ben Hansen (ubernaut) 2:53 pm on June 6, 2015 Permalink | Log in to Reply

      you should add checking out the user list to that list 🙂

    • Sharon Austin 6:19 pm on June 9, 2015 Permalink | Log in to Reply

      @jeremyfelt Thank you, got ’em. While I’ll go in right away, I may be quiet for a few days to lurk, watch, and make sure I understand what you’re looking for…I want to give feedback that is well-targeted to the needs. Thanks again for doing this.
      @ubernaut recommendation so noted! 🙂

    • Sharon Austin 8:55 pm on June 11, 2015 Permalink | Log in to Reply

      @jeremyfelt I have sent you email with the first summary (Subdirectory) to your gmail account. If you wouldn’t care to look it over before I post, that would be a favor. Feel free to share it if you think it is okay to share. I’ll work on the Subdomain tomorrow.

      Thanks again for doing this.

    • Sharon Austin 4:58 pm on June 12, 2015 Permalink | Log in to Reply

      Apologies, @jeremyfelt, I just read the latest post sent out about testing the UI…I will put the screenshots on #makeflow, Thanks again.

    • Saravanan 8:03 am on June 20, 2015 Permalink | Log in to Reply

      @jeremyfelt, I would like to help out with this. I will need access to sites to test them on my iPhone 6 plus; and Mac. Thanks.

  • Ryan Boren 5:01 pm on March 31, 2015 Permalink
    Tags: , , testing   

    We must be our own beta audience. 

    Using the beta tester plugin, I follow trunk through every phase of development via five devices (iPhone 5, iPhone 6+, Nexus 5, iPad Air, Macbook). With the plugin installed, select “Bleeding edge nightlies”. Every day, your site will auto update to the latest nightly build. We committed long ago to ensuring that trunk is continuously dogfoodable and quickly fixed in the rare event that something nasty happens, like a fatal error. I have never once experienced loss of content while following trunk.  If you follow this blog, consider putting the beta tester plugin on a real site that you use regularly. We must take this small extra risk with our own sites so that we truly see what we’re making before releasing it.

    We desperately need mobile beta testers. WordPress will be a champion of the open mobile web. We will work around the iOS Safari bugs that hamper us. We will make the mobile web a better place. With the beta tester plugin installed on a public site, testing betas from any touch device is as straightforward as testing from the desktop. Despite this ease, 4.2 in its current state is a regression from 4.1 on mobile, particularly on iOS. We’ll work through these problems before release, but we really need mobile beta testers as well as mobile patch testers. Mobile patch testing (and patch testing in general) is not so easy to set up. We need better tools and documentation here.

    Check out the Beta Testing section of the Core Development Handbook for help setting up the Beta Tester plugin. I’m always hanging out in the #core-flow Slack channel as @boren if you have questions. Let’s build a mobile beta audience.

  • Jen 3:58 pm on October 5, 2011 Permalink
    Tags: , testing, 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)

  • Jen 2:52 pm on December 23, 2010 Permalink
    Tags: testing   

    As everyone knows, we’re behind on the 3.1 release schedule, and as we have not hit RC yet, it’s unlikely we’ll release before the end of the year. Sad Christmas. There are 11 tickets in the milestone right now. I know it’s the holidays, so people are busy, but it also means people are taking time off work and hanging around killing time in a lot of cases, so if everyone could pitch in and test the crap out of things, that would be great.

    This release has had fewer contributors than previous ones, and while some put that on the shorter dev cycle, I don’t know that that’s really right, since 3 months in on any release we usually have more activity. It’s easy to leave it all to @nacin since he’s fast and everything, but we really need more people trying to break things and find actual technical bugs to help ensure that we don’t wind up shipping a release that hasn’t been widely tested. Thanks!

    (And happy holidays! Today specifically, happy Festivus!)

    • Darnell Clayton 6:36 pm on December 23, 2010 Permalink | Log in to Reply

      Festivus for the rest of us! Ironically when I was high school, I had a teacher who would “punish” students in detention by forcing them to watch episodes of Seinfeld. We all became addicts after a few weeks. 😉

      Perhaps I’ll consider “upgrading” one of my other blogs in order to test out 3.1 features. After Christmas that is (as I have to make sure my theme is compatible with 3.1 first).

    • Jon Brown 7:10 pm on December 23, 2010 Permalink | Log in to Reply

      I think the last sentence of Darnell’s comments says it, “waiting for theme support”

      Arguably the biggest feature/incentive to test 3.1 is post formats which requires extensive theme support it’s not nearly as easy to add as featured images or menu support.

      That said thanks to your plea I’m installing 3.1 on three sites today.

    • Denis 6:25 pm on December 24, 2010 Permalink | Log in to Reply

      Happy Christmas!

      And many thank you for not ruining my own year end vacation by releasing on schedule. 😉

    • Malcjohn 9:56 pm on December 24, 2010 Permalink | Log in to Reply

      Hi peope behind the WP. It’s important to say that WP is great (i also use it) and i hope that you will continue to release new versions, doesn’t matter when. I am a fan of WP, but i cant help you with PHP, just some easy HTML.

      But i want to say one thing. It’s very, very important. I will not criticise the “production of next version”, but i will tell you the truth.
      As far as i know : somebody says “the next realse will be on 15.7.20xx ” and the major improvements are …….
      Afterwards, admin make a timetable and tickets starts to be doing.

      So from this moment its a bad start to close tickets. Nobody should says when the next release will be published. It’s better to say : “we will close 250 tickets, doesn’t matter which one” (look in the trac, some tickets are should be closed in 2009 <<< something is wrong !) and only then realese a new version. We don't need a huge improvments, "but be with time" ( for example : HTML5,CSS3 etc., or just to maintain the hole WP, thought bugs etc. )

      Also i must tell, that there isn't any marketing for devs. Of course, some WP sites publish arcticles (for users only), but we have to make marketing also for the developers !!! Only they can help us to make WP better. We have less people working on it and everybody (matt, jenne) has to convience devs and just normally people to work on WP in trac. It should be prestige to work for WP, as the same for HTML5 in W3C.

      So my recommendations are :

      complettly change the release plan (dev cycle plan). Start thinking hard on a change for pre-production of next WP.

      make a lot of marketing for devs, some bonus for them. NOT MONEY, but something which matt and jenne must made up. (some small gifts). Just make WP valuable to contribute

      I really like WP and a huge thanks to nacin and other people who make it. But we have to change our habbits and start a new period of WP

      Merry Christmas to everybody.
      John from Prague,

      • Jane Wells 4:38 pm on January 3, 2011 Permalink | Log in to Reply

        Hi John. I’m sorry, but we disagree. Saying we should close 250 tickets and it doesn’t matter which ones, would mean we could have 250 tiny bugs and miss bigger ones, or that we do 250 feature tickets and don’t touch any bugs. Our releases get much more serious thought given to them, and will continue to do so. The best way to get involved for developers is to start writing patches, following the irc chats, seeing how things play out on tickets.

    • hakre 12:08 pm on December 25, 2010 Permalink | Log in to Reply

      Happy Christmas and Holidays!

      I hope all developers and contributors can re-charge their batteries these days for the amazing things to come. Enjoy yourself, family and friends.

    • Keith B Broadbent 3:15 pm on December 25, 2010 Permalink | Log in to Reply

      how can I help. i have extensive experience in WP, just had a class in html and css, working with adobe cs5

      • Jane Wells 4:40 pm on January 3, 2011 Permalink | Log in to Reply

        Testing the development beta/RC versions to help us find bugs is always good. Helping people in the forums is always good. Right now, at the tail end of the dev cycle, there’s not much to do re design or lightweight html/css, as we are only fixing unexpected bugs. We’ll start a new dev cycle the third week of January.

    • Malcjohn 6:27 pm on January 3, 2011 Permalink | Log in to Reply

      OK, it was my opinion. Still we should not say, the next realese will be xx.xx.xx, but say “when it will be, than it will be” . The same does Blizzard, a game company with their games

  • 4:39 am on February 2, 2010 Permalink
    Tags: , testing   

    To test WordPress trunk with a test install of WordPress MU:

    -Download trunk from the link at the bottom of https://core.trac.wordpress.org/browser/trunk
    -make a backup copy of your wp-config.php and .htaccess
    -do a manual upgrade of the install replacing the WordPress (MU) code to the files extracted from the zip
    -the only original files that should remain from your WordPress MU install are those in wp-content, wp-config.php & .htaccess

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