Debugging
There are many levels to how we can debug our code. The following sections outlines some of these methods from simplest to most complex.
Debugging in Twig
In our current development we have access to dump() from within a twig file which is called like so:
or to dump the entire context
This will provide the equivalent of var_dump(), but is formatted in an easier to read manner.
Commented Twig Includes
<!-- Begin output of "partials/navigation.twig" -->
<nav class="navigation">...</nav>
<!-- / End output of "partials/navigation.twig" -->
This only active when WP_DEBUG is set to true in wp_config.php, but it gives you the ability to see what code is from where when inspecting the rendered page.
Twig Helper Functions
Some Twig helper functions are provided from og-core to log dumped variables in the console and assiste with debugging
log_json($data) // console logs data passed in as json
get_pattern('pattern-name') // returns the pattern template
json($data) // returns json encoded data
debug($data) // adds data to query monitor
log_warn('string') // console warn
log_error('string') // console error
log_success('string') // console success
// Example Usage
{% set data = {
'foo': 'bar',
'bar': 'baz'
} %}
{{ log_json(data) }}
// In the console:
// {
// "foo": "bar",
// "bar": "baz"
// }
Debugging in JavaScript
We can use console.log() in JavaScript to output to the console. This is the equivalent of var_dump() in PHP.
We can also use console.table() to output an array or object as a table in the console. This is the equivalent of print_r() in PHP.
Utilize the browser's developer tools to view the console.
Debugging in PHP
We can use var_dump() and print_r() in PHP to output to the browser. This is useful for debugging in WordPress.
A better implementation has been added that matches the twig dump() functionality. This is called dump() and is called like so:
It functions the same was as it does in twig, formatting the var_dump() output in an easier to read manner.
Xdebug
Xdebug is a PHP extension which provides debugging and profiling capabilities. It should be installed in vscode. There is a toggle to turn it on and off from within the Local by Flywheel interface.
By going to the Tools section of the interface you can also create a custom vscode launch file for debugging that specific project. This will create a .vscode directory in the root of the project with a launch.json file. This file is ignored by git. Alternatively, you can set global xdebug settings in your ~/.vscode/launch.json file.
Xdebug in vscode
When Xdebug is enabled in vscode you can use the debugger to step through the code.
This can be done by setting breakpoints in vscode and then running the debugger. You can also inspect variables and their values at each step.
This is a more advanced topic and method than using var_dump() or print_r() to debug. But it is very helpful when you are trying to find a bug that is not obvious.
Profiling in PHP
Profiling is the process of measuring and analyzing the performance of a program in order to identify and eliminate bottlenecks.
This is the process to setup profiling in our current development environment.
Go to the folder directory of the website and locate the conf/php/php.ini.hbs file.
Locate the [xdebug] section if it exists and modify it to match the following:
[xdebug]
{{#if os.windows}}
zend_extension = php_xdebug.dll
{{else}}
zend_extension = {{extensionsDir}}/xdebug.so
{{/if}}
{{#if xdebugEnabled}}
xdebug.mode=debug,develop,profile
{{else}}
xdebug.mode=off
{{/if}}
xdebug.client_port=9003
xdebug.start_with_request=trigger
xdebug.discover_client_host=yes
NOTE: You will need to restart the site server for these changes to work.
Cachegrind files will be saved to the /tmp directory. You can view these files with a tool like Webgrind.
This is an advanced topic and will be expanded upon at a later time. For now, this is just a reference for how to setup profiling in our current development environment.