Skip to content

Custom Modules with jQuery

For child themes with custom modules, you'll need to convert the custom modules before you can disable jQuery and the legacy structure.

Next Steps


Update Base.HTML

This is an extra step required for V26 and v28, make sure you have the latest version.

Follow the steps here to update the base.html in the child theme


Option 1 - Convert your custom modules to remove jQuery and Legacy Structure

Bookmark this page to refer back to it as you complete the steps.

If you are a developer or working with a developer, you can complete the conversion process one of two ways.

  1. You can review the updated theme module code to update your custom modules to remove jQuery and apply the changes to the code structure
  2. You can create a new custom module with vanilla JS (clone to child theme) and recode your customization

We recommend option 2 and making sure your theme is updated to the latest version (at least v30). Why? With V28 each module fully handles its own JavaScript and CSS style dependencies.

If you run into issues or decide you'd like help, you can request a quote here.


  • Find information on how to debug jQuery dependencies in our How To Debug guide.
  • In the Design Tools, you can right-click on a module to reveal the option to show its revision history.
  • Use diffing to find out what changed.
  • You can temporarily deactivate jQuery to test a page by adding the following URL parameter: disableJQuery=true

Jump to Step Three ↓

Option 2 - Continue using the child theme and custom modules as-is

If you are happy with your website and want to keep it as-is, you can continue to use your child theme and custom modules without making any changes.

We will continue to provide the option to support jQuery and the legacy code structure through mid of 2024, at which point you would not be able to accept future updates (see theme status). 

Converting Custom Modules FAQ

This information will help you with the conversion process.

What is Vanilla?

Vanilla JS is a name to refer to using plain JavaScript without any additional libraries (like jQuery back in the day).

People use it as a joke to remind other developers that many things can be done nowadays without the need for additional JavaScript libraries.

Aspects of refactoring jQuery to Vanilla


Code that is used repetitively in modules has been moved to reusable macros.


Backward Compatibility:

Unfortunately, we cannot just translate jQuery to Vanilla code.

Some restructuring of HTML code is necessary, dependencies have changed, etc.

Introduction of „vanilla“ class

To guarantee backward compatibility with old custom modules in child themes, jQuery has been modified to ignore elements wrapped in "vanilla" class.

In contrast, the vanilla codebase ignores all elements without "vanilla".

You can simply switch a module to vanilla by adding the class to a module's root element.


<div class="pwr-sec-team vanilla …
PWR Match Height

Match height elements must be wrapped in a "pwr-mh-group" or "pwr-mh-group-byRow" class.

The value of "data-pwr-mh" must be unique within a "pwr-mh-group".

Serverside-generated unique ids are not necessary no longer. 

  1. Rename all "data-mh" attributes to "data-pwr-mh" and choose an unique id (eg: "title", "desc", "familyname" )
  2. Add "pwr-mh-group" or "pwr-mh-group-byRow" to the modules root element


<div class="pwr-sec-price-tables vanilla pwr-mh-group-byRow …

<h2 class="pwr-price-table__title pwr--toc-ignore" data-pwr-mh="mhID1">{{ price_table.title }}</h2>
Unification of Module Backgrounds

All code regarding backgrounds has been moved to macros/_background.html

  1. Add the background macro at the beginning of a module
    {% import '../macros/_background.html' as macros_bg %}
  2. Remove all code related to backgrounds
  3. Add the background style in the module root element
    <div class=”sec-...
    {# Background - Style #}
    {{ macros_bg.get_style( }}
  4. Add Background content in the module root element
    {# Background  #}
    {{ macros_bg.get_content( }}
Header / Footer Modules and Partials

If you have customized any of the Header or Footer files, these will need to be reviewed carefully against the new code base to ensure all changes are accounted for:

  • templates > partials > footer.html
  • templates > partials > header.html
  • modules > footer
  • modules > header
Custom System Page or Blog Templates

Before the Legacy Asset Structure can be disabled, System Page and Blog Templates need to be updated to reflect the change to how the CSS is handled.

There are now individual require_css statements that have to be added.

We recommend using a Code Diff tool to compare your custom template with the new v28 template.

This is an example statement: