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!

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’

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.

First things first… Costs.

It doesn’t cost the earth to have a website written. A normal company is likely to want a presence on the net and that’s it. No need for huge fancy sites to be optimised to within an inch of their life and no need to even have a graphic designer involved. Of course you can do, and generally end up with a better site but if you want to keep things simple then it’s not necessary.

There are only really two ongoing costs for a website… domain name(s) and website hosting.

Domain Names

A domain name is very cheap indeed although costs do vary. In the past I have used a few registraars and people always have their favourites. I use Europe Registry for this site but have just registered www.letsboat.co.uk with 123-reg (aff link) for a grand total of £7 for two years.

Web Hosting

Many website developers such as myself will offer to host the site for you at £X per year. This is a good idea if you want a lot of support but ultimately it’s cheaper to do it yourself and pay a developer when (if) things go wrong. This site is hosted with imountain however I wouldn’t recommend them at all. It costs me $10 per month but I find it very slow here in the UK. I tend to recommend Hostgator (aff link) to my clients. All you need for your own website is their most basic package although I would recommend their Baby plan in case you want to host more than one site using the same account. you can pay monthly with most hosts although you only usually get the quoted prices if you pay for two or three years up front. Depending on your financial situation this might be worth doing. If you go to hostgator.com and use tortoise25 as the coupon code you will get 25% off the quoted price if it helps.

Website Development

No one, if they can help it, writes sites in pure code any more. They are a nightmare to maintain and generally not very good. Also, as the client, you end up paying for a developer to make the smallest change. This is where WordPress comes in. WordPress, a content management system (CMS), allows you and developers to write sites (like this one in fact) quite quickly and with a massive range of free themes and plugins to make sites do whatever you want them to. Galleries, shops, video players, etc… All doable without much more than a few simple steps.

Installing WordPress requires you to get a PHP enabled server, set up a MySQL database, FTP up the WordPress files found at WordPress.org, apply the theme, add some plugins and write the content in. Sounds like a lot but when you do it for a living it doesn’t take long to get something up there. However it’s kind of like car maintenance.. you think you can service it yourself and you know that, in principle, replacing a few engine consumables is an easy job and takes a mechanic only a couple of hours. Then you start the job and it takes two days and never does run right after that. See the parallel there?

That’s it…. you never have to pay for content updates and you can always contact me for advice/help. If you hadn’t noticed, I’m a bit of a WordPress enthusiast. But then why not when WordPress is used for a huge number of sites on the internet (50,000,000 I think was the last count I read).

What do you need to provide to a Website Developer?

Simple enough question to ask, hard question to answer really. Here is a very basic list…

• Content
• Look and feel
• Gather resources to use

And then for any site with an ecommerce aspect:

• Products
• Payment processor (Paypal, Clickbank, Sagepay, etc…)
• Gather resources for download or delivery

Let me expand on these…

Content is self explanatory. I recommend firstly thinking about how many pages you want on the site and then jotting down, in something like Word, the content for each page. Images to compliment text is always a nice addition but can be done later. Additionally with a domain and a site you might want to let people get in touch with you. Have a think about what phone numbers (if any) and email addresses you want public or if you just want a contact form.

Look and feel is something that will definitely need to be expanded on. If you have a look at a few themes around the internet. There are literally thousands of them out there, loads free and others premium. Either is ok and neither better than the other. WordPress has it’s own showcase of free themes (required to be free to be in the list!). Someone like myself will firstly ask if you want a graphic designer involved, at which stage this process will be escalated to another level of cost and complexity. However, if you want something basic then a free theme will do. There are a large number of ‘framework’ based themes for free out there which allow people to edit their theme without touching the code. They tend to be very basic but might be a good starter. Otherwise there are even more standard themes about which can be modified to suit if need be. I normally recommend that people give up to three themes from the directory they like and then a new theme can be made which incorporates the better features of each.

Gathering resources is really just a cursory note for you to gather any images or logos (your company logo for example) in digital form to be added to the site. They need to be as high a quality as you can find. Images like logos should really be in JPG, PNG or GIF format and be bigger than needed so they can be trimmed to fit for the site. You can make images smaller and retain quality but not make them bigger.

Ecommerce aspects really are similar… Products is just something, as before, for you to think about. The descriptions for the products, the pricing, images and ways of getting hold of them (postage, pdf, etc..)

Payment processor is what we call the way in which people are asked to pay for their items. Normally Paypal is the standard for small sites. People tend to have accounts via eBay these days anyway. Other types of processor are available but tend to incur monthly costs (£20/month I think for Sagepay). Paypal is the easiest if you want to keep ongoing costs down. The requirement to sell is that you have a premier or business account. To do it you just need to login and look at your account settings then jump the hoops to update your account. This simply involves linking a bank account to you Paypal account (takes a few days, best done in advance of being needed). Nothing official otherwise needed.

Gathering resources is, again, just putting together the images and the content for the products. There are several shopping carts for use for downloads and ecommerce within WordPress.

SEO

Perhaps the buzzword of the net these days. I’ve not yet met someone that hasn’t heard the acronym although often people don’t know what it means… only that they want it. Plugins exist for free for WordPress to allow you to add your site to Google and other search engines and to allow you to compliment your content with the right sort of data to get you noticed. There are quite a few guides on the internet to help you through this.

Summary

So what was the point of all that then? Well… hopefully now you shall know about the sorts of things you are likely to be asked for when wanting a website and will be prepared for your initial conversation with website developers if that’s the direction you want to go.

By all means get in touch with me to go over any project you have in mind or even just to get an idea of how much it would cost for me to do it all for you. Take a look at some of the sites I have done in the past on my Portfolio page or get in touch using either of my contact or get a quote forms.

‘Why not add a product key?’ you ask!

Well yes a product key would do the job and avert the efforts of a portion of these people but obviously when using an interpreted/scripted language such as PHP they will be able to open up your source code, remove any license checking code and then pass the ‘cracked’ version around as before. Generally it’s not hard to find this sort of code… simply look for any filenames which hint at ‘licensing’ or ‘auth’, open them up (usually very small files) and put a ‘return true;’ at the start of the key checking method.  As I said this method stops a large portion of people from passing it around so it’s still worth doing.

What about a ‘call home’ script?

Same story here I’m afraid but more convenient for the seller (and you can get some lovely stats on the people using your code). A Call Home script is simply a piece of code that runs on the client site (per page load? per admin page load? every day on a CRON job?) and in effect sends a request back to a central server run by the code seller (you?) to simply authenticate sites. If, for example, example.com buys a script from my_premiumscripts.com then installs it on their server… Every so often the example.com server will call the my_premiumscripts.com server and have the following conversation:

example.com (e): Dude?
my_premiumscripts.com (m): Dude?
e: So… I’m just checking in with you, everything ok?
m: Ah great stuff, yes I see you purchased a copy of my code. Feel free to carry on using it.
e: Brilliant!
m: Indeed. don’t forget to check in with me tomorrow though.
e: Ok bye!

Or they could say this:

example_dotcomsmate.com (e): Dude?
my_premiumscripts.com (m): Dude?
e: So… I’m just checking in with you, everything ok?
m: Who are you again?
e: I’m a new site you don’t know about. I got your script from a friend (torrent? friend? unauthorised reseller?)
m: Oh ok, that’s fine with me but you have to send me some money first before you can use the software.
e: What? Hey I just want to have a look at it for a few days (years)
m: Nope sorry, I am going to deactivate the software on your site now. Bye!
e: Oh ok, bye!

Ok I jazzed up the conversation a bit but you get the idea. Call home scripts work really well from a protection point of view but have one really major drawback… they require you, as the seller, to have a 100% uptime server and it requires either the client server or the clients users to each initiate a request to that server. This means that both your server is going to get a lot of, what can only be described as, logging traffic (useless to everyone really) and the clients (servers or client machines) are going to get a worse (slower) user experience because of it. That and if you ever decide to move server or domain for the script then there is a lot of admin to do.

Either way there is the potential for you lose out on potential lovely cash. What we need is to be able to use the product key method with a way of stopping people from getting at the source code. There are a few ways to do this, some more awkward than others (both for the purchaser and the developer). The two worth mentioning are:

Code Encryption

This is the daddy of code protection. If your code is protected by an encryption algorithm then people are unable to look at the source code no matter how resourceful. The real downside of this is that you have to force your users to install additional server software before your code will run on their server. No simple FTP it up and start using it type system; this method is likely to involve your server host and a support ticket or two. An example of this would be any system that uses Ioncube Loader which, I understand to be, the same sort of thing.

Code Obfuscation

This is the lighter and more manageable version of the above. Whenever you look at an obfuscated file it will appear jibberish to the reader. PHP can interpret it because it doesn’t care whether a variable or function/method has a name which is human readable or not. Obfuscation works by removing all whitespace, renaming functions and variables and swapping out ascii text for a different characterset/encoding which is not immediately obvious to a novice that it’s text. Often these scripts make use of nested loops, dummy methods and evaluated code (code as a string which has then had the eval() function passed over it. Base64 encoding is popular but very easy to spot and decode to it’s use is on the decline. No additional software is required to run obfuscated code, it’s just a pain when there is an error in the code and the developer, for example, is on holiday for the next month! The downside of this for the developer is that it can be decoded and reverted to something resembling it’s original form (minus original function and variable names) by simply working backwards. Well… it’s not simple at all but is doable! Many virus script writers use this method of hiding a scripts intention. I have had to decode a few myself and it’s not fun.

Recommendations

My only recommendation is going to be to use neither and just go with a simple product key. Yes you are going to get taken for a ride by some people who want to redistribute it amongst their friends but think about it… they can’t get any updates from you, no support and if their source of the code disappears then they might even come and buy from you in the first place.

The key is to constantly be working on your scripts/applications. Don’t settle on a single version for too long, encourage a good community around the work and most importantly don’t rip people off in the first place… if the price is reasonable then people will happily pay it. A cheaper price is also a nice reason to offer sightly less involved support. It’s also a possible avenue of further income, premium support etc..

The real issue with any form of code protection is that updates and critical fixes won’t work without the original developer putting a new package together and, often, the entire fileset being replaced. If something goes wrong and the developer is not available then the job can not be outsourced which causes more issues. This is why I would always recommend you stand behind a well written Terms and Conditions document which must be agreed before the software can be used. Generally a block in the code is a challenge to be overcome, a legal document that requires signing and makes you liable is not!

Thanks for reading!

nb: example.com, example_dotcomsmate.com and my_premiumscripts.com are fabricated and although they might exist have no relation to the content in this article.

One of the sites I am working on has three top level pages which will form three distinct sections of the site. I decided that it would be good to show different sets of widgets within these sections and therefore had to concoct a way to determine from any page it’s top level parent page. The function below simply returns true or false if the first argument is a child of the second. It also returns true if the first argument is the same as the second.

The Function

function page_has_parent($current_page, $target_parent=0) {
	global $wpdb;

	$return = false;

	if ($current_page == $target_parent) {
		$return = true;
	} else {
		$sql = 'SELECT post_parent
			FROM ' . $wpdb->posts . '
			WHERE ID = ' . $current_page;
		if ($parent = $wpdb->get_var($sql)) {
			if ($parent == $target_parent) {
				$return = true;
			} else if ($parent) {
				$return = page_has_parent($parent, $target_parent);
			}
		}
	}

	return $return;
}

The Usage

The following is a WordPress example of showing one sidebar or the other based on page

$this_page = get_the_ID();
if (page_has_parent($this_page, 7)) {
	dynamic_sidebar('Sidebar2');
} else if (page_has_parent($this_page, 11)) {
	dynamic_sidebar('Sidebar2');
} else ....

The wp_comments table doesn’t have support or scope to store comments with an associated user (as opposed to post). At this juncture I would have inserted a null (or 0) value into the post_id column and added a row into the wp_commentmeta table with the user ID it refers to. However, I didn’t write the core code for the project so I simply updated a neat little system written by Dan Wellman. Dan’s system is pretty good and uses AJAX and JSON to add comments to a new database table with two fields (author and comment). It was what I would call ‘a good start’ as DB details were required in a number of different files and the database had room for improvement. I have a few more plans for the code but for now have changed a couple of things and bundled it into a WordPress plugin for you.

In my version the database table is created for you, it has several more fields including a primary key (!), timestamps and room for additional information (not currently utilised) to be stored. The WordPress database class is used now so no duplication of the connection details is necessary.

Take a look at the plugin and comments and suggestions for additions are very welcome.

Download
SB Author Comments (1.84 kB)

Usage
Upload and activate the plugin as normal. Then add the following code to your author.php theme template making sure to edit the $author_id variable as appropriate.

<?php
if (function_exists('sb_ac_comment_form')) {
echo sb_ac_comment_form($author_id);
}
?>

Credit
Once again credit goes to Dan Wellman who detailed the integration into his site on his blog

So… first, a bit of logic

Logically speaking a standard layout web page can be split into four distinct areas as follows:

• Header
• Footer
• Sidebar(s)
• Content

And as such WordPress uses different theme files to render the appropriate sections. We need to split our HTML page into those different files. There are, however, lines of code that WordPress needs you to put into each of these files and so tbe best way todo this without missing anything is to recycle another theme. So… go to your WordPress install and visit /wp-content/themes/ and…

1. Duplicate the directory called ‘default‘
2. Open style.css in a text editor and edit the name of the theme and any other information you feel like
3. Either remove or replace screenshot.jpg from the theme directory so it looks different in the theme menu

That’s it, you now have a skeleton to work from and it’s time to make it look like your site. Let’s assume you have a simple brochureware site and, therefore, don’t need any blog type pages. Largely these sites have a standard consistent layout on each page (often except the home page but that difference is for another tutorial) and WordPress uses this consistency to slot in the appropriate information for each page. We do this by…

1. Choose a short yet typical page from your site and view the HTML source
2. Open 4 separate text files from the new theme directory in your favourite text editor. They are: header.php, footer.php, sidebar.php and page.php
3. From the HTML source take the top section of code (usually as far as the content and sidebar code inclusive of a menu assuming you are using a top horizontal bar navigation) and place it into header.php making sure to preserve the obvious dynamic sections of code (anything between <?php and ?> can be assumed to be dynamic)
4. Do the same with the footer into footer.php (the section below the content and sidebar that often contains SEO links and copyright notices)
5. The remaining block should contain the content and sidebar code… simply cut out the sidebar code into sidebar.php
6. Finally split the content code into the bit before the text and the bit after the text (ie: layout code stripping out the text itself). Then paste these sections around the ‘while’ loop within page.php.
7. (optional) copy your stylesheet into style.css making sure to preserve the comment at the top of the file as this is used by WordPress to define the theme and without which will not pick up any of the code.

Step 6 will likely be the most difficult to do as there are three or four important lines of PHP code in there. Firstly the line that reads <?php get_header(); ?> is the code that calls header.php. Likewise <?php get_footer(); ?> and <?php get_sidebar(); ?> call their appropriate namesakes. Make sure that they are in the correct logical positions for the page to render in the right order.

The Loop

The hardest section is what is called ‘the loop’ by WordPress bods. This is the section of code that shows the post(s) from the database relative to the page you are looking at. The Loop often falls into the following form:

<?php if (have_posts()) : while (have_posts()) : the_post(); ?>
 <div id="post-<?php the_ID(); ?>">
 <h2><?php the_title(); ?></h2>
 <div>
 <?php the_content('<p>Read the rest of this page &raquo;</p>'); ?>

 <?php wp_link_pages(array('before' => '<p><strong>Pages:</strong> ', 'after' => '</p>', 'next_or_number' => 'number')); ?>

 </div>
 </div>
 <?php endwhile; endif; ?>

You shouldn’t really need to change any of the code itself but you might need to edit the encapsulating HTML to make your styles fit in. For example if your page titles are not in H2 tags then you need to change it to suit etc etc…

Testing it!

This will always be a case of trial and error until you know what you are doing so don’t worry if it all goes pear shaped. That’s what the undo button is for!

To test that your theme is working properly then you need to visit your sites back end at /wp-admin and click the link on the left hand side called ‘appearance‘. The themes page will appear and to activate your theme you simply find it in the list and click ‘activate’. Then view the front end of the site and see what it looks like.

At this stage you might be confused because the home page looks different to the rest of the site. This is because, by default, WordPress uses the index.php file from your theme directory to generate the home page. To change this visit the settings -> reading page from the left menu and use the dropdown box to choose an appropriate page to be used for the home page.

What’s next?

Ok so your theme looks like it did before you spent hours making the them for the WordPress site… why on earth are we using WordPress at all you ask! Well if you were to create a new page for your old site then you would have to duplicate an HTML file, trawl through code (or look at Dreamweaver or another WYSIWYG) to find the sections to replace before uploading to your site and updating the links in the various menus as appropriate. With WordPress you just add a ‘page‘ using the nice admin system and it’s all done for you.

I always tell my clients to go and have a look at the WordPress plugins directory for ideas and things to ad to their site. A word of warning though, some plugins conflict with others and too many plugins might slow your site down considerably. Over time you will get used to a core few you know and trust.

Feel free to ask me any questions about WordPress, PHP or other and hopefully I will be able to help you decide what’s the best direction for your site to take. Expect a lecture about how good WordPress is though!