- xwiki-devs@xwiki.org - lists.xwiki.org

Re: [xwiki-devs] [xwiki-notifications] XWiki updates, 5 pages have been modified since 2016/11/28

by Vincent Massol

Sorry about these emails sent by error. It’s XWiki SAS infra preparing the clustering of xwiki.org in the near future. Thanks -Vincent > On 30 Nov 2016, at 00:00, admin(a)xwiki.org wrote: > > Contents > • xwiki > • XWiki > • XWikiAdminGroup > • XWikiServerCommons > • XWikiServerDesign > • Profile of Fabio Mancinelli > • Profile of Kevin Hoarau > Hello Developers, > > This message is sent by XWiki. Here are the pages in your watchlist that have been modified since the last notification: > <wiki.gif> xwiki > <space.gif> XWiki > <document.gif>XWikiAdminGroup <arrowup.gif> > XWiki.XWikiAdminGroup > > On 2016/11/28, the page has been modified by Fabio Mancinelli > <object.gif>XWiki.XWikiGroups > <string.png>member: > XWiki.khoarau > <metadata.gif>author: XWiki.ThomasMortagne ⇨ XWiki.fmancinelli > <document.gif>XWikiServerCommons <arrowup.gif> > XWiki.XWikiServerCommons > > On 2016/11/28, the page has been modified by Fabio Mancinelli > <object.gif>XWiki.XWikiServerClass > <string.png>homepage: > Main.WebHome > <string.png>server: > commons.xwikiorg-node1.xwikisas.com > <metadata.gif>author: XWiki.superadmin ⇨ XWiki.fmancinelli > <document.gif>XWikiServerDesign <arrowup.gif> > XWiki.XWikiServerDesign > > On 2016/11/28, the page has been modified by Fabio Mancinelli > <object.gif>XWiki.XWikiServerClass > <boolean.png>secure: > 0 > <object.gif>XWiki.XWikiServerClass > <string.png>homepage: > Main.WebHome > <string.png>server: > design.xwikiorg-node1.xwikisas.com > <metadata.gif>author: XWiki.superadmin ⇨ XWiki.fmancinelli > <document.gif>Profile of Fabio Mancinelli <arrowup.gif> > XWiki.fmancinelli > > Between 2016/11/28 and 2016/11/28, the page has been modified 2 times, by 1 user: Fabio Mancinelli > <object.gif>XWiki.WatchListClass > <dblist.png>documents: > dev:ReleasePlans.ReleasePlan43M1,xwiki:XWiki.fmancinelli,xwiki:ReleaseNotes.ReleaseNotesXWiki43M1,platform:Features.XWikiRESTfulAPI,dev:ReleasePlans.ReleasePlanHelp,enterprise:Main.Download,manager:Main.Download,xwiki:ReleaseNotes.WebHome,xwiki:Blog.XWikidev:ReleasePlans.ReleasePlan43M1 xwiki:XWiki.fmancinelli xwiki:ReleaseNotes.ReleaseNotesXWiki43M1 platform:Features.XWikiRESTfulAPI dev:ReleasePlans.ReleasePlanHelp enterprise:Main.Download manager:Main.Download xwiki:ReleaseNotes.WebHome xwiki:Blog.XWiki Enterprise and Enterprise Manager 43 Milestone 1 Released,platform:DevGuide.API,rendering:Main.JavaDoc,dev:Community.ReleaseManagerRoster,enterprise:Main.Roadmap,extensions:Extension.RealTimeReleased platform:DevGuide.API rendering:Main.JavaDoc dev:Community.ReleaseManagerRoster enterprise:Main.Roadmap extensions:Extension.RealTime Wiki Editor,dev:XWiki.XWikiPreferences,dev:Community.XWikiDebugIdea,xwiki:ReleaseNotes.ReleaseNotesXWiki43M2,extensions:Extension.Task executor,dev:Hackathon2013.WebHome,dev:Community.BuildingInEclipse,design:Design.DirectoryStructureforXWikiApplications,design:Proposal.ExtensibleAPIforaccessingstructureddata,design:Proposal.ExtensibleAPIforaccessingstructuredata,extensions:Extension.RFC ApplicationEditor dev:XWiki.XWikiPreferences dev:Community.XWikiDebugIdea xwiki:ReleaseNotes.ReleaseNotesXWiki43M2 extensions:Extension.Task executor dev:Hackathon2013.WebHome dev:Community.BuildingInEclipse design:Design.DirectoryStructureforXWikiApplications design:Proposal.ExtensibleAPIforaccessingstructureddata design:Proposal.ExtensibleAPIforaccessingstructuredata extensions:Extension.RFC Application xwiki:XWiki.XWikiServerDesign xwiki:XWiki.XWikiAdminGroup > <document.gif>Profile of Kevin Hoarau <arrowup.gif> > XWiki.khoarau > > Between 2016/11/28 and 2016/11/28, the page has been modified 2 times, by 1 user: Kevin Hoarau > <object.gif>XWiki.WatchListClass > <dblist.png>documents: > xwiki:XWiki.khoarau > On 2016/11/28, the page has been created by Kevin Hoarau > {{include document="XWiki.XWikiUserSheet"/}} > <object.gif>XWiki.XWikiRights > <boolean.png>allow: > Allow > <levels.png>levels: > edit > <users.png>users: > XWiki.khoarau > <object.gif>XWiki.XWikiUsers > <boolean.png>active: > Yes > email_WATCHLIST_IMG_PLACEHOLDERemail: > ****************** > <string.png>first_name: > Kevin > <string.png>last_name: > Hoarau > <password.png>password: > ****************** > <metadata.gif>parent: ⇨ xwiki:Main.UserDirectory > <metadata.gif>author: XWiki.XWikiGuest ⇨ XWiki.khoarau > <metadata.gif>defaultLanguage: ⇨ en > <metadata.gif>syntax: XWiki 2.1 ⇨ XWiki 2.0

8 years, 9 months

1
0
0 0

[xwiki-devs] [Brainstorming] Restrict parent page based on its type

by Marius Dumitru Florea

Hi devs, I have an XWiki application that creates two types of pages. Let's call them Category and Procedure. The application has two template providers that allow the users to create Categories and Procedures anywhere on the wiki using the Create Page menu. I would like to restrict the creation like this: * You can create a new Category page either as a top level page or as a child of an existing Category page * You can create a new Procedure page only as a child of an existing Category or Procedure page Category -> ... Category -> Procedure -> ... -> Procedure One solution to achieve this is to add a new property to the template provider, e.g. "parentType", that specifies the type of pages (XClass references) that are allowed as parent. We would use a Database List with multiple selection and relational storage. We can use the empty string to represent "no parent" (i.e. top level page). An empty list would mean no parent type restriction. Category template provider: {parentType: ["CategoryClass", ""]} Procedure template provider: {parentType: ["CategoryClass", "ProcedureClass"]} Do you think this is useful? Do you see any problem with this solution? Is it worth implementing? Thanks, Marius

8 years, 9 months

6
5
0 0

[xwiki-devs] [Proposal][UX] Change the user type for the Admin user to 'simple'

by Ecaterina Moraru (Valica)

Hi, A simple change that could improve the experience for newcomers would be that the default Admin user to have a simple type. One of the problems new users have is that they have too many options in the Edit menu and this can be confusing. The downside is that it will add an additional step for developers/testers to change the user type back (or at least until we provide a Developer user/profile). Also we would need to make sure the documentation is up to date and fix the tests. WDTY? I've created http://jira.xwiki.org/browse/XE-1580 Thanks, Caty

8 years, 9 months

5
13
0 0

[xwiki-devs] [ANN] XWiki 8.2.2 released

by Thomas Mortagne

The XWiki development team is proud to announce the availability of XWiki 8.2.2. This is a bugfix release that fixes important bugs discovered in the 8.2.1 version. 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.2.2 Thanks for your support -The XWiki dev team

8 years, 9 months

1
0
0 0

[xwiki-devs] [VOTE] Drawer reorganisation

by Ecaterina Moraru (Valica)

Hi, If you want to participate in a quick survey about the Drawer reorganization, please answer these questions: https://goo.gl/forms/WLlAjUGMqaZbUR2l1 (you need a Google account for the form) Thanks, Ecaterina Moraru and Guillaume Delhumeau P.S This is a summary/vote mail about the discussions we had on the "Re-organize the Drawer's entries" thread http://xwiki.markmail.org/thread/6qjwzvteeazlbtn4 P.P.S If you don't have a Google account you can give punctual feedback on the following differences: I. Separation: None (A) vs. Local+Global actions (B) See: http://design.xwiki.org/xwiki/bin/download/Proposal/DrawerImprovement/Choic… II. Index Wording: With (A) ["User Index"] vs. Without 'Index' (B) ["Users"] See: http://design.xwiki.org/xwiki/bin/download/Proposal/DrawerImprovement/Choic… III. Main Wiki Wording: "Global" (A) vs. "Main Wiki" (B) vs. "Home" (C) See: http://design.xwiki.org/xwiki/bin/download/Proposal/DrawerImprovement/Choic… IV. Log-out Icon: Without (A) vs. With (B) See: http://design.xwiki.org/xwiki/bin/download/Proposal/DrawerImprovement/Choic… V. Log-out Position: In Header (A) vs. After actions (B) vs. Drawer Footer (C) See: http://design.xwiki.org/xwiki/bin/download/Proposal/DrawerImprovement/Choic… VI. Administration Wording: "Administer wiki" (A) vs. "Administration" (B) vs. "Wiki Settings" (C) See: http://design.xwiki.org/xwiki/bin/download/Proposal/DrawerImprovement/Choic…

8 years, 9 months

1
1
0 0

[xwiki-devs] [Brainstorming] Install extension on subwikis that have deps that need to be installed on root

by Vincent Massol

Hi devs, I’d like to discuss a use case that we don’t support ATM. Imagine the following scenario: * I have an extension that can be installed in a subwiki * That extension has some transitive dependencies and one of them has a constraint of being installed on root: <xwiki.extension.namespaces>{root}</xwiki.extension.namespaces> * The user has PR Right now EM refuses to install it. I’ve discussed quickly with Thomas and he said the limitation currently exists to prevent subwikis to have impact on other subwikis (because if you install something in the root namespace then it’ll be visible to all subwikis). So the question I want to ask: should we offer this possibility? IMO we should because the user has PR. Now we could also display some warning or make it visible that some extensions will be installed in root in the plan for example. WDYT? Thanks -Vincent

8 years, 9 months

1
0
0 0

[xwiki-devs] XWiki on docker and docker hub

by Ludovic Dubost

Hi, I've made a pull request to Fabio's dockerfile to update it to 8.4.1. https://github.com/xwiki-contrib/docker-xwiki/pull/2 In the process I made quite some changes: - Support for XWiki 8.4.1 and Java 8 (needed debian jessie-backports) - Added libreoffice server - Added xinit to manage xwiki instance - Added webapps/ROOT/index.html to redirect to XWiki page from root URL - Persistence handled in a data container - Added quickRun.sh for one click build and run I think it would be good for the xwiki community to have an officiel Dockerfile and to publish it on docker hub for people to find an "official" XWiki available for the latest version. The approach in this Dockerfile might not be perfect but it's an acceptable one I think. I would like to change the distributionId for this instance. Once the xwiki war is deployed, what needs to be changed to change the distributionId ? Ludovic -- *Ludovic Dubost* *Founder and CEO* ludovic(a)xwiki.com skype: ldubost Blog: http://blog.ludovic.org <https://r.clb.pt/r/08c3c9b2cf61b703f121baebe7511ede?d=http%3A%2F%2Fblog.lud…>

8 years, 9 months

2
2
0 0

[xwiki-devs] [XWiki Day] BFD#128

by Alexandru Cotiuga

Hello all, This Thursday is BFD#128: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 40 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=100 00#Created-vs-Resolved-Chart/10470 Here's the BFD#128 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13707 Have a nice BugFixing Day, Alex

8 years, 9 months

1
1
0 0

[xwiki-devs] [ANN] Release of Limits Application 1.2.1.

by Guillaume Delhumeau

Hello A new version of the Limits Application is available. See http://extensions.xwiki.org/xwiki/bin/view/Extension/Limits+Application/#Hv… You can install with the Extension Manager. This version fixes an important bug which prevents the user to install the application via the Extension Manager. However, I would remind you that using the Extension Manager to install this particular application is not the recommend way, since any user having the administration right will be able to uninstall it. And thus remove the limitations you wanted to enforce. Have a good day, -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

8 years, 9 months

1
0
0 0

[xwiki-devs] Evolution of the Blog Application

by Guillaume Delhumeau

Hi. The Blog Application is one of our main applications. It has been fully written in Velocity, so that even users who don't have programing rights can install it on their wiki. However, I am currently working on XWIKI-13861 [1]. It is about marking the blog documents as hidden when they are not "published" so that visitors won't find them by mistake with the search engine. To accomplish it, I've created a listener that change the document visibility when a blog post is saved. To implement this listener, we have 2 options, with both benefits and drawbacks: A: Write the listener with Java and introduce an xwiki-platform-blog-api module. =========================================================== Pros: * It follows our Best Practices. * We use a nice and powerful language: Java. Cons: * It make the Blog Application dependent to a Java Module, so the wiki administrator needs the PR to install it if the JAR is not already installed in the WAR. * Note that this JAR would be bundled in the XE's WAR while the Blog Application is part of the main wiki flavor, so XE users won't see the change right now. B: Write the listener with Groovy directly on a wiki page. ========================================== Pros: * Blog Application remains a full XAR extension that you can install without PR, as it has always been. Cons: * We need to use the groovy macro, which is not consistent with our Best Practices. * We need a bit of plumbing to register the listener (what we really need is to be able to write listeners easily with an XObject). * If the user has not the PR, the listener will not be registered, so the new behavior introduced by XWIKI-13861 won't be applied. It's a kind of nice degradation but we need to explain it to the user, which will be technical and not user-friendly (we already have lacks on this domain). C: Don't write a listener, but make all changes in Velocity ========================================= Pros: * It remains a full XAR extension. * No degradation Cons: * We need to make the business logic of hiding the blog document in a velocity service and in the blog post sheet. * It is less safe than the listener because a user can still change the "hidden" and the "published" values of the XObjects and bypass the synchronization. * We cannot write an automatic migrator that would be executed only on wiki events. Conclusion ======== My preference goes to A, because: * I don't really like the degradation principle for technical reasons that the user might not understand. * It's simple & safe. * If I would have written the Blog App myself, I would have made a Script Service in Java to put the business logic away from Velocity. * We have plenty of extensions having Java modules. A better approach would be to authorize the installation of approved and/or signed modules even when the admin has not the programming right. Since we need a collegial decision, I am asking you your opinion :) Thanks, [1] http://jira.xwiki.org/browse/XWIKI-13861 -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

8 years, 9 months

2
2
0 0

[xwiki-devs] [ANN] Release of Nested Pages Migrator Application 0.6

by Guillaume Delhumeau

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

8 years, 9 months

1
0
0 0

[xwiki-devs] Replace the Mailing Lists by a Forum

by Guillaume Delhumeau

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

8 years, 9 months

6
17
0 0

[xwiki-devs] [ANN] XWiki 8.4.1 released

by Eduard Moraru

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

8 years, 9 months

1
0
0 0

[xwiki-devs] Fwd: [xwiki-users] Re-organize the Drawer's entries

by Guillaume Delhumeau

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

8 years, 9 months

4
9
0 0

[xwiki-devs] Why are extensions of same version removed when installing a new extension?

by Vincent Massol

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

8 years, 9 months

3
9
0 0

[xwiki-devs] Msissing deps somewhere on fontawesome

by Vincent Massol

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

8 years, 10 months

1
1
0 0

[xwiki-devs] [Brainstorming] XWiki Architecture after 10+ years: what's next?

by Vincent Massol

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

8 years, 10 months

3
2
0 0

[xwiki-devs] Bootstrap 3.x.x will no longer be developed

by Guillaume Delhumeau

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

8 years, 10 months

4
4
0 0

[xwiki-devs] [Proposal] Make it simple for users to have filterable/sortable tables by default in XE

by Vincent Massol

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

8 years, 10 months

4
3
0 0

[xwiki-devs] Inconsistency between Flamingo Skin and Icon Theme Application

by Guillaume Delhumeau

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

8 years, 10 months

2
1
0 0

[xwiki-devs] [ANN] XWiki 8.4 released

by Guillaume Delhumeau

The XWiki development team is proud to announce the availability of XWiki 8.4. This version brings a lot of usability improvements. The WYSIWYG editor ( *CKEditor*) has been upgraded and proposes a better dialog for the creation of links. It is also possible to configure it from the administration. Application Within Minutes does not enforce anymore the location where the application's entries must be created, but proposes to the creator the places *where* and *from where* these entries should be. We have also get rid of the Data page where the entries where created before. The default values of the user preferences are now better exposed to the users. The order of the applications in the application panel can now be changed by the administrator. And the users now have the ability to filter the page types when they create a page. As usual plenty of less noticeable improvements are proposed, and 45 bugs have been fixed since XWiki 8.3. 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/ Thanks for your support -The XWiki dev team

8 years, 10 months

1
0
0 0

[xwiki-devs] [XWiki Day] BFD#126

by Alexandru Cotiuga

Hello devs, This Thursday is BFD#126: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 44 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=100 00#Created-vs-Resolved-Chart/10470 Here's the BFD#126 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13704 Have a nice BugFixing Day, Alex

8 years, 10 months

1
0
0 0

Re: [xwiki-devs] [xwiki-users] Lots of disabled Yahoo email addresses on the xwiki.org lists

by Pascal BASTIEN

Hello, It is strange because my emails have a DKIM signature like here (piece of header from a mail I sent from my xwiki email to myself at another adress). Is it sympa who's altering this signature? Can I fix it (if it is "my fault")? Thxs Pascal ---------------------------------- Received: from nm43-vm5.bullet.mail.gq1.yahoo.com (nm43-vm5.bullet.mail.gq1.yahoo.com [67.195.87.220]) xxx DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s2048; t=1478593132; bh=g3zLYH4xKxcPrHOD18z9YfpQcnk/GaJedfustWU5uGs=; h=Date:From:Reply-To:To:Subject:References:From:Subject; b=N6C8UltuP6jp4mZaWG43Y1ngel4R75RdftqTuXxYHngnseuGe5/2k2/H5pwVcJVe34gjtB33vMZm1j4yZ56M8++zNl4Asb4xV/6wwF+JL+ZGlcXTmfJdGlx5+GdukOzN6bX9Dz9Lvp5GpsYHZnWE8eANw0SeJ9t9wcvzKmNOYW+t9S53N27nfRfjYAwm7iZVmUsgbbZlpnW3NYrPOLoBGZX67aq6gsq877LKUyLLgLP5oszQnx3cUZAsgmjRuSYIIzjF42vfzjVjs7rOoO7royNl5O8BeFlgpevF/BDk2g2K7KXRTkkKtmDMxxxx -------------------------------------------- En date de : Lun 7.11.16, Sergiu Dumitriu <sergiu(a)xwiki.org> a écrit : Objet: Re: [xwiki-users] Lots of disabled Yahoo email addresses on the xwiki.org lists À: "XWiki Users" <users(a)xwiki.org>, "XWiki Developers" <devs(a)xwiki.org> Date: Lundi 7 novembre 2016, 15h40 By the way, all of Pascal's and Julio's emails (and other yahoo users) end up in my spam folder because of the broken DKIM signatures. On 11/07/2016 09:24 AM, Sergiu Dumitriu wrote: > This is partially XWiki's infrastructure fault, too. > > DMARC doesn't work well with mailing lists, since they tend to break > DKIM signatures. The only way to fix the problem (at least for the > majority of emails) is to remove the footer from the configuration. > > So, options: > > - remove the footer, which means that "incompetent" users will have a > hard time finding information about unsubscribing, but allows users from > modern email providers to subscribe > - keep the footer, which makes it harder for legitimate users to stay > subscribed >

8 years, 10 months

2
2
0 0

[xwiki-devs] [ANN] Forum Application v2.2 Released

by Alexandru Cotiuga

Hello all, A new version of the Forum Application extension is available. In order to see the latest changes check the Release Notes <http://extensions.xwiki.org/xwiki/bin/view/Extension/ForumApplication#Hv2.2>. See also the XAFORUM-231 <https://jira.xwiki.org/browse/XAFORUM-231> and XAFORUM-236 <https://jira.xwiki.org/browse/XAFORUM-236> which have been closed as duplicates and fixed in CKEditor Application. You can install or upgrade it with the Extension Manager. Thanks, Alex

8 years, 10 months

1
0
0 0

Re: [xwiki-devs] [xwiki-users] Lots of disabled Yahoo email addresses on the xwiki.org lists

by Sergiu Dumitriu

This is partially XWiki's infrastructure fault, too. DMARC doesn't work well with mailing lists, since they tend to break DKIM signatures. The only way to fix the problem (at least for the majority of emails) is to remove the footer from the configuration. So, options: - remove the footer, which means that "incompetent" users will have a hard time finding information about unsubscribing, but allows users from modern email providers to subscribe - keep the footer, which makes it harder for legitimate users to stay subscribed On 11/02/2016 07:57 AM, Vincent Massol wrote: > Hi everyone, > > Just to let you know that on the 28th of October, there were 234 members of the xwiki users list who’ve been automatically disabled (ie they’re not going to receive mails). This is apparently caused by a change in Yahoo’s email policy: > > <gumush(a)gmail.com>: host gmail-smtp-in.l.google.com[74.125.133.27] said: > 550-5.7.1 Unauthenticated email from yahoo.com.br is not accepted due to > 550-5.7.1 domain's DMARC policy. Please contact the administrator of > 550-5.7.1 yahoo.com.br domain if this was a legitimate mail. Please visit > 550-5.7.1 https://support.google.com/mail/answer/2451690 to learn about > the 550 5.7.1 DMARC initiative. o3si17254181wjx.109 - gsmtp (in reply to > end of DATA command) > > So if you’re in that case, please contact Yahoo as mentioned in the message above. > > Thanks > -Vincent -- Sergiu Dumitriu http://purl.org/net/sergiu

8 years, 10 months

1
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs