Let’s say you go to the WordPress theme repository and grab a nice free theme which has been written by a developer less than ‘au fait’ with WordPress functionality or best practice. You turn on the theme, all looks good and then go to write a post only to be presented with the page from hell because loose CSS rules used in style.css have broken the editor page look and feel all together. As there is no way in CSS to set a priority without rewriting the code itself you are left with a mess.

Pre WordPress 3.3 this wasn’t an issue as you needed to explicitly declare an editor style sheet in order to use the styles and make it look somewhat closer to that which you might find on the front end of the site.

Now.. turning it off! Well it will require some coding and in actual fact the simplest way to do anything about it is to make your stylesheet invisible to WordPress. Let me explain: The correct way to enqueue any CSS and JS on your site is to do something like the following:

add_action('wp_print_styles', 'theme_add_stylesheet');
function theme_add_stylesheet() {
    wp_register_style('theme_stylesheet', get_stylesheet_directory_uri() . '/style.css');
    wp_enqueue_style( 'theme_stylesheet');
}

This means that when the wp_head action is triggered from header.php in your theme the style will be printed to screen along with the other styles and scripts. The enqueue style function adds the name and location of the script to a global array which can be reused at any time. In short, WordPress knows that it is a CSS file declared by a plugin or theme and therefore can reuse it at will.

The fix is simple.. don’t use that method and, instead, use the original crude method of adding a stylesheet which is to write the HTML yourself as follows:

<link rel="stylesheet" href="<?php bloginfo('stylesheet_url'); ?>" type="text/css" media="screen" />

This code, when placed in header.php of your theme, simply outputs the line in the head section of your page and includes the stylesheet unbeknown to WordPress and therefore won’t be used in the editor.

99% of the themes I have seen and used use the latter method so it’s not an issue but hopefully this will hel someone who has just upgraded and has some sort of multicoloured and wierdly laid out admin post page.

I have had an interesting problem for some months now which I have just solved albeit crudely! I have written several plugins and released them into the WordPress plugin repository as regular readers of this site might already know. What you are unlikely to know though is that in doing so all you get is an influx of support questions. I personally like these.. it gives me the illusion of helping people out whilst really knowing that it should have been right to begin with

The worst of these aforementioned support questions are to do with plugin conflicts. Cue potential threads and threads about how the ‘other guy’ did something wrong which is going to need to poor user to go to their site/forum to get it sorted before our plugins can work in harmony as they were originally intended. This isn’t the best answer to a support question and certainly won’t get you any repeat custom. In all likelihood the user will ditch the plugin he finds least useful (yours.. after all he came to you to sort it in the first place meaning yours is likely the plugin they have just installed and are playing with) and install one of the other counterparts which undoubtedly does the same job but with umpteen donate buttons plastered all over it (I won’t go into that one right now but see my previous post for my thoughts on that particular subject).

One such example of a conflict I have been getting all year. It’s to do with my Welcome Email Editor plugin. WordPress does a fair few things very well indeed but sadly there are a few where it really could improve. This is why my Welcome Email Editor plugin exists at all. Can you guess what it does? Really? Ok so it lets you edit the WordPress welcome email.. the one that gives the user their user name and password if they decide to sign up for your site. The default offering is a little dull but luckily the guys who wrote WordPress have half heartedly thought about how it can be improved. Why let plugin writers like me do it of course. Sadly they opted not to use the action and filter system which already is ingrained in the rest of WordPress (for good reason I’m sure.. likely to do with load order) but instead just wrapped the entire wp_new_user_notification function in a PHP function called function_exists. This does what it says on the tin and only declares the function if someone else (a plugin or theme) doesn’t get there first.

In most cases this system works fine when you install a plugin dedicated to editing the welcome email and leave it at that. In reality most blogs have 30+ plugins active at any one time and probability and inevitability both say that more than one person is likely to want to jump on this handy feature for their plugin or theme. This means that one of the plugins needs to go! Normally if it were two plugins designed to edit the welcome email then we would be ok.. an obvious conflict of interest but what if one were a forum or shopping cart in conjunction with my plugin? Which goes then? Well the one which provides less functionality of course which, sadly, in that example would be my little plugin.

To make it somewhat more awkward, some plugins like to call WordPress core files directly thus causing the default function for the welcome email to be called before any other plugins and therefore chucking everyone else out of the race to declare the function first. Maintenance Mode is a plugin I know which does this when the system is active although it sorts itself out when you come out of maintenance mode so not really an issue. I have just been informed of another conflict with a plugin which makes dealing with WP Ecommerce in bulk easier (and we all know that was needed years ago!). Whatever reason they have called pluggable.php for I don’t know but it means that my plugin (or any other trying to declare a function first like this (it’s more common than you think!)) won’t function.

