As you probably know already, the XWikiPreference document is a huge mess and is pretty much the worst possible example of extension page, containing a mix of everything that should never be mixed in the same document: xclass, custom rights, default configuration, custom configuration, etc. It even contains things which are actually more UI elements that we would usually put in templates, UI extensions, or even email templates if they were introduced today:
meta: part of the HTML tag
confirmation_email_content and validation_email_content: I assume, according to their content, mail templates used in the validation process.
Since XWikiPreferences is such a mess and would be way too dangerous to merge, it’s not merged. This means that the UI elements indicated above are never updated during an XWiki upgrade.
For now, I would like to propose a very simple change to improve the situation for future new installations for those 3 UI elements: move their content to their own location, and in the code where we currently evaluate the content of those 3 fields have a fallback on those new locations when the content is empty.
That way, when an instance which started with this logic is upgraded, it will benefit from update/fix of those default content. It also means that it’s easy to include the content of the template when you just want to add stuff before/after the standard content without modifying it.
For the locations I propose templates in xwiki-platform-web-templates since those templates are easy to include, and their content seems generic enough for any skin (but it would still allow a skin to customize them).
WDYT ?
Here is my +1 for moving those scripts to upgradable locations and +1 for these locations to be xwiki-platform-web-templates templates.
What do you plan to do with the administration sections that currently allow customizing them? Afaik, at least the meta part is currently customizable in the administration.
The problem with what you propose is that if somebody customizes these fields, there won’t be any notice on upgrades, again. So unless we think that these fields should only be rarely customized, I’m not sure if this improves the situation a lot. For the meta part, I’m wondering if a UIXP could be an interesting solution, at least if we also implement proposal 2 of this thread to allow disabling UIX.
As I said, I don’t plan to remove them, they will still work as before (but by default they will be empty). The difference will be that it will be easy to include the standard version if you just want to add something before or after.
If you really want to modify them then it will be the same limitation as any template customization and yes you won’t have upgrades. We can’t remove those fields for obvious retro compatibility reason and IMO what I propose is already a much better situation since most people don’t customize those.
Once we moved it to a template, yes, we can more easily add all sort of extension points. What I propose here is not an end goal, it’s just the first step to move this content out of the XWikiPreferences area by default.
I missed this proposal but IMO it’d not a good choice on 2 basis:
the content of the HTTP META field is supposed to contain content that is not important and that the admin user can want to change. Moving it to a meta.vm file hides what’s in there and makes it hard for the user to change or even know what it contains.
Problem is that it’s not true since a very long time. As explained, we had a lot of problems with this field being stored in XWikiPreferences and never upgraded (so not getting bugfixes, since it’s more code that actual values in there).