Hard second to this idea. It's an imposition on developers to be able to have our own dependency management solution throughout a project and then have to discard it for this one very important use case, in lieu of an obsolete way of doing it.
thanks for the suggestion! Based on the feedback we received, we are exploring this addition to the Page builder. Can you please share how important the following features are to you?
1. The possibility to specify allowed sections per editable area
2. The possibility to specify the number of sections that can be added to an editable area
3. The possibility to specify allowed widgets per section
I second Elmar's feature priorities as well.
Heck yeah! This would be great. It would also enable the development team and contributors to straw-man proposed improvements to the Page Builder ecosystem.
I've been thinking about this scenario because my organization has several large sites and doing monolithic rebuilds of sites that still have content being changed on them every day presents a serious challenge. How do you completely rebuild a website while the old one is a moving target?
I agree with the other commenter that mixing the Portal Engine and Page Builder in the same editing experience is a technical non-starter, compounded by the Portal Engine's days being quite literally numbered.
However, one solution here would be to build out the new MVC site in sections defined by MVC route mappings, then any HTTP requests the MVC site doesn't have explicitly route-mapped can be passed through to the old Portal Engine site to handle (as opposed to the MVC site returning a 404). Then, the url routes of the Portal Engine site's content tree that are intercepted by the MVC site can be decommissioned and editors directed to the new PageBuilder version.