Add generator for system component "variable"

[jowhannez]

Hey!

Among the possible system components, "variable" seems to be missing. I use it for basically every project so it would be a nice feature.

[AugustMiller]

I like the idea—although I think implementing as a generic Behavior generator would make it more broadly applicable.

Thanks for bringing it up!

[brandonkelly]

You can use the twig-extension generator to generate a Twig extension which defines new global variables. I wouldn’t recommend appending additional stuff to the craft variable except for backwards compatibility purposes.

[khalwat]

Any reason not to continue appending things to the craft variable? A number of my plugins do that as it was the recommended practice at some point, and for one-off things it seemed like a convenient place to stash functionality.

Also, one nice thing about namespacing things that way is you don't have to worry as much that the global you're introducing via your plugin is going to stomp on variables people might be using in their Twig templates already.

For a "maps" plugin for instance, you might provide functionality via craft.map. but if you just made a Twig global map there's a pretty good chance someone will be using that in their templates already

Believe it or not, I actually has a support issue sort of like this a while ago... took me a while to figure out what was going on, but basically they created a Twig variable in their templates named seomatic and then, well, obviously things like seomatic.meta.blah then blew up and didn't work

And seomatic is pretty non-generic

Commerce still hangs things off of the craft variable too: https://github.com/craftcms/commerce/blob/develop/src/Plugin.php#L722 ... via a Behavior no less: https://github.com/craftcms/commerce/blob/develop/src/web/twig/CraftVariableBehavior.php#L39

[khalwat]

Clarification from Brandon:

It will continue to be totally fine to add things to the craft variable either via adding a service:

        Event::on(
            CraftVariable::class,
            CraftVariable::EVENT_INIT,
            function (Event $event) {
                /** @var CraftVariable $variable */
                $variable = $event->sender;
                $variable->set('disqus', DisqusVariable::class);
            }
        );

or via behavior:

        Event::on(CraftVariable::class, CraftVariable::EVENT_INIT, static function(Event $event) {
            /** @var CraftVariable $variable */
            $variable = $event->sender;
            $variable->attachBehavior('commerce', CraftVariableBehavior::class);
        });

[AugustMiller]

A bit of context for anyone arriving here via search or Discord…

---

We still discuss this option in the Twig extension docs!

The most important thing to consider is what kind of functionality you are introducing to Twig. In the past, extending the craft variable was the only means of adding features; now, there are a number of different language constructs to consider (i.e. functions, filters, tags, tests, global variables, and so on), and hanging something on a single global variable is often not the ideal path for developer experience.

But yes—using behaviors is still totally valid, if that's the DX/API that makes sense for the plugin!

As an example—

{# Behavior: This is a funny place for a text manipulation function… #}
{{ craft.highlight(entry.myText, 'some term') | raw }}

{# Twig extension: Ahh, that feels nice! #}
{{ entry.myText | highlight('some term') }}

P.S: Check out the feature/behaviors branch, and tell it you want to target craft\web\twig\variables\CraftVariable!

P.P.S: There's also a new article on behaviors that explains the mechanism behind attaching things to the CraftVariable.

[khalwat]

Well, in fairness, the ability to add Twig filters/functions has been available since the dawn of Craft AFAIK.

I've been doing it from day 1 of making plugins for Craft, albeit probably going a bit overboard, because for some plugins I added the functionality both to the global namespace via a Twig filter/function, and also hanging it off of the craft variable.

I figured I'd let people choose how they wanted to use it, but I think it's a bit excessive now. e.g.: https://nystudio107.com/docs/typogrify/#using-typogrify

When making a plugin, we'd basically just decide whether it made sense to introduce some kind of global Twig filter/function or add something to the Craft variable.

So if there is official guidance of the best or recommended practice of when to do one vs. the other, that'd be welcome.

[brandonkelly]

v1.7.0 is out now with a behavior generator (#27).

> php craft make behavior --plugin foo
Behavior name: (PascalCase) MyVariable
Behavior namespace: [foo\behaviors]
Target class (optional): craft\web\twig\variables\CraftVariable
 → Creating plugins/foo/behaviors/MyVariable.php … ✓
 → Updating plugins/foo/Plugin.php … ✓

[johanneshakonsen]

awesome!