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

[xwiki-devs] [XWiki Day] BFD#124
by Alexandru Cotiuga 28 Oct '16

28 Oct '16

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

1 1

[xwiki-devs] Re-organize the Drawer's entries
by Guillaume Delhumeau 26 Oct '16

26 Oct '16

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

1 1

[xwiki-devs] [Proposal] Push Markdown Syntax 8.2 artifacts to Maven Central?
by Vincent Massol 24 Oct '16

24 Oct '16

Hi devs, I’m referring to those artifacts: http://maven.xwiki.org/releases/org/xwiki/contrib/markdown/ Rationale: So that XWiki Rendering can be used with Markdown syntax without having to add the XWiki remote Maven repository. Is it ok with everyone to push contrib artifacts to Maven Central (it's the first time we'd do this!)? Right now we have only commons and rendering artifacts, see http://repo2.maven.org/maven2/org/xwiki/ I'm asking since we cannot undo this… Thanks -Vincent PS: We have the same question for Mediawiki artifacts (except mediawiki-xml which depends on platform) now that they are in contrib too: http://maven.xwiki.org/releases/org/xwiki/contrib/mediawiki/

2 2

[xwiki-devs] [Contrib] Request repository for "macro-salesforce"
by Ludovic Dubost 23 Oct '16

23 Oct '16

Hello devs, I want to publish a macro to interact with salesforce. It will be a few macros with groovy code and some samples to show how to use them. - a repository on xwiki-contrib called "macro-salesforce" - no e.x.o page yet, as I will release the app once it's commited (it's not fully ready as it still needs some cleanup) - username: ldubost Thanks, Ludovic -- *Ludovic Dubost* *Founder and CEO* ludovic(a)xwiki.com skype: ldubost Blog: http://blog.ludovic.org <https://r.clb.pt/r/a381866da7040c7d0e2c752c06945349?d=http%3A%2F%2Fblog.lud…>

2 1

[xwiki-devs] [Contrib] Request repository for "macro-elasticsearch"
by Ludovic Dubost 23 Oct '16

23 Oct '16

Hello devs, I want to publish a macro to interact with elastic search and kibana4. It will be a two macros with groovy code and some samples to show how to use them. - a repository on xwiki-contrib called "macro-elasticsearch" - no e.x.o page yet, as I will release the app once it's commited (but it's ready) - username: ldubost Thanks, Ludovic -- *Ludovic Dubost* *Founder and CEO* ludovic(a)xwiki.com skype: ldubost Blog: http://blog.ludovic.org <https://r.clb.pt/r/9a7b6e136c9008b49ba6caeefdd7dc35?d=http%3A%2F%2Fblog.lud…>

2 1

[xwiki-devs] Fwd: [XWiki] Feedback form reply
by Vincent Massol 22 Oct '16

22 Oct '16

FYI, there might be some stuff to improve/fix in CKEditor. Thanks -Vincent > Begin forwarded message: > > From: Akiyoshi Yamakawa > Subject: Re: [XWiki] Feedback form reply > Date: 22 October 2016 at 16:48:10 GMT+2 > To: Vincent Massol <vincent(a)massol.net> > > Hi Vincent > > Thank you for taking time to reply me, > and sorry for late response from me. > > Your advice is very helpfull and the following problems are solved: > (1) url link target=_blank > (2) Character foreground color and background color buttons in CkEditor > (3) About PDF export , Japaese Characters(multi byte) output seems incorrect > like another Wiki products like DekiWiki, etc. > But copying/pasting to MS-Word or Libre Office Writer as html document and > using it's PDF output is sufficient for me. > > It's going very well for me about Xwiki !! > Thak you and your team all and Xwiki community!! > > Best Regards, > Akiyoshi Yamakawa(Okinawa Japan) > > > 2016-09-12 16:16 GMT+09:00 Vincent Massol <vincent(a)massol.net <mailto:[email protected]>>: > Hi Akiyoshi > > I’ve noticed your remark about XWiki in the feedback form: > > “ > On Xwiki8.2.1, link function of ckeditor doesn't work well. There is no setting in ckeditor link dialog about setting target="_blank". I feel it is better to use Xwiki7.4.x with ckeditor Extension & customize application-ckeditor-webjar-1.3.x.jar to full functional ckeditor. My main reason to use ckeditor is to avoid wiki tag setting like ||target="_blank" . Most of users want to use ckeditor Full function version, not want to use wikitag. > " > > Answer: > Please check http://extensions.xwiki.org/xwiki/bin/view/Extension/CKEditor+Integration#H… <http://extensions.xwiki.org/xwiki/bin/view/Extension/CKEditor+Integration#H…> > > Note: > When you have some question about XWiki you could ask it on the forum/user mailing list, see http://dev.xwiki.org/xwiki/bin/view/Community/MailingLists <http://dev.xwiki.org/xwiki/bin/view/Community/MailingLists>. This is the place where all xwiki developers and users are and you’ll get the best support there! :) > > Thanks for your feedback, that helps us a lot! > -Vincent > XWiki committer > >

1 0

[xwiki-devs] [XWiki Day] BFD#123
by Alexandru Cotiuga 21 Oct '16

21 Oct '16

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

1 1

[xwiki-devs] Release notes strategy for included contrib extensions
by Vincent Massol 19 Oct '16

19 Oct '16

Hi devs, We now include a few contrib apps in XE. However, when someone checks the RN for XE, for example http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki83M2 all they see is this: “The following dependencies have been upgraded: * Tour Application 1.0.4” It doesn’t say if there are any substantial things added those deps. I can think of 2 solutions: 1) When something is noticeable, add it to the RN of XE. So for example if CKEditor extension adds something new, users checking the RN of XE can see it immediately. 2) Link to the RN of the extension. However RN of extensions on e.x.o are not nice. They’re just lists of JIRA issues. So for this solution to be a bit satisfactory we would need to improve the RN of extensions, starting with those we bundle in XE. Another possibility is to say that for Recommended Extensions we pay an extra care to write nice Release Notes. But that’s harder to enforce and ensure. Option 1) is my preference. WDYT? Thanks -Vincent

6 9

[xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general
by Vincent Massol 19 Oct '16

19 Oct '16

Hi devs, With the recent introduction of the Applications Index (see http://extensions.xwiki.org/xwiki/bin/view/Extension/Application+Index+Appl…) we need to agree on a few things. In the past we had: * We wanted all new app that you installed to automatically be visible in the Applications Panel * This is why the Applications Panel config had a blacklist (and not a white list) What we’ve done: * We add the Applications Index * We removed some apps from the Applications Panel. Namely: Invitation, Panels, Scheduler, User Directory and Tour applications. this was done using hardcoded blacklist xobjects in PanelsCode.ApplicationsPanelConfiguration. The need: * We need to remove this hack. It’s not normal for the Panels module to know all the apps that shouldn’t be listed in it! Proposal: * Replace the blacklist configuration of the Applications Panel by a whitelist one * When a new app is installed, list it in the Applications Index but don’t add it to the Applications Panel * If an admin wants to add this new for his users, he’ll need to add it in the Admin UI for the Applications Panel. WDYT? Thanks -Vincent

6 16

[xwiki-devs] [Proposal] Disable Message Stream by default in platform distribution + XE
by Vincent Massol 18 Oct '16

18 Oct '16

Hi devs, I’m working on http://jira.xwiki.org/browse/XWIKI-10543 and it’s been reported by Nicolas that all the users he’s seen use XWiki don’t use the Message Stream feature and moreover they even ask him to remove it. One specific issue he’s raised is that the messages are sent to the AS (either the global one or the user’s one) and the messages are drowned with the page updates. Basically we’d need to polish this feature better to make it really useful. I agree with this POV. I also agree that in order to make XWiki simpler and less cluttered, this feature could be disabled. Thus I’m proposing to still bundle it but to disable it, since we already have a Message Stream Admin UI config. WDYT? Thanks -Vincent

7 10