Hi there,
sorry for the long prose text,
key statements are bold.
I am looking for a future proof XenForo MediaWiki bridge. My past experiences with vbulletin have made me very cautious about using third party solutions. Honestly, while the publically available information on XLink/XWiki shows some positive moments in the recent past, overall I am clueless as to what to make of XLink/XWiki:
On the one hand, there is the well-known excellent code quality of ThemeHouse/Audentio. On the other hand, upon closer inspection, the XWiki star shines far less brightly,
I nearly get an escape reflex. Let me explain how this happened to me:
0) First, just to make sure:
The pricing doesn't scare me. Even if I am one of those who prefer to install things by myself, I know the value of such a software solution and the effort it takes to maintain it.
1)
Weak public communication
Several questions here in the discussion, and the -externally hosted- documentation and FAQ consisting of some handfuls of one-pagers give me the impression that
"pre-sales" at XLink/XWiki is just more of a bother. Feature and issue discussions are more or less non-existent or even remain unresolved.
One example that directly concerns me:
It is still unclear which options XLink/XWiki offers for already existing communities regarding the topic "username compatibility". In most cases, a large number of XenForo usernames already exists lower-case and with underscores, but this seems to cause problems with MediaWiki or XLink/XWiki. Neither the documentation, nor the FAQ, nor this discussion here give a clear answer to this issue. There are some hidden hints that accounts can be linked using the email address as key. It remains open which system leads where and how and which restrictions for usernames still may or must be applied then.
Unfortunately, the two direct and clear questions on this topic (case-sensitive & underscore) were never answered by TH/Au, although it seems that there might have been a solution for at least that one customer.
2)
Unknown conditions for support cases
It seems that the mentioned before username-issue was solved by one-to-one support magic. Whether it was a configuration issue or an individual patch helped, whether the patch is also available and update-safe for that particular or other affected customers,
whether some code of it
finds its way back into the next release for all customers, all these answers remain open for me.
It also remains unclear how such a solution can be achieved,
is remote access for a support ticket mandatory? In
another case it seems it isn't clear for the customer himself what exactly was corrected by the support on his own (!) system, but he is at least happy that it works again.
For me, this is a hair-raising event. Perfect support may be available by a ticket, but I often read here that this requires direct access to a project. So
is TH/Au also able to help me via classical logfiles or telco live screen sharing?
I'm sure you understand I can't just give people unknown to me easily access to a system that contains live project user/customer data. Unfortunately, I guess without executing the purchase, I can't even find the applicable T&C.
3)
Dealing with new releases
New releases of XLink/XWiki seem to come out primarily on an as-needed basis without schedule, often the patch release post follows a customer bug report without citing itself.
One can guess that the release probably fixed the customer's bug, but not for sure. That' s a pity!
For the release of XenForo 2.2 there was no announcement if XLink/XWiki is compatible. Apparently it works just like that and the meta-infos in the resource-overview also say that it works. Well, you can do it that way.
Finally, at the major release of MediaWiki it gets incomprehensible for me:
- Beginning of August until the beginning of September 2020, four 1.35 release candidates appear.
- End of September, 1.35.0 "stable" appears as a new LTS release.
- End of November, a customer reports an incompatibility of 1.35 with XWiki because one DB column has been removed by MediaWiki.
- Just one day later the problem is solved by a new XWiki version: 1.1.
- The new XWiki 1.1 branch instantly gets incompatible with all MediaWiki versions < 1.35.
No matter how I try to interpret this process, it scares me:
A new MediaWiki major/LTS version was released two months ago, then a customer (!) notices that XWiki is incompatible. Only one day later there is a patch provided, which at the same time immediately excludes all previous versions of MediaWiki, including 1.31 LTS, which is still in support for half a year by the Mediawiki team.
If I were a XLink/XWiki customer right now, and perhaps had other MediaWiki extensions that were not yet 1.35-capable, I would have to decide immediately what to do.
Because not one single word mentions whether XWiki 1.1.0 also includes security-patches whether there still will be security patches provided for the 1.0 branch if needed. Is this the normal way an add-on release/compatibility cut is done at TH/Au?
4)
Unclear function description, XLink/XWiki looks like a black box.
Somewhen in the past™, customers were already satisfied if someone offered a software and argued with his great knowledge without revealing technical details. Today we know that software solutions, especially with interfaces exposed to the public, that doesn't communicate thoroughly about and uses open standards for that tasks, typically is the one that gets hacked first.
XLink has full access to XenForo resources, XWiki has full access to MediaWiki's resources, there must be a TH/Au (unknown)/proprietary interface between the two that magically makes everything possible.
How is it secured against attacks? Because that's the magic on interfaces: At best, you get two hacked servers for the price of one, both the forum and the wiki.
What security measures are implemented in XLink/XWiki to prevent that?
5)
No hints about the configuration options for customer test system usage.
Of course, many "bricked" issues would often have been caught early with the use of XenForo's recommended evaluation via a
cloned test system without impact on live platforms. However,
I can't find any references anywhere if a cloned test system is even possible with XLink/XWiki (under a different subdomain or domain). On the other hand, I do find a lot of hints concerning the "correct" use of the API key, which rather makes me fear that a fully functional test system with XLink/XWiki might not be possible without further efforts?
-----
Just to be clear: For me, XLink/XWiki is not a "nice-to-have" add-on for an extra button somewhere, which could be turned off if necessary in case of problems, and whose code can be at least roughly evaluated.
To me, XLink/XWiki are additional, very complex elements, which, along with XenForo and Mediawiki, all need to work securely in sync to make an integral platform functioning at all. So I need to set higher standards here and
for that I need reliable, truthful support by TH/Au.
I understand XWiki will evolve rather stable to slow. Also, I can state especially concerning style and javascript issues, the response/solution time seems to be pleasingly short lately.
But is it usual to have an initial response time of several days in case of a php/code error?
How will TH/Au handle new XenForo/MediaWiki releases and compatibility issues in the future?
Will TH/Au act and communicate more proactively when supporting the XLink/XWiki solution in the future, or will it stay being reactive only responding to requests and problem reports "on demand"?
Can you give me good arguments against my concerns and explain why XLink/XWiki is a good choice for my project at all?
Thank you very much for your time and have a nice day,
Herbert