Ask Questions and Find Answers

Based on the HTML spec it seems it can accept any flow content (that is mostly everything): https://www.w3.org/TR/html52/grouping-content.html#the-dd-element

Awesome, thank you. I wasn't sure if it was every tag or just block level. I honestly do respect the editor team, perhaps I could step away at this point. I find that UX and UI feedback is taken less helpful closer to a release.

Jorge, I feel I should let you know this issue appears worse than at first sight, it's not alloy editor issue at all. I added an existing freemarker web content template structure that I have in a 7.0 instance. In previous 7.2's this has worked fine. In RC3 the content display portlet isn't showing the content, it's only listing the fields in what looks like a debug output?

That would explain the dd's for sure. I couldn't see an LPS but will keep looking. Are the tests occurring with templates other than basic web content?

https://issues.liferay.com/browse/LPS-96120
When creating the template and structure I had linked the two correctly. Because it's happening with Basic Web Content I would think there is a bug preventing the template displaying correctly?

Sure thing, just for reference the beta versions didn't behave in this way.I believe the "default template" isn't sticking, forcing users to select a template every time they add content (historically it is template developers that make this link, so users don't have to do that). I attached the section of the content form that is malfunctioning. If it was intended I would seriously not ship the product in that configuration and would put it back to how it was.Just glad I caught it, it's a major UX issue. Having to select a default template each time.

Even adding basic web content, in 7.1, 7.0 the user never had to touch that area of the form and I would be glad if the users never touched that part of the form because they could select the wrong template and bug our support about it.

Thanks Jorge! I didn't know what exactly was occurring just that something didn't look right with that output. That would make sense that when editing that template the linkage is failing to save.

Oh my gosh, can this be addressed as a critical issue? It's not a bug and was an intended change, granted with unforeseen consequences. I feel though this change should have had more oversight and UAT. The change completely breaks functionality and makes a release candidate days away from a release less stable than the beta. Fragments are cool, and are progressing rapidly but changes shouldn't break existing functionality nor make a worse experience for users of previous versions of Liferay (Forcing users to select a template each time is a step backwards and increases the chances a wrong template will be picked / content created with no template linked at all).

https://issues.liferay.com/browse/LPS-86223
​​​​​​​
"with the introduction of fragments, which are more business user-friendly, templates should not be mandatory" I'm trying to be respectful in regards to this, the work on fragments is a major undertaking, I think though a UAT group needs to be formed within the community and at the enterprise level. Some of these changes are crippling to the product.

Possible solution ...

Make toggle in structure "target headless" or "target fragment usage". Defaulted off so that existing functionality is not broken. The power of the toggle. https://issues.liferay.com/browse/LPS-96306