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

Brian Fegter gave a talk in the after­noon dis­cussing Word­Press pre­mium themes. Brian runs Mis­ter Nifty where he works with churches of all sizes on their tech needs.

He got started by cov­er­ing the truth about com­mer­cial themes. As he says:

There is not one sin­gle theme that does not require sup­port. You must build a sup­port system

Brian also believes that soft­ware devel­op­ment needs to be for the cus­tomer. This is why sup­port and doc­u­men­ta­tion are so impor­tant. As he pointed out, a pur­chased theme rarely stays in its orig­i­nal condition.

Hav­ing a solid tem­plate archi­tec­ture is also fun­da­men­tal to cre­at­ing a good pre­mium theme. Brian pointed to the Word­Press Codex for infor­ma­tion on theme devel­op­ment and tem­plate hierarchy.

Brian set down a credo for prop­erly devel­op­ing a theme. He believed that you should:

  • fol­low tem­plate hier­ar­chy patterns
  • clearly name sup­port­ing files and folders
  • never, never, ever, never, ever nest a plu­gin inside a theme
  • clar­ity over cleverness

Word­Press assets are your friend when cod­ing a theme. There’s a lot that is built in to Word­Press which will let you eas­ily enhance a com­mer­cial theme with­out a large code foot­print. The main things dis­cussed were:

  • clearly named sidebars
  • cus­tom post types only when necessary
  • define theme loca­tions for menus
  • local­ize your strings
  • set WP image sizes vs image resiz­ing scripts
  • lever­age the power of CSS with body_class() and post_class()

He also showed off some cool func­tion­al­ity in the UpThemes frame­work that’s avail­able on Github. There’s lots of sweet stuff built in there for Google fonts and more.

In some ways code is nar­ra­tive. Your theme tells a story and has an intended result. The back-end code should clearly nar­rate the story of the front-end dis­play. All this helps because clean code lever­ages the brain to quickly iden­tify and asso­ciate words with functions.

Func­tions though need to use pre­fixes and should only try to accom­plish one thing. If any func­tion includes things that can be spun out into a sep­a­rate func­tion then they should be spun out that way. For code com­ments with func­tions Brian says that:

If it’s nec­es­sary to com­ment about how a func­tion works, your code stinketh.

It’s also a good idea to use built in func­tion­al­ity for things like browser detec­tion and con­tent fil­ter­ing. This keeps you from hav­ing to add lots of server over­head and user frus­tra­tion. In other words, we should be cre­at­ing use­ful code, not dupli­cate code.

3 Responses to “WordCamp St. Louis: The Anatomy of a Premium WordPress Theme”