xwiki-devs July 2016

xwiki-devs@xwiki.org

17 participants
39 discussions

[xwiki-devs] [contrib][android-authenticator] Release of An Alpha Testing Version

by fitz

Hi Dear Everyone, I've finished most of the functions for the android-authenticator GSoC2016 project and made some documents. User Guide: http://extensions.xwiki.org/xwiki/bin/view/Extension/Android+authenticator Design: http://design.xwiki.org/xwiki/bin/view/Proposal/AndroidAuthenticator GSoC2016 Progress: http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Androidcontact2016 Also I have released an alpha version in google play store. You can join the testing program, download and install the app. Follow this link to help me test and improve: https://play.google.com/apps/testing/org.xwiki.android.authenticator . If you have any question, please feel free to ask. or just comment on the above pages or create issues in Jira. Thank you in advance. Thanks, Fitz -- View this message in context: http://xwiki.475771.n2.nabble.com/contrib-android-authenticator-Release-of-… Sent from the XWiki- Dev mailing list archive at Nabble.com.

8 years

[xwiki-devs] [ANN] XWiki 8.2.1 released

by Ecaterina Moraru (Valica)

The XWiki development team is proud to announce the availability of XWiki 8.2.1. This is a bugfix release that fixes important bugs discovered in the 8.2 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/ReleaseNotesXWiki821/ Thanks for your support -The XWiki dev team

8 years, 1 month

Re: [xwiki-devs] [Discussion] Committing date changes on document XML files

by Thomas Mortagne

Le 25 juil. 2016 18:31, "Vincent Massol" <vincent(a)massol.net> a écrit : > > > > On 25 Jul 2016, at 18:20, Eduard Moraru <enygma2002(a)gmail.com> wrote: > > > > Hi, > > > > On Mon, Jul 25, 2016 at 6:46 PM, Vincent Massol <vincent(a)massol.net> wrote: > > > >> I think I’d be in favor of: > >> * Have our xar:format remove the dates > >> * Have xar:verify fail if the dates are in the XML (thus our quality build > >> will fail if that’s the case) > >> * Have the import set the current date if no dates are defined (that’s > >> probably the case already, would need to be checked) > >> > > > > A side-effect of this is that, when you upgrade and extension, all the > > pages of the extension will be changed and set to the update date as their > > last modification dates, right? (i.e. it affects both fresh installs and > > upgrades) > > Isn’t this what happens now already, i.e. when an existing page is imported the current date is set (unless it’s a backup pack)? Yes EM does not take into account plumbing stuff like date and version. > > If the issue is about the diff, I guess we could have a diff that doesn’t take into account the dates (or a better algorithm could be to not update a page that only has the date metadata modified). It's already the case... > > > Thinking more about it, it could be problematic for all the pages of an > > extension that you upgrade to appear as being modified, even if nothing > > changed in them in that particular version. > > We should definitely not update pages with no changes. > > > Another minor negative side-effect would also be searching or listing > > documents and sorting them by the last update time. Of course, this would > > mostly affect admins or users with "show hidden documents" enabled. > > I we don’t update pages that haven’t been changed we won’t have this problem, right? > > > However, if you happen to also manage some content pages in your build > > (that are not supposed to be hidden), this becomes a nuissance. > > > > WDYT about the 2 problems? I guess we could always accept them and say that > > installs/upgrades are relatively rare and that the impact is minimal (and > > similar to an empty save in a document - something that can already be > > observed in practice in a document's history - so we don`t introduce > > anything new). > > > > Thanks, > > Eduard > > > > P.S.: Here`s an existing issue more or less related to this topic > > http://jira.xwiki.org/browse/XWIKI-7058. Caty reminded me about it. > > And http://jira.xwiki.org/browse/XWIKI-11764 > > Thanks > -Vincent > > > * Have AS and Watchlist exclude import / new wiki (already the case) > >> > >> Thanks > >> -Vincent > >> > >>> On 25 Jul 2016, at 14:08, Eduard Moraru <enygma2002(a)gmail.com> wrote: > >>> > >>> Hi, devs, > >>> > >>> This interesting discussion [1] came up recently on a github commit that > >>> lead us to realise that a practice which we have been doing since forever > >>> is not documented in our best practices guides and that we also seem to > >>> lack consensus on it. > >>> > >>> It`s about the practice of skipping date field changes from document XML > >>> pages when committing them to source control. This includes doc date > >>> and contentUpdateDate > >>> fields, but also attachment dates. > >>> > >>> You can see some arguments on the discussion[1], but I also wanted to > >>> mention that this practice goes in line with what we do for document > >>> versions (which is handled by the xar:format maven plugin goal which we > >>> execute every time, before committing XML pages). If we are to update doc > >>> dates, then we should also increment doc versions, otherwise it does not > >>> make any sense. > >>> > >>> The idea was, AFAIR, that XWIki`s code pages should not generate any > >>> updates in the user`s wiki content, in any way, and that and update of > >> the > >>> code of a "system"/XWiki page should not show up as an update of *the > >>> user's content*, since it would otherwise confuse him. > >>> > >>> What we are currently missing from xar:format is exactly this: the reset > >> of > >>> XML page dates to have a clearer and more consistent date for XWiki`s > >> code > >>> pages. > >>> > >>> Your input is appreciated and the result of this discussion would be the > >>> update of our Development Practices [2] and Application Development Best > >>> Practices [3] pages. > >>> > >>> Thanks, > >>> Eduard > >>> > >>> ---------- > >>> [1] > >>> > >> https://github.com/xwiki/xwiki-platform/commit/1938dd18e1d25b8c03e4cb222862… > >>> [2] http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices > >>> [3] > >>> > >> http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPra… > >>> _______________________________________________ > >>> devs mailing list > >>> devs(a)xwiki.org > >>> http://lists.xwiki.org/mailman/listinfo/devs > >> > >> _______________________________________________ > >> devs mailing list > >> devs(a)xwiki.org > >> http://lists.xwiki.org/mailman/listinfo/devs > >> > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs

8 years, 1 month

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

by Alexandru Cotiuga

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

8 years, 1 month

[xwiki-devs] [ANN] XWiki 8.2 released

by Ecaterina Moraru (Valica)

The XWiki development team is proud to announce the availability of XWiki 8.2. This release integrates CKEditor as the default WYSIWYG content editor. It also features a redesigned default homepage, a tour on the homepage to describe the XWiki user interface to newcomers, new default templates, a new application index in the drawer and a new administration UI to help manage available syntaxes. There are also minor improvements to the template providers, the Flamingo skin and Ratings. For developers, we have Livetable macro improvements and a long overdue change of behavior for the getRenderedContent() method. 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/ReleaseNotesXWiki82 Thanks for your support -The XWiki dev team

8 years, 1 month

[xwiki-devs] [Discussion] Committing date changes on document XML files

by Eduard Moraru

Hi, devs, This interesting discussion [1] came up recently on a github commit that lead us to realise that a practice which we have been doing since forever is not documented in our best practices guides and that we also seem to lack consensus on it. It`s about the practice of skipping date field changes from document XML pages when committing them to source control. This includes doc date and contentUpdateDate fields, but also attachment dates. You can see some arguments on the discussion[1], but I also wanted to mention that this practice goes in line with what we do for document versions (which is handled by the xar:format maven plugin goal which we execute every time, before committing XML pages). If we are to update doc dates, then we should also increment doc versions, otherwise it does not make any sense. The idea was, AFAIR, that XWIki`s code pages should not generate any updates in the user`s wiki content, in any way, and that and update of the code of a "system"/XWiki page should not show up as an update of *the user's content*, since it would otherwise confuse him. What we are currently missing from xar:format is exactly this: the reset of XML page dates to have a clearer and more consistent date for XWiki`s code pages. Your input is appreciated and the result of this discussion would be the update of our Development Practices [2] and Application Development Best Practices [3] pages. Thanks, Eduard ---------- [1] https://github.com/xwiki/xwiki-platform/commit/1938dd18e1d25b8c03e4cb222862… [2] http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices [3] http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPra…

8 years, 1 month

[xwiki-devs] [UX][Vote] Content Templates by default

by Ecaterina Moraru (Valica)

Hi, By default there are not many page templates an user could see. In order for users to understand the power and purpose of XWiki, it would be helpful to add more content templates by default. Content Templates are templates that don't belong to a particular application, but provides an initial content structure. The templates will be suggested in the creation step. Here are some templates we could add by default: http://design.xwiki.org/xwiki/bin/view/Proposal/TemplatesDefault#HProposal 1. Article 2. Encyclopedia 3. Meeting 4. Simple Page You can test them on http://design.xwiki.org/xwiki/bin/view/Proposal/TemplatesDefault/ (use the Create button) Please vote if you agree these templates should be added by default or otherwise let me know your feedback. Thanks, Caty

8 years, 1 month

[xwiki-devs] [Contrib] Request repository for "application-templates"

by Ecaterina Moraru (Valica)

Hello devs, I want to publish a collection of templates that can be used in the Creation step. They will be content templates that provide a certain structure for pages, depending on the use case, making it faster for users to follow a certain layout standard. Initially it would contain Article, Encyclopedia, Meeting Report and Simple Page. I would need: - a repository on xwiki-contrib called "application-templates" - a JIRA project called "TEMPLATES" - no e.x.o page yet - username: evalica Thanks, Caty

8 years, 1 month

[xwiki-devs] Convention for class property hints ?

by Jerome Velociter

Hello, Right now class property hints are not supported right in the core of XWiki (though it's been mentioned as a possible future item of the roadmap for AWM, see http://markmail.org/message/ltuphlj7bnnso2yb ). Once this will be implemented, it will rely on i18n message keys so that hints are localizables (same strategy as for class property pretty names) I'd like to start the discussion and see if we can agree on a convention that would be used in the future when this module is implemented. The reason for this is I'm starting to work on a LDAP admin UI, and I find that their field pretty names are not self-explanatory. It's not a matter of expression, it's just the fact that what they describe needs more explanation than what the pretty name can offer). In this light, I'm planning on displaying such longer hints in this admin section. Right now the format for a pretty name is : Space.Class_property=Pretty name The format for a hint could be something like : Space.Class_property.xHint=Hint This would need escaping rules I think, since I believe "property.xHint" is a valid property name Note that I use "xHint" and not "hint" to be consistent with the form standards class names. This can be discussed though. WDYT ? Do you have other ideas ? Jerome. -- Jérôme Velociter Winesquare http://www.winesquare.net/

8 years, 1 month

[xwiki-devs] [VOTE] Use {{html clean="false"}} as a best practice when developing applications

by Marius Dumitru Florea

Hi devs, I'd like to propose that we use, from now on, {{html clean="false"}} when developing applications, because: * HTML cleaning is an extra step that can increase page loading time * the HTML cleaner can have bugs (like any other code) or unexpected behaviour (like removing some elements or some attributes when you don't expect it) * when I make a mistake in my HTML code I'd like to detect it as soon as possible, instead of letting the cleaner silently "fix" it for me. Note that we would still have the webstandards validation tests as a safety net (only for the default distribution though) We should keep clean=true by default because we don't want the XWiki users to break the XWiki UI too easily when they copy some HTML from the web and paste it inside the HTML macro. Here's my +1 WDYT? Thanks, Marius

8 years, 1 month

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs July 2016