Creating a WordPress Theme From Static HTML: Releasing Your Theme

If you've been following this series you now have a working WordPress theme. Your theme has a number of template files, including a page template and an archive template, and also has featured image support.

As your theming skills progress, you may decide you wish to release your themes to the public. The best way to do this is via the WordPress theme repository.

This has a number of advantages over releasing your theme elsewhere:

  1. Your theme will be available to other WordPress users for free, meaning you're giving something back to the WordPress community—a community which gave you WordPress itself for free.
  2. Your theme will be easily found, as the theme repository is where most people go looking for free themes.
  3. Your theme will be checked by the Theme Review Team, which means users can trust it.

You may have ambitions of selling premium themes via a theme vendor, but I would strongly advise releasing themes for free first—that way you can hone your theme building skills and get feedback from the community before you work on premium themes. Users have extremely high expectations of premium themes these days so don't expect to be releasing your first theme for money.

In this tutorial, I'll list the coding standards that you'll be expected to meet if your theme is to be accepted, and show you how to submit your theme.

What You'll Need

  • your code editor of choice
  • a browser for testing your work and uploading your theme
  • a WordPress installation, either local or remote
  • If you're working locally, you'll need MAMP, WAMP or LAMP to enable WordPress to run.
  • If you're working remotely, you'll need FTP access to your site plus an administrator account in your WordPress installation.

Coding Standards

Before you start preparing your theme for release, you need to check it against the WordPress Coding Standards. These standards apply to all WordPress themes and plugins and to the WordPress core itself:

  • Ensure that your code syntax won’t cause conflicts with other themes or plugins or with WordPress core. For example, name all files correctly and give your plugin files and functions unique names, using the name of your plugin or theme as a prefix. Don’t use wp_ as a prefix for any functions or files to avoid conflicts with the core.
  • Validate your code. Use a validation service such as the W3C’s validation sites for HTML and CSS to ensure that your code validates. In some cases, your code may not validate for good reasons (e.g., you’re using HTML5 or CSS3, which aren’t part of the spec yet)—if this is the case, be sure that you understand why the code isn’t validating and fix it so that it won’t cause any problems.
  • Debug your code. Use WP_DEBUG to verify that your code doesn’t throw any errors, including deprecated function notices, PHP errors, warnings, or other notices.
  • If your theme or plugin uses JavaScript, test it using the JavaScript console in your browser. Make sure you’re using the latest version of any JavaScript libraries; and if you’re using jQuery, do this by accessing the version of jQuery bundled with WordPress.
  • Browser test your code. Confirm that your theme or plugin works across the major browsers, and avoid using browser hacks to achieve browser compatibility where possible — it’s far better to write clean code that supports multiple browsers and then add “extras” such as CSS3 goodies that aren’t necessary for effective use of a site running your theme or plugin.
  • Test your code on multiple devices. As more and more users access WordPress sites on mobile devices, your code should work across them. Consider whether your theme should be responsive and ensure that any interactions in your plugin work across devices and don’t break the layout.
  • Test your code on multiple WordPress installations, including installations on different server platforms and those running Multisite. It’s also helpful to test on installations running other popular plugins such as BuddyPress and some of the big theme frameworks if you can, to ensure there are no incompatibilities. Ask other developers to help you with this so you have as wide a range of testing environments as possible.

Theme Review Guidelines

When reviewing themes that have been submitted, the Theme Review Team uses the "Theme Review Guidelines" to check that the theme is suitable and well written. Your theme must meet these to be accepted:

  • Code quality—Your code should meet the WordPress Coding Standards and must not generate any deprecated function notices, warnings, or errors.
  • Presentation vs. Functionality—Themes are for presentation, so if your theme is functional, it should be a plugin instead.
  • Theme features—Your theme should support all core WordPress features, regardless of whether it has its own additional features.
  • Template tags and hooks—These should be implemented correctly.
  • WordPress-generated CSS classes—Your theme must use these where relevant.
  • Template files—Your theme must use these correctly.
  • Security and privacy—Themes must ensure data security and user privacy.
  • Licensing—Your theme must be licensed under a GPL-compatible license.
  • Naming—Your theme’s name must not include “WordPress” and it should be unique, to avoid confusing users.
  • Credit links—Your theme should use these appropriately.
  • Documentation—At a minimum, you should provide a readme.txt file.
  • Theme Unit Tests—Your theme must pass them.
  • Theme obsolescence—You should keep your theme current after it is accepted.

Preparing Your Theme

The steps below aren't exhaustive—you'll need to check against the coding standards and theme review guidelines above, but these are some of the basic steps you'll need to take to prepare a theme like the one you've developed over the course of this tutorial.

Stylesheet

First, check the information in your stylesheet. The stylesheet contains all of the information required by WordPress but you may also want to add tags to help people to find it. In your style.css file, in the commented out text at the top, add the following:

Validation

Next, validate your code using the W3C's validation services for HTML and CSS. If you find any bugs, fix them.

Sometimes you may find an error which is caused by the fact that you are using HTML5. If you understand the error and are confident that your HTML5 is correct, you can ignore it.

Debugging

Open the wp-config.php file in your development installation of WordPress and find the following line:

Change it so it reads:

Now open your development site, activate the theme (if it isn't already activated), and test each page.

Make sure you test all the kinds of pages which could be created by WordPress—static pages, archive pages, single pages, 404 pages etc. Test the admin screens in the WordPress backend too.

If any error messages appear, fix the offending code. For our theme, WP_DEBUG doesn't throw up any errors—phew!

Browser and Device Testing

Test your code in the most commonly used browsers, in particular IE—for publicly available themes, it's wise to support IE8 and up, although you may decide to support IE7 if you can do this without too much difficulty. If you don't have access to all browsers you can use a browser testing tool like Browserstack, which lets you set up a free trial account for a limited period of time.

As well as browsers, you'll need to test on a few different devices. If you can get hold of some physical devices these are best, but you can also use emulators and simulators to test multiple devices and environments. As a minimum you should test on iOS and Android, and on screen sizes including a smartphone and large and small tablets.

Readme.txt

The readme.txt file will tell users how your theme works. Create a new blank file in your theme folder called readme.txt and insert a description of how your theme works in it.

In my theme I've written the following:

Naming

Check that your theme's name and directory name is unique. If you've added any functions, filters or hooks, add a prefix to their names to ensure your code doesn't clash with the code added by any other plugins.

In my theme I've used wptutsplus_ as a prefix. Do not use wp_.

Running the Theme Unit Tests

When you submit your theme, the review team will run the theme unit tests on it to check that it's ok. It makes sense to do this yourself so you know that it will pass. Follow these steps:

  1. Download an XML file containing test data.
  2. Using the "Import" menu in the WordPress admin, import the XML file to your theme.
  3. Set WP_DEBUG to ‘true’ in wp-config.php.
  4. Install a list of plugins, all of which can be installed via the Developer plugin.
  5. Perform a theme review using this process.

If your theme passes, you can be confident it will pass the Theme Review Guidelines.

Uploading Your Theme

Once you've tested your theme and you are confident that it will meet all the criteria, you can submit it.

Save your theme as a .zip file.

Go to the theme submission page on the WordPress site:

creating-wordpress-theme-from-static-html-upload-theme

Upload the theme.

That's it! Your theme will then be reviewed, and if it passes it will be added to the repository. Be patient though—the Theme Review Team is staffed by volunteer members of the WordPress community so they may not be able to get around to your theme immediately.

Summary

Making your themes available for other users is a great way to give something back to the WordPress community.

In this series of tutorials, you've worked all the way through the process of creating a WordPress theme. You started with some static HTML, prepared it for WordPress, converted it into template files, created extra template files for pages and archives, and added widget areas, menus and featured images. Finally you learned how to upload it to the theme repository for use by other users.

As your theme building skills progress you will create more complex WordPress themes, with additional template files, custom loops and more. Hopefully these tutorials will have given you the starting point you need to take things further in future.

Resources

Tags:

Comments

Related Articles