The huge range of useful plug-ins for Wordpress are a contributing factor to its huge popularity both as a blogging platform and as a content management system. The great thing about the plugin system is that – in theory at least – it’s dead simple to setup. You upload the plugin to your plugins directory, then go into the wordpress admin area and activate it. Any special instructions will then appear from the plugin itself.

Of course life isn’t always that simple. A client called early this morning saying that he was having problems installing a new plugin (the mailchimp wordpress plugin- that he was getting a ‘Plugin could not be activated because it triggered a fatal error.’ message. Working through his problem is hopefully instructive for others, so here’s what we did.

Check the Wordpress error message

Error messages appear for a very good reason. They’ll give you the clue as to what the problem is. So try to activate the plugin, and at the top of your plugins page, when a problem occurs, you’ll get an error message.

In many cases the problem exists because of a limit placed by the server setup on memory allocated to php. In this case you’ll get a ‘Allowed memory size of xxx bytes exhausted while upgrading Wordpress‘. There’s a good discussion on how to fix this very common problem here

That, though wasn’t the problem for this client. Instead he was getting the following error:

‘Warning: main(/public_html/testsite/wp-content/plugins/mailchimp/MCAPI.class.php) [function.main]: failed to open stream: No such file or directory in/public_html/testsite/wp-content/plugins/mailchimp/mailchimp.php on line 28

This straight away gives us something concrete to work on. In the activation of the plugin the file MCAPI.class.php is called, and if not present will produce the above error.

“But it is there”, an increasingly frustrated client remarked – “after all, I uploaded the latest version of the plugin directly, and even went into the file-manager to check if the file was there!”.

A quick check on the server confirmed my  hunch. The file was there, but was in lowercase – rather than the specified MCAPI.class.php.  In grammatical terms I’m as guilty as the next for my often random capitalisation of terms. This often produces mild irritation from people reading things I’ve written, but rarely causes downright confusion – Web Servers, though, are a different case.

A file in lowercase is not necessarily the same as a file in uppercase – for example, on a unix system you can have both existing in the same folder.  So, the simple solution? A quick rename of the offending file to its correct uppercase format – and bob’s your uncle the mailchimp plugin was fine

The offender? Take a look at your ftp client

This solved the immediate problem, but how had it occured in the first place? After all, Client A. had done everything according to the book – he’d downloaded the latest version of the plugin. He’d checked that it was compatible with the version of wordpress he was running (this is another useful check to do whenever having problems with a plugin), and uploaded it.

A quick look at his ftp program settings revealed the problem. Using the wonderful Total Commander program, he’d missed one tell-tale setting which was causing all the problems:

That little box checked, ‘convert file names to lowercase’ was the problem. So, from now on, it’s unchecked, and all systems are go.

Have you had any other problems installing plugins, for which there was a simple solution? Let us know and we’ll link to them.

Things have been very busy here for the last couple of months, so sorry for the lack of posts. We hope to resume normal posting shortly.

In the meantime, here’s a quick and simple wordpress tip that’s come in handy for us so we thought it would be good to share.

One common problem you can run into, when customising wordpress themes, is the default length of  text returned by the handy template tag the_excerpt . The default, which is set at 55 words (not characters!) is often to big a chunk to fit its required purpose – that of providing a teaser for posts.

What to do? Well, you can add code into the functions.php file to change the default size of the_excerpt site-wide – as detailed here

What, though, if you just want to reduce the excerpt on a specific page – for example on your home page (by default index.php)?

Using the simple php command  substr you can reduce the_excerpt directly in the loop.  You’re going to have to use the get_the_excerpt hook first though, as you can’t run substr directly on the_excerpt template tag.

Let’s take the example of the front page:

The loop starts here: <?php while (have_posts()) : the_post(); ?> returning template tags like the_title(), the_author(), and the_excerpt() for use within the template.

We’re going to create a variable called $excerpt and assign the contents of get_the_excerpt() to it. So <?php while (have_posts()):the_post();$excerpt=get_the_excerpt();?>

Then, wherever in your template you want to reduce the size of the_excerpt simply replace it with <?php echo substr($excerpt,0,x);?> where x is the number of characters (not words!) that you want to display.  So, to display an excerpt of 50 characters you would have <?php echo substr($excerpt,0,50);?>

Adding a ‘Read More’ link

You should, of course, provide a link to the full post when using the_excerpt or any variation on it. To do that, simply add <a href=”<?php echo the_permalink();?>”>[ read more...]</a> immediately after your excerpt code.

Stumbled across this problem recently and thought it worth sharing, for anyone who’s trying to set up a form on wordpress and on submission gets a 404 error.

Recently we set up a contact form for a client on their wordpress blog. Many people simply use one of the numerous plugins available to achieve this, but the client wanted some particular customisation for this form so we decided to set up a page template to handle the contact form.

All well and good, until the form gets submitted (regardless of where the action is pointed). Some scratching of heads ensued, as we tested the form independently of wordpress. This post on the wordpress support site gave an indication of the problem. Using the field ‘name’ was causing all to go awry. Change your field name to something like cname and the form works fine.

Great – that’s a solution, but why does it happen? Well, you can get the answer quickly by adding to your form template. Load the page and you’ll see that $name is a variable already used by Wordpress for the slug, or the part of the url specific to a given page when using the customised permalinks structure. When you assign a field the id of ‘name’ you send wordpress looking for a page that doesn’t exist, hence your 404 error.