<p>Yes, utility methods can go in a <a href="https://craftcms.com/docs/3.x/extend/module-guide.html" rel="nofollow noreferrer">module</a> that <a href="https://craftcms.com/docs/3.x/extend/extending-twig.html#register-a-twig-extension" rel="nofollow noreferrer">registers a custom Twig extension</a> or <a href="https://craftcms.com/docs/3.x/extend/extending-twig.html#extend-the-global-craft-variable" rel="nofollow noreferrer">extends the Craft variable</a>. How you structure that depends on scope of the project (and personal preference):</p>
<ul>
<li>For small projects with only a handful of utility functions, just stick them in a single extension in one module.</li>
<li>For medium projects with some custom functionality, I would create one separate module for each of those custom functionalities. Then each module can register Twig extensions (or extend the Craft variable) with functions and filters specific to that module / functionality. You can also stick to a single module, but with separate Twig extensions for related functions.</li>
<li>For really large projects or custom module with tons of stuff in it, I'll divide it further and put all the business logic and actual functionality in <a href="https://craftcms.com/docs/3.x/extend/services.html" rel="nofollow noreferrer">services classes</a>. This way, those methods are also available to PHP if necessary (e.g. for usage in a Controller). The Twig extension then only provides methods that call the corresponding service classes, or provides access to the service class itself so you can call its methods from Twig.</li>
</ul>

CC BY-SA 4.0
2022-02-02T16:36:13.297Z
Thanks -- seems a bit inconvenient I guess when you're trying to do something quick and dirty -- but I reckon setting up a module and having that separation of concerns isn't too many more steps than using something like `functions.php` -- and it provides a way to keep things a bit more organized.
kevindeleon
CC BY-SA 4.0
2022-02-02T16:46:11.403Z
@kevindeleon Yes, once you're used to it setting up a module takes less than a minute. You can also use the [pluginfactory website](https://pluginfactory.io/) to create the module files, though I always find those come with a lot of stuff I don't need.
MoritzLost
CC BY-SA 4.0
2022-02-02T16:46:45.177Z
@kevindeleon And anything that discourages 'quick and dirty' is a plus in my opinion :D
MoritzLost
CC BY-SA 4.0
2022-02-02T15:59:20.483Z
2022-02-02T15:59:20.483Z
MoritzLost
<p>So when using Drupal or Wordpress -- obviously you can write as much PHP in a template as you need, or in Wordpress for example, you can abstract that functionality away to the functions.php file. This allows for a quick way to add functionality without the overhead of setting up an entire plugin to do so.</p>
<p>I understand the benefits in Twig/Craft of not allowing that is to keep templates clean.</p>
<p>So, then what's the proper way of creating utility/helper functions in Craft that are callable in the templates? Would it be to create a &quot;utility&quot; module and just stick all of your utility functions in that module, or is there a better way to do it?</p>

<craft3><templating><modules>
How to create custom utility/helper functions for use in Twig templates?
# How to create custom utility/helper functions for use in Twig templates?

(Asked by: username_0 on 2022-02-02)

So when using Drupal or Wordpress -- obviously you can write as much PHP in a template as you need, or in Wordpress for example, you can abstract that functionality away to the functions.php file. This allows for a quick way to add functionality without the overhead of setting up an entire plugin to do so.

I understand the benefits in Twig/Craft of not allowing that is to keep templates clean.

So, then what's the proper way of creating utility/helper functions in Craft that are callable in the templates? Would it be to create a "utility" module and just stick all of your utility functions in that module, or is there a better way to do it?

**Tags:** craft3, templating, modules

---

## 1 answers

### Answer by username_1 on 2022-02-02. Score: 2 | Accepted answer

Yes, utility methods can go in a [module](https://craftcms.com/docs/3.x/extend/module-guide.html) that [registers a custom Twig extension](https://craftcms.com/docs/3.x/extend/extending-twig.html#register-a-twig-extension) or [extends the Craft variable](https://craftcms.com/docs/3.x/extend/extending-twig.html#extend-the-global-craft-variable). How you structure that depends on scope of the project (and personal preference):

* For small projects with only a handful of utility functions, just stick them in a single extension in one module.
* For medium projects with some custom functionality, I would create one separate module for each of those custom functionalities. Then each module can register Twig extensions (or extend the Craft variable) with functions and filters specific to that module / functionality. You can also stick to a single module, but with separate Twig extensions for related functions.
* For really large projects or custom module with tons of stuff in it, I'll divide it further and put all the business logic and actual functionality in [services classes](https://craftcms.com/docs/3.x/extend/services.html). This way, those methods are also available to PHP if necessary (e.g. for usage in a Controller). The Twig extension then only provides methods that call the corresponding service classes, or provides access to the service class itself so you can call its methods from Twig.

> **Comments:**
> **username_0**: Thanks -- seems a bit inconvenient I guess when you're trying to do something quick and dirty -- but I reckon setting up a module and having that separation of concerns isn't too many more steps than using something like `functions.php` -- and it provides a way to keep things a bit more organized.  
> **username_1**: @kevindeleon Yes, once you're used to it setting up a module takes less than a minute. You can also use the [pluginfactory website](https://pluginfactory.io/) to create the module files, though I always find those come with a lot of stuff I don't need.  
> **username_1**: @kevindeleon And anything that discourages 'quick and dirty' is a plus in my opinion :D  

---

