{% module %} path seems to ignore changes

[yellcorp]

Hi there,

I've been using the {% module %} HubL tag in template source (according to these instructions)  to instantiate custom modules, so far with success, but I'm now running into an apparent issue where changing the `path` argument (with the intent of swapping in a different custom module) seems to have no effect. Instead, the old module continues to be rendered - the one located at the old `path` - and no amount of checking, double-checking, reuploading through either the `hs` cli, or editing directly in Design Manager, seems to be able to convince the CMS to let go of the module at the old path and render the new one.

I freely admit I may be missing some step in the process or misunderstanding something, but the documentation on the 'path' argument seems very concise, with no caveats about this behavior.

Currently I can't provide code samples due to my work being guarded by an NDA, but I may be able to create a minimal reproduction if I find time. Until then, has anyone experienced this? Are there workarounds?

[yellcorp · Accepted solution]

My question applies specifically to the {% module %} tag, not {% dnd_module %}. dnd_modules seem trivially replaceable by deleting the old module and adding the new one through the CMS page editor UI.

In the hours after I posted this question, some experimentation led to similar points in @erod's post. Changing the id forced the path argument to be observed, though it had at least two undesirable side-effects:

1. It clears the editor settings for that module. Not so bad for small modules, but represents lost time and duplicated effort if the module involves repeatable groups crossed with (for example) image assets and the like
2. It seems to make the old id a permanent piece of invisible state associated with the page, becoming a sort of do-not-use id that the original developer needs to document to avoid future confusion.

Indeed, I ended up being sure that I was editing the correct template, but the initial 'stickiness' of the path argument had me doubting myself! Another reason this behavior feels buggy.

I did end up finding a workaround that addresses the above two points, involving the CMS Pages API:

1. Use get_pages_page_id_buffer to fetch the page's current editor state. Save the JSON response.
2. Use a text editor to perform a find/replace of the old module id with the new one. This could be automated with a script if this operation needs to be repeated.
   • I'm not clear on the prescribed way to get a module's id, but it can be done by using the hs fetch command. Download temporary copies of your old and new modules and note the value of module_id in the downloaded module's meta.json.
   • Downloading the module is a key step - it's unlikely a module_id field will exist in the meta.json file you authored. It seems to get added upon upload.
3. Use put_pages_page_id_buffer  to update the page's editor state, submitting your modified JSON as the request body. Return to the page editor UI in your web browser and note the module in use is the new one.

[Teun]

Hi @yellcorp ,

Do you expect to swap the modules on live pages? If you used the new drag and drop coded templates or a flexible column, the following would apply:

Whenever a page is created by using a template, that page will be the new source for the modules shown on that page. Changing default content or changing a module will not change the content on the page that is created by the template, it will only show if you create a new page with that template. So if you want to switch the module, you should do this manually for each page. But again, this only applies to drag and drop and flexible column templates.

[erod]

I think I understand your question but I'm not sure I can give you a solution based on what you wrote so I'll ask the obvious questions: 

• Have you tried swapping the entire snippet instead of just replacing the path? The {% module %} tag has a Module ID that needs to be swapped.  
  • {% module "MODULE_ID GOES HERE" path='PATH GOES HERE' %} 
• Are you sure you're editing the same template that's being used by the page? Sometimes people have duplicates and end up editing the wrong thing.