Thanks Christoph, this is very useful feedback.
Played a bit with them. Very, very nice.
Maybe some things already work or there are different ideas for solutions.
A few things:
1) Please make 'com.liferay.fragment.api', version: '2.0.0' available, I'd like to implement a FragmentCollectionContributor.
That's the idea. It should be possible to do it already.
2) Those builtin collections and sections are pretty nice. But I probably want to remove them in productive environments. Even if they are ok, I need to replace them with my own versions in case a change is required.
I could deactivate them in the app-manager, but I would like it more, if there was an extra package I could simply delete. (At least add a documentation section: "How to remove builtin fragments" and list all packages I should/could deactivate there)
Yes, that's exactly what we want devs to be able to do. In fact, each out of the box collection contributor is an independent bundle so you can choose which to remove, which to leave and also add your own. Look for modules called com.liferay.fragment.collection.contributor.*
3) It would also be very helpful, if you could provide us with a nice documentation and the code (html, css, js) of at least some of those fragments. Of course, I can go to github, search the stuff there and download it, but most people simply don't do that. Why not add a nice link to a git project or even a zip file to documentation https://dev.liferay.com/es/develop/tutorials/-/knowledge_base/7-1/developing-fragments
I think documentation is on its way, but I'll double check and will make sure it contains the info you suggest.
4) On fragment page: Delete section doesn't ask for confirmation.
That's pretty brutal. If there is no undo, delete should be an expensive operation. Removing an empty section without content without asking is fine, but when removing a section with content there should be a confirmation dialog. (Note: In my experience people delete stuff all the time. Staging offers some protection, but it is often not enabled because it is also a bit of a hassle).
Agreed. Juan also brought it up to the team and there is a task to make this happen.
5) Please add an "Anchor" tag/element.
There's one very common request, we have to add very often: "We want to add a link to a specific position on a page". I think, a builtin anchor feature would be very neat.
It could be a basic element, it could also be a lfr-editable type="anchor" tag displaying a # symbol for editors. Clicking on it allows the editor to name the anchor. For normal users it is an invisible div on the page.
It's being finished as we speak. See https://issues.liferay.com/browse/LPS-86186
6) How can I add my own my-editable or maybe a "lfr-editable type"?
I am quite sure that some day in the future, I will need that. e.g. a date field is necessary because ...
Yeah, that's a good point, although it's still a bit hard to encapsulate into an API what is necessary to support a new type. I think we should move in that direction though. Could you create a Feature request for it?
7) Search
I noticed that the whole content of the page is stored as am xml. It is also stored as a "snipped ...". It would be nice, for me as a developer, to add a "search-key" to the lfr-editable. That would allow me to e.g. boost headings. Note: I am not sure, what the best idea is here.
Sounds interesting. Could you create a feature request for it?
Thanks for all the suggestions!
Jorge
