Hi all,
For the 9.1 roadmap, see
http://www.xwiki.org/xwiki/bin/view/Roadmaps/#HXWiki9.0-9-2, Caty and I
have worked on a Help Center to cover the "Demo Content" and (partially)
the "In-Product Tours and Documentation" topics. I opened this issue
http://jira.xwiki.org/browse/XWIKI-14018 to follow the progress. I
committed a first working version on
https://github.com/xwiki/xwiki-platform/tree/feature-help-center .
I committed the code in platform mainly because we already have a
xwiki-platform-help-ui module which is related, but we can discuss putting
the help center in a different place:
* either a separate child module of xwiki-platform-help (to separate the
help center from the rest of the help pages like the XWiki syntax help and
the tips panel)
* on xwiki-contrib
Caty named it "Help Center" in the initial proposal, then used "Help" in
the prototype. We need to decide which one is best. I'm fine with both. The
version I committed uses "Help Center".
The help center pages have quite a few images and 4 big gifs (animated
steps) which leads to a 22Mb XAR. I hope the size won't cause any issue. It
may slow down the XWiki Enterprise functional tests setup?
Caty and I would like to put the help center pages on playground.xwiki.org
so that we can measure if it's useful (without having to wait for the
playground wiki to be upgraded to XWiki 9.1).
WDYT?
Thanks,
Marius
Hello,
Is there a way to customize default location for new pages?
(Added later - I figured it out, I'm leaving the previous steps of how
and why)
I set up a new XWiki (9.0) from scratch, created "Public" space,
configured it so non-admins don't see anything else, switched it to
default both in web.xml "homePage" param and Admin -> Descriptor ->
Homepage "Public.WebHome", everything works as intended, but when I'm at
host/bin/view/Public/ and I click "Plus icon (Create)" it offers to
create a new page at top level "home /", while I want it to select "home
/ Public /" by default, which I assume would be a reasonable behavior.
Is it possible?
>From what I checked it's handled in file skins/flamingo/menus_content.vm ?
"#macro(displayCreateButton)
<div class="dropdown" id="tmCreate">
<a href="$doc.getURL('create')" role="button"
title="$services.localization.render('core.menu.create')"><span
class="glyphicon glyphicon-plus"></span></a>
</div>
#end"
Any suggestions on how to change it?
I tried replacing the lines:
<div class="dropdown" id="tmCreate">
<a href="$doc.getURL('create')" role="button"
title="$services.localization.render('core.menu.create')">
<span class="glyphicon glyphicon-plus"></span></a>
</div>
With:
#set( $parentEqualsDocFullName =
"parent=$escapetool.url($doc.getFullName())" )
<div class="dropdown" id="tmCreate">
<a href="$doc.getURL('create', $parentEqualsDocFullName)" role="button"
title="$services.localization.render('core.menu.create')">
<span class="glyphicon glyphicon-plus"></span></a>
</div>
Turns out it just ends up being ignored.
(Added later) Also, as I understand now it would be redundant.
After some googling I found createinline.vm, lines 239-243
#if ($parentReference.equals($homeReference.lastSpaceReference))
## We want to discourage ending up with all the pages children of the
homepage so we
## default to top level documents, unless the user explicitly says
otherwise.
#set ($parentReference = $parentReference.wikiReference)
#end
Actually that's exactly what I want. I'm trying to comment out the 4th line.
Restarted, it worked.
It all seems a bit counterintuitive, could you please consider making it
configurable, in "xwiki.properties" maybe?
Why exactly is it "discouraged"? Is it only a matter of "style" or are
there any potential complications I'm unaware of?
Greetings, Lilianne
Thanks Denis for the feedback.
Done, it’s now deleted :)
The official image is now the first one… Come on xwiki users, let’s get this pull number increased now! (7 pulls already)
https://hub.docker.com/search/?isAutomated=0&isOfficial=0&page=1&pullCount=…
Thanks
-Vincent
> On 9 Feb 2017, at 13:48, Denis GERMAIN <dt.germain(a)gmail.com> wrote:
>
> Agreed,
>
> The longer you leave it, the longer people might use it instead of the
> official. As of today, the official isn't even the first to appear in the
> list when you search for xwiki in dockerhub (but I suspect this will soon
> change as people start pulling it).
>
> And people who already have pulled it won't be affected aside from the fact
> that they won't get updates, so no impact for them.
>
> Regards,
> Denis
>
> 2017-02-09 11:40 GMT+01:00 Vincent Massol <vincent(a)massol.net>:
>
>> Ok so now that we have an official xwiki image on dockerhub at
>> https://hub.docker.com/_/xwiki/ we need to decide what we do with
>> https://hub.docker.com/r/xwiki/xwiki-mysql-tomcat/
>>
>> I think we should remove it to avoid confusion.
>>
>> Anyone having any issue with me removing it now? WDYT?
>>
>> Thanks
>> -Vincent
>>
>>> On 16 Jan 2017, at 18:37, Vincent Massol <vincent(a)massol.net> wrote:
>>>
>>> Hi everyone,
>>>
>>> I’ve started a first version of a XWiki docker packaging at
>> https://github.com/xwiki-contrib/docker-xwiki and I’ve created an
>> automated build on DockerHub at https://hub.docker.com/u/xwiki/. The goal
>> is to provide an official packaging done by the XWiki dev team.
>>>
>>> Since I’m a recent user of Docker I’m sure I’ve made plenty of mistakes
>> and not following some best practices, even though I’ve tried my best to do
>> that ;)
>>>
>>> So it would be great if:
>>> * Some users could try it out and let me know how it works
>>> * Users could tell me what they’d expect in term of setup from a docker
>> distribution.
>>> * Some Docker experts review my code and let me know what I should
>> improve!
>>>
>>> After I receive some confirmation that it works well-enough, my goal is
>> to document it as an official way of installing xwiki on xwiki.org.
>>>
>>> Feel free to create jiras for ideas and bugs at
>> http://jira.xwiki.org/browse/XDOCKER.
>>>
>>> Thanks a lot!
>>> -Vincent
>>>
>>> PS: Note that I’m sure some will want a different DB, such as postgreSQL
>> for example. That should be easy to do. Pull request accepted! :)
>>>
>>
>>
Hi devs,
We have a unintended regression in the standard import: if what you
import is identical to what is already in the database (including the
author) it won't add a new version (if you use the default option "Add
a new version to the existing page").
What happen in practice is that if you keep calling XWikiDocument#set*
methods with the same data it won't update the metadata or content
dirty flags. This flags are what hibernate store look at to know if it
should add a new version or not.
You can reproduce the same behavior with a simple script which load a
document, always set the same content and save. You will notice that
the history of that document does not change.
So the question is do we force metadata dirty to true all the time in
the instance output filter or do we keep this feature (in which case
we should optimize it a bit to not do the useless XWiki#saveDocument
but that's another subject).
WDYT ?
It could be seen as a nice feature but in practice my first reaction
was WTF and you often want to be sure the import actually did
something so I'm +1 to force metadata dirty. But I'm +0 to keep the
current behavior if there is a majority for it.
--
Thomas Mortagne
Hi devs,
Right now we’ve started acknowledging the committers in the Release notes.
I’d like to propose to extend that try to ack everyone who participates in one way or another to a release, and not just developers.
I can think of 3 more items to add:
A) All the JIRA issue reporters that have had an issue fixed for the release (bug, improvement, new feature, etc). They took the time to report an issue and thus they’ve helped the committers to improve the quality of the release and thus they should be acknowledged. This allows us to also ack QA. We could decide to exclude the reporters who’ve also been committers or leave them in.
B) The people who’ve contributed translations done after the start of the release development.
Ideally we would also ack:
C) The people who’ve helped on the list for the release
D) The people who’ve helped on the Design and made proposals that made it to the release. I’m thinking of Caty for example. Luckily Caty also commits some code and often she’s recognised through commits.
The problem with C) and D) is that they’re hard to gather. But we could do it on an ad-hoc basis by adding them to the RN during the development (when they help) instead of doing it at the end.
In any case I’d like to focus on A) and B) FTM and I’m proposing to add them to the Release Plan since they’re easy to find out.
WDYT?
Thanks
-Vincent
Hi everyone,
I’ve started a first version of a XWiki docker packaging at https://github.com/xwiki-contrib/docker-xwiki and I’ve created an automated build on DockerHub at https://hub.docker.com/u/xwiki/. The goal is to provide an official packaging done by the XWiki dev team.
Since I’m a recent user of Docker I’m sure I’ve made plenty of mistakes and not following some best practices, even though I’ve tried my best to do that ;)
So it would be great if:
* Some users could try it out and let me know how it works
* Users could tell me what they’d expect in term of setup from a docker distribution.
* Some Docker experts review my code and let me know what I should improve!
After I receive some confirmation that it works well-enough, my goal is to document it as an official way of installing xwiki on xwiki.org.
Feel free to create jiras for ideas and bugs at http://jira.xwiki.org/browse/XDOCKER.
Thanks a lot!
-Vincent
PS: Note that I’m sure some will want a different DB, such as postgreSQL for example. That should be easy to do. Pull request accepted! :)
Hello,
Can someone please create the repository and the Jira project for the Tooltip
Macro <http://extensions.xwiki.org/xwiki/bin/view/Extension/Tooltip+Macro>
extention ? At this point, it can't be installed with EM and we need to do
some adjustments to this macro.
Repository name : macro-tooltip
Jira project name : MTOOLTIP
Thank you,
Raluca.
Hi devs,
I’ve started setting up GitHub organization jobs on ci.xwiki.org. One is already set up for xwiki contrib:
http://ci.xwiki.org/job/XWiki%20Contrib/
What it means:
* Whenever a contrib project commits a Jenkinsfile (see example: https://github.com/xwiki-contrib/syntax-markdown/blob/master/Jenkinsfile) then automatically this project gets built by jenkins
* It works for all branches and is removed when branches are removed
Now, I’m working on creating some shared pipeline libraries (see https://github.com/jenkinsci/workflow-cps-global-lib-plugin) so that we can avoid duplications in Jenkinsfile. So I need an SCM location for it and it seems that it cannot be in a directory of an existing repo and it needs to be in the root of a repo.
Thus I’m proposing https://github.com/xwiki/xwiki-jenkins
WDYT?
Note: we could also use xwiki-contrib but it would be a bit weird to use that for building xwiki org repos and my plan is to move to Jenkinsfile also for repos in the xwiki GitHub org (commons, rendering, etc).
Thanks
-Vincent