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  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&Continue" 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 
>> >> 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 
>> >>> wrote:
>> >>> >
>> >>> > > Hi Caty,
>> >>> > >
>> >>> > > I am a fan of “B”.
>> >>> > >
>

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&Continue" 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 
>> 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) >> >:
>>>
>>> > On Wed, Apr 26, 2017 at 5:41 PM, Craig Wright 
>>> 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 mobi

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 
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 
> Subject: Re: [xwiki-users] [Proposal][UX] Feedback for Explicit Content
> Actions
>
>
> > On 28 Apr 2017, at 09:57, Ecaterina Moraru (Valica) 
> wrote:
> >
> > On Fri, Apr 28, 2017 at 10:47 AM, Clément Aubin
> > 
> > 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 
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 
> 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) :
>>
>> > On Wed, Apr 26, 2017 at 5:41 PM, Craig Wright 
>> 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 > > > <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
>> > > >> trans

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 
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) :
>
> > On Wed, Apr 26, 2017 at 5:41 PM, Craig Wright  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  > > <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 inte

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 
> 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) 
> > 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 
> >> 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  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  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 Explicit Content Actions

[Ecaterina Moraru (Valica)]

On Wed, Apr 26, 2017 at 5:46 PM, Craig Wright  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) 
> > 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 
> >> 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  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  <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/Sandb

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 
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  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&View", 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
> &

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

[Ecaterina Moraru (Valica)]

On Wed, Apr 26, 2017 at 1:11 PM, Mahomed Hussein 
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 
> 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 
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 
> 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

[xwiki-users] [ANN] XWiki 9.3 released

[Ecaterina Moraru (Valica)]

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

This release brings a couple of small, but very useful improvements like:
* the ability to filter the sections in Administration,
* reset changes done to extension pages and
* alternative configuration locations.

Developers also get:
* some helpful API in writing clean queries when escaping and filtering,
* a new API to find documents belonging to extensions and
* more control through a new extension point for the content menu

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

Thanks for your support
-The XWiki dev team

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

[Ecaterina Moraru (Valica)]

; >>>>
> >>>>> On 21 April 2017 at 15:28, Vincent Massol 
> 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
> >>>>>>
> >>>>>>>
> >>>>>>> Thank you
> >>>>>>&g

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] display page title and name(url) while creating a page

[Ecaterina Moraru (Valica)]

Let's see what variants we have:

1. Instead of displaying "Title", display the "Name" instead.
This won't solve anything. There is no difference between Page Name and
Page Title for the normal users. Seeing "Name" instead of "Title", will not
stop the users to enter spaces if they want, so the URL will still have
those spaces. We don't force the Page Names to trim spaces.

One quick solution here is indeed to use "URL" label instead of "Name". For
the reasons Vincent mentioned this might not end up in the product for now,
so you will need to do some custom development (changing some translations)
to have this change. If you want to be "hackish" you can even change the
translation for "Title" to "URL" instead and hope that your users will
enter shorter URLs (since we generate the name from the title).

Displaying just Name / URL, means users will still have to go and change
the title manually. The only way to cut a step in the flow is to
autogenerate the page names (which we currently do). But for your use case
you shoyld write a shorting/trimming algorithm, but this is custom, since
you mentioned you want just the initials and no spaces, etc.

2. Displaying both "Title" and "Name". This will create confusion and need
for explanations. That's why we display these options just for advanced and
long-time users of XWiki, since they are used to the concepts.

-

IMO what you are describing is advanced user behavior. Normal users don't
generally care about their URLs and SEO. But the beauty of XWiki is that
you can customize it locally to perfectly match your needs.

Vincent mentioned something about AWM. I don't see much difference from the
Create Page. We generate the names from title here too. We display them in
the breadcrumb, but in a more simple way. Displaying the "localhost"/server
part is not simple user behavior. AWM is more complex.

-

So I would not change anything on the product side, since I believe these
should be solved as custom changes for your instance.
We want to encourage users to use page titles (with spaces in them since
they are more readable and supported), while we are preserving the page
name behavior for advances users (but we don't enforce it). If users made
mistakes they can always change the title or rename the page.

On the product side the only change I would like us to do is using the URL
naming, but this was debated in the past and dropped for Vincent's reasons.

Thanks,
Caty


On Thu, Apr 20, 2017 at 11:57 PM, Vincent Massol  wrote:

>
> > On 20 Apr 2017, at 22:51, Vincent Massol  wrote:
> >
> > Hi Vishal,
> >
> > Ok, I misunderstood you in your first email. I understood the opposite.
> I thought you were complaining that have 2 notions (page name + page title)
> was confusing but it’s actually the opposite! What you find confusing is
> the fact that it’s not easy for your users to set both the page name and
> page titles!
> >
> > It’s funny (or not :)) since this is exactly what we had in past
> versions of XWiki and we had several complaints that it was confusing to
> have the 2 notions and this is why he hid the page name only for advanced
> users.
>
> Actually, if I remember well, what we were doing was to ask for the page
> name and we were setting the title to the same as the page name by default
> and then the user could edit the title before saving the page.
>
> We’ve now done the opposite (user deciding on the title and page name
> being derived from it) but leading to the issue you’re raising about URL
> SEO…
>
> Thanks
> -Vincent
>
> > See below.
> >
> >> On 20 Apr 2017, at 14:20, Vishal  wrote:
> >>
> >> Thanks Vincent for your thorough reply..
> >> You guessed it right. We intend to have clean and short urls for SEO
> >> reasons.
> >> Current scheme creates two problems:
> >>
> >> 1) The Page name is fetched automatically from the Title. Often the
> titles
> >> have spaces which translate as *percent characters *in url which makes
> it
> >> somewhat unclean :)
> >
> > Indeed you’re right. By hiding the page name we’re now incitating to
> have longer URLs and encoded characters showing up in URLs which is not
> nice I agree.
> >
> > Maybe one solution is to do something similar to what we do in AWM, i.e.
> generate automatically the URL from the title entered by the user and show
> the resulting URL to the user and give the user the opportunity to change
> the URL.
> >
> > See http://extensions.xwiki.org/xwiki/bin/download/Extension/
> App%20Within%20Minutes%20Application/AppWithinMinutes-Step1.png
> >
> >> 2) Secondly, to have the shorter url, we use only the short forms of
> >> complete title.
> >> Ex. For title 'Pune University' we use name PU.
> >
> > Hey, you’re from Pune? :) I’ve been there about 15 times! That was in a
> previous job where my company and KPIT Cummins were partners.
> >
> >> Otherwise in this hierarchy of pages, the url would be much longer.
> >> Ex. We have page 'Electronics and Telecommunications' branch under page
> >> 'Pune Univ

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 
> 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) :
>>
>> > 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 

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  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) :
>
> > 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 
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)  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  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/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 
>> > 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)  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] [xwiki-devs] Re-organize the Drawer's entries

[Ecaterina Moraru (Valica)]

On Tue, Nov 15, 2016 at 4:18 PM, Guillaume Delhumeau <
guillaume.delhum...@xwiki.com> wrote:

> According to your suggestions, I have started some iterations in a real
> wiki.
>
> Proposition 8, iteration 1
> ==
> http://jira.xwiki.org/secure/attachment/33243/P8_iter1.png
>
> * Same wording
> * Separation between wiki-related items and global items
> * Remove "Home", because it's already in the breadcrumb and it is not
> necessary to have it in this "often used features" menu.
>  "Create Wiki" and "Delete Wiki", because it should be done inside the Wiki
> Index.
>
>
Some remarks:
- We don't use officially the "subwiki" term. We have just "Wiki", see
http://markmail.org/message/cehvpds5qmljq5f7
- In Olivier's proposal there was also the name of the subwiki which was
somehow interesting
- There is an inconsistency between "Subwiki" and "Global actions" ... they
should be similar in terms of naming structure (with or without "actions")
- If you remove "Create wiki" and "Delete wiki" then I don't see such a
need for the "subwiki-global" separation, since "Wiki Index" will be lonely
-- We said we move "Create wiki" in the Wiki Index, but there we will have
other problems in terms of displaying the option: will be make it part of
the Create step? Do we create a separate button for it? How do we display
it?
- For wikis that allow just local users, the breadcrumb home doesn't take
you to the Global home, but removing "Home" won't impact in this case,
since apparently we don't display Home at all in this case. The problem is
that for these cases, the users won't know how to go back to the main wiki.



> Proposition 8, iteration 2
> ==
> On subwiki:
> http://jira.xwiki.org/secure/attachment/33245/P8_iter2.png
>
> On main wiki:
> http://jira.xwiki.org/secure/attachment/33246/P8_iter2_mainwiki.png
>
> * Same but with a more human wording
> * Applications is displayed before users, because I think we more often
> need to use an app than we need to see other users
>

- Administration is a "human" wording and also it's used across our
documentation and interface. Also it goes hand in hand with the
Administrator user. I don't see big improvements in changing to the
"Settings" wording.
- There is a problem with "All Users" since in some setups, where you have
local users, that link won't take you to "all" users. Again hard to say
that it's really a correct separation.
- Regarding the order, we should define a rule. It could either be
alphabetical or usage (although that is hard to compute). With the mention
that extremes are easier to access. So for example first and last items in
a list are easier to access than intermediary items: so placing users after
applications, because applications are more used, it will have the
consequence that, being the last item in the list, it will make Users be
easily to access than Applications.


>
> Proposition 8, iteration 3
> ==
> http://jira.xwiki.org/secure/attachment/33247/P8_iter3.png
>
> * Same but introduced the "Recent Changes" entry (leads to an Activity
> Stream maybe)
>

- Regarding the "Recent Changes" this could be see as application, so it
could be available in the Application Index (kind of is, but as part of
Dashboard).


>
> My conclusions
> ===
>

- The problem is that if I read my comments and I remove the P8's
subwiki/global separation (since Wiki Index is alone) + remove the "Create
and Delete wiki" since we say they will be available in Wiki Index, remove
the Home navigation since we rely on breadcrumbs, plus we keep the same
wording, but maybe change a bit the Index order, we will have P9:
http://jira.xwiki.org/secure/attachment/33250/P9.png

And it doesn't quite have much of a change in it if we compare it to the
current version. This might be good or bad. Following Jan-Paul comment that
we should not advertise for 'Delete wiki' and that 'Create wiki' is very
rare, we might say P9 contains just the needed elements: Administration +
Indexes.

Since the only difference between simple users and admins would be the
"Administration", we could have it last as P9.1 + try a simpler naming:
http://jira.xwiki.org/secure/attachment/33251/P9.1.png

But now we will need to find a way to Create wikis.

---

Now regarding Index naming. If we use:
- Manage: for example "Manage Wikis", it will be harder to make it
consistent with the other Indexes, since for example User Index does not
provide the management setting (they are in administration). Also for
simple users, manage verb doesn't mean anything.
- All: all is complicated for farm setup, where "All Users" might mean just
local users, same for Applications and Pages, since they are just local, so
they are not all.
- Index: it is a bit more ambiguous, but it better satisfy the duality of
content.
- //simple: Having just "Pages", "Users", etc. can be also a solution.

---

Regarding Olivier's comment about "Recent changes" (in P7). I agree that
the majority of wikis provide it, s

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

[Ecaterina Moraru (Valica)]

On the issue Olivier also did another proposal P7
http://jira.xwiki.org/browse/XWIKI-13070
so make sure you read also that.

Guillaume would be possible to have a visual proposal for the partial
changes you mentioned you would like to do?
Ideally we should have like 2 (max 3) images in order to vote on them or
reiterate until everybody is happy.

Thanks,
Caty

On Mon, Nov 14, 2016 at 1:26 PM, Guillaume Delhumeau <
guillaume.delhum...@xwiki.com> wrote:

