Adding XDebug & MailCatcher support

[swashata]

Hi,

First of all thank you very much for this project. It has enabled me to use docker instead of vvv for developing WordPress Plugins and Themes.

There were two things I missed the most when making transition

1. XDebug Remote debugging (yes it works great with VSCode).
2. MailCatcher for debugging and testing emails.

I have managed to add both to this awesome container and I am willing to send PR to add support. Please let me know if you are interested.

[swashata]

PS: The trick to add xdebug remote support was to set xdebug.remote_host=host.docker.internal as described here.

Installing and configuring mailcatcher was straight forward, gem install mailcatcher and then copying over a conf file.

[dsifford]

Hi @swashata,

Thanks for the kind words. Glad to hear the project has served you well.

As @karellm I think will attest, our primary focus with this project is keeping the WordPress service as lean and focused on just WordPress as possible (with the singular exception being having a mechanism for SSL cert automation baked into the image).

I do agree that both XDebug and MailCatcher are attractive tools for development setting, but there are a good number of individuals (including myself) that use this image for production environments as well, so having the extra bloat isn't ideal for those cases.

---

To speak to both XDebug and MailCatcher individually

XDebug: We've tossed around the idea of adding it before and decided against it. This might be better suited for a fork of this project where you can add things specific to your needs.

MailCatcher: Have you considered instead adding a separate service for this, exposing port 1025, and communicating with the wordpress image that way?

[swashata]

Hi,

Thanks for the quick response. I've totally taken the wrong route for the MailCatcher. I am fairly new to docker, and honestly I had no idea that I could do that. Thanks for the tip 😄

About XDebug, it actually only makes sense to install on development environment. I have seen the PR before (in fact I made it my starting point), but I guess with the availability of host.docker.internal it is now simpler to add remote debugging. I am actually using it for development right now.

Anyway, I will leave it up to you to decide whether it is worth-while to have xdebug or not. I am afraid that it may not work at all for linux hosts, because host.docker.internal is actually available on mac and windows only and the workaround mentioned in the issue may not work for listening on xdebug server provided by IDE.

Please close this issue if you don't think there is something we can do about it right now.

[karellm]

I agree that XDebug shouldn't be forced into the image. That said we could make a dev image or have a dev tag.