XWiki @ Google Summer of Code 2018

Last modified by Eduard Moraru on 2018/04/03 16:34

This page hosts information and project ideas for the open source project XWiki related to the Google Summer of Code 2018 mentorship program.

XWiki has also been participating to Google Code-In since 2017.

About GSoC

You can learn a lot about the program by reading the GSoC FAQ. The timeline of this year's edition is given here.

XWiki Guidelines

Being part of the XWiki community means knowing our rules and practices. As a GSOC student you need to make sure you read and apply our guidelines. 

Student Application template

When applying for one of our projects, please provide this information about yourself and the project you choose in the application which you submit to Google.

Proposed Projects (12)

Students can come up with their own ideas, but the ideas need to be proposed and discussed on the mailing list.

Finish and improve Android XWiki authenticator and contact synchronization

The idea is to continue the work on XWiki Authenticator and contacts started during GSOC 2016.

The main use case is to get all the contacts of your organization's intranet automatically synchronized on your phone so that you don't have to use a browser, go to your intranet, login and search form some user to see if he entered his phone in his profile. The other important part is to make sure this is as integrated and as standard as possible from Android point of view and allow other applications to use registered XWiki authenticators to access an XWiki instance without the need for the user to give the password to that application.

Current code: https://github.com/xwiki-contrib/android-authenticator
Known bugs/improvements: http://jira.xwiki.org/browse/ANDAUTH
Documentation: http://extensions.xwiki.org/xwiki/bin/view/Extension/Android+authenticator/

The first requirements for this project during this GSOC are:

  • get something stable enough to release a 1.0 version, especially a good support of bad network
  • a nicer and more polished configuration UI

Then any improvement idea is welcome. You can find some ideas already listed on jira and here are a few others:

Coordinated by


Translation in context

XWiki 4.4 introduce new translation macro which will allow to find easily translated content in a page when using annotated HTML5 renderer (you can see the result by adding ?outputSyntax=annotatedhtml in the URL).

The idea is to use that and provide a "translation mode" where you can directly select and translate what you see in the page (when the translation macro is used). The idea is also to make easy to contribute to http://l10n.xwiki.org from your local wiki by sending your corrections to it.

Various ideas for the look and feel of this feature:

Location where to code this: https://github.com/xwiki-contrib/application-translation

Coordinated by



The project aims at exploring best practice and realizing extensions to XWiki and a widespread open-source static-site-generator such as Jekyll or Wintersmith (more here) so that XWiki is used as a back-office for a large part of the content of a static-generated website.

The extensions should be written for XWiki and for the SSG with such functions as:

  • detect when the site-generation is needed
  • list all pages or pages of with a given object type or pages with a given object value (e.g. tags)
  • include page content, attachments, and objects' properties for 
  • include the attachment content in different forms (e.g. rescaled images, converted video or office documents)
  • include the textual-content in different forms (rendered wiki syntax, source syntax, with or without traces of the XWiki origin)

It should be possible to trigger the creation of the static site from the command line, also from a remote client, and from the server.

The idea behind this this investigation, is that the trusted collaboration of a team of persons should be complemented by a published (and potentially attackable) set of web-pages.

Coordinated by

Estimated workload: a summer.

Integrate lint tools in the Wiki editor

The Wiki editor has been improved lately with integration of tools for code autocompletion and syntax highlighting. The next step is to integrate some lint tools for the supported scripting languages: Velocity, Groovy, Python, Ruby, PHP (see the Scripting page), CSS, JavaScript and provide a way of configuring the checkstyle rules to be applied for each of them.

Current code: https://github.com/xwiki-contrib/wiki-editor-devtools.

Coordinated by


Improve Confluence importer

A project already exist to help migrate from Confluence to XWiki: Confluence.

It's already very useful but there it could be improved in various ways. You can find a lot of ideas in Jira but here are big ones:

  • fix various remaining bugs
  • add support for many more standard Confluence macros (see Anchor macro for inspiration)
  • Confluence REST API based input: the idea is explore the possibility to get data from a running instance of Confluence instead of the current database export

Coordinated by


PAC4J based universal authenticator

The idea is to build a bridge authenticator around PAC4J. XWiki allows writing custom authenticator and there is many of those, see http://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Authentication/#HCustomAuthentication but they are written one by one and they don't share much with each other.

It would be nice to have the possibility to reuse the tons of authenticators that comes with PAC4J. Doing that means doing some plumbing and wiring to transmit all the information required by PAC4J and back to the XWiki authentication API (and UI when required).

Coordinated by


Improve OpenId Connect provider and authenticator

It's possible to use XWiki as OpenId Connect provider and also make XWiki authenticate on OpenId Connect provider. See OpenId Connect project page.

It work well but has various limitation that it would be nice to fix. You can find various ideas on Jira but here are the main ones:

  • both
    • setup integration tests
  • provider:
    • UI to manage authorizations
    • salt the stored token
    • allow accessing any resource using access token
    • add support for registering clients (only allow a set a clients with generated authorization key) and provide corresponding UI to manage them
    • improve the UI (very basic right now)
  • authenticator:
    • support automatically authenticating a user who is coming back
    • support client authentication (for provider who allow only registered clients)

Coordinated by


Implement PDF export with XHTML and paged CSS

Currently, the PDF export of XWiki is implemented based on XSL-FO and transformation of XHTML to FO. This poses a couple of problems, mainly related to the current level of support of FO from libraries implementing FO to PDF transformation, as well as the limitations of automatized transformation of XHTML to FO. The problems are mainly related to styling limitations, auto-layouting, etc.

The idea is to try to replace this with a pure XHTML & CSS (paged CSS) export, using an open source library for producing PDFs out of this.

This is only the first step of this project, the next steps being to validate that all customisation that is currently possible on the PDF export will remain possible with the new tool, and explore the new capabilities of the export (once ported to the new technology), build tools for it, etc.


Coordinated by

Estimated workload: 2-3 man months.

Add a REST API to XWiki Notifications

During the 9.X cycle, the Notifications Module has been added in order to replace the Activity Stream Plugin.

The idea is to develop in a first time a REST API for retrieving a user notifications and interacting with the user notification preferences. In a second time, we can consider developing a REST API for directly sending notifications.

In practice, this feature could help to integrate XWiki with other web platforms that could send notifications to their users through XWiki or client-side applications that would use this API in order to retrieve notifications and display them to the user.

Coordinated by


Google Blockly Editor

The idea is to integrate Google Blockly into XWiki to be able to let users create XWiki scripts using visual blocks.

Tasks to be implemented:

  • Integrate a Blockly editor inside XWiki as a new editor (in addition to the current wiki and WYSIWYG editors)
  • Create custom Blockly blocks to represent common XWiki scripting actions (as many as possible)
  • Make the blocks output Velocity scripts
  • Package it all as an XWik Extension that can be installed into any XWiki instance

Coordinated by


Expose XWiki as an NFS server

The idea is to allow someone to access XWiki as an NFS server and modify wiki page content, metadata and attachment directly as virtual files.

You can take a look at http://extensions.xwiki.org/xwiki/bin/view/Extension/WebDAV%20Server for inspiration since it's pretty much the same goal but with a different protocol (there will be difference since the WebDAV one is quite old and does not support things like nested spaces/pages and made some choices related to WebDAV limitations).

Note: https://github.com/dCache/nfs4j looks very promising for the actual NFS protocol support.

Coordinated by


Improve DokuWiki importer

The DokuWiki importer project started last year in Google Summer of Code 2017, where basic functionalities were implemented and along with the ability to import most of the data. 

However, there many ways to improve the performance of DokuWiki importer. Keep tracking Jira for ideas. Some notable ideas are: 

  • Fix the support for inter-wiki links - Define the mappings for the "default" links, Define mappings for services pointed out by 'this' and finally convert custom mappings to idiomatic mappings.  
  • Add various customizations to the importer interface, allowing user to specify to ignore various pages or metadata of pages. 
  • Add support for popular DokuWiki macros. 

Coordinated by


Mentors (9)

The following community members are assigned to mentor the proposed projects:

Contact us

You can ask for more information about each project proposal and interact with the community and mentors through the usual communication channels: mailing list (devs AT xwiki.org) or the IRC channel.

What's next after GSOC?

First and foremost: Thank you for having participated to XWiki!

We want to keep you in the community for as long as possible. We understand that you may have school projects to carry on and won't have the time to continue participating much immediately after GSOC. However, we're really keen to see you coming back to this community when things settle a bit more and you get some time again.

Here's some visibility and ideas of what's next after you've completed a GSOC project and opportunities you may have:

  • You could be voted as Committer
  • You could get hired by one of the companies doing some business on top of the XWiki project
  • Become a Google Code-In mentor
  • You could propose a school project, PhD, etc about XWiki to your teachers!
  • You'll be able to add a nice line to your CV about having participated to an open source project emoticon_smile
  • You can ask for recommendations on LinkedIn, Facebook, etc about your work as a GSOC student
  • (Future, doesn't exist ATM) Your name on the Hall of Fame
  • (Future, doesn't exist ATM) Receive an XWiki GSOC t-shirt
  • (Future, doesn't exist ATM) Be sponsored to take about XWiki at conferences
  • (Future, doesn't exist ATM) Be able to implement some bounties for XWiki and get paid for it
  • (Future, doesn't exist ATM) Be invited to physically participate to an XWiki conference

Previous GSoC editions

Created by Eduard Moraru on 2012/02/29 02:09

Get Connected