Perl Search Script for Web Site Searches

A client needed a search function for his site. Since it’s not a WordPress site (yet!), the options had to be reviewed. We settled on using a stand-alone script for adding a search function to the site. Could have used the simple Google search that you see everywhere, but we didn’t want to see the big G on this particular site.

Perlfect Search is an open source solution that was easy to upload, install and configure. Except for one small detail.

A dreaded 500 Internal Server Error appeared upon running a search for the first time. Aaack! It took a while to find the problem and my web host came to the rescue. The first line in the search script and indexer script both had a trailing slash and that made the files ‘not found’ on this particular web host.

The first line of the perl scripts at my host (your host or server may have things set up differently) should be this:

#!/usr/local/bin/perl -w

not this:

#!/usr/local/bin/perl/ -w

Check the Perlfect FAQs for more help. The README file that comes in the script zip package will help immensely for installing and indexing via SSH.

Paths For Building WordPress Themes or Plugins

When tinkering with the code that runs WordPress it’s very important to get the correct path to a file. Of course it is or else the files can’t be found and your new functionality won’t work.

According to the Codex –

In Version 2.6, users were given the ability to move their /wp-content/ directory to anywhere they want, and many users already keep all WordPress files (like /wp-admin/ and /wp-includes/) in an unusual place.

In case you’ve moved the files for your WP installation, you probably have a good handle on paths and how to traverse them. For those who don’t, it can be a hair-pulling experience to find the right path. Once the right path is found, work can continue.

WordPress Paths

To help avoid those DUH! moments, here are some functions and constants that WordPress has defined regarding paths. Once you’re familiar with these functions, writing useful and working code should become easier. Optional parameters may be of use in modifying the output for several of the following templates, including $path, $file or $scheme.

plugin_basename()
Usage: plugin_basename(__FILE__); Returns: the name of the plugin and file, such as “myPlugin/myPlugin.php”
get_theme_root()
Usage: get_theme_root(); Returns: path to themes directory. No trailing slash.
get_theme_root_uri()
Usage: get_theme_root_uri(); Returns: URI for themes directory. No trailing slash.
get_theme_roots()
Usage: get_theme_roots(); Returns: Themes directory with a leading slash, like “/themes”.
site_url()
Usage: site_url(); Returns: Site directory with no trailing slash.
http://www.site.com OR http://www.site.com/wordpress
admin_url()
Usage: admin_url(); Returns: Admin directory with trailing slash.
http://www.site.com/wp-admin/
content_url()
Usage: content_url(); Returns: Content directory with trailing slash.
http://www.site.com/wp-content/
plugins_url()
Usage: plugins_url(); Returns: Plugins directory with trailing slash.
http://www.site.com/wp-content/plugins/
includes_url()
Usage: includes_url(); Returns: Includes directory with trailing slash.
http://www.site.com/wp-includes/
home_url()
Usage: home_url(); Returns: Home directory with no trailing slash.
http://www.site.com
ABSPATH (constant)
Usage: ABSPATH. Returns: Home directory with no trailing slash.
TEMPLATEPATH (constant)
Usage: TEMPLATEPATH. Returns: Path to current theme with no trailing slash.

There are a few more functions for multisite installations and backwards capability specified in the Codex.

PHP Paths

Some PHP functions worth noting –

  • __FILE__ returns the filename of the script that is currently being run
  • dirname() returns parent directory’s path for a given filename with no trailing slash
  • basename() returns the filename component of path without any parent directories
  • getcwd() returns current working directory

Use the functions or constants indicated to build your paths instead of hard-coding them. You’ll save yourself a LOT of trouble when it comes time to move your WordPress installation to a new server or directory.

Using PHP Inside Content of WordPress Blogs

Using PHP inside of content on WordPress sites may not produce the expected results. As WordPress is built in PHP, you might think you could just start typing PHP code inside a post to pull some information from a database. Sorry to say, but it doesn’t work that way.

WordPress takes your blog content and runs it through some backend shenanigans to create the output that you see on the screen. WP expects to find other content in posts, like text and images, not code.

To run PHP code inside a blog post or Page, you’ll have to work a little differently than simply filling up the space in the text editor.

