[xwiki-devs] [ANN] XWiki Enterprise 2.0 Milestone 2 released
The XWiki development team is pleased to announce the release of XWiki Enterprise 2.0 Milestone 2. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download The main goal of 2.0 is to make XWiki fully XWiki 2.0 syntax. Main changes from 2.0 Milestone 1: * Lots of improvements and new features in the new WYSIWYG editor * Lots of improvements and bugfixes in the rendering engine and the syntax converter * Improvements for the blog application * It's now possible to choose the content renderer to use when viewing a page * New Footnote macro * New xwiki-properties module * New Latvian translation * New Swedish translation * New Korean translation For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise20M2 Thanks -The XWiki dev team
On Thu, Jul 30, 2009 at 16:38, Thomas Mortagne<[email protected]> wrote:
The XWiki development team is pleased to announce the release of XWiki Enterprise 2.0 Milestone 2.
Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download
The main goal of 2.0 is to make XWiki fully XWiki 2.0 syntax.
Main changes from 2.0 Milestone 1:
* Lots of improvements and new features in the new WYSIWYG editor * Lots of improvements and bugfixes in the rendering engine and the syntax converter * Improvements for the blog application * It's now possible to choose the content renderer to use when viewing a page * New Footnote macro
Actually the footnote is released but not yet included in XE by default. You can try it by downloading (http://maven.xwiki.org/releases/org/xwiki/platform/xwiki-core-rendering-macr...) and put it in lib/ folder.
* New xwiki-properties module * New Latvian translation * New Swedish translation * New Korean translation
For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise20M2
Thanks -The XWiki dev team
-- Thomas Mortagne
First of all, kudos on the release of 2.0M2 -- it is awesome. I cloned /var/lib/mysql after shutdown of mysqld for quiescence, and quickly got a 5-way multiwiki replicated onto a home system: loaded in the appropriate fedora RPM packages for tomcat, installed the latest 64 bit sun jvm RPM, and everything pretty much upgraded without a hitch. Good job! * One thing I've noticed, and I'm not sure if it's due to a styling or customization that I didn't upgrade, is that the footer of documents that normally has the comments/attachment/information/history tabs doesn't work. The tabs' contents are all empty. I skipped upgrading some documents to prevent overwriting my customizations -- is there a 2.0 update lurking among these docs causing this problem: XWiki.XWikiPreferences, XWiki.XWikiAdminGroup, XWiki.WebPreferences, XWiki.Admin, XWiki.XWikiAllGroup, Main.WebHome, Panels.QuickLinks ?? * What happened to the "styling" and scrollable list in Main.SpaceIndex http://localhost:8080/xwiki/bin/view/Main/SpaceIndex?space=Main used to display in a scrollable list. Now it just inserts an ugly-looking sequence, not even in tabular format, into the document. * Finally, I'm having ongoing problems with the office-importer, which I have't really been able to get running ever since 1.8 final, when it was rearchitected to manage it's own oofice-server instance. http://code.xwiki.org/xwiki/bin/view/Applications/OfficeImporterApplicationL... is my prior result of my getting this working on Linux, allowing a more sysadmin-friendly startup of openoffice server at boot via SYSV-init (cf. chkconfig). Unfiortunately I could not get the external openoffice importer management to work. When enabled, the openoffice importer control panel would not display, giving a velocity error in place of the page contents. Using an "internally managed" ooserver instance, I had the following problems: (1) not setting "Server path /usr/lib64/openoffice.org3" gave a default path of /opt/... unfortunately, for fedora, that's not where openoffice is installed. Also, unless the code specifically checks e.g. for 32 vs 64 bit architecture, this path could also be wrong even if this particular bug is fixed. It may better to have the documentation not set user-expectations that the correct path will be chosen. Instead, a statement, on windows, this default path is chosen, on linux, a different one, etc. (2) Auto-start=yes resulted in a totally non working wiki, across all vhosts. It should die more gracefully. (3) When trying to start a internally managed ooserver-instance, I consistently get message "Inadequate privileges." despite being Admin. (I can start the external ooserver instance so openoffice seems to work). Niels http://nielsmayer.com
I'm not sure what I just changed by switching the vhost accessed by localhost in editing "Objects of type XWiki.XWikiServerClass XWikiServerClass 0: localhost" however, now when i access pages, the comments/attachment/information/history tabs work (A browser cache issue that got refreshed by changing which v-host is accessed by 'localhost' and re-accessing?). Anyways, ignore the following issue: On Sun, Aug 2, 2009 at 2:31 PM, Niels Mayer <[email protected]> wrote:
* One thing I've noticed, and I'm not sure if it's due to a styling or customization that I didn't upgrade, is that the footer of documents that normally has the comments/attachment/information/history tabs doesn't work. The tabs' contents are all empty. I skipped upgrading some documents to prevent overwriting my customizations -- is there a 2.0 update lurking among these docs causing this problem: XWiki.XWikiPreferences, XWiki.XWikiAdminGroup, XWiki.WebPreferences, XWiki.Admin, XWiki.XWikiAllGroup, Main.WebHome, Panels.QuickLinks ??
Niels http://nielsmayer.com PS: tip on simulating multiple vhosts: list multiple lines in /etc/hosts , e.g. 'foo 127.0.0.1' 'bar 127.0.0.1' ; this fools xwiki's vhosting mechanism enough to test a cloned vhost setup. Set "Objects of type XWiki.XWikiServerClass XWikiServerClass 0: foo" on XWiki.WikiServerHost_foo , and "Objects of type XWiki.XWikiServerClass XWikiServerClass 0: bar" on XWiki.WikiServerHost_bar for two db's 'Host_foo' and 'Host_bar' ...
Hi Neils, * Finally, I'm having ongoing problems with the office-importer, which I
have't really been able to get running ever since 1.8 final, when it was rearchitected to manage it's own oofice-server instance.
http://code.xwiki.org/xwiki/bin/view/Applications/OfficeImporterApplicationL... is my prior result of my getting this working on Linux, allowing a more sysadmin-friendly startup of openoffice server at boot via SYSV-init (cf. chkconfig).
Unfiortunately I could not get the external openoffice importer management to work. When enabled, the openoffice importer control panel would not display, giving a velocity error in place of the page contents.
Can you post your xwiki log corresponding to this issue? Current error handling in velocity only displays a generic error message, you need to look at the logs to see what went wrong.
Using an "internally managed" ooserver instance, I had the following problems: (1) not setting "Server path /usr/lib64/openoffice.org3" gave a default path of /opt/... unfortunately, for fedora, that's not where openoffice is installed. Also, unless the code specifically checks e.g. for 32 vs 64 bit architecture, this path could also be wrong even if this particular bug is fixed. It may better to have the documentation not set user-expectations that the correct path will be chosen. Instead, a statement, on windows, this default path is chosen, on linux, a different one, etc.
Unfortunately this is how jodconverter works. May be this will be fixed in a future release.
(2) Auto-start=yes resulted in a totally non working wiki, across all vhosts. It should die more gracefully.
It should not die at all. I will check this on 2.0M2 and get back to you.
(3) When trying to start a internally managed ooserver-instance, I consistently get message "Inadequate privileges." despite being Admin. (I can start the external ooserver instance so openoffice seems to work).
The page XWiki.OpenOfficeAdmin must be saved with programming rights. Make sure this is true. Thanks. - Asiri
Niels http://nielsmayer.com _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Again,
Unfiortunately I could not get the external openoffice importer management to work. When enabled, the openoffice importer control panel would not display, giving a velocity error in place of the page contents.
Can you post your xwiki log corresponding to this issue? Current error handling in velocity only displays a generic error message, you need to look at the logs to see what went wrong.
(2) Auto-start=yes resulted in a totally non working wiki, across all vhosts. It should die more gracefully.
It should not die at all. I will check this on 2.0M2 and get back to you.
It's true, officeimporter external oo server option semms to be busted. It's funny I fixed the exact same bug in a previous release but it seems it has been introduced again. It's not in officeimporter but in xwiki configuration which seems to fail to read configuration information for officeimporter application. I'm looking into it now. Thanks. - Asiri
Hi, On Mon, Aug 3, 2009 at 11:37 AM, Asiri Rathnayake < [email protected]> wrote:
Hi Again,
Unfiortunately I could not get the external openoffice importer management to work. When enabled, the openoffice importer control panel would not display, giving a velocity error in place of the page contents.
Can you post your xwiki log corresponding to this issue? Current error handling in velocity only displays a generic error message, you need to look at the logs to see what went wrong.
(2) Auto-start=yes resulted in a totally non working wiki, across all vhosts. It should die more gracefully.
It should not die at all. I will check this on 2.0M2 and get back to you.
It's true, officeimporter external oo server option semms to be busted. It's funny I fixed the exact same bug in a previous release but it seems it has been introduced again. It's not in officeimporter but in xwiki configuration which seems to fail to read configuration information for officeimporter application.
I'm looking into it now.
Fixed the problem on 2.0 branch: http://jira.xwiki.org/jira/browse/XWIKI-4049 This problem is only affecting 2.0 branch so it should not be a problem in 1.9 releases (checked myself with 1.9.2 XE). Many thanks for reporting this issue. - Asiri
A few more problems, which i consider more "major" than previous first impression issues: On the "main" host of a v-hosted setup: (1) Using administration "users" panel, add a user. As soon as user is added, no entries in users panel display. Subsequent return to this panel continues to show no users. The added user is created, however, and other user logins still work. However, no subsequent editing or browsing of users in user panel is possible. (2) In administration "groups" panel, go to a group , e.g. XWikiAdminGroup and add the new user to that group. As soon as this is done, all the users in the group list disappear, yet the "lightbox popup" remains up. Subsequent browsing of a group where new members added shows an emtpy list of users, just like in the above users panel. (3) the lightbox popup out of Groups->XWikiAdminGroup has a cancel button that is nearly invisible, and partially overlaps other buttons (the forw/back pager, which needn't display if only one page of users in list). This is in firefox 3.0.12 on Fedora 10 Linux. -- Niels http://nielsmayer.com PS: I shift-reloaded the pages with issues a few times to make sure it wasn't caused by the browser caching an old javascript file.. PPS: I wouldn't have been adding users had I not just recently extracted my head from a dark and fetid orifice, in attempting to get "programming rights" on a muli-vhost-wiki... fortunately I happened to catch http://jira.xwiki.org/jira/browse/XWIKI-4066 "out of the corner of my eye" :
For example, when the backup pack xwiki-enterprise-wiki-n.n.xar is used as a template or imported into a virtual sub-wiki and since local user XWiki.Admin is used as authors of most pages, those don't receive programming rights, because only global user may have these rights. For most pages, this has no concequence, but a few ones don't work properly. For example XWiki.AllAttachementsResults, which use non-priviledged API does not work in a virtual wiki, without being resaved by a global user having programming rights first.
Isn't this the cause of numerous bugs All over the place? How would scripts requiring programming rights that are part of the 2.0 XAR , installed in each virtual-wiki, end up pointing to the "global user" XWiki.Admin and not a local XWiki.Admin that is the admin of the particular virtual-wiki. The latter wouldn't get programming rights. Isn't this also the cause of the office-converter issues I was having?? Asiri Rathnayake wrote:
(3) When trying to start a internally managed ooserver-instance, I
consistently get message "Inadequate privileges." despite being Admin. (I
can start the external ooserver instance so openoffice seems to work).
The page XWiki.OpenOfficeAdmin must be saved with programming rights. Make sure this is true.
participants (3)
-
Asiri Rathnayake -
Niels Mayer -
Thomas Mortagne