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

by Marius Dumitru Florea

Hi devs, The 8.4 release is planned for today but I would like to postpone it for 2 days, so for Wednesday 9 November, in order to finish: * http://jira.xwiki.org/browse/XWIKI-13761 * http://jira.xwiki.org/browse/XWIKI-13360 * https://jira.xwiki.org/browse/CKEDITOR-68 which I believe are very important. I hope this is fine with you. Thanks, Marius

8 years, 10 months

2
1
0 0

[xwiki-devs] [Proposal] Add authclass property to the XWikiPreferences class

by Alexandru Cotiuga

Hi devs, I'm proposing to add this new property to the *XWikiPreferences* class since there are many authenticators, listed on http://platform.xwiki.org/xwiki/bin/view/Features/Authentication and most of them require the overriding of the *xwiki.authentication.authclass* property in the *WEB-INF/xwiki.cfg* file and the restart of the wiki. So the *authclass* is meant to keep the value of the *xwiki.authentication.authclass *property*.* Please keep in mind that *xwiki.cfg* was the historical file containing the configuration options, we're moving away from it and this can be the moment to improve this functionality by removing the *restart wiki* step which is often a pain for the user. Thanks, Alex

8 years, 10 months

4
7
0 0

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

by Alexandru Cotiuga

Hello devs, This Thursday we had BFD#125: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 54 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=100 00#Created-vs-Resolved-Chart/10470 Here's the BFD#125 dashboard: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13702 See the results on our blog post: http://www.xwiki.org/xwiki/bin/view/Blog/Bug+Fixing+Day+125 Thanks, Alex

8 years, 10 months

1
0
0 0

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

by Ecaterina Moraru (Valica)

Hi Guillaume, Thanks for starting this thread. ---------------------------------------------------------- Current Drawer analysis: Languages ( L / G ) --- Home ( G ) [N] --- Administer wiki ( L ) [A] [W] --- Wiki Index ( G ) [I] [W] Page Index ( L ) [I] User Index ( L / G ) [I] Applications Index ( L) [I] --- Create wiki ( G ) [A] [W] --- Delete wiki ( L ) [A] [W] L = Local/Wiki setting/action/effect G = Global/Farm setting/action/effect N = Navigation A = Action W = Wiki entity ---------------------------------------------------------- Some examples of grouping: 1. Local / Global effect grouping (ex. Main/Subwiki actions should be grouped) 2. Entities grouping (Wiki related actions should be grouped: create, administer, delete, etc.) 3. Index grouping (group all index applications together) 4. Navigation grouping (to Main wiki or other wikis) 5. Actions grouping 6. other? So the main question is what grouping would we want to prioritize first: 1-5? ---------------------------------------------------------- Some things to consider: A. Naming consistency: A1. Across wiki: we need to consider the terms usage. For example Home vs. Homepage; Wiki vs. Subwiki; Settings vs. Administration; Wiki Index vs. Browse all wikis vs. Show all wikis -- We need to align these usages and pick the one most relevant for the end user and correct as terminology A2. Across the menu: this implies having all entries plural/singular or having the same additional text (ex. do we mark Indexes the same way? Administer wiki / Delete this wiki / Create a new wiki, etc.) B. Explicit (vs. Cryptic) -- how explicit should we make the labels vs. icons usage C. Quick access to local actions -- in subwikis we should optimize for local actions and try to display them first, since some teams might have dedicated wikis and the main wiki could be used just as a portal or as a farm D. Order most used actions first -- for example 'Delete wiki' is not a very used action E. Navigation vs. Actions grouping E1. Actions removal -- for example we could even remove 'Delete wiki' action and consider that the wiki management actions can be accessed just from Wiki Index -- this would mean that 'Administrate wiki' would be removed too, and we use that action a lot in the initial configuration phases, so that would increase the time to reach Administration E2. Adding more wiki navigation -- For example http://jira.xwiki.org/browse/XWIKI-12538 talks about having a way to add quick access to other subwikis (ideally as favorites, since listing all wikis does not scale) ---------------------------------------------------------- Proposals grouping feedback: Current. -1 (Local/Global), -2 (Wiki grouping), +3 (Indexes), partial 4 (Navigation), -5 (Actions) || +A2 (Naming consistency), -C (Quick access) P1. -1 (Local/Global), partial 2 (Wiki grouping), +3 (indexes), partial 4 (Navigation), partial 5 (Actions) || +A2 (Naming consistency), -C (Quick access) P2. partial 1 (Local/Global), -2 (Wiki grouping), partial 3 (Indexes), -4 (Navigation), -5 (Actions) || +A2 (Naming consistency), +C (Quick access) P3. partial 1 (Local/Global), -2 (Wiki grouping), +3 (Indexes), -4 (Navigation), -5 (Actions) || +A2 (Naming consistency), +C (Quick access) P4. -1 (Local/Global), partial 2 (Wiki grouping), +3 (Indexes), -4 (Navigation), +5 (Actions) || +A2 (Naming consistency), partial C (Quick access) ---------------------------------------------------------- The problem is that when you approach an usability problem using these kind of grouping / grading it's very easy to fall in the 'technicalities' trap and not think about the user perspective. So although I understand why I proposed P1-4, for users it will not make sense. That's why I like P5, because the grouping comes natural and is more explicit, although is not using the consistent terminology. P5: +1 (Local/Global), -2 (Wiki grouping), -3 (Indexes), partial 4 (Navigation), -5 (Actions) || -A2 (Naming consistency), -A1 (Across wiki), +B (Explicit), +C (Quick access to local), ? D (Most used actions) Things to fix for P5: - Think where to fit the "Languages" - A1 + A2: we need to think about the naming of Indexes (especially Wiki Index in this case) and fix them in drawer and across; replace Settings with Administration; fix the "Go to ..."; consistent actions naming. Additionally we should fix A1 (see http://jira.xwiki.org/browse/XWIKI-9363) ---------------------------------------------------------- Before starting this thread I tried to rethink about a new solution and I came up with P6: -1 (Local/Global), +2 (Wiki grouping), +3 (Indexes), +4 (Navigation), +5 (Actions) || +A2 (Naming consistency), -A1 (Across wiki), -B (Cryptic/Iconography), -C (Quick access), ? D (Most used actions), +E2 (More navigation) i) Having Indexes listed before local actions (will give a -C for quick access), but the advantage is that the menu composition will change less if we visit main wiki vs. subwikis. P5 also have this propety. ii) I've grouped and added more navigation by providing the list of wikis. There are several problems with this approach: ii.1 - not scalable for large number of wikis (even though I've put an accordion there) ii.2 - cryptic actions (icon usage for Create, Administration, Delete wiki) ii.3 - mobile issues (because the icons are very small and we will need a different layout for mobiles or we might have problems with large wiki names) ---------------------------------------------------------- Thanks, Caty On Wed, Oct 26, 2016 at 11:42 AM, Miroslav Galajda < miroslav.galajda(a)gmail.com> wrote: > Hi, I vote for P5 proposal. > > Mirec > > On 26 October 2016 at 10:28, Guillaume Delhumeau < > guillaume.delhumeau(a)xwiki.com> wrote: > > > 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 > > > > > > > > > > > -- > > 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 >

8 years, 10 months

3
4
0 0

[xwiki-devs] [ANN] XWiki 8.4 Release Candidate 1 released

by Marius Dumitru Florea

The XWiki development team is proud to announce the availability of XWiki 8.4 Release Candidate 1. The highlights of this release are the new page type filter from the Create Page form and the new configuration section for the CKEditor. Changing the supported languages from the administration has been made easier with the new language picker. Ordering the Application panel items is now possible with simple drag & drop. Sub-wiki initialization is now asynchronous. As usual the release also includes many bug fixes and smaller improvements. 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.4RC1/ Thanks for your support -The XWiki dev team

8 years, 10 months

1
0
0 0

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

by Alexandru Cotiuga

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

8 years, 10 months

1
1
0 0

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

by Guillaume Delhumeau

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

8 years, 10 months

1
1
0 0

[xwiki-devs] [Proposal] Push Markdown Syntax 8.2 artifacts to Maven Central?

by Vincent Massol

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/

8 years, 10 months

2
2
0 0

[xwiki-devs] [Contrib] Request repository for "macro-salesforce"

by Ludovic Dubost

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…>

8 years, 10 months

2
1
0 0

[xwiki-devs] [Contrib] Request repository for "macro-elasticsearch"

by Ludovic Dubost

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…>

8 years, 10 months

2
1
0 0

[xwiki-devs] Fwd: [XWiki] Feedback form reply

by Vincent Massol

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:vincent@massol.net>>: > 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 > >

8 years, 10 months

1
0
0 0

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

by Alexandru Cotiuga

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

8 years, 11 months

1
1
0 0

[xwiki-devs] Release notes strategy for included contrib extensions

by Vincent Massol

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

8 years, 11 months

6
9
0 0

[xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general

by Vincent Massol

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

8 years, 11 months

6
16
0 0

[xwiki-devs] [Proposal] Disable Message Stream by default in platform distribution + XE

by Vincent Massol

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

8 years, 11 months

7
10
0 0

[xwiki-devs] Problem of certificate in latest XE build

by Vincent Massol

Hi devs, I’ve rebuilt XE today from sources and I got the following certificate errors in my console: https://gist.githubusercontent.com/vmassol/ebea2da98f00771b3af5cb3ce90c582b… As you can see there are a lot of errors displayed. We need to fix this ASAP. Thanks -Vincent

8 years, 11 months

3
7
0 0

[xwiki-devs] [Usability] Newbie feedback - Creating pages

by Vincent Massol

Hi devs, Over the weekend I asked my brother in law (who doesn’t anything about XWiki) to test it and give me some feedback. He did this test with me next to him so I could observe and ask him what was going through his head. I’m sending below a summary of the session. We now need to address each point and see what we want to do to improve the situation. The Setup ======== * HSQLDB/Jetty already setup with an Admin user already logged in. * I had made the Admin user a simple user. * I later realized that I had forgotten to remove my local cookie on my computer and he didn’t have the Tour. Thus I don’t know if he’d have read it till the end of not. * I asked him 2 things only: ** Create some new pages ** Modify the home page The Feedback =========== * First thing he wanted to do was to switch the UI to French (he’s French). He looked for his user profile, found it, and couldn’t find a way to change the language. Fail. I had to tell give him the hint that language was a global wiki-level setting and I had to do it for him. Other feedback: The French translation for the language settings is really not user-friendly and needs to be changed, it’s currently “Localisation”, which is too technical. * Then he said he spotted a bug. The home page had a title of “Home” in French instead of “Accueil”. * He looked around in the UI and at some point he clicked on Page Administration on the home page. This opened a UI with a title of "Administration : Main”. He asked: “what is Main?”. Indeed he was on the home page that was entitled “Home” and suddenly he was shown “Main” which 1/ was in English and 2/ didn’t mean anything to him. * Then he went on to create a new page and initially was looking for that in the drawer in the Wiki Administration UI… At some point, I had to tell him to stop and I created a simple user for him (that is not Admin so that he couldn’t do in the wiki administration - I should have started with this probably although we need to fix our issue that first time users are admins). Once this was done he was able to quickly find the “+” to create a new page. * However, he wanted to create a structure with a “Domain” folder and some pages inside that folder. He saw the Tree in the Navigation Panel and saw that it was hierarchical and thus he wanted to do the same and create that “Domain” folder first. So he cancelled the Create Page UI since this was about creating a page and he wanted a folder. He then found the “Children Pages” entry in the “More” menu. Note that in French it’s badly labelled as “Enfant de XXX” which was weird to him (FTR it’s also invalid grammatically, missing an “s” for plural) but he understood it was related to children page he suggested “Sous-pages” as a better translation). So he clicked on it and he saw a form displayed (actually it was the filter of the LT UI). And he started typing “Domain” in the text input but nothing happened and he was puzzled. —> When you look at the children LT for a page not having children, you’ll see that we should improve the UI. It doesn’t even say that’s it’s empty and that there are no children pages… * At this point he was a bit stuck and couldn’t understand how to create a folder. I had to tell him that in XWiki you could created hierarchical pages and that there’s no notion of folders (I didn’t want to explain the concept of Spaces especially since he hide this in the UI). He mentioned that after 20 years of Microsoft practice, everyone understands the concept of folders and files and that it’s hard to understand that we only have hierarchical pages. He suggest that we may want to have 2 “+” buttons next to each other (like “+” and “++” or some other visual with a tooltip of “Créer page” and “Créer sous-page"). One to create sibling pages and another one to create children pages). In his head, the default when you create a page is to create a sibling page, not a sub-page. * After this he was able to create his pages (note that he used immediately the templates we provided for his test and selected the Encyclopedia template). * He noted that the icon for Rename/Move/Delete was weird and he didn’t understand the relationship between the actions and the icon which is the one for settings (the cog). He suggested to use something different like a rubber (which incidentally I see that it’s missing from http://design.xwiki.org/xwiki/bin/view/Proposal/XWiki+Icon+Set and we need to add it). FYI he was no longer Admin at this point so the “Page Administration” entry wasn’t visible. * When he edited his first page, he quickly told me that that the “Save” buttons are way too hidden (they’re usually not even visible when you edit if you don’t scroll down). He was expecting them to see them at the top, close to the page menus. He suggested that we should have a horizontal bar that stays always visible when you scroll down and that contains the save buttons. * At this point he created a hierarchy of pages and then wanted to move some page around to test this feature. However he could find the menu entry to do so. He could easily find the move, copy and delete entries but that’s not what he was looking for. The reason is that the French translation is “Renommer”. On English I see that we’ve now renamed it to "core.menu.rename=Move / Rename”. But the French translation is still “Renommer”. When I suggested to have “Renommer / Déplacer” to him he said that he’d simply call it “Déplacer” since for renaming a page he doesn’t need to go to that screen and he can simply edit the page and change the title. He said it’s fine to leave the ability to change the title on the Move UI but that it was just a nice bonus and not the main goal of this screen in his opinion. * On the Rename UI screen, he started by clicking in the source breadcrumb, and he was surprised that the browser navigated away. Later on he realized that the was a target section. At this point he commented that he expected to see the target first since that’s what he wanted to change. He also suggested that if would be simpler to use if the target breadcrumb was replaced by a Tree to choose the new location. * When he tried to modify the home page he did it very easily and was able to put his own content. When I told him that some user find it difficult to understand that they could modify the home page he said that it’s not the first thing he’d have done. * On the positive side, the navigation panel was really nice for him. He kept using it all the time to navigate. Thus navigation wasn’t an issue for him. That’s it. Hope we can use this to improve basic user experience. The biggest item by far is to make users understand that there’s no folder and that there’s only hierarchical pages. I think I like his idea of the 2 add buttons (create sibling page and create children page), or something similar (I guess the Create UI itself could have a different UI to ask the user clearly if he/she wants to create a sibling or a children page). Thanks -Vincent

8 years, 11 months

2
5
0 0

[xwiki-devs] [Proposal] Officially deprecate GWT WYSIWYG editor and don't fix issues related to it

by Vincent Massol

Hi devs, I’d like that we agree on an official position re the GWT WYSIWYG editor. We’ve already decided to make CKEditor the default editor and to keep the GWT editor bundled (but off by default) till the end of the 8.x cycle. I’d like now that we agree about 2 points: * We don’t fix issues related to the GWT editor that do not reproduce on the CKEditor editor. * Now remains the question as to whether we close them as won’t fix or not. Ideally the best IMO is to create a new JIRA project for the GWT Editor in the Contributed Extensions category, and move all opened JIRA issues to it. We create a version labelled “Previous versions when the GWT editor was in platform” so that we can use that as affects. Of course another option would be to not touch those issues FTM and wait till we do the move in 9.0+. I prefer moving the issues now if we agree now that we don’t fix issues related to the GWT editor. WDYT? Thanks -Vincent

8 years, 11 months

5
4
0 0

[xwiki-devs] [Proposal] Having the docextra tabs in edit mode.

by Guillaume Delhumeau

Hi. Currently a user have 2 ways to attach a file to a wiki page: - in the attachment tab in VIEW mode only ; - if it's an image, using a WYSIWYG editor. However, if it's not an image, you cannot add it while you're writing the content. It's a bit as if you were not able to attach a file while you were writing an email... not user friendly! So we have this issue: http://jira.xwiki.org/browse/XWIKI-5400 To fix it, I see 2 options: - add the handling of attachments in edit mode. - add *all* docextra tabs like we have in view mode (it's not because you are editing a page that you don't need to see the history of the page, nor the comments). But this might be not relevant for the class and the object editor. My proposal: * Display docextra tabs by default. * In class and object editors, set $docExtras = []. * Set $docExtras = [] in all sheets where we consider it's not relevant to have the tabs. WDYT? Thanks, -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

8 years, 11 months

6
10
0 0

[xwiki-devs] [Proposal] Roadmap for 8.4.x till end of the year

by Vincent Massol

Hi devs, After discussing with XWiki SAS internally here’s a list of items that’s interesting to fix for XWiki SAS (in that order, from top to bottom) from now till end of the year (i.e. 8.4.x). The goal is to try to take as many issues as possible from this list, starting from top to bottom. Process I propose: * For each dev, take an issue that is the closest possible from the top and work on it. Put your name on http://www.xwiki.org/xwiki/bin/view/Roadmaps/ and assign yourself to the jira issue. * Once done, repeat. * The names put below are just indicative and should be considered as ideas of devs who could work on them. Ordered list (top is most important): * Periodic crashes with ClassLoader related locking issue - XWIKI-13792 - Thomas * Admins should be able to decide the order in which apps are displayed in the Applications Panel - XWIKI-13075 - Guillaume * When I'm in full mode I would like to save directly without returning to normal Edit Mode - CKEDITOR-112 - Marius? * Make the WYSIWYG admin UI display configuration for all available WYSIWYG editors - XWIKI-13654 - Marius? * Sort Recommended Extensions by Ratings when no search query is specified - XWIKI-13779 - Thomas * When inserting large images while editing, it should all fit, the user should not need to scroll to the right to see it all. - CKEDITOR-108 - Marius? * Clarify the Hamburger Menu - XE-1582 - Guillaume * Provide an option in the AWM wizard that creates a Template Provider for the app - XWIKI-13761 - Marius? * Solr search UI is still very slow - XWIKI-13192 - Thomas * Provide a way to filter templates in the creation step - XWIKI-13762 - Guillaume * Simplify creation of New link to new page in CKEditor - CKEDITOR-116 - Marius? * Cannot upgrade the CKEditor extension - XE-1570 - Guillaume? * Cannot delete document with many large attachments - XWIKI-8910 - Thomas * For regular users, "Data" level is confusing in the Pages tree for an application created with App Within Minutes - XWIKI-13360 - Guillaume? * Customizing the PDF export CSS could cause a NPE - XWIKI-13457 - Vincent * The parent-child relationship of a page is not updated during a move - XWIKI-13493 - Marius? * Add Check List of actions to perform to create first content in XWiki with links to video tutorials - (Missing JIRA) - Caty? * --Attachments are not copied from a Template Provider - XWIKI-13524 - Edy-- * Extension Manager add extension search should suggest only compatible versions - XWIKI-9920 - Thomas? * Hard to understand which is the default value for Profile's Preferences entries (edit/view mode) - XWIKI-7715 - Guillaume * Adding a new overriding template resulted in the creation of 190 XWikiSkinFileOverrideClass - XWIKI-13179 - Thomas? * Demo Content Inside XE - (Missing JIRA) - Caty? * Admin UI to allow disabling tours on a given wiki or for all wikis - TOUR-50 - Guillaume? * Bad Image Scaling Quality - XWIKI-7623 - Guillaume? * See to which groups a user belongs to - XWIKI-1901 - Guillaume? * Make a tool to evaluate the status of the hierarchy before running the nested spaces migrator - NPMIG-46 - Guillaume * Hide "XWiki" space from Navigation Tree - (Missing JIRA) - ? * Reorder the "Create a Page" menu steps in a more coherent way - XE-1588 - Marius? * Allow resetting changes found by the "Compute change" feature of EM - XWIKI-13747 - Thomas * Admin tools doesn't work anymore on 8.0+. In general test features to see if they work in 8.3+ - ADMINTOOL-45 + ADMINTOOL-46 + ... - Alex * Add highlighted text to invite newcomers to click on the edit button to start modifying content - XE-1583 - Caty? * Change the user type for the Admin user to 'simple' - XE-1580 - Guillaume? * Page creation date should be the date of the installation - XWIKI-7058 - Thomas? * Add an administration control panel for the redirects created on rename - XWIKI-13385 - Guillaume? * Add "Index Page" Template - TEMPLATES-7 - Caty? * Deactivate "section editing" by default and/or hide them in CSS and display them with hover - (Missing JIRA) - Caty? * Change saved into a LESS SSX that is already cache does not always get recompiled - XWIKI-13300 - Thomas? * Have an option to edit directly in full screen mode - XWIKI-13793 - Marius? * Add support for nested spaces in Distribution Wizard report - XWIKI-12270 - Guillaume? * Remove XWiki Enterprise and transform it into a Knowledge Base Flavor - XE-1581 - Thomas * Replace Home Page with actual content and move current Home page to a documentation page accessible from that home page - (Missing JIRA) - Caty? * Move "Last modified by" next to "Create by" - (Missing JIRA) - Caty? * Display sponsored extensions on extensions.xwiki.org - XINFRA-211 - Vincent * Implement a View mode in addition to Standard/Advanced, with cookie based setting - (Missing JIRA) - Caty? * Put the "Add a new page" button is (really) outside of the Menu relating to the current page (because it's about another page) - XE-1587 - Caty? * Allow searching for Forum discussions - XAFORUM-144 - Alex * Rights can be lost after a migration - NPMIG-20 - Guillaume * Missing indexes in 3.2 index auto creation system - XWIKI-7125 - Thomas? * LESS compilation of SSX may sometimes generate invalid CSS with missing colors - XWIKI-13299 - Guillaume? * Allow upgrading a flavor in Distribution Wizard - XWIKI-12148 - Guillaume? * Use the language set for the Main Wiki for newly created subwikis - XWIKI-11431 - Guillaume * Deactivate messaging feature by default - XWIKI-10543 - Alex? * Clarify advanced Users "Edit Menu" + use the term "Duplicate" instead of "Copy" in the wheel menu - XWIKI-13774 - Caty? * Maps not working because of missing API key - MAP-13 - Alex * When leaving the edit mode without saving, notify the user that there are changes he needs to save - XWIKI-6927 - Guillaume? * Allow inviting global groups to a subwiki - XWIKI-7531 - Guillaume? * Make the "redirect" option on page rename configurable - XWIKI-13384 - Marius? * Add an option to disable automatic silent merges when upgrading an extension - XWIKI-12705 - Thomas * Redesign the delete UI to look more like the other refactoring actions - XWIKI-12548 - Guillaume? * In the CKEditor, I would like the toolbar to be displayed in one line (and not 2) - CKEDITOR-110 - Marius? == Dates == * 8.4RC1: 31 October 2016 * 8.4Final: 7 November 2016 * 8.4.1: 21 November 2016 * 8.4.2: 5 December 2016 * 8.4.3: 19 December 2016 * 8.4.4: 9 January 2017 (to account for Christmas + new Year celebrations) WDYT? Note that I’ve put this on http://www.xwiki.org/xwiki/bin/view/Roadmaps/ @Non XWIKI-SAS developers: please add any item you’d like to work on to the list and on http://www.xwiki.org/xwiki/bin/view/Roadmaps/ and put your name next to it! (that’s if you wish to make it visible to all, no pressure ;)). Thanks -Vincent

8 years, 11 months

1
0
0 0

Re: [xwiki-devs] [Proposal] Having the docextra tabs in edit mode.

by Denis Gervalle

+1 for your proposal until we have a better solution. I would avoid comment tab if ever possible, since it increase the inconveniences already explained. I agree with almost all other comments, but until we have time for something better, this proposal would be a first improvement. We should just ensure it does not cause any regression. -- Denis Gervalle SOFTEC sa - CEO On Fri, Oct 14, 2016 at 12:19 PM, Denis Gervalle <denis.gervalle(a)softec.lu> wrote: +1 for your proposal until we have a better solution. I would avoid comment tab if ever possible, since it increase the inconveniences already explained. I agree with almost all other comments, but until we have time for something better, this proposal would be a first improvement. We should just ensure it does not cause any regression. -- Denis Gervalle SOFTEC sa - CEO On Thu, Oct 13, 2016 at 11:28 AM, Guillaume Delhumeau <guillaume.delhumeau(a)xwiki.com> wrote: 2016-10-13 11:07 GMT+02:00 Ecaterina Moraru (Valica) <valicac(a)gmail.com>: > Some notes about the comments: > - @GD: In CkEditor when drag&dropping it doesn't open a file explorer > (that's for the simple upload), instead you just drag the image from > Desktop and it inserts it. > I think I was not clear. I know CKEditor does not a file explorer. But you have to open that kind of application by yourself (in mac it's called "Finder", on my laptop it's called "Nautilus") if the file you plan to drag is not on your desktop (which is the case 99% of the time). That is exactly what I dislike. > - @Vincent: the inline editing approach (with keeping the attachments tab > in the same location) doesn't work for cases when we hide the docextra: we > will have the same problem, and we might plan to remove that area for other > skins. > - @Thomas: yes this approach to have attachments tab in edit is problematic > because of the save and other js events, plus to me is still oldish. > > So I don't want us to include the attachment tab in edit mode (although it > sounded as a nice option). Instead I would like at least to have an > improved drag&drop for CkEditor (improvement) and in the 'future' to > support drag&drop in wiki mode (new feature). > > Thanks, > Caty > Thanks, > > > On Thu, Oct 13, 2016 at 10:47 AM, Thomas Mortagne < > thomas.mortagne(a)xwiki.com > > wrote: > > > Something is not clear to me. What is exactly going to happen in edit > > mode when you select an attachment ? > > > > If the plan is to let the attachment tab behave exactly as it does in > > view mode (which is to actually upload the attachment and save the > > document) I'm really not a big fan of this. If we support attachments > > in edit view it should not send anything until we click save. > > > > > > On Thu, Oct 13, 2016 at 9:41 AM, Vincent Massol <vincent(a)massol.net> > > wrote: > > > > > >> On 12 Oct 2016, at 18:47, Guillaume Delhumeau < > > guillaume.delhumeau(a)xwiki.com> wrote: > > >> > > >> Just some remarks before I go: > > >> * As a developer, I always use the Wiki editor, and even for me it's a > > pain > > >> to go to view mode to upload a file (for example, an image in the > > release > > >> notes). > > >> * I never use drag&drop in whatever application I have. I have never > > liked > > >> it because it requires to open a file explorer specially for that and > > it's > > >> always a pain because I use applications in full size mode. I'm sure > I'm > > >> not the only one so I'm not fond of having it as the only way to > upload > > >> attachments. > > > > > > For the sake of the discussion, also note that there’s another option. > > Don’t leave the view page when editing (ie. inline editing) and just > > replace the view area by an edit area. And find how to display the page > > syntax and include/display references in the UI. > > > > > > The nice part is that it 1) it saves a reload of the UI (good for perf) > > and 2) it feels more snappy and no context switching for the user (better > > usability). > > > > > > If you remember this was a proposal done a very long time ago by > > Jean-Vincent Drean (tried to find the thread again but didn’t succeed). > > > > > > Thanks > > > -Vincent > > > > > >> Thanks, > > >> > > >> 2016-10-12 18:00 GMT+02:00 Ecaterina Moraru (Valica) < > valicac(a)gmail.com > > >: > > >> > > >>> There are some problems with docextra, because it contains comments, > > which > > >>> are mostly needed in view mode, not in edit. So in edit mode, we > would > > need > > >>> just some tabs from docextra. But I'm not sure that adding docextra > now > > >>> will fix the underlying problem of the issue. > > >>> > > >>> The issue was trying to fix the attachments uploading limitation of > the > > >>> editor. The problem is that the editors (including CKEditor) are > > >>> advertising that they add images and not other file types. If users > > want to > > >>> add a PDF they might be confused. > > >>> > > >>> Ideally the users would just need to drag&drop a file and we would > > insert a > > >>> displayer depending on the dragged type (viewer for PDFs, gallery for > > >>> multiple images, image macro for single image, etc.) > > >>> Also even if in CKEditor the drag&drop option for images is > permitted, > > >>> nobody knows about it. And currently CKEditor has the limitation to > > allow > > >>> dragging just images and not other types (dragging an image inserts > it, > > >>> dragging a text file does nothing). > > >>> > > >>> Other thing to consider is that for Groupware flavor, where we > promote > > >>> applications, we hide the docextra, since this is not so relevant for > > >>> application entries. Hidding docextra creates > > >>> http://jira.xwiki.org/browse/XWIKI-13799 and > > >>> http://jira.xwiki.org/browse/XWIKI-12993 . > > >>> > > >>> So, a conclusion: I'm not sure adding #docextra in the edit mode is > the > > >>> best solution, especially since we try to make the interface more > > simple > > >>> and we usually hide docextra also from view. > > >>> An idea would be to better mark in the Edit mode that Drag&Drop is > > >>> permitted (at least for the CKEditor - the wiki mode will still have > > the > > >>> same issue). Have a drag&drop behavior also for other file types, not > > just > > >>> images (for text files we could create a link for the attached file, > > etc.). > > >>> Plus have a link to manually go to the attachments viewer as a backup > > (by > > >>> fixing the 2 additional issues mentioned). The problem will still > > remain on > > >>> wiki mode, but let's say those users are more advanced and know how > to > > use > > >>> viewers (although consistency between the edit modes would be ideal). > > >>> > > >>> Thanks, > > >>> Caty > > >>> > > >>> > > >>> On Wed, Oct 12, 2016 at 5:26 PM, Guillaume Delhumeau < > > >>> guillaume.delhumeau(a)xwiki.com> wrote: > > >>> > > >>>> Hi. > > >>>> > > >>>> Currently a user have 2 ways to attach a file to a wiki page: > > >>>> - in the attachment tab in VIEW mode only ; > > >>>> - if it's an image, using a WYSIWYG editor. > > >>>> > > >>>> However, if it's not an image, you cannot add it while you're > writing > > the > > >>>> content. It's a bit as if you were not able to attach a file while > you > > >>> were > > >>>> writing an email... not user friendly! > > >>>> > > >>>> So we have this issue: http://jira.xwiki.org/browse/XWIKI-5400 > > >>>> > > >>>> To fix it, I see 2 options: > > >>>> - add the handling of attachments in edit mode. > > >>>> - add *all* docextra tabs like we have in view mode (it's not > because > > you > > >>>> are editing a page that you don't need to see the history of the > page, > > >>> nor > > >>>> the comments). > > >>>> > > >>>> But this might be not relevant for the class and the object editor. > > >>>> > > >>>> My proposal: > > >>>> * Display docextra tabs by default. > > >>>> * In class and object editors, set $docExtras = []. > > >>>> * Set $docExtras = [] in all sheets where we consider it's not > > relevant > > >>> to > > >>>> have the tabs. > > >>>> > > >>>> WDYT? > > >>>> > > >>>> Thanks, > > > > > > _______________________________________________ > > > devs mailing list > > > devs(a)xwiki.org > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > > -- > > Thomas Mortagne > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

8 years, 11 months

1
0
0 0

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

by Alexandru Cotiuga

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

8 years, 11 months

1
1
0 0

[xwiki-devs] [myxwiki] XWiki Enterprise 8.3 Upgrade

by Thomas Mortagne

Hi everyone, myxwiki.org has been upgraded to XE 8.3. If you own a wiki hosted there you should have a look at the release notes for this version at: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ You should automatically get an upgrade wizard for your wiki when you login as admin. For more details see the upgrade guide available at : http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Upgrade#HUpgradingwikid… To be notified of the myxwiki.org server upgrade you can follow myxwiki on twitter: http://twitter.com/myxwiki Thanks, -XWiki Community

8 years, 11 months

1
1
0 0

[xwiki-devs] [Vote] Introduce a 'displayPageHeader' parameter in the query string in Flamingo

by Guillaume Delhumeau

Hello. In Flamingo, we have a variable called $displayPageHeader, defined in layoutvars.vm. When it is set, the logo is not displayed in the top menu, but on a header under it. It is used by some clients, where they could also add some extra content. Example: http://tof.canardpc.com/view/83040d2d-79c4-4f1b-ab1b-af8ee5f3be62.jpg I'd like to expose this variable into the Flamingo Theme, see: http://jira.xwiki.org/secure/attachment/33074/33074_preview.png However, in order to enable the live preview in the theme editor, I need to be able to change the value of the $displayPageHeader variable on the fly, or at least by setting a parameter in the query string. This variable will be: displayPageHeader Possible values: "true", "false" Default value: Fallback to the Flamingo Theme, "false" if empty. I don't have other use-case to cover with this variable. Here is my +1. Thanks, -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

8 years, 11 months

3
3
0 0

[xwiki-devs] [ANN] XWiki 8.3 released

by Ecaterina Moraru (Valica)

The XWiki development team is proud to announce the availability of XWiki Enterprise 8.3. This release introduces Recommended Extensions both on extensions.xwiki.org and inside the Extension Manager. Other changes are page suggestions for non-existing page, exporting child pages in XAR and HTML formats and many more improvements. For developers, we added visibility and creation restrictions on template providers and also Velocity templates can be provided inside a JAR extension. 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.3/ Thanks for your support -The XWiki dev team

8 years, 11 months

1
0
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