# DisabledException: 'module' is disabled in this context

**URL:** <https://community.hubspot.com/t/disabledexception-module-is-disabled-in-this-context/74615>\
**Category:** CMS Development\
**Tags:** starter\
**Created:** [February 7, 2023, 9:16am UTC](https://community.hubspot.com/t/disabledexception-module-is-disabled-in-this-context/74615 "2023-02-07T09:16:14Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![JanRa](https://d10pqhm3lwygmk.cloudfront.net/user_avatar/community.hubspot.com/janra/32/26693_2.png) [@JanRa](https://community.hubspot.com/u/JanRa)\
**Post date:** [February 7, 2023, 9:16am UTC](https://community.hubspot.com/t/disabledexception-module-is-disabled-in-this-context/74615/1 "2023-02-07T09:16:14Z")

</div>

Hi Devs,

**The Problem:**

I recently run into an issue saving custom modules in my hubspot blog-index dnd template.  
The error notice told me:  
_Error while updating a module_  
_Please click “Apply changes”, try again, or check if the “blog-listings” module has errors._ (translated)  
After further investigation the chrome dev-tools notified me about the problem, mentioned in this subject:  
_DisabledException : ‘module’ is disabled in this context_  
**Further investigation:**  
I checked all my templates for nested modules and destructed my whole theme in another developer account.

Removing and reinserting modules showed me, that my post-listing modules caused this issue. More precisely, my readingtime estimation macro seems to cause the error.  
With the message _‘module’ is disabled in this context_ in mind, maybe some blog-posts contain modules or further logic in their content. It wasn’t an option to edit all my blog-post contents.  
Debugging their _post\_body_ didn’t show any modules neither.  
**My thoughts to fix it**  
I guess my readingtime macro causes hubspot to parse the post\_body of my posts in my custom module context

```lia-code-sample
<!-- old and problem causing example -->
{% macro readingtime(mytext) %}
	{% set time = mytext|striptags|wordcount|divide(225)|round(0, "ceil") %}
	{{ time > 0 ? time : 1 }}
{% endmacro %}

<!-- fixed version of readingtime estimation escaping curly braces -->
{% macro readingtime(mytext) %}
	{% set time = mytext|escape_jinjava|striptags|wordcount|divide(225)|round(0, "ceil") %}
	{{ time > 0 ? time : 1 }}
{% endmacro %}

<!-- macro call in a loop in a custom module -->
{{ readingtime(content.post_body) }}

```

To resolve this behaviour i came along to the [escape\_jinjava](http://escape_jinjava) filter.  
It seems, that the problem doesn’t occure anymore because of escaping those braces used in hubl templates.  
Did someone experienced the same problem or has a reference where this problem is described in detail? I couldn’t find a documentation or community post about this topic.  
Greetings 🙂

---

<div class="post-metadata">

**Author:** ![Anton](https://d10pqhm3lwygmk.cloudfront.net/user_avatar/community.hubspot.com/anton/32/103167_2.png) [@Anton](https://community.hubspot.com/u/Anton)\
**Post date:** [February 7, 2023, 10:28am UTC](https://community.hubspot.com/t/disabledexception-module-is-disabled-in-this-context/74615/2 "2023-02-07T10:28:11Z")

</div>

Hi @JanRa,

try this reading time script

```lia-code-sample
{% set initialPostWords = content.post_body|striptags|wordcount %}
 {% set calculatedPostWords = (initialPostWords/100) * 100 %}
 {% set finishedPostWords = calculatedPostWords|divide(300)|round(2) %}

{{ finishedPostWords|round }}

```

using it for years and never had issues with it.

best,

Anton

_Moderator note: While this solution may not address the original poster’s specific situation, it could be helpful for other community members facing similar challenges._

---

<div class="post-metadata">

**Author:** ![JanRa](https://d10pqhm3lwygmk.cloudfront.net/user_avatar/community.hubspot.com/janra/32/26693_2.png) [@JanRa](https://community.hubspot.com/u/JanRa)\
**Post date:** [February 7, 2023, 3:20pm UTC](https://community.hubspot.com/t/disabledexception-module-is-disabled-in-this-context/74615/3 "2023-02-07T15:20:02Z")

</div>

I also found this snippet while debugging, but it didn’t solve the issue.