Global and local variables types

khomutovspace

I have an idea that i want to share. Maybe someone else experience the same.
The key is to divide all (custom) variables into to types: global and local. They would be used in the same ways, but the difference is about editing them. Global ones could be changed only in the «global data and files» and the locals would be specific for every single page.
It makes a lot of use cases: for example, it could be used for social media links, which are similar for all the site, favicon, version of sources and so on.
I know, it could somehow destroy the minimalist concept of the Automad. But i am sure there could be way to make it simple.

antstei

Hi khomutovspace 👋

If I understand you correctly, the feature you mentioned already exists as so-called „Shared Variables“: This variable type can be considered as a kind of global fallback for (local) page variables and is stored in the (shared) „General Data and Files“ section … 🖖

khomutovspace

antstei Well, I am not sure we are talking about the same. But maybe problem is about my misunderstanding of difference between page and shared variables. As for me, no matter how, but all the usual variables like @{ favicon }, which are used only as a resource url for browser, are showing in shared data and on the exact page. My question was about this and says of avoiding this.

mad

khomutovspace Hi there, I understand your issue. I think it could be useful to simplify the user experience. The idea behind the current concept is, as antstei mentions correctly, to provide local overrides for global properties. That kind of scoping gives the user a lot of freedom. For example in case you want to have a different icon for the landing page, you can simple define a different file in one place locally and use the global for all other pages. There are many use cases where this concept is very helpful. However, I was also thinking about something similar to your idea in the past and it’s worth investigating it more!

It’s great to discuss this with you guys! 😊

antstei

Thank you very much guys for your clarification khomutovspace and for your reply mad! – Indeed, I misunderstood the (essential) part of your idea to avoid „scoping“ and make shared variables immutable when editing a specific context, i.e. page, … 🙌

One conceivable solution could be to display a switch next to each shared variable in the „Variables in the main theme“ section, allowing the variable to be used as a constant in all other contexts: Set as constant that cannot be changed when editing a specific page, the corresponding shared variable becomes read only in the „Variables in current template“ section … 🖖

mad

antstei Yeah! I could imagine that instead of a switch, there could be a reserved prefix to make a variable „shared only“. For example variables starting with an underscore will not show up in the page settings. Like using ‘@{ var }’ in a template will add ‘var’ only to the shared data section in the dashboard.

khomutovspace

mad Yes, the idea with some prefix sounds a lot better.

antstei

Hi @mad and @khomutovspace 👋

I totally agree with you guys, a reserved prefix sounds like a brilliant idea! 👏 An additional question that might be of interest in terms of user experience is whether it’s better to either exclude “shared only” variables from the page settings – as you suggest mad – or to show them in the page settings, but disable the respective input field? 🖖

mad

khomutovspace Cool! I will put it on the list for the next release! 😎

mad

antstei I think hiding those shared only variables looks cleaner in the UI. 🤔

mad

Hi @antstei and @khomutovspace, version 1.6.0 now provides the option to define masks to hide variables either in the shared or page scope. Masks can be defined in the theme.json as follows:

{
    ...
    "masks": {
        "page": ["var1", "var2"],
        "shared": [...]
    }
    ...
}