30 Jul
2009
30 Jul
'09
4:38 p.m.
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
30 Jul
30 Jul
5:20 p.m.
On Thu, Jul 30, 2009 at 16:38, Thomas Mortagne<thomas.mortagne(a)xwiki.com> 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-mac…)
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
2 Aug
2 Aug
11:31 p.m.
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/OfficeImporterApplication…
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
3 Aug
3 Aug
1:26 a.m.
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 <nielsmayer(a)gmail.com> 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' ...
7:18 a.m.
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/OfficeImporterApplication…
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
8:07 a.m.
Hi Again,
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
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.
3:25 p.m.
Hi,
On Mon, Aug 3, 2009 at 11:37 AM, Asiri Rathnayake <
asiri.rathnayake(a)gmail.com> wrote:
Hi Again,
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
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.
4 Aug
4 Aug
7:20 a.m.
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.
5522
days inactive
5527
days old
7 comments
3 participants
participants (3)
-
Asiri Rathnayake -
Niels Mayer -
Thomas Mortagne