Add PostgreSQL client and server to Dockerfile

[alikon]

on devcontainer.json use:
// for MySQL

"runServices": ["app", "mysql", "mailpit"]
"containerEnv": { "PROFILE": "mysql" }

// for PostgreSQL

"runServices": ["app", "db_pgsql", "mailpit"]
"containerEnv": { "PROFILE": "pgsql" }

for full debug extensions + joomla core

code /workspaces/testcom/testcom.code-workspace

Summary by Sourcery

Add support for both MySQL and PostgreSQL dev profiles and improve the devcontainer setup for Joomla, debugging, and testing.

New Features:

• Allow choosing MySQL or PostgreSQL as the database backend via devcontainer PROFILE and docker-compose services.
• Persist Joomla files in a named Docker volume shared with the app container.
• Automatically configure Xdebug in the container based on the detected Docker gateway.
• Add a basic Apache VirtualHost configuration tailored for the Joomla document root.
• Add VS Code multi-root workspace and debug launch configuration files to streamline development.

Enhancements:

• Make the post-create script idempotent by skipping Joomla installation when an existing configuration is detected.
• Improve service readiness checks with healthchecks for MySQL and PostgreSQL and more robust wait logic in the post-create script.
• Refine Cypress setup with automatic baseUrl detection for local and Codespaces environments and explicit CMS path wiring.
• Restrict database access to an internal Docker network and clean up exposed ports to only those needed externally.
• Tighten Apache/PHP/Xdebug configuration and permissions for a more reliable local development environment.

[alikon]

@sourcery-ai review

[sourcery-ai]

Reviewer's Guide

Adds PostgreSQL support to the devcontainer (client, server service, and Joomla installer integration), refines MySQL usage, improves Joomla install robustness and Codespaces behavior, and enhances developer tooling (Xdebug auto‑config, Cypress, phpMyAdmin, multi-root workspace).

File-Level Changes

Change	Details	Files
Introduce database profile switching between MySQL and PostgreSQL and wire it into the Joomla installation flow.	Read PROFILE env var (default mysql) in post-create script and derive DB_TYPE, DB_HOST, DB_PREFIX based on it. Implement readiness checks for MySQL using mysql and for PostgreSQL using pg_isready with clear error messages and timeouts. Pass DB_TYPE, DB_HOST, DB_PREFIX into Joomla CLI installer arguments instead of hardcoding MySQL values. Skip Joomla installation steps when configuration.php already exists (volume reuse).	.devcontainer/post-create.sh
Improve Joomla environment setup and configuration for reuse, extensions, and Codespaces compatibility.	Guard Joomla installation with a configuration.php existence check to support persistent web root volumes. Download and unpack Joomla nightly build only when needed and configure debug, error reporting, and mail (Mailpit). Conditionally install the Alikonweb extension when its package zip is present and run robo map against the Joomla root. Refine the reverse-proxy fix.php to always honor HTTP_X_FORWARDED_HOST and enforce HTTPS/port 443, wiring it into both frontend and admin entrypoints. Create persistent joomla-html volume and adjust ownership/permissions of the Joomla root.	.devcontainer/post-create.sh .devcontainer/docker-compose.yml
Add PostgreSQL service to docker-compose and refactor networking and health checks.	Define an internal bridge network (testcom-internal) and attach app, mysql, db_pgsql, and mailpit to it. Add db_pgsql service using postgres:16 with test_joomla DB, joomla_ut user/password, volume-backed data, and a pg_isready healthcheck. Add healthchecks to the MySQL service and make app depend_on both mysql and db_pgsql with healthy conditions. Introduce named volumes mysql-data, db_pgsql_data, and joomla-html; mount joomla-html into app at /var/www/html; expose mailpit SMTP (1025).	.devcontainer/docker-compose.yml
Extend the devcontainer image with PostgreSQL client support and additional PHP extensions, and configure Apache for Joomla.	Install default-mysql-client, postgresql-client, libpq-dev, plus existing system dependencies in Dockerfile. Build and enable PHP extensions zip, mysqli, pdo, pdo_mysql, pdo_pgsql, pgsql, and xdebug. Enable Apache modules rewrite and ssl, set ServerName, and copy a Joomla-specific VirtualHost config as the default site. Create custom PHP ini for uploads and error logging; expose ports 80/443 and keep Apache as the entrypoint.	.devcontainer/Dockerfile .devcontainer/apache-joomla.conf
Refine Xdebug configuration and auto-detect the correct client host inside the container.	Replace static xdebug.ini with minimal defaults and move detailed configuration to post-create script. Parse /proc/net/route in post-create script to compute the container gateway IP and use it as xdebug.client_host, falling back to host.docker.internal when necessary. Write a generated /usr/local/etc/php/conf.d/99-xdebug.ini with mode=debug, start_with_request=yes, client_port=9003, idekey=VSCODE, and log_level=0.	.devcontainer/xdebug.ini .devcontainer/post-create.sh
Improve Cypress setup and baseUrl handling for both local and Codespaces environments.	Ensure node_modules/.bin/cypress is marked assume-unchanged in git when in a git work tree and make it executable. Install Cypress via npx cypress install, copy cypress.config.dist.js to cypress.config.js, and inject cmsPath pointing at JOOMLA_ROOT. Dynamically compute BASE_URL from Codespaces environment vars when present, otherwise default to http://localhost, and rewrite baseUrl in cypress.config.js accordingly.	.devcontainer/post-create.sh
Enhance developer UX by auto-opening the VS Code multi-root workspace and writing a detailed environment summary file.	Open the testcom.code-workspace after setup (best effort, errors ignored). Generate codespace-details.txt summarizing active profile, Xdebug host, Joomla admin URL and credentials, phpMyAdmin URL (for MySQL), Mailpit, Cypress, and Xdebug settings. Echo the same details to the console at the end of post-create for quick access.	.devcontainer/post-create.sh testcom.code-workspace

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've found 2 issues, and left some high level feedback:

• The container still mounts .devcontainer/xdebug.ini but post-create.sh now overwrites /usr/local/etc/php/conf.d/99-xdebug.ini dynamically, so consider removing the volume or clearly separating static vs generated Xdebug config to avoid confusion and subtle precedence issues.
• The Joomla-related post-create steps (phpMyAdmin install, Codespaces proxy fix, permission adjustments, etc.) are executed only when configuration.php is missing, meaning they won’t run when reusing an existing Joomla volume; if those steps are required on every startup, move them outside the if [ -f "$JOOMLA_ROOT/configuration.php" ] guard.
• The code /workspaces/testcom/testcom.code-workspace invocation in post-create.sh assumes a VS Code/Dev Containers environment and may be noisy or fail elsewhere; consider gating it behind an environment check (e.g. REMOTE_CONTAINERS/CODESPACES) or making it opt-in.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The container still mounts `.devcontainer/xdebug.ini` but `post-create.sh` now overwrites `/usr/local/etc/php/conf.d/99-xdebug.ini` dynamically, so consider removing the volume or clearly separating static vs generated Xdebug config to avoid confusion and subtle precedence issues.
- The Joomla-related post-create steps (phpMyAdmin install, Codespaces proxy fix, permission adjustments, etc.) are executed only when `configuration.php` is missing, meaning they won’t run when reusing an existing Joomla volume; if those steps are required on every startup, move them outside the `if [ -f "$JOOMLA_ROOT/configuration.php" ]` guard.
- The `code /workspaces/testcom/testcom.code-workspace` invocation in `post-create.sh` assumes a VS Code/Dev Containers environment and may be noisy or fail elsewhere; consider gating it behind an environment check (e.g. `REMOTE_CONTAINERS`/`CODESPACES`) or making it opt-in.

