^{(This is a part of the plugin survey 2011)}

Are my newly installed plugin compatible with the installation? The fast answer is yes - probably. But it is not easy for a new user to determine. Since last survey there has been three major releases of DokuWiki and the plugin developers assisted by the community have tried to keep the compatibility information up to date. This year 70% of the plugin homepages has been modified within last 12 months compared to 95% and 92% last surveys.

The result, 303 plugins (37%) explicitly states compatibility with at least one of the 4 recent releases. 45% have no, old or unclear compatibility stated. The pie chart shows “best” compatibility for each plugin and the table shows number of plugins for each release. The survey was conducted only 13 days after the “Angua” RC release so the meager result for this release is not really surprising.

A “!broken” or “!maybe.broken” tag is an obvious way of stating incompatibility with the current DokuWiki version. 4 plugins had their tag removed since last survey (ical, iframe, linkbonus, orphanswanted). With 3 new there are now 10 plugins (1%) are tagged in this way.

• content, html2pdf (new), includeuserpage, isbn, livepreview, meta, recent, refworks, statdisplay (new), userhistory (new)

90 (+24 since last year) plugins state conflict with one or more other plugins divided into 34 separate “conflict groups”. Since 2009 the number has more than doubled, reason for this is unclear. One reason might be the large total increase of plugins, another might be that functionality in older plugins are enhanced by releasing a new similar plugin instead of improving the old one. Here is the list of conflict groups after the more obvious, like addnewpage v.s. addnewpage_old, are removed.

• quickedit v.s. sidebar_template v.s. dblclickedit v.s. fckglite v.s. inlineeditor v.s. odt
• vshare v.s. dailymotion v.s. google_video v.s. youtube v.s. youtubev2
• dokucrypt v.s. edittable v.s. aceeditor v.s. pagemod v.s. searchtablejs
• indexmenu2 v.s. lightboxv2 v.s. indexmenu v.s. yalist v.s. navi
• jquery-syntax v.s. code v.s. code2 v.s. code3
• force_preview v.s. enforcesummary v.s. enforcedcomments v.s. livepreview
• definitionlist v.s. newline v.s. data v.s. qc
• backlinks v.s. autolink2 v.s. backlinks2 v.s. shortcut
• include v.s. header2 v.s. mediasyntax
• s5 v.s. processing v.s. s5reloaded
• inlineeditor v.s. dw2pdf v.s. odt
• sidebar v.s. discussion v.s. noprint
• stats v.s. charter v.s. pchart
• numberedheadings v.s. htag
• pageredirect v.s. asiansearch
• xbr v.s. highlightjs
• linkback v.s. badbehaviour
• any_wysiwyg_editors v.s. preservefilenames
• searchstats v.s. docsearch
• form v.s. bureaucracy
• saveandedit v.s. blogtng

A more detailed analysis were done for asiansearch and pageredirect. They both use the TPL_ACT_RENDER event. Asiansearch replaces the default code for action 'show' to create better search highlighting while pageredirect uses it to add a notice “You where re-directed here from page xxx” on the page top. Using them both unfortunately creates the “You where re-directed..” at the bottom of the page as asiansearch already have output the page content when pageredirect catches the event.

Sharing class names with another plugin might cause problems. PHP does not allow a class to be declared more than once. Having two plugins installed at the same time (and enabled) sharing the same class name will cause a fatal error “Cannot redeclare class …”. Then the poor admin has to manually remove the files to get the wiki started again.

boxwh is one plugin that never should be installed together with box or boxes_mod as it uses a class name not matching the used folder. It also have an extra folder __MACOSX which will show up as a broken plugin in the plugin manager.

Mostly this is no problem. Plugins like code, code2 and code3 uses the same class name but will overwrite each other while installing so the are never installed at the same time. However only the plugin with same name as class name will get popularity points (from all variants).

Are the wiki syntax used by syntax_plugins compatible? The 802 downloaded plugins have been scanned for

• addEntryPattern()
• addExitPattern()
• addSpecialPattern()

Although there are no rules for syntax mentioned some “de facto” standard has evolved. In this survey it looks like a majority of special patterns are either {{…}} (160 cases) or ~~…~~ (80 cases). A very common entry/exit pattern (231 plugins) is something like an XML tag even if some use upper case letters.

Automatic checking of regex strings is beyond SurveyBot's abilities, it even fails resolving static variables. But some observations can be made reading the list. Here are a couple of cases of greedy regex'es.

A lot of plugins still have the workaround with \x3C instead of '<' for early versions of the DokuWiki lexer lookahead bug described in patterns. A lot more than ten plugins do not feature a lookahead pattern.

Some plugins allows adding of syntax through config files, for example sqlcomp and vshare. Locale dependent syntax using $this->lang["keywordpattern"] is also available, like in datefilter and chessdiagram.

So see for yourself, here is a list of the syntax at time of survey, or here Use correct regular expressions.

Replacement renderers are inherently conflicting with each other because only one can be selected at a time. There are 12 replacement renderers.

• footnotestyle, header2, highlightjs, html5, linkprefix, mundart, noblankcells, nodetailsxhtml, pirate, purplenumbers, refererremove, xbr

_{Continue to ⇒ source_code}