Welcome to the official blog for the WordPress Support team.
Need help with a WordPress issue? You can find help with your WordPress problem by posting in the support forums or asking on the #wordpress IRC channel.
Want to get involved?
Answering a question in the support forums or on IRC is one of the easiest ways to get started. Everyone knows the answer to something!
We have a detailed handbook to help contributors learn how to work with the forums and IRC.
Weekly Meetings
As well as discussing support issues here on the blog, we use Slack for group communication.
Our weekly meeting is held every Thursday 17:00 UTC, with the first meeting of the month being office hours, and the next will be at Thursday, 17:00 UTC(your time zone) in #forums on SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..
Debugging PHPPHPPHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. code is part of any project, but WordPress comes with specific debug systems designed to simplify the process as well as standardize code across the coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress., plugins and themes. This page describes the various debugging tools in WordPress and how to be more productive in your coding as well as increasing the overall quality and interoperativity of your code.
NOTE: While it is not mandatory to account for WP_DEBUG in plugins and themes it is highly recommended that pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and theme developers use WP_DEBUG mode while working on code they plan to release publicly. If your plugin or theme is not compatible then the errors, notices and warnings it throws will make it impossible for other developers to use your plugin/theme while they have WP_DEBUG enabled and your theme will not be eligible for promotion via the official WordPress tools.
WP_DEBUG is a PHP constant (a permanent global variable) that can be used to trigger the “debug” mode throughout WordPress. It is assumed to be false by default and is usually set to true in the wp-config.php file on development copies of WordPress.
Note: The true and false values in the example are not surrounded by apostrophes (‘) because they are boolean (true/false) values. If you set constants to ‘false’, they will be interpreted as true because the quotes make it a string rather than a boolean.
It is not recommended to use WP_DEBUG or the other debug tools on live sites; they are meant for local testing and staging installs.
Enabling WP_DEBUG will cause all PHP errors, notices and warnings to be displayed. This is likely to modify the default behavior of PHP which only displays fatal errors and/or shows a white screen of death when errors are reached.
Showing all PHP notices and warnings often results in error messages for things that don’t seem broken, but do not follow proper data validation conventions inside PHP. These warnings are easy to fix once the relevant code has been identified, and the resulting code is almost always more bug-resistant and easier to maintain.
Enabling WP_DEBUG will also cause notices about deprecated functions and arguments within WordPress that are being used on your site. These are functions or function arguments that have not been removed from the core code yet but are slated for deletion in the near future. Deprecation notices often indicate the new function that should be used instead.
WP_DEBUG_LOG is a companion to WP_DEBUG that causes all errors to also be saved to a debug.log log file inside the /wp-content/ directory. This is useful if you want to review all notices later or need to view notices generated off-screen (e.g. during an AJAX request or wp-cron run).
WP_DEBUG_DISPLAY is another companion to WP_DEBUG that controls whether debug messages are shown inside the HTMLHTMLHTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites. of pages or not. The default is ‘true’ which shows errors and warnings as they are generated. Setting this to false will hide all errors. This should be used in conjunction with WP_DEBUG_LOG so that errors can be reviewed later.
SCRIPT_DEBUG is a related constant that will force WordPress to use the “dev” versions of core CSSCSSCSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. and JavascriptJavaScriptJavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. files rather than the minified versions that are normally loaded. This is useful when you are testing modifications to any built-in .js or .css files. Default is false.
The SAVEQUERIES definition saves the database queries to an array and that array can be displayed to help analyze those queries. The constant defined as true causes each query to be saved, how long that query took to execute, and what function called it.
define('SAVEQUERIES', true);
The array is stored in the global $wpdb->queries.
NOTE: This will have a performance impact on your site, so make sure to turn this off when you aren’t debugging.
The following code, inserted in your wp-config.php file, will log all errors, notices, and warnings to a file called debug.log in the wp-content directory. It will also hide the errors so they do not interrupt page generation.
// 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);
@ini_set('display_errors',0);
// Use dev versions of core JS and CSS files (only needed if you are modifying these core files)
define('SCRIPT_DEBUG', true);
There are many well-written plugins that handle debugging in WordPress and show more information about the internals, either for a specific component or in general. Some examples of such plugins are Debug Bar with Debug Bar Console, Log Deprecated Notices and Total Security.
Before WordPress 3.1, the STYLE_DEBUG constant behaved similarly to SCRIPT_DEBUG but affected CSS files rather than JavaScript. In 3.1 the two constants were merged into SCRIPT_DEBUG, which now affects both types of minified file.