And then there are pages that you want users to EDIT in inline mode, but not in wiki, example: User Profile, Dashboard.
UserDirectory is also problematic, but it's using view mode to allow customizations. On Tue, Nov 7, 2017 at 4:58 PM, Eduard Moraru <[email protected]> wrote: > The second topic of interest was the extension pages that are designed to > be modified, like the demo AWM apps or intro blog post, homepage, etc. > > 1) IMO, all these pages should be separated from the code pages of an > extension and moved to a "-content" extension. At this point, we could > introduce a flag on a XAR extension that its pages are modifiable and all > the above described limitations will not be enforced and, on upgrade, the > user would be free to choose what happens to the changes (i.e. discard, > backup or even merge). > > 2) The second option would be to explicitly mark (in the extension > descriptor ?) modifiable pages inside a XAR extension, so to continue > mixing code pages with content pages, but I would prefer we would not > continue to do it. I guess this would be towards proposal 3) from Thomas, > but I think I would prefer it to be done from an extension level, and not > page level (since that would imply editing the page and might collide with > previous decisions). > > Thanks, > Eduard > > On Tue, Nov 7, 2017 at 4:43 PM, Eduard Moraru <[email protected]> > wrote: > > > Hi, > > > > One option I was discussion with Caty that would cover the need to not > > have code pages modified, while also allowing devs (including us) to work > > and experiment is that we only add a warning/banner in edit mode on pages > > belonging to an extension, informing the user that their changes *will be > > discarded when upgrading* and what he could do instead, to keep them. > > > > So, when upgrading to a new version, we would have the following > > directions to decide on: > > > > 1) We could show the list of modified extensions with options for each > > extensions (not each document) to: > > a) discard changes > > b) backup changes > > c) merge changes (I would personally not be in favor of keeping this, > > since it will be too tempting for everyone to abuse it and we would be > back > > at the current state when upgrades take a very long time and are hard to > do) > > > > 2) We could simply discard any modifications done on the extensions and > > upgrade to the newest version (i.e. never do the 3-way merge) > > > > > > The main idea is that you are free to do changes and experiment, but if > > you want your work to be used in production or to survive an upgrade, you > > need to do one of the following things: > > > > A) Contribute your changes so that they are included in the next version > > of the application. > > > > B) Publish your changes as a fork of the application. Optionally, it > could > > be a light fork which only contains the modified pages and has a fixed > > version dependency on the standard application. It will be your job to > keep > > your fork up to date, otherwise you will be stuck using an older version > of > > the application. If the application is part of the Standard Flavor and > > because of the fixed dependency version, it will mean you will not be > able > > to upgrade XWiki either until you update your fork first. If you don't > use > > a fixed version dependency, you risk upgrading the standard application > to > > a version that is no longer compatible with your changes. > > > > Thanks, > > Eduard > > > > On Tue, Nov 7, 2017 at 4:16 PM, Thomas Mortagne < > [email protected] > > > wrote: > > > >> On Tue, Nov 7, 2017 at 1:02 PM, Ecaterina Moraru (Valica) > >> <[email protected]> wrote: > >> > On Tue, Nov 7, 2017 at 1:00 PM, Thomas Mortagne < > >> [email protected]> > >> > wrote: > >> > > >> >> Hi devs, > >> >> > >> >> We started to think about https://jira.xwiki.org/browse/XWIKI-14377 > >> >> with Caty and she noticed that it might not be as simple as "all > >> >> extensions pages are protected" because there is extensions pages > that > >> >> are almost always supposed to be modified: first example is > >> >> Main.WebHome which is modified 99% of the time but another good one > is > >> >> Sandbox or Quicklinks panel. > >> >> > >> >> So what do we do about it ? > >> >> > >> >> I'm not fully sure yet but here are some ideas : > >> >> > >> >> 1) So what ? It's still extension pages and you might still have > >> >> conflicts during next upgrade. If you want standard pages to be > >> >> modified then generate them during install. > >> >> > >> >> 2) Only show the warning when a page is hidden and consider all non > >> >> hidden pages as OK to modify > >> >> > >> >> 3) Explicitly mark each standard page that is OK to be modified with > >> >> some xobject > >> >> 3.a) EM XAR handler behave with these pages as it always did > >> >> 3.b) EM XAR handler has a special support for these pages controlled > >> >> by one of the xobject fields (skip the document from any merge if > >> >> there is any customization, always overwrite any customization, etc.) > >> >> > >> >> WDYT ? > >> >> > >> >> 1) might be too harsh, generating Main.WebHome might be doable (but > >> >> still a pain to maintain) but it's quite a pain to generate the whole > >> >> Sandbox space (and not even talking about maintaining it...) > >> >> > >> > > >> > Don't forget that some of these pages are localized. > >> > >> And there is that too which makes this option even more difficult to > >> apply. > >> > >> > > >> > > >> >> > >> >> 2) we might still want to see some application home pages in the > >> >> search result and most of them should really not be modified > >> >> > >> >> 3.a) will still have the "what should I do" effect sometime for pages > >> >> that user is allowed to modify > >> >> > >> >> 3.b) has my preference right now, sounds like the nicest from user > and > >> >> author point of view, can even be used for other use cases than edit > >> >> protection control > >> >> > >> > > >> > Not sure how hard would be technically, but instead of an exception > >> list, I > >> > would like an inclusion list. > >> > >> Since 90% of the pages coming from extensions ares stuff nobody should > >> touch I really don't think this is a good idea. > >> > >> > We talked so much in the past about Application Descriptor and we also > >> have > >> > some patterns put in place, like placing the code inside a Code space > >> and > >> > mark the technical pages hidden. > >> > > >> > I believe all the content pages of an application should be editable > by > >> > user and should be ignored during an upgrade, but all the technical / > >> code > >> > pages should not be encouraged to edit and they will need to be > >> upgraded on > >> > new releases. > >> > > >> > Instead of marking what pages should be ignored, we should mark what > >> pages > >> > we should upgrade and restrict from editing, thus defining the > >> > application's structure and descriptor. > >> > > >> > The only downside with this approach is that it's more work to do, > since > >> > there are fewer 'content' (some Homepages, some demo content) pages > >> inside > >> > our applications, than the technical pages. > >> > > >> > Also if we were to go into the application description direction we > >> might > >> > want to move the pages in a nested structure, enforcing the rules we > >> have > >> > on application structure. But this might mean a lot of work and we > need > >> to > >> > be convinced of the benefits. > >> > > >> > >> > Also this goes beyond editing and also we would want to warn on other > >> > operations, like move, delete. Marking what pages are ok to Edit, > would > >> not > >> > provide us information if that page is ok to move and thus won't break > >> the > >> > application. > >> > >> Actually 3.b support well all that since the whole point is to > >> indicate what kind of page it is (the page need to exist but can be > >> modified, the page can be deleted, the page should never be modified, > >> etc.). Default being "nobody should touch this page in any way" since > >> that's what we want for most pages. > >> > >> > > >> > Thomas also talked about a preference in the User Profile that would > >> allow > >> > editing and won't display the warning, intended for developers to ease > >> > their work. This is one aspect to consider, the other is if we want > >> special > >> > permissions for some users, like administrators. > >> > >> This is a different subject IMO. > >> > >> > > >> > Thanks, > >> > Caty > >> > > >> > > >> >> > >> >> -- > >> >> Thomas Mortagne > >> >> > >> > >> > >> > >> -- > >> Thomas Mortagne > >> > > > > >
