Support a local / dev image

[StephenMiracle]

How helpful would it be to provide a dev image for FrankenWP & WordPress?

What should be included?
Thinking DEBUG=true
Caddy set to debug
WP_DEBUG set to true

And include xdebug?

[ngdangtu-vn]

Wordpress doesn't have a good debug tool. Debug bar and query monitor ain't good enough. It couldn't be used to debug api, especially for download links. So xdebug is a proper tool that bring justice back to PHP.

(Please don't suggest me to use log, it is not very productive way)

[nickchomey]

Agreed. Xdebug is by far the most important tool for me - for debugging, profiling, and developing.

[PascaleBeier]

One way would be to provide *-dev images, the other way would be to provide a development build target for the Dockerfiles.

These should come with

• xdebug preinstalled
• Debug Variables set to debug
• Xdebug Environment Variables delegated

The actual configuration of xdebug is something that should happen in the container, not the image itself and varies from Windows, Linux, and Mac.

We could provide a sample compose.dev.yml pulling in the dev image, and setting the correct environment variables for xdebug.

[ngdangtu-vn]

I agree with your idea. It is a right way to enable xdebug from docker-compose.yml. This allow dev to test the site in multiple stage (from debug to test like users use the site).

Also, the xdebug env var shouldn't share value with DEBUG_MODE env of wp to offer the best debug experience (sometime you might want xdebug only, or wp query monitor only).

[nickchomey]

I don't have much experience with docker, but what I do on a normal server is install the xdebug extension and then toggle it on and off by adding/removing a ; in front of the first line in the ini file zend_extension=xdebug. And then restart php

You can then check if it is loaded in php info. Eg

PHP 7.4.10 (cli) (built: Aug 18 2020 09:37:14) ( NTS DEBUG ) 
Copyright (c) The PHP Group 
Zend Engine v3.4.0, Copyright (c) Zend Technologies 
with Zend OPcache v7.4.10-dev, Copyright (c), by Zend Technologies 
with Xdebug v3.0.0-dev, Copyright (c) 2002-2020, by Derick Rethans

I currently use openlitespeed, which allows for having distinct ini files per host by using PHP_INI_SCAN_DIR ( https://docs.litespeedtech.com/lsws/cp/cpanel/php-user-ini/#php_ini_scan_dir-in-the-webadmin-console), so I can turn xdebug on/off for each site rather than at the server level. I don't know if this would be possible with frankenphp, but would be ideal.

[StephenMiracle]

Nice. Thanks for the litespeed context @nickchomey.

a Caddyfile would be the equivalent for this instance. A couple of users have already asked about running with multiple hosts. Generally, you should have a single site per docker instance, but I wonder if it would make sense to be able to setup multiple sites if they all were using the same webserver [caddy]. I'm going take a look at this.

In regards to xdebug, I'm sold. I've already started setting up an example template with a compose.yaml file. I like the note about being able to toggle on the type of debugging you want to do and not have just a global debug toggle.

[nickchomey]

Yes, this is sort of part of a larger meta problem. And the solution probably belongs upstream in frankenphp rather than WordPress-specific, so that any app can use it as well as the static binary version (which I'd prefer to use) and not just docker.

Not only do I toggle xdebug on/off per vhost (and usually only on a staging site if on a production server), but also toggle on an off different xdebug modules - debug, develop, profile, trace etc...

So, hopefully some sort of mechanism can be introduced upstream to allow for multiple sites per caddy/frankenphp server, each with their own php config that can be reset/updated without affecting the others. It would be ideal if the caddyfile could just have a PHP_INI_SCAN_DIR directive for each site/app/host, which could point to their respective ini file directory. I generally put mine literally in the web app root directory - eg /app/php-configs, adjacent to /app/wp-content

I'm not sure I can be helpful in how to actually implement any of this, but I am happy to brainstorm conceptual stuff like this

One other thing that might be helpful is Devilbox. I haven't used it in a little while, but it is a docker compose-based local dev environment. And it allows for using xdebug with custom php ini files. You have to rebuild the container in order to turn it on/off, and I don't think you can toggle per-site

cytopia/devilbox#946

https://devilbox.readthedocs.io/en/latest/intermediate/configure-php-xdebug.html

[StephenMiracle]

that’s interesting. You’ll need to reboot any container when turning off / in xdebug since you have to restart the server. It’s core docker functionality. But that shouldn’t be much of an issue.

We should be able to allow for multiple sites / caddyfiles . the current dockerfile already allows for multiple php.ini files so we will need to map the caddyfile to the php.ini