> OK so now it's a bit more than only re-organizing the drawer's entries.
> Your proposition is also about removing some elements, and renaming some of
> them. We are more closer to your original issue (
> http://jira.xwiki.org/browse/XE-1582).
>
> It's a big change that we usually don't do at the end of a development
> cycle.
>
> Concerning its content, and more precisely the renaming of the items, I
> would love to read the opinion of committers. For example, I agree it looks
> more natural to see "All users" than "User Index" or "All other wikis"
> instead of "Wiki Index" in a subwiki, but it breaks the famous consistency
> principle we tend to have.
>
> I also like "Settings" instead of "Administration", but we could even go
> deeper and say "Settings of the wiki" to not confuse with "User Settings".
>
> You also propose a "Recent Changes" item, which could lead to the Activity
> Stream. Should I open a new discussion about this?
>
> For now, I could change the order of the elements, and introduce 2
> categories: "items concerning the current wiki", and "items concerning the
> main wiki". It's already a breakage from the UI Extension API point of
> view.
>
> Thanks,
>
> 2016-11-03 10:01 GMT+01:00 Guillaume Delhumeau <
> guillaume.delhum...@xwiki.com>:
>
> > Yes Miroslav, we have received your message. Thanks you :)
> >
> > 2016-11-02 23:13 GMT+01:00 Miroslav Galajda  >:
> >
> >> Hi, I've sent an email with preference for P5, last week. Have you
> >> received
> >> it?
> >>
> >> P5 seems to me clean and logical to work with.
> >>
> >> Thanks
> >> Mirec
> >>
> >> On 2 November 2016 at 11:23, Guillaume Delhumeau <
> >> guillaume.delhum...@xwiki.com> wrote:
> >>
> >> > Hello.
> >> >
> >> > Thanks for your comments. Any other?
> >> >
> >> > Guillaume
> >> >
> >> > 2016-10-26 17:03 GMT+02:00 Jan-Paul Kleijn :
> >> >
> >> > > P5 is also my favorite because it draws more attention to the
> content.
> >> > > It's the more grown-up version.
> >> > >
> >> > >
> >> > > Op 26-10-2016 om 10:28 schreef Guillaume Delhumeau:
> >> > >
> >> > > No opinion?
> >> > >>
> >> > >> 2016-10-24 18:09 GMT+02:00 Guillaume Delhumeau <
> >> > >> guillaume.delhum...@xwiki.com>:
> >> > >>
> >> > >> Hello dear developers and XWiki users.
> >> > >>>
> >> > >>> I would you to take a look at the issue
> >> http://jira.xwiki.org/browse/
> >> > >>> XWIKI-13070.
> >> > >>>
> >> > >>> The problem is that the current order (that I have implemented
> >> based on
> >> > >>> my
> >> > >>> intuition) seems to not be clear for our users. The main point is
> >> that
> >> > >>> the
> >> > >>> menu mixes up global items (Home wiki, Wiki Index) and local ones
> >> > >>> (Administer Wiki, Page Index, Delete wiki, etc...).
> >> > >>>
> >> > >>> Caty and Oliver have made some proposals that you could find in
> the
> >> > >>> issue.
> >> > >>>
> >> > >>> They are called P1, P2, P3, P4 and P5.
> >> > >>>
> >> > >>> I propose you to express your preferences so we can implement it
> >> based
> >> > on
> >> > >>> a consensus.
> >> > >>>
> >> > >>> Here are mine:
> >> > >>>
> >> > >>> P1: There is a logical order and separation between item. However,
> >> it
> >> > >>> seems the more used actions (Wiki Index, Page Index) are less
> >> visible
> >> > >>> than
> >> > >>> some other (Delete Wiki, Create Wiki...)
> >> > >>>
> >> > >>> P2: The order and the separation are logic. The "delete wiki"
> >> action is
> >> > >>> still very visible but all other items are good.
> >> > >>>
> >> > >>> P3: Same than P2. Except that having "Wiki Index" along with
> "User,
> >> > Page
> >> > >>> and Application Index" mixes up local and global items.
> >> > >>>
> >> > >>> P4: Why not, but maybe the 3 first actions should be placed after
> >> the
> >> > >>> other ones, since they would be less used. Same remark about the
> >> mixing
> >> > >>> of
> >> > >>> local and global items.
> >> > >>>
> >> > >>> P5: A clear distinction between local and global scope. More used
> >> items
> >> > >>> are located first. This is my favorite one.
> >> > >>>
> >> > >>>
> >> > >>> So +1 for P5, +0 for the other options so far.
> >> > >>>
> >> > >>> Now, what about you?
> >> > >>>
> >> > >>> Thanks,
> >> > >>> Guillaume
> >> > >>>
> >> > >>> PS: I send this message to both devs and users mailing lists,
> >> because I
> >> > >>> think users are directly concerned by this topic.
> >> > >>>
> >> > >>> --
> >> > >>> Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
> >> > >>> Research & Development Engineer at XWiki SAS
> >> > >>> Committer on the XWik

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 consis

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), ?

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 list

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
>>
>>
>>
>> 
>> From: users  on behalf of Ecaterina Moraru
>> (Valica) 
>> 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
>> >
>> >
>> >
>> > ___
>> > 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  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
>
>
>
> 
> From: users  on behalf of Ecaterina Moraru
> (Valica) 
> 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
> >
> >
> >
> > ___
> > 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)]

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  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
> 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] Wanted pages as siblings

[Ecaterina Moraru (Valica)]

On Sat, Sep 24, 2016 at 2:09 PM, tskala  wrote:

> According to
> http://xwiki.475771.n2.nabble.com/Include-Macro-Usage-tp7597998.html and
> http://jira.xwiki.org/browse/XWIKI-13148
>
> Is there any switch to make non-existent links create sibling pages rather
> then children?
>

