# Proposal: Deprecate sections **URL:** \ **Category:** Feature requests\ **Created:** [December 14, 2023, 9:36am UTC](https://zola.discourse.group/t/proposal-deprecate-sections/1968 "2023-12-14T09:36:00Z")\ **Posts on this page:** 12\ **Page:** 2
**Author:** ![keats](https://avatars.discourse-cdn.com/v4/letter/k/34f0e0/32.png) [@keats](https://zola.discourse.group/u/keats)\ **Post date:** [September 8, 2024, 12:00pm UTC](https://zola.discourse.group/t/proposal-deprecate-sections/1968/21 "2024-09-08T12:00:25Z")
---
**Author:** ![g-braeunlich](https://avatars.discourse-cdn.com/v4/letter/g/51bf81/32.png) [@g-braeunlich](https://zola.discourse.group/u/g-braeunlich)\ **Post date:** [October 19, 2024, 3:32pm UTC](https://zola.discourse.group/t/proposal-deprecate-sections/1968/22 "2024-10-19T15:32:15Z")
Whats your suggestion to test tera2 with zola? I saw that in the “next” branch on github, still “tera v1.20.0” is pulled in (cargo tree). ---
**Author:** ![keats](https://avatars.discourse-cdn.com/v4/letter/k/34f0e0/32.png) [@keats](https://zola.discourse.group/u/keats)\ **Post date:** [October 19, 2024, 9:50pm UTC](https://zola.discourse.group/t/proposal-deprecate-sections/1968/23 "2024-10-19T21:50:12Z")
It’s not yet ready for use in Zola, still missing some stuff. It’s getting there though, it’s usable on its own if you want to play with it: [GitHub - Keats/tera2](https://github.com/Keats/tera2) ---
**Author:** ![keats](https://avatars.discourse-cdn.com/v4/letter/k/34f0e0/32.png) [@keats](https://zola.discourse.group/u/keats)\ **Post date:** [August 21, 2026, 4:11pm UTC](https://zola.discourse.group/t/proposal-deprecate-sections/1968/24 "2026-08-21T16:11:09Z")
Official RFC: [Proposal: Deprecate sections](https://zola.discourse.group/t/proposal-deprecate-sections/1968) All comments are welcome! ---
**Author:** ![bemyak](https://yyz2.discourse-cdn.com/free1/user_avatar/zola.discourse.group/bemyak/32/1106_2.png) [@bemyak](https://zola.discourse.group/u/bemyak)\ **Post date:** [August 21, 2026, 6:15pm UTC](https://zola.discourse.group/t/proposal-deprecate-sections/1968/25 "2026-08-21T18:15:49Z")
I think the correct link is [[RFC] Merging page and section by Keats · Pull Request #3258 · getzola/zola · GitHub](https://github.com/getzola/zola/pull/3258) 🙂 ---
**Author:** ![bemyak](https://yyz2.discourse-cdn.com/free1/user_avatar/zola.discourse.group/bemyak/32/1106_2.png) [@bemyak](https://zola.discourse.group/u/bemyak)\ **Post date:** [August 21, 2026, 6:21pm UTC](https://zola.discourse.group/t/proposal-deprecate-sections/1968/26 "2026-08-21T18:21:49Z")
Thank you, I think RFC process is something that’s been missing from Zola. Would be nice to have a more structured way of discussing such proposals 👍 ---
**Author:** ![keats](https://avatars.discourse-cdn.com/v4/letter/k/34f0e0/32.png) [@keats](https://zola.discourse.group/u/keats)\ **Post date:** [August 21, 2026, 7:54pm UTC](https://zola.discourse.group/t/proposal-deprecate-sections/1968/27 "2026-08-21T19:54:23Z")
> [@bemyak](#): > > I think the correct link is [[RFC] Merging page and section by Keats · Pull Request #3258 · getzola/zola · GitHub](https://github.com/getzola/zola/pull/3258) 🙂 🤦 thanks ---
**Author:** ![Colas.Nahaboo](https://yyz2.discourse-cdn.com/free1/user_avatar/zola.discourse.group/colas.nahaboo/32/1610_2.png) [@Colas.Nahaboo](https://zola.discourse.group/u/Colas.Nahaboo)\ **Post date:** [August 22, 2026, 8:55pm UTC](https://zola.discourse.group/t/proposal-deprecate-sections/1968/28 "2026-08-22T20:55:03Z")
Just a comment on the back compatibility: I am more in favor of not making the new code able to read the old format, but providing a migration tool, because: - the new code does not get bloated (no need to understand the old format) - the migration tool is also simpler (no need to understand the new format) - the migration tool do not need to evolve: it works on frozen format - no deadline on when to drop backcompat: backcompat will be always there in the form of the migration tool. This is important as it reduces the decision stress of the maintainers on when to pull the plug, and no user is left behind even if he does not follow what is happening with Zola. Also, zola.toml should include a **version variable** describing the version of zola the site was built for, so the new zola can output an informative message instead of random errors. ---
**Author:** ![keats](https://avatars.discourse-cdn.com/v4/letter/k/34f0e0/32.png) [@keats](https://zola.discourse.group/u/keats)\ **Post date:** [August 23, 2026, 12:44pm UTC](https://zola.discourse.group/t/proposal-deprecate-sections/1968/29 "2026-08-23T12:44:35Z")
The backcompat layer is very very thin. Just a few lines of validation to be written. Please comment on the GH PR though ---
**Author:** ![Colas.Nahaboo](https://yyz2.discourse-cdn.com/free1/user_avatar/zola.discourse.group/colas.nahaboo/32/1610_2.png) [@Colas.Nahaboo](https://zola.discourse.group/u/Colas.Nahaboo)\ **Post date:** [August 23, 2026, 5:10pm UTC](https://zola.discourse.group/t/proposal-deprecate-sections/1968/30 "2026-08-23T17:10:32Z")
The RFC seem OK for me, with two points: At “_Overall, it shouldn’t be a breaking change, except for some narrow cases_”, I think it these cases should trigger an error/warning rather than silently fail, to avoid user frustrations. And maybe this is simpler to implement in a lint/check/migration tool rather than building it into the code at the risk of false positives? I will have to check once there is a first implementation if my bilingual (FR/EN) section templates still work, which is the part of my site with the most code. From reading the RFC, I cannot anticipate problems issue, so it should work, and thus I have no comment. ---
**Author:** ![keats](https://avatars.discourse-cdn.com/v4/letter/k/34f0e0/32.png) [@keats](https://zola.discourse.group/u/keats)\ **Post date:** [August 24, 2026, 12:58pm UTC](https://zola.discourse.group/t/proposal-deprecate-sections/1968/31 "2026-08-24T12:58:01Z")
> [@Colas.Nahaboo](#): > > At “_Overall, it shouldn’t be a breaking change, except for some narrow cases_”, I think it these cases should trigger an error/warning rather than silently fail, to avoid user frustrations. > And maybe this is simpler to implement in a lint/check/migration tool rather than building it into the code at the risk of false positives? Those narrow cases are all in the templates and honestly would be tricky to write a migration for that. It would be a few times more work than the actual changes as we would need to inspect all the templates, track variables, where it’s set and field access. ---
**Author:** ![Colas.Nahaboo](https://yyz2.discourse-cdn.com/free1/user_avatar/zola.discourse.group/colas.nahaboo/32/1610_2.png) [@Colas.Nahaboo](https://zola.discourse.group/u/Colas.Nahaboo)\ **Post date:** [August 24, 2026, 8:56pm UTC](https://zola.discourse.group/t/proposal-deprecate-sections/1968/32 "2026-08-24T20:56:23Z")
I was just advocating for at least raising an error rather than silently failing. And I was guessing (with no certainty) that raising an error in the code may trigger false positives on valid new syntax. Whereas the migration (or just a simple checker) working only on old syntax cannot have false positives. [Previous page](https://zola.discourse.group/t/proposal-deprecate-sections/1968.md?page=1)