[dokuwiki] Re: A small idea
- From: Michael Klier <chi@xxxxxxxxxxx>
- To: dokuwiki@xxxxxxxxxxxxx
- Date: Tue, 25 Mar 2008 16:43:12 +0100
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:
