Make WordPress Core

Updates from December, 2012 Toggle Comment Threads | Keyboard Shortcuts

  • Mark Jaquith 7:42 pm on January 7, 2013 Permalink
    Tags: ,   

    WordPress 3.6: Autosave and Post Locking 

    I want, as a major 3.6 bullet point, that we should never lose posts due to expired cookies, loss of connection, inadvertent navigation (even if AYS’d), plugin or core errors on save, browser crashes, OS crashes, cats walking on keyboards, children drooling in keyboards, etc. I want people to trust WordPress with their posts. They should never fear that something they’ve spent time creating or editing should go away due to their mistake or ours or that of a third party. Mistakes and errors should be recoverable. I can’t stress enough how important it is that people believe this and have good reason to believe it. If a post gets lost, there is a catastrophic loss of trust, that could take years to be regained (if indeed it ever is). This is people’s time and their creative output we’re talking about. If we’re not valuing those things above all else, then our priorities are seriously out of order. This is an all-hands-on-deck item for 3.6. Even if you’re not actively working on the code or the copy or the UI or the UX I want you to be thinking about ways in which WordPress could better treat your creative output as the valuable artifact it is.

    Things this will likely involve:

    • Local storage of post data while editing, in-between autosaves and manual saves.
    • More frequent “heartbeat” pings to the server (allowing data to hitch a ride at certain intervals, and also allowing us to quickly deliver messages back from the server about events).
    • Real and more granular post locking. Right now we just have a wimpy notice that isn’t a good deterrent against people simultaneously editing a post and overwriting each other’s changes.
    • Probably some interaction with the team working on improving Post Revisions.
    • UX work for making recovery from failure scenarios smooth, clear, and worry-free.

    @aaroncampbell and I have chosen @azaozz to lead this, as it will probably be very JavaScript-heavy. There are a lot of moving parts here, so please leave a comment if you’re interested in this important, heroic, virtuous endeavor. :-)

     

    • Mike Schinkel 7:43 pm on January 7, 2013 Permalink | Log in to Reply

      +1!

    • Jon Brown 7:46 pm on January 7, 2013 Permalink | Log in to Reply

      +1 – May I suggest that versioning and autosaving of metadata be included in this push. I’ve seen several people become reliant on the revisions and auto-save of the content (yay, they trust it!) and then be disappointed to discover their excerpt or content in a metabox isn’t given the same treatment.

      • Mark Jaquith 7:55 pm on January 7, 2013 Permalink | Log in to Reply

        There’s at least one ticket that touches on that http://core.trac.wordpress.org/ticket/20299

        But yeah, we need to start thinking about the fact that as more people use WP as a CMS, a lot of their important data resides outside of post_content.

        • Travis Northcutt 8:01 pm on January 7, 2013 Permalink | Log in to Reply

          Absolutely this. We make heavy use of post meta in sites we build for people, and storing revisions would be a huge plus. Does anyone know of additional tickets that address this? (The one Mark linked to is specifically focused on the fact that previewing changes to a post updates meta (silently), which isn’t expected behavior).

    • Pippin (mordauk) 7:55 pm on January 7, 2013 Permalink | Log in to Reply

      Huge +1.

    • goldenapples 7:58 pm on January 7, 2013 Permalink | Log in to Reply

      +1, I’m very interested in helping work on these features. I’ve worked with the authors on the site I manage to find workarounds for a number of related problems and have several ideas I’d like to test out:

      • visualizing revision history as a tree rather than just a list (I look at vim’s :Gundo plugin as a rough UI example)
      • post meta as mentioned above, although that needs a LOT of thought (lots of postmeta is never shown in a meta box, or is not meant to be edited by authors…)
      • doing more to enable inter-user messaging along with the “heartbeat” autosave calls. Its possible to do something with websockets for the maybe 2% of sites that have that enabled, but for most people, the regular admin-ajax calls could be used to pass messages back and forth about what other users are viewing, if one user requests a release of the lock, etc.

    • adamsilverstein 9:07 pm on January 7, 2013 Permalink | Log in to Reply

      i’m interested in helping if i can

    • John Saddington 9:19 pm on January 7, 2013 Permalink | Log in to Reply

      omg. yes.

    • Arnan de Gans 9:22 pm on January 7, 2013 Permalink | Log in to Reply

      And on top of that… While you guys are at it, make the dashboard, the whole of it, faster. Better loading, faster rendering (?) Whatever. Often on sites that have a bunch of plugins active it get’s really sluggish.

      • Aaron D. Campbell 10:13 pm on January 7, 2013 Permalink | Log in to Reply

        This is largely dependent on what they plugins you’re talking about do on the dashboard. Sounds like they’re likely doing something wrong if they’re slowing down the dashboard that much.

      • Aaron Brazell 12:04 am on January 9, 2013 Permalink | Log in to Reply

        Or nuke it altogether. I don’t have numbers but I’m guessing the majority of people spend 1% of their time in the Dashboard. I find it altogether useless, although I’m sure some would disagree with me.

        When I login to WP to produce content, the first thing I do is click on Add New in the posts menu. That’s a hover and a click more than I need to get into content production.

    • John Kleinschmidt 9:46 pm on January 7, 2013 Permalink | Log in to Reply

      I have been doing a decent amount of work around offline storage recently and would love to help contribute on the JS side of things.

    • Md Mahmudur Rahman 10:10 pm on January 7, 2013 Permalink | Log in to Reply

      Excellent.

    • Grant Norwood 11:59 pm on January 7, 2013 Permalink | Log in to Reply

      Thanks, Mark. This is a great goal, and worthy of the urgency you’ve expressed! Since you mentioned post revisions, I’d like to recommend that we think about how to better compare post/page/CPT revisions within the rich text editor. As it is currently implemented, non-technical users have difficulty comparing large amounts of plain-text and raw HTML, and often give up immediately when using the compare feature. Developers are accustomed to the unified diff format, but we’re the only ones.

      Could we take inspiration from the review/editing/comparison tools used in other popular copy-editing apps (i.e., MS Word) that would make a copywriter feel more at home when comparing content revisions?

    • Gabriel Koen 9:18 pm on January 9, 2013 Permalink | Log in to Reply

      I’d like to lend a hand with this, I can provide user insight (our dev team has been fielding issues regarding this topic for a few years from a large staff of writers) as well as do PHP and JS coding for it.

    • Mike Bijon 12:49 am on January 13, 2013 Permalink | Log in to Reply

      I’d like to help with this during this cycle too.

      Since I’m time-limited to being effective on only 1-2 tickets per cycle, I be happy to help with tests and testing if time there would be valuable.

  • Aaron D. Campbell 6:09 pm on January 7, 2013 Permalink
    Tags: ,   

    WordPress 3.6: the Post Formats UI feature 

    Post formats is going to be a major win for 3.6. It’s one of those features that has so much potential, but it really falls short in usability and honestly we haven’t really taken the time to truly show what it can do. We’re going to re-think the admin UI for post formats, similar to what Alex King did with his WordPress Post Formats Admin UI plugin. The goal is to make post formats much more user friendly and then show them off with the 2013 theme.

    We’ve chosen @helen as lead for this project. Helen has done some amazing stuff customizing the post screen for various projects, and we’re glad to be able to leverage that for core.

    Anyone interested in helping with this feature, please comment to let us know. The 3.6 schedule is considerably shorter than the 3.5 schedule was, so we really need to get moving on things as quickly as possible.

     

    • Paul 6:15 pm on January 7, 2013 Permalink | Log in to Reply

      take a look at what Hybrid does in its latest release
      http://themehybrid.com/docs/tutorials/post-format-tools

    • Chip Bennett 6:16 pm on January 7, 2013 Permalink | Log in to Reply

      I think standardizing on the Post Formats UI, the types of data/content used for each post format type, and the method of input of those data will be a HUGE win for Theme developers and end users alike.

      The Theme Review Team will support your efforts here. Please keep us in the loop, so that we can update Theme Review guidelines accordingly, and help educate Theme developers regarding any changes.

      I’ll pass the word over to the team, in case anyone wants to contribute specific UI ideas.

    • Jonathan Christopher 6:24 pm on January 7, 2013 Permalink | Log in to Reply

      Really loving the idea of this getting some love for 3.6! Like Alex King’s implementation, will the UI update include customization along the lines of Custom Field storage as well? Thinking specifically about a Link post, will there be a core-defined Custom Field correlated with that? I realize that’s a really specific question so I’ll generalize it by asking if those types of conversations (data storage) will be a part of the UI update?

      • Helen Hou-Sandi 1:46 pm on January 8, 2013 Permalink | Log in to Reply

        Going to stay away from implementation details here, – “just” gauging interest :) Don’t want to have discussion getting buried/lost.

    • nphaskins 6:25 pm on January 7, 2013 Permalink | Log in to Reply

      +1

      Pulling some ideas from Alex’s stuff would be pretty sweet.

      http://alexking.org/blog/2011/10/25/wordpress-post-formats-admin-ui

    • Mike Schinkel 6:28 pm on January 7, 2013 Permalink | Log in to Reply

      I’d love to see the ability in a plugin to move the TinyMCE editor to the bottom of the post screen rather than have it anchored where it has always been. Hopefully addressing post formats would make this a requirement?

      • Helen Hou-Sandi 6:30 pm on January 7, 2013 Permalink | Log in to Reply

        There’s a hook between title and editor as of 3.5. It’s purposefully not a sortables (metaboxes) area, but perhaps it’s at least helpful in that regard?

        • Mike Schinkel 7:14 pm on January 7, 2013 Permalink | Log in to Reply

          HI Helen,

          Thanks, yes I did notice that hook. In part it triggered me to want to be able to move the editor even more. :) Much of the custom post type work I do would prefer to have the body at the bottom vs. at the post. So it’s not really helpful because metaboxes still go below the editor. I can dream? :)

          • Helen Hou-Sandi 2:38 pm on January 8, 2013 Permalink | Log in to Reply

            I guess I find sortable metaboxes above a statically-placed TinyMCE instance disruptive in practice, especially since a user could presumably drag anything into any given sortable area. Since the title is similarly static in placement, it seems sensible that the hook between the two not be a sortable one. I put lots of things in edit_form_after_title, but haven’t (yet) wanted them to be in the metabox “look” or be draggable.

        • Justin de Vesine 9:22 pm on January 7, 2013 Permalink | Log in to Reply

          Speaking of sortables and TinyMCE, we recently needed to handle that gracefully, and we’re doing so by destroying the editor instances at the start of a sort and re-creating them afterwards, which seems to be both stable and reasonably speedy. (See https://github.com/Annotum/Annotum/commit/28f50e13ee00d63edd5563fa00dd45abcacf4e10 for the implementation in the Annotum project.)

          • Vitor Carvalho 4:13 pm on January 8, 2013 Permalink | Log in to Reply

            That is very interesting indeed! It would be nice to have it implemented in future WP. Thank you Justin ;)

        • Vitor Carvalho 4:11 pm on January 8, 2013 Permalink | Log in to Reply

          The problem about TinyMCE is that it cannot be sortable. Once instantiated it cannot be moved through the DOM.

      • Manny Fleurmond 12:13 pm on January 19, 2013 Permalink | Log in to Reply

        Just riffing for a bit: I hope people get what Iā€™m trying to convey:

        So when I look at a post, I see the content data (the title and content), ie the meat and potatoes of a post and I see meta data/ taxonomies that add to the main data to categorize/tag/describe it. The content has is own area and meta data/ taxonomies/ etc are relegated to meta boxes. Looking at the different post format examples from other CMSā€™s, you are basically changing the type of content and therefore are changing the type of content fields you are using. Video posts may need a title and description, but they also need a video source url. An aside doesnā€™t even need a title. Post formats are just presets of custom content fields.

        In order to beef up post formats, I think we need to add hooks and an API that allows developers to change the content area of a post; to basically upgrade a few custom fields to content status. Not only should developers be able to add fields that are important enough to be content alongside the post title and post content fields, they should be able to replace those fields entirely, if they so wish. I have a side project where I disabled the title and content, to be replaced by a URL field and it always felt weird to me that I had to put that field in a meta box when it should have been considered the main content. A new post format UI would basically just be picking out a preset of fields that best fits the format of content. As Mike Schinkel suggested in the UI update post, flexibility is key as it would open some nice functionality for plugin developers as well as make WP a lot more robust.

    • Edward Caissie 6:28 pm on January 7, 2013 Permalink | Log in to Reply

      Something to keep in mind (perhaps more so for the Theme Review Team) is not to go forward with Post Formats pigeon-holed into a rigid display of their associated content. I can see strong recommendation being made for how one might use the Post Formats but I would like to see anything stronger than a recommendation.

      • Edward Caissie 6:30 pm on January 7, 2013 Permalink | Log in to Reply

        er, I meant: “… I would *not* like to see anything stronger …”

      • Chip Bennett 6:49 pm on January 7, 2013 Permalink | Log in to Reply

        I think the “big win” opportunity here is in establishing a standard convention regarding what *types of content* apply to each post format type, and what *type of data* each of those types of content are.

        For example, some post format types lend themselves well to *not* having a Post Title. That convention can be established, and Post Title hidden from the UI. (The associated Theme Review guideline would be “must not display Post Title for format types X, Y, Z”)

        For another example, some post format types have been implemented using post custom meta data. For all such instances, it is hugely important to standardize on hat post custom meta key/value.

        Implementation of Post Formats has been a bit of a “wild west”, with different Theme developers making different assumptions about appropriate content and appropriate data types for each post format type. I would love to see those assumptions standardized – and it is on that standardization that I think the WPTRT dovetails nicely into the effort by the UI team.

        • Mark Jaquith 7:19 pm on January 7, 2013 Permalink | Log in to Reply

          This. We don’t want to constrain theme design, but we do want theme designers to know what data they’re getting, in which format, and to know which assumptions have been made about the utility and availability of various pieces of that data.

          • Devin Reams 7:25 pm on January 7, 2013 Permalink | Log in to Reply

            Agreed. The frustrating part of formats so far has been the fact we standardized on the formats, but not other benefit/data to go with it. So we still have to “throw” everything into the_content. A consistent meta data format would be a big win here.

            But, you say, “what If someone switches to a theme without post formats, don’t they lose that meta data”? Sure, which is why we came up with some code to ‘fall back’ in those cases (attach the meta to the content display, basically): http://alexking.org/blog/2011/11/02/wordpress-post-format-fallbacks

            • Daniel Jalkut (Red Sweater) 7:45 pm on January 7, 2013 Permalink

              I want to strongly agree with this and also point out that from a 3rd-party client developer perspective, this has implications on the ability to present a meaningful editing UI as well. I develop a blog editing app for the Mac, that also supports Tumblr which has the closest comparable feature to this that I know of. With Tumblr, I present e.g. the quotation and the attribution of a “Quote” type post separately, in indepent fields. With the WordPress “everything in content” approach, it would be possible to structure the content of the post on first edit, but impossible to reliably pull it apart again when opening up to re-edit.

              I imagine the same problem is limiting the ability of theme and plugin developers to innovate in the wp-admin built-in editor.

        • Aaron D. Campbell 7:26 pm on January 7, 2013 Permalink | Log in to Reply

          This is huge. We want users to be able to change themes and know that all their posts (in any format) will continue to work as expected. We don’t want one theme using _link_url postmeta and another _url because that’s when content is lost (or at least appears lost to the user, and for all intents and purposes it might as well be)

        • grantpalin 12:01 am on January 9, 2013 Permalink | Log in to Reply

          I agree, a standard convention will be useful to guide themers in implementation – something that’s seemed lacking since formats appeared. Guidelines, not rules!

        • Jonas Bolinder (jond3r) 12:36 pm on January 9, 2013 Permalink | Log in to Reply

          A too strict position on which data is allowed or not for a theme too display for a certain post format is discouraging. In particular a theme might want to display a relevant Post Title, which can be beneficial for understanding the content for humans (and bots).

    • Zach "The Z Man" Abernathy 6:29 pm on January 7, 2013 Permalink | Log in to Reply

      Count me in! I’m on-board for whatever is needed in 3.6

    • Travis Northcutt 6:39 pm on January 7, 2013 Permalink | Log in to Reply

      @Helen, when/where will you be discussing what needs to be done? I’m not *sure* I can commit time to helping ,but I’d like to follow along in any case.

      • Helen Hou-Sandi 7:59 pm on January 7, 2013 Permalink | Log in to Reply

        Should be like anything else in development – likely IRC for much of the interaction to keep things moving quickly, along with the ticket #19570 on Trac (especially summaries). Right now we’re gauging interest in various proposed features/release items.

        • Travis Northcutt 8:04 pm on January 7, 2013 Permalink | Log in to Reply

          Thanks! I haven’t gotten involved in contributing to core really in the past (beyond chiming in on a ticket here and there), so I wasn’t sure what exactly to expect.

        • Slobodan Manic 7:23 pm on January 9, 2013 Permalink | Log in to Reply

          I’m sure I can commit time :)

          Really, would love to help with this one, agree with everyone else that post formats could use some standardization.

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

      I’d be happy to help out with this.

    • prettyboymp 6:57 pm on January 7, 2013 Permalink | Log in to Reply

      A set of functions like the post_type_supports() functions of custom post types would be extremely useful.

      I use it frequently to create a handler (form controls/save callback) for certain types of post meta and can turn it on for any post type by just making that post type support it. Similar functionality for post formats would make it possible to carry some of these over instead always unnecessarily needing a custom post type.

    • Tammy Hart 6:59 pm on January 7, 2013 Permalink | Log in to Reply

      I’d like to help out with this as well. I’ve customized Alex King’s approach and used it a couple of times myself.

    • wycks 7:23 pm on January 7, 2013 Permalink | Log in to Reply

      This feature did meet with some pushback when it was first released because of lack of interest ( ā‰  tumblr).

      Since then has there been any indication that people are using it? Can someone show me some good examples, besides ma.tt?

      Do you think it’s apparent lack of use is because of the UI?

      ā„¢ my opinion , I might be totally wrong.

      • Devin Reams 7:31 pm on January 7, 2013 Permalink | Log in to Reply

        See Alex’s blog or my blog using the FavePersonal theme which has the aforementioned “post format UI” (and associated meta data) which allows for a pretty nice user experience (both for publisher and visitor) a la tumblr. It allows a lot more to be done when creating responsive designs, too.

        I see a ton of other themes marked ‘post-formats’ in the theme browser on WP.org but the sample data doesn’t seem to take advantage of it (or the themes I saw don’t…).

      • Helen Hou-Sandi 8:03 pm on January 7, 2013 Permalink | Log in to Reply

        The various mobile apps also have post format support built in, with the image format being the one that probably sees the most use, as the “Quick Photo” feature in the apps automatically assigns that format. Of course, it’s up to the theme to do something special with it.

        The issues I see with adoption (or lack thereof) is with the lack of UI that makes an actual difference for the end user besides choosing from some radio buttons that don’t show you what’s different about the choices, and lack of data standardization for theme authors to take advantage of. It’s not something that’s going to be used by everybody in every application, and there are no illusions about that, but for those who do use it, it’s valuable and desirable, and we should always be making things better.

    • sara cannon 10:53 pm on January 7, 2013 Permalink | Log in to Reply

      count me in to help here as well.

    • Alex King 1:02 am on January 8, 2013 Permalink | Log in to Reply

      Obviously I’m a big fan of this getting into core. The trac ticket is here for anyone interested:

      http://core.trac.wordpress.org/ticket/19570

      The code in the GitHub repos should work fine with WordPres 3.5, but obviously we wouldn’t want the JS hacks that were needed to implement it as an add-on.

      Having thought it through and implemented this once already, I’m still pretty pleased with the overall approach we used and the naming conventions we established. I’d *really* love to see the post meta naming conventions maintained if at all possible.

      Helen, let me know if there are things I can do to help out!

    • Mel Choyce 2:24 am on January 8, 2013 Permalink | Log in to Reply

      I’d like to help out with this, if there’s still room.

    • Amy Hendrix (sabreuse) 2:49 am on January 8, 2013 Permalink | Log in to Reply

      Sign me up.

    • grantpalin 12:04 am on January 9, 2013 Permalink | Log in to Reply

      I’d be happy to help with this in the form of suggestions and feedback. I’ve been puzzled by the lack of a real UI for using formats, and have used Alex King’s plugin to fill the hole. Something worthwhile could be to write a guide on migrating from a plugin-based solution to a core-based one, which I might be able o help with.

    • Jonas Bolinder (jond3r) 12:52 pm on January 9, 2013 Permalink | Log in to Reply

      I’m prepared to contribute (with code and opinions).

    • davebc 5:41 pm on January 9, 2013 Permalink | Log in to Reply

      I’m no coder, but I’ve been dying for post formats to get this attention since they debuted and have stuck with Tumblr solely for this reason ever since. There are few things I won’t do to help test, if you could use that.

      One request: please don’t overlook the bookmarklet when updating the UI for these features.

    • Japh 9:36 pm on January 9, 2013 Permalink | Log in to Reply

      I know I said it in IRC the other week, but just to be sure: I’m in for this one!

    • Lance Willett 4:50 pm on January 17, 2013 Permalink | Log in to Reply

      @aaroncampbell Can you tag this post “post formats”?

    • Lance Willett 4:52 pm on January 17, 2013 Permalink | Log in to Reply

      In case it’s helpful, here is some code that might be helpful even if for how *not* to implement. Heh.

      We have several themes on WP.com where post formats are crucial to the theme and where we needed to have “content parts” broken out, like in a Video post. We wanted just the video URL or markup and not the rest of the post content.

      From the Esquire theme, for example:
      https://wpcom-themes.svn.automattic.com/esquire/content-grabbers.php

      The regex there handles URL, video, and audio.

      Todo to make this much better:

      1. Use get_children() instead to replace the SQL in all thes grabber functions
      2. Cache the result in post meta, then refresh it only when the post changes

      We’d obviously love to replace all this code once core supports getting the better post format UI and being able to “grab” the content pieces out cleanly.

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

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