Change "Include default language" value in admin causes a "template not found" error?

Support Themes & Styling
1

Hello,

I’m facing an awkward issue with a custom theme (working properly until then) since I changed the Include default language parameter in admin panel.
I just turn it from No to Yes and now I have this error message: “ERROR: home.html.twig template not found for page: /”. Switch it back didn’t change anything, from admin or locally. I can’t get it to work anymore, even though my templates exist and have the expected names. I erased both Grav and browser cache. Markdown files extensions do include the different languages used (.fr.md and .en.md)
I have this problem both on localhost and online.
I’m using Grav v1.7.34.
Here’s an excerpt of my /user/localhost/config/system.yaml file:

languages:
  supported:
    - fr
    - en
  default_lang: null
  include_default_lang: false
  include_default_lang_file_extension: true
  translations: true
  translations_fallback: true
  session_store_active: false
  http_accept_language: false
  override_locale: false
  pages_fallback_only: false

I also set default_lang to fr in the /user/config/site.yaml file.

Has anyone experienced similar difficulties by making these changes? Is there something I didn’t get?

Thanks for your hints!

1 Like
2

Thanks for the good info to help us diagnose :slight_smile:

Yeah language setting interactions are very tricky in my limited experience, especially when you work through Admin I’ve found. I don’t think I’ve had that exact problem though.

Are the *.fr.md and *.en.md files present in the other site pages? Do the other pages work or is the problem just on the home page?

Also, do you have a backup?

3

Okay thanks to share your experiences.

*.fr.md and *.en.md files are present in every other pages of the website yes. And neither of them work.

I’ll backup everything before doing further mess yeah you’re right.

I have the feeling my /user/localhost/config/system.yaml file has been filled with lots of parameters since I modified an option via the admin.
I realized this by comparing with the config files of another website I’d made, which are “healthy” in principle, and these contain much less content.
I’m going to try and restore the contents of the localhost system.yaml, and I’ll keep you updated! Your comment about the admin’s behavior put me on this track, it does indeed seem that the admin panel has rewritten the file, adding lots of stuff.

4

And it was simply that! Thanks for your insights, which turned out to be right :wink: So it’s good to remember that admin panel can be a prankster (or has a fetish for file overwriting)^^ My theme linking issue was finally related to a corruption of the /config/system.yaml file for the prod version, and of the /user/localhost/config/system.yaml file for the local version. Restoring them solved the problem.

5

@mji, What happens when editing /user/env/localhost/config/system.yaml using Admin is the following:

  • Grav reads file /system/config/system.yaml.
  • Any variable changed in /user/config/system.yaml with the same name and structure, will override the default setting from /system/config/system.yaml.
    New variables will be added.
  • Any variable changed in /user/env/localhost/config/system.yaml, etc with the same name and structure, will override the default setting from /system/config/system.yaml, and /user/config/system.yaml.
    New variables will be added.
  • The combined set of variables is handed over to Admin
  • When saving the config in Admin, the entire set of configuration variables will be saved into the config file.

This is how Streams work.

1 Like
6

Some developers, like me, don’t generally use Admin for site building because of these kinds of surprises. I do use it when I am building blueprints or testing the user experience for clients who want to log in and make edits. However, I usually revert the changes it makes to keep my changes “clean”.

There are two behaviours in particular that I don’t like:

  • It saves all configuration options rather than just the differing ones. This makes comparison trickier and undermines tracking with version control. I have submitted a ticket about this and been told it’s very difficult to rectify. (as per @pamtbaau’s description above)
  • It saves configurations for the current environment only. This is a very limiting behaviour when working with multiple environments.

It also re-numbers ordered pages when you re-order them. Git doesn’t always track those renames well. I have to live with this because my clients want to edit pages more than anything else.

I have sometimes noticed that Admin will save language-specific versions of pages when I want them in the default language (just *.md), which is why I wondered if your original issue was related. However I might have had my language settings wrong. There are many such settings and they can be counter-intuitive.

Sorry, this wasn’t meant to turn into a rant.

7

Thanks for your enlightments, it’s useful to understand how it works for future manipulations! And also to help some users with Admin of their website, true.

8

I want to add that I am a big fan of the Admin plugin for content editors! I just don’t like its output so much, and generally I understand why it’s difficult to make it cleaner.