Ready to get started?Download WordPress

Make WordPress Core

Updates from December, 2012 Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Nacin 7:51 pm on January 3, 2014 Permalink
    Tags: ,   

    The email used for notifications on Trac is currently specified in Trac preferences. I’m changing this to pull automatically from your WordPress.org profile. After this change, there will not be a way to have a separate email address for Trac and any manually specified email address will be overridden.

    We need to make this change because, very simply, it’s a better user experience. By killing this extra user preference, it’s one less step users need to set up in order to receive notifications. (And a tighter feedback loop could possibly boost engagement.)

    That will affect about a thousand users we have in the system, probably incidentally for most. But, about 50-100 users might have been deliberately declaring a separate email address; for example 50 users had “trac” appear specifically in their email. Even without a dedicated email, it is trivial to filter Trac emails; you just might need to make some adjustments.

    As you may have noticed, this is part of a series of changes I’ve been making to Trac. I’ll be doing a summary post in a few days outlining everything that has changed.

    NOTE: This does not affect wp-trac@lists.automattic.com. If you subscribe to the “firehose” this is not affected.

    Edit, 20:23 UTC. This is now enabled. For the moment, the email address will sync when you next visit Trac. Please find me if you have any questions.

    • Ionel Roiban 7:55 pm on January 3, 2014 Permalink | Log in to Reply

      Sounds good.

    • Ryan Duff 7:57 pm on January 3, 2014 Permalink | Log in to Reply

      Is there an ETA on the time this will be changed?

      I’ll have to update my email filters on my .org acct and would like to have it ready to test so my phone doesn’t blow up some night when I’m sleeping.

      That’s why I used a specific “list” acct ;)

      • Ryan Duff 7:59 pm on January 3, 2014 Permalink | Log in to Reply

        Err wait, this is the notification email, not the list email. I may be fine as I think that goes to the same email on my .org profile already.

        Heads up may still be nice for the handful that will have to adjust though.

      • Andrew Nacin 8:00 pm on January 3, 2014 Permalink | Log in to Reply

        Sometime in the next 1-72 hours.

        Note — you have the same email address in both Trac references and your WordPress.org profile. If you were referring to the firehose mailing list, that’s not affected. I’ve added a note to the bottom of the post.

        • Ryan Duff 8:13 pm on January 3, 2014 Permalink | Log in to Reply

          Yup. I’m using a separate address for the svn/trac mailing lists. When I went to verify email filters I realized that the ones that come through as trac notification went to the email on file for .org.

          This week has been a bumble from the start. At least it’s Friday. Thanks for following up!

    • Andrew Nacin 8:08 pm on January 3, 2014 Permalink | Log in to Reply

      Here is a short list of names I recognize who this will affect: @westi @dd32 @viper007bond @sterlo @coffee2code @chmac @eddiemoya @kawauso @lloydde @mrmist @ptahdunbar.

      In most cases, though, the user updated their WordPress profile but never bothered to update Trac. That’s why we’re doing this!

    • Eddie Moya 7:38 am on January 4, 2014 Permalink | Log in to Reply

      I did use “+trac” in my email address to filter for it, so I really appreciate that you went through the effort of figuring out who might specifically affected by it. Otherwise I would have been confused about why my filters stopped working, since this is something I haven’t touched in a very long time.

      Idk if the list is just really that short of people affected – but maybe it would make sense to send out a blast email on trac to let everyone know that way in case they aren’t lucky enough to be the 11 names you listed. Just a thought.

      Thanks again for the heads up.

  • Andrew Nacin 9:26 pm on December 31, 2013 Permalink
    Tags: ,   

    Commit announcements for 3.9 

    Lots of news to share! First: Helen Hou-Sandí has had guest commit for the past three release cycles. She’s been spending the last year reviewing contributions, mentoring contributors, and working on some of our larger UI projects. I’m proud to announce @helen is now a permanent committer to WordPress!

    We’ve invited John Blackbourn (@johnbillion) to be a committer for the 3.9 cycle. His strong, consistent contributions have been backed by excellent judgment and temperament.

    Matt Thomas, who led the dashboard redesign in 3.8 (and 3.2, and 2.7, etc.), will keep his commit to continue to maintain and improve WordPress UI. He’s been a great mentor to many contributing designers and his long-term impact is indelible.

    For the last few years, we’ve been granting commit access on per-cycle basis, sometimes for a particular component, feature, etc. Generally, after about a year, a guest committer can be considered for permanent commit access. Dominik Schilling, Sergey Biryukov, Drew Jaynes, and Scott Taylor have all had their commit extended for 3.9.

    Drew (@DrewAPicture) was given temporary commit for inline documentation starting with 3.7. He’s been heading up the long-running initiative to document every hook in WordPress. Scott (@wonderboymusic) also started committing during 3.7, and has a particular penchant for digging deep into the query and taxonomy APIs. And Sergey (@SergeyBiryukov) and Dominik (@ocean90), well, they are forces of nature.

    (@aaroncampbell was also given guest commit in 3.7, but he ended up not having much time to use it.)

    Here’s a full list of those with permanent commit: @markjaquith, @ryan, @westi, @matt, @azaozz, @dd32, @koopersmith, @duck_, @helen, and me (@nacin); @lancewillett for bundled themes; @iammattthomas for UI. You might have also seen commits before from @josephscott (XML-RPC), @nbachiyski (internationalization), and @mdawaffe (secret weapon for really tricky problems).

    Next weekly meeting is January 8. Happy new year, everyone. Here’s to a great 2014.

  • Andrew Nacin 2:26 am on July 28, 2013 Permalink
    Tags: post types, ,   

    Potential roadmap for taxonomy meta and post relationships 

    In the days before the WordPress Community Summit in October, a number of contributing developers huddled together to discuss a number of long-term architecture ideas. Among them were taxonomy meta and post relationships. (Ah, I see I now have your attention!) This post is more or less a proposed roadmap. It’s an ambitious plan that is designed to take place over perhaps five or more releases.

    (During WordCamp San Francisco’s keynote, @matt talked a little about a new aim to build teams of contributors and reviewers around individual core components. There will be a lot more on that in the coming days and weeks. For now, here’s a post that covers two components, post types and taxonomy.)

    The discussion included all core committers at the time — @ryan, @markjaquith, @westi, @azaozz, @nacin, @dd32, @koopersmith, and @duck_ — and a number of contributing developers, including @aaroncampbell, @dh-shredder, @helen, and @scribu.

    At the moment, terms are represented in WordPress using two different IDs: a term ID, and a term taxonomy ID. A term ID (and name and slug) can actually appear in multiple taxonomies, so to identify a particular term, you must have either the term ID and the corresponding taxonomy, or just the term taxonomy ID. This dates back to the original taxonomy schema in WordPress 2.3. At the time, the concept of “shared terms” seemed like it could be an important abstraction. Hindsight is 20/20, and shared terms are the bane of taxonomies in WordPress.

    So when we talk about term meta, we’re actually talking about term taxonomy meta — meta associated with a term taxonomy ID, not a term ID. The problem is, the public ID used in the API and elsewhere is the term ID (and, by necessity, a taxonomy is also passed). This confusion — and the need for there to be only one object identifier in our metadata API (term taxonomy ID, not two, as in term ID and taxonomy) — has long forced us to table the discussion of term metadata.

    (There are separate conceptual issues here — at what point does a term with metadata simply become a post-like object that can relate to other posts? And given post relationships, could terms and posts actually converge in their underlying schema? I’m not actually going to answer those questions in this post. Purely talking schema and architecture at this point.)

    At WordCamp San Francisco last year, four of us — me, Gary Pendergast (@pento), @scribu, and @koopersmith — came up with a rather crazy way to make major changes to our table schema while still being backwards compatible. In fact, we came up with two ways to do it. This was the plan everyone heard and discussed at the summit.

    It was clear that shared terms had to go. The first step is removing a UNIQUE index on the slug field in the wp_terms table. (This is dependent on #17689.) Then, we stop creating new shared terms. Step three, on an upgrade routine, we actively look for any existing shared terms and split them.

    These three initial steps must happen over two to three major releases, as we’re talking about a bug fix, a schema change, an API change, and an upgrade routine — in that order.

    Then comes the fun part, in yet another major release. With shared terms split, term ID and term taxonomy ID will be identical  on every install.  If we moved the slug and name fields from wp_terms to wp_term_taxonomy, we could actually drop wp_terms.

    How can we remove an entire table but still be backwards compatible? We came up with two solutions:

    1. Because all fields in wp_terms will exist in wp_term_taxonomy, wp_terms can be recreated as a MySQL view to be a read-only mirror of term data, thus being compatible with all existing queries.
    2. Because all fields in wp_terms will exist in wp_term_taxonomy, and because table aliases like `t`and `tt` are always used when joining these two tables, $wpdb->terms can simply be set to $wpdb->term_taxonomy. A query that previously joined wp_terms with wp_term_taxonomy would just join itself.

    In all: Using the second approach (yes, it works), it took about 20 lines of code to make WordPress run without a wp_terms table. Wow, right?

    So by this point, we would finally have a sane taxonomy schema. Less joins, a cleaner API (probably helped by a new WP_Term object to model WP_Post and WP_User), no more shared terms headaches, and a single, sane ID for a single taxonomy’s term.

    Once that is all finished, we can finally have term meta. Maybe. (Kidding. (Kind of.))

    Where do post relationships come in? The existing Posts 2 Posts plugin by @scribu is fantastic and serves the niche well. But we’re not really comfortable making any architecture or API changes along these lines while our taxonomy schema is still in a far from ideal state.

    The post relationships plugin supports posts to posts, and posts to users. Core taxonomy relationships supports posts to terms, but it can also be rigged to relate users to terms. (It also supported links to terms, yet another object type.) We didn’t fully iron out this idea yet, but one idea is to convert the current wp_term_relationships table to a more generic object relationships table, which can support posts to posts, posts to users, terms to users, and of course posts to terms (and, really, any arbitrary relationship).

    A disclaimer: This post doesn’t promise anything. Do not rely on the contents of this post for future projects.  It will take us some time to lay out the proper groundwork and make sure we get this right. Do not expect this to happen in WordPress 3.7, or even 3.8. (Actually, do not expect this to happen at all.)

    That said, I’m really glad to get this information out there and I’m excited to hear any feedback you may have. We are always thinking toward the future, and a lot of contributing developers have mile-long roadmaps in their heads — it’s long past time to get those on paper.

    • Scott Taylor 2:39 am on July 28, 2013 Permalink | Log in to Reply

      `WP_Term` should happen as soon as possible. Proper modeling, fix caching, etc

      • Andrew Nacin 6:26 am on July 29, 2013 Permalink | Log in to Reply

        Yes, but ideally we wait until we have a single ID to pass around. It really needs to be term_taxonomy_id, but we don’t pass it around anywhere else in the UI.

    • Jon Brown 2:44 am on July 28, 2013 Permalink | Log in to Reply

      Will this happen for 3.7? j/king… I read every beautiful word of this post including the disclaimer. This all sounds brilliant. TaxID/TermID confused the heck out of me for a LONG time as a new to WP developer.

    • Scott Kingsley Clark 4:06 am on July 28, 2013 Permalink | Log in to Reply

      Excited about all the above, will watch like a hawk at how things go and be available to test and implement changes in my own projects!

    • Manny Fleurmond 4:52 am on July 28, 2013 Permalink | Log in to Reply

      Keeping an eye out for developments. The things that could be possible with connecting posts, terms, users, etc in all types of relationships (one to one, one to many, many to many) is mind boggling. This would definitely help plugins like bbPress and cause an awesome boom of innovation in the WP plugin development community. I wait and watch with baited breath.

    • Grant Palin 5:14 am on July 28, 2013 Permalink | Log in to Reply

      The two terms tables have puzzled me for a while. Now I see it is due to the way core is set up. So it’s interesting that you are looking at correcting the core setup and simplifying things a bit. WP_Terms sounds good, and will help improve the image that WordPress has among some coders as being poorly coded. And not least, the possibility of having content type or term relationships in core would be excellent, and further the ability of WP to be a CMS out of the box.

    • Mike Schinkel 5:22 am on July 28, 2013 Permalink | Log in to Reply


    • Shane Pearlman 5:51 am on July 28, 2013 Permalink | Log in to Reply

      + yay

    • rfair404 7:01 am on July 28, 2013 Permalink | Log in to Reply

      Both are great ideas. I want to play.

    • Avryl 8:29 am on July 28, 2013 Permalink | Log in to Reply

      Awesome! :D

    • Hassan 9:42 am on July 28, 2013 Permalink | Log in to Reply

      For the past two weeks or so I was always thinking about taxonomy meta, whether WordPress will ever support it or should I just go with workarounds (e.g. wp_options). Then all of a sudden @nacin wrote this post! Yay!

      Even though it’s not here yet (hey come soon already!), I’m already planning for some projects! (Yeah, I read the disclaimer :))

    • Julien 10:13 am on July 28, 2013 Permalink | Log in to Reply

      Great news! The future is bright with WordPress. This will open up everything and Worpress will be seriously taken as à tool for web application! Can’t wait to see this released for Wp 3.9 (kidding;))

    • Mike Little 11:24 am on July 28, 2013 Permalink | Log in to Reply

      For those who need to work now with the idea of Term/Taxonomy metadata, there are some plugins already out there. I have successfully used “Taxonomy Metadata” (http://wordpress.org/plugins/taxonomy-metadata/) in a project; also “Meta for taxonomies” (http://wordpress.org/plugins/meta-for-taxonomies/) looks interesting.

      A question: the current system (sort of) supports synonyms/aliases for terms, which can be very useful: are there plans to retain this functionality?

      • Rahe 8:03 am on July 29, 2013 Permalink | Log in to Reply

        Meta for taxonomies is perfect, it uses the WordPress meta API and is only an API ( like the WordPress post_meta ).
        I use it very often, the only problem is there is no easy way like the posts meta box to display/edit the meta in the admin.

      • Andrew Nacin 8:13 am on July 29, 2013 Permalink | Log in to Reply

        I’ve almost never seen it used, but no plans to remove that functionality. This should continue to work just fine. Worth pointing out that any shared terms will be split which could possibly break aliases. Something to keep in mind.

    • aristath 12:30 pm on July 28, 2013 Permalink | Log in to Reply

      This conversation brings in mind what happened on Drupal 6 when it became Drupal 7. I know Drupal and WordPress are 2 completely different things, but bare with me.

      On Drupal 6, there were taxonomies and nodes. Something similar to out terms and posts… And the database structure was also similar to what we have now.
      On Drupal 7 however, they decided to make some radical changes. There were no longer nodes and taxonomies, everything was an “entity”. The database structure was significantly simplified and allowed it to move forward as a CMS.
      Ideally this is the direction I would love to see on WordPress… and this sounds like a first step to that direction.

      The proposed solutions are both viable, though I find the 2nd one more compelling.

      • Andrew Nacin 8:15 am on July 29, 2013 Permalink | Log in to Reply

        Yeah, we’re aware of this. It’s certainly something to at least think about. But I don’t think a generic “entity” makes sense for us.

        I’ll share that, according to folklore, the current taxonomy schema was actually inspired by Drupal’s own schema. And we know how that went. :-)

    • Charles Frees-Melvin 2:25 pm on July 28, 2013 Permalink | Log in to Reply

      What if there was a single meta table and a meta_type filed that has “posts”, “comments”, “users” in it. It would make meta more versatile to extend to taxonomies once taxonomies are ready for it. Kind of like we did to categories and link categories when we came up with the terms/taxonomies system.

    • Mike 2:47 pm on July 28, 2013 Permalink | Log in to Reply

      Does this mean I won’t be able to use one taxonomy term with two different taxonomies?
      Because I thought that was the perfect bug –>>feature scenario.

      • Matt Van Andel 11:57 pm on July 28, 2013 Permalink | Log in to Reply

        This wouldn’t affect that at all. Currently, taxonomy terms are an overly-normalized nightmare. If you create a Category called “Foo” and a Tag called “Foo”, only one term is added to wp_terms and then it is associated with the taxonomy in wp_term_taxonomy. The weird thing about this is that there is only entry in wp_term_taxonomy for each term, even though the normalized terms are listed in wp_terms. It is, frankly, really stupid… but as @Nacin said, hindsight is 20/20.

        What is being proposed is that those two tables are merged. You could still have identical terms in multiple taxonomies – but how they are identified in the database and by the API would change to something a little more sane.

        • Mike Schinkel 5:39 pm on July 29, 2013 Permalink | Log in to Reply

          taxonomy terms are an overly-normalized nightmare.

          Actually, if it had been normalized it would likely be much less of a nightmare. As-is the current schema causes E. F. Codd to turn over in his grave.

    • Robert Chapin 4:29 pm on July 28, 2013 Permalink | Log in to Reply

      Excellent direction.

    • Stephanie Leary 8:09 pm on July 28, 2013 Permalink | Log in to Reply

      I will now find @nacin and give him a hug.


    • portfola 8:43 pm on July 28, 2013 Permalink | Log in to Reply

      This is a welcome development, thank you!

    • Matt Van Andel 11:33 pm on July 28, 2013 Permalink | Log in to Reply

      Finally! These are all things that have driven me crazy for as long as I’ve been developing for WordPress.

      But over at *least* 5 major versions? Ugh. Post 2 Post is a decent bandaid, but that’s functionality that we need in core as of yesterday. What is the reasoning for spacing out the rollout that much? Is it just to minimize potentially breaking changes? Are there ways we can accelerate the process?

      • Japh 11:36 pm on July 28, 2013 Permalink | Log in to Reply

        If you have a listen to Matt’s State of the Word talk, you’ll note that the plan is to speed up update and release cycles generally. So this could happen over a shorter period of time than you might think, despite being over a number of cycles.

        In fact, I imagine it’s this type of thing that’s part of the reasoning behind speeding up the cycles: bigger changes can happen faster.

      • Andrew Nacin 10:43 am on July 29, 2013 Permalink | Log in to Reply

        As the post tried to carefully outline, this requires a significant number of schema, API, and architecture changes. Database upgrades can be very painful, especially with the very real potential of significant amounts of data to modify and migrate here — we need to make sure that we don’t try to bite off too much each release.

        There’s nothing wrong with Posts 2 Posts being in a plugin. You’ll note this post doesn’t actually promise post relationships — it’s entirely possible we leave it out of core for the long term. I’m not saying it’s likely, but my point is that not only is there not a way to accelerate this process, but that there isn’t a need for it either.

        • Taras Mankovski 5:28 pm on July 29, 2013 Permalink | Log in to Reply

          > There’s nothing wrong with Posts 2 Posts being in a plugin.

          This reads like a Jedi mind trick: “You don’t need this… Go back to work.”

          “I don’t need this… I’ll go back to work”

    • sboisvert 4:14 am on July 29, 2013 Permalink | Log in to Reply

      I’ve thought about this. And I’m happy smarter people have also thought about it and now have a good plan to fix it :)

    • Frank Bültge 10:04 am on July 29, 2013 Permalink | Log in to Reply

      @Nacin Thanks for the status. This are very nice news.

    • Michael Dance 5:00 pm on July 29, 2013 Permalink | Log in to Reply

      This sounds like a really, really sharp approach. Great job so far.

      As a heavy Posts 2 Posts user, I just want to mention that post relationships have pretty much eliminated my need for term meta.

      As a simple example: say you have a Journal Article post type and a Journal Issue taxonomy. Each term is a different journal issue, but for each one you’d want an image, a masthead — more than a term can provide. So that’s where term meta could help.

      But: with post relationships, you can just make Journals a post type and relate each journal to a bunch of articles that way. Suddenly journals have access to post meta, featured images, the works.

      I’m not saying I don’t want term meta at all, but there is a danger that it could open the door to terms and taxonomies being used way beyond the scope of what they’re meant to do and muddy the lines between term and post. And while post relationships can cover most of the use cases of term meta (if I’m wrong on this, I’d love to see some examples), the opposite is definitely not true, so to me, post relationships are the bigger priority.

      (All that said, I know that this is a long way off, and in the meantime I’m just as excited about getting rid of the shared term abstraction and creating WP_Term.)

    • Ben Huson 7:11 pm on July 29, 2013 Permalink | Log in to Reply

      Nice to see this on the roadmap – even if we should “not expect this to happen at all” :)

    • Marcus 12:46 pm on July 30, 2013 Permalink | Log in to Reply

      this will be awesome!

    • Allstar 9:14 pm on July 30, 2013 Permalink | Log in to Reply

      I’m all for progress…

      What about internationalisation?

      I’ve wanted for ages for the term_taxonomy tables description field to be moved into the terms table. Therefore all the language would be in one place and the data in another.
      So, you would only use the term_taxonomy_id as a primary for getting stuff BUT you could have multiple terms (in different languages) associated with it. You would not go to the terms table first to find something unless it was by text lookup.

      A WP_Term object is a big *like* from me but I’d l’d also like WP to be easier on the international side of things and my above comment on how to do international user entered terms would be a good step.

      Of course I’m no Core Developer big wig so I might’ve overlooked something but it’s at least worth mentioning in case the idea had been overlooked or I overlooked a way of doing it.

    • shawfactor 7:18 am on July 31, 2013 Permalink | Log in to Reply

      @nacin the speed and modelling improvements would be nice but the can you elaborate further on how you would extend the current taxonomies which are doubles into triples without having a redundant field on the doubles?

      Also I think Posts 2 Posts plugin by @scribu is nice but as I’ve argued: http://shawfactor.com/b/gaA

      post relationships need to be in the core and they nheed to be semantic.

    • Chris Lema 2:53 pm on July 31, 2013 Permalink | Log in to Reply

      +1 for doing it over several releases (even if it’s slow). Quick DB changes have tons of unintended consequences. Great write up.

    • AzzX 12:10 am on August 2, 2013 Permalink | Log in to Reply

      I have used CPTonomies and Posts to Posts to achieve more functionality though they are hacks and susceptible to being discontinued and breaking. This is where Drupal excels. If I want to have ratings and comments on a specific Taxonomy I can – without hacking the core.

    • grindcode 12:10 pm on August 2, 2013 Permalink | Log in to Reply

      This is the last milestone WP needs to approach any needs. Good stuff!

    • Chuck Reynolds 10:43 am on August 3, 2013 Permalink | Log in to Reply

      needs to happen.. might as well start the move and roll it out slow.

  • Alexander Hoereth 4:33 pm on June 25, 2013 Permalink
    Tags: ,   

    Code Revisions: Week 1 

    My initial post did get quite some feedback – not overall good. I expected the negative feedback. I did not take part in the discussion, but I think others did a nice job there (thanks Jen & Aaron). Also thanks to the developers who offered to give support when I might get stuck.

    To make it short:  I already prepared myself for this project before the official coding phase started and could skip the initial “warm up phase”. At the moment I am ahead of the timeline.

    This week mostly was on the connection between a file and a post (#284), the initial creation of a post when a file is edited for the first time (#285) and the updating of the corresponding post on every edit (#287). I also chatted with my mentors about the brought up security worries. We will definitely look into those and discuss them (and possible solutions) with lead developers – the code resulting from this project will not make it into core if it introduces security flaws!

    The next week will be about viewing code revisions. This on the one hand includes a revisions list which needs to be added below the editors (#286) and on the other hand fixing possible problems with the revisions view on revisions.php (e.g. #289). I will take the negative feedback as a challenge and still hope to get code revisions into core. Till next week then.. Comments are open!

    • George Stephanis 4:39 pm on June 25, 2013 Permalink | Log in to Reply

      Sounds good!

      RE: Viewing Code Revisions, this is already mostly functional in things like the Custom CSS module in Jetpack, which stores the data as a Custom Post Type.


      It’s probably a quick win, for the moment at least.

      • ahoereth 11:01 pm on June 25, 2013 Permalink | Log in to Reply

        Thanks! Didn’t know jetpack already does something similar. I guess most of the actual revision viewing won’t need any specific changes. Thats exactly why this project is about “WordPress native” code revisions: Most stuff is already there and just needs some adjusting.

        • George Stephanis 11:25 pm on June 25, 2013 Permalink | Log in to Reply

          Yup. The Jetpack Custom CSS module just stores it in the DB and then enqueues something that outputs it in the header — no files required.

          The Revisions formatting is new in 3.6, @westi and @ethitter led the charge on that front.

          It may be nice to use something to do syntax highlighting on the diffs and such, though, for the revisions.

    • Nile Flores 6:03 pm on June 25, 2013 Permalink | Log in to Reply

      I’ve got a concern on the permalink structure. This was actually brought up originally in my FB group All About WordPress – https://www.facebook.com/groups/AllAboutWP/permalink/630256080319512/ . One of the users has 3.6 installed on her live site and is saying that WordPress is automatically editing the permalink structure for the user.

      This is not web etiquette. I don’t like my permalink structure to be altered automatically and its a pain if I have to alter them to add words, rather than just cut out what I don’t want.

      It seems I am not the only one with this concern. NOW, if there were an option to disable or enable it in the feature, this would be great because at the moment there are none.

      In fact, I am confused where I should be saying this, but it is obviously something that needs addressed.

    • Nile Flores 6:07 pm on June 25, 2013 Permalink | Log in to Reply

      I apologize… 3.5.2 this is occurring. And no plugins are installed that have this ability in it. Strange? Or should I submit this to the support forums?

    • Erlend Sogge Heggen 8:55 pm on June 25, 2013 Permalink | Log in to Reply

      For the record I think this is a brilliant project, and I’m pretty sure the majority of WP users would agree with me. From what I could tell, the criticism you have received is poorly misguided and only represents a very small minority.

      The only thing that worries me about code revisions is that child theme shops like Studiopress can now make a stronger argument for premium child themes. The devs better be weary of that trend.

      • ahoereth 11:02 pm on June 25, 2013 Permalink | Log in to Reply

        Thanks for the support :) Why do you think code revisions give theme shops stronger arguments for premium child themes? Not sure I get what you are referring to.

      • Aaron D. Campbell 2:29 pm on June 26, 2013 Permalink | Log in to Reply

        I’m not sure what you mean about premium child themes. As far as I know, that’s all StudioPress does. I think all their premium themes are built as child themes for their Genesis framework. I don’t think it’s a trend to be wary of, I actually think it’s a great way to do premium themes.

      • Ipstenu (Mika E.) 3:31 pm on June 26, 2013 Permalink | Log in to Reply

        What’s wrong with it? A theme is a theme, and if you edit someone else’s child theme (by the way, StudioPress -rarely- changes theirs) then you’re in a less-worse spot, since you have your code changes saved as revisions now. yay! :) Isn’t that the goal?

  • 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.


      • 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.


      • 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)


      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


    • 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 :)

  • 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. :)


    • 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/

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