Problem/Motivation
The Twig engine provides options for configuring debugging, automatic reloading (recompiling) of templates, and caching compiled templates in the filesystem. The core implementation of Twig supports these options but they are currently hardcoded and cannot be overridden by developers. These are the defaults in core:
debug: TRUE
auto_reload: FALSE
cache: TRUE
Enabling debug should also implicitly enable auto_reload unless auto_reload is set to FALSE. Having auto_reload default to NULL is Twig's default behaviour and would make more sense to folks who are already familiar with Twig.
Proposed resolution
Originally a UI solution was proposed, but since these settings are used by developers and will likely be different per environment, settings.php configuration was determined to be a better solution.
The patch adds three new settings (twig_debug, twig_auto_reload, twig_cache) to settings.php to control these Twig environment options and uses the Settings API to access this information when building the Twig environment.
The proposed patch also makes auto_reload match Twig's implementation and documentation, so that enabling debug also enables auto_reload unless a value is specified for auto_reload.
Remaining tasks
Review the latest patch.
User interface changes
None
API changes
None
Original report by japerry
in TwigFactory.php , autoreload is hardcoded to TRUE. We should be listening to the performance settings page instead.
| Comment | File | Size | Author |
|---|---|---|---|
| #77 | 1843034-77-test.patch | 4.35 KB | star-szr |
| #77 | interdiff.txt | 712 bytes | star-szr |
| #64 | 1843034-63-test.patch | 4.32 KB | star-szr |
| #63 | 1843034-63-test.patch | 11.15 KB | star-szr |
| #63 | interdiff.txt | 1.5 KB | star-szr |
Comments
Comment #1
japerryPer conversation with CHX and FabienX -- we've made a new twig page under performance that allows the setting of three variables:
'twig.debug.enabled'
'twig.debug_verbose.enabled'
'twig.autorefresh.enabled'
It also sets these variables in the TwigFactory in initializing twig.
Comment #2
japerryComment #3
fabianx commentedPer IRC: In twig.engine please do output the
<!--only if debug_verbose is set. Thanks!Comment #4
japerryadd the verbose flag check before rendering the twig templates.
Incorporates changes from the first patch, use this one instead.
Comment #5
c4rl commentedJust to clarify, I believe filter.module on d.o stripped out info from comment #3, it should say "do output the
<!--only if debug_verbose is set"Comment #6
fabianx commentedPlease commit.
Comment #7
fabianx commented*FIXED* here:
http://drupalcode.org/sandbox/pixelmord/1750250.git/commit/6e1c158d8304e...
Comment #8
fabianx commentedTagging for move to core with "Twig engine"
Comment #10
steveoliver commentedMoving this from Twig sandbox to core queue. Attached patch adds admin settings for Twig cache, debug, and autorefresh options.
Comment #12
steveoliver commentedFatal error: Call to a member function get() on a non-object
Ah, $config is not available yet...
Hmm... Ideas?
Comment #13
steveoliver commentedI'm guessing this is related to #1873442: Refactored core Twig integration
Comment #14
c4rl commentedLet's try this one
Comment #15
c4rl commentedNevermind, sorry.
Comment #16
gddIs it really necessary that these settings are available in the UI? If that requirement can be removed, these would be good candidates either for inclusion in $conf[] or in the new settings() API - #1833516: Add a new top-level global for settings.php - move things out of $conf
Comment #17
c4rl commentedYeah, giving this some thought it seems that these settings pertain to developers, who have access to the codebase, and will vary per-environment. Providing an UI is an anti-pattern.
So can we refactor this for a non-UI solution?
Comment #18
gddThis is untested and the comments need help, but conceptually this is how it should look.
Comment #19
gddAlso, while I saw where it gets set, it appears the the verbose setting doesn't actually get checked or used anywhere?
Comment #21
gddThis new patch restores the update_free_access variable which I had accidentally removed in the last patch. The last test run was (hopefully) canceled.
Comment #23
steveoliver commented@heyrocker: you're right, the verbose setting doesn't affect anything currently, but it's used to print the list of theme hook suggestions in the debug comments. Will integrate into patch here after finishing in sandbox -- hopefully in the next hour or so.
Comment #24
steveoliver commentedThis is the extent of which I'd currently like to use Twig settings. I've removed 'debug_verbose' and instead always output all debugging information. Also, I've changed the setting names to reflect the names of the primary Twig options they affect. Thanks for your help, heyrocker. Let's see if it'll install.
Comment #25
steveoliver commentedComment #26
gddActually, since all calls to these use FALSE as a default, you can just comment them out. That is what most of the other things in $settings do.
It is probably worth adding tests for these too.
Comment #27
gddComment #28
star-szrGoing to try writing some tests for this.
Comment #29
fabianx commentedI do not totally agree with that change (though I can without problems live with it) and the reason is performance.
Twig will hopefully be used for everything themed on the site and the compilation cache is an important asset here.
If you recompiled for each row, for each block, foreach breadcrumb, etc. this could be many many compilation runs and it could be slow.
Maybe however twig_debug should imply twig_auto_reload instead. The result is the same, but only for those templates that changed. Though then a note should be added that after enabling disabling twig_debug that the cache should be cleared.
I can see that someone wants to use twig_auto_reload however and not enable the debugging features. (in case of frequent deployments for example on a staging site). So keeping both options is a good choice IMHO.
Unrelated to this: We probably should create a patch to Devel 8.x to add the dpm, etc. functions as another TwigDevelExtension.
Besides that the patch looks good to me.
Thanks!
Comment #30
star-szrCrosspost :)
Comment #31
steveoliver commentedTo summarize the points by Fabianx in #29: Twig 'cache' setting will be set by $settings['twig_cache']; 'debug' by $settings['twig_debug']; and 'auto_reload' by $settings['twig_auto_reload'];
Also, FWIW: in this patch (or the one in #24), in addition to making Twig settings configurable, implements a check for the 'debug' setting to output debugging information around twig templates.
Comment #32
star-szrMade some progress on a test, the main issue I'm having is that the settings I'm overriding in my test methods are not being picked up by the Twig engine.
I did manual testing by changing my settings.php and that went fine, I did find that I needed to clear the cache so that the setting changes in settings.php took effect.
The settings are definitely being changed, I can check settings()->get() and see they are being updated. I've tried $this->resetAll() and even drupal_flush_all_caches() after $this->settingsSet() but that doesn't make any difference, nor does putting $this->settingsSet() into setUp(). I'm not sure if part of the issue is because Twig is loaded so early in the bootstrap, or maybe this is a DIC thing that I just don't understand yet.
Interdiff doesn't show the test being added, just the changes to other files from #24.
Comment #33
fabianx commentedHa ha, that is a nice way to put it, but more correct would be IMHO that the templates are recompiled from source each time they are used.
However given that there is static class caching, you could say that it is "stored" for the duration of one request.
Comment #34
steveoliver commentedShould we note the defaults?
i.e.
* Not recommended in production environments (Default: FALSE);
I'd edit to say:
"Render twig template."
I'd edit to say:
"The output generated by the template, plus any debug information."
Do we like our debug output?
Maybe we can extend this test and test that our FILE NAME SUGGESTIONS match our theme_hook_suggestions. On that note, I noticed some duplicates in theme_hook_suggestions. May want to check out http://drupal.org/project/issues/drupal?text=theme_hook_suggestions
Lastly, I think the settings should be in this order (logical to me): Cache, Auto-Reload, Debug
Comment #35
steveoliver commentedactually, they will always match theme_hook_suggestions -- guess i just wanted to point to the issues around theme_hook_suggestions, as they're relevant here.
Comment #36
star-szrIf anyone has any ideas for how to test this I'm all ears. I'll be taking another look at the tests tonight though. After sleeping on it I think the issue is that the Twig environment is initialized in bootstrap and by that time it's too late to change any settings except by settings.php. Need to confirm that though. I think other tests that use $this->settingsSet() are dealing with run-time settings that can be changed on the fly.
Rerolled to hopefully address most of #33 and #34.
Some comments on #34:
I went with "Renders a Twig template.", per http://drupal.org/node/1354#functions.
Looks good to me, but discussing that would be better handled in another issue IMO.
I can see putting auto-reload before debug, but it sounds like disabling the cache should almost never be done because it would be a big performance hit. If we put cache first, people might just disable cache and not even realize they can just turn on auto-reload. Leaving the order as is for now, let's discuss this a bit more.
Comment #37
star-szrGot a bit further on the test, the auto_reload test is passing but I'm still having trouble with the debug output test. It passes if I actually enable twig_debug in settings.php so the assertion is correct. Testbot can have a peek at this one.
Comment #38
star-szrAlmost forgot, huge thanks to @sun for telling me about
$this->rebuildContainer()in #drupal-contribute.Comment #40
star-szrThis is not fully testable to the extent I was hoping, for example I don't think we can test that the debug markup gets inserted or that cache files don't get generated when caching is off.
Spoke to @tim.plunkett and @chx on IRC tonight and the main issue is this: you can override settings in the current request via
$this->settingsSet()and$this->rebuildContainer(), but as soon as you do adrupalGet(), that's a new request and any settings overrides are gone since they are only stored in memory.So here's a test only and combined patch with tests for all three settings to the extent that I've found them to be testable. The test only patch should show 2 failures.
I tested all three settings in settings.php and they worked as expected, would like someone else to perform manual testing.
Comment #41
star-szrI'm going to add one more assertion each to the debug and auto_reload test methods, I don't like that they rely on the default values - the debug test method will currently pass because debug is currently set to TRUE in core.
Comment #42
star-szr#40: 1843034-40.patch queued for re-testing.
Comment #43
star-szrUpdated per #41, looking for 3 failures in the test only patch, one for each setting.
Comment #44
star-szrAfter talking to @Fabianx,
twig_auto_reloadshould default to NULL so thatauto_reloadis enabled whendebugis enabled. This makes our implementation match Twig's: http://twig.sensiolabs.org/doc/api.html#environment-optionsUpdated the default, added some more test coverage, and updated/tweaked default.settings.php to reflect this change.
Comment #45
star-szrRestoring disappearing tags.
Comment #46
fabianx commented#44: We should probably also add this information:
"debug: When set to true, the generated templates have a __toString() method that you can use to display the generated nodes (default to false)."
from Twig to settings.php in addition to our own debug markup.
Comment #47
star-szrWe discussed #46 in IRC and decided to update default.settings.php with a link to a (to be completed) handbook page with more information about debugging.
Comment #48
steveoliver commentedNitpick:
@see at the end of the comment block?
Comment #49
star-szrI could go either way on the @see, the standards don't dictate where it needs to be. I think it makes sense where it is.
Comment #50
steveoliver commentedCottser: Sounds good. I like that the production environment warnings are in the same place (last line) in all the docblocks.
As we discussed on irc Cottser, let's pull the theme hook / template suggestions debug output feature into #1906506: Twig settings implementation: Show theme hook / template suggestions in HTML comments. This way we keep implementation out of this config/settings issue.
Comment #51
steveoliver commentedAlso, re manual testing: #40, we don't need to worry about [manual] testing the *implementation* of the settings here, only that the settings are set and overriden properly. It's the job of the Twig extension to handle those settings properly.
Comment #52
star-szrJust updated the issue summary, here is a revised patch without the additional debug output.
Comment #53
star-szrPer #51, and since we're no longer worrying about the debug output in this issue, I think the test coverage is plenty.
Comment #54
star-szrDon't mind me, just fixing the name of the theme_test template file in a comment.
Comment #54.0
star-szrAdding issue summary
Comment #54.1
star-szrUpdating remaining tasks
Comment #54.2
star-szrUpdated issue summary.
Comment #55
fabianx commentedThis patch is close to RTBC, but this needs to be fixed first:
This comment now is wrong.
Lets use / copy the one from twig and fix the other issue to patch the debug output in as follow-up:
"debug: When set to true, the generated templates have a __toString() method that you can use to display the generated nodes (default to false)."
http://twig.sensiolabs.org/doc/api.html#environment-options
Comment #56
fabianx commentedI don't understand this change ... Why change only the comment?
Comment #57
star-szr#55: great catch. I've updated the comment to remove the part about additional debug output, I'd rather not put anything about
__toString()and non-Drupal "nodes" in the docblock though. I added a note about the 'dump' function, I think explaining debugging in depth is better explained in the handbook and I just drafted a new handbook page on debugging variables: http://drupal.org/node/1906780#56: the template filename is theme_test.template_test.html.twig, the array index in $templates is theme_test_template_test.
Comment #58
fabianx commentedLooks good to me, was tested manually, docs are correct now => RTBC
Comment #59
catchThere was a chmod change in the patch which I think I avoided. Committed/pushed to 8.x.
Comment #60
star-szr@catch: Thanks for noticing my accidental chmod, and thanks for the commit!
Comment #61
star-szrI just noticed the added test was missed in the commit:
http://drupalcode.org/project/drupal.git/commit/c05b5bf
Comment #62
star-szrBack to RTBC based on #58 to get the test committed :)
Comment #63
star-szrSlight tweak of the test to use the twig_extension() function.
Comment #64
star-szrThe patch in #63 incorrectly contains #1906506-21: Twig settings implementation: Show theme hook / template suggestions in HTML comments. Here is the correct patch.
Comment #65
fabianx commentedMore tests are seldom a bad thing, they pass as well => RTBC
Comment #66
podarok#63 looks good
+1 RTBC
Comment #67
star-szrThe patch in #64 is the patch to look at, even though I didn't rename the patch file.
Comment #68
dags commentedChange notice: http://drupal.org/node/1922666
Comment #69
podarok#68 looks good for me
Comment #70
star-szrTest in #64 still needs to be committed :)
Comment #71
podarokwoops
cross post
this #64 still needs commit
Comment #72
webchickWow, that was off my radar, sorry!
Committed and pushed to 8.x. Yay, tests. :D
Comment #73
xjmTwigSettingsTestis failing in HEAD, both on the bot and locally.Need to retest month-old patches before we commit them I think. :)
To roll this back:
Comment #74
webchickOops. :) I'll get this in about a half hour when I get home.
Comment #75
webchickOk, should be fixed up now. We'll need a (hopefully quick) re-roll of this one.
Comment #76
star-szrI'm on it.
Comment #77
star-szrRerolled for #1829224: Convert the 'theme_default' variable to CMI.
Comment #78
xjmOh, it was a simple thing after all. :)
RTBC if it passes.
Comment #79
podarokufo cleaned
Comment #80
podarok#77 +1 RTBC
Comment #81
xjm#77: 1843034-77-test.patch queued for re-testing.
Comment #82
fabianx commented#77: 1843034-77-test.patch queued for re-testing.
Comment #83
star-szrComment #84
alexpottCommitted d569e20 and pushed to 8.x. Thanks!
Comment #86
star-szrReverting title for posterity.
Comment #86.0
star-szrBetter wording.
Comment #87
michelleAdding a note in case anyone else ends up confused like me. The changes here to settings.php moved over to example.settings.local.php in #2226761: Change all default settings and config to fast/safe production values