If we can agree on some key facts I’ll happily search for german pages and try to update them.
I’ll try to extract as much as possible from sites you mentioned above, yet the wiki comparison mentions a GWT based editor (under Features 2), which puzzles me, I thought you were “full CKEditor” now?
That’s correct, the pages were not up to date. I’ve fixed all places where I could notice GWT. Let me know (or edit them) if you see other places.
Awesome!
There are several topics here:
Let me try to reply with the thoughts it evokes in me so that we can try to find what we can do about it.
Actually that’s not fully correct. There’s only a single document listing all steps you have to perform for the WAR install (I assume this is the one you’re referring to): http://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Installation/InstallationWAR/
Ofc we can’t guess what servlet container or what DB the user wants to use so the user has to click on the right link but they’re all listed.
7 servlet containers on 8 databases that’s 56 combinations 
Now the reality is that the majority of users will want Tomcat and MySQL (see http://www.xwiki.org/xwiki/bin/view/ActiveInstalls/).
Do you really believe that the issue is that you need to click on links in the current documentation?
What we could do but I’m really not sure it’s worth the cost would be to develop a small app for this. Looks overkill to me. WDYT?
Regarding installation, I think that one potential issue is that users will jump to the manual WAR install (which is the most complex one) when sometimes they could use the DEB or Docker installs for example. Do you think that’s true? I’ve tried to reword a bit http://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Installation/#HInstallationMethods to put the WAR install as the last one.
You said:
So the apt-get way is not good in your cases?
I’ve read again http://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Installation/InstallationWAR/ and it didn’t look that bad. Do you have specific examples of things that we could improve? I just had one idea when reading it which is to move some stuff in a section at the bottom, for example for the Security Manager thing.
One thing that is apparently not working so well is that the documentation is a wiki and everyone is encouraged to help out and reword things, move things around, etc.
I agree with this one. Actually our rule is simple: we only support 3 branches in the documentation, see https://www.xwiki.org/xwiki/bin/view/Main/Support#HSupportedVersions So normally anything older than 9.11.x should get cleaned/removed.
I have already used XWiki for 4 years and i have a lot to say:
what should we do? Spending the time to PR, support, actualizing information, translate and write new guide, making the videos “How to us XWiki at/as…” Man-hours require investment and altruism. But this is only part of a whole. If u know that u want - u always follow the nessesary way.
I wrote 2 articles about XWiki, but this is not enought.
Added some stuff, especially looking at https://snapcraft.io could be interesting. It’s by default on Ubuntu since 16.04 and the snap client is available in most Linux distributions standard repositories as far as I can see.
That’s actually fine (for me). I reviewed the tomcat guide again and it still feels “jumpy”. Allow me to give only one exampe: The second bullet point is already a link again give enough memory to Java. I’d prefer to have reasonable default here and a “for more info see memory settings section” link. Which could then also be referenced to by the current OOM error debug section.
This may cause a little redundancy but should be better for most. And if one gets surprised be the very high popularity of your xwiki installation (which I wish for every xwiki installation 
) one may need to adjust. If you run a “special needs” installation, like high volume or high availibity demands, you know it normally and plan ahead accordingly.
This could be nice, actually I liked the wizard for remi’s php repository, which admittedly covers a way simpler topic. I don’t know if this is “worth” it, maybe it is the detail that signs the deal, maybe it’s just a little sugar on the top.
Maybe it could be used for some new cool dynamic page type in our wikis too, wouldn’t that be awesome?
A cheaper and faster option is to dedicate a special section for user contributed howtos, where you see very concrete descriptions of installations, like installing “xwiki 9.x on centos 7.x with tomcat 8.x and mysql 5.x”. I see a lot of benefits from this: First that would encourage users to edit documentation, second you as a user may find “your” required walkthrough already “readymade” and third there may be nice little tricks and hints to get “inspired” even for the official documentation.
That may be possible, but it may be also the case that it is some kind of “catch-all” configuration, when you you don’t have docker or debian available. So it is somewhat natural that you see quite a lot of installations for this configuration.
Getting more complex stuff out of sight is always a good idea. I’d also propose to move the docker method to the production ready methods yet maybe below the debs. I also like the docker-hub description a lot.
Writing good documentation is a tough craft, writing great documentation is an art. So sadly this is somewhat expected. Yet I’ll try now and then…
If your only option is RHEL, no.
If I’ll find one, I’ll delete it.
A nice alternative/addition may be https://packager.io/ or https://openbuildservice.org/ to create packages for us poor RHEL/SLES/Centos using souls.
Note that Fedora is listed on https://snapcraft.io/ so I guess RHEL is not far and from what I understood work is in progress for other distributions (there is already some alpha builds for Centos being tested as far as I can see on https://forum.snapcraft.io/t/install-snapd-on-centos/1495/25).
I know packager.io but what is interesting about snaps packages is that you actually have the client available in all those distributions and an already known central repository (store), with package.io you have to add a new repository for each application you want to install.
Just added a new entry on http://dev.xwiki.org/xwiki/bin/view/Drafts/IncreasingActiveInstalls/ about advertising releases on new web sites. I’ve added one:
Please add some more!
It might be also worth to look into importing content into and exporting content from xwiki. Because these are two topics, I found, that you just can’t avoid. And everyone expects near perfect results. Unfortunately this is not the case for what I tested so far.
I just reevaluted the Streams Filter Application again to import some MediaWiki pages but it feels pretty rough to use currently. I’ll open a new thread for this in special.
The good thing is the conversion mediawiki->xwiki 2.1 syntax is working incredibly well for manual conversion even for crazy long and complicated pages, yet not for bulk operations.
Couple of little suggestions:
1/ ensure this information is up-to-date and accurate (this is where I first went looking for information on wikis)
https://www.wikimatrix.org/show/XWiki
It was last edited recently, so someone is doing that. Check for accuracy just in case it was not you.
2/ Have you updated your information at Infogalactic and Wikipedia recently? If not, do so.
3/ When I was first playing with xwiki, I had lots of problems getting everything to work - so much so that I abandoned it and went with Confluence for several years. I only tried again because the much improved features.
The install was still a bit of a pain and it took a couple of attempts, plus some problem solving to get java/tomcat playing nicely - maybe hosting a repository with prepackaged builds that “just work” for common distributions.
4/ is your features page up to date? Last edited Sept 2017.
List of websites where we advertise XWiki already:
List of websites where we’re not advertising XWiki and where we should:
Please edit and add to the list to help out!
Hi @pdwalker. Yes we do that at each release (it’s done by us). It’s part of our release plan. If you want to see all the places we edit, check the last release for example: http://dev.xwiki.org/xwiki/bin/view/ReleasePlans/ReleasePlan10.5
Interesting, first time I’m hearing about this site. What is it? Why does it have some old copy of wikipedia pages? Shouldn’t it be their job to do the sync? We do update all the page links you mentioned but on wikipedia, not on infogalactic.com. Seems like a pain to have to do it in both places and seems weird, no?
That’s an interesting feedback, thanks for mentioning it. So this shows we’re progressing, nice
It’s good that you came back because one of my worries is that when someone tries a software and doesn’t like it for whatever reason, the person usually doesn’t come back to it, or at least for a very long time.
That’s one of the reasons I/we’ve been pushing for usability improvements and especially first minutes usability improvements.
On this topic, if you see things we should improve for the first 5 minutes experience please let us know.
Yeah I’d love if we could have it even smoother. Please send ideas about what we should improve on the install/upgrade process from your POV.
Yes it’s up to date
The page is mostly automated and all extensions that are automatically bundled in XWiki Standard and present on extensions.xwiki.org are listed There’s only the Base Features part that is manual and that doesn’t change over time since everything new is done as an extension now.
Thanks, keep the ideas coming!
1/ You’ve got that covered. Excellent.
2/ --opinion-- Wikipedia has become a site toxic to anyone with a non "progressive" or "liberal" viewpoint. Infogalactic was founded as a fork of Wikipedia where they would leave out the politics and politically correct views which is damaging the quality of some of the wikipedia content. --/opinion--While it has not yet gotten the popularity of Wikipedia, it’s rapidly growing.
Anyway, if you’re updating wikipedia, that should be good enough for now, so that’s not really an issue.
Oh, suggestion: use the SVG version of your logo rather than the low resolution PNG. It’s much nicer (I see someone has already done that for Infogalactic)
3/ re: improved features - I am not sure which features made me come back and reevaluate xwiki. App Within Minutes, and the custom databases you could do? Maybe, I don't remember exactly now. And funnily enough, in the end I didn't develop the database type app - just stuck with a quick "app within minutes" type app for some of the larger listings I had to deal with.The usability of the wiki within the first couple of minutes is almost instantly obvious to me. I had no issues with that. (one minor annoyance which I will detail in a later post - which is not necessarily an xwiki problem as it is with my expectations)
3a/ Installation - I forget all the little things I had to do, and the number of attempts I needed until I was happy with my initial installation. I'll redo an installation somewhere else and then see if any of those annoyances/problems are actually an issue or not. By now, I've forgotten what I did to install it, so it should be just doing it from scratch again.Ages past, when installing software under Unix/Linux, I’d have to do the whole compile everything from source after first making sure that I had all the necessary libraries and prerequisites. These days, I’m completely spoiled with the {yum|apt} install commands and I have to confess to getting mentally lazy.
So in the spirit of that laziness, the install should be as easy as one of those package installation commands for one of the supported platforms. I suspect that will take a good deal of work, so the other possibility is preparing a self contained, prebuilt XWiki appliance that some one interested in evaluating the software can just download, and run under their hypervisor of choice.
Depending on how you build it, you may be able to have just one version that can be imported to run under KVM/ESXi or VirtualBox.
You could even keep a current version, and a previous version. The previous version could be used by someone to test the upgrade process.
4/ wonderful - you're aware of all that.Please note that my installation memories my be incorrect, or I may have been just doing something silly. When I do a new install, I’ll actually pay attention and write down anything that actually is a real difficulty.
I think we’re already doing that. We have 2 of them ATM:
What we’d like to add is a RPM one in the future but we’re lacking someone in the dev team using RPM. If someone could contribute and maintain one that would be the best FTM.
Do you have anything else in mind?
an update after your last post.
@rbr: do you have an example so that I can see what’s wrong and what would need to be changed?
Thanks
I agree with you. More generally speaking having a large number of integrations with all kind of external software is the best because it allows XWiki to fit in an existing ecosystem. It also does automatic advertising for XWiki.
The only issue is that developing integration is complex and long (and needs maintenance since the other software is constantly evolving too). I don’t see this as being possible for the xwiki dev team. As you can notice on extensions.xwiki.org there are several integrations (google docs, github, onlyoffice, etc). Nobody has done a sharepoint one yet though.
Yes: This google search for xwiki form validation has this page as second(!) result.
And there are more, I’ll report them if I find more.
Maybe it would be a good idea to add rel="nofollow" to all “action links” like history, export, etc as described here.
Ok I see, thanks for the example.
That’s an excellent idea Do you think you could create a JIRA issue for this?