On the Solspace.com redesign, I wanted to leverage tweets as testimonials about our work. I knew from experience with our clients that automated systems are subject to spam, so we decided to use Twitter's favorites functionality as a curation tool. Greg Ferrell modified EllisLab's Twitter Timeline plugin to pull from favorites. For a short while we used that to display tweets directly from Twitter onto the site.
Pretty quickly we learned that depending on Twitter's search API creates a fragile system. The API limits requests per IP. If you are on a shared server then you may be sharing this limit. Additionally, Twitter's API changes occasionally. These issues can potentially leave an empty spot on our site or even a page that won't load. I've seen a situation on a client site where the client was displaying their own tweets, but they tweeted infrequently and the search API wouldn't pull their older content, sometimes leaving the space on their site devoted to tweets empty.
To foolproof this system and to give us additional filtered display options for tweets, we now use Solspace's Importer to put tweets into weblog entries. After hearing about a recent Twitter API change that caused problems on some sites displaying content directly from Twitter, I thought others might find this technique useful.
To do this, you'll need the Twitter Timeline plugin and the Importer Module. Importer is currently available only for EE1.x, but it is in our pipeline for conversion.
Make an XML feed
Here is our template code for the XML feed
<root>
{exp:twitter_timeline screen_name="twitter_username" limit="100"
favorites="yes" create_links="user_mentions|hashtags|urls"}
<item>
<title>{name} - {id}</title>
<screen_name>{screen_name}</screen_name>
<id>{id}</id>
<profile_image_url>{profile_image_url}</profile_image_url>
<name>{name}</name>
<text><![CDATA[{text}]]></text>
<date>{created_at format="%Y-%m-%d %h:%i:%s %A"}</date>
</item>
{/exp:twitter_timeline}
</root>
The parameter favorites="yes" will not do anything in Twitter Timeline natively. As mentioned previously, we modified it to pull favorites.
We find Twitter's responses unreliable, XML is frustrating enough without Twitter throwing in some extra tricks. If you test your feed from a shared server and it comes out empty, try testing again later, your server limit for requests may have been hit.
Make a weblog to hold your Twitter data
Our custom fields are:
- Screen Name {tweets_screen_name}
- ID {tweets_id}
- Profile Image URL {tweets_profile_image_url}
- Name {tweets_name}
- Text {tweets_text}
In preferences, set "Automatically turn URLs and email addresses into links?" to off.
Configure Importer
- Under "Create and Edit Import Profiles" select "New XML Profile"
- In the tabs at the top, select "XML from Web Source"
- Add a Profile Name
- Assign your new weblog as the destination weblog.
- Once you do this, a default status select should appear. Assign that.
- Our Duplicate entry handling settings are:
- Check for duplicates?: yes
- When a duplicate entry is found, what should the default action be?: Do nothing (Skip)
- When a duplicate entry is found, override the old categories with the new categories found in the incoming data?: Override the old with the new
- We have no fixed fields
- Email notifications go to Kelsey and I and the template reads:
Hello Christy and/or Kelsey, {total_inserted} tweets were updated on {import_date}. You deserve a break. Go outside. Love, Christy
- Email sending rules are: Send email at the end of an import
- Primary XML tag is "item"
- XML Method is "Loose XML"
- URL of XML file points to the template that our XML feed is in
- Map of XML to Entry Fields
- Key field is set to ID
- Save Profile
Once you save, on the view/edit profiles screen, you'll see a line for your new profile with a link "Remote Access URL". Clicking this link displays the URL that triggers your import. We have this link bookmarked and hit it manually when we favorite things, but you could also set up a cron to hit it.
Further Potential
Once tweets are in weblog entries they can be searchable, tagged and categorized. You also know that they'll show up to the party and older tweets won't be lost.
If you try this out I hope you'll let us know how it goes.



8 Comments
dfbills
Apr 20, 2011 1:24 pm
#1
This is great! Thanks for sharing.
Ryan Battles
Apr 20, 2011 5:01 pm
#2
This is a great solution to a problem that I imagine will be revisited regularly as Twitter evolves and modifies their API. However, I have run into an issue where if a user is trying to display a feed of tweets that has many entries per day, their database can quickly grow out of control. That example was using a solution that was module-based, so the database holding the entries was not a standard channel. With your approach, I suppose the standard data-pruning tools are available, so the client would to be able to go in every 30 days or so and delete older tweets. Do you know of any way to automatically prune these types of channels so the older content doesn’t build up?
Mitchell Kimbrough
Solspace
Apr 20, 2011 7:45 pm
#3
Jovia Web,
We worry about this too. You could definitely fill up your DB with a lot of data and you would want to prune the data some way.
A nice thing about Importer is that you can create an import profile that points to a feed that you use for deletions. The feed would contain XML entries that are older than a certain time. You can tell the Importer profile to delete any channel entry in EE that it finds a match for in the feed.
The heavy lifting in our example would actually be on the template side where you are creating a feed of Tweets that are older than a certain date, a date that you would probably feed through the url so that the thing could be dynamic.
mk
Ryan Battles
Apr 20, 2011 8:00 pm
#4
Hah, I didn’t realize that my screen name was my company name, I hate it when people do that, so I just changed it
Anyway, that’s a great solution regarding the data pruning. I haven’t looked into the EE1 version of the add-on very much so I didn’t know that that was a feature. Very handy indeed! You guys always seem to think of all the angles with your add-ons.
Mitchell Kimbrough
Solspace
Apr 20, 2011 8:04 pm
#5
We often have a client involved when we develop an add-on and that’s been a good way of uncovering some of the feature needs. I’ve used that one feature pretty frequently.
Importer needs a complete rewrite. Not only do we need to convert it to EE 2, but I want to really tidy everything up in there.
mk
Christy Collins
Solspace
Apr 21, 2011 5:53 am
#6
Ryan, I was chatting with Greg about this last night and he had an additional suggestion of EE’s native data pruning: http://expressionengine.com/legacy_docs/cp/admin/utilities/data_pruning.html
Neither he nor I knew this existed before we were discussing your question.
Ryan Battles
Apr 21, 2011 6:37 am
#7
Christy, that is a great tool, and I’ve used it on a few sites where the number of posts can get out of control. I just don’t like that you have to manually go in and do it. Mitchell’s mentioning of an automatic way to do it with Importer is a much more user-friendly approach. Looking forward to seeing how the add-on comes together for EE2.
Eric Miller
May 6, 2011 4:35 am
#8
Worked like a charm, and set it up in just a few minutes. Super slick. Thanks Christy!