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

by Thomas Mortagne

Hi devs, I need to make Extension Manager provide a user agent when communicating with repositories to be a good http citizen but I'm not sure which user agent to set. Should it be: * an Extension Manager repository handler user agent * an Extension Manager user agent * an XWiki user agent * an XWiki platform user agent WDYT ? -- Thomas Mortagne

13 years, 7 months

2
1
0 0

[xwiki-devs] creation date not correct

by Edo Beutler

Hi devs Today we stumbled across, what we think, is a bug. All (at least almost all) the creation dates are wrong. They are set to the first occurrence of getDocument() for a specific document and not on first save(). Usually the difference ist only small (minutes), but there are cases where the difference are several days. We suppose that calling getDocument('Test.NotExistingDoc') creates the document and puts it into the cache with a current timestamp in creation date. Let's say you work now for an hour before you save the document, then the creation date would be an hour old even though the document has just been created. We always expected the creation date to be the moment of the first save. Thus we think it's a bug. We came across the problem because we had someone complaining that a document he created on the 19th was listed under the ones from the 17th. This could even happen across users if e.g. there is a link to a not yet existing page. User A clicks on the link, realizes there is nothing on the page and leaves. Hours later user B goes to the page and adds content. Now the creation date of the page would be at an inexplicable time for user B since he never touched the document until hours after the shown creation date. We work on 2.7.2 at the moment, but judging by the source code we think it should be the same in the current version. To reproduce it create the following script: #set($newDoc = $xwiki.getDocument('Test.NotExistingDoc')) $newDoc.getCreationDate() If you reload several times you see, that the creation date does not change, even though the document has never been saved. Add a save to the script: $newDoc.save() Now you have a document where creation date and save date of the version 1.1 do not match. Should I create a JIRA issue for that? Maybe we could even send you a git pull request, but you would have to tell us where you want it to be fixed: 1. In save action. There the creator of the document gets set already. 2. In the store action. We think it would belong there, but are not sure if this would break something e.g. import or copy 3. Somewhere else Regards, Edo

13 years, 7 months

2
2
0 0

[xwiki-devs] Dates for 3.4 final and 3.5 RC1/final

by Marius Dumitru Florea

Hi devs, The 3.4 final release has been delayed almost 3 weeks, for various reasons, so we need to adjust the planning for 3.5. I propose: 3.4Final: 23 January (this Monday, so in 3 days) 3.5RC1: 6 February (2 weeks) 3.5Final: 13 February (1 week) WDYT? I can be the release manager of 3.5 but we need a release manager for the beginning of the 4.x cycle. Thanks, Marius

13 years, 7 months

6
7
0 0

[xwiki-devs] Upgraded from Xwiki 2.x to 3.1.1 now Admin panel looks strange is wiki or DB corrupt?

by Kaya Saman

Hi, I wonder if anyone can help me as I've tried to obtain help from the Xwiki Users list but didn't work? After an upgrade from my old version of Xwiki which was 2.x (I think I built it in 2010) to 3.1.1 I ended up seeing this as my admin panel: http://www.optiplex-networks.com/xwiki/bin/download/Main/WebHome/Screenshot… In comparison with my old Xwiki instance this doesn't look right. Additionally, figuring that I should upgrade to version 3.3 or 3.4rc-1 I ended up not being able to display anything and getting a 500 error in Tomcat. I am using Tomcat6 coupled with Postgresql as DB backend. I will post the logs of tomcat if requested but currently I am slightly more concerned with the ill looking admin panel. Also having two similar wiki sites running on 2 different instances of Tomcat, I am unable to use the WYSIYSG editor on this current wiki as it doesn't render, the little animation just keeps spinning forever but not actually doing anything. The other wiki's WYSIYSG editor is ok though after the upgrade?? Can anybody help? Regards, Kaya

13 years, 7 months

2
4
0 0

[xwiki-devs] [Announcement] XWiki Enterprise 3.2.1 and XWiki Enterprise Manager 3.2.1 Released

by Sergiu Dumitriu

The XWiki development team is proud to announce the availability of XWiki Commons, XWiki Rendering, XWiki Platform, XWiki Enterprise and XWiki Enterprise Manager 3.2.1. This is the first and probably last bugfix release of the 3.2 series, with no new features, and a few bugfixes and minor improvements. One important change is the way relative references in an included document are resolved, reverting back to the pre-3.0 behavior. See http://jira.xwiki.org/browse/XWIKI-7382 for more details. Other areas with several bugfixes are support for Oracle databases, the rending engine, the WYSIWYG editor, and the Activity Stream. See the full release notes at http://www.xwiki.org/xwiki/bin/ReleaseNotes/ReleaseNotesXWikiEnterprise321 for more details. Note: The binaries for this release aren't listed on the Download page, but they can be obtained directly from our maven repository [1] or the OW2 forge download area [2]. [1] http://maven.xwiki.org/releases/org/xwiki/enterprise/ [2] http://forge.ow2.org/project/showfiles.php?group_id=170 -- Sergiu Dumitriu http://purl.org/net/sergiu/

13 years, 7 months

1
0
0 0

[xwiki-devs] [VOTE] Limit xwiki.authentication.group.allgroupimplicit to the group wiki

by Thomas Mortagne

Hi devs, Right now if you enable xwiki.authentication.group.allgroupimplicit any user from any wiki will be part of any XWiki.XWikiAllgroup group from any wiki. I think this is wrong, for me xwiki.authentication.group.allgroupimplicit is supposed to have the same behavior as if it was disabled except that it allows to avoid loading a potentially huge group just to check if the user is in it. So I propose to also compare the user and group wiki and not just check that the group has space "XWiki" and name "XWikiAllGroup". WDYT ? -- Thomas Mortagne

13 years, 7 months

4
3
0 0

[xwiki-devs] About 3.2.1 release

by Guillaume Fenollar

Hi devs, I'm still waiting for xwiki 3.2.1 to be released, we have to use this version for some projects. Any news on that? Thanks, -- Guillaume Fenollar XWiki SysAdmin Tel : +33 (0)1.83.62.65.97

13 years, 7 months

6
8
0 0

[xwiki-devs] [Announcement] XWiki Enterprise 3.3.1 and XWiki Enterprise Manager 3.3.1 Released

by Sergiu Dumitriu

The XWiki development team is proud to announce the availability of XWiki Commons, XWiki Rendering, XWiki Platform, XWiki Enterprise and XWiki Enterprise Manager 3.3.1. This is the first and probably last bugfix release of the 3.3 series, with no new features, and a few bugfixes and minor improvements. One important change is the way relative references in an included document are resolved, reverting back to the pre-3.0 behavior. See http://jira.xwiki.org/browse/XWIKI-7382 for more details. Other areas with several bugfixes are the workspaces functionality, the Debian installer, the extension manager, cache management, and App Within Minutes. See the full release notes at http://www.xwiki.org/xwiki/bin/ReleaseNotes/ReleaseNotesXWikiEnterprise331 for more details. -- Sergiu Dumitriu http://purl.org/net/sergiu/

13 years, 7 months

1
0
0 0

[xwiki-devs] Time spent doing the release

by Marius Dumitru Florea

Hi devs, Vincent asked me to write down the time I spend doing the release so that we can see what part of the release process needs to be improved. Here's the result: (1) Stabilize the build, making sure all tests pass on CI: up to 4 days (2) Update translations: ~15min (lots of unsignificant changes that have to be reviewed and ignored) (3) Set up the release agent: ~10min (4) Release on Jira, checking opened issues for partial commits, moving or splitting issues: ~30min (it really depends on how many issues have the "Fix Version/s" set to the released version and are not yet closed) (5) Write the release notes: from 2h to a full day (the relatively easy part is scanning closed Jira issues for new features, upgrades, important bugfixes, migration or backward compatibility problems; then you have to push developers to document the new features and the migration problems that they have introduced -- this takes longer) (6) Maven release: ~2h (if everything goes smoothly, otherwise you maybe have to spend an additional 1h to fix cyclic dependencies or bad dependency versions) (7) Collect Clirr report and clean up the release agent: ~10min (8) Paper work (announcements/news): ~1h 30min As you can see the most time consuming is: * stabilizing the build -> committers should check the CI after they commit * writing the release notes -> committers should document their work on XWiki.org before the release day Thanks, Marius P.S.: Kudos to Sergiu and Caleb for the (semi-)automated release script!

13 years, 7 months

3
2
0 0

[xwiki-devs] username cookie a plan for the future?

by Paul Libbrecht

Hello developers, since quite long I see that XWiki has the practice of a cookie that says the username (and password) encrypted. The way to encrypt the username seems a "simple" cipher that would be fairly easy to share, provided the key is shared of course. I am considering to use this for the purpose of recognizing the authenticity of a request to another web-application. I am thinking a simple servlet-filter would be able to do most of the authentication services, provided the user is logged in into xwiki (and the cookie-path makes /blabla also receive the cooke). But there are two questions: - is this encryption recognizable as signed? (i.e. can someone without the key generate an encrypted username?) - is this practice expected to last? If yes to both, it would be interesting to share a servlet filter (or even Apache module) that would do this recognition and indicate the recognized user-principals. Maybe that was done already? thanks in advance Paul

13 years, 7 months

2
1
0 0

[xwiki-devs] XWiki Enterprise and XWiki Enterprise Manager 3.4 Release Candidate 1 Released

by Marius Dumitru Florea

The XWiki development team is proud to announce the availability of XWiki Commons, XWiki Rendering, XWiki Platform, XWiki Enterprise and XWiki Enterprise Manager 3.4 Release Candidate 1. The first release candidate of the 3.4 version brings a few bug fixes and improvements over the previous version. The most notable addition is the possibility to easily import an extension from any repository into XWiki Repository. You can find the full list of issues fixed for this release at http://goo.gl/G9InJ . See the full release notes at http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterpris… for more details. Thanks -The XWiki dev team

13 years, 7 months

3
3
0 0

[xwiki-devs] Wrongly deprecated xe.pagination.* translation properties?

by Vincent Massol

Hi Sergiu, I've seen you committed the following below. I'm now renaming properties since I' m moving the livetable to platform. You've marked 2 properties as "deprecated": +# Deprecated: xe.pagination.results=Results xe.pagination.results.of=out of However they're are still used in livetable.js. How come? Thanks -Vincent Author: sdumitriu Date: 2009-05-22 15:09:39 +0200 (Fri, 22 May 2009) New Revision: 20272 Modified: platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources.properties Log: XWIKI-3880: Improve the pagination aspect Adding resources Modified: platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources.properties =================================================================== --- platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources.properties 2009-05-22 12:57:04 UTC (rev 20271) +++ platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources.properties 2009-05-22 13:09:39 UTC (rev 20272) @@ -1675,11 +1675,19 @@ xe.space.index=Space Index xe.space.index.description=This page lists all your wiki's spaces +xe.pagination.page=Page +xe.pagination.page.title=Go to page {0} +xe.pagination.page.previous=« previous page +xe.pagination.page.prev.title=Previous Page +xe.pagination.page.next=next page » +xe.pagination.page.next.title=Next Page +xe.pagination.results.none=No results +xe.pagination.results.one=One result +xe.pagination.results.single=Result {0} of {1} +xe.pagination.results.many=Results {0} - {1} of {2} +# Deprecated: xe.pagination.results=Results xe.pagination.results.of=out of -xe.pagination.page=Page -xe.pagination.page.next.title=Next Page -xe.pagination.page.prev.title=Previous Page xe.livetable._actions.delete=delete xe.livetable._actions.rename=rename

13 years, 7 months

2
1
0 0

[xwiki-devs] [VOTE] Mark the xwiki/1.0 syntax as deprecated

by Sergiu Dumitriu

Hi devs, Since a long time ago, the xwiki/1.0 syntax has been deprecated in favor of the new rendering engine and the 2.x syntaxes, but this has never been declared deprecated formally. We should: * mark the syntax as deprecated in the UI (like 2.1 was marked experimental in the syntax choice dropdown) * deprecate classes and methods that deal only with the old syntax * push more for migrating all documents to the 2.1 syntax; the biggest troublemaker is the statistics application Here's my +1. We should also decide on a timeline for the complete removal of the 1.0 syntax. Is that something we want to do? Provided we manage to migrate all the official documents and some major contributed applications during the 4.x cycle, is XWiki 5.0 a good target? We should package the support for xwiki/1.0 as an optional extension installable using the extension manager, so that people can upgrade from older versions. Or we could package just a syntax migrator that can be used for an automatic conversion to a newer syntax, without actually providing rendering support for it. -- Sergiu Dumitriu http://purl.org/net/sergiu/

13 years, 7 months

11
13
0 0

[xwiki-devs] [Discussion] Release strategy and slippages - Timeboxing

by Vincent Massol

Hi devs, We've been quite bad at following the release strategy we've defined so far: timeboxing. We've been constantly slipping our release dates during all the past releases (and not by 1 or 2 days, but by 2 weeks or more). Personally I find this not professional of us and for me it means that the date we give are just a joke now. I don't even see why we're giving dates since they can only be misleading to anyone who would act on them… At the current slippage rate, we should only give a month estimation to have a chance of being correct ;) There's only one reason we're really slipping IMO: we've forgotten that we're doing time boxing. Let me remind us what time boxing is and how it can be made to work: * It means releasing on a fixed date and releasing whatever is ready at that date. * The idea is also to do quick releases so that if a given feature is not in a release it'll be in the next one coming soon (we used to do 2 to 3 weeks releases at some points and recently we've been doing instead 3-5 weeks instead) * The reason for releasing often is because this pushes the bug fixes and new stuff to users ASAP and thus let them experiment with them and give us feedback (bugs, usability, etc) * The way to make timeboxing work is by having automated functional tests so that we can release safely knowing that our test suite will catch the problems if any. This means that whenever a commit is done, in the same commit there are tests proving that what is committed is working (and not several weeks later which would be anti-timeboxing). * it doesn't mean we cannot have a roadmap. What it means is that we should the maximum of what is in the roadmap in a given time slot. What's not done doesn't get released. This means that large features should be divided into small one that will fit. Developers need to think about what they're doing by constantly checking the release date and verifying what they can achieve for that date and make absolutely sure that what they have committed is working for that date (even if what they have committed is not finished). * Timeboxing is not about how many men/days you have available or whether people are on holidays or not. If you have less men/days you do less work. It doesn't change the release date. Basically you can only do timeboxing if you have good and automated quality control. The opposite of timeboxing is feature releases which lead to the following: * People committing not working stuff or without tests because they know they'll have time to fix it later on before the release (easy to think this since there's no release date, it's only when the features are done that it'll get released) * Release date become not important since they keep being pushed since what's important is to release planned features * Build failing all the time and developers not caring about it ("it can always be fixed later when we get close to the release date" - that's easy to say since there' no fixed release date) * Users seeing less frequent releases and giving less feedback to developers (thus helping less) * In general, quality dropping over time So we have several choices: 1) Forget timeboxing and do feature-based releases, i.e. we list features and we only release when they're done 2) Start doing real timeboxing again I've seen so many projects do 1) in the past with such bad results that for me there's no doubt that the only good strategy is 2). Especially for an open source project which has a strong community and we should be releasing stuff regularly and quickly to this community to get good feedback. Doing timeboxing is also a great way to improve the quality of our code. Timeboxing can only work fine if everyone agrees with it (we can revert stuff from a developer if it breaks things but it's a pain) and believe in the release date, so we'd need everyone's agreements. So WDYT, are we ok to resume doing timeboxing and go back on track? On my side I'm ok to do it and help enforce it. If we agree we should start now by releasing RC1 ASAP and give a new date for 3.4 final and release on that date. Thanks -Vincent

13 years, 8 months

3
4
0 0

[xwiki-devs] [Vote] Release 3.4RC1 ASAP (today/tomorrow) ?

by Marius Dumitru Florea

Hi devs, What do you prefer: (1) Release 3.4RC1 today or tomorrow (depending on how much time it takes to fix the failing tests on CI and any blockers -- please list them) and release 3.4 final this Thursday, 19 January. (2) Release 3.4RC1 at the end of this week (Thursday/Friday) and release 3.4 final at the start of the next week, 23 January. I'm more for (2) because it would allow me to include some fixes to the AppWithinMinutes that I couldn't do in 3.4M1 because I was busy with fixing failing tests on CI, doing the actual release and writing the release notes. Thanks, Marius

13 years, 8 months

3
5
0 0

[xwiki-devs] List of users property in a class within a workspace

by Ido Meshi

13 years, 8 months

1
0
0 0

[xwiki-devs] Fwd: Happy to announce the creation of XWiki Clams Core + XClams Wiki

by Ludovic Dubost

News on XWiki CLAMS (Curriki) ---------- Forwarded message ---------- From: Ludovic Dubost <ludovic(a)xwiki.com> Date: 2012/1/14 Subject: Happy to announce the creation of XWiki Clams Core + XClams Wiki To: xclams-devs(a)xwiki.org Hi, I'm happy to announce that the migration process from SVN to GitHub and creation of the XClams and Curriki.org project went very well. We know have: https://github.com/xwiki-contrib/xwiki-clams-core with the curriki-2.0, curriki-2.1 and the master branch https://github.com/xwiki-contrib/currikiorg with the curriki 1.8 and older branches The Sankore source code will come soon We also have: A brand new Wiki: http://xclams.xwiki.org with more information about the project, the community and the committers I've also published the current velocity APIs in the current xwiki-clams-core: http://xclams.xwiki.org/xwiki/bin/view/Design/XClamsVelocityAPIsV22 The next steps are: - the publishing of the Sankore Source Code - changing the jenkins build to the GitHub source - bringing back many patches from Sankore into xwiki-clams-core - create the xwiki-clams-demo project with clean default data for a XClams based project - bring back Curriki.org on the master branch Thanks a lot to Sergiu for his help Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

13 years, 8 months

1
0
0 0

[xwiki-devs] XCLAMS mailing list on markmail

by Ludovic Dubost

Hi, The migration of Curriki to XClams is progressing. Thanks to Sergiu we now have the xclams-core and currikiorg projects on GitHub. Thanks Sergiu. I'm currently working on preparing xclams.xwiki.org. While doing that, I think it would be nice to archive the xclams-dev mailing list on markmail and nabble. I'm not sure how to do that. I'm sure Vincent can help ? Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

13 years, 8 months

1
0
0 0

[xwiki-devs] XWiki Enterprise and XWiki Enterprise Manager 3.4 Milestone 1 Released

by Marius Dumitru Florea

The XWiki development team is proud to announce the availability of XWiki Commons, XWiki Rendering, XWiki Platform, XWiki Enterprise and XWiki Enterprise Manager 3.4 Milestone 1. This is the first and only milestone of the 3.4 version. We're getting closer to the end of the 3.x cycle and the goal of this release (and the following one, which will be the last of the cycle) is to improve the current features. The highlights of this release are: * New default color theme * XWiki 2.1 is the default page syntax * Delete space menu * Simple space templates * Special characters in attachment name * Minimized action menu * Display macro * Improved Extension Manager UI See the full release notes at http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterpris… for more details. Thanks -The XWiki dev team

13 years, 8 months

1
0
0 0

[xwiki-devs] Get current space [velocity]

by Hamster

This should be easy, but I am stuck :-( I have created a new panel. The panel shows all the document in the current space. But if the user is in the Main Space, I don't want to show any documents, I want to show all the spaces (except for a couple default spaces). #if $currentSpace = "Main" #set ($hiddenSpaces = ["AnnotationCode", "ColorThemes", "Invitation", "Panels", "Scheduler", "Stats", "XWiki"]) #set($spacesSorted=$xwiki.sort($xwiki.spaces) ) #foreach($space in $spacesSorted) #if (!$hiddenSpaces.contains($space)) * [[$space>>${space}.WebHome]] #end #end #else // Code which shows all documents #end How do I know when I am in the Main Space? -- View this message in context: http://xwiki.475771.n2.nabble.com/Get-current-space-velocity-tp7183403p7183… Sent from the XWiki- Dev mailing list archive at Nabble.com.

13 years, 8 months

3
2
0 0

[xwiki-devs] [VOTE] Remove existing deprecated ColorThemes and replaced them with new ones for XE 3.4

by Ecaterina Moraru (Valica)

Hi devs, Since the recent Skin/ColorThemes changes done for XE 3.4, the existing ColorThemes are deprecated. I propose to remove them from our standard distribution and replace them with some themes created specially for the new skin changes. You can see these 3 new colorthemes (Ruby, Dusk, Mint) at: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/34NewColorThemes (clicking on the preview image you can see them in action) obs. I created a ColorTheme for every color we have in XWiki logo (blue, orange, red, green) The deprecated ColorThemes will still be available in the extensions repository: Default http://extensions.xwiki.org/xwiki/bin/view/Extension/Default33+ColorTheme Bordo http://extensions.xwiki.org/xwiki/bin/view/Extension/Bordo+ColorTheme Nature http://extensions.xwiki.org/xwiki/bin/view/Extension/Nature+ColorTheme BlueSky http://extensions.xwiki.org/xwiki/bin/view/Extension/BlueSky+ColorTheme Inner Dark http://extensions.xwiki.org/xwiki/bin/view/Extension/Inner+Dark+ColorTheme Nightfall http://extensions.xwiki.org/xwiki/bin/view/Extension/Nightfall+ColorTheme Peach http://extensions.xwiki.org/xwiki/bin/view/Extension/Peach+ColorTheme This is my +1 Pull request at https://github.com/xwiki/xwiki-enterprise/pull/14 waiting for the vote result and will be committed for 3.4 RC1. Thanks, Caty

13 years, 8 months

11
11
0 0

[xwiki-devs] [VOTE] Change document id stored in the database to reduce the likelihood of duplicate id

by Denis Gervalle

Now that the database migration mechanism has been improved, I would like to go ahead with my patch to improve document ids. Currently, ids are simple string hashcode of a locally serialized document reference, including the language for translated documents. The likelihood of having duplicates with the string hashing algorithm of java is really high. What I propose is: 1) use an MD5 hashing which is particularly good at distributing. 2) truncate the hash to the first 64bits, since the XWD_ID column is a 64bit long. 3) use a better string representation as the source of hashing Based on previous discussion, point 1) and 2) has already been agreed, and this vote is in particular about the string used for 3). I propose it in 2 steps: 1) before locale are fully supported in document reference, use this format: <lengthOfLastSpaceName>:<lastSpaceName><lengthOfDocumentName>:<documentName><lengthOfLanguage>:<language> where language would be an empty string for the default document, so it would look like 7:mySpace5:myDoc0: and its french translation could be 7:mySpace5:myDoc2:fr 2) when locale are included in reference, we will replace the implementation by a reference serializer that would produce the same kind of representation, but that will include all spaces (not only the last one), to be prepared for the future. While doing so, I also propose to fix the cache key issue by using the same reference, but prefixed by <lengthOfWikiName>:<wikiName>, so the previous examples will have the following key in the document cache: 5:xwiki7:mySpace5:myDoc0: and 5:xwiki7:mySpace5:myDoc2:fr Using such a key (compared to the usual serialization) has the following advantages: - ensure uniqueness of the reference without requiring a complex escaping algorithm, which is unneeded here. - potentially reversible - faster than the usual serialization - support language - independent of the current serialization that may evolved independently, so it will be stable over time which is really important when it is used as a base for the hashing algorithm used for document ids stored in the database. I would like to introduce this as early as possible, which means has soon has we are confident with the migration mechanism recently introduced. Since the migration of ids will convert 32bits hashes into 64bits ones, the risk of collision is really low, and to be careful, I have written a migration algorithm that would support such collision (unless it cause a circular reference collision, but this is really unexpected). However, changing ids again later, if we change our mind, will be really more risky and the migration difficult to implements, so it is really important that we agree on the way we compute these ids, once for all. Here is my +1, -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

13 years, 8 months

7
12
0 0

[xwiki-devs] [VOTE] New {{display}} macro and changes to the {{include}} macro

by Vincent Massol

Hi devs, As you know in XE 3.0 we've changed the behavior for resolving local links/attachments when they're included using the {{include}} macro (they're now resolved against the included document instead of the including document). Now there might be some use cases (pretty rare IMO but they exist) where you'd want the links to be resolved against the including document. Here's a use case: you have a sheet document that references an image called image.png and you want that the including document provides it (like an Abstract in Java! ;)). So we've brainstormed with Thomas and here's our proposal: * Introduce a new {{display reference="…"/}} macro. This macro will *execute* the passed reference in its own context (it'll do what {{include context="new"…}} was doing before). It'll be located in the new display module. * Deprecate the "context" parameter of the {{include}} macro. The reason is that calling with context=new is not an include, it's a display. * Add a new "resolve" parameter for the {{include}} macro with possible values = "current" | "source", with a default value of "source". resolve=source means that the links/attachments are resolved against the source (ie the document being included). Using resolve=current means that you want the links/attachments resolved against the including document. Pros: * Clearly separate the 2 use cases: display and include * Make the include macro simple (a single "resolve" parameter) * Use the new display module as it should be and start the direction of having displayer macros for displaying all types of entities Note: In the future we'll also want to deprecate the "document" parameter of the include macro in favor of a more generic "reference" parameter, which will allow the macro to include other types of entities (such as an object property for ex). WDYT? Here's my +1 Thanks -Vincent

13 years, 8 months

8
28
0 0

[xwiki-devs] CI status before 3.4M1 release

by Marius Dumitru Florea

Hi devs, I'd like to release 3.4M1 tomorrow morning (EET) but there are still failing tests on CI: * xwiki-enterprise-test-extension : ExtensionsAdminPage was not synchronized with the latest changes to the Extension Manager UI. It expects an "Extensions" administration section, which was (I guess) replaced in the mean time with three different administration sections. Sergiu or Thomas should take care of this, otherwise I'll exclude the test. * xwiki-enterprise-test-ui : Sergiu, please update TemplateProviderInlinePage and CreatePageTest due to XWIKI-7358 (Add support for simple space templates). * xwiki-enterprise-test-wysiwyg : A test is failing because when you go to an unexisting page (/bin/view/Space/UnexistingPage) the link to create that page doesn't lead to edit mode but to a strange "create" mode, which has only a button to create the page. Sergiu, I think this is related to XWIKI-7358. Can you take care of it? * there is one App Within Minutes test failing on CI which I can't reproduce locally. I'm taking care of this. Thanks, Marius

13 years, 8 months

1
0
0 0

[xwiki-devs] Fwd: Configuring the webhome page of main space?

by mohit gupta

Hi Folks, I would really appreciate even if somebody can provides the pointers about below queries. Thanks and Regards Mohit Gupta ---------- Forwarded message ---------- From: mohit gupta <motgupta(a)gmail.com> Date: Thu, Jan 5, 2012 at 4:01 PM Subject: Configuring the webhome page of main space? To: XWiki Users <users(a)xwiki.org> Hi All, I want to configure the default home page i.e webhome page of main space. I am looking for these kind of customizations:- 1) Replacing *Welcome to your wiki *with Welome to *ApplicationName Wiki.*Though i can see the ways to customize the panel bars,browser title bar text but not the text. 2) Right now, on web home page under main space i can see see all the details(like what activity admin or any other users did . For example modification in existing page or creation of new page) on page just after login (i.e webhome page on main space). i want to hide these unnecessary details from specific group users? Is it possible to customize. i am not even able to find the vm file for this page so that i can do some tweaking in code?

13 years, 8 months

3
6
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