xwiki-devs September 2016

xwiki-devs@xwiki.org

20 participants
47 discussions

Re: [xwiki-devs] Nested Pages - Search Links Not Working

by Keith Davis

It's very hard to manage this application with zero support. Am I blacklisted or what? I haven't received input on a single support issue since I complained about the release notes issue (which strangely enough seems to be being worked on now). Keith Davis (214) 906-5183 - I.T. Director From: Keith Davis Sent: Friday, September 16, 2016 11:54 AM To: 'devs(a)xwiki.org' Subject: Nested Pages - Search Links Not Working So we are now starting to change all of the our pages to Nested. When linking to Nested pages in the page themselves, the links appear like this in the WYSIWYG editor: [[Tickets>>Main.Intranet.Tickets<http://Home.Intranet.Tickets>]] but when saved are converted to this: <a href="/xwiki/bin/view/Main/Intranet/Tickets/">Tickets</a> However, Search results are broken. They appear like this: [cid:image005.jpg@01D20F61.C86FF330] Those do not work as the link Main.Intranet.Tickets takes me to this page: [cid:image006.jpg@01D20F61.C86FF330] I've tried re-indexing, but that does not help. Keith Davis - MCSA, ZCE P.R.I.D.E. - I.T. Director / Senior Developer www.pridedallas.com<http://www.pridedallas.com/> Mobile (214) 906-5183

7 years, 11 months

[xwiki-devs] [Proposal] New best practice for app development: namespace restrictions

by Vincent Massol

Hi, Since XWiki 8.0 we now have a way to define in which namespace an extensions work. See “xwiki.extension.namespaces” in http://extensions.xwiki.org/xwiki/bin/view/Extension/XWiki+Commons+-+Extens… I’m proposing to add that apps should use this as a best practice in http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPra… WDYT? Thanks -Vincent

7 years, 11 months

[xwiki-devs] Nested Pages - Search Links Not Working

by Keith Davis

So we are now starting to change all of the our pages to Nested. When linking to Nested pages in the page themselves, the links appear like this in the WYSIWYG editor: [[Tickets>>Main.Intranet.Tickets<http://Home.Intranet.Tickets>]] but when saved are converted to this: <a href="/xwiki/bin/view/Main/Intranet/Tickets/">Tickets</a> However, Search results are broken. They appear like this: [cid:image005.jpg@01D20F61.C86FF330] Those do not work as the link Main.Intranet.Tickets takes me to this page: [cid:image006.jpg@01D20F61.C86FF330] I've tried re-indexing, but that does not help. Keith Davis - MCSA, ZCE P.R.I.D.E. - I.T. Director / Senior Developer www.pridedallas.com<http://www.pridedallas.com/> Mobile (214) 906-5183

7 years, 11 months

[xwiki-devs] [XWiki Day] BFD#118

by Alexandru Cotiuga

Hello devs, This Thursday is BFD#118: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 56 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=100 00#Created-vs-Resolved-Chart/10470 Here's the BFD#118 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13691 Thanks and waiting for your participation! Alex

7 years, 11 months

[xwiki-devs] [ANN] Limits Application 1.1 has been released

by Guillaume Delhumeau

Hello. Yesterday, I announced you the availability of a new extension: the Limits Application. Since, Thomas Mortagne suggested me an idea to make it better. The UI of the application is now contained in the JAR, so it cannot be removed by mistake by an user who manipulates wiki pages. Moreover, the UI is now visible on every subwikis, without the need to install something on each of them. Also, developers will be happy because they can overwrite the default UI like any skin template! To download it or see more informations, see: http://extensions.xwiki.org/xwiki/bin/view/Extension/Limits+Application/#Hv… Thanks, -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

7 years, 11 months

[xwiki-devs] [Brainstorming] New script API needed: isXARExportAvailable()

by Vincent Massol

Hi devs, I’d like to add a new script API in oldcore. I need a new API to know if the XAR export feature is available so that the Page level XAR export button is displayed (I’m trying to fix http://jira.xwiki.org/browse/XWIKI-13695#). I was thinking about adding some XXXScriptService in oldcore but the right hint would be “xar” and XXX would be “XAR”. The problem is that we already have one in xwiki-platform-xar (which right now is used by oldcore and thus I cannot add this new method to the existing XarScriptService that is there). I can’t find any name or hint that would make sense on the long run for oldcore. Some other ideas: * OldCoreScriptService, hint = “oldcore” and we consider it something temporary that will need to go away and deprecate * CoreScriptService, hint = “core”. Same * ImportExportSerciceService, hint = “?” Last, I have the option to continue what we’ve done so far which is increase a bit more the size of api.XWiki. For example we have in there the following method which does something similar: /** * @return true if title handling should be using the compatibility mode or not. When the compatibility mode is * active, if the document's content first header (level 1 or level 2) matches the document's title the * first header is stripped. */ public boolean isTitleInCompatibilityMode() { return this.xwiki.isTitleInCompatibilityMode(); } so I could add XWiki.isXARExportAvailable()… WDYT? Any preference? Right now I have a hard time deciding. I hate it but I’m considering adding a new method to the XWiki class, but I’d love to find something better. Thanks -Vincent

7 years, 11 months

[xwiki-devs] [Proposal] Future of XAR Import/Export code

by Vincent Massol

Hi devs, We are trying to reduce the size of oldcore (been working on it for years ;)). We currently have code for XAR import and export in several places in oldcore. I’d like to define the strategy that we’d like to follow in the future for moving this code out. Let’s see what we have and what it could become: * An existing ‘filter" module outside of oldcore to import/export XAR. * An action for exporting a XAR: ExportAction. Future: make it a new URL type with components as we’ve done for webjars * An action for importing a XAR: ImportAction. Future: make it a new URL type with components as we’ve done for webjars * A UI at the page level to export a page as a XAR. Future: add an UIXP in export_modal.vm and plugin the XAR option as an UIX * 2 Uis in the admin to import and export XARx. Future: convert those for ConfigurableClass. * A legacy “packaging” plugin with oldcode to import XARs. Future: retire it in xwiki-contrib and rewrite the Import/Export Admin UI to use the new XAR filter from the filter module. * Ancillary classes such as XARImport*/XARExport* events. So the question is where to put those? Proposal: xwiki-platform-xar ===================== I think what would make the most sense would be to continue the XAR module started by Thomas: xwiki-platform-xar. It would go like this: xwiki-platform-xar |_ xwiki-platform-xar-api (what’s currently in xwiki-platform-xar + Java code from oldcore defined above) |_ xwiki-platform-xar-ui (the ui part of the oldcore code above) |_ xwiki-platform-xar-filter (the move from xwiki-platform-filter-stream-xar) WDYT? The other option that I like less would be to group everything under the filter module but it doesn’t seem good. I’d prefer to keep this module generic as much as possible and have “business” modules using it (XAR import/export, Confluence import/export, MediaWiki,import/export, etc). Thanks -Vincent

7 years, 11 months

[xwiki-devs] [ANN] A new extension released on Contrib: Limits Application

by Guillaume Delhumeau

Hello. I just have released the first version of a new application in contrib, the Limits Application. This extension prevents the creation of too many users or wikis in an instance. It can also limits the number of members of any global group you want. The reason behind the creation of this application is the need, for XWiki hosters, to add some restrictions on their instances to save their resources. For example, a virtual machine handling a lot of users needs more memory: it's fair that the client pay more to push back these limits. See: http://extensions.xwiki.org/xwiki/bin/view/Extension/Limits+Application/ Thanks, -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

7 years, 11 months

Re: [xwiki-devs] [Proposal] Move out Chart Macro + Renderer to Contrib

by Eduard Moraru

Hi, Let`s think about active installs. The client module (i.e. the one doing the work and reporting) can be considered core, but the server module (the one receiving and showing a UI of the collected data) is not really core and can be moved to contrib. This will also fix the chart macro issue, since it's the server/ui module depending on it and not the client-api one. Thanks, Eduard On Sun, Sep 11, 2016 at 8:45 PM, Vincent Massol <vincent(a)massol.net> wrote: > > > On 11 Sep 2016, at 19:24, Vincent Massol <vincent(a)massol.net> wrote: > > > > Hi devs, > > > > I’d like to propose: > > * move out the Chart Macro + Renderer to Contrib since it’s not core. > > * still depend on it in the XE distribution for now. However if everyone > feels that it’s not needed to have it by default for users and that it’s > better to let them install it, I’m also fine. But right now I prefer to > have it by default. > > > > WDYT? > > hmm there’s a small problem… Right now the Active Installs module uses the > chart macro… > > And Statistics UI too. I guess this one could be moved to contrib easily > (we don’t bundle it anymore by defaultà. > > However for ActiveInstalls it’s more complex, unless we don’t want to > consider it core but I don’t think we want that… > > So it means either we stop using the chart macro there (which would be a > shame) or we consider the chart macro core… > > Any idea? > > Thanks > -Vincent > > > Thanks > > -Vincent > > > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs >

7 years, 11 months

[xwiki-devs] [Proposal] Move XE as a flavor, rename it and distribute the platform distribution instead

by Vincent Massol

Hi devs, We have a platform distribution that allows users to pick the flavor they wish to use. However we’re currently not advertising it. Instead we’re currently advertising XE on the xwiki.org download pages. I’m proposing that we change that: * Advertise the platform distribution in the download pages of xwiki.org. We would simply call it “XWiki”, e.g. XWiki 8.3. * Move existing xwiki-platform-distribution/xwiki-platform-flavor into xwiki-platform-distribution/xwiki-platform-flavors/xwiki-platform-flavor-base * Create a new flavor in xwiki-platform-distribution/xwiki-platform-flavors/xwiki-platform-flavor-<new name here> * I’m proposing to name this new flavor "Knowledge Base” (and the module xwiki-platform-distribution/xwiki-platform-flavors/xwiki-platform-flavor-kb) since this is what most users use XWiki for. The idea, initially, would simply be to use the same deps as XE and maybe remove the Blog app (or not). * Stop distributing the XE packagings We’re already well into the XWiki 8.3 dev (M2 is planned for tomorrow Monday) so it seems a bit ambitious to do this for 8.3. We could do it for 8.4 though. WDYT? Outstanding questions: * How do we upgrade existing users using XE? WDYT? Thanks -Vincent

7 years, 12 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs September 2016