The XWiki development team is proud to announce the availability of XWiki
9.7.
This release brings small improvements to currently established features.
The code viewer now provides a blame view by default and the notification
center now allows the user to enable or disable notifications globally on
an application, as well as toggling default notification filters provided
by the platform.
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/Data/XWiki/9.7/
Thanks for your support
-The XWiki dev team
The XWiki development team is proud to announce the availability of
XWiki 9.7RC1!
This release brings small improvements to currently established
features. The code viewer now provides a blame view by default and the
notification center now allows the user to enable or disable
notifications globally on an application, as well as toggling default
notification filters provided by the platform.
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/Data/XWiki/9.7RC1
Thanks for your support
-The XWiki dev team
Hi devs,
While thinking about what features a Technical Documentation Flavor [1]
should have, I came up with some ideas that we could integrate inside
xwiki.org in order to make it a better documentation website:
- navigation tree in the left panel, see
--
http://design.xwiki.org/xwiki/bin/download/Proposal/Flavors/TechnicalDocume…
compared to
-- http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Installation
- simpler skin (at least remove the comments area - lots of deprecated
questions/answers and we have now the forum for that)
- simpler menu (less entries + merge with the navbar if technical possible
now, otherwise wait for newer version)
- simpler footer area by removing the number of links displayed (we need to
look at mouseflow)
Would be great also to upgrade XWiki.org to a newer version.
There were all sorts of ideas in the past like:
- displaying 'Edit' also for unregistered in order to encourage edits
- display 'Register'/'Log-in' links in the navbar in order to encourage
edits
these are not part of the current proposal, but keep the ideas coming :) we
will try to implement them when we can.
Of course it would be great if we would had time to:
- update the docs content
- reorganize pages
- update the blog styling
- etc.
but I guess small changes will come in time.
Let me know what you think,
Caty
[1]
http://design.xwiki.org/xwiki/bin/view/Proposal/Flavors/TechnicalDocumentat…
Hi devs,
I’d like to raise a pain point.
Environment:
* myxwiki.org
* lescastcodeurs wiki
What happened:
* We upgraded myxwiki.org
* Emmanuel (an Admin user of the lescastcodeurs wiki) got the Distribution Wizard and followed it to upgrade the wiki
The problem:
* Several features are broken. For example AppWithinMinutes (some pages display red boxes saying that the last author didn’t have script rights)
The reason:
* Emmanuel was admin but didn’t have script rights (after some xwiki upgrade that caused existing users to not have script rights if not set explicitly)
* For ex on the AppWithinMinutes space: https://www.evernote.com/l/AHcaXGYEzdZJXLTQEy2Vbohcfzu5vMbxkBM
Brainstorming:
1) What should we do to not have this problem?
2) What solution do we offer to fix it easily?
Re 2) we have:
* http://extensions.xwiki.org/xwiki/bin/view/Extension/Change%20Content%20Aut…
* http://extensions.xwiki.org/xwiki/bin/view/Extension/Change%20creator%2C%20…
However none are good for me without changes since they either change all pages in the wiki (which is not what I want) or they change only a single page.
Any idea?
Thanks
-Vincent
Hi devs,
Problem
=======
We have 2 issues right now when installing an extension in XWiki:
1) It’s not clear where is the entry point of that extension.
- Example1: an app that is only for admins and only has a ConfigurableClass
- Example2: an app that provides a macro and doesn’t have a UI
2) Even when an extension registers itself in the Applications Panel, the user still need to refresh the page or navigate away to see it.
Proposal
========
* Introduce the concept of Entry point (a.k.a home page) in Extension metadata
* Have the EM UI display the extension’s entry point (when there’s one) after having installed the extension so that the user can click on it and be taken to the home page of the extension.
This would make extensions more discoverable IMO.
Implementation Details
==================
* Some maven extension metadata properties in pom.xml
* A format to represent an entry point. It shouldn’t be a full URL since that needs to be computed at runtime. Basically it should contain:
** The document reference
** The action to use (view, admin, etc) - optional, should default to “view"
** The query string to use - optional, should default to an empty query string
This corresponds to the notion of ResourceReference (EntityResourceReference to be precise). However we don’t have any textual representation of it ATM.
WDYT? Good idea? Bad idea?
Thanks
-Vincent
Hi all this is another update regarding the integration of Redpen, aka the
Content Checker extension. As of now, I have finally implemented
dictionary-based validators (validators that check for invalid or subpar
expressions). With this, most of the validators will be easily added within
the configurable class of the extension.
Feel free to check the design page for the UI implementation:
http://design.xwiki.org/xwiki/bin/view/Proposal/RedPenIntegration
<http://design.xwiki.org/xwiki/bin/view/Proposal/RedPenIntegration>
Also, the output of the document checks are currently registered in the
logs, and are separated into warnings and errors. The determination of
whether a particular validator setting gives a warning or an error is
registered in the xwiki.properties file. The automatic validation function
also cancels document saves when errors are registered by Redpen.
There are now two core milestones to be done on this extension. First and
critically, I would need to implement functional test, especially on the
Configurable classes. To this end, I would appreciate any advise on how I
can implement this (I have previously only created a functional test to test
the entry of expressions into the Dictionary part of the extension.)
After that, I would then implement the Job module of this extension. (The
Job will be accessible in another tab, 'Job', below the current Dictionary
tab in the Administration UI panel.)
I would greatly appreciate any advice on what else needs to be added
regarding the Content Checker functionality, and with the implementation of
functional tests. Thank you!
--
View this message in context: http://xwiki.475771.n2.nabble.com/GSOC-Update-5-Redpen-Integration-tp760438…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Greetings everyone!
I’m pleased to announce the second milestone of the Dokuwiki importer.
The additions are :
> Support for a wide range of archives in the input.
> DokuWiki Syntax parser supporting full grammar.
You can find it here: http://extensions.xwiki.org/xwiki/bin/view/Extension/DokuWiki/
Please feel free to experiment, and report any bug that you encounter.
Cheers!
Shubham