Re: [xwiki-users] [xwiki-user] Attempting to install Xwiki3.1 on tomcat5.5
Well that was just the Tomcat5_Security parameter to set to no ... On 05/09/2011 17:53, natoine wrote: > Hello Folks, > > If anybody can help me ... > > I've tried to install Xwiki latest version 3.1 in tomcat through the > xwiki.war distribution. > I've followed the steps listed there : > http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Installation > > And I've the following error in catalina.out (of course tomcat/xwiki > doesn't work ^^) : > INFO: Deploying web application archive xwiki-enterprise-web-3.1.war > Sep 5, 2011 3:31:49 PM org.apache.catalina.core.StandardContext > processTlds > SEVERE: Error reading tld listeners javax.servlet.ServletException: > Exception p\ > rocessing TLD at resource path /WEB-INF/struts-form.tld in context > /xwiki-enter\ > prise-web-3.1 > javax.servlet.ServletException: Exception processing TLD at resource > path /WEB-\ > INF/struts-form.tld in context /xwiki-enterprise-web-3.1 > at > org.apache.catalina.startup.TldConfig.tldScanTld(TldConfig.java:555) > at > org.apache.catalina.startup.TldConfig.execute(TldConfig.java:301) > at > org.apache.catalina.core.StandardContext.processTlds(StandardContext\ > .java:4307) > at org.apache.catalina.core.StandardContext.start(StandardContext.java:\ > 4144) > at > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBas\ > e.java:760) > at > org.apache.catalina.core.ContainerBase.access$0(ContainerBase.java:7\ > 44) > at > org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(Contai\ > nerBase.java:144) > at java.security.AccessController.doPrivileged(Native Method) > at > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:7\ > 38) > at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:544\ > ) > at > org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:831\ > ) > at > org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:72\ > 0) > at > org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:49\ > 0) > at > org.apache.catalina.startup.HostConfig.check(HostConfig.java:1217) > at > org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.jav\ > a:293) > at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(Lifecyc\ > leSupport.java:120) > at > org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBa\ > se.java:1306) > at > org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.\ > processChildren(ContainerBase.java:1570) > at > org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.\ > processChildren(ContainerBase.java:1579) > at > org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.\ > run(ContainerBase.java:1559) > at java.lang.Thread.run(Thread.java:636) > Sep 5, 2011 3:31:49 PM org.apache.catalina.core.StandardContext start > SEVERE: Error listenerStart > Sep 5, 2011 3:31:49 PM org.apache.catalina.core.StandardContext start > SEVERE: Context [/xwiki-enterprise-web-3.1] startup failed due to > previous erro\ > rs > Sep 5, 2011 3:33:15 PM org.apache.struts.action.RequestProcessor > processMapping > SEVERE: Invalid path was requested /login > Sep 5, 2011 3:33:48 PM org.apache.catalina.core.StandardContext > processTlds > SEVERE: Error reading tld listeners javax.servlet.ServletException: > Exception p\ > rocessing TLD at resource path /WEB-INF/struts-form.tld in context > /xwiki-enter\ > prise-web-3.1 > javax.servlet.ServletException: Exception processing TLD at resource > path /WEB-\ > INF/struts-form.tld in context /xwiki-enterprise-web-3.1 > at > org.apache.catalina.startup.TldConfig.tldScanTld(TldConfig.java:555) > at > org.apache.catalina.startup.TldConfig.execute(TldConfig.java:301) > at > org.apache.catalina.core.StandardContext.processTlds(StandardContext\ > .java:4307) > at > org.apache.catalina.core.StandardContext.start(StandardContext.java:\ > 4144) > at > org.apache.catalina.manager.ManagerServlet.start(ManagerServlet.java\ > :1173) > at > org.apache.catalina.manager.HTMLManagerServlet.start(HTMLManagerServ\ > let.java:549) > at > org.apache.catalina.manager.HTMLManagerServlet.doGet(HTMLManagerServ\ > let.java:105) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl\ > .java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce\ > ssorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:616) > at > org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:24\ > 4) > at java.security.AccessController.doPrivilege
Re: [xwiki-users] file operations in file system storage is too slow
On 09/05/2011 03:28 PM, Haru Mamburu wrote: > Thanks a lot for help, > > No way to disable recycle bin. If some vandals would ruin content and delete > attachments - it would be lost without possibility to get it back. > Move operations usually take milliseconds despite of file size. By accident I > found a reason of such slow down: XE makes TWO copies of the file in recycle > bin (in the file storage). > > Should I report it as a bug of file storage? Yes. > Kind regards, > > Dmitry Bakbardin > > > 05 сентября 2011, 22:35 от Sergiu Dumitriu: > > > > On 09/05/2011 12:10 AM, Haru Mamburu wrote: >> >> HI! >> >> Xwiki 3.1. Attachment versioning turned off. Storage is set to file system, >> Works fine with relatively small files. >> I uploaded 700M file - no problem, a bit to wait, but works fine. >> I tried then to delete this file. The result was also successful, but took >> nearly 1.5 minutes to finish. Is there any way to run file operations faster? >> > > Deleting an attachment will save the file in the attachment trash, which > means copying the file in another place. You could try to disable the > attachment trash to get a faster result, if you don't care about rolling > back deleted attachments. > > The time spent seems reasonable given that it involves disk I/O and a > fairly large file. What could be done to improve responsiveness is to do > all the work in the background, i.e. just start the file copy process > and instantly resume the work. This means more work to ensure that > future requests affecting that file won't interfere in a bad way. > -- Sergiu Dumitriu http://purl.org/net/sergiu/ ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Download resume for large files - no way?
On 09/05/2011 03:20 PM, Haru Mamburu wrote: > Thanks a lot, > > I put the "resume feature" request into Jira. :-) > File system storage is implemented and now I'm precisely looking for the > right way to use XE in a kind of non-profit library project, where > attachments could be from 1KB to approx 1Gb in one piece. That is why I'm > doing field test to avoid surprises in the nearest future. > My first preliminary conclusion: it's worth to use XE in such a way, but for > now there are too many things go unusual way to use XE as is. I'm going to > run project anyway, so would be glad for futher cooperation to make file > storage and big files operation more seamless both for administrators and > end-users. Sure, we welcome as much feedback about the FS attachment storage as possible. It's something quite new and worthy of improvements. > Kind regards > > Dmitry > > > 05 сентября 2011, 22:30 от Sergiu Dumitriu: > > > > > On 09/04/2011 10:02 PM, Haru Mamburu wrote: >> >> Hi! >> >> By default, XWiki doesn't have "resume" ability for downloads. Is there any >> way to turn it on? From the moment file system storage was implemented into >> XE it makes sence. > > It's not implemented yet, but it could easily be implemented yet if > there's demand for this feature. > >> And another question-idea: >> On uploading big (all) files, XWiki creates hash for torrent, stores it >> together with file. >> On Download request - user gets torrent file and starts download. >> Server side strats seeding and after download is complete - kills seeding >> process from torrent-client. >> Upload can be done almost the same way. >> >> The question is: >> Does existing XWiki functionality allow to implement such a upload-download >> technology? > > Well, since it's Java, anything should be possible given the right > amount of time. Being Open Source, any feature can get implemented if > there's enough need for it, but for the moment there haven't been any > requests for such thing, so the best way to see this committed is to > come up with patches. > -- Sergiu Dumitriu http://purl.org/net/sergiu/ ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] file operations in file system storage is too slow
Thanks a lot for help, No way to disable recycle bin. If some vandals would ruin content and delete attachments - it would be lost without possibility to get it back. Move operations usually take milliseconds despite of file size. By accident I found a reason of such slow down: XE makes TWO copies of the file in recycle bin (in the file storage). Should I report it as a bug of file storage? Kind regards, Dmitry Bakbardin 05 сентября 2011, 22:35 от Sergiu Dumitriu : On 09/05/2011 12:10 AM, Haru Mamburu wrote: > > HI! > > Xwiki 3.1. Attachment versioning turned off. Storage is set to file system, > Works fine with relatively small files. > I uploaded 700M file - no problem, a bit to wait, but works fine. > I tried then to delete this file. The result was also successful, but took > nearly 1.5 minutes to finish. Is there any way to run file operations faster? > Deleting an attachment will save the file in the attachment trash, which means copying the file in another place. You could try to disable the attachment trash to get a faster result, if you don't care about rolling back deleted attachments. The time spent seems reasonable given that it involves disk I/O and a fairly large file. What could be done to improve responsiveness is to do all the work in the background, i.e. just start the file copy process and instantly resume the work. This means more work to ensure that future requests affecting that file won't interfere in a bad way. -- Sergiu Dumitriu http://purl.org/net/sergiu/ ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Download resume for large files - no way?
Thanks a lot,
I put the "resume feature" request into Jira. :-)
File system storage is implemented and now I'm precisely looking for the right
way to use XE in a kind of non-profit library project, where attachments could
be from 1KB to approx 1Gb in one piece. That is why I'm doing field test to
avoid surprises in the nearest future.
My first preliminary conclusion: it's worth to use XE in such a way, but for
now there are too many things go unusual way to use XE as is. I'm going to run
project anyway, so would be glad for futher cooperation to make file storage
and big files operation more seamless both for administrators and end-users.
Kind regards
Dmitry
05 сентября 2011, 22:30 от Sergiu Dumitriu :
On 09/04/2011 10:02 PM, Haru Mamburu wrote:
>
> Hi!
>
> By default, XWiki doesn't have "resume" ability for downloads. Is there any
> way to turn it on? From the moment file system storage was implemented into
> XE it makes sence.
It's not implemented yet, but it could easily be implemented yet if
there's demand for this feature.
> And another question-idea:
> On uploading big (all) files, XWiki creates hash for torrent, stores it
> together with file.
> On Download request - user gets torrent file and starts download.
> Server side strats seeding and after download is complete - kills seeding
> process from torrent-client.
> Upload can be done almost the same way.
>
> The question is:
> Does existing XWiki functionality allow to implement such a upload-download
> technology?
Well, since it's Java, anything should be possible given the right
amount of time. Being Open Source, any feature can get implemented if
there's enough need for it, but for the moment there haven't been any
requests for such thing, so the best way to see this committed is to
come up with patches.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
document.write('
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] file operations in file system storage is too slow
On 09/05/2011 12:10 AM, Haru Mamburu wrote: > > HI! > > Xwiki 3.1. Attachment versioning turned off. Storage is set to file system, > Works fine with relatively small files. > I uploaded 700M file - no problem, a bit to wait, but works fine. > I tried then to delete this file. The result was also successful, but took > nearly 1.5 minutes to finish. Is there any way to run file operations faster? > Deleting an attachment will save the file in the attachment trash, which means copying the file in another place. You could try to disable the attachment trash to get a faster result, if you don't care about rolling back deleted attachments. The time spent seems reasonable given that it involves disk I/O and a fairly large file. What could be done to improve responsiveness is to do all the work in the background, i.e. just start the file copy process and instantly resume the work. This means more work to ensure that future requests affecting that file won't interfere in a bad way. -- Sergiu Dumitriu http://purl.org/net/sergiu/ ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Download resume for large files - no way?
On 09/04/2011 10:02 PM, Haru Mamburu wrote: > > Hi! > > By default, XWiki doesn't have "resume" ability for downloads. Is there any > way to turn it on? From the moment file system storage was implemented into > XE it makes sence. It's not implemented yet, but it could easily be implemented yet if there's demand for this feature. > And another question-idea: > On uploading big (all) files, XWiki creates hash for torrent, stores it > together with file. > On Download request - user gets torrent file and starts download. > Server side strats seeding and after download is complete - kills seeding > process from torrent-client. > Upload can be done almost the same way. > > The question is: > Does existing XWiki functionality allow to implement such a upload-download > technology? Well, since it's Java, anything should be possible given the right amount of time. Being Open Source, any feature can get implemented if there's enough need for it, but for the moment there haven't been any requests for such thing, so the best way to see this committed is to come up with patches. -- Sergiu Dumitriu http://purl.org/net/sergiu/ ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
[xwiki-users] [xwiki-user] Attempting to install Xwiki3.1 on tomcat5.5
Hello Folks, If anybody can help me ... I've tried to install Xwiki latest version 3.1 in tomcat through the xwiki.war distribution. I've followed the steps listed there : http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Installation And I've the following error in catalina.out (of course tomcat/xwiki doesn't work ^^) : INFO: Deploying web application archive xwiki-enterprise-web-3.1.war Sep 5, 2011 3:31:49 PM org.apache.catalina.core.StandardContext processTlds SEVERE: Error reading tld listeners javax.servlet.ServletException: Exception p\ rocessing TLD at resource path /WEB-INF/struts-form.tld in context /xwiki-enter\ prise-web-3.1 javax.servlet.ServletException: Exception processing TLD at resource path /WEB-\ INF/struts-form.tld in context /xwiki-enterprise-web-3.1 at org.apache.catalina.startup.TldConfig.tldScanTld(TldConfig.java:555) at org.apache.catalina.startup.TldConfig.execute(TldConfig.java:301) at org.apache.catalina.core.StandardContext.processTlds(StandardContext\ .java:4307) at org.apache.catalina.core.StandardContext.start(StandardContext.java:\ 4144) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBas\ e.java:760) at org.apache.catalina.core.ContainerBase.access$0(ContainerBase.java:7\ 44) at org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(Contai\ nerBase.java:144) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:7\ 38) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:544\ ) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:831\ ) at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:72\ 0) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:49\ 0) at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1217) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.jav\ a:293) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(Lifecyc\ leSupport.java:120) at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBa\ se.java:1306) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.\ processChildren(ContainerBase.java:1570) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.\ processChildren(ContainerBase.java:1579) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.\ run(ContainerBase.java:1559) at java.lang.Thread.run(Thread.java:636) Sep 5, 2011 3:31:49 PM org.apache.catalina.core.StandardContext start SEVERE: Error listenerStart Sep 5, 2011 3:31:49 PM org.apache.catalina.core.StandardContext start SEVERE: Context [/xwiki-enterprise-web-3.1] startup failed due to previous erro\ rs Sep 5, 2011 3:33:15 PM org.apache.struts.action.RequestProcessor processMapping SEVERE: Invalid path was requested /login Sep 5, 2011 3:33:48 PM org.apache.catalina.core.StandardContext processTlds SEVERE: Error reading tld listeners javax.servlet.ServletException: Exception p\ rocessing TLD at resource path /WEB-INF/struts-form.tld in context /xwiki-enter\ prise-web-3.1 javax.servlet.ServletException: Exception processing TLD at resource path /WEB-\ INF/struts-form.tld in context /xwiki-enterprise-web-3.1 at org.apache.catalina.startup.TldConfig.tldScanTld(TldConfig.java:555) at org.apache.catalina.startup.TldConfig.execute(TldConfig.java:301) at org.apache.catalina.core.StandardContext.processTlds(StandardContext\ .java:4307) at org.apache.catalina.core.StandardContext.start(StandardContext.java:\ 4144) at org.apache.catalina.manager.ManagerServlet.start(ManagerServlet.java\ :1173) at org.apache.catalina.manager.HTMLManagerServlet.start(HTMLManagerServ\ let.java:549) at org.apache.catalina.manager.HTMLManagerServlet.doGet(HTMLManagerServ\ let.java:105) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl\ .java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce\ ssorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:24\ 4) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:537) at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:\ 276) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil\ .java:162) at org.apache.catalina.core.ApplicationFilterChai
[xwiki-users] Deleted Attachments in filesystem Storage
Hi! Xwiki 3.1. Attachment versioning turned off (xwiki.store.attachment.versioning.hint = void) Storage is set to file system, Recicle Bin is ON. 1. xwiki/bin/view/Main/AllDocs?view=attachments - gives empty table. How one can see all attachments in a Live table? 2. To verify attachment versioning: attach several times the same file - one copy is stored as a file in a storage, version upgrades correctly - no problem. 3. I deleted an attachment. It shoild be in recycle bin: ~GLOBAL_DELETED_ATTACHMENT_ID_MAPPINGS.xml appeared in /store folder. XML inside shows were to find files. Files are on their places as descriebed. BUT Recycle bin gives terrible surprise: it stores TWO COPIES of deleted file: first is: . second is: ~v1.1. Please note, that attachment VERSIONING is turned OFF. For big attachments (1GB and more) such a behaviour is a disaster for two reasons: - unreasonable disk space consumption - (probably) huge delay while user deleting attachment. What is correct way to disallow XWiki such file duplication? 4. XWiki.DeletedAttachments gives empty table. How one can see all deleted attachments in a Live table? Thanks a lot Dmitry Bakbardin ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Copy Paste in editor
Marius, a new version of the clipboard events draft has been just launched: http://dev.w3.org/2006/webapi/clipops/clipops.html This, together with the HTML 5 specification, should resolve the issues you describe below. It is an implementation work, a non-trivial one. Gerritjan, if you have some developer hours available and know the target browsers you want to address, you may have a chance to implement something that catches the native paste event and calls the paste function there (this might even avoid the GWT recompilation). paul Le 5 sept. 2011 à 11:44, Marius Dumitru Florea a écrit : > On Mon, Sep 5, 2011 at 12:00 PM, Gerritjan Koekkoek > wrote: >> Hi, >> >> This feature we know, but since we deal with many people who collaborate we >> did not manage to tell them all, or they forget... >> Is it possible to force them use this, disable PASTE in rich text area? > > Handling Copy/Paste is complex for multiple reasons. Two of them are: > > * the clipboard can contain private information so the editor must > have special rights to be able to access it. For instance, you > wouldn't want a web page to steal the user/password you just copied, > or to put a dangerous shell script hoping you'll paste it by mistake. > * the editor doesn't know where the pasted text came from. It can be > from the text you are editing (you just copy a phrase from one > paragraph to another) or it can be from an external source (an office > document or a different web page). I'm sure your users wouldn't be > happy if they had to go through the paste dialog each time they copy a > word from a paragraph and paste it in another paragraph. > > Hope this helps, > Marius > >> >> Gerritjan >> >> Op 5 sep. 2011, om 08:33 heeft Marius Dumitru Florea het volgende geschreven: >> >>> Hi Gerritjan, >>> >>> On Mon, Sep 5, 2011 at 8:48 AM, Gerritjan Koekkoek >>> wrote: Hi, Many of our users use copy and past from windows (or mac) to bring textsnippets into the wiki In the display it looks fine, but when you edit the wiki, not the wysywig editor, there is a lot of , ((())) or sometimes even tags. Is it possible to configure the editor (or something else) that it is only possible to paste UTF ascii text without any styling (!) (so it must be dummy-proof) Or better, to automatically convert styles that we allow; like bold, italic, underline, upper, lower... >>> >>> There is a paste icon on the WYSIWYG editor tool bar (check the Import >>> menu if you have an older version of XWiki Enterprise). You should use >>> it instead of pasting directly into the rich text area. On the dialog >>> that it opens there is a check box that you can use to filter the >>> styles (only the basic styles like bold, italic, etc. are preserved). >>> >>> Hope this helps, >>> Marius >>> Gerritjan ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users >>> ___ >>> users mailing list >>> users@xwiki.org >>> http://lists.xwiki.org/mailman/listinfo/users >> >> ___ >> users mailing list >> users@xwiki.org >> http://lists.xwiki.org/mailman/listinfo/users >> > ___ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Copy Paste in editor
On Mon, Sep 5, 2011 at 12:00 PM, Gerritjan Koekkoek wrote: > Hi, > > This feature we know, but since we deal with many people who collaborate we > did not manage to tell them all, or they forget... > Is it possible to force them use this, disable PASTE in rich text area? Handling Copy/Paste is complex for multiple reasons. Two of them are: * the clipboard can contain private information so the editor must have special rights to be able to access it. For instance, you wouldn't want a web page to steal the user/password you just copied, or to put a dangerous shell script hoping you'll paste it by mistake. * the editor doesn't know where the pasted text came from. It can be from the text you are editing (you just copy a phrase from one paragraph to another) or it can be from an external source (an office document or a different web page). I'm sure your users wouldn't be happy if they had to go through the paste dialog each time they copy a word from a paragraph and paste it in another paragraph. Hope this helps, Marius > > Gerritjan > > Op 5 sep. 2011, om 08:33 heeft Marius Dumitru Florea het volgende geschreven: > >> Hi Gerritjan, >> >> On Mon, Sep 5, 2011 at 8:48 AM, Gerritjan Koekkoek >> wrote: >>> Hi, >>> >>> Many of our users use copy and past from windows (or mac) to bring >>> textsnippets into the wiki >>> In the display it looks fine, but when you edit the wiki, not the wysywig >>> editor, there is a lot of , ((())) or sometimes even tags. >>> >>> Is it possible to configure the editor (or something else) that it is only >>> possible to paste UTF ascii text without any styling (!) (so it must be >>> dummy-proof) >>> Or better, to automatically convert styles that we allow; like bold, >>> italic, underline, upper, lower... >> >> There is a paste icon on the WYSIWYG editor tool bar (check the Import >> menu if you have an older version of XWiki Enterprise). You should use >> it instead of pasting directly into the rich text area. On the dialog >> that it opens there is a check box that you can use to filter the >> styles (only the basic styles like bold, italic, etc. are preserved). >> >> Hope this helps, >> Marius >> >>> >>> Gerritjan >>> ___ >>> users mailing list >>> users@xwiki.org >>> http://lists.xwiki.org/mailman/listinfo/users >>> >> ___ >> users mailing list >> users@xwiki.org >> http://lists.xwiki.org/mailman/listinfo/users > > ___ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Copy Paste in editor
Hi, This feature we know, but since we deal with many people who collaborate we did not manage to tell them all, or they forget... Is it possible to force them use this, disable PASTE in rich text area? Gerritjan Op 5 sep. 2011, om 08:33 heeft Marius Dumitru Florea het volgende geschreven: > Hi Gerritjan, > > On Mon, Sep 5, 2011 at 8:48 AM, Gerritjan Koekkoek > wrote: >> Hi, >> >> Many of our users use copy and past from windows (or mac) to bring >> textsnippets into the wiki >> In the display it looks fine, but when you edit the wiki, not the wysywig >> editor, there is a lot of , ((())) or sometimes even tags. >> >> Is it possible to configure the editor (or something else) that it is only >> possible to paste UTF ascii text without any styling (!) (so it must be >> dummy-proof) >> Or better, to automatically convert styles that we allow; like bold, italic, >> underline, upper, lower... > > There is a paste icon on the WYSIWYG editor tool bar (check the Import > menu if you have an older version of XWiki Enterprise). You should use > it instead of pasting directly into the rich text area. On the dialog > that it opens there is a check box that you can use to filter the > styles (only the basic styles like bold, italic, etc. are preserved). > > Hope this helps, > Marius > >> >> Gerritjan >> ___ >> users mailing list >> users@xwiki.org >> http://lists.xwiki.org/mailman/listinfo/users >> > ___ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