There are two ways (at least) of using PHP inside WP blogs to produce the desired output. The first way is to set up a WP template page that points to a pre-written PHP page that is identified in a Page. The second way is to use a plugin that facilitates PHP code execution inside content areas in WordPress. Both ways have their advantages and disadvantages.

Using WP Template Pages to Execute PHP Code

A template page is used to identify a pre-written PHP page. By saying “a pre-written PHP page” I mean a .php file that you’ve already written and which has been executed successfully by a server. A template file has at the top of it a PHP comment which identifies the template name followed by an include statement that identifies the .php file. WP template files must follow this format to be properly identified by the WordPress engine as a template file.

<?php
/*
Template Name: soccer-roster
*/
include (TEMPLATEPATH . ‘/soccer-roster.php’);
?>

The above snippet  is a complete template file which indicates the name of the template as “soccer-roster” and the path to the associated PHP file, soccer-roster.php. The template file is best saved with “template” in the file name. It must be located in the site’s theme folder.

After creating the template file and .php file, upload both to the theme folder. Create a blank Page. Do not put anything where you would normally write the content, but go ahead and give it a meaningful title. On the Add New Page page, look for the “Page Attributes” widget. Click the down-arrow to expand the list of templates and select your template. Using the example above, you would select the “soccer-roster” template. If the template is not stored in the theme folder, it will not appear in this drop-down list. Save the page and preview it. The PHP code, from soccer-roster.php, should be executed just as you would expect.

PROs

  • No interference from WP, code interpreted as stand-alone PHP.
  • Page renders as expected.

CONs

  • Can only be used with Pages, not posts or text widgets.
  • May have to wrestle with adapting PHP output into style of site.
  • CAUTION: Use a child-theme to safely save site-specific template files.

If your site relies heavily on plugins, using template pages may be the best method, see below. If it’s not a big deal to style the PHP output pages like the rest of your site, creating WP Pages that use templates is a breeze. If you need to put code in a post or text widget, keep reading.

Using WP Plugins to Execute PHP Code

Modifying WordPress themes is not for everyone, so using a plugin to execute PHP code may be the easier option. There are more than a handful of plugins available for the task. I chose to use Exec-PHP plugin for WordPress. It is a very well documented plugin. Thank you, Sören.

Download, unpack, upload and activate the plugin in the usual fashion. Verify these settings to make the plugin do its magic:

  • Disable tag balancing by unchecking ‘WordPress should correct invalidly nested XHTML automatically’ in the Settings/Write menu.
  • Disable the WYSIWYG editor (visual editor) in the user’s settings through the Users/Your Profile menu.
  • Assign the ‘unfiltered_html’ capability to the user, if user is not the administrator. Can use role manager plugin to assign this capability to other users.
  • Assign the ‘exec_php’ capability to the user, if user is not the administrator. Can use role manager plugin to assign this capability to other users.

Once I disabled the visual editor, my site was ready to go.

PROs

  • Easy, just change a couple of settings in blog admin. Plugin gives highly visible warning on Add New Post or Add New Page pages if the settings are not correct.
  • PHP code can be written in the normal fashion using the <?php ?> tags. It does not need to be marked up in any special way as it might with other plugins.
  • PHP can be used in text widgets and posts, as well as Pages.

CONs

  • Can’t use plugins that embellish or rely on the WYSIWYG editor.

Didn’t try any other PHP-execution plugins because Exec-PHP worked as soon as the visual editor was disabled.

As mentioned either method will get you there, it’s just a matter of style. If you need the visual editor to create your posts, use the template method. If you want to put PHP code in posts and text widgets, use the plugin method. Good luck!

Which Versions of PHP and MySql Run Your WordPress Blog?

How Healthy is Your WordPress Blog? Do you know what version of PHP or MySQL your server is running?

The improvements in WordPress continue. Check the state of your blog’s health by running the new Health Check plugin. Currently, it will check for the versions of PHP and MySQL that are running your blog. In order to work with WP 3.2, your server will need to be up-to-date and running —

  • PHP version 5.2 or greater
  • MySQL version 5.0.15 or greater

In an attempt to help others into the 21st century, WordPress will no longer work using PHP 4 or MySQL 4.

WordPress will also drop support for Internet Explorer 6. Yay! There are other improvements coming, so stay tuned!