xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

[xwiki-devs] [Proposal] Introduce a BeginIgnoreEvent/EndIgnoreEvent classes and clarify Begin/EndFoldEvent usage

by vincent＠massol.net

Hi devs, I’m not sure if we are all on the same page on the topic of ignoring and folding events so I’m making this proposal to try to clarify things. Needs: * Use case 1: Ability to ignore events. For example when cleaning spam, since we’re removing pages with spam in the title we may not want to have those pages appear in the Activity Stream, so the cleaning tool should be able to ignore events. * Use case 2: Grouping of Events. For example when we import a XAR we don’t want that each page in the XAR appear as a change in the Activity Stream since that would flood the stream. Instead we want to have a single entry that says “XAR xxx has been imported” (and ideally have the ability to click on a details link to unfold the full list of nested events. Current situation: * We currently have a Begin/EndFoldEvent which correspond to use case 2. The javadoc for Being says: "Implemented by event indicating a task which generates other events during its process is starting. This generated events could be seen as children of this task, that you can fold. This interface should only be used when there is a corresponding {@link EndFoldEvent}.”. * We don’t have any specific Event to say that we want to ignore all the events that come after it. * A lot of Event Listeners are currently excluding Begin/EndFoldEvent. ** For example the AS completely ignores any BeginFoldEvent sent to it (which is not correct, it should at least log one line). Proposal: * Keep Begin/EndFoldEvent with the current meaning, i.e. that it means that nested events are sent between the Begin/End. * Introduce 2 new classes: BeginIgnoreEvent/EndIgnoreEvent for the use case 1 (i.e. when some code needs to completely have the following events ignored). Those classes would implement BeginFoldEvent and EndFoldEvent. WDYT? Thanks -Vincent

8 years, 11 months

[xwiki-devs] [Proposal] Hiding "WebHome" in wiki syntax for links and images

by Eduard Moraru

Hi devs, As XWIKI-12920 [1] mentions, we need to hide "WebHome" references in the wiki syntax for links and images (for now) in order to be consistent with what we did in the UI. What this means is that [[label>>Page.WebHome]] should be equivalent to [[label>>Page]]. The plan is to apply the same logic as we did for URLs and detailed by Vincent in "Solution 2" in his comment on the issue [2]. In order to achieve this, Vincent proposed to introduce a new "space:" resource type and make this new type the default instead of "doc:" which is the current default. Before: [[label>>Page]] => [[label>>doc:Page]] After: [[label>>Page]] => [[label>>space:Page]] if "Page.WebHome" exists, or => [[label>>doc:Page]] if "<currentSpace>.Page" exists, or => wanted link to create "Page.WebHome" when clicked. Using either the "doc:" or the "space:" versions manually will resolve the requested resource, without doing any fallback resolution (which is applied only for the no-prefix version). For the same consistency reason, we need to apply the same fallback to the "attach:" resource type, e.g: [[attach:Page@file.ext]] => [[label>>attach:space:Page@file.ext]] || [[label>>attach:doc:Page@file.ext]] However, a resource is defined as ((type:) resource) so for attachments we would need to extend the type's definition to allow it to contain ":" in the type name (i.e. "attach:doc" and "attach:space") so that more variations are tested when resolving a link reference before treating it as a generic/untyped reference (this is where the fallback mechanism kicks in). There is also the image syntax that needs to be extended to support the same fallback logic, so something like: image:Page => image:space:Page || image:doc:Page In all these cases: * link space: prefix, * link attach:doc and attach:space prefixes and * image space: and doc: prefix ... we would be breaking backwards compatibility in the sense that if a wiki with the name "space" (and/or "doc", depending on which case of the above you are) already existed in the wiki farm, any links pointing to documents in that wiki from other wikis will be broken, because, for example [[label>>space:Page]] no longer points to the document "space:Page.WebHome" (from wiki "space"), but to the document "Page.WebHome" from the current wiki (where the link is made). To fix this, one would have to write [[label>>space:space:Page]] instead. I guess we could/should write a migrator to try to fix most of these cases automatically (like we fix links to a document that was renamed), but a couple of links will be unfixable if they are built programatically (e.g. by velocity scripts) and the process could prove to be extremely lengthy one (due to the parsing, processing, serialization and resaving of each document). Please feel free to comment on the above described approach. Thanks, Eduard P.S.: I did not mention macro parameter references which would also need a solution for hiding the "WebHome" part, but I`d prefer it if we handle that another time / in another thread. ---------- [1] http://jira.xwiki.org/browse/XWIKI-12920 [2] http://jira.xwiki.org/browse/XWIKI-12920?focusedCommentId=89129&page=com.at…

8 years, 11 months

Re: [xwiki-devs] PDFMulti Export

by Alessandro Strambini

Hello Anca The problem was, the page turned blank and I had to close the page. I wrote a script which works with the URL Export and loops over pages. It works great for me, so you dont have to follow this problem anymore. But thanks fort he answer :) Best Regards Alessandro Strambini

8 years, 11 months

[xwiki-devs] PDFMulti Export

by Alessandro Strambini

Hello, I wanted to ask if there is any Tool or Script at the moment to export Multiple Pages as PDF (like The PDFCollection Maker extension http://extensions.xwiki.org/xwiki/bin/view/Extension/PDF+Export+Collection+…) or the MultiPage Export, which works for me but not when i have alot of Pages to export. Im at version 7.2 and it seems like the Collection one isnt working anymore. Is there any alternative? Or did i skipped some important configuration change that it should work? I would be glad for any help. Best Regards Alessandro Strambini

8 years, 11 months

[xwiki-devs] Logo customization

by vishale

I am not happy with current logo size provided. I would like to have wikipedia like size and style. as i am not comfortable with editing css, please help me a way out. <http://xwiki.475771.n2.nabble.com/file/n7597748/wikipedia-logo.png> -- View this message in context: http://xwiki.475771.n2.nabble.com/Logo-customization-tp7597748.html Sent from the XWiki- Dev mailing list archive at Nabble.com.

8 years, 11 months

[xwiki-devs] [Proposal] New Anti Spam API in xwiki-platform-spam

by vincent＠massol.net

Hi devs, We’ve suffered some spamming attacks on xwiki.org recently and we’ve put xwiki.org under cloudflare. This should prevent some attacks but it’s not enough and spam is still going through. I’d like to propose creating a new xwiki-platform-spam module with an API module and a simple implementation using keyword blacklisting. xwiki-platform-spam |_ xwiki-platform-spam-api |_ xwiki-platform-spam-simple We could imagine adding an akismet implementation later on: xwiki-platform-spam-akismet For the simple implementation, I’d like to be able to configure the keywords in xobjects to make it simple to update and have the community helping. The API would be simple: @Role public interface SpamChecker { /** * Checks if the passed content is considered spam or not. * * @param content the content to check * @param parameters a map of parameters that depends on the implementation used. For example this can include the * IP address of the submitter of the content, its email address, the date of submission, etc * @return true if the content is considered spam or false otherwise */ boolean isSpam(Reader content, Map<String, Object> parameters); } Then the idea would be to have an EventListener for page save and comment save and go through this API. WDYT? Thanks -Vincent

8 years, 11 months

[xwiki-devs] [Proposal] Support retro-compatibility for page objects

by Guillaume Delhumeau

Hello. In XWiki, we take care of retro-compatibility. Each class that is not internal is considered as API, and we have clirr to detect when an API breakage is done. However, we don't apply this strategy regarding the page objects of our functional tests. I noticed this when I've tried to use some pages objects defined on an application based on platform 6.4.1 on an other application based on platform 7.4. Due to incompatibility issues, I had to rewrite some page objects in my new application. It will be a major issue when we will move some current core extensions to contrib. So I propose considered Page Objects as API, and to add CLIRR checks on the build. WDYT? Thanks, -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

8 years, 11 months

[xwiki-devs] [Feedback] Evaluation of Travis as a CI tool

by Jean SIMARD

Dear devs, It's been a while I'm using Travis-CI.org as a CI tool for my projects. And I thought why not using it with XWiki? So I investigate a bit with xwiki/xwiki-commons [1]. If you don't want to read the details below, here is a resume. I would push to keep Jenkins at this point (much more complete than Travis) but, one killing-feature is missing (in my opinion): integration with Github (display the result of a build in Pull Request is of great value when evaluating a PR). The following list is not exhaustive and is mainly about the most important features I've noticed. ### Travis # Benefit * We don't maintain a server * It's well-integrated with Github * It builds Pull Requests * It builds Branches * UI is pretty nice (at least better than Jenkins, hey!) # Drawbacks * You cannot choose which branches you want to build (all or none) * The UI is crashing often on Firefox (blocks the browser for few seconds before Firefox propose to kill the script) * You only have a raw log (meaning Travis cannot present information of the log with a organised structure) ### Jenkins # Benefits * We already have it and it works * It's specifically adapted for Java project (much much more details to parse the result of the build logs) * It can build branches * It can build Pull Requests # Drawbacks * Consumes a lot of resources on our servers * UI is not easy to browse (note that it show much more than Travis so of course, it's more difficult to do an UI with more information!) [1] https://travis-ci.org/woshilapin/xwiki-commons/ -- Jean Simard jean.simard(a)xwiki.com Research engineer at XWiki SAS http://www.xwiki.com Committer on the XWiki.org project http://www.xwiki.org

8 years, 11 months

[xwiki-devs] [Contrib] New repository for anti spam tool: application-antispam

by vincent＠massol.net

Hi devs, I’d like a new contrib project on xwiki-contrib to host the API I’m developing that offers antispam tools. I’m going to create it but this is a heads up about this new project. Right now it offers this Java API (with a corresponding script service): @Role public interface AntiSpam { /** * Get references and last authors of all documents matching a given solr query string. * * @param solrQueryString the solr query string to search with (e.g. "mcafee") * @param nb the number of matching results to return * @param offset the start position in the full list of matching results * @return the list of references of matching documents and their last authors * @exception AntiSpamException if an error occurs such as a failure to find matching documents */ Pair<List<DocumentReference>, Set<DocumentReference>> getMatchingDocuments(String solrQueryString, int nb, int offset) throws AntiSpamException; /** * Clean the passed documents of all changes made by the passed authors. * * @param documentReference the reference to the document to clean * @param authorReferences the reference to the authors for which to remove all changes from the document * @param skipActivityStream if true then don't generate events in the Activity Stream for the changes made to * the document * @exception AntiSpamException if an error occurs */ void cleanDocument(DocumentReference documentReference, Collection<DocumentReference> authorReferences, boolean skipActivityStream) throws AntiSpamException; /** * Find all documents with the passed author. * * @param authorReference the author for which to return the list of modified documents (i.e the last author of * the returned documents) * @param nb the number of results to return * @param offset the start position in the full list of results * @return the list of references to documents for which the passed author was the last author * @exception AntiSpamException if an error occurs */ List<DocumentReference> getDocumentsForAuthor(DocumentReference authorReference, int nb, int offset) throws AntiSpamException; } Thanks -Vincent

8 years, 11 months

[xwiki-devs] Google Apps Application

by Florian Véron

Hello, We are working with Ludovic on the google apps application. You can find the code here https://github.com/xwiki-contrib/application-googleapps, and we already have some version released. Can we have a jira for this project in order to follow issues on this app ? Thanks, Florian Véron

8 years, 11 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs