3rd Party CMS Module or Custom Code?
Third-Party modules or custom code?
Our experience with core CMS platforms and their so-called “included” or available modules that purport to satisfy popular needs of our clients, such as blogging and e-commerce, has taught us an important lesson:
They usually do not satisfy the requirements.
Even if they come close, extensive custom code is required to bring the basic functionality of these modules to function as advertised, and especially, as specified by our clients.
Reliance on custom code rather than “out-of-the-box” functionality may seem counter-intuitive. Why not just configure and go? The simple answer is that’s just unrealistic. Why? The client will always be unsatisfied with the outcome – the feature or functionality is almost never quite right.
Further, the module almost never integrates with existing systems. Or it may integrate with the CMS in question, but is so difficult to understand and maintain, that in the long run, the module will stand in the way of future improvements and functional requirements.
Add to the mix responsive design. Upon implementation we have recently found that many of these modules do not adhere to best practices of responsive, and we must programmatically override components (at great cost and complication) to ensure compatibility .
However, the introduction of these custom overrides presents a new conundrum: future module upgrades are impossible. So even though the site now renders responsively, the client is stuck with a non-updatable module - completely defeating the purpose of using the module in the first place.
In this case, you’re damned if you do, and damned if you don’t, as they say.
These are just a few examples of the problems that arise from “plugging in” heavy and un-abstracted modules that purport to do it all. In reality they only do only what their designers thought was of general value. These modules are often lacking in code transparency and extensibility. They are closed systems that do not account for very specific client needs.
So how do they even get on our radar? Marketing materials and salespeople will promise prospective clients the world to sell their core systems. We know that in the end the client ends up with more costs and frustrations trying to use add-ons than if they were to implement light-weight, functionally specific, custom modules that are transparent, flexible, de-buggable and healthy – and fully owned by the client.
But sometimes the deal is already signed, sealed and delivered.
As technologists, if and when possible, we must guide clients to the right technology solutions, but when they go down the module road, the next best thing we can tell them? Proceed with caution.