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

[DX] Replace app and app_dev.php with .env #1049

Closed
CoolGoose opened this Issue Feb 28, 2017 · 17 comments

Comments

Projects
None yet
6 participants
@CoolGoose
Copy link

CoolGoose commented Feb 28, 2017

Currently symfony uses two separate php files for entry points into the application.
This seems to be an initial confusion point for new developers trying to adopt symfony and a possible security issue if you don't remove your app_dev.php from git when doing live deployments.

Other PHP frameworks recommend different methods that might be cleared for the end user:
1. Zend uses a developer mode cli trigger .
2. Cake recommends using php-dotenv
3. CodeIgniter recommends using SetEnv .
4. Didn't find anything clear on the Yii documentation, maybe I'm missing it :)
5. Laravel uses .env files

Considering the recent [.env file support](http://symfony.com/blog/new-in-symfony-3-3-dotenv-
component) in symfony 3.3 going with a single app.php that switched based on the .ENV will make it easier to onboard on Symfony and allow make it easier to split development from production code.

@Pierstoval

This comment has been minimized.

Copy link
Contributor

Pierstoval commented Feb 28, 2017

I would also propose to merge app.php and app_dev.php, which is something that's done in many recent Symfony apps, but I'm note sure this proposal is good for a Symfony-newcomer point of view.

It has an impact when installing Symfony, and introduces something (environment variables) which is by default detached from the application, and most of the time depends on the platform itself.

Imagine a full class of students installing a new Symfony standard edition on their school machines, having to setup a webserver, etc., when they're not devops and they don't know that they have to setup a .env file complementary to the app/config/parameters.yml file that is created by the Symfony installer.

This might make the application not ready-to-run, and if you have, like laravel, a default .env.dist file for instance, even if this file is processed by the installer and that parameters.yml looks for environment vars, this makes the thing counter-intuitive: newcomers would ask "Why we use env vars in a non-versioned file, and load these env vars in another non-versioned file?".

For experienced developers this might have become clear that env vars are nice, but for beginners, sometimes, even the concept of environment vars is not clear.

@CoolGoose

This comment has been minimized.

Copy link
Author

CoolGoose commented Feb 28, 2017

@Pierstoval the problems that i experienced in our in house development team with developers that have at least two years of experience is that often times, especially compared to the old frameworks, they forget about having to go to app_dev.php to do development work and are confused initially.

I agree that the experience varies from developer to developer, but the overall strategy in the PHP frameworks land seems to go towards having .env files for easier management and not polluting git with real config files.

Also having app and app_dev.php makes it harder for newcomers to actually have an easy way of doing dev -> qa/staging -> live setups since it would imply an app_qa.php

@Pierstoval

This comment has been minimized.

Copy link
Contributor

Pierstoval commented Feb 28, 2017

Having an app_qa.php file totally makes sense if you make your tests on a QA platform and you want to add specific configuration for CI, load other services for logging, hardcode some tokens or tools in config_qa.yml, etc.. Some companies I worked for added this kind of environment and this was for a very good reason, not just to have app_staging.php.

The presence of app.php and app_dev.php is a good introduction for newcomers to explain the concept of environment in the Kernel (even though the debug part is harder to explain).

Having different environments explicitly defined in specific files is important for basic understanding of the framework and the structure of the Standard Edition.

I'm mostly talking for the many students I had that, even if they sometimes mistake by opening app.php instead of app_dev.php, had a complete understanding of the difference between both files, and they know that by definition that one file is dedicated to their machine, and the other one to the production server.

Moving the standard edition to environment vars seems overkill to me. A simple documentation page "Merge your web entry points with environment vars" or blog article is fairly enough and can explain in a few lines what it is.

We should also take in account that each platform is different. Some (like me for example) will not use any .env file. I prefer to make my parameters.yml file load environment vars and put these env vars in my apache/nginx vhost. It's just a matter of taste, but hey, if this env file was used by default I would've had to do the same than if it wasn't: override the application to fit my needs. And my needs are not what newcomers and learners need.

It is hard enough to teach about Symfony, let's not make the most plug-and-play Symfony edition harder to understand for students 😉

That's my opinion 😄

@garak

This comment has been minimized.

Copy link

garak commented Apr 11, 2017

There's no need to "go to app_dev.php to do development work". Just use console server:run (or console server:start) and you're done.

@Pierstoval

This comment has been minimized.

Copy link
Contributor

Pierstoval commented Apr 11, 2017

@garak not everyone want to use built-in PHP server which is not easily configurable. Some guys want to use docker, some others want an apache or nginx server, some want something different.

"Just do this" is not an argument 😉

@garak

This comment has been minimized.

Copy link

garak commented Apr 11, 2017

If you really want to use apache, just use app_dev.php as DirectoryIndex. I'm not an expert in nginx, but I'm sure there's a similar option.

@Pierstoval

This comment has been minimized.

Copy link
Contributor

Pierstoval commented Apr 11, 2017

@garak No, either for apache or nginx, for this you have to change the .htaccess (for apache) or the vhost itself (for nginx). All of this is not "plug-and-play"-able.

And in the case of Apache, removing the .htaccess and copy/pasting its content into apache's vhost is part of the best practices, to avoid Apache reading the .htaccess file on each request

=> http://symfony.com/doc/current/setup/web_server_configuration.html

@fabpot

This comment has been minimized.

Copy link
Member

fabpot commented Apr 11, 2017

I'm closing this issue as we won't change Symfony SE. But Symfony Flex is going to have just one web front controller, so that will be fixed there.

@fabpot fabpot closed this Apr 11, 2017

@Pierstoval

This comment has been minimized.

Copy link
Contributor

Pierstoval commented Apr 11, 2017

And Symfony Flex will recommend the use of environment vars, so we're set 😆

@martijn80

This comment has been minimized.

Copy link

martijn80 commented Nov 27, 2018

Hi guys, in symfony 2 and 3 I really loved the fact that I could quickly switch from app.php to the app_dev.php (for my IP address only) variant of an url on my production host to investigate some slow queries in the web profiler or some exceptions/logs, etc. I really miss this feature in symfony 4.

(Yes I know i could just look add the mysql slow query log, but I really liked the fact that all queries from the current page were beatilfully summed up and could read response/request vars and exceptions logs from the web profiler as well)

How can I accomplish this with the .env setup in symfony 4?
How should you quickly (and only for a certain/my ip address) switch to a dev env for a given production url?

I was thinking about creating a separate vhost (like dev.example.com) and set the env to dev there, but this isn't really the most developer friendly experience is it?

What would you recommend? Or am I missing something?

@Pierstoval

This comment has been minimized.

Copy link
Contributor

Pierstoval commented Nov 27, 2018

I don't see the point of having prod env in your machine, as your machine is the dev one. If you need a prod env that is not the real prod, you can use docker-compose and run twice the same service with different env vars, or you can use platform-as-a-service (PaaS) like Heroku or others to run a small pre-prod app.

@martijn80

This comment has been minimized.

Copy link

martijn80 commented Nov 27, 2018

Hi pierstoval, thanks for you reply. I guess my question wasn't clear (or I didnt understand your answer). So I edited my comment a bit. But let give me an example.

I have a live symfony 3.4 project here :
https://example.com/some/route (running via the app.php frontcontroller offcourse)

Some error occurs or I want to look into the web profiler quickly, so I just change the url to : https://example.com/app_dev.php/some/route (I've whitelisted my IP in app_dev.php so now I see the profiler).

You see how easy this was? I'm struggeling to find an easy way to do this in symfony 4 with .env.
Your suggestion (if I understand correctly is about making a complete copy of the website, which misses the point because I want to see the profiler (and exceptions) for the exact site (code, content and db) that is live.

@Pierstoval

This comment has been minimized.

Copy link
Contributor

Pierstoval commented Nov 28, 2018

Using app_dev.php in prod is not recommended, as it can expose the app's configuration and phpinfo (and more depending on the installed bundles).

Even using app_dev for a few seconds could be crawled by lots of existing bots (I had the case for my project before moving to SF4 a year ago), I even saw a webzine crash because app_dev was exposed for an hour, possibly accidentally.

If you want more details, I'd suggest you use an external tool like Sentry with Monolog to report the errors to an external app (that's what I do for my projects), then you'll have all details (stack trace, etc) available on your private dashboard, and you can debug without having to open a fragile door to your app.

But I understand that app_dev is easier. If you really need this, you can implement such feature easily by mimic-ing the old behavior of the app_dev file in your own custom web entry point, I don't think it should be a big deal for you to copy/paste the .env file into a .env.dev and just change prod to dev and enable debug..

@martijn80

This comment has been minimized.

Copy link

martijn80 commented Nov 29, 2018

Hi Pierstoval, I know it's not recommended (and thats why I whitelist only my IP in app_dev.php). But it's way easier then setting up sentry and be dependent on more tools (more points of failure and more maintenance) and since this issue is about Developer Experience (DX) I was hoping SF4 had a similair easy way.

I guess making a copy of Symfony 4 index.php to profiler.php and then setting the env vars to dev and debug true (and blocking all ip's except my own) is the easiest option for now.

Too bad one of the killer features of Symfony (the developer toolbar), isnt more easily available. Hopefully someone else will read this issue and maybe add other ways.

Cheers for now.

@stof

This comment has been minimized.

Copy link
Member

stof commented Nov 29, 2018

the Symfony developer bar has never been meant to be accessible in production.

@fabpot

This comment has been minimized.

Copy link
Member

fabpot commented Nov 29, 2018

It's even stronger than that: NEVER EVER use the profiler in production, that's a huge security risk.

@martijn80

This comment has been minimized.

Copy link

martijn80 commented Dec 1, 2018

Hi @stof and @fabpot thanx for stopping by. Could you give a better (developer friendly and secure) alternative? What is in your opinion the best way to view (or profile) a live application?

I know of Blackfire (experimenting with it right now).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
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.