What is WP_DEBUG for and how do I use it?

PHP normally only displays fatal errors in the browser, or doesn’t load any page content and gives you a “White Screen of Death (WSOD)” if it has a fatal error before the page can load. A fatal error is one in which something is so wrong in the PHP code that it cannot make sense of it to gracefully fail in the background. If I forget to add chocolate chips when making cookies, I still have a perfectly tasty dough. If I forget to add baking soda though, I end up with a flat, gooey mess.

WordPress has a few features built in to make it easier to see PHP errors while you are testing. You’d want to activate these while developing a new site, theme, or plugin to ensure that you are seeing any PHP errors that come up.

As mentioned in the last post on PHP Illegal Strings, there are a few failure types in PHP including warnings, notices, and errors. Turning on WP_DEBUG will allow you to see those failure types so that you can fix them in your code.

Activating WP_DEBUG

If you have access to all of the files of your WordPress install, you’ll want to edit the wp-config.php file, which is located in the root directory, meaning the same folder that has the wp-admin, wp-content, and wp-includes folders. You’re going to go into that file and add the following line of code near the bottom of the file, but before the stop editing notice:

define( 'WP_DEBUG', true );

/* That's all, stop editing! Happy blogging. */

If that line already exists but says false, change that to true. There can be other lines of code above or below this, but as long as it’s above the comment to stop editing, it’s in the right spot.

What did we do?

We’ve now told WordPress that rather than hide PHP errors, we want them to display while viewing the site. WP_DEBUG is a PHP constant, which by convention are written in all caps. We’ve used the PHP define() function to set the value of that constant to a boolean true. Note that we didn’t surround the word true in quotes, otherwise PHP would read it as a string.

Using WP_DEBUG also allows us to see any deprecated functions that are running on our site. Deprecated functions exist in WordPress but are no longer the standard way to perform a particular tas. As an example, long ago in WordPress history you would get the ID of a category in WordPress with the function the_category_ID(), but now the function to do the same in a better way is get_the_category().


There are some companions to WP_DEBUG that can be used to make it even more helpful. You may not always be able to easily see errors if they are loading behind content, or you may want to keep track of them over time to review later. Two other constants that are built into WordPress that can help are WP_DEBUG_LOG and WP_DEBUG_DISPLAY.


Setting up WP_DEBUG_LOG allows you to save all of the debug errors that are getting displayed to a file in your WordPress install. That file gets saved to wp-content/debug.log by default. Whenever an error occurs that WP_DEBUG would display, it will also get saved to that file with a timestamp of when the error occured.

To turn on WP_DEBUG_LOG you’ll want to define the following constant:

define('WP_DEBUG_LOG', true);

You don’t have to worry about creating the debug.log file if it doesn’t already exist. WordPress will do this for you automatically as soon as it has an error to log. So hopefully not right away!


By default, setting WP_DEBUG to true will display all errors on the screen in your browser, on both the visitor-facing frontend, and the admin-facing backend of your site. This is ok while you’re editing a site that isn’t live with other people using it, but you don’t really want those errors displaying to other site visitors. It will make the site look more broken than it is, and can even be a security concern.

If you want to use WP_DEBUG but don’t want to display errors to the screen, set the following constant:

define('WP_DEBUG_DISPLAY', false);

Again, if you don’t set that as false, it will default to true when debug is turned on. If you are setting it to false, you’re probably also setting WP_DEBUG_LOG to true, since otherwise you won’t see the errors on the screen or in a debug log.

If you want to passively log errors for review later on a live site, just in case any come up, you can combine the three definitions above to turn on debug mode, log errors, and stop them from displaying on the site. I recommend doing this if you don’t have anything else handling these error logs for you, which you’d probably know if you did.

// Enable WP_DEBUG mode
define('WP_DEBUG', true);
// Enable Debug logging to the /wp-content/debug.log file
define('WP_DEBUG_LOG', true);
// Disable display of errors and warnings 
define('WP_DEBUG_DISPLAY', false);

Continuing to Debug Your Site

The settings above display PHP errors, but they don’t actually do anything to fix them. You’ll need to handle that yourself. Still, they provide an invaluable source of information to determine why something is broken on your site. This won’t show all types of errors that could occur, since not all broken page or feature problems are PHP related.

