Warnings and Errors in Local

Are you wondering why a site that is working perfectly on a remote server is suddenly looking very broken when you import it into Local?

Because Local is meant to be a development environment, one possible reason for the site to look broken is that Local is set to be much noisier about issues it encounters.

By default, Local is set to show both PHP errors AND warnings. This can be confusing for some users since by default, most remote servers only show PHP Fatal errors, but suppress warnings. When a site is imported into Local, the warnings that are being suppressed on the remote server are now showing on the Local site, and make the local site appear broken.

It’s important to remember that the Local site is probably not broken — it’s just Local giving you more info about potential problems in the form of PHP warnings.

As an example, this screenshot shows the same site on Flywheel’s servers (on the left), and within Local (on the right).

On the left, a PHP warning isn’t displayed on a remote site that has warnings hidden. On the right, that same PHP warning is showing a big orange box that is coming from xDebug.

Why is this happening?

There are two reasons why Local looks broken compared to the remote site:

  1. Local has more verbose error reporting enabled, which means it will show warnings and notices in addition to more serious errors.
  2. Local uses Xdebug to make those messages easier to read (and louder!)

The reason that Local is configured this way is because it is a development tool. By seeing notices and warnings early, you are in a position to fix things before they become big problems on the production site.

You can toggle Xdebug on or off easily from the Local app. From your Local app select the site you’d like and the toggle option will be at the bottom of that page.

Toggle on or off Xdebug.
Toggle on or off Xdebug.

PHP Backstory: Error Reporting Levels

It’s a fact of life that sometimes, code generates errors.

PHP can be configured to display a wide spectrum of those “errors”, from really bad ones (FATAL) to those things that only a nit-picky computer would complain about (NOTICE).

Newer versions of PHP, and many production environments will default to a setting that looks something like this:

E_ALL & ~E_DEPRECATED & ~E_STRICT & ~E_NOTICE

Which you can read in plain language as saying:

Ok, PHP, show me all your “errors”, unless they are a “Deprecated”, “Strict”, or “Notice” error.

Because Local is a development environment, it has a very different setting in place:

E_ALL & ~E_DEPRECATED

Again, you can read that in plain language as saying:

PHP, show me all your “errors” except for “Deprecated” ones.

There are definitely different mixes of values you can use, but that should get you understanding the general backdrop of how PHP displays errors.

If you want to know more, you can always take a closer look at some of the resources on the PHP Manual:

Ok Great, but How Do I Fix My Site?

The best thing to do is to read each message and try to fix things. This might include fixing code or updating plugins.

But sometimes, you’re not in a position to fix those underlying issues right away, and you just want to work on the site as it is on the remote server.

The next best thing is to adjust the error reporting to more closely match what a production environment looks like.

Quick-fix in wp-config.php

The easiest way to hide those warnings and notices is to disable error reporting in the wp-config.php file:

ini_set('display_errors','Off');
ini_set('error_reporting', E_ALL );
define('WP_DEBUG', false);
define('WP_DEBUG_DISPLAY', false);

There’s a bit more here than just PHP settings, specifically, we’re also disabling the errors that WordPress will be showing as well.

Adding configuration settings to the wp-config.php file to prevent PHP warnings from showing.

Super custom php.ini.hbs

Updating the wp-config.php file is pretty quick, but you might want a little more control over the actual settings that PHP is using as opposed to editing the WordPress configuration file.

To do this, you’ll want to adjust the PHP settings that Local uses when starting the site. You can edit those settings by navigating to the php.ini.hbs file for the site:

sitename/conf/php/php.ini.hbs

Note that this is a template that Local uses — it isn’t the actual php.ini file. This is because different settings behave differently on different Operating Systems. In order update the php.ini file for a site in Local, you need to make those adjustments and then restart the site so that Local can re-compile the php.ini.hbs file.

To update the error reporting settings for the site follow these steps:

  1. Stop the site in Local
  2. Update and Save php.ini.hbs
  3. Start the site to have Local use the new settings
Updating the php.ini.hbs file and restarting the site is another way of preventing warnings and errors from displaying.

You can find more info on all the various adjustments that can be made to this configuration file by looking at PHP’s documentation on it: