Stripslashes in textarea in a WordPress plugin option

Working on a WordPress plugin today I found that when HTML was added within a ‘textarea’, backslashes (\) were being added to the code wherever there was an apostrophe or quotation mark.

After hunting down a solution by searching for things like:

wordpress text stripslashes
wordpress stripslashes in textarea
wordpress slashes in textarea
wordpress plugin options textarea slashes

etc. etc. etc.!

I tried a suggestion which is supposed to disable PHP magic quotes, found in this article:

Getting rid of unwanted backslashes in WordPress form input from

if ( get_magic_quotes_gpc() ) { 
$_POST = array_map( 'stripslashes_deep', $_POST ); 
$_GET = array_map( 'stripslashes_deep', $_GET ); 
$_COOKIE = array_map( 'stripslashes_deep', $_COOKIE ); 
$_REQUEST = array_map( 'stripslashes_deep', $_REQUEST ); 

Unfortunately this didn’t work, and there’s a warning at about this stripslashes_deep method being unreliable:

“Please Note: On any page load where WordPress itself loads, the above example will be unreliable. Very early in its execution, WordPress intentionally adds “magic quotes” for the sake of consistency. This is regardless of the return of get_magic_quotes_gpc(). Core code, and plugins all over, expect the values of $_REQUEST etc to be escaped.”

The solution to the problem of backslashes in a textarea in a WordPress plugin…

I eventually found the solution from this post on the WordPress forum where Rev. Voodoo was having the backslashes problem on text input, but NOT on textareas – so I just took a look at the method he used on the textarea’s and copied that.

When you echo the option in to the textarea, that’s where you add your ‘stripslashes’ code, like so:

<textarea name="myplugin_options[mytextarea-option]" rows="7" cols="57" type='textarea'><?php echo stripslashes($options['mytextarea-option']); ?></textarea>

And voila! Backslashes are no more :)

But then – I had a problems displaying the options in my theme on the front end of the site. First, the HTML code was printing as escaped entities (I think that’s the correct way to describe it…) – meaning on my page I could see the ‘< p >‘ and ‘< a href' etc. as text rather than them being displayed as a regular HTML paragraph and anchor, and I was getting backslashes again. This is the code I was originally using to display the option in my theme:

$options = get_option('myplugin_options');
$mytextareaoption = $options['mytextarea-option'];
echo "{$mytextareaoption}";

And this is the updated code I used to display the option in my theme, without any HTML escaping errors or backslashes:

$options = get_option('myplugin_options');
$mytextareaoption = $options['mytextarea-option'];
esc_html( $mytextareaoption );
echo stripslashes ( "{$mytextareaoption}" );

And voila again! No HTML errors or backslashes on the front end :)

For reference: this article about Data Validation at is really informative. Although, there are so many options it can a bit overwhelming understanding which one is best to use in a situation. Nevertheless, it’s definitely worth a read to help us learn more about WordPress development.

Animal rescue custom post type plugin for WordPress

screenie_plugin_animals-cpt_add-postI’ve worked on a number of animal rescue WordPress websites and recently developed a basic ‘custom post type’ plugin so that animals for adoption can be posted separately from regular ‘posts’. Posts can then be reserved for news, events and general blogging.

I’m making my ‘animals custom post type’ plugin available for download here (it’s free, released under GNU General Public License):

Download Animals Custom Post Type Plugin

Download the .zip file and:

  • upload it via FTP to your wp-content/plugins directory, or in your WordPress admin panel, go to Plugins > Add New > Upload, to upload the file manually, then
  • activate the plugin on the ‘Plugins’ page and the ‘Animals’ option should then appear in the menu

Note: In some cases, the permalink structure must be updated in order for the new template files to be accessed when viewing posts of a custom post type. To do this, go to Administration Panels > Settings > Permalinks, change the permalink structure to a different structure, save the changes, and change it back to the desired structure.

What’s included in the ‘Animals’ custom post type and custom taxonomies plugin?

Once the plugin has been installed and activated you will see an ‘Animals’ option appear in the list on the left of the WordPress admin dashboard.

Here you can add posts for any type of animal for adoption, and there are 6 types of custom taxonomy included with the custom post type, which are:

  • Species
  • Gender
  • Age Group – included so that you can group animals of similar ages together, e.g. 0-1 years, 2-5 years etc.
  • Age – so that you can also add a more specific age
  • Rehoming Status – you can add custom rehoming statuses such as ‘Available for adoption’, ‘In foster’, ‘Rehomed’ etc.
  • Rehoming Options – you can add custom rehoming options such as ‘Can’t be homed with children under 10’, ‘Can live with dogs’ etc.

All of these taxonomies can then be easily accessed from the front end of the site, for example in a menu, a tag cloud widget or an advanced search system so that people can perform very specific searches on animals for adoption.

(If you want to add more custom taxonomies here’s a very useful ‘Custom Taxonomy Code Generator‘.)

Why use a custom post type for animals for adoption?

Using a custom post type has many advantages over using regular posts:

  1. It makes the administration process easier for the rescue owner/website manager – it’s a much better user experience if you can see the ‘Animals’ section in the admin panel and click on ‘add new animal’ instead of using ‘add new post’ for animals AND regular posts alike.
  2. You can use different taxonomies for each post type, so whereas your ‘posts’ might just have the tags and categories taxonomies available, your ‘animals’ can have custom taxonomies like age, gender, breed etc. and it’s much simpler for the end-user than if these custom taxonomy options are presented to them on the post edit page when they’re simply writing a regular news/blog post.
  3. It’s easier to distinguish and display the animals for adoption on the front end of the site – your animals for adoption can be given their own style based on the custom post type – many WordPress themes add a special CSS class to the ‘body’ html tag based on the custom post type of the archive or single post being viewed, and special custom post template files can be included in your theme, so the layout of the page can be completely customised.
Update July 2014
I’ve had a few queries in the comments about how to display your animals custom posts. I found this tricky when custom post types were first introduced too!

You can basically access the custom posts via a URL and you can include the URL(s) in your menu on the front end of your site. So for example:

To view all animals:

All animals marked as ‘available for adoption’:

All animals of a certain species, for example – dogs:

All animals of a certain gender:

All animals of a certain age:

So whatever terms you have used for taxonomies you can view all posts marked with those taxonomies.

Another method suggested by Jennifer Mann in the comments (thanks Jennifer!) is to use the ‘Display Posts Shortcode plugin‘ which makes it super easy to create a page and simply add in a shortcode to display any list of posts within that page.

So for example, to display a list of all animals posts created using this ‘animals custom post type’ plugin, you would use this shortcode:

[display-posts post_type=”phanimals”]


To find out more about different options for the list using this method (such as showing images and excerpts), see their arguments document here:

I love helping animal rescues get more from their WordPress websites, so hopefully this will be the first of many posts dedicated to the topic :) Soon I will add more information and code examples on how to display the custom taxonomies on your animals for adoption posts on the front end of your site using the terms function.

Do let me know in the comments if this plugin was useful for you or if you have any questions.

New WordPress default theme Twenty Thirteen, let’s take a look

screenie_twentythirteenNow that Twenty Thirteen is officially released and is now the default theme for WordPress, I thought it was high time I took a look under the hood.

Before I dig in to the code I must be honest and say I’m not very fond of the default design of Twenty Thirteen. I like the general colour scheme but I think the background image on the header is quite ugly!

I’m sure the theme will look great on a mobile device, but on a desktop monitor everything looks a little on the large side – very large fonts (which are great as long as they’re not overused), a large header area with lots of wasted space and large empty areas to the left and right of the main content column in the center (perhaps sidebars can be added in the theme options? Haven’t checked that out yet).

Presumably the header background image can be customised by the site
admin which is an incredibly useful feature for the everyday WordPress user, but still I feel the area has been made far too large (I thought big headers were ‘so 5 years ago’).


I do like the fonts used in Twenty Thirteen. It makes a change for a default theme to use a serif font for entry titles and a sans-serif font for the main body of text. It really helps the titles to stand out and is something you usually see a lot on professionally designed custom themes.

I like the idea of using a different background colour for posts of different formats – BUT – pretty much every site I’ve made/worked on so far, barring one, hasn’t used the post format feature, so this may be wasted on many sites. Maybe it would have been better to have background colours alternate on a per-post basis so that a long list of regular posts would still be able to make use of the effect.

Of course, design is subjective – so whilst there are things I do and don’t like about Twenty Thirteen, I can understand that many people will think it looks lovely, and that’s all good.

So we shall move on to the ‘under the hood’ portion of this Twenty Thirteen review:

Twenty Thirteen CSS and HTML

First impressions on the CSS of the theme are – “WOW, this is much cleaner than Twenty Twelve!” There’s less clutter and the code is laid out in such a tidy manner.

REM sizes are gone in Twenty Thirteen, yay!

I’m glad ‘rem’ sizes aren’t used in Twenty Thirteen as they were in Twenty Twelve. That always seemed overkill to me, but perhaps they will make a come back at a later date when the web design world is more prepared for them.

I’m glad that the basic structure and selector (CSS ID’s and classes) names have remained pretty much the same, albeit with minor changes here and there.

Looking at the HTML source of my demo page I see that some areas of the footer have ‘hard coded’ CSS elements within in the code, like so:

		<footer id="colophon" class="site-footer" role="contentinfo">
				<div id="secondary" class="sidebar-container" role="complementary">
		<div style="position: relative; height: 307px;" class="widget-area masonry">
			<aside style="position: absolute; top: 0px; left: 20px;" id="pages-2" class="widget widget_pages masonry-brick"><h3 class="widget-title">Pages</h3>		<ul>
			<li class="page_item page-item-495"><a href="">A parent page</a>

This is very unusual and as far as I knew – frowned upon. I’m not sure why this has been done. I can’t imagine the theme would contain errors so blatant, as they are tested by a lot of people before being officially released, so I wonder if the CSS is somehow dynamically generated, perhaps based on the users browser size? I’m still trying to figure that one out.

Twenty Thirteen colours

The colour scheme for Twenty Thirteen is warm and well put together (although as already mentioned I’m not very keen on the coloured circles header image).

One of the first things I do when playing around with the CSS for a child theme is edit the colours used for links. This was very easy in Twenty Twelve with most link colours easily change-able by just editing the single colour setting for anchors (the ‘a’ element) in the CSS. But I notice Twenty Thirteen has used quite a few different HEX colour codes for links, and 3 or 4 of them are very close variations of the same dark red, meaning the difference will probably not very noticeable so it would’ve been easier, and in my opinion less confusing to the end user, to use just the one dark red colour.

But this is a small complaint. Not even a complaint really, more of a comment :)

Twenty Thirteen Theme Options

Although I could understand the zen-like simplicity of NOT having a theme options page for Twenty Twelve, I’m glad to see this is back in Twenty Thirteen. I’m glad on behalf of all the non-web-designer WordPress users out there who’ve been crying out for ways to customise the look of their website without having to really deal with code, which is understandably not everyone’s cup of tea.

(And the options page will certainly come in handy when people want to change that butt-ugly header image! [/joke])

Twenty Thirteen conclusion – more study needed!

As this has been just a brief review and there’s a lot of features I haven’t even seen yet, I won’t give a full on conclusion here except to say that first impressions are good – it seems to be a friendly, uncomplicated theme.

More study will be required before I can officially (in my head) give it a placing in the ‘which is best’ list of the last 4 WordPress default themes.

Free Twenty Thirteen child themes will follow – the fruits of my study! Watch this space.