You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We're having a considerable amount of customers that are trying to run simple php scripts inside Lagoon and are struggling because there is no simple php config available in the nginx image.
I think though we can improve the Developer Experience even more, with one of these things:
A. create a new nginx-php image (like the nginx-drupal) image that has the nginx php config already in it and loaded
B. add a new php.conf nginx config to the nginx image and explain how to use it instead of the static-files.conf that is defaultly used.
Solution A would definitely be the one with the highest DX, but then we might up having a LOT of nginx-* images for all kind of languages, frameworks and applications.
So maybe Solution B would be a more scalable way for the future.
The text was updated successfully, but these errors were encountered:
I would proposed rather than php.conf perhaps php-app.conf or php-server.conf. From a DX perspective php.conf and php.ini are super close - I get that these are unrelated - but from the perspective of a php developer setting this up, I think it could be clearer?
We're having a considerable amount of customers that are trying to run simple php scripts inside Lagoon and are struggling because there is no simple php config available in the nginx image.
Currently the support tells them to copy something like this https://gist.github.com/Schnitzel/6b19074386bc33d80b75f2f4824ecb03 which works for most simple php scripts.
I think though we can improve the Developer Experience even more, with one of these things:
A. create a new
nginx-php
image (like thenginx-drupal
) image that has the nginx php config already in it and loadedB. add a new
php.conf
nginx config to thenginx
image and explain how to use it instead of thestatic-files.conf
that is defaultly used.Solution
A
would definitely be the one with the highest DX, but then we might up having a LOT ofnginx-*
images for all kind of languages, frameworks and applications.So maybe Solution
B
would be a more scalable way for the future.The text was updated successfully, but these errors were encountered: