mTips for managing Genesis Child Theme custoizations

[l_entrepreneur]

Hi Everyone.

As a new user to both WordPress and Genesis, there are many complexities which are not easy to initially understand. For someone looking to modify a Genesis Child Theme, this is particularly the case.

I thought I’d share some tricks I've found over the past couple of months while building a Genesis for WordPress site.
This post is for sharing purposes, and all are welcome to contribute, comment or correct. I hope it helps someone with the same questions I was asking.

Feel free to jump straight to the solution tips section. The middle part of to give context to new users.

The audience:
Certain aspects around how to correctly customize a Child Theme and where this should be made are not as obvious as one might expect.

There are some widely varying approach and knowledge gaps in advice available to new Genesis users. While this post might fit into that category, I’m hoping there are some who will find this beneficial or at least thought provoking.
WordPress makes creating a blog or website look easy, but once you get your hands dirty with both Genesis and WordPress code, the sophistication and complexity of these tools become immediately evident.

There seem to be three distinct groups of people who utilize and modify Genesis content. Those who:
1) use a Genesis Child Theme and are happy with the available WP plugins and features within the Genesis Child Theme.
2) use a Genesis Child Theme but want to modify code and add content which is either not available via a plugin or needs coding changes in php, html, javascript or css.
3) build a child theme for their own use.

I have now read hundreds of blogs and almost every theme developer has journeyed down this same path. At one point or another they changed their approach as their knowledge grew and their needs changed. While there is defiantly no absolutely correct way of customizing a theme, there is certainly some direction that are better than others. This makes the first few weeks into customizing quite daunting and very confusing.

For those ambitious enough to create their own Child Theme from scratch, the two best starting points appear to be:
1) (http://www.billerickson.net/genesis-base-child-theme/)
2) (http://bonesforgenesis.com/).

This post will focus on the middle group. Partly because this is where I’m at in the journey and partly because I was unable to find these answers when I started looking.

I will assuming that this group wants too preserve the upgradeability of the Child Theme, so modifying the Child theme is not an option. The child theme I am using is the Dynamik Website Builder.

The problem:
After finding a few but significant issue with my Child Theme, I sought advice from both the Genesis community and the Child Theme developers on how to best manage customization. On paper my Child Theme should be able to manage all customizations, but in reality it has a few weaknesses which I was not willing to put up with.

My requirements are quite simple:
a) be able to add custom CSS, PHP, HTML, templates, javascript, and jquery ui features
b) all changes to be standalone, adding to the Child Theme rather than modifying it
c) allow easy switching of themes in the future by someone other than me
d) keep the design approach pure to WordPress design philosophies
e) able to protect customization from the end user making mistakes. In my case this is my family, so I’m keen to make this as simple yet as flexible as possible.

WordPress philosophy:
While there was to be some liberty taken by WordPress themselves, and by Genesis on how design should be made, most of this seems to relate to the past. There are dedicated sections on both website on how to code and design solutions. The benefits are greater compatibility between themes and plugins, and a more stable and simple way to make changes.

Two WordPress design considerations are very apparent.
1) Functionality and content that could exist across themes should reside in plugins.
2) Style and elements that are not relevant across themes reside in themes.

My Child Theme has a great plugin to help automate small scale changes, but if you want to utilize their style design tool, it only comes as a theme that includes the technical design tool hardwired into the theme. This is not a problem until you face bugs or want to turn features off.

In searching for a way to circumvent some issues decide on the best approach to where changes should reside, I found a few tips which are likely to be beneficial to anyone who uses a Genesis Child Theme.

The solution options:
Depending on Genesis expert blog you read, you will find different ways to approach the customization of a theme.
For non-Genesis people, the typical solution to this problem is to create a Child Theme of the Parent theme and all works very easily. This is how users of “canvas” theme by woothemes make changes.

The Genesis framework takes the Parent theme role. It is therefore not possible for a Genesis Child Theme user to adopt the standard WordPress approach unless they want to change a theme that likely cost money, has regular updates, and you might be paying support on.

The more advanced users seem to not use other peoples Child themes, instead they create their own child theme. I don’t fall into this category of user….yet!

