There’s a rule in the Maven XAR plugin that enforces the following title for WebPreferences pages: $services.localization.render('admin.preferences.title') (“Preferences”)
IIUC, we have a sheet associated to the XWikiPreferences object that sets the title to $services.localization.render('administration.title.page') (“Page Administration”)
I suggest we change the rule so it checks:
Whether the title is not set, or set to one of these two (for backward compatibility) for WebPreferences pages, and also for XWikiPreferences (with the corresponding translation strings), or
That the title is not set (which will make all extension developers remove the title from all their WebPreferences / XWikiPreferences pages - which will allow the platform to fully manage the title of WebPreferences pages), or
We remove the rule entirely (for both WebPreferences and XWikiPreferences pages) (with the risk that people set titles hardcoded to the language they currently use in their XWiki instance)
The rationale behind this proposal is that:
we shouldn’t require users to hardcode some arbitrary translation string they should not have to care about in their projects
in any case this is not needed (anymore?) anyway
Worse than that, apparently it’s causing inconsistencies between WebPreferences pages created on the instance directly, and those imported from a XAR package
WDYT?
I’l open the vote for until the end of the month and create a ticket for that with the preferred option if they are not vetoed.
I’m fine with 3. too, but since the point of that rule was consistency, let’s keep the spirit of it and impose what’s the cleanest (so empty, since that title is actually not used in the UI currently).
I meant for the display (since that was your question).
I have the feeling that you skipped the fact that the title which is currently forced in each WebPreferences is a script, so I’m not sure how this is easier to sort and filter.
That page name is a bit missleading since apparently it actually does not contain any XWikiPreferences object
Try with XWiki.WebPreferences.
When the admin UI create the WebPreferences page, it always set the XWikiPreference object in it (even when you only went to the right management), so I assumed all our WebPreferences pages had one. Among other things, the XWikiPreferences sheet also automatically redirect you to the admin UI of the page.
