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.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a whole bunch of twig files with a ".html" extensions (i.e., "structure.html").
These files are in a directory hierarchy, and many include or extend others.
These were built prior to my adopting Laravel, and so all the calls to include or extends specify the full filename and directory (relative to the template base directory).
Example: {{ extends 'main_themes/structure.html' }} etc., etc.
I would like to ditch all the fancy laravel magic of specifying view names without file extensions, and just be able to specify full file names with extensions, so all the templates don't have to be reworked. (These template files are in a library that is also shared by code that isn't coming out of laravel, and thus needs to specify full filenames; I'd like to continue to share the code this way).
I can get around this by loading the Twig environment myself directly,, but then I don't get the benefit of all the extensions and Laravel functions that TwigBridge automatically includes, as well as its automatic injection of certain data into the views.
Is there any way to achieve this?
I'm aware of using View::addExtension('html', 'twig');
which lets me use both .html and .twig files and load them with laravel view functions and inside the templates (without the extension), but this still doesn't let me just leave the full filenames in there.
I also tried
'View::addExtension('', 'twig'); (adding an empty string as extension), but that didn't seem to work, nor did escaping the dots with backslashes (return view('main_themes/theme.html');`, etc.).
(N.B. I have found that using a '/' as directory separator instead of a dot ('.') does work; which is nice, and useful, but still doesn't solve the problem.)
The text was updated successfully, but these errors were encountered:
I'm pretty sure I just did a workaround, bypassed using the TwigBridge and just called Twig views manually, using the Twig class directly (e.g., Twig->render(...)) ... doesn't give me the Laravel magic (vars and such) in the views, but I can pass what I need into the view manually, just like I'm used to doing when using Twig in non-Laravel contexts.
Thanks for your input, though; haven't dug deeper in quite a while.
Hello,
I have a whole bunch of twig files with a ".html" extensions (i.e., "structure.html").
These files are in a directory hierarchy, and many include or extend others.
These were built prior to my adopting Laravel, and so all the calls to
include
orextends
specify the full filename and directory (relative to the template base directory).Example:
{{ extends 'main_themes/structure.html' }}
etc., etc.I would like to ditch all the fancy laravel magic of specifying view names without file extensions, and just be able to specify full file names with extensions, so all the templates don't have to be reworked. (These template files are in a library that is also shared by code that isn't coming out of laravel, and thus needs to specify full filenames; I'd like to continue to share the code this way).
I can get around this by loading the Twig environment myself directly,, but then I don't get the benefit of all the extensions and Laravel functions that TwigBridge automatically includes, as well as its automatic injection of certain data into the views.
Is there any way to achieve this?
I'm aware of using
View::addExtension('html', 'twig');
which lets me use both .html and .twig files and load them with laravel view functions and inside the templates (without the extension), but this still doesn't let me just leave the full filenames in there.
I also tried
'View::addExtension('', 'twig');
(adding an empty string as extension), but that didn't seem to work, nor did escaping the dots with backslashes (
return view('main_themes/theme.html');`, etc.).(N.B. I have found that using a '/' as directory separator instead of a dot ('.') does work; which is nice, and useful, but still doesn't solve the problem.)
The text was updated successfully, but these errors were encountered: