parapgraphs in block syntax plugins

Hi list,

There is one general problem I came across in several syntax plugins 
which allow paragraphs in block level elements.

Inline syntax is no problem (getPType() 'normal').
For block syntax you'd normally use: getPType() 'block'.
But there's one problem with block syntax with allowed type 
'paragraphs': A new paragraph will only be created when the entry syntax 
is followed by two new lines.
Many plugins (e.g. blockquote) bypass this problem by setting getPType() 
to 'stack' and closing one </p> before the rendered output and one 
opening <p> after the rendered output. (The empty <p>s will get cleaned 
up by DokuWiki automatically afterwards anyway.)
But this is not particularly good style and causes potentially problems 
elsewhere.

I had a short discussion with Chris about this a while ago: 
http://irclog.dokuwiki.org/index.php?d=2009-10-04#msg199980

I must admit I don't understand enough of the code. What I understood is 
this ideally should be fixed in the core or alternatively could be fixed 
in a plugin with a kind of "hack" by smuggling two EOLs into the code.

I tried adding two $handler->_addCall('eol',array(),$pos); into the 
DOKU_LEXER_ENTER case of handle(). But that doesn't work. It seems 
DOKU_LEXER_ENTER is too early (?). (It works in DOKU_LEXER_UNMATCHED, 
but that's the wrong place anyway, of course.)
Does anyone know if there is a quick fix to circumvent this behaviour?
If there's no simple solution I'd rather go with the "dirty" solution 

darcs changes 2009-11-02

Good Morning!

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

---------------------------------------------------------------------
Sun Nov  1 01:00:02 CET 2009  Andreas Gohr <andi[at]splitbrain.org>
  tagged develsnap 2009-11-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

Re: parapgraphs in block syntax plugins

Anika Henke wrote:
> Many plugins (e.g. blockquote) bypass this problem by setting getPType() 
> to 'stack' and closing one </p> before the rendered output and one 
> opening <p> after the rendered output. (The empty <p>s will get cleaned 
> up by DokuWiki automatically afterwards anyway.)

> If there's no simple solution I'd rather go with the "dirty" solution 
> (see above, with 'stack' and closing the </p>) and wait for the fix in 
> the core.

I just realised, I cannot use this "hack".
At the moment I'm trying to get the blockquote plugin (or the wrap 
plugin, it doesn't matter because it's the same problem) work with the 
purplenumbers plugin.

The purplenumbers plugin (or any other render plugin) works only with 
e.g. paragraphs made by p_open() and p_close(), of course. So, adding 
paragraphs in render() instead of handle() in a syntax plugin will lead 
to those paragraphs not being recognised by a render plugin.

Adding those calls to handle() could solve that problem.
I tried adding $handler->_addCall('p_close',array(), $pos); to 
DOKU_LEXER_ENTER and $handler->_addCall('p_open',array(), $pos); to 
DOKU_LEXER_EXIT. But any call in DOKU_LEXER_EXIT gets rendered at the 
*start* of the output.
Is there any way to manipulate that?

Thanks,
Anika
--

-- 

darcs changes 2009-11-03

Good Morning!

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

---------------------------------------------------------------------
Mon Nov  2 21:19:48 CET 2009  Andreas Gohr <andi[at]splitbrain.org>
  * ad backend: multi domain setup
  Ignore-this: 730fc5ffd5facc5ebea39c6613f44493
  Support for doing SSO with multiple AD Domain Servers

Mon Nov  2 20:28:31 CET 2009  Kittithat Arnontavilas <mrtomyum[at]gmail.com>
  * Thai language update
  Ignore-this: fa1e066502278dac24a367f2d0f2a76d

Mon Nov  2 15:13:33 CET 2009  Andreas Gohr <gohr[at]cosmocode.de>
  * ad auth: do not connect to AD server in constructor FS#1791
  Ignore-this: 5b5b6e67b2800c0ecde8b65de303c4df

Mon Nov  2 14:01:15 CET 2009  Andreas Gohr <gohr[at]cosmocode.de>
  * LinkWizard: don't add a title when useheading is used for content FS#1745
  Ignore-this: 48f0da3ab0bf0178197b16e63143e1ca

Mon Nov  2 13:16:32 CET 2009  Andreas Gohr <gohr[at]cosmocode.de>
  * LinkWizard: fix for problems with root links in subnamespaces FS#1771
  Ignore-this: e07c765961bc73acda47cb4b2a464fde

Mon Nov  2 11:46:43 CET 2009  Andreas Gohr <gohr[at]cosmocode.de>
  * Fixed ssues on the "Page locked" screen

Caching Issue with external images from Dropbox

Hi,

I riginally wanted to integrate galleries from Dropbox into Dokuwiki. Thanks
to Andreas the gallery plugin has made big efforts during the last weeks.

But there is still an issue, although GDLib works fine on my server:
Gallery streams from Dropbox don't show up in the web browser when having
"send http referrers" activated in the browser. Dropbox wants to prevent
hotlinking this way.
As I understood, Dokuwiki should download, resize and cache external images
as long as GDLib or ImageMagick works. But with Dropbox images it seems to
refuse and only forward the browser.

Now my question: Is this a Dropbox or Dokuwiki issue? For example take this
Dropbox image link (works only with an empty http referrer field):
http://photos-3.getdropbox.com/i/o/xt3MNi0o8Q49sohm9d0bga_RHC2ygQg3b77c5qPvGls
It doesn't have a proper ending, so Dokuwiki should render it with an
additional &.jpg
But instead, a big question mark is shown. So are here some MIME headers
missing? Does the gallery plugin maybe not recognice the image and just
forward the browser which can handle this?

Thank You
Richard
--

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

Re: Caching Issue with external images from Dropbox

> As I understood, Dokuwiki should download, resize and cache external images
> as long as GDLib or ImageMagick works.

And config:fetchsize is set to a big enough value

> Now my question: Is this a Dropbox or Dokuwiki issue? For example take this
> Dropbox image link (works only with an empty http referrer field):
> http://photos-3.getdropbox.com/i/o/xt3MNi0o8Q49sohm9d0bga_RHC2ygQg3b77c5qPvGls
> It doesn't have a proper ending, so Dokuwiki should render it with an
> additional &.jpg

Unfortunately dropbox doesn't ignore the additional parameter:

http://photos-3.getdropbox.com/i/o/xt3MNi0o8Q49sohm9d0bga_RHC2ygQg3b77c5qPvGls?.jpg

You're out of luck there.

Andi

-- 
splitbrain.org
--

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

Re: Caching Issue with external images from Dropbox

Hi,

> Unfortunately dropbox doesn't ignore the additional parameter:
> 
> http://photos-3.getdropbox.com/i/o/xt3MNi0o8Q49sohm9d0bga_RHC2ygQg3b77c5qPvGls?.jpg
> 
> You're out of luck there.

and the gallery plugin just forwards the browser when it cannot download and
cache such external images? GDLib is working on my server and fetchsize is
set to 10000000. It is resizing and caching local images very well.

Thanks.

Richard
--

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

Re: Caching Issue with external images from Dropbox

> and the gallery plugin just forwards the browser when it cannot download and
> cache such external images? GDLib is working on my server and fetchsize is
> set to 10000000. It is resizing and caching local images very well.

The gallery plugin simply calls ml() which in turn creates an URL to
the lib/exe/fetch.php

fetch.php uses the file extension (which your images don't have) to
find out if it is an image that it can resize. If that's not the case
it does a redirect to the given URL and exits.

Andi

-- 
splitbrain.org
--

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

[Patch] Rowspan cont.

Ok, here's second try with rowspan using parser/handler. I probably wont use rowspan very often but the ::: syntax suggestion was so nice . Some code cleanup and test units updated.

 

The other patch is removal of the class Doku_Handler_Section in inc/handler.php, which is dead code IMHO.

 

Cheers

 

/Håkan

 

[Patch] - Hide "old revs" when not actin show

Hi,

 

it's me again... This one may be debated

 

With the object of showing users which actions that are available or not, some templates has used the $ACT variable. I think it's good that templates are different and represent several kinds of user interaction BUT we should also make small usability improvements to the DokuWiki core (potentially affecting all templates).

 

I have attached a small patch hiding the "Old revisions" button and link for every action besides "show". This will change template.php affecting ALL templates, not just the default. Reason behind this is that the action doesn't make sense in any other context. Especially not with the admin screen and a novice admin looking for how to revert to his/her old settings.

 

A small number of templates using bulleted lists (showing bullets) will probably have to be adjusted.  

 

Comments?

 

/Håkan