Displaying Latest Twitter Feeds

PHP Function to Displaying Latest Twitter Feeds

<?php

function display_latest_tweets(
$twitter_user_id, $cache_file = ‘./twitter.txt’,
$tweets_to_display = 100, $ignore_replies = false,
$twitter_wrap_open = ‘<h2>Latest tweets</h2><ul id=”twitter”>’,
$twitter_wrap_close = ‘</ul>’, $tweet_wrap_open = ‘<li><span class=”status”>’,
$meta_wrap_open = ‘</span><span class=”meta”> ‘, $meta_wrap_close = ‘</span>’,
$tweet_wrap_close = ‘</li>’, $date_format = ‘g:i A M jS’, $twitter_style_dates = false) {
// Seconds to cache feed (1 hour).
$cachetime = 60*60;

// Time that the cache was last filled.
$cache_file_created = ((@file_exists($cache_file))) ? @filemtime($cache_file) : 0;

// A flag so we know if the feed was successfully parsed.
$tweet_found = false;

// Show file from cache if still valid.
if (time() – $cachetime < $cache_file_created) {
$tweet_found = true;

// Display tweets from the cache.
@readfile($cache_file);
}
else {
// Cache file not found, or old. Fetch the RSS feed from Twitter.
$rss = @file_get_contents(‘http://twitter.com/statuses/user_timeline/&#8217;.$twitter_user_id.’.rss’);
if($rss) {
// Parse the RSS feed to an XML object.
$xml = @simplexml_load_string($rss);

if($xml !== false) {
// Error check: Make sure there is at least one item.
if (count($xml->channel->item)) {
$tweet_count = 0;
// Start output buffering.
ob_start();

// Open the twitter wrapping element.
$twitter_html = $twitter_wrap_open;

// Iterate over tweets.
foreach($xml->channel->item as $tweet) {
// Twitter feeds begin with the username, “e.g. User name: Blah”
// so we need to strip that from the front of our tweet.
$tweet_desc = substr($tweet->description,strpos($tweet->description,”:”)+2);
$tweet_desc = htmlspecialchars($tweet_desc);
$tweet_first_char = substr($tweet_desc,0,1);

// If we are not gnoring replies, or tweet is not a reply, process it.
if ($tweet_first_char!=’@’ || $ignore_replies==false) {
$tweet_found = true;
$tweet_count++;

// Add hyperlink html tags to any urls, twitter ids or hashtags in the tweet.
$tweet_desc = preg_replace(‘/(https?:\/\/[^\s”<>]+)/’,'<a href=”$1″>$1</a>’,$tweet_desc);
$tweet_desc = preg_replace(‘/(^|[\n\s])@([^\s”\t\n\r<:]*)/is’, ‘$1<a href=”http://twitter.com/$2″>@$2</a>&#8217;, $tweet_desc);
$tweet_desc = preg_replace(‘/(^|[\n\s])#([^\s”\t\n\r<:]*)/is’, ‘$1<a href=”http://twitter.com/search?q=%23$2″>#$2</a>&#8217;, $tweet_desc);

// Convert Tweet display time to a UNIX timestamp. Twitter timestamps are in UTC/GMT time.
$tweet_time = strtotime($tweet->pubDate);
if ($twitter_style_dates) {
// Current UNIX timestamp.
$current_time = time();
$time_diff = abs($current_time – $tweet_time);
switch ($time_diff) {
case ($time_diff < 60):
$display_time = $time_diff.’ seconds ago’;
break;
case ($time_diff >= 60 && $time_diff < 3600):
$min = floor($time_diff/60);
$display_time = $min.’ minutes ago’;
break;
case ($time_diff >= 3600 && $time_diff < 86400):
$hour = floor($time_diff/3600);
$display_time = ‘about ‘.$hour.’ hour’;
if ($hour > 1){ $display_time .= ‘s’; }
$display_time .= ‘ ago’;
break;
default:
$display_time = date($date_format,$tweet_time);
break;
}
}
else {
$display_time = date($date_format,$tweet_time);
}

// Render the tweet.
$twitter_html .= $tweet_wrap_open.$tweet_desc.$meta_wrap_open.'<a href=”http://twitter.com/&#8217;.$twitter_user_id.'”>’.$display_time.'</a>’.$meta_wrap_close.$tweet_wrap_close;
}

// If we have processed enough tweets, stop.
if ($tweet_count >= $tweets_to_display) {
break;
}
}

// Close the twitter wrapping element.
$twitter_html .= $twitter_wrap_close;
echo $twitter_html;

// Generate a new cache file.
$file = @fopen($cache_file, ‘w’);

// Save the contents of output buffer to the file, and flush the buffer.
@fwrite($file, ob_get_contents());
@fclose($file);
ob_end_flush();
}
}
}
}

// In case the RSS feed did not parse or load correctly, show a link to the Twitter account.
if (!$tweet_found) {
echo $twitter_wrap_open.$tweet_wrap_open.’Oops, our twitter feed is unavailable right now. ‘.$meta_wrap_open.'<a href=”http://twitter.com/&#8217;.$twitter_user_id.'”>Follow us on Twitter</a>’.$meta_wrap_close.$tweet_wrap_close.$twitter_wrap_close;
}
}

display_latest_tweets(‘<twitter-username>’);

?>

PHP 4 and MySQL 4 End of Life Announcement

WordPress has always been to make it run on common server configurations. WordPress has want users to have flexibility when choosing a host for their precious content. Because of this strategy, WordPress runs pretty much anywhere. Web hosting platforms, however, change over time, and occasionally are able to reevaluate some of the requirements for running WordPress. Now is one of those times. You probably guessed it from the title — we’re finally ready to announce the end of support for PHP 4 and MySQL 4!

First up, the announcement that developers really care about. WordPress 3.1, due in late 2010, will be the last version of WordPress to support PHP 4.

For WordPress 3.2, due in the first half of 2011, we will be raising the minimum required PHP version to 5.2. Why 5.2? Because that’s what the vast majority of WordPress users are using, and it offers substantial improvements over earlier PHP 5 releases. It is also the minimum PHP version that the Drupal and Joomla projects will be supporting in their next versions, both due out this year.

The numbers are now, finally, strongly in favor of this move. Only around 11 percent of WordPress installs are running on a PHP version below 5.2. Many of them are on hosts who support PHP 5.2 — users merely need to change a setting in their hosting control panel to activate it. We believe that percentage will only go down over the rest of the year as hosting providers realize that to support the newest versions of WordPress (or Drupal, or Joomla), they’re going to have to pull the trigger.

In less exciting news, we are also going to be dropping support for MySQL 4 after WordPress 3.1. Fewer than 6 percent of WordPress users are running MySQL 4. The new required MySQL version for WordPress 3.2 will be 5.0.15.

WordPress users will not be able to upgrade to WordPress 3.2 if their hosting environment does not meet these requirements (the built-in updater will prevent it). In order to determine which versions your host provides, wordpress created the Health Check plugin. Right now, Health Check will only tell you if you’re ready for WordPress 3.2. In a future release it will provide all sorts of useful information about your server and your WordPress install, so hang on to it!

In summary: WordPress 3.1, due in late 2010, will be the last version of WordPress to support PHP 4 and MySQL 4. WordPress 3.2, due in the first half of 2011, will require PHP 5.2 or higher, and MySQL 5.0.15 or higher.

WordPress 3.0.1

After nearly 11 million downloads of WordPress 3.0 in just 42 days, releasing WordPress 3.0.1. The requisite haiku:

Three dot oh dot one
Bug fixes to make you smile
Update your WordPress

This maintenance release addresses about 50 minor issues. The testing many of you contributed prior to the release of 3.0 helped make it one of the best and most stable releases.

Download 3.0.1 or update automatically from the Dashboard > Updates menu in your site’s admin area.

WordPress 3.0 Release Candidate

First release candidate (RC1) for WordPress 3.0 is now available. What’s an RC? An RC comes after beta and before the final launch. It means we think we’ve got everything done: all features finished, all bugs squashed, and all potential issues addressed. But, then, with over 20 million people using WordPress with a wide variety of configurations and hosting setups, it’s entirely possible that we’ve missed something. So! For the brave of heart, please download the RC and test it out (but not on your live site unless you’re extra adventurous). Some things to know:

• Custom menus are finished!
• Multi-site is all set.
• The look of the WordPress admin has been lightened up a little bit, so you can focus more on your content.
• There are a ton of changes, so plugin authors, please test your plugins now, so that if there is a compatibility issue, we can figure it out before the final release.
• Plugin and theme *users* are also encouraged to test things out. If you find problems, let your plugin/theme authors know so they can figure out the cause.
• There are a couple of known issues.

If you are testing the RC and come across a bug, you can:

• Report it on the wp-testers mailing list
• Join the dev chat and tell us live at irc.freenode.net #wordpress-dev
• File a bug ticket on the WordPress Trac

Download WordPress 3.0 RC1

Source: WordPress.org

Secure File Permissions Matter

Summary: A web host had a crappy server configuration that allowed people on the same box to read each other’s configuration files, and some members of the “security” press have tried to turn this into a “WordPress vulnerability” story.

WordPress, like all other web applications, must store database connection info in clear text. Encrypting credentials doesn’t matter because the keys have to be stored where the web server can read them in order to decrypt the data. If a malicious user has access to the file system — like they appeared to have in this case — it is trivial to obtain the keys and decrypt the information. When you leave the keys to the door in the lock, does it help to lock the door?

A properly configured web server will not allow users to access the files of another user, regardless of file permissions. The web server is the responsibility of the hosting provider. The methods for doing this (suexec, et al) have been around for 5+ years.

I’m not even going to link any of the articles because they have so many inaccuracies you become stupider by reading them.

If you’re a web host and you turn a bad file permissions story into a WordPress story, you’re doing something wrong.

WordPress 3.0, Beta 1

This is an early beta. This means there are a few things we’re still finishing. We wanted to get people testing it this weekend, so we’re releasing it now rather than waiting another week until everything is finalized and polished. There’s a ton of stuff going on in 3.0, so this time we’re giving you a list of things to check out, so that we can make sure people are testing all the things that need it.

You Should Know:

• The custom menus system (Appearance > Menus) is not quite finished. In Beta 2, the layout will be different and a bunch of the functionality will be improved, but we didn’t want to hold things up for this one screen. You can play with making custom menus, and report bugs if you find them, but this is not how the final screen will look/work, so don’t get attached to it.
• The merge! Yes, WordPress and WordPress MU have merged. This does not mean that you can suddenly start adding a bunch of new blogs from within your regular WordPress Dashboard. If you’re interested in testing the Super Admin stuff associated with multiple sites, you’ll need some simple directions to get started.
• We’re still fiddling with a few small things in the UI, as we were focused on getting the more function-oriented code finished first. For example, we’re getting a new icon for the Super Admin section.

Things to test:

• Play with the new default theme, Twenty Ten, including the custom background and header options.
• Custom Post Type functionality has been beefed up. It’s really easy to add new types, so do that and see how it looks!
• WordPress MU users should test the multiple sites functionality to make sure nothing broke during the merge.

Already have a test install that you want to switch over to the beta? Try the beta tester plugin.

Testers, don’t forget to use the wp-testers mailing list to discuss bugs you encounter.

We hope you like it! And if you don’t, well, check back when beta 2 is ready.

Download the WordPress 3.0 Beta 1 now!