How to Identify, Debug, and Improve Messed Up WordPress Code

Debugging and improving upon a messed up WordPress project is quite a challenge.

A common misconception in the WordPress world is that a website would work “just fine” by setting up a few WordPress plugins combined with a premium theme.

Sure – you can also set up a massive enterprise platform that consumes 8GB of RAM for the first load but it doesn’t make it efficient or the right choice for a successful project.

Building a website that is supposed to scale and grow with time by bundling a few dozen plugins in it is “doing it wrong”.

WordPress Plugins Are Generic

By design, both the majority of WordPress themes and plugins are generic. They aim for solving as many problems for a large suite of industries providing various options for each and every use case.

And that makes sense from a business standpoint, right?

At the end of the day, you end up with a cumbersome and messed up code base. Your product likely utilized just a small percentage of all classes and functions, options and settings provided by all of the plugins installed on your website.

A good example are sliders, galleries, visual builders and other complex engines. They usually support tons of options that could fit every need. But you end up using 1% of those options. The rest is technical debt that you need to deal with later on. Debugging 50,000 lines of code and refactoring your extensions while using a fraction of those is not an easy feat.

Not to mention security, of course.

The Revolution Slider Security Leak

100,000+ compromised WordPress websites

A couple years ago, Revolution Slider (one of the most popular slider plugins) had a major vulnerability affecting over 100,000 websites out there. It was embedded in a bunch of premium themes (over 1,000 ThemeForest themes) which were all affected at once.

After researching the compromised sites, Sucuri found that SoakSoak’s vehicle of attack is the critical security vulnerability that was discovered in the Slider Revolution plugin and made public in September. At that time, Envato identified more than 1,000 themes sold through its marketplace that were potentially affected by this particular vulnerability.

On top of that, plenty of websites have purchased the plugins separately.

Even if a vendor releases a security fix soon, there are a few major considerations to keep into account:

  • Hackers still have an open vector letting them brute force over 100K websites before the official update.
  • Plenty of users won’t install their plugin right away.
  • Some website owners/freelancers may update the plugin which may result in a major regression on the website (forcing them to revert for the time being).
  • Website owners who have purchased a premium theme won’t receive an update right away. The theme authors should ship a new version sometime after the plugin has been updated, which may take weeks.
  • Some website owners have wrongfully customized the code of their code theme and can’t update as it will override their changes.

That’s what may lead to a ruined reputation and shameful downtime for a small business running a poorly integrated website.

Bloated WordPress Project Maintenance is a Nightmare

Maintaining a bloated and messed up codebase of over 100,000 lines of extra code ain’t easy – especially when it’s not your own code and you have to cater for all ongoing updates in time.

That’s a liability for customers and may impact the website in numerous ways, such as:

  • Complete downtime for the website.
  • A broken section or a set of pages on the site.
  • Broken logic that’s not trivial to intercept and debug (except for users, of course).
  • Messed up layout in certain places.

It’s really annoying when a certain component misbehaves and it may take you a while to notice that, let alone get it fixed. Especially when it happens due to a set of features that you’re not using at all (interfering with the life cycle of WordPress).

This makes the overall maintenance expensive, time-consuming, and resulting in poor user experience for the client.

Web Hosting Costs Go Up

The larger the active codebase (activated plugins, a heavy theme), the longer it takes for the website to load everything in time before rendering a result for the client.

That’s tricky at first, but it is not an apparent problem until your website starts generating a good volume of traffic.

Actually, that’s not a problem either if your website loads in 8–10 seconds and Google decides to penalize it for being slow and for the high bounce rates from customers leaving the site before it loads completely.

Either way, a heavy code base loading tons of scripts and styles and generating hundreds of database queries per user would eat up resources quickly, and won’t be able to sustain concurrent users browsing the site at the same time. This means higher hosting costs.

Debugging and Refactoring Can Save Hosting Costs

We’ve had a client generating just about 250,000 page views a month paying $1,500 a month for hosting. After working on refactoring improvements for a few months, we’ve migrated the site to an alternative plan that currently costs about $400/mo for the production environment (excluding the staging VPS and a few other service costs).

And one of our clients generating over 15,000,000 page views a month has been hosted with Pagely for less than $2K/mo even though they’re paying for a high availability managed platform with redundant storage, load balancers, failover servers and more. This could have been brought down to $1K/mo if it wasn’t for the safety nets.

Their previous hosting fee was $4,500. The hosting company wanted to upgrade them to the next plan at over $6,000 a month.

In the long run, a poorly coded platform may cost thousands of dollars a month in additional hosting expenses.

Poor User Experience

A slow website would not be something that potential customers would be happy to browse. Especially if it causes other regressions on mobile, messed up screens, misbehaving logic due to other plugins causing conflicts with one another.

A blocker that could easily be avoided with a properly built platform in the first place.

3rd Party Services Can Interfere

Let’s not forget about 3rd party service integrations within your WordPress website.

Modern websites rely on various SaaS solutions for their digital platforms:

  • A marketing automation software
  • CRM
  • Lead generation tools like Optin Monster
  • Landing page builders
  • Booking platforms
  • Related posts/news engines
  • External image resizing/compressing
  • A comprehensive header bidding ad management system

External services are usually integrated with one of the following ways:

  1. Hooked into the standard life cycle of rendering a WordPress page.
  2. Loading JavaScript for all visitors (or other assets such as images, CSS, fonts).

Needless to say, they are supposed to work fine with your theme, plugins, content, hosting environment, user control capabilities, and everything in-between.

They add up to the load time of the platform and may filter existing data, causing discrepancies with the standard load of the website.

No, you don’t have to avoid 3rd party services at all cost. But consider debugging at all times – as this is a separate entity within your web application.

And debugging is one of my favorite WordPress topics – I even gave a training video during WordSesh fixing a WordPress Core bug and submitting a corresponding patch:

There are two possible alternatives that would solve most of the incompatibility, security, and performance problems for a poorly coded WordPress website.

1. Build a Clean and Solid WordPress Platform

Considering that WordPress is fairly stable and works fine even for projects generating hundreds of millions of page views a month, using it as a foundation framework for starters makes sense. That is, if you’re utilizing most of its functionality (being a CMS at its core).

Everything else should be planned carefully and deliberately.

  1. If you’re using off-the-shelf plugins, make sure that they solve small problems without being a Swiss Army Knife. It doesn’t make sense to use something that solves 100 problems if you only face 1 or 2.
  2. Conduct a detailed code review. Test the plugin on a clean install. Benchmark. Debug it. Write down the number of HTTP requests in the front-end and key back-end pages. Track the number of database queries. Take a look at what’s stored in the database and whether it’s something acceptable.
  3. For example, some plugins store metadata by adding a dozen meta keys in the postmeta table. This is adding up quickly by publishing hundreds of posts.
  4. Others are serializing data. This is harder to edit, search, and filter through.
  5. Or create other database tables for solving that problem.

You should be familiar with the business case and what works in each scenario.

Normally, you’d go for a custom WordPress theme built from scratch or a base theme that doesn’t load numerous sliders or page builders. The cleaner and simpler it is, the better.

The rest of the business logic should be developed from scratch – solving the business problem in a performant manner.

2. Slowly Analyze, Debug, and Refactor the Codebase

Go over the existing platform and analyze all of the key areas that need a solid improvement:

  • Getting rid of plugins that are not really required and could be replaced with 20–50 lines of custom code
  • Identifying large plugins that can be replaced with a lightweight version
  • Replacing a heavy premium theme with a lighter starter theme
  • Identifying heavy plugins causing performance problems in all areas
  • Analyzing plugins that may conflict with each other

Once the initial analysis is done, write a brief development and deployment plan about solving each of those problems step by step. Causing regressions and missing certain areas is quite possible so this needs to be coordinated with the client as well.

Improving the platform gradually would let you focus on stability, performance, and security.

You can use GT Metrix or another performance scanner in order to identify key areas that need improvement – and take it from there.

Ideally, you can focus on preparing an automated testing framework including unit tests, automated UI tests (screenshot tools that can compare website pages across deployments) and other tools that could ensure that your website behaves as anticipated across updates.

In any case, installing a few random plugins is a recipe for disaster unless you plan the process properly and always put performance and stability as a high priority.

Action Plan for WordPress Website Owners

Plan your development cycle upfront.

Best-case scenario, start with a proper engine on top of a standard WordPress installation. Pick your plugin wisely and don’t go for a bloated and heavy WordPress theme.

Keep your 3rd party services to a minimum. That includes additional layers that you don’t understand well (a yet another random CDN provider or a web-application firewall).

If you can’t afford a decent solution at first, make a note on all compromises you make at first.

More importantly, remember this:

You have to account for data migrations, updates in user experience, possible regressions in existing content, minor performance leaks that may add up and break a specific feature (or bring the whole website down).

Once you generate some decent traffic, hire a professional WordPress development agency for a code review gig or a WordPress retainer. Let professionals analyze your code base. Compare your initial notes with theirs and design an action plan for initial cleanup and ongoing technical debt payoff.

After all, your platform is capable of handling tons of traffic. But even simple mistakes may affect the entire WordPress system.

One thought on “How to Identify, Debug, and Improve Messed Up WordPress Code

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.