xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

[xwiki-devs] Release of Curriki 1.17 (CDN)

by Paul Libbrecht

The Curriki developers' team is happy to announce that Curriki 1.17 is now released and deployed to www.curriki.org . This release fixes a number of bugs and adds the support for serving the static resources (such as JS, pictures, or CSS files that are part of the webapp) from a cloud distribution network. Curriki has chosen the Amazon Web Service S3 upload and Cloudfront CDN solution. This release required a number of adjustments in the internals (a URL factory) and quite some skin adjustments, often because absolute URLs that refer to CDN resources often get caught by the wiki syntax processor. We are thrilled to bring this release to the users' community of curriki.org for a better responsiveness and to the developers of the XCLAMS-based platforms. XCLAMS, the XWiki Collaborative Learning Assets Management System, is a web-service based on the XWiki platform that enables learning resources to be exchanged, developed, and shared following the Open Educational Resources model. The source of the Curriki.org XCLAMS branch is at: https://github.com/xwiki-contrib/currikiorg/commit/72b6e963ecd9e9794bda5f8d… The commit of the release is: https://github.com/xwiki-contrib/currikiorg/ For more details about bug fixes, see the jira version: http://jira.xwiki.org/secure/ReleaseNote.jspa?projectId=10160&version=15062 More information about XCLAMS in general see http://xclams.xwiki.org . The XWiki developers' team Paul, Bob, Todd, and Felix

10 years

[xwiki-devs] XWiki 6.3 Flamingo disappeared after import large XAR

by Andrea Ferroni

I have installed XWiki enterprise 6.3 Flamingo skin is visibile. After import my previous XWiki 5.1 content, using extension Large+XAR+Import, Flamingo skin disappeared. XWiki is exactly 5.1 style and I can't select Flamingo from Admin panel. Why ? Ho to restore Flamingo ? Andrea

10 years

[xwiki-devs] [ANN] XWiki 6.4 Milestone 2 released

by Eduard Moraru

The XWiki development team is proud to announce the availability of XWiki 6.4 Milestone 2. This version brings mainly UI improvements in the Menu application, Mail application and Flamingo skin, while offering developers the ability to write LESS in Skin Extensions, a cool icon picker and new ConfigurableClass and Mail Sender API features. 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/ReleaseNotesXWiki64M2 Thanks -The XWiki dev team

10 years

[xwiki-devs] [Proposal] Delay the 6.4 release by introducing a milestone

by vincent＠massol.net

Hi devs, When we look at our roadmap at http://www.xwiki.org/xwiki/bin/view/Roadmaps/ we can see that there are some issues that we wanted fixed in 6.4 and that are not done yet and they wouldn’t fit in a RC: - batch mail feature (ability to send large volumes of mails) - several outstanding issues for flamingo - "Move the "Pretty Name" and Description sections from the Main Wiki to their respective subwiki Administration page” - "Extension Manager add extension search should suggest only compatible versions - Addition of Ratings feature in Repository app In summary, we’re very very late and not in a good shape, and holidays are coming soon… So I’m proposing the following: - release 6.4M2 this week (Edy to do the release) - add a 6.4M3 release spanning 2 weeks, to be released on 5th - move the RC to 12th of Jan - move the final to 19th of Jan. Overall this means a delay of 3 weeks compared to our initial plan of: - 6.4M1: --1st of Dec-- 3rd of Dec - 6.4M2: 15 Dec - 6.4RC1: 22 Dec - 6.4Final: 29 Dec This is not nice obviously since it impacts our ability to start XWiki 7.0 at beginning of January but I don’t see any other option. Note that the reason why it’s important to have these features in 6.x is because a lot of users are still on 5.x or older and are going to move to 6.x during the coming year and it’ll be another year before they move to some XWiki 7.x release so we need to close the 6.x cycle nicely. Also note that I’ve considered adding a 6.5 release but I think it’s better to extend 6.4 because: - our cycles go from N.0 to N.4 - adding a full release would delay the starting date of 7.0 dev even more Also note that we’ll probably have 6.4.1, 6.4.2, … stabilization releases too. WDYT? Thanks -Vincent

10 years

[xwiki-devs] [Review] Extension Repository App & Ratings

by Victor Rachieru

Hei devs, I've been working on implementing ratings for the Extension Repository App and making that information available via Extension Manager. Also, this required the integration of the ratings module from xwiki-contrib into xwiki-platform. On my personal repository you'll find two branches containing the 1st version of the working code. The tasks covered ------------- XWIKI-11507 <http://jira.xwiki.org/browse/XWIKI-11507> : Integrate the ratings system from xwiki-contrib XWIKI-7780 <http://jira.xwiki.org/browse/XWIKI-7780> : Rating and advice system for extensions XWIKI-11508 <http://jira.xwiki.org/browse/XWIKI-11508> : Include ratings information in the Extension REST API XWIKI-11509 <http://jira.xwiki.org/browse/XWIKI-11509> : Display ratings information in the Extension Manager UI Modules modified ------------- xwiki-commons-extension xwiki-commons-repository xwiki-platform-extension xwiki-platform-flamingo xwiki-platform-ratings xwiki-platform-repository xwiki-platform-web Branches ------------- https://github.com/vrachieru/xwiki-platform/tree/xwiki-platform-ratings https://github.com/vrachieru/xwiki-commons/tree/xwiki-commons-ratings Feedback is welcome. Thank you, Victor

10 years

[xwiki-devs] [Proposal] Introduce LESS in Skin Extensions (SSX)

by Guillaume "Louis-Marie" Delhumeau

Hi. Since the beginning of the week, I am working to have the LESS pre-processor inside our Skin Extension objects (see: http://jira.xwiki.org/browse/XWIKI-10708). It would enable us to use the Flamingo Theme variables and all bootstrap's mixins inside SSX (see http://jira.xwiki.org/browse/XWIKI-11374). Example of use-case: http://jira.xwiki.org/browse/XWIKI-11408 (Menu Application: Improve default look to make it better-looking with the Flamingo skin). I have created a design page there for the details: http://design.xwiki.org/xwiki/bin/view/Proposal/LESSModuleImprovements I propose to add a new property inside the XWiki.StyleSheetExtension class which will be called "CSS preprocessor". The actual possible values would be "LESS" or "none", but in the future we can imagine having "SASS" or anything else. Then I propose to change the actual SSX action to perform a LESS compilation if needed. Note that the user would still be able to use or not Velocity in addition of the CSS preprocessor. The other possibilities (that are not part of this proposal) are to create a new XWiki.LESSStyleSheetExtension and a new LSSX action which would behave exactly as the previous objet and action, or to have the ability to choose the processor directly inside the SSX content, with a special line like "# preprocessor = less" or something like that. I have made a prototype that is working ( https://github.com/xwiki/xwiki-platform/tree/feature-less-ssx) and I am taking care of the compatibility with older skins that do not use LESS (Colibri for instance). Here is my +1. I would like to commit it today to have it in 6.4M2. I have done a lot of refactoring on the LESS module (with a better cache system among other things) that I don't want to commit in a release candidate. Thanks, -- Guillaume Delhumeau (gdelhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

10 years

[xwiki-devs] [Discussion] Replacing the use of PR checks. Is it really an option? How exactly?

by Eduard Moraru

Hi devs, We are all waiting for signed scripts to come to the rescue, but until then, we have pretty much agreed that it is a good idea to remove PR checks, which don`t work in subwikis (see activity stream [1], wikis module [2], etc.) However, once we do that, we open up a big security problem, such as "trap pages". These are basically documents containing malicious usage of our services, that are written by regular users and that are waiting (or tricking) for admins (or users with privileges) to access them by mistake. Since those script services will be looking only at the current user's rights, they will be executing the malicious code and the security will be compromised. What options do we have here? On some modules (like the wiki module) it might be useful to check the context security document (sdoc) and see if its author is an admin (of the wiki descriptor that is being saved) or a global admin, thus replacing a PR check on the current document with an "admin check on the current document". Using sdoc instead of just doc avoids attempts of using proxy documents (e.g. default ones like /bin/view/someDocument?sheet=SomeBadDocument or custom ones created by the usage of the display or include macros), but unfortunately that is not set by default by XWiki's actions and is only available in a handful of locations, meaning we can not rely on sdoc. A mechanism similar to CSRF protection API but for script services to confirm that the user really intended to execute them might be another idea, but I`m not sure how that might be implemented without allowing easy bypass by directly providing the challenge result. CAPTCHA for sensitive script services? :) That might be too extreme and completely ruin the UX. Any ideas? Thanks, Eduard ---------- [1] http://jira.xwiki.org/browse/XWIKI-10446 [2] http://jira.xwiki.org/browse/XWIKI-11416

10 years, 1 month

[xwiki-devs] [Idea] Sandbox flavor

by vincent＠massol.net

Hi devs, Here’s an idea we discussed with Charles yesterday when he was surprised that clicking on “Sandbox” in the QuickLinks Panel wasn’t leading to a new wiki but to a page. The idea is: - create a Sandbox flavor - add training content in several spaces, on the home page of the wiki, that the user is encouraged to modify/edit - more generally make this whole wiki a training wiki for learning how to use xwiki - When an admin sets up an XWiki instance, if he wants a zone for his users to learn xwiki, he’d create a subwiki and choose the Sandbox flavor WDYT? Thanks -Vincent

10 years, 1 month

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

by Eduard Moraru

Hi devs, As you probably already know, today is BFD#74: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 55 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-R… Still half way there... With just a bit more participation, we can make it. Here's the BFD#74 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=12990 Thanks and enjoy your bug fixing day! -Eduard

10 years, 1 month

Re: [xwiki-devs] [xwiki-users] [VOTE] Enable default actions for the Flamingo top menu entries

by Marius Dumitru Florea

I committed my changes so that those that haven't voted yet can see it in action. Will revert if someone is against it. Thanks, Marius On Mon, Dec 8, 2014 at 11:07 PM, Guillaume Lerouge <guillaume(a)xwiki.com> wrote: > +1 > > Thanks a lot for all your effort on this Marius! > > Guillaume > > On Mon, Dec 8, 2014 at 1:18 PM, Guillaume "Louis-Marie" Delhumeau < > gdelhumeau(a)xwiki.com> wrote: > >> +1, looks good. >> >> 2014-12-08 12:59 GMT+01:00 Marius Dumitru Florea < >> mariusdumitru.florea(a)xwiki.com>: >> >> > On Sat, Dec 6, 2014 at 11:02 PM, Denis Gervalle <dgl(a)softec.lu> wrote: >> > > +1, ideally with a hover feedback very similar to the one of a dropdown >> > > button. >> > >> > The color theme is responsible for the hover effect. A flat color >> > theme will probably use a single color highlight, controlled by the >> > @navbar-default-link-hover-bg LESS variable. A 3D color theme may use >> > some gradients to achieve the 3D effect on hover. A minimalistic color >> > theme (like Simplex) will just change the text color on hover, leaving >> > the background transparent. >> > >> > This proposal/vote is about agreeing on: >> > * displaying a small vertical bar between the menu label and toggle >> > (using a color derived from the menu background) to indicate the >> > separation between the two (especially for tablet devices where >> > there's no hover) >> > * hovering/activating the menu label and the toggle separately, as it >> > happens with a drop down button (e.g. the Add button). >> > >> > Thanks, >> > Marius >> > >> > > >> > > On Fri, Dec 5, 2014 at 6:59 PM, Pascal BASTIEN < >> pbasnews-xwiki(a)yahoo.fr> >> > > wrote: >> > > >> > >> May I? (you send mail at user list)... then +1 >> > >> On 6.3 I still use 6.2 menu (I modified the template on my xwiki) >> > >> >> > >> I'm agree with you the 2 side of button must be better separate (with >> > >> color on hoover or a black vertical bar?). >> > >> >> > >> IMO we must respect the same logic of actions button (an one-click >> > default >> > >> action and drop down sub menu level at the right-side-click ) >> > >> With CSS it should be possible to:- use 2 side button on big screen- >> use >> > >> GoTo menu on small screen >> > >> (with @media min-width) >> > >> >> > >> Thxs >> > >> Pascal BASTIEN >> > >> De : Marius Dumitru Florea <mariusdumitru.florea(a)xwiki.com> >> > >> À : XWiki Developers <devs(a)xwiki.org>; XWiki Users <users(a)xwiki.org> >> > >> Envoyé le : Vendredi 5 décembre 2014 17h20 >> > >> Objet : [xwiki-users] [VOTE] Enable default actions for the Flamingo >> > top >> > >> menu entries >> > >> >> > >> Hi everyone, >> > >> >> > >> = Short Story = >> > >> >> > >> I propose to change the behaviour of the top level menu from Flamingo >> > >> for tablet and desktop screens (so NOT for phones) to match the >> > >> behaviour we had in 6.2 BUT improving the separation between the >> > >> navigation links and the drop down toggle. The idea is that the top >> > >> level menu entries should behave like a drop down button (e.g. the Add >> > >> button) but without looking like one. You can see some screen shots at >> > >> http://jira.xwiki.org/browse/XWIKI-11517. >> > >> >> > >> = Long Story = >> > >> >> > >> I've heard complains that the current behaviour of the top level menu >> > >> from Flamingo skin is not perfect. The issue is that you need to click >> > >> twice to navigate. Ok, with a mouse you can use the middle click >> > >> (wheel) to open the link in a new tab but still it's annoying for >> > >> simple uses and for those that use the touch pad or a tablet. >> > >> >> > >> An alternative I have investigated in >> > >> http://jira.xwiki.org/browse/XWIKI-11479 is to open the menu on hover >> > >> (on devices that support this of course). The result is quite nice and >> > >> effective but there is a problem: if you have a second horizontal menu >> > >> displayed under the top level menu then you'll have a hard time >> > >> hovering the second menu. So I decided to close XWIKI-11479 as Won't >> > >> Fix. For those that like the open-on-hover behaviour and which don't >> > >> plan to use a second menu I've published this extension >> > >> >> > >> >> > >> http://extensions.xwiki.org/xwiki/bin/view/Extension/Hover+and+Default+Acti… >> > >> . >> > >> >> > >> The other alternative to fix the problem is to go back to the >> > >> behaviour from 6.2. Precisely, each menu has two sides: >> > >> * on the left is the label which is a link used for navigation >> > >> * on the right there is a toggle (arrow) used to open the menu. >> > >> >> > >> The problem with this, and the reason we change it in 6.3, was that >> > >> the label and the toggle were not separated very well so the user >> > >> could easily think they were doing the same action (opening the menu). >> > >> At the same time this separation felt unnatural on extra small screens >> > >> (phones) because you couldn't tap easily on the toggle (arrow). >> > >> >> > >> The solution I propose is to: >> > >> * Keep the current behaviour for extra small screens (phones). That >> > >> means the use has to tap twice to navigate: one tap to open the menu >> > >> and another one on the "Go to this XYZ". >> > >> * On desktop and tablet enable the default action (navigation link) as >> > >> in 6.2 but improve the separation so that the menu behaves as much as >> > >> possible as a drop down button (e.g. the Add button) without looking >> > >> like one. This means: >> > >> ** You should understand there are two sides without hovering >> > >> ** Separate hover and active state (e.g. the link is not hovered when >> > >> the toggle is hovered) >> > >> >> > >> I've investigated *many* ways to achieve this and the result can be >> > >> seen on http://jira.xwiki.org/browse/XWIKI-11517. This is close to >> > >> >> > >> >> > >> http://extensions.xwiki.org/xwiki/bin/view/Extension/Enable+Default+Action+… >> > >> but not the same. >> > >> >> > >> NOTE: The way the menu behaves and looks on hover and click (text and >> > >> background color) is strictly determined by the color theme. Some >> > >> themes highlight the hovered menu items by changing their background >> > >> color, others the text color and some do both. My changes are >> > >> independent on this. We can of course improve the default color theme >> > >> to better highlight the menu items. This is a different topic though. >> > >> >> > >> I'd like to commit this changes in 6.4. Here's my +1. >> > >> >> > >> Thanks, >> > >> Marius >> > >> _______________________________________________ >> > >> 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 >> > >> >> > > >> > > >> > > >> > > -- >> > > Denis Gervalle >> > > SOFTEC sa - CEO >> > > _______________________________________________ >> > > 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 (gdelhumeau(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

10 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs