Re: [xwiki-users] [Proposal] Comparing XWiki to MediaWiki and Confluence on xwiki.org

[Ecaterina Moraru (Valica)]

Created Forum entry
https://forum.xwiki.org/t/comparing-xwiki-to-mediawiki-and-confluence-on-xwiki-org/634

Thanks,
Caty

On Fri, Sep 22, 2017 at 7:11 PM, Ecaterina Moraru (Valica) <
vali...@gmail.com> wrote:

> Hi,
>
> I finally got the time to make another iteration for these comparison
> pages.
>
> If anyone want to make modifications on the texts, they are available at:
> - http://dev.xwiki.org/xwiki/bin/view/Drafts/Compare/
> - http://dev.xwiki.org/xwiki/bin/view/Drafts/Compare/XWiki-vs-Confluence/
> - http://dev.xwiki.org/xwiki/bin/view/Drafts/Compare/XWiki-vs-MediaWiki/
>
> They should look like:
> - Compare: http://design.xwiki.org/xwiki/bin/download/Proposal/
> XWikiOrg2017/preview_Compare.png
> - XWiki vs. Confluence: http://design.xwiki.org/xwiki/
> bin/download/Proposal/XWikiOrg2017/preview_Confluence.png
> - XWiki vs. MediaWiki: http://design.xwiki.org/xwiki/
> bin/download/Proposal/XWikiOrg2017/preview_MediaWiki.png
>
> I'm curious to know what you think about this version in terms of layout,
> validate the content, maybe you have other points that we can compare the
> solutions on, maybe I wrote something wrong for the solutions.
>
> Let me know,
> Caty
>
> On Tue, May 17, 2016 at 11:17 PM, Bryn Jeffries <
> bryn.jeffr...@sydney.edu.au> wrote:
>
>> Denis Gervalle said:
>> > > Yes, we only maintain documentation for the latest version of XWiki on
>> > > xwiki.org (not enough manpower to have decent doc for several
>> versions
>> > > ATM).
>> > >
>> >
>> > However, for version 6.2.5 and later, you have a way to mitigate this
>> > limitation. You can install the Scripting Documentation Application on
>> your
>> > own wiki (see
>> > http://extensions.xwiki.org/xwiki/bin/view/Extension/Scripti
>> ng+Documenta
>> > tion+Application).
>>
>> Thanks, I did not know about this tool, which sounds excellent.
>>
>> > Unless you are using XWiki prior to 4.2 , using Wiki Component is
>> definitely
>> > the recommended way to writes Groovy components. Registering
>> > components "by hand" from a groovy script has many drawbacks not only
>> > the restart one, and you should avoid doing that. The best is of course
>> to
>> > write the components in Java, and install them as an extension.
>>
>> I've found the ability to write small Groovy scripts as components has
>> been very handy and simpler than writing full extensions in Java. For
>> utilities that I don't wish to make into public extensions the burden of a
>> small Groovy script into a proper extension seems prohibitive (although
>> that may just be that I haven't written one yet, and I'm just a walker at
>> the bottom of a hill complaining about how high it looks...). Last time I
>> asked there is was no simple way to install private extensions. Also, I
>> didn't have much luck writing a proper component in Groovy, which I
>> sometimes prefer to Java.
>> ___
>> users mailing list
>> users@xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/users
>>
>
>

Re: [xwiki-users] [Proposal] Comparing XWiki to MediaWiki and Confluence on xwiki.org

[Ecaterina Moraru (Valica)]

Hi,

I finally got the time to make another iteration for these comparison
pages.

If anyone want to make modifications on the texts, they are available at:
- http://dev.xwiki.org/xwiki/bin/view/Drafts/Compare/
- http://dev.xwiki.org/xwiki/bin/view/Drafts/Compare/XWiki-vs-Confluence/
- http://dev.xwiki.org/xwiki/bin/view/Drafts/Compare/XWiki-vs-MediaWiki/

They should look like:
- Compare:
http://design.xwiki.org/xwiki/bin/download/Proposal/XWikiOrg2017/preview_Compare.png
- XWiki vs. Confluence:
http://design.xwiki.org/xwiki/bin/download/Proposal/XWikiOrg2017/preview_Confluence.png
- XWiki vs. MediaWiki:
http://design.xwiki.org/xwiki/bin/download/Proposal/XWikiOrg2017/preview_MediaWiki.png

I'm curious to know what you think about this version in terms of layout,
validate the content, maybe you have other points that we can compare the
solutions on, maybe I wrote something wrong for the solutions.

Let me know,
Caty

On Tue, May 17, 2016 at 11:17 PM, Bryn Jeffries  wrote:

> Denis Gervalle said:
> > > Yes, we only maintain documentation for the latest version of XWiki on
> > > xwiki.org (not enough manpower to have decent doc for several versions
> > > ATM).
> > >
> >
> > However, for version 6.2.5 and later, you have a way to mitigate this
> > limitation. You can install the Scripting Documentation Application on
> your
> > own wiki (see
> > http://extensions.xwiki.org/xwiki/bin/view/Extension/Scripting+Documenta
> > tion+Application).
>
> Thanks, I did not know about this tool, which sounds excellent.
>
> > Unless you are using XWiki prior to 4.2 , using Wiki Component is
> definitely
> > the recommended way to writes Groovy components. Registering
> > components "by hand" from a groovy script has many drawbacks not only
> > the restart one, and you should avoid doing that. The best is of course
> to
> > write the components in Java, and install them as an extension.
>
> I've found the ability to write small Groovy scripts as components has
> been very handy and simpler than writing full extensions in Java. For
> utilities that I don't wish to make into public extensions the burden of a
> small Groovy script into a proper extension seems prohibitive (although
> that may just be that I haven't written one yet, and I'm just a walker at
> the bottom of a hill complaining about how high it looks...). Last time I
> asked there is was no simple way to install private extensions. Also, I
> didn't have much luck writing a proper component in Groovy, which I
> sometimes prefer to Java.
> ___
> users mailing list
> users@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
>

Re: [xwiki-users] How to debug page rights

[Ecaterina Moraru (Valica)]

[[Note: The XWiki project is switching away from this mailing list and moving 
to a forum: https://discourse.xwiki.org. This list will be made readonly in a 
few days. Please post on the forum from now on. Thanks.]]

-
Hi,
http://extensions.xwiki.org/xwiki/bin/view/Extension/Check%20Security%20Cache
can help in some ways.

I've proposed some improvements to the Rights system that (if people like
them / want them) they could be implemented in the future. Would love to
hear your thoughts on them, see
https://forum.xwiki.org/t/ux-rights-improvements/107/7

Thanks,
Caty

On Mon, Jun 5, 2017 at 6:02 PM, Vincent Massol  wrote:

> [[Note: The XWiki project is switching away from this mailing list and
> moving to a forum: https://discourse.xwiki.org. This list will be made
> readonly in a few days. Please post on the forum from now on. Thanks.]]
>
> -
> HI Jan,
>
> > On 5 Jun 2017, at 14:23, jan.steh...@gmail.com wrote:
> >
> > [[Note: The XWiki project is switching away from this mailing list and
> moving to a forum: https://discourse.xwiki.org. This list will be made
> readonly in a few days. Please post on the forum from now on. Thanks.]]
> >
> > -
> > Hi everybody,
> > I'm migrating content from 5.4.5 wiki to the 9.4. The old content was one
> > space and about 300 pages. The content has been imported ok, however it
> is
> > visible only to admin.
> > Is there any debug option which I can turn on, so I can debug why is this
> > page restricted to other users?
>
> Maybe http://extensions.xwiki.org/xwiki/bin/view/Extension/
> Security%20Inspector%20Application/ ?
>
> Thanks
> -Vincent
>
> PS: Please try to use the forum from now on, we’re removing this list.
> Thanks
> >
> > Thanks for hints.
> > --jans
>
>

Re: [xwiki-users] Initial permissions for users - new users can't see anything

[Ecaterina Moraru (Valica)]

[[Note: The XWiki project is switching away from this mailing list and moving 
to a forum: https://discourse.xwiki.org. This list will be made readonly in a 
few days. Please post on the forum from now on. Thanks.]]

-
If you explicitly allow a right, it gets automatically denied for the rest
of the users.
Maybe this is your problem. You explicitly allowed view to some user/group
at that level, implicitly denying it for your user.

Thanks,
Caty

On Fri, Jun 2, 2017 at 12:46 AM, Douglas Landau 
wrote:

> [[Note: The XWiki project is switching away from this mailing list and
> moving to a forum: https://discourse.xwiki.org. This list will be made
> readonly in a few days. Please post on the forum from now on. Thanks.]]
>
> -
> Greets,
>
> In my XWiki installation, when regular users log in for the 1st time, they
> are greeted with a simple message:
>
>Error
> You are not allowed to view this page or perform this action.
>
> To be sure, the user has no rights at all.  However, the new user IS
> placed in the group "XWikiAllGroup", and that group DOES have all rights
> excelt Admin, Delete, and Program.  In other words, it has View, Comment,
> Edit, and Script, and Register.
>
> 1.  Is this correct?   Should the new user not have all rights except for
> Admin, Delete, and Program?
>
> 2.  The new user IS placed in the XWikiAllGroup.  So, why can the new user
> not see the Main page, and other pages?
>
> 3.  What have I done to get in this situation and what is the proper
> remediation?
>
> Thanks!!!
> Doug
>
>
> The information contained in this transmission may contain West Marine
> proprietary, confidential and/or privileged
> information.  It is intended only for the use of the person(s) named
> above. If you are not the intended recipient, you are
> hereby notified that any review, dissemination, distribution or
> duplication of this communication is strictly prohibited.
> If you are not the intended recipient, please contact the sender by reply
> email and destroy all copies of the original
> message. To reply to our email administrator directly, please send an
> email to netad...@westmarine.com.
>

Re: [xwiki-users] [Proposal][UX] Feedback for Visible Save buttons

[Ecaterina Moraru (Valica)]

On Tue, May 9, 2017 at 11:20 PM, Olivier Seres <ose...@gmail.com> wrote:

> Caty,
> Thanks for this work!
> We should also consider that there could be other options to be added in
> the future, like "Allow realtime" radio button, or introduced by some
> forecoming extensions
>

Ideal we could also remove options :) and make it more simpler :)
On mobile the options will go on 2 rows, so we currently have this problems.

Thanks,
Caty


> In order to avoid messing up the layout (in beeing be obliged to placing
> the option in some weird places - like underneath because there is no other
> options),  it might be wise to think to an elegant design solution within
> this bottom bar to take their growth into account.
> Currently thinking to an unfolding menu, but I'm sure there are many other
> ways.
>
>
>
> Olivier
>
>
> On Tue, May 9, 2017 at 6:13 PM, Ecaterina Moraru (Valica) <
> vali...@gmail.com> wrote:
>
>> Hi,
>>
>> The initial proposal was about the fixed bottom position. For that we will
>> have https://jira.xwiki.org/browse/XWIKI-14162 issue
>> In order to have a bottom bar, we compacted the save options, for that we
>> will have the https://jira.xwiki.org/browse/XWIKI-14267
>>
>> Thanks to everyone who responded in the survey. The results are available
>> at
>> https://docs.google.com/forms/d/1DM74hlXQQ22WVdqhYbGWyITWXTH
>> 5qgmKSMIrS3eHDKE/viewanalytics
>>
>> The proposal we will implement is
>> http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisi
>> bleSave/proposal9xCK.png
>>
>> Initially I wanted to remove some buttons and reduce their number, but the
>> feedback was mixed, so this has been postponed, until we gather more usage
>> data or feedback.
>>
>> Some conclusions:
>> - "Save & View" received 12 votes as used most often. Since it's also an
>> action that changes modes (takes the user to view) and is a final action,
>> it will be marked with primary state (blue).
>> - "Save" was also voted and voters were against remove it. Since it
>> received 12 votes and is related to save, it will be the next action. We
>> simplified the name from "Save" to "Save".
>> - "Preview" received just 4 votes, but we consider this action to be
>> directed towards newcomer users that need to be comfortable with their
>> changes and be able to preview them.
>> - "Cancel" was kept near the other actions in order to be consistent with
>> the other layout we have across XWiki. It will be displayed outside of the
>> button group.
>>
>> Thanks,
>> Caty
>>
>> On Thu, Apr 27, 2017 at 4:29 PM, Ecaterina Moraru (Valica) <
>> vali...@gmail.com> wrote:
>>
>> > Sorry. The link was https://goo.gl/forms/QyG5eOM44rBkd3qk2
>> >
>> > On Thu, Apr 27, 2017 at 4:23 PM, Ecaterina Moraru (Valica) <
>> > vali...@gmail.com> wrote:
>> >
>> >> I've created this form to gather data about the buttons usage, in order
>> >> to make a proposal for the buttons location
>> >> https://docs.google.com/forms/d/e/1FAIpQLSeQwjxlFl321Ap97xKlYRcf
>> -39wlG-
>> >> cJXXqM1nududfjo3KHQ/viewanalytics
>> >>
>> >> Hope everyone is comfortable with Google Forms.
>> >> Thanks,
>> >> Caty
>> >>
>> >>
>> >> On Thu, Apr 27, 2017 at 12:56 PM, Denis GERMAIN <dt.germ...@gmail.com>
>> >> wrote:
>> >>
>> >>> Great proposition ! I like it.
>> >>>
>> >>> I see that the subject has also diverted to the fact that you can
>> "save
>> >>> and
>> >>> continue" and "save and view". Some of our users are lost the first
>> time
>> >>> as
>> >>> they click "save and continue" and don't understand why they are
>> still in
>> >>> edit mode. Clarifying this would indeed be a good idea, even though
>> they
>> >>> usually get the distinction quickly after that.
>> >>>
>> >>> Regards,
>> >>> Denis
>> >>>
>> >>> 2017-04-26 17:01 GMT+02:00 Ecaterina Moraru (Valica) <
>> vali...@gmail.com
>> >>> >:
>> >>>
>> >>> > On Wed, Apr 26, 2017 at 5:41 PM, Craig Wright <crw+xw...@crw.xyz>
>> >>> wrote:
>> >>> >
>> >>> > > Hi Caty,
>> >>> > >
>> >>> > > I

Re: [xwiki-users] [Proposal][UX] Feedback for Visible Save buttons

[Ecaterina Moraru (Valica)]

Hi,

The initial proposal was about the fixed bottom position. For that we will
have https://jira.xwiki.org/browse/XWIKI-14162 issue
In order to have a bottom bar, we compacted the save options, for that we
will have the https://jira.xwiki.org/browse/XWIKI-14267

Thanks to everyone who responded in the survey. The results are available
at
https://docs.google.com/forms/d/1DM74hlXQQ22WVdqhYbGWyITWXTH5qgmKSMIrS3eHDKE/viewanalytics

The proposal we will implement is
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/proposal9xCK.png

Initially I wanted to remove some buttons and reduce their number, but the
feedback was mixed, so this has been postponed, until we gather more usage
data or feedback.

Some conclusions:
- "Save & View" received 12 votes as used most often. Since it's also an
action that changes modes (takes the user to view) and is a final action,
it will be marked with primary state (blue).
- "Save" was also voted and voters were against remove it. Since it
received 12 votes and is related to save, it will be the next action. We
simplified the name from "Save" to "Save".
- "Preview" received just 4 votes, but we consider this action to be
directed towards newcomer users that need to be comfortable with their
changes and be able to preview them.
- "Cancel" was kept near the other actions in order to be consistent with
the other layout we have across XWiki. It will be displayed outside of the
button group.

Thanks,
Caty

On Thu, Apr 27, 2017 at 4:29 PM, Ecaterina Moraru (Valica) <
vali...@gmail.com> wrote:

> Sorry. The link was https://goo.gl/forms/QyG5eOM44rBkd3qk2
>
> On Thu, Apr 27, 2017 at 4:23 PM, Ecaterina Moraru (Valica) <
> vali...@gmail.com> wrote:
>
>> I've created this form to gather data about the buttons usage, in order
>> to make a proposal for the buttons location
>> https://docs.google.com/forms/d/e/1FAIpQLSeQwjxlFl321Ap97xKlYRcf-39wlG-
>> cJXXqM1nududfjo3KHQ/viewanalytics
>>
>> Hope everyone is comfortable with Google Forms.
>> Thanks,
>> Caty
>>
>>
>> On Thu, Apr 27, 2017 at 12:56 PM, Denis GERMAIN <dt.germ...@gmail.com>
>> wrote:
>>
>>> Great proposition ! I like it.
>>>
>>> I see that the subject has also diverted to the fact that you can "save
>>> and
>>> continue" and "save and view". Some of our users are lost the first time
>>> as
>>> they click "save and continue" and don't understand why they are still in
>>> edit mode. Clarifying this would indeed be a good idea, even though they
>>> usually get the distinction quickly after that.
>>>
>>> Regards,
>>> Denis
>>>
>>> 2017-04-26 17:01 GMT+02:00 Ecaterina Moraru (Valica) <vali...@gmail.com
>>> >:
>>>
>>> > On Wed, Apr 26, 2017 at 5:41 PM, Craig Wright <crw+xw...@crw.xyz>
>>> wrote:
>>> >
>>> > > Hi Caty,
>>> > >
>>> > > I am a fan of “B”.
>>> > >
>>> > > I like the idea of putting the changelog and autosave options above
>>> on a
>>> > > preceding row. I would argue that for most users, their eyes only
>>> see the
>>> > > leftmost buttons as the functionally useful area. Thus putting
>>> Cancel on
>>> > > the far right effectively “hides” the button.
>>> > >
>>> >
>>> > Yes, the most visible buttons are the ones on the left side and that's
>>> the
>>> > purpose. We need people to see the Save button :)
>>> > Now, 'summary' functionality is not mandatory when editing and can
>>> also be
>>> > disabled from Administration - Editing.
>>> > Having it on a separate line is not an option since we initial idea of
>>> the
>>> > thread is to provide a fixed bottom bar, when the viewport is small. So
>>> > there are all on a single bar in order to be compact.
>>> >
>>> >
>>> > >
>>> > > For the purposes of mobile, I think it is acceptable to hide the
>>> > changelog
>>> > > and autosave options on small-screen resolutions. (Such as when I am
>>> > > editing from iPhone, I am highly unlikely to leave a changelog
>>> message
>>> > > anyway.)
>>> > >
>>> >
>>> > I haven't iterated much on the mobile version, but the mockup I have is
>>> > http://design.xwiki.org/xwiki/bin/download/Proposal/
>>> > IdeaVisibleSave/mobile.png
>>> > It can be improved, and as y

Re: [xwiki-users] [Proposal][UX] Feedback for Explicit Content Actions

[Ecaterina Moraru (Valica)]

Hi,

So after 2 weeks of available time to express opinions I have some
conclusions: we are going to implement P2.
I've created http://jira.xwiki.org/browse/XWIKI-14265
We are going to make sure to have a span around the labels so that they can
be easily hidden in custom skins.

We had 42 votes around the subject held on 4 channels, for more details see
http://design.xwiki.org/xwiki/bin/view/Proposal/IdeaLabeledActions#HVoting
P2 had 65% of the votes, while P4 35%.

Thanks everyone for the votes
Caty

On Fri, Apr 28, 2017 at 12:36 PM, Mahomed Hussein <maho...@custodiandc.com>
wrote:

> > I’d go as far as saying that the labels could actually be distracting by
> taking more visual
> > space and catching your eyes when you look at the UI as a whole and want
> to focus on the
> > content.
>
> I totally agree with this about the UI and wasted space and distractions.
>
> > Now this could be minor and the advantages for the newcomers could be
> more important than the
> > small downside for returning users.
>
> Well newcomers just need to learn about the functions of the buttons by
> using them once or twice. Whereas the rest of us have to deal with the
> wasted space and distraction forever more :) Also, can't the concern about
> newcomers (and the introduction to the purpose of the buttons) be addressed
> with the tour application that now runs for new users?
>
> Honestly I don't think everyone is going to agree on this. Whatever the
> XWiki team chooses, will probably be fine. People will complain for a bit
> and just move on with life. So I think the team should just take the result
> from the poll and implement that as I think the topic could continue
> indefinitely :-)
>
>
> Kind regards,
>
>
>
>
> Mahomed Hussein
> Custodian Data Centre
> Email: maho...@custodiandc.com
> http://www.CustodianDC.com
>
> -Original Message-
> From: users [mailto:users-boun...@xwiki.org] On Behalf Of Vincent Massol
> Sent: 28 April 2017 09:02
> To: XWiki Users <users@xwiki.org>
> Subject: Re: [xwiki-users] [Proposal][UX] Feedback for Explicit Content
> Actions
>
>
> > On 28 Apr 2017, at 09:57, Ecaterina Moraru (Valica) <vali...@gmail.com>
> wrote:
> >
> > On Fri, Apr 28, 2017 at 10:47 AM, Clément Aubin
> > <clement.au...@xwiki.com>
> > wrote:
> >
> >> Hi,
> >>
> >> On 04/27/2017 11:58 AM, Ecaterina Moraru (Valica) wrote:
> >>> Some summary until now:
> >>> P2: Craig, Olivier
> >>> P4: Mahomed, Steffen, Jesse, Miroslav
> >>
> >> As a «fresh» user, I would prefer P2, mostly because I don’t think
> >> that every newcomer will have the intuition to look at the top-right
> >> corner of the page for its options. Adding labels allows for those
> >> three icons to be more visible.
> >>
> >>
> > From an usability perspective, having labels is unbeatable both for
> > new users and advanced users.
>
> I agree for new users but not for advanced. Users who’ve used those button
> just once know about them and don’t need the labels. I’d go as far as
> saying that the labels could actually be distracting by taking more visual
> space and catching your eyes when you look at the UI as a whole and want to
> focus on the content.
>
> Now this could be minor and the advantages for the newcomers could be more
> important than the small downside for returning users.
>
> Thanks
> -Vincent
>
> > We could also display the icons labels only if the user has the
> > «simple»
> >> user profile and remove them as soon as he becomes more advanced.
> >>
> >
> > Not sure about making this configurable. It's a simple decision, we
> > need to agree on a default. With this approach we make everything in
> > XWiki configurable.
> >
> > The advantage of reaching to newcomers is that in time they will also
> > become advanced users. We want to encourage user transformation. Also
> > I don't think users that start with a more explicit interface will
> > like the change after, since they will become accustomed to it.
> >
> > Thanks,
> > Caty
> >
> >
> >>
> >> Thanks,
> >>
> >> --
> >> Clément Aubin
> >> Web Developer Intern @XWiki SAS
> >> clement.au...@xwiki.com
> >> More about us at http://www.xwiki.com
>
>

Re: [xwiki-users] News panel wizard

[Ecaterina Moraru (Valica)]

On Thu, May 4, 2017 at 12:40 PM, tadewos somano  wrote:

> And the date in xwiki(for blogs, wikis,...) is 2009. How can it be
> corrected?
>

I don't have an answer for that (except 1. xar export the page, modify
manually the date and reimport the page; or 2. change the date using
programming; etc.) but you can read more about the issue at
https://jira.xwiki.org/browse/XWIKI-7058

Thanks,
Caty


>
>
>
> *​Best,​Tadewos *
>
>
>
>
> On Thu, May 4, 2017 at 11:24 AM, Sebastian Luna Valero <
> sebastian.luna.val...@gmail.com> wrote:
>
> > ​Hi All,
> >
> > Many thanks for your answers, good to see different available options!
> >
> > I have finally used xwiki's default blog to make announcements, and then
> I
> > have also added the "Recent Blog Posts" panel to the top left corner
> which
> > is moreless what we wanted to do.
> >
> > Best regards,
> > Sebastian
> >
>

Re: [xwiki-users] Question about activating css source maps and cache cleaning

[Ecaterina Moraru (Valica)]

To be honest I don't know about the properties you are asking about so I'm
not sure if this will solve your problem, but when I want the LESS parser
to activate I usually go in a Flamingo Theme and I re-save it (not sure if
I need to be in the "Advanced" section or if the theme needs to be active).

On Wed, May 3, 2017 at 10:49 AM, Interaktionsweise <
ne...@interaktionsweise.de> wrote:

> Hi,
>
> I've been wondering if there is something else do to to get the source
> maps for css enabled.
> I followed the instructions on the Extension page of the "LESS Module".
> I edited and un-commented the property "lesscss.generateInlineSourceMaps
> = true" within "xwiki.properties".
> Afterwards I restarted the server service.
> I also switched color themes to clean the cache.
> But I cannot see a change in the developer views of Chromium or Firefox.
> Every style still refers to style.css.
>
> At this point I also want to ask about the usage of the manual cleaning
> method for the cache.
> The documentation says that I can use the LESS CSS script service and
> provides a snippet
>
> {{velocity}}
>  $service.lesscss.clearCache()
> {{velocity}}
>

In theory this can be put inside any page, save and view. Make sure you
properly close the {{/velocity}} macro (although might work as well).

Thanks,
Caty


> But where should I put this?
> The section "Script Service" on the LESS Module page only has a link to
> the source code on GitHub. I'm still digging into the XWiki world so maybe
> it is just a matter of time if can figure it out. The whole velocity less
> scripting thing is a huge topic though.
>
> Regards,
> sthag
>
>

Re: [xwiki-users] News panel wizard

[Ecaterina Moraru (Valica)]

There is this extension
http://extensions.xwiki.org/xwiki/bin/view/Extension/Flash%20messages%20application
it's not using panels, but has the purpose you want.
it needs to be tested with latest versions of XWiki,

Thanks,
Caty

On Tue, May 2, 2017 at 12:15 PM, Sebastian Luna Valero <
sebastian.luna.val...@gmail.com> wrote:

> Hello,
>
> Is it possible to make announcements to users on XWiki so they can see it
> easily when they log in?
>
> Not sure whether this functionality is already available somehow on XWiki
> (I'm using version 8.4.5) and I am thinking of presenting the announcements
> within a panel wizard similar to one like "recently modified".
>
> Best regards,
> Sebastian
>

Re: [xwiki-users] [Proposal][UX] Feedback for Explicit Content Actions

[Ecaterina Moraru (Valica)]

On Fri, Apr 28, 2017 at 10:47 AM, Clément Aubin <clement.au...@xwiki.com>
wrote:

> Hi,
>
> On 04/27/2017 11:58 AM, Ecaterina Moraru (Valica) wrote:
> > Some summary until now:
> > P2: Craig, Olivier
> > P4: Mahomed, Steffen, Jesse, Miroslav
>
> As a «fresh» user, I would prefer P2, mostly because I don’t think that
> every newcomer will have the intuition to look at the top-right corner
> of the page for its options. Adding labels allows for those three icons
> to be more visible.
>
>
>From an usability perspective, having labels is unbeatable both for new
users and advanced users.


> We could also display the icons labels only if the user has the «simple»
> user profile and remove them as soon as he becomes more advanced.
>

Not sure about making this configurable. It's a simple decision, we need to
agree on a default. With this approach we make everything in XWiki
configurable.

The advantage of reaching to newcomers is that in time they will also
become advanced users. We want to encourage user transformation. Also I
don't think users that start with a more explicit interface will like the
change after, since they will become accustomed to it.

Thanks,
Caty


>
> Thanks,
>
> --
> Clément Aubin
> Web Developer Intern @XWiki SAS
> clement.au...@xwiki.com
> More about us at http://www.xwiki.com
>

Re: [xwiki-users] [Proposal][UX] Feedback for Visible Save buttons

[Ecaterina Moraru (Valica)]

Sorry. The link was https://goo.gl/forms/QyG5eOM44rBkd3qk2

On Thu, Apr 27, 2017 at 4:23 PM, Ecaterina Moraru (Valica) <
vali...@gmail.com> wrote:

> I've created this form to gather data about the buttons usage, in order to
> make a proposal for the buttons location
> https://docs.google.com/forms/d/e/1FAIpQLSeQwjxlFl321Ap97xKlYRcf
> -39wlG-cJXXqM1nududfjo3KHQ/viewanalytics
>
> Hope everyone is comfortable with Google Forms.
> Thanks,
> Caty
>
>
> On Thu, Apr 27, 2017 at 12:56 PM, Denis GERMAIN <dt.germ...@gmail.com>
> wrote:
>
>> Great proposition ! I like it.
>>
>> I see that the subject has also diverted to the fact that you can "save
>> and
>> continue" and "save and view". Some of our users are lost the first time
>> as
>> they click "save and continue" and don't understand why they are still in
>> edit mode. Clarifying this would indeed be a good idea, even though they
>> usually get the distinction quickly after that.
>>
>> Regards,
>> Denis
>>
>> 2017-04-26 17:01 GMT+02:00 Ecaterina Moraru (Valica) <vali...@gmail.com>:
>>
>> > On Wed, Apr 26, 2017 at 5:41 PM, Craig Wright <crw+xw...@crw.xyz>
>> wrote:
>> >
>> > > Hi Caty,
>> > >
>> > > I am a fan of “B”.
>> > >
>> > > I like the idea of putting the changelog and autosave options above
>> on a
>> > > preceding row. I would argue that for most users, their eyes only see
>> the
>> > > leftmost buttons as the functionally useful area. Thus putting Cancel
>> on
>> > > the far right effectively “hides” the button.
>> > >
>> >
>> > Yes, the most visible buttons are the ones on the left side and that's
>> the
>> > purpose. We need people to see the Save button :)
>> > Now, 'summary' functionality is not mandatory when editing and can also
>> be
>> > disabled from Administration - Editing.
>> > Having it on a separate line is not an option since we initial idea of
>> the
>> > thread is to provide a fixed bottom bar, when the viewport is small. So
>> > there are all on a single bar in order to be compact.
>> >
>> >
>> > >
>> > > For the purposes of mobile, I think it is acceptable to hide the
>> > changelog
>> > > and autosave options on small-screen resolutions. (Such as when I am
>> > > editing from iPhone, I am highly unlikely to leave a changelog message
>> > > anyway.)
>> > >
>> >
>> > I haven't iterated much on the mobile version, but the mockup I have is
>> > http://design.xwiki.org/xwiki/bin/download/Proposal/
>> > IdeaVisibleSave/mobile.png
>> > It can be improved, and as you said we could decide that on mobile we
>> can
>> > hide some functionality, but again hard to have stats to justify what is
>> > used/needed or not.
>> >
>> > Thanks,
>> > Caty
>> >
>> >
>> > > FWIW, taborder should be the following:
>> > >
>> > > 1. Edit input
>> > > 2. Changelog input
>> > > 3. Save button
>> > > 4. Preview button
>> > > 5. Cancel button
>> > > 6. Autosave option
>> > >
>> > > My $0.02. :)
>> > >
>> > > Thanks,
>> > > Craig
>> > >
>> > > > On Apr 26, 2017, at 2:20 PM, Ecaterina Moraru (Valica) <
>> > > vali...@gmail.com> wrote:
>> > > >
>> > > > Hi,
>> > > >
>> > > > On Wed, Apr 26, 2017 at 2:39 PM, Craig Wright <crw+xw...@crw.xyz
>> > > <mailto:crw+xw...@crw.xyz>> wrote:
>> > > >
>> > > >> Overall I like these changes. A couple of suggestions:
>> > > >>
>> > > >> No one in my community understands “Save and Continue” versus “Save
>> > and
>> > > >> View”. Dropping the “and Continue” is a great step, but I would go
>> > > farther
>> > > >> and give “Save and View” the emphasis color (blue, in this case).
>> That
>> > > is
>> > > >> the more highly understood behavior. “Save” (and continue editing)
>> is
>> > > >> useful but not as generally useful as “Save and View”. Especially
>> if
>> > you
>> > > >> are dropping Preview.
>> > > >>
>> > > >> FWIW, I use Preview more often from WYSIWYG m

Re: [xwiki-users] [Proposal][UX] Feedback for Visible Save buttons

[Ecaterina Moraru (Valica)]

I've created this form to gather data about the buttons usage, in order to
make a proposal for the buttons location
https://docs.google.com/forms/d/e/1FAIpQLSeQwjxlFl321Ap97xKlYRcf-39wlG-cJXXqM1nududfjo3KHQ/viewanalytics

Hope everyone is comfortable with Google Forms.
Thanks,
Caty


On Thu, Apr 27, 2017 at 12:56 PM, Denis GERMAIN <dt.germ...@gmail.com>
wrote:

> Great proposition ! I like it.
>
> I see that the subject has also diverted to the fact that you can "save and
> continue" and "save and view". Some of our users are lost the first time as
> they click "save and continue" and don't understand why they are still in
> edit mode. Clarifying this would indeed be a good idea, even though they
> usually get the distinction quickly after that.
>
> Regards,
> Denis
>
> 2017-04-26 17:01 GMT+02:00 Ecaterina Moraru (Valica) <vali...@gmail.com>:
>
> > On Wed, Apr 26, 2017 at 5:41 PM, Craig Wright <crw+xw...@crw.xyz> wrote:
> >
> > > Hi Caty,
> > >
> > > I am a fan of “B”.
> > >
> > > I like the idea of putting the changelog and autosave options above on
> a
> > > preceding row. I would argue that for most users, their eyes only see
> the
> > > leftmost buttons as the functionally useful area. Thus putting Cancel
> on
> > > the far right effectively “hides” the button.
> > >
> >
> > Yes, the most visible buttons are the ones on the left side and that's
> the
> > purpose. We need people to see the Save button :)
> > Now, 'summary' functionality is not mandatory when editing and can also
> be
> > disabled from Administration - Editing.
> > Having it on a separate line is not an option since we initial idea of
> the
> > thread is to provide a fixed bottom bar, when the viewport is small. So
> > there are all on a single bar in order to be compact.
> >
> >
> > >
> > > For the purposes of mobile, I think it is acceptable to hide the
> > changelog
> > > and autosave options on small-screen resolutions. (Such as when I am
> > > editing from iPhone, I am highly unlikely to leave a changelog message
> > > anyway.)
> > >
> >
> > I haven't iterated much on the mobile version, but the mockup I have is
> > http://design.xwiki.org/xwiki/bin/download/Proposal/
> > IdeaVisibleSave/mobile.png
> > It can be improved, and as you said we could decide that on mobile we can
> > hide some functionality, but again hard to have stats to justify what is
> > used/needed or not.
> >
> > Thanks,
> > Caty
> >
> >
> > > FWIW, taborder should be the following:
> > >
> > > 1. Edit input
> > > 2. Changelog input
> > > 3. Save button
> > > 4. Preview button
> > > 5. Cancel button
> > > 6. Autosave option
> > >
> > > My $0.02. :)
> > >
> > > Thanks,
> > > Craig
> > >
> > > > On Apr 26, 2017, at 2:20 PM, Ecaterina Moraru (Valica) <
> > > vali...@gmail.com> wrote:
> > > >
> > > > Hi,
> > > >
> > > > On Wed, Apr 26, 2017 at 2:39 PM, Craig Wright <crw+xw...@crw.xyz
> > > <mailto:crw+xw...@crw.xyz>> wrote:
> > > >
> > > >> Overall I like these changes. A couple of suggestions:
> > > >>
> > > >> No one in my community understands “Save and Continue” versus “Save
> > and
> > > >> View”. Dropping the “and Continue” is a great step, but I would go
> > > farther
> > > >> and give “Save and View” the emphasis color (blue, in this case).
> That
> > > is
> > > >> the more highly understood behavior. “Save” (and continue editing)
> is
> > > >> useful but not as generally useful as “Save and View”. Especially if
> > you
> > > >> are dropping Preview.
> > > >>
> > > >> FWIW, I use Preview more often from WYSIWYG mode since there is not
> a
> > > 1:1
> > > >> translation of editor view to page view. Whereas, when I am editing
> > > source,
> > > >> I can predict how it will look most of the time. :)
> > > >>
> > > >> I would also move the Cancel button over next to the other buttons.
> > If I
> > > >> had to rate which buttons I use the most frequently, “Cancel” would
> be
> > > at
> > > >> the top, followed by “Save and View,” followed very very distantly
> by
> > > “Save
> > > >> and Continue."
&

Re: [xwiki-users] [Proposal][UX] Feedback for Explicit Content Actions

[Ecaterina Moraru (Valica)]

Some summary until now:
P2: Craig, Olivier
P4: Mahomed, Steffen, Jesse, Miroslav

Thanks,
Caty

On Thu, Apr 27, 2017 at 10:06 AM, Miroslav Galajda <
miroslav.gala...@gmail.com> wrote:

> Opps, I wanted to vote for P4 not for P2 :-) I've mixed up the images :-)
>
> P4 goes with existing style and makes it from design perspective consistent
> with buttons for inline section editing.
>
> Sorry
>
> Miroslav Galajda
>
> On 26 April 2017 at 16:34, Miroslav Galajda <miroslav.gala...@gmail.com>
> wrote:
>
> > Hi,
> >
> > I'm voting for P2 because it is making the visual style of buttons with
> > dropdown menu to look as they should look, with indication of the
> dropdown
> > menu.
> > Secondly, the visual style of the edit page button will keep consistent
> > with the buttons for inline section editing.
> >
> > Best regards,
> > Miroslav Galajda
> >
> >
> >
> > On 26 April 2017 at 15:27, Ecaterina Moraru (Valica) <vali...@gmail.com>
> > wrote:
> >
> >> This is getting interesting since I know users that like the P2 version
> >> and
> >> actually it was one of the first choices for re-implementation.
> >>
> >> I guess we need more votes to reach a conclusion.
> >> Thanks to everyone that is participating,
> >> Caty
> >>
> >> On Wed, Apr 26, 2017 at 4:14 PM, Jesse Bright <je...@abrightfamily.com>
> >> wrote:
> >>
> >> > They both look great but I like the look of P4 better.
> >> >
> >> > Regards,
> >> >
> >> > Jesse
> >> >
> >> > > On Apr 25, 2017, at 10:33 AM, Ecaterina Moraru (Valica) <
> >> > vali...@gmail.com> wrote:
> >> > >
> >> > > Hi,
> >> > >
> >> > > We had feedback that new users don't know where to find the 'Edit'
> and
> >> > > 'Create' buttons. Also there is some confusions of why we have a
> 'cog'
> >> > icon
> >> > > that contains actions like 'Delete' and a 'three dots' icon that
> >> contain
> >> > > other actions.
> >> > >
> >> > > Would be great if you could tell us which version you prefer:
> >> > > P2:
> >> > > http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaLabe
> >> ledActions/
> >> > advancedUser.png
> >> > > P4:
> >> > > http://design.xwiki.org/xwiki/bin/download/Proposal/
> >> > IdeaLabeledActions/P4_1_bigger.png
> >> > >
> >> > > Both proposals add backgrounds around the icons, the main difference
> >> is
> >> > > that P2 also uses descriptive labels, while P4 keeps the consistency
> >> with
> >> > > the top icons and a more minimalist style.
> >> > >
> >> > > For the more actions menu, we want to combine the actions and add
> >> > category
> >> > > labels, see
> >> > > http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaLabe
> >> ledActions/
> >> > moreActions.png
> >> > >
> >> > > What do you think? Do you have other solutions for your instances?
> Did
> >> > you
> >> > > encounter the same problem?
> >> > >
> >> > > Thanks,
> >> > > Caty
> >> >
> >> >
> >> >
> >>
> >
> >
>

Re: [xwiki-users] [Proposal][UX] Feedback for Explicit Content Actions

[Ecaterina Moraru (Valica)]

On Wed, Apr 26, 2017 at 6:45 PM, Craig Wright <crw+xw...@crw.xyz> wrote:

> Hi Caty,
>
> I like the current P2. What are the drop-down options for Edit?
>

'Edit' drop-down is for 'Advanced' users and it contains the other edit
modes, see
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaLabeledActions/advancedExpanded.png
For 'Normal' users the 'Edit' is just a button, see
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaLabeledActions/simpleUser.png


>
> My reasoning for hiding Create is that the Create function is a little
> confusing to begin with for new users. If you are used to files and
> folders, it is weird that a file is also a folder (that a node can have
> child nodes that are also documents). This makes sense to me because I am a
> computer science grad, but it isn’t that obvious to long-time Mac/Windows
> users. I would almost want it to be called “Create New Child Page” or
> something, to better indicate what is going to happen when you click that
> button. Except, sometimes, it doesn’t create a new child page, depending on
> the template you choose. In any case, there is no obvious solution, P2
> looks best of the options provided. :)
>

That's another story :)

Thanks,
Caty


>
> Thanks,
> Craig
>
>
> > On Apr 26, 2017, at 4:06 PM, Ecaterina Moraru (Valica) <
> vali...@gmail.com> wrote:
> >
> > On Wed, Apr 26, 2017 at 5:46 PM, Craig Wright <crw+xw...@crw.xyz> wrote:
> >
> >> Hi Caty,
> >>
> >> I would use the Edit text w/ pencil on Edit and just the plus icon for
> >> Create. The reason is Edit needs to be differentiated from Create, but
> this
> >> is accomplished with the word Edit. On small resolutions (iPhone) I
> think
> >> it is acceptable to hide the word Edit.
> >>
> >
> > I have to disagree here. The purpose is to promote and highlight both
> > important actions and that is both 'Edit' and 'Create'. The 'plus' sign
> can
> > be also confusing for new users. Highlighting just 'Edit' would be hard
> to
> > justify.
> >
> >
> >>
> >> The triple-dot icon needs to be a button. P2 has it as a free-floating
> >> icon, P4 has it as a button: it needs to be a button as per P4.
> >>
> >
> > Yes, a better screenshot for P2 is
> > http://design.xwiki.org/xwiki/bin/download/Proposal/
> IdeaLabeledActions/P2_noRightPanels.png
> > The symmetric P4 screenshot is
> > http://design.xwiki.org/xwiki/bin/download/Proposal/
> IdeaLabeledActions/P4_noRightPanels.png
> >
> > Thanks,
> > Caty
> >
> >
> >> Otherwise, looks good!
> >>
> >> Be well,
> >> Craig
> >>
> >>> On Apr 26, 2017, at 3:34 PM, Miroslav Galajda <
> >> miroslav.gala...@gmail.com> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I'm voting for P2 because it is making the visual style of buttons with
> >>> dropdown menu to look as they should look, with indication of the
> >> dropdown
> >>> menu.
> >>> Secondly, the visual style of the edit page button will keep consistent
> >>> with the buttons for inline section editing.
> >>>
> >>> Best regards,
> >>> Miroslav Galajda
> >>>
> >>>
> >>>
> >>> On 26 April 2017 at 15:27, Ecaterina Moraru (Valica) <
> vali...@gmail.com>
> >>> wrote:
> >>>
> >>>> This is getting interesting since I know users that like the P2
> version
> >> and
> >>>> actually it was one of the first choices for re-implementation.
> >>>>
> >>>> I guess we need more votes to reach a conclusion.
> >>>> Thanks to everyone that is participating,
> >>>> Caty
> >>>>
> >>>> On Wed, Apr 26, 2017 at 4:14 PM, Jesse Bright <
> je...@abrightfamily.com>
> >>>> wrote:
> >>>>
> >>>>> They both look great but I like the look of P4 better.
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> Jesse
> >>>>>
> >>>>>> On Apr 25, 2017, at 10:33 AM, Ecaterina Moraru (Valica) <
> >>>>> vali...@gmail.com> wrote:
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> We had feedback that new users don't know where to find the 'Edit'
> and
> >>>>>> 'Create' buttons. Also there is some confusions of why we have a
> 'cog'
> 

Re: [xwiki-users] [Proposal][UX] Feedback for Explicit Content Actions

[Ecaterina Moraru (Valica)]

On Wed, Apr 26, 2017 at 5:46 PM, Craig Wright <crw+xw...@crw.xyz> wrote:

> Hi Caty,
>
> I would use the Edit text w/ pencil on Edit and just the plus icon for
> Create. The reason is Edit needs to be differentiated from Create, but this
> is accomplished with the word Edit. On small resolutions (iPhone) I think
> it is acceptable to hide the word Edit.
>

I have to disagree here. The purpose is to promote and highlight both
important actions and that is both 'Edit' and 'Create'. The 'plus' sign can
be also confusing for new users. Highlighting just 'Edit' would be hard to
justify.


>
> The triple-dot icon needs to be a button. P2 has it as a free-floating
> icon, P4 has it as a button: it needs to be a button as per P4.
>

Yes, a better screenshot for P2 is
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaLabeledActions/P2_noRightPanels.png
The symmetric P4 screenshot is
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaLabeledActions/P4_noRightPanels.png

Thanks,
Caty


> Otherwise, looks good!
>
> Be well,
> Craig
>
> > On Apr 26, 2017, at 3:34 PM, Miroslav Galajda <
> miroslav.gala...@gmail.com> wrote:
> >
> > Hi,
> >
> > I'm voting for P2 because it is making the visual style of buttons with
> > dropdown menu to look as they should look, with indication of the
> dropdown
> > menu.
> > Secondly, the visual style of the edit page button will keep consistent
> > with the buttons for inline section editing.
> >
> > Best regards,
> > Miroslav Galajda
> >
> >
> >
> > On 26 April 2017 at 15:27, Ecaterina Moraru (Valica) <vali...@gmail.com>
> > wrote:
> >
> >> This is getting interesting since I know users that like the P2 version
> and
> >> actually it was one of the first choices for re-implementation.
> >>
> >> I guess we need more votes to reach a conclusion.
> >> Thanks to everyone that is participating,
> >> Caty
> >>
> >> On Wed, Apr 26, 2017 at 4:14 PM, Jesse Bright <je...@abrightfamily.com>
> >> wrote:
> >>
> >>> They both look great but I like the look of P4 better.
> >>>
> >>> Regards,
> >>>
> >>> Jesse
> >>>
> >>>> On Apr 25, 2017, at 10:33 AM, Ecaterina Moraru (Valica) <
> >>> vali...@gmail.com> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> We had feedback that new users don't know where to find the 'Edit' and
> >>>> 'Create' buttons. Also there is some confusions of why we have a 'cog'
> >>> icon
> >>>> that contains actions like 'Delete' and a 'three dots' icon that
> >> contain
> >>>> other actions.
> >>>>
> >>>> Would be great if you could tell us which version you prefer:
> >>>> P2:
> >>>> http://design.xwiki.org/xwiki/bin/download/Proposal/
> >> IdeaLabeledActions/
> >>> advancedUser.png
> >>>> P4:
> >>>> http://design.xwiki.org/xwiki/bin/download/Proposal/
> >>> IdeaLabeledActions/P4_1_bigger.png
> >>>>
> >>>> Both proposals add backgrounds around the icons, the main difference
> is
> >>>> that P2 also uses descriptive labels, while P4 keeps the consistency
> >> with
> >>>> the top icons and a more minimalist style.
> >>>>
> >>>> For the more actions menu, we want to combine the actions and add
> >>> category
> >>>> labels, see
> >>>> http://design.xwiki.org/xwiki/bin/download/Proposal/
> >> IdeaLabeledActions/
> >>> moreActions.png
> >>>>
> >>>> What do you think? Do you have other solutions for your instances? Did
> >>> you
> >>>> encounter the same problem?
> >>>>
> >>>> Thanks,
> >>>> Caty
> >>>
> >>>
> >>>
> >>
>
>

Re: [xwiki-users] [Proposal][UX] Feedback for Visible Save buttons

[Ecaterina Moraru (Valica)]

On Wed, Apr 26, 2017 at 5:41 PM, Craig Wright <crw+xw...@crw.xyz> wrote:

> Hi Caty,
>
> I am a fan of “B”.
>
> I like the idea of putting the changelog and autosave options above on a
> preceding row. I would argue that for most users, their eyes only see the
> leftmost buttons as the functionally useful area. Thus putting Cancel on
> the far right effectively “hides” the button.
>

Yes, the most visible buttons are the ones on the left side and that's the
purpose. We need people to see the Save button :)
Now, 'summary' functionality is not mandatory when editing and can also be
disabled from Administration - Editing.
Having it on a separate line is not an option since we initial idea of the
thread is to provide a fixed bottom bar, when the viewport is small. So
there are all on a single bar in order to be compact.


>
> For the purposes of mobile, I think it is acceptable to hide the changelog
> and autosave options on small-screen resolutions. (Such as when I am
> editing from iPhone, I am highly unlikely to leave a changelog message
> anyway.)
>

I haven't iterated much on the mobile version, but the mockup I have is
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/mobile.png
It can be improved, and as you said we could decide that on mobile we can
hide some functionality, but again hard to have stats to justify what is
used/needed or not.

Thanks,
Caty


> FWIW, taborder should be the following:
>
> 1. Edit input
> 2. Changelog input
> 3. Save button
> 4. Preview button
> 5. Cancel button
> 6. Autosave option
>
> My $0.02. :)
>
> Thanks,
> Craig
>
> > On Apr 26, 2017, at 2:20 PM, Ecaterina Moraru (Valica) <
> vali...@gmail.com> wrote:
> >
> > Hi,
> >
> > On Wed, Apr 26, 2017 at 2:39 PM, Craig Wright <crw+xw...@crw.xyz
> <mailto:crw+xw...@crw.xyz>> wrote:
> >
> >> Overall I like these changes. A couple of suggestions:
> >>
> >> No one in my community understands “Save and Continue” versus “Save and
> >> View”. Dropping the “and Continue” is a great step, but I would go
> farther
> >> and give “Save and View” the emphasis color (blue, in this case). That
> is
> >> the more highly understood behavior. “Save” (and continue editing) is
> >> useful but not as generally useful as “Save and View”. Especially if you
> >> are dropping Preview.
> >>
> >> FWIW, I use Preview more often from WYSIWYG mode since there is not a
> 1:1
> >> translation of editor view to page view. Whereas, when I am editing
> source,
> >> I can predict how it will look most of the time. :)
> >>
> >> I would also move the Cancel button over next to the other buttons. If I
> >> had to rate which buttons I use the most frequently, “Cancel” would be
> at
> >> the top, followed by “Save and View,” followed very very distantly by
> “Save
> >> and Continue."
> >>
> >>
> > This is very interesting behavior. I would love to be able to have some
> > usage stats, but with XWiki being installable and independently hosted,
> > stats are always hard to get by.
> >
> > Personally I use "Save" a lot (I like to save often in order to not lose
> > stuff), but I usually use the keyboard shortcut, not necessarily the
> > button. It is true that 'Preview' in WYSIWYG has its usages, especially
> > when using macros or nested macros, since the result is not accurate.
> >
> > Regarding "Save & View" I always do it as a final step, while I never use
> > "Cancel" - i just navigate away or hit the browser's 'Back'.
> >
> > Also in terms of functionality the "Autosave" can be used instead of the
> > "Save", so we can remove 'Save' (especially in case of advanced users).
> >
> > So the only stats I have are from the http://playground.xwiki.org <
> http://playground.xwiki.org/> from the
> > past 2 months. These are the top 3 pages edited, see
> > http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/
> UsageFebApr2017.png <http://design.xwiki.org/xwiki/bin/download/Proposal/
> IdeaVisibleSave/UsageFebApr2017.png>
> >
> > Now let's see the heatmaps:
> > - Sandbox.WebHome:
> > http://design.xwiki.org/xwiki/bin/download/Proposal/
> IdeaVisibleSave/Sandbox-Home.png <http://design.xwiki.org/
> xwiki/bin/download/Proposal/IdeaVisibleSave/Sandbox-Home.png>
> > - Sandbox.TestPage1:
> > http://design.xwiki.org/xwiki/bin/download/Proposal/
> IdeaVisibleSave/Sandbox-TestPage1.png <http://design.xwiki.org/
> xwiki/bin/download/Proposal/IdeaVisibleSave/Sandbox-TestP

Re: [xwiki-users] Color theme switching to default!

[Ecaterina Moraru (Valica)]

Make sure the sub-wiki users have the right to view the global theme?

Thanks,
Caty

On Wed, Apr 26, 2017 at 2:12 PM, Petros Marinos  wrote:

> Greetings dear XWiki users!
>
> I have installed XWiki 8.4.4 on CentOS 7.3, with Tomcat and MySQL support.
>
> I have integrated the site with Active Directory, so any user can use
> Windows credentials to login and have the XWiki user automatically created
> (without the need of registration).
>
> In the starting “Home” Wiki, i have created a new Color Theme to use. Every
> new user logins to this wiki, retains the Color Theme i chose for the wiki
> and all is good.
>
> However, when i created a new Wiki (Wiki2 let’s say) and have chosen the
> new “Global” Color Theme to use for this Wiki too, only root can login to
> that wiki and retain it. All other new users, once they login to this wiki,
> have their color theme switching to default!
>
> What am i missing?
>
> Thank you all for any assistance!
>
> Best regards,
> Petros
>

Re: [xwiki-users] [Proposal][UX] Feedback for Explicit Content Actions

[Ecaterina Moraru (Valica)]

This is getting interesting since I know users that like the P2 version and
actually it was one of the first choices for re-implementation.

I guess we need more votes to reach a conclusion.
Thanks to everyone that is participating,
Caty

On Wed, Apr 26, 2017 at 4:14 PM, Jesse Bright <je...@abrightfamily.com>
wrote:

> They both look great but I like the look of P4 better.
>
> Regards,
>
> Jesse
>
> > On Apr 25, 2017, at 10:33 AM, Ecaterina Moraru (Valica) <
> vali...@gmail.com> wrote:
> >
> > Hi,
> >
> > We had feedback that new users don't know where to find the 'Edit' and
> > 'Create' buttons. Also there is some confusions of why we have a 'cog'
> icon
> > that contains actions like 'Delete' and a 'three dots' icon that contain
> > other actions.
> >
> > Would be great if you could tell us which version you prefer:
> > P2:
> > http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaLabeledActions/
> advancedUser.png
> > P4:
> > http://design.xwiki.org/xwiki/bin/download/Proposal/
> IdeaLabeledActions/P4_1_bigger.png
> >
> > Both proposals add backgrounds around the icons, the main difference is
> > that P2 also uses descriptive labels, while P4 keeps the consistency with
> > the top icons and a more minimalist style.
> >
> > For the more actions menu, we want to combine the actions and add
> category
> > labels, see
> > http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaLabeledActions/
> moreActions.png
> >
> > What do you think? Do you have other solutions for your instances? Did
> you
> > encounter the same problem?
> >
> > Thanks,
> > Caty
>
>
>

Re: [xwiki-users] [Proposal][UX] Feedback for Visible Save buttons

[Ecaterina Moraru (Valica)]

Hi,

On Wed, Apr 26, 2017 at 2:39 PM, Craig Wright <crw+xw...@crw.xyz> wrote:

> Overall I like these changes. A couple of suggestions:
>
> No one in my community understands “Save and Continue” versus “Save and
> View”. Dropping the “and Continue” is a great step, but I would go farther
> and give “Save and View” the emphasis color (blue, in this case). That is
> the more highly understood behavior. “Save” (and continue editing) is
> useful but not as generally useful as “Save and View”. Especially if you
> are dropping Preview.
>
> FWIW, I use Preview more often from WYSIWYG mode since there is not a 1:1
> translation of editor view to page view. Whereas, when I am editing source,
> I can predict how it will look most of the time. :)
>
> I would also move the Cancel button over next to the other buttons. If I
> had to rate which buttons I use the most frequently, “Cancel” would be at
> the top, followed by “Save and View,” followed very very distantly by “Save
> and Continue."
>
>
This is very interesting behavior. I would love to be able to have some
usage stats, but with XWiki being installable and independently hosted,
stats are always hard to get by.

Personally I use "Save" a lot (I like to save often in order to not lose
stuff), but I usually use the keyboard shortcut, not necessarily the
button. It is true that 'Preview' in WYSIWYG has its usages, especially
when using macros or nested macros, since the result is not accurate.

Regarding "Save & View" I always do it as a final step, while I never use
"Cancel" - i just navigate away or hit the browser's 'Back'.

Also in terms of functionality the "Autosave" can be used instead of the
"Save", so we can remove 'Save' (especially in case of advanced users).

So the only stats I have are from the http://playground.xwiki.org from the
past 2 months. These are the top 3 pages edited, see
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/UsageFebApr2017.png

Now let's see the heatmaps:
- Sandbox.WebHome:
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/Sandbox-Home.png
- Sandbox.TestPage1:
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/Sandbox-TestPage1.png
- Sandbox.Test.WebHome:
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/Sandbox-Test.png

>From these heatmaps we see that 'Preview' has the most usage and after is
"Save", with no usage for "Save & Continue" and "Cancel".
Not we need to take into account 2 aspects: Sandbox is used by first-time
users of XWiki and they usually are afraid to mess things up so the Preview
is comforting for them. Also in the current layout 'Preview' is the first
button from left-to-right, so it's assumed as the primary action.

So if the initial proposal was 'varA', what do you think about 'varB'?
- var A [Save; Save & View]:
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/varA.png
- var B [Save & View; Preview]:
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/varB.png
- var C [Save & View; Save]:
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/varC.png

Note: users that went to 'Preview', usually come back to the previous view,
see
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/Sandbox-Test-preview.png

I left 'Cancel' at the end, in order to be the last button and have
visibility (not get lost in all the other options). Users need to use it as
an 'escape' route, so it's better to find it fast and always have a static
position = last. For this usually the first and last positions are best.

My initial rationale to remove 'Preview' from the WYSIWYG editor was that
WYSIWYG does life preview, so I though not many users use it, since I never
used it. Seeing the stats for newcomers is impressive, still it would be
great if more advanced / long-term users of XWiki would summaries a bit
their button usage, so we could take a more informed decision. XWiki needs
to accommodate both newcomers, but also long term users.

Thanks,
Caty


> Nice work!
>
> Craig
>
>
> > On Apr 25, 2017, at 6:21 PM, Ecaterina Moraru (Valica) <
> vali...@gmail.com> wrote:
> >
> > Hi,
> >
> > We had some users complaining that the first time they edit a page they
> > don't know how to save it. Depending on the screen resolution, the save
> > buttons since they are at the bottom of the page are not visible and some
> > users don't know they need to scroll in order to see them.
> >
> > We want to make some changes to XWiki, that:
> > - Display the save buttons in a fixed bottom bar, when they are out of
> the
> > viewport, see
> > http://design.xwiki.org/xwiki/bin/download/Proposal/
> IdeaVisibleSave/bottomBar.png
> > - W

Re: [xwiki-users] [Proposal][UX] Feedback for Explicit Content Actions

[Ecaterina Moraru (Valica)]

On Wed, Apr 26, 2017 at 1:11 PM, Mahomed Hussein <maho...@custodiandc.com>
wrote:

> P2 is great because it is descriptive and probably helpful on wikis with a
> lot of users who are "less technical" or "slightly technophobic".
>
> P4 is great because it is compact and I think even technophobic users will
> understand what the buttons do after the first few tries. So my vote is for
> P4.
>

Hi, Thank for the vote. Noted :)

Caty


>
> Regarding "combine the actions and add category labels". That looks
> awesome and much more intuitive.
>
>
> Kind regards,
>
>
>
>
> Mahomed Hussein
> Custodian Data Centre
> Email: maho...@custodiandc.com
> http://www.CustodianDC.com
>
> -----Original Message-
> From: users [mailto:users-boun...@xwiki.org] On Behalf Of Ecaterina
> Moraru (Valica)
> Sent: 25 April 2017 18:33
> To: XWiki Mailinglist <users@xwiki.org>
> Subject: [xwiki-users] [Proposal][UX] Feedback for Explicit Content Actions
>
> Hi,
>
> We had feedback that new users don't know where to find the 'Edit' and
> 'Create' buttons. Also there is some confusions of why we have a 'cog' icon
> that contains actions like 'Delete' and a 'three dots' icon that contain
> other actions.
>
> Would be great if you could tell us which version you prefer:
> P2:
> http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaLabeledActions/
> advancedUser.png
> P4:
> http://design.xwiki.org/xwiki/bin/download/Proposal/
> IdeaLabeledActions/P4_1_bigger.png
>
> Both proposals add backgrounds around the icons, the main difference is
> that P2 also uses descriptive labels, while P4 keeps the consistency with
> the top icons and a more minimalist style.
>
> For the more actions menu, we want to combine the actions and add category
> labels, see http://design.xwiki.org/xwiki/bin/download/Proposal/
> IdeaLabeledActions/moreActions.png
>
> What do you think? Do you have other solutions for your instances? Did you
> encounter the same problem?
>
> Thanks,
> Caty
>

Re: [xwiki-users] [Proposal][UX] Feedback for Visible Save buttons

[Ecaterina Moraru (Valica)]

Hi,

The proposal it's just one version, but the image you vote for is how it
will look like, after the user scrolls. Yes, it is the new / proposed
version, so I'm glad you like it.

On Wed, Apr 26, 2017 at 1:04 PM, Mahomed Hussein <maho...@custodiandc.com>
wrote:

> I don't really use small viewports but if I did, my vote would be for
> http://design.xwiki.org/xwiki/bin/download/Proposal/
> IdeaVisibleSave/after.png
>
> The design is clean, flows and is intuitive. (Unless I've misunderstood
> you, and you are saying this is the way it looks now :) )
>
> I have noticed that you have lost "Preview" from the compacted bar. Maybe
> make the left button preview, the right button is "Save & View" with a drop
> down for "Save & Continue" (like you have with the Edit/Settings button.
>

I've removed the Preview for the WYSIWYG mode, but it would be necessary
for the Wiki mode.

Regarding the dropdown with the options, initially I iterated it but I
don't quite like how it looked
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/5.png

Thanks for our feedback,
Caty


>
>
> Kind regards,
>
>
>
>
> Mahomed Hussein
> Custodian Data Centre
> Email: maho...@custodiandc.com
> http://www.CustodianDC.com
>
> -Original Message-
> From: users [mailto:users-boun...@xwiki.org] On Behalf Of Ecaterina
> Moraru (Valica)
> Sent: 25 April 2017 18:22
> To: XWiki Mailinglist <users@xwiki.org>
> Subject: [xwiki-users] [Proposal][UX] Feedback for Visible Save buttons
>
> Hi,
>
> We had some users complaining that the first time they edit a page they
> don't know how to save it. Depending on the screen resolution, the save
> buttons since they are at the bottom of the page are not visible and some
> users don't know they need to scroll in order to see them.
>
> We want to make some changes to XWiki, that:
> - Display the save buttons in a fixed bottom bar, when they are out of the
> viewport, see http://design.xwiki.org/xwiki/bin/download/Proposal/
> IdeaVisibleSave/bottomBar.png
> - When the user scroll, the buttons go into their position, see
> http://design.xwiki.org/xwiki/bin/download/Proposal/
> IdeaVisibleSave/after.png
> - We compacted the bottom functionalities (summary, minor, auto-save), see
> before:
> http://design.xwiki.org/xwiki/bin/download/Proposal/
> IdeaVisibleSave/before.png
> after:
> http://design.xwiki.org/xwiki/bin/download/Proposal/
> IdeaVisibleSave/smallViewPort.png
>
> What do you think about this proposal? Would it improve the visibility of
> the buttons? Do you have other ideas? Is it something we should implement?
>
> Thanks,
> Caty
>

[xwiki-users] [Proposal][UX] Feedback for Explicit Content Actions

[Ecaterina Moraru (Valica)]

Hi,

We had feedback that new users don't know where to find the 'Edit' and
'Create' buttons. Also there is some confusions of why we have a 'cog' icon
that contains actions like 'Delete' and a 'three dots' icon that contain
other actions.

Would be great if you could tell us which version you prefer:
P2:
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaLabeledActions/advancedUser.png
P4:
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaLabeledActions/P4_1_bigger.png

Both proposals add backgrounds around the icons, the main difference is
that P2 also uses descriptive labels, while P4 keeps the consistency with
the top icons and a more minimalist style.

For the more actions menu, we want to combine the actions and add category
labels, see
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaLabeledActions/moreActions.png

What do you think? Do you have other solutions for your instances? Did you
encounter the same problem?

Thanks,
Caty

[xwiki-users] [Proposal][UX] Feedback for Visible Save buttons

[Ecaterina Moraru (Valica)]

Hi,

We had some users complaining that the first time they edit a page they
don't know how to save it. Depending on the screen resolution, the save
buttons since they are at the bottom of the page are not visible and some
users don't know they need to scroll in order to see them.

We want to make some changes to XWiki, that:
- Display the save buttons in a fixed bottom bar, when they are out of the
viewport, see
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/bottomBar.png
- When the user scroll, the buttons go into their position, see
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/after.png
- We compacted the bottom functionalities (summary, minor, auto-save), see
before:
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/before.png
after:
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/smallViewPort.png

What do you think about this proposal? Would it improve the visibility of
the buttons? Do you have other ideas? Is it something we should implement?

Thanks,
Caty

Re: [xwiki-users] display page title and name(url) while creating a page

[Ecaterina Moraru (Valica)]

ou can use JS.
> >>>>
> >>>> Thanks
> >>>> -Vincent
> >>>>
> >>>>> On 21 April 2017 at 15:28, Vincent Massol <vinc...@massol.net>
> wrote:
> >>>>>
> >>>>>> Hi Miroslav,
> >>>>>>
> >>>>>>> On 21 Apr 2017, at 15:05, Miroslav Galajda <
> >> miroslav.gala...@gmail.com
> >>>>>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> Hi, let me enter into this conversion.
> >>>>>>> Some time ago I've asked for help how to solve problem with
> >> diacritics
> >>>>>> (or
> >>>>>>> accents) in page names when creating new pages so that the have
> >>>>>>> url-friendly names. You can search for "strip accents from page
> >>>>>>> name
> >>>> used
> >>>>>>> in url" in xwiki users mailing list. I've got no hint or
> >>>>>>> solution
> >> from
> >>>>>>> xwiki community till today.
> >>>>>>>
> >>>>>>> I've come with solution that ensures for simple users, creating
> >>>>>>> url-friendly names without requiring them to think about the
> >>>>>>> concept
> >> of
> >>>>>> the
> >>>>>>> page name or page title. They simple enter the desired human
> >>>>>>> readably
> >>>>>> page
> >>>>>>> name, and in the code behind of the page creation, I have made
> >>>>>>> some modifications in createinline.vm to hook into page creation
> process.
> >>>> The
> >>>>>>> modifications are mainly javascript based, where I've attache to
> >> submit
> >>>>>>> event of the "form#create", where I replace the entered "title"
> >>>>>>> with
> >>>> the
> >>>>>>> one for url-friendly. And for url-friendly name I've used this
> >>>> javascript
> >>>>>>> based solution on https://pid.github.io/speakingurl/.
> >>>>>>> I've integrated this principle also into page creation process
> >>>>>>> of FAQ
> >>>> and
> >>>>>>> Blog applications, which we are using in our xwiki installation.
> >>>>>>>
> >>>>>>> It would be nice if you could integrate this principle into
> >>>>>>> xwiki so
> >>>> that
> >>>>>>> everyone can have nice url-friendly urls without worring about
> >>>>>>> it. It
> >>>> is
> >>>>>>> also suitable for english speaking users. You don't have to
> >>>>>>> worry
> >> about
> >>>>>>> entering spaces or other non-url allowed characters, which make
> >>>>>>> url
> >>>> look
> >>>>>>> ugly.
> >>>>>>
> >>>>>> That looks very nice!
> >>>>>>
> >>>>>> One way forward I could think about:
> >>>>>> * We provide some Create script service to return a URL-friendly
> >> string.
> >>>>>> We introduce a component role for this. We refactor
> >>>>>> createinline.vm to
> >>>> use
> >>>>>> it and to display the URL.
> >>>>>> * You could then contribute your code as an extension that we
> >>>>>> make available on extensions.xwiki.org for users to install
> >>>>>> * We decide later on if we want to bundle it by default
> >>>>>>
> >>>>>> If we don’t agree about displaying the URL by default all the
> >>>>>> time
> >> then
> >>>> an
> >>>>>> option is to introduce a UIX in createinline.vm for that. And
> >>>>>> this
> >>>> could be
> >>>>>> implemented in your extension too for example or by default in
> >>>>>> XWiki (possibly with an Admin setting).
> >>>>>>
> >>>>>> WDYT?
> >>>>>>
> >>>>>> Thanks
> >>>>>> -Vincent
> >>>>>>

Re: [xwiki-users] display page title and name(url) while creating a page

[Ecaterina Moraru (Valica)]

Hi,

Users can change the URL anytime after the page creation, and that is using
the "Rename" action, although I agree that simple users might not really
see the connection between Rename, URLs and Titles. So yes it would be
ideal to provide the ability to select (reserve) the URL from the creation
page step (for steps optimization purposes).

Now, some important mention is the use case. From what I can assume from
your answers, the majority of you have Wikis / Knowledge Bases. For this
flavor the URLs are important and I quite get the need.
The issue is for users that use XWiki for Groupware / Applications use
case. When your instance is using heavily applications, you don't care
about the URL is generating, you don't care about the nesting, etc. We had
users that requested to never see the Page Name part and actually the
ability to auto-generate the URL with some random numbers that they
shouldn't see.

That's why the subject is a bit problematic, because some users want to
see/alter the Page Name/ URL; while others don't care it exists.

I also don't like the configuration proposal, since it's always hard to
test all combinations of configurations and we need to decide on the
default.
Not sure about changing it in the Base Flavor, since not all Flavors users
might need it. The UIX could be a solution in order to use it just by some
Flavors.

What is really interesting and good to know is that indeed the Page Name /
URL are important for Knowledge Bases (KB). Still in KBs the content
creators are not that many (compared to readers) and they usually are the
wiki gardeners, and they tend to be 'advanced' users.

The smallest / simplest changes would indeed be in the labels wording and
descriptions. Also the 'URL' mention instead of Page Name.

Thanks,
Caty


On Sun, Apr 23, 2017 at 8:23 AM, Vishal  wrote:

> Hi all..
> Thanks for taking the issue this much seriously.
>
> Hi Vincent..
> > Hey, you’re from Pune? :) I’ve been there about 15 times!
> Hey, you are welcome again.. I would expect you to drop me an email while
> visiting Pune next time :)
>
> > Normal users don't generally care about their URLs and SEO.
> Hi Caty..
> You are definitely correct about SEO as simple users don't even know what
> SEO is.
> But I am very sure that even simple users do care about URLs. For instance,
> we share all our educational articles on our wiki in chats, like in
> WhatsApp, Facebook, Gmail, and what not. And they often ask me to clean the
> encoded URLs for them. In last 15 days for instance, I had to rename about
> 250 pages..
> > I don’t fully agree with you. I have the feeling (can’t prove it)
> And I guess this is what Vincent felt but couldn't prove.
>
> > But for your use case you shoyld write a shorting/trimming algorithm, but
> > this is custom
> Yes I agree. It should be custom because not all will want such trimming of
> URLs.
>
> >It may generate nicer urls but they’re not perfect either. They’re a bit
> longish from what I see
> I think we can't and shouldn't force anyone to have short URLs. Long URL
> doesn't seem a problem for us, but inability to shorten them in the first
> place indeed is.
> I disagree with having any shortening algorithm as even we do use full
> names
> in URLs at certain places. e.g. /Pune-University
>
> My Proposal:
> I strongly agree with Vincent about Create Page UI like AWM. This is what
> we
> think will be most user friendly. (Sorry, couldn't upload images but rough
> layout)
>
> *Title: (Tip: Title as shown on Page/Document)
> [Title Textbox]
>
> URL: (Tip: this is a webaddress)
> [Non editable initial part of URL][Textbox for last part of URL]
>
> Location: (Tip: location of page in wiki)
> [Documents tree/Parent]*
>
> In above layout, we could use algorithm at URL section just to make them
> more readable (removing ecoded characters), nothing else.
>
> And it would be nice to have this universally editable, no need of any
> options like ALWAYS, NEVER, etc. Also no need to restrict it to just
> advanced users, because mostly users who could create a page would know
> about URLs.
>
> Very much thanks for this wonderful discussion.
> Regards,
> Vishal
>
>
>
> --
> View this message in context: http://xwiki.475771.n2.nabble.
> com/Page-Title-and-Name-confusion-tp7603546p7603588.html
> Sent from the XWiki- Users mailing list archive at Nabble.com.
>

Re: [xwiki-users] XWiki User Group Lyon ?

[Ecaterina Moraru (Valica)]

The idea is very nice Thomas.

Ideally we should also have remote meetings to know each other better. Like
once a month over hangout or other open-source services like
https://talky.io or https://meet.jit.si/. Usually people participating in
these meeting want to have the local ones too. Maybe someone is interested
in meeting in Iasi, Romania? :) (your thread has just been hijacked :P)

Thanks,
Caty

On Thu, Apr 13, 2017 at 3:48 PM, Thomas Mortagne 
wrote:

> Hi everyone,
>
> I'm wondering if anyone would be interested in a XWiki User Group in
> Lyon (France).
>
> The idea would be to meet on a regular basis (It depends a lot how
> many people are interested and I guess it's a discussion to have
> during the first meeting but something like once every 4 months for
> example). The idea would be to have short talks (something like 15/20
> minutes) on various subjects (here are some examples on my side: talk
> about new features, present the intranet of "Atelier des Médias"
> coworking association which is based on XWiki, etc.) and then spend a
> nice evening discussing and eat/drink stuff.
>
> WDYT ?
>
> --
> Thomas Mortagne
>

Re: [xwiki-users] location of footnotes

[Ecaterina Moraru (Valica)]

It seems like a bug for CkEditor and Footnote macro. You should report it
on https://jira.xwiki.org

You could manually set the footnotes from Wiki syntax, see
http://extensions.xwiki.org/xwiki/bin/view/Extension/Footnote%20Macro
http://extensions.xwiki.org/xwiki/bin/view/Extension/Put%20Footnotes%20Macro

Thanks,
Caty

On Sun, Apr 2, 2017 at 6:58 PM, Vishal  wrote:

> I have a page:
>
> ==section 1==
>
> ==section 2==
> footnote
>
> ==section 3==
>
> ==references==
>
>
> the footnote is given in section 2.
> after editing a whole page footnote reference is auto inserted at page
> bottom.. i.e. ==references== here.
> this is what i want.
>
> but when i edit the section 2 only (not whole page), the footnote is
> inserted at the bottom of section 2 itself instead of the bottom of whole
> page (==references==).
>
> what can i do to avoid this? currently, i need to delete the footnote
> reference manually everytime i edit the section 2.
>
>
>
> --
> View this message in context: http://xwiki.475771.n2.nabble.
> com/location-of-footnotes-tp7603329.html
> Sent from the XWiki- Users mailing list archive at Nabble.com.
>

Re: [xwiki-users] [UX] Administration Improvements

[Ecaterina Moraru (Valica)]

Hi all,

For the record, Marius Florea and me proposed some improvements for
Administration, see
http://design.xwiki.org/xwiki/bin/view/Proposal/Administration9x

There are many topics that can be targeted in Administration and they are
considered for future proposals (like Rights, Templates improvements, etc.)
since they are more complex to tackle. We focused now on prioritizing
often-used sections and improving the hints / values and make the styling
more consistent.

Feedback is welcomed.

Thanks,
Caty

On Thu, Feb 23, 2017 at 2:05 PM, Ecaterina Moraru (Valica) <
vali...@gmail.com> wrote:

> Hi Denis,
>
> Thanks for your feedback.
>
> On Thu, Feb 23, 2017 at 1:38 PM, Denis GERMAIN <dt.germ...@gmail.com>
> wrote:
>
>> We are running multiple flavors of Xwiki including 7.4.4 (production),
>> 8.4.4 and 9.0
>>
>> 1. what sections are always needed and maybe we could prioritize them;
>> Users and Groups are the most heavily used menu in administration for us
>> We also rely heavily on Import/Exports
>>
>> 2. what sections could be grouped together, since they are related;
>>
>> 3. what sections are not relevant and could be removed (maybe because they
>> are too technical, or not needed or rarely used);
>> Creating subwikis is sometime used so it shouldn't be dropped (for us)
>> Templates are not often used but really important to us
>>
>> 4. if there are important recurring things missing from administration;
>> There is no easy way to troubleshoot users rights on a page. In other
>> words, sometime users set rights on "pages and children" OR "pages", and
>> it
>> causes all sort of trouble
>> - some users can't see some pages but they should (due to misconfiugration
>> of the rights)
>> - some users can open pages with the direct link but can't navigate to it
>> a) I don't see why there is 2 types of rights on a page, I would
>> personnaly
>> keep only "pages and children" rights and drop "page only" rights
>>
>
> This is when you need to make exceptions: you want all the children to
> behave in a certain way, but the parent or a certain subpage to have
> different rights. I agree it's a more marginal use case, but still it could
> happen.
>
>
>> b) To troubleshoot, I'd like to have a way to see why some users can see
>> the page and some don't, or to help me find where the problem is
>>
>
> I agree the rights inheritance is problematic and yes we should improve it
> (in terms of setting it and display the applied rules). This functionality
> gets outside of the scope of this Administration
> reorganization/simplification, but it's indeed very important (and
> apparently a common problem).
>
>
>>
>> 5. other ideas?
>> I find the Template creation (with provider) procedure counter intuitive.
>> Maybe it could be simplified ?
>>
>
> We added some new functionality in terms of visibility and creation
> restrictions for templates, but they were intended more as powerful
> features, we didn't focus on simplifying the process. Yes, we could do some
> improvements there too, especially since we have started promoting
> Templates more.
>
> Thank you so much,
> Caty
>
>
>> 2017-02-23 11:28 GMT+01:00 Ecaterina Moraru (Valica) <vali...@gmail.com>:
>>
>> > Thanks Stéphane for your answer. It's very helpful.
>> >
>> > Caty
>> >
>> > On Thu, Feb 23, 2017 at 12:15 PM, Stéphane LASSIRE <
>> slass...@cesap.asso.fr
>> > >
>> > wrote:
>> >
>> > > Hello,
>> > >
>> > > What a nice idea.
>> > > We are using a Xwiki 7.4.4 release.
>> > >
>> > > 1. what sections are always needed and maybe we could prioritize them;
>> > > -> Users / groups / right access / extensions / statistics
>> > >
>> > > 2. what sections could be grouped together, since they are related;
>> > > -> Configuration / Look / Email
>> > >
>> > > 3. what sections are not relevant and could be removed (maybe because
>> > they
>> > > are too technical, or not needed or rarely used);
>> > > -> wikis (we are using only 1 instance, so no need of multi configs
>> for
>> > us)
>> > >
>> > > 4. if there are important recurring things missing from
>> administration;
>> > > -> rights "inspector", not really to know the right of a page inside a
>> > > space
>> > > for all users and groups
>> > > -> activity of a group / user. I try t

Re: [xwiki-users] [UX] Administration Improvements

[Ecaterina Moraru (Valica)]

Hi Denis,

Thanks for your feedback.

On Thu, Feb 23, 2017 at 1:38 PM, Denis GERMAIN <dt.germ...@gmail.com> wrote:

> We are running multiple flavors of Xwiki including 7.4.4 (production),
> 8.4.4 and 9.0
>
> 1. what sections are always needed and maybe we could prioritize them;
> Users and Groups are the most heavily used menu in administration for us
> We also rely heavily on Import/Exports
>
> 2. what sections could be grouped together, since they are related;
>
> 3. what sections are not relevant and could be removed (maybe because they
> are too technical, or not needed or rarely used);
> Creating subwikis is sometime used so it shouldn't be dropped (for us)
> Templates are not often used but really important to us
>
> 4. if there are important recurring things missing from administration;
> There is no easy way to troubleshoot users rights on a page. In other
> words, sometime users set rights on "pages and children" OR "pages", and it
> causes all sort of trouble
> - some users can't see some pages but they should (due to misconfiugration
> of the rights)
> - some users can open pages with the direct link but can't navigate to it
> a) I don't see why there is 2 types of rights on a page, I would personnaly
> keep only "pages and children" rights and drop "page only" rights
>

This is when you need to make exceptions: you want all the children to
behave in a certain way, but the parent or a certain subpage to have
different rights. I agree it's a more marginal use case, but still it could
happen.


> b) To troubleshoot, I'd like to have a way to see why some users can see
> the page and some don't, or to help me find where the problem is
>

I agree the rights inheritance is problematic and yes we should improve it
(in terms of setting it and display the applied rules). This functionality
gets outside of the scope of this Administration
reorganization/simplification, but it's indeed very important (and
apparently a common problem).


>
> 5. other ideas?
> I find the Template creation (with provider) procedure counter intuitive.
> Maybe it could be simplified ?
>

We added some new functionality in terms of visibility and creation
restrictions for templates, but they were intended more as powerful
features, we didn't focus on simplifying the process. Yes, we could do some
improvements there too, especially since we have started promoting
Templates more.

Thank you so much,
Caty


> 2017-02-23 11:28 GMT+01:00 Ecaterina Moraru (Valica) <vali...@gmail.com>:
>
> > Thanks Stéphane for your answer. It's very helpful.
> >
> > Caty
> >
> > On Thu, Feb 23, 2017 at 12:15 PM, Stéphane LASSIRE <
> slass...@cesap.asso.fr
> > >
> > wrote:
> >
> > > Hello,
> > >
> > > What a nice idea.
> > > We are using a Xwiki 7.4.4 release.
> > >
> > > 1. what sections are always needed and maybe we could prioritize them;
> > > -> Users / groups / right access / extensions / statistics
> > >
> > > 2. what sections could be grouped together, since they are related;
> > > -> Configuration / Look / Email
> > >
> > > 3. what sections are not relevant and could be removed (maybe because
> > they
> > > are too technical, or not needed or rarely used);
> > > -> wikis (we are using only 1 instance, so no need of multi configs for
> > us)
> > >
> > > 4. if there are important recurring things missing from administration;
> > > -> rights "inspector", not really to know the right of a page inside a
> > > space
> > > for all users and groups
> > > -> activity of a group / user. I try to put a counter inside pages to
> see
> > > if
> > > it is accessed but it a basic solution. I would like to see how much
> some
> > > pages are viewed. The statistics are limited on this part
> > >
> > > 5. other ideas?
> > > -> see 4
> > >
> > > Thanks
> > >
> > > Cordialement
> > >
> > > Stéphane Lassire
> > > Chargé de l'informatique et de la communication
> > > Courriel : slass...@cesap.asso.fr
> > >
> > > -Message d'origine-
> > > De : users [mailto:users-boun...@xwiki.org] De la part de Ecaterina
> > Moraru
> > > (Valica)
> > > Envoyé : mardi 21 février 2017 16:15
> > > À : XWiki Mailinglist; XWiki Mailinglist
> > > Objet : [xwiki-users] [UX] Administration Improvements
> > >
> > > Hi,
> > >
> > > We are thinking about improving the Administration, so would be great
> to
> > > hear your opinion about:
> > > 1. what sections are always needed and maybe we could prioritize them;
> 2.
> > > what sections could be grouped together, since they are related; 3.
> what
> > > sections are not relevant and could be removed (maybe because they are
> > too
> > > technical, or not needed or rarely used); 4. if there are important
> > > recurring things missing from administration; 5. other ideas?
> > >
> > > We are particularly interested in 1. and that is sections that are used
> > > often and would love to know which are those (since they differ so much
> > > depending on usage).
> > >
> > > Let us know,
> > > Caty
> > >
> >
>

Re: [xwiki-users] [UX] Administration Improvements

[Ecaterina Moraru (Valica)]

Thanks Stéphane for your answer. It's very helpful.

Caty

On Thu, Feb 23, 2017 at 12:15 PM, Stéphane LASSIRE <slass...@cesap.asso.fr>
wrote:

> Hello,
>
> What a nice idea.
> We are using a Xwiki 7.4.4 release.
>
> 1. what sections are always needed and maybe we could prioritize them;
> -> Users / groups / right access / extensions / statistics
>
> 2. what sections could be grouped together, since they are related;
> -> Configuration / Look / Email
>
> 3. what sections are not relevant and could be removed (maybe because they
> are too technical, or not needed or rarely used);
> -> wikis (we are using only 1 instance, so no need of multi configs for us)
>
> 4. if there are important recurring things missing from administration;
> -> rights "inspector", not really to know the right of a page inside a
> space
> for all users and groups
> -> activity of a group / user. I try to put a counter inside pages to see
> if
> it is accessed but it a basic solution. I would like to see how much some
> pages are viewed. The statistics are limited on this part
>
> 5. other ideas?
> -> see 4
>
> Thanks
>
> Cordialement
>
> Stéphane Lassire
> Chargé de l'informatique et de la communication
> Courriel : slass...@cesap.asso.fr
>
> -Message d'origine-
> De : users [mailto:users-boun...@xwiki.org] De la part de Ecaterina Moraru
> (Valica)
> Envoyé : mardi 21 février 2017 16:15
> À : XWiki Mailinglist; XWiki Mailinglist
> Objet : [xwiki-users] [UX] Administration Improvements
>
> Hi,
>
> We are thinking about improving the Administration, so would be great to
> hear your opinion about:
> 1. what sections are always needed and maybe we could prioritize them; 2.
> what sections could be grouped together, since they are related; 3. what
> sections are not relevant and could be removed (maybe because they are too
> technical, or not needed or rarely used); 4. if there are important
> recurring things missing from administration; 5. other ideas?
>
> We are particularly interested in 1. and that is sections that are used
> often and would love to know which are those (since they differ so much
> depending on usage).
>
> Let us know,
> Caty
>

[xwiki-users] [UX] Administration Improvements

[Ecaterina Moraru (Valica)]

Hi,

We are thinking about improving the Administration, so would be great to
hear your opinion about:
1. what sections are always needed and maybe we could prioritize them;
2. what sections could be grouped together, since they are related;
3. what sections are not relevant and could be removed (maybe because they
are too technical, or not needed or rarely used);
4. if there are important recurring things missing from administration;
5. other ideas?

We are particularly interested in 1. and that is sections that are used
often and would love to know which are those (since they differ so much
depending on usage).

Let us know,
Caty

[xwiki-users] [ANN] XWiki 7.4.6 released

[Ecaterina Moraru (Valica)]

The XWiki development team is proud to announce the availability of XWiki
7.4.6.
This is a bugfix release that fixes important bugs discovered in the 7.4.5
version. This release is the last release for the 7.x cycle, since the 7.4
branch reached end of life on January 2017.

You can download it using these links:
JAR:
http://download.forge.ow2.org/xwiki/xwiki-enterprise-installer-generic-7.4.6-standard.jar

EXE:
http://download.forge.ow2.org/xwiki/xwiki-enterprise-installer-windows-7.4.6.exe

ZIP:
http://download.forge.ow2.org/xwiki/xwiki-enterprise-jetty-hsqldb-7.4.6.zip

WAR:
http://download.forge.ow2.org/xwiki/xwiki-enterprise-web-7.4.6.war

XAR:
http://download.forge.ow2.org/xwiki/xwiki-enterprise-ui-mainwiki-all-7.4.6.xar

Make sure to review the release notes:
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/7.4.6/

Thanks for your support
-The XWiki dev team

Re: [xwiki-users] List with Checkboxes

[Ecaterina Moraru (Valica)]

