The Issues

• The url to the AJAX loader symbol is hardcoded into the plugin, so if you don’t use a white background in your theme the loading symbol looks quite ugly. If you replace the default icon with your own it gets overwritten on each plugin update.
• The javascripts for the plugin gets loaded on every single page of the site no matter if the plugin is used or not on that page, which adds unnecessary loading time where it’s not needed.
• The path to the stylesheet for the validation and submit messages is also hardcoded into the plugin, and if you edit the stylesheet to fit your theme, the edits gets lost on each update, and you have to reupload your custom stylesheet for the plugin.

The Solutions

So to not have to edit the plugin file, I added a few overrides in my theme’s functions.php file instead to change the behaviour of the plugin where needed.

Let’s start by taking care of the AJAX loading symbol. To change the path to the gif file I use a regular expression to update the url.

// Change the URL to the ajax-loader image
function change_wpcf7_ajax_loader($content) {
	if ( is_page('contact') ) {
		$string = $content;
		$pattern = '/(<img class="ajax-loader" style="visibility: hidden;" alt="ajax loader" src=")(.*)(" \/>)/i';
		$replacement = "$1".get_template_directory_uri()."/images/ajax-loader.gif$3";
		$content =  preg_replace($pattern, $replacement, $string);
	}
	return $content;
}
add_filter( 'the_content', 'change_wpcf7_ajax_loader', 100 );

This function filters the content, tracks down the AJAX loader tag and replaces the URL with a path to the current {theme folder}/images/ajax-loader.gif. So you can have your own custom AJAX loader stored in your theme folder instead, untouched on each plugin update. I added the if( is_page(contact) ) {} to the function to make sure the filter only runs on pages where needed, to not waste CPU cycles on pages where the plugin is not used. Contact is the name of the page where I use the form, change it to the name, or names of pages where you use the plugin.

Okay, now let’s see take care of the script loading on each page of the site.

// Add the Contact Form 7 scripts on selected pages
function add_wpcf7_scripts() {
	if ( is_page('contact') )
		wpcf7_enqueue_scripts();
}
if ( ! is_admin() && WPCF7_LOAD_JS )
	remove_action( 'init', 'wpcf7_enqueue_scripts' );
add_action( 'wp', 'add_wpcf7_scripts' );

This function removes the call to add the Contact Form 7 scripts on every page, and then adds back the call where needed, in my case I add them back at the page called contact, but change that to whatever works for you.

And finally, let’s deal with the stylesheet.

function remove_wpcf7_stylesheet() {
	remove_action( 'wp_head', 'wpcf7_wp_head' );
}
add_action( 'init' , 'remove_wpcf7_stylesheet' );

Here I actually remove the call to the stylesheet completely. As I have made my own style that fits my theme, I don’t use the default stylings. If you use the default stylings but just want it to load where needed, you could use an is_page condition like on the loading of the scripts. I could have put the Contact Form 7 Stylesheet in the theme folder using the same technique as on the AJAX loader to leave it untouched on a plugin update, but as I like to keep the calls to external files to a minimum to have the site load as fast as possible, I just put the WPCF7 CSS styles directly in my default style.css of my theme instead and got rid of the plugin stylesheet loading.

The Final Code

And here is what the final code looks like, ready to get pasted into the functions.php file in the theme you are using.

/**
 * Functions:	Optimize and style Contact Form 7 - WPCF7
 *
 */
// Remove the default Contact Form 7 Stylesheet
function remove_wpcf7_stylesheet() {
	remove_action( 'wp_head', 'wpcf7_wp_head' );
}

// Add the Contact Form 7 scripts on selected pages
function add_wpcf7_scripts() {
	if ( is_page('contact') )
		wpcf7_enqueue_scripts();
}

// Change the URL to the ajax-loader image
function change_wpcf7_ajax_loader($content) {
	if ( is_page('contact') ) {
		$string = $content;
		$pattern = '/(<img class="ajax-loader" style="visibility: hidden;" alt="ajax loader" src=")(.*)(" \/>)/i';
		$replacement = "$1".get_template_directory_uri()."/images/ajax-loader.gif$3";
		$content =  preg_replace($pattern, $replacement, $string);
	}
	return $content;
}

// If the Contact Form 7 Exists, do the tweaks
if ( function_exists('wpcf7_contact_form') ) {
	if ( ! is_admin() && WPCF7_LOAD_JS )
		remove_action( 'init', 'wpcf7_enqueue_scripts' );

	add_action( 'wp', 'add_wpcf7_scripts' );
	add_action( 'init' , 'remove_wpcf7_stylesheet' );
	add_filter( 'the_content', 'change_wpcf7_ajax_loader', 100 );
}

This tweak was published when Contact Form 7 was at version 1.10, and should continue to work just fine as long as no major changes is made to the inner workings of the plugin.

This led me to think that it would be real handy to get the log messages sent out by email as well, so you don’t risk to have a problem going on at the site unnoticed for days or even weeks.

So I wrote an extension to the native Log class in CodeIgniter which adds this functionality. Below is the code for MY_Log.php which extends the CI_Log class. MY_Log calls the native Log functions so the log file still gets generated, and if a log message was executed it also gets sent out by email afterward.

Change the email address in the code to the one you want to receive the log messages to, and then save the file in your application/libraries/ folder as MY_Log.php. This assumes that your Class Extension Prefix is set to MY_ in your config file.

I hope some of you find this class extension useful, and feel free to improve upon it. Cheers!

<?php
/**
 * MY_Log Class
 *
 * This library extends the native Log library.
 * It adds the function to have the log messages being emailed when they have been outputted to the log file.
 *
 * @package		CodeIgniter
 * @subpackage		Libraries
 * @category		Logging
 * @author		Johan Steen
 * @link		http://wpstorm.net/
 */
class MY_Log extends CI_Log {
	/**
	 * Constructor
	 *
	 * @access	public
	 */
	function MY_Log()
	{
		parent::CI_Log();
	}

	/**
	 * Write Log File
	 *
	 * Calls the native write_log() method and then sends an email if a log message was generated.
	 *
	 * @access	public
	 * @param	string	the error level
	 * @param	string	the error message
	 * @param	bool	whether the error is a native PHP error
	 * @return	bool
	 */
	function write_log($level = 'error', $msg, $php_error = FALSE)
	{
		$result = parent::write_log($level, $msg, $php_error);

		if ($result == TRUE && strtoupper($level) == 'ERROR') {
			$message = "An error occurred: \n\n";
			$message .= $level.' - '.date($this->_date_fmt). ' --> '.$msg."\n";

			$to = 'someone@example.com';
			$subject = 'An error has occured';
			$headers = 'From: Example Name <no-reply@example.com>' . "\r\n";
			$headers .= 'Content-type: text/plain; charset=utf-8\r\n';

			mail($to, $subject, $message, $headers);
		}
		return $result;
	}
}
?>

To make a long story short, WordPress is my favorite system to base a new websites on, and today you can make about any site in WordPress if you are patient enough. Personally I have always worked with the mindset of using the right tool for each job to get it done as quick and easy as possible.

I have a few WordPress based sites, but I also run two sites where WordPress just don’t cut it if I don’t want to spend an enormous amount of time writing custom plugins. I have built a vintage clothing webshop for a dear friend of mine called Sugarmood as well as a memorial site for our old Amiga demoscene group Equinox.

Neither of those two sites would work very well to develop within the WordPress system, so I have written them in plain PHP from scratch. And they work pretty well, but as they have grown in features I started to feel that searching through all the code was becoming cumbersome for each change or update. Coming from a classic application development background for the desktop I wanted to make a MVC (Model – View – Controller) based design instead in PHP to get a structured web application to easy update and extend upon.

So I wrote a few MVC prototypes in PHP to get the ball rolling and build a nice base framework to make sites upon where I easily could reuse code and write any custom functions. And they worked pretty fine.

But Doh! I forgot it was 2009 already and most things you can think of is already thought of.

Fortunately I did some googling resarch for some MVC techniques and stumbled upon some very fine PHP MVC Open Source frameworks out there. Why re-invent the wheel? So I downloaded CakePHP, Zend Framework and CodeIgniter, installed them all and explored and evaluated them.

They are all good frameworks for using the MVC model to develop web sites around but in the end my choice fell on CodeIgniter. Mainly because it was very lightweight and didn’t have it’s own huge library of custom commands that would take some considerable amount of time to learn. Remember I don’t do this fulltime so I wanted something that works well, was flexible and with a low learning curve so I could get going right away.

CodeIgniter fulfilled everything I wanted and more, and if you are already familiar with object oriented PHP programming the learning treshold is virtually zero. This suited me perfect.

So I’ll now begin moving these two sites into the CodeIgniter framework and then take them to the next step when I have them in place.

In this coming journey to get into the CodeIgniter world I’ll probably write quite a lot of custom libraries and plugins to extend it, everthing which I plan to also release here as well as writing a few articles around if I find out some interesting techniques. So keep your eyes open, as time passes there will be quite some CodeIgniter related articles, code snippets, tutorials and downloads available here.

So I say, come on and ignite me, baby!