While doing back-end development, I like using the Ray app as a lightweight replacement for a more involved Xdebug extension for PHP. Instead of tracing everything in the request, I only send the relevant pieces of information to the desktop app. That’s what I need in 95% of cases anyway.
It works similarly to console.log() or console.table() in the browser and its DevTools. As I knew that Ray does support debugging in a browser too, I decided to dive in and start using it.
Single tool to debug it all.
The official docs are super minimal, covering only the installation of the node-ray package.
Here is the repo (click the image):
I encourage you to read the readme file of the repo to understand how to use it. Below I will cover my specific case and my approach.
Using node-ray for WordPress debugging
In my local WordPress development, I use /wp-content/mu-plugins to reconfigure or tweak something quickly. I usually create one file per a big chunk of functionality or set of plugins. For example, when I was doing WPForms development, I had debug-wpforms.php, when I did WP Mail SMTP development – debug-smtp.php and so on. It’s very easy to then manage all those various code snippets and configuration arrays if any.
With node-ray, I went with the same route and created a new browser-ray.php file there, with this code:
<?php
add_action( 'wp_head', static function () {
?>
<script src="https://cdn.jsdelivr.net/npm/node-ray@latest/dist/standalone.min.js"></script>
<?php
}, - 42 );Code language: PHP (php)I used the negative priority to bump my debugging script up in the loading order of any CSS/JS that will be output using the wp_head hook.
And now I can call ray() (or window.ray() depending on your JS structure) to dump debug information into the Ray app.
Upsides
That’s a matter of personal preference, really.
My desktop setup consists of a big 27″ monitor in the center, a small 13″ laptop screen on the right, and a small 10″ iPad Air screen under the 27″ screen. I call this iPad screen a “debugging screen” and I usually put there (using the MacOS Continuity feature) either Ray or Tinkerwell app (or both).
So technically this small screen is located between by keyboard and the 27″ screen, very easy to see and use, but still small enough not to steal my attention.
Then, you use the same tool I already know and love for both back-end PHP and front-end JavaScript debugging.
Downsides
There are a couple of downsides that may be possible to fix somehow, but I haven’t yet invested time in doing that as they are not bothering me that much.
- It looks like
node-rayopens the second Ray window. So your PHP and JSray()calls will be dumped in 2 different Ray instances. At least it happened like this for me several times. Maybe I can redefine that using global Ray config, not sure yet. - When
node-rayreports a place where thewindow.ray()was called, it will always point tounknown-file.js:1. So you can’t click thefile_name.php:42to open your IDE in that place where it was called.
The 1st problem is not a deal breaker as I can just group 2 windows side by side on my iPad debugging screen:

The 2nd problem is somewhat disappointing, but as I don’t excessively use ray(), I don’t have problems finding where I put the ray() call, especially given that I quite often use it in combination with the label() method:
ray( $variable )->label( 'do_something()' );Code language: PHP (php)
Leave a Reply