Hey everyone,
I wanna read and access the variables passed in url in Velocity on different
Xwiki Pages. Please suggest me a method. I have tried something in groovy
and velocity but I want to use only one macro/language for it.
Thanks
--
View this message in context: http://xwiki.475771.n2.nabble.com/Reading-Get-Post-variables-from-url-tp758…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi developers.
Tuesday evening, after trying to fix all issues that integrate Workspace in
XE made, I had a bit of time to work on this JIRA:
http://jira.xwiki.org/browse/XWIKI-9341 "Menu improvements when Workspaces
activated".
The idea was to quickly implement the Caty's proposal for M2 (which was
scheduled for the day after). I made it and I sent a pull request. I have
also sent a mail to Vincent to show him my work.
== Proposal A ==
There is some screenshots (Proposal A):
Logged as admin:
http://xwiki.kephpage.net/proposals/workspaces-menus/new-home-menu.png
Not logged as admin:
http://xwiki.kephpage.net/proposals/workspaces-menus/new-home-menu-non-admi…
You can get it from this commit:
https://github.com/xwiki/xwiki-platform/commit/8c1c1bac2cde30f9024525e50249…
(except that I have changed the wiki icon for this screenshot)
We though this menu was confusing and not consistent with the current menus:
- Why do we have a link to the *main wiki* administration when we are in a
(sub)wiki? Does it make sense?
- Why do we have the main wiki (called Home) in the left of the current
wiki, space and page? The fact that there is actually a "main" and several
"sub" wikis is only due to the implementation. We could imagine, in the
future, a new implementation where there is no distinction between "main"
and "sub", but where we have an independent "system" that allows the users
to create and manage their wikis. Then, it seems better to call the menu
"System" or "XWiki".
- When we don't have the admin right on the main wiki, we only have a
single item in this menu, meanwhile wiki, space and page has more content.
It does not look good.
- If you are in the main wiki, you have "Administer main wiki" twice: once
in the Home menu, once in the Wiki menu.
- The left menu has too many items.
== Proposal B ==
Vincent thought it was not good enough to be integrated in 5.2M2, so we
started to iterate until having this proposal:
http://xwiki.kephpage.net/proposals/workspaces-menus/new-xwiki-menu.png(pro…
B).
Why putting this menu to the right side? It's because, on the left side, we
have Wiki/Space/Page, where you have actions that you can actually achieve
on these Wiki, Space and Page. Actions like "Administer", "Delete" or
"Rename". The XWiki menu does not provide actions like that, it just
provides some shortcuts to navigate thought the wikis. It's more a "System"
menu, like the Profile menu, or the Register action. That's why we put it
there. Moreover, it make the left menu smaller, which is less confusing.
== Proposal C ==
We had also this idea:
http://xwiki.kephpage.net/proposals/workspaces-menus/wiki-menu.png(proposal C)
But we didn't like it, because the "Wiki Directory" and the "Main Wiki"
link are not related to the current wiki, meanwhile actions like
"Administer", "Index" or "Delete" are.
---
After having created the proposal B, I asked Vincent: "What should I do? Do
I commit it, without asking to the community?". He said yes, because he
wanted to have something to show to the community that can still be changed
for the RC1, and he applied the pull request.
So, let me list again the 3 proposals we have:
A - "Home" menu (Caty's proposal):
Current implementation:
http://xwiki.kephpage.net/proposals/workspaces-menus/new-home-menu.png
Mockup with the new skin:
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/PortalMenu/Men…
B - "XWiki" right menu:
http://xwiki.kephpage.net/proposals/workspaces-menus/new-xwiki-menu.png
C - Add actions to the "Wiki" menu:
http://xwiki.kephpage.net/proposals/workspaces-menus/wiki-menu.png
I propose to start a thread where you can all give your opinion, regarding
one of these proposals, and you can also bring new ideas. We must have a
consensus for the RC1!
0 for proposal A (the left menu is too heavy).
+0 for proposal B (not perfect IMHO).
-1 for proposal C.
Louis-Marie
Hi devs,
There are several remote branches that are probably no longer needed. Let me list them all and we can decide which one we can remove:
commons:
origin/XWIKI-7748
origin/feature-AbstractScriptService
origin/feature-diff
origin/feature-diff-display
origin/feature-execution-context-metadata
origin/feature-extensionauth
origin/feature-extensiondistribution
origin/feature-extensionoverridemaven
origin/feature-extensionrequestcustomization
origin/feature-filterjson
origin/feature-improvecm
origin/feature-jacoco
origin/jenkins-job-creation
rendering:
origin/feature-jsonsyntax
origin/itext-pdf-renderer
origin/markdown-renderer
origin/restrict-type-parser-per-syntax
platform:
origin/4.5.3
origin/XWIKI-8450
origin/XWIKI-8494
origin/enabled-csrf-protection
origin/feature-activeinstalls
origin/feature-alfresco-link
origin/feature-annotations-merged-with-comments
origin/feature-authorization-context
origin/feature-customizable-user-directory
origin/feature-deprecate-virtual-mode
origin/feature-distributionwikimode
origin/feature-execution-context-metadata
origin/feature-extensionauth
origin/feature-extensiondistribution
origin/feature-extensionpages
origin/feature-filterable-activity-stream
origin/feature-localization
origin/feature-luamacro
origin/feature-lucene-4.0.0-upgrade
origin/feature-newmodel
origin/feature-portlet-3.5.x
origin/feature-resource-and-wiki-modules
origin/feature-restimportxar
origin/feature-restimprovements
origin/feature-security-authorization
origin/feature-solr-index-thread
origin/feature-solr-search
origin/feature-split-activity-and-messageSender-macros
origin/feature-standardclasses
origin/feature-store-attachments-newstore
origin/feature-thumbnails
origin/feature-upgradeinfinispan
origin/feature-upgraderestlet2.1
origin/feature-user-profile-information-editor
origin/feature-users
origin/feature-wysiwyg-standalone
origin/feature-xarpluginextensions
origin/feature-xclass-property-component
origin/feature-xwikiexistslocale
enterprise:
origin/enabled-csrf-protection
origin/feature-activeinstalls
origin/feature-customizable-user-directory
origin/feature-extensiondistribution
origin/feature-filterable-activity-stream
origin/feature-portlet-3.5.x
origin/feature-restimprovements
origin/feature-solr-search
origin/feature-split-activity-and-messageSender-macros
origin/feature-thumbnails
origin/feature-xarpluginextensions
manager:
origin/feature-xarpluginextensions
Let me know which one I can remove (I'll reply for the branches I've created in a response to this email).
Thanks
-Vincent
Hi devs.
I am testing the migration from XEM 4.5.4 to XE 5.2 (local build). Sorin
has already reported some problems in JIRA.
For me, the problem occurs when I use the "upgrade all wikis" option.
Let me explain it:
= Prerequisites =
1. Install a new XEM 4.5.4.
2. Create a workspace with WorkspaceManager (called 'workspace1')
3. Create a new subwiki with WikiManager (called 'subwiki1') - I create it
from a XAR template which is xwiki-enterprise-ui-all.
= Upgrade, part 1 =
1. Replace the webapp with a 5.2.
2. Put your own maven directory as the extension repository. (in
xwiki.properties:
extension.repositories=local:maven:file://${sys:user.home}/.m2/repository)
3. Upgrade the main wiki
It works:
- For example Main.SpaceIndex is in version 2.1.
- In the "installed extensions" menu, I can see all extensions correctly
upgraded.
= Upgrade, part 2 =
== Scenario 1 ==
1. In the DW, choose "Upgrade all wikis. Choose this option if all wikis
are administrated by the same entity.".
It displays "All extensions are up to date. "
But:
'workspace1' is not upgraded:
- for example Panels.WorkspaceInformationPanel is still in version 1.1
- In the "installed extensions" menu, I see 'XWiki Enterprise - UI All'. It
has not been upgraded because there is no new version for it. It has been
replaced by xwiki-enterprise-ui-wiki-all.
'subwiki1' is not upgraded:
- for example Main.SpaceIndex is still in version 1.1
- In the "installed extensions" menu, I see 'XWiki Enterprise - UI All '
with the message 'Installed but not valid'. It has not been upgraded
because there is no new version for it. It has been replaced by
xwiki-enterprise-ui-common.
== Scenario 2 ==
1. In the DW, choose "Upgrade only the current wiki. Choose this option if
each wiki is administrated by a separate entity. In this case it's best if
each wiki is upgraded by its owner. ".
2. Go to every subwiki, logged as Admin. You will see the DW.
3. Select "Yes, this is an upgrade".
Note: if you upgrade a subwiki, the proposed UI will be XWiki Enterprise -
UI - Common meanwhile if you upgrade a workspace, it will be XWiki
Enterprise - UI - Wiki. It is normal.
4. You will see "Administration Application - 5.2-SNAPSHOT - Installed
version 4.5.4 is not valid", and the same for several extensions.
5. Click on "continue", anyway.
All is OK. In the "installed extensions" menu, I can see all extensions
correctly upgraded.
= Conclusion =
- The scenario 1 don't work at all.
- In the scenario 2, it displays "Installed version 4.5.4 is not valid"
which is disturbing, because everything go right in the end.
As Marius and Thomas explained me:
> When you have an extension installed with version X, and then a new
> version Y is released but with the id changed, extension manager is not
> able to detect it. Ideally the EM should detect this and propose the user
> to upgrade from version X to Y even if the extension id has changed between
> version X and Y.
>
How can we solve these issues?
Thanks,
Guillaume Louis-Marie Delhumeau
The name of the extension is webrtc-application.
The purpose of this application is to facilitate communication via
audio/video between users in XWiki.
I'm having some difficulty at the moment with github, but can someone check my changes and perhaps check them in?
I basically had to take the AnchorFilter out so it would leave the anchors as is, and then replace all the links in the main doc that were moved, to the new link reference.
Thanks
Dan Jones
________________________________
This communication (including all attachments) is intended solely for
the use of the person(s) to whom it is addressed and should be treated
as a confidential AAA communication. If you are not the intended
recipient, any use, distribution, printing, or copying of this email is
strictly prohibited. If you received this email in error, please
immediately delete it from your system and notify the originator. Your
cooperation is appreciated.
Hi everyone,
During this summer's XWIki SAS seminar, several committers/contributors met and discussed about how to improve the project's quality even further.
Some of them must have been drunk because they agree to do insane actions :) Since they will probably tell us that they don't remember about it, here's the rundown as agreed at that time:
* Sonar - find rules and propose have them in build - Vincent
* After 5.X cycle, continue 1 day per week with rolling themes - Vincent to organize
* Create JMeter scenario in build (and run them at each release) to ensure we don't decrease performances - Marius [Sorin]
* Improve knowing what version of XWiki some doc corresponds to - Caty?
* Work on xwiki.org dev guide - GuillaumeD
* Improve skin on xwiki.org - Caty
* Lots more stats/live data on xwiki.org - Marius/Fabio
* Have one job per platform top level module on CI - Vincent
* Test framework to skip storage and potentially move some integration/func tests to use it - Thomas
* Automatic Build promotion from jenkins when all jobs pass to save release time and avoid slippages - Vincent [Caleb]
* Review/propose checkstyle rules to remove if any - Caleb
* Try: SCM jenkins plugin to put jenkins under SCM… not sure it works fine... - Vincent
* Make functional sel2 tests run on phantomJS - Marius/Vincent
* Send heapdump in crash emails - Caleb
go go go!
Thanks
-Vincent
PS: Seem I was drunker than others since I agree to a lot of actions ;)
Hi devs,
In anticipation, I'm also proposing to remove the 5.1 branch since several of its jobs are failing and I doubt we're going to release any update of it. Instead we would release a 5.2.1 if we need to.
WDYT?
Thanks
-Vincent
Hi devs,
Following our agreed practice of supporting only the latest 2 branches (master + latest stable) I'm proposing to remove the XWiki 5.0 branch in git and on ci.xwiki.org
FTR we currently have 9 issues with a fixfor of 5.0.4 in platform, 3 in commons, none in rendering and 1 in enterprise.
WDYT?
Thanks
-Vincent