UI extension point for document content footer

Hi everyone,

we already have an UI extension point for the page content header (see: https://www.xwiki.org/xwiki/bin/view/Documentation/DevGuide/ExtensionPoint/BeforeTitle/) but none for the page content footer. I now need this UIXP to insert a Like button as part of my work on Like feature.

There was already some discussions about adding such UIXP as part of https://jira.xwiki.org/browse/XWIKI-13081. So here there’s three main questions:

  1. Do you agree to create a UIXP for page content footer?
  2. Do you agree that we create a unique UIXP for content footer and transform tags and author as UIX (instead of creating two UIXP after/before as discussed in the comments of XWIKI-13801)
  3. Do you agree to name it org.xwiki.platform.flamingo.skin.resources.contentFooter (here I’m following our Naming convention we voted on not so long ago)

Note that I’d like to have a clear view on 1 and 2 ASAP since I’ll need to implement it for my work on Like (so for 12.6RC1). 3 is important too, but it’s easy to change at last minute if needed.


  1. yes
  2. yes
  3. yes

From what I see it’s not a “page content header” but a “before title” UIXP.

Note: When I look at myxwiki.org for example (which is on XS 12.3) the page edit menu is on the same line as the title which doesn’t correspond to a “before title” UIXP. The reason is that the code outputs several DIVs and then there’s some CSS to reorder them.

I don’t quite agree about this one :slight_smile: For me this UIXP is not related to the Flamingo skin but to the common templates, and thus must not have the Flamingo part in it. Said differently another skin should be able to implement this UIXP too. Otherwise it means that another skin will not be able to benefit from the UIX and it breaks the whole concept of UIXPs :slight_smile: (which is to have reusable parts between skins and to be able to inject content into any skin and it’ll appear at the right place). This is an important topic that we discussed in the past already but it’s probably good to reassert what we want. WDYT?


  • We need consistency so the question is not just about the “after content” UIXP but also the one for before the content.
  • We need to decide about terminology. 2 choices: “before/after” or “header/footer”. We use both right now. For ex: “beforeContent” vs “contentHeader” and “afterContent” vs “contentFooter”.
  • The before content template (contentheader.vm) currently does the following:
    • display the UIXP for “before title” line
    • display the title line (no UIXP ATM)
    • display the last modified line (no UIXP ATM)
    • display the menu line (using the menu UIXP)
  • In addition there’s also the hiearchy.vm before that for the breadcrumb which is also part of the before content area.

Proposition 1

  • Have a single UIXP for before the content: “before content” (or “content header”). And it supports several UIX, with an order. Then have 4 UIXs for this UIXP:
    • breadcrumb: implemented as a UIX of “before content” with priority 1
    • title: implemented as a UIX of “before content” with priority 2
    • last modified: implemented as a UIX of “before content” with priority 3
    • content menu: implemented as a UIX of “before content” with priority 4
  • This means deprecating the “before title” UIXP IMO since any UI that need to come before the title just need a UIX with a priority slightly lower than the title UIX one.
  • It also means deprecating the “after content header” one (https://www.xwiki.org/xwiki/bin/view/Documentation/DevGuide/ExtensionPoint/AfterContentHeaderUIX) for the same reason.
  • Note: The menu UIXP can stay and be used inside the UIX for “content menu”.
  • Following the same idea, I would go with a single UIXP for after the content: “after content” (or “content footer”). We would have several UIX for it:
    • one for the tags
    • one for the “created by”
    • one for the docextra part
    • one for the like
  • The positioning for each UIX is done by the CSS. This is why I prefer a single “before content” and “after content” so that there’s no semantic issue with the positioning (if you say “before title” and then move the title with CSS then it becomes wrong). With before/after content we just assume that the content will not move which is more likely to happen :slight_smile:



Proposal 2

Since after and before are problematic (as the after is the previous of the next section), we could imagine having a single “content” UIXP for all content areas, each UIX of it being a DIV and then use CSS to lay it out.

This doesn’t change all specific UIXPs, in only impacts the UIXP that are about big “content” areas (header, content, footer, panels). All the other UIXP can still be UIXPs of these content UIXs.

This is a much bigger refactoring. Although we’re not ready to go for it right now, it’s interesting to know if we want to go in this direction and start thinking how we could move to it (and how to refactor the templates accordingly).

Templates vs UIXP

We need to decide when something is a template and when it’s a UIXP. In the past we did everything with templates and more and more we are going towards UIXP so we need to be clear when we allow ourselves to add a template file and when we use a UIXP instead. And when we refactor templates into UIXP.

If you think about it and push it to the extreme there would be a single template and all the rest could be implemented as UIXP.

Back to the topic

If we agree about proposition 1 then we should implement Simon’s need using a single “after content” UIXP with order/priority and refactor at least the tags and “created by” parts into UIXs. I say at least because it would also be nice to refactor the docextra as such a UIX IMO. The issue is backward compatibility with xwiki instances having custom skins overriding the “docextra.vm” template. Not sure how we could handle this.

So to summarize my answer to the 3 questions:

  1. yes but provided we agree a proposition 1 (ie we need to be consistent with the before content too).
  2. yes
  3. no on 1 points (the flamingo part in the name) and not sure about “contentFooter” vs “afterContent”.


As always when we have a proposal it needs 2 parts:

  • How does the proposal positions itself on the larger design scale, i.e. what is the direction we want to go after (even if we wan’t do it right now for lack of time).
  • What we do now, in order to progress in the wanted direction

IMO, this proposal by Simon was only answering the second part (what we do now) without answering where we want to go. This is why my answer was a bit long, as I tried to define what would be a consistent strategy.

This probably deserves a design page on design.xwiki.org as a continuation to:

Cool, no big surprise for point 3 :slight_smile:

Nice, that’s actually why I specified that I was following exactly our Naming convention: right now the contentfooter.vm is in flamingo module, not in platform-web and the name was reflecting that according to our convention. But I agree with you that it doesn’t really make sense here and it should be a generic template.
So I’m definitely +1 to prefix it with org.xwiki.platform.template. Now I think we need to ensure we all agree that and clarify it in the Naming convention documentation.

I’m ok for going towards Proposal 1. Regarding names, I slightly prefer afterContent since contentFooter might be a bit ambiguous with the actual pageFooter. But I’m +0.

Just not sure about the docextra part. Right now it’s not in contentfooter.vm and I personally see it as part of the page footer (by opposition to content footer).

Now you are talking about deprecating UIXP how do we manage that? We display a warning when the UIXP is used, but we integrate it where it used to be as usual? I don’t see how we could get rid of it in some legacy.

Well Proposal 2 is actually pushing the discussion about UIXP granularity to another level. If we talk only about pure dynamicity, I’d be 100% ok to push towards that. Now I don’t have any idea on the possible impact of such refactorings on performance and possibly on maintenance / backward compatiblity.

Yeah well, that’s exactly my point about Proposal 2 :slight_smile: It’s already pushing it further and I don’t know how much we want to push.

So, unless someone else is against it, I’ll take back my work on it to create a UIXP named (for now) org.xwiki.platform.template.afterContent with 3 UIX (tag, author and like). I keep docextra as a template for now.

I’m changing my mind about that because:

  1. the actual file for this is naming contentfooter.vm
  2. this content is output if the velocity variable $displayContentFooter is set to true (see https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-flamingo/xwiki-platform-flamingo-skin/xwiki-platform-flamingo-skin-resources/src/main/resources/flamingo/layoutvars.vm#L127)

So it will be easier to reuse the same name.

Did we decide anything? Is this topic closed? is it documented?

Documented on https://www.xwiki.org/xwiki/bin/view/Documentation/DevGuide/ExtensionPoint/ContentFooterUIX/

Was it agreed? I don’t see @tmortagne or @mflorea for ex in the discussion. I hope it means they’re ok.

I was talking about the general rule. Is https://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HUserInterfaceExtensionPointNaming reflecting what was decided?