## Individual Comments

### Comment 1
<location path=".devcontainer/Dockerfile" line_range="39-41" />
<code_context>
+    # Composer
     curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer && \
-    # Install Xdebug
+    # Xdebug
     pecl install xdebug && \
-    # Enable Apache's rewrite module and set the ServerName to prevent warnings
-    a2enmod rewrite && \
+    docker-php-ext-enable xdebug && \
+    # Apache
+    a2enmod rewrite ssl && \
</code_context>
<issue_to_address>
**issue (bug_risk):** Avoid configuring Xdebug twice to prevent duplicate zend_extension warnings.

`pecl install xdebug` + `docker-php-ext-enable xdebug` already creates an ini with `zend_extension=xdebug`, and `post-create.sh` adds the same line to `99-xdebug.ini`, so Xdebug will be loaded twice. To avoid warnings and version‑dependent issues, either drop `zend_extension` from `99-xdebug.ini` and rely on the auto-generated ini, or skip `docker-php-ext-enable` and manage Xdebug only via your custom ini.
</issue_to_address>

### Comment 2
<location path=".devcontainer/docker-compose.yml" line_range="13" />
<code_context>
     volumes:
       - ..:/workspaces/testcom:cached
       - ./xdebug.ini:/usr/local/etc/php/conf.d/99-xdebug.ini
+      - joomla-html:/var/www/html
     ports:
</code_context>
<issue_to_address>
**suggestion:** Binding xdebug.ini while also rewriting 99-xdebug.ini in post-create.sh can be confusing and redundant.

Because `./xdebug.ini` is mounted to `/usr/local/etc/php/conf.d/99-xdebug.ini` but `post-create.sh` later regenerates that same file, the bind mount no longer has any effect and creates ambiguity about the real source of truth. Consider either removing the bind mount and relying on the script-generated config, or stopping the script from rewriting `99-xdebug.ini` and keeping all configuration in the mounted file instead.

Suggested implementation:

```
    volumes:
      - ..:/workspaces/testcom:cached
      - joomla-html:/var/www/html

```

To fully align with the suggestion, verify that `post-create.sh` is indeed generating `/usr/local/etc/php/conf.d/99-xdebug.ini` with the desired Xdebug settings. If any configuration currently exists only in `./xdebug.ini`, you should migrate those settings into the script-generated file logic in `post-create.sh`, or into a base template that the script uses.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[sourcery-ai]

issue (bug_risk): Avoid configuring Xdebug twice to prevent duplicate zend_extension warnings.

pecl install xdebug + docker-php-ext-enable xdebug already creates an ini with zend_extension=xdebug, and post-create.sh adds the same line to 99-xdebug.ini, so Xdebug will be loaded twice. To avoid warnings and version‑dependent issues, either drop zend_extension from 99-xdebug.ini and rely on the auto-generated ini, or skip docker-php-ext-enable and manage Xdebug only via your custom ini.

[sourcery-ai]

suggestion: Binding xdebug.ini while also rewriting 99-xdebug.ini in post-create.sh can be confusing and redundant.

Because ./xdebug.ini is mounted to /usr/local/etc/php/conf.d/99-xdebug.ini but post-create.sh later regenerates that same file, the bind mount no longer has any effect and creates ambiguity about the real source of truth. Consider either removing the bind mount and relying on the script-generated config, or stopping the script from rewriting 99-xdebug.ini and keeping all configuration in the mounted file instead.

Suggested implementation:

    volumes:
      - ..:/workspaces/testcom:cached
      - joomla-html:/var/www/html

To fully align with the suggestion, verify that post-create.sh is indeed generating /usr/local/etc/php/conf.d/99-xdebug.ini with the desired Xdebug settings. If any configuration currently exists only in ./xdebug.ini, you should migrate those settings into the script-generated file logic in post-create.sh, or into a base template that the script uses.