From 3af65d5729063cdb9af2a8b4c62b09c044395861 Mon Sep 17 00:00:00 2001 From: Soner Sayakci Date: Thu, 13 Aug 2026 08:18:59 +0200 Subject: [PATCH 1/3] docs: drop shopware/docker Composer package from hosting guides Guide new projects to shopware-cli project create instead of composer create-project, and inline the TRUSTED_PROXIES example instead of linking to the Flex recipe. --- .../infrastructure/reverse-http-cache.md | 10 +++++++++- guides/hosting/installation-updates/docker.md | 19 ++++++++++--------- 2 files changed, 19 insertions(+), 10 deletions(-) diff --git a/guides/hosting/infrastructure/reverse-http-cache.md b/guides/hosting/infrastructure/reverse-http-cache.md index 7980d53580..8212c45307 100644 --- a/guides/hosting/infrastructure/reverse-http-cache.md +++ b/guides/hosting/infrastructure/reverse-http-cache.md @@ -72,9 +72,17 @@ If you look for the old documentation and examples, you can find it [here](https ::: info Since Shopware 6.6, the `TRUSTED_PROXIES` environment variable is no longer taken into account out of the box. -Make sure to create a Symfony configuration to make it configurable again, as shown in the [trusted_env.yaml example](https://github.com/shopware/recipes/blob/main/shopware/docker/0.1/config/packages/trusted_env.yaml). +Create a Symfony configuration to make it configurable again: ::: +```yaml +parameters: + env(TRUSTED_PROXIES): '' + +framework: + trusted_proxies: '%env(TRUSTED_PROXIES)%' +``` + For the most part, using Symfony and Varnish doesn't cause any problem. But when a request passes through a proxy, certain request information is sent using either the *standard Forwarded* header or *X-Forwarded* headers. For example, instead of reading the `REMOTE_ADDR` header (which will now be the IP address of your reverse proxy), the user's true IP will be stored in a standard Forwarded: for="..." header or an *X-Forwarded-For* header. diff --git a/guides/hosting/installation-updates/docker.md b/guides/hosting/installation-updates/docker.md index 73f971ae49..e2c09560a2 100644 --- a/guides/hosting/installation-updates/docker.md +++ b/guides/hosting/installation-updates/docker.md @@ -10,16 +10,21 @@ nav: Shopware provides a Docker image to run Shopware 6 in a containerized environment for production intent. The Docker image is based on the official PHP image and includes the required PHP extensions and configurations to run Shopware 6. But it does not contain Shopware itself. It's intended to be used together with your existing Shopware project, copy the project into the image, build it, and run it. -If you don't have a Shopware project yet, you can create a new one with: +If you don't have a Shopware project yet, create one with [Shopware CLI](../../../products/tools/cli/index.md): ::: info -You can create a Project with a specific Shopware version by specifying the version like: `composer create-project shopware/production:6.6.7.0 ` +You can create a project with a specific Shopware version by specifying the version like: `shopware-cli project create 6.6.7.0` ::: ```bash -composer create-project shopware/production +shopware-cli project create cd -composer require shopware/docker +``` + +Alternatively, you can run the CLI without a separate installation via: + +```bash +npx @shopware-ag/shopware-cli project create ``` The typical Dockerfile in your project would look like this: @@ -53,10 +58,6 @@ COPY --from=build --chown=82 --link /src /var/www/html The Dockerfile uses the `shopware-cli` image to build the project and then copies the built project into the `base-image` image. The `base-image` is the Shopware Docker image. -::: info -Instead of copying the Dockerfile to your project, rather run `composer req shopware/docker` to add the Dockerfile to your project. This keeps the Dockerfile up-to-date with the latest changes using Symfony Flex recipes. -::: - ## Available Tags / Versioning ::: info @@ -127,7 +128,7 @@ In a very basic setup when all files are stored locally you need 5 volumes: | image thumbnails | `/var/www/html/public/thumbnail` | | generated sitemap | `/var/www/html/public/sitemap` | -Shopware logs by default to `var/log`, but when `shopware/docker` Composer package is installed, we change it to stdout. This means you can use `docker logs` to see the logs or use logging driver to forward the logs to a logging service. +Shopware logs by default to `var/log`. In Docker, configure Monolog to write to stdout or stderr so you can use `docker logs` or a logging driver to forward the logs to a logging service. ## Ideal Setup From 80a06dc523121029486adbd0b6110303dd7c0aa1 Mon Sep 17 00:00:00 2001 From: Soner Sayakci Date: Thu, 13 Aug 2026 08:26:03 +0200 Subject: [PATCH 2/3] docs: include Docker Monolog stderr config Show the production monolog.yaml that writes JSON logs to stderr instead of only mentioning stdout/stderr in passing. --- guides/hosting/installation-updates/docker.md | 28 ++++++++++++++++++- 1 file changed, 27 insertions(+), 1 deletion(-) diff --git a/guides/hosting/installation-updates/docker.md b/guides/hosting/installation-updates/docker.md index e2c09560a2..0d178bf782 100644 --- a/guides/hosting/installation-updates/docker.md +++ b/guides/hosting/installation-updates/docker.md @@ -128,7 +128,33 @@ In a very basic setup when all files are stored locally you need 5 volumes: | image thumbnails | `/var/www/html/public/thumbnail` | | generated sitemap | `/var/www/html/public/sitemap` | -Shopware logs by default to `var/log`. In Docker, configure Monolog to write to stdout or stderr so you can use `docker logs` or a logging driver to forward the logs to a logging service. +Shopware logs by default to `var/log`. In Docker, configure Monolog to write to stderr so you can use `docker logs` or a logging driver to forward the logs to a logging service. + +Create `config/packages/prod/monolog.yaml`: + +```yaml +parameters: + env(MONOLOG_LOG_LEVEL): "error" +monolog: + handlers: + main: + type: fingers_crossed + action_level: "%env(MONOLOG_LOG_LEVEL)%" + handler: nested + excluded_http_codes: [404, 405] + buffer_size: 50 + nested: + type: stream + path: php://stderr + level: "%env(MONOLOG_LOG_LEVEL)%" + formatter: monolog.formatter.json + console: + type: console + process_psr_3_messages: false + channels: ["!event", "!doctrine"] + business_event_handler_buffer: + level: "%env(MONOLOG_LOG_LEVEL)%" +``` ## Ideal Setup From da5ce06b804de5392003a926826d1b4b53573c39 Mon Sep 17 00:00:00 2001 From: Soner Sayakci Date: Thu, 13 Aug 2026 08:27:01 +0200 Subject: [PATCH 3/3] docs: name trusted proxies config file path Specify config/packages/trusted_env.yaml so readers know where to put the TRUSTED_PROXIES Symfony configuration. --- guides/hosting/infrastructure/reverse-http-cache.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/guides/hosting/infrastructure/reverse-http-cache.md b/guides/hosting/infrastructure/reverse-http-cache.md index 8212c45307..5df0809f3c 100644 --- a/guides/hosting/infrastructure/reverse-http-cache.md +++ b/guides/hosting/infrastructure/reverse-http-cache.md @@ -72,7 +72,7 @@ If you look for the old documentation and examples, you can find it [here](https ::: info Since Shopware 6.6, the `TRUSTED_PROXIES` environment variable is no longer taken into account out of the box. -Create a Symfony configuration to make it configurable again: +Create `config/packages/trusted_env.yaml` to make it configurable again: ::: ```yaml