
|
[dokuwiki]
||
[Date Prev]
[12-2007 Date Index]
[Date Next]
||
[Thread Prev]
[12-2007 Thread Index]
[Thread Next]
[dokuwiki] Re: AW: Re: Patch: Trigger IO_WIKIPAGE_WRITE on page delete
- From: Myron Turner <turnermm02@xxxxxxx>
- To: dokuwiki@xxxxxxxxxxxxx
- Date: Fri, 21 Dec 2007 10:20:49 -0600
I'm sorry to jump in at this late date, but I it wasn't until I saw the
patch that I actually looked at the code. You've identified a problem
that should be addressed but I'm not sure even if a patch is the way to
solve it.
First, I'm wondering whether the patch would be backwardly
compatible. As you say, the event will now be triggered twice
(actually 3 times--being triggered for writing to the attic). It's true
that users should have been checking for the empty data field to
distinguish between a deletion and a write. But the extra firing could
cause some problems for legacy code.
I think that either a delete event should be triggered or, ideally, that
the DokuWiki code should look at possibly correcting its current
handling of "empty" data.
My impression has been that the data field would be unreliable in any
case, because a file is not considered empty by DokuWiki unless it has
no data at all, which means that to delete a file, you must make sure it
contains no characters at all. My own event handlers, however, consider
such files as empty and I delete them. I haven't traced the sequencing
of writes in DokuWiki and how they relate to deletions, but I'm not
entirely sure where your patch would leave my code.
I think there is also an issue with regard to DokuWiki's code logic.
Your patch places the triggering of this event in a code block which
handles matters which have occurred after a write, after the file has
been removed. Ideally, the event should show an empty field because an
empty file has just been written. To be specific, the DokuWiki code reads:
if ($wasRemoved){
}
else {
io_writeWikiPage($file, $text, $id);
}
The IO_WIKIPAGE_WRITE event is triggered out of the else block in
io_writeWikiPage(). The patch places the new trigger in the $wasRemoved
block. As I said, I'm not sure about the DokuWiki the code sequence.
But presumably, the empty file is being written in io_writeWikiPage().
But for some reason the data field is not empty. It may be that the
file is previously designated as having been removed, and the code never
gets to the else block and to io_writeWikiPage().
Again, sorry to come into this thread so late,
Myron
Gabriel Birke wrote:
Hi,
before I sent the patch, I asked on the list which version I should
implement, but I got no feedback. I chose the IO_WIKIPAGE_WRITE solution to
comply with the documentation on the events list (
http://wiki.splitbrain.org/wiki:events_list#io_wikipage_write ). Triggering
the event twice is standard behavior for updates (and with a little
creativity, you can declare a deletion an "update" ;-) More important, the
documentation states that on delete the variable $data[0][1] is empty. This
empty data would not be sent without the patch.
If one of the code maintainers sends me a mail, I will gladly provide a
patch that provides a IO_WIKIPAGE_DELETE event (maybe even move the deletion
code from common.php to io.php).
Greetings,
Gabriel
-----Ursprüngliche Nachricht-----
Von: dokuwiki-bounce@xxxxxxxxxxxxx
[mailto:dokuwiki-bounce@xxxxxxxxxxxxx] Im Auftrag von Guy Brand
Gesendet: Donnerstag, 20. Dezember 2007 21:58
An: dokuwiki@xxxxxxxxxxxxx
Betreff: [dokuwiki] Re: Patch: Trigger IO_WIKIPAGE_WRITE on
page delete
On 19 December at 13:23, Gabriel Birke wrote:
After applying this patch, DokuWiki will fire two
IO_WIKIPAGE_WRITE events
instead of one when a page is deleted. The first event has
no revision and
Hi Gabriel,
Naive question: why two times the same event and not a more specific
DELETE event?
--
bug
--
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist
--
_____________________
Myron Turner
http://www.room535.org
http://www.bstatzero.org
http://www.mturner.org/XML_PullParser/
--
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist
|

|