Code Wordpress Theme

[Gabby Dreher]

Thisarticle is about developing WordPress Themes. If you wish to learn more about how to install and use Themes, review 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.

WordPress Themes are files that work together to create the design and functionality of a WordPress site. Each Theme may be different, offering many choices for site owners to instantly change their website look.

WordPress Themes live in subdirectories of the WordPress themes directory (wp-content/themes/ by default) which cannot be directly moved using the wp-config.php file. The Theme's subdirectory holds all of the Theme's stylesheet files, template files, and optional functions file (functions.php), JavaScript files, and images. For example, a Theme named "test" would reside in the directory wp-content/themes/test/. Avoid using numbers for the theme name, as this prevents it from being displayed in the available themes list.

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_include" action hook. More information about creating plugins can be found in the Plugin API reference.

To ensure smooth transition for language localization, use the WordPress gettext-based i18n functions for wrapping all translatable text within the template files. This makes it easier for the translation files to hook in and translate the labels, titles and other template text into the site's current language. See more at WordPress Localization and I18n for WordPress Developers.

Create a screenshot for your theme. The screenshot should be named screenshot.png, and should be placed in the top level directory. The screenshot should accurately show the theme design and saved in PNG format. While .jpg, .jpeg, and .gif are also valid extensions and file formats for the screenshot, they are not recommended.

The recommended image size is 1200px wide by 900px tall. The screenshot will usually be shown smaller but the over-sized image allows for high-resolution viewing on HiDPI displays. Note that because the Manage Themes screen is responsive, the top and bottom of the screenshot image might not be viewable so keep graphics near the center.

When enabling the availability of the Theme Customize Screen for a user role, use the "edit_theme_options" user capability instead of the "switch_themes" capability unless the user role actually should also be able to switch the themes. See more at Roles and Capabilities and Adding Administration Menus.

If you are using the "edit_themes" capability anywhere in your Theme to gain the Administrator role access to the Theme Customize Screen (or maybe some custom screens), be aware that since Version 3.0, this capability has not been assigned to the Administrator role by default in the case of WordPress Multisite installation. See the explanation. In such a case, use the "edit_theme_options" capability instead if you want the Administrator to see the "Theme Options" menu. See the additional capabilities of Administrator role when using WordPress Multisite.

More specifically, if I have a bunch of custom functions which only apply to the admin area and others which just apply to my public website is there any reason to possibly include all admin functions within their own file or group them together?

If you are getting to the point where the code in your theme's functions.php is starting to overwhelm you I would definitely say you are ready to consider splitting it up into multiple files. I tend to do that almost by second nature at this point.

I create a subdirectory called "includes" under my theme directory and segment my code into include files organized by what makes sense to me at the time (which means I'm constantly refactoring and moving code around as a site evolves.) I also rarely put any real code in functions.php; everything goes in the include files; just my preference.

Just to give you an example here's my test install that I use to test my answers to questions here on WordPress Answers. Every time I answer a question I keep the code around in case I need it again. This isn't exactly what you'll do for a live site but it shows the mechanics of splitting up the code:

Another option it to start grouping your code by function and create your own plugins. For me I start coding in the theme's functions.php file and by the time I get the code fleshed out I've moved most of my code into plugins.

On the other hand structuring your PHP files is 99% about creating order and maintainability and 1% about performance, if that (organizing .js and .css files called by the browser via HTTP is a completely different case and has huge performance implications.) But how you organize your PHP code on the server pretty much doesn't matter from a performance perspective.

And last but not least code organization is personal preference. Some people would hate how I organize code just as I might hate how they do it too. Find something you like and stick with it, but allow your strategy to evolve over time as you learn more and get more comfortable with it.

As I just came back and saw that this answer is getting more and more upvotes, I thought I might show how I'm doing it nowadays - in a PHP 5.3+ world. The following example loads all files from a themes subfolder named src/. This is where I have my libraries that handle certain tasks like menus, images, etc. You don't even have to care about the name as every single file gets loaded. If you have other subfolders in this directory, they get ignored.

The \FilesystemIterator is the PHP 5.3+ supercedor over the \DirectoryIterator. Both are part of the PHP SPL. While PHP 5.2 made it possible to turn the built in SPL extension off (below 1% of all installs did that), the SPL now is part of PHP core.

EDIT The obviously correct way is to use namespaced code, prepared for PSR-4 autoloading by putting everything in the appropriate directory that already is defined via the namespace. Then just use Composer and a composer.json to manage your dependencies and let it auto-build your PHP autoloader (that imports automatically a file by just calling use \\ClassName). That's the de-facto standard in the PHP world, the easiest way to go and even more pre-automated and simplified by WP Starter.

I like to use a function to the files inside a folder. This approach makes it easy to add new features when adding new files. But I write always in class or with namespaces - give it more control about the Namespace of functions, method etc.

In Themes I use often a other scenario. I define the function of the externel file in a support ID, see the example. That is usefull if I will easy deactivate the feture of the externel file. I use the WP core function require_if_theme_supports() and he load only, if the support ID was active. In the follow example I deifned this supported ID in the line before load the file.

in terms of breaking it up, in my boiler plate I use a custom function to look for a folder called functions in the theme directory, if it is not there it creates it. Then is creates an array of all the .php files it finds in that folder (if any) and runs an include(); on each of them.

Step 1. Create and Store the Template Files

Step 2. Set Up the Initial CSS Stylesheet

Step 3. Make the WordPress Theme Functional

Step 4. Build a Layout for Your Custom Theme

Step 5. Improve Your Design on the CSS Stylesheet

Finally, create the WordPress staging area by switching to the Staging tab and clicking Create staging. Enter your preferred subdomain and click Create.

After creating all the theme template files, we can start writing the code. Begin by adding details to the style.css stylesheet we made earlier to allow WordPress to recognize its content.

These details are information that will show up in the WordPress admin area, like the theme name, author, and description. They are written based on the WordPress file header formatting. Here is an example:

Due to inconsistent margins and padding settings, several web browsers might display your WordPress theme differently. To ensure it shows properly, link the normalize.css file to functions.php.

The normalize.css template is a premade stylesheet that provides a basis for your CSS code, allowing it to load consistently across different browsers. To add it, insert the normalization function into functions.php:

Next, add a function to enable the widget area or sidebar. A widget is a modular extension that lets you add specific features to different sections of your WordPress website. To enable it, add the following after the previous snippet:

In the code, the if statement checks whether WordPress already displays a sidebar. If not, it will show the widgets you have added from the Widgets menu under the Appearance tab.

Then, add the HTML tags, which contain the document metadata, like the web page title, default character set, responsive design viewport, and the linked stylesheet. All these details are enclosed with different tags.

If you have different layouts for the header, sidebar, and footer, add the template tags to call their code into index.php. For example, use get_header to link the header, and so on.

Then, add the tags to create the main container and assign a class for styling. Use a WordPress loop to retrieve the post content and display it using the_content() function.

Areas like landing pages contain everlasting content that rarely changes. Instead of single.php, they will inherit the layout from index.php if dedicated page templates are missing.

3a8082e126