Round Up: 18 Free Plugins to Help Troubleshoot and Debug WordPress

I’ve written numerous tutorials explaining how to troubleshoot WordPress, plugins, email, and more. When investigating issues, diagnosing problems, and hunting bugs, troubleshooting is a critical core skill for any web developer. To help readers level up their tool belt, here’s a quick round-up of free plugins to help troubleshoot any of your WordPress projects.

Plugins to troubleshoot & debug WordPress

There are TONS of great troubleshooting plugins available at the WordPress.org Plugin Directory. Some of these plugins you’re probably familiar with, others are newer with their own unique features. While nobody is gonna need all of these plugins, it is comforting that there are so many to choose from. So you can find the best tools for whatever inspecting or debugging is needed. Plus all of these plugins are open source and 100% free. So without further ado..

BugFu Console Debugger
Handy plugin that enables logging of PHP directly via the browser console. Can be a huge time saver for developers.
Code Profiler
Measures the performance of your plugins and themes at the PHP level. Finally a replacement for the once-great P3 Profiler.
Debug
Handles the configuration of debug and other variables via wp-config.php. So you don’t have to edit the file manually.
Debug Bar
Adds a debug menu to the admin bar that shows query, cache, and other debugging information. Super useful tool for analyzing performance.
Debug Info
Provides important details about your WordPress operating environment. Easy way to get PHP configuration (via phpinfo()).
Debug Log Manager
Provides all sorts of tools for managing your site’s debug logs and more. Another massive time-saving tool.
Debug This
Displays lots of details about your WordPress site via the admin bar. Reveals “under the hood” what’s happening on each page.
Log HTTP Requests
Incredibly useful plugin for measuring and logging outgoing HTTP requests. One of my favorite plugins when developing.. other plugins :)
Plugin Detective
Holds your hand through the process of troubleshooting your site. Could be super useful depending on your workflow.
Query Monitor
Enables debugging of database queries, PHP errors, hooks, and much more. Hands down one of the best plugins for debugging WordPress.
System Dashboard
Monitors WordPress components, processes, server hardware, software, and resource usage. A must-have for serious WordPress developers.
Variable Inspector
Enables you to inspect various PHP variables via the dashboard in the WP Admin Area. Huge time-saver when working with PHP variables.
WP Console
Adds PsySH runtime developer console, interactive debugger and REPL. Write code and view the output right in your browser.
WP Crontrol
Enables you to view and control what’s happening in the WP-Cron system. Excellent plugin and highly recommended.
WP Debug Log
Enables you to check the debug log from the dashboard and optionally send email notifications. Looks super useful for debugging with WordPress.
WP Debugging
Adds the requisite PHP constants to the wp-config.php file to enable debugging. So you don’t have to edit the file manually.
WPPerformanceTester
Measures performance of your WordPress site. Looks interesting and useful but hasn’t been updated in a while.
WordPress Hosting Benchmark tool
Tests the performance of your server and compares with results from other servers. A great tool for diving deeper into server performance.
Explore even more debug tools..
The WP Plugin Directory is loaded with many plugins for developing, troubleshooting, and debugging your site. Try a few searches and browse the results. All free and open source. Amazing.
Shouts out to the developers working to provide these free tools to the WordPress community. Your work is important and appreciated.

Note: WordPress plugins tend to change over time, usually for the better but not always. So to be safe, make sure to check the official homepage/docs for more details before trying any of the above plugins. If anything should or should not be on the list, please let us know so we can update the post. Thank you!

Props

Gotta give props here. I was inspired to put this round up together after seeing this post in David McCan’s Dynamic WordPress group on Facebook. Check it out for some interesting comments and more ideas for troubleshooting your WordPress-powered websites.

Cheers! 😎


What I Learned by Fixing One Line of CSS in an Open Source Project

I was browsing the Svelte docs on my iPhone and came across a blaring UI bug. The notch in the in the REPL knob was totally out of whack. I’m always looking to contribute to open source, and I thought this would be a quick and easy fix. Turns out, there was a lot more to it than just changing one line of CSS. 

Replicating, debugging, setting up the local environment was interesting, difficult, and meaningful.

The issue

I opened my browser DevTools, thinking I’d see the same issue in the phone view. But, the bug wasn’t there. Now this is a seriously tricky CSS problem.

💡 What I learned

If you’re using Chrome on iOS as your browser, you’re still using Safari’s renderer. From Wikipedia:

Chrome uses the iOS WebKit – which is Apple’s own mobile rendering engine and components, developed for their Safari browser – therefore it is restricted from using Google’s own V8 JavaScript engine.

This is backed up by caniuse, which provides this note on iPS Safari:

Screenshot of caniuse with a note saying the safari browser for iOS is tried to the operating system, so the numbers used are based on the OS version.

Now it’s clear why the issue wasn’t showing up on my machine but it was showing up on my phone. Different rendering engines! 

Reproduce the issue locally

I pulled down the project and ran it locally. I confirmed it was still an issue by running the local code in a simulator as well as on my actual iPhone. Safari on macOS has an easy way to open up DevTools instances of each one.

Screenshot of the Safari Develop menu expanded with the Simulator option highlighted in blue.

This provides access to a console just like you would in the browser but for iOS Safari.  I’m not going to lie, Apple’s developer experience is top notch (see what I did there? 😬).

I’m able to reproduce the issue locally now.

💡 What I learned

After pulling down the Svelte repo and looking around the code a bit, I noticed the UI and SVGs were being pulled in via a package called @sveltejs/site-kit. Great, now I need my local version of site kit to get pulled into svelte/site so I can see changes and debug the issue.

I needed to point the node_modules in Svelte’s package.json to my local copy of site-kit. This sounded like a Symlink. After looking through the docs without much luck I Googled around and stumbled upon npm-link. That let me see what I was doing!

I can now make local changes to site-kit and see them reflected in the Svelte project.

Solving the issue

Seriously, all this needed was a one-line change:

border: transparent;

But locating where that one line should go was not as straightforward as you’d think. Source maps on the project are still a little rough around the edges and are showing this CSS coming from the Nav.svelte component when it was really coming from another file. That would be another great way to contribute to the project!

Then you search around and learn that this is being handled and you learn a little more about how it’s done. Everything now looks great on mobile and desktop.

That’s all it needed!

Let’s rewind

What started as a quick, one-line change became a bit of a journey. I had to:

  • Run the project and component repositories
  • Learn about system linking
  • Contribute documentation about lining to site-kit
  • Learn about different browser renderers
  • Learn how to emulate an iOS Safari browser
  • Learn how to get access to its debugger
  • Find the issue when source maps weren’t working correctly
  • Fix the issue (finally!)

Working on your own, you normally don’t get to deal with issues like this, or have a large complex system you need to build a mental model of and learn. You don’t get to learn from maintainers. Most importantly, you don’t see all of the hard work that goes into building a popular technical product.

When I submitted this idea to CSS-Tricks. Chris said he had recently dealt with a similar situation. Difficult learning is durable learning. Embrace the struggle.

Never stop learning

I grabbed another issue from the Svelte project and now I’m learning about CSSStyleSheet because there’s another issue (I think), with how Safari handles keyframe animations within stylemanager.ts. And so the learning continues down paths I never would have treaded in my day-to-day work.

When something breaks, enjoy the journey of learning the system. You’ll gain valuable insights into why that thing broke and what can be done to fix it. That’s one of the awesome benefits of contributing to open source projects and why I’d encourage you to do the same.


The post What I Learned by Fixing One Line of CSS in an Open Source Project appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

How to Get Redis-cli Without Installing Redis Server

I probably spend more time than most in  redis-cli because I find it invaluable when I'm writing software or getting to know a new module. If I didn't have  redis-cli , understanding Redis' data structures and testing connections would be far more complicated, and I probably would've stopped using Redis long ago.

Redis-cli  by itself isn't that complicated — it's a REPL (read-eval-print loop) that speaks to the Redis server. However, getting this jewel of a tool is not as straightforward for many. The source for redis-cli is included in the Redis GitHub repository and is automatically compiled when you build Redis from source. But what happens if you can't (or don't want to) build Redis from source? It means you also don't have redis-cli, and building an entire database from source just to get access to the command-line interface (CLI) utility is overkill and sometimes not even an option.