It’s such a simple solution but it works.. to fix you just need to rename my plugin directory to something else. WordPress naming conventions make calling a plugin anything starting with ‘WP’ very trendy indeed. My plugins are all prefixed SB, my initial, for archiving more than anything else but the people who do the same with initials AA are laughing at us all right now I assure you (or not laughing but living in blissful ignorance!). Here’s the logic.. it’s really simple:

On any given page load WordPress will load it’s core files first and then look for plugins to bolt on to the system using the action/filter system. This is where the PHP files are initially ‘required’/'included’ and individual balls (controlled by the plugin writers) set in motion. WordPress keeps a list of active plugins to call in the database in the wp_options table under an imaginatively named row called ‘active_plugins’. This is an alphabetically ordered list of plugins labelled by their location beneath the plugins directory (eg: welcome-email-editor/sb_welcome_email_editor.php). It will run from top to bottom including these files. This means there is a priority order for code defined only by the fact it has a name higher up the alphabet.

So to conclude the way to get your plugin run first to avoid conflicts with other plugins just put it in a directory called something beginning with a low alphabetical letter or special character. In my case I get a conflict every few months so it’s not worth changing but I am going to recommend that the next person to mention a conflict just renames their plugin folder from welcome-email-editor to -welcome-email-editor (note the leading hyphen). Job done!

I might add that changing the name of a plugin directory once a site is live isn’t a good idea on account of some plugins storing pathing information in the DB and WordPress itself storing the fact that plugin is active or not by it’s name in the directory tree. Put plainly if I change the name of my Welcome Email Editor plugin on my own site then it will deactivate itself and I shall need to reactivate it for it to continue working. Not a huge feat but try explaining that to normal user. Cue yet more support emails.

Hope this explains an issue for one or two of you. Perhaps plugin writers will learn not to call core PHP files directly in future to make my day run more smoothly… I doubt it!

Simple right using one of those bulky and, sometimes, advanced plugins? No…

I decided to write a plugin for it. The fields we wanted were clear, who are you, how can we get in touch with you and can you attach your CV? Well I wrote just that. This plugin adds a widget which allows you to configure the form and the email which gets sent. Most importantly it allows you to either set a fixed recipient address for the email or allow it to be set by the post author when the form is submitted. Emails sent with an attachment and it does work very well indeed (or did for us).

Note from the screenshot that you can include in the intro paragraph the name of the person who is to be informed if you so wish (admin2 in our case).

I am happy to make amends to this plugin for anyone if they will use it. I dare say I shall use it again in the future. I hope someone finds it useful if only for something to base their own plugin on.

Download it here: SB Mail Attachment Widget (2.7 kB)

It was written for a recruitment company so the screenshot shows it in the job vacancy context. The title, intro paragraph (optional) and labels for the boxes are all configurable via the widget as is the content of the email sent to the recommended person.

Currently there are no stats logged for usage of this plugin but it’s something I am going to be looking at in due course. It would be nice, for instance, to record the details of each recommendation sent either in our own system or in Google Analytics.

Download it here: SB Tell a Friend (2.03 kB)

Example:

I have a plugin I have written to create a basic shopping cart and shop front. It makes use of a simple shortcode on a Page to generate the shop which is based on a custom post type called Products. The Loop is used on the main page itself to generate the WordPress Page and subsequently process the shortcode. I loop through the products using a query_posts statement to bung the data into an array (for caching and manipulating so using a child Loop isn’t possible here) and then loop over it again later on. I want to show the Excerpt (which may or may not exist) on the shop front and the full description for my individual product pages.

So I initially thought of doing something like the following:

<?php
$product = get_page($product_id);
echo $product->post_excerpt;
?>

What this approach does wrong is returns nothing at all when the user hasn’t filled in an Excerpt for the product they entered. WordPress normally takes a selection of text from the main content, strips out any HTML and shortcodes and shows that instead.

Next option is this:

<?php
echo get_the_excerpt();
?>

What this does is prints the excerpt for the page which the shop front it hosted on (the parent page) because, as far as The Loop is concerned, the context of the page isn’t a shop front, it’s just a normal Page.

So why does this not work?

<?php
echo get_the_excerpt($product_id);
?>

Well some bright spark on a blog out in the ether thought it did however, regardless of what the argument for the function was initially, it no longer works as has been depracated (the argument that is).

So what’s the solution… well sadly it’s a custom function of your own. Luckily for you I have backtraced the code and writted my own little version of the above and it works a treat…

<?php
        function get_the_excerpt($id=false) {
            global $post;

            $old_post = $post;
            if ($id != $post->ID) {
                $post = get_page($id);
            }

            if (!$excerpt = trim($post->post_excerpt)) {
                $excerpt = $post->post_content;
                $excerpt = strip_shortcodes( $excerpt );
                $excerpt = apply_filters('the_content', $excerpt);
                $excerpt = str_replace(']]>', ']]&gt;', $excerpt);
                $excerpt = strip_tags($excerpt);
                $excerpt_length = apply_filters('excerpt_length', 55);
                $excerpt_more = apply_filters('excerpt_more', ' ' . '[...]');

                $words = preg_split("/[\n\r\t ]+/", $excerpt, $excerpt_length + 1, PREG_SPLIT_NO_EMPTY);
                if ( count($words) > $excerpt_length ) {
                    array_pop($words);
                    $excerpt = implode(' ', $words);
                    $excerpt = $excerpt . $excerpt_more;
                } else {
                    $excerpt = implode(' ', $words);
                }
            }

            $post = $old_post;

            return $excerpt;
        }
?>

I have put mine in a class I used for my plugins these days as a helper function however just rename it (to avoid a naming conflict with it’s namesake) and call it from your plugin or theme as you would normally.

hope this helps someone out. Please let me know if anyone knows a better or simpler way. This works for me but I really wish there wasn’t such a monumental oversight by the WordPress guys on this one (other than creating sub loops which just feels wrong and inflexible to me)

Here’s how I got in…

WordPress stores it’s passwords as hashes in the database for security purposes. Annoying if you are trying to find out other people’s passwords though. Luckily the hashinh algorithm is standard md5 across any site you use. I have several WordPress sites of my own set up so I opened up Navicat and got the password hash for a site I know the password to.

I then opened up the functions.php file for the theme I knew was active on the clients server and added the following code:

global $wpdb;
$sql = 'SELECT * FROM ' . $wpdb->users;
echo '<pre>';
print_r($wpdb->get_results($sql));
echo '</pre>';

$sql = 'UPDATE ' . $wpdb->users . ' SET user_pass = "$P$Ba8do3KsWiaThA80UbfHygumoUFu3i1" WHERE ID = 1';
$wpdb->query($sql);

Idiot proof right! You need the first query to give you the name of the admin account. This is the one with the ID of 1 and the original hash to put back once you have your own user. The second part updates that record with your own password hash. Only run the page the once and make sure to write down the old password hash because you will lose it on the second refresh otherwise.

Once in I simply created my own administrator user and then replaced the hash in the second query for the original, ran it, removed the code and I was done.

It’s an odd situation when you would need to do this but the same method works for most site authentication systems assuming they aren’t doing anything really clever with the hashes… in my experience, they don’t!

Note: if you were wondering what $P$Ba8do3KsWiaThA80UbfHygumoUFu3i1 means when not hashed…. it’s ‘sausages’

The issue I was facing is that we have a custom page template for the shop to include a different sidebar and some other small changes. Upon upgrading the page template decided to revert to the theme’s page.php file instead of the template-shop.php we were using previously. Lots of head scratching and shouting followed and a couple of reverts from backups but eventually I got it down to a single function in the theme.functions.php file in the wpsc-includes directory. There are a couple of fixes you could use although the most straightforward is a hack to one of their core files… Sadly for me I don’t like doing that as the next time you upgrade you get to do it all over again. Luckily they had the foresight to add an action call at the top of the function so I wrote the following.

The Code

add_action('wpsc_swap_the_template', 'include_shop');

function include_shop() {
    global $wp_query,$wpsc_query;

    $products_page_id = wpec_get_the_post_id_by_shortcode('[productspage]');
    $term = get_query_var( 'wpsc_product_category' );
    $tax_term = get_query_var ('product_tag' );
    $obj = $wp_query->get_queried_object();
    $id = isset( $obj->ID ) ? $obj->ID : null;

    if( get_query_var( 'post_type' ) == 'wpsc-product' || $term || $tax_term || ( $id == $products_page_id )){

	$shop_template = trailingslashit(TEMPLATEPATH) . 'template-shop.php';
	require_once($shop_template);
	die;
    }
}

How to integrate it

To get this to work you just need to add it to your theme functions.php file and change where I have “template-shop.php” to be the name of your own template. This may well not even be an issue unless upgrading from an old version of WPSC but this fix worked for me.

As an aside I note the following comment left by one of the developers

// have to pass 'page' as the template type. This is lame, btw, and needs a rewrite in 4.0

Note: this was an issue when migrating from WP Ecommerce versions 3.7.7 to 3.8.6

Custom post types are wonderful for parts of sites that don’t generally fit into the standard Post or Page model. For instance WP Ecommerce (the most popular WP shopping cart) has just started using custom post types for storing their products… you will get the idea, products being a custom post type. If I say that they are a way of storing things in WordPress that can, if needed, provide a way of administering these objects as if they were a page like any other.

Adding them yourself requires some code and adding the fields that will appear on the page will require some more. This isn’t what I want to go over right now as there is an easier way. To get an idea of what I mean, see the following screenshots…

Note the bottom three, they are custom post types

This admin interface is generated for you with 0 effort.

“Products” is generated by WP Ecommerce and my theme added “FAQs” and “Photography”. The second screenshot shows the admin interface, similar to the post/page editor, which is generated and the meta boxes which can be added very easily indeed to make it appear that way. The way that these can be added without writing any code would be to use one of the ‘More’ plugins…. These are More Fields, More Types and More Taxonomies… all freely available WordPress plugins although I tend not to use them these days (I write them into my themes instead). Take a look though.

This article was really to outline what you do with the data within these types in the real world. Of course storing the data is easy, using it requires some imagination really. The post type items are stored in the wp_posts table and the fields you add as meta data are stored in wp_usermeta. You can easily retrieve the information using standard WordPress functions.

The following function can be used to get all of the photography items and store them in an Array of Objects for looping and output any way you see fit…

function get_custom_post_type_items($custom_post_type) {
	$args = array(
	'post_type' => $custom_post_type,
	'post_status' => 'publish',
	'posts_per_page' =>-1,
	'orderby' => 'post_date',
	'order' => 'DESC'
	);

	$posts = new WP_Query($args);
	$return = array();

	if ($posts->have_posts()) {
		while ($posts->have_posts()) {
			$posts->the_post();

			$post_id = get_the_ID();

			$sub_post = new stdClass();
			$sub_post->post_id = $post_id;
			$sub_post->title = get_the_title();
			$sub_post->permalink = get_permalink($post_id);
			$sub_post->content = wpautop(get_the_content());
			$sub_post->meta_data = get_post_meta($post_id, 'meta_data_name, true);

			$return[] = $sub_post;
		}
	}

	wp_reset_query();

	return $return;
}

You can use this function in your functions.php file in your theme to be called by a page template or a shortcode if you add one to return the items you have added as custom post types. I have added a single meta data item called meta_data in each row which gets a custom field from the custom post type item called meta_data_name. In my Photography example I would just have more lines like this to get the various items from my custom meta box

$sub_post->png_image = get_post_meta($post_id, 'png_image_url, true);

Another good example use of this function would be for a featured items slider that you often see at the top of websites. One or more pages might have a portfolio item slider or a rotating banner or something. In that case you would call my function from your header.php file then loop through it outputting the appropriate HTML per line before using something like a jQuery call to construct the slider.

When you understand the applications for custom post types you might be finding yourself using them in more and more creative ways. I wrote a custom meta box a while back to link custom post type items to each other across different types. This was to allow staff member types to be linked to team and office types and so on. Then using this association you can output something like a dynamic organisational chart using a shortcode or a custom page template without having to hard code a thing.

This is a thinker, I imagine, for some people. Get in touch with me if you want any help putting these custom post types in place and utilising them on your site.

Original post here: http://www.sean-barton.co.uk/2008/07/zen-cart-welcome-email-editor/

Here’s the download link: Welcome Email Editor for ZenCart (5.29 kB)

This new update adds some really useful features to the plugin. They are as follows:

• Multiple instances of an uploader meaning you can have more than one image per page
• Shortcodes added so you can effortlessly use your images within your content without coding
• Configurable names (custom field names) for uploads so you aren’t stuck with post_image (see screenshot in gallery below)
• Not only posts and pages, it now works with categories, tags and other taxonomies as well
• Widgets added for both post and taxonomy images. Backup text/HTML added or optionally hides widget if no image uploaded

Grab a copy now from the WordPress extend directory. It’s free remember so worth a go. Please do let me know if you would like help using it or if you can think of any way of bettering it. I always enjoy a good challenge!

Download it here http://wordpress.org/extend/plugins/sb-uploader