MediaWiki Filter

@klausi: Thanks for your comments; I don't think that the MediaWiki parser is comparable with a library, especially as there is no "library" to download anywhere. Users would have to download the complete MediaWiki software package in a certain version, extract dozends of files from the archive in a certain structure, and to throw away the rest (including a competing index.php file). Considering the problems most users have with simple library packages like jQuery UI, Colorbox, Flowplayer, Video.js and the like, I don't think that such an approach would work for normal users.

@kenorb: Could you please look into the hook_init() and coding style issues? Thanks!

The applicant has replied to the e-mail.

Thanks, but I believe this already is in #2 from last October. Anyone care to reply to the "external libraries" issue?

Reactivating.

• #1576082: Fix Version Information
• #1576298: Add GPL Licencing Information
• #1576086: Remove CVS/SVN Autoprops Tags
• #1576072: Move/Use Mediawiki Library from "sites/all/libraries" Directory
• #1576064: Create Development Guidelines

• #1579934: Setup Test Suite
• #1577364: Fix SQL Queries as Indicated by Coder
• #1577362: Fix Style Warnings as Reported by Coder
• #1576076: Update to Mediawiki 1.19.0

@patrickd: An "automated review" of the project does not make much sense in this case. Please reade the project page, which states:

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. For instance, we have to use different variable names that integrate with Mediawiki (which are in CamelCase) that don't follow the Drupal conventions (which use underscores).

@AmbikaFR: Thanks for your manual review. The interesting question now would be, if - one year after the application for full project status - a developer is still following this issue ;-/ At least kenorb seems to have lost interest completely.

@Beat: Could you please comment on #14?

As stated on the project page, the primary goal of this Drupal.org Project application is was to gain full project status. The full project status has been denied for over a year, with very bizarre reasoning (not allowed to package GPL'd code on d.o, different formatting of external code etc.). You might figure how this treatment demotivates any volunteer developer, especially considering that this module is fully operational.

Addtionally, refusing the full project status makes it impossible to build (sponsor, develop) a D7 port. That leaves the numerous sites that are using mediawiki_filter, and PEAR Wiki filter without an upgrade path, as both module's maintainers have left Drupal development (guess why!). And that makes it impossible for this module's users, including the refugees from Origo, to even consider migrating to D7 or beyond since there is no working alternative for using MediaWiki markup in Drupal.

That's very bad news!

As I mentioned multiple times, mediawiki_filter is the "official" successor for pearwiki_filter which has been abandoned de facto with the D5 version. Our project page states this as well. The same core developers started mediawiki_filter, but outside of d.o (guess why!). mediawiki_filter was one of the core modules for Origo. Origo has been featured years ago on the d.o start page (before the design relaunch, when community issues still mattered), and lots of frustrated users of pearwiki_filter fetched the more robust and better featured mediawiki_filter from Origo's SVN. The Origo people left drupal development last summer, and since then the module's user base hase neither a reposity to obtain the module, nor an issue queue. A couple of developers committed to the sandbox and tried to help co-maintaining this module, but left frustrated, as this project's application was blocked since September 2011.

And yes, I consider it "blocking" when you comment stuff like "you should not include external libraries with your module", or some guy runs some automated coding style tests against packaged external code. That's missing the whole point of the module, those issues have been targeted from the beginning in the module's documentation, and it's pretty ignorant in regard to the work we invested in the code and the documentation.

However, as #15 shows, all active developers have been scared away in the past year, so the userers are f****d as we have to consider #3 become true.

Maybe my English conversation skills are really bad, or we are somehow talking past each other.

In #14, 'AmbikaFR' made a manual review (btw, thanks for this!). Since September 27, 2012, the last developer actively involved in this module (Beat, a guy from the original ETH Zürich/Origo team), did not respond to the issues raised by AmbikaFR anymore. Beats last bunch of commits were made in May 2012 (about half year before the review), so it's pretty fair to assume that there aro no developers reading this issue anymore.

Even if it's a punch the user's faces, this module has been abandoned by it's developers, like 'PEAR Wiki filter', or other essential D6 modules like 'Image' with it's 60k user base. This might have been a "matter of days" a year ago, when there still were active developers, but as of today, the train appears to have departed. Thusly, the status "won't fix" appears to be proper, and that keeps being very bad news for those relying on this module.

P.S.: Just ran into this comment by Eugen: http://drupal.org/node/649270/revisions/1961296/view (" guess, if the community decides to treat the authors of modules this way, basically the "we dont care about you, just give us your work, slave", i bet this will happen again and again.", )#29

Yes, that's how it is: We had developers, and we had sponsoring, but we did never get full project status; the developers jumped off, and the sponsoring was revoked, so the Drupal.org Project application failed.

For D6, the module can be used 'as is', it's feature complete and works smoothly on (at least) dozends of sites - nobody can tell on how many, that was one of the reasons why we wanted full project status. For D7 migration attemts this is a showstopper, and for the sponsoring company it was a showstopper to use Drupal anymore.

Fixed link

@mrded: Thanks for offering help! Personally, I'm still interested as I'm using the D6 version on several sites, and the lack of a D7 port is a showstopper for all these projects.

However, all developers have left this project or even the Drupal community at all, and the company that offered funding of this project does not support Drupal anymore.

If the questions raised by the reviewer 'AmbikaFR' in #14 need to be taken care of, this project needs a developer. I can only help with documentation and respond to issues about the module's usage.

Very interesting!

You are prabably aware that the original developers of PEAR Wiki Filter (D5/D6) and mediawiki_filter (d6) are the same people? They considered PEAR Wiki Filter a dead end and created mediawiki_filter as a replacement and successor.

@joachim: Sadly, yes. 'mediawiki' is a D5 project, and 'mediawiki_api' does not even support wikilinks; even worse, it is incompatible with 'freelinking'.

'mediawiki_api' needs a developer to get the module usable, not someone helping with documentation or in the issue queue. If mrded's project moves out of it's sandbox status, it will be the one and only way to work with MediaWiki/Wikitags in D7.