RewriteEngine Off
<ifmodule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !^index.php$
RewriteRule . index.php [NC,L]
</ifmodule>

This essentially tells your server to redirect anything that isn’t a file or directory to index.php.

Then index.php looks like this:

$url = str_replace("/","",$_SERVER['REQUEST_URI']);
if(isset($url) && trim($url)!='') {
$id = base_convert($url,36,10);
//this is where you either query your database for a slug or build the URL
$uri = 'http://your-site-goes-here.com/path/to/article';
}
 
if($uri) {
header('HTTP/1.1 301 Moved Permanently');
header('Link: < '.$uri.">; rel=shortlink");
header('Location: '.$uri);
exit;
} else {
header("Location: http://your-site-goes-here.com/"); exit;
}

How do you get your short links? That’s easy. Just run this function:

$shorturl = base_convert($id,10,36);

However, this isn’t the most compact way to condense. Obviously, this is base36, the highest PHP can go. But what about uppercase letters? And other characters?

So I set out, for some reason, to build a better condenser.

This is the result of several hours of work, mostly wasted, on some intellectual pursuit that was more a case of simply not letting it defeat me. A few notes: I’m quite confident that given enough time, and if I cared, I could make the code cleaner and more efficient in some places. I’m also aware that on 32 bit machines, it maxes out at the integer limit. I does support signed integers though, from min to max.

$ft_str = '0123456789abcdefghijklmnopqrstuvqwxyzABCDEFGHIJKLMNOPQRSTUVQWXYZ';
# uncomment the next line if you prefer to use potentially non-URL-safe base96
# $ft_str .= '0123456789abcdefghijklmnopqrstuvqwxyzABCDEFGHIJKLMNOPQRSTUVQWXYZ_@$!#%^&*()=+\|}{][,;:~'; }

$powers = array();
for($p=0;$p<=10;$p++) {
$powers[$p]=pow(strlen($ft_str),$p);
}
 
function ft_unconvert($str) {
if(substr($str,0,1)=='-') { $pfx='-'; } else { $pfx=''; }
global $ft_str,$powers;
$base = strlen($ft_str); $q=0;
$s = str_split(strrev($str)); $len = sizeof($s);
foreach($s as $k=>$v) {
$sp = strpos($ft_str,$v);
$decimal += pow($base,$k)*$sp;
}
return $pfx.$decimal;
}
 
function ft_converter($int) {
if($int > 0) { $pfx='-'; $int=abs($int); } else { $pfx=''; }
global $ft_str,$powers;
$base = strlen($ft_str); $q=0;
$p = str_split($str);
krsort($powers);
foreach($powers as $k=>$v) {
if($int>=$v) {
$timesinto = floor($int/$v);
$digit .= $ft_str{$timesinto};
$int = $int % $v;
} elseif($int>0 && $k==0) {
$digit .= $ft_str{$int};
$int = $int % $v;
}
}
return $pfx.$digit;
}
 
function ft_convert_demo($num) {
global $ft_str;
$ftc = ft_converter($num);
return "Converting ".$num." into base ".strlen($ft_str).": ".$ftc."<br />Unconverting ".$ftc." to base 10: ".ft_unconvert($ftc);
}
 
echo ft_convert_demo('50687');

This time, I traced the problem back to wp-lytebox, and I’m ashamed to say I’ve had to fix the same problem before.  It all started when I couldn’t load the post page in the backend of firsttube.com.  Digging in, I eventually found a file called sys.php in the root of the site, and it listed the contents of my site and had a form that allowed someone to add a page, chmod a page, or delete a page.  Killer!

I found that it was defaulting to /path/to/WP/wp-includes/plugins/wp-lytebox, and sure enough, digging into that directory revealed several other fun scripts, all of which gave someone the ability to access all the files on my site.  Fun!

I found that I already had replaced this plugin before, so I decided to get rid of it altogether, this now proving it wasn’t a misconfiguration, but rather, a problem with the wp-lytebox itself.

In this process, however, I was unable to fix my issue.  Visiting /wp-admin/post-new.php still rendered only a page footer, and nothing more.

So I starting fooling around in my directories looking for files that had been modified more recently than when I did my 2.9.2 upgrade.  One of the files? My .htaccess file.

“This be odd,” I thought to myself, “I’ve changed this not, methinks.”

Sure enough, there was a rogue line within: RewriteCond ^/default/$ /wp-admin/includes Huh?

I dug into that folder, and the .htaccess file there was recent too? It’s contents? DefaultIndex users.php

Of course, I immediately opened users.php and found, as you might have guessed, a bunch of Russian crap. Savvy WP hackers will know, it’s not a real file, there is no users.php in the real wp-admin/includes directory.

I also found a folder that had two large files, both named core.XXXX where XXXX was a 4 digit number, and a massive 40 MB error_log.  Yikes.

I thought I had everything cleaned out, and I truly believed that the way in was wp-lytebox.  Then I found this.  And sure enough, all of the listed files were compromised.  So I nuked all the files, and replaced them all.  D’oh!

So, if you’re arriving via Google or Bing or Yahoo!, do NOT use wp-lytebox.

If you’re interested in some revealing behind-the-scenes info, feel free to ask questions now.

I don’t believe anyone out there is still using Flip, but if there is, this is how to defeat the script: simple add this line at line 102 of account.php:

 if(strstr($_POST['em'],"][")) { die('Fail'); }

and this at line 162:

 if(strstr($_POST['nem'],"][")) { die('Fail'); }

Alternatively, you can download the modified file here or download Flip 3.0.1 here.

It may sound odd, but I would highly recommend that you do *not* use this code. It’s now 7 years old and the web is a much different place. The code here is really not suited for running a website today. That said, it was odd to unzip and install it and see that it actually works. The rendering of most of the “themes” is weird (Fudge works great), but otherwise, everything worked.

If you are still a Flip user, I recommend you update your account.php page immediately, and if you have the time and inclination, upgrade to 3.0.1. The following files have some minor changes:

• account.php
• index.php
• inc/config.php
• README.html

Once again, this code is aged not particularly well suited for today’s web.  If you want a simple weblog, I recommend WordPress.

Directions are this easy: set the path of $tw_File with a static, writable file.  Set $tw_userid to your Twitter user id.  Done. 

Download firsttube.com “get latest tweet” php snippet.

//an array of some songs I like
$songs =  array(
		'1' => array('artist'=>'The Smashing Pumpkins', 'songname'=>'Soma'),
		'2' => array('artist'=>'The Decemberists', 'songname'=>'The Island'),
		'3' => array('artist'=>'Fleetwood Mac', 'songname' =>'Second-hand News')
	);

The problem is thus: I’d like to echo out the songs I like in the format “Songname (Artist),” and I’d like to do it alphabetically by artist. PHP provides many functions for sorting arrays, but none will work here. ksort() will allow me to sort by key, but the keys in the $songs array are irrelevant. asort() allows me to sort and preserves keys, but it will sort $songs by the value of each element, which is also useless, since the value of each is “array()”. usort() is another possible candidate and can do multi-dimensional sorting, but it involves building a callback function and is often pretty long-winded. Even the examples in the PHP docs references specific keys.

So I developed a quick function to sort by the value of a key in a sub-array. Please note this version does a case-insensitive sort. See subval_sort() below.

function subval_sort($a,$subkey) {
	foreach($a as $k=>$v) {
		$b[$k] = strtolower($v[$subkey]);
	}
	asort($b);
	foreach($b as $key=>$val) {
		$c[] = $a[$key];
	}
	return $c;
}

To use it on the above, I would simply type:

$songs = subval_sort($songs,'artist'); 
print_r($songs);

This is what you should expect see:

Array
(
    [0] => Array
        (
            [artist] => Fleetwood Mac
            [song] => Second-hand News
        )
 
    [1] => Array
        (
            [artist] => The Decemberists
            [song] => The Island
        )
 
    [2] => Array
        (
            [artist] => The Smashing Pumpkins
            [song] => Cherub Rock
        )
 
)

The songs, sorted by artist.

I wrote an application some time ago for my company that looks up the longitude and latitude of an address for use in our geocoding initiative. It relied on yahoo_geo(), a function written by PHP creator Rasmus Lerdorf and the Yahoo Maps API. It was largely dependent on this function:

function yahoo_geo($location) {
	$q = 'http://api.local.yahoo.com/MapsService/V1/geocode?appid=rlerdorf&location='
		.rawurlencode($location);
	$tmp = '/tmp/yws_geo_'.md5($q);
	request_cache($q, $tmp, 43200);
	libxml_use_internal_errors(true);
	$xml = simplexml_load_file($tmp);
	$ret['precision'] = (string)$xml->Result['precision'];
	foreach($xml->Result->children() as $key=>$val) {
		if(strlen($val)) $ret[(string)$key] = (string)$val;
	}
	return $ret;
}

This function worked for over two years for us with no problems at all. Then suddenly, in the last month, it started getting spotty. I fixed things by commenting out the caching parts of the function and forcing each execution to run again. Then I got errors about the libxml_use_internal_errors() function, so I commented that out. But today, the function just flat out failed, every single time returning the same error:

Warning: file_get_contents(http://XXXXXXXXXX/XXX) [function.file-get-contents]: failed to open stream: HTTP request failed! in /home/intranet/html/fetch.php on line X

What the heck? This code is all over the web. I’ve tried a million permutations of this function, including using fopen() and ob_get_contents(), and none have worked. And most frustratingly, I could load the URL successfully in Lynx and eLinks, so the machine could quickly and easily fetch the URL.

So I ventured into a sandbox I’ve never really played before: cURL. cURL is an interesting animal. But the interesting thing is, once I got it working, it worked faster than ever! So, without further ado, here is the new and improved yahoo_geo() function:

function yahoo_geo($location) {
	$q = 'http://api.local.yahoo.com/MapsService/V1/geocode?appid=rlerdorf&location='.urlencode(trim($location));
	$ch = curl_init($q);
	curl_setopt($ch, CURLOPT_HEADER, 0);
	ob_start();
	curl_exec($ch);
	$stream = ob_get_contents();
	ob_end_clean();
	if($stream) {
		$xml = simplexml_load_string($stream);
		$ret['precision'] = (string)$xml->Result['precision'];
		if($xml) {
			foreach($xml->Result->children() as $key=>$val) {
				if(strlen($val)) $ret[(string)$key] =  (string)$val;
			}
		}
		curl_close($ch);
		return $ret;
	} else {
		return FALSE;
	}
}

Note: If you’re reproducing these functions elsewhere, be careful – WordPress may have converted the quotes into smart quotes that will need to be fixed before this script will run properly.

The interesting thing here is that I’ve browsed the source of Slash, Scoop, phpNuke, and now WordPress, and all of them are definitively more complex and much heavier than the entire OSNews codebase. Now, before you jump all over me – firstly, Slash and Scoop are Perl, and I don’t really read Perl, so I can’t speak as an expert there.  Secondly, WordPress and Nuke both are very portable and dynamic, whereas OSNews has a narrow focus and, location-wise, is very static.  But that aside, OSNews has withstood simultaneous link bombs from Slashdot and Digg.  As amazing as WordPress is, it’s mostly amazing that it functions at all and loads in less than 2 minutes per page with as much going on as I can see behind the scenes.   That’s not a cut on WordPress, by the way.

In fact, if anything , what is really impressed upon me is how smooth and simple OSNews code is, if I may be so bold.  OSNews runs superfast due, in part, to lots of creative caching, some on-demand, some via cron.  But it also does so because of highly efficient queries that are measured for speed on their JOINs, meaning in some cases, it’s faster to do 20 simple queries than one complex one, or build a long and scary chain of “OR x=a OR x=b OR x=c OR x=d…”  Watching WordPress code in action is really fun for me, but watching OSNews work knowing what I now know about how much work PHP can cram into its threads is even more fun.

The fact is, it’s rarely PHP that crashes a website. It’s usually overloading MySQL and/or bandwidth limitations. Obviously, we can’t do much about bandwidth. If you’re on a really cool host, they may be psyched for your Digging or Slashdotting, but most are not particularly keen on you using too much processor, too much bandwidth, or too many MySQL connections. Although MySQL is capable of amazing scaling, rarely do web hosts leverage it properly, and even if they did, rarely do most programmers know how to read into slow queries, find inefficient code like loops within loops, and debug a site performance before it’s too late.

The site linked from Digg shares a very lame trick, let’s examine:

//put this code at the very beginning of your page, before anything else
$randomdigg = rand(1,4);
if($randomdigg != 1) {
exit("Thanks for visiting, but the site is under a great deal of 
stress due to being on the front page of Digg. 
Please try back in a few moments. Thanks!");
}

Ok, so essentially, approximately 25% of the time, the page will work, the other 75% of the time, the user will get the message and be asked to refresh later. That’s really lame. First off, unless you want your website to be functional only 25% of the time, you have to be there babysitting it when it hits front page. Also, you need to remove this code. But what if you wanted everything to happen automagically? What if your site could withstand a digging, a slashdotting, a redditing, an OSNews’ing, a Farking, whatever…. all at once, without being forewarned?

Although there are lots of [[http://www.danga.com/memcached/|tools that can do magic for you]], you can leverage plain old PHP to do this dirty work for you, and it’s easy to integrate into your site.

Here’s the premise, we examine the referrer of the page, and if the page is from one or many domains that you specify, you build a cache ON REQUEST. Then, you serve the cached version. When the cache stales, say after minute or two, you refresh it, as needed, again, on request. And the best part is, it’s easy to do.

So, let’s review the code. First, at the top of the page, let’s do this:

$rfr = $_SERVER['HTTP_REFERER']; //get the referring site
$op = '';
if(strstr($rfr,'digg.com')) { $op="do-cache"; } 
$cache= "/path/to/mysite/cache/".$postid.".html";

Let’s take it line by line. First, we get the referring site. If it is digg.com, we’re going to turn the cache on by setting $op to “do-cache.” Note that we preset the $op variable to null to prevent abuse. Next, we define the file we’re going to use as the cache. Since we might want to do this for any entry/page, we’ll give it a unique address. Remember that you do not have to use .html as an extension, since it’s static code anyway. I’ve seen “id.cache”, “id.txt”, and even just “id”. It doesn’t matter, it will be included in a PHP page and spit out as X/HTML anyway.

if(file_exists($cache)) {
	$fmt = filemtime($cache); 
	if($fmt > time()-180) { 
		header("Location: http://mysite.com/cache/".$id.".html"); 
		exit(); 
	} elseif($fmt > time()-1800) { 
         //cache will reload if it's been reloaded 
         //in the last half hour
	   $op=="do-cache"; 
	} else {
	   $op='';
	}
}

This might seem overwhelming, but it’s really not. Check it out. If the cache exists, regardless of referrer, we’re going to check it. The filemtime() function will tell us when the cache was last refreshed. If it reports a time in the last 180 seconds (you can change that number), it will redirect you to the cache. PHP will barely have to do any work, Apache will barely have to do any work, and MySQL will not be touched at all. Almost any host can hang in there to serve static traffic like this.

But what about if the cache is old? Once your site is no longer getting hits every three minutes, for the next 27 minutes, it will blindly reload the cache. It will keep the cache going as long as the page has been hit in the last 30 minutes. After no one hits the cache for 30 minutes, it will go back to fully dynamic. When someone hits the page from digg again, it will start the caching process again. In this case, we’re going to let the cache rebuild. Enter the next part of the code.

if($op=="do-cache") {
	ob_clean(); 
	ob_start(); 
}

If the $op variable is set to “do-cache”, our mission is… uh… to build or rebuild the cache. So, we begin with two simple PHP standard functions, ob_clean() and ob_start(). The “ob” in these functions stands for “output buffering.” When you buffer your output, nothing is echoed by the script, but rather written to a buffer. In short, it’s all stored up in memory for eventual dumping later. Now we stop the caching scripts and just write our normal HTML via PHP and MySQL.

At the end of the page – the very end, after your html element is closed, you’ll need this last bit.

if($op=="do-cache") { 
	$buffer = ob_get_contents(); 
	$fp = @fopen($cache,'w'); 
	if($fp) { 
		fwrite($fp,$buffer); 
	}
	@fclose($fp); 
	ob_get_flush();  	
}

What’s up with this? Again, if we’re building the cache, we’re getting the contents of the buffer, which contains all of our page. Then we’re opening the cache file we specified above, and lastly, dumping the contents of the buffer into the cache file. Our final action is to clear the buffer, which is unnecessary to us now anyway.

That’s it. Your cache is reloaded, and will be served for the next three minutes, after which it will reload the cache every 3 minutes until no one hits the site for 30 minutes. Then it will go back to dynamic. If another digg visitor comes, it will recache and serve the cache. Having written several types of caching mechanisms for large sites myself, I can tell you this “cache on demand” method works. On OSNews v4, we use this for things like user-specific RSS files, which aren’t plausibly built via cron jobs and, frankly, we don’t want to allow access to MySQL without limit. They reload every 60 minutes, regardless of referer.

If you maintain a site and have any concern about being Dugg, I encourage you to research some sort of caching mechanism. Your web host will thank you, and you will be thankful for the maintained uptime and high hit count.

So, I got a phone call from the director of our customer contact department this week. He was concerned about the reports. He made a decision last week that when a call came in that was a lead – in other words, a non-customer, that his people would fill the phone number from the caller ID into the account number field. But when he ran his export reports, he found that hisn techs had entered this phone number for ALL of the calls: 429-496-7295. That’s weird, he said. So he called me and asked why that was. I checked all the calls and most were from one woman, so my first instinct was “Check if her browser has autocomplete turned on”. But he swore that he tried it too and gotten the same result.

I checked the database and sure enough, it was right there: 429-496-7295, in all of the fields. So I went back to the code. In short, I took the input from the form, and declared it like this:

$accountnum = (int) $_POST['accountnum'];

Pretty straightforward: explicitly declare the type. So, I started my debugging by attempting to manually enter the data into the database. Sure enough: the account key field showed this: 4294967295.

So, I went back to the PHP and started by dumping out the raw SQL query:

INSERT INTO calls ('','x','x','x','4294967295','x','x');

What? So the database automatically converts it to this weird phone number and PHP does too? Suddenly it occured to me. One of the benefits of 64-bit computing is the ability to address more memory. There are limits to what can be done in 32-bit computing, and one is that integers have a limit! In this case, a database field called “integer” is limited to numbers between -2,147,483,648 and +2,147,483,647. It just so happens that the number is the same length as a US phone number – 10 digits. Changing the db field to “BIGINT” allowed me to manually run the SQL query and it worked. But the app still didn’t.

PHP’s int() and (int) $var syntaxes both conform to the integer limit. So I devised a work around:

$ac = $_POST['accountnum'];
if(!is_numeric($ac) { $ac = (int) $ac; }

It’s not gorgeous, but it will more than suffice for an internal app. We web programmers don’t usually have to deal with big integers, so it’s totally possible that web developers would never have had occasion to handle a situation like this. Here’s looking forward to native 64-bit for our next server, though.

When using said portal, every URL looks something like:

domain.com/login.aspx?QS=jasbndfiaubnfoaeuifwoeifbwfe

The only difference is that the “QS” GET variable is even longer. I made the request of our developers to get rid of this query string for the login page, and the login page only. This is what that code looks like in PHP, inserted at line 1.

if(!$_GET['QS']) { 
     $_GET['QS'] = 'jasbndfiaubnfoaeuifwoeifbwfe'; 
}

That’s it. One line of code. In ASP.net, this cost me 3 hours of developer time. THREE hours.

Then I asked our old developers to make a change to their code. It was doing a check in login if they are customers from the new app or the old one. If they are old, it processes the login. If it’they are new, it gives them an error message. So I said, instead of giving them the error, let’s redirect them to /new-directory/login.aspx?email=[base64_encoded email]&password=[base64_encoded password].

This is that code in PHP:

if($is_new) { 
     header("Location: /newdirectory/login.aspx?email="
.base64_encode(stripslashes($_POST['email'])) . "&password="
.base64_encode(stripslashes($_POST['password'])));
} else {
     //process login
}

This cost me 2 hours at $165. Am I getting taken for a ride? I keep telling them – this would take 30 seconds in PHP. And they tell me, yes but ASP.net doesn’t work that way, and we need to change the web.config, and we need to recompile the entire site, etc, etc. If it were just one vendor, I’d be more suspicious, but two separate, unrelated developers are giving me crazy quotes like this.

I hear people bitch about PHP online ad nauseum. Every time I see real code, it appears PHP is FAR faster and far more friendly when it comes to customization.

PHP includes a variable in the superglobal scope $_SERVER called “PATH_INFO.” PATH_INFO includes information entered after the name of the requested script.

Let’s use firsttube.com as an example. The URL of a story is constructed as such:

http://firsttube.com/read.php/[id]/[url_friendly_title].html

The story is also accessible as /read.php?id=[id]

So how do we construct this so-called “pretty URL?” Using PATH_INFO. Read on for details.

Knowing the URL, we will use some code like this:

if(isset($_SERVER['PATH_INFO'])) {
	$getvars = explode('/', $_SERVER['PATH_INFO']);
	list($null,$id,$title) = $getvars;
	$id = (int) $id;
} else {
	$id = (int) $_GET['id'];
}

Let’s review piece by piece.

First, we find out if there is PATH_INFO set. This is information BEFORE a question mark, so it doesn’t include GET variables. Then, we use the standard explode() function to break up the PATH_INFO at the “/” sign, typical in a URL. It fills the “getvars” array, which I’ve arbitrarily named, it could be anything.

Now, the first element is always NULL in this sense, but the second element is the id we had before. And the third element is the title, which is something like title_of_the_post.html. In another post, I’ll discuss sanitizing your title.

So what have you discovered is that the “title.html” portion is useless. It’s there solely to please search engines and users who care. Try it. All that matters is the number. There are reasons why you’d validate the title, for example, so people don’t link to http://yoursite.com/storyID/your_mother_is_cow.html and have it be a valid URL. But for now, let’s keep it simple.

Next is just to construct a linked URL that you like. Perhaps your database tracks date. You could make a URL http://yoursite.com/index.php/2006/09/28/1558.html. Then do a little magic:

if(isset($_SERVER['PATH_INFO'])) {
	$getvars = explode('/', $_SERVER['PATH_INFO']);
	list($null,$year,$month,$day,$time) = $getvars;
	if(strstr($time,".html")) { $time = str_replace(".html","",$time); }
} else {
	$id = (int) $_GET['id'];
}

Then, after you fix the time, you can assemble the timestamp for SELECTing:

Let’s say you prefer the WordPress format, which is yoursite.com/year/month/title.html. Create an extra field in the database called “title” and record the title as you generate your entry. It becomes a permalink, uneditable, even if the title changes. Or not. That’s up to you.

Either way, using PATH_INFO truly puts you in control of the URLs on your website.

1. This version is more secure – it won’t let the content of the feed break your HTML. Update: Apparently, the desired behavior is to render the HTML, not to preserve the markup as markup, so the new version Eugenia has released reflects that change. So code will be rendered, including javascript, so beware!!
2. This version outputs friendly errors. The 1.0 version can fail if your php.ini isn’t set up right, or output a blank page if there are certain errors.
3. This version is more portable and doesn’t rely on a particular PHP configuration.
4. Most differently, this version can cache the results. This way, each reload won’t hammer an RSS feed. Rather, the results can be cached for a perdiod and fed from cache, and then when the cache expires, it reloads the cache.

The source code is here: MobileQuo. Note that you will need to upload a blank WRITABLE file in your MobileQuo directory. Then just use the rest of the code from Eugenia here.