10/29/2023 0 Comments Phpstorm docker composeXdebug.remote_port has an interesting quirk in that if you don’t set the parameter, it defaults to port 9000. Do I wish I’d have known about this years ago? For sure. Enable remote triggering of the Xdebug server and set autostart to true when either a breakpoint is hit in the code or you’ve set the break to be at the entry point to your application’s code and: bingo. Remember me mentioning “bookmarklets” in the browser earlier? You have to use an extension to keep a server connection alive with your Xdebug session – for example, for Firefox: Xdebug.remote_enable and tostart are more interesting. Zend_extension has always been the PHP ini file parameter name for adding in extensions – it hooks the pecl extension (or extensions installed with other tools like PEAR) installed to the runtime, so things like zip, redis, curl and the like use the same parameter to enable them. I said this wouldn’t just be a copy and paste article, so: what are these parameters? Here’s what to put in it: zend_extension=xdebug Now we’re running PHP and fpm in a container, so we need to inject the configuration in with docker-compose.įirst, create the file to inject and save it in the project root – let’s call it xdebug-local.ini. It’s at this point you want to install it with pecl, so add pecl install Xdebug into the run commands for the container: RUN docker-php-source extract & \ĭocker-php-source delete Step Two: Configuring Xdebugīefore Docker, Xdebug was relatively straightforward to configure on a platform, in that it was a new set of the php.ini parameters – you’d either just edit the existing php.ini, or load in a custom ini or override. Our project had this in our Dockerfile to install redis and imagick: RUN docker-php-source extract & \ So, to install Xdebug, you need to include it with pecl (you can still -only- use pecl for operating system-level dependencies at the time of writing). Part of what made the installation significantly easier for me was that the project it was being installed on was already using a Dockerfile as part of the stack. That is to say: what is this thing I’m doing and why does it work? Bearing that in mind, here is how I implemented the stack, step by step with a little bit more info than just your average set of instructions. One of the things that most articles I’d read or tried to follow miss out one core thing that frustrated me: most have the “how”, but not the “why”. So, I thought: why not give it a go again? And so I did, going step by step though Gary and Derick’s video, with the goal to implement it into our development process for our Open Source project Awe-der. These thoughts of mine were also circulated in others’ replies to the tweet, but it was when Tighten’s Matt Stauffer and Twilio’s Gary Hockin stepped in to offer livestreams with Derick to set it up that I took notice – the resulting content is now excellently documented at with others’ contributions. Lastly, but most importantly for developers: why bother when you can use var_dump() or Symfony’s dump() or Laravel’s dd()?.Given that when used as part of Laravel’s tinker it boots up the whole app into a REPL environment, does that render something like Xdebug somewhat redundant? I’ve previously written an article () on how superb PsySh is as an application’s command line.It was a pain trying to set it up manually before, but what about now, where Xdebug runs a server on an IP, but it will be running in Docker? A lot has changed since I started – I use Jetbrains PHPStorm as my IDE, and develop with Docker. Plus, things like custom “bookmark” browser extensions made it feel like you had to jump through a lot of hoops to use it effectively. I’d tried Xdebug before at some point – I can’t recall when, and had an experience that left me thinking that understanding what you could do with it would take far too much time up for me to learn.It’s not like it was some obscure or new tool being talked about. It’s been around years – I started writing PHP professionally in 2016, by which time Xdebug had existed for 14 years. Like many PHP developers with significant experience: I know of Xdebug.Let’s clear up some existing thoughts I had on Xdebug – some readers might nod in agreement or have/had similar experiences: I thought, ‘Do I need to revisit Xdebug?’, and I realised that I’d fallen into Derick’s trap. Quite the controversial “hot-take” from Derick, and while it certainly caused quite the stir (that it was probably designed to), it made me think.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |