Grav v2.0.0 Twig in content not processed

[beejay41]

I thought you'd cracked this one.

My first site (where all this started) has now migrated to V2.0.0 without issue. (Congratulations on V2 launch.)

So, now I'm migrating a second site, similar modular structure as with site one, but the missing images and {{ unite_gallery(...) }} have returned.
(I've added unite_gallery to the sandbox exceptions and there is no logs/security.log or generated comments, to give any clues.)

On site1, the page: process: twig: true is shown on every Page under Advanced tab, but not on site2, so for some reason page: process: twig: true in system.yaml is being lost or ignored, both in Admin and the front-end.

Default system.yaml
...
pages:
  process:
    twig: true
    markdown: false
  twig_first: false
  never_cache_twig: false
...

env:domain system.yaml has the same entries as above.

Default security.yaml
twig_content:
  process_enabled: true
  editor_enabled: false
  config_access: false

env:domain security.yaml
twig_sandbox:
  allowed_functions:
    ... (default list)
    - unite_gallery

I added the contents of the default security.yaml to the env:domain copy, but this made no difference.

[rhukster]

The thing that jumps out is that you're seeing no entries in logs/security.log. That's the real clue, and it tells us this isn't the sandbox blocking unite_gallery yet.

In Grav 2.0, Twig in page content has a master gate: security.twig_content.process_enabled. The old system.pages.process.twig: true no longer turns it on by itself, so if the gate is off, that setting just gets ignored (exactly what you're seeing). Both have to be true before any content Twig runs, and only then does the sandbox check the allowed functions.

Here's why the empty log matters. Grav logs in two places:

• If a page wants Twig but the gate is closed, you get a twig_content gate blocked line.
• If the gate is open and Twig runs but unite_gallery isn't allowed, you get a sandbox violation line.

You're getting neither. So on site two the content Twig is never even being requested, which almost always means your environment-specific config isn't actually loading for that site. A couple of things to check:

1. Confirm the effective value, not the file. In Admin under the config, or via bin/grav, check that security.twig_content.process_enabled actually reads true on site two. If it's false, your override isn't being picked up (wrong env folder for that hostname is the usual culprit).
2. You mentioned merging the default security.yaml into your env copy "without resolution." If that left any leftover merge markers or broke the YAML, the file fails to parse and silently falls back to defaults (where the gate is false). Run bin/grav yamllinter to be sure it's valid.

Once the gate genuinely reads true, load a page with {{ unite_gallery(...) }} and watch security.log. If you then see a sandbox violation, one more gotcha: twig_sandbox.allowed_functions is a plain list, so overriding it in your user/env config replaces the whole default list rather than adding to it. You need the full default list plus unite_gallery, otherwise core functions like url and t get blocked too.

One side note: your posted config also has markdown: false. If that's really in effect site-wide, it'll break normal ![](image.jpg) image rendering on its own, separate from the Twig issue, so worth double-checking that too.

Let me know what the effective process_enabled value comes back as and we can narrow it from there.

[rhukster]

Closing to tidy my inbox.. reply if you still have issues an i'll reopen.

[beejay41]

I've run bin/grav yamllinter - no issues.

I've disabled the sandbox - no change! All Twig in content of any page is not being processed:
<img class="gs_thumb transition" style="width: 100%;" src="{{url('user://thumbs/stories/thumbnail.the-wizard-leaves.jpg')}}" alt="The Wizard Leaves">
<div class="pull-left">{% include 'partials/facelike.html.twig' ignore missing %}</div>
<img class="gs_thumb transition" src="{{url('user://thumbs/stories/thumbnail.Chris_Lowe.jpg')}}" alt="Chris Lowe">

Please view: Test site (remove grav-2/ to see working original.)

The puzzle/frustration is that this is a working 1.7 site, which hasn't migrated successfully. The original wouldn't be working if system: page: process: twig: true were not set.

(I don't use/like markdown, so disabling it should give a performance improvement.)

[rhukster]

Good data point — disabling the sandbox with no change actually rules the sandbox out. In 2.0 there are three layers, and they run in order:

1. system.pages.process.twig → "process Twig in this page's content?"
2. security.twig_content.process_enabled → the master gate (NEW in 2.0, ships as false)
3. security.twig_sandbox.* → only filters individual functions once Twig is already running

Twig only executes in content when both 1 and 2 are true. The sandbox (3) can never leave a literal {{ url(...) }} in the output — it can only block specific functions after Twig is already running. So the fact that you see raw {{ }} and {% include %} on every page means Twig isn't running at all, which is layer 1 or 2 — not the sandbox. That's also why disabling the sandbox did nothing, and why you get no security.log line (Grav only logs a "gate blocked" entry when Twig is actually requested but denied).

The smoking gun is your own observation: on site1 the "Process Twig" toggle shows ON for every page's Advanced tab, on site2 it doesn't. That toggle is defaulted from the effective merged config, so on site2 the effective value really is false — meaning the files you edited aren't the config Grav is loading for that site.

So forget the sandbox for now and confirm the effective values in Admin:

• Configuration → System → Pages → "Process → Twig" should be ON
• Configuration → Security → "Twig content: process enabled" should be ON

If Admin shows either as OFF despite your YAML, the override isn't loading. Two usual causes:

• You're editing system/config/*.yaml (shipped defaults) instead of user/config/*.yaml — the user/ copy wins.
• Your user/env/<host>/ folder name doesn't exactly match the live hostname (chrislowestories.banjorinse.uk). The /grav-2/ subfolder doesn't change the host, so the env folder must be named for that domain.

Set both ON in Admin (which writes to user/config/, the copy that actually loads), then run bin/grav clear and reload. You should see the per-page toggle flip ON across the board, and your {{ url(...) }} / includes start rendering. Only after that does the sandbox matter — re-enable it and, if a function gets blocked, you'll finally get a security.log line telling you exactly which one to add (and remember the allowed_functions list is a full replacement, so include the defaults plus your additions).

Separately: markdown: false site-wide will stop ![]() images and inline markdown from rendering everywhere — keep that in mind, though it's not the cause of the Twig issue here.

[beejay41]

In Admin-2,

• Configuration → System → Pages → Process does not show Twig, don't think it ever does anymore
  • Default system.yaml pages: process: twig: does not exist
  • env:domain system.yaml pages: process: twig; true
• Configuration → Security → "Twig content: process enabled" shows ON

Curiously, if I set "Allow editors to toggle Twig in Content" ON, then all pages now show Process: Twig: true as default. I am admin.super, so that shouldn't make a difference and still isn't acted upon.

system/config/*.yaml all have the same datestamp and don't appear to have changed ( certainly no process: twig: true or otherwise there).
user/env/<domain>/ was created automatically by Grav 1.7 - if there was a typo, then I'd expect to see multiple env folders in user: once I start editing configurations, but there aren't, just domain and cli (which I assume is created by the Schedular Cron job on 1.7 and Migrated).

Still no Twig processing:

<img class="gs_thumb" style="width: 100%;" src="{{url('user://thumbs/stories/thumbnail.the-wizard-leaves.jpg')}}" alt="The Wizard Leaves">

ls -al ~/chrislowestories.banjorinse.uk/user/thumbs/stories/
total 332
drwxrwsrwx 4 www-data www-data  4096 Jun  5  2025 .
drwxrwsrwx 4 www-data www-data  4096 Feb 11  2021 ..
drwxrwsrwx 2 www-data www-data  4096 Feb 11  2021 photo-album
-rw-rw-rw- 1 www-data www-data  8032 Mar  6  2018 thumbnail.bd2-jan17.jpg
-rw-r--r-- 1 www-data www-data 13510 Jun  5  2025 thumbnail.bd2-jan17.jpg.webp
-rw-rw-rw- 1 www-data www-data  9487 Mar  6  2018 thumbnail.bromyard-50-mh3.jpg
-rw-r--r-- 1 www-data www-data 13530 Jun  5  2025 thumbnail.bromyard-50-mh3.jpg.webp
-rw-rw-rw- 1 www-data www-data  8287 Jan 29  2018 thumbnail.chris-lowe.jpg
-rw-r--r-- 1 www-data www-data  6234 Mar  5  2024 thumbnail.Chris_Lowe.jpg
-rw-r--r-- 1 www-data www-data  9964 Jun  5  2025 thumbnail.Chris_Lowe.jpg.webp
-rw-rw-rw- 1 www-data www-data 50469 Feb 28  2018 thumbnail.keep-calm.png
-rw-r--r-- 1 www-data www-data 10205 Mar  5  2024 thumbnail.Ron_Plant.jpg
-rw-r--r-- 1 www-data www-data 16096 Jun  5  2025 thumbnail.Ron_Plant.jpg.webp
-rw-rw-rw- 1 www-data www-data 11418 Mar  6  2018 thumbnail.speake-lowe-draw-partner.jpg
-rw-r--r-- 1 www-data www-data 17036 Jun  5  2025 thumbnail.speake-lowe-draw-partner.jpg.webp
-rw-rw-rw- 1 www-data www-data  6976 Mar  6  2018 thumbnail.spiders-web.jpg
-rw-rw-rw- 1 www-data www-data 17964 Mar  6  2018 thumbnail.the-wizard-leaves.jpg
-rw-r--r-- 1 www-data www-data 25626 Jun  5  2025 thumbnail.the-wizard-leaves.jpg.webp
-rw-rw-rw- 1 www-data www-data 15152 Jan 29  2018 thumbnail.unclejacksrainbow.jpg
-rw-rw-rw- 1 www-data www-data  1414 Mar  6  2018 thumbsm.bd2-jan17.jpg
-rw-rw-rw- 1 www-data www-data  1688 Mar  6  2018 thumbsm.bromyard-50-mh3.jpg
-rw-rw-rw- 1 www-data www-data  1630 Jan 29  2018 thumbsm.chris-lowe.jpg
-rw-r--r-- 1 www-data www-data  3058 Mar  5  2024 thumbsm.Chris_Lowe.jpg
-rw-rw-rw- 1 www-data www-data  7324 Feb 28  2018 thumbsm.keep-calm.png
-rw-r--r-- 1 www-data www-data  4179 Mar  5  2024 thumbsm.Ron_Plant.jpg
-rw-rw-rw- 1 www-data www-data  1912 Mar  6  2018 thumbsm.speake-lowe-draw-partner.jpg
-rw-rw-rw- 1 www-data www-data  1340 Mar  6  2018 thumbsm.spiders-web.jpg
-rw-rw-rw- 1 www-data www-data  2007 Mar  6  2018 thumbsm.the-wizard-leaves.jpg
-rw-rw-rw- 1 www-data www-data  2299 Jan 29  2018 thumbsm.unclejacksrainbow.jpg
drwxrwsrwx 2 www-data www-data  4096 Feb 11  2021 uncle-jacks-rainbow

It still comes back to why this site? I've rerun Migrations for site1 and it's perfect, so are 3 others I've now migrated (once I add unite_gallery to safe functions and tweak some xss options). Despite the modular structure, this is no different to site1. On the other sites, clicking Open staged install shows a working site, no Twig (other than a missing `unite_gallery' perhaps), even before touching Admin-2.
I have to be doing something really unusual somewhere and it's probably in the 1.7 original. I've disabled as many plugins which don't adversely affect operation and I tend to use the same selection on all my sites, which leaves my custom theme, but I can't image what I could do there to cause such a problem.
@rhukster you should have received links to this site's backup. Perhaps you can see something I can't. If you want a login, send me an account file or suggest a password by email.

Separately: I'm more comfortable with HTML and Twig as I do more theme creation than content creation, so stick with that syntax, also being a programmer by trade. I just can't get the design control in Markdown to do justice to the Client's content.

[beejay41]

Spoke too soon. I have another Migrated site which doesn't process Twig out of the box (so to speak). So I don't think it's my theme for this site, but I may have a clue. Hopefully update shortly.

My thought was wrong. I noticed that page: process: twig: true is removed from user/system.yaml by the Migration, so if this wasn't also set in user/<domain>/config/system.yaml it would be lost to the Migrated site. But the failing sites both had page: process: twig: true in the <domain> version, so the Migrations do have the expected setting.

So, I still have no idea why the setting is being ignored, but at least I have 2 examples, so far.

[beejay41]

Unrelated: my next migrated site has crashed:
Object of class Grav\Common\Page\Page could not be converted to string on home page! The huge stack trace gives me no clues where in my Theme this is occurring. Admin-2 looks OK, nothing unusual on the Reports page. (now Grav-2.0.2, good to see, I just can't keep up.)
Putting this to one side and trying the next site migration on my list.
Edit: my fault.

[beejay41]

Another site, only a couple of Twig references. Migration looks to have spotted everything:
Content already migrated in Step 2 — 6 top-level entries under staged user/. Enabled security.twig_content.process_enabled (system.yaml pages.process.twig was on; system.yaml pages.frontmatter.process_twig was on). Widened security.twig_sandbox allowlist (1 function(s)) so page content can use them. NOTE: 1 name(s) in content are not PHP functions (unite_gallery) — these are plugin-provided Twig functions. The providing plugin must register them (ideally via the onBuildTwigSandboxPolicy event); otherwise they will still fail after migration. Your source site had system.twig.undefined_functions ON, and 1 name(s) used in content were not in your safe_functions list — review the additions and remove any you do not trust. Removed dead 1.x key(s) from system.yaml: undefined_functions, undefined_filters.

I can see in Admin-2, that unite_gallery has been added and security.twig_content.process_enabled set. I can now see process: twig set as default on the pages I've viewed, specifically those with Twig in their content. all good stuff. But still Twig displayed instead of images, etc.

The unite_gallery is completely missing, but that relates to this log/security.log message:
[2026-06-25T11:32:42.604282+00:00] grav-security.WARNING: [TwigContentXss] blocked route=/gallery found=dangerous_tags {"route":"/gallery","found":"dangerous_tags","hint":"Rendered Twig content produced markup the XSS detector flags. The blueprint validator cannot see render-time-assembled payloads; content was blanked. Disable security.twig_content.xss_scan_output to allow it."} []
After setting Filter Dangerous HTML tags to No, the gallery displays as expected, Twig is being processed (unite_gallery adds <script> to the page, hence the XSS). (This should be unnecessary after declaring unite_gallery safe, and opens the XSS risk the the wider site, but then the plugin could use proper asset management, not spit out script tags. The misery of 3rd party plugins!)

Unfortunately, the following 2 fragments remain unprocessed:
{{ page.media['SC Town Centre Trail - May 2019.jpg'].lightbox(1024,768).cropResize(176,176).html('Trail Map')|raw }}
<p><a title="Town Centre Trail Map" href="{{ page.media['SC Town Centre Trail - May 2019.pdf'].url() }}" target="_blank" rel="noopener">Click here for PDF version on the Map &hellip;</a></p>

It's all moving in the right direction, Twig is being processed on this site. I'm sure there is a good explanation for the last 2 (the blank spaces in the filenames perhaps).

Aside: this was my last public site (copy of) to test migration. I will revisit the previous Twig issue sites, to see if fresh migrations change anything with 2.0.2 - the Page Object error I have no clue.

[beejay41]

Returning to site5, this is a sandbox issue, Twig is being processed. I didn't rerun the Migration, but upgraded using Admin-2 to Grav-2.0.2; Admin-2.0.6.
If I disable the sandbox, all the Twig is processed.

So what's wrong with:

<p class="indent">In addition to the basic options, there are advanced options to customise the content and presentation of the HTML Document, not found in the freeware version.</p>
<p style="text-align: center;">{{ page.media['favPro1.jpg'].lightbox(1024,768).cropResize(176,176).html('Screen shot, Basic options')|raw }}
{{ page.media['favPro2.jpg'].lightbox(1024,768).cropResize(176,176).html('Screen shot, Colours')|raw }}
{{ page.media['favPro3.jpg'].lightbox(1024,768).cropResize(176,176).html('Screen shot, Advanced')|raw }}<br />
{{ page.media['favPro4.jpg'].lightbox(1024,768).cropResize(176,176).html('Screen shot, Image overrides')|raw }}</p>

[2026-06-25T12:46:37.521814+00:00] grav-security.WARNING: [TwigSandbox] blocked rule=method token=lightbox route=/favourite-pro {"rule":"method","token":"lightbox","class":"Grav\\Common\\Page\\Medium\\ImageMedium","route":"/favourite-pro","extra":"Calling \"lightbox\" method on a \"Grav\\Common\\Page\\Medium\\ImageMedium\" object is not allowed in \"@Page:/srv/www/self/website/jonessoft.banjorinse.co.uk/grav/grav-2/user/pages/02.shareware/favorites-to-html-pro\" at line 5.","hint":"To allow this method, add 'lightbox' under security.twig_sandbox.allowed_methods['Grav\\Common\\Page\\Medium\\ImageMedium'] — OR disable the sandbox via security.twig_sandbox.enabled: false."} []

Come on, that's one of yours!

[beejay41]

Seems like I can't win:

[rhukster]

Great debugging, and you've actually landed on two real issues on our side, not yours.

The lightbox / cropResize block is a gap in our defaults, you're right. The Twig sandbox ships a default allow-list keyed by class. It includes Grav\Common\Page\Medium\MediumInterface (which is why .url() and .html() work) but it does not include an entry for ImageMedium, and all the image-manipulation methods (lightbox, cropResize, cropZoom, resize, quality, and friends) live on ImageMedium and go through its __call(). So the sandbox has nothing to match them against and blocks them. That's on us, and we'll be adding these to the shipped defaults.

To get your completed migrations rendering now, add an ImageMedium entry to user/config/security.yaml. One important catch: the per-class allowed_methods lists merge by position, so a partial file can drop the core defaults. The safe way is to paste the complete list (defaults + the new entry). Here it is:

twig_sandbox:
  allowed_methods:
    - class: 'Grav\Common\Grav'
      methods: 'offsetget, offsetexists, __get, getversion, theme'
    - class: 'Grav\Common\Config\Config'
      methods: 'get, toarray, value, default, offsetget, offsetexists'
    - class: 'Grav\Common\Page\Interfaces\PageInterface'
      methods: 'content, header, title, menu, slug, route, rawroute, url, path, permalink, template, templateformat, filepath, date, dateformat, modified, media, parent, children, collection, find, findmedia, value, summary, taxonomy, visible, published, publishdate, unpublishdate, routable, language, modular, modulartwig, ismodule, ispage, isfirst, islast, adjacentsibling, prevsibling, nextsibling, metadata, id, order, breadcrumbs, home, tostring, __tostring'
    - class: 'Grav\Common\Page\Pages'
      methods: 'root, base, dispatch, home, all, children, instances, routes, sort'
    - class: 'Grav\Common\Uri'
      methods: 'path, url, params, param, query, host, port, scheme, route, base, extension, method, referrer, ip, addr, toarray, __tostring'
    - class: 'Grav\Common\Page\Media'
      methods: 'images, videos, audios, files, all, get, offsetget, offsetexists, __tostring'
    - class: 'Grav\Common\Page\MediaCollectionInterface'
      methods: 'images, videos, audios, files, all, get, offsetget, offsetexists, __tostring'
    - class: 'Grav\Common\Page\Medium\MediumInterface'
      methods: 'url, html, filepath, filename, metadata, thumbnail, parsedownelement, __tostring'
    - class: 'Grav\Common\Page\Medium\ImageMedium'
      methods: 'url, html, lightbox, link, lazy, autoretina, srcset, sizes, watermark, thumbnail, resize, forceresize, cropresize, crop, cropzoom, zoomcrop, quality, format, negate, brightness, contrast, grayscale, emboss, smooth, sharp, edge, colorize, sepia, rotate, flip, fixorientation, gaussianblur'
    - class: 'Grav\Common\User\Interfaces\UserInterface'
      methods: 'authorize, authorized, authenticated, username, fullname, email, language, offsetget, offsetexists'
    - class: 'Grav\Common\Taxonomy'
      methods: 'taxonomy'
    - class: 'Grav\Common\Language\Language'
      methods: 'getactive, getdefault, getlanguages, getlanguage, enabled'
    - class: 'Grav\Common\Assets'
      methods: '__tostring, addcss, addjs'
    - class: 'stdClass'
      methods: '*'
    - class: 'Grav\Common\Data\Data'
      methods: 'get, value, toarray, items, offsetget, offsetexists, __tostring'

Run bin/grav clear afterwards. That keeps the sandbox on (so you don't have to disable it site-wide) and unblocks the page.media[...] chains. The two fragments you thought were failing on the spaces in the filenames are the same lightbox block, not the spaces, so they'll come back too.

On the unite_gallery <script> / XSS block: that one is the scanner doing its job. unite_gallery writes raw <script> into the page body, and security.twig_content.xss_scan_output flags rendered markup that contains script tags and blanks it. Turning that scan off on those pages is the pragmatic unblock for now, but you're right that it widens your exposure. The clean fix is for the plugin to register its assets through Grav's asset manager instead of emitting inline <script> in content. We'll look at whether the scanner can be scoped more precisely so one plugin's output doesn't force you to lower the bar everywhere.

Bigger picture: this whole thread has been genuinely useful. Two things are coming out of it on our end:

1. We're going to widen the shipped sandbox defaults so the standard media methods work out of the box. They should never have required hand-editing after a migration.
2. The migrator already scans your content and auto-adds custom Twig functions and filters to the allow-list. We're going to extend that same scan to method calls so it detects patterns like page.media[...].lightbox() and seeds the right allowed_methods automatically. That would have caught this for you before you ever saw an error. (Tracked in Scan content for Twig method calls and seed security.twig_sandbox.allowed_methods grav-plugin-migrate-grav#11.)

This security layering is clearly a point of real confusion, and that's feedback we're taking seriously, so thank you for the detailed reports.

Separately: the Object of class Grav\Common\Page\Page could not be converted to string crash on the other site is unrelated to the sandbox, so let's not lose it in here. If you can open a fresh issue with that stack trace (and the theme template it points into, if you can find it), we'll dig into that one on its own.

[beejay41]

I'm pleased that's all useful, but I still don't understand site2.
I've rerun the Migration after updating the 1.7 plugins, the Migration output looks a bit thin compared to the above:
Content already migrated in Step 2 — 7 top-level entries under staged user/. Enabled security.twig_content.process_enabled (1 page(s) set process.twig). Removed dead 1.x key(s) from system.yaml: undefined_functions, undefined_filters.
No mention of pages.process.twig which is on in the 1.7 source site.

security.log does complain about unite_gallery, but the site still displays Twig after it is added to the safe functions. No page shows the process:twig override, yet the option is in env:system.yaml. The log also complains about various XSS, which drops a couple of module pages, which are easily restored by turning off the related options, but nothing which affects Twig processing.

Stopping for today, have a good evening.