This is intended to be a Read-Me for Flawless developers so they can get to grips with some of the functionality of this Parent-Child theme structure and some of the features available in this theme. The idea of this is to reduce technical debt each time we get asked to build a custom theme – we end up repeating work that we have done a hundred times over – and usually its for tasks that are vaguely content focussed – I want this element here or can we make it do this (rather than what I would argue is actual development work).

So starting from that basis there are a number of features that remove a lot of the grunt work from a lot of what we do. Starting off with an asbtract overview – the theme is parent-child and most of the functionality lives in the parent and can be extended from the child. So for example if we wanted a different menu structure in the child theme we would simply copy over the nav walker file into the child overwrite this. Using locate_template() function in WordPress the Parent/Child relationship prioritises the existence of the file in the child theme before the parent therefore we can overwrite most of the functionality this way if we choose to.

The most prevalent issue we run into with Parent/Child is the Javascript. Old style JS is heircachical and therefore it needed to live in the Child to have prevalence and even then would cause conflicts. To get around this the JS is set up in the parent as a function which exposes and API in the child – so if you need to extend the functionality of the parent – you can modify one of these child extend files – or you can disable the parent js module altogether and just write your own (beware as a gotcha though some of the JS is bundled in each module so if your sure you want to re-write it rather than extend it be prepared you might lose some other functionality that you will have to rewrite) over-time we can modularise this further to make sure theres fewer dependancies to reduce this overhead.

Again all of the CSS can be extended from the child – the loading order is such that anything that gets written in the child will take prevelance over the parent. It doesnt prevent you from creating all of your own stuff in the child theme – just reduces the need to if you can extend functionailty and or styling so your not having to rewrite it each time.

I think we should establish some groundrules for deciding what makes it into the parent over time and each thing even if it appears to be minor should be discussed and have consensus. So my argument would be for things like creating a button which has multiple types of content in it like images text links or captions (several different contents) becomes a layout rather than a component (similar to what we discussed before). The more you apply this logic I believe is where we get to a point where it becomes significantly harder to maintain as you are creating layouts as opposed to content types. I think that if we are creating a “content type” it should theoretically look visually the same if it is in col-2 to col-12 as in it scales proportionatly and will work on all screen-sizes. If it doesnt fit that criteria then it becomes a layout and one would have to find a more sensible way of adjusting it to work across all possible configurations that a user might design.