Easier handling of context variables

Using Neos & Flow Installation & Deployment
1

This is a bit of a red carpet issue. If you are new to PHP software at that complexity level you might probably have never heard of environment variables. That’s probably even the case for the ordinary developer who doesn’t know about Apache, Nginx configuration and stuff.

How to set FLOW_CONTEXT depends on the webserver you use and that barrier should be lowered.

I’m thinking of introducing dotenv as an additional possibility to set those global variables. This concept is originally used in Ruby on Rails, but also Laravel already adopted this concept. That would make it easy for developers without knowledge of webservers to getting started with Flow and we could set this configurations independent of the used webserver.

What do you think about that?

1 Like
2

Hey Hans,

totally makes sense for me :slight_smile: So +1 from my side!

All the best,
Sebastian

3

The JIRA ticket for that is FLOW-389 and I’ve already created an implementation for testing that, see the Pull-Request.

4

TBH my immediate thought was: “Developers that don’t know about environment variables? Rly?” I mean, they exist since the 60s (I’d guess) and have even been around in DOS as well as Windows all the time.

So, for me that “dotenv” is something unknown and adds additional complexity. Just saying…

5

I don’t have a strong opinion towards this change, but I must say I share Karstens concerns… Not only does it add (a little) complexity, but a new dependency, possible performance & security issues. Especially given the fact that one can also tweak the index.php (like jweiland.net used to do it for their Flow installations) if setting an env variable isn’t an option…

6

Well actually I would neather call them developers. Sorry that was the totally incorrect term. Let’s just say users, that want to install Neos and try it out. They can download a zip file and unpack that. Probably they are able to change the DocRoot (but unfortunately many people don’t) but if they want to try Neos with the speed of a production environment, at that moment they need to know about environment variables.

And it’s not complexity as it’s just optional and it should make it easier.
I’m even thinking about adding a button to the last setup step which creates the .env file containing the production settings. And that’s definitely a red carpet issue.
I already created a pull request that adds at least the hint for the application context to the last setup step with a reference to the documentation.
But that requires the user to read the documentation and set the environment variables according to the webserver he uses. (Probably it’s not possible to override the variable with .htaccess SetEnv in his case)

We want many users to try out Neos and make it easy for them.

7

Good point indeed. But if it’s just about the application context, we could also add that functionality w/o relying on a new library (that is simple enough but allows for much more than what we actually need).
E.g. we could check for a file .context during bootstrapping

8

This could be as simple as replacing

$context = getenv('FLOW_CONTEXT') ?: (getenv('REDIRECT_FLOW_CONTEXT') ?: 'Development');

by

if (file_exists($rootPath . '/.context')) {
	$context = file_get_contents($rootPath . '/.context');
} else {
	$context = getenv('FLOW_CONTEXT') ?: (getenv('REDIRECT_FLOW_CONTEXT') ?: 'Development');
}

in index.php.

9

Just realized this is in the dotenv documentation (emphasis mine):

phpdotenv is made for development environments, and generally should not be used in production.
In production, the actual environment variables should be set so that there is no overhead of loading the .env file on each request.

10

I totally agree. It should not be necessary to use that on your production server, because of the overhead. But as I implemented it, it just checks for the existence of the file and then loads it.

But in the end there are so many files that are read and loaded by Neos / Flow that one more wouldn’t have a big influence.

It should really be optional to provide the possibility to do this more easily when trying it out.

But maybe Christian will say some other things he had in mind today for what that would be useful.

11

Sorry, I wasn’t aware of this thread and thus commented on Github. I think that, if a pull request exists, we should generally discuss code there, what do you think?

Anyway, I left another comment with a suggestion there.

12

You all speak only about index.php but what about command line? I find it rather dangerous to suggest manipulating the index.php, TBH checking for one file will not add any overhead that we cannot save in a dozen other places.
I still think this would be a valuable addition (and yes then using the library suggested).

I see it again as something becoming standard and modifying core files seems never a good idea even if as small as the index.php.

13

The driving force behind this is probably:

On the CLI you can just use an environment variable and there is no doubt as to how to set it. Then again, if you have never heard of environment variables–but I’ve been there in this discussion already…

I stll think that this adds another option to work around a problem with an existing option that isn’t really a problem. You just exchange one for the other. YMMV.

That being said, I’d not veto against this, given the current approach (check for file, else nothing) is taken.

14

My point was that using a 3rd party library only to ease changing the application context seems like an overhead.
Sub-requests will inherit the context of the web request anyways - and for “real” CLI requests we currently ignore the context specified in .htaccess, too.
Anyways, I think we’re on the same track: We could put it in a separate file and check it when bootstrapping Flow. Whether or not we want to extend that to CLI requests is a different question I’d say.

15

I think it can be useful for things like FLOW_PATH_ROOT, FLOW_PATH_TEMPORARY etc. etc. so not only context.

16

Mh, we currently use environment variables for those and I think that’s a good choice… We could change that, but having two concurring mechanisms is confusing and error-prone…
Now for the application context I see that we might need an alternative way in order to make it easier to use Neos even if you’re not familiar with servers (or have limited access)…
But changing root/temp paths - is that really an issue for those cases?

17

IMO: Either we do that for all environment variables, or not at all. Anything else would be inconsistent and error prone. On top of that, we do it for all requests, or not at all.

18

IMO: Either we do that for all environment variables, or not at all.
Anything else would be inconsistent and error prone. On top of that, we
do it for all requests, or not at all.

That’s what I would expect of this change.

19

Can we continue here and decide something? I still feel this is a useful change if we use it for all possible env variables.