Xwiki developers,
Our company develops wikis. We set up the core wiki, and then write extensions to add specific tools depending on the subject of the wiki . All of our wikis have been developed with the MediaWiki platform, which is written in PHP and prefers the mySQL database. We need to convert over to a Java and Oracle solution; XWiki is a contender for us.
To help us decide on xWiki, Do you mind answering a few questions for us such as the following?
1. One advantage of wikis for us is the revision history, fast creation of content, media uploads, and the user management. Are these things solved well with xwiki?
2. We need to add some custom tables to the wiki database and then save to those tables from a page form. Is that possible?
3. We need to develop forms for particular categories. The fields within the forms will be saved to your tables and our custom tables. Is this possible?
4. It looks like xWiki has components. We are just starting to experiment with your components. Are they helpful with your product?
5. Do you have hooks in the code or other possibilities to extend code without changing it?
6. Is it possible to change core code?
User mark up differences between your xWiki and mediaWiki is not a big factor for us.
Thanks,
Mary
Hi,
I am creating an HTML form which should redirect a user to an UNC folder
after they have clicked on a button.
I got everything setup, but the $response.sendRedirect($folder) doesn't open
the folder.
If I just put $folder on the page, it shows the UNC-path (and when I click
that link, it takes me to that folder)
So I know that the link $folder is correct...but how can I open that folder
automaticly?
Should I be using redirect or something else?
--
View this message in context: http://xwiki.475771.n2.nabble.com/HTML-form-which-redirects-user-to-UNC-fol…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi devs,
This is an _alternative_ proposal to what is currently implemented in our
Solr Search. For the current implementation there is another proposal [1]
that is already partially integrated.
The current Solr implementation is focused on Facets search. This means
that not all possible filters are revealed, but just those that match the
current query, letting the user narrow the results.
This alternative proposal will display all the possible filters and will
let the user make his own selections instead of auto-selecting for him.
This proposal is inspired from JIRA's filters.
Although being able to customize and to refine the filters to exactly what
you need will be great for developers and advanced users, please keep in
mind that normal users will be more comfortable with the faceted search
since it's more 'standard' in the wild (in the e-commerce and
product-related websites). Advanced user know exactly what they want in
comparison with normal users that rely on the first 3 results.
You can see a screenshot at
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/SearchProposal…
and read the whole proposal at
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/SearchProposal3
Thanks,
Caty
[1] http://xwiki.markmail.org/thread/du4dknibbgxx6pdn
The XWiki development team is proud to announce the availability of XWiki 5.0.2.
This is a bugfix release for the 5.0.x cycle. The blocking bugs that
leaded to this release are about PostgreSQL support and new multiwiki
behavior.
You can download it here:
http://www.xwiki.org/xwiki/bin/view/Main/Download (please allow a few
hours for the binaries to propagate to the download servers if the
download doesn't work yet)
Make sure to review the release notes:
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki502
Thanks
-The XWiki dev team
Hi everyone,
Today is BFD22. Our goal is still to have more bugs closed than created for the past 1000 days!
http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352
Some stats:
- BFD 19: 53 bugs behind before it started
- BFD 20: 36 bugs behind before it started
- BFD 21: 39 bugs behind before it started
- BFD 22: 20 bugs behind, so we're catching up!
Let's try to close the gap during this BFD.
Here's the BFD#22 dashboard to follow the progress during the day:
http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11593
Let's close the gap, we could even close it today if we're good enough!
Thanks
-Vincent
The XWiki development team is proud to announce the availability of
XWiki 4.5.4.
This is a bugfix release for the 4.5.x cycle, hopefully the last on the
4.x cycle. Affected areas include the distribution wizard and the
extension manager, Internet Explorer compatibility, Oracle and
PostgreSQL compatibility, and multiwiki improvements.
You can download it here:
http://www.xwiki.org/xwiki/bin/view/Main/Download (please allow a few
hours for the binaries to propagate to the download servers if the
download doesn't work yet)
Make sure to review the release notes:
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki453
Thanks
-The XWiki dev team
Hi devs,
XWiki 5.1 Milestone 1 is going to be released the next Monday. We'll go
through the list of bugs fixed for 5.1 M1 and try to validate as many as we
can. Besides those, do you want us to test some specific issues or features
?
Thank you,
Manuel
Hi devs,
This is our 21st BFD!
Here's the jira dashboard:
http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11591
Our status before we start it (on 1000 days):
- 2337 created
- 2298 resolved
=> 39 behind
Some stats:
- BFD 19: 53 bugs behind before it started
- BFD 20: 36 bugs behind before it started
So we "lost" 3 bugs during the week, not that bad considering lots of issues where open. I've seen Marius close quite a few this week, thanks for that Marius! :)
Ok let's try to win some bugs so that during the next BFD we're at less than 39!
Have a good BFD today!
-Vincent
Hi,
I've just built two packages for archlinux, one concerning
xwiki-enterprise, the other xwiki-manager.
To install xwiki :
yaourt -S xwiki-enterprise
or
yaourt -S xwiki-manager
Packages are here :
https://aur.archlinux.org/packages/xwiki-enterprise/
and here :
https://aur.archlinux.org/packages/xwiki-manager/
What about creating a repository for them on xwiki-contrib, for example :
archlinux-packages ?
If someone create the repo, I'll upload files tomorrow.
--
Frédéric Bouquet
Twitter/Github : bouquetf
http://www.espacedefouille.org/
Hello,
I know XWiki 5.0.2 is scheduled to be released within the next days. I
noticed there's no Release Notes page for it on xwiki.org. Besides the
usual list of issues fixed for it do you want some other features tested as
well ?
Thanks,
Remus :)
FTR I've just documented the Unstable annotation here:
* http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#H40Unsta…
* http://platform.xwiki.org/xwiki/bin/view/DevGuide/API
Note that I'm not especially fond/proud of the max time strategy we have since it can lead to APIs staying for 2 years but at least it makes it easy to implement by checking for @unstable before each "N Milestone 1" release.
Another option would be to automate the check in a Maven plugin (by reading annotation and then reading @since javadoc tag) and keep @unstable code only for , say, 6 major releases (which corresponds to 1 cycle length).
Thanks
-Vincent
I'm going to perform the following rename.
XWiki.SolrSearchAdmin -> Solr.Administration
Main.SolrSearch -> Solr.WebHome
and I'm going to add Solr.Translations .
Let me know if you think this is a bad move,
Marius
Hi devs,
Now that the virtual mode is on by default our users are having troubles when they install 5.0.1.
It's the second time in 2 days that I have to help someone.
The issue is that users will want to use URLs such:
http://myhost/xwiki/bin/view/Main/WebHome
And those URLs don't work anymore by default (which can be seen as a regression).
So I'm proposing the following change for 5.0.2/5.1M1:
* If there's only 1 wiki configured then always point to the main wiki.
WDYT?
We need to make it easy again to use XWiki initially.
Thanks
-Vincent
Hello GSoC Mentors,
As you are participating to Google Summer of Code, I'm wondering if you
could consider using Flower Dev Center [1] while working with students.
Flower Dev Center is an online platform for UML modeling diagramming,
with a strong focus on code synchronization, integration with dev tools
(Git, SVN, etc) and real time collaboration on diagrams (and a little
bit on code as well).
We think Flower Dev Center can be helpful for both: mentors and students
during Google Summer of Code. We have created an article on this topic
(i.e. Flower Dev Center + GSoC): [2], [3].
If you have a couple of spare minutes, could you tell us if you would
like to use Flower Dev Center? And/or raise topics that you think are
important (based on previous GSoC participations) to be supported by
Flower Dev Center?
REMARK1: Right now, Flower Dev Center is closed source and offered for
free to open-source projects. Starting with next version we'll begin to
open its API and source code, so that anyone could write extension
plugins, etc.
REMARK2: The next version of Flower Dev Center, the 2.0.0 planned for
June/July 2013, has major new features, that we did not demonstrate yet
and that will improve even more the collaboration between developers.
REMARK3: Flower Dev Center will support programming languages that are
not object oriented, starting with 2.0.0
Thank you in advance!
Best regards,
Mircea @ The Flower Platform Team.
[1] - Flower Dev Center web site - http://www.flower-platform.com
[2] - Video “Flower Dev Center + Google Summer of Code” -
http://learn-discuss.flower-platform.com/flower_dev_center/videos/flower_de…
[3] - Text version with same content as the above video -
http://learn-discuss.flower-platform.com/flower_dev_center/tutorials/flower…
Hi devs,
ATM the solution is described here: http://dev.xwiki.org/xwiki/bin/view/Community/Debugging#HDebuggingJavaScript
What would you think about doing this instead:
* Package both the minimized and the non minimized version in our WAR (it shouldn't add too much weight to our overall WAR size)
* Have a directory structure like this:
resources/.../<module>/
|_ <non minified js file here>
|_ min/<minified js files here>
* This would allow to put in our xwikivars.vm something like (pseudo code):
#if ("$!request.minify" == 'false')
#set ($jsDir = '/')
#else
#set ($jsDir = 'min/'
#end
* Then everywhere we reference JS files we use $jsDir. For example in attachmentsinline.vm:
$xwiki.jsfx.use('uicomponents/widgets/${jsDir}upload.js', {'forceSkinAction': true, 'language': ${xcontext.language}})
…
This would allow to remove the "debug" profile and make it much faster to debug XWiki issues, even in production systems.
WDYT?
Thanks
-Vincent
Hi,
We introduced in XWiki 4.3 a new experimental search based on Apache Solr
[A] .
Right now our Solr Search [B] is marked as experimental and I don't know
how many of you got a chance to play a bit with it.
In order for it to become default we need to make sure we are covering the
major use cases. So in this mail we should provide some feedback on what is
really needed from a relevance, user experience, performance, etc. point of
view.
I am very interested also in some general feedback on the Lucene Search:
major problems you had with it and limitations.
The following questions are mostly related to Solr Search:
1) The Solr implementation adds a 'Filtered Search'. Are all filters that
are available now needed (wiki, space, type, filetype)? Are we missing
some? What is the most important one? Should we have multiple select?
>From a technical point of view we could add a lot of things (object
properties, query boost, etc.) but I'm more interested, in production, what
are some advanced or common use cases of search usage. IMO our Lucene
implementation is too simplistic, but it would be a shame to add useless
complexity to the Solr one if we really don't need it. On the other hand
having a customizable search is a really nice thing.
The customization part is kind of complex, but also the most powerful. I
want to know how much would we need the ability to explicitly mention the
types of results we want vs. excluding things, etc.
2) The Solr search adds a 'Sort' feature. What do you think about that?
3) Search result metadatas: should we display the relevance? What other
information should be displayed besides name, location, type?
4) Other mentions.
Having a generic search is more complex, than knowing exactly what your
search needs to return. We need to make sure we don't add too many niche
things while keeping the functionality satisfiable for general use cases.
Thanks,
Caty
---------------
[A]
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki43#HExper…
[B]
http://extensions.xwiki.org/xwiki/bin/view/Extension/Solr+Search+Application
Hello all,
I've been working on some improvements on user changing password (see
XWiki-6882). In particular, I tried to make mandatory, for an user wanting
to change his password, to submit also his current password, so that I
could check it.
The problem is that there is no way to make this check through velocity. I
tried to use some groovy instead, but it breaks the functional tests. So I
need to introduce a new method "checkPassword" accessible from velocity
scripts. The question is, where should I implement it ?
There are two possibilities
1) Wrote a new component
2) Add this method in an existing API.
I don't really like 1), as I feel it would be strange to introduce a new
service with only one method.
In the meanwhile, for 2), I don't really know in which API this method
could fit. Sergiu told me that I could perhaps put it in
com.xpn.xwiki.plugin.rightsmanager.RightsManagerPluginApi,
but that it wasn't really good either. Any ideas ?
Cheers,
Thomas
Hi all,
For security reasons, I would like to be able to perform some rights
checking in the HTML macro (i.e I would like to forbid use of scripts to
untrusted users). But as the HTML macro is currently defined only in
xwiki-rendering, I can't do anything like that (xwiki-rendering should be
independent from the platform).
So, I would like to override the HTML macro in platform, in order to be
able to perform the security checks I want. Does this seems acceptable to
you ?
Thanks,
Thomas
Hi devs,
I'd like to copy all Document*Event in xwiki-platform-model/src/main/java/org/xwiki/model/event/* and deprecate (move to legacy) all the ones in the bridge module.
It seems they don't need XWikiContext, XWikiDocument or the like so it should be pretty easy.
WDYT?
Thanks
-Vincent