We don't have this behavior customizable. XWIKI-13148 implemented the
default, which is creating children.


>
> We are trying to use xwiki as a wiki. Meaning we have many terms that
> interlinks between each other. Atm. it hits "almost unusable" barrier :/
>
> Using Ecaterina Moraru (Valica) example:
>
> [[TestMain]]
> [[TestMain1]]
> [[TestMain2]] - new link
>
> results in:
>
> http://localhost:8080/xwiki/bin/view/Main/TestMain/
> http://localhost:8080/xwiki/bin/view/Main/TestMain1/
> http://localhost:8080/xwiki/bin/view/Main/TestMain1/TestMain2/
>
> In this case TestMain2 cannot use [[TestMain]] nor [[TestMain1]] links
> (another great inconvenient for "wiki", but let's put that one aside).
> Given
> there is no parent linking, we need to use absolute path for any and all
> links that actually goes to other branches, which is inconvenient on its
> own. But with unrestricted "create new links as children by default" it
> means hell.
>

The 'simple' references (using 1 word) are always relative to the current
page, looking first for siblings and after for children. If you want
something from top, yes you need to use absolute references.


>
> Even worse, creating new page from link doesn't offer any choice of
> correcting parent, so atm. non-existent links are liability because they
> must not be under no circumstances clicked or they create unwanted children
> where no links will work.
>
> And to extend the bad things.. we use templates. There are more of them so
> we need to restrict templates just to specific departments they are meant
> for. But template provider's visibility restriction seems absolute. It
> doesn't extend to children of checked parent.


This was fixed in http://jira.xwiki.org/browse/XWIKI-13290 in 8.1

Another improvement you might find interesting for template providers is
http://jira.xwiki.org/browse/XWIKI-8759 for 8.3-M2.

Maybe you can test your use case on 8.3-M2 and see if it's an improvement
from what we had in 8.0.

Thanks,
Caty


> Which is also bad, because we
> cannot even create children easily as they won't see templates they need
> to.
> But it also means [[TestMain2]] from above example cannot even be created
> using template because with "always child link" it doesn't see templates
> defined for [[Main]].
>
> I tried to make [[TestMain1]] terminal page even if it's not recommended
> (nor wanted really) but it didn't help. [[TestMain2]] is still offered as
> [[TestMain1/TestMain2/WebHome]]. And since it's a child it won't see
> templates defined for [[Main]] even when it should because we need
> templates
> for entire branch, without the need to manually administrate every new
> nested page created so its pages can use templates as well.
>
> Any way out of it? Config param to make new links siblings and
> [[.TestPage1]] for explicit child would solve the worst problems. Offering
> the same dialog as for new pages so parent could be fixed manually each
> time
> would at least help. But links are already pretty hard to use (again, for a
> wiki; namely anchors and pages from other branches) to make it even harder
> (with something like mandatory [[..link]] added to every link there is)
>
> Using v.8.0
>
>
>
> --
> View this message in context: http://xwiki.475771.n2.nabble.
> com/Wanted-pages-as-siblings-tp7601368.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] 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

[xwiki-users] [Community] Help needed in testing XWiki 8.2

[Ecaterina Moraru (Valica)]

Hi XWikiers,

We need your help in testing 8.2-RC1 in order to have the best quality for
the 8.2 final release.
You can download from
http://www.xwiki.org/xwiki/bin/view/Download/DownloadVersion/?projectVersion=8.2-rc-1

The release of version 8.2 was planned for 18 Jul, but we want to delay it
by a week in order to have the maximum time to test the new features.

There are a lot of improvements, you might like and be interested in:
- CKEditor Becomes the Default WYSIWYG Editor
- New Homepage
- New Tour for the Homepage
- Application Index, Template improvements, Livetable improved filtering,
available syntaxes configuration and many others. You can read a partial
release note at
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki82

Issues found can be reported on http://jira.xwiki.org/browse/XWIKI

Thank you,
Caty
___
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  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
>
>
>
> 
> From: users  on behalf of Ecaterina Moraru
> (Valica) 
> 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
> >
> >
> >
> > ___
> > 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] 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  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] 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  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] 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  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] 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  wrote:

> Can a dev look at the release notes of the  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] [xwiki-devs] The future of the Spaces macro in the context of Nested Spaces/Documents

[Ecaterina Moraru (Valica)]

Hi,


On Fri, Jun 12, 2015 at 1:30 PM, Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> wrote:

> Hi guys,
>
> The wiki home page displays, by default, the list of spaces that exist
> in the wiki (hidden or not, depending on the user profile settings).
> This is done using the
> http://extensions.xwiki.org/xwiki/bin/view/Extension/Spaces+Macro . As
> we have started to work on adding support for nested spaces/documents,
> we need to review the purpose of this macro. Is it still relevant to
> display a list of spaces when there is a tree hierarchy? It only makes
> sense if you want to display just the list of direct children of a
> given node.
>
> I see the following options:
>
> (1) Display the list of top level nodes (space/document) on the wiki
> home page. No tree. The rationale is that loading the tree (even if
> done lazy) is more expensive that displaying a static list of links.
> For this we can extend the Spaces Macro with a parameter to specify
> the parent node. When this parameter is not specified the macro will
> list the top level nodes. (In the context of nested documents we could
> introduce a new macro Document List instead)
>

This direction could mean something like this:
- Main Wiki:
http://design.xwiki.org/xwiki/bin/download/Improvements/WorkspaceHomepage/Home.png
- Subwiki (+ Nested Space):
http://design.xwiki.org/xwiki/bin/download/Improvements/WorkspaceHomepage/WorkspaceTech.png

So for example the main wiki display the list of wikis, while the subwiki
list the immediate spaces. If you want to go to the nested spaces structure
you would need to enter the wanted spaces in order to see it's children.

My main problem with this approach is that this works when we have
dedicated WebHomes, like until now.
With Nested Documents, the document will not be hubs anymore (listing
children and activity), but they could be content documents where the
spaces macro has no point in being displayed.

Another usage of this macro was when importing the Dashboard inside a space
and it listed the 'Documents in space X' + Activity Stream.
This view mode was an alternative in providing a livetable.

The main advantage of this macro was the ability to create spaces. Not sure
how many users created spaces this way or accessed the Administration and
Document Index shortcuts.



So let's say we don't need to have actions and create and we will use the
macro just for navigation.



>
> (2) Display the tree hierarchy on the wiki home page, using
> http://extensions.xwiki.org/xwiki/bin/view/Extension/Document+Tree+Macro
> .Of course, the tree will be lazy loaded, and only the top level nodes
> are displayed initially. If we do this then we can probably deprecate
> the Spaces Macro and advice the users to use the Document Tree Macro
> instead.
>

With nested documents and without the actions, I find the Document Tree
Macro to be more powerful, since it's not restricting you to load a page in
order to see it's children. You can browse easy the structure. I see the
Document Tree Macro as a more modern version of the Spaces Macro, so I am
ok to deprecate it. (We need to make sure what we do with Tags Application
and Information Tab in docextra, since we could make some changes also
there).

My comment regarding the document tree is would it be useful inside the
content. Since we will not have WebHomes anymore we will have less demand
for spaces dashboards.

There was an older idea of creating a left panels switch for appbar and
hierarchical navigation, see
http://design.xwiki.org/xwiki/bin/view/Proposal/AppBar#HFunctionalityExtensibility

This would imply moving the Spaces Functionality from content to panels.



Conclusion:
- With nested documents there will be a less demand for WebHomes dashboard
since they will be replaced with content.
- Modifying Spaces Macro with a parent parameter is not the only change
this macro will need, since we would need to also normalize the
'Administration', 'Document Index', 'Create' actions;
- We will still have the wikis dashboards that can list hierarchy,
activity, members;
- We could display Document Tree in the content as a replacement for Spaces
Macro, or we could make the panels more easily configurable / switchable
between 'AppBar'/'Hierarchy'/'Custom Content'.

Thanks,
Caty


>
> WDYT?
>
> Thanks,
> Marius
> ___
> 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] 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,  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 
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
>  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
> >>  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)]

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 
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 
> 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] Printing pages as displayed

[Ecaterina Moraru (Valica)]

On Thu, May 7, 2015 at 1:46 PM, Mahomed Hussein 
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] 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 
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 
>  À : Maciej Fokt ; XWiki Users 
>  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  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
> &

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  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  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 :
>
> > On Sat, Apr 4, 2015 at 12:23 PM, Eduard Moraru 
> > 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 
> 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-comm

[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)]

I'm glad that you solved your problem.

Have fun,
Caty

On Wed, Mar 18, 2015 at 7:42 PM, MishaK  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] 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  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)]

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  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)]

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  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] [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  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 :

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