How developers are getting WordPress theme development wrong
The world of WordPress theme development has advanced over the years to give small business owners an incredible array of options to layout and style their WordPress blogs, websites, and ecommerce stores at minimal cost. In the past, theme development was costly. Building themes from scratch and writing all the rules of how a how a theme should function or how it should be laid out needed to be planned, designed, and coded from scratch. Today, theme frameworks, the new WordPress “Customizer” (introduced in WordPress 3.4), and “child themes” make it far easier to develop custom themes that are visually exciting while also including additional functionality using javaScript (or variations of javaScript, like jQuery, Backbone, or Node).
Every year since 2010, WordPress has released a default theme that is added to the Theme management panel in your WordPress install. These themes are usually white background and black text – so they are literally a blank slate for you or your developer to color around the lines. They are called frameworks, because they already include the complete layout and rules about how to handle font sizes, font colors, rollovers, bullet points, block quotes, featured images, and overall page layouts. It’s sort of like a coloring book. You get the book and there are already sketches available for you or your child to apply a design aesthetic using crayons or colored pencils.
As we’ve learned how themes should be developed, we’ve coalesced around the concept of standardization. The commonalities in theme development are applied in theme frameworks, allowing theme developers to focus on style and advanced functionality, rather than writing the same line of code across multiple themes to display something as common as a post title, post excerpt, or featured image. In addition, today’s theme framework developers have also advanced the idea of page builder templating tools, which provide a website owner with the ability to add a homepage carousel themselves or layout the home page as columns and rows with blocks of content by replacing the WordPress post engine and making the layout look more like a website than a blog. While theme frameworks make it easy for theme developers to create custom themes, they are inherently complex themselves. The developers of these frameworks are providing a toolset for general theme development and they must be able to push new versions with bug fixes, security patches, or new features requested by users. Disconnecting a framework from its developer prevents the developer from providing these important updates.
At Digital Strategy Works, we keep finding very capable theme developers taking default WordPress themes that ship with WordPress (or other popular theme frameworks) and hacking them to create new custom themes. We have a huge problem with this. When a developer takes a pre-built theme framework (ex. WordPress 2016 that ships with WordPress as its default theme), hack it, and rename it, they disconnect the theme from being updated by the original theme author. In this case, WordPress themselves! We need to maintain that connection to the theme developer who will push new releases, because themes must maintain their connection to their originator to take those updates.
You may be asking the question, “well, if theme developers aren’t supposed to hack and rename theme frameworks, then how can they do theme development?
The answer is, child themes!
What is a child theme? It is a theme that is the child of a parent. In web development, we use parent/child relationships to define when something is primary and when something else is directly related to primary. Want to know more about parent/child relationships in web development? Here is a good review of parent/child relationships in CSS on the Lorelle.WordPress.com blog.
If the parent theme framework contains all the pre-set rules, you can create a child theme of the parent theme with it’s own set of rules that override the parents without actually changing any code in the parent theme, which is the master framework. For example, if a font color for a hyperlink in your parent theme is defined as blue in the parent’s CSS style sheet. You can create a new CSS style sheet in the child theme and define the link color as red. You never touched the original CSS file and that rule for the link color, but your child theme’s CSS file rule will override the parent theme rule and make the color of the link red, instead of blue.
Another function of child themes is the ability to add a functions.php file inside your child theme, then add additional functionality to your parent theme, without overwriting its own functions.php file. A functions.php file contains some of the more complex rules around how your theme actually functions. If a developer writes functions into the functions.php file of the parent them, any new update from the original developer will wipe out that code. That’s why it’s important to add functions to the child theme functions.php file and not the parent’s functions.php file. Make sense?
We don’t want anyone touching the parent theme framework and all the underlying code. We want to create a child of the parent, which simply overrides CSS styles or adds additional function logic to the parent them without actually touching the parent theme files themselves.
Example: Name of the theme is the business name and shows an update available.
How do you know if your developer has hacked a theme framework and left you with a theme that cannot be updated? That’s difficult for the non-technical small business owner or a non-technical employee managing WordPress sites for a large business to know. However, you can login to your WordPress admin Dashboard, navigate to Appearance > Themes, and check the active theme. If the theme does not have a name or if the theme is the name of your business (like the example shown above, which is common practice), your theme may suffer from being disconnected to its original developer. Notice in the example that the image for the theme is not the actual image of the site itself. It’s still the image of the WordPress theme framework that was modified. If it were the child theme, then it might have the correct screenshot of the website homepage. If the theme was renamed as your business name or doesn’t have a name, but does show that it can be updated – DO NOT UPDATE! You will overwrite your theme files with the update and break your site.
Warning: Don’t try this unless you have daily backups and you’re working in your staging (alternative development environment)
To test the theory that your developer took a theme framework, hacked it, and renamed it without using a child theme, you need to push your live site into a staging environment and then update the active theme. You should always backup your files before you make any updates. Some hosting companies provide daily backups, while on others you must use a plugin for WordPress like Backup Buddy to backup your site to somewhere (like DropBox or Google Drive) other than where your WordPress files are hosted. I mean, why backup to the same folder on your host that WordPress is on? If you ever have an issue, not only is your site lost, but your backups are too!
If you have a website and your WordPress developer left you without the ability to update your theme, then contact us today. We can help convert what your original developer left you with into a child theme of a recent theme framework (we use the Make Theme Framework by Theme Foundry) and then you’ll be able to take theme updates without having to worry about breaking your site.