Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Symfony 3.4+ #74

Open
danabrey opened this issue Sep 22, 2017 · 8 comments
Open

Symfony 3.4+ #74

danabrey opened this issue Sep 22, 2017 · 8 comments

Comments

@danabrey
Copy link

Would you consider adding support for Symfony 3.4+ applications either on a separate branch or by way of an environment variable or some such?

The nginx configuration would need to send requests to public/index.php instead of web/app(_dev).php, and the PHP version would need to be bumped to 7.1.3^

@danabrey
Copy link
Author

You can see the changes required to support Symfony 4 apps on my fork here: https://github.com/danabrey/docker-symfony-1

@maxpou
Copy link
Owner

maxpou commented Sep 25, 2017

Hi @danabrey,
This is a very good idea!
Feel free to open a PR! If the PR is ok, I'll merge it in a separate branch!

Edit: I just change PHP version to 7.1 😉

@danabrey
Copy link
Author

Great @maxpou! If it's just the nginx config that needs altering to support a Symfony 4 app, is it worth considering having multiple nginx setups - symfony.dev and symfony4.dev, for example?

Just having separate branches would work, though, and is probably clearer.

@yahyaerturan
Copy link

.dev domains are being directed to https with new version of Chrome browsers.

First need to change it to something else, for example: .local

Here is the nginx configuration for Symfony 3.4 and Symfony 4.x:

server {
    server_name syfmony.local www.symfony.local;
    root /var/www/symfony/public;

    location / {
        # try to serve file directly, fallback to index.php
        try_files $uri /index.php$is_args$args;
    }

    location ~ ^/index\.php(/|$) {
        fastcgi_pass php-upstream;
        fastcgi_split_path_info ^(.+\.php)(/.*)$;
        include fastcgi_params;
        # When you are using symlinks to link the document root to the
        # current version of your application, you should pass the real
        # application path instead of the path to the symlink to PHP
        # FPM.
        # Otherwise, PHP's OPcache may not properly detect changes to
        # your PHP files (see https://github.com/zendtech/ZendOptimizerPlus/issues/126
        # for more information).
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        fastcgi_param DOCUMENT_ROOT $realpath_root;
        fastcgi_param HTTPS off;
        # Prevents URIs that include the front controller. This will 404:
        # http://domain.tld/index.php/some-path
        # Remove the internal directive to allow URIs like this
        internal;
    }

    # return 404 for all other php files not matching the front controller
    # this prevents access to other php files you don't want to be accessible.
    location ~ \.php$ {
        return 404;
    }

    error_log /var/log/nginx/symfony_error.log;
    access_log /var/log/nginx/symfony_access.log;
}

And just a suggestion maybe it might be good to define the domain in .env file.

Also it might be a good solution to bind a volume for root user folder in php container for persistant .bashrc, custom bin folders and global node_modules. (- ./root:/root)

This is the far best container based on standard images instead of unsolicited personel images. Thanks.

@danabrey
Copy link
Author

danabrey commented Dec 30, 2017

I've seen a lot of recommendations for using .test instead of .local, because:

  • .test is reserved and won't ever be given the same treatment as .dev
  • .local clashes with Bonjour

@maxpou
Copy link
Owner

maxpou commented Jan 31, 2018

Hi, forgot to mention but this stack now uses symfony.local (since #90). HSTS isn't a problem anymore.

@danabrey can you tell me a bit more about this?

.local clashes with Bonjour

@danabrey
Copy link
Author

danabrey commented Feb 7, 2018

hostname.local gets resolved to local private network IPs on MacOS and most Linux distributions, so there's a possibility of clashes if a machine existed on one's local network with the hostname symfony. Unlikely, but possible.

https://en.wikipedia.org/wiki/.local

@Matts
Copy link

Matts commented Apr 17, 2018

I've created a Symfony 4 API Boilerplate with this repo, it still needs a little work on automation/setup but in the meantime it can be found at https://github.com/Matts/Symfony-4-Docker-API-Boilerplate

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants