Creating your own WordPress Plugins Easily

WordPress Plugins allow easy modification, customization, and enhancement to a WordPress blog. Instead of changing the core programming of WordPress, you can add functionality with WordPress Plugins. Here is a basic definition:

WordPress Plugin: A WordPress Plugin is a program, or a set of one or more functions, written in the PHP scripting language, that adds a specific set of features or services to the WordPress weblog, which can be seamlessly integrated with the weblog using access points and methods provided by the WordPress Plugin Application Program Interface (API).

Wishing that WordPress had some new or modified functionality? The first thing to do is to search various WordPress Plugin repositories and sources to see if someone has already created a WordPress Plugin that suits your needs. If not, this article will guide you through the process of creating your own WordPress Plugins.

This article assumes you are already familiar with the basic functionality of WordPress, and PHP programming.

Resources
■To understand how WordPress Plugins work and how to install them on your WordPress blog, see Plugins.
■There is a comprehensive list of articles and resources for Plugin developers, including external articles on writing WordPress Plugins, and articles on special topics, in Plugin Resources.
■To learn the basics about how WordPress Plugins are written, view the source code for well-written Plugins, such as Hello Dolly distributed with WordPress.
■Once you have written your WordPress Plugin, read Plugin Submission and Promotion to learn how to distribute it and share it with others.
Creating a Plugin
This section of the article goes through the steps you need to follow, and things to consider when creating a well-structured WordPress Plugin.

Names, Files, and Locations
Plugin Name
The first task in creating a WordPress Plugin is to think about what the Plugin will do, and make a (hopefully unique) name for your Plugin. Check out Plugins and the other repositories it refers to, to verify that your name is unique; you might also do a Google search on your proposed name. Most Plugin developers choose to use names that somewhat describe what the Plugin does; for instance, a weather-related Plugin would probably have the word “weather” in the name. The name can be multiple words.

Plugin Files
The next step is to create a PHP file with a name derived from your chosen Plugin name. For instance, if your Plugin will be called “Fabulous Functionality”, you might call your PHP file fabfunc.php. Again, try to choose a unique name. People who install your Plugin will be putting this PHP file into the WordPress Plugin directory in their installation, wp-content/plugins/, so no two Plugins they are using can have the same PHP file name.

Another option is to split your Plugin into multiple files. Your WordPress Plugin must have at least one PHP file; it could also contain JavaScript files, CSS files, image files, language files, etc. If there are multiple files, pick a unique name for a file directory and for the main PHP file, such as fabfunc and fabfunc.php in this example, put all your Plugin’s files into that directory, and tell your Plugin users to install the whole directory under wp-content/plugins/.

In the rest of this article, “the Plugin PHP file” refers to the main Plugin PHP file, whether in wp-content/plugins/ or a sub-directory.

Readme File
If you want to host your Plugin on http://wordpress.org/extend/plugins/, you also need to create a readme.txt file in a standard format, and include it with your Plugin. See http://wordpress.org/extend/plugins/about/readme.txt for a description of the format.

Home Page
It is also very useful to create a web page to act as the home page for your WordPress Plugin. This page should describe how to install the Plugin, what it does, what versions of WordPress it is compatible with, what has changed from version to version of your Plugin, and how to use the Plugin.

File Headers
Now it’s time to put some information into your main Plugin PHP file.

Standard Plugin Information
The top of your Plugin’s main PHP file must contain a standard Plugin information header. This header lets WordPress recognize that your Plugin exists, add it to the Plugin management screen so it can be activated, load it, and run its functions; without the header, your Plugin will never be activated and will never run. Here is the header format:

The minimum information WordPress needs to recognize your Plugin is the Plugin Name line. The rest of the information (if present) will be used to create the table of Plugins on the Plugin management screen. The order of the lines is not important.

License
It is customary to follow the standard header with information about licensing for the Plugin. Most Plugins use the GPL license used by WordPress or a license compatible with the GPL. To indicate a GPL license, include the following lines in your Plugin:

Programming Your Plugin
Now, it’s time to make your Plugin actually do something. This section contains some general ideas about Plugin development, and describes how to accomplish several tasks your Plugin will need to do.

WordPress Plugin Hooks
Many WordPress Plugins accomplish their goals by connecting to one or more WordPress Plugin “hooks”. The way Plugin hooks work is that at various times while WordPress is running, WordPress checks to see if any Plugins have registered functions to run at that time, and if so, the functions are run. These functions modify the default behavior of WordPress.

For instance, before WordPress adds the title of a post to browser output, it first checks to see if any Plugin has registered a function for the “filter” hook called “the_title”. If so, the title text is passed in turn through each registered function, and the final result is what is printed. So, if your Plugin needs to add some information to the printed title, it can register a “the_title” filter function.

Another example is the “action” hook called “wp_footer”. Just before the end of the HTML page WordPress is generating, it checks to see whether any Plugins have registered functions for the “wp_footer” action hook, and runs them in turn.

You can learn more about how to register functions for both filter and action hooks, and what Plugin hooks are available in WordPress, in the Plugin API. If you find a spot in the WordPress code where you’d like to have an action or filter, but WordPress doesn’t have one, you can also suggest new hooks (suggestions will generally be taken); see Reporting Bugs to find out how.

Template Tags
Another way for a WordPress Plugin to add functionality to WordPress is by creating custom Template Tags. Someone who wants to use your Plugin can add these “tags” to their theme, in the sidebar, post content section, or wherever it is appropriate. For instance, a Plugin that adds geographical tags to posts might define a template tag function called geotag_list_states() for the sidebar, which lists all the states posts are tagged with, with links to the state-based archive pages the Plugin enables.

To define a custom template tag, simply write a PHP function and document it for Plugin users on your Plugin’s home page and/or in the Plugin’s main PHP file. It’s a good idea when documenting the function to give an example of exactly what needs to be added to the theme file to use the function, including the .

Saving Plugin Data to the Database
Most WordPress Plugins will need to get some input from the site owner or blog users and save it between sessions, for use in its filter functions, action functions, and template functions. This information has to be saved in the WordPress database, in order to be persistent between sessions. There are two basic methods for saving Plugin data in the database:

1.Use the WordPress “option” mechanism (described below). This method is appropriate for storing relatively small amounts of relatively static, named pieces of data — the type of data you’d expect the site owner to enter when first setting up the Plugin, and rarely change thereafter.
2.Post Meta (a.k.a. Custom Fields). Appropriate for data associated with individual posts, pages, or attachments. See post_meta Function Examples, add_post_meta(), and related functions.
3.Create a new, custom database table. This method is appropriate for data associated with individual posts, pages, attachments, or comments — the type of data that will grow as time goes on, and that doesn’t have individual names. See Creating Tables with Plugins for information on how to do this.
WordPress Options Mechanism
See Creating Options Pages for info on how to create a page that will automatically save your options for you.

WordPress has a mechanism for saving, updating, and retrieving individual, named pieces of data (“options”) in the WordPress database. Option values can be strings, arrays, or PHP objects (they will be “serialized”, or converted to a string, before storage, and unserialized when retrieved). Option names are strings, and they must be unique, so that they do not conflict with either WordPress or other Plugins.

Here are the main functions your Plugin can use to access WordPress options.

add_option($name, $value, $deprecated, $autoload);
Creates a new option; does nothing if option already exists.
$name
Required (string). Name of the option to be added.
$value
Optional (string), defaults to empty string. The option value to be stored.
$deprecated
Optional (string), no longer used by WordPress, You may pass an empty string or null to this argument if you wish to use the following $autoload parameter.
$autoload
Optional, defaults to ‘yes’ (enum: ‘yes’ or ‘no’). If set to ‘yes’ the setting is automatically retrieved by the get_alloptions function.
get_option($option);
Retrieves an option value from the database.
$option
Required (string). Name of the option whose value you want returned. You can find a list of the default options that are installed with WordPress at the Option Reference.
update_option($option_name, $newvalue);
Updates or creates an option value in the database (note that add_option does not have to be called if you do not want to use the $deprecated or $autoload parameters).
$option_name
Required (string). Name of the option to update.
$newvalue
Required. (string|array|object) The new value for the option.
Administration Panels
Assuming that your Plugin has some options stored in the WordPress database (see section above), you will probably want it to have an administration panel that will enable your Plugin users to view and edit option values. The methods for doing this are described in Adding Administration Menus.

Internationalizing Your Plugin
Once you have the programming for your Plugin done, another consideration (assuming you are planning on distributing your Plugin) is internationalization. Internationalization is the process of setting up software so that it can be localized; localization is the process of translating text displayed by the software into different languages. WordPress is used all around the world, so it has internationalization and localization built into its structure, including localization of Plugins.

It is highly recommended that you internationalize your Plugin, so that users from different countries can localize it. There is a comprehensive reference on internationalization, including a section describing how to internationalize your plugin, at I18n for WordPress Developers.

Plugin Development Suggestions
This last section contains some random suggestions regarding Plugin development.

■The code of a WordPress Plugin should follow the WordPress Coding Standards. Please consider the Inline Documentation Standards as well.
■All the functions in your Plugin need to have unique names that are different from functions in the WordPress core, other Plugins, and themes. For that reason, it is a good idea to use a unique function name prefix on all of your Plugin’s functions. Another possibility is to define your Plugin functions inside a class (which also needs to have a unique name).
■Do not hardcode the WordPress database table prefix (usually “wp_”) into your Plugins. Be sure to use the $wpdb->prefix variable instead.
■Database reading is cheap, but writing is expensive. Databases are exceptionally good at fetching data and giving it to you, and these operations are (usually) lightning quick. Making changes to the database, though, is a more complex process, and computationally more expensive. As a result, try to minimize the amount of writing you do to the database. Get everything prepared in your code first, so that you can make only those write operations that you need.
■SELECT only what you need. Even though databases fetch data blindingly fast, you should still try to reduce the load on the database by only selecting that data which you need to use. If you need to count the number of rows in a table don’t SELECT * FROM, because all the data in all the rows will be pulled, wasting memory. Likewise, if you only need the post_id and the post_author in your Plugin, then just SELECT those specific fields, to minimize database load. Remember: hundreds of other processes may be hitting the database at the same time. The database and server each have only so many resources to spread around amongst all those processes. Learning how to minimize your Plugin’s hit against the database will ensure that your Plugin isn’t the one that is blamed for abuse of resources.
■Eliminate PHP errors in your plugin. Add define(‘WP_DEBUG’, true); to your wp-config.php file, try all of your plugin functionality, and check to see if there are any errors or warnings. Fix any that occur, and continue in debug mode until they have all been eliminated.

developing or designing your own WordPress Theme

The following article is about developing or designing your own WordPress Theme. If you wish to learn more about how to install and use Themes, review the documentation regarding Using Themes. This topic differs from Using Themes because it discusses the technical aspects of writing code to build your own Themes rather than how to activate Themes or where to obtain new Themes.

You may wish to develop WordPress Themes for your own use or for distribution.

Why WordPress Themes

WordPress Themes are files and styles that work together to create a presentation or look for a WordPress site. Each Theme may be different, offering many choices for users to take advantage of in order to instantly change their website look.

Why should you build your own WordPress Theme?

 To create your own unique WordPress site look
 To take advantage of templates, template tags, and the WordPress Loop to generate different web page results and looks.
 To provide alternative templates for specific site features, such as category pages and search result pages.
 To quickly switch between two site layouts, or to take advantage of a Theme or style switcher to allow users to change the look of your site.
 To design WordPress Theme(s) so that others may enjoy your designs through public release.
A WordPress Theme has many benefits, too.
 It separates the presentation styles and template files from the system files so the site will upgrade without drastic changes to the visual presentation of the site.
 It allows for customization of the presentation and web page results unique to that Theme.
 It allows for quick changes of the look and feel of a WordPress site.
 It takes away the need for a WordPress user to have to learn CSS, HTML, and PHP in order to have a good looking website.
Why should you build your own WordPress Theme? That’s the real question.
 It’s an opportunity to learn more about CSS, HTML/XHTML, and PHP.
 It’s an opportunity to put your expertise with CSS, HTML/XHTML, and PHP to work.
 It’s creative.
 It’s fun (most of the time).
 If you release it to the public, you can feel good that you shared and gave something back to the WordPress Community (okay, bragging rights!)

Anatomy of a Theme

WordPress Themes live in subdirectories residing in wp-content/themes/. The Theme’s subdirectory holds all of the Theme’s style sheet files, template files, and optional functions file (functions.php), and images. For example, a Theme named “test” would probably reside in the directory wp-content/themes/test/.
WordPress includes two Themes in the download, a “Classic” and “Default” Theme. The two Themes are different and use different functions and tags to generate their web page results and looks. Examine the files carefully for these Themes to get a better idea of how to build your own Theme files.
WordPress Themes consist of three main types of files, in addition to images. One is the style sheet called style.css, which controls the presentation (look) of the web pages. The second is the optional functions file (functions.php). The other files are the template files which control the way the web page generates the information from the Database to be displayed as a web page. Let’s look at these individually.
Theme Style Sheet
In addition to CSS style information for your theme, the stylesheet, style.css must provide details about the Theme in the form of comments. No two Themes are allowed to have the same details listed in their comment headers, as this will lead to problems in the Theme selection dialog. If you make your own Theme by copying an existing one, make sure you change this information first.
The following is an example of the first few lines of the stylesheet, called the style sheet header, for the Theme “Rose”:
/*
Theme Name: Rose
Theme URI: the-theme’s-homepage
Description: a-brief-description
Author: your-name
Author URI: your-URI
Template: use-this-to-define-a-parent-theme–optional
Version: a-number–optional
.
General comments/License Statement if any.
.
*/
The simplest Theme includes only a style.css file, plus images, if any. To create such a Theme, you must specify a set of templates to inherit for use with the Theme by editing the Template: line in the style.css header comments. For example, if you wanted the Theme “Rose” to inherit the templates from another Theme called “test”, you would include Template: test in the comments at the beginning of Rose’s style.css. Now “test” is the parent Theme for “Rose”, which still consists only of a style.css file and the concomitant images, all located in the directory wp-content/themes/Rose. Additionally (as of WordPress 2.7), the child theme may contain template files, which can be selected in the admin panel as normal, and will override the parent’s template files where those possess the same name.
The comment header lines in style.css are required for WordPress to be able to identify a Theme and display it in the Administration Panel under Design > Themes as an available Theme option along with any other installed Themes.
Note : When defining the parent Theme, in the Template: section of the comment header, you must use the name of the directory of the style. For example, to use as parent template called Cold Steel, don’t write Template: Cold Steel, but Template: cold_steel, assuming cold_steel is the directory of that Theme. Also, Themes that inherit from default should not specify the Template: section at all.
Theme Functions File
A theme can optionally use a functions file, which resides in the theme subdirectory and is named functions.php. This file basically acts like a plugin, and if it is present in the theme you are using, it is automatically loaded during WordPress initialization (both for admin pages and external pages). Suggested uses for this file:
 Define functions used in several template files of your theme
 Set up an admin screen, giving users options for colors, styles, and other aspects of your theme
The “Default” WordPress theme contains a functions.php file that defines functions and an admin screen, so you might want to use it as a model. Since functions.php basically functions as a plugin, the Function_Reference list is the best place to go for more information on what you can do with this file.
Theme Template Files
Templates are PHP source files used to generate the pages requested by visitors. Let’s look at the various templates that can be defined as part of a Theme.
WordPress allows you to define separate templates for the various aspects of your weblog; however, it is not essential to have all these different template files for your blog to function fully. Templates are chosen and generated based upon the Template Hierarchy, depending upon what templates are available in a particular Theme. As a Theme developer, you can choose the amount of customization you want to implement using templates. For example, as an extreme case, you can use only one template file, called index.php as the template for all pages generated and displayed by the weblog. A more common use is to have different template files generate different results, to allow maximum customization.
Basic Templates
At the very minimum, a WordPress Theme consists of two files:
 style.css
 index.php
Both of these files go into the Theme’s directory. The index.php template file is very flexible. It can be used to include all references to the header, sidebar, footer, content, categories, archives, search, error, and other web pages generated by the user on your site. Or it can be subdivided into modular template files, each one taking on part of the workload. If you do not provide any other template files, WordPress will use the built-in default files. For example, if you do not have either a comments.php or comments-popup.php template file, then WordPress will automatically use the wp-comments.php and wp-comments-popup.php template files using Template Hierarchy. These default templates may not match your Theme very well, so you probably will want to provide your own. The basic files normally used to subdivide (which go into the Theme’s directory) are:
 header.php
 sidebar.php
 footer.php
 comments.php
 comments-popup.php
Using these modular template files, you can put template tags within the index.php master file to include or get these units where you want them to appear in the final generated web page.
 To include the header, use the get_header() template tag.
 To include the sidebar, use the get_sidebar() template tag.
 To include the footer, use the get_footer() template tag.
Here is an example of the include usage:

For more on how these various Templates work and how to generate different information within them, read the Templates documentation.
Query-based Templates
WordPress can load different Templates for different query types. There are two ways to do this: as part of the built-in Template Hierarchy, and through the use of Conditional Tags within The Loop of a template file.
To use the Template Hierarchy, you basically need to provide special-purpose Template files, which will automatically be used to override index.php. For instance, if your Theme provides a template called category.php and a category is being queried, category.php will be loaded instead of index.php. If category.php is not present, index.php is used as usual.
You can get even more specific in the Template Hierarchy by providing a file called, for instance, category-6.php — this file will be used rather than category.php when generating the page for the category whose ID number is 6. (You can find category ID numbers in Manage > Categories if you are logged in as the site administrator in WordPress version 2.3 and below. In WordPress 2.5 the ID column was removed from the Admin panels. You can locate the category id by clicking ‘Edit Category’ and looking on the URL address bar for the cat_ID value. It will look ‘…categories.php?action=edit&cat_ID=3′ where ’3′ is the category id). For a more detailed look at how this process works, see Category Templates.
If your Theme needs to have even more control over which Template files are used than what is provided in the Template Hierarchy, you can use Conditional Tags. The Conditional Tag basically checks to see if some particular condition is true, within the WordPress Loop, and then you can load a particular template, or put some particular text on the screen, based on that condition.
For example, to generate a distinctive style sheet in a post only found within a specific category, the code might look like this:

Or, using a query, it might look like this:
post;
if ( in_category(’9′) ) {
include(TEMPLATEPATH . ‘/single2.php’);
} else {
include(TEMPLATEPATH . ‘/single1.php’);
}
?>
In either case, this example code will cause different templates to be used depending on the category of the particular post being displayed. Query conditions are not limited to categories, however — see the Conditional Tags article to look at all the options.
Media Icons
This feature is currently broken in WordPress 2.5.
Wordpress uses media icons to represent attachment files on your blog and in the Admin interface, if those icons are available.
It looks for image files named by media type in the images directory of the current theme. (As of WordPress 2.2, the default theme comes with only one media icon, audio.jpg.)
For example, for an attachment of MIME type audio/mpeg, WordPress would look for an icon file at these locations, stopping after the first match (see wp_mime_type_icon):
1. my_theme/images/audio.jpg
2. my_theme/images/audio.gif
3. my_theme/images/audio.png
4. my_theme/images/mpeg.jpg
5. my_theme/images/mpeg.gif
6. my_theme/images/mpeg.png
7. my_theme/images/audio_mpeg.jpg
8. my_theme/images/audio_mpeg.gif
9. my_theme/images/audio_mpeg.png
Theme Template Files List
Here is the list of Theme template files recognized by WordPress. Of course, your Theme can contain any other style sheets, images, or files. Just keep in mind that the following have special meaning to WordPress — see Template Hierarchy for more information.
style.css
The main stylesheet. This must be included with your Theme, and it must contain the information header for your Theme.
index.php
The main template. If your Theme provides its own templates, index.php must be present.
comments.php
The comments template. If not present, comments.php from the “default” Theme is used.
comments-popup.php
The popup comments template. If not present, comments-popup.php from the “default” Theme is used.
home.php
The home page template.
single.php
The single post template. Used when a single post is queried. For this and all other query templates, index.php is used if the query template is not present.
page.php
The page template. Used when an individual Page is queried.
category.php
The category template. Used when a category is queried.
tag.php
The tag template. Used when a tag is queried.
taxonomy.php
The term template. Used when a term in a custom taxonomy is queried.
author.php
The author template. Used when an author is queried.
date.php
The date/time template. Used when a date or time is queried. Year, month, day, hour, minute, second.
archive.php
The archive template. Used when a category, author, or date is queried. Note that this template will be overridden by category.php, author.php, and date.php for their respective query types.
search.php
The search results template. Used when a search is performed.
404.php
The 404 Not Found template. Used when WordPress cannot find a post or page that matches the query.
These files have a special meaning with regard to WordPress because they are used as a replacement for index.php, when available, according to the Template Hierarchy, and when the corresponding Conditional Tag (a.k.a is_*(); function) returns true. For example, if only a single post is being displayed, the is_single() function returns ‘true’, and, if there is a single.php file in the active Theme, that template is used to generate the page.
Referencing Files From a Template
The WordPress Default Theme (based on Michael Heilemann’s Kubrick layout for WordPress 1.2) provides a good example of how queries are mapped onto templates.
The code inserts the URL of the template directory into the template output. You can append any additional URI information to this output to reference files in your Theme.
The code inserts the URL of the directory that contains the current Theme stylesheet into the template output. You can append any additional URI information to this output to reference files for your Theme, specifically those that are used by the stylesheet.
The constant TEMPLATEPATH is a reference to the absolute path to the template directory for the current Theme (without the / at the end).
Note that URIs that are used in the stylesheet are relative to the stylesheet, not the page that references the stylesheet. For example, if you include an images/ directory in your Theme, you need only specify this relative directory in the CSS, like so:
h1 { background-image: URL(images/my_background.jpg); }
It is a good practice to use URIs in the manner described above to reference files from within a template, since, then your template will not depend on absolute paths.
Defining Custom Templates
It is possible to use the WordPress plugin system to define additional templates that are shown based on your own custom criteria. This advanced feature can be accomplished using the template_redirect action hook. More information about creating plugins can be found in the Plugin API reference.
Plugin API Hooks
When developing Themes, it’s good to keep in mind that your Theme should be set up so that it can work well with any WordPress plugins you (or another Theme user) might decide to install. Plugins add functionality to WordPress via “Action Hooks” (see Plugin API for more information). Most Action Hooks are within the core PHP code of WordPress, so your Theme does not have to have any special tags for them to work. But a few Action Hooks do need to be present in your Theme, in order for Plugins to display information directly in your header, footer, sidebar, or in the page body. Here is a list of the special Action Hook Template Tags you need to include:
wp_head
Goes in the HTML element of a theme; header.php template. Example plugin use: add javascript code.
Usage:
-or-
wp_footer
Goes in the “footer” of a theme; footer.php template. Example plugin use: insert PHP code that needs to run after everything else, at the bottom of the footer.
Usage:
-or-
wp_meta
Typically goes in the

Meta

section of a theme’s menu or sidebar; sidebar.php template. Example plugin use: include a rotating advertisement or a tag cloud.
Usage:
-or-
comment_form
Goes in comments.php and comments-popup.php, directly before the comment form’s closing tag (

). Example plugin use: display a comment preview.
Usage: ID); ?>
For a real world usage example, you’ll find these plugin hooks included in the default theme’s templates.
Theme Development General Guidelines
Please be clear about the following in your documentation (a README file included with your Theme helps many users over any potential stumbling blocks):
1. Indicate precisely what your Theme and template files will achieve.
2. Adhere to the naming conventions of the standard theme hierarchy.
3. Indicate deficiencies in your Themes, if any.
4. Clearly reference any special modifications in comments within the template and style sheet files. Add comments to modifications, template sections, and CSS styles, especially those which cross template files.
5. If you have any special requirements, which may include custom Rewrite Rules, or the use of some additional, special templates, images or files, please explicitly state the steps of action a user should take to get your Theme working.
6. Try and test your Theme across browsers to catch at least a few of the problems the users of the Theme may find later.
7. Provide contact information (web page or email), if possible, for support information and questions.
Take time to read through Designing Themes for Public Release, an article with good tips on preparing your Theme for the public.

New To WordPress – Where to Start

If you are new to WordPress and you’re worried about where to start, you’ve come to the right place! Here is a very simple step-by-step plan for getting started with WordPress. Please remember, if you need help along the way, plenty of options for assistance are listed in this article. Welcome to the exciting world of WordPress!

Contents

1 Step One – Read
2 Step Two – Make a Plan
3 Step Three – Install WordPress
4 Step Four – Set Up WordPress
4.1 Presentation and Themes
4.2 Adding Plugins
5 Advanced Use of WordPress
6 Need More Help
■7 And Finally

Step One – Read
Before you invest your valuable time and energy into installing WordPress, there are some documents you need to read. WordPress is a great product; it’s easy-to-use, it’s quite powerful, but it isn’t necessarily the right software for everyone. Just like building a house, you have to use the right tool for the right job. Consider creating a PDF to read at your leisure.

■About Weblogs – What is Blogging all about?
■What is WordPress?
■WordPress Features
■Before You Install WordPress
Step Two – Make a Plan
Based upon the information you’ve just read, including instructions on installing WordPress, you should have a list of the things you need, and the things you need to do. If not, make that list now–you’ll want to make sure it includes the following information:

■Website Host Requirements Checked and Verified
■Versions of PHP and MySQL Checked and Verified
■Web Host Compatibility with New Versions of WordPress
■Your Website Username and Password
■Text Editor Software
■An FTP Client Software
■Your Web Browser of Choice
The following documents will help you understand more about how WordPress works and how to make a plan for your WordPress site:

■WordPress Features
■First Steps With WordPress
■WordPress Lessons
It is important to make a plan about how you want to use WordPress on your site. Here are some questions to ask yourself. Make a list of the answers so you can add to your plan.

■Will you install WordPress in the root directory, subdirectory, or you just want to make a test site to make sure you want to use it?
■Have you made a list of your site Categories? Understand that WordPress can only order Categories alphabetically by name or by ID (order entered through the Manage > Categories screen), so if the display order of your Categories is important to you, start making your list of Categories.
■Have you made a list of Pages you may want to add to your site, such as About, Contact, or Events?
Step Three – Install WordPress
With this information and your plan, it’s time to install WordPress.

■Before You Install WordPress
■Installing WordPress
■Hosting WordPress
■Editing the wp-config.php file
■Frequently Asked Questions About Installing WordPress
■Using FTP Clients and Software
■Changing File Permissions
■Upgrading WordPress
■Common Installation Problems
■Trouble: I Can’t Login
Step Four – Set Up WordPress
With your installation complete, it’s time to set up WordPress so it will work the way you want it to work. As you change various settings, it is recommended you view how those changes impact your site by frequently clicking the View Site link at the top of the Administration Screen. Though you may choose to do these steps in any order, your site will cause you fewer problems if you proceed in the following order:

■Users > Your User Profile – set the user information you want published on your site
■Your User Profile > Other Users – add authors and users that will be using your site, if applicable
■Options > General – set your site name and other site information
■Options > Writing – set the settings of your Write Post screen
■Options > Reading – set how many posts to show on the front page and in categories and your feed requirements
■Options > Discussion – Turn on or off comments and set how to handle them
■Manage > Categories – add a few categories to get started from your category list
■Manage > Posts – After you have written a few posts, this is where you will manage them by editing or deleting
■Presentation > Themes – maybe change the look of your site?
■Manage > Pages – add a Page or two like “About Us” or “Contact Me”
■Write > Write Post – start adding content to your site
■Writing Posts – step-by-step instructions on writing posts
Take time to explore the WordPress Codex site, the official documentation site for WordPress. You’ll find helpful information by reading WordPress Lessons, and these helpful documents:

■Introduction to Dealing with Comment Spam
■Moderating Comments
■Using the Links Manager
■WordPress in Languages Other than English
Presentation and Themes
With the new WordPress version 1.5, changing the look of your WordPress website is possible with just a few clicks. Here is a list of resources and information about changing the look of your site with WordPress Themes.

■Using WordPress Themes
■Blog Design and Layout
■Using Pages
At this point, there may be something about your Theme choice that is bothering you, or, you really want to get your hands dirty understanding how your WordPress Theme works. These simple guides to help customize your WordPress Theme:

■Lessons: Designing Your WordPress Site
■CSS Overview, Tips, Techniques, and Resources
■Stepping Into Templates
■Lessons: Template Files
■Stepping Into Template Tags
■Lessons: Working With Template Tags
■WordPress Template Tags
■Understanding the WordPress Loop
■The WordPress Loop in Action
■Editing Files in WordPress
■Frequently Requested Design Help
■Frequently Asked Questions about Site Layout and Design
If you want to create a new WordPress Theme from scratch, or do major renovations, or even design WordPress Themes for public release, you will need to be familiar with HTML, XHMTL, and CSS. The following documents will get you started:

■Developing Your Own WordPress Theme
■Designing Themes for Public Release
■Validating a Website
■Lessons: Website Development
■CSS Fixing Browser Bugs
■CSS Troubleshooting
■Positioniseverything
■Position is Everything’s 3 Complex Column – Perched on a Lily Pad
■Position is Everything Piefecta 3-Column Layout
If you want a custom-made WordPress Theme created especially for you by expert web-designers, it is recommended you search for qualified web-designers on the Internet, or look in your local community, or draw from the List of Recommended Web Page Designers by Laughing Squid.

Adding Plugins
There are many “add-on” scripts and programs for WordPress called Plugins that add more capabilities, choices, and options to your WordPress site. WordPress Plugins do many things, including; customizing the results of your site information, adding weather reports, adding spell check capability, and presenting custom lists of posts and acronyms. For more on how to work with Plugins and where to find WordPress Plugins for your site:

■Managing Plugins
■Plugins
■http://www.wp-plugins.org/
■http://www.wp-plugins.net/
■Bloggingpro List of Plugins
Advanced Use of WordPress
Now that you are familiar with the basic features and functions of how WordPress works, it might be time for you to plunge deeper into the power of WordPress. The links below will expand your familiarity with PHP, HTML, XHTML, and CSS:

■Lessons: WordPress Feature and Functions
■Lessons: WordPress Tech Techniques
■Using Permalinks
■Photoblogs and Galleries
■WordPress Advanced Techniques
■Advanced Techniques for Plugins and Customization
■WordPress Server and Database Information
■Developer Documentation
Need More Help
As simple and easy as it is to use WordPress, if troubles arise, if something is confusing, if things aren’t working, don’t despair because help is available! Even though WordPress is free and open source, there are literally hundreds of volunteers eager to help you. Here are some helpful resources for WordPress:

■FAQ
■Getting More Help
■Using the Support Forums
■WordPress Forum
■IRC Freenode WordPress Support on channel #wordpress
■WordPress IRC Live Help
And Finally
Now that you’re a full fledged WordPress user, consider contributing to the WordPress Codex, Support Forum, Development, and other volunteer efforts that keep WordPress going. WordPress is free and totally supported by volunteers, and your help is needed.