Don’t hit the panic button!
The Open Source revolution has been ideal for a great many, specifically the content management systems (CMS). However, CMS’s have their pitfalls and disadvantages. Quite often, they won’t immediately rear their ugly heads but sooner or later they will. There exists a multitude of CMS’s for all purposes. Wiki, social media, blogging, bulletin-boards, chat forums, e-commerce, websites, calendars, customer & sales management and even dating, no kidding. The common strategy is to purchase a template of which there are thousands from which to choose, enabling you to setup a beautiful website in a single day if not sooner.
Open Source tools have enabled people with no technical background to quickly and most importantly establish an attractive web presence in a very short time, in a very inexpensive way. This website is running on WordPress.
However, Open Source CMS’s are great until…..they break…..and break they will.
If you’re running a business you’ll inevitably demand more out of your website, most likely sooner than later. This usually means adding extended functionality in the form of plugins or modules. This is where the road becomes perilous. Running a few very well supported and popular plugins probably won’t bring the house down. But, if you keep adding them you will most likely run into problems.
First, even some of the most reliable and popular plugins can clash with each other. This is just a fact of life when it comes to the general business of micro-computing no matter what you’re doing. Second, not all plugins are created equal. You might use one whose owner has orphaned it. If it’s not consistently updated, there’s a good chance it will break when you install future CMS updates. Maybe not tomorrow or a a year, but sooner or later a plugin will simply stop working. If it’s a plugin on which you rely, you’re going to be in a world of hurt. Third, adding too many plugins slows down your site. If you complain to your web host, they’ll suggest upgrading to a more reliable (and thus expensive) hosting package. Fourth, even paid and supported CMS templates will eventually break. Links won’t work, styles are absent, forms won’t submit, etc. The best way to deal with this is by turning off automatic CMS updates, but then you become increasingly vulnerable to security risks the farther you fall behind.
Open Source development is slightest toward setup and implementation, not fixing broken things. The most common solution is to reinstall everything. It’s the old “I don’t know what’s wrong, but I know how to fix it” approach. If you didn’t make a site backup, you’re in another world of hurt. There are people out there (including me) who won’t touch broken CMS’s. This is from bad experience(s) with clients whose sites needed maintenance, and my best efforts broke them even more. I spent days trying to get it right, but I realized there’s no telling how long it could take and I had other pressing projects on my plate. I had to admit my ineptitude and cut them loose. Still haunts me. I will no longer fix broken CMS’s UNLESS, it’s part of a professional job. Almost weekly I turn down someone looking to get a broken WordPress or Drupal site fixed.
So, if you’re dealing with a broken CMS site, I feel your pain. You don’t have many options unless you have very deep pockets. In closing, here are a few of things you can do to avoid this very stressful pitfall. First, keep a completely separate development environment running your version of the CMS as a perfect mirror of your live site, replete with all plugins and content. Update everything including the CMS itself or any plugins in the development environment first. Second, THOROUGHLY TEST the upgraded site. Doing it right could save you a major headache later. If it’s e-commerce, test a purchase with a single and multiple items in the cart. Then test it with multiple items of each aforementioned scenario. Make yourself an exhaustive testing plan to ensure everything passes. Fourth, spend the money on professional tech support. If you customize anything in a template, make sure you keep a log of what changed to provide the developer(s). If you didn’t do this, just download the entire site and compare each file to a virgin install using a free IDE tool with a ‘file diff” feature (Sublime Text, NetBeans, Text Wrangler, etc. Even MS Word might do it.) Then you can figure out what changed and change it back.
If properly managed, Open Source tools can be a godsend. But, a great many are discovering their ugly side.