Posting this here, mostly for my own benefit: http://snipplr.com/view/9444/copy-directory-without-svn-files/
rsync -r --exclude=.svn source destination
Updating WordPress Without Torching SVN Directories
Rails-Like SQL Query Logging in WordPress
Coming out of doing Rails development for the past couple years, there are several things that I have become pretty accustomed to that are somewhat aggravating not to have in the WordPress environment. The one thing that I miss the most though, is having a log of SQL queries to pore over and see what’s happening with the DB, and which queries are taking the longest. After some searching, I came across this post, which led me in the right direction. After some tweaking here is the result:
In your wp-config.php, add this line:
define('SAVEQUERIES', true);
In your functions.php, add this:
// outputs SQL queries to a log
add_action('shutdown', 'sql_logger');
function sql_logger() {
global $wpdb;
$log_file = fopen(ABSPATH.'/sql_log.txt', 'a');
fwrite($log_file, "//////////////////////////////////////////\n\n" . date("F j, Y, g:i:s a")."\n");
foreach($wpdb->queries as $q) {
fwrite($log_file, $q[0] . " - ($q[1] s)" . "\n\n");
}
fclose($log_file);
}
Jackpot! Now, you have a log file to go to town on. Enjoy!
WordPress Search API Plugin Installation Woes
UPDATE: This issue has been fixed as of version 1.0.8. Additionally, this fix was put into play in less than 24 hours, and that, my friends, is badassssssss.
=== Original Post Below ===
So I’m working on a big project and trying to come to grips with the various WordPress Search Plugins. The problem with the default search capability is that it’s not very good. Fortunately, enterprising folks have stepped into that void, not least of whom are Andy Skelton and Justin Shreve, who, on the very day I was looking for just such a thing, announced an updated Search API plugin. I got the plugin tested it out on my testing app and liked what I saw immediately. It is fast, uses MySQL fulltext indexing (or Google, or Sphinx, or others, by now, probably), has advanced search capabilities built in and is officially sanctioned and will be updated at least for the foreseeable future.
I said to myself, “Self, this is an awesome plugin. It does just what I want. I’m going to install it on my project app and go to town.” So I did, but then the hours of frustration came into play. Basically, any time I would search for anything, it would come back with no results. I said “That’s weird. It works on one app, but not the other. Hmm… What’s the difference?”
Well, it turns out that the project I’m working on is using a different MySQL server than the one on my local box, and it turns out that the remote server uses InnoDB engine by default, and not MyISAM. The problem with that is that InnoDB doesn’t support Fulltext Indexing. So, when you create the table via the plugin installation, it fails silently and your index table fails to exist. So when you are searching a nonexistent index, that fails silently and it just looks like you don’t have any search results.
Now, if you’ve read this far, you probably want to hear how I fixed the problem. Well, you can force a table to use a different engine by tacking on “ENGINE MYISAM” at the tail of your create table statement. I altered the statement, ran it manually, built the index and poof, it worked! Hopefully, a future update will have this rectified (or at least throw an error when the index table doesn’t build), but if not, now you can fix this problem, should you run into it.
For those who are really interested, this is what my create table statement looked like:
create table wp_search_index (`id` bigint(20) NOT NULL auto_increment,`object` bigint(20) NOT NULL,`title` text NOT NULL,`content` text NOT NULL,`post_date` datetime NOT NULL,`parent` bigint(20) NOT NULL,`categories` text NOT NULL,`tags` text NOT NULL,`author` text NOT NULL,`type` varchar(50) NOT NULL,`protected` smallint(6) NOT NULL,PRIMARY KEY (`id`),FULLTEXT KEY `title` (`title`),FULLTEXT KEY `content` (`content`),FULLTEXT KEY `title_and_content` (`title`,`content`)) ENGINE MYISAM;
Apparently, DirecTV Thinks It Is OK To Lie To Their Customers
Long story short: Two months ago, we had an out of warranty service call to fix an improperly installed switch on our DirecTV system. I figured this would be a $50 charge, but the technician said that since they installed the old switch wrong, that I should call and try to get a credit. I called and explained the situation and the customer “service” rep said that I would see a $50 credit on this bill or on my next bill.
Neither one of those things happened, so today I called back. The people I talked to today said that the charge was valid and that was why the credit that I was promised was not applied. I went back and forth with the mush-mouthed mumbling supervisor long enough for me to deduce that DirecTV doesn’t give a crap about what their customer “service” reps say to their customers, as long as they get them off the line and get on to the next billing problem.
Moral of the story: DirecTV is staffed by liars and people with low character. They don’t care about their customers and are willing to say whatever it takes to make their day easier and do less work. Additionally, they are perfectly willing to throw away long time customers who are generally satisfied with the service over fifty friggin’ bucks.
Making a WordPress Tag Cloug That Respects query_posts()
Tag clouds are a Thing. I mean, don’t get me wrong, I’m sure they are useful. But a certain type of people just LOVE tag clouds. This post isn’t about if they are awesome or if they are lame, but rather about how to make a WordPress tag cloud respect your authority, especially when using query_posts() to trim down the posts on a specific page.
You see, if you are using query_posts() to choose a subset of your posts, you probably don’t want the tags for posts that aren’t on that page to show in that tag cloud. Unfortunately, the default WordPress tag cloud gets the whole frigging taxonomy and that’s no fun for anyone. The approach I took was to make a second loop and snag the tags out of the posts that are in play. This approach might not work for you, but it worked for my needs at the time.
Here’s the code:
function qp_tag_cloud() {
$tags = array();
if ( have_posts() ) : while ( have_posts() ) : the_post();
if (get_the_tags() ) {
foreach(get_the_tags() as $tag) {
$tags[$tag->term_id] = $tag->name;
}
}
endwhile;
endif;
foreach ($tags as $key=>$value) {
echo "<a href="". get_tag_link($key) ."">" . $value . "</a>";
}
}
OK, so this is more of a list of tags than a tag cloud. Anyway. Hope this helps someone, as there was very little helpfulness out in the Google about this issue. Enjoy!