Xdebug request directly from bin/magento

[dmanners]

Description

Would it not be possible with a change in xdebug config to trigger a call directly from bin/magento rather than having to setup a php cli script in phpstorm? From my understanding this could be done if we added the config xdebug.start_with_request=yes from the default xdebug settings.

Then we would just need to turn on the normal listener and run the debugger as if we were debugging through the browser then open the cli and simply run bin/magento

[nietoga]

Sup, dude. This is what I'm using atm for that purpose.

bin/docker-compose exec -e PHP_IDE_CONFIG=serverName="$serverName" phpfpm php -d xdebug.start_with_request=yes "$@"

I'll see if I can push something more meaningful for this in the future but you just have to execute:

bin/php-xdebug bin/magento ...

[markshust]

From the AI overlords:

Setting xdebug.start_with_request=yes means that Xdebug will start debugging every single request made to your PHP application. While this can be helpful for some developers, there are a few potential downsides:

1. Performance impact: Since Xdebug adds debugging and profiling features to your PHP application, it can slow down your application's performance. By enabling this setting, every request will incur this performance overhead, potentially making your development or production environment considerably slower.

2. Privacy and security concerns: If Xdebug is enabled for all users and requests in production, confidential debugging information may be exposed, leading to potential security and privacy risks. It is generally recommended to disable Xdebug or restrict debugging in production environments.

3. Increased resource usage: Debugging every request can consume more system resources (CPU, memory, etc.), especially for high-traffic applications. This can lead to slower response times and potentially affect the capacity of your server or development machine.

4. Noise from irrelevant requests: When debugging a specific issue, you may only need to capture data for a certain request or a subset of requests. Having Xdebug enabled for all requests can generate a lot of unnecessary data and make it harder to identify the relevant information.

5. Hindered development workflow: Continuously enabled Xdebug can interfere with your development flow, as it might slow down requests when you are not interested in debugging.

To mitigate these downsides, consider using xdebug.start_with_request=trigger, so debugging is only enabled when a trigger parameter (such as a cookie, GET, or POST parameter) is set. This way, you can selectively enable debugging only when needed, balancing performance, and productivity.

---

So, there is a definite performance impediment with setting xdebug.start_with_request=yes. I also confirmed this on other forum posts, which also recommend using xdebug.start_with_request=trigger instead.

I've always avoided the xdebug.start_with_request=yes setting because I didn't like how it assumed you are debugging every request, and it seemed to bypass the need to set up the specific config to get this working..

That said, @dmanners would xdebug.start_with_request=trigger work for you? This requires a trigger param to be set, which I'm not 100% sure is an option when using bin/magento. I'm leaning on leaving things as they are, as I don't think the extra setup for CLI debugging is too painful, especially since this isn't too common of an action.

[nietoga]

Hi @markshust

I don't know if my development workflow is weird, but I actually think a way to execute cli commands with xdebug enabled by default is pretty useful. This is what I usually do:

I have a PHP script setup to enable me to do this kind of stuff.

// File named: app/tests/custom.php
$syncOrder = function ($orderId) use ($objectManager) {
    $orderRepo = $objectManager->get(OrderRepositoryInterface::class);
    $order = $orderRepo->get($orderId);
    $syncManager = $objectManager->get(OrderSyncManager::class);
    $syncManager->syncOrder($order);
};

Then I call the function:

bin/php-xdebug app/tests/custom.php syncOrder 1234

This way I have a more finegrained way to debug specifically what I'm trying to debug. I've seen may developers setup a controller to achieve the same result, which I think is kind of the same, but less practical to work with.

Anyways, I think your comments are on point, as setting it up was not difficult and I even shared how to do it in my previous comment.

[dmanners]

@markshust yeah with the trigger it could be an option. Let me have a play around with how this could work.

[dmanners]

hey @nietoga thanks for the command. I tested it with my setup but the trigger does not seem to happen. What exactly should the server name be here or is the variable ok? Neither the variable or the name of my server in my ide made a difference.

[dmanners]

oh never mind @nietoga it would help if I actually set a breakpoint :D

[nietoga]

Well, the server name is the name you gave the server on the servers' configuration of PhpStorm. I guess you already discovered that.

Also, if you want to trigger some specific stuff, these are the modules I use to test:

https://github.com/nietoga/magetools