There was this extension that worked (haven't tested on latest versions)
http://extensions.xwiki.org/xwiki/bin/view/Extension/TodoList+Application+using+emberjs

Thanks,
Caty

On Thu, Jan 26, 2017 at 6:51 AM, Jesse Bright 
wrote:

> I am making a several lists with tasks and associated checkboxes. The
> checkbox data will not be stored or used in any way. It's only purpose is
> as a reminder of tasks which have been completed.
>
> My best idea for achieving this is to write a wiki macro using the HTML
> macro to insert a checkbox input. However this means I have to develop list
> tabbing behavior and write my macro reference repeatedly in each list space.
>
> Does any one know of a better or easier way to create a checkbox list?
>
> Regards,
>
> Jesse
>
>

Re: [xwiki-users] [xwiki-devs] [Brainstorming] XWiki stickers

[Ecaterina Moraru (Valica)]

FTR, we've iterated with George (who did most of the work) and proposed
A.4.1-3, for the Standard category.

We are still waiting for proposals for the other categories, especially if
you have ideas about messages suited to explain/promote XWiki.

Thanks,
Caty

On Mon, Jan 9, 2017 at 4:08 PM, Ecaterina Moraru (Valica) <vali...@gmail.com
> wrote:

> We are starting to gather some proposals there.
>
> We have 3 proposals for Standard category (A); 2 for Event category (B)
> and 12 for Original category (C).
>
> I personally like A.1 and maybe have A.3 in the same style as A.1 (but
> have the original logo). A.1 should just keep the url, since "Just us on"
> would be hard to read.
>
> Thanks,
> Caty
>
> On Sun, Jan 8, 2017 at 10:21 AM, Ludovic Dubost <ludo...@xwiki.com> wrote:
>
>> Le 8 janv. 2017 02:15, "Eduard Moraru" <enygma2...@gmail.com> a écrit :
>>
>> I`ve added your attachments to the list of previews. They look a bit odd
>> (smaller, with some extra padding) as SVGs, but the browser seems to be
>> able to handle them now.
>>
>>
>> I made then with inkscape on mac. I found the initial svg that I loaded
>> not
>> looking exactly as the PNG so there must be some compatibility issue
>>
>> Ludo
>>
>>
>>
>>
>> Let`s see some more, including in the "Messages" section. We should have a
>> preview of how those stickers would look like. Will probably add one
>> around
>> Monday.
>>
>> Thanks,
>> Eduard
>>
>> On Sun, Jan 8, 2017 at 1:31 AM, Ludovic Dubost <ludo...@xwiki.com> wrote:
>>
>> > Hi Edy,
>> >
>> > Great initiative ! I've put some ideas as SVGs attachment to the page
>> >
>> > http://design.xwiki.org/xwiki/bin/view/Proposal/XWikiSticker
>> s#Attachments
>> >
>> > Ludovic
>> >
>> >
>> > --
>> > *Ludovic Dubost*
>> > *Founder and CEO*
>> > ludo...@xwiki.com
>> > skype: ldubost
>> > Blog: http://blog.ludovic.org
>> >
>> > On Sat, Jan 7, 2017 at 6:24 PM, Eduard Moraru <enygma2...@gmail.com>
>> > wrote:
>> >
>> > > Hello, fellow XWiki community members,
>> > >
>> > > Since XWiki will be participating at this year's FOSDEM (
>> www.fosdem.org)
>> > > open source meeting in Brussels and since we never did spend some time
>> to
>> > > think about XWiki sticker that would help promote our community, we
>> > invite
>> > > everybody to chip in with *ideas on how XWiki stickers should look
>> like*.
>> > >
>> > > We would like to focus on *thumb-sized* (vertical/badge; horizontal
>> with
>> > > text) stickers in a couple of formats:
>> > > 1) X logo + "xwiki.org" under (standard XWiki sticker)
>> > > 2) Horizontal message/quote + "xwiki.org" under it (get creative on
>> the
>> > > messages)
>> > > 3) FOSDEM or other open source event flavored sticker (we have one
>> idea,
>> > > others are welcomed)
>> > > 4) Anything text/graphic XWiki-related (or about open source, wikis,
>> > etc.),
>> > > within the size restrictions, for the more talented/creative ones out
>> > there
>> > > :)
>> > >
>> > > Other inspiration and resources:
>> > > http://www.unixstickers.com/stickers
>> > > http://design.xwiki.org/xwiki/bin/view/Standards/ColorsLogo
>> > > https://www.xwiki.org/xwiki/bin/view/Main/Media
>> > > https://www.xwiki.org/xwiki/bin/view/Main/Logo
>> > >
>> > > Please use this wiki page to share your ideas or designs (or even
>> reply
>> > to
>> > > this mail, but the wiki page would be nicer :) ):
>> > > http://design.xwiki.org/xwiki/bin/view/Proposal/XWikiStickers
>> > >
>> > > The deadline is *end of Wednesday, 11th January, 2016*. You can
>> continue
>> > > contributing after this date as well, since ideas are always welcomed,
>> > but
>> > > they will probably be printed for future events.
>> > >
>> > > It`s a short notice, but FOSDEM is close and we can do more
>> brainstorming
>> > > rounds in the future as well.
>> > >
>> > > XWiki SAS is going to handle the printing of the logos around the end
>> of
>> > > this week or next week.
>> > >
>> > > We will come back with the results and you can come to FOSDEM at
>> XWiki's
>> > > booth to talk to us and grab some stickers to enjoy and share yourself
>> ;)
>> > >
>> > > The plan is to eventually create a stickers page on xwiki.org where
>> > > everybody can download and print XWiki stickers themselves. It should
>> > > include both generally approved XWiki stickers but also community made
>> > > ones.
>> > >
>> > > Looking forward to your ideas,
>> > >
>> > > Thanks,
>> > > Eduard
>> > >
>> >
>>
>
>

Re: [xwiki-users] [xwiki-devs] [Brainstorming] XWiki stickers

[Ecaterina Moraru (Valica)]

We are starting to gather some proposals there.

We have 3 proposals for Standard category (A); 2 for Event category (B) and
12 for Original category (C).

I personally like A.1 and maybe have A.3 in the same style as A.1 (but have
the original logo). A.1 should just keep the url, since "Just us on" would
be hard to read.

Thanks,
Caty

On Sun, Jan 8, 2017 at 10:21 AM, Ludovic Dubost  wrote:

> Le 8 janv. 2017 02:15, "Eduard Moraru"  a écrit :
>
> I`ve added your attachments to the list of previews. They look a bit odd
> (smaller, with some extra padding) as SVGs, but the browser seems to be
> able to handle them now.
>
>
> I made then with inkscape on mac. I found the initial svg that I loaded not
> looking exactly as the PNG so there must be some compatibility issue
>
> Ludo
>
>
>
>
> Let`s see some more, including in the "Messages" section. We should have a
> preview of how those stickers would look like. Will probably add one around
> Monday.
>
> Thanks,
> Eduard
>
> On Sun, Jan 8, 2017 at 1:31 AM, Ludovic Dubost  wrote:
>
> > Hi Edy,
> >
> > Great initiative ! I've put some ideas as SVGs attachment to the page
> >
> > http://design.xwiki.org/xwiki/bin/view/Proposal/
> XWikiStickers#Attachments
> >
> > Ludovic
> >
> >
> > --
> > *Ludovic Dubost*
> > *Founder and CEO*
> > ludo...@xwiki.com
> > skype: ldubost
> > Blog: http://blog.ludovic.org
> >
> > On Sat, Jan 7, 2017 at 6:24 PM, Eduard Moraru 
> > wrote:
> >
> > > Hello, fellow XWiki community members,
> > >
> > > Since XWiki will be participating at this year's FOSDEM (
> www.fosdem.org)
> > > open source meeting in Brussels and since we never did spend some time
> to
> > > think about XWiki sticker that would help promote our community, we
> > invite
> > > everybody to chip in with *ideas on how XWiki stickers should look
> like*.
> > >
> > > We would like to focus on *thumb-sized* (vertical/badge; horizontal
> with
> > > text) stickers in a couple of formats:
> > > 1) X logo + "xwiki.org" under (standard XWiki sticker)
> > > 2) Horizontal message/quote + "xwiki.org" under it (get creative on
> the
> > > messages)
> > > 3) FOSDEM or other open source event flavored sticker (we have one
> idea,
> > > others are welcomed)
> > > 4) Anything text/graphic XWiki-related (or about open source, wikis,
> > etc.),
> > > within the size restrictions, for the more talented/creative ones out
> > there
> > > :)
> > >
> > > Other inspiration and resources:
> > > http://www.unixstickers.com/stickers
> > > http://design.xwiki.org/xwiki/bin/view/Standards/ColorsLogo
> > > https://www.xwiki.org/xwiki/bin/view/Main/Media
> > > https://www.xwiki.org/xwiki/bin/view/Main/Logo
> > >
> > > Please use this wiki page to share your ideas or designs (or even reply
> > to
> > > this mail, but the wiki page would be nicer :) ):
> > > http://design.xwiki.org/xwiki/bin/view/Proposal/XWikiStickers
> > >
> > > The deadline is *end of Wednesday, 11th January, 2016*. You can
> continue
> > > contributing after this date as well, since ideas are always welcomed,
> > but
> > > they will probably be printed for future events.
> > >
> > > It`s a short notice, but FOSDEM is close and we can do more
> brainstorming
> > > rounds in the future as well.
> > >
> > > XWiki SAS is going to handle the printing of the logos around the end
> of
> > > this week or next week.
> > >
> > > We will come back with the results and you can come to FOSDEM at
> XWiki's
> > > booth to talk to us and grab some stickers to enjoy and share yourself
> ;)
> > >
> > > The plan is to eventually create a stickers page on xwiki.org where
> > > everybody can download and print XWiki stickers themselves. It should
> > > include both generally approved XWiki stickers but also community made
> > > ones.
> > >
> > > Looking forward to your ideas,
> > >
> > > Thanks,
> > > Eduard
> > >
> >
>

Re: [xwiki-users] Lots of questions and issues

[Ecaterina Moraru (Valica)]

Hi Mario,

So each problem should be reported as an individual issue in the
appropriate component.

You should first check if there are not already opened issues with that
particular problem (use the search with keywords). For example, these are
the issues related to PDF Export
http://jira.xwiki.org/issues/?jql=project%20%3D%20XWIKI%20AND%20component%20%3D%20%22Old%20Core%20-%20PDF%20export%22%20AND%20status%20%3D%20Open%20ORDER%20BY%20priority%20DESC

Regarding questions, it's the same: each topic should have a separate mail
thread. This way we can assure we stay on subject and the mail can be
referenced to other users, in case they have the same questions.

The only problem is the quantity of questions you ask and the availability
of the committers and contributors to answer them, since this is a
community support. Sometimes it can take a while, especially if there are
complicated aspects.

Thanks,
Caty

On Thu, Jan 5, 2017 at 8:47 PM, Hofstätter Mario <
mario.hofstaet...@automationx.com> wrote:

> Dear devs,
>
> over the past few months we have moved over to using xwiki as a
> replacement for your old sharepoint and mediawiki servers. Meanwhile we
> have accumulated a list of problems and questions we are unable to solve.
> Some of which open JIRA bugs might already exist.
>
> In my opinion this mailinglist is not suitable for this many questions
> (needs attachments, screenshots). How may we proceed? Should we create a
> jira entry for every issue?
>
> An extract of some problems (now running 8.4.3):
> - PDF Export: The pdf misses some elements of the page, for example
> display of info/warn/error marcros (see your sandbox page info and warning
> macro examples) and other stuff. Layout has big issues (images cut off,
> Tables cut off)
> - Multipage PDF Export: Pdf export collection extension is broken,
> MultipagePdfExport Space Export extension too.
> - No image lightbox by default, unclear how to implement it in the wysiwyg
> editor
> - Document tree is really cumbersome for normal users (we use currently
> use some velocity to show children), new children macro insufficient (shows
> translations and attachment)
> - DocumentTree Macro "finder" does not work correctly (finds only some
> pages?)
>
> As for just "questions", should be ask each one of them in an separate
> mail here on the list?
>
> Thank you very much,
> Mario
>

[xwiki-users] [ANN] XWiki 8.4.3 released

[Ecaterina Moraru (Valica)]

The XWiki development team is proud to announce the availability of XWiki
8.4.3.
This release is a bugfix release that brings usability improvements to the
Drawer, Wiki Index and Template Providers.

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.3/

Thanks for your support
-The XWiki dev team

Re: [xwiki-users] [UX][Proposal] Administration Overview

[Ecaterina Moraru (Valica)]

http://design.xwiki.org/xwiki/bin/view/Proposal/AdministrationOverview

On Fri, Dec 9, 2016 at 6:04 PM, Ecaterina Moraru (Valica) <vali...@gmail.com
> wrote:

> Hi,
>
> This is a idea proposal for an Administration Overview that:
> A. Provides generic/global information about the instance like 'version',
> 'instance id', etc.
> B. Provides a summary of usage listing count of major entities (wikis,
> users, pages, extensions, etc.)
> C. Lists demo content installed in the wiki
> D. Provides a way for administrators to subscribe to the XWiki Community
>
> I'm curios which of the above section sounds interesting to you and would
> like to see inside the product. Also maybe you have other ideas of what is
> missing or could be represented better.
>
> Thanks,
> Caty
>

[xwiki-users] [UX][Proposal] Administration Overview

[Ecaterina Moraru (Valica)]

Hi,

This is a idea proposal for an Administration Overview that:
A. Provides generic/global information about the instance like 'version',
'instance id', etc.
B. Provides a summary of usage listing count of major entities (wikis,
users, pages, extensions, etc.)
C. Lists demo content installed in the wiki
D. Provides a way for administrators to subscribe to the XWiki Community

I'm curios which of the above section sounds interesting to you and would
like to see inside the product. Also maybe you have other ideas of what is
missing or could be represented better.

Thanks,
Caty

Re: [xwiki-users] [ANN] XWiki 8.2.2 released

[Ecaterina Moraru (Valica)]

You can download using this link:
http://www.xwiki.org/xwiki/bin/view/Download/DownloadVersion/?projectVersion=8.2.2

Thanks,
Caty

On Tue, Nov 29, 2016 at 2:23 PM, Mario 
wrote:

> The downloadlink has not been updated yet?
>
> BR
>
>
>
> --
> View this message in context: http://xwiki.475771.n2.nabble.
> com/ANN-XWiki-8-2-2-released-tp7601945p7601963.html
> Sent from the XWiki- Users mailing list archive at Nabble.com.
>

Re: [xwiki-users] [VOTE] Drawer reorganisation

[Ecaterina Moraru (Valica)]

Hi,

Thanks to everyone who voted.

Results as of 28 Nov can be seen here
http://jira.xwiki.org/secure/attachment/33281/28NovResults.png

Point III is still ambiguous.

We will discuss the final selection and implementation in
http://jira.xwiki.org/browse/XWIKI-13070

Thanks again,
Caty

On Wed, Nov 23, 2016 at 8:07 PM, Ecaterina Moraru (Valica) <
vali...@gmail.com> wrote:

> 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/Choice1.png
>
> II. Index Wording: With (A) ["User Index"] vs. Without 'Index' (B)
> ["Users"]
> See: http://design.xwiki.org/xwiki/bin/download/Proposal/
> DrawerImprovement/ChoiceWording.png
>
> III. Main Wiki Wording: "Global" (A) vs. "Main Wiki" (B) vs. "Home" (C)
> See: http://design.xwiki.org/xwiki/bin/download/Proposal/
> DrawerImprovement/ChoiceSeparation2.png
>
> IV. Log-out Icon: Without (A) vs. With (B)
> See: http://design.xwiki.org/xwiki/bin/download/Proposal/
> DrawerImprovement/ChoiceLogoutIcon.png
>
> 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/ChoiceLogoutPosition.png
>
> VI. Administration Wording: "Administer wiki" (A) vs. "Administration" (B)
> vs. "Wiki Settings" (C)
> See: http://design.xwiki.org/xwiki/bin/download/Proposal/
> DrawerImprovement/ChoiceAdministration.png
>
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

[xwiki-users] [VOTE] Drawer reorganisation

[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/Choice1.png

II. Index Wording: With (A) ["User Index"] vs. Without 'Index' (B) ["Users"]
See:
http://design.xwiki.org/xwiki/bin/download/Proposal/DrawerImprovement/ChoiceWording.png

III. Main Wiki Wording: "Global" (A) vs. "Main Wiki" (B) vs. "Home" (C)
See:
http://design.xwiki.org/xwiki/bin/download/Proposal/DrawerImprovement/ChoiceSeparation2.png

IV. Log-out Icon: Without (A) vs. With (B)
See:
http://design.xwiki.org/xwiki/bin/download/Proposal/DrawerImprovement/ChoiceLogoutIcon.png

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/ChoiceLogoutPosition.png

VI. Administration Wording: "Administer wiki" (A) vs. "Administration" (B)
vs. "Wiki Settings" (C)
See:
http://design.xwiki.org/xwiki/bin/download/Proposal/DrawerImprovement/ChoiceAdministration.png
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

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

[Ecaterina Moraru (Valica)]

The Navigation additions of P6 are better suited for Wiki Index
application, than the Drawer.

So from what we currently have P5 looks like the better candidate (if
nobody else has any other suggestions) (and because of its focus on local
actions), but we need to fix the naming inconsistencies.

Thanks,
Caty

On Wed, Oct 26, 2016 at 4:34 PM, Ecaterina Moraru (Valica) <
vali...@gmail.com> wrote:

> P6: http://jira.xwiki.org/secure/attachment/33161/P6.png
>
> On Wed, Oct 26, 2016 at 4:33 PM, Ecaterina Moraru (Valica) <
> vali...@gmail.com> wrote:
>
>> 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
>&

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

[Ecaterina Moraru (Valica)]

P6: http://jira.xwiki.org/secure/attachment/33161/P6.png

On Wed, Oct 26, 2016 at 4:33 PM, Ecaterina Moraru (Valica) <
vali...@gmail.com> wrote:

> 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

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

[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 

Re: [xwiki-users] checklist creation and use

[Ecaterina Moraru (Valica)]

Also this is interesting
http://extensions.xwiki.org/xwiki/bin/view/Extension/TodoList+Application+using+emberjs
but it's an older extension.

Thanks,
Caty

On Tue, Oct 11, 2016 at 2:28 PM, Vincent Massol  wrote:

> Hi,
>
> > On 10 Oct 2016, at 20:16, shouldbe q931  wrote:
> >
> > Hi,
> >
> > Long time user, very infrequent poster...
> >
> > I'm looking for something for users of our xwiki to create checklists
> > as something akin to a template, and then use the created checklist
> > template, saving the completed checklist as a page.
> >
> > Any suggestions would be welcomed.
>
> I think Templates is what you’re asking for, see
> http://extensions.xwiki.org/xwiki/bin/view/Extension/
> Administration+Application#HTemplates
>
> Thanks
> -Vincent
>
> >
> > Cheers
> ___
> users mailing list
> users@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
>
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

[xwiki-users] [ANN] XWiki 8.3 released

[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
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] Flamingo color theme advanced Less

[Ecaterina Moraru (Valica)]

An alternative to Solution 1, step 2 (ovewriting the "less/style.less.vm")
you could try this:

Solution B:
1. In your skin, add the "less/advanced.less", as in
http://design.xwiki.org/xwiki/bin/download/Proposal/ColorThemeforFlamingo/Advanced_step1.png
2. in your Flamingo Theme, add a SSX object, with Content Type: LESS (if
you need velocity, you can make it parsable + I've made it global for the
whole wiki, but you can manually call it) and write
"@import("advanced.less");". Apparently the LESS compiler is looking only
on files that are in the flamingo/less file system folder. So that's all
you need to write, see
http://design.xwiki.org/xwiki/bin/download/Proposal/ColorThemeforFlamingo/Advanced_step2B.png

So besides this "less/advanced.less" you can break your code in as many
file as you need.

Hope this helps,
Caty

On Mon, Sep 26, 2016 at 5:32 PM, Ecaterina Moraru (Valica) <
vali...@gmail.com> wrote:

> The problem is that we cannot use velocity in the Flamingo Theme's
> advanced section, so we cannot write @import "$xwiki.getSkinFile('
> advanced.less')";
>
> So this means we need to go to the file where all the LESS files get
> imported. This means "less/style.less.vm". There you need to add your
> custom .less file, in our case I've called it "advanced.less", do it by
> writing '@import "advanced";' at the end of the import list. Now be
> careful, since you are overwriting this file, if you are going to make an
> upgrade, you need to backport the official changes of this file to your
> custom skin.
>
> Now you need to add the advanced.less file to your skin. Add it in the
> overrides section, having the /less folder prefix, since there we expect
> all LESS files to be present.
>
> In order to be easier to follow I've created a screenshot of a very small
> change I've made (the body text should be colored blue), see
> http://design.xwiki.org/xwiki/bin/download/Proposal/ColorThemeforFlamingo/
> advancedLess.png
>
> So in conclusion you need to add 2 overrides to your skin (I've made my
> changes to XWiki.DefaultSkin in order to test), for "less/advanced.less"
> (where you will have your code) and "less/style.less.vm" (where you need to
> copy the standard content of that file from the flamingo folder in your
> file system + add the import to your custom less). The changes you will
> have in advanced.less will be applied globally to your skin, independent of
> the current Flamingo Theme.
>
> Hope this helps,
> Caty
>
>
> On Mon, Sep 26, 2016 at 5:00 PM, Gerritjan Koekkoek <
> gerrit...@cdlsworld.org> wrote:
>
>> What would be the notation in the advanced box
>>
>>
>> I now have:
>>
>> @import('custom.less')
>>
>>
>> And I added custom.less as attachment to my skin-page.
>>
>>
>> But this gives me a compile error on the less...
>>
>>
>> Gerritjan Koekkoek
>> Vader van Rai Koekkoek (cdls) en voorzitter vereniging CdLS
>> Visit our website<http://www.cdlsworld.org>
>> Facebook<https://www.facebook.com/gerritjan.koekkoek>
>> email<gerrit...@cdlsworld.org>
>>
>>
>>
>> 
>> From: users <users-boun...@xwiki.org> on behalf of Ecaterina Moraru
>> (Valica) <vali...@gmail.com>
>> Sent: 26 September 2016 15:08:51
>> To: XWiki Users
>> Subject: Re: [xwiki-users] Flamingo color theme advanced Less
>>
>> You could attach your less files to the Skin page, especially since if you
>> have advanced / big customizations is more the responsibility of the skin,
>> rather than the color theme.
>>
>> Thanks,
>> Caty
>>
>> On Mon, Sep 26, 2016 at 3:35 PM, Gerritjan Koekkoek <
>> gerrit...@cdlsworld.org
>> > wrote:
>>
>> > Our Advanced box in the flamingo color theme is getting pretty Big (But
>> it
>> > works !)
>> >
>> >
>> > But would it be possible to attach less files to the color theme page
>> and
>> > adding something like
>> >
>> >
>> > @import("waihonabuttons.less") in the advanced box of the color
>> theme?
>> >
>> >
>> > What would I need in the  part of the filename?
>> >
>> >
>> > Gerritjan Koekkoek
>> > Vader van Rai Koekkoek (cdls) en voorzitter vereniging CdLS
>> > Visit our website<http://www.cdlsworld.org>
>> > Facebook<https://www.facebook.com/gerritjan.koekkoek>
>> > email<gerrit...@cdlsworld.org>
>> >
>> >
>> >
>> > ___
>> > users mailing list
>> > users@xwiki.org
>> > http://lists.xwiki.org/mailman/listinfo/users
>> >
>> ___
>> users mailing list
>> users@xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/users
>> ___
>> users mailing list
>> users@xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/users
>>
>
>
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] Flamingo color theme advanced Less

[Ecaterina Moraru (Valica)]

The problem is that we cannot use velocity in the Flamingo Theme's advanced
section, so we cannot write @import "$xwiki.getSkinFile('advanced.less')";

So this means we need to go to the file where all the LESS files get
imported. This means "less/style.less.vm". There you need to add your
custom .less file, in our case I've called it "advanced.less", do it by
writing '@import "advanced";' at the end of the import list. Now be
careful, since you are overwriting this file, if you are going to make an
upgrade, you need to backport the official changes of this file to your
custom skin.

Now you need to add the advanced.less file to your skin. Add it in the
overrides section, having the /less folder prefix, since there we expect
all LESS files to be present.

In order to be easier to follow I've created a screenshot of a very small
change I've made (the body text should be colored blue), see
http://design.xwiki.org/xwiki/bin/download/Proposal/ColorThemeforFlamingo/advancedLess.png

So in conclusion you need to add 2 overrides to your skin (I've made my
changes to XWiki.DefaultSkin in order to test), for "less/advanced.less"
(where you will have your code) and "less/style.less.vm" (where you need to
copy the standard content of that file from the flamingo folder in your
file system + add the import to your custom less). The changes you will
have in advanced.less will be applied globally to your skin, independent of
the current Flamingo Theme.

Hope this helps,
Caty


On Mon, Sep 26, 2016 at 5:00 PM, Gerritjan Koekkoek <gerrit...@cdlsworld.org
> wrote:

> What would be the notation in the advanced box
>
>
> I now have:
>
> @import('custom.less')
>
>
> And I added custom.less as attachment to my skin-page.
>
>
> But this gives me a compile error on the less...
>
>
> Gerritjan Koekkoek
> Vader van Rai Koekkoek (cdls) en voorzitter vereniging CdLS
> Visit our website<http://www.cdlsworld.org>
> Facebook<https://www.facebook.com/gerritjan.koekkoek>
> email<gerrit...@cdlsworld.org>
>
>
>
> 
> From: users <users-boun...@xwiki.org> on behalf of Ecaterina Moraru
> (Valica) <vali...@gmail.com>
> Sent: 26 September 2016 15:08:51
> To: XWiki Users
> Subject: Re: [xwiki-users] Flamingo color theme advanced Less
>
> You could attach your less files to the Skin page, especially since if you
> have advanced / big customizations is more the responsibility of the skin,
> rather than the color theme.
>
> Thanks,
> Caty
>
> On Mon, Sep 26, 2016 at 3:35 PM, Gerritjan Koekkoek <
> gerrit...@cdlsworld.org
> > wrote:
>
> > Our Advanced box in the flamingo color theme is getting pretty Big (But
> it
> > works !)
> >
> >
> > But would it be possible to attach less files to the color theme page and
> > adding something like
> >
> >
> > @import("waihonabuttons.less") in the advanced box of the color
> theme?
> >
> >
> > What would I need in the  part of the filename?
> >
> >
> > Gerritjan Koekkoek
> > Vader van Rai Koekkoek (cdls) en voorzitter vereniging CdLS
> > Visit our website<http://www.cdlsworld.org>
> > Facebook<https://www.facebook.com/gerritjan.koekkoek>
> > email<gerrit...@cdlsworld.org>
> >
> >
> >
> > ___
> > users mailing list
> > users@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/users
> >
> ___
> users mailing list
> users@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
> ___
> users mailing list
> users@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
>
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] mobile/tablet support for new templates

[Ecaterina Moraru (Valica)]

Hi,

So yes the template are meant to work on mobile, but as you said the logic
behind the order of sections could be improved.

Regarding how to do it, you could  change the order of the .col-xs-*
containers and then use the '.pull-right' class for the contents section
(to make sure it still looks the same for desktop).

Would you be interested in providing a PR for these changes?
The code is available at
https://github.com/xwiki-contrib/application-templates/tree/master/application-templates-ui/src/main/resources/Templates

Thanks,
Caty

On Wed, Aug 3, 2016 at 6:16 PM, superuser  wrote:

> The new 4 templates in 8.2 are nice. But the view on mobile need to be
> corrected, i think.. e.g. the contents section of encyclopedia template
> should come at top but currently its at bottom when view on small screens.
> I
> dont intend to change the template structure for large/ PC screens (they
> are
> really good), but want to adjust for small screens.
> How can i do that?
> Also any help on 'how to reorganize content view on mobile' is appreciated.
>
>
>
> --
> View this message in context: http://xwiki.475771.n2.nabble.
> com/mobile-tablet-support-for-new-templates-tp7600556.html
> Sent from the XWiki- Users mailing list archive at Nabble.com.
> ___
> users mailing list
> users@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
>
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] Question about panel sizing

[Ecaterina Moraru (Valica)]

Hi,

The width of panels is computed in layout.less.

Thanks,
Caty

On Tue, Aug 16, 2016 at 3:07 PM, Vincent Massol  wrote:

> Hi Rudi,
>
> > On 16 Aug 2016, at 13:58, Rudi Ritosalo  wrote:
> >
> > Hello,
> >
> > I am asking help on the matter of changing the left and right panel size
> of the XWiki i've installed. I'm using a war installed Xwiki 8.1 with a
> flamingo theme. So far from what I've gathered is
> > that usable panel sizes are small, medium and large. What I'm looking
> for is something between small and medium. Is there a .vm or a .css file in
> the WAR package where I can modify
> > the width of the panels manually? Or is there some other way to more
> precisely alter the width of the panels?
>
> I don’t have a precise answer but I’d use your browser dev tools and use
> CSS to find what to override.
>
> Then I’d use an SSX, see http://platform.xwiki.org/
> xwiki/bin/view/DevGuide/SkinExtensionsTutorial
>
> IMO that’s better than changing the default since it’ll allow you to
> upgrade with less problems in the future.
>
> Thanks
> -Vincent
>
> > Thanks in advance,
> >
> > Rudi
>
> ___
> users mailing list
> users@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
>
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] Question regarding changing default format of Numbered Lists

[Ecaterina Moraru (Valica)]

Hi,

The code you wrote should work just fine. Just add it to your custom skin
or to a global SSX.

Thanks,
Caty

On Fri, Aug 5, 2016 at 7:06 PM, rlarkin  wrote:

> Hello-
>
> I am a new user and I have a question regarding changing the default method
> of numbering used for numbered lists. I am attempting to use xwiki to store
> our company policy, which as of now is kept in a series of individual
> documents. The difficulty is that management is insistent that I maintain
> the current numbering schema used for numbered lists which is in the
> format:
>
> A. Item One
>   1. Sub-Item 1
> a. Sub-Sub Item 1
>
> While I can do so manually using the xwiki syntax this is a great deal of
> work when dealing with dozens of lists within hundreds of policies. In
> addition I would like to make it as easy as possible for whomever comes
> after me. I believe that the css code for something like this would be
> something along the lines of:
>
> ol {list-style-type:upper-alpha;}
> ol ol {list-style-type:decimal;}
> ol ol ol {list-style-type:lower-alpha;}
>
> but I am uncertain as to whether this is the proper method of implementing
> this change, and if so am uncertain as to where that code would go. Any
> help
> would be appreciated.
>
>
>
>
> --
> View this message in context: http://xwiki.475771.n2.nabble.
> com/Question-regarding-changing-default-format-of-
> Numbered-Lists-tp7600593.html
> Sent from the XWiki- Users mailing list archive at Nabble.com.
> ___
> users mailing list
> users@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
>
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

[xwiki-users] [ANN] XWiki 8.2.1 released

[Ecaterina Moraru (Valica)]

The XWiki development team is proud to announce the availability of XWiki
8.2.1.
This is a bugfix release that fixes important bugs discovered in the 8.2
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/ReleaseNotesXWiki821/

Thanks for your support
-The XWiki dev team
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

[xwiki-users] [ANN] XWiki 8.2 released

[Ecaterina Moraru (Valica)]

The XWiki development team is proud to announce the availability of XWiki
8.2.
This release integrates CKEditor as the default WYSIWYG content editor. It
also features a redesigned default homepage, a tour on the homepage to
describe the XWiki user interface to newcomers, new default templates, a
new application index in the drawer and a new administration UI to help
manage available syntaxes. There are also minor improvements to the
template providers, the Flamingo skin and Ratings. For developers, we have
Livetable macro improvements and a long overdue change of behavior for the
getRenderedContent() method.

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/ReleaseNotesXWiki82

Thanks for your support
-The XWiki dev team
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] Flamingo color theme mapping on skin div's

[Ecaterina Moraru (Valica)]

@component-active-bg is not applied to any specific XWiki element (since
with a search I see that it appears only in variables.less).
But if you use default Bootstrap elements like navs and dropdowns, that
value will be used. Which inherits brand-primary value, etc.

//** Global background color for active items (e.g., navs or dropdowns).
@component-active-bg:   @brand-primary;

To answer your questions you just need to search for a particular variable
inside the .less files.

Thanks,
Caty

On Tue, Jul 12, 2016 at 4:08 PM, Gerritjan Koekkoek <gerrit...@cdlsworld.org
> wrote:

> Hi,
>
>
> I understand all Less variables are from bootstrap.
>
> I also understand the less files that are linked to a color theme will
> compile a style.css that is loaded on each page
>
> My question is how are they applied to XWiki default skin div's (id's or
> classes)
>
>
> Where is defined:
>
> #xwikimaincontainer will have a number of less variables (or not)
>
>
> In other words: Which XWiki ID's an/or classes use:
>
> @brand-primary
>
>
> And which XWiki ID's and/or classes are considered to get
> @component-active-bg applied ?
>
>
> Gerritjan Koekkoek
> Vader van Rai Koekkoek (cdls) en voorzitter vereniging CdLS
> Visit our website<http://www.cdlsworld.org>
> Facebook<https://www.facebook.com/gerritjan.koekkoek>
> email<gerrit...@cdlsworld.org>
>
>
>
> 
> From: users <users-boun...@xwiki.org> on behalf of Ecaterina Moraru
> (Valica) <vali...@gmail.com>
> Sent: 12 July 2016 10:56:26
> To: XWiki Users
> Subject: Re: [xwiki-users] Flamingo color theme mapping on skin div's
>
> Hi,
>
> @component-active-bg come from Bootstrap.
> You can find about the default variables in variables.less.
>
> The way they were used can be found in the .less files.
>
> Thanks,
> Caty
>
> On Tue, Jul 12, 2016 at 9:38 AM, Gerritjan Koekkoek <
> gerrit...@cdlsworld.org
> > wrote:
>
> > Who has mapped the flamingo-colortheme on the skin-div's?
> >
> > Or is this documented anywhere ?
> >
> >
> > what is default styled with Brand-primary, Brand-success, Brand-info,
> > Brand-warning, Brand-danger
> >
> > what is @Component-active-color and @Component-active-bg
> >
> >
> >
> > Gerritjan Koekkoek
> > Vader van Rai Koekkoek (cdls) en voorzitter vereniging CdLS
> > Visit our website<http://www.cdlsworld.org>
> > Facebook<https://www.facebook.com/gerritjan.koekkoek>
> > email<gerrit...@cdlsworld.org>
> >
> >
> >
> > ___
> > users mailing list
> > users@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/users
> >
> ___
> users mailing list
> users@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
> ___
> users mailing list
> users@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
>
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] Flamingo color theme mapping on skin div's

[Ecaterina Moraru (Valica)]

Hi,

@component-active-bg come from Bootstrap.
You can find about the default variables in variables.less.

The way they were used can be found in the .less files.

Thanks,
Caty

On Tue, Jul 12, 2016 at 9:38 AM, Gerritjan Koekkoek  wrote:

> Who has mapped the flamingo-colortheme on the skin-div's?
>
> Or is this documented anywhere ?
>
>
> what is default styled with Brand-primary, Brand-success, Brand-info,
> Brand-warning, Brand-danger
>
> what is @Component-active-color and @Component-active-bg
>
>
>
> Gerritjan Koekkoek
> Vader van Rai Koekkoek (cdls) en voorzitter vereniging CdLS
> Visit our website
> Facebook
> email
>
>
>
> ___
> users mailing list
> users@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
>
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] How to test new language translation for XWiki user interface

[Ecaterina Moraru (Valica)]

Hi penguin,

I'm sure you won't finish all the translations :) but any contribution is a
step towards that direction :)

Thanks,
Caty

On Mon, Jul 4, 2016 at 5:55 PM, penguin  wrote:

> Hi,
>
> I think I can add translations to l10n when I add user interface
> translation
> to my site.
>
> However, I am not sure that I can finish all of translation.
>
> Regards,
> -Penguin
>
>
>
> --
> View this message in context:
> http://xwiki.475771.n2.nabble.com/How-to-test-new-language-translation-for-XWiki-user-interface-tp7600215p7600224.html
> Sent from the XWiki- Users mailing list archive at Nabble.com.
> ___
> users mailing list
> users@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
>
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

[xwiki-users] [Proposal] Comparing XWiki to MediaWiki and Confluence on xwiki.org

[Ecaterina Moraru (Valica)]

Hi,

Since we had users asking on the IRC what are the differences between XWiki
and other solutions, it would be a good idea to provide such pages on the
website:

- XWiki and MediaWiki
http://dev.xwiki.org/xwiki/bin/view/Drafts/XWiki-vs-MediaWiki

- XWiki and Confluence
http://dev.xwiki.org/xwiki/bin/view/Drafts/XWiki-vs-Confluence

It would be great to know if you agree with the listed content and if you
find other similarities or distinctions between the above solutions.

Additionally, what other solutions would you be interested in seeing
comparison with?

Thanks,
Caty
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

[xwiki-users] [ANN] XWiki 8.1 Release Candidate 1 released released

[Ecaterina Moraru (Valica)]

The XWiki development team is proud to announce the availability of XWiki
8.1 Release Candidate 1.
This release candidate brings a couple of improvements and bugfixes to
Extension Manager and other bundled components.

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/ReleaseNotesXWiki81RC1

The following people have contributed code to this release (sorted
alphabetically):
Alexandru Cotiuga
Clemens Robbenhaar
Denis Gervalle
Ecaterina Moraru (Valica)
Guillaume Delhumeau
Thomas Mortagne

Thanks for your support
-The XWiki dev team
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

[xwiki-users] [UX][Brainstorming] Simplifying the Homepage

[Ecaterina Moraru (Valica)]

Hi,

I would like to gather your ideas about how we could simplify the Homepage
of XWiki Enterprise.
- Maybe is something that doesn't make sense to have on it?
- Maybe is something that is missing?

Thanks,
Caty

Interaction Designer on behalf of XWiki Development Team
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] Advice on building simple app

[Ecaterina Moraru (Valica)]

Hi Tim,

Have you tried using AWM?
http://extensions.xwiki.org/xwiki/bin/view/Extension/App+Within+Minutes+Application

After you have the structure you can try to modify the Sheet page and add
conditionals.

Thanks,
Caty

On Mon, Apr 18, 2016 at 6:11 PM, Tim Dudgeon <
tdudg...@informaticsmatters.com> wrote:

> Hi all,
>
> I'm wanting to create a simple XWiki "app" and being new to this wanted to
> get some advice before starting.
> What I want is probably not too far removed from the FAQ app, so it may
> well look a bit like this, but I wanted to get some pointers before heading
> off in the wrong direction.
>
> The app is essentially a directory of "things" where each "thing" will be
> its own wiki page, and there will be a master page that lists them all and
> allow pagination, filtering etc. (livetable etc.)
> The "things" will have a small number of "fields", not too different from
> the FAQ app. But where it may differ is that the page for each "thing"
> should also allow free form editing of the wiki page so that arbitrary
> additional info can be added (even including scripts etc.) This arbitrary
> extra info will just be part or the page, not part of the directory.
> The page for each "thing" will therefore be a combination of structured
> info (the fields) appearing at the top of the page in a consistent manner
> across all pages), and non-structured info appearing below this.
>
> All advice greatly appreciated.
>
> Tim
>
> ___
> users mailing list
> users@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
>
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

[xwiki-users] [ANN] XWiki 7.4.2 released

[Ecaterina Moraru (Valica)]

The XWiki development team is proud to announce the availability of XWiki
7.4.2.
This is a bugfix release that fixes important bugs discovered in the 7.4.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/ReleaseNotesXWiki742

The following people have contributed code to this release (sorted
alphabetically):
Alexandru Cotiugă
Denis Gervalle
Ecaterina Moraru (Valica)
Eduard Moraru
Guillaume Delhumeau
Sergiu Dumitriu
Thomas Mortagne
Vincent Massol

Thanks for your support
-The XWiki dev team
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] [xwiki-devs] [VOTE] Move to Java 8 as minimal version for XWiki 8.0+

[Ecaterina Moraru (Valica)]

+1

Thanks,
Caty

On Tue, Feb 9, 2016 at 5:11 PM, vinc...@massol.net 
wrote:

> Hi devs,
>
> I’d like to propose that we move to Java 8 as the minimal Java version
> supported for XWiki 8.0+.
>
> The rationale is:
>
> * Java 7 is end of life since April 2015.
> * It brings [Default Methods|
> https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html]
> which would make retro compatibility a lot easier for us (it's very hard to
> add new features to existing API right now).
> * Required for:
> ** Infinispan 8
> ** JGroups 4
> ** Jetty 9.3+ seems to require Java 8 (or maybe it's just optimized for
> it, http://download.eclipse.org/jetty/ is not crystal clear about what
> "Java 8+" means exactly)
>
> Nice to have
> * Lambda Expressions
> * Repeating Annotations which would probably allow us to use several times
> \@Named instead of \@Component(hints=\{"hint1", "hint2"\}) for example
> * New date/time APIs (pretty much what is in Joda Time). We should
> refactor our $datetool velocity tool to make the java.time api available
> from velocity
> * more…
>
> See http://jira.xwiki.org/browse/XCOMMONS-878
>
> Here’s my +1 and my +1 to start requiring Java 8 for 8.0M2.
>
> Thanks
> -Vincent
>
> ___
> devs mailing list
> d...@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

[xwiki-users] [ANN] XWiki 8.0 Milestone 1 released

[Ecaterina Moraru (Valica)]

The XWiki development team is proud to announce the availability of XWiki
8.0 Milestone 1.

This is the first milestone release of the 8.x cycle. With this occasion we
deprecated and retired multiple projects like Colibri Skin, Color Themes,
old XWiki 1.0 syntax, etc. We also continued to polish our Nested Pages
feature introduced in 7.2, by adding improvements such as: asynchronous
copy and rename page actions, improved location picker for simple users and
the ability to omit "WebHome" in wiki links syntax.

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/ReleaseNotesXWiki80M1

The following people have contributed code to this release (sorted
alphabetically):

Alexandru Cotiugă
Denis Gervalle
Ecaterina Moraru (Valica)
Eduard Moraru
Guillaume Delhumeau
Marius Dumitru Florea
Sergiu Dumitriu
Thomas Mortagne
Vincent Massol

Thanks for your support
-The XWiki dev team
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

[xwiki-users] [ANN] XWiki 7.1.4 released

[Ecaterina Moraru (Valica)]

The XWiki development team is proud to announce the availability of XWiki
7.1.4.
This is a bugfix release that fixes important bugs discovered in the 7.1.3
version. We also retired the XML-RPC Integration since it led to security
vulnerabilities.

You can download it using these links:

JAR:
http://download.forge.ow2.org/xwiki/xwiki-enterprise-installer-generic-7.1.4-standard.jar

EXE:
http://download.forge.ow2.org/xwiki/xwiki-enterprise-installer-windows-7.1.4.exe

ZIP:
http://download.forge.ow2.org/xwiki/xwiki-enterprise-jetty-hsqldb-7.1.4.zip

WAR:
http://download.forge.ow2.org/xwiki/xwiki-enterprise-web-7.1.4.war

XAR:
http://download.forge.ow2.org/xwiki/xwiki-enterprise-ui-mainwiki-all-7.1.4.xar

Make sure to review the release notes:
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki714

The following people have contributed code to this release (sorted
alphabetically):
Ecaterina Moraru (Valica)
Eduard Moraru
Marius Dumitru Florea
Thomas Mortagne
Vincent Massol

Thanks for your support
-The XWiki dev team
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] congratulations

[Ecaterina Moraru (Valica)]

Thanks Ricardo for all your nice words! :)

Caty

On Wed, Nov 25, 2015 at 11:12 AM, vinc...@massol.net 
wrote:

> Hi Ricardo,
>
> We like these kind of messages! Keep them coming :)
>
> Thanks a lot for sharing this with us.
> -Vincent
> On 24 Nov 2015 at 15:54:41, [IDIS Technical Secretariat] Ricardo Rodríguez
> (ricardo.rodrig...@idisantiago.es) wrote:
>
> Dears,
>
> I've just updated to XWiki 7.3. I'm really happy to keep enjoying XWiki and
> to see how the framework is evolving. The interface is now cleaner, much
> nicer. All behind the scene seems to me clearer release after release.
>
> Thanks for the effort!
>
> Warmest regards,
>
> Ricardo
> ___
> users mailing list
> users@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
>
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

[xwiki-users] [ANN] XWiki 7.3 released

[Ecaterina Moraru (Valica)]

The XWiki development team is proud to announce the availability of XWiki
7.3.
This is a stabilisation release focusing on the Nested Pages feature which
was introduced in XWiki 7.2.

Lots of polishing has been done for the Nested Pages feature integration,
targeting the consequences on the UI redesign and the changes at
applications level. The release includes a couple of bug fixes, a few
dependency upgrades and new UI extension points available for extension
developers.

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/ReleaseNotesXWiki73

The following people have contributed code to this release:

Clemens Robbenhaar
Ecaterina Moraru (Valica)
Eduard Moraru
Gabriela Smeria
Guillaume Delhumeau
Jean SIMARD
Manuel Smeria
Marius Dumitru Florea
Pascal Bastien
Sergiu Dumitriu
Thomas Mortagne
Vincent Massol

Thanks for your support
-The XWiki dev team
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] ForumApplication : Subscribe by mail ?

[Ecaterina Moraru (Valica)]

Search is again not working because of hidden, see
http://jira.xwiki.org/browse/XAFORUM-144

Still I am not aware of any watchlist filtering of hidden pages. Hidden
pages can be viewed if you change in your Profile the "Display Hidden
Pages" preference.

Thanks,
Caty

On Tue, Oct 6, 2015 at 4:12 PM, j3rem1e  wrote:

> Thanks for your answer,
>
> I have maybe something wrong with my setup : The watchlist and mail
> notifications have always worked correctly in xwiki, but not in the forum
> application (blog, faq and wiki pages work and send a notification each
> time
> the are updated). Moreover, the search function didn't work either on the
> forum (maybe this two issues are linked ?).
>
> I have developped a workaround with a custom EventListener for the
> notification. Ill try to search a little more why the native watchlist
> doesn't work for me.
>
>
>
> --
> View this message in context:
> http://xwiki.475771.n2.nabble.com/ForumApplication-Subscribe-by-mail-tp7596257p7596350.html
> Sent from the XWiki- Users mailing list archive at Nabble.com.
> ___
> users mailing list
> users@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
>
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] ForumApplication : Subscribe by mail ?

[Ecaterina Moraru (Valica)]

Hi,

Forum app doesn't have something special implemented in order to send
mails.
The Watchlist feature should work, just make sure your mail server settings
are correct.
Regarding the apparence in the activity stream, this is related ti the fact
the forum entities are hidden, but this won't affect the Watchlist feature.

Thanks,
Caty

On Thu, Oct 1, 2015 at 11:55 AM, j3rem1e  wrote:

> Subscribing to the space didn't work.
> The forum application seems to store topics and answers in a hidden
> document
> (TopicXX and TopicAnswerXX), and this document doesn't appear in the
> activity stream and (i suppose) are not notified through the watchlist
> plugin ?
>
>
>
>
>
>
> --
> View this message in context:
> http://xwiki.475771.n2.nabble.com/ForumApplication-Subscribe-by-mail-tp7596257p7596272.html
> Sent from the XWiki- Users mailing list archive at Nabble.com.
> ___
> users mailing list
> users@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
>
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

[xwiki-users] [ANN] XWiki 6.4.5 released

[Ecaterina Moraru (Valica)]

The XWiki development team is proud to announce the availability of XWiki
6.4.5.
This is a stabilization release that fixes important bugs discovered in the
6.4.4 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/ReleaseNotesXWiki645

The following people have contributed code to this release:
Anca Luca
Denis Gervalle
Ecaterina Moraru (Valica)
Eduard Moraru
Guillaume Delhumeau
Jean SIMARD
Manuel Smeria
Marius Dumitru Florea
Thomas Mortagne
Vincent Massol

Thanks for your support
-The XWiki dev team
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] Document autosave in xwiki 7.0.1

[Ecaterina Moraru (Valica)]

Hi,

The feature is available only in Wiki editor, near the Save buttons.
Regarding WYSIWYG, there is an issue about enabling it
http://jira.xwiki.org/browse/XWIKI-8614
In the issue you also have pictures if you still can't find it.

Thanks,
Caty


On Wed, Jul 1, 2015 at 11:58 AM, robert roberts.vart...@gmail.com wrote:

 According to this feature list
 http://platform.xwiki.org/xwiki/bin/view/Features/PageEditing there should
 be auto save feature in xwiki (also in 7.0.1?). Does it have to be
 explicitly enabled? I don't see it neither in WYSIWYG nor in source edit
 mode.



 --
 View this message in context:
 http://xwiki.475771.n2.nabble.com/Document-autosave-in-xwiki-7-0-1-tp7595321.html
 Sent from the XWiki- Users mailing list archive at Nabble.com.
 ___
 users mailing list
 users@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/users

___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] Document autosave in xwiki 7.0.1

[Ecaterina Moraru (Valica)]

Hi,

You are showing me the WYSIWYG tabs, the Source one.

The feature is available in the Wiki Editor. In order to access the Wiki
editor, you should enable 'Advanced Mode', see
http://platform.xwiki.org/xwiki/bin/view/Features/PageEditing#HAdvancedMode

Thanks,
Caty


On Wed, Jul 1, 2015 at 1:41 PM, robert roberts.vart...@gmail.com wrote:

 Strange. I still can't find it
 https://www.dropbox.com/s/62zsjb1wi4lmb7q/doc_edit.png?dl=0



 --
 View this message in context:
 http://xwiki.475771.n2.nabble.com/Document-autosave-in-xwiki-7-0-1-tp7595321p7595324.html
 Sent from the XWiki- Users mailing list archive at Nabble.com.
 ___
 users mailing list
 users@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/users

___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] Link

[Ecaterina Moraru (Valica)]

Hey,

An similar idea would be to add some rights for that particular page that
has View for unregistered users.

Thanks,
Caty

On Wed, Jul 1, 2015 at 1:18 PM, Maciej Fokt maciek.f...@taxi123.pl wrote:

 Hey,

 I would like to know if there is the possibility of concluding a login and
 password in the link to the XWiki. I would like to allow other users to
 login without entering data. Is it possible?

 Regards,
 Maciek.
 ___
 users mailing list
 users@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/users

___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] Release Notes of Forum Application

[Ecaterina Moraru (Valica)]

Hi,

Not sure what you are talking about. They look fine, see
http://imgur.com/Nc6cdwF

Thanks,
Caty

On Wed, Jun 24, 2015 at 4:14 PM, Hamster teun...@hotmail.com wrote:

 Can a dev look at the release notes of the  ForumApplication
 http://extensions.xwiki.org/xwiki/bin/view/Extension/ForumApplication

 It seems like FWK005 oarse may not be called while parsing is messing
 things up :-)



 --
 View this message in context:
 http://xwiki.475771.n2.nabble.com/Release-Notes-of-Forum-Application-tp7595276.html
 Sent from the XWiki- Users mailing list archive at Nabble.com.
 ___
 users mailing list
 users@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/users

___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] Old XWiki Downloads

[Ecaterina Moraru (Valica)]

I've moved the 'Older version' link in Other downloads sections.
When we had XEM, XEclipse the link was better suited in the past location.

Thanks,
Caty

On Thu, Jun 18, 2015 at 11:45 AM, withwind...@gmail.com wrote:

 Here is the website you can download all the release versions:
 http://forge.ow2.org/project/showfiles.php?group_id=170


 -邮件原件-
 发件人: users [mailto:users-boun...@xwiki.org] 代表 RonHancock
 发送时间: 2015年6月18日 4:10
 收件人: users@xwiki.org
 主题: Re: [xwiki-users] Old XWiki Downloads

 here here! It is almost impossible to find old versions on the website.
 There should be an older versions button somewhere on the download page
 to
 take you to the archives.

 Ron



 --
 View this message in context:

 http://xwiki.475771.n2.nabble.com/Old-XWiki-Downloads-tp7585869p7595182.html
 Sent from the XWiki- Users mailing list archive at Nabble.com.
 ___
 users mailing list
 users@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/users

 ___
 users mailing list
 users@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/users

___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

[xwiki-users] [ANN] XWiki 7.1 released

[Ecaterina Moraru (Valica)]

The XWiki development team is proud to announce the availability of XWiki
7.1

This release adds important changes and improvements for Extension Manager,
Solr Search, Watchlist, a new experimental Flavors mechanism and a Debug
mode for performance analysis.

Extension Manager provides a summary for the extension diff view in order
to ease the navigation of the local code changes. A new Extension History
section has also been added, offering support for selective export, import
and replay of extension-related history records.

Solr Search UI is improved by making it responsive on small screens. The
users can now sort, paginate and filter the search results without a page
reload.

The Flavors and Watchlist Realtime option are currently still experimental,
but you are encouraged to test them and provide feedback.

The WatchList performance has been improved, especially for the Realtime
notification option. The Realtime Watchlist messages are displayed in a
more user-friendly way, sending mails for a variety of events, threaded by
your email client by the document they occurred in.

The Flavor mechanism is allowing the selection of Flavors in the wiki
creation step. In the future, XWiki will offer different Flavors and these
are steps towards this direction.

Under-the-hood there are various mail and job module improvements. The
developers can now trigger old Prototype event listeners from jQuery and a
new API is available to escape wiki syntax.

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/ReleaseNotesXWiki71

The following people have contributed code to this release:
Thomas Mortagne
Vincent Massol
Guillaume Delhumeau
Eduard Moraru
Marius Dumitru Florea
Denis Gervalle
Sergiu Dumitriu
Manuel Smeria
Gabriela Smeria
Ecaterina Moraru (Valica)
Anca Luca
Jean SIMARD
Clemens Robbenhaar

Thanks for your support
-The XWiki dev team
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] Issue with Mocca Calendar finding fullcalendar.js

[Ecaterina Moraru (Valica)]

Hi Jeremie,

You should also report the issue on http://jira.xwiki.org/browse/MOCCACAL

Thanks,
Caty

On Thu, Jun 4, 2015 at 5:26 PM, Thomas Mortagne thomas.morta...@xwiki.com
wrote:

 Actually the issue you have is because of the change made in
 http://jira.xwiki.org/browse/XWIKI-11094 which removed jquery from
 /xwiki/resources/js/amd/jquery. This might actually be seen as an
 important API breackage.

 On Thu, Jun 4, 2015 at 4:17 PM, Jeremie BOUSQUET
 jeremie.bousq...@gmail.com wrote:
  2015-06-04 11:34 GMT+02:00 Marius Dumitru Florea 
  mariusdumitru.flo...@xwiki.com:
 
  On Wed, Jun 3, 2015 at 1:05 PM, Jeremie BOUSQUET
  jeremie.bousq...@gmail.com wrote:
   Hello dear xwiki-ers,
  
   (long time no see ;) )
  
   I installed the Mocca Calendar application [1] in my xwiki 5.4.7
  instance,
   but when browsing to its home page, needed js file can't be loaded
 and so
   not much appears ...
  
   Error from FF console:
  
   GET http://r-wikiggs.gemalto.com/fullcalendar.js [HTTP/1.1 404 Not
 Found
   9ms]
   Error: Script error for: fullcalendar
   http://requirejs.org/docs/errors.html#scripterror
  
   I understand that it probably comes from MoccaCalendar.Macro js
  extension:
  
   require(['jquery', 'fullcalendar'], function(jQuery, fullCalendar) {
  
   ... but my knowledge of requireJS is more than poor so I'm not sure
 how
  to
   fix this ... For sure URL used to reach fullcalendar.js is NOK.
 
  I'm not familiar with the Mocca Calendar application, but from the 404
  URL you get in the Firefox console it seems you're missing the
  Require.js configuration that specifies where the 'fullcalendar'
  module is located. Require.js attempts to load the module from the
  root of your webapp as a fallback and fails. See
  http://requirejs.org/docs/api.html#config-paths .
 
 
  Thanks Marius,
 
  I checked from page source and there is:
 
  require.config({
baseUrl: '/',
  paths: { 'jquery': /xwiki/resources/js/amd/jquery },
map: {
  '*': { 'jquery': 'jQueryNoConflict' },
  'jQueryNoConflict': { 'jquery': 'jquery' }
}
  });
 
  I suppose this is a basic configuration of xwiki, I'm not sure where
  require conf can be altered ... (from velocity templates ?)
  Anyway, as I did not find fullcalendar.js, what I did is:
  - download fullcalendar-2.3.1.zip and unzip it to
  $TOMCAT_HOME/webapps/xwiki/resources/js/fullcalendar/
  - change js extension in MoccaCalendar.Macro with: require(['jquery',
  '/xwiki/resources/js/fullcalendar/fullcalendar.js'], function(jQuery,
  fullCalendar) {
 
  A calendar is now displayed (sometimes), but seems to be missing
  stylesheets completely, so it's not really usable ...
  I feel there must be something easier to do ;)
 
  BR,
  Jeremie
 
 
  Hope this helps,
  Marius
 
  
   Thanks,
   BR,
   Jeremie
   ___
   users mailing list
   users@xwiki.org
   http://lists.xwiki.org/mailman/listinfo/users
  ___
  users mailing list
  users@xwiki.org
  http://lists.xwiki.org/mailman/listinfo/users
 
  ___
  users mailing list
  users@xwiki.org
  http://lists.xwiki.org/mailman/listinfo/users



 --
 Thomas Mortagne
 ___
 users mailing list
 users@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/users

___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] Printing pages as displayed

[Ecaterina Moraru (Valica)]

On Thu, May 7, 2015 at 1:46 PM, Mahomed Hussein maho...@custodiandc.com
wrote:

 Hi

 Can anyone help please with some information on how to modify/control the
 print layout please? Thanks.


Each skin has a print.css




 Kind regards,

 Mahomed




 -Original Message-
 From: users [mailto:users-boun...@xwiki.org] On Behalf Of Mahomed Hussein
 Sent: 05 May 2015 17:59
 To: XWiki Users
 Subject: Re: [xwiki-users] Printing pages as displayed

 Oh! I forgot to mention we are running 7.0.1 and a custom skin/theme based
 on the flamingo skin.


 Kind regards,

 Mahomed




 -Original Message-
 From: users [mailto:users-boun...@xwiki.org] On Behalf Of Mahomed Hussein
 Sent: 05 May 2015 17:53
 To: XWiki Users
 Subject: [xwiki-users] Printing pages as displayed

 Hi

 Is there a way of printing the pages as they are displayed? Ideally
 printing without the side panel, but with all the different
 colours/formatting as it appears on the screen would be ideal. At the
 moment all colours and formatting is stripped if you try to print directly
 from the page, using the print preview option or by exporting to PDF.

 I have tried an export to HTML and then using the local html file to see
 if that works but it seems that whatever script/css is forcing the print
 formatting still takes effect on the exported html. I have tried saving the
 page only directly but it still does the same thing. I have tried Chrome.
 Firefox and IE.

 I have also tried a google search and I have searched for print and
 printing on the FAQ but there are so many results it may take a few hours
 to go through them all. I suspect there’s a CSS file I need to modify
 somewhere (possibly print.css?) that will format the export with the header
 colours etc. If so, please could someone kindly point me at the correct
 documentation or provide any tips/hints?

 Thanks in advance.


 Kind regards,

 Mahomed






 ___
 users mailing list
 users@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/users
 ___
 users mailing list
 users@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/users
 ___
 users mailing list
 users@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/users

___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] Printing pages as displayed

[Ecaterina Moraru (Valica)]

Except print.css another way of 'printing' XWiki pages would be to
customize the PDF export, but this step is more complicated (you need to do
modifications to pdf templates, XHTML2FO XSL and FOP XSL transformations,
etc.), see
http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Configuration#HCustomizingthePDFexportLook26Feel

Depends on what you need to do.
Have fun,
Caty

On Thu, May 7, 2015 at 2:57 PM, Mahomed Hussein maho...@custodiandc.com
wrote:

 Great! Thanks. Good to know I was on the right path :)


 Kind regards,

 Mahomed




 -Original Message-
 From: users [mailto:users-boun...@xwiki.org] On Behalf Of Ecaterina
 Moraru (Valica)
 Sent: 07 May 2015 12:25
 To: XWiki Users
 Subject: Re: [xwiki-users] Printing pages as displayed

 On Thu, May 7, 2015 at 1:46 PM, Mahomed Hussein maho...@custodiandc.com
 wrote:

  Hi
 
  Can anyone help please with some information on how to modify/control the
  print layout please? Thanks.
 

 Each skin has a print.css


 
 
  Kind regards,
 
  Mahomed
 
 
 
 
  -Original Message-
  From: users [mailto:users-boun...@xwiki.org] On Behalf Of Mahomed
 Hussein
  Sent: 05 May 2015 17:59
  To: XWiki Users
  Subject: Re: [xwiki-users] Printing pages as displayed
 
  Oh! I forgot to mention we are running 7.0.1 and a custom skin/theme
 based
  on the flamingo skin.
 
 
  Kind regards,
 
  Mahomed
 
 
 
 
  -Original Message-
  From: users [mailto:users-boun...@xwiki.org] On Behalf Of Mahomed
 Hussein
  Sent: 05 May 2015 17:53
  To: XWiki Users
  Subject: [xwiki-users] Printing pages as displayed
 
  Hi
 
  Is there a way of printing the pages as they are displayed? Ideally
  printing without the side panel, but with all the different
  colours/formatting as it appears on the screen would be ideal. At the
  moment all colours and formatting is stripped if you try to print
 directly
  from the page, using the print preview option or by exporting to PDF.
 
  I have tried an export to HTML and then using the local html file to see
  if that works but it seems that whatever script/css is forcing the print
  formatting still takes effect on the exported html. I have tried saving
 the
  page only directly but it still does the same thing. I have tried Chrome.
  Firefox and IE.
 
  I have also tried a google search and I have searched for print and
  printing on the FAQ but there are so many results it may take a few hours
  to go through them all. I suspect there’s a CSS file I need to modify
  somewhere (possibly print.css?) that will format the export with the
 header
  colours etc. If so, please could someone kindly point me at the correct
  documentation or provide any tips/hints?
 
  Thanks in advance.
 
 
  Kind regards,
 
  Mahomed
 
 
 
 
 
 
  ___
  users mailing list
  users@xwiki.org
  http://lists.xwiki.org/mailman/listinfo/users
  ___
  users mailing list
  users@xwiki.org
  http://lists.xwiki.org/mailman/listinfo/users
  ___
  users mailing list
  users@xwiki.org
  http://lists.xwiki.org/mailman/listinfo/users
 
 ___
 users mailing list
 users@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/users
 ___
 users mailing list
 users@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/users

___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] Clear them all! :p

[Ecaterina Moraru (Valica)]

Hi,

First of all I'd like to thank Mahomed for the nice words he said about
XWiki.

I agree that we must try to make XWiki as simple as it can be for the
end-users and, as Pascal said, one solution for this is to improve the
documentation.

The problem is that I'm not sure I completely understood what problem
Maciek has (in order to improve it).

Thanks,
Caty

On Thu, Apr 23, 2015 at 12:39 PM, Mahomed Hussein maho...@custodiandc.com
wrote:

 I'm sure we can debate this all day.

 XWiki is very simple for end users to use. The actual purpose of the wiki
 (to allow people to create/edit/view articles/pages) is simple and
 straight-forward. I have everyone in our organisation using it
 successfully, and trust me, some of the end users should not be allowed
 near computers. But they managed to use the system for its purpose just
 fine. That doesn't mean that they can all install, configure, update and
 customise XWiki.

 I'll give you another analogy. XWiki is like a fine car. Cars are easy to
 use and drive by almost anyone. But that doesn't mean everyone can fix a
 car. Even if you know a little bit about how engines work and how to change
 the oil etc. Some jobs just have to be left to the professionals. XWiki is
 the same. Everyone can use it very easily. But when it comes to the
 advanced stuff, if you can't understand the excellent documentation, and no
 one can help you on the mailing list then the problem is not with XWiki.

 I consider myself a very competent engineer and developer, but there are
 some things that even I find quite advanced in XWiki. That goes to show how
 powerful it is (and what a great job the developers have done).

 Anyway I don’t think this is too constructive for the mailing list so I
 will stop here. You are entitled to your opinion and I am to mine (I think
 XWiki is great). If you don't like XWiki then I hope you find something
 that suits you better. That's the beauty of the internet and open source.
 You can always find something that suits you or make your own :)


 Kind regards,

 Mahomed




 -Original Message-
 From: users [mailto:users-boun...@xwiki.org] On Behalf Of Pascal BASTIEN
 Sent: 22 April 2015 22:23
 To: XWiki Users; Maciej Fokt
 Subject: Re: [xwiki-users] Clear them all! :p

 Hello,I'm sorry, I'm not agree with you : a powerfull system must hide the
 systems complexity... And it is a wiki : it's mean if there aren't enough
 simple documentation then anybody (high ueser AND normal people with non
 computer vision) must write a page to contribute and make more available
 for simple user. :-)
 IMO we can use a simple xwiki and/or use higher  level xwiki and/or a
 customized one. :-)

 Pascal B.


   De : Mahomed Hussein maho...@custodiandc.com
  À : Maciej Fokt maciek.f...@taxi123.pl; XWiki Users users@xwiki.org
  Envoyé le : Mercredi 22 avril 2015 18h37
  Objet : Re: [xwiki-users] Clear them all! :p

 That's just the way technology is. The more powerful a system is, and the
 more options it has, then the more technical it is. If you want something
 that's easy for no computer people then I'm afraid you need to use
 something which has less features and power. A jumbo jet pilot needs to
 have more experience and knowledge than a Cessna pilot. The jumbo jet has
 more buttons and features and probably cannot be easily or ever flown by a
 Cessna pilot. That's just the way things are.

 XWiki actually has VERY good documentation (some of the best I've seen,
 and I've seen a lot of systems). It also has a helpful mailing list.
 Unfortunately it's not XWiki' s fault if you can't understand the
 documentation or the help that you have been offered several times here.

 I genuinely hope you manage to find a system that you like and works for
 you.


 Kind regards,

 Mahomed




 -Original Message-
 From: Maciej Fokt [mailto:maciek.f...@taxi123.pl]
 Sent: 22 April 2015 17:27
 To: XWiki Users; Mahomed Hussein
 Subject: Re: [xwiki-users] Clear them all! :p

 No way... I have back to the 1.1 version and now i haven't settings...

 Why XWiki (good, big and helpful toll) can be so hard for no computer
 people...

 Thanks all for help, but XWiki is too hard for me, I think.


 W dniu .04.2015 o 18:00 Mahomed Hussein maho...@custodiandc.com pisze:

  He has a problem with his install and I believe he wants to reset the
  system so it will be the same as when he installed it for the first
  time. I don't think this is possible without uninstalling, then
  searching and deleting all files/folders related and then installing
  from the beginning.
 
 
  Kind regards,
 
 
 
 
  -Original Message-
  From: users [mailto:users-boun...@xwiki.org] On Behalf Of Ecaterina
  Moraru (Valica)
  Sent: 22 April 2015 16:30
  To: XWiki Users
  Subject: Re: [xwiki-users] Clear them all! :p
 
  I guess you could revert the WebPreferences history to version 1.1.
 
  For example, in the Administration you have this URL:
  - xwiki/bin/admin/XWiki/XWikiPreferences
  You

Re: [xwiki-users] Clear them all! :p

[Ecaterina Moraru (Valica)]

I guess you could revert the WebPreferences history to version 1.1.

For example, in the Administration you have this URL:
- xwiki/bin/admin/XWiki/XWikiPreferences
You could do:
- xwiki/bin/view/XWiki/XWikiPreferences?viewer=history
and then on the version 1.1 use Rollback.

Not sure if this is what you meant.
Thanks,
Caty


On Wed, Apr 22, 2015 at 6:01 PM, Maciej Fokt maciek.f...@taxi123.pl wrote:


 Hello,

 Is there option to return to the first contain and settings? I mean, I
 want to clear everything. I would like to back to the settings after
 installation.

 Greetings,
 Maciek.
 ___
 users mailing list
 users@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/users

___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] Xwiki Flamingo Icons Bug?

[Ecaterina Moraru (Valica)]

Do you have this file /webapp/resources/uicomponents/wiki/wiki.css ?

Maybe http://jira.xwiki.org/browse/XWIKI-10577 is the issue.
We delete the file and moved the selectors to Colibri.

Thanks,
Caty

On Sat, Apr 4, 2015 at 6:36 PM, Georg Hirn georg.h...@gmail.com wrote:

 Hi all!

 @Eduard:
 I have commented out the lucene plugin, that works, the exception has gone
 away, thank you.
 But my original issue still exists.
 Sorry I did not know that attachments not work, here are the links to the
 screenshots:

-

 https://drive.google.com/file/d/0B_VsU8fJmgGTUDk4OEdtcFpBa3c/view?usp=sharing
-

 https://drive.google.com/file/d/0B_VsU8fJmgGTN3kxTHRJV2FJckU/view?usp=sharing
-

 https://drive.google.com/file/d/0B_VsU8fJmgGTY1V4VWh5bTlMUnM/view?usp=sharing

 @Thomas:
 I compared these two files and found the following differences:

 xwiki.cfg:
  xwiki.cfg.dpkg-dist:
 xwiki.title.compatibility=1
 xwiki.title.compatibility=0
 LucenePlugin listed no LucenePlugin
 listed
 WatchListPlugin listed no WatchListPlugin
 listed

 I changed that to xwiki.title.compatibility=0 and commented LucenePlugin
 and WatchListPlugin out, restarted tomcat, but the original issue is still
 there.

 Thanks,
 Georg


 2015-04-04 13:41 GMT+02:00 Thomas Mortagne thomas.morta...@xwiki.com:

  On Sat, Apr 4, 2015 at 12:23 PM, Eduard Moraru enygma2...@gmail.com
  wrote:
   Hi,
  
   The relevant exception in that log is
 java.lang.ClassNotFoundException:
   com.xpn.xwiki.plugin.lucene.LucenePlugin. The Lucene Plugin has been
   retired [1] and replaced by the Solr Search application [2].
  
   You are currently getting that exception because you did not properly
   upgrade your xwiki.cfg/xwiki.properties configuration files. They need
 to
   be upgraded appropriately to the release notes of the versions you are
   upgrading through.
  
   In this particular case, you did not remove from the xwiki.cfg file,
  inside
   the xwiki.plugins section, the reference to LucenePlugin. Once you
  remove
   it, XWiki should no longer try to load it and you should not get that
   exception message any more.
 
  In this particular case it probably means you kept the current version
  when apt-get asked you if you wanted to move to the new one. You
  should compare /etc/xwiki/xwiki.cfg and /etc/xwiki/xwiki.cfg.dpkg-dist
  (this is the new standard version) files.
 
  
   Regarding your original issue, try sharing a screenshot with us. Note
  that
   attachments don`t work on this list, so please use an image upload
 online
   service and share us the link.
  
   Thanks,
   Eduard
  
   --
   [1]
  
 
 http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki70M1#HDeprecatedandRetiredprojects
   [2]
  
 
 http://extensions.xwiki.org/xwiki/bin/view/Extension/Solr+Search+Application
  
   On Fri, Apr 3, 2015 at 3:39 PM, Georg Hirn georg.h...@gmail.com
 wrote:
  
   Ok, I have made a apt-get upgrade for xwiki. It did update some
 packages
   with no errors, see apt-get log:
  
   Log started: 2015-04-03  13:53:45
(Lese Datenbank ... ^M(Lese Datenbank ... 5%^M(Lese Datenbank ...
10%^M(Lese Datenbank ... 15%^M(Lese Datenbank ... 20%^M(Lese
 Datenbank
   ...
25%^M(Lese Datenbank ... 30%^M(Lese Datenbank ... 35%^M(Lese
 Datenbank
   ...
40%^M(Lese Datenbank ... 45%^M(Lese Datenbank ... 50%^M(Lese
 Datenbank
   ...
55%^M(Lese Datenbank ... 60%^M(Lese Datenbank ... 65%^M(Lese
 Datenbank
   ...
70%^M(Lese Datenbank ... 75%^M(Lese Datenbank ... 80%^M(Lese
 Datenbank
   ...
85%^M(Lese Datenbank ... 90%^M(Lese Datenbank ... 95%^M(Lese
 Datenbank
   ...
100%^M(Lese Datenbank ... 165997 Dateien und Verzeichnisse sind
  derzeit
installiert.)
Vorbereitung zum Entpacken von
.../xwiki-enterprise-tomcat7-mysql_7.0+1_all.deb ...
Entpacken von xwiki-enterprise-tomcat7-mysql (7.0+1) über (7.0) ...
 * Stopping Tomcat servlet engine tomcat7   ESC[205G ^MESC[199G[
  OK ]
 * Starting Tomcat servlet engine tomcat7   ESC[205G ^MESC[199G[
  OK ]
Vorbereitung zum Entpacken von
.../xwiki-enterprise-tomcat-common_7.0+1_all.deb ...
Entpacken von xwiki-enterprise-tomcat-common (7.0+1) über (7.0) ...
Vorbereitung zum Entpacken von
.../xwiki-enterprise-mysql-common_7.0+1_all.deb ...
Entpacken von xwiki-enterprise-mysql-common (7.0+1) über (7.0) ...
Vorbereitung zum Entpacken von
  .../xwiki-enterprise-common_7.0+1_all.deb
...
Entpacken von xwiki-enterprise-common (7.0+1) über (7.0) ...
xwiki-enterprise-common (7.0+1) wird eingerichtet ...
xwiki-enterprise-tomcat-common (7.0+1) wird eingerichtet ...
xwiki-enterprise-mysql-common (7.0+1) wird eingerichtet ...
dbconfig-common: writing config to /etc/dbconfig-common/xwiki.conf
dbconfig-common: flushing administrative password
xwiki-enterprise-tomcat7-mysql (7.0+1) wird eingerichtet ...
 * Stopping Tomcat servlet engine tomcat7  

[xwiki-users] [ANN] XWiki 7.0 released

[Ecaterina Moraru (Valica)]

The XWiki development team is proud to announce the availability of XWiki
7.0.

This is the first release of the 7.x cycle. It features many improvements
for extensions, a simplified Wiki Creation Wizard, improved differences
view, integration of a new Tree Widget with the WYSIWYG editor and Index
Application, etc.

Regarding extensions, we now have the ability to organize and filter
extensions by category in the Extension Repository, the install date and
the user that performed the install are now available in the extension
details, the extensions that were installed explicitly are now displayed
distinctly, etc.

We improved the difference views for document history and extension upgrade
process, by showing a difference summary between the two versions, detailed
changes to objects definitions, etc.

Developers may enjoy a new application to edit wiki Skins, a new Finder
Plugin for the Tree Widget and API improvements to the Mail Sender and
Extension Manager modules.

The Watchlist module has a new component based implementation and also
there is an experimental Realtime Watchlist Notification feature.

XWiki also moved to Servlet 3.0.1 which means various old application
servers versions are not supported anymore and the old Lucene search module
was finally retired to Contrib.

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/ReleaseNotesXWiki70

Thanks
-The XWiki dev team
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] Globally changing font, headers and title in XWiki

[Ecaterina Moraru (Valica)]

Hi,

http://jira.xwiki.org/browse/XWIKI-11679

This issue is fixed in  6.2.5, 7.0-milestone-1, 6.4.1 versions.

Thanks,
Caty

On Tue, Mar 17, 2015 at 10:37 PM, MishaK mkurba...@gmail.com wrote:

 Yes, I am using administrator account. It looks like ONLY @headings-color
 is
 missing. Any suggestion on how to fix this problem?



 --
 View this message in context:
 http://xwiki.475771.n2.nabble.com/Globally-changing-font-headers-and-title-in-XWiki-tp7594311p7594338.html
 Sent from the XWiki- Users mailing list archive at Nabble.com.
 ___
 users mailing list
 users@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/users

___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] Globally changing font, headers and title in XWiki

[Ecaterina Moraru (Valica)]

Hi,

- Go to your FlamingoTheme editor, like 'edit/FlamingoThemes/Charcoal'
- Go to section 'Advanced', in the textarea write: @headings-color: blue;

Thanks,
Caty

On Wed, Mar 18, 2015 at 3:23 PM, MishaK mkurba...@gmail.com wrote:

 Thank you for your answer!
 Is there a way to upgrade the xwiki through web without accessing the local
 files?
 Also, can I fix the issue with the advanced option in the Color Theme using
 @lessCode or something? If so, how?

 Regards,
 Michael



 --
 View this message in context:
 http://xwiki.475771.n2.nabble.com/Globally-changing-font-headers-and-title-in-XWiki-tp7594311p7594343.html
 Sent from the XWiki- Users mailing list archive at Nabble.com.
 ___
 users mailing list
 users@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/users

___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] Globally changing font, headers and title in XWiki

[Ecaterina Moraru (Valica)]

Not sure what you mean by 'Topic title color'? Are you refering to the
Forum App?

Anyway, you should inspect with Firebug or with your browser's Inspector,
see what class has the header you need and write the appropiate CSS
selector for it.

For example, the @headings-color is set for h1, h2, h3, h4, h5, h6.

For example, you could write something like this:

@headings-color: blue;

#document-title h1 {
  color: green;
}

in order to have a different color for the main page header (that has the
id='document-title'), but again ... depends what you are talking about.

Thanks,
Caty


On Wed, Mar 18, 2015 at 5:41 PM, MishaK mkurba...@gmail.com wrote:

 That worked, thanks again!
 Is there a separate class for the topic title colour? I want it to have
 separate colours from the rest of the headers.

 Regards,
 Michael



 --
 View this message in context:
 http://xwiki.475771.n2.nabble.com/Globally-changing-font-headers-and-title-in-XWiki-tp7594311p7594346.html
 Sent from the XWiki- Users mailing list archive at Nabble.com.
 ___
 users mailing list
 users@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/users

___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] Globally changing font, headers and title in XWiki

[Ecaterina Moraru (Valica)]

I'm glad that you solved your problem.

Have fun,
Caty

On Wed, Mar 18, 2015 at 7:42 PM, MishaK mkurba...@gmail.com wrote:

 I meant the topic title of the page at the top. In this case it was
 heading 1
 so I followed your example and everything worked.
 Thank you very much, I appreciate it! Been trying to solve this problem for
 a week. I couldn't exactly find what i was looking for in documentation and
 guides for xwiki. It's great that you guys follow and support this forum!



 --
 View this message in context:
 http://xwiki.475771.n2.nabble.com/Globally-changing-font-headers-and-title-in-XWiki-tp7594311p7594348.html
 Sent from the XWiki- Users mailing list archive at Nabble.com.
 ___
 users mailing list
 users@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/users

___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] [xwiki-devs] Suggestions for new Photo Albulm Xwiki

[Ecaterina Moraru (Valica)]

Hi,

It's great that you are thinking about writing a Photo application since we
are missing a photo gallery and I'm sure lots of people in the community
would like one.

There is this page on design.xwiki.org
http://design.xwiki.org/xwiki/bin/view/Proposal/PhotoApplication
that list related extensions for photo album and also list some possible
requirements, not sure if it's what you are needing.

Good luck,
Caty

On Fri, Mar 13, 2015 at 7:02 PM, Cray xWiki crayxw...@gmail.com wrote:

 Hello,

 we are a groupe of four students and we are actually working on a XWiki
 extension.

 This extension will be a modern photo gallery which allows users to
 organise and publish photos.

 For now, our planned features are the followings:

 -Thumbnails display
 -Responsive display
 -Autoplay (diaporama)
 -Nice transitions
 -Intuitive configuration page included drag and drop function to upload
 images

 Do you have another ideas or suggestions to improve our extension ?

 Thank you in advance.

 Best regards,

 CRAY team
 ___
 devs mailing list
 d...@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/devs

___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] cell borders in tables

[Ecaterina Moraru (Valica)]

Hi,

Since this seems to be a recurring issue, I've created
http://jira.xwiki.org/browse/XWIKI-11908

Thanks,
Caty

2015-03-03 21:52 GMT+02:00 Jamal ram...@gmail.com:

 Stylesheet extensions are documented here:


 http://platform.xwiki.org/xwiki/bin/view/DevGuide/SkinExtensionsTutorial#HMinimalStyleSheeteXtension

 J



 --
 View this message in context:
 http://xwiki.475771.n2.nabble.com/cell-borders-in-tables-tp7594148p7594193.html
 Sent from the XWiki- Users mailing list archive at Nabble.com.
 ___
 users mailing list
 users@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/users

___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

[xwiki-users] [ANN] XWiki 6.4.1 released

[Ecaterina Moraru (Valica)]

The XWiki development team is proud to announce the availability of XWiki
Enterprise 6.4.1.

This is a stabilization release that fixes important bugs discovered in the
previous 6.4 version, while also providing an integration of the new Tree
Widget with the Index Application and the WYSIWYG Editor.

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/ReleaseNotesXWiki641

Thanks
-The XWiki dev team
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] List all registered macros

[Ecaterina Moraru (Valica)]

Hi,

XWiki/WikiMacros will list all the existing wiki macro on a wiki, but not
sure it this covers all your need.

Thanks,
Caty

On Tue, Jan 13, 2015 at 1:10 PM, ICLED c.lederm...@interact-consulting.com
wrote:

 How can I get a list of all *registered* macros?I know how to get a list of
 the XWiki.WikiMacroClass with the * Query Generator
 http://extensions.xwiki.org/xwiki/bin/view/Extension/Query+Generator  *
 extension, but it will not show if the macro is properly registered or
 not.I
 also want to get the attributes of a registered macros such as source
 document or built in, language...



 --
 View this message in context:
 http://xwiki.475771.n2.nabble.com/List-all-registered-macros-tp7593652.html
 Sent from the XWiki- Users mailing list archive at Nabble.com.
 ___
 users mailing list
 users@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/users

___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

[xwiki-users] [ANN] XWiki 6.4 Milestone 3 released

[Ecaterina Moraru (Valica)]

The XWiki development team is proud to announce the availability of XWiki
6.4 Milestone 3.

This milestone integrates the Ratings module inside platform, providing the
ability to rate extensions inside the Extension Repository and visualise
them inside Extension Manager. We have also added improvements for Flamingo
Skin on the responsiveness aspect, reintroduced the Wiki configuration
section in Administration and done massive work in augmenting the Mail
Sender API to be able to send large number of emails.

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/ReleaseNotesXWiki64M3

Thanks
-The XWiki dev team
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] Problem showing Menu Application on XE6.3

[Ecaterina Moraru (Valica)]

Hi Ramon,

I've just installed the Menu Application 6.3 on a XWiki Enterprise 6.3 and
it worked without a problem.
On Menu space, I've created a new menu entry, kept the default structure
and it worked.
Just make sure that for the 'Menu Display Location' property you set 'After
the Page Header' for example.

So maybe there is something in your particular setup that causes problems.

Thanks,
Caty

On Wed, Dec 17, 2014 at 12:38 AM, Ramon Gomes Brandão 
ramon.bran...@planejamento.gov.br wrote:

 Hi Xwiki Members,

 We're working on a brand new instance of our intranet using XE6.3. Despite
 the very nice new features, one of them - maybe the most important for our
 use case - is not working: the Menu Application. It was the first and only
 extension I've installed since now on a fresh new standard 6.3 using
 flamingo skin, following the instructions on the menu application page -
 http://extensions.xwiki.org/xwiki/bin/view/Extension/Menu+Application 
 http://extensions.xwiki.org/xwiki/bin/view/Extension/Menu+Application.

 I have only the Admin user so far. I've created the same sample menu using
 the app documentation, set to display after the page header, selected
 current wiki (tested all the options by the way) and nothing happened. The
 XWikiAdminGroup has programming rights selected. I've simply changed to
 colibri skin in WebPrefs look and feel section and also not worked.

 Am I losing any config/setup step? How can I check what's happening?

 I've not tested 6.4M2 yet, once it brings improvements on look and feel to
 Menu Application. I would like to learn and get the Menu working on 6.3
 first.

 Could you help me?

 Best Regards,
 --
 Ramon Gomes Brandão

 **

 **

 *RAMON BRANDÃO*


 ___
 users mailing list
 users@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/users

___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

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

[Ecaterina Moraru (Valica)]

I like it too.

What I would 'improve' is: when the dropdown is .open, have the
background-color also on entity name, not just the arrow.
This would mean removing 'background-color: transparent' from
'.navbar-nav.dropdown-split.open.dropdown-split-left'.

This way, you can clearly see the separation of link/action in normal mode,
but see the affiliation of the menu when open (also this is visible since
the menu starts under the entity name, not the arrow).

This is just a remark I have, but I'm waiting for more feedback from
others.

Thanks,
Caty


On Wed, Dec 10, 2014 at 6:17 PM, Marius Dumitru Florea 
mariusdumitru.flo...@xwiki.com wrote:

 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 guilla...@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 
  gdelhum...@xwiki.com wrote:
 
  +1, looks good.
 
  2014-12-08 12:59 GMT+01:00 Marius Dumitru Florea 
  mariusdumitru.flo...@xwiki.com:
 
   On Sat, Dec 6, 2014 at 11:02 PM, Denis Gervalle d...@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-xw...@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.flo...@xwiki.com
 À : XWiki Developers d...@xwiki.org; XWiki Users 
 users@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+Action+for+Flamingo+Menu
.
   
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 

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

[Ecaterina Moraru (Valica)]

+1

Thanks,
Caty

On Sat, Dec 6, 2014 at 11:02 PM, Denis Gervalle d...@softec.lu wrote:

 +1, ideally with a hover feedback very similar to the one of a dropdown
 button.

 On Fri, Dec 5, 2014 at 6:59 PM, Pascal BASTIEN pbasnews-xw...@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.flo...@xwiki.com
   À : XWiki Developers d...@xwiki.org; XWiki Users users@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+Action+for+Flamingo+Menu
  .
 
  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+for+Flamingo+Menu
  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@xwiki.org
  http://lists.xwiki.org/mailman/listinfo/users
 
 
 
  ___
  users mailing list
  users@xwiki.org
  http://lists.xwiki.org/mailman/listinfo/users
 



 --
 Denis Gervalle
 SOFTEC sa - CEO
 ___
 users mailing list
 users@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] I can not use less variable in a SSX

[Ecaterina Moraru (Valica)]

Hi,

http://jira.xwiki.org/browse/XWIKI-10708

Thanks,
Caty

On Fri, Dec 5, 2014 at 5:24 PM, Pascal BASTIEN pbasnews-xw...@yahoo.fr
wrote:

 Hello,
 In ./skins/flamingo/less/bootstrap/variables.less we found:
 //== Media queries breakpoints
 //
 //## Define the breakpoints at which your layout will change, adapting to
 different screen sizes.
 ...
 // Small screen / tablet
 //** Deprecated `@screen-sm` as of v3.0.1
 @screen-sm:  768px;
 @screen-sm-min:  @screen-sm;

 Then I want use screen-sm-min in a new SSX object but this doesn't
 work:@media (min-width: @screen-sm-min) {
   h1 {
 color: fuchsia;
}}(If I replace screen-sm-min with his value 768px, my SSX work well.)
 Is it normal than @screen-sm-min doesn't work in a SSX?Thxs
 Pascal B


 ___
 users mailing list
 users@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/users

___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

[xwiki-users] [ANN] XWiki 6.2.3 released

[Ecaterina Moraru (Valica)]

The XWiki development team is proud to announce the availability of XWiki
6.2.3.

This is a bug fix release with lots of issues fixed to stabilize the
Flamingo skin.

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/ReleaseNotesXWiki623

Thanks
-The XWiki dev team
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] Admin rights after migration

[Ecaterina Moraru (Valica)]

On Mon, Sep 29, 2014 at 6:49 PM, Moens Patrick 
patrick.mo...@curia.europa.eu wrote:

 Hi Vincent,

 I found the bug, or don't understand rights in new version of xwiki:)

 If I give the programing rights to XWikiAllGroup even if I block
 Adminstration rights to the group, all users have admin rights.

 I've uncheck programming rights and everything is ok, exept that users
 don't have results of scripts on pages.


Give one administrator you trust the programming right. Go over the pages
with scripts and re-save them with that Admin 's account. The scripts
should be fine.

Thanks,
Caty



 Patrick


 -Original Message-
 From: users [mailto:users-boun...@xwiki.org] On Behalf Of
 vinc...@massol.net
 Sent: Monday, September 29, 2014 4:15 PM
 To: XWiki Users
 Subject: Re: [xwiki-users] Admin rights after migration

 Hi Patrick,

 I don’t know about your problem (no bug has been reported on this so it’s
 probably some rights configuration issue) but I would really advise to
 install XWiki 6.2 (or wait for 6.2.1 which should be out this week,
 possibly tomorrow).

 Thanks
 -Vincent

 On 29 Sep 2014 at 15:52:38, Moens Patrick (patrick.mo...@curia.europa.eu
 (mailto:patrick.mo...@curia.europa.eu)) wrote:

  Hello ,
 
  I've a strange bug since Friday. I've installed a fresh xwiki 6.1 on
 tomcat/oracle 2 weeks ago and imported exported data from a old xwiki 2.3
 (but data have been migrated to xwiki 6.1 before export).
 
  Everything was ok until Friday. Now every users have admin rights but
 they are not in the admin group. They have access to all spaces,/docs.
 
  If anyone have an idea. I've check rights, and nothing change between
 pre production server and problematic prod :/
 
 
  PAtrick
 ___
 users mailing list
 users@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/users
 ___
 users mailing list
 users@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/users

___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] [Discussion] What trees would you like to see in the XWiki garden?

[Ecaterina Moraru (Valica)]

Hi Marius,

We need trees:
* for global vision/management: (AllDocs) doing crud operations on pages in
particular (but would be nice also to rename/move/delete spaces/wikis? )
* for navigation: in a panel that should list parent/child relation or
space/page relation for the current page/space.
* for selection: especially when doing import or multi-page exports
* for development: as you said a  full XWiki Entity Tree would be nice for
applications like AWM, but we would need also partial Entity Trees for
Class or Objects Editor (displaying objects and properties)
* for classification: any category/sub-category or folder/page type of
classification would need a tree (Blog Categories, File Manager, etc. ...
tags, photo albums, etc.) when the structure is user/defined based on a
parent/child relation

Things to consider:
* multiple views: wiki/space/page vs. parent/child
* multiple parent: simple parent vs. multiple parent classification (maybe
in case of tags, photo albums)

Wishes:
* Normal:
** I would like that we could use a consistent tree across XWiki
functionality.
** I wish we could have operations on tree entries (by dragdrop or just
from actions).
* Ideas:
** I wish users could define their own tree structures (not necessarily
having XWiki's two dimensions [parent/child and location] but maybe
defining a custom structure: example, I'm writing a book and I want to
organize the pages in chapters. Maybe I have some pages that I don't know
exactly in what chapter to put [orphan/hanging] or that could go in
multiple chapters )
** Change the display of a tree from vertical to horizontal (like a graph)
(could work for the book example)

Lacking:
* Normal:
** Navigation panel (when visualizing a space or even a wiki we could
display a contextual {{spaces/}} gadget in a panel that could be expanded)
** Documentation panel (of related pages displaying the parent/child
relationship)
** Multi-page export with entity selection
** Groups/Users
* Ideas:
** Dependencies Tree for applications installed with EM
** Roles/Rights vs. Inherited/Global/Locally set Rights Tree (kind of crazy
I know :) )
** Major / Minor versions history

Not sure exactly what you expected people to answer :) I tried to think of
all kinds of usages (not all are needed or realistic). Hope it helps.

Thanks,
Caty


On Thu, Sep 25, 2014 at 4:56 PM, Dmitry Bakbardin haru_mamb...@mail.ru
wrote:


 Hi, Marius!
 I would add also
 wiki  space  page  [anchor in a page]
 in the WYSIWYG editor.
 + one more vote for:
 1. wiki  space  page  [translations | attachments | objects |
 classProperties]  object  objectProperties
 2. parent page  child page
 I'm almost happy with this macro:
 http://extensions.xwiki.org/xwiki/bin/view/Extension/HierarchyMacro
 It has very important feature: EDITABLE tree - one can change order of
 pages in the tree and page's parent by moving it up or down.
 I'm using it now as a TOC of space. This macro has few critical bugs,
 e.g.  http://jira.xwiki.org/browse/HIERARCHYM-5
 Also I'd be completely happy to have an option Blacklisted pages list in
 each and every tree/macro.


 Kind regards,

 Dmitry


 Thu, 25 Sep 2014 16:04:57 +0300 от Marius Dumitru Florea 
 mariusdumitru.flo...@xwiki.com:
 Hi guys,
 
 There are a couple of places in XWiki where we use trees to display
 structured / hierarchical data. Are trees a good solution for data
 visualization in those cases? Can those trees be improved? Are there
 other places in XWiki where you would like to see a tree?
 
 Let me review some of the trees we currently have:
 
 1. Document Index Tree
 
 wiki  space  page  [attachments | page]
 
 This tree is also used in the WYSIWYG editor when you create a link to
 a wiki page or to an attachment. It shows the spaces on the first
 level and then under each space the parent-child hierarchy of
 documents from that space. If a document has attachments then a
 special child node is added. The tree can also display wikis on the
 first level and then spaces on the second.
 
 So it mixes two hierarchies: wiki  space  page  attachment and
 parent  child. This can be confusing. For instance Blog.WebHome has
 Main.WebHome as parent, but you don't see Blog.WebHome under the
 Main.WebHome node in the tree because it is in a different space.
 
 2. XAR Import
 
 space  page
 
 This is a very simple tree with only two levels. I don't have any
 problem with it. Would be cool if it would show more information, like
 attachments or objects, but it's a bit more complex to get this kind
 of data from the XAR without reading the documents first.
 
 3. Dynamic Hierarchy Macro (
 
 http://extensions.xwiki.org/xwiki/bin/view/Extension/Dynamic+Hierarchy+Macro
 )
 
 parent page  child page
 
 Unlike the Document Index Tree, this tree uses only the parent-child
 hierarchy. You don't see the spaces but at least you get the full
 parent-child hierarchy. This time Blog.WebHome is a child of the
 Main.WebHome node.
 
 I'm not sure it's better than the Document