Compiled templates have full paths (instead of relative)
I was trying to precompile my templates using php artisan optimize --force on a staging server before deploying to the live server.
However, I noticed that the full path name is included in the compiled templates:
- in the comment at the top of the file (which isn't important),
- in calls to
$this->env->loadTemplate(...)withinblock_XXXX()methods, and - in the
getTemplateName()method
So, I'm thinking that this isn't a good thing as far as precompiling on one server/directory then deploying to another.
Any way to force all those paths to be relative to the views folder, or somewhere else?
This is using 0.6.1, BTW. Another project here uses 0.5.2 and the twig:compile command, and the generated files use relative paths.
Does the template name affect your code? Can you show an example how this would cause problems? Is it by using the view composers? Those should be normalized by https://github.com/rcrowe/TwigBridge/commit/e41d9dfc5c10c5c1fc2fc92d5dd77a3077715852
I'm guessing the template name won't matter too much (but I don't know very much about Twig's or TwigBridge's internals to be sure).
My main concern are the parts of the compiled template like:
public function block_hero($context, array $blocks = array())
{
// line 9
echo "\t";
if ((twig_template_get_attributes($this, (isset($context["paginator"]) ? $context["paginator"] : null), "currentPage", array(), "method") == 1)) {
// line 10
echo "\t\t";
$this->env->loadTemplate("/home/admin/domains/staging.example.com/app/config/../views/front/home.twig", "318517247")->display(array_merge($context, array("hero_style" => "hero-home")));
// line 11
echo " ";
}
}
// ...
public function getTemplateName()
{
return "/home/admin/domains/staging.example.com/app/config/../views/front/home.twig";
}
Does that call to $this->env->loadTemplate() actually look in that path for the template file, or is that just a string name (matching the values returned by getTemplateName()) that's used for lookup?
And yes, I am using view composers extensively, and I do refer to my templates (in View:make() calls and within template embeds, etc.) as "front.home", and not with full paths or with a ".twig" extension.
Thanks!
The internal template name doesn't matter that much, but I'm looking into making the view names more consistent. Problem is that the View::make() just passes the full path instead of the name, so I can't really pass the name on.
Ok, so just to confirm that this line:
$this->env->loadTemplate("/home/admin/domains/staging.example.com/app/config/../views/front/home.twig", "318517247")->display(array_merge($context, array("hero_style" => "hero-home")));
That's not really a file path that's being loaded. It's just a string name used to identify a template, right?
No that is the path of a template that's loaded, probably not the path of that template, but the parent, block or some include.
Oh. So it doesn't look like I can compile the templates on my staging server and then sync them to production. :disappointed:
No don't think so. Op 9 okt. 2014 18:11 schreef "Colin Viebrock" [email protected]:
Oh. So it doesn't look like I can compile the templates on my staging server and then sync them to production. [image: :disappointed:]
— Reply to this email directly or view it on GitHub https://github.com/rcrowe/TwigBridge/issues/154#issuecomment-58533744.
FWIW, we've got other projects here using the 0.5.2 version of TwigBridge, and they run artisan twig:compile to pre-compile templates. The resulting files only contain relative URLs instead of absolute ones like I posted above.
I'll look at this in #155
Ok, thanks! Feel free to close this if you want, then. :)
FYI, the #155 PR "fixes" the issue I was having in that calls to $this->env->loadTemplate(...) are now using a normalized name instead of the full path.
The compiled templates still have a getTemplateName() method, which returns the full path. But does that method get called anymore? I really only see it in getParent().
I'm still hoping to compile templates on a staging server. If getTemplateName() returned a relative/normalized path, and anytime that value was used to actually load a file it was "denormalized" to a full path, I think that would allow for this. Or am I misunderstanding things?
Hmm, that PR should fix the events but not sure if that also fixes the compiled path.
In my template I have something like this:
$this->parent = $this->env->loadTemplate("twig/base.twig");
Not sure why yours is showing the full path.
Inside my templates' doDisplay() method, I have calls to fixed templates name. e.g.:
$this->env->loadTemplate("front.single.partials._media_icons");
However, some of my templates have getTemplateName() using the full path:
public function getTemplateName()
{
return "/Users/admin/Documents/workspace/domain.local/app/config/../views/front/user/lost.twig";
}
and some have relative paths:
public function getTemplateName()
{
return "front.user._tos";
}
I did a artisan twig:clean and then artisan optimize --force, so I'm pretty sure I'm not looking at old compiled templates.
Okay but I don't think getTemplateName() is used to load. But not really sure.
Looking a bit more ... some templates are still using full paths for $this->env->loadTemplate(...).
I'm having a hard time finding a pattern that might figure out why this happens ... although it seems to only happen in compiled templates that end up with multiple classes defined in them. (Sorry, I don't know enough about the internals to know why this happens). In these cases, it seems like the first instance of the class uses the full path names, but the second one uses normalized names.
Maybe this has something to do with calls to {% embed ... %}. That's the only thing I think is common amongst the weirdly behaving files.
Hi. Today I've noticed that I was having full paths also. In a blank project, it happens to me when I add Twig_Extension_Debug to the enabled extensions lists. Without it, the getTemplateName is already normalized "partials.partial_a"
I noticed this issue while using view composers. I was/am getting partials/partial_a instead of partials.partial_a while calling $view->getName() inside the composer compose method.
Maybe getNormalizedName should replace / by . during the normalization process
That is what I suggested in #155 Can you try that and continue discussion there?