xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

[xwiki-devs] [Proposal] Make it simpler for users to install extensions offline

by Vincent Massol

Hi, I’d like to propose that we add a new extension repo location by default in xwiki.properties that points to a predefined location in the permanent directory. For example: PERMDIR/extension/custom or PERMDIR/repository We’d have a README file in there that could explain what this directory is for with a small command line example: mvn org.apache.maven.plugins:maven-dependency-plugin:2.1:get \ -DrepoUrl=url \ -Dartifact=groupId:artifactId:version \ -Dmaven.repo.local=/location/to/custom/repo This new repo would be the last one in the list of repos in xwiki.properties. WDYT? Thanks -Vincent

8 years, 6 months

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

by Alexandru Cotiuga

Hi devs, Today is BFD#109: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 107 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-R… Here's the BFD#109 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13620 Happy Bug Fixing Day! Thanks, Alex

8 years, 6 months

[xwiki-devs] [ANN] XWiki 7.4.4 released

by Vincent Massol

The XWiki development team is proud to announce the availability of XWiki 7.4.4. This is a bugfix release that fixes important bugs discovered in the 7.4.3 version. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki744 The following people have contributed code to this release (sorted alphabetically): Alexandru Cotiuga Clemens Robbenhaar Denis Gervalle Eduard Moraru Guillaume Delhumeau Marius Dumitru Florea Medjdoub Pascal Bastien Thomas Mortagne Vincent Massol Thanks for your support -The XWiki dev team

8 years, 6 months

[xwiki-devs] [ANN] Release of Nested Pages Migrator Application 0.5.1

by Guillaume Delhumeau

Hello A new version of the Nested Pages Migrator Application extension is available. See http://extensions.xwiki.org/xwiki/bin/view/Extension/Nested+Pages+Migrator+… You can install or upgrade with the Extension Manager. The application is still a beta version that you should use carefully. But this version brings some important bug fixes. Enjoy! -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

8 years, 6 months

[xwiki-devs] [Proposal] Location for third-party extensions' content in XWiki Enterprise

by Alexandru Cotiuga

According to the new decided strategy in http://markmail.org/search/?q=[xwiki-devs]+[VOTE]+New+Strategy+for+the+XWik…, third-party extensions can by bundled in XWiki Enterprise. In some cases, we would need some content from those extension to be available at build time. Where could we put it? Taking the Tour Application's example, which It is about to be added in the dependency management of xwiki-enterprise and inherited in xwiki-enterprise/xwiki-enterprise-ui/xwiki-enterprise-ui-commons, we could have the following options: 1) xwiki-enterprise-ui-commons as a space Tours 2) xwiki-enterprise-ui-wiki as a space Tours 3) xwiki-enterprise-ui-mainwiki as a space Tours 4) in a new child module of xwiki-enterprise.ui (looks like "help" keyword would make sense: xwiki-enterprise-ui-help) which could be used for future cases 5) in a new child module of xwiki-enterprise-ui having a specific name for tours. Could we decide a new rule for this topic? Thanks, Alex

8 years, 6 months

[xwiki-devs] [UX][Vote] Future of Main.Welcome

by Ecaterina Moraru (Valica)

Hi, This thread is about deciding on a future for the Main.Welcome page. This page was used as the first gadget's content and was intended to be modified by the users. In 8.2M2 we changed the content of Main.WebHome page to provide simple wiki text instead of the Dashboard include, deprecating somehow the purpose of the Welcome page. Problem: In the 'Navigation' panel the "Welcome to your wiki" is displayed as a child page of "Home". Users might ask what is the purpose of this page. We could either: 1. Keep it 1.A and mark it as hidden: in order to not be displayed in the Navigation tree 1.B and move it to Dashboard: instead of being in the Main space, since now it's used only there. 1.C and change the text: from a generic 'Welcome' message, to instructions on how to edit the Dashboard (we would need a separate proposal on the content + if we want to display other gadgets) 2. Remove it We could consider that its content is deprecated by the new Main.WebHome page, so no need for this page. So we could delete the page + remove it from Dashboard. Dashboard could highlight more advanced gadgets (needing the separate Dashboard proposal). Let me know what you think, Caty

8 years, 6 months

[xwiki-devs] Integration of ratings in xwiki-platform

by Victor Rachieru

Hei devs, I intend to integrate the ratings application which is now on xwiki-contrib into the xwiki-platform. This in mainly due to 3 points: ----- 1/ give the ability to use ratings in a wiki 2/ using it to provide ratings for the Extension Repository Application (XWIKI-7780) 3/ display ratings within Extension Manager (XWIKI-11509) The first point can be accomplished by using the ratings app as is but the other two imply that the ratings app should be a module that is maintained by XWiki. It makes sense that if the Extension Repository App and Extension Manager which are maintained by XWiki depend on the Ratings App, that this itself is maintained by XWiki as well. The steps needed for this is as follows: ----- 1/ create a new module in the xwiki-platform core for the ratings - xwiki-platform-core -- xwiki-platform-ratings --- xwiki-platform-ratings-api --- xwiki-platform-ratings-ui 2/ change the artifact id from "application-ratings" to "xwiki-platform-ratings" 3/ change the package from "org.xwiki.contrib.ratings" to "org.xwiki.platform.ratings" Implications ----- 1/ clone of the existing code is now in xwiki-platform under a different artifact id (having duplicate code, this takes us to #2) 2/ the code from xwiki-contrib would probably have to be deemed as "retired" 3/ the applications with a dependency to the xwiki-contrib ratings would have to be upgraded to depend on the module from xwiki-platform 4/ the script service would remain unchanged (changing the artifact id and package name does not affect the service) 5/ if by any chance someone has code that uses the classes from the ratings app on contrib, by upgrading, that code will cease to function Please state you position on this matter. Links ----- http://extensions.xwiki.org/xwiki/bin/view/Extension/Ratings+API http://extensions.xwiki.org/xwiki/bin/view/Extension/Ratings+Application https://github.com/xwiki-contrib/application-ratings Thank you, Victor

8 years, 6 months

[xwiki-devs] Customize the title of a blog

by Julio Brum

Hello, How can I customize the title of a blog? I need to replace the title; information author, date, etc., which are below the title for a picture. I would like to replace this layout: [image: Imagem inline 1] for this layout (with image): [image: Imagem inline 2] Thank you in advance. Sincerely, Julio

8 years, 6 months

[xwiki-devs] UI extensions points VS ConfigurableClass (or any XObjects mechanism)

by Guillaume Delhumeau

Hello developers. I send this e-mail because I want to talk about the concept of UIX when it comes to inject content in a application that has already a mechanism to append content. Use-case: being able to inject some content in an administration page. Example: I would like to write an extension that display some informations on the "users" section of the administration. See the image: http://jira.xwiki.org/secure/attachment/32664/32664_example.png Currently, the only solution that I have is to overwrite XWiki.AdminUsersSheet which generate 2 problems: - it's a mess to maintain when XWiki is upgraded. - 2 different extensions cannot inject content in the same page (one will overwrite the other). Generally, we implement UI extension for this kind of problems, and that was my first intention. In the commit https://github.com/xwiki/xwiki-platform/commit/374903eea354db2d25b6541f8fd7… (on a branch), I've introduced a UIX point on the top of the right side of the administration. It can display several ordered extensions. And it can be displayed in a particular section, or in all of them. The UI extension has the following benefits: - we can easily create extensions to inject content anywhere. - if the UIX is supposed to be injected in a particular section and if that section does not actually exists (for example: if it has a part of an optional application that is not installed), the UIX is simply not displayed. - the mechanism is already used in a lot of places and is well-known. But in this particular context, this solution has a drawback: it creates a kind of duplication with the ConfigurableClass mechanism that we use to display sections in the administration ( http://extensions.xwiki.org/xwiki/bin/view/Extension/Administration+Applica… ). So I've tried to create a ConfigurableClass object to implement my use-case. However, it has several issues: - if 2 XObjects define the same section in the administration, both of them are displayed but we cannot select the order. - one of the 2 xobjects is automatically added in a form, which is not what I want. According to the documentation: " codeToExecute is executed before the form is begun, however if you have multiple ConfigurableClass objects in the same application which are also shown in the same section of the administration application (perhaps with different headers) then codeToExecute of any ConfigurableClass object after the first will be executed inside of the form. " There is one image to show this: http://jira.xwiki.org/secure/attachment/32665/32665_problems.png The mechanism has also the following limitations: - there is no way to inject content in ALL the sections of the administration. - if you want to inject content in a section only if that section exists, you cannot. Because of the presence of your object, the section will be displayed all the time. This is bad if you want to inject some content in an optional application that might be or not installed. So I'm front of 2 possible implementations: - introduce the UIX anyway, with all it benefits. - improve the ConfigurableClass mechanism, with special attention to not break the backward compatibility (I think about the "codeToExecute" parameter). The first solution have my preference. Not only because it's easier to implement (see my patch), but also because of its benefits. Moreover, the use-case is NOT to create a section in the administration. It is only about INJECTING content on an existing section, and this is exactly the purpose of UIXs. I believe this debate exceeds this particular use-case, and that we might have the same question for any application that define some custom way to be modular. So I propose this rule: - it's OK to create a custom mechanism to *structure* a modular application. - it's OK to add some UIX points in it too when the goal is to be able to inject content in an existing section. But I find this definition quite imprecise. What do you think about this? For the record, this is the JIRA issue about this topic: http://jira.xwiki.org/browse/XWIKI-13494 Thanks, -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

8 years, 6 months

[xwiki-devs] [UX][Proposal] Recommended extensions on e.x.o

by Ecaterina Moraru (Valica)

Hi devs, This is a proposal on how we could improve the homepage of extensions.xwiki.org in order to make it easier for users to discover useful extensions. Homepage: http://design.xwiki.org/xwiki/bin/download/Proposal/XWikiOrgExtensionsWiki/… The main idea is to add a Recommended property to the Extensions class in order to select some extensions that we believe to be of high quality. Having this property will help us highlight this selection on the homepage, by providing a custom livetable (users that will want to browse all extensions should use the 'Browse' action - that will take them to the current e.x.o livetable). Some notes about the recommended livetable, we should: - add a filterble Ratings column - improve the Author column (by providing filtering and a display) - simplify the date format I've tried to make the proposal as simple as possible to implement. Let me know what you think, Caty

8 years, 6 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