Is there a typo in the version number of the deb package list for the
latest 6.1 release? The version is listed as 6.1~rc+1 instead of
6.1+rc+1, a consequence of which it's lower than the milestone dev
releases. (I had to do a 'downgrade' to get it to install)
_
* Bold face markup is lost on export.
Hmm... what could account for this difference - perhaps choice of font
for PDF... I did change it to san serif. Maybe there is an issue with
selecting the bold version of the font at export time.
* Export of a slab of plain text wrapped in {{{ }}} loses n
Arghh! This is a bit disappointing - the PDF exporter seems a bit
underbaked?
* Bold face markup is lost on export.
* Export of a slab of plain text wrapped in {{{ }}} loses newlines on
export.
* Box macro lost on export.
___
users mailing list
use
Aha! That one did not come up in google
Thanks for that. A bit annoying though!
On 21/05/2014 10:45 PM, Thomas Mortagne wrote:
See http://jira.xwiki.org/browse/XRENDERING-175
On Wed, May 21, 2014 at 2:24 PM, wrote:
Hmm... well I'm not getting that behaviour. It's as if something buggy i
Hmm... well I'm not getting that behaviour. It's as if something buggy
is going on. This is with V5.4.4
The problem is not ending the table per se, it's getting a blank line to
render between the table and the next paragraph?
On 21/05/2014 10:00 PM, Marius Dumitru Florea wrote:
This works f
Having some "fun" understanding what ends off a table in 2.1 syntax. If
I have a normal paragraph of text following a table, and I want one
blank line between the table and the text, I either have to precede the
next para with \\:
|Last row A|Last row B
\\Next paragraph of text
---or--- lea
I thought that may have been the case...surely there can't be that many
places in the code where the user id text is validated? (And if there is
a period then can it not be held internally in escaped syntax?)
In any case, how do we address the consequential issues of this
constraint on things
Why does this restriction exist? It makes it difficult to map through
to LDAP if we can't map to AD/LDAP username field that contain periods,
such as format of "firstname.lastname" which is quite common. Also, it
is possible to authenticate to xwiki using email address and password
rather than
I'd like to try this out. Have installed it, but the documentation is
/very/ poor in terms of how you actually use it. Could someone guide me
through how do you actually create a collection page with this thing?
Thanks... MT
___
users mailing list
u
Many thanks for that clarification... cheers
On 7/05/2014 4:59 PM, vinc...@massol.net wrote:
Hi,
On 7 May 2014 at 06:50:54, mcto...@gmail.com
(mcto...@gmail.com(mailto:mcto...@gmail.com)) wrote:
It seems to work, e.g. a space name such as R12.01
Wiki links with such a space name prefix a
It seems to work, e.g. a space name such as R12.01
Wiki links with such a space name prefix also seem to work, such as
Home>>R12.01.WebHome
even though it seems to me that creates a certain ambiguity about
interpreting the period - which one is separating the space name from
the page name at
I installed this extension on my dev wiki... installation went fine.
Followed the directions to save the two Xuake documents with programming
rights (Is there any way to confirm the pages actually now have the
ability to run?)
Anyhow, I'm supposed to be able to bring up the console using F10
... and ... because I had explicitly granted View right to the
unregistered user on those two spaces, I had to do the same for the
XWikiAllGroup too, even though that group had the View right at the wiki
level. Otherwise as soon as ordinary user logged in, he lost colors and
skin!
I think thi
It turned out that what I had to do was grant the View right to the
unregistered user on both:
* The XWiki space
* The ColorThemes space
But leave the right off at the Wiki level. This seems to enforce
authentication still being required.
On 6/05/2014 11:40 PM, mcto...@gmail.com wrote:
XWiki
XWiki 5.4.4
I have a 'locked down' main wiki (i.e. no unauthenticated guest access)
that has a custom skin and color theme. The login form though has a
different skin from the wiki itself!
I was thinking this was something to do with a missing right
somewhere... did try granting view rights
Why am I getting this warning? Things seem to be working ok otherwise
2014-05-06 11:58:05,333 [http://localhost:8080/bin/view/Main/] WARN
onfiguredQueryExecutorProvider - Could not find a QueryExecutor with
hint hibernate which is the hint for the storage engine. the default
QueryExecutor
For some reason, the appearance of the top menu bar is different for a
subwiki than the main wiki. What is controlling this? I'd like the
appearance of the way it is in the main wiki to be reflected in the
subwikis too.
MT
___
users mailing list
user
17 matches
Mail list logo