Nobody leavz...
By staze
I know my site just got kind of ugly, but I’ve had a hell of a time working with a development version of the site, and I figured so few people actually read my site anyway that I should just bite the bullet and do the development on the live site anyway.
Anywho, it’s ugly now, but it’ll get better looking over the coming days/weeks. Please be patient.
Thanks.
By staze
WordPress uses DB entries called _transients to cache certain data. Cached entries are by default, things like RSS info, when cron last run, etc. If you use a plugin like Google Analytics Dashboard (GAD hereafter) though, you also get cached data relating to that. Unfortunately, either due to a bug in WordPress, or something left out of GAD, this cached info doesn’t seem to be deleted after it’s designated expiration time/date (_transients have a set expiration time, but they don’t seem to matter for GAD set transients).
Looking around online, I found someone who was dealing with a similar problem here.
The trick was to add the following to my the functions.php file in my theme.
add_action( ‘wp_scheduled_delete’, ‘delete_expired_db_transients’ );
function delete_expired_db_transients() {
global $wpdb, $_wp_using_ext_object_cache;
if( $_wp_using_ext_object_cache )
return;
$time = isset ( $_SERVER[‘REQUEST_TIME’] ) ? (int)$_SERVER[‘REQUEST_TIME’] : time() ;
$expired = $wpdb->get_col( “SELECT option_name FROM {$wpdb->options} WHERE option_name LIKE ‘_transient_timeout%’ AND option_value < {$time};" );
foreach( $expired as $transient ) {
$key = str_replace('_transient_timeout_', '', $transient);
delete_transient($key);
}
}
Later in the day, when that cron task ran, it removed all the expired transients from my wp-options table, and at midnight, when my system cron task ran to optimize my DB tables, the table shrunk down to the size it should be. If you so wanted, you could add the optimize operation to the above, but I figure it’s not that big of a deal once things are under control. As always, back up your DB and any files you modify before implementing changes. If you have access to a mysql console, you can also try the query out by doing something like:
SELECT option_name FROM wp_options WHERE option_name LIKE '_transient_timeout%' AND option_value < now();
You'll want to change "wp_options" if you have a different prefix set for wordpress. Theoretically, that query should show you all your expired transients.
Have fun!
By staze
So, it’s been a desire of mine for a while to make up a URL shortener. It seems like such a trivial coding experiment, but a fun one.
The first hurdle, getting something better than base10 for the URLs. That’s fairly easy, in that you can look here. The code he lists isn’t complete, as you need some other stuff. So, go grab the Cassis project code instead.
Note: when you “include_once” that code, you’ll want to do it like:
ob_start();
include_once("./cassis.js");
ob_end_clean();
Next you’ll need to code up something to add URLs to your database. That’s also easy enough. My suggestion would be a simple table that would have “id”, “shortcode”, and “url”. Make id a primary key, and add an index on the “shortcode”. Maybe one on the “url” if your going to be using the system heavily enough to require checking to see if a URL exists already before blindly creating a new short-url.
The last hurdle is to write the decoder. Basically, just have it look for “GET”, and look that up in the DB table, then set the “header(location: )” to be the URL in the for that short code.
Now, normally, you’d have a mod_rewrite rule that looked something like this:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule shortener.php?url=$1 [L]
Except, WordPress permalinks use something similar, and the two don’t play nice. Now, it would be cool to pass all URLs on to the decoder, and if it didn’t exist in the DB, you’d pass it on to the wordpress index.php. I haven’t quite figured out how to do that, but I found a pretty decent work around.
RewriteRule ^z(.*) shortener.php?url=$1 [L]
Stick that before the WordPress rewrite rules. What that will do is, if there’s a URL that starts with “z”, it’ll pass whatever comes after that “z” on to the decoder. Personally, I don’t have any pages, or files on my website that start with “z”, so it’s safe for me to do. Your experience may vary. If the decoder doesn’t find the url in the table, it simply redirects to my main page. I think I’ll change that to a 404 here once I am further along.
I’m going to keep playing with this. And hopefully, make some pretty spiffy use of it, but for now, it’s “basically” working. I’ll try to remember to post back on this topic when I have more to report on it. =)
Special thanks to my friend Aaron for the advice on this one.
UPDATE 1: I got 404’s to work for non-existant short codes. So, the key with wordpress is to use something like this
header("HTTP/1.1 404 Not Found");
include("index.php");
Basically, I was trying all kinds of other things, then realized that index.php for wordpress will look for the header state, and redirect appropriately. So, that’s it. It now throws a 404 (which, without that include, it would throw a 404, but it was just a blank page)… Cheers!