November 2016 - xwiki-devs@xwiki.org

[xwiki-devs] [ANN] Release of Nested Pages Migrator Application 0.6
by Guillaume Delhumeau 23 Nov '16

23 Nov '16

Hello A new version of the Nested Pages Migrator Application is available. See http://extensions.xwiki.org/xwiki/bin/view/Extension/Nested+Pages+Migrator+… You can install or upgrade with the Extension Manager. The application is still in beta but some progress have been made. Anca and Alex have fixed a couple of bugs and I have improved the UI. Complex settings are now hidden by default and it's now clear that the plan is actually a tree that you can expand. I hope it will help you to perform the migration, if you have not already done it. Thanks, -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

1 0

[xwiki-devs] Replace the Mailing Lists by a Forum
by Guillaume Delhumeau 23 Nov '16

23 Nov '16

Hi everybody. Today I would like to speak about an issue that annoys me for years. We are working on a tool whose one of the objectives is to stop scattering information in multiple places. It's even the main argument explained in the video integrated on the home page of XWiki: https://www.youtube.com/watch?v=9QTWrZ7OfzI. But on the other hand, we, developers of XWiki, do the opposite in practice. We discuss on mailing lists that are archived on Markmail, we report issues on Jira and we do investigations on design.xwiki.org, and I don't even count Github. A newcomer have to understand the role and the functioning of each tool. It's quite complex. I don't think we should give up Jira because it is the best tool available in its domain and there is no serious competitor. However, concerning the mailing lists, it's very different. Let me list some problems: - We recently had troubles with some emails that were lost because of subtleties in the email protocols. - Someone who just want to discuss once have to register to the mailing list and then receive thousands of emails every year. - Some emails are lost in the SPAM catchers. - You cannot use serious text formatting. As far as I know, HTML is not supported on the ML nor in Markmail. - You cannot send attachments. - People looking at messages on Markmail do not always understand how to answer (I've seen some people trying to answer directly on Markmail because they believe it WAS the messaging tool). - This is "so 90s"! It still have some advantages: - Users can use their beloved email client. - Mail lists are quite standards in the Open Source world. However it does not balance the drawbacks. To fix this, I see several options: A - Evaluate and improve the Forum Application ( http://extensions.xwiki.org/xwiki/bin/view/Extension/ForumApplication) and use our own Dog Food. B - If it is too costly, use any PHP forum that the Open Source world have. phpBB for example is the common choice. However, it does not centralize everything but it replaces the couple ML/Markmail and these tools are very well-known. C - Use JIRA tickets with a certain label for development discussions because sometime the debates are spread between issues and threads, so it could be better to have everything directly on the issue. (FTR I don't think JIRA is the right tool for that but I wanted to list all options). This is not an action plan but a first step in that direction. Let me hear what you think. Thanks, Guillaume

6 17

[xwiki-devs] [ANN] XWiki 8.4.1 released
by Eduard Moraru 22 Nov '16

22 Nov '16

The XWiki development team is proud to announce the availability of XWiki 8.4.1. This bugfix release addresses some important problems discovered in the 8.4 release, like the page translations issue, but also brings a couple of improvements, specifically focused on the Active Installs application and the Blog UI. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/8.4.1 Thanks for your support -The XWiki dev team

1 0

[xwiki-devs] Fwd: [xwiki-users] Re-organize the Drawer's entries
by Guillaume Delhumeau 22 Nov '16

22 Nov '16

OK so now it's a bit more than only re-organizing the drawer's entries. Your proposition is also about removing some elements, and renaming some of them. We are more closer to your original issue ( http://jira.xwiki.org/browse/XE-1582) It's a big change that we usually don't do at the end of a development cycle. Concerning its content, and more precisely the renaming of the items, I would love to read the opinion of committers. For example, I agree it looks more natural to see "All users" than "User Index" or "All other wikis" instead of "Wiki Index" in a subwiki, but it breaks the famous consistency principle we tend to have. I also like "Settings" instead of "Administration", but we could even go deeper and say "Settings of the wiki" to not confuse with "User Settings". You also propose a "Recent Changes" item, which could lead to the Activity Stream. Should I open a new discussion about this? For now, I could change the order of the elements, and introduce 2 categories: "items concerning the current wiki", and "items concerning the main wiki". It's already a breakage from the UI Extension API point of view. Thanks, 2016-11-03 10:01 GMT+01:00 Guillaume Delhumeau < guillaume.delhumeau(a)xwiki.com>: > Yes Miroslav, we have received your message. Thanks you :) > > 2016-11-02 23:13 GMT+01:00 Miroslav Galajda <miroslav.galajda(a)gmail.com>: > >> Hi, I've sent an email with preference for P5, last week. Have you >> received >> it? >> >> P5 seems to me clean and logical to work with. >> >> Thanks >> Mirec >> >> On 2 November 2016 at 11:23, Guillaume Delhumeau < >> guillaume.delhumeau(a)xwiki.com> wrote: >> >> > Hello. >> > >> > Thanks for your comments. Any other? >> > >> > Guillaume >> > >> > 2016-10-26 17:03 GMT+02:00 Jan-Paul Kleijn <email(a)biggee.nl>: >> > >> > > P5 is also my favorite because it draws more attention to the content. >> > > It's the more grown-up version. >> > > >> > > >> > > Op 26-10-2016 om 10:28 schreef Guillaume Delhumeau: >> > > >> > > No opinion? >> > >> >> > >> 2016-10-24 18:09 GMT+02:00 Guillaume Delhumeau < >> > >> guillaume.delhumeau(a)xwiki.com>: >> > >> >> > >> Hello dear developers and XWiki users. >> > >>> >> > >>> I would you to take a look at the issue >> http://jira.xwiki.org/browse/ >> > >>> XWIKI-13070. >> > >>> >> > >>> The problem is that the current order (that I have implemented >> based on >> > >>> my >> > >>> intuition) seems to not be clear for our users. The main point is >> that >> > >>> the >> > >>> menu mixes up global items (Home wiki, Wiki Index) and local ones >> > >>> (Administer Wiki, Page Index, Delete wiki, etc...). >> > >>> >> > >>> Caty and Oliver have made some proposals that you could find in the >> > >>> issue. >> > >>> >> > >>> They are called P1, P2, P3, P4 and P5. >> > >>> >> > >>> I propose you to express your preferences so we can implement it >> based >> > on >> > >>> a consensus. >> > >>> >> > >>> Here are mine: >> > >>> >> > >>> P1: There is a logical order and separation between item. However, >> it >> > >>> seems the more used actions (Wiki Index, Page Index) are less >> visible >> > >>> than >> > >>> some other (Delete Wiki, Create Wiki...) >> > >>> >> > >>> P2: The order and the separation are logic. The "delete wiki" >> action is >> > >>> still very visible but all other items are good. >> > >>> >> > >>> P3: Same than P2. Except that having "Wiki Index" along with "User, >> > Page >> > >>> and Application Index" mixes up local and global items. >> > >>> >> > >>> P4: Why not, but maybe the 3 first actions should be placed after >> the >> > >>> other ones, since they would be less used. Same remark about the >> mixing >> > >>> of >> > >>> local and global items. >> > >>> >> > >>> P5: A clear distinction between local and global scope. More used >> items >> > >>> are located first. This is my favorite one. >> > >>> >> > >>> >> > >>> So +1 for P5, +0 for the other options so far. >> > >>> >> > >>> Now, what about you? >> > >>> >> > >>> Thanks, >> > >>> Guillaume >> > >>> >> > >>> PS: I send this message to both devs and users mailing lists, >> because I >> > >>> think users are directly concerned by this topic. >> > >>> >> > >>> -- >> > >>> Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) >> > >>> Research & Development Engineer at XWiki SAS >> > >>> Committer on the XWiki.org project >> > >>> >> > >>> >> > >> >> > >> >> > > _______________________________________________ >> > > users mailing list >> > > users(a)xwiki.org >> > > http://lists.xwiki.org/mailman/listinfo/users >> > > >> > >> > >> > >> > -- >> > Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) >> > Research & Development Engineer at XWiki SAS >> > Committer on the XWiki.org project >> > _______________________________________________ >> > users mailing list >> > users(a)xwiki.org >> > http://lists.xwiki.org/mailman/listinfo/users >> > >> _______________________________________________ >> users mailing list >> users(a)xwiki.org >> http://lists.xwiki.org/mailman/listinfo/users >> > > > > -- > Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) > Research & Development Engineer at XWiki SAS > Committer on the XWiki.org project > -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

4 9

[xwiki-devs] Why are extensions of same version removed when installing a new extension?
by Vincent Massol 21 Nov '16

21 Nov '16

Hi devs, When trying to install a new extension I was surprised to see that EM is saying that it’ll removed existing installed extensions to replace them with the same extension in the same version. See screenshot: https://www.evernote.com/l/AHfLVOUhq8ZIrpItBgPWw1KOQ7E2uvCukTU Any idea? Is that a known bug/limitation? Thanks -Vincent

3 9

[xwiki-devs] Msissing deps somewhere on fontawesome
by Vincent Massol 17 Nov '16

17 Nov '16

Hi devs, In a functional tests I’ve noticed the following console errors: https://www.evernote.com/l/AHdqMNmXFNVIf5kGm0_Yd8svSJxb3M2CidQ Seems we’re missing some dependencies somewhere that we need to fix. Thanks -Vincent

1 1

[xwiki-devs] [Brainstorming] XWiki Architecture after 10+ years: what's next?
by Vincent Massol 14 Nov '16

14 Nov '16

Hi devs, We’ve been developing XWiki over 10 years now. I’d like to start a discussion about major architecture changes we may want to do in the coming 5 years. With this discussion I have 2 goals in mind: * Prepare XWiki for the challenges ahead (prevent it from being obsolete, have an architecture that can adapt to changes, etc) * Make XWiki an interesting project to develop on for its developers (interesting technologies, interesting intellectual challenges, etc) Let me start with a few large architecture items I can think about: * Polyglotism for the front end. This is the ability to code the XWiki UI in any language (PHP, Node.js, javascript, native applications, etc). Right now XWiki UIs are coded mostly using Velocity (and a bit of javascript). It would be nice to be more agnostic and to attract non java developers. The core (Server part) could still be in Java but it would be nice that UIs and extensions could be developed in any language. One architecture that could achieve this would be to have a Core Server exposing all operations as REST APIs. This would decouple the Server part from the Client part. It also means having all XWiki API modules offering REST APIs and making it extra easy to add new REST APIs. * Greatly simplify development of XWiki Extensions. There are several directions that I can think of: ** Direction 1: Expose the resources making up an Extension on the file system and let users use their favorite tools to write the content (web IDEs, text editors, etc) ** Direction 2: Develop an IDE in the cloud. Again there are 2 options here: *** Take ownership of the XWiki Web IDE application and push it much further *** Go in the direction of integrating with a well-known cloud IDE such as Eclipse Che/CodeEnvy (with pre-built workspaces, docker VMs and one click deploy to test your extension, direct deployment of extensions to e.x.o, etc). ** Other: In general, make it faster to develop extensions. The advantage of the Cloud IDE or Web IDE is that it removes the burden of setting up the tools on your local machine (maven, java, etc) so someone new to XWiki should be operational under 5 minutes to run the first tutorial. * Promote our SOLR Query Language as the main query language for XWiki and deprecate XWQL/HQL. Goal: make querying independent of the stores (right now we have a single store implemented on a RDBMS but we can imagine in the future moving to another type of store, and even to multiple stores). ** Make it easy for extensions to contribute new SOLR indexes for their needs. ** Once we use only SOLR QL we can then more easily switch to a different database model. We would also need the next Generation XAR format to be able to fully export an XWiki instance (or some part of it) into a XAR and be able to reimport it (right now lots of stuff are not in the XAR such as data found in the permanent directory). * Move towards a container-based approach to install/deploy XWiki (docker, etc). The idea being to start being microservices-friendly. Right now we already have 2 such services in XWiki: external SOLR + office imports with an office server. We need to be able to include those in distributions and add more. It should be easy to develop a new microservice and set it up in XWiki for redistribution. ** It may be interesting to investigate infrastructure frameworks such as kubernetes, apache karaf and the like. The goal being to build systems that are more responsive, resilient, auto-adaptive, elastic (see the reactive manifesto at http://www.reactivemanifesto.org/) ** We could imagine to be able to package our office import micro-services (ie including an office server) as an extension that can be installed and deployed in the XWiki system automatically. Ok that’s already a good start. Let me know if you feel excited by some of those and feel free to add more. Note that the idea here is to brainstorm about large architecture changes. Thanks -Vincent

3 2

[xwiki-devs] Bootstrap 3.x.x will no longer be developed
by Guillaume Delhumeau 14 Nov '16

14 Nov '16

Last month, one of the main contributors of Bootstrap has announced that the 3.x.x branch will no longer be developed [1]. It means that they are currently putting all their efforts to Bootstrap 4.x, and now they are releasing Alphas so the version 4.0 should be available soon. In Flamingo, we use Bootstrap 3.3.7. If we decide to upgrade to Bootstrap 4, we will have the following problems: 1. Bootstrap 4 is not retro-compatible with Bootstrap 3. There are new components, and some have been removed. We know that some extensions are using Bootstrap elements so there is a risk they're gonna be broken. 2. Bootstrap 4 no longer uses the LESS language. Instead, they use SASS [2] (the SCSS variant). Which means we should integrate SASS in XWiki, as we did for LESS. Some work could be re-used, but there are still work to do, and it increases the number of CSS preprocessor to support. For the record, the team has mentioned that Bootstrap might use PostCSS in the future! I've already spoken about this problem in a previous thread last year [3], but the problem will probably hits us in the following months. It may be a strong topic for XWiki 9.x or 10.x. Note: I haven't mentioned the Bootstrap alternative called "Foundation" [4], since it would be a bigger breaking change :) Thanks, Guillaume [1] https://github.com/twbs/bootstrap/issues/20631#issuecomment-244844932 [2] http://sass-lang.com/guide [3] http://markmail.org/message/7sbviier23wzfadf [4] http://foundation.zurb.com/ -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

4 4

[xwiki-devs] [Proposal] Make it simple for users to have filterable/sortable tables by default in XE
by Vincent Massol 14 Nov '16

14 Nov '16

Hi devs, I’ve noticed that users often try to make simple tables filterable/sortable. And LT are too complex for simple tables. Actually we do implement the feature already in xwiki-platform (tablefilterNsort.js.js + icons) but we don’t make it easy for users to use it. Right now a user has to know the magic incantation. They can find the doc here: * http://extensions.xwiki.org/xwiki/bin/view/XWiki/XWikiSyntax?syntax=2.1&sec… * http://snippets.xwiki.org/xwiki/bin/view/Extension/Table+Sorter What I’d like to propose is to 1/ Include a new core macro in xwiki-platform that would allow to transformation a table into a sortable/filterable table, as it’s done by http://extensions.xwiki.org/xwiki/bin/view/Extension/Make+All+Wiki+Tables+S…: {{table [sort="true|false" filter="true|false” oddEven=“true|false”}} |=heading1|=heading2 |cell1|cell2 {{/table}}} 2/ In the CKEditor UI when inserting a table, offer several checkboxes for Sortable, Filterable, OddEven and have the WYSIWYG editor insert this table macro when checked. My rationale for wanting to include it is because I consider this to be a basic use case (core use case) that would benefit from being by default in any flavor of XWiki. WDYT? Note that if we should not agree to have it by default then it also doesn’t make sense to have tablefilterNsort.js in xwiki-platform IMO. Thanks -Vincent

4 3

[xwiki-devs] Inconsistency between Flamingo Skin and Icon Theme Application
by Guillaume Delhumeau 14 Nov '16

14 Nov '16

Hello there. Flamingo is a skin based on Bootstrap, and this framework offers a free but reduced set of icons [1] coming from Glyphicons.com [2]. For this reason, when I started the implementation of Flamingo, I used the free Glyphicons from Bootstrap. A few months later, we introduced the Icon Theme Application [3], in order to replace our Silk icons [4] by more accurate ones, depending on the configuration of the wiki. Unfortunately, the icons provided by Bootstrap were not a good candidate to replace Silk, because a lot of icons were missing. Instead, we have decided to use Font Awesome [5], which looks more like Glyphicons. However, we haven't changed Flamingo to drop glyphicon, so we have an inconsistency between what we propose to developers via the Icon Theme Application, and what we have in the skin. It means a developer cannot, using our best practices, re-use the same icons that the normal UI. So the only option I see is to use the Icon Theme Application in Flamingo too. We have an issue for this [6]. But it means: - Flamingo won't look good if the Font Awesome Theme is not installed on the wiki - It's a matter of taste or habit, but I think Font Awesome does not look as good than Glyphicons in the skin. See: -- http://jira.xwiki.org/secure/attachment/33143/mockup.png -- http://jira.xwiki.org/secure/attachment/33144/mockup-drawer.png - Some Velocity macros [7] (that might be used by extensions) expect to work with Glyphicons. By changing this we create a breaking change. I am not satisfied with the first results. It may be improved, but keep in mind that every changes that we made in the XWiki Icon Set affect all Icon Themes (Font Awesome and Silk). What do you think ? Thanks, Guillaume [1] http://getbootstrap.com/components/#glyphicons [2] http://glyphicons.com/ [3] http://extensions.xwiki.org/xwiki/bin/view/Extension/Icon+Theme+Application [4] http://www.famfamfam.com/lab/icons/silk/ [5] http://fontawesome.io/ [6] http://jira.xwiki.org/browse/XWIKI-12595 [7] For example https://github.com/xwiki/xwiki-platform/blob/76ff57ec6a6fca48bc5f3f563f575b… used by http://platform.xwiki.org/xwiki/bin/view/ExtensionPoint/Edit+Actions -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

2 1