One solution you may read about is to create a plugin for your changes. This initially seems smart until you understand that users can easily turn these off, and they can be deleted in just two clicks. An unusual issue can be caused by someone putting a plugin into the WordPress plugins area with the same name. Apparently your plugin could be overwritten during updates. There are many ways to limit these issues, but they begin to create more unnecessary work.
In the end I simply did not like that functional design content was buried in the plugins directory.

How can we therefor preserve the Child Theme while also giving an organized and structured place to make changes of any complexity!

The solution tips:
Below are a few tips to help you when decide how to organize your customization work.

Tip 1: Learn about the “mu-plugins” folder.
This is a WordPress folder that needs to be manually created in “wp-content”. It is scanned by WordPress and functions similar to a Plugins folder. Mu-plugins show up in the WP plugins screen, but they cannot be deleted or modified from within WordPress.

The WP codex on this folder contains details on the limitations: (https://codex.wordpress.org/Must_Use_Plugins)
There are some limitations, but most of these are exactly the reasons you would look at using this folder.
One unfortunate limitation is that the sub folders are not scanned for their {plugin}.php file, meaning you either need to create a simple master file to call each plugin, or you need to move each of the {plugin}.php files to the root.
Because this folder is not used for anything else (on a personal site), you could choose to use the entire folder as your own person plugin folder.

If you don’t like any of those options, a nice mu-plugin called (must-use-loader) has been developed which scans the sub folders for you. (https://github.com/bueltge/Must-Use-Loader).

The use of mu-plugins folder allows you to adopt a WordPress style variation to the unofficial Grandchild theme concept. (http://docs.appthemes.com/tutorials/creating-grandchild-themes/)

If you are still not sold on the idea, there was a time when Bill Erickson, one of the gurus of Genesis, used this approach extensively. (http://www.billerickson.net/core-functionality-plugin/). His reasons (in the blog link) for limiting the use of mu-plugins are not relevant to my situation and probably won’t affect many others.

Tip 2: Model your custom content directories and files on WordPress and Genesis structures
One thing that confused me when I first started reading about customizations, was the constant reference to putting changes in the functions.php file. After a while I realized some people actually do this, but that many consider it a generic reference to any file that acts like a fucntions.php file.

Reading some blogs, people seems determined to justify that all code changes need to be added to a single functions.php file for performance purposes. From what I have read, this is both incorrect and can actually cause more problems than good.

Every WordPress plugin has its own equivalent to the functions.php file. A few hundred lines of your own code in a separate file should make no performance difference. The quality of the code is probably a much more important consideration.

One beneficial reason to putting code into separate files, is that it makes debugging and experimenting with options much easier. It also makes finding and reading code easier.

Here is the code I’m currently using in my “mu-plugin” file. This changes and evolves on a daily basis as I learn and tidy up my build, so feel free to point out any improvements.
http://codetidy.com/8437/

Tip 3: Learn about the WordPress template hierarchy.
You have probably read blogs urging people to understand the template hierarchy. When I first did I opened up the codex and skimmed it, but could not appreciate its importance, or its elegant simplicity.

As soon as you start learning about Advanced Custom Fields, this is one area that should be reviewed.
The WP Codex (https://codex.wordpress.org/Template_Hierarchy) has a useful diagram but I prefer another one and have the image saved on my desktop (http://marktimemedia.com/assets/template-hierarchy-retina-blue.jpg)

Tip 4: Learn about the WordPress template hierarchy.
To better organize your custom templates, there is another WordPress folder that is not initially created. It is called “my-templates”. It is manually created in the Child Themes root folder. See the WP Codex for reference to this (http://codex.wordpress.org/Page_Templates#File_Folders).

While you could easily add custom templates to the root of the child theme, using this folder make it easier to organizing large numbers of templates.

Tip 5: Adding custom templates to the mu-plugins folder.
Adding custom templates to the mu-plugins folder falls into the grey area between functionality and style and seems to be a point for debate. If you build a Custom Post type solution and your templates would be required to function across themes, then putting them in the mu-plugins folder makes sense.

To allow the automated WordPress template hierarchy searching to work with your custom template folder location, here is some code that I’ve found to work effectively.
http://codetidy.com/8438/

Cheers, W

[Susan]

Great post! Thanks for sharing!

[sammond7]

great tips! looking forward to trying this mu-plugin concept! Thanks!!!

[Author]

Posts