Time to Say Goodbye to WordPress

Introduction

For over a decade, ByteLaunch has developed hundreds of websites. Although we have built them on multiple platforms, the most common by far is WordPress. Why? In our early days, it competed with the likes of Joomla, Drupal, and Dreamweaver. To say WordPress was a breath of fresh air is an understatement. In contrast to the aforementioned platforms, WordPress was far and away the easiest to use which made it extremely appealing to customers. Additionally, it was open-source, meaning not only was it free, but it also made it extremely attractive to developers to build plugins and modify the code base to extend its functionality—a no-brainer to recommend, and we wern’t alone in our assessment. Today, WordPress is the most used content management system (CMS) on the internet. 42.9% of the world’s websites are built with WordPress according to w3techs.com and if we look at websites that are created with CMSs, that number is even higher with 65.3% of websites built with an identifiable content management systems.

A Quick History Lesson

Let’s first talk about what WordPress was designed to be: platform for simple blogs. Over time, the development of the platform led by the open source community moved the software in a direction so it could do more than it was initially designed to do because the core concept and user friendly interface was ahead of its time. While that sounds great on paper, the evolution of the code base lead to a significant amount of “code bloat” (we’ll discuss this in greater detail below). The problem was there wasn’t much the developers could do as they couldn’t just start over knowing the primary use of the entire platform had shifted beyond its initial intent. If they chose to rebuild from scratch, you would be dealing with a mess of incompatibility issues which would have almost certainly led to its premature demise. However, in fairness to the developers, its very likely that rebuilding the platform probably wasn’t even considered as the evolution happened over a period of time—we just have the benefit of hindsight. We would have likely done the same thing which was to give what the people wanted and continue to support the platform’s core by way of patches and workarounds as they really didn’t have much of an option even if they realised it would best to start from scratch at a certain point. It simply wasn’t a realistic solution for a number of reasons. With a platfom with almost a 20-year span, the gradual evolution of a sub-optimal core for a globally used CMS ultimately compromised it in two critical areas which we are feeling the effects of today.

Early WordPress Backend User Interface

Performance

Once you have WordPress installed, you need to add your favorite plugins for easy editing, backups, security, SEO, contact forms, and any other additional functionality your application requires. Next, you need to add a theme, most of which attempt to accommodate any design you can throw at it—trading a lot code efficiency for the promise of “creative freedom” (which was rarely fully realized in a practical sense). At this point, you’ve added even more bloat to an already hefty platform. The biggest consequence of all of this extra weight is performance, aka, speed, which is not only detrimental to the user experience but also to organic search engine rankings. Yes, people have been trying to solve these speed issues with CDNs, image optimization, caching plugins, etc., however, these “fixes” do nothing to address the primary issue of code bloat. All you are doing is trying to treat the symptom with no cure for the desease. Unfortunately, there is not much the community can do about this (as discussed previously) and it’s only going to get worse as time goes on. Implementing tools to help speed up the platform may marginally increase overall load times but it can never perform as well as a modern lean platform designed and optimized to address the underlying performance issues that WordPress won’t ever be able to realistically solve.

Google Pagespeed Report

Security

However, the most serious flaw when it comes to WordPress is security. In the past year, we have been tasked to clean up numerous hacked WordPress sites and those calls have been growing at an alarming pace.

Today, 94% of the websites hacked are running WordPress. It is the most targeted and vulnerable CMS on the market.

This mainly comes down to two issues: the fundamental (and now outdated) web principles of a platform designed as a simple blogging engine that was launched nearly two decades ago, and its own popularity. The widespread popularity of WordPress with its underlying core that was not designed to be the world’s most popular CMS makes it very appealing for hackers to develop automated bots to spider the internet and gain entry to vulnerable sites. A single popular plugin with an honest oversight could leave a backdoor open to millions of websites. It's far too easy.

A Recent News Article on 4.6 Million Attempted WordPress Site Hacks

Updating your website frequently can make your site less susceptible (assuming you have only installed quality plugins and themes that the authors update and maintain frequently), however, often times an update will cause a conflict that breaks the functionality which can be noticeable by visitors or worse, bring down the entire site. This makes us as developers, let alone an average website owner reluctant to update the site as updates become available. In order to ensure uptime, our approach is to complete an offsite build, update the site on a staging server then resolve any issues prior to implementing the changes on the live environment. The problem with this procedure is although it is prudent, it takes a significant amount of time (aka, money) to do this every time a plugin or the core needs an update (which is often). Even with all this work, it will reduce your liability but never eliminate it completely.

Wordfence WordPress Security Plugin Showing Current Site Issues

If your site is hacked, it can be extremely difficult to clean out all of the malicious code that spreads quietly and viciously like a form of cancer. You may be able to use some tools to find malicious code but that is assuming that it has been identified previously on other sites and added to a list of harmful scripts for the tool to compare against which is not always the case. For every site we have ever cleaned, the security software has identified issues on roughly 50% of them. For the ones that did properly identify problems, the tools have never identified all of the infected files—ever. Failure to correctly clean all of affected files will result in further spread until you realize your site has a banner for discount prescriptions and Google has banned your site from advertising. On one such occasion, it took our customer over a month to get their ads back up and running. The best remedy is to review every file and entry within the database to ensure it has been fully cleaned out and as you can imagine, could take a significant amount of time and is reliant on a very experienced developer to determine what is supposed to be there and what is not. This process can be very difficult even for the most senior developer as it is prone to human error as hackers have become much more sophisticated with their techniques and try to disguise malicious code in very innovative ways. We had one customer that had so much malicious code on their site, it was going to cost more for us to clean it than it was to simply start over from scratch. Now, you can put contingency plans in place such as automated backups which will avoid scrapping the site completely but in the event you need to restore from a backup, you will need to determine when the problem started otherwise all you are doing it chopping the weed down and not removing it at its root, which, as stated above, will rear its ugly head in a matter of time. Additionally, you will have lost whatever changes to your site in the period between the current date and the date of your previous backup pre-hack—fingers-crossed your backups go back that far. Needless to say, its not a fun situation.

Why is Now the Best Time To Move on? How Come You Stuck With it for So Long?

You have to remember that the major issues that we speak about today were relatively minor for a long period of time as there weren’t nearly as many automated malicious bots and performance wasn’t a major topic of discussion as web frameworks and the devices that surfed the internet were much slower than they are today. As time passed, modern web languages and the devices we all have in our pockets advanced greatly as did the paradigm of user experience which shifted towards performance. Google really accelerated this sentiment by increasing the weighting of its rankings based on speed and continues to do so with frequent updates to their search algorithm.

An Article Regarding Google's Search Algorithm Updates

However, the biggest reason that most of the development community has stood by WordPress for so long is there was no realistic/practical alternative. Don’t get me wrong, there have been many platforms that have attempted to dethrone it but they always came with some sort of major compromise and the ones that seemed like they had a chance were in their infancy which was too risky of a proposition as they could be gone tomorrow leaving the customer with an abandoned platform. So, for all of its flaws, WordPress was the best option for years as it provided the best blend of ease of use, a deep developer pool, active open source community, and low development costs.

What Are You Recommending Now?

Today, we believe we have come to a point where WordPress alternatives have finally tipped the scales. Our CMS of choice is a platform called Statamic. Statamic is built using a modern framework (Laravel) that is lightning fast, is practically unhackable, has most of the features that WordPress requires a plugin for are already built in, and is incredibly easy to use. If you look at the backend of Statamic, the interface will feel immediately familiar to anyone that has some experience with WordPress. That said, no platform is perfect and we don’t believe Statamic is right for every situation, for instance, if you have an eCommerce site, we would actually recommend you use a platform such as Shopify or Big Commerce as Statamic does not have eCommerce capabilities out of the box. However, outside of eCommerce capabilities, we believe it to be a worthy alternative for the majority of WordPress site owners. For those interested in learning more about how Statamic compares to WordPress, they have an entire page on their website on this very topic:
[https://statamic.com/vs/wordpress.]

The Backend of Statamic - A Familiar, Intuitive Interface
Conclusion

If you currently have a WordPress website and are interested in Statamic, we can help! Good news, it doesn’t need to be a complete site overhaul. We can take exactly what you have and migrate it over without you having to start from scratch.