Using Craft CMS helpers in Twig since changes to create()

[jamesmacwhite]

Craft CMS 5.9.0 and 4.17.0, no longer allows you to use the create() function to access helpers e.g.

{% set moneyHelper = create('craft\\helpers\\MoneyHelper') %}
{{ moneyHelper.toDecimal(value) }}

Due to the recent change:

It’s no longer possible to instantiate objects that don’t extend yii\base\BaseObject via the create() Twig function, which fixes a moderate-severity SSTI issue. (GHSA-94rc-cqvm-m4pw)

If you wanted to use the Craft CMS helpers in Twig, what is the preferred approach to do this now?

I could create a global of the required helper via Twig extension e.g.

<?php

use craft\helpers\MoneyHelper;
use Twig\Extension\AbstractExtension;
use Twig\Extension\GlobalsInterface;

class ExampleTwigExtension extends AbstractExtension implements GlobalsInterface
{
    public function getGlobals(): array
    {
        return [
            'moneyHelper' => new MoneyHelper()
        ];
    }
}

Perhaps there is a better way though?

[wsydney76]

Ran into the same issue, and yes, it should work this way. However, I received the following warning, (which, tbh, I can't tell whether it's true or relevant):

You are correct that it can “work” in practice.

What’s happening is:

Twig sees Str as an object and calls an instance method: Str->kebab(...)

PHP then resolves that to Illuminate\Support\Str::kebab(...) even though it’s a static method

PHP has historically permitted calling static methods “non-statically” (via an instance).
That’s why your new Str() approach behaves as expected in Twig.

The material caveat is that this pattern is not considered correct PHP semantics and has been progressively tightened:

On modern PHP versions, calling static methods as instance methods can trigger deprecation notices (and in stricter environments, those can become exceptions or break CI/test runs).

Whether you “see” the problem depends on your error reporting configuration (prod often hides it; dev/test often fails on it).

So:

If your goal is “does it run?”: yes, it can.

If your goal is “robust across PHP upgrades and strict error handling?”: it’s brittle.

So a solution would be to use a 'proxy class'

<?php
namespace modules\main\web\twig;
use craft\helpers\MoneyHelper;

/**
 * @mixin MoneyHelper
 */
final class MoneyHelperProxy
{
    public function __call(string $method, array $args)
    {
        return MoneyHelper::{$method}(...$args);
    }
}

and use that in the Twig extension:

public function getGlobals(): array
{
    return [
        'moneyHelper' => new MoneyHelperProxy(),
    ]; 
}

(The proxy class could be abstracted so that it works for every static class, but I prefer a dedicated class so that IDE code suggestions work).

It's worth noting that behind the changelog notice Added the Illuminate Support library. is hidden that Laravel helpers can also be exposed this way.

[jamesmacwhite]

Interesting, it would be nice if Craft exposed its helpers through Twig directly to be fair. I know some select methods of some helpers are, but that's down to developer choice by the looks of it. It seems a lot of work to have to proxy each helper class you want to use, on the grounds of being "robust across PHP upgrades and strict error handling" for future upgrades.

There is perhaps a better way it could be done in Craft CMS core given create() now can't be used to reference them, there are other useful helpers e.g. DateTimeHelper if you needed more advanced logic and didn't want to reinvent the wheel in a macro or something.

[wsydney76]

Saw a generic class that could avoid creating multiple proxy classes, (untested, bad IDE support)

<?php
// StaticClassProxy.php

final class StaticClassProxy
{
    public function __construct(private string $classname) {}

    public function __call(string $method, array $args)
    {
        return ($this->classname)::{$method}(...$args);
    }
}

return [
    'Str' => new StaticClassProxy(\Illuminate\Support\Str::class),
]

[jamesmacwhite]

Interesting. I still think this seems verbose for what it is. I suspect there is a better way that it could be done in Craft CMS itself, if the decision was made to expose all Craft helpers via Twig directly.

For context, the original warning information on the implementation in your first post, was that provided by a human or AI agent? If human is there a link to the discussion/info?

[wsydney76]

was that provided by a human or AI agent?

It's from a private conversation with a Laravel person in the context of a Laravel -> Craft port, the wording was probably generated with the help of AI, but checked.

I found this article in the meanwhile, which confirms the statement but makes it seem less urgent.

Calling static methods from an instance is a long-standing, allowed behavior in PHP, but it is widely discouraged due to ambiguity and OOP principle violations. As of 2024, there are no official plans to deprecate this pattern, but developers should avoid it to improve code clarity and future-proof their applications.

The PHP ecosystem is moving toward stricter OOP practices, and while deprecation may not be imminent, relying on instance-based static calls risks technical debt. By adopting class-based static calls and following modern best practices, developers can write more maintainable, readable code that aligns with PHP’s evolving standards.

So for the moment you might feel save to stay with the new AbcHelper() method, the ‘technical debt’ seems manageable to me, as it is not spread wildly across the entire application, but only in one place.

[jamesmacwhite]

Thanks @wsydney76, useful information.

My feelings here are that it seems acceptable for the initial pattern, but in the longer term, it would be nice if the helper classes were available under Twig generally, given the breaking changes to create(). There are several examples of using create() to access classes like this, and this is now not possible. Obviously, the security concerns are important, but it is still a breaking change with some impact.

[brandonkelly]

I was unaware people are using create() for helpers classes. Those really should be abstract since they are have exclusively static methods, and are not intended to ever be instantiated.

And that warning is correct @wsydney76. Even if you can instantiate them, you shouldn’t be treating static methods as instance-level methods.

That said, I went ahead and adjusted create() to allow craft\helpers\* classes to be created for the next release, as there’s no security concern with them. (fae1c5f)

We can figure out a better solution in Craft 6.

[jamesmacwhite]

That's great, thanks @brandonkelly!

[brandonkelly]

Craft 5.9.7 is out with that fix.

[FrankZwiers]

@brandonkelly Could you also please backport this to 4.17?

[brandonkelly]

@FrankZwiers Sure! Craft 4.17.4 is out with that same change.