Hi devs,
tomcat9 package is now available in Debian repositories so I would
like to start providing xwiki-tomcat9-* Debian packages of XWiki.
Nothing complex so far but it if we provide an official tomcat 9
oriented package it would also make more sense to add Tomcat 9 in
https://dev.xwiki.org/xwiki/bin/view/Community/SupportStrategy/ServletConta…
(only Tomcat 8 right now).
Another argument is that it's the current recommended stable version
from Tomcat point of view so people will use it more and more.
WDYT ?
Here is my +1
--
Thomas Mortagne
The XWiki development team is proud to announce the availability of XWiki
11.6.
This release brings new security features related to user authentication
and management, a new way to see document changes closer to the WYSIWYG
edition and a new macro to define part of a document that should be
asynchronously loaded for better performance.
You can download it here: https://www.xwiki.org/xwiki/bin/view/Main/Download
Make sure to review the release notes:
https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/11.6/
Thanks for your support
-The XWiki dev team
Hi devs,
Here’s a proposal for 11.7:
To finish for XWiki 11.6 (in progress)
====================
July
* Finish Visual diff (on HTML and not markup) - Marius
* Editor Selection For TextArea Fields When Editing XObjects - http://jira.xwiki.org/browse/XWIKI-15753 - Marius
* Add UI to activate/deactivate users - https://jira.xwiki.org/browse/XWIKI-12654 - Simon
XWiki 11.7
==========
August:
* 11.7-rc-1: 19th of Aug
* 11.7 final: 26th of Aug
* Merge conflict: allow choice by chunks and custom fixes - https://jira.xwiki.org/browse/XWIKI-16464 - Simon
* Security: not be allowed to set a right you don't have (min) - https://jira.xwiki.org/browse/XWIKI-16266 - Thomas
* Async rendering improvements - Thomas
* Better handling of user removal and transfer of rights - http://jira.xwiki.org/browse/XWIKI-12142 - Marius (usability)
Thanks
-Vincent
Hi everyone,
I'm currently working on improving security on XWiki comments. We
already use a restricted mode in our comments but that does not cover
every possible case. In order to improve it we should also filter out
some part of the html when using the html macro.
I propose:
(a) that we use a configurable whitelist of HTML attributes that
would be allowed in the output HTML: all the other attributes would be
filtered out.
(b) that the HTML macro is put in restricted mode for users who do
not have scripting rights.
For (a) I'm hesitating between a whitelist or a blacklist: I assume a
blacklist would be shorter but there's also more risk of missing
something. On the contrary a configurable whitelist doesn't prevent
administrator to accept more than what we give in standard.
A first whitelist could be (taken from:
https://github.com/xwiki/xwiki-platform/pull/122/files#diff-c33fcb5dca86b15…)
alt, class, height, id, name, rel, scope, style, target, title, width
Note that href is not included in this list for example.
WDYT?
Simon
--
Simon Urli
Software Engineer at XWiki SAS
simon.urli(a)xwiki.com
More about us at http://www.xwiki.com
The XWiki development team is proud to announce the availability of
XWiki 11.6RC1.
This release brings new security features related to user authentication
and management, a new way to see document changes closer to the WYSIWYG
edition, and a new macro to define part of a document that should be
asynchronously loaded for better performance.
You can download it here: https://www.xwiki.org/xwiki/bin/view/Main/Download
Make sure to review the release notes:
https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/11.6RC1
Thanks for your support
-The XWiki dev team
Hi everyone,
Thanks for having me here
About Me
I am Ashish Sharma, selected as a student for Google Summer of Code. I am
final year student enrolled in Guru Gobind Singh Indraprastha University,
Delhi. I am a resident of India.
Profiles
GitHub - https://github.com/ashish932/xwiki-helm-chart/
LinkedIn - https://www.linkedin.com/in/ashish932/
Riot - @ashish932:matrix.org
I will be presenting my project "Helm Chart for XWiki" to all of you.
Following
are the relevant details.
Helm Chart for XWiki
Mentors: Shubham Jain, Neha Gupta
Technologies: Kubernetes, Docker, other if required
Overview
The proposed project is a helm chart that would deploy xwiki as highly
available and reliable. It should be configurable with different
databases(either a standalone database or a clustered one) that are
configurable with xwiki. It would give the option to either configure solr
externally (standalone or clustered) or managed within the container. It
should deploy the app on a shared file system like a rook. It should
support Istio virtual services, istio matrix, and istio distributed tracing
and should be a secured system with RBAC and security credential rotation.
The chart should be easily deployed on GKE and amazon EKS.
Features
-> Support for different Databases
-> Choice between using an external database, a single node DB or a
multi-cluster DB setup
-> Support for shared file system
-> Support for istio and it's services
-> RBAC, SSL and other security methods
If you have any features in mind that should be added please feel free to
reply to this mail.
Some Design Questions?
-> Which Databases should be supported?
-> As we have to detach solr out of the docker container(run it in an
independent container) would be there a requirement for a code change, and
we should approach it?
-> Apart from solr is there any other stateful service that could or should
be detached from the docker container?
Here is my current repository which deploys XWiki for MySQL database using
official XWiki docker container:-
https://github.com/ashish932/xwiki-helm-chart/
Thank You
Ashish Sharma
Hi everyone,
Hope you are doing well.
I would like to request an account on http://nexus.xwiki.org for the
release of Interactive Maps Application
(org.xwiki.contrib:application-interactive-maps) version 1.0-SNAPSHOT.
*Requested username:* ginpachi
Best,
Fawad
Hi devs,
As part of the annual XWiki SAS Hackaton, we propose with Vincent to create
a contrib extension "application-pagelogs" that will display the rendering
logs of a page within the page itself.
Repository : xwiki-contrib/application-pagelogs
JIRA ID : PAGELOGS
Thanks,
Clément
Hi everyone,
this is a proposal to add a new wikimacro script binding for the next
release, that I also plan to backport on 11.3.x and 10.11.x branches.
We had recently a bug report (https://jira.xwiki.org/browse/XWIKI-16520)
about the WikiMacro parameter: types were introduce in 10.10 (with
https://jira.xwiki.org/browse/XWIKI-13282) but we in fact never
converted them, making their type pretty useless.
We provided a first fix to it actually broke at least one existing
macro, AttachmentSelector which was still expecting String parameter
values instead of the types used in some of those parameters.
So even if the parameters were supposed to be typed since XWiki 10.10,
in practice they never have been. We might as well consider returning a
typed values as a regression since it might break some of the existing
macros.
That's why I propose to implement right now a new wikimacro binding, to
be able to get both typed parameter values and string parameter values.
The old binding would then still be available by using $xcontext.macro
but we would deprecate its usage.
I propose that all the existing $xcontext.macro information to be
available by using $macro, and to be able to use:
* $macro.parameters.foo to get a typed parameter value
* $macro.parametersAsString.foo to get the string value parameter
Could you tell me if you agree with all those changes?
Thanks,
Simon
--
Simon Urli
Software Engineer at XWiki SAS
simon.urli(a)xwiki.com
More about us at http://www.xwiki.com
Hi guys,
We have a decision to take re the docker image.
Until now we were supporting the arm64v8 architecture. However due to some changes, it's now ony supported with java11. So we have 2 solutions for the tomcat base image to use:
1) stay on java8 and move to the adoptopenjdk base image (so that we get java patches) BUT drop support for arm64v8 architectures
2) move to java11 and move to the adoptopenjdk base image (so that we get java patches) and keep support for arm64v8 archietectures
My POV is that we should do 1) since XWiki is supposed to run well on Java11 (it may even be faster on it?) and we want it to work on it anyway. We also test it with our docker tests every week
Side note: we could also decide to move to java11 everywhere on our CI agents and keep some tests weekly on java8 (ie invert the current situation)
WDYT?
Thanks
-Vincent
The XWiki development team is proud to announce the availability of XWiki
11.5.
This release continues the work on improving concurrent editing of pages
and introduces new page and attachment pickers for macros. The code macro
gets a new layout to display line numbers. Inline editing support for wiki
macros has also been greatly improved.
You can download it here: https://www.xwiki.org/xwiki/bin/view/Main/Download
Make sure to review the release notes:
https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/11.5
Thanks for your support
-The XWiki dev team
Hi devs,
XWiki SAS, the company who started the XWiki open source project, is celebrating its 15 years.
As an XWiki open source developer, you made XWiki what it is today and you can be proud of that! XWiki SAS would like to invite you to the party.
- Monday, 8th July
- Starting at: 19:00
- La Baleine Blanche
- Port de la Gare
- 75013 Paris
- Attire: Business Casual
If you plan to attend please register on http://go.xwiki.com/AF0U05SN00iF4Dg001010PK
Thanks
-Vincent
The XWiki development team is proud to announce the availability of
XWiki 11.5RC1.
This release continue the work on improving concurrent editing of
documents, introduce new page and attachment pickers for macros. The
code macro get a new layout to display line numbers. Inline editing
support for wiki macro also been greatly improved.
You can download it here: https://www.xwiki.org/xwiki/bin/view/Main/Download
Make sure to review the release notes:
https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/11.5RC1
Thanks for your support
-The XWiki dev team
Hi devs,
I'm opening this vote in order to propose an API breakage consisting in renaming the extension point "org.xwiki.platform.head" to "org.xwiki.platform.html.head". The former identifier was introduced too early by mistake in 11.1RC1 due to an omission by me, apologies, but it does not fit well because it does not self-explain that it targets the html head. Here is the extension point documentation page:
https://www.xwiki.org/xwiki/bin/view/Documentation/DevGuide/ExtensionPoint/…
As far as I know, there's just one public extension using this extension point for now, it's the OpenGraph Application, which already uses the new identifier:
https://extensions.xwiki.org/xwiki/bin/view/Extension/OpenGraph%20Applicati…
Further information about the change is available in the following pull request, which requires among other things that this vote passes:
https://github.com/xwiki/xwiki-platform/pull/1115
Thanks to Caty for spotting the issue and the guidance on how to fix it, and to Simon and Vincent.
Kind regards
Stéphane
--
Stéphane Laurière
XWiki – https://xwiki.com
Hi devs,
We currently have https://dev.xwiki.org/xwiki/bin/view/Community/DatabaseSupportStrategy
However, it doesn’t say explicitly which versions we officially support:
* For HSQLDB it says 2.3.3 which is wrong since the latest version is 2.4.1
* For MySQL it says 5.x but doesn’t specify which specific version(s)
* Same for other DBs
We cannot really support every versions since supporting means testing too.
So what I propose:
Question 1: definition
* We say we support the latest stable version of the databases for a given version cycle
** For MySQL, it’s the latest of the 5.x cycle, which is 5.7.24 as of today (see https://hub.docker.com/_/mysql/)
** For PostgreSQL, it’s the latest of the 9.x cycle, which is 9.6.10 as of today (see https://hub.docker.com/_/postgres/)
** For Oracle, it’s the latest of the 11.x cycle, which is 11.2.0.4.0 as of today (see https://www.oracle.com/technetwork/database/enterprise-edition/downloads/in…)
Question 2: review what we support
* For MySQL I think we could also start supporting MySQL 8.x (ie the latest version of that cycle). We have an issue open for it currently: https://jira.xwiki.org/browse/XWIKI-15215
* For PostgreSQL we could also start supporting versions 11.x (ie the latest version of that cycle)
* For Oracle, we could also start supporting versions 12.x (ie the latest version of that cycle)
Question 3: decide if we drop some support
* Is there any cycle that we should support for? Right now I think that MySQL 5.x is still heavily used, same for postgreSQL 9.x I guess. Don’t know for Oracle.
* Any idea?
So WDYT about the 3 questions?
Thanks
-Vincent
Hi devs,
Right now we bundle 3 HBM files for DBs we don’t support: derby, mssql and db2. So we can’t guarantee that they work and it’s possible they don’t anymore after the Hibernate upgrade.
I propose to do the following:
* Create a single repo in contrib to host them. hibernate-mappings-extra or something like that
* Document how to install these mappings in the page for each of these DBs. For ex for DB2 it would be documented on https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Installation/…, etc.
The only downside is that when we make chages to the HBM files we support we won’t make the same adjustements for these non supported DBs… OTOH we don’t support them...
WDYT?
Thanks
-Vincent