[pmwiki-users] Re: newwin with defined size
jo at durchholz.org
Thu Jul 7 17:24:52 CDT 2005
Christian Schlatter wrote:
>> Since it's bad practice to emit PHP errors if the user mistyped the
>> markup, I suggest changing the markup so that it will be ignored until
>> it has at least one parameter, like so:
>> >> Markup('newwin', 'directives', '/\\(:newwin\s+(.+?):\\)/e',
>> ^^^ ^
>> >> "newwin(PSS('$1'))");
>> The \s+ requires a nonempty sequence of blank-space character, and the
>> + makes the regular expression want at least one character after that
>> sequence - the net result is that ParseArgs will find at least one
>> parameter and fill $args[''] with at least one array entry.
> Nice solution, although I think it is still better for an end user to
> output something like "newwin error: you should define xy" instead of
> the markup itself.
I have done so in the Input recipe.
I have somewhat mixed feelings about that though. Seeing that the markup
wasn't recognised usually alerts the wiki author to the problem - and
even if it doesn't, the next author will be alerted. Emitting error
messages is somewhat less "friendly".
For Input, it was unavoidable - there are too many different possible
causes if a markup is erroneous, so simply showing the unprocessed
markup doesn't give the author a clue what exactly went wrong.
> BTW, it would be nice to have a global PmWiki error
> handling function, that could be called within markup code. Maybe a
> function that collects all error messages (classified by markup) and
> prints them nicely at the beginning of wikitext.
Error messages at the place where the erroneous markup was make it
easier to assign the cause of an error.
>> Note that I strongly advise against popping up windows anyway. It's
>> annoying to people who want to open the window in a tab (instead of in
>> a new window), for example - the link to the photo would ignore the
>> new tab and open a new window anyway. It will also exclude those users
> seems to be the only one more or less supported by major browsers
> - My own webserver statistics show that 99.8% of all visitors have
This means that 99.8% of all visitors are potential spam sources :-(
> - The language itself is quite secure, only some implementations and
> some extensions (e.g. IE's JScript) are not.
It's always the implementations that are unsecure.
And all those IE alternatives shouldn't rest on their laurels - Firefox
just plugged some security holes, only weeks after the 1.0 release.
The problem is that JS is far too complicated to be safe. There are
simply too many things that can go wrong, and a single error can make
the entire implementation unsafe.
> destructive approach, since lots of useful functionality is lost. The
> same goes for restrictive firewall admins ;-)
Enabling JS isn't the right solution either. JS is the worst security
hole within a computer (the worst overall security hole is sitting in
front of the keyboard though...)
More information about the pmwiki-users