The XWiki development team is pleased to announce the release of XWiki
Enterprise and XWiki Enterprise Manager 2.4.1.
This is a bug fix release for the 2.4 branch.
Important Bugs fixed:
* XWIKI-5511 - In some conditions a newly created wiki does not
have the standard classes
* XWIKI-5492 - Can't move the focus outside of the rich text area in Opera
* XWIKI-5440 - user.isUserInGroup return false if User in Master
and group in virtual
* XWIKI-5452 - "cache.path" configuration is not taken into
account by JBossCache module
* XWIKI-5414 - Keyboard shortcuts are not ignored when trying to
navigate with keys in a select input
* XWIKI-5391 - MediaWikiScanner#docElements() raises unexpected
ParseException when encountering <D_TABLE_CAPTION> tokens
* XWIKI-5515 - NPE when accessing an not existing wiki and autowww = 0
* XWIKI-5363 - PeriodFactory#createSinceMonthsPeriod creates a
"since weeks" period instead
* XWIKI-5476 - Problem with non-px image dimensions in wysiwyg
mode only with IE7
* XWIKI-5457 - Propeditor cannot work anymore with recent livetable code
* XWIKI-5243 - Reflected XSS in edit(wiki|wysiwyg|wysiwygnew).vm
* XWIKI-5450 - SQL injection in suggest.vm
* XWIKI-5428 - Save and Continue doesn't validate the mandatory
document title
* XWIKI-5434 - Saved request parameters are not restored on relogin
* XWIKI-5244 - Stored XSS via user/group name
* XWIKI-5510 - Text and background color don't match the color themev
* XWIKI-5417 - xwiki/2.0 renderer should escape any (% it can find
* XWIKI-5453 - includeMacro() no longer works in XE 2.4
* XASEARCH-10 - Escaping issue in Main.DatabaseSearch
* XAADMINISTRATION-156 - Cannot add "global" user in groups
* XAADMINISTRATION-155 - Improper search icon position in
Administration Application
* XAADMINISTRATION-168 - Small inconsistency in DOM of some
elements that use ConfigurationClass Class
For more information see the Releases notes at:
http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise241
and http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXEM241
Thanks
-The XWiki dev team
Hi devs,
Currently the image plugin [1] allows us to create image thumbnails by
specifying the image width and/or height in the query string of the
image attachment download URL:
/xwiki/bin/download/Spage/Page/image.jpg?width=100
I propose that we:
(A) Use the image width and/or height (when they are specified in the
image syntax using pixel unit) to resize the image on the server side.
For instance:
[[image:logo.jpg||width="100px"]]
will be linked to
/xwiki/bin/download/Spage/Page/logo.jpg?width=100
and
[[image:logo.jpg||style="height: 50px; width: 70px"]]
will be linked to
/xwiki/bin/download/Spage/Page/logo.jpg?width=70&height=50
The image plugin also accepts a quality parameter that controls the
compression quality when encoding jpeg images. The default value of this
parameter (i.e. when not specified in the URL) is configurable. I
propose we use 0.3 by default, 1 representing the best quality.
(B) Add the ability to limit the image dimensions (preserving aspect
ratio) when the image width and/or height are not specified in the image
syntax (or when they are not using pixel unit). The width and height
limit will be configurable and -1 by default (i.e. no limitation). For
instance:
image:logo.jpg
will be linked to
/xwiki/bin/download/Spage/Page/logo.jpg?width=1024
when width limit is 1024, and to
/xwiki/bin/download/Spage/Page/logo.jpg?width=1024&height=768&keepAspectRatio=true
when width limit is 1024 and height limit is 768. Note that in this case
the image aspect ratio is preserved. The image is resized to best fit
the limits. If the user want to bypass the limit he has to specify the
image width/height in the image syntax.
I'm +1 for both (A) and (B). WDYT?
Thanks,
Marius
[1]
http://svn.xwiki.org/svnroot/xwiki/platform/core/trunk/xwiki-core/src/main/…
Hi,
I have started creating the classes for representing forms, form fields and form field validation
constraints. I now have:
FormTextAreaFieldClass
FormSelectFieldClass
FormTextFieldClass
FormFieldConstraintClass
and I plan to add:
FormClass
and
FormGenerator
Since there seem to be a lot of documents associated with this project, I am proposing to make it a
top level application and put the documents in a new space called Forms.
WDYT?
As planned by the XE 2.5 roadmap
(http://enterprise.xwiki.org/xwiki/bin/view/Main/Roadmap) i would like
to move extension manager to the platform. It's one application for
the UI and one jar for the framework (plus several MB of
maven/classloading dependencies).
The rationale is that it makes it easier to try and play with it to
have as much comments as possible.
It would be "taged" as experimental which means anything in it can be
changed anytime and nobody can expect a code that use this component's
API to not be broken.
The current state of Extension Manager is summarized in
http://dev.xwiki.org/xwiki/bin/view/Design/ExtensionManagerProposal#HPlanni…
and detailed in the rest of the document.
I'm pretty confident it's not dangerous for the rest of XE when you
don't use it and it can't slow down it or something.
So WDYT ?
Here is my +1.
Thanks,
--
Thomas Mortagne
Hello there,
I have been asked to develop something on top of the pdf export facilities
on the xwiki. But I run into a small problem:
When *generating a pdf with multiple pages*, say all the pages from one
space, the ids of elements within the pages get duplicated and the *pdf
exportation fails*.
i.e.:
*Page A* with a title *TheQuickBrownFox...* some text under it and then *page
B* with the same title: *TheQuickBrownFox...* with some other text under
this. Both will get an auto ID of *TheQuickBrownFox...
*Now this doesn't happen for items on the same page since the ID generation
mechanism counts all items of the same name and increments it if necessary.
But this mechanism does not contemplate cross page duplicated items.
To avoid the following error:
Property ID "lipsum" (found on "fo:block") previously used; ID values
must be unique within a document! (See position 12:39)
We thought some changes to the ID generation mechanism could be made:
We could* prefix the ID* with the space and page name and this would
be a simple elegant solution.
Now:
Is this the best solution?
Will someone point out the best place to do this?
If I post a patch with this fix will it be included on the trunk?
Thank you in advance,
» Ricardo Espírito Santo
» Linkare TI - Tecnologias de Informação, Lda
Hi devs,
wdyt about committing the section & macro columns from the contrib
(https://svn.xwiki.org/svnroot/xwiki/contrib/projects/xwiki-macro-column/)
in the platform macros, along with a first, very simple implementation
of the dashboard macro (which for the moment only delegates to the
section macro)?
This would be the first step towards the implementation of the
dashboard, and the plan is to be done before 2.5M2.
Here's my +1.
WDYT?
Anca