incorrect links

I've the same problem

A possible workaround, https://drupal.org/project/freelinking.

No it is not, Freelinking doesn't exist anymore:

"This module is unsupported due to a security issue the maintainer didn’t fix. See SA-CONTRIB-2014-072 - Freelinking, Freelinking Case Tracker - Access bypass for details."

I am not too familiar with MediaWiki API, but I was prompted to test for compatibility with freelinking. Both these filters will try to process double square brackets. As far as I am able to tell, they are incompatible. Having both enabled for the same text format does not work.

In other words: If you want to use freelinking as a workaround for the problem reported above, you must disable MediaWiki API.

@gisle: Currently, 'MediaWiki API' is the only module for D7 that implements Wikitags as used on the Wikimedia projects (Wikipedia, Commons etc.). For D6 there was the excellent 'mediawiki_filter' that was refused full project status at d.o and thusly was never ported to D7. For D5 and D6 also was a 'PEAR Wikifilter' module which has been abandoned for a half decade. So there simply is no alternative to 'MediaWiki API' if you need to work with D7.

All these input filters try to make fast Wiki markup available for Drupal, e.g.

• link to node: [[Node title]],
• external hyperlink: [http://example.com external link],
• text formatting like bold '''bold''' or emphasis ''emphasis'',
• text structuring: == Second heading ==,
• lists * unordered list, # ordered list etc.

'mediawiki_filter' implemented link handling, formatting, Interwiki links, ToC and much more; and it integrated with other Wiki-related modules like 'Wikitools'. Opposed to that, 'MediaWiki API' takes an lazy approach and just tries to embed an external parser without much else; that causes all kinds of weird problems (for comparison, have a look at the complex integration code from mediawiki_filter which has been developed at the ETH Zürich; the project page has some background information and documentation).

Yes, it appears that 'MediaWiki API' is incompatible with any input filter trying to handle links. Another example is the 'interwiki' module that implements Interwiki links like [[wikipedia:article]]; it shows exactly the same behaviour like 'Freelinking'. This is most bizarr since the module maintainer does not want to implement link handling in 'MediaWiki API'. Disabling 'MediaWiki API' obviously is not an option as it is the default input format (it is used instead of HTML or WYSIWYG).

I'd consider this a bug in 'MediaWiki API', thus changing the category ("bug report") and the component ("code") since an input format that can not handle links at all and does not interact properly with 3rd party modules does not make much sense.

gisle, asb: I understand you, but I don't have much time to take care of this module thoroughly that's why I'm seeking a co-maintainer. Do you would like to help in this thing?

@asrob, thanks for the offer of co-maintainership, but I have to decline.

I aleady use freelinking. This project has some functionality overlapping that of the MediaWiki API project.

However, freelinking has recently become unsupported. I am currently working with the Security Team and others to make it supported again. After it has been reverted to supported state (in about two weeks time if the project goes according to plan), I shall probably sign on as co-maintainer of freelinking in order to make sure it stays healthy. I don't have the resources to co-maintain two overlapping projects, and I need to focus on the project I already use.

Good luck, with MediaWiki API! I hope asb or other of the project's users will step up to co-maintain it.

I will try to help in any project that gives me Mediawiki wikitags; I already wasted a lot of time for mediawiki_filter; we had a company funding the development of this abandoned project from Origo, we had coders at hand, but we lost against d.o beaurocracy. The issues with Mediawiki API are code related and require a skilled coder, so I can not help with that, sorry.

Just an update with a reference to comment #2 and #3: Freelinking is alive again.

Please note that if you want to use Freelinking for mediawiki wikitags, you must disable this project (MediaWiki API). Freelinking is an alternative to MediaWiki API, not an add-on.

As I said, the maintainer of 'MediaWiki API' recommends 'Freelinking' to enable hyperlinks (e.g. #2 in this issue). We all know now that this recommendation was misleading as both modules are incompatible. So there is no hyperlinking with 'MediaWiki API', as long as these incompatibilites are not fixed. To my understanding, 'MediaWiki API' should support everything that the MediaWiki API provides - this includes hyperlinks, of course - and not rely on another module. However, I am not the maintainer of this module.

Freelinking is an alternative to MediaWiki API, not an add-on.

It would be great if there was an alternative to 'MediaWiki API' for D7, but there is none. There simply is no module for D7 that gives us MediaWiki tags, like 'mediawiki_filter' (D6) or 'Pear Wikifilter' (D5) did. Mediawiki_filter won't be ported to D7 because the project was refused full project status, so most probably there will be no usable method to use MediaWiki tags in Drupal anymore. Sites relying on a MediaWiki input format are stuck with D6, as are sites that use the image.module.

Freelinking is not an alternative to 'MediaWiki API' since it does not provide tags to format and structure a document.

asb wrote:

Freelinking is not an alternative to 'MediaWiki API' since it does not provide tags to format and structure a document.

Fair enough.

asb wrote:

Mediawiki_filter won't be ported to D7 because the project was refused full project status, so most probably there will be no usable method to use MediaWiki tags in Drupal anymore.

I had a look at the Mediawiki filter application: https://www.drupal.org/node/1267234 - and it looks that the project's failure to be promoted to a full project is a very unfortunate case of miscommunication and misunderstandings.

The process to have projects promoted to full projects requires the applicant to follow the Drupal.org project application workflow. For instance, the applicant is supposed to respond to reviews in the review issue thread (not by PMs) , and when he thinks the project is ready for a new review he need to set status of the application to "Needs review".

Something really weird is happening in comment #16. You change the status from "Needs review" to "Needs work" yourself: https://www.drupal.org/node/1267234#comment-6539082. I can only guess why you did this, but it looks like you believe that the phrase "Needs work" means that the reviewers should work on approving your application.

Unfortunately, this is not at all what it means. In this context: "Needs work" = "This project needs more work before it can be reviewed again for promotion to a full project."

While it is not immediately apparent, to handle the huge volume of applications, there is considerable automation in the process. For instance, there is a script that will automatically close with the status "Closed (won't fix)" any project that meets the following condition: Having the status "Needs work" for 60 consecutive days. Note that this script exercises no judgement about the merits of the application, it is a simple, automatic measure to prevent the application queue from being clogged up by abandoned applications.

The action of the automated script is simple to revert. The applicant just need to prove that he hasn't abandoned the project by changing the status of the project to "Needs review" (after doing the work that resulted in the status "Needs work"). Klausi makes an attempt to to explain how it "works" in comment #19: https://www.drupal.org/node/1267234#comment-6930032.

He also suggests what is actually the fast lane to full project status. Simply to to request ownership and repurpose the namespace of the abanoned Pearwiki filter, which already is a full project. (That is how I got my own promotion - by taking over Anonymous Publishing, which was abandoned after D5. If you had followed up on that particular advice, I am pretty sure Mediawiki filter would have been full project in two weeks max.)

But at this point you appear to be so frustrated and disgusted with the whole process that you ignore his advice, and the project rolls of the radar.

This is a pity, because it was indeed a great project.

PS: There is also some other weirdness in this application. You seem to disagree with the reviewers that object to the use of a 3rd party library by insisting that the project does not use a 3rd party library, i.e. https://www.drupal.org/node/1267234#comment-5091878. However, the use of a 3rd party library is mentioned on the project page https://www.drupal.org/sandbox/asb/1199160. Quote:

Note that due to the nature of this module (and its usage of a 3rd party library), some of the Drupal guidelines have to be broken.

@gisle: MediaWiki is the software that powers Wikipedia and all Wikimedia projects, e.g. Creative Commons. It is a full, stand-alone application like Drupal, just more robust and better scalable. What 'mediawiki_filter' accomplished was to wrap segments of this application - the parser- into a Drupal module and enable major parts of MediaWiki's feature set for Drupal as an input format. As 'MediaWiki API' demonstrates, you can not take the whole MediaWiki application 'as is' and just plug it into Drupal. Several functions need to be modified, that's why it won't work to install MediaWiki somewhere and run an isolated wrapper module elsewhere (as some project "reviewers" demanded). Since MediaWiki is free software like Drupal (GNU GPL), there should be no issues to bundle an altered (= forked) release of MediaWiki with a Drupal wrapper module. However, the application process started with the argument that GPL'd software must not be hosted at d.o. That's as idiotic as it can get.

This wrapper module has a long history since the same guys developed - prior to 'mediawiki_filter' - Pear Wikifilter and other Wiki-like utility modules like 'exif' and 'recent_changes' as well. The initial development took place at the ETH Zurich, Pear Wikifilter was hosted at d.o and then left abandoned as this approach (using a PEAR library) was determinded to be a dead end; development continued under a new approach (embedding the full MediaWiki application) and moved to a commercial company; this Drupal module was no longer available at d.o, but could be checked out from a public SVN repository for the 'Origo' project; when this company left Drupal development a couple of years later, the sandbox project was an attempt to salvage the remains at d.o and gain full project status for a mature module that was used and developed professionally for years. What happened in the so called review was brainless nitpicking about nonsense; the wrapper code had been developed by professional software engineers and was proven to be reliable and to work as advertised for years.

Several people were involved in the project application, including developers; during the application phase, one by one was scared away from the project, or the Drupal community as a whole. That's why others maintainers of the sandbox application tried to work around the d.o obstacles in their own way ("if they want to call Microsoft Windows a library, let's call it a library"). The next argument to refuse the application full project status was that the "library" would have to follow d.o coding standards or it must not be hosted at d.o. This objection was actually about the number of leading whitespaces in one of the most heavily tested open source applications in the world. This debate was the reason for the last remaining developer to leave the project and the Drupal community as a whole (he now codes in Python and considers d.o as a place for wannabe beaurocrats). At this point, there were no developers involved anymore that could respond to code related questions. Also I could not claim to take over maintainership of an abandoned module; this would be fraud since a non-developer should only co-maintain a project.

I don't want to dig into the procedure any further, but nobody took the time to read the project application carefully (if someone doesn't have the time to carefully review a project application, he shouldn't claim to "review" it, right?). It starts with a review that doesn't even bother to take notice of the existing documentation, it continues with the request to take over a foreign project with a totally different and proven dead end approach (using a PEAR library, not the MediaWiki application), and cumulates in the request to earn a "review bonus" that can be only earned by developers.

The only real problem of this project application was to gullibly believe that a non-developer (me) could, with the help of some developers, salvage an existing module at d.o. You can not. Non-developers are nothing at d.o. It's not about solutions, but about the number of whitespaces in code. d.o is becoming an increasingly hostile environment for network admins, site maintainers, website developers, and users. At least that's what I have learned in the past eight years.

Fixed in version 7.x-1.0-rc3.