[xwiki-users] IE bug with top menu
Hi! XE 3.4. IE 9 gives interesting bug: it doesn't show top menu. It exists, even works, but invisible. So, users can't find logout button :-( http://jira.xwiki.org/browse/XWIKI-7496 Does anyone has a clue how to fix it fast? Kind regards, Dmitry ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Workspace manager, WYSIWYG editor + 3-rd new idea
Hi, All, As we have now workspaces in addition to virtual spaces, it looks logic to provide following scenario in UI of WYSIWYG editor: select virtual wiki/workspace - Space - Page - Anchor It would help much in multiworkspace environment. Is it difficult to implement? Please, vote if it looks useful for you at http://jira.xwiki.org/browse/XEM-209 Kind Regards, Dmitry 01 февраля 2012, 15:36 от Eduard Moraru enygma2...@gmail.com: Hi Dmitry, I understand your concerns about programming rights. It has been and it still is a subject of debate. However, please note that you do not need programming rights to do velocity scripting inside XWiki (whether it is on the main wiki or on a subwiki). You need PR only for groovy scripting (since it has access to the core java layer) and for some velocity methods that request access to the same core java layer that you should normally not need to access. Even so, there are rare times when you want to do some complex stuff that *really* needs groovy or privileged velocity APIs, so you can not completely escape the need of PR. I`m not sure the PR wiki-level encapsulation you desire is easy to perform, since PR (as they are currently defined) are too powerful to be contained inside a wiki and generally tend to have access to everything. The current PR would need serious rethinking and maybe redefinition in order to obtain that, but it's good to have this encapsulation in consideration when it will come to that. My 2 cents on the issue :) Thanks, Eduard On Wed, Feb 1, 2012 at 8:42 AM, Haru Mamburu haru_mamb...@mail.ru wrote: Hi, Eduard, Sorry to be unclear first time. Let's end it up: E.g. I set up my workspace AND I need to do some scripting on it. If I got everything right, looks not possible without GLOBAL programming rights. Programming rights actually should work even without admin rights. For now we have no tool to encapsulate programming rights of user with programming rights niether inside his own workspace (as a global user), nor inside virtual wiki. Ideal XWiki world runs everything independently. It's how I understand words platform and engine. So, this encapsulation engine is another new feature request. I'd like to ask. Is it easy to implement? Finally: http://jira.xwiki.org/browse/XEM-207 - second level of virtualization http://jira.xwiki.org/browse/XEM-208 - programming rights incapsulation inside workspaces and virtual wikis Hope, it helps. Kind Regards. Dmitry 30 января 2012, 18:21 от Eduard Moraru enygma2...@gmail.com: Hi Dmitry, I`m not sure I fully understand your proposal or concerns. 1. You are saying that global admins are dangerous because they can get programming rights and kill everything. They don`t need programming rights to kill everything if they have global admin rights :) They just use the UI to delete everything. Also, I don`t think XWiki`s scope is to protect you from yourself or from your trusted people. If you assign global admin rights to someone, you`d better do it carefully. The same goes with every collaborative system. 2. You are describing a usecase where only subwikis/workspaces are launched in production and that the main wiki is restricted to regular users, in an attempt to avoid global admins. Well... sure, but how is this different from you being the only main wiki admin and the other users to be only subwiki admins (at best)? I`m not sure it's ok to impose such a usecase to users instead of applying it only when needed. Workspaces is already designed to fulfil this usecase by not assigning any main wiki admins. It allows global users to create their own workspaces (subwikis) and play as they wish inside them, no programming rights or global admins involved. 3. I`m not sure I understand the proposed flexible solution. If by virtual wiki 2 - workspaces - workspaces (probably) you mean to allow subwikis to be created inside subwikis, then this, indeed is the new feature request that I was referring to when suggesting that you create a new jira. The idea is more general than your particular use case and can be applied to various usecases. Though I still think that one level of virtualization is enough for XWiki (as things are working right now), I accept the idea that some people might need more complex scenarios. Thanks, Eduard On Sat, Jan 28, 2012 at 7:41 PM, Haru Mamburu haru_mamb...@mail.ru wrote: Hi Eduard, Thanks for explnation. I'm very happy to issue a new idea, but idea itself is a bit wider and deeper, then described below. I would like to point out some reasons and effects to be more clear before jiraing it :-) Security leak XE/XEM Usecase XE/XEM + Workspace Manager. One main Wiki and let's say, hundreds of workspaces. To be more real we'd add Wiki Manager and tens of virtual wikis running on the same
Re: [xwiki-users] Workspace manager free default pages set + 2 new ideas
Hi, Eduard, Sorry to be unclear first time. Let's end it up: E.g. I set up my workspace AND I need to do some scripting on it. If I got everything right, looks not possible without GLOBAL programming rights. Programming rights actually should work even without admin rights. For now we have no tool to encapsulate programming rights of user with programming rights niether inside his own workspace (as a global user), nor inside virtual wiki. Ideal XWiki world runs everything independently. It's how I understand words platform and engine. So, this encapsulation engine is another new feature request. I'd like to ask. Is it easy to implement? Finally: http://jira.xwiki.org/browse/XEM-207 - second level of virtualization http://jira.xwiki.org/browse/XEM-208 - programming rights incapsulation inside workspaces and virtual wikis Hope, it helps. Kind Regards. Dmitry 30 января 2012, 18:21 от Eduard Moraru enygma2...@gmail.com: Hi Dmitry, I`m not sure I fully understand your proposal or concerns. 1. You are saying that global admins are dangerous because they can get programming rights and kill everything. They don`t need programming rights to kill everything if they have global admin rights :) They just use the UI to delete everything. Also, I don`t think XWiki`s scope is to protect you from yourself or from your trusted people. If you assign global admin rights to someone, you`d better do it carefully. The same goes with every collaborative system. 2. You are describing a usecase where only subwikis/workspaces are launched in production and that the main wiki is restricted to regular users, in an attempt to avoid global admins. Well... sure, but how is this different from you being the only main wiki admin and the other users to be only subwiki admins (at best)? I`m not sure it's ok to impose such a usecase to users instead of applying it only when needed. Workspaces is already designed to fulfil this usecase by not assigning any main wiki admins. It allows global users to create their own workspaces (subwikis) and play as they wish inside them, no programming rights or global admins involved. 3. I`m not sure I understand the proposed flexible solution. If by virtual wiki 2 - workspaces - workspaces (probably) you mean to allow subwikis to be created inside subwikis, then this, indeed is the new feature request that I was referring to when suggesting that you create a new jira. The idea is more general than your particular use case and can be applied to various usecases. Though I still think that one level of virtualization is enough for XWiki (as things are working right now), I accept the idea that some people might need more complex scenarios. Thanks, Eduard On Sat, Jan 28, 2012 at 7:41 PM, Haru Mamburu haru_mamb...@mail.ru wrote: Hi Eduard, Thanks for explnation. I'm very happy to issue a new idea, but idea itself is a bit wider and deeper, then described below. I would like to point out some reasons and effects to be more clear before jiraing it :-) Security leak XE/XEM Usecase XE/XEM + Workspace Manager. One main Wiki and let's say, hundreds of workspaces. To be more real we'd add Wiki Manager and tens of virtual wikis running on the same engine (something like XWiki.com running) As my humble experience shows, nearly never in natural way XWiki would have only one User with Admin Rights on the Wiki level. It's human to be all the time in a hurry and meanwhile XWiki becomes messy inside. It's not the big problem yet. :-) As an Admin User on wiki level, I can easily gain programming rights. For now, it's completely uncontrolled and will run unnoticed. So, let's imagine that all stars in solar system lined up in a bad way and one Admin became an AngryAdmin with a revenge as a primary goal of life. Let's make it even worth: AngryAdmin knows XWiki quite good and scripting for him is an open book. To make it more real: AngryAdmin doesn't have root access to the server. :-) At this stage he has all necessary knowledge and access rights to ruin ALL WIKIs onboard. I didn't dig much in it, but if Workspace Manager has appropriate tools, then it's possible: one short script and it's over :-) I didn't met such occasions before, but heard a lot of similar usecases (not with XWiki :-) Thus, I NEVER run production on MAIN wiki! It looks dangerous for me. I'd better be paranoic admin rather embarrased admin. If somebody will become an angry-beaver-admin, he would be able to ruin only one space (now he has a front-end tool for this :-)) or more, but only inside one project and all running wikis will stay alive. Such workflow keeps my paranoia quiet :-) SO, at last new idea: escape MAIN WIKI from production completely. As only global users has programming rights, it looks very logic to leave Main Wiki to Core and instances management and keep it safe from local admins. When U have a lot of users it sounds reasonable for me. Let's
[xwiki-users] dafault DB name change
Hi, All! Does anyone know, is it possible to change default DB name xwiki to smth else? I changed in config.cfg, xwiki.db=test in hibernate.cfg.xml property name=connection.urljdbc:mysql://localhost/test/property After XWiki reload it tries to access xwiki db still. :-( What is correct way to do it? Thanks in advance, Dmitry ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] dafault DB name change
Yes, I did. :-( XEM 3.4 javax.servlet.ServletException: com.xpn.xwiki.XWikiException: Error number 3 in 0: Could not initialize main XWiki context Wrapped Exception: Error number 3202 in 3: Exception while reading document [name = [XWikiPreferences], type = [DOCUMENT], parent = [name = [XWiki], type = [SPACE], parent = [name = [xwiki], type = [WIKI], parent = [null Wrapped Exception: Error number 3301 in 3: Exception while switching to database xwiki Wrapped Exception: Access denied for user 'test'@'localhost' to database 'xwiki' And actually there is no DB xwiki in Mysql. Xwiki is completely right. The rest settings in xwiki.cfg are intact. Kind regards Dmitry PS. Sorry for the private mailing 30 января 2012, 20:46 от Thomas Mortagne thomas.morta...@xwiki.com: On Mon, Jan 30, 2012 at 5:06 PM, Haru Mamburu haru_mamb...@mail.ru wrote: Hi, All! Does anyone know, is it possible to change default DB name xwiki to smth else? I changed in config.cfg, xwiki.db=test in hibernate.cfg.xml property name=connection.urljdbc:mysql://localhost/test/property After XWiki reload it tries to access xwiki db still. :-( What is correct way to do it? Well that's supposed to be the correct way actually. You sure you uncommented xwiki.db ? Thanks in advance, Dmitry ___ 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] dafault DB name change
] at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3609) ~[mysql-connector-java-5.1.18-bin.jar:na] at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3541) ~[mysql-connector-java-5.1.18-bin.jar:na] at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2002) ~[mysql-connector-java-5.1.18-bin.jar:na] at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2163) ~[mysql-connector-java-5.1.18-bin.jar:na] at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2618) ~[mysql-connector-java-5.1.18-bin.jar:na] at com.mysql.jdbc.ConnectionImpl.setCatalog(ConnectionImpl.java:5086) ~[mysql-connector-java-5.1.18-bin.jar:na] at org.apache.commons.dbcp.DelegatingConnection.setCatalog(DelegatingConnection.java:374) ~[commons-dbcp-1.3.jar:1.3] at org.apache.commons.dbcp.DelegatingConnection.setCatalog(DelegatingConnection.java:374) ~[commons-dbcp-1.3.jar:1.3] at org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.setCatalog(PoolingDataSource.java:333) ~[commons-dbcp-1.3.jar:1.3] at sun.reflect.GeneratedMethodAccessor164.invoke(Unknown Source) ~[na:na] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) ~[na:1.6.0_26] at java.lang.reflect.Method.invoke(Method.java:597) ~[na:1.6.0_26] at org.hibernate.jdbc.BorrowedConnectionProxy.invoke(BorrowedConnectionProxy.java:74) ~[hibernate-core-3.6.9.Final.jar:3.6.9.Final] at $Proxy213.setCatalog(Unknown Source) ~[na:na] at com.xpn.xwiki.store.XWikiHibernateBaseStore.setDatabase(XWikiHibernateBaseStore.java:620) ~[xwiki-platform-legacy-oldcore-3.4.jar:na] ... 69 common frames omitted 30 января 2012, 21:29 от Thomas Mortagne thomas.morta...@xwiki.com: On Mon, Jan 30, 2012 at 6:10 PM, Haru Mamburu haru_mamb...@mail.ru wrote: Yes, I did. :-( XEM 3.4 javax.servlet.ServletException: com.xpn.xwiki.XWikiException: Error number 3 in 0: Could not initialize main XWiki context Wrapped Exception: Error number 3202 in 3: Exception while reading document [name = [XWikiPreferences], type = [DOCUMENT], parent = [name = [XWiki], type = [SPACE], parent = [name = [xwiki], type = [WIKI], parent = [null Wrapped Exception: Error number 3301 in 3: Exception while switching to database xwiki Wrapped Exception: Access denied for user 'test'@'localhost' to database 'xwiki' Do you have more ? Would be nice to get the full stack trace. And actually there is no DB xwiki in Mysql. Xwiki is completely right. The rest settings in xwiki.cfg are intact. Kind regards Dmitry PS. Sorry for the private mailing 30 января 2012, 20:46 от Thomas Mortagne thomas.morta...@xwiki.com: On Mon, Jan 30, 2012 at 5:06 PM, Haru Mamburu haru_mamb...@mail.ru wrote: Hi, All! Does anyone know, is it possible to change default DB name xwiki to smth else? I changed in config.cfg, xwiki.db=test in hibernate.cfg.xml property name=connection.urljdbc:mysql://localhost/test/property After XWiki reload it tries to access xwiki db still. :-( What is correct way to do it? Well that's supposed to be the correct way actually. You sure you uncommented xwiki.db ? Thanks in advance, Dmitry ___ 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 -- Thomas Mortagne ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Workspace manager free default pages set
Hi All, By accident I found a soluion. For me it looks a bit wierd. If you set in xwiki.cfg xwiki.virtual.usepath to 0, then all menus become Workspace Manager links free. For now, if I want to use usepath and don't want to use Workspace Manager, there is no an one click solution :-( Is it a bug or it's a feature? Should I report it? Kind regards, Dmitry 27 января 2012, 01:34 от Haru Mamburu haru_mamb...@mail.ru: Hi. all! XEM 3.4. Main Wiki works fine. I want to set up virtual wiki without Workspace Manager application inside and it's links in menu, because as far as I inderstood it is useless in virtual wikis. What is right way to get rid of Workspace Manager and it's links in top menu in virtual wiki? Kind regards, Dmitry ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Workspace manager free default pages set
Ooops, wrong solution. The problem is still active: is there a right way to get rid of Workspace Manager's links in virtual wikis in 3.4? 27 января 2012, 13:46 от Haru Mamburu haru_mamb...@mail.ru: Hi All, By accident I found a soluion. For me it looks a bit wierd. If you set in xwiki.cfg xwiki.virtual.usepath to 0, then all menus become Workspace Manager links free. For now, if I want to use usepath and don't want to use Workspace Manager, there is no an one click solution :-( Is it a bug or it's a feature? Should I report it? Kind regards, Dmitry 27 января 2012, 01:34 от Haru Mamburu haru_mamb...@mail.ru: Hi. all! XEM 3.4. Main Wiki works fine. I want to set up virtual wiki without Workspace Manager application inside and it's links in menu, because as far as I inderstood it is useless in virtual wikis. What is right way to get rid of Workspace Manager and it's links in top menu in virtual wiki? Kind regards, Dmitry ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Workspace manager free default pages set
Thank you Eduard, Sorry, probably I wasn't clear in my questions... - I want to use WORKSPACE Manager on MAIN Wiki and manage them as designed. - BUT, the same time I want to use WIKI Manager to have completely independent from main wiki and other workspaces virtual wikis. So, I set up XEM, installed Workspace manager to play around AND with Wiki Manager created virtual Wiki. Now I completely stuck how to get rid of all Workspace Manager links in wiki farm (!) (not workspaces). I would prefer to keep running Workspace Manager on main Wiki AND Wiki farm simultaneously, if possible. Is there any simple solution? The only thing I suppose should work is to take *.vm files from XE and attach them to the skin file. Looks wierd and unpredictable for me :-( Kind Regards, Dmitry 27 января 2012, 14:26 от Eduard Moraru enygma2...@gmail.com: Hi Dmitry, Starting with 3.3, XEM has moved the main usecase for subwikis from farm to workspaces. This means that, additionally to the WikiManager application [1], now XEM also contains the Workspace Application [2]. The encouraged way of for creating a wiki farm right now (if that is really what you need) is to get XE, install WikiManager [1] and create your farm. If you *insist* on using XEM for creating a wiki farm, all you have to do is delete the WorkspaceManager space, thus removing the Workspaces application and disabling the extra menus that were getting in your way. Additionally, you should also remove the xwiki-platform-workspace-api-version.jar file from the /webapps/xwiki/WEB-INF/lib/ folder, since you don`t want to use it anymore and you have removed the UI. However, if your plan is to have global users that work on different subwikis (like an intranet with departments mapped to subwikis or a place where you work on projects mapped to subwikis, etc.), you might reconsider using Workspaces. In any case, I hope this solves your problem. Thanks, Eduard - References: [1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Wiki+Manager+Application [2] http://extensions.xwiki.org/xwiki/bin/view/Extension/Workspace+Application On Fri, Jan 27, 2012 at 11:57 AM, Haru Mamburu haru_mamb...@mail.ru wrote: Ooops, wrong solution. The problem is still active: is there a right way to get rid of Workspace Manager's links in virtual wikis in 3.4? 27 января 2012, 13:46 от Haru Mamburu haru_mamb...@mail.ru: Hi All, By accident I found a soluion. For me it looks a bit wierd. If you set in xwiki.cfg xwiki.virtual.usepath to 0, then all menus become Workspace Manager links free. For now, if I want to use usepath and don't want to use Workspace Manager, there is no an one click solution :-( Is it a bug or it's a feature? Should I report it? Kind regards, Dmitry 27 января 2012, 01:34 от Haru Mamburu haru_mamb...@mail.ru: Hi. all! XEM 3.4. Main Wiki works fine. I want to set up virtual wiki without Workspace Manager application inside and it's links in menu, because as far as I inderstood it is useless in virtual wikis. What is right way to get rid of Workspace Manager and it's links in top menu in virtual wiki? Kind regards, Dmitry ___ 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] Workspace manager free default pages set
Thanks a lot for clarification. It makes sence now from explained point of view, but I still can't get WHY as global user on NON-workspace wiki I should see Workspace Manager menus? Anyhow I can't use Workspace Manager INSIDE virtual Wiki. It makes sence if you would extend Workspace manager and make it completely independent on each and every virtual wiki. So, the main reason why: it's just useles inside virtual wiki (for now) For me, e.g., ideal workflow looks like: Case 1. XEM - virtual wiki isolated, no Workspace Manager on board Case 2. XEM - virtual wiki isolated, WITH Workspace Manager on board. Each virtual wiki in this case will be able to produce it's own workspaces isolated from each other (like independent projects on the same server). Only Local Users can take part in workspace management. Case 3. XEM - virtual wiki isolated + Workspace manager on board. Same as Case 2, but Local Users can log once in any virtual/workspace wiki they allowed AND via this login have access to each and every wiki they registered/invited. For current purposes I would prefer Case 1 behaviour. Soon I'd like to use Case 2 then 3 scenario, but for now - no way :-( Hope it would be useful for futher development. Kind Regards, Dmitry 27 января 2012, 16:48 от Eduard Moraru enygma2...@gmail.com: Oh, I see now. The way it works now when visiting a normal subwiki (not a workspace) is that: 1) If you are a global user (user of the main wiki), the menus will be displayed to you (and you will be thus exposed to the global context of which you are part of). 2) If you are a local user (user of a subwiki that is part of a wiki *farm*), you don`t see the menus any more and are isolated inside the wiki (and not exposed to the global context). So, as a conclusion, the menus appear to you based on your user type and not on the type of wiki you are currently viewing. Does that make sense now? Does this fit your usecase? If not, can you please elaborate on the reason why you would like global users not to be able to see the global context when viewing a regular subwiki? Thanks, Eduard On Fri, Jan 27, 2012 at 1:32 PM, Haru Mamburu haru_mamb...@mail.ru wrote: Thank you Eduard, Sorry, probably I wasn't clear in my questions... - I want to use WORKSPACE Manager on MAIN Wiki and manage them as designed. - BUT, the same time I want to use WIKI Manager to have completely independent from main wiki and other workspaces virtual wikis. So, I set up XEM, installed Workspace manager to play around AND with Wiki Manager created virtual Wiki. Now I completely stuck how to get rid of all Workspace Manager links in wiki farm (!) (not workspaces). I would prefer to keep running Workspace Manager on main Wiki AND Wiki farm simultaneously, if possible. Is there any simple solution? The only thing I suppose should work is to take *.vm files from XE and attach them to the skin file. Looks wierd and unpredictable for me :-( Kind Regards, Dmitry 27 января 2012, 14:26 от Eduard Moraru enygma2...@gmail.com: Hi Dmitry, Starting with 3.3, XEM has moved the main usecase for subwikis from farm to workspaces. This means that, additionally to the WikiManager application [1], now XEM also contains the Workspace Application [2]. The encouraged way of for creating a wiki farm right now (if that is really what you need) is to get XE, install WikiManager [1] and create your farm. If you *insist* on using XEM for creating a wiki farm, all you have to do is delete the WorkspaceManager space, thus removing the Workspaces application and disabling the extra menus that were getting in your way. Additionally, you should also remove the xwiki-platform-workspace-api-version.jar file from the /webapps/xwiki/WEB-INF/lib/ folder, since you don`t want to use it anymore and you have removed the UI. However, if your plan is to have global users that work on different subwikis (like an intranet with departments mapped to subwikis or a place where you work on projects mapped to subwikis, etc.), you might reconsider using Workspaces. In any case, I hope this solves your problem. Thanks, Eduard - References: [1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Wiki+Manager+Application [2] http://extensions.xwiki.org/xwiki/bin/view/Extension/Workspace+Application On Fri, Jan 27, 2012 at 11:57 AM, Haru Mamburu haru_mamb...@mail.ru wrote: Ooops, wrong solution. The problem is still active: is there a right way to get rid of Workspace Manager's links in virtual wikis in 3.4? 27 января 2012, 13:46 от Haru Mamburu haru_mamb...@mail.ru: Hi All, By accident I found a soluion. For me it looks a bit wierd. If you set in xwiki.cfg xwiki.virtual.usepath to 0, then all menus become Workspace Manager links free. For now, if I want to use usepath and don't want to use Workspace Manager, there is no an one click solution :-( Is it a bug or it's a feature? Should I report it? Kind
[xwiki-users] Workspace manager free default pages set
Hi. all! XEM 3.4. Main Wiki works fine. I want to set up virtual wiki without Workspace Manager application inside and it's links in menu, because as far as I inderstood it is useless in virtual wikis. What is right way to get rid of Workspace Manager and it's links in top menu in virtual wiki? Kind regards, Dmitry ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
[xwiki-users] Selected pages of PDF to image conversion in XWiki?
Hi! The task is: - Calculate MD5 of attached PDF document - Extract e.g first 10 pages from the attached PDF file as images - store images as attachments into the document 1. What is the best way to calculate MD5 in XWiki? Is it possible to do via standard velocity scripting in XWiki? 2. Is there any built in/hidden ways of PDF-image conversion of several pages of attached PDF file? If not, what is the solution possible? I found some opensource JAVA libraries, but I realize a big gap in my understanding between libraries and their integration in XWiki with followng velocity scripting usage. Does anyone has a clue where to dig to make all this staff runnung? Thanks in advance, Dmitry ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Status of filesystem attachment storage.
Hi, I had been playing with FS for quite a long time and must say, that it is almost ready for production: - Looks stable, major and minor bug fixes were made. - Since 3.4 it deals with non-ascii correctly. I checked it with Cyrillic on 3.4RC1. - If you would turn FS on, be aware, that recycle bin with FS works, BUT still we have http://jira.xwiki.org/browse/XWIKI-7399 So, I didn't manage to make it running. So, I just switched off recycle bin for attachments, because this bug makes deleted attachment unmanaged. :-( If so - why in 3.4 versions default storage for attachments will be hibernate? If you don't play with large attachments (like I do), for clusering and maintainance it would much easier to keep all attachments in DB. Traditionally it was DB :-) As for me, Attachments size is relatively huge and will make all system very slow very soon, so I use FS from the very beginning of the project. Kind Regards Dmitry 25 января 2012, 01:37 от Ryszard Łach ryszard.l...@contium.pl: Hi. Could anyone, please, give any info about status of filesystem attachment storage? Is it stable? Does it deal with non-ascii filenames prolerply? If so - why in 3.4 versions default storage for attachments will be hibernate? Cheers, R. -- ___ 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] Version Error
Looks like http://platform.xwiki.org/xwiki/bin/view/AdminGuide/InstallationMySQL#HHTTP500Error Try this. Hope it will help. Kind Regards, Dmitry 23 января 2012, 20:10 от eparent_pk epar...@photonicknowledge.com: Hi, I'm having the http://pastebin.com/k5V6mBha same error . My xwiki installation is Enterprise 3.3, on Ubuntu 11.10 (x64) with tomcat6. I installed following the instructions on this http://blog.dontneedcoffee.com/2010/02/install-xwiki-22-on-ubuntu-910-mysql.html site . Here is an example of my http://pastebin.com/HEPmAAeQ hibernate.cfg.xml . I created MySQL user 'xwiki' who was granted with create, insert, alter, delete entries for the xwiki database. All the setup tutorials I've seen are quite straight forward but, for some reason, I just can't get it to work. Any hint / advice will be appreciated. Cheers, - Eric -- View this message in context: http://xwiki.475771.n2.nabble.com/Version-Error-tp6480013p7216532.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 ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] XWiki Enterprise and XWiki Enterprise Manager 3.4 Milestone 1 Released
Hi! Thanks a lot for the new XWiki version. As for: New default color theme - http://jira.xwiki.org/browse/XWIKI-6982 It's the old one, but looks actual still. Great thanks for: * Special characters in attachment name. I checked cyrillic names - works fine. Also I checked an issue we couldn't reproduce earlier. It failed to work again. http://jira.xwiki.org/browse/XWIKI-7399 Kindly ask somebody to reproduce steps in this JIRA issue and prove the bug or clarify how to avoid it. Till now I failed to get it working :-( Thanks in advance, Dmitry 13 января 2012, 22:00 от Marius Dumitru Florea mariusdumitru.flo...@xwiki.com: The XWiki development team is proud to announce the availability of XWiki Commons, XWiki Rendering, XWiki Platform, XWiki Enterprise and XWiki Enterprise Manager 3.4 Milestone 1. This is the first and only milestone of the 3.4 version. We're getting closer to the end of the 3.x cycle and the goal of this release (and the following one, which will be the last of the cycle) is to improve the current features. The highlights of this release are: * New default color theme * XWiki 2.1 is the default page syntax * Delete space menu * Simple space templates * Special characters in attachment name * Minimized action menu * Display macro * Improved Extension Manager UI See the full release notes at http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterprise34M1 for more details. Thanks -The XWiki dev team ___ 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] [Help] Help us improve the XWiki documentation by telling us what's missing
Hi, Vincent, I put an issue XWiki setup and configuration issues at http://jira.xwiki.org/browse/XWIKIORG-25 Probably, the list of setup problems is not full and somebody would extend it. :-) Kind regards, Dmitry 05 января 2012, 14:07 от Vincent Massol vinc...@massol.net: Guys, we didn't get any new JIRA issue on improving the xwiki.org documentation. So I guess it means our documentation is perfect and there's nothing to improve, right? :) Come on, help us identify precise stuff that need improvement. I'm sure you have had problems finding information about something in the past! Thanks -Vincent On Dec 20, 2011, at 2:16 PM, Vincent Massol wrote: Hi XWiki users, The XWiki projects needs your help. We'd like to improve the documentation on xwiki.org but we need your help to tell us what should be improved in your opinion. To do so we've created a JIRA project for listing stuff to do: http://jira.xwiki.org/browse/XWIKIORG It would be a great help if you could register there and create JIRA issues for anything you think should be improved on xwiki.org. Please try to create very specific and focused issues so that they are actionable easily (for example an issue saying Improve xwiki.org documentation would not help much ;) but one that would say for example: Provide documentation on how to use the DBListClass is useful). Thanks a lot for your help! -Vincent on behalf of the XWiki Dev Team ___ 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] Tomcat and /xwiki path
Thanks a lot, Sergiu!
Understanding logic behind something makes it much easier to find right
solution. :-)
Also I updated documentation
http://platform.xwiki.org/xwiki/bin/view/AdminGuide/InstallationTomcat#HNginxproxyingforTomcatapplications
to save nginx newbies time for setting it up.
Kind regards,
Dmitry Bakbardin
26 декабря 2011, 10:25 от Sergiu Dumitriu ser...@xwiki.com:
On 12/25/2011 03:04 PM, Haru Mamburu wrote:
Hi, All
Recently I had to deploy XWiki under Centos. As a brand new task for me it
required tonns of documentation to dig in.
Finally I managed to set up: Centos + MySQL + Tomcat 7 + nginx.
Everything is fine besides some Tomcat's behaviour.
- localhost:8080 or localhost:8080/ shows ROOT application
- localhost:8080/xwiki shows XWiki application as desired. Fine.
- if nginx redirects required requests from 80 port to localhost:8080/xwiki
we obtain wrong links, because /xwiki automatically is added to requested
string. Works fine only first request to e.g. mydomain.com.
So, next step is to set XWiki application as DAFAULT application in Tomcat,
so localhost:8080 will call XWiki by default.
Googling gave me several complicated solutions with redirect and two almost
clear solutions with Tomcat configuration:
- Deploy XWiki in $CATALINA_HOME/webapps/ROOT
After this nginx can easily proxy all requests like mydomain.com on 80
port to localhost:8080
- Deploy XWiki in $CATALINA_HOME/webapps/xwiki
Then add Following string in Host section in $CATALINA_HOME/conf/server.xml
:
Context path= docBase=${catalina.home}/webapps/xwiki/
I tried second way, it works fine, nginx redirects all mydomain.com
requests to localhost:8080 correctly, BUT all URLs from required, e.g,
localhost:8080/xwiki/bin/view/Main
become
localhost:8080/bin/view/Main
So, we miss /xwiki in URL.
As for me, xwikiless URLs solution looks fine, BUT as far as I remember,
somebody from developers' team pointed out in mailing lists some time ago,
that /xwiki in URL could be necessary in some cases. (??)
The questions are:
1. Is it crucial for XWiki and/or some XWiki applications to eat shorten
URL on Tomcat's level?
Will it affect, for example, on virtual wiki mapping for URLs based
addresses like http://myfarm.net/xwiki/wiki/wikiname/?
XWiki should work just fine with the shorter URLs. The xwikiless
information might be very outdated, when it used to be true that some
parts of XWiki would fail.
2. Should we change anything in XWiki configuration files to force it
working with such URLs?
No.
OR, the best way to put ${catalina.home}/webapps/ROOT/Web-inf/web.xml with
redirect information as it is done e.g. in standalone XWiki for Windows?
From other side, I also found an opinions on forums, that redirect method
is not the best solution for search engines robots. So, I got lost a bit :-)
Kindly ask you to clarify this tricky subject in order to avoid unnecessary
errors in the future.
On finding right, community approved solution(s), I will amend
documentation accordingly.
It should also be possible to configure nginx to work properly with
XWiki deployed as /xwiki/, so if you want, you can dig some more to find
out why it doesn't work right now and what to do to make it work.
My guess is that you're trying to map :80/* to :8080/xwiki/* which means
that /xwiki/ will be added to each URL that nginx requests from Tomcat,
including those that already have /xwiki in them. Thus, all the URLs
generated by XWiki, such as /xwiki/bin/view/Some/Doc, will end up as
:8080/xwiki/xwiki/bin/view/Some/Doc, which is wrong. You should have two
different rules if you want to keep /xwiki/ in the URL:
1. Redirect from hostname.com/ to hostname.com/xwiki, as a client
response redirect, not as an internal forwarding.
2. Forward requests to /xwiki/* to :8080/xwiki/*
Thanks in advance,
Dmitry Bakbardin
--
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
[xwiki-users] Tomcat and /xwiki path
Hi, All
Recently I had to deploy XWiki under Centos. As a brand new task for me it
required tonns of documentation to dig in.
Finally I managed to set up: Centos + MySQL + Tomcat 7 + nginx.
Everything is fine besides some Tomcat's behaviour.
- localhost:8080 or localhost:8080/ shows ROOT application
- localhost:8080/xwiki shows XWiki application as desired. Fine.
- if nginx redirects required requests from 80 port to localhost:8080/xwiki we
obtain wrong links, because /xwiki automatically is added to requested string.
Works fine only first request to e.g. mydomain.com.
So, next step is to set XWiki application as DAFAULT application in Tomcat, so
localhost:8080 will call XWiki by default.
Googling gave me several complicated solutions with redirect and two almost
clear solutions with Tomcat configuration:
- Deploy XWiki in $CATALINA_HOME/webapps/ROOT
After this nginx can easily proxy all requests like mydomain.com on 80 port
to localhost:8080
- Deploy XWiki in $CATALINA_HOME/webapps/xwiki
Then add Following string in Host section in $CATALINA_HOME/conf/server.xml :
Context path= docBase=${catalina.home}/webapps/xwiki/
I tried second way, it works fine, nginx redirects all mydomain.com requests
to localhost:8080 correctly, BUT all URLs from required, e.g,
localhost:8080/xwiki/bin/view/Main
become
localhost:8080/bin/view/Main
So, we miss /xwiki in URL.
As for me, xwikiless URLs solution looks fine, BUT as far as I remember,
somebody from developers' team pointed out in mailing lists some time ago, that
/xwiki in URL could be necessary in some cases. (??)
The questions are:
1. Is it crucial for XWiki and/or some XWiki applications to eat shorten URL on
Tomcat's level?
Will it affect, for example, on virtual wiki mapping for URLs based addresses
like http://myfarm.net/xwiki/wiki/wikiname/?
2. Should we change anything in XWiki configuration files to force it working
with such URLs?
OR, the best way to put ${catalina.home}/webapps/ROOT/Web-inf/web.xml with
redirect information as it is done e.g. in standalone XWiki for Windows?
From other side, I also found an opinions on forums, that redirect method is
not the best solution for search engines robots. So, I got lost a bit :-)
Kindly ask you to clarify this tricky subject in order to avoid unnecessary
errors in the future.
On finding right, community approved solution(s), I will amend documentation
accordingly.
Thanks in advance,
Dmitry Bakbardin
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] [Announcement] XWiki Enterprise 3.3 and XWiki Enterprise Manager 3.3 Released
One more vote on board :-) 18 декабря 2011, 01:49 от Ludovic Dubost ludo...@xwiki.com: 2011/12/17 Eugen Colesnicov ecolesni...@gmail.com Thanks for great job! Especially for the Oracle support! Also AppWithinMinutes looks very interesting - I will start to feel it! Also, regarding to your discussion about 3.4 roadmap and 3.x cycle, I want one more time to focus you at an older problem - supporting of russian symbols (or other non-latin characters, spaces and special symbols) in attachment names. Interesting moment. If you using office importer and your office-file named in russian, and your file contains some pictures, when wiki-page creates - ALL PICTURE ATTACHMENT FILENAMES WRITTEN ON RUSSIAN WITHOUT ANY PROBLEM! I can download them, get link, etc. According to this I can make a conclusion, that supporting of non-latin attachment filenames is ALREADY DONE ON A PLATFORM LEVEL. And, right now, for my opinion, NEED ONLY SMALL STEP - DELETE FUNCTION OF CUTTING NON-LATIN SYMBOLS FROM ATTACHMENT FILENAMES DURING NORMAL ATTACH PROCESS. Good point, maybe a patch could be provided that deactivates this stripping using a configuration setting. I would vote +1 to include it asap in the platform. Ludovic Please, include this issue in your roadmap of 3.x cycle! This is really important thing - because without this XWiki cannot named as multilanguage web platform. ALL OTHER MODERN WEB-PLATFORMS ALREADY HAVE THIS FUTURE... Only XWiki lagging ... -- Best regards Eugen Colesnicov -- View this message in context: http://xwiki.475771.n2.nabble.com/Announcement-XWiki-Enterprise-3-3-and-XWiki-Enterprise-Manager-3-3-Released-tp7103443p7103549.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 -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost ___ 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] Each sub-wiki has own storage location... is it possible?
Thanks, now all you need is to attach the patch or issue a git pull request :) Welcome, but still kindly ask you to clarify what exactly to do :) I got lost a bit :( Thanks a lot, Dmitry 09 декабря 2011, 13:09 от Vincent Massol vinc...@massol.net: Hi Haru, On Dec 9, 2011, at 6:34 AM, Haru Mamburu wrote: Thanks a lot, Vincent, Nice, I get credit even when I don't speak :) I issued a feature request, http://jira.xwiki.org/browse/XE-1061 Thanks, now all you need is to attach the patch or issue a git pull request :) Cheers, -Vincent Kind Regards Dmitry 09 декабря 2011, 09:16 от Ludovic Dubost ludo...@xwiki.com: I don't think it has been done but it shouldnt be a difficult patch Ludovic Envoyé de mon iPhone Le 8 déc. 2011 à 23:01, Haru Mamburu haru_mamb...@mail.ru a écrit : Does anyone has a clue? 04 декабря 2011, 06:50 от Haru Mamburu haru_mamb...@mail.ru: Hi, all! For now we have a possibility to move wiki's filestorage easily by changing path in config file. Cool! In multi-sub-wiki environment it looks very useful (sometimes) to split common storage and move sub-wiki's storage to other place. Is there any simple way to set location of each sub-wiki's storage? If not, is it easy to implement? Kind Regards Dmitry Bakbardin ___ 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] Push on translations
Hi! I fixed Russian translation both for XE and Wiki Manager. Some links look broken in the right panel Supported Languages for XE, what may lead to misunderstanding especially for new users. Also Best XE Contributors left panel is still in TODO list. :-) Kind Regards, Dmitry Bakbardin 08 декабря 2011, 12:49 от Ludovic Dubost ludo...@xwiki.com: Hi XWiki devs and users, I think we need to make a push on translations. We have about 150 translations that are not yet available in French German Latvian Russian Swedish Otherwise we have the following language that would need a small push to get complete: Spanish (es) 459 translations Czech (cs) 258 translations Traditional Chinese (zh_TW) 641 Catalan 863 It would be great to get some contributors for Italian Portugese Dutch Any help is welcome to get this down. If you want to help you can go to http://l10n.xwiki.org If we get the translations numbers under 250 we'll make sure we get the translations in the distribution. Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost ___ 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] Each sub-wiki has own storage location... is it possible?
Thanks a lot, Vincent, I issued a feature request, http://jira.xwiki.org/browse/XE-1061 Kind Regards Dmitry 09 декабря 2011, 09:16 от Ludovic Dubost ludo...@xwiki.com: I don't think it has been done but it shouldnt be a difficult patch Ludovic Envoyé de mon iPhone Le 8 déc. 2011 à 23:01, Haru Mamburu haru_mamb...@mail.ru a écrit : Does anyone has a clue? 04 декабря 2011, 06:50 от Haru Mamburu haru_mamb...@mail.ru: Hi, all! For now we have a possibility to move wiki's filestorage easily by changing path in config file. Cool! In multi-sub-wiki environment it looks very useful (sometimes) to split common storage and move sub-wiki's storage to other place. Is there any simple way to set location of each sub-wiki's storage? If not, is it easy to implement? Kind Regards Dmitry Bakbardin ___ 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
[xwiki-users] Each sub-wiki has own storage location... is it possible?
Hi, all! For now we have a possibility to move wiki's filestorage easily by changing path in config file. Cool! In multi-sub-wiki environment it looks very useful (sometimes) to split common storage and move sub-wiki's storage to other place. Is there any simple way to set location of each sub-wiki's storage? If not, is it easy to implement? Kind Regards Dmitry Bakbardin ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] XOffice not downloading pages, missing attachments
Hi, Paul, IMHO, from one side Xoffice - great tool, from other - it's almost useless: - MS Word is not the only editor in the PC world - MS Word is relatively heavy application. - Installation process is far from seamless - huge headache for people who have almost no free time and are not interested in learning yet another program. They will have to spend 10 times more time on installing it, than on mastering WYSIWYG editor. Just try it on 10 users, you will see the difference :-) - Localization (here I mean cyrillic names) Much more versatile tool - web browser. Everyone we talked to about editing a wiki document via the web interface was simply not interested. When human has choice to learn or skip learning with the same final result, usually choice is obvious. Nobody ever will find browser more useful, then MS Word, until you will close MS Word option forever. That's human. Meanwhile each and every user wil find it more useful for them, then old-styled-word editing. So, in this case - CHOICE is bad thing to move forward. Try it on regular users and you will feel it yourself. Last century people mastered MS Word, this century people found it extrafeatured, simplified as much as possible editing process and made wiki-cloud based systems default for document workflow. So, for more or less big projects: Windows and Word purchase looks insane versus open source OS + web browser. As I understand, it's the only reason, why other project do not such tools (like XOffice). I do have MS Word on my Windows 7 machine, but I don't remember when I used it last time to EDIT documents. ;) As for me, XWiki has one of the best in class web-based WISIWYG editor and all known for me users found it easy to use: NO NEED to dig into XWiki Syntax AT ALL. Just try other solutions to compare. The killer feature is that normal users can create a document and copy-paste screenshots into a wiki document. This really has sence to implement into WISYWIG editor, but don't think it's a primary necessity. For me, for example, more critical - less complicated mechanism of anchor management. Probably, these reasons are slowly pushing Xoffice aside of mainstream. Kind regards. Dmitry Bakbardin 24 октября 2011, 18:36 от Paul Harris harris...@gmail.com: The killer feature is that normal users can create a document and copy-paste screenshots into a wiki document. That cannot be done with (almost) any web wiki editor I can find at present. Every person we showed it to loved it, and was willing to try editing a document on the wiki. Everyone we talked to about editing a wiki document via the web interface was simply not interested. We work with people who have almost no free time and are not interested in learning yet another program (ie web-wiki)... They know MS Word well, they are already read to write content. I don't understand why you aren't pushing this simple but powerful component more. I don't see it mentioned on wikipedia, or wikimatrix. I think if you made sure xoffice worked, and let people know it existed, then more people would use xwiki. Its a killer feature and I don't understand why its not on billboards on the sides of freeways. Regards, Paul On 24 October 2011 20:35, Florin Ciubotaru florin.ciubot...@xwiki.comwrote: Hi, If you didn't start your documentation yet and you don't have any legacy documents, I'd recommend using a pure web solution like XWiki. If you use MS Office for advanced content, you will have issues pushing that content to the wiki anyway. I created XOffice a few years ago, when MS Office was a lot more dominant and web editors were still weak(including the one used by XWiki), but the situation is quite different now. Indeed there was no development on it for the past year. If you have critical issues with XOffice, it may be one of the following: - you are using a localized version of Office or Windows (there are older known issues with those) - there is a conflict with newer XWiki versions. The MS Office and Windows behavior and security settings are different for versions released on other languages. It doesn't make a lot of sense, but that's the way it is. I've been receiving quite a few requests for a new release. However I could only do some bug fixing only for the En/En environment, since it's a pain to test and fix other versions. Thanks, Florin Ciubotau On Mon, Oct 24, 2011 at 9:46 AM, Vincent Massol vinc...@massol.net wrote: Hi Paul, Indeed nobody is actively working on it at the moment and I was about to send a mail this week to propose to retire it and move it to the contrib repository since nobody in the xwiki committers are active on it and we want to keep a good quality on the software that we make available. The only alternative would be someone stepping up and willing to work on it and ensure it works with latest XWiki
Re: [xwiki-users] 4Developers: more important issues regarding to XE 3.3 Roadmap
Thank you, Caleb, But JIRA says, that I can't vote on the topics I issued, so 0 means +1 :-) Kind regards, Dmitry 20 октября 2011, 12:49 от Caleb James DeLisle calebdeli...@lavabit.com: I have just assigned myself XWIKI-6918 and XWIKI-6917, the bugs. You can go ahead and vote on the feature requests (resume download and webdav access) and we can see where things go from there. Caleb On 10/20/2011 04:02 AM, Haru Mamburu wrote: Hi, All Also, I'd add all bug fixes with file storage system, because for now, I have had to switch off (in 3.2): - versioning of attachment - recycle bin for attachment to use it more or less seamless. Otherwise, there is a big mess with deleted attachment occure. Everything I found, JIRAded already: XWIKI-6989, XWIKI-6921, XWIKI-6918, XWIKI-6917. Would be nice also to have resume download for big files: XWIKI-6921 So, we have a new feature, but with a very limited functionality, that really works. Moreover, not each and every core functions really support attachments, stored in FS. For projects with big and huge attachments these topics are essential, IMO. Some additional support for cyrillic XWIKI-6955 is also welcome to put in plan. :-) Best regards, Dmitry Bakbardin 20 октября 2011, 11:25 от Eugen Colesnicov ecolesni...@gmail.com: Hello developers! I seen your thread about XE 3.3 Roadmap + Finishing the 3.x cycle. In this post also described jira-requests, which you planned to resolve in a near future. All is great, the general strategy and each step are right, but also exists some other important issues (I think that its are important) and I want to put your attention on its. If is it possible, can you analyze possibility to include these issues in your nearly plans? 1. XE-1032 - XWiki 3.2 totally cannot work on Oracle (upgrade fresh install failed). I think, it is important issue, because supporting of Oracle are declared - but in realty XE 3.2 is not supporting Oracle. To the future, maybe is good proposal, same as you wrote in a 3.2 release notes - which browsers are tested supporting - also will write witch DB are tested supporting. I can test new releases on Oracle. 2. XE-324 - allow special (russian and asian) characters in attachment names - very old issue, but I think is important, because without it - you cannot declare that XWiki have normal multi-language support. All modern web-platforms applications now have this possibility (wikis, web-mails, social applications, etc.) only XWiki is lagging... 3. XWIKI-2870 - Ability to select query language in Database List property. This is more for developers, and also very old issue. I think it is important, because if you did something modern (in this case - XWQL) - need to support this in all parts of platform... If you didn't do this - your great work for modern features - looks like as garbage - I cannot use XWQL in Database List property - as a result - I am not using XWQL at all, because I don't want to write queries 2 times. If is it possible, can you analyze possibility to include these issues in your nearly plans? PS. Maybe another users know some more important unresolved issues? I think, user opinions will be interesting for developers! Thanks beforehand! Eugen Colesnicov -- View this message in context: http://xwiki.475771.n2.nabble.com/4Developers-more-important-issues-regarding-to-XE-3-3-Roadmap-tp6911884p6911884.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 ___ 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] 4Developers: more important issues regarding to XE 3.3 Roadmap
Yes I do have JIRA account, just try to vote for your own issues, I don't think you will succeed. Have a look at file attached. :-) Dmitry 20 октября 2011, 16:47 от Thomas Mortagne thomas.morta...@xwiki.com: On Thu, Oct 20, 2011 at 2:13 PM, Haru Mamburu haru_mamb...@mail.ru wrote: Thank you, Caleb, But JIRA says, that I can't vote on the topics I issued, so 0 means +1 :-) That's weird, do you have an account on jira ? Kind regards, Dmitry 20 октября 2011, 12:49 от Caleb James DeLisle calebdeli...@lavabit.com: I have just assigned myself XWIKI-6918 and XWIKI-6917, the bugs. You can go ahead and vote on the feature requests (resume download and webdav access) and we can see where things go from there. Caleb On 10/20/2011 04:02 AM, Haru Mamburu wrote: Hi, All Also, I'd add all bug fixes with file storage system, because for now, I have had to switch off (in 3.2): - versioning of attachment - recycle bin for attachment to use it more or less seamless. Otherwise, there is a big mess with deleted attachment occure. Everything I found, JIRAded already: XWIKI-6989, XWIKI-6921, XWIKI-6918, XWIKI-6917. Would be nice also to have resume download for big files: XWIKI-6921 So, we have a new feature, but with a very limited functionality, that really works. Moreover, not each and every core functions really support attachments, stored in FS. For projects with big and huge attachments these topics are essential, IMO. Some additional support for cyrillic XWIKI-6955 is also welcome to put in plan. :-) Best regards, Dmitry Bakbardin 20 октября 2011, 11:25 от Eugen Colesnicov ecolesni...@gmail.com: Hello developers! I seen your thread about XE 3.3 Roadmap + Finishing the 3.x cycle. In this post also described jira-requests, which you planned to resolve in a near future. All is great, the general strategy and each step are right, but also exists some other important issues (I think that its are important) and I want to put your attention on its. If is it possible, can you analyze possibility to include these issues in your nearly plans? 1. XE-1032 - XWiki 3.2 totally cannot work on Oracle (upgrade fresh install failed). I think, it is important issue, because supporting of Oracle are declared - but in realty XE 3.2 is not supporting Oracle. To the future, maybe is good proposal, same as you wrote in a 3.2 release notes - which browsers are tested supporting - also will write witch DB are tested supporting. I can test new releases on Oracle. 2. XE-324 - allow special (russian and asian) characters in attachment names - very old issue, but I think is important, because without it - you cannot declare that XWiki have normal multi-language support. All modern web-platforms applications now have this possibility (wikis, web-mails, social applications, etc.) only XWiki is lagging... 3. XWIKI-2870 - Ability to select query language in Database List property. This is more for developers, and also very old issue. I think it is important, because if you did something modern (in this case - XWQL) - need to support this in all parts of platform... If you didn't do this - your great work for modern features - looks like as garbage - I cannot use XWQL in Database List property - as a result - I am not using XWQL at all, because I don't want to write queries 2 times. If is it possible, can you analyze possibility to include these issues in your nearly plans? PS. Maybe another users know some more important unresolved issues? I think, user opinions will be interesting for developers! Thanks beforehand! Eugen Colesnicov -- View this message in context: http://xwiki.475771.n2.nabble.com/4Developers-more-important-issues-regarding-to-XE-3-3-Roadmap-tp6911884p6911884.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 ___ 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 -- Thomas Mortagne ___ 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] [Announcement] XWiki Enterprise 3.2 Release Candidate 1 Released
Hi! Workspace manager alternative way of using virtual wikis. Does it mean, that If I need both XEM and Workspace Manager I can use both of them almost independently? And Wiki Farms are invisible for Workspace manager? Is it safe to use both of them simultaneously? As far as I understood, it's not possible to use Workspace Manager on a Wiki farm? Is it true? Best regards, Dmitry Bakbardin 06 октября 2011, 03:12 от Sergiu Dumitriu ser...@xwiki.com: The XWiki development team is proud to announce the availability of XWiki Enterprise 3.2 Release Candidate 1. This is the first (and hopefully last) release candidate for the 3.2 series. Apart from a few minor bugfixes, this version brings the Workspace Manager as a standard feature of the platform, as an alternative way of using virtual wikis, compared to XEM. See http://www.xwiki.org/xwiki/bin/ReleaseNotes/ReleaseNotesXWikiEnterprise32RC1 for more details. -- 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] Access rights management bug?
Thanks a lot for explanation, So, as far as I understood, scenario is: - Space of the document has only view right for Group1. Our user is a member of Group1. - This user tries to edit the document in edit/inline mode by pressing the link/button generated somwhere else, not in required page. - Required page checks if our user belongs to Group1 and if true - opens document as a user with real edit rights - User in Group1 edits properties in inline mode. On pressing submit button script saves page as our edit-mode-user. - Finally Group1 user again has no edit rights and no edit menu options. In this case some behaviour is still unclear: - Logic says to me that access rights are checked before script will run. If yes, no way to run edit mode in our case. - If user presses button Save view instead of form Submit button, what happens? Again, there is no way to script to save page with $doc.saveAsAuthor() function. Am I missing something? The second scenario loks more clear for me if scripts do ALL the job: - Required page Checks rights - Asks user via form if he wants to edit page - Sends user to ANOTHER page - This another page obtains all necessary data from the object properties of required page. - builds form and gives pseudo-inline mode to our user. - saves document on submit on behalf of user with edit rights. - redirects back to saved required page (by the way, redirect doesn't eat cyrillic names, and for now I don't know how to get it round) And in this case ALL pages for User from Group1 would be accessible only in XWiki's native view mode. This scenario gives a guarantee and deep feeling of safe wiki for admin , but also gives a lot of additional programming. And as far as I got - this is the only way to build ''smart -user-resistant' application. :-) But still, I'd prefer to manage all these rights via default XWiki application. Kind regards, Dmitry Bakbardin 23 сентября 2011, 11:30 от Caleb James DeLisle calebdeli...@lavabit.com: Another way that you can get the results you are looking for is to write a script which does the editing on the user's behalf. If the script document is saved by someone who has permission to edit the document which the user wants to edit and the user needs to be able to, for example: edit only the content of an object but not add or remove objects or change the document's main content. The script can check that the user is permitted and provide the appropriate form then do the operation on the user's behalf. The script can use the $doc.saveAsAuthor() function to do that. Caleb On 09/21/2011 07:31 PM, Sergiu Dumitriu wrote: On 09/21/2011 10:09 AM, Haru Mamburu wrote: Hi! So, this feature makes absolutely useless delete rights, for example, if each and every user with edit rights can easily skip Delete and Admin Prohibition. Actually edit right behaves like admin in the allowed space. As for me it looks a little bit wierd. Well, delete rights are not that relevant actually. By default only the document's creator can delete a document. So, unless you explicitly give delete rights to somebody, they'll only be able to delete their own documents. All users by default are simple, but as you mentioned, nothing stops the intruder with edit rights if he knows magic of URLs. For me it looks logical, that if I PROHIBITED right to delete or Admin rights - it means prohibited, but not don't pay attention'. The delete and admin rights don't normally work on page level anyway, it's pretty hard to get hold of them if they're not explicitly granted. If you want finer grained security, you can implement them in Java, not as normal access rights, but as guard checks blocking actions according to your own custom rules. For security it means VERY big black whole. And actually we don't have any instrument to track or stop it (besides watching pages). For semi-open projects, or even open, like Wikipedia it creates paradise for vandals, even if you open edit rights only for registered users. Once you can find couple of hundreds pages in Recycle bin even if nobody but Admin has ability to delete pages. :-) And actually rights management contradicts wit 6 user types concept http://dev.xwiki.org/xwiki/bin/view/Design/6TypesOfXWikiUsers So, my proposal is: discuss and implement more precise rights management system in the neares future. Let's make XWiki more safe :-) Yep, this was actually on the roadmap for 3.1, but it got postponed. Rights management is a very serious issue that needs to be tackled, but it's quite big so it will have to be approached in smaller steps. Thnks a lot for help, Dmitry 21 сентября 2011, 17:39 от Guillaume Lerougeguilla...@xwiki.com: Hi Dmitry, unfortunately for your use case this is a feature of XWiki. When a user is granted edit right on a page, he is allowed to edit any object attached
Re: [xwiki-users] Access rights management bug?
Thanks a lot for explanation, So, as far as I understood, scenario is: - Space of the document has only view right for Group1. Our user is a member of Group1. - This user tries to edit the document in edit/inline mode by pressing the link/button generated somwhere else, not in required page. - Required page checks if our user belongs to Group1 and if true - opens document as a user with real edit rights - User in Group1 edits properties in inline mode. On pressing submit button script saves page as our edit-mode-user. - Finally Group1 user again has no edit rights and no edit menu options. In this case some behaviour is still unclear: - Logic says to me that access rights are checked before script will run. If yes, no way to run edit mode in our case. - If user presses button Save view instead of form Submit button, what happens? Again, there is no way to script to save page with $doc.saveAsAuthor() function. Am I missing something? The second scenario loks more clear for me if scripts do ALL the job: - Required page Checks rights - Asks user via form if he wants to edit page - Sends user to ANOTHER page - This another page obtains all necessary data from the object properties of required page. - builds form and gives pseudo-inline mode to our user. - saves document on submit on behalf of user with edit rights. - redirects back to saved required page (by the way, redirect doesn't eat cyrillic names, and for now I don't know how to get it round) And in this case ALL pages for User from Group1 would be accessible only in XWiki's native view mode. This scenario gives a guarantee and deep feeling of safe wiki for admin , but also gives a lot of additional programming. And as far as I got - this is the only way to build ''smart -user-resistant' application. :-) But still, I'd prefer to manage all these rights via default XWiki application. Kind regards, Dmitry Bakbardin 23 сентября 2011, 11:30 от Caleb James DeLisle calebdeli...@lavabit.com: Another way that you can get the results you are looking for is to write a script which does the editing on the user's behalf. If the script document is saved by someone who has permission to edit the document which the user wants to edit and the user needs to be able to, for example: edit only the content of an object but not add or remove objects or change the document's main content. The script can check that the user is permitted and provide the appropriate form then do the operation on the user's behalf. The script can use the $doc.saveAsAuthor() function to do that. Caleb On 09/21/2011 07:31 PM, Sergiu Dumitriu wrote: On 09/21/2011 10:09 AM, Haru Mamburu wrote: Hi! So, this feature makes absolutely useless delete rights, for example, if each and every user with edit rights can easily skip Delete and Admin Prohibition. Actually edit right behaves like admin in the allowed space. As for me it looks a little bit wierd. Well, delete rights are not that relevant actually. By default only the document's creator can delete a document. So, unless you explicitly give delete rights to somebody, they'll only be able to delete their own documents. All users by default are simple, but as you mentioned, nothing stops the intruder with edit rights if he knows magic of URLs. For me it looks logical, that if I PROHIBITED right to delete or Admin rights - it means prohibited, but not don't pay attention'. The delete and admin rights don't normally work on page level anyway, it's pretty hard to get hold of them if they're not explicitly granted. If you want finer grained security, you can implement them in Java, not as normal access rights, but as guard checks blocking actions according to your own custom rules. For security it means VERY big black whole. And actually we don't have any instrument to track or stop it (besides watching pages). For semi-open projects, or even open, like Wikipedia it creates paradise for vandals, even if you open edit rights only for registered users. Once you can find couple of hundreds pages in Recycle bin even if nobody but Admin has ability to delete pages. :-) And actually rights management contradicts wit 6 user types concept http://dev.xwiki.org/xwiki/bin/view/Design/6TypesOfXWikiUsers So, my proposal is: discuss and implement more precise rights management system in the neares future. Let's make XWiki more safe :-) Yep, this was actually on the roadmap for 3.1, but it got postponed. Rights management is a very serious issue that needs to be tackled, but it's quite big so it will have to be approached in smaller steps. Thnks a lot for help, Dmitry 21 сентября 2011, 17:39 от Guillaume Lerougeguilla...@xwiki.com: Hi Dmitry, unfortunately for your use case this is a feature of XWiki. When a user is granted edit right on a page, he is allowed to edit any object attached
[xwiki-users] How to delete Deleted Attachments while FS is on?
Hi! XEM 3.1. I turned on filesystem storage, attached file, then deleted it. Due to http://jira.xwiki.org/browse/XWIKI-6918 and no acces via WebDAV yet (http://jira.xwiki.org/browse/XWIKI-6989) - there is no way to review deleted attachments in recycle bin and delete it. As far as I understand - manual delition via filesystem operations is wrong way to do this because of lost metadata. Is there any way to delete deleted attachments correctly until XWIKI-6918 would be fixed and XE would upgraded to fixed one? Kind regards Dmitry Bakbardin ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Access rights management bug?
Hi! So, this feature makes absolutely useless delete rights, for example, if each and every user with edit rights can easily skip Delete and Admin Prohibition. Actually edit right behaves like admin in the allowed space. As for me it looks a little bit wierd. All users by default are simple, but as you mentioned, nothing stops the intruder with edit rights if he knows magic of URLs. For me it looks logical, that if I PROHIBITED right to delete or Admin rights - it means prohibited, but not don't pay attention'. For security it means VERY big black whole. And actually we don't have any instrument to track or stop it (besides watching pages). For semi-open projects, or even open, like Wikipedia it creates paradise for vandals, even if you open edit rights only for registered users. Once you can find couple of hundreds pages in Recycle bin even if nobody but Admin has ability to delete pages. :-) And actually rights management contradicts wit 6 user types concept http://dev.xwiki.org/xwiki/bin/view/Design/6TypesOfXWikiUsers So, my proposal is: discuss and implement more precise rights management system in the neares future. Let's make XWiki more safe :-) Thnks a lot for help, Dmitry 21 сентября 2011, 17:39 от Guillaume Lerouge guilla...@xwiki.com: Hi Dmitry, unfortunately for your use case this is a feature of XWiki. When a user is granted edit right on a page, he is allowed to edit any object attached to that page (this is used through the edit inline mode as well, when editing in inline mode the user is actually updating the values of object properties in the page. One way to work around this is by making all users simple users by default so that the menus do not display the advanced edit options. However, users that know the right URLs will still be able to access the object edition mode. In short: sorry but no, not safe the way you mean it :-( Guillaume On Sat, Sep 17, 2011 at 6:57 AM, Haru Mamburu haru_mamb...@mail.ru wrote: Dear Users, XE 3.1. Playing with rights I found very unpleasant and IMO dangerous behaviour. Two Default groups: XWikiAllGroup and XWikiAdminGroup Admin gives rigths to XWikiAllGroup to view pages - no problem. Admin gives rigths to XWikiAllGroup to EDIT pages. From my point of view - EDIT means only page EDIT in edit/inline mode, but not: - managing page access rights - editing in editor object mode. I even tried to prohibit to XWikiAllGroup users Administration rights, nothing changed. As for my project - it is a disaster. I must separate four categories of users: 1. All users - have View access to definite spaces. 2. SOME registered users - have edit rights for spaces/pages (edit/inline), create rights. BUT NO Access rights management, NO object mode editing) 3. Admin Users with Admin rights on several spaces to delete/undelete pages AND access rights management. 4. XWiki Admin As I discovered, I can't get split second and third group. :-( It would be wise to avoid rights management and object editing mode availability to smart users, that can bring a mess into the system in couple of seconds. For example, smart user with edit rights will easily prohibit access to pages to whole XWikiAllGroup OR he even can grant VIEW rights ONLY to XWikiAdminGroup with the same results - page becomes inaccessible to non-admin users. I checked everything with a Test user in XWikiAllGroup. I don't know if it is a bug or a feature, but for me it's a disaster :-( Is there any way to make XWiki project safe? Best Regards Dmitry Bakbardin ___ 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] WebDav
Hi! I used to play with WebDav and Total Commander's plugin http://ghisler.fileburst.com/fsplugins/webdav.zip Enter URL like this: url/xwiki or url:port/xwiki Then it connects fine. Also, try to play with UTF-8 options to read pages correctly (if you have problems) The only problem I found: there is no Deleted attachments in WebDav access. Am I missing something? Dmitry Bakbardin 20 сентября 2011, 16:19 от Gerritjan Koekkoek gerritjankoekk...@gmail.com: I do understand it is a feature always on? I did a little test with mac os x lion, finder, go to server I entered http://[url] without www. But how do I Identify myself and what rights are exposed, I assume the same rights the user has on the Wiki? Or should I use another webDAv client? Op 20 sep. 2011, om 13:02 heeft Vincent Massol het volgende geschreven: On Sep 20, 2011, at 12:51 PM, Gerritjan Koekkoek wrote: On the xwiki.org there is a feature on XWiki presented; The WebDAV feature exposes wiki content (attachments, page content) through the well-known WebDAV protocol. This allows using WebDAV clients like DAVExplorer, file browsers like the Windows Explorer (XP), the Finder (MAC) or Nautilus (Linux) to directly browse and edit wiki content just as you would do for files in your local file system. Does this feature require configuration of the server. No Do I understand that by dropping photo's in a folder I could add photo's the the XWiki photoalbum Yes although the XWiki stores all the attachments in a mySql database? XWiki stores attachment where you've defined it. By default it's in the database (any DB supported by Hibernate, doesn't have to be MySQL). See http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Attachments Thanks -Vincent We have a server on version 2.7.1 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
[xwiki-users] XWiki vs. cyrillics
Dear developers, Recently I had been checking each and every step in XWiki cyrillic management. Brief results from last to least: 1. Office integration: no way to work with cyrillic page names http://jira.xwiki.org/browse/XOFFICE-252 2. Eclipse:: no way to work with cyrillic space names http://jira.xwiki.org/browse/XECLIPSE-154 3. $response.sendRedirect() gives ??? instead of cyrillic letters, so some scripts become useless, Parent Page search suggest in edit mode gives ??? instead of cyrillic http://jira.xwiki.org/browse/XWIKI-6955 The rest works fine, or I didn't discover it yet :- As far as I understand XWiki, all these bug should live somewhere in the core, maybe somewhere else also and it's not so trivial to fix it. The question is: what are priorities in XWiki development and is it planned to make cyrillic users happy to use all XWiki features available in nearest future? Thanks a lot for understanding. Kind regards. Dmitry Bakbardin ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
[xwiki-users] Access rights management bug?
Dear Users, XE 3.1. Playing with rights I found very unpleasant and IMO dangerous behaviour. Two Default groups: XWikiAllGroup and XWikiAdminGroup Admin gives rigths to XWikiAllGroup to view pages - no problem. Admin gives rigths to XWikiAllGroup to EDIT pages. From my point of view - EDIT means only page EDIT in edit/inline mode, but not: - managing page access rights - editing in editor object mode. I even tried to prohibit to XWikiAllGroup users Administration rights, nothing changed. As for my project - it is a disaster. I must separate four categories of users: 1. All users - have View access to definite spaces. 2. SOME registered users - have edit rights for spaces/pages (edit/inline), create rights. BUT NO Access rights management, NO object mode editing) 3. Admin Users with Admin rights on several spaces to delete/undelete pages AND access rights management. 4. XWiki Admin As I discovered, I can't get split second and third group. :-( It would be wise to avoid rights management and object editing mode availability to smart users, that can bring a mess into the system in couple of seconds. For example, smart user with edit rights will easily prohibit access to pages to whole XWikiAllGroup OR he even can grant VIEW rights ONLY to XWikiAdminGroup with the same results - page becomes inaccessible to non-admin users. I checked everything with a Test user in XWikiAllGroup. I don't know if it is a bug or a feature, but for me it's a disaster :-( Is there any way to make XWiki project safe? Best Regards Dmitry Bakbardin ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Cyryllic bug in scripting
Thanks a lot for help. I'm not using xwiki.org for tests (but now I do understand why cyrillic letters disappear on xwiki.org :-) All test were done on standalone XWiki 3.1 on Windows. A don't have a clue how to check encodings in there: Admin.Tools configuration check failed to run, but cyrillic space names and page names works fine, despite of the facts described below. All test were done once more on Glassfish+MySQL+XWiki 3.1 with exactly the same results. Cyrillic space names and page names works fine, despite of the facts described below also. XWiki: Admin.Tools configuration check says following: General db settings MYSQL encoding setting character_set_client: utf8mb4 MYSQL encoding setting character_set_connection: utf8mb4 MYSQL encoding setting character_set_database: utf8 MYSQL encoding setting character_set_filesystem: binary MYSQL encoding setting character_set_results: MYSQL encoding setting character_set_server: utf8 MYSQL encoding setting character_set_system: utf8 General db collation settings MYSQL collation setting collation_connection: utf8mb4_general_ci MYSQL collation setting collation_database: utf8_general_ci MYSQL collation setting collation_server: utf8_general_ci MySQL connector is set inside XWiki (not present in Glassfish) Glassfish URI Encoding is set to UTF-8 That's everything I understand, what you advised me to check. Best Regards, Dmitry Bakbardin 12 сентября 2011, 10:32 от Vincent Massol vinc...@massol.net: On Sep 12, 2011, at 5:05 AM, Haru Mamburu wrote: Dear Users, I found bug with cyrillic letters in velocity Scripting. Does it happen only with cyrillic? http://jira.xwiki.org/browse/XWIKI-6955 Something similar was found in this extention http://extensions.xwiki.org/xwiki/bin/view/Extension/Extract+Wikipedia+Article+Introduction I wrote a comment to the page. Should I report it as a bug, or its not supported by XWiki development team? It's simply that xwiki.org's DB is currently configured in iso 8859-1 instead of UTF8 AFAIK. Are you sure **all** your subsystems are correctly configured in UTF8: - your servlet container - your database - your xwiki instance ? Cyrillic users would be unhappy if scripting has such other languages limitations. :-( Is it possible to fix this somehow? Yes see above. Thanks -Vincent As to: http://jira.xwiki.org/browse/XWIKI-6955 Same Script again. The question is: If you enter Smith John in the input field, script creates page SmithJohn. Is it possible somehow to keep the space mark between Last name and first name in the page name after script? Thanks in advance Dmitry Bakbardin ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
[xwiki-users] Cyryllic bug in scripting
Dear Users, I found bug with cyrillic letters in velocity Scripting. Does it happen only with cyrillic? http://jira.xwiki.org/browse/XWIKI-6955 Something similar was found in this extention http://extensions.xwiki.org/xwiki/bin/view/Extension/Extract+Wikipedia+Article+Introduction I wrote a comment to the page. Should I report it as a bug, or its not supported by XWiki development team? Cyrillic users would be unhappy if scripting has such other languages limitations. :-( Is it possible to fix this somehow? As to: http://jira.xwiki.org/browse/XWIKI-6955 Same Script again. The question is: If you enter Smith John in the input field, script creates page SmithJohn. Is it possible somehow to keep the space mark between Last name and first name in the page name after script? Thanks in advance Dmitry Bakbardin ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Filesystem Storage backup, clustering, mirroring
Thanks a lot for for assistance, Ludovic. Looks complicated, but at first glance at least manageable. Will you recommend any Java-based sync tools to build completely platform independent system? Ideal solution for me looks smth like: - Master Wiki accepts file and stores it in FS storage - Master Wiki initiates an event and sends it to Sync Tool / Mirror Wiki - Sync Tool / Mirror Wiki requests file, gets it, stores it and writes success sync event in log. Do we need to tie XWiki events with sync events, or it is safe for XWiki, when mirror database has a new-file record and file is not in the storage yet? 1/ A redundant RAID5 network storage shared over Fiber Channel and NFS. This is for clustering Is it possible to configure XWiki to use ANY folder as a storage, OR default one is an only option? If Yes, HOW? Some bugs are found in 3.1 with FS on. It causes attachment management problems. http://jira.xwiki.org/browse/XWIKI-6918 http://jira.xwiki.org/browse/XWIKI-6917 Is there any fast solution? Or there is no simple solution and we should wait at least 3.2 release to manage attachments? Because for now, we don't have legal XWiki access to deleted attachments. Best Regards, Dmitry Bakbardin 09 сентября 2011, 12:51 от Ludovic Dubost ludo...@xwiki.com: Hi Haru, 2011/9/9 Haru Mamburu haru_mamb...@mail.ru Hi! I was going to build on the XEM base a library with files 1Kb-1Gb inside . But on digging deeper I'm a bit desperate now: XE is an excellent platform to run the project from one side, from other - completely unclear how to make it safe :-( Great that you working on a big database with XEM.. Sounds like a nice project File System storage does have it's drawback, which is why we initially chose to be all-database, but we faced the limitation of database storage for very large attachments.. Backup and Clustering are indeed more complex, but it's possible.. On filesystem storage implementation, there are several sufficient question are still beyond of understanding: 1. Clustering and/or mirroring XWiki. When data was stored completely in the Database Engine - it was more or less clear how to build following system: Customers - Master Server -- Mirror Server If Master Server is down - we easily switch customers to Mirror Server. Afterwards we restore full configuration and get back necessary redundancy. With filesystem storage mirroring mission becomes impossible? I suggest either 1/ A redundant RAID5 network storage shared over Fiber Channel and NFS. This is for clustering 2/ A rdist process that will replicate regularly the FS for mirroring only 2. Backup process. Database data backup is also more or less clear. When filesystem storage turned on, there is painful moment of synchronizing backup moment both for data in Database AND data in Filesystem. The only Idea I have for now: stop everything, backup everything, run everything. IMO it's not the best solution due to quite annoying downtime. Are you going to implement such a functionality inside? What is the best pactice to implement backup in a right way? I would suggest: 1/ rdist replication + mysql replication 2/ when backuping, blocking both replication and performing the backup At XWiki SAS we always use a MySQL replication which is the DB being backed-up. This is important to have the minimal impact on the production system. If you backup the production database directly you can have locking issues that block XWiki from operating properly. Ludovic If you already have a solution, kindly ask you to share the information. :-) Best regards, Dmitry Bakbardin ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
[xwiki-users] Filesystem Storage backup, clustering, mirroring
Hi! I was going to build on the XEM base a library with files 1Kb-1Gb inside . But on digging deeper I'm a bit desperate now: XE is an excellent platform to run the project from one side, from other - completely unclear how to make it safe :-( On filesystem storage implementation, there are several sufficient question are still beyond of understanding: 1. Clustering and/or mirroring XWiki. When data was stored completely in the Database Engine - it was more or less clear how to build following system: Customers - Master Server -- Mirror Server If Master Server is down - we easily switch customers to Mirror Server. Afterwards we restore full configuration and get back necessary redundancy. With filesystem storage mirroring mission becomes impossible? 2. Backup process. Database data backup is also more or less clear. When filesystem storage turned on, there is painful moment of synchronizing backup moment both for data in Database AND data in Filesystem. The only Idea I have for now: stop everything, backup everything, run everything. IMO it's not the best solution due to quite annoying downtime. Are you going to implement such a functionality inside? What is the best pactice to implement backup in a right way? If you already have a solution, kindly ask you to share the information. :-) Best regards, Dmitry Bakbardin ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
[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: filename.extension second is: filename~v1.1.extension 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] 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 ser...@xwiki.com:
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
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 ser...@xwiki.com: 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
[xwiki-users] Download resume for large files - no way?
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. 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? Thanks in advance, Dmitry Bakbardin ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
[xwiki-users] file operations in file system storage is too slow
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? Thanks a lot. Dmitry Bakbardin. ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] applications in wiki-farm fail to run
Thanks a lot for help, I just updated documentation on this issue. You're welcome to improve it. http://manager.xwiki.org/xwiki/bin/view/AdminGuide/Application+installation+into+wiki-farm If somebody would give me a clue to define this subject as bug, I'd jira it also :-) Best regards, Dmitry Bakbardin 02 сентября 2011, 12:15 от AngeloG elgh...@gmail.com: Haru Mamburu wrote: By accident I found the solution, but as for me it looks a bit wierd for everyday usage. 1. Import in main wiki Admin Tools http://extensions.xwiki.org/xwiki/bin/view/Extension/AdminTools with the User with programming rights. 2. Run the page Admin.CheckProgrammingRights 3. Confirm programming rights by pressing the link Confirm give programming rights 4. If everything successful, we can see following (note, that wiki is only with standard pack of pages): * fixing Main.Spaces * fixing Main.Activity * fixing AnnotationCode.Style * fixing AnnotationCode.Script * fixing AnnotationCode.Settings5. Checking Annotation application on wiki farms gives positive result - it works. I don't know is it a bug of XEM or a feature, but probably it worth to do smth with such a complicated process and/or update documentation if it should work this way. Is there any less wierd way to make applications running? Hope, somebody will give a solution :-) Thanks a lot Dmitry Bakbardin 01 сентября 2011, 20:00 от Haru Mamburu lt;haru_mamb...@mail.rugt;: Thanks a lot for help. Now step by step. 1. XE installation - Annotations works fine 2. XEM installation - Annotations works fine 3. templatexe deployment (xwiki/bin/view/XemManager/Install) - Annotations disappears in templatexe farm. 4. test wiki-farm deployment from templatexe template, installation of http://extensions.xwiki.org/xwiki/bin/view/Extension/Annotations+Application according to instuctions. Result the same - no annotations found in wiki-farm. :-( Is there any way to install smth. in main wiki and just allow application in a specific farm? Thanks in advance. Dmitry Bakbardin 01 сентября 2011, 12:15 от Vincent Massol lt;vinc...@massol.netgt;: Hi Dmitry, On Aug 31, 2011, at 6:19 PM, Haru Mamburu wrote: Hi! Xwiki 3.1. Latest XEM works fine, deploys wiki farms - no problem. All attempts to make applications running on wiki-farm failed (e.g. Annotations). Documentation keeping silence, or I'm missing something. :-( Is there any way to make applications running on non-main wikis? Is there a way to install application in main wiki and grant permission to be used in specific wiki-farm? All applications can be installed in all wikis. That should work fine. Annotations are installed by default so I'm not sure what you are installing… We need more details of the steps you're following and the issues you're seeing. Thanks -Vincent Thanks a lot in advance Dmitry Bakbardin ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users Hi, for what I know when you create a subwiki, may be using the default template, it is empty. So unless you have already your own template ready, the best thing is to log in in the subwiki and import the default xar containing the default pages (you need to import XE pages in the subwikis and not the XEM pages). After doing this it is possible that annotation still don't work in the subwiki. *** This is because the javascript and style (CSS) that enable the annotations need to be saved with programming rights (AnnotationCode.Style, AnnotationCode.Script, AnnotationCode.Settings). In order to do that, just login with a user with programming rights, go to those documents, edit and save with no changes. (thanks to Anca Luca for this solution). *** This worked for me, I hope it can help you Angelo -- View this message in context: http://xwiki.475771.n2.nabble.com/applications-in-wiki-farm-fail-to-run-tp6747170p6753116.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 ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] applications in wiki-farm fail to run
Thanks a lot for help. Now step by step. 1. XE installation - Annotations works fine 2. XEM installation - Annotations works fine 3. templatexe deployment (xwiki/bin/view/XemManager/Install) - Annotations disappears in templatexe farm. 4. test wiki-farm deployment from templatexe template, installation of http://extensions.xwiki.org/xwiki/bin/view/Extension/Annotations+Application according to instuctions. Result the same - no annotations found in wiki-farm. :-( Is there any way to install smth. in main wiki and just allow application in a specific farm? Thanks in advance. Dmitry Bakbardin 01 сентября 2011, 12:15 от Vincent Massol vinc...@massol.net: Hi Dmitry, On Aug 31, 2011, at 6:19 PM, Haru Mamburu wrote: Hi! Xwiki 3.1. Latest XEM works fine, deploys wiki farms - no problem. All attempts to make applications running on wiki-farm failed (e.g. Annotations). Documentation keeping silence, or I'm missing something. :-( Is there any way to make applications running on non-main wikis? Is there a way to install application in main wiki and grant permission to be used in specific wiki-farm? All applications can be installed in all wikis. That should work fine. Annotations are installed by default so I'm not sure what you are installing… We need more details of the steps you're following and the issues you're seeing. Thanks -Vincent Thanks a lot in advance Dmitry Bakbardin ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] applications in wiki-farm fail to run
By accident I found the solution, but as for me it looks a bit wierd for everyday usage. 1. Import in main wiki Admin Tools http://extensions.xwiki.org/xwiki/bin/view/Extension/AdminTools with the User with programming rights. 2. Run the page Admin.CheckProgrammingRights 3. Confirm programming rights by pressing the link Confirm give programming rights 4. If everything successful, we can see following (note, that wiki is only with standard pack of pages): * fixing Main.Spaces * fixing Main.Activity * fixing AnnotationCode.Style * fixing AnnotationCode.Script * fixing AnnotationCode.Settings5. Checking Annotation application on wiki farms gives positive result - it works. I don't know is it a bug of XEM or a feature, but probably it worth to do smth with such a complicated process and/or update documentation if it should work this way. Is there any less wierd way to make applications running? Hope, somebody will give a solution :-) Thanks a lot Dmitry Bakbardin 01 сентября 2011, 20:00 от Haru Mamburu haru_mamb...@mail.ru: Thanks a lot for help. Now step by step. 1. XE installation - Annotations works fine 2. XEM installation - Annotations works fine 3. templatexe deployment (xwiki/bin/view/XemManager/Install) - Annotations disappears in templatexe farm. 4. test wiki-farm deployment from templatexe template, installation of http://extensions.xwiki.org/xwiki/bin/view/Extension/Annotations+Application according to instuctions. Result the same - no annotations found in wiki-farm. :-( Is there any way to install smth. in main wiki and just allow application in a specific farm? Thanks in advance. Dmitry Bakbardin 01 сентября 2011, 12:15 от Vincent Massol vinc...@massol.net: Hi Dmitry, On Aug 31, 2011, at 6:19 PM, Haru Mamburu wrote: Hi! Xwiki 3.1. Latest XEM works fine, deploys wiki farms - no problem. All attempts to make applications running on wiki-farm failed (e.g. Annotations). Documentation keeping silence, or I'm missing something. :-( Is there any way to make applications running on non-main wikis? Is there a way to install application in main wiki and grant permission to be used in specific wiki-farm? All applications can be installed in all wikis. That should work fine. Annotations are installed by default so I'm not sure what you are installing… We need more details of the steps you're following and the issues you're seeing. Thanks -Vincent Thanks a lot in advance Dmitry Bakbardin ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
[xwiki-users] applications in wiki-farm fail to run
Hi! Xwiki 3.1. Latest XEM works fine, deploys wiki farms - no problem. All attempts to make applications running on wiki-farm failed (e.g. Annotations). Documentation keeping silence, or I'm missing something. :-( Is there any way to make applications running on non-main wikis? Is there a way to install application in main wiki and grant permission to be used in specific wiki-farm? Thanks a lot in advance Dmitry Bakbardin ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Attachments-RAM dependencies, anchors, TOC
Thank you, Marius, I will try now and leave feature request also :-)
Tue, 07 Dec 2010 12:07:36 +0200 письмо от Marius Dumitru Florea
mariusdumitru.flo...@xwiki.com:
On 12/07/2010 01:55 AM, Haru Mamburu wrote:
Hi!
Kindly ask you to solve some unclear topics:
I. How can I find information about such dependencies:
- How many server RAM memory is required for each 1GB of attachments?
- The same for CPU.
How to estimate this and calculate hardware? What are main principles?
II. Is it possible to customise WYSIWYG editor separetly for each space
in one sub-XWiki ?
You can edit the wysiwyg_storeConfig velocity macro found in
templates/macros.vm so that it takes the value of the WYSIWYG editor
configuration parameters from space preferences. For instance:
#set($ok = $parameters.put('menu',
$xwiki.getSpacePreference('wysiwyg.menu', 'link image table macro
import')))
See
http://nexus.xwiki.org/nexus/service/local/repositories/releases/archive/com/xpn/xwiki/platform/xwiki-core/2.6/xwiki-core-2.6-javadoc.jar/!/com/xpn/xwiki/api/XWiki.html#getSpacePreference%28java.lang.String,%20java.lang.String%29
Then you have to add the corresponding properties (i.e.
'wysiwyg.menu')
to SpaceName.WebPreferences page (where 'SpaceName' is the space where
you want the WYSIWYG editor to be customised).
You can do this for any WYSIWYG editor configuration parameter. For the
full list, see
http://platform.xwiki.org/xwiki/bin/view/AdminGuide/WysiwygEditor#HConfigurationParameters
.
III. Is there any way to manage anchors from Links plugin in WYSIWYG
editor?
The logic is:
- select space
- select page
- select anchor on this page
- put the link
This is not possible right now through the WYSIWYG editor UI. You can
open a feature request on jira.xwiki.org
Hope this helps,
Marius
For now, even if I write down XWiki.WebHome#anchor in the link field
manually, I get #anchor cut out.
And the only way to do it via source code editor manually. Then it works
fine. Personally me found more or less suitable solution with FF plugin
https://addons.mozilla.org/ru/firefox/addon/416/
It's very easy to get anchor, but not so easy to put it. For
unqualified users it makes XWiki one-handed.
IV. Is there any way to make TOC macro to build table of contents of
several pages and put it on one page?
For Example:
toc Page1, Page2, Page3
It's very useful, when one can group all project highligts together
in one TOC.
I used to use Track Wiki, it works excellent in there. I suffer from
it's absence now :-)
Thank you
Dmitry Bakbardin
___
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
[xwiki-users] Attachments-RAM dependencies, anchors, TOC
Hi! Kindly ask you to solve some unclear topics: I. How can I find information about such dependencies: - How many server RAM memory is required for each 1GB of attachments? - The same for CPU. How to estimate this and calculate hardware? What are main principles? II. Is it possible to customise WYSIWYG editor separetly for each space in one sub-XWiki ? III. Is there any way to manage anchors from Links plugin in WYSIWYG editor? The logic is: - select space - select page - select anchor on this page - put the link For now, even if I write down XWiki.WebHome#anchor in the link field manually, I get #anchor cut out. And the only way to do it via source code editor manually. Then it works fine. Personally me found more or less suitable solution with FF plugin https://addons.mozilla.org/ru/firefox/addon/416/ It's very easy to get anchor, but not so easy to put it. For unqualified users it makes XWiki one-handed. IV. Is there any way to make TOC macro to build table of contents of several pages and put it on one page? For Example: toc Page1, Page2, Page3 It's very useful, when one can group all project highligts together in one TOC. I used to use Track Wiki, it works excellent in there. I suffer from it's absence now :-) Thank you Dmitry Bakbardin ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Attachments-RAM dependencies, anchors, TOC
Thank you very much, in general - it's more than clear. Now I'm almost ready to master both science and art of XWiki setup :-) Mon, 06 Dec 2010 19:11:45 -0500 письмо от Caleb James DeLisle calebdeli...@lavabit.com: On 12/06/2010 06:55 PM, Haru Mamburu wrote: Hi! Kindly ask you to solve some unclear topics: I. How can I find information about such dependencies: - How many server RAM memory is required for each 1GB of attachments? It depends on how large the attachments are. Currently (as of version 2.6) attachments are stored on the disk and in the database rather than in RAM so the only limit on the total of all attachments is the amount of space which your database can hold. Remember that the default database HSQL holds all tables in RAM. If you're asking about a single very large attachment. There is some inefficient code in the attachment version storage which means that you can only store attachments up to about 60MB with 512MB of heap space (RAM). This can be bypassed by setting the attachment version store type to void and the limit will rise over 100MB where the problem will become the transfer to and from the database. - The same for CPU. The CPU usage for attachments is not really a factor as compared to the number of users, page loads per second, number of pages, complexity of queries etc. How to estimate this and calculate hardware? What are main principles? It is an art as much as it is a science ;) Others know much more than me about the rest of your questions so I will leave this to them. Caleb II. Is it possible to customise WYSIWYG editor separetly for each space in one sub-XWiki ? III. Is there any way to manage anchors from Links plugin in WYSIWYG editor? The logic is: - select space - select page - select anchor on this page - put the link For now, even if I write down XWiki.WebHome#anchor in the link field manually, I get #anchor cut out. And the only way to do it via source code editor manually. Then it works fine. Personally me found more or less suitable solution with FF plugin https://addons.mozilla.org/ru/firefox/addon/416/ It's very easy to get anchor, but not so easy to put it. For unqualified users it makes XWiki one-handed. IV. Is there any way to make TOC macro to build table of contents of several pages and put it on one page? For Example: toc Page1, Page2, Page3 It's very useful, when one can group all project highligts together in one TOC. I used to use Track Wiki, it works excellent in there. I suffer from it's absence now :-) Thank you Dmitry Bakbardin ___ 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
