Whilst designing new websites, it’s common to use an off-the-shelf theme as basis for a new site. However, making changes to a theme or plugin can cause problems when it comes to upgrading.
When making changes to plugin or theme code, it’s important to be aware that when these plugins or themes are upgraded – your changes will be lost.
There are often two very different schools of thought on this. If you’re developing the site for a client, it is often tempting to simply make changes directly; in fact – sometimes this is desired if most of the module is being replaced. However, it’s often done as a short-cut to save time – it means that the changes to the site can be reflected immediately.
However this means that problems will only be found when the module is upgraded – or worse, upgrades will be put off completely to avoid costs.
Depending on the platform that you’re using, there are often methods around this – but almost always at the cost of immediate development time. However, any good developer should be already practising these guidelines; and companies not following it are generally a warning sign if upgrades are expected.
Before you do perform upgrades, it is always recommended to manually take a backup; and confirm that it is usable.
WordPress
WordPress offers a neat system for theme changes in Child Themes. We’ve used this ourselves, both developing child themes manually and using tools such as Child Theme Configurator. These use the built-in WordPress systems to allow overriding particular templates and CSS styles. This effectively creates a new theme, which references another existing theme as its’ parent and applies changes. There can be found a huge amount of information on the official WordPress codex.
Many modules, such as WooCommerce also support their own variations of these methods, although there is no fully built-in system for overriding plugins – only themes.
Magento
Magento supports a variation of these called Subthemes. This requires setting a parent theme in the theme.xml, and work in a very similar way. As per usual with Magento, almost everything is an XML configuration and can override or remove other blocks, and even use new classes. Magento’s system is a lot more complicated that WordPress, and offers a lot wider customisation of themes, but makes it much more difficult to do so.
The plugin system works in exactly the same way, and unlike WordPress, also allows the use of these blocks and designs to change plugins in a very generic way – albeit with much more work.
We’ve mentioned just two platforms above that use child themes, though there are many more frameworks that support similar systems. We always recommend the use of child themes where possible, as although it can mean development is more complex – the result that upgrades can be completed without worry is far more important.