My POV is that we should expect them to be edited or even deleted and thus be considered demo pages. This means they’re upgraded when no changes is made to them but as soon as a user makes a modification, they’re not upgraded anymore.
I don’t think this is an all or none answer. Like any other wiki page some plugins are meant to be modified (like the quicklinks panel which even have an edit link on it) and some are complex pages which are not meant to be modified.
Quicklinks is an obvious one (the only obvious one probably) but this brainstorming was going further than that with the idea of discussing whether all panels (except maybe edit ones which should be deprecated soon probably but that’s another matter) be content supposed to be modified by users if they need to customize them.
I see 2 options:
Either we say they are all customizable and we make them demo
Or we say they’re not and users need to copy them as new panels if they need to customize them in which case we remove the “Edit/delete” actions in the Panels app (maybe replace “edit” with “Copy” or “Customize by copying”).
List panels that should be editable. Personally I don’t know any except QuickLinks.
Modify Panels app to have the LT action columns display:
“Edit” for modifiable panels
“Copy to customize” for non-modifiable panels
Also remove the “delete” action from the Panels LT.
Ancillary question: Do we have a script service API to know the XAR type of a given page?
Introduce a ConfigurableClass xobjects for panels which expose configuration options. Such as the number of entries to display for panels displaying entries.
Introduce a new “Panels” menu category in the admin menu. Then either leave the current “Panels” menu entry under “L&F” or move it under the new “Panels” entry as the first entry under a “General Configuration” entry or something like that.
Would you be making a distinction between “editable”, such as quicklinks and customizable, such as the # of entries to show in “recently edited pages”.
One allows for editing the actual content, while the other is just a configuration setting.
If you try to edit a panel you’re getting a scary warning:
Thus something is off. We have various solutions:
Option 1: we consider that all panels are editable and their wiki pages should all be of type customizable. With this, we can keep the “Edit” action in the Panel app home page.
Option 2: we consider that panels are not supposed to be edited and we remove the “Edit” action in the Panels app home page LD. We replace it with a new action: “Copy to customize”. (optional) We also remove the Quick Links panel which is not used by default and acts more as a demo. It’s not really needed since it’s possible to create such as panel easily if you need it.
Option 3: we consider that some panels are supposed to be edited while others aren’t. This would mean adding that info into the Panel XClass and using it to decide if there should be an “Edit” action in the LD or not.
I personally think that option 3 is the worst of all. If you take the example of the “Recently Modified” panel (which is what brought this discussion), the need was not really to edit it, but to configure it to adjust the number of elements displayed. A better solution for this would be to introduce a configuration option for that panel. It’s going to be impossible to take all cases into account about what users will want to do with a panel and why they’d want to edit it. Thus for me the best option is to go with either option 1 or 2.
I have a preference for option 2 as I think we should consider panels like any wiki page belonging to an extension, i.e. supposed to NOT be modified.
Would this also apply to panels that were created by the user, i.e., that aren’t part of an extension or do you suggest to only disable the edit action for those panels that are part of an extension? What about panels that are part of an extension but are explicitly marked as customizable?
Good point. Indeed it could be solved by checking if the panel page is part of an extension or not. This would be logical since the initial idea is to not have the warning when editing, and this would avoid it.
Another good point. We could decide to not show an “Edit” action if the panel is part of an extension and if it cannot be edited (i.e. not of type customizable, configuration and demo).