Joomla! and Wordpress are great content management systems and offer a wide variety of features that should cover most of the usage scenarios when you employ a CMS to build a website. If that’s not enough for your needs, you can choose from thousands of free and paid extensions (or plugins) that will, depending on type, either add that one small feature you need (that “Share” button for your audience to share some useful information from your website on their social media accounts), or completely transform your website’s CMS into a full-fledged social network, or news portal.
There are, however, cases where you just won’t find an extension or a plugin that does what you need, especially when you need some content from an external service. That’s when you get a piece of code from the provider, and instructions on where to add it. You paste the code, check if it works, and after a correction or two, it happily shows (and works) on your site. Happily ever after? Yes, but not always.
Embedded code does have one major drawback - it relies on an external service to show content. Those services are subject to changes that may, or may not, break the content that is embedded somewhere. It’s best to check once in a while if the code still works, especially if we built the website for someone other than ourselves - or set up a monitoring system, like uptimerobot to watch it for us. If you use a monitoring system and the embedded content displays regular text, you can set it up for certain keywords, like „title”. Just make sure you are using the text that is in the embedded content, not around it.
One good example of things that require maintenance that is recurring would be Google’s reCaptcha. Over the years they changed their API a few times, rendering all CMS extensions useless until the developers caught up with the changes and released updates for their plugins and extensions. Contact forms on websites stopped working because the plugin was waiting for external data that just wasn’t there anymore. Had the captcha protection been added manually to the site’s code, the website owner would be able to immediately remedy the situation by replacing the code with the updated version, rather than wait for the plugin developer to react to the changes. More manual work, but possibly much quicker solution.
Another case of custom coding that might not age well is CSS tweaking. The usual problem with the styling changes in templates is that they are made in the core template’s or theme’s files. It’s good because all the code is in one place, but it’s also bad because of the same thing - if you update your template (or theme), the changes you made (or had done for you) will most likely be overwritten by a new file with updated code. That means searching the site’s backups for the custom code, or even rolling back the site just to keep the styling in the original form.
Many Joomla! Templates and WordPress themes allow customization via additional files that are never automatically updated. A good example would be our CloudBase 3.0 template, and its’ capability of grabbing a file with custom CSS rules that you upload to the site - a great solution if you want to be absolutely sure your changes stick even if you update your template. It’s very convenient, but you may run into a situation where a template update that worked on one of your sites, simply does not agree with another one. By that time you should already be renaming (or removing) the custom CSS, as it’s definitely the culprit.