Optimizing LandingSites for WordPress
A new WordPress plugin called LandingSites came out recently that allows people referred to your site from search engines to see a list of related posts in case the original post wasn’t what they wanted. This is a great feature that has existed on some other CMS products for a while.
If a user searches for something and clicks on a link to your WordPress site, now you can present them with the linked post and also a list of other posts that are related. This is very similar in functionality to the Related Entries Plugin, except it only takes effect if a user was referred from a search engine. This allows you to only take the related search hit for referred users instead of every user. It also lets you greet new users with a friendly message about what they were searching for and what else might interest them based on their search terms.
The plugin installed just fine and I was able to add it to my theme fairly easily. However, the code was loaded with substr() calls and other slow functions. A lot of processing was being done, even if a user was not referred to your site (i.e. they were just browsing around). Instead of using a cascade of if(substr = searchengine) calls, I implemented a match array keyed off known search engine hosts that returns the query delimiter immediately. I also condensed the code into a few functions to remove redundant code.
The updated code can be downloaded here. Note that if you run WordPress 2.0, uncomment the bottom section where ls_install is. WP 1.5 users need to execute the SQL manually (I may add a WP 1.5 init routine if the spirit moves me). I need to add a version check to make this 100% portable, but I’m already nodding off… I may update it tomorrow to add the portability check.
Enjoy!
UPDATE: Now that I got a little sleep, I’ve updated things a bit to keep me from being embarassed for being lazy! The biggest change is the implimentation of static variables for the terms, delimiter, and referer. Since we call these routines multiple times in template code, it was redundant. Now using a static variable, the values are maintained during a page’s processing which eliminates a lot of processing. We process once for each value and reuse it every time we are called. I did not cache the database query since I can’t imagine why you would need to grab the related posts twice in one page.
I also made the DB schema update portable for WP 1.5 and 2.0 so the schema will be updated for you automagically even if you aren’t using WP 2.0.x. Anyone with a WP 1.2 install, please check that it works as well. I used a little trickery and a stored option to ensure the DB schema is only checked during admin interface page views, not main page views and can be checked quickly without a DB query (since options are cached already)
I fixed the problem where SQL queries failed if the post ID wasn’t available (i.e. you used it on a main page, etc) so you won’t see a post in the related list when viewing it.
Finally, I added support for search engines like A9 and Excite which include the search term as a URL path instead of in a query variable.
[Originally posted at baptiste.us - See the original article for comments]