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

by Nexus Repository Manager

12 years, 6 months

1
0
0 0

[xwiki-devs] RESTful Create Page doesn't exist?

by zacharykane

Hello everyone, I'm trying to automate Page generation in my client but I'm stuck on something. The way it works is a simple form on my client let's my users construct a Page Title to search for, so: .../xwiki/bin/view/Main/Whatever-Name-They've-Typed What I'm trying to do is if you get a 404 (and that page that says this doesn't exist, edit this to create) I create the page via REST commands and then direct them to the WYSIWYG editor for that new page - /xwiki/bin/edit/Main/Whatever-Name-They've-Typed - this works pretty much. The problem: The page doesn't seem to exist yet until they've clicked save and view on their editor. If I try to open the page I've just made via REST (at the aforementioned .../xwiki/bin/view/Main/Whatever-Name-They've-Typed) it says it still doesn't exist and edit this page to create. What gives? I'm doing all of this with XMLHTTPRequst and waiting for the 201 status after the page is supposedly successfully created then redirect them to the /edit/ page so they can start creating right away. -- View this message in context: http://xwiki.475771.n2.nabble.com/RESTful-Create-Page-doesn-t-exist-tp75841… Sent from the XWiki- Dev mailing list archive at Nabble.com.

12 years, 6 months

4
8
0 0

[xwiki-devs] [Proposal] Release XWiki 4.5.2 tomorrow

by Vincent Massol

Hi devs, I'd like to release XWiki 4.5.2 tomorrow. We have a very important bug fix in it (http://jira.xwiki.org/browse/XWIKI-8872) that warrants the release. In addition Jean-Vincent is also committing a quick fix (hack) to fix the wiki creation issue (see http://jira.xwiki.org/browse/XWIKI-8046). Full list: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11495 We can have a 4.5.3 if need be later on. Thanks -Vincent

12 years, 6 months

1
1
0 0

[xwiki-devs] [CONTRIB] Authenticator Trusted LDAP

by Thomas Mortagne

Hi xwikiers, I just released a new authenticator on http://extensions.xwiki.org/xwiki/bin/view/Extension/XWiki+Authenticator+Tr… . * extract the user id from the remote user and automatically create related XWiki user profile * allow using different LDAP configuration depending on what is in the remote user * synchronize user related information and group membership from LDAP (use the standard LDAP authenticator for this actually) Enjoy :) -- Thomas Mortagne

12 years, 6 months

1
0
0 0

[xwiki-devs] [QA] Feedback for 5.0 M1

by Sorin Burjan

Hello, XWiki 5.0 M1 is soon going to be released, scheduled for Monday. I see in the Release Notes Page only 2 things listed *Release Application *Office Import using the Office Macro Besides, I also know that Marius worked on DW. Besides these 3 things, I want to ask the developers if they want something else tested, for example features they worked on and didn't had the time to test properly. In order to improve the communication between the people doing QA in the community and the developers, I will send these e-mails regularly from now. Waiting our feedback. Regards, Sorin B.

12 years, 6 months

5
5
0 0

[xwiki-devs] BFD#11 Today

by Vincent Massol

Today is an important BFD. it might be THE BFD where we go back in the green :) See http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Let's go for it! All together! Thanks -Vincent

12 years, 6 months

6
12
0 0

[xwiki-devs] [Proposal] Don't work on the syntax 1.0 to 2.0 converter anymore

by Vincent Massol

Hi devs, I'd like to agree that we're not going to spend more time working on the Syntax 1.0 to 2.0 converter now that 1.0 syntax is really old and deprecated. Most XWiki instances have now switched to the new syntax and the converter is already helpful when converting pages. It's a lot of work to improve it further and it's never going to be perfect anyway. It's the rule of the 20/80... I'd like to close the following issues as won't fix as a consequence, following our rules of closing issues that we don't plan/want to work on: http://bit.ly/ZtFrtK Of course if any contributor or any devs suddenly wants one day to work on improving the converter, he can do so at any time… WDYT? Thanks -Vincent

12 years, 6 months

5
5
0 0

[xwiki-devs] Where to move AttachmentSelector.xml currently in xwiki-enterprise-ui?

by Vincent Massol

Hi devs, I'm wondering where to move the AttachmentSelector.xml page which is currently in enterprise-ui It's used by the admin app (XWikiSkinsSheet.xml) and the user app (XWikiUserSheet.xml). Maybe we'll need an attachment module in platform one day and thus we could put it in: xwiki-platform-attachment/xwiki-platform-attachment-ui Another idea is xwiki-platform-model/xwiki-platform-model-ui WDYT? Any other idea? Thanks -Vincent PS: I've started moving UserProfileTest by creating a new xwiki-platform-user-test module when realizing that it depends on the attachmentselector macro… Note that we already have an Admin app page (XWikiSkinsSheet.xml) in xwiki-platform-administration-ui that depends on that macro too so we really need to move AttachmentSelector.xml to platform somewhere...

12 years, 6 months

2
3
0 0

[xwiki-devs] [Idea] XWiki REST API documented using swagger

by Vincent Massol

Hi devs, Could be great if we could succeed in integration XWiki's REST API in Swagger: https://developers.helloreverb.com/swagger/ See also https://github.com/wordnik/swagger-core/wiki/java-jax-rs WDYT? Thanks -Vincent

12 years, 6 months

1
0
0 0

[xwiki-devs] [Proposal] When the DB is empty propose to install the EM

by Vincent Massol

Hi devs, When the wiki is empty (just the WAR installed, DW skipped) and when the user goes to the Administration, I think we should have a warning and a button telling the user that he should install the EM UI to be able to install extensions. ATM he can only use the Import feature and this will not allow him to easily install stuff (see the email about the user who tried to install the Admin app like this). WDYT? Thanks -Vincent

12 years, 6 months

3
5
0 0

[xwiki-devs] [Proposal] Introduce a first set of UI Extension Points

by Jean-Vincent Drean

Hi, following the previous thread I'd like to make a new proposal, introduce the following UIXPs in our templates : * header top: after <div id="xwikimaincontainerinner"> * header bottom : before the closing </div> * content top: after <div id="contentcontainer"> * content bottom : before the closing </div> * footer top: after <div id="footerglobal"> * footer bottom : before the closing </div> Since we don't have a builtin mechanism (as in: have top/bottom static list independent from the UIXP ID in the UIX) for the moment we have to emulate it by inserting multiple API calls (in the current proposal: at the top and bottom of the elements). Now we need to choose a syntax for the extension point IDs: 1) Use only dots in IDs: platform.header.top, platform.header.bottom, etc I was worried about using dots at first [1] but I guess that if we want to have a mapping between the HTML skeleton and UIXP IDs we'll use html5 custom attributes (<element data-uixp="platform.header" />), since we're talking about the future here. 2) Use a different separator for the position: platform.header#top If we decide to create a "position" static list in UIX, a specific separator for the position would allow to easily migrate existing UIXs. My preference goes to 2). Here are the UIXPs that would appear in the current homepage (after renaming the current IDs): * platform.header#top * platform.header#bottom * platform.content#top * platform.content#bottom * platform.panels.rightPanels * platform.panels.Applications * platform.panels.Applications.more * platform.footer#top * platform.footer#bottom [1] The problem dots is that if we decide to move towards a more generic insertion mechanism (http://dev.xwiki.org/xwiki/bin/view/Design/InterfaceExtensions#HInterfaceEx…) with a mapping between HTML IDs and UIPX IDs, the IDs will not be HTML friendly. It's not recommended to use dots in HTML elements ID and Name attributes because of HTML selectors (#id.class is a CSS selector that will look for <element id="id" class="class"/> and not <element id="id.class"/>) which then requires to escape dots in IDs when manipulating the DOM. WDYT ? JV.

12 years, 6 months

2
1
0 0

[xwiki-devs] [Notice] For contrib developers

by Vincent Massol

Hi guys, I've just added explanations on how to publish a contrib extension on extensions.xwiki.org here: http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome#HPublishingonextension… Hope it helps, -Vincent

12 years, 6 months

3
8
0 0

[xwiki-devs] [Proposal] Add support for referencing easily XObjects in the model module

by Vincent Massol

Hi devs, ATM in the model module there's no ability to reference an xobject other than by using a free form name. The problem is that this is not really usable. This is why we introduced the BaseObjectProperty in oldcore. However this is major PITA since we can't have clean code that create an object reference and that doesn't depend on oldcore. I'd like to propose the following: * Modify ObjectProperty to add 2 named parameters: Class reference and position * Make the name optional in EntityReference This means that when we use an EntityReferenceResolver to resolve "wiki:space.page^wiki2:space2.page2" we get an ObjetReference with: * name = null * param1: name = "classReference", value = EntityReference * param2: name = "objectPosition", value = 0 Rationale: * This is exactly what we already do for Locale (and what we'll do for Version too probably) so it's logical to do it for Object References too Consequences: * We need to modify the Seralizers/Resolvers accordingly * We need to modify EntityReference to support a null name * We deprecate BaseObjectProperty * Probably some other stuff to modify like modifying event listeners listening on objects since it's now going to be much easier, etc WDYT? Thanks -Vincent

12 years, 6 months

4
15
0 0

[xwiki-devs] xwiki-platform-chat and snapshots

by Felix T

Hi all, I worked the last days to get the xwiki-platform-chat running in an example installation. This project looks very interesting for us at Curriki. But I think I have the "normal" problems at this point of time. The current version of the xwiki-platform-chat at github seems to depend on the 4.2-SNAPSHOT version of xwiki. but I can not find them in the snapshot repository of xwiki nexus ( http://nexus.xwiki.org/nexus/content/groups/public-snapshots). Is that intended? Am I doing something wrong (Searching the wrong repository)? Apart from that it would be interesting what you think about the future of the xwiki-platform-chat? Is is intended to be pushed further, to newer versions of xwiki, or away from the jetty dependency? Thanks in advance Felix PS: I tried to remove all the "SNAPSHOT"s and go for version 4.2 this seems to bring me to a "Build Successful" but the resulting .war seems not to be assembled correctly (missing artifacts).

12 years, 6 months

6
6
0 0

[xwiki-devs] [Brainstorming] XWiki Flavors

by Ecaterina Moraru (Valica)

Hi, XWiki Flavors are a set of predefined extensions having a specific use case in mind. XWiki Flavors can be considered specializations of XWiki instances suited for different purposes like public websites, intranets, content sharing, project management, community status, business intelligence, etc. Scenario: You want to install XWiki. The installer will propose different 'flavors' and will install automatically all required extensions. This way you will have a product close to your initial needs. You can later refine it by installing / uninstalling other extensions. So when I first thought about the process of installing a Flavor I imagined that I could customize what I wanted from the Flavor and select just the things I need. Actually for me Flavors were like categories with subcategories, and more of a classification system, than a packaging one. http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/custo… Also another difference in my vision is that I had a Base Package that contains the common denominator for all Flavors. The Base Package should contain basic mechanics for managing content and users. Selecting no flavor will still result in having basic wiki features (page creation, attachments, history, users, etc.). After some discussions with Eduard I understood that Flavors could be defined as extensions and they could contain just a list of dependencies on other extensions. The Extension Manager will install the 'exact' list it gets from the definition without the ability to exclude some dependencies. I've watched the 'recent' mails about XWiki Flavors [1] [2] [3] [4] and for me the conclusion is clear: we will never agree on what starting features are the best and that will solve everybody's problems. But that is ok and normal and the strength of XWiki is it's extensibility. So the next idea was to have a Flavor Creator that will allow users to create their own collections of extensions. This collection should be then published to extensions.xwiki.org and could appear in the installer list as suggestions. http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/flavo… If Application Within Minutes let's you create your own applications, the Flavor Creator would let you make packages of extensions for a specific purpose. This way we strengthen XWiki's extensibility and we let the users take the power and customize the solutions that are perfect for them. Just some ideas. Thanks, Caty [1] [Idea]"Community" flavor http://xwiki.markmail.org/thread/2e3fdm3hfuh54vpr [2] [Idea] XWiki Project Development Flavor http://xwiki.markmail.org/thread/334vzyytfvlppmri [3] Idea collection minimal xwiki configuration http://markmail.org/thread/abma4pzuq2ooy6as [4] [UserStory] Wiki Archetypes http://xwiki.markmail.org/thread/jp35ackl2puuscjv

12 years, 6 months

7
16
0 0

[xwiki-devs] [ANN] XWiki 5.0 Milestone 1 released

by Thomas Mortagne

The XWiki development team is proud to announce the availability of XWiki 5.0 Milestone 1. This release is the first release for the 5.x cycle with a new Release application and contains various Extension Manager and Distribution Wizard improvements. 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/ReleaseNotesXWiki50M1 Thanks -The XWiki dev team

12 years, 6 months

1
0
0 0

[xwiki-devs] [VOTE] Name for Entity classes in the new model

by Vincent Massol

Hi devs, As you may have seen, I've been working on the new model in a branch. We need to decide on the naming of the Entity classes (wiki, space, document, object, object definition, etc). We have several possibilities I know of for naming them: 1) Wiki, Space, Document, Object, ObjectDefinition 2) WikiEntity, SpaceEntity, DocumentEntity, ObjectDefinitionEntity 3) Wiki, Space, Document, XObject, XObjectDefinition (or simply ObjectDefinition) 4) XWiki, XSpace, XDocument, XObject, XObjectDefinition 5) Some other name for objects. Some concerns: * Using Object as in 1) is a bit of a pain since there's java.lang.Object which forces to use the FQN name when coding in Java. Which is why I've put proposals 2) and 3) * In proposal 3) there's a bit of an inconsistency with the X in XObject which is not present in the other entity names, hence proposal 4 and 2) * In proposal 1) there can be some other clashes. For example Document can clash with the DOM Document object My personal vote goes to 2), even though it makes the entity names a bit longer. Cast your votes! Thanks -Vincent

12 years, 6 months

8
11
0 0

[xwiki-devs] [Discussion] Remove 'buttonwrapper' class from Standard

by Ecaterina Moraru (Valica)

Hi devs, Our documentation http://platform.xwiki.org/xwiki/bin/view/DevGuide/VerticalForms is requesting to use .buttonwrapper class as container for button controls. When I added this in the standard was because we were also supporting Toucan Skin and in Toucan this was needed in order to have images on buttons (it was an older skin and we needed to support IE6 and IE7). Since we don't support Toucan anymore and now the CSS has advanced that you can insert additional style by using the ':after' or ':before' pseudo-classes I don't think there is no reason to keep an additional container. I send this mail because Marius created a very sweet Button Group Widget in 4.5.1 http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki451#HButt… and he is using the .buttonwrapper container. I don't think we should promote an additional container anymore. Right now Colibri's CSS demand the 'buttonwrapper' in the style it has both for inputs or for links. This could be changed for Colibri by rewriting a bit those rules or by adding new ones (more specific but would preserve backward compatibility). I don't know if these changes should be kept for a new skin or added now, so let me know what you think. Thanks, Caty

12 years, 6 months

4
3
0 0

[xwiki-devs] Statistics about XWiki bug fixing

by Vincent Massol

Hi devs, I've created a new dashboard for stats about how we fare regarding bugs: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Namely there are 3 majors charts (left column shows stats over the whole period of the project while on the right stats are for the last 365 days): * Created vs Resolved: Show how many bugs were created vs bugs resolved. The blue line shows the evolution of non fixed bugs. We can see that we've not been good till recently and only recently we're starting to invert the trend. * Recently Created Chart: The red bars shows how many bugs that were created at given point in time are still open. I'm not sure exactly how to draw a conclusion from this chart yet… * Average age chart: Shows how long it was taking to fix a bug as an average. For example on 1 Jan 2006 it was taking 184 days average to get a bug fixed. And on 1st of March 2013 it's now taking 736 days average to get your bug fixed… This shows how bad we are with bug fixing… By continuing our weekly BFDs, we should see this average age go down normally… We should also try to pick the oldest bugs first to make it go down faster ;) WDYT? Any analysis that comes to your mind? For me it means we really needed to start addressing our bugs and that are weekly BFDs are going in the right direction and starting to have some effects. Thanks -Vincent

12 years, 6 months

2
3
0 0

[xwiki-devs] Diagram Application

by Marius Dumitru Florea

FYI, I just published a Diagram Application (based on AppWithinMinutes and draw.io) on extensions.xwiki.org , installable with the Extension Manager. Documentation: http://extensions.xwiki.org/xwiki/bin/view/Extension/Diagram+Application Source: https://github.com/xwiki-contrib/application-diagram Enjoy, Marius

12 years, 6 months

3
6
0 0

[xwiki-devs] Plenty of JIRA issues with missing "affects" field...

by Vincent Massol

Hi devs, I've fixed a few of those but there are still plenty. If you feel like helping, feel free to add affects to them (and "components" where it's missing): http://jira.xwiki.org/issues/?jql=category%20%3D%2010000%20AND%20affectedVe… Thanks -Vincent

12 years, 6 months

3
3
0 0

[xwiki-devs] [Proposal] XWiki memory requirements increase...

by Vincent Massol

Hi devs, Right now we recommend this on http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Installation#HPrerequis… : "A minimum of 300MB of heap memory and 96MB of permGen. Recommended values are above 512MB for the heap and 128MB for the permGen (-Xmx512m -XX:MaxPermSize=128m)" I've discovered on http://ci.xwiki.org/job/xwiki-enterprise-test-extension/org.xwiki.enterpris… that we had an OOM and it seems to happen more and in more in our functional tests on CI. Something we've done must have increased our permgen memory. I've done some measurements with yourkit and here's what I found: * After XWiki is started and before any page is called we already use 64MB of permgen * After calling the home page, the permgen used goes to 101MB * After calling a page using the code macro, the permgen goes to 132MB So it seems that your default value of 96MB and recommended value of 128MB are not enough… BTW forcing garbage collection reduces from 132MB to 130MB (not much). We need to either find what is taking all our permgen memory or if it's legit increase our recommendations and the default value we use in start_xwiki.sh/bat Any idea? My hunch tells me the Extension Manager could be the cause. Thanks -Vincent

12 years, 6 months

3
3
0 0

[xwiki-devs] [Notice] Dashboard link in release notes

by Vincent Massol

Hi devs, I've modified the release notes template on xwiki.org so that we always put a link to the jira dashboard in all our release notes from now on. Examples: - http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki451 - http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki50M1 It's up to the RM to create the associated JIRA dashboard and filters (or anyone who wants to help for that matter but it's up to the RM to make sure it's there). Thanks -Vincent

12 years, 6 months

1
0
0 0

[xwiki-devs] [Proposal] Roadmap for XWiki 5.0

by Vincent Massol

Hi devs, With XWiki 4.x cycle coming to an end soon, it's time to prepare the roadmap for XWiki 5.0. This is a proposal that comes from some internal meetings done with XWiki committers who are working for XWiki SAS. If you're interesting in participating to this release, don't hesitate to add yourself to the list so that everyone can have some visibility of what's going to be worked on during this timeframe! If you think some work defined below doesn't go in the interest of the project also feel free to raise issues. Features: * Continue SOLR implementation - Edy * EM upgrade of subwikis + flavor concept (add Flavor type in EM/Repository) + leftover from 4.x for EM/DW - Thomas + Marius for DW UI part for flavors * AWM work from 4.x to finish (see http://www.xwiki.org/xwiki/bin/view/Roadmaps/WebHome) - Marius * scalable import/export - Thomas * Home page improvements (XE) and usability improvements in general - JV * Horizontal Menu management (add, remove pages) - JV * virtual=1 by default - Edy (Edy will need to make a proposal for that since it's an important decision ;)) * l10n speed improvements - Ludovic Important JIRAs sorted by priority (most important first): * AWM Add the ability to publish an application as an extension XWIKI-7377 - Marius * AWM Add the ability to export an application XWIKI-7376 - Marius * Unable to edit a page using the WYGIWYG editor after adding a dashboard macro to it XWIKI-8495 - Need volunteer * Improve AWM for it to deal with error messages made by Client when filling the AWM form in using special chars XWIKI-8763 - Marius * Import of Office file breaks Activity Stream and Recently Modified Panel XRENDERING-261 - Need volunteer * Cannot change document title from "inline" mode XWIKI-7905 - Not sure if we want it, to be checked with Marius * When the workspace owner is changed, the new owner is not added as a member nor in the admin group XWIKI-8397 - Edy * Unable to upload a new attachment using the "All pages" tab in the WYSIWYG editor XWIKI-8465 - Marius * Workspace owner and initial members not set as members (nor in admin group) when the workspace identifier contains an underscore XWIKI-8394 - Edy Investigations: * XEM Homepage / Portal - Caty * Knowledge base Flavor - Caty/Ludovic * New Activity Stream Investigation Part 1 - JV (he's agree to become our AS champion :)) * General Flavours Investigation - Caty + input from tech Regarding dates I'm proposing the following: * 5.0M1: 4 March 2013 * 5.0M2: 25 March 2013 * 5.0RC1: 8 April 2013 * 5.0Final: 15 April 2013 Thanks -Vincent

12 years, 6 months

1
3
0 0

[xwiki-devs] [ANN] XWiki 4.5.1 released

by Vincent Massol

The XWiki development team is proud to announce the availability of XWiki 4.5.1. This is a bugfix release. 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/ReleaseNotesXWiki451 Thanks -The XWiki dev team

12 years, 6 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs