WordCamp St. Louis: The Anatomy of a Premium WordPress Theme

Brian Fegter gave a talk in the afternoon discussing WordPress premium themes. Brian runs Mister Nifty where he works with churches of all sizes on their tech needs.

He got started by covering the truth about commercial themes. As he says:

There is not one single theme that does not require support. You must build a support system

Brian also believes that software development needs to be for the customer. This is why support and documentation are so important. As he pointed out, a purchased theme rarely stays in its original condition.

Having a solid template architecture is also fundamental to creating a good premium theme. Brian pointed to the WordPress Codex for information on theme development and template hierarchy.

Brian set down a credo for properly developing a theme. He believed that you should:

  • follow template hierarchy patterns
  • clearly name supporting files and folders
  • never, never, ever, never, ever nest a plugin inside a theme
  • clarity over cleverness

WordPress assets are your friend when coding a theme. There’s a lot that is built in to WordPress which will let you easily enhance a commercial theme without a large code footprint. The main things discussed were:

  • clearly named sidebars
  • custom post types only when necessary
  • define theme locations for menus
  • localize your strings
  • set WP image sizes vs image resizing scripts
  • leverage the power of CSS with body_class() and post_class()

He also showed off some cool functionality in the UpThemes framework that’s available on Github. There’s lots of sweet stuff built in there for Google fonts and more.

In some ways code is narrative. Your theme tells a story and has an intended result. The back-end code should clearly narrate the story of the front-end display. All this helps because clean code leverages the brain to quickly identify and associate words with functions.

Functions though need to use prefixes and should only try to accomplish one thing. If any function includes things that can be spun out into a separate function then they should be spun out that way. For code comments with functions Brian says that:

If it’s necessary to comment about how a function works, your code stinketh.

It’s also a good idea to use built in functionality for things like browser detection and content filtering. This keeps you from having to add lots of server overhead and user frustration. In other words, we should be creating useful code, not duplicate code.

Comments

Brian Fegter says:

Thanks for the writeup! I appreciate it.

You’re welcome!

[…] recently gave a talk at Wordcamp St. Louis. You can see a more in-depth writeup of my session on Andrew Spittle’s blog. Below is the slide presentation I used. Enjoy! Wordcamp St. Louis – Clean Coding Posted by […]

Comments closed