What it does do is give you a good footing to begin the fun part of debugging: digging into code and squashing bugs as you find them. In this case the old proverb is true: Knowledge is Power.

WordCamp Atlanta 2019 – My Review

I’ve been attending WordCamp Atlanta since 2013, and it’s been one of my favorite annual WordCamp events. It is larger than WordCamp Orlando, with an average of 600 attendees to our 350, but it rarely feels large with the sensible layout of the venue and separation of spaces. Everything is in one building across two floors, and all of the rooms are near each other.

The ease of getting around, and the proximity of hundreds of WordPress people without a feeling of claustrophobia makes it an ideal setting for conversations. We call the space between sponsor tables and session rooms the “Hallway Track”, since it can be a valuable session space itself. I can talk with friends that I see a handful of times per year, or find out what other companies in the space are up to.

WordCamp Atlanta 2019 Sponsor Area

WordCamp Orlando 2019 is coming on 23-25 August!

Our call for speakers is open, and tickets go on sale soon. Learn more at orlando.wordcamp.org

My Workshop – Building a Plugin

Recently I’ve been having success at events teaching attendees how to build their own plugins and themes. I was under a new constraint this time, of offering my plugin workshop in a 50 minute time-slot as a lecture, where it’s been a two to three hour workshop in the past. Treating it as a lecture meant no hands on, one-on-one help, but it let me present the information at a comfortable speed.

The questions that I got, both immediately following my session and throughout the weekend, indicated that I was able to help some of the attendees. I was told by three separate people that they attended the getting started workshop the day before, and my lecture put that information in place for them in an understandable way.

I’m not always confident when I give presentations, as listening to myself drone on for more than a few minutes feels excessive to me, and I can only imagine what others think. Having thoughtful followups made me feel that I provided value.

Code for my workshop can be found on my Github.


WordCamps are a great place to learn more about WordPress, but also to learn about related topics, such as SEO and marketing, running a business, or developing applications. We hold a unique position in tech in that our tool serves users at all ends of the technical spectrum. The lower barrier of entry to starting your first WordPress site coupled with the flexibility and extensibility of the platform makes it an ideal way for people of various skills to interact on a common ground.

I only attended a handful of sessions other than my own, preferring to spend time in the Happiness Bar offering help, as well as the aforementioned conversation time. Here are a few of my highlights:

  • Getting confirmation from Tom McFarlin, a developer who I greatly respect, that WordPress can serve as an application foundation. I’ve wasted some time that I could have been working on a variety of projects wondering if I’m just trying to fit a peg into a WordPress shaped hole, forgetting that getting something done at all is better than an optimized nothing.
  • Being reminded by Adam Walker, co-owner of Sideways8, that routines, habits, and processes are key when it comes to managing your work life. I’m impressed with the number of projects that he handles while maintaining a balance that leans favorably toward family and personal life. Sometimes you just need to hear the same message in a new way or for the tenth time before it sinks in. I’m making some changes based on his presentation, which he shared on his site.
  • Getting some ideas on ways to automate my development workflow from Chris Wiegman, a personal friend and team lead at WP Engine. This is one of the places that I feel that I could improve most when it comes to my processes. Some of the tooling that Chris uses is beyond me currently, but I want to expand my toolset. Chris also shared his slides on his site.

The rest of the event

I got to hang out with lots of WordPress friends and meet a few new people this weekend. I try not to only talk to people that I already know, since that leaves out all of the people who would be good friends if I took the time to get to know them now. I also shared dinner, lunch, coffee breaks, and walks around town with fellow attendees.

The real value of these events for me is the personal connection, where I get to talk one-on-one with someone a step ahead of or behind me in the business and product building process. We’re all learning this as we go, and it’s good to be reminded that no one comes in with all of the knowledge, and no business starts fully-formed.

WordCamp Atlanta 2019 Tips and Tricks Boards

WordCamp Atlanta made these great boards for people to post tips and tricks around business, WordPress, and life. I wish I’d gotten a picture at the end of Sunday!

On the secondary value front, I won an IKEA gift card from the folks at GoDaddy Pro! I don’t usually enter contests at WordCamps, but I’m glad that I entered that one and was still in town during closing remarks. We’ve been talking about getting a new couch at home for a while, and this is the push to make that purchase happen.

A big thanks to SiteGround!

Finally, I want to thank SiteGround yet again for helping to sponsor my trip. I realize that I haven’t yet written a post on the SiteGround Ambassador program, which is something that I’m going to fix now.

I met three members of the SiteGround team that I haven’t yet had the chance to meet, spent some time at their booth, and discussed SiteGround services several times during the event. It’s very easy to do when the conversation comes up from whoever I’m talking to with general interest, and I don’t even feel like I’m giving a sales pitch. That said, I’d do a sales pitch anyway, since I truly enjoy the service and level of support.

SiteGround team at WordCamp Atlanta 2019
The SiteGround team is always a great WordCamp addition!

I also got to chat with Francesca Marano, the WordPress Community Manager at SiteGround. We chat online regularly, but in person opens up new space for the kinds of conversations that don’t regularly come up online. Again, these events are a great way to catch up and form deeper connection with the people who help make this community worth sticking around for.

I greatly enjoyed WordCamp Atlanta 2019, and look forward to another fantastic event in 2020!

PHP v7.1 and v7.2 Illegal Strings

An update to Yoast SEO v11.1 came out yesterday, causing a few site errors relating to illegal strings in PHP. It made me dust off this post to provide some detail on what that PHP warning is, why it is happening, and how it can be fixed.

Last year I updated all existing client sites that I could to PHP version 7.2, to replace versions 5.6 and 7.0, both of which reached their end of security update lifespans in December of 2018. The current plan for WordPress v5.2 is to drop support for versions of PHP below 5.6, which is targeted to be released on 7 May. If this goes well, the minimum PHP version will be bumped to 7.0 later this year.

We’re only a few weeks away from this change, and a lot of hosts have been informing users that their version will change, or that they should opt-in to update when they can. One issue is that there are some things that work in earlier versions of PHP that will now throw warnings, notices, and errors in newer versions. One of the ones that I had to contend with on a few sites recently was the “Illegal string offset” warning.

Warning: Illegal String Offset

Here’s a few warnings that appeared on a development version of a site that I was upgrading (file path removed for readability):

__Warning:__ Illegal string offset 'menu' in [file location] on line 13
__Warning:__ Illegal string offset 'post_types' in [file location] on line 25
__Warning:__ Illegal string offset 'post_formats' in [file location] on line 36

I’m noting that it’s a development environment, because I had WP_DEBUG set to true in my wp-config.php file, which I don’t do on live, production environments. Basically, I ensure that on a live version of a site I don’t have PHP errors/warnings/notices displayed, even if there are some that would otherwise display.

I took a look at that file, which was a configuration file for the theme being used. The relevant lines from that file are below:

 * Theme menu
$theme['menu'] = array(
    'Upload your fonts',

 * Post types
$theme['post_types'] = array(

 * Post formats
 * aside, gallery, link, image, quote, status, video, audio, chat
$theme['post_formats'] = array( 'gallery' );

Can you spot the issue? I didn’t immediately see it myself, as I saw things like $theme['menu'] and thought “how can that be read as a string? The braces clearly indicate that we’re setting an array key.

Explicitly Declaring an Array in PHP

What I didn’t realize was that we were missing something that’s necessary as of PHP v7.1.0: an explicit declaration of the variable $theme as an array. If you take a look at the PHP.net manual entry on PHP Array Syntax Modifying, you’ll see the following note:

Note: As of PHP 7.1.0, applying the empty index operator on a string throws a fatal error. Formerly, the string was silently converted to an array.

So there’s our issue, and with it, a lead on a solution: the theme never explicitly declared the variable $theme to be an array, and so it was assumed to be a string. Since it is no longer being silently converted, we have a warning being thrown.

Fixing the Illegal String Offset Warning

The solution in this case is to add a line to the start of that block of code where we explicitly declare our variable as an array. What that looks like is this:

$theme = array();

 * Theme menu
$theme['menu'] = array(
    'Upload your fonts',

By adding $theme = array();, we’re telling PHP, “yes, this is an array, please treat it as such.” It doesn’t have to try to guess what we mean, which newer versions of PHP no longer do anyway.

PHP v7.0+ also introduces strict typing, which is great for being even more explicit in your PHP coding. This makes the code more secure (people can’t put different data types in than you intend), and less liable to break (you will always know what type of data to expect). If you want to learn a bit more, Eric Mann wrote a short introductory post on the topic early last year.

PHP is getting better and better all the time, but this progress sometimes causes old code to break. While this is frustrating, it can also give you the opportunity to review old code with fresh eyes. It’s not always convenient to do this, but it can overall improve your site!

Fix Missing Leading Zeroes in WordPress Zip Codes

Recently, I helped a client import a large set of addresses into a location plugin for WordPress. The import mainly went smoothly, but we noticed some issues when searching in areas with zip codes leading with one or two zeroes. The addresses weren’t coming up as they should.

After examining some of the imported addresses, we realized that all of the leading zeroes were being stripped, and we could no longer search by those zip codes. I’m going to give a brief overview of why this happened, and how I solved it. Hopefully it helps if you need to make this kind of update to a WordPress database too!

Why is this happening?

Some programs “helpfully” strip leading zeroes from numbered cells, including Excel, Numbers, and Google Sheets. This means that 04102 in Portland, Maine becomes 4102, which isn’t a zip code in the US.

The same could happen upon import into the database, depending on how the import is done. In either case, I’m working with an import that’s already complete, as opposed to having caught this issue before the addresses were added to the site. I don’t want to remove all other relevant content just to import again and fix these zip codes, so I’m going to go directly to the database to solve the problem.

How to fix the missing zeroes

There are several ways to add the zeroes back, but most places that you search will suggest changing the datatype of the zip code column, which doesn’t help when it’s in WordPress where we can’t modify that when there is other info stored in the same place. Plus some zip codes have the full nine digit route number depending on where the data was taken from, and some are postal codes from Canada and other countries that don’t follow the same pattern.

In this particular case, we know what we’re looking for (postmeta with a key of wpsl_zip, and we know where it’s at (the wp_postmeta table). If you connect to the MySQL database through PHPMyAdmin or an external application you can run the following query to see how many zip codes stored have fewer than five digits:

Important: Always make a backup of your database before doing any of the changes below!

    `meta_key` = 'wpsl_zip' AND LENGTH(`meta_value`) < 5

What we’ve told the database to do, is to “select all rows from the wp_postmeta table that have a meta_key of ‘wpsl_zip’, and that have a meta_value of less than five characters in length”.

It’s important to ignore rows that already have a value of five or more characters, as LPAD will trim them to fit five characters otherwise. We don’t want that, just the ones that are too short.

The above will return all of the rows that match the query, so that we can review them and confirm that they are indeed the addresses that we want to update.

Now that we’ve identified how many there are (89 in this case), the following MySQL command will update those zipcodes using LPAD to add a left padding of 0’s until the meta_value is five characters. Values that are already five characters or larger are ignored.

    `meta_value` = LPAD(`meta_value`, 5, 0)
    `meta_key` = 'wpsl_zip' AND LENGTH(`meta_value`) < 5

You’ll see that the WHERE clause is the same, since we already confirmed that we had the right records to change before. What we’ve done differently with this query is to say that we want to make updates to the wp_postmeta table by setting the meta_value of the rows that we selected to have exactly five characters, and that if they have fewer than five characters, to left pad them with 0’s.


To review, the MySQL function LPAD works like this:

    "cell that we want to change",
    "final cell string length",
    "what to use to left pad the cell if needed"

I hope that helps save you spending the same time that it took me to find the problem that I had and to come up with a solution!

Setting up a Custom Palette in Gutenberg

While there’s been a lot written about the new editing experience that came out with WordPress v5.0 last month, I want to give a reminder of some of the neat features for end users. One of the best things about the new editor is that a theme or plugin can add or remove features from the editor with simple hooks, allowing you to craft an experience that fits your needs.

As an example, I have taken a few client sites that have embraced the new editor, and used their style guides to add their branding colors, fonts, and variants into the page editor. Now, when they want to add a block of content with a colored background or change the color of a button on a page, they have their palette of brand-approved colors already set to use. No need to remember hex codes or anything confusing!

Sounds great! How do I set up a custom color palette?

Default WordPress Editor Color Palette
Notice that the editor will warn you if your background and text colors aren’t high contrast. This makes it a bit easier to keep your content accessible!

By default the editor will have a palette of 11 colors, plus a color picker to get a different color. You can swap to a palette of your own by adding some code to your theme. Place the following in your functions.php file or where appropriate based on your structure. Next, we’ll modify it to fit our needs.

This code came directly from the Gutenberg Theme Support Handbook, a good resource for all WordPress developers.

function mytheme_setup_theme_supported_features() {
    add_theme_support( 'editor-color-palette', array(
            'name' => __( 'strong magenta', 'themeLangDomain' ),
            'slug' => 'strong-magenta',
            'color' => '#a156b4',
            'name' => __( 'light grayish magenta', 'themeLangDomain' ),
            'slug' => 'light-grayish-magenta',
            'color' => '#d0a5db',
            'name' => __( 'very light gray', 'themeLangDomain' ),
            'slug' => 'very-light-gray',
            'color' => '#eee',
            'name' => __( 'very dark gray', 'themeLangDomain' ),
            'slug' => 'very-dark-gray',
            'color' => '#444',
    ) );

add_action( 'after_setup_theme', 'mytheme_setup_theme_supported_features' );

There’s a lot of code there, but not a lot to break down. First, remember that after_setup_theme is a hook, on which you add the function mytheme_setup_theme_supported_features that you’re creating. In that function we’re using add_theme_support, a built in WordPress function, where we’re using editor-color-palette to set our palette up.

We’re adding an array of colors, and each element of that array is itself an array. Within those nested arrays we have the name of the color, which we’re making translatable with the __() function, and setting the textdomain of our theme. Change themeLangDomain to whatever matches your theme. This name is a descriptor for when you hover over it in the palette.

The slug is a string of how you’ll refer to the color elsewhere in your code. The color is the hexadecimal value of the color that you want in your palette. With the above code, you’ve got a new editor palette with four colors that you’ve set, along with the color picker.

Our custom WordPress editor color palette
Our four custom colors now appear, along with the color picker

Adding to Our Palette

There are a few more features of the editor color palette that I’d like to show off, including targeting blocks in CSS, Customizer set colors, and removing the color picker.

Using our Color Palette Selections in CSS

If you’re editing text with the color palette you shouldn’t have to make any other changes. But what if you want to use the color selection in something a bit more customized, or in your own block type?

The slug that we added to our colors in the example above lets us target for both background and text colors. We don’t even need to use the color set in the editor, but something custom to our needs. For example, you may want a specific background or text color when you use the strong magenta color. In that case, here’s the CSS that can target the classes added when we use that color:

.has-strong-magenta-background-color {
    background-color: #313131;

.has-strong-magenta-color {
    color: #f78da7;

Setting a Color Palette with the Customizer

The twentynineteen theme that comes with WordPress has a custom palette that includes colors that can be set in the Customizer. This means that you can set your own primary and secondary color from the WordPress dashboard, without changing code!

		'name'  => __( 'Primary', 'twentynineteen' ),
		'slug'  => 'primary',
		'color' => twentynineteen_hsl_hex( 'default' === get_theme_mod( 'primary_color' ) ? 199 : get_theme_mod( 'primary_color_hue', 199 ), 100, 33 ),
		'name'  => __( 'Secondary', 'twentynineteen' ),
		'slug'  => 'secondary',
		'color' => twentynineteen_hsl_hex( 'default' === get_theme_mod( 'primary_color' ) ? 199 : get_theme_mod( 'primary_color_hue', 199 ), 100, 23 ),

The new color is now set as the output of a function that will get a theme mod, if you’ve modified the color. If not, it’ll return the default, ensuring that there’s always a color set.

The WordPress customizer with a primary color selection

Removing the Color Picker

You can also do things like disable the color picker, to ensure that users can only use the colors that you have preset for them. Doing so requires just one line of code in your functions file:

add_theme_support( 'disable-custom-colors' );

With that single line we’ve made it so the beautiful design that we’ve worked so hard to craft and the branding style guide that we have had to constantly review will always be set the way that we want.

Wrapping Up

As you can see, there’s a lot that you can do to change how users edit content in the Gutenberg editor, without having to add a tremendous amount of code.

This is only the beginning, and even more developer and user friendly features like this already exist or are coming to the editor and the rest of WordPress. I’m excited for the new opportunities this gives to all stakeholders of a site, from designers and developers, to admins and editors, all the way to customers and visitors. Let’s keep making WordPress better for everyone!