Access the App name & description settings within Twig

[LukeTowers]

I would like to be able to access the App Name and Tagline settings within my theme's Twig. As it stands right now, I have to add

$this->page['app_name']        = BrandSetting::get('app_name');
$this->page['app_description'] = BrandSetting::get('app_tagline');

to a custom component that I must include for every layout in order to be able to access these variables within my theme. I believe it would be helpful if they were accessible to the themes through Twig by default, similar to the other general variables available under the this object. Perhaps something like {{ this.app.name }} and {{ this.app.tagline }}?

[daftspunk]

There is performance considerations here. The $this->vars['this'] object called in CmsController is providing access to objects that we have already initialized anyway so there is no additional overhead.

If we add a BrandSettings::get call, it will force every front-end page to initialize the BrandSettings model, which is exclusively used in the backend at the moment.

Consider creating a utility component that injects the values you need, or alternatively extending twig to introduce the functionality as a filter or function.

Some other options that we can consider:

1. Adding a type called variables to registerMarkupTags that would allow you to register custom variables to the this object. Eg to make available {{ this.app_name }} use

public function registerMarkupTags()
{
    return [
        'variables' => [
            'app_name => BrandSetting::get('app_name')
        ],
        [...]
    ];
}

2. Seeding the $vars property with the View facade shared variables

$this->vars = (array) View::getShared();

Allowing you to share any variable across the entire front end, as we can do with Content and Mail Templates already. To make {{ app_name }} available use

View::share('app_name', BrandSetting::get('app_name'));

3. Both

[LukeTowers]

I know I could always just continue to have a utility component / plugin that injects those variables, however I was thinking that it's a reasonably common use case to want to use those values in themes for OctoberCMS.

A parallel to those settings would be the site name and tagline used in WordPress sites, utilized by themes in creating title tags for pages and copyright notices, as well as just general branding of the theme specific to the site its being used on.

This way, themes wouldn't have to essentially duplicate these options in their own settings pages, they could just use the common values that would already be assigned for the backend.

What are your thoughts on that?

[seanthepottingshed]

+1

[daftspunk]

I was thinking that it's a reasonably common use case to want to use those values in themes for OctoberCMS.

BrandSettings define the branding for the back-end, so I'm not sure I entirely agree with this. Theme customization was built specifically to service this need. These values are loaded in a special way, they are magically accessed through the already initialized Theme object, so it comes at no additional expense to make them available.

It's unfortunate that we can't define a twig variable as a closure, allowing the Brand Settings to be lazy loaded, and also have no performance impact. This being the primary objection. Secondary is the separation of concerns, it is assumed that Backend\Models\BrandSetting should not be accessible from the front end because it is a resident of the backend module. If the data were to be shared, it should live in the system module instead.

That said, it may be possible to pluck the app name from the backend brand settings, and push it to the CMS theme data for all themes. We just need a really good reason to do that.

A parallel to those settings would be the site name and tagline used in WordPress sites

This is probably where the mix up is coming from. Perhaps I am failing to see a reasonable use case beyond the fact that it is a familiar trait from WordPress.

[YahzeeSkellington]

...being able to display the site name on any page, meta tag and so forth without having to create new functions should be enough reason :P

[daftspunk]

@YahzeeSkellington, read the first paragraph of my last comment. Here is an example of defining the site name, and here is how its used.

[silasrm]

@daftspunk I'm using like clean theme but always return "October CMS". I set other name in theme.yaml, theme_fields.yaml, Backend Settings > App Name, config/app.php and still this.

• PS: I'm clean cache before try.

fields:
    site_name:
        label: 'Academia de Gestão da Emoção'
        comment: 'Primeira escola de Gestão da Emoção do mundo'
        default: 'Academia de Gestão da Emoção'
        span: auto

Any idea?

[silasrm]

I'm have success change to this, in theme.yaml:

...
form:
    fields:
        site_name:
            label: 'Academia de Gestão da Emoção'
            comment: 'Primeira escola de Gestão da Emoção do mundo'
            default: 'Academia de Gestão da Emoção'
            span: auto
...

And removing theme_fields.yml.

[LukeTowers]

See https://octobercms.com/plugin/luketowers-essentialvars for my final solution to this