Nested Custom Modules

CMS > Custom Modules
1

Is it possible to nest more than 1 child module inside a parent module?

Here’s a hypothetical:
I’m assuming this needs to be done with nested custom modules, but I’m open to all solutions.
I have three locations: HQ, Location 1, Location 2.
Each location has it’s own blog.
Location 1 and location 2 should not have access to each other blog.
(By “not have access”, hidden is fine, or even in another folder. No need for password protection.)
HQ needs access to all blogs.

On the website, location 1 and location 2 will have their own mini-sites. On their mini-site just their own blog posts appear.

HQ also has a blog on the umbrella site which contains posts from both locations and post that they have created.

I’m thinking if I could nest the two location blogs (custom modules) in the HQ blog, this scenario would work.

Or maybe I can add all the blogs to a collection with liquid… is it possible to add to collections?

This is not for an immediate need, I’m doing some exploration for a site we’re maybe migrating to treepl down the road.

1 Like
2

Nesting more than 1 child module would be very useful. The next site I migrate could have 1 parent module with 5 child modules. It would simplify site structure, data access & front end code so much I wonder how hard it would be to implement?.

3

I’ve been playing around with nested custom modules quite a bit and this sort of setup is possible, although probably not intuitively so.

I’ve created a video to explain the concept:
https://drive.google.com/file/d/1IbB6dcAgut6JJqjRn90OaKMGGU9Pas_s/view?usp=sharing

That being said, for a blog, using the actual built-in blog you can easily achieve the structure of content needed, however there are limitations in restricting access to each blog from other admin users.

PS: no, I don’t believe we can join liquid collections together… but that would be awesome if we could :slight_smile:
Backlog request perhaps?

1 Like
4

Great idea and example for that a case where the properties for each A Item, B Item and C Item Custom Modules all have the same data structure. My requirement is for 5 different sets of data (each with a variable number of items). In the BC implementation each set of data is in a separate web app, passed as a collection along with the ‘parents’ ID key as a custom parameter to a .tpl file. It will be similar in Treepl but much much simpler than in BC. & I’ve just had a similar requirement land for the site I’ve migrated.

5

Hi @peter.medbury. Since A, B and C are separate modules they could also have totally different properties. You’d just have to consider that when outputting and handle each modules ‘layout’ accordingly.

6

Interesting point @Adam.Wilson. Entering data into the All Items module is straight forward when A Items, B Items & C Items have the same structure. So if the structures were different then All Items would have to have all the properties from A Items, B Items & C Items. Something to think about/test for the upcoming migration.

7

Ah, I see what you mean. Yep, more thought and testing needed for that one :slight_smile:

8

Brilliant @Adam.Wilson Thank you for thinking about the solution and then documenting it so nicely. I really appreciate all your hard work. Crystal clear!

On a side not I think your video should live outside of this post. I think it’s a useful case study to explain nested modules. What about posting it to the demo site? Or just under nested module in the docs as a case study?

9

Sidebar: @alex.n Can we get correct answers turned on for this category?

10

The collections are just essentially arrays, are they not? Have you ever tried the liquid array filters on a collections?

Seems like a long shot, but imagine the possibilities.

11

Of course, enabled…

1 Like
12

I had experimented with concatenating collections before and was unsuccessful. However, testing this again now it seems to work ok.
I think though, when digging further into this there will likely be some limitations, such as sorting, filtering and pagination… but could certainly work in most cases.

Here’s my simple test concatenating 2 collections:

{% component source: "Blog Post", layout: "List", filterBy: "parentid", filterValue: "1953", collectionVariable: "blog1", type: "module" %}
{% component source: "Blog Post", layout: "List", filterBy: "parentid", filterValue: "1954", collectionVariable: "blog2", type: "module" %}

{% assign grouped =  blog1.items | concat: blog2.items %}

<ul>
{% for i in grouped %}
    <li>{{i.name}}</li>
{% endfor %}
</ul>

Which outputs:

  • My Post Name from Blog1
  • My Post Name from Blog2
13

Yes, I can add it as an external resource in the docs.

Thinking more about this ‘solution’, and as @peter.medbury has helped me realise, we’re not really utilising (and possibly losing) the power of those A, B and C modules. I’m now thinking you may be able to better achieve a similar thing just by using the 3 modules with Categories (no nesting).
This wouldn’t make available one single collection of posts but that might not really be necessary anyway (?) - or the use of concatenating the collections may work here.

With all the ways of ‘connecting’ custom modules together (Categories, Nesting, Datasource…) there’s subtle pros and cons with each, making it tricky to evaluate which is best.
Non the less this is a good exercise in testing nested modules - even if in reverse :slight_smile:

1 Like
14

Good grief. That’s awesome. Thanks for exploring that @Adam.Wilson I wonder how robust that is. Really opens up a lot of possibilities. Now I just need to crank up the ol’ time generator and generate some time so I can play with that :stuck_out_tongue_winking_eye: