Where to organize code in WordPress

You have 2 options for the placement of custom code in WordPress. Either you create a plugin, or you create (or edit) a theme.

Some developers coming from other frameworks have the impress that in WordPress there is a lot of complexity and blocking stuff that would get in the way of coding. That’s a misconception based on the reality that some newcomers especially to freelance development, end up doing work with existing 3rd party code. In other words it’s the nature of trying to add to an existing plugin or modify an existing theme, that in that situation you have to learn and grapple with the complexity of an existing codebase. And sometimes that will be a relatively undocumented or perhaps poorly coded project.

What I want to impress on you is that in WP you can start with fairly blank slate, not much different from how you start a project using a PHP framework such as Laravel or CodeIgniter, or even a NodeJS project.

I highly recommend that even if you plan to support and work with 3rd party themes, that you experience WP directly by building a simple WordPress theme from scratch. Don’t be intimidated by the prospect of this challenge. It’s actually quite simple and we can show you how to get a basic theme installed in under 10-minutes.

Even if you plan to work mostly as a plugin developer, it’s worth knowing how themes work, understanding template hierarchy and other fundamentals of how WordPress delivers content to the browser. This will help you craft plugins that work with themes properly and which can be supported by most themes.

Base Theme versus Child Theme

We tend to recommend that you learn and use Base Themes, which are full WP themes on most projects. But we know some of you will want to explore the world of WordPress 3rd party themes, or you’ll have clients that insist on a certain theme, or you’ll be taking over the management of an existing site with a theme already installed. In these cases unless you can switch to a new custom base theme, you’re next best option is a Child Theme.

Understand that generally “hacking themes” is not advised. This would be changing or adding code to an existing theme, especially a 3rd party theme. Even with the WP default themes, again a child theme is recommended instead of changing any of the code contained. The reason is because those themes are not managed by you, their managed by the theme developer. As updated are released, your changed will all be completely over-written, and therefore lost, which will often break a site. Typically as a result of this if you were to hack a theme, you only have 2 options for management and neither are good. One is never update that theme. This is bad because if a security flaw is found and fixed, you don’t get that fix. When WP updates are made, you’re theme now falls farther and farther behind and may eventually be obsolete (broken). The other option is you somehow manage your custom changes and repeat those changes after each update. While you might be able to automate this process, if you’re that technically proficient… why did you hack the theme in the first place?

The one situation where we would not call it “hacking a theme” to make changed directly to a 3rd party theme, is when you really have carefully determined you want to manage that entire codebase. In other words you’ve decided to start with a 3rd party theme, but now you’re going to adapt it to fit a site, and you’re never going to use any further updates from the original developer. In other words you’re forking the project. This could actually be a worthwhile approach to consider in some circumstances. You might really want certain features or styles from a theme, and if you like how the original developer structured it, then you might decide to work from it, and fork the project.

About the Instructor

Casey Milne

Senior WordPress Developer, Eat/Build/Play

Casey started programming PHP in 2003. His early work involved PHP application development and custom sites built from PHP and HTML. He adopted Drupal in the early days of CMS, and then switched later to WordPress in 2012. For the past 8-years he has developed WordPress plugins and large-scale WP sites. Casey's main forte is handling API integrations and building data-driven functionality in WordPress.