xwiki-devs February 2016

xwiki-devs@xwiki.org

21 participants
47 discussions

Re: [xwiki-devs] [xwiki-users] Translations available at Global Level

by Ecaterina Moraru (Valica)

Hi, The copy dialog is something we added recently in 7.2+ and displays the page structure from the subwikis. The problem is that if from subwikiA you want to copy to subwikiB and you are browsing the tree, you will see unrendered titles for the homepage of some applications. 1. So the current 'solution' was to change the visibility for TranslationDocumentClass from WIKI to GLOBAL. Apparently this requires PROGRAMMING rights. 2. Another bad solution would be not use translations keys for those homepage titles, in order to display plain text. Or just accept the fact that it is unrendered (which looks really bad). 3. other??? Thanks, Caty On Mon, Feb 8, 2016 at 12:03 PM, Iustin Insuratelu < iustin.insuratelu(a)xwiki.com> wrote: > Hello, > > Recently we've been discussing about a situation that creates some > inconveniences. > > What happens in short: > * Have multiple subwikis, each with different extensions > * Try to copy one content page from one wiki to another > * When you are using the Copy Dialog - you can see pages from other > subwikis. In that list the translations are broken. > * It's about the applications homepages that uses translations keys for > their titles. > > You will get something similar to http://screencast.com/t/8aHY7dca > There are problems with translations visibility between subwikis. > Check: > * ideas > * filemanager > * xpoll > * notes > > You can get more details from: > * http://jira.xwiki.org/browse/NOTES-3 > * http://jira.xwiki.org/browse/XDOODLE-32 > * http://jira.xwiki.org/browse/IDEAS-63 > > The current solution (see > https://github.com/xwiki-contrib/application-ideas/pull/16) creates a few > glitches with installing that app on subwikis and programming rights. > > What we need is to define a rule that will be acceptable for the entire XE. > What are your thoughts on this? > > Regards, > *Iustin* > _______________________________________________ > users mailing list > users(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/users >

8 years, 7 months

[xwiki-devs] [Idea] Sponsoring issues

by Vincent Massol

Hi devs, WDYT of doing like Jenkins is doing and adding a "Sponsor this issue" button on JIRA? For example: https://issues.jenkins-ci.org/browse/JENKINS-9030 When you click it redirects to http://www.freedomsponsors.org/core/login/?next=/core/issue/sponsor%3Ftrack… You can check http://www.freedomsponsors.org/ It could be interesting to try it and see how it goes. WDYT? Thanks -Vincent

8 years, 7 months

[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, 7 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, 7 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, 7 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, 7 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, 7 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs February 2016