Make WordPress Core

Updates from February, 2012 Toggle Comment Threads | Keyboard Shortcuts

  • Erick Hitter 4:47 pm on February 13, 2013 Permalink
    Tags: ,   

    Revisions Update, 2/11 

    As has been the case for many sessions now, Monday’s revisions office hours focused on changes to the UI. @karmatosed provided new mockups, influenced by a thread on the Accessibility blog. @adamsilverstein also posted a series of patches on #23396 that begin to implement the general direction we’ve chosen for UI updates (aside: we’ll do our best to keep future mockups on this ticket, for easier discovery; until now, most have been posted in the comments on these update threads). We are certainly approaching a consensus on the new design, but have held off on any significant UI-specific coding until we’re confident that our efforts won’t be wasted.

    Beyond UI, there are patches on three tickets that could use testing: #16215, #22289, and #19932. @adamsilverstein and @westi are working on unit tests, which should help move the patch review along.

    We should have new mockups to review during tomorrow’s office hours at 1500 UTC in #wordpress-dev.

    [IRC log]

     

  • Daniel Bachhuber 1:52 am on February 8, 2013 Permalink
    Tags: ,   

    Editorial Flow Update, 2/7 

    Editorial flow is making progress and hitting interesting questions to answer. Our two primary tickets right now are #12706 and #23314.

    For the first, we’re waiting on feedback on the approach from @nacin. Once we’ve gotten confirmation it’s the right direction, I’ll continue working to make the patch commit-ready.

    For the second, the biggest question was how we should handle revisions for post meta and taxonomy terms. In the interest of getting to a committable patch, we’ll be dropping post meta / custom taxonomy support in favor of just being able to stage edits for the title and body content. Furthermore we’ve decided it would be worthwhile to add a new post type property so this functionality is opt-in. Posts and Pages in core will receive this by default.

    Our primary goals are to have commit-ready patches for both tickets by the beginning of next week. Konstantin’s secondary goal is to chat with @westi and @ethitter and see whether revisions for post meta is within scope for 3.6. My secondary goal is to go through other editorial flow tickets and touch base with where each is at.

    Next office hours are Tuesday, February 12th at 10 am PT / 1 pm ET / 1800 UTC.

    Office hour log

     

    • Jon Brown 2:12 am on February 8, 2013 Permalink | Log in to Reply

      Initially I was disheartened that you guys were dropping metadata support, but read the irclogs and it makes sense and I’m glad their are still advocates for adding it back in later.

      All of which I share only to say, THANK YOU, for such an open and transparent process. Really all the teams are doing a fabulous job and all the communication is hugely appreciated, so thank you for that and all the great work.

    • Erick Hitter 2:21 am on February 8, 2013 Permalink | Log in to Reply

      Tuesday office hours conflict (for me) with the WordCamp Base Theme chat, so I’ll note here that meta revisions are not in scope for 3.6.

      While the relevant tickets (#20564 and #20299) marked as 3.6, we’ve spent a good deal of time on UI/UX, and that will likely continue to be the bulk of our focus for this iteration. @nacin marked both as 3.6 because they block #23314, but we (@westi, @adamsilverstein, @karmatosed, and I) don’t have the availability to address them at this time.

    • crushgear 4:16 pm on February 11, 2013 Permalink | Log in to Reply

      Hi Daniel — you previously requested for some workflow examples. Here’s an example workflow from a WordPress.com VIP publisher:

      1) Writer puts text in WordPress and saves as “pending review” so the editor knows its ready.
      2) An editor goes in and edits the text in WordPress and schedules the post to publish, or publishes immediately if breaking news.
      3) The post goes live. 
      4) A producer goes in and updates the appropriate fields, if they are not already filled out (category, social text, SEO headline etc). Also could fix any typos found post-launch. Probably wouldn’t need approval before going live.
      5) A photo editor goes in and adds a featured image (these changes could go live without approval) and updates the post.

      Revisions:

      • Occasionally they post corrections after a story is published and those changes would need approval.
      • Occasionally they do rolling posts where they update the text or photos as an event goes on. Those updates may or may not need to be reviewed before publish.
      • Often they have rolling photo galleries where they add a photo each day as more photos come from the wire. Those changes they’d want an editor to review before updating the post.

      Suggestions:

      • It would be nice to have the ability to delete a revision without deleting the live post.
      • It would be nice to have the ability to schedule a revision to go live, so that an update can push without a person waiting around.

  • Erick Hitter 4:39 pm on February 7, 2013 Permalink
    Tags: ,   

    Revisions Update, 2/7 

    We started today’s office hours by reviewing @karmatosed’s latest mockups for the revisions screen. We’re in agreement that these reflect the direction we’ll take, so @adamsilverstein will begin coding the changes in preparation for Monday’s meeting. As some concerns have been raised about the use of red and green, @karmatosed will post to the Accessibility group’s P2 asking for feedback on the current mockups. She will also explore the use of patterns to differentiate additions and deletions, as suggested by @helen.

    @westi made a few suggestions, based on his recent experiences with Revisions, which we’ve agreed to incorporate. For clarity, the current version will be included in the revisions list to provide a stronger connection with the overall revisions workflow. Second, we decided that when first landing on the revision screen for a given post, we should show the diff of the current version and its immediate predecessor revision; since most users are probably looking for this anyway, why not save them a step?

    Lastly, we chatted about the status of code-oriented tickets scoped for 3.6. A few (#16215, #22289, and #19932) have patches, which we’ll be reviewing and providing feedback on before Monday’s meeting. With any luck, we can land at least one in Core before the next dev chat. Beyond that, development on the remaining tickets should progress over the weekend, with the aim of having more patches to review for our next office hours.

    For reference, the tickets that are in scope for 3.6 (at least at this point), can be found here.

    [IRC Log]

     

  • Konstantin Kovshenin 11:45 am on January 29, 2013 Permalink
    Tags: ,   

    Editorial Flow office hours, today (Tuesday) at 1800 UTC.

    I’ve been working on some mockups over the weekend of possible UI implementations for revising published content. Still very draft and a bunch of unanswered questions, nonetheless here are some pictures:

    So the agenda for today’s office hours is to discuss these, and maybe pick a direction (even if it’s totally different from the list above). Since there’s an overlap with the Revisions team, would appreciate if @westi and/or @ethitter popped in.

     

    • John Blackbourn (johnbillion) 1:38 pm on January 29, 2013 Permalink | Log in to Reply

      My vote goes to the first option (http://cl.ly/image/1b401P3B0d3U) which looks like it’ll work well and is surprisingly intuitive.

    • berkun 5:45 pm on January 29, 2013 Permalink | Log in to Reply

      Two thoughts:

      1. Overall the first option seems simplest (assuming these are 4 alternative designs). Only question is why the last screen is needed. It seems each of the options that show under the ‘More’ dropdown is already present. (UI redundancy can be ok, but not sure why it’s needed here)

      http://cl.ly/image/0z2w0P2f0O0V

      2. In the first design details of the publishing status disappear on the 3rd screen. Saying “This version is unpublished” expresses less information than the previous state, where it says “Published on Jan 1st. 12:54″.

      That loss in detail might be fine if we’re certain the user knows they’re working on a revision of something already published and the time it happened is irrelevant. But ideally we’d find an elegant way to tell them both info about when the original was published, *and* info that the current revision is unpublished.

      We could say:

      This version is unpublished
      Last version published at 1/21 12:45

      There’s a small can of worms here in how the schedule field behaves. It’s the only place the last published time appears, yet it goes away depending on what options the user has set.

      • Konstantin Kovshenin 6:07 pm on January 30, 2013 Permalink | Log in to Reply

        Cool, thanks for the feedback Scott! We discussed this briefly in IRC, everybody seemed to like the first version, or at least the direction. We’ll be working on it in #23314 if you’re interested. From the mockup, “view published version” actually links to the same Edit Post screen, only of the published version, so it isn’t really the preview changes button, but yes, all other options are redundant :)

    • Justin Sternberg 6:35 pm on January 31, 2013 Permalink | Log in to Reply

      The publish metabox is already a bit unwieldy without these updates for the standard blogger. What do we think about simplifying the metabox (even more than it currently is) but add functionality in the form of a click to expand type of UI?

    • Justin Sternberg 6:37 pm on January 31, 2013 Permalink | Log in to Reply

      **sorry, bad grammar** “The publish metabox is already a bit unwieldy for the standard blogger without these updates.”

      • adamsilverstein 6:42 pm on January 31, 2013 Permalink | Log in to Reply

        i was thinking the same thing, as were also talking about trying to cram a ‘revisions’ link in there on the revisions refresh.

        i like the idea of hiding with a click to expand functionality, and also the idea of really simplifying the publish box – all most users need is publish or update; move the other functionality to another box called ‘Drafts & Revisions’…

      • Justin Sternberg 6:49 pm on January 31, 2013 Permalink | Log in to Reply

        I’m not sure this is the proper time/place to discuss this, but I like the idea of a post status bar? Like a bar above title/metaboxes that displays info like published date, publish status, revision status, post-format, etc (think browser status bars). Then that info can be removed from the publish metabox and other metabox displaying post info (or hidden in a click-to-expand section of the metabox) and give the user a high-level overview of the post’s status.

        • Daniel Bachhuber 6:55 pm on January 31, 2013 Permalink | Log in to Reply

          I’m not sure this is the proper time/place to discuss this, but I like the idea of a post status bar?

          Could you share a mockup or wireframe? Also, it sounds like this could be built as a plugin first for user testing / viability purposes.

    • adamsilverstein 6:54 am on February 1, 2013 Permalink | Log in to Reply

      i created a new ticket (#23352) to track proposed changes to the publish box from the revisions team that relate to your workflow mockups. what do you think of simplifying publish and moving functionality to a new publish options box?

    • adamsilverstein 6:58 am on February 1, 2013 Permalink | Log in to Reply

  • Aaron D. Campbell 11:21 pm on January 7, 2013 Permalink
    Tags: ,   

    WordPress 3.6: Revisions 

    Revisions are an extremely powerful tool for content tracking, but there are a few parts that need a little TLC. Ever since they were first introduced, there’s been a problem with proper author attribution on revisions (see #16215), and we’re going to take a crack at fixing that in 3.6. Additionally, while the current diffs are pretty cool, and make a lot of sense to those of us that look at diffs everyday, there’s a lot of room for improvement for your average user. We’d like to see some UI improvements around the diffs as well as information that makes more sense to an average content creator (words changed, a visual representation of what was added/removed, prettier output, etc).

    @markjaquith and I chose @westi to lead this. I’m excited to see the improvements on this one! There’s a little of everything in this project, so please leave a comment if you’re interested in lending a hand.

     

    • Alex Mills (Viper007Bond) 11:25 pm on January 7, 2013 Permalink | Log in to Reply

      It’d be nice to have revisions also include post meta and taxonomy data so that when restoring to a previous revision, the whole post’s state could be restored.

    • adamsilverstein 11:28 pm on January 7, 2013 Permalink | Log in to Reply

      i’d love to help with this.

    • Rafael Ehlers 11:31 pm on January 7, 2013 Permalink | Log in to Reply

      And make define(‘WP_POST_REVISIONS’, false); works!

    • karmatosed 11:32 pm on January 7, 2013 Permalink | Log in to Reply

      I’d love to help from a UI angle on this.

    • Erick Hitter 11:58 pm on January 7, 2013 Permalink | Log in to Reply

      I’m very interested in helping with this.

    • zippykid 12:32 am on January 8, 2013 Permalink | Log in to Reply

      +1

    • janw.oostendorp 1:49 am on January 8, 2013 Permalink | Log in to Reply

      A suggestion. Can revisions be stored like only save one revision a day per post? Most of the time I would want to restore a revision I already overridden the nr I’ve set on that day. So I can’t go back to yesterday.

      Maybe save all revisions of this day and 1 for every day that is defined in `WP_POST_REVISIONS`.
      Just a suggestion.

      • Peter Westwood 9:38 am on January 8, 2013 Permalink | Log in to Reply

        This sounds like an interesting idea. I think our primary drive will be around the presentation and making it much more user friendly.

        It may be that we can alter the presentation to provide a less verbose history by default with only one revision per day highlighted while keeping the full history as well – the full history is really useful in the context of one of the key theme of 3.6 – never lose your content.

        • Curtiss Grymala 4:22 pm on January 8, 2013 Permalink | Log in to Reply

          While I think this is an interesting idea, I think it might be just as helpful (more helpful in my use-cases) if revisions were actually systematically compared at some point, and identical revisions were either dumped or not highlighted.

          For instance, let’s say I go in to look at a post (for instance, to copy a shortcode I used in it, etc.) and then, out of habit, click “Update”. Although I didn’t change anything in the post, WP stores a separate revision for that update, and shows that in the list of revisions. It would be nice if WP was able to compare that version to the previous version, recognize that nothing changed, and downgrade that revision somehow.

          I think, either way, we would need to look at somehow classifying revisions (possibly with a +1 or -1) to differentiate between revisions that should be highlighted (for reversion purposes) and those that are just stored for record-keeping (basically just to know when someone accessed the edit page for that post).

          • wedi 7:17 pm on January 9, 2013 Permalink | Log in to Reply

            That is really a big point. It’s quite annoying to click through several revisions to find the last real change.

    • esmi 2:53 pm on January 8, 2013 Permalink | Log in to Reply

      Can some of the accessibility issues associated with revisions also receive some attention? Specifically, the Compare Revisions table.

      1. As this is a form, each of the radio buttons needs an associated label. By all means, position the label offscreen if you must but without those labels, the form is virtually impossible to use in some situations.

      2. Can we have unique text for each of the Restore links? Again, position the unique fragment offscreen if necessary but handful of identical-sounding links creates major problems for some users.

      3. Ideally, get rid of the table markup. Forms + tables = accessibility problems for many users.

      • Peter Westwood 10:55 am on January 9, 2013 Permalink | Log in to Reply

        Can some of the accessibility issues associated with revisions also receive some attention?

        We will definitely look at the issues you have highlighted and see how we can best address them.

    • lessbloat 9:27 pm on January 8, 2013 Permalink | Log in to Reply

      Thought I’d play with some visual indicators showing whats changed between diffs, so at a glance you can see: “Oh ya, this is the one where I just removed on line”, or “this is the one where I removed 5 paragraphs”.

      Option 1

      Option 2

      Option 3

      Option 4

      Hat tip to MarkJaquith for the concept.

      • Aaron D. Campbell 9:33 pm on January 8, 2013 Permalink | Log in to Reply

        I really like it. Personally I think the bars are more user-friendly than the raw numbers, but I don’t have much preference between those three.

      • karmatosed 9:58 pm on January 8, 2013 Permalink | Log in to Reply

        I like the bar dots the most but my worry about any graphical indicator like that is a ‘what does it mean’. 3 red dots to me or a lump of a bar isn’t as instantly recognisable maybe to all users. I guess my question would be: “Is it important to know what of what”? If that’s the case then a number is far more indication. If a vague idea is all that’s needed then exacts aren’t as required.

        Worth exploring around other ways of representing I think aside from ones that require more maybe guess work as to what % of what?

      • GrahamArmfield 10:10 am on January 9, 2013 Permalink | Log in to Reply

        As a sighted person a visual representation can sum up a concept neatly. Unfortunately not everyone is sighted or has clear sight. Using colour as the only way to convey meaning can also be problematic – especially in your choice of red/green. Some 8% of men and 2% of women are colourblind – with red/green colourblindness being the most common.

        Any solution like this needs to also include plain visible text to indicate what the bars mean. I’d especially echo karmatosed’s point – will even all sighted users understand what’s being represented here. And how would the dots/lines represent removing some characters and adding some different ones?

      • Peter Westwood 10:57 am on January 9, 2013 Permalink | Log in to Reply

        These are neat and address a piece of the UI that I hadn’t even considered improving yet :)

        If we don’t focus on trying to condense the visualisation of the whole diff down into some coloured fragments are there ways in which we can highlight if the diff is a large or small change well?

      • wedi 7:18 pm on January 9, 2013 Permalink | Log in to Reply

        That is great! An indication if the content or just meta data was edited would be very useful, too.

      • ArielK 7:48 pm on January 9, 2013 Permalink | Log in to Reply

        I like “option 1″ it’s very clear & simple.

      • Sam Parsons 11:06 pm on January 10, 2013 Permalink | Log in to Reply

        Here’s an idea of a mockup that would show both visually and give some words to explain to those not accustomed to this type of image and to those who have visual impairments (either color-blindness or others).

        mockup of the revision interface.

        • Peter Westwood 1:30 pm on January 11, 2013 Permalink | Log in to Reply

          This is quite neat, I wonder if this is too specific though :)

          What people probably want to know is things like:

          • Is this the revisions where I fixed that typo
          • Is this the revision where the editor re-wrote my whole post

          It will be interesting if we can present something more like a graduated size of change metric which has more end-user meaning that something very technical like word count – especially when word counting is so hard to get write in some situations like some asian languages.

      • karmatosed 1:07 pm on January 18, 2013 Permalink | Log in to Reply

        I had a bit of an experiment around this area. One thing that struck me was how small the content is for that wide area. It perhaps means we can use that area to give more information – people seem to be saying different information is useful to different users so perhaps just saying the time, who and an indicator isn’t enough.

        I also thought a bit about how things like commit messages and ways and along with different representations came up with the following.

        I know it’s very different from what have now it’s more just an exploration of a few things and doesn’t have to all be used.

        • karmatosed 1:09 pm on January 18, 2013 Permalink | Log in to Reply

          I just realised that squashed it down a bit in the message so here is the original linked to see it a bit more clearly:

      • karmatosed 1:25 pm on January 18, 2013 Permalink | Log in to Reply

        I also did a different exploration using bars.

    • esmi 11:33 am on January 9, 2013 Permalink | Log in to Reply

      If you’re going with the red/green combination, please consider using numbers – not bars. http://quirm.net/temp/red-green.png shows the display as it would be seen by those who suffer from 2 out of 3 of the known forms of color blindness. Using numbers would also by-pass any issues for non-sighted users and give everyone a clear indication of the changes made.

      • Siobhan 3:07 pm on January 10, 2013 Permalink | Log in to Reply

        In terms of writing, numbers are much more useful as they provide context. Also, word count is more useful than character count.

    • talgalili 10:51 am on January 12, 2013 Permalink | Log in to Reply

      Hello all,

      I would like to ask for another feature:
      When comparing two revisions, allowing a reviewer to have an “accept/reject” for each section changed (in a similar way as offered by libre-office or MS-word), which at the end of it will create a new revision.

      Background story for the request: I recently had the need for such a feature, since I have three friends working on the same post, where one is more “senior”. The senior friend wanted to be able to accept/reject changes by the other contributors. Since this was not an option in WP, we decided to do the first draft of the post in word, and exchange it by e-mails.

      Thank you all for taking on work at this front :)
      Cheers,
      Tal

  • Jen Mylo 11:00 pm on December 16, 2012 Permalink
    Tags: , , twitter   

    Antsy for 3.6 to start and need a project? Who wants to make an official importer for the new Twitter archives? Would think we’ll want to add that into the importers list. Would suggest importer auto-assign “status” or “aside” post format (or make it an option in the plugin to choose format). Who’s in? I volunteer to ux review and test. :)

    http://thenextweb.com/twitter/2012/12/16/twitter-has-started-rolling-out-the-option-to-download-all-your-tweets/

     

    • Aaron Brazell 11:05 pm on December 16, 2012 Permalink | Log in to Reply

      I already was planning on doing this as a plugin, and I’ve been quiet for awhile. I can do this. But… I need to have the archives available to me, and my account doesn’t have it yet.

      • Jane Wells 11:26 pm on December 16, 2012 Permalink | Log in to Reply

        Mine either, but I’ll see if I can wrangle one we can use.

      • Ryan Duff 11:26 pm on December 16, 2012 Permalink | Log in to Reply

        Or as soon as someone gets and volunteers a copy of their archive. From the post it doesn’t seem there’s an api, but a set of html pages + xml, or json files (pick your poison)

        Also, from what I’ve heard they files are monthly, so if you’ve been on Twitter for 4 years you’d be looking at 48 json files to handle w/ an importer.

        Of course that’s all based off what I’ve read. I don’t have it yet. Just something to chew on.

        • Aaron Brazell 11:32 pm on December 16, 2012 Permalink | Log in to Reply

          Yeah it’ll be an interesting challenge but I wanna see what the data looks like first. If they turn it on for me, I’ve got 6 years of archives which would be a good stress test too.

          • Andrew Nacin 11:33 pm on December 16, 2012 Permalink | Log in to Reply

            Could handle the zip that they send you as-is. In fact, I imagine that would be the best approach for users.

            • Aaron Brazell 2:54 pm on December 17, 2012 Permalink

              I feel like we need to be able to parse the HTML, CSV and JSON in any zip file if we approach it that way. From the user perspective, I think you’re right but I sure hope the CSV and HTML are decent enough.

        • Samuel Wood (Otto) 11:38 pm on December 16, 2012 Permalink | Log in to Reply

          It’ll just be a matter of iterating the json. Simple stupid, for the most part.

    • Samuel Wood (Otto) 11:06 pm on December 16, 2012 Permalink | Log in to Reply

      If they actually roll it out to people unchanged, then it should be fairly trivial. When I get it on my account, I’ll let you know.

    • Phil Erb 11:25 pm on December 16, 2012 Permalink | Log in to Reply

      When archives are available to me, I’d love to help test.

    • Andrew Nacin 11:36 pm on December 16, 2012 Permalink | Log in to Reply

      We now have an API for importers, which means we can add this to wp-admin/import.php the moment it is done.

      When anyone gets access to their zip, please share it (or at least a sample so we can learn the format).

    • Aaron D. Campbell 12:29 am on December 17, 2012 Permalink | Log in to Reply

      Looks like my account has the option. I’m requesting an archive and will post it somewhere to use.

    • Myatu 6:53 am on December 17, 2012 Permalink | Log in to Reply

      Wouldn’t it be more sensible to have this as a 3rd party plugin, rather than having to maintain more bloat?

      • Peter Westwood 10:40 am on December 17, 2012 Permalink | Log in to Reply

        It will be a plugin anyway not in the core download – all the importers are plugins now.

        • Myatu 6:21 am on December 18, 2012 Permalink | Log in to Reply

          Actually forgot about that! Shows how often I’ve used that feature. I stand corrected :)

      • Jane Wells 11:39 am on December 17, 2012 Permalink | Log in to Reply

        As @westi states, all importers are plugins, not core code. I didn’t specify that in my post, since I took it as a given that core developers know that.

    • Simon Wheatley 8:34 am on December 17, 2012 Permalink | Log in to Reply

      Note that the current Twitter IDs overflow (?) and corrupt if you convert them to integers on a 32bit system. That one has got me before. (Apologies if that’s teaching everyone to suck eggs.)

      Also, would you mind putting in a filter for the post data before save… I’d prefer to store tweets in a custom post type. Ta! :)

    • Andrew Nacin 6:49 pm on December 17, 2012 Permalink | Log in to Reply

      I’ve outlined a potential plan for such an importer on a Trac ticket: http://core.trac.wordpress.org/ticket/22981. If you want to continue to discuss the idea, feel free to do so here. Implementation can occur on the ticket. (This is a plugin, but an official importer is also a core priority, hence the use of core trac.)

      I’ve also uploaded a tweet archive contributed by @chadhuber to the ticket. It does contain sane json.

    • Beau Lebens 9:23 pm on December 17, 2012 Permalink | Log in to Reply

      In case it helps, I already made one, packaged in here: http://wordpress.org/extend/plugins/keyring-social-importers/

  • Andrew Nacin 5:12 pm on September 20, 2012 Permalink
    Tags: , ,   

    Timeline for Twenty Twelve 1.0 — final testing window 

    During the dev chat yesterday (logs), it was determined that the timeline for Twenty Twelve’s release to the WordPress.org theme directory will be next week.

    That means if you have any bugs to report against Twenty Twelve, please do so now! It’s time for final reviews. Once 1.0 is released, it will be very tough for us to make style or code changes, as we will then need to avoid breaking child themes (both code wise, and stylistically).

    So, if you haven’t looked at Twenty Twelve yet, now’s the time. Here’s the demo site: http://twentytwelvedemo.wordpress.com. Also, if you’re using the Beta Tester plugin instead of a checkout from Subversion, you may not have Twenty Twelve installed and up to date. In that case, here’s a direct link to download a ZIP.

    (@westi, @dd32, we should adjust how beta theme installs are handled…)

     

  • Jen Mylo 7:29 pm on June 24, 2012 Permalink
    Tags: beta tester   

    @westi: Could we add an option in the beta tester plugin to revert to latest stable? With beta tester activated, then deactivated, the version remains the beta version (and beta tester stuff about nightly build stays on Updates screen for some reason). Would be good to be able to revert to stable for troubleshooting purposes.

     

    • Jane Wells 7:56 pm on June 24, 2012 Permalink | Log in to Reply

      (Even after deleting plugin and associated filed via admin, the Updates screen still acts like beta tester is active.)

    • kurtpayne 8:00 pm on June 24, 2012 Permalink | Log in to Reply

      How would we roll back database updates?

    • mbijon 12:29 am on June 25, 2012 Permalink | Log in to Reply

      +1 to this idea.

      …but the database revert process is a problem: If we create a database backup and revert to it, then there’s a risk that new data will be lost. The extra work isn’t great, but it sounds like every upgrade script might need a counterpart downgrade script.

    • Marc Hindley 1:16 am on June 25, 2012 Permalink | Log in to Reply

      This feature would be great, not just for beta version, but for any release version, where a plugin might not work after an update, at least for testing purposes. But @mbijohn is right, new data could be lost, so the only way I can think of, is to document the db upgrades and reverse them rather than restoring a backup. That would have the added benefit, that you could select your version to roll back to, or roll back one at a time. It would certainly make upgrading less of a fear, although it might tempt laziness on the part of the plugin developers.

    • Peter Westwood 9:15 am on June 25, 2012 Permalink | Log in to Reply

      This might be possible :)

      I don’t think trying to do a database backup and revert is going to be simple but it is probably possible to get you back to the latest stable version. I’ll take a look into this.

    • Alex Mills 6:15 pm on June 25, 2012 Permalink | Log in to Reply

      Just to play devil’s advocate, if people are running betas then they should be capable of backing up their database, etc. and they shouldn’t be running it on a site they care about if not.

      By running a beta, you’re taking the risk that something will break.

    • Jon Brown 9:54 pm on June 25, 2012 Permalink | Log in to Reply

      Would it work to check the database version and only allow rollback if the database version hasn’t been incremented.

      I don’t follow core close enough to know if the DB versions get incremented for changes to trunk nightly, or only when there is a new tagged/released version…

    • Mert Yazıcıoğlu 10:24 am on June 26, 2012 Permalink | Log in to Reply

      Beta Tester Plugin is not supposed to be used on a live site so I don’t think losing the new data should be a concern.

      Though, I heard that WordPress Move makes backing up and restoring from a backup process a snap ;)

    • Shapeshifter 3 12:41 pm on June 27, 2012 Permalink | Log in to Reply

      Alex is correct, and I myself am guilty of running both beta and/or nightly build versions on my live site. Up until now I have not been damaged by the risk, but I frequently update my database on my hosted server and use the bleeding edge nightlies to correct any short-term programming errors or misses.

      What I have noticed as a non-developer user is that currently both WordPress 3.4.1 and 3.5 are being developed at the same time. WP 3.4.1 was offered only on the “Point Release Nightlies” but did not actually offer nightly updates. WP 3.5 is offered on the “Bleeding Edge Nightlies”. If I wanted to trim my risks, having the 3.41 version also offered on “bleeding edge nightlies” would help out. If multiple versions of WordPress are being developed at the same time, it seems (and I might be wrong) that having the choice to use either the “point release” or the “nightly builds” for the WordPress versions being developed might alleviate some of the risks for a non-professional user.

      I just disabled and uninstalled my beta tester, and Jane is correct in that my site is still in version 3.4.1 RC-1 and informs me that a newer version is available for update.

      • Alex Mills 4:44 pm on June 27, 2012 Permalink | Log in to Reply

        I run trunk (updated via a “svn up” cron) on my live site as well but I also have automated backups in the event that something goes terribly wrong.

        Only 3.5 is actually being developed — the 3.4 branch just receives backported bug and security fixes from trunk (aka 3.5 right now). No new features go into the branches (like 3.4) that need actual testing.

        EDIT: Or simply put, development happens in trunk with important fixes being backported to the latest branch.

  • Andrew Nacin 10:40 pm on February 16, 2012 Permalink
    Tags:   

    Results of 2/15 Dev Meeting 

    The teams and status document has been updated to reflect current cycles. Yesterday’s dev meeting focused on identifying issues pertaining to blockers and resources, and whether any adjustments or corrections needed to be made, across all teams. As I didn’t keep a general summary, you may find the log is here.

    I did take notes on who needs resources from whom:

    • @petemall and @MarkJaquith will be discussing #19796 and #19235 with @ryan and @nacin
    • @westi and @maxcutler will be discussing capabilities in XML-RPC and APP with @ryan, @nacin, @kurtpayne
    • @getsource and @helenyhou need @azaozz and @dkoopersmith to go over the scrolling JS
    • @jane and @helenyhou: screenshots review
    • @jane and @petemall: autocomplete UI review
    • Also @jane: Review HTML in captions UI (if necessary) and header changes

    And there may be a few others I didn’t catch. Ideally this will all happen before our meeting next Wednesday.

    Two teams were added: @georgestephanis and Zach Abernathy (thezman84) working on tablets, and @aaronjorbin working with Tom Auger (tomauger) on favicons. I have been communicating with both teams to help get things off the ground.

    If you want to get involved, there are 198 open tickets on report 5, many of which fall under no team. If they do, find the team during office hours or contribute directly to the ticket, as many have done.

    Next meeting is 2/22 at 2100 UTC.

     

  • Joseph Scott 4:09 pm on February 13, 2012 Permalink
    Tags: ,   

    Team Update: Bugs-RPC

    Our first cycle closed on Friday. Only three of the original tickets on our list have been committed so far, with others at various steps closer to commit readiness.

    The plan for our second cycle is to continue wrap on our original ticket list. If that completes with time left over we’ll begin adding more test code to @westi‘s new RPC test code.

     

← Older posts

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel