I’m also loving the new Custom Post Types, and on one of my sites, I have setup a few different post types. On the frontend I have different widths for posts, pages and my new WordPress 3.0 custom post type ‘portfolio. I wanted to reflect the different widths in my admin editor style sheet as well. The posts are the narrowest ones, while pages are wider and my custom post type portfolio is the widest, so I have made 3 style sheets which are pretty much the same, with the exception of the

html .mceContentBody {
	max-width:640px;
}

which sets the width for the editor. My style sheets are named; editor-style-post.css, editor-style-page.css and editor-style-portfolio.css.
To be able to decide which post type I’m editing I check post_type in the $current_screen variable and then set the correct CSS according to that.

The code I end up with adding to my functions.php file looks something like this.

function my_editor_style() {
	global $current_screen;
	switch ($current_screen->post_type) {
	case 'post':
		add_editor_style('editor-style-post.css');
		break;
	case 'page':
		add_editor_style('editor-style-page.css');
		break;
	case 'portfolio':
		add_editor_style('editor-style-portfolio.css');
		break;
	}
}
add_action( 'admin_head', 'my_editor_style' );

By expanding on the code above you can continue defining stylesheets for any custom post types you might end up with in WordPress 3.0.

That’s it folks, cheers!

PayPal Widget Setup

I just released a new version of PayPal Donations, version 1.2.

New in this version is the inclusion of a sidebar Widget for the PayPal button. I’m using the new WordPress 2.8 API for the Widget, so it’s only available if you run the plugin on WordPress 2.8 or newer.

In the widget admin you can specify a descriptive text as well as overrides for Purpose and Reference if you wish.

Enjoy and cheers!

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!

When I set this site up, about two months ago, I didn’t really have any plans where I wanted to go with it, so I just named it Coding for Fun and downloaded a free WordPress theme to get it started so I had a place to host my Post Snippets plugin for WordPress.

Well, I’ve really enjoyed all the positive response I got from that plugin, and the ambition to make something good out of this site has come as a result of that. So I decided to make my own WordPress theme and rebrand it – to make the site a tad more serious. The theme is done (you’re looking at it right now) except some minor tweaks with the commenting styling, which I’ll do as soon as time permits.

I’ll continue posting updates to my WordPress plugins, as well as releasing new ones. And also I have some articles planned that will surface down the road. Both around WordPress and PHP as well as some other coding platforms that I am working with.

Still, this is just something I do for fun, I have my daytime (and sometimes evening and nighttime) job which takes a decent amount of time, so articles, new plugins and updates will come when they come. But things are cooking!

Cheers, and hope to see you around!

New in version 1.1

• Added an option to select the currency to make the donations in.
• Changed the default button in a new install from a custom button to the large button.

Enjoy and cheers!

The plugin comes with a few options, like selecting what button to display and a few other useful, optional, settings.

And of course it generates valid XHTML code (which I noted a few other donation plugins don’t).

I have a few more things planned for this guy, which will come in future updates, but this release gets all the basic parts of the the job done when you need a donation button for your causes or free stuff.

If time allows I have planned to rewrite my Fix Symmetry plugin for LightWave 3D from LScript to a compiled C plugin in 32 and 64 bits versions. I have a few other things planned this weekend as well to complete, but if I get around doing this, I’ll post an article about some useful techniques when working with LightWave plugin development.

New in this version is that you can create your own WordPress shortcodes with your snippets as well as making the quicktags optional.

Changelog for version 1.4:

• Added a checkbox for Shortcodes (SC) in the admin panel. When checking this one a dynamic shortcode will be generated and inserted instead of the snippet, which allows snippets to be updated later on for all posts it’s been inserted into when using this option.
• Added a checkbox for Quicktags (QT) in the admin panel, so Quicktags are optional. Speeds up loading of the post editor if you don’t need the quicktag support, and only use the visual editor. Defaults to off.

I have a few things that I’ll polish with the new shortcode function, like adding default variable settings and a few other things. So there will be another update not to far away, and then I think this plugin is pretty feature complete of what I wanted to do with it.