[dokuwiki] Re: A small idea

Balazs Attila-Mihaly (Cd-MaN) wrote:
> This means that a subset of users will be stuck in a situation like "I can't
> update my wiki because the new release is incompatible with plugin X, but
> the author of X has gone away and I'm not a programmer". What about a middle
> ground like: make this an option but set it to off by default (ie. there is
> a checkbox in the administration interface where it says "auto-generate old
> date format string" which is unchecked by default)?

Ok, I've made some research on this topic. From the ~370 plugins listed at
wiki.splitbrain.org the following are relying on the $conf['dformat'] setting:

plugin:content              last update 2005-09-27
plugin:diskussion_forum     last update 2006-06-25
plugin:userhistory          last update 2007-01-1
plugin:timer                last update 2005-08-01
plugin:lastmod              last update 2005-10-10
plugin:newpagetemplate      last update 2007-02-24
plugin:loglog               last update 2007-10-19

plugin:gtd                  updated in devel (if not I'll update it)
plugin:blog                 updated in devel
plugin:discussion           updated in devel
plugin:editor               updated in devel
plugin:include              updated in devel
plugin:pagelist             updated in devel
plugin:feed                 updated in devel
plugin:task                 updated in devel
plugin:var                  will be updated by me
plugin:gtd                  will be updated by me
plguin:lastfm               will be updated by me (atm broken anyway)
plugin:linkback             I am 1000% sure it will be updated by foosel
plugin:bloglinks            I am 1000% sure it will be updated by foosel

I might missed 1-5 but you get the picture. I'll be happy to post fixes for
the 7 plugins mentioned above on the their plugins pages or contact their
authors via mail if necessary ;-).

> PS. A small critique: it is bad practice (imho) to change the interface of a
> software (and by interface I mean the programmatic way of interacting with
> it, not the GUI) in a way which is purposefully incompatible with the old
> one (like changing the format of a configuration variable). Even more so
> when the given interface is semi-public and it is known that third-party
> code relies on it. Given how flexible dynamic programming languages like PHP
> are, it is much nicer to introduce a new property with the desired meaning
> and let the old property alone.

Full ack from my side on this! However, in this particular case there is IMHO
no harm done, because, first, it's a cosmetic thing, it doesn't make the wiki
unusable, second, the fix for the third party code is trivial, third, the list
of affected plugins is short compared to the plugins available ... and the
most popular plugins (blog suite and the like) will be updated the day the new
DW release sees the light anyway ;-).

Best Regards,
    Chi

-- 
Michael Klier

www:    http://www.chimeric.de
jabber: chi@xxxxxxxxxxxxxxxxxx
key:    http://downloads.chimeric.de/chi.asc
key-id: 0x8308F551

Other related posts: