Download Form Feedback - 2016

 The migration works very badly that need to improve. More than 50% of pages are broken after migrated from 6.4 to 8.4

 More than one Wiki setup, in a easy way to handle.

 Most enterprises (and even smaller organizations) use some kind of directory service for user authentication and group management (e.g. OpenLDAP, Microsoft Active Directory, Samba). XWiki currently (to my knowledge) supports static mapping between local XWiki Groups and LDAP (security) groups based on Distinguished Name (dn). Maintaining lots of such groups quickly becomes tedious as LDAP groups are created, removed, renamed, and relocated. This has to be kept synchronized with the static configuration within XWiki and is prone to errors. I suggest some kind of automated mechanism for supporting external (security) groups with a configurable key of various data types. As an example, in Active Directory, a possible attribute to use is the "objectGUID" (https://msdn.microsoft.com/en-us/library/ms679021(v=vs.85).aspx) which is a 16-byte value, since it is the same during an object's entire life cycle. That way, role management within XWiki can be centrally managed using already existing tools, aligning management with already established business processes.

Answer from Thomas Mortagne (XWiki Core Dev):

 LDAP groups are not only LDAP DNs, you can also use LDAP filters and organization units. So in your case it would probably be something like XWiki.MyXWikiGroup=(objectGUID=someguid). See the examples in the xwiki.cfg file. 

 Your official xwiki side is for me the reference. I can see several useful UI components there which I do not know how to reuse/build in my xwiki project. I’d like to have some kind of “showroom” where we can see list of available components and example how to build it.

 I have recently tried your XWiki product with different deployment methods. In general XWiki works really well, quite easy to use, and the access to the source editing with XWiki syntax is powerful.
 - Installation: should be more stable (I couldn't install in on a Linux docker container, even though I tried all types of DEB packages
 - I haven't tried on a real Linux server). The Zip deployment on Windows works great though. Flexibity of choosing diffrent deployment methods is good, but if it's hard to keep all options work fine, I suggest only support Zip and WAR deployment, as these options should work for most normal usage scenarios.
 - UX/UI: Generally, UX is good, the onboarding tutorial is nice and very useful. UI is quite modern and looks nice compared to other wiki softwares. However, few things could be improved: The organization of the left menu could be simplified a bit. UI should have more consistent look and feel (now it is flat UI here, 3D there, font size varies from place to place, etc.) Would be nice to see it in 100% Bootstrap 3. Also, the default formatting for tables could be improved. Comming from Confluence I miss the way they treat tables (and the whole editor in general): that is some kind of common sense that made table look/work good enough yet simple enough for almost all kind of uses. So when using XWiki I always add a simple grey background to all table header columns/rows (but it took a little bit of learning the xwiki syntax). And I still prefer the UI for creating table on Confluence.
 - Security: for the on-premise delployment package, please don't use a default password for Admin, that's a very bad security practice (a lot of people will forget to change that password, see more here: https://www.owasp.org/index.php/Top_10_2013-A5-Security_Misconfiguration), I suggest dynamically generating amdin password when xwiki starts the first time, then print it out in the console or a local file, then force user to change it when they first log in.

 Instead of refreshing the entire page as I navigate it would be nice if only the body of the page refreshed and the navigation stay static (unless I add a new page of course.)
 I am quite happy with XWiki.  Thanks for reaching out to me.

 Richer right management, better debugging of wiki pages
 Xwiki is the best wiki I tried until now !

 On Xwiki8.2.1,  link function of ckeditor doesn't work well.  There is no setting in ckeditor link dialog about setting target="_blank".  I feel it is better to use Xwiki7.4.x with ckeditor Extension & customize application-ckeditor-webjar-1.3.x.jar to full functional ckeditor.   My main reason to use  ckeditor is  to avoid wiki tag setting like ||target="_blank" .  Most of users want to use ckeditor Full function version, not want to use wikitag.
 functionality of ckeditor in Xwiki8.2.1 is so cheap and disappointed. I hope to use Full Functionality of ckeditor.

 Math Formula insertion function is desirable (like image insertion with mimetex.cgi etc)
 I'm very happy to use Xwiki, it's very powerful and useful ! I will change to Version 8.2.1 soon.

 Installation tool for the owne server.

 Provide more typed and strict API in Java
 Clean the API
 Provide simplified API allowing to manipulate the pages/objects like a graph
 Simplify reference serialization
 Allows to implement extension in Java directly in the wiki (like groovy extensions but allowing multiple files for the structure and linking jar to classpath)
 Improve the documentation a lot

 Easily customizable Horizontal Navbar, enabled by default (I still can't find how to do it).  Update the Linux (Debian) installation instructions.  I had a very difficult time installing on Ubuntu 16.xx and could not install at all on Ubuntu 14.04 LTS.
 Enable changing the color theme depending on Wiki to make it a little more obvious what "Wiki" you are viewing at the moment.  I'm sure this is possible.  Perhaps I just don't understand it.

 Simplify the view. less button and better locations. use a toolbar on the top of the page (like confluence)
 Good project. I'm looking if it can fit to build a portal. I think yes. Confluence wiki is really easier to begin a knowledge base with non-IT people.

 I want to use ckEditor with full functionality (i.e. full menu button), I hope it will be implemented in the following version of Xwiki ! I use mimetex.cgi to write math-formula, so Image insertion by url is preferrable.
 I can't do my task without Xwiki now. I thank you all. 

 Improve documentation (is somewhat outdated in some areas)

 Hi everyone,

Before I send my feedback I have to say that english is not my first language, so I apologize for my english.

I'm new using XWiki and I'm having a problem when I try to customize any color theme. When I choose an existing color theme and try to customize it, the theme editor saves the changes but it never applies it to my XWiki. But, when I create a color theme with the configuration I want, the theme editor saves it correctly and applies it to my XWiki, this is OK, the problem comes when I want to change anything in the theme I created because it make the same thing I first say (Save the changes but don't apply them).

I hope I made myself clear.

Thank you for reading and please help me to solve this problem.

Cheers.

 Better documentation would do you a lot of good. You should also consider archiving all information related to older releases. You still have Version 2 documentation when you are at Version 8. It would make it much easier to update, read and learn from your documentation if is was limited to just the latest and greatest or at least the LTS release.

 To be able to group tags for a group of pages and not all at the same place mixed up

 Happy with the product, I wish that the upgrade process was simpler, like a  one click installer like wordpress or joomla

 I would like to be able to paste an image into the wiki directly from the clipboard. Maybe that can be done, but I didn't find the extension that would allow that. I would not mind if the paste created an attachment, possibly asking me the name I want to give it. Currently, I have to paste into gimp or paint, save as a file, upload the file and then reference the attachment in the page so it will show.

 That brings up another point. Finding an extension that does what you want is difficult, and most extensions lack screen sample to show you what they do.

 More role based read/write access. There are pages we would like to limit update capability to a specific group of individuals, and even readability to to a group, and some open to everyone. We would like to be able to define the roles based on information found in AD.