- xwiki-devs@xwiki.org - lists.xwiki.org

[xwiki-devs] Email application
by Sales, G. (Grant) 31 Aug '10

31 Aug '10

My send page by email panel isn't functional. I get a error telling me that there might be an error in the email address I've entered. This panel was installed correctly with a user that has programming rights. Any thoughts on the settings that I need to play with? Or is my version of xwiki not capable of doing this? I've been reading some of these emails and it looks like maybe in a new version of xwiki this panel will come standard, is this true? If so I can I update to the current version and also be able to delete properties in a class? Thanks for your help ~Grant Grant Sales Security Operations Analyst ING 111 Washington Ave South Minneapolis, MN 55401 Tel: 612.342.7889 Fax: 612.342.3428 Cell: 320.761.0966 Email: grant.sales(a)us.ing.com www.ing-usa.com ING. Your future. Made easier. (r) --------------------------------------------------------- NOTICE: The information contained in this electronic mail message is confidential and intended only for certain recipients. If you are not an intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication and any attachments is strictly prohibited. If you have received this communication in error, please notify the sender by reply transmission and delete the message without copying or disclosing it. ============================================================================================

1 2

[xwiki-devs] Wysiwyg editor and macro accessing to Alfresco (or other external tool)
by jurevert 30 Aug '10

30 Aug '10

Hi, Our goal is to develop a wysisyg macro allowing to : - Insert an Image stored on Alfresco - Insert a link to a document stored on Alfresco To do this; we have develop a small browser on Alfresco in order to choose the image to insert (img src) or the file to link (a href). After selecting the Alfresco file; we need to generate a macro like : [[Lien vers le doc toto>>http://alfresco.airfrance.fr/alfresco/.../toto.doc||rel="__blank" title="Ouvrir le doc toto..."]] or [[image:http://alfresco.airfrance.fr/alfresco/..../image.jpg]] Using the wiki editor and the old Wysiwyg editor; we had no problem to do this. (Openning popup and populate les link field with alfresco file path.) With the new editor; I can't find the way to do this. In fact my problem could be resume to add a picto in the 'link' and 'image' macro GUI allowing to open my alfresco browser in order to populate the path ! Any idea to do this ? Thanks, Julien -- View this message in context: http://xwiki.475771.n2.nabble.com/Wysiwyg-editor-and-macro-accessing-to-Alf… Sent from the XWiki- Dev mailing list archive at Nabble.com.

2 4

[xwiki-devs] [Proposal][UX] Recent Changes Improvements
by Ecaterina Valica 30 Aug '10

30 Aug '10

Hi, This is a page centric proposal for "Recent Changes": * Partial Prototype (Firefox) http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ActivityStreamP3D * Some screenhots http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ActivityStreamV3 Any feedback is greatly appreciated. Thanks, Caty P.S: Older user centric proposal was http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ActivityStreamV2

2 3

[xwiki-devs] [proposal] Move servlet filters out of the core
by Alex Busenius 30 Aug '10

30 Aug '10

Hi devs, I propose to move servlet filters out of the old core to xwiki-container-servlet. There are 3 filters, com.xpn.xwiki.web.SetCharacterEncodingFilter com.xpn.xwiki.web.SavedRequestRestorerFilter com.xpn.xwiki.web.ActionFilter They are almost self-contained (except for ActionFilter, see a note later) and are easy to move. Moreover, SavedRequestRestorerFilter offers functionality to save the request, that might also be useful in other places (like csrf-token). There is (currently) no need for portlet filters, so moving filters into a separate module doesn't seem to be worth it. Since the filters are not used directly, I'd move them into org.xwiki.container.servlet.filters.internal and public methods used elsewhere into org.xwiki.container.servlet.filters. Note that xwiki-core would become dependent on xwiki-container-servlet (it currently depends on container-api), but it shouldn't be a problem. In more detail, * SetCharacterEncodingFilter would be moved as is to filters.internal. * SavedRequestRestorerFilter would be split into the actual filter and SavedRequestManager that would contain the static methods String getOriginalUrl(HttpServletRequest) String saveRequest(HttpServletRequest) String getRequestIdentifier() SavedRequestManager could also be a component, but it would make it more complicated to use from the filter. * ActionFilter should be moved to filters.internal too, but it uses XWiki.stripSegmentFromPath(String, String) to parse the URL and replace the action part by the stored value. There are 2 other copies of the URL parsing code that uses stripSegmentFromPath(...), in XWiki.getDocumentReference(...) and XWiki.getXWiki(...), I can think of 3 alternatives: 1. Leave ActionFilter in the core 2. Move URL parsing code into xwiki-url, i.e. add/implement missing methods to create XWikiURL from string representation and extract host, action, document reference and parameters from it. 3. Move stripSegmentFromPath(...) to xwiki-container-servlet too I'm +1 for 2, since it's the cleanest option. WDYT? Thanks, Alex

5 7

[xwiki-devs] [Proposal] Stop logging errors when a wiki macro cannot be registered due to insufficient privileges for the asked visibility
by Jerome Velociter 30 Aug '10

30 Aug '10

Hi friends, I'm proposing a patch (see http://jira.xwiki.org/jira/browse/XWIKI-5439) to stop logging a full exception at error level when the wiki fails to register a wiki macro due to insufficient privileges for the asked visibility. This is currently what happens, and it can trash your log, for example if you initialize a farm with hundreds of wikis throwing couple of times such error :) Thing is this is not a real error, in the sense "something went wrong" so it should be logged at the debug level. The patch introduce a new exception : org.xwiki.rendering.macro.wikibridge.InsufficientPrivilegesException, which when caught by the wiki macro initializer is logged at debug level, by opposition of the more generic org.xwiki.rendering.macro.wikibridge.WikiMacroException that remains logged at error level. I'm calling for a vote since the patch introduce a API signature change. Though I tend to think it's internal enough not to go through deprecation cycle. My +1 Jerome.

6 6

[xwiki-devs] [proposal] Deprecate XWikiHibernateStore internal methods.
by Caleb James DeLisle 27 Aug '10

27 Aug '10

There are a number of public methods in XWikiHibernateStore which are either nolonger used, unused outside of XWikiHibernateStore, or used in only a few places in old code. To make maintainence easier I propose deprecating them to discourage outside code from using them so they can later be removed or made private. Here is a list: saveXWikiObject used 1 place in c.x.x.XWiki#addUserToGroup which appears to be easily fixed. saveXWikiCollection used 3 places in the stats plugin. loadXWikiObject used 1 place in the old query plugin. loadXWikiCollection used 3 places in the stats plugin. deleteXWikiCollection used 1 place in stats plugin. deleteXWikiCollection used 1 place in stats plugin. deleteXWikiClass used nowhere. loadXWikiProperty used nowhere (outside of XWikiHibernateStore). saveXWikiClass used nowhere (outside of XWikiHibernateStore). loadXWikiClass used nowhere (outside of XWikiHibernateStore). saveXWikiClassProperty used nowhere. loadAttachmentList used nowhere (outside of XWikiHibernateStore). saveAttachmentList used nowhere (outside of XWikiHibernateStore). saveAttachment used nowhere (outside of XWikiHibernateStore). injectCustomMappingsInSessionFactory used nowhere (outside of XWikiHibernateStore). injectInSessionFactory used nowhere (outside of XWikiHibernateStore). isValidCustomMapping used nowhere (outside of XWikiHibernateStore). getBatcherStats used nowhere. resetBatcherStats used nowhere. WDYT? Caleb

3 3

[xwiki-devs] [proposal] Cancelable events and refactoring script macros
by Alex Busenius 26 Aug '10

26 Aug '10

Hello, I'd like to refactor AbstractScriptMacro in order to be able to change script behavior in the future without fanout violations. Here is the plan emerged after several discussions with ThomasM: Introduce a notion of cancelable events. Such events can be canceled by the receiver (providing an optional reason), the actual canceling is performed by the sender. http://dev.xwiki.org/xwiki/bin/view/Design/CancelableEvents Send a cancelable event ScriptEvaluationStartsEvent in AbstractScriptMacro just before evaluating the script and a ScriptEvaluationFinishedEvent right after evaluation has finished (in finally block). Add the following 3 listeners to those events (into rendering.internal.macro.script) and move the corresponding code from AbstractScriptMacro there: ScriptClassLoaderHandlerListener * does class loader manipulations currently performed by AbstractScriptMacro#getClassLoader & Co PermissionCheckerListener * Aborts execution of scripts that need PR if the document is not saved with PR * To distinguish velocity and PR scripts, introduce a new interface PrivilegedScriptMacro extends ScriptMacro and let AbstractJSR223ScriptMacro implement it NestedScriptMacroValidatorListener * Replaces NestedScriptMacroValidator (ScriptMacroValidator component is removed completely) The refactoring will remove the following methods (breaks API): AbstractJSR223ScriptMacro: * protected boolean canExecuteScript() * public List execute(JSR223ScriptMacroParameters, String, MacroTransformationContext) AbstractScriptMacro: * protected boolean canHaveJarsParameters() * protected ClassLoader getClassLoader(String, ClassLoader) WDYT? Alex

6 6

[xwiki-devs] [proposal] Remove flickr plugin from CORE
by Sorin Burjan 25 Aug '10

25 Aug '10

Hello. It seems that platform/trunks/core/xwiki-core/src/main/java/com/xpn/xwiki/plugin/flickr plugin is not used by anything in XWiki. It seems to be old and deprecated. I propose to remove it from xwiki-core. The things to discuss would be : Topic I. Where to move it: 1.Deprecate it (move it to contrib retired) 2.Remove it from everywhere (delete code) 3.Move it to CORE plugins 4.Rewrite it nicely as a service and have it : 1.as core module 2.in contrib sandbox Topic II. Relation to the platform 1.bundle it by default 2.not bundle it by default I am +1 for I.2 and II.2 . WDYT? Thanks, Sorin

6 6

Re: [xwiki-devs] IMPORTANT: WYSIWYG editor language in user interface
by Marius Dumitru Florea 25 Aug '10

25 Aug '10

Hi Ramon, First of all sorry for the late reply, I've been in holidays for the past two weeks. On 08/18/2010 09:05 PM, Ramon Gomes Brandão - SERINT wrote: > Hi Marius, > > I’m a long-time enthusiast of XWiki and I think it’s the best wiki tool I'm happy to hear that! > ever. However, I feel some lack of updated documentation on how to > build it. I’m implementing a large instance of XWiki Enterprise 2.4 in > my work here in Brazil, and I’m facing an issue: detailed instructions > on how to build the new WYSIWYG editor. I’ve translated the > Strings.properties file in Portuguese, and I’m trying to use Eclipse > with m2eclipse to build it, but I definitively don’t know how to > proceed. I saw your messages on xwiki-users archives about this build. > Could you help me sending detailed steps on how to do this? Here are my > questions: > > 1) I’ve installed Eclipse+m2eclipse+subclipse and checked out the > platform/web/trunk folder. It contains the following sub-folders (modules): > > -gwt > > -standard > > -xwiki-gwt-dom > > -xwiki-gwt-user > > -xwiki-gwt-wysiwyg-client > > -xwiki-gwt-wysiwyg-server > > Do I need all the modules to proceed? The WYSIWYG editor code is split between xwiki-gwt-wysiwyg-client and xwiki-gwt-wysiwyg-server. The server side depends on the XWiki core, while the client side depends on xwiki-gwt-user and xwiki-gwt-dom. You can ignore the other two modules (gwt and standard). You can ignore xwiki-gwt-dom too if you don't plan to change/enhance the DOM API. > Where should I place > Strings_pt.properties ? Do I need to modify “extended-property …” both > on xwiki-gwt-user and > xwiki-gwt-wysiwyg-client/resources/…/Wysiwyg.gwt.xml or only in this > last one? There are three translation files as indicated on http://l10n.xwiki.org/xwiki/bin/view/Wysiwyg/ . One is included in xwiki-gwt-user and the other two are in xwiki-gwt-wysiwyg-client: http://svn.xwiki.org/svnroot/xwiki/platform/web/trunk/xwiki-gwt-user/src/ma… http://svn.xwiki.org/svnroot/xwiki/platform/web/trunk/xwiki-gwt-wysiwyg-cli… http://svn.xwiki.org/svnroot/xwiki/platform/web/trunk/xwiki-gwt-wysiwyg-cli… Best is to translate all these files. You should place the translated file (e.g. Strings_pt.properties) in the same directory as the corresponding source file (e.g. Strings.properties). Then you have to modify both: http://svn.xwiki.org/svnroot/xwiki/platform/web/trunk/xwiki-gwt-user/src/ma… and http://svn.xwiki.org/svnroot/xwiki/platform/web/trunk/xwiki-gwt-wysiwyg-cli… in order to update the locale property: <extend-property name="locale" values="...,pt"/> > > 2) Which modules do I need to build (with right click - > Run as -> > Maven build or Maven install)? In which order? I don't build from eclipse although I have m2eclpse installed. I prefer the console. The right build order is: xwiki-gwt-user > xwiki-gwt-wysiwyg-client > xwiki-gwt-wysiwyg-server xwiki-gwt-user and xwiki-gwt-wysiwyg-client generate jars that are used by xwiki-gwt-wysiwyg-server which generates a war. Note that building xwiki-gwt-wysiwyg-server takes a long time because GWT compilation is costly. > > 3) Does this build generates a war automatically? Where does it > generates the war (where I can find it)? The war generated by xwiki-gwt-wysiwyg-server is placed in the target directory (e.g. target/xwiki-web-gwt-wysiwyg-server-2.5-SNAPSHOT.war). I know this happens when you build from command line. Might be different when you build from eclipse, but you should be able to find the war anyway. In the worst case, if you run "mvn install" the war will be installed in your local repository: ~/.m2/repository/com/xpn/xwiki/platform/xwiki-web-gwt-wysiwyg-server/2.5-SNAPSHOT/xwiki-web-gwt-wysiwyg-server-2.5-SNAPSHOT.war > > 4) How to load the new build into my running XWiki Enterprise 2.4 > instance? You have to replace (don't merge!) webapps/xwiki/resources/js/xwiki/wysiwyg/xwe directory from your XWiki installation with the one from the previously generated war. If you change code on the WYSIWYG sever side then you have to update the jars from WEB-INF/lib (copy those from the generated war) but that's not your case from what I can see. Don't forget to clear the browser cache. > How to force always the WYSIWYG editor to be shown in Portuguese? > You can either configure the Portuguese language as the default language in XWiki (the clean way) or, the hard way, you can build the WYSIWYG editor only for Portuguese language by replacing: <extend-property name="locale" values="...,pt"/> with <set-property name="locale" value="pt" /> in the descriptors of the xwiki-gwt-user and xwiki-gwt-wysiwyg-client GWT modules. > Hope you can help me. Note that the best way to contribute a translation is to add it to l10n.xwiki.org . This way all the previous steps are done by us. The downside is that you have to wait for the next release to see the Portuguese translation in action. Hope this mail doesn't come too late, Marius > > Regards, > > *Ramon Gomes Brandão* >

1 0

[xwiki-devs] [proposal] Migrate database to store passwords in LargeStringClass and begin using crypto.passwd#protectPassword
by Caleb James DeLisle 25 Aug '10

25 Aug '10

Because protectPassword generates a base-64 encoded java serialized form, the size is quite a bit larger than the 255 character limit of StringProperty and thus PasswordProperty. The use of java serialization is central to the upgradability of the password verification function because any new class which implements PasswordVerificationFunction automatically works. Given this, I want to migrate the database to move password hashes into the xwikilargestrings table and change PasswordProperty to extend LargeStringProperty. During this migration, any passwords still stored in plaintext will be ported to the scrypt function, passwords stored as a hash will have an exclamation mark pretended to the text (this is invalid base64) and be inserted into the table as is. PasswordClass will keep the sha-512 hash function for legacy passwords but will port passwords to the new format as users log in. These changes will allow us to close http://jira.xwiki.org/jira/browse/XWIKI-70 and http://jira.xwiki.org/jira/browse/XWIKI-582 WDYT? Caleb

6 14