<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>140dev &#187; Integrating Twitter with Wordpress</title>
	<atom:link href="http://140dev.com/twitter-api-programming-blog/category/wordpress/feed/" rel="self" type="application/rss+xml" />
	<link>http://140dev.com</link>
	<description>Twitter API Programming Tips, Tutorials, Source Code Libraries and Consulting</description>
	<lastBuildDate>Wed, 31 Jul 2019 10:03:15 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.6</generator>
		<item>
		<title>WordPress architecture is in place</title>
		<link>http://140dev.com/twitter-api-programming-blog/wordpress-architecture-is-in-place/</link>
		<comments>http://140dev.com/twitter-api-programming-blog/wordpress-architecture-is-in-place/#comments</comments>
		<pubDate>Fri, 15 Oct 2010 15:30:39 +0000</pubDate>
		<dc:creator>Adam Green</dc:creator>
				<category><![CDATA[140dev Source Code]]></category>
		<category><![CDATA[Database Cache]]></category>
		<category><![CDATA[Integrating Twitter with Wordpress]]></category>
		<category><![CDATA[Tweet Aggregation]]></category>

		<guid isPermaLink="false">http://140dev.com/?p=276</guid>
		<description><![CDATA[I rebuilt the code for the 104dev system using a WP-style architecture. As expected the messiest part was getting the directory paths right. I think the idea of putting most of the functionality into separate plugin directories will be a big win. There will be a very small core of tweet collection code and general [&#8230;]]]></description>
				<content:encoded><![CDATA[<p></p><p>I rebuilt the code for the 104dev system using a WP-style architecture. As expected the messiest part was getting the directory paths right. I think the idea of putting most of the functionality into separate plugin directories will be a big win. There will be a very small core of tweet collection code and general purpose functions. If everything else is a plugin, others can build onto the system. <a href="http://140dev.com/demo/">Here</a> is a very simple demo of the code in use. </p>
<p>The source of this page shows of easy it is to add Twitter functionality to any Web page:<br />
<code><br />
&lt;head&gt;<br />
&lt;title&gt;Tweet Display from Database Cache&lt;/title&gt;<br />
&lt;meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /&gt;<br />
&lt;link rel="stylesheet"<br />
    href="http://140dev.com/demo/themes/default.css" type="text/css" /&gt;<br />
&lt;script type="text/javascript"<br />
    src="http://ajax.googleapis.com/ajax/libs/jquery/1.4/jquery.min.js"&gt;&lt;/script&gt;<br />
&lt;script type="text/javascript"<br />
    src="http://140dev.com/demo/plugins/tweet_display/site.js"&gt;&lt;/script&gt;<br />
&lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;?php print file_get_contents('http://140dev.com/demo/plugins/tweet_display'); ?&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;<br />
</code></p>
<p>I&#8217;ll write up a tutorial to describe the architecture I used. The key is a decoupled approach. The 140dev server can deliver tweets to any site. That allows a single collection point for interaction with the Twitter API, but any number of display sites for the aggregated tweets.</p>
]]></content:encoded>
			<wfw:commentRss>http://140dev.com/twitter-api-programming-blog/wordpress-architecture-is-in-place/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Decisions about the tweet aggregation code</title>
		<link>http://140dev.com/twitter-api-programming-blog/decisions-about-the-tweet-aggregation-code/</link>
		<comments>http://140dev.com/twitter-api-programming-blog/decisions-about-the-tweet-aggregation-code/#comments</comments>
		<pubDate>Wed, 13 Oct 2010 23:09:06 +0000</pubDate>
		<dc:creator>Adam Green</dc:creator>
				<category><![CDATA[140dev Source Code]]></category>
		<category><![CDATA[Database Cache]]></category>
		<category><![CDATA[Integrating Twitter with Wordpress]]></category>
		<category><![CDATA[Tweet Aggregation]]></category>
		<category><![CDATA[Twitter Developers]]></category>

		<guid isPermaLink="false">http://140dev.com/?p=264</guid>
		<description><![CDATA[I&#8217;ve been thinking about how to prepare the tweet aggregation code used for the dev tweets page. I know that I want to add multiple modules to the system, and make it easy to customize the appearance of the tweet list. This sounds a lot like the WordPress model with plugins and themes, so I&#8217;m [&#8230;]]]></description>
				<content:encoded><![CDATA[<p></p><p>I&#8217;ve been thinking about how to prepare the <strong>tweet aggregation code</strong> used for the <a href="http://140dev.com/twitter-development-team-tweets/">dev tweets page</a>. I know that I want to add multiple modules to the system, and make it easy to customize the appearance of the tweet list. This sounds a lot like the WordPress model with plugins and themes, so I&#8217;m going to adopt a similar code architecture. If I do this right, others will be able to add their own plugins and themes. I also want to make installation as drop dead simple as possible. Finally, I&#8217;m going to call the code base 140Dev. I already use this name for the company and site. Why bother coming up with a new product name, only to have to rename the site and company to match the product later? And so it begins&#8230;</p>
]]></content:encoded>
			<wfw:commentRss>http://140dev.com/twitter-api-programming-blog/decisions-about-the-tweet-aggregation-code/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Fun with WordPress code and tweet aggregation</title>
		<link>http://140dev.com/twitter-api-programming-blog/fun-with-wordpress-code-and-tweet-aggregation/</link>
		<comments>http://140dev.com/twitter-api-programming-blog/fun-with-wordpress-code-and-tweet-aggregation/#comments</comments>
		<pubDate>Sat, 09 Oct 2010 13:08:03 +0000</pubDate>
		<dc:creator>Adam Green</dc:creator>
				<category><![CDATA[Integrating Twitter with Wordpress]]></category>
		<category><![CDATA[Tweet Aggregation]]></category>

		<guid isPermaLink="false">http://140dev.com/?p=159</guid>
		<description><![CDATA[I had an interesting time getting the Twitter developer tweets onto a WordPress page. I explored lots of different paths: My first attempt was to use a plugin called Exec-PHP. This worked fine as a way of getting the tweet list to appear on a WordPress page, because I have the display code callable by [&#8230;]]]></description>
				<content:encoded><![CDATA[<p></p><p>I had an interesting time getting the <a href="http://140dev.com/twitter-development-team-tweets/">Twitter developer tweets </a>onto a WordPress page. I explored lots of different paths:</p>
<ul>
<li> My first attempt was to use a plugin called <a href="http://wordpress.org/extend/plugins/exec-php/">Exec-PHP</a>. This worked fine as a way of getting the tweet list to appear on a WordPress page, because I have the display code callable by a single PHP include. The problem is that this plugin only lets me add code to the content of the page, which appears in the HTML body. I also need to add CSS and JS files to the page head.</li>
<li> I next tried writing my own plugin that could insert the CSS and JS in the head, and the include in the body. I got that to work, but found a problem with the CSS and JS files. The method everyone recommends to add code to a WordPress page head is to tie this to the init action. Unfortunately, init is called for every page, so the result of this new plugin was to insert a CSS and JS file load into every page on the site. This is an unnecessary performance hit that I was not willing to accept.</li>
<li> So I tried adding is_page() tests to the functions that load the CSS and JS files to the head, and the function that includes the tweet list into the content of the page. I only want to include the CSS and JS files on the tweet aggregation page. I found out that the init hook happens before WordPress knows what page is loaded, so is_page() fails in a function called by the init hook.</li>
<li> I spent almost an entire day reading everything written about this problem, only to find that none of the posted solutions worked. I then tried every WordPress hook to find one that allows code to be inserted into the page head and also works with an is_page() test. I finally found that the wp_enqueue_scripts hook does the job. Funny that nobody recommends this, but it does seem to work.</li>
<li> So now I have a plugin that can insert the the CSS, JS, and tweet list onto a single specified page. But how do I specify that page? I could write the page name into the plugin code, but that means editing the plugin script to adapt it to each site where the tweets are displayed. That makes me queasy, so I decided to save the page name in a config file I already use to store parameters for the tweet display, like the refresh interval, and the number of tweets to be displayed. This can now be edited to control the insertion of the tweet aggregation in a WordPress site. It still seems like a hack, but I&#8217;m using this plugin just for my site. When I get around to open sourcing this plugin, I&#8217;ll build a plugin settings page, so users can easily enter the page name for the tweet display.</li>
</ul>
]]></content:encoded>
			<wfw:commentRss>http://140dev.com/twitter-api-programming-blog/fun-with-wordpress-code-and-tweet-aggregation/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
