[wp-trac] [WordPress Trac] #22981: Tweets import plugin tracking ticket

[WordPress Trac]

#22981: Tweets import plugin tracking ticket
---------------------------+----------------------------
 Reporter:  nacin          |       Type:  task (blessed)
   Status:  new            |   Priority:  high
Milestone:  WordPress.org  |  Component:  Plugins
  Version:                 |   Severity:  normal
 Keywords:                 |
---------------------------+----------------------------
 This ticket is to track the development of a plugin that can import tweets
 from a downloaded twitter.com archive. Presumably, such a plugin would be
 added to the importers list on wp-admin/import.php.

 Trac is best when it is used to discuss implementation. If you want to
 discuss the general idea, please do so on
 [http://make.wordpress.org/core/2012/12/16/antsy-for-3-6-to-start-and-
 need-a/ make/core].

 Some initial thoughts on implementation:
  * It should use the JSON-formatted data that comes with a downloaded
 tweet archive. The importer should take the entire zip, extract it, and
 loop through the monthly files. Anything more is an unnecessary burden on
 the user.
  * The plugin should import the tweet as actual content. A filter is good
 idea, if someone wishes to toggle this to instead insert links to tweets
 (and thus rely on oEmbed). It should also store the JSON-serialized array
 of data (directly from 1.1 of Twitter's API) in postmeta.
  * It should import posts as a post format. Status makes the most sense;
 'link' could also work for links, then there's also 'aside'. The post
 format to use should be filterable on a tweet-by-tweet basis. The post
 type to use should be filterable, as a 'tweet' type may be desired.
  * It should handle importing an archive over an existing archive, by
 looking for the existing tweet (probably IDs as a meta key). I don't think
 deleted tweets should be removed in this process, though.
  * Remember that tweet IDs are going to be bigger than 32-bit integers, so
 they must be treated as strings, and we should not try to set a post ID as
 we might with other importers. This importer should be tested on a 32-bit
 environment.

 Beyond that, there are other "nice to haves" that would likely be left to
 plugins of this plugin, given they are beyond the standard role of an
 importer. Beau Lebens, for example, has done some/all of this already:
  * Tagging based on hashtags, and a separate mentions and/or in-reply-to
 taxonomy.
  * Filtering over raw (no-HTML) content to add things like links to
 hashtags, links in tweets, etc., on display, rather than doing all of this
 on save. (Should a hashtag link go to the internal tag, or to twitter.com?
 Maybe the internal tag's description links to twitter.com?)
  * A cron to import new tweets using the same importing methods.

 One thing I will suggest: decisions, not options. Note I said "filter" a
 bunch of times, but never the word "option." Not that there won't be a
 need for any user decision here, but we should make a plugin that works
 well for the common use cases, and leave the rest to other enterprising
 developers.

 Side note: I am working on acquiring a namespace for the Twitter importer
 in the wordpress.org plugin repository.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/22981>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software