BC's Incontext Editing: How to replicate functionality with custom modules

While migrating an older non-liquid page to Treepl today, I came across an issue regarding the way my client will be able to edit their content in Treepl. On the BC site I used Incontext Editing, so I could define repeating regions of code hence enable my client to easily duplicate, edit and delete blocks of content without breaking code in a way which is not yet possible with the nICE editor.
Obviously I will use a custom module for that content in Treepl and set up properties but this doesn’t give me the same flexibility. Or at least I don’t know yet how to achieve thatt. I made a little video for better understanding:

Maybe someone has an idea? Or came across the same problem?

Hi @TimL. Your Custom Module item would just use ‘Name’ and ‘Description’ properties; where the date heading is the name of the item and the paragraph is the content/description.
Then all your markup goes into the layout to keep it safe.
Probably just need to implement ‘weighting’ as well to sort them as needed.

Ha, that would be easy, but I think it’s a bit more complicated :slight_smile: . The example I was showing is basically one item (a team member) with his biography. Following your idea, the client would have to create a new custom module for each new team member. But the plan is, to have a module “team” and each member with his/her vita is an item. Nested modules might be a solution though (the sub-module being for the events in the biography), but that’s only available in “Pro” and the sorting with weighting is painfull compared to the “visual” way it is now. Hence I would have to take a feature from the client while having to charge him more :frowning:.
I might have to make the grid more robust by using a table in the description (where the client can add and delete rows) and then use javascript on it on the front end to make it responsive.

Oh, I get it now… those blocks are already within another Custom Module item. Ok.

Repeatable property ‘blocks/sets’ as a Custom Module property type is something I’ve been meaning to write up as a backlog request :slight_smile:

Only way I can think to do this (on lower site plans) is just to set up many date/paragraph property sets in your CM so there are blank ones available for the client to add to.
But this doesn’t help with front-end editing.

Hi @TimL. I might have a work-around for you.
See video explainer here: https://drive.google.com/file/d/1LLm8lekiWgq8B1M_QIgcHiE98lXQfSmc/view?usp=sharing
And I’ve added you to my test site as an admin if you want to grab the code :slight_smile:

Thanks a lot @Adam.Wilson! Checked your video, brilliant work! My only concern is, if this will still work after a future nICE update. But I’ll check it on my instance at the weekend anyway.