XWiki [Deleted]

The off-canvas mobile navigation (and anything else that relies on XenForo's has-js class on the HTML element) does not currently work if you are using MediaWiki v1.34 or above, because of a change in MediaWiki that changes the way it applies its own client-js / client-nojs classes to the HTML element.

I've written up an issue here:
 
The off-canvas mobile navigation (and anything else that relies on XenForo's has-js class on the HTML element) does not currently work if you are using MediaWiki v1.34 or above, because of a change in MediaWiki that changes the way it applies its own client-js / client-nojs classes to the HTML element.

I've written up an issue here:
Thank you so much for writing up an issue @36degrees :)
 
Getting some sort of double-gzipping issue going on now with MediaWiki 1.35 – getting 'garbled output' when trying to access the wiki.

$wgDisableOutputCompression is definitely set to false in the MediaWiki config file, and changing the skin back to the default skin fixes it.

The only workaround I've found so far is to disable gzip entirely in XenForo by adding $config['enableGzip'] = false; to src/config.php :confused:
 
Sorry, that was my brain not functioning at 11pm! I should have set $wgDisableOutputCompression is definitely set to true – which it is! I just wrote the wrong thing.
 
I'm trying to add thumbnail styling rules similar to Mediawiki's Vector skin with no luck. I've tried CSS pages within the wiki, within xenforo, and editing the skin directly, but I can't get the thumbnail to look anything like this:

1606296012852.webp
What's the best way to add some CSS classes for thumbnails?
 
Content is completely managed by MediaWiki, so any class management needs to be done the traditional way. You can then ship the styling via the thxwiki.less file or via your extra.less file if you'd rather not modify any add-on templates.
 
I think XWiki with MediaWiki 1.35 no longer includes some of the 'shared' CSS.

From the release notes:

The ResourceLoaderSkinModule class now has a "legacy" feature that loads the stylesheets previously part of the "mediawiki.legacy.shared" and "mediawiki.legacy.commonPrint" module. Those modules are now deprecated and no longer loaded by skins. For skins needing to retain these styles, you will need to load these styles via a module using the ResourceLoaderSkinModule class. See Vector and Monobook for examples.

Our test board (running MediaWiki 1.34) includes the stylesheet /wiki/load.php?lang=en&modules=mediawiki.legacy.commonPrint%2Cshared%7Cmediawiki.toc.styles&only=styles&skin=xwikiskin whereas 1.35 only includes /wiki/load.php?lang=en&modules=mediawiki.toc.styles&only=styles&skin=xwikiskin (which is only

The result of this is that the styles for various classes (including things like tright and tleft – used to align thumbnails) are no longer included.

(And yes, I am very much regretting installing a newer version of MediaWiki than we had on our test board 🙃)
 
I think XWiki with MediaWiki 1.35 no longer includes some of the 'shared' CSS.

From the release notes:



Our test board (running MediaWiki 1.34) includes the stylesheet /wiki/load.php?lang=en&modules=mediawiki.legacy.commonPrint%2Cshared%7Cmediawiki.toc.styles&only=styles&skin=xwikiskin whereas 1.35 only includes /wiki/load.php?lang=en&modules=mediawiki.toc.styles&only=styles&skin=xwikiskin (which is only

The result of this is that the styles for various classes (including things like tright and tleft – used to align thumbnails) are no longer included.

(And yes, I am very much regretting installing a newer version of MediaWiki than we had on our test board 🙃)

That explains a lot, thank you. I've been adding bits and pieces back in via thxwiki.less but it's a slog, what solution did you end up going with? I tried the ResourceLoaderSkinModule method like Monobook, but couldn't get it working.
 
Last edited:
That explains a lot, thank you. I've been adding bits and pieces back in via thxwiki.less but it's a slog, what solution did you end up going with? I tried the ResourceLoaderSkinModule method like Monobook, but couldn't get it working.
From memory, I think I grabbed the output from /wiki/load.php?lang=en&modules=mediawiki.legacy.commonPrint%2Cshared&only=styles&skin=xwikiskin (which gives you the CSS for the 'missing' modules that aren't included by default in 1.35), prettifying it and adding that to extra.less.
 
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
 
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

Hey there Herbert,

Thanks for your detailed thoughts.

I could go into detail on every concern but I think I would do better to sum up our strategy as a whole. If this still leaves questions I can address in turn.

There was a time in our past where we wanted to just sell add-ons and themes. But for reasons I won't go into great detail on, it became an extremely poor decision to do so. Suffice to say there was volatility everywhere, from the technical side, market side, everywhere really. So, since then, our listed-as-maintained add-ons that are public are fully maintained and stable to the best of our ability and we have made the choice to only list add-ons that more or less require low maintenance in general or are simple in nature. But the VAST majority of our key add-ons we use regularly are not listed here at XenForo.com. Over time we will be removing some of the more complex ones for purchase, and perhaps even open sourcing the simpler ones, as we've done heavily in the past. In general, unless it makes entirely good sense to do so, our future add-ons will stay private (as a few other add-on developers have selected to do so)

Our business is structured entirely on working 1 on 1 with communities of all sizes and types. So, we prefer that if you need such functionality to contact us first, have a phone call, discuss needs, etc. So while you are welcome to buy, skip the phone call, and install on your own, its not something we think is best. Any piece of functionality worth adding to your site requires some tender love and care, even stock features from XenForo. We're happy to do a demo of this particular product and whatever else over a call to determine if its a right fit. But again, we'd have a 1 on 1 relationship, where we work closely with you. 1 off add-ons in the distributed marketplace, for our company, is and was too difficult to do well for again a multitude of reasons, even though we do as I said maintain any that are currently listed.

We've been building addons and themes since literally day 1 of XF being released. The moment the zip file was ready from XenForo 10 years ago, I set off to make a theme. I think I've done a decent job of building quality products over the years, but at some point it just wasn't viable for me at least. Communities were too complex to build the type of products I wanted to build, and I didn't have often the resources or capabilities to do them precisely as I wanted. And this isn't to say we're going anywhere either, I'm happy with where we are now, moreso than I ever have been.

We currently have 3 people working on our add-ons, and have been working on them nonstop the last 5 years at least. We still do a weekly sprint to go through newly reported issues, and have even introduced a new way of monitoring bug reports.

Regarding this specific product: We have a few large boards using this specific product, and we maintain dozens of Wikis (both using this product and not). But I assume you can guess that the interest for such a product is rather small. Even if its 50 communities, its hardly enough to maintain such a bridge. But we do it anyways as some people help invest into it again on a 1 on 1 basis. What we've seen is that 9/10 work out of the box. But that other 10% requires often times a bit of tweaking, new features, cleanup on their server, etc. And if you happen to fall in that 10%, you wouldn't be very happy. So we're just doing a full refund at that point if it doesnt work out. But thats why a phone call to determine goals is so essential, it should tell us whether or not it is a good fit ahead of time. And if its not, I will do my best to steer you into a new direction.

Hope this helps clarify a bit. I entirely respect if you want to use another product that is more self-install focused. Our products, or at least our big system products, will all be done on a more personal level moving forward (and we've been doing it this way for around a year now).

Here for any questions, you're welcome to contact me at audent.io as well!
 
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
I wouldn't recommend it if you want future proof, we've had ours since October, and it's still not working, Support is somewhat slow, now currently an API issue, we were asked to check logs, but there aren't any errors...

When looking at MediaWiki's authapp for xenforo, It does get updates? even though its "unmaintained"
 
Future-proofing would be a concern if this were a fully custom wiki. It's a bridge, and neither XF nor Mediawiki are going anywhere.

Since 1.5 there have been multiple ways to connect the two platforms, this is just the most elegant (yet hard to install) solution.
 
Last edited:
Top Bottom