Andreas Gohr | 1 Sep 04:00
Favicon
Gravatar

darcs changes 2008-09-01


Good Morning!

This are the darcs changes for DokuWiki committed
yesterday. Please test them and report bugs.

---------------------------------------------------------------------
Mon Sep  1 01:00:01 CEST 2008  Andreas Gohr <andi[at]splitbrain.org>
  tagged develsnap 2008-09-01
---------------------------------------------------------------------

Single patches can be downloaded from
http://dev.splitbrain.org/darcs/index.cgi/dokuwiki/?c=patches

Bye,
your darcs changelog mailer

--

-- 
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist

Lindgren Daniel | 1 Sep 09:29
Picon

SV: Re: DokuWikiFCKW.pm not working?

> I've been working on a major upgrade to DokuWikiFCK and I've 
> written the attached for users of DokuWikiFCK on windows.  
> You may have to go into the file and change the temp 
> directory at line 51 from C:\Windows\temp to your temp 
> directory, although the php documentation suggests this will 
> not be necessary.
> 
> Change the name of html2wiki to html2wiki.pl and place it in 
> the same directory as your Perl binary, or any other 
> directory which is in your Path.

Tried the new save.php with fckg (correct?) and empty (deleted) pages was the result. I used html2wiki.bat
instead of ...pl because my Perl installation hasn't registered to handle .pl.

The HTML tempfile is created but the shell_exec conversion to DokuWikiFCK by html2wiki doesn't seem to
happen, at least not with a resturn result in the $TEXT variable. If I try it manually it works, eg
"html2wiki.bat c:\temp\_dw3A.tmp -dialect DokuWikiFCK" on the command line.

Changing temp directory wasn't necessary on my installation, but if you want to you have to use double
backslashes in Windows, eg "C:\\Temp".

If I select "DW Edit" everything works fine, but I guess that means I completely bypass fckg. Deselecting
"Convert FCK ..." has no effect.

=====================================================================
Med vänliga hälsningar/Best Regards

Tulldata, Driftenheten        Tel    : 0920-259618
Daniel Lindgren               Mobil  : 070-6725325
Aurorum 3                     Fax    : 0920-259790
(Continue reading)

Spring Pierre | 1 Sep 10:53
Picon
Favicon
Gravatar

Re: syntax plugin match getter and setter

hi gerry,

> does that mean that syntax plugins will have to be changed to be  
> supported by the DokuFCKW?

basically, the patch i submitted will set the the parsed match to the  
syntax plugin object.

then, within my renderer, i will be able to overwrite the  
Doku_Renderer->plugin() method to just output s.th. like

     <code style="plugin">
         // will return s.th. like "{{navi>navigationmenu}}"
         $this->getMatch();
     </code>

this will then be processed correctly, when transforming the wzsiwyg  
xhtml back to DW syntax.

> But: I dont know how your fersion 2.0 works basically - but can' you  
> trigger a render event via AJAX to get the correct output form DW  
> itself instead of rendering your own?

i actually inherit from the Doku_Renderer_xhtml class and only  
overwrite the necessary methods.

yours ... pierre
==
PS: andy: did you miss the patch? should i include "PATCH" in the  
subject next time?
(Continue reading)

Spring Pierre | 1 Sep 11:01
Picon
Favicon
Gravatar

Re: Proposal: New event TPL_TOC_RENDER

hi all,

> In order to add new items to the TOC in a clean way (e.g. by the
> discussion and the linkback plugin to create links to their respective
> sections on a page), I hereby propose the addition of a new event in
> tpl_toc() which would contain the TOC data array as eventdata and  
> allow
> it to be modified by registered action plugins.

i'd love this event. i am writing an attachment plugin for a client  
right now, and it would come in handy ...

yours ... pierre

==
PS: the client agreed to open source the attachment plugin ;)
--
Liip AG // Rte de la Fonderie 7 // CH-1700 Fribourg
Fon 026 4222511 // Key id 0x5BF5F8FA // www.liip.ch

Gerry Weißbach | 1 Sep 13:58
Picon
Favicon
Gravatar

Redirect on do=show and Post send


hi folks,

some days ago there was a discussion on a new event + the behavior of
redirecting to the current page without any post data if some has been
send before ...

currently I have the problem, that I need this POST data in an  <php>
section ... but I won't get it any longer. Has anyone thought of that
or is this exactly what had to be banned?

Sinc.
Gerry.
--

-- 
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist

Gina Häußge | 1 Sep 14:15
Gravatar

Re: Redirect on do=show and Post send

Heyas,

Gerry Weißbach wrote:
> currently I have the problem, that I need this POST data in an  <php>
> section ... but I won't get it any longer. Has anyone thought of that
> or is this exactly what had to be banned?

+1

Same issues on my end with the discussion plugin which needs data like 
which entry to reply to or edit during rendition, not action 
dispatching. I temporarily worked around by using GET instead of POST, 
but wanted to raise that question as well as soon as everyone was back 
from weekend-mode ;)

Making the redirect preventable might be sufficient to resolve the issue 
I think. Any other suggestions?

Greetings,
   Gina
--

-- 
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist

Gerry Weißbach | 1 Sep 14:20
Picon
Favicon
Gravatar

Re: Redirect on do=show and Post send


>Making the redirect preventable might be sufficient to resolve the issue
>I think. Any other suggestions?

I'm not sure if simply preventing by a plugin will be enough since I'm
not using a plugin in my case.

Gerry.
--

-- 
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist

Michael Hamann | 1 Sep 14:21
Picon
Gravatar

Re: Redirect on do=show and Post send

Hi,

Gerry Weißbach wrote:
> currently I have the problem, that I need this POST data in an  <php>
> section ... but I won't get it any longer. Has anyone thought of that
> or is this exactly what had to be banned?

No, not really, the idea was more to have an event for plugins that want
to change the redirect and to prevent users from ending on doku.php when
they do e.g. cancel an edit.

I've attached a patch that changes the redirect-call so a redirect is
only executed when the initial action is not 'show'.

I don't know if this a clean solution, but it should work.

@Gina's mail: I don't know if it is that good when all users, that rely
 on POST-data in show, or plugin authors that do this, have to change
their code.

Greetings,
Michael
Gina Häußge | 1 Sep 14:28
Gravatar

Re: Redirect on do=show and Post send

Heyas,

Gerry Weißbach wrote:
>> Making the redirect preventable might be sufficient to resolve the issue
>> I think. Any other suggestions?
> 
> I'm not sure if simply preventing by a plugin will be enough since I'm
> not using a plugin in my case.

Right, sorry, I'm not on 100% today :)

Greetings,
   Gina
--

-- 
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist

Gina Häußge | 1 Sep 14:31
Gravatar

Re: Redirect on do=show and Post send

Heyas,

Michael Hamann wrote:
> I've attached a patch that changes the redirect-call so a redirect is
> only executed when the initial action is not 'show'.
> 
> I don't know if this a clean solution, but it should work.
> 
> @Gina's mail: I don't know if it is that good when all users, that rely
>  on POST-data in show, or plugin authors that do this, have to change
> their code.

Being mostly a plugin developer myself, I don't think it is ;), but I 
thought maybe there was a definite reason behind disabling POST by this.

The patch you prepared should take care of the issue though I think 
(warning: not on 100% today again ;)), and still support the intentions.

Greetings,
   Gina
--

-- 
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist


Gmane