This pull request has two changes

1. All early returns from recv.vcl have been changed to set a header called req.http.x-pass. Problem with doing return(pass) is that it skips any backend selection that you may end up doing later in the VCL processing. This is in vast majority of cases undesirable. To really take advantage of this the Paas should add a request setting object that has the action of PASS in case req.http.x-pass is present
2. Any object with no cache headers should not be cached. It's not necessarily against the spec to cache it however there have been numerous cases of misconfiguration where there was a server misconfig where private data was cached. This is just a safety precaution.

The max-age=0 cache control directive is not enough from prevent the client caching. This does not prevent the client from reserving the cached page with the browser's previous button. It is better to use the no-cache directive in this case (or no-store if we also dont want the proxy to cache).

We have a problem with this on a shopware project when we add a product to the cart in ajax then we are going to another page and then back with the browser previous button. The basket appear empty.

I have made a couple changes to the stock Fastly VCL. Some of the issues that I have observed are

• Early returns e.g. return(lookup) at the end of recv.vcl. This will do an early return and avoid shielding logic causing worse cache hit ratios
• Simplified pieces of code with cookie accessors e.g. req.http.Cookie:sw_states.
• Corrected the deliver.vcl which would have resulted in no caching on Fastly edge nodes (only on shield)

Please describe the feature you would like to see implemented.

When installing fastly via setup-fastly.sh, the command will fail if /tmp/fastly already exists, but the fastly command (/tmp/fastly/fastly) is missing.

There should be a check if /tmp/fastly/fastly exists, otherwise it should re-install fastly again.

Early return(pass) removes all the default Fastly logic. That should not be done. Furthermore, this early return(pass) prevents any caching of the Shopware assets, that are returned without a cache-control: public.

In dedicated environments where you have multiple nodes the deploy hook only runs once, while the pre_start hook (which is specific to dedicated gen 2) is executed on all nodes.

$PLATFORM_REGISTRY_NUMBER is an environment variable that is only present on dedicated generation 2 clusters (but not on grid nor on dedicated generation 3)

Hello

Here is a change to dump the .env file as .env.local.php during the platform sh build hook and remove the overhead introduced by parsing the env files stack in production.

To ensure the retro-compatibility with the previous Shopware versions the dump is executed only when Shopware >= 6.4.16.0 is enabled in composer vendors

PHP Version

8.0

Shopware Version

4.6.1

Expected behaviour

Activate plugin by CLI

Actual behaviour

If I install by composer and activate the plugin by CLI, I have an error: Shopware Plugin Lifecycle Service

Activate 1 plugin(s):

• Custom Products (v3.4.0)

08:16:25 CRITICAL [console] Error thrown while running command "plugin:activate SwagCustomizedProducts". Message: "Impossible to create the root directory "/app/public/theme/ff35c4252d36bcd7bc8db9252e7e277b/css". mkdir(): Read-only file system" ["exception" => League\Flysystem\Exception^ { …},"command" => "plugin:activate SwagCustomizedProducts","message" => "Impossible to create the root directory "/app/public/theme/ff35c4252d36bcd7bc8db9252e7e277b/css". mkdir(): Read-only file system"]

In Local.php line 112:

Impossible to create the root directory "/app/public/theme/ff35c4252d36bcd7bc8db9252e7e277b/css". mkdir(): Read-only file system

How to reproduce

After adding in platform.app.yaml problem was solved. Maybe I made something wrong? "/public/bundles": source: local source_path: "public/bundles" "/public/theme": source: local source_path: "public/theme"