Environments

Hey Szabolcs

IIRC from flex recipe changes this change was made from version 5.1. Default kernel was simplified to use only YAML or PHP configuration, so if you want to use XML you need to implement it by yourself.

Cheers!

triemli

That's odd. Can you double-check that APP_NAME does not contain any white space at the beginning or at the end of the string? Another thing to try is to not use the processor for a moment and update your variable to Frontend, let's see if by doing that change it works, if it works it would mean that the processor is doing something odd. You can set the result into a parameter and dump it to see what's actually returning

Cheers!

I tried to use it from scratch: i got an error:
There are no registered paths for namespace "__main__".
Somehow need to say for twig this path.
But idk why, if I specified default_path in twig config.

Hey triemli!

Hmm. So, in some cases, you can't use an environment variable for a piece of config, and I think this might be one of those situations. The problem is that, in order for the env vars to work, Symfony must not "resolve" the values during container builder. Basically, your container is built just once when you deploy, and the dumped container (in an ideal situation) will container (basically) getenv('APP_NAME') so that when Twig is instantiated, it gets the current environment variable. In some cases, however, Symfony needs to actually "resolve: (and get the final value) of an environment variable during the build process. That's what's happening in this case.

I'm actually not sure that this is needed... it could be a bug. But basically, the value is "semi-resolved" (to this internal placeholder value) during container build and then Symfony checks to see if that directory exists (using this semi-resolved, internal hash value). It doesn't, so it simply doesn't even add that path to Twig at all. This maybe smells like a Symfony bug to me.

But, let me say 2 more things:

A) First, I think you can work around this by adding a Twig namespace path instead of overriding the default:

twig:
    default_path: '%kernel.project_dir%/templates'
    paths:
        '%kernel.project_dir%/%env(APP_NAME)%': 'App'

You would render things as @App/path/to/file.html.twig. The only caveat I'm aware of is that whatever APP_NAME is set to when you are deploying, that directory will need to exist (else the container build will fail).

B) Second, what you're trying to do may work, but the system isn't really meant to be used this way. For one, the Twig path is normally read at "compile time" so that Symfony can "cache warm" the Twig templates: pre-compile them so that they're not compiled at runtime on the first request. You would be opting out of that. Another solution to all of this would be to wrap Twig in a custom service, give that customer service a render() call, and then your service pre-fixes the APP_NAME value when rendering. The only catch is that the default_path (or at least one of the paths would need to point to a directory that contains ALL the templates. So, in your example, it would probably need to point to src/. Then, when rendering in a controller, you might pass default/homepage.html.twig to your custom service. It would then change that to be Frontend/templates/default/homepage.html.twig.

Anyways, it's a bit messy in all directions to have things this dynamic. Another option, if you have a "set"/static number of possible APP_NAME values, would be to create one twig namespaced path (that's the paths config again) per possible value - e.g. one for "Frontend". Then, your custom service would just prefix the paths with @ then the value of APP_NAME then the path that was passed to it (e.g. <code<default/homepage.html.twig`).

Cheers!

Thanks @weaverryan for the great answer!
I tried this configurations:

`twig:

default_path: '%kernel.project_dir%/src/%env(ucfirst:APP_NAME)%/templates'
paths:
    '%kernel.project_dir%/src/%env(ucfirst:APP_NAME)%/templates': '__main__'

`

And it works!

Basically I have this approach of multi application architecture:

https://github.com/yceruto/symfony-skeleton-vkernel/blob/master/src/VirtualKernel.php#L65

So that's why I need dynamic load. Based on APP_NAME we are load "right" configuration. In src folder many folders like <i>Frontend</i>, <i>Backend</i>, <i>Publisher</i>, <i>Landing</i>, <i>Api</i> etc...

Becuase of this all apps use the same entities, services and database. So copy-paste those big entities in separated symfony apps would be cold idea. Every even a small changes in 1 entity would require to remember fix <b>all </b>the projects.

The only what I affraid a bit about twig cache. It need to be separated too.

Hey triemli!

Nice! About the Twig cache warming, it will probably be fine without it - I just don't have any experiencing with using a system where it's not "warmed up". But it's probably not a big deal. But again, if you have a "finite" number of APP_NAME (i.e. it's not a dynamic value where a new one could be added to the database, for example), then you could have the "best" of both worlds by creating one twig "path" per possible app name - e.g.

twig:
    # ...
    paths:
        '%kernel.project_dir%/src/Frontend/templates': 'Frontend'
        '%kernel.project_dir%/src/Backend/templates': 'Backend'

... and then read the APP_NAME in a custom service that prefixes the @ and then the APP_NAME env var. The downside is that, whenever you render a template, you need to call your service instead of Twig directly (but you could create a custom controller that overrides the render() method and calls your service instead.

Cheers!

weaverryan yeah, I will check how it will work in real project and maybe also try with override render() method. Also nice idea! Thanks a lot for advise!