Re: [xwiki-users] Post-upgrade issue
Hi Ivan,
It looks like skin extension plugins are not loaded in your XE. You can try:
{{velocity}}
$xwiki.ssx
{{/velocity}}
And see if it outputs the plugin API object.
Also, can you check whether your xwiki.cfg file has the plugins declared
like:
#-# List of active plugins.
xwiki.plugins=\
com.xpn.xwiki.monitor.api.MonitorPlugin,\
com.xpn.xwiki.plugin.skinx.JsSkinExtensionPlugin,\
com.xpn.xwiki.plugin.skinx.JsSkinFileExtensionPlugin,\
com.xpn.xwiki.plugin.skinx.CssSkinExtensionPlugin,\
com.xpn.xwiki.plugin.skinx.CssSkinFileExtensionPlugin,\
.
If you are sure that your xwiki.cfg is correct, you should see some
exception traces when you start XE. These exceptions will complain that some
plugins are missing or was not loaded due to errors.
If you can try the above and post the tomcat logs for missing / errornous
plugins, may be we can help.
Thanks.
- Asiri
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Post-upgrade issue
Additional info:
I am playing in Sandbox now. Here are the results:
{{velocity}}
$xwiki
{{/velocity}}
turns into
com.xpn.xwiki.api.xw...@223373
===
{{velocity}}
$xwiki.getXMLEncoded('abc')
{{/velocity}}
turns into
abc
===
{{velocity}}
$xwiki.ssx.use('Main.Dashboard')
{{/velocity}}
turns into
$xwiki.ssx.use('Main.Dashboard')
Velocity seem to be working, it looks like a parser issue. Maybe
I should try to downgrade some JAR? Which one?
--
If you want to get to the top, you have to start at the bottom
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
[xwiki-users] Post-upgrade issue
After upgrading from 2.3 to 2.4M1 there are lots of text
strings everywhere on every page. They look like this:
$xwiki.ssfx.use('js/xwiki/widgets/jumpToPage.css', true)
$xwiki.jsfx.use('uicomponents/widgets/confirmationBox.js', true)
$xwiki.ssfx.use('uicomponents/widgets/confirmationBox.css', true)
$xwiki.jsfx.use('uicomponents/widgets/confirmedAjaxRequest.js', true)
$xwiki.jsfx.use('uicomponents/widgets/notification.js', true)
$xwiki.ssfx.use('uicomponents/widgets/notification.css', true)
(snipped)
It's an easy-to-edit website that will help you work better
together. This Wiki is made of pages sorted by spaces. You're
currently in the Main space, looking at its home page (WebHome).
$xwiki.ssx.use('Main.Dashboard')
Also, there are exceptions java.lang.NullPointerException in logs
and lines like this:
[#|2010-06-13T12:59:22.015+0700|INFO|sun-appserver2.1|
javax.enterprise.system.stream.out|
_ThreadID=17;_ThreadName=http://metrolace.ru/bin/view/Main/;|
2010-06-13 12:59:22,015 [http://metrolace.ru/bin/view/Main/] ERROR
internal.DefaultVelocityEngine - Left side ($tagCount.size()) of '>'
operation has null value at velocity macro[line 54, column 24]|#]
What's going on? Did I something wrong while updating?
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] The new GWT-based WYSIWYG editor doesn't support the syntax
Hello. The plugin is in the config file. Here is a list of my plugins. xwiki.plugins=\ com.xpn.xwiki.monitor.api.MonitorPlugin,\ com.xpn.xwiki.plugin.calendar.CalendarPlugin,\ com.xpn.xwiki.plugin.skinx.JsSkinExtensionPlugin,\ com.xpn.xwiki.plugin.skinx.JsSkinFileExtensionPlugin,\ com.xpn.xwiki.plugin.skinx.CssSkinExtensionPlugin,\ com.xpn.xwiki.plugin.skinx.CssSkinFileExtensionPlugin,\ com.xpn.xwiki.plugin.feed.FeedPlugin,\ com.xpn.xwiki.plugin.ldap.LDAPPlugin,\ com.xpn.xwiki.plugin.google.GooglePlugin,\ com.xpn.xwiki.plugin.flickr.FlickrPlugin,\ com.xpn.xwiki.plugin.mail.MailPlugin,\ com.xpn.xwiki.plugin.packaging.PackagePlugin,\ com.xpn.xwiki.plugin.query.QueryPlugin,\ com.xpn.xwiki.plugin.svg.SVGPlugin,\ com.xpn.xwiki.plugin.charts.ChartingPlugin,\ com.xpn.xwiki.plugin.fileupload.FileUploadPlugin,\ com.xpn.xwiki.plugin.image.ImagePlugin,\ com.xpn.xwiki.plugin.captcha.CaptchaPlugin,\ com.xpn.xwiki.plugin.userdirectory.UserDirectoryPlugin,\ com.xpn.xwiki.plugin.usertools.XWikiUserManagementToolsImpl,\ com.xpn.xwiki.plugin.zipexplorer.ZipExplorerPlugin,\ com.xpn.xwiki.plugin.autotag.AutoTagPlugin,\ com.xpn.xwiki.plugin.lucene.LucenePlugin,\ com.xpn.xwiki.plugin.diff.DiffPlugin,\ com.xpn.xwiki.plugin.rightsmanager.RightsManagerPlugin,\ com.xpn.xwiki.plugin.jodatime.JodaTimePlugin,\ com.xpn.xwiki.plugin.scheduler.SchedulerPlugin,\ com.xpn.xwiki.plugin.mailsender.MailSenderPlugin,\ com.xpn.xwiki.plugin.activitystream.plugin.ActivityStreamPlugin, \ com.xpn.xwiki.plugin.watchlist.WatchListPlugin, \ com.xpn.xwiki.wysiwyg.server.plugin.WysiwygPlugin, \ com.xpn.xwiki.plugin.tag.TagPlugin What else might it be? Thanks Lee -- View this message in context: http://xwiki.475771.n2.nabble.com/The-new-GWT-based-WYSIWYG-editor-doesn-t-support-the-syntax-tp5135766p5172359.html Sent from the XWiki- Users mailing list archive at Nabble.com. ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Searching workaround for HTML in title-field
Ivan Levashew wrote: > James DeLisle wrote: > >> This is not a problem only with the search field. It's a security policy that >> XWiki allows it's users to run script. In syntax 1.0 you are allowed to type >> HTML (and thus script) into the document, in syntax 2.0 you can use HTML in >> the document by invoking the HTML macro. >> >> My opinion is that to prevent users from running script you would have to >> set up >> an output filter such as Apache mod_filter and implement a policy which >> blocks all >> script which is in parts of the page which are user editable. >> > > I have a short experience with Jaxer. It is not maintained, but is > pretty usable if starting from scratch is OK for you. Notable difference > is that most operations are performed on structured DOM trees as opposed > to structureless strings in e. g. PHP. The engine is serverside Mozilla, > so the tricks like innerHTML are working, but strings are exception > instead of a rule in the world of Jaxer. > We have something like that. We call it XDOM. It can be rendered into XHTML, PDF OpenOffice export etc. http://code.xwiki.org/xwiki/bin/view/Modules/RenderingModule There is an issue for adding means to manipulate the XDOM using server side script. http://jira.xwiki.org/jira/browse/XWIKI-5234 2 problems: 1. Lots of content (including all of the .vm templates) is in Syntax 1.0 which doesn't use the new rendering module. 2. Syntax 2.0 parsers contain lots of code and have bugs of their own. IMO security code should be as small and as heavily reviewed as possible. > > I think, sooner or later it would be evident that next major revision of > X-Wiki must use structured data instead of all that > easy-to-forget-because-anyway-it-mostly-works escaping. > > This makes sense because, for instance, one might want to enable users > to post into common blog but prevent them from storing scripts. There is > no "string noscript(string)" function. It is far beyond mere escaping. > Even if such function existed, parsing and serializing is CPU-costly. > I think you could strip all types of script invocation from a stream of xml without actually parsing the xml. If you can't do it with sed, it's not worth doing ;) ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Searching workaround for HTML in title-field
James DeLisle wrote: > This is not a problem only with the search field. It's a security policy that > XWiki allows it's users to run script. In syntax 1.0 you are allowed to type > HTML (and thus script) into the document, in syntax 2.0 you can use HTML in > the document by invoking the HTML macro. > > My opinion is that to prevent users from running script you would have to set > up > an output filter such as Apache mod_filter and implement a policy which > blocks all > script which is in parts of the page which are user editable. > I have a short experience with Jaxer. It is not maintained, but is pretty usable if starting from scratch is OK for you. Notable difference is that most operations are performed on structured DOM trees as opposed to structureless strings in e. g. PHP. The engine is serverside Mozilla, so the tricks like innerHTML are working, but strings are exception instead of a rule in the world of Jaxer. I think, sooner or later it would be evident that next major revision of X-Wiki must use structured data instead of all that easy-to-forget-because-anyway-it-mostly-works escaping. This makes sense because, for instance, one might want to enable users to post into common blog but prevent them from storing scripts. There is no "string noscript(string)" function. It is far beyond mere escaping. Even if such function existed, parsing and serializing is CPU-costly. -- If you want to get to the top, you have to start at the bottom ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] XWiki/1.0 and XWiki/2.0 escaping
The bug itself is reported on JIRA: http://jira.xwiki.org/jira/browse/XAPANELS-126 -- If you want to get to the top, you have to start at the bottom ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Searching workaround for HTML in title-field
This is not a problem only with the search field. It's a security policy that
XWiki allows it's users to run script. In syntax 1.0 you are allowed to type
HTML (and thus script) into the document, in syntax 2.0 you can use HTML in
the document by invoking the HTML macro.
My opinion is that to prevent users from running script you would have to set up
an output filter such as Apache mod_filter and implement a policy which blocks
all
script which is in parts of the page which are user editable.
Caleb
Ivan Levashew wrote:
> Joel Forsberg wrote:
>> Do you happen to know the JIRA ticket for this bug? (if there is one?)
>>
> http://jira.xwiki.org/jira/browse/XE-24 but it is for previous search
> engine.
>
>> The {pre} seems to dodge some of the unwanted effects, but in turn makes
>> further editing the script difficult. Next time I edit the {pre} seems to
>> have
>> disappeared, instead leaving a -tag artifact depending on circumstances.
>>
>>> CrossSiteScripting example: alert('I pwnd U')
>>> => bad, bad, bad
>> That is exatly what I would like to avoid, hehe. :)
>>
>
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Searching workaround for HTML in title-field
Joel Forsberg wrote:
>
> Do you happen to know the JIRA ticket for this bug? (if there is one?)
>
http://jira.xwiki.org/jira/browse/XE-24 but it is for previous search
engine.
> The {pre} seems to dodge some of the unwanted effects, but in turn makes
> further editing the script difficult. Next time I edit the {pre} seems to
> have
> disappeared, instead leaving a -tag artifact depending on circumstances.
>
>> CrossSiteScripting example: alert('I pwnd U')
>> => bad, bad, bad
> That is exatly what I would like to avoid, hehe. :)
>
--
If you want to get to the top, you have to start at the bottom
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] [l10n] issue posting translation to XWiki site
On Sat, Jun 12, 2010 at 16:24, coldserenity wrote: > > Hello Thomas, > > I have a few question regarding l10n. > There's a set of properties representing short-cuts: core.shortcuts.* > E.g. > > http://l10n.xwiki.org/xwiki/bin/view/XE/XEXWikiCoreResources_1342260095_core-shortcuts-view-class_uk > > Questions are: > - how do I use those short-cuts on the UI? and Theses shortcuts are supposed to be enabled by default. For example when you type "o" on a page you goes to object edition. See http://platform.xwiki.org/xwiki/bin/view/Features/KeyboardShortcuts for more. > - should those be translated at all? It mostly depends of the keyboard usually used with the language your are translating I guess. For example using shortcut like "o" with a Chinese keyboard would probably be a pain. > > Thanks > Roman > -- > View this message in context: > http://xwiki.475771.n2.nabble.com/l10n-issue-posting-translation-to-XWiki-site-tp5163871p5171693.html > Sent from the XWiki- Users mailing list archive at Nabble.com. > ___ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > -- Thomas Mortagne ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] [l10n] issue posting translation to XWiki site
Hello Thomas, I have a few question regarding l10n. There's a set of properties representing short-cuts: core.shortcuts.* E.g. http://l10n.xwiki.org/xwiki/bin/view/XE/XEXWikiCoreResources_1342260095_core-shortcuts-view-class_uk Questions are: - how do I use those short-cuts on the UI? and - should those be translated at all? Thanks Roman -- View this message in context: http://xwiki.475771.n2.nabble.com/l10n-issue-posting-translation-to-XWiki-site-tp5163871p5171693.html Sent from the XWiki- Users mailing list archive at Nabble.com. ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
[xwiki-users] XWiki/1.0 and XWiki/2.0 escaping
Hello!
Yet another problem I'm encountering is lack of
proper escaping tools. I have noticed it when I
decided to use [ and ] in page titles.
«My Recent Modifications» became broken because
XWiki parsed [ and ]. Currently I have added
{pre} and {/pre} at both ends, but it is just a
krunch. What is the proper way? I have checked
$escapetool and $xwiki.get*Encoded APIs. There is
no common API to escape [, ], =, {, etc.
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
[xwiki-users] Associated forum
What forum would you recommend to use in combination with X-Wiki? Its authorization is wished to be integrated with X-Wiki's one, and userbase is wished to be taken from X-Wiki (because WebDAV won't work otherwise IIUC). ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
[xwiki-users] Subdomains as spaces
Does anybody had this idea before? I'd like to establish the mapping as follows: http://something.metrolace.ru/Page -> http://metrolace.ru/bin/view/Something/Page/ http://something.another.metrolace.ru/ -> http://metrolace.ru/bin/view/SomethingAnother/WebHome/ That is, the whole domain is a collaborative wiki with pretty short URLs. New domains are being created on demand because they are essentially good old Spaces. I'm going to use url_rewrite in Squid (in particular, because I don't know why it's so difficult to get rid of /bin/) and custom XWikiURLFactory implementation. Any advices? Did somebody already write custom URLFactory before? -- If you want to get to the top, you have to start at the bottom ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Crete xwiki pages from a template
Abel Solórzano Astorga writes: > So when the page is created it has the same content as the template > page. Something like this? http://platform.xwiki.org/xwiki/bin/edit/Main/LongURLs?template=ShortURLs It works in 2.3, and it's largely used by structured objects (e. g. create new Blog record, create new Todo, etc.). Another interesting argument is a parent. Parent seems to be the page that is displayed in the navigation bar as being a parent for the page. -- If you want to get to the top, you have to start at the bottom ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Yet another thread on file-based attachments
On Jun 12, 2010, at 6:55 AM, Caleb James DeLisle wrote: > > > Ivan Levashew wrote: >> I have seen another threads, but I didn't noticed any good idea. I have >> only seen JCR project in the sandbox. >> >> http://dev.xwiki.org/xwiki/bin/view/Design/JcrStore >> >> I have no idea what is JCR. «JCR» sounds very different from >> «filesystem». Installing and maintaining JCR is likely to be yet another >> brainache I'd like to skip. Finally, «Translate XWQL to JCRSQL2» sounds >> very different from «simple and reliable». > JCR seems to be proposed as a replacement for the database entirely. This is not correct. JCR is simply a Java API and an SPI for implementers to plug any storage. There are SPI implementations for filesystem, RDBMS, and more. If you prefer it serves a similar purpose as Hibernate but in a standard way and more generic since it supports any type of storage. See http://en.wikipedia.org/wiki/Content_repository_API_for_Java for example. > I would have to see it's performance before I would want to advocate for the > idea. The only potential problem re performance is the mapping between the java objects and the tables if you choose the RDBMS SPI. We'll need to compare the performance with our current Hibernate solution indeed. >> «Storing 10Mb octet streams >> in database» doesn't sound like being reliable, and indeed it caused >> strange problems recently. > On the one hand it definitely over-stresses the database but on the other hand > it is very nice to be able to do a database dump, wipe the disk, load the dump > and be right back where you were before. Maybe a hybrid where content is > stored > in the db and 'cached' on the hard disk but caches make debugging a huge pain. > Still something has to be done about the max_packet issue. > >> >> So my humble wish is to see xwikiattachment_content table replaced with >> a mere filesystem storage. Other tables left intact. Maintaing >> «Space/Document/Attachment» structure is not a requirement (althoung it >> would be nice since I could share it in GreyLink DC++ this way). Actually we have a separate Attachment storage (there's an interface called XWikiAttachmentStoreInterface) and it should be pretty easy to implement a file-based implementation of it. I wonder why nobody has done it before Thanks -Vincent ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Yet another thread on file-based attachments
On Sat, Jun 12, 2010 at 11:02, Ivan Levashew wrote: > I'm testing WebDAV now and getting lots of exceptions when > copying photos from PhotoAlbum. > > There are entries like this one: > > Caused by: java.lang.OutOfMemoryError: Java heap space > > Web server isn't stable in these moments. > > javaw.exe consumes about 600Mb of memory. Although I can adjust it > to use 3Gb of memory, this seems to be a wrong way. Storing big > attachments in a database is a wrong way. Handling them in-memory is > a wrong way. They should be handled in another manner. Some kind of > event-based servlet streams attachments block by block without putting > any whole octet stream in memory (it seems that stroring attachments > in database implies this as a consequence). > > No matter what I (and you) do, wrong way will constantly show its > wrongness and limitations. > > X-Wiki is far from being perfect yet indeed it's outstanding. I don't > regret I have spent some time to get it working. I hope, current way > of handling attachments will be obsoleted soon. +1, storing attachments in the DB is a pretty bad idea. Not to mention that storing large objects in MySQL restrains from using InnoDB. > > -- > If you want to get to the top, you have to start at the bottom > > ___ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > -- Je prête mes livres sur Bibale, http://www.bibale.com/bibale/-/user/hbs ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Yet another thread on file-based attachments
I'm testing WebDAV now and getting lots of exceptions when copying photos from PhotoAlbum. There are entries like this one: Caused by: java.lang.OutOfMemoryError: Java heap space Web server isn't stable in these moments. javaw.exe consumes about 600Mb of memory. Although I can adjust it to use 3Gb of memory, this seems to be a wrong way. Storing big attachments in a database is a wrong way. Handling them in-memory is a wrong way. They should be handled in another manner. Some kind of event-based servlet streams attachments block by block without putting any whole octet stream in memory (it seems that stroring attachments in database implies this as a consequence). No matter what I (and you) do, wrong way will constantly show its wrongness and limitations. X-Wiki is far from being perfect yet indeed it's outstanding. I don't regret I have spent some time to get it working. I hope, current way of handling attachments will be obsoleted soon. -- If you want to get to the top, you have to start at the bottom ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
