Multiple instances of webpart with CMSEditableRegion in the page doesn't save the content properly

Do you handle saving of web part content? or Kentico does it out of the box?

Obviously it rewrites content saving content of the last web part. I guess this could be caused be the fact that those editable areas have the same id (and/or name).

Why don't you add those editable text one by one to the page template without wrapping them into a single web part?

As Roman said - the issue will be in the same editable control ID. You may need to set the IDs dynamically in the code behind in one of the life cycle events to ensure they have unique IDs.

Hi Rex,

I've noticed in a few of your messages that you are going down the path of using editable web parts and widgets to store content. When starting out with Kentico, it's really common to use this approach. However, it has some drawbacks. I saw a large project in which all content was stored in widgets and editable parts. It got so complex that the dev team was very frustrated. In the end, they refactored the whole site to use a structured content approach. I feel like I should at least let you know about it.

If you are interested, take a look at Brenden Kehren's answer to this post. It caused an aha moment for me.
Webparts vs Widgets vs Static HTML

And, then look at Joel Dahlin's post here:
Tips for Creating Page Types in Kentico

These materials from Brenden and Joel inspired this presentation:
Kentico content architecture @ the Inaugural Seattle Kentico Users Group

You'll gain a lot of benefits by switching to a structured content approach, because the content will be decoupled from the presentation.

• Future proof your site. It will be much easier to migrate to MVC.
• Often, a much easier-to-use authoring experience. I've heard customer's say, "oh, it's so easy".
• The HTML markup is easier to maintain. You have big chunks in templates and transformations.
• The layout and design of a page, or web part can be changed without having to destroy and re-enter the content.
• Less need of nested web parts and widgets.

Regards,

Mike

Thanks for all your insightful comments and recommendations.

Roman and Juraj,

I've used kentico's default saving. All the editable region have it's own unique ID, i.e Card1, Card2, and Card3.

Why don't you add those editable text one by one to the page template without wrapping them into a single web part?

Initially, I wanted the user to fill-up the content by just typing the contents in the editable boxes, without thinking about the layout and other settings. Let's say this user is really old non-technical. I don't want them to drag and drop webparts all over the template or give the freedom to control the layout because this will lead to more problem.

Upon reading Mike and Brendan's (for the second time) comments, i've decided to revert to the plain old webpart, where the user will open the design tab and manually enter the contents.

Mike,

Thanks for sharing your presentation. Just wondering if you have a full video presentation of this?

Regards, Rex

Hi Rex,
In this case, why don't you let the user to add the content on the Form tab only? You will set the fields for given page type and then you will design the page template with the web parts (e.g. repeaters) and their transformations to get the data from respective fields. This way the editor user will not mess up the design. Is this what you meant by reverting back to the old web part?

Hi Rex,

I don't have a video of the presentation, but what Juraj is saying is exactly the point. Design the solution so that content is entered in the form tab (fields of custom page types), not so that content is entered in web part properties or widget properties.

Mike

Juraj,

Form tab is good way of limiting the user to fill up the contents, however, they are quite visual and wants to see how the page looks like while editing, specifically on break points.

reverting back to the old web part

What i mean is not using editable region in it. Instead, educate them on how to enter the contents properly.

Mike,

Yes, it's a good alternative solution. I'll try to explore this and see how to make it work for the user.

So, once they fill in the content, they can use the preview feature to see how it looks like. So, you can setup e.g. a simple workflow so the changes are not live right ahead and the users can preview them. And they can even send preview links to unpublished pages to other users.