0

I'm trying to debug a WordPress-installation using Xdebug and PhpStorm.

If I write this in the top of functions.php:

[line 1]: <?php
[line 2]: $test = '1234';

And set a breakpoint on line 2, and run 'Debug functions.php', then I hit that breakpoint and I'm able to debug that breakpoint in PhpStorm. So far so good!

But if I move it down, to the bottom of functions.php, and do the same thing, then I get the error:

PHP Fatal error: Uncaught Error: Call to undefined function add_action() in /path/to/project/wp-content/themes/my-theme-name/functions.php:44
#0 {main}
Stack trace:
thrown in /path/to/project/wp-content/themes/my-theme-name/functions.php on line 44

Line 44 looks like this:

[line 43]: include_once( __DIR__ . '/classes/AdminNotice.php' );
[line 44]: add_action('admin_notices', [new AdminNotice(), 'displayAdminNotice']);

I've also tried debugging other files.

Like page.php. Same thing - if I add my demo-code (and breakpoint) in the top, then it works. But if I move it to the bottom, then it stumbles over get_header(). The error:

PHP Fatal error: Uncaught Error: Call to undefined function get_header() in /path/to/project/wp-content/themes/my-theme-name/page.php:6
Stack trace:
#0 {main}
thrown in /Users/zethodderskov/Code/Greenmind/V2-1__local/app/public/wp-content/themes/my-theme-name/page.php on line 6

And line 6 looks like this:

get_header(); ?>

And if I set a breakpoint in an imported class, then it doesn't stop at that breakpoint (even though I'm 100% sure that it reaches that part of the code).

This may be because it's reached during a POST-request. Hmm... I hate being a noob.


Useful intel

  • I've tried a bunch of times setting Xdebug up, but I've never been successful. This is the closest I've gotten. So it might be some stupid blunder.
  • I'm using PHP v. 8.0.6, Xdebug version 3.0.4 and PhpStorm version 2020.3.1 - Build #PS-203.6682.180.
  • The remote server is a Cloudways-server.
  • I've defined WordPress (and WooCommerce) as external libraries (Languages & Frameworks >> PHP). So PhpStorm should know the WordPress-functions. And I can CMD+click on the WordPress-functions and see the function definitions.
  • If I go to 'Run' >> 'Web Server Debug Validation' and click 'Validate', then it shows all green ticks.
  • The guide I've followed the most is this Zero-configuration Xdebug debugging.
  • Here is the contents of my local php.ini-file:
...
... Omitted lines
...

[xdebug]
zend_extension="/usr/local/lib/php/pecl/20200930/xdebug.so"
xdebug.mode=debug
xdebug.client_host=12.123.123.123 (IP to Cloudways-server)
xdebug.client_port=9003

; End of file
  • In Cloudways, I've added these lines to the php.ini on the remote server (under 'Application Settings' >> 'PHP FPM Settings'):
php_admin_value[display_errors]=on
php_admin_value[memory_limit]=2048M
php_value[xdebug.remote_enable]=1
php_value[xdebug.mode]=debug
php_value[xdebug.client_host]=87.116.38.66

Answer to comments 1

As @LazyOne pointed out, then I might be debugging a single file, whereas I'm trying to debug the entire project running.

I'm just unsure how to do that. If I go to 'Run' >> 'Edit configurations' (under debug), then I reach this dialog box:

PhpStorm Xdebug edit configuration

And I'm not really sure what I'm supposed to do here, since it 'forces me' to define which file I'm trying to debug.

Zeth
  • 2,273
  • 4
  • 43
  • 91
  • 2
    *"And set a breakpoint on line 2, and run 'Debug functions.php',"* If I'm getting you correctly you are trying to debug `functions.php` file **directly**. But it's not meant to work like that. It meant to be executed as part of the normal WordPress code execution flow. *Right now you are **bypassing** the whole WP core code,* including classes autoloading and any functions that would normally be defined before `functions.php`gets executed in normal execution flow. – LazyOne May 27 '21 at 11:41
  • 1
    **P.S.** 1) Side note on "`xdebug.client_host=12.123.123.123 (IP to Cloudways-server)`" -- `client_host` is to specify the IP where IDE (debug client) is running. It's Xdebug that connects to IDE and NOT other way around. 2) This makes me think that right now you may be executing (debugging) your `functions.php` locally in a CLI environment (where IDE overrides these settings when you hit "Debug" for PHP Script type of configs) and not a web page request... – LazyOne May 27 '21 at 11:44
  • 1
    To add to what @LazyOne said - you don't even *need* Xdebug on your local machine if you're debugging WordPress running on a Cloudways server. Xdebug needs to only be there where PHP runs. – Derick May 27 '21 at 11:52
  • Thanks for weighing in, @LazyOne. I've added some further details as an answer to your first comment. ... Regarding your other comment. Are you telling me, that I should remove those lines (in the bottom of my local `php.ini`-file), since they're not being used there? – Zeth May 27 '21 at 11:55
  • If I remove these lines: `;[xdebug] ;zend_extension="/usr/local/lib/php/pecl/20200930/xdebug.so" ;xdebug.mode=debug ;xdebug.client_host=12.123.123.123 ;xdebug.client_port=9003 ` from my local php.ini-file, then it shows me the error: "/usr/local/bin/php -dxdebug.mode=debug -dxdebug.client_port=9003 -dxdebug.client_host=127.0.0.1 /path/to/project/wp-content/themes/my-theme-name/functions.php" ... And then it doesn't stop at any breakpoint. – Zeth May 27 '21 at 12:00
  • 1
    @Zeth Yes, you are doing local run/debug in a CLI bypassing the WordPress core code. The error is correct and expected in such situation. You need to do a web page debug instead (use the `+` button on your screenshot and add Run/Debug Configuration of the appropriate type... or better use Zero-config approach where you control "debug me" flag (Xdebug cookie) with Xdebug browser helper extension). – LazyOne May 27 '21 at 12:01
  • 1
    @Zeth For that you need to have Xdebug configured on your Cloudways server, `xdebug.client_host` must point to your local machine (the IP used to connect from server to your home/work PC) and your router/firewlal must allow such connection on Xdebug port. – LazyOne May 27 '21 at 12:01
  • 1
    That's if you want to debug your remote (live) code. Would be better if you can run a copy of your WP site locally (same computer as IDE: on the same OS or a virtual/docker) where it will be more easier to set it up (opening firewall/router; knowing your IP might be an issue in some cases). Anyway: 1) https://learnxdebug.com/ 2) https://www.jetbrains.com/phpstorm/documentation/debugging/ 3) https://www.jetbrains.com/help/phpstorm/debugging-with-phpstorm-ultimate-guide.html – LazyOne May 27 '21 at 12:04

0 Answers0