Have been able to update the MarkupExpressionsExtensions recipe (and
Acme's ZAP Toolbox) so they now
1) Check for proper permissions before revealing source code.
2) Properly handle the wiki markup expressions (allowing you to put
directives into a hidden PTV).
Please feel free to upgrade at
On Wed, Apr 18, 2007 at 04:38:16PM -0400, The Editor wrote:
Second post on a couple problems with the Markup Expressions
Extensions recipe, I'd like to resolve...
On 4/16/07, The Editor [EMAIL PROTECTED] wrote:
In trying to finish up this recipe I came up with a bug...
if (!
On 4/19/07, Patrick R. Michaud [EMAIL PROTECTED] wrote:
On Wed, Apr 18, 2007 at 04:38:16PM -0400, The Editor wrote:
Second post on a couple problems with the Markup Expressions
Extensions recipe, I'd like to resolve...
On 4/16/07, The Editor [EMAIL PROTECTED] wrote:
In trying to finish
On Thu, Apr 19, 2007 at 01:47:28PM -0400, The Editor wrote:
On 4/19/07, Patrick R. Michaud [EMAIL PROTECTED] wrote:
On Wed, Apr 18, 2007 at 04:38:16PM -0400, The Editor wrote:
$MarkupExpr['wiki'] = 'MkExpExtWiki($params)';
In the comments at the top of markupexpr.php, it reads:
On 4/19/07, Patrick R. Michaud [EMAIL PROTECTED] wrote:
On Thu, Apr 19, 2007 at 01:47:28PM -0400, The Editor wrote:
On 4/19/07, Patrick R. Michaud [EMAIL PROTECTED] wrote:
On Wed, Apr 18, 2007 at 04:38:16PM -0400, The Editor wrote:
$MarkupExpr['wiki'] = 'MkExpExtWiki($params)';
In
On Thu, Apr 19, 2007 at 02:33:58PM -0400, The Editor wrote:
It would be very nice to be able to accurately store pagelists in
PTV's.
The phrase store pagelists in PTV's doesn't quite make sense
to me. Exactly what text do you want the page text variable to
contain?
[...] The text var
Second post on a couple problems with the Markup Expressions
Extensions recipe, I'd like to resolve...
On 4/16/07, The Editor [EMAIL PROTECTED] wrote:
In trying to finish up this recipe I came up with a bug...
if (! CondAuth($p, $HandleAuth['source'])) return '';
seems to fail
On Tuesday 17 April 2007 09:20, Hans wrote:
Monday, April 16, 2007, 3:00:34 PM, The wrote:
5) As far as Han's concern about using eval in the math function, I'm
pretty sure the function's pattern matching check on the input value
will eliminate any possible risk. It is a very nice, concise,
On 4/17/07, Petko Yotov [EMAIL PROTECTED] wrote:
On Tuesday 17 April 2007 09:20, Hans wrote:
Monday, April 16, 2007, 3:00:34 PM, The wrote:
5) As far as Han's concern about using eval in the math function, I'm
pretty sure the function's pattern matching check on the input value
will
Tuesday, April 17, 2007, 8:56:32 AM, Petko wrote:
It is safe to not break anything existant, neither reveal private information,
as it allows the eval'd string to contain only numbers and operators. No PHP
function can be executed, no internal variable can be printed.
It is not safe because
On Tuesday 17 April 2007 10:11, you wrote:
It is not safe because if the expression is not mathematically correct,
it will however try to execute it, and this will result in a Fatal Error.
Try with
{(math '12+(*')}
But you can tell your users not to write such incorrect expressions.
On Tuesday 17 April 2007 10:16, Hans wrote:
It is not safe because if the expression is not mathematically correct,
it will however try to execute it, and this will result in a Fatal Error.
Thank you! This is useful. So I cannot use math functions with this
math extension? Just the simplest
On 4/17/07, Petko Yotov [EMAIL PROTECTED] wrote:
On Tuesday 17 April 2007 10:16, Hans wrote:
It is not safe because if the expression is not mathematically correct,
it will however try to execute it, and this will result in a Fatal Error.
Thank you! This is useful. So I cannot use math
On Tuesday 17 April 2007 12:08, Petko Yotov wrote:
So I cannot use math functions with this
math extension? Just the simplest of arithmetic?
Yes you can as long as you write it correctly.
Sorry, I didn't reply well here.
No, PHP math functions cannot be used (such as round(), sqrt(),
Tuesday, April 17, 2007, 11:18:57 AM, Petko wrote:
No, PHP math functions cannot be used (such as round(), sqrt(), abs(), etc.).
Yes, just the simplest of arithmetic -- addition, substraction,
multiplication, division -- and the expression *must* be written correctly.
Maybe it better be
On 4/17/07, Hans [EMAIL PROTECTED] wrote:
Tuesday, April 17, 2007, 11:18:57 AM, Petko wrote:
No, PHP math functions cannot be used (such as round(), sqrt(), abs(),
etc.).
Yes, just the simplest of arithmetic -- addition, substraction,
multiplication, division -- and the expression
On 4/17/07, Hans [EMAIL PROTECTED] wrote:
Tuesday, April 17, 2007, 11:18:57 AM, Petko wrote:
No, PHP math functions cannot be used (such as round(), sqrt(), abs(),
etc.).
Yes, just the simplest of arithmetic -- addition, substraction,
multiplication, division -- and the expression
On Tue, Apr 17, 2007 at 11:20:27AM +0100, Hans wrote:
Tuesday, April 17, 2007, 11:18:57 AM, Petko wrote:
No, PHP math functions cannot be used (such as round(), sqrt(), abs(),
etc.).
Yes, just the simplest of arithmetic -- addition, substraction,
multiplication, division -- and the
Sunday, April 15, 2007, 10:41:08 PM, Patrick wrote:
- I think {(server ...)} really ought to use the actual $_SERVER
names instead of introducing its own. Otherwise authors have
to learn a different set of names for things that already have names.
Perhaps, but an admin that knew enough
On Mon, 16 Apr 2007, Hans wrote:
(which is why PHP calls its variable $_SERVER).
Is there a need for a {(server ...)} markup expression? Would it not be
more fitting to use page variables for things like the user's browser
name or the ip address? And then I would use terms like {$Browser}
On Mon, Apr 16, 2007 at 08:28:30AM +0100, Hans wrote:
Sunday, April 15, 2007, 10:41:08 PM, Patrick wrote:
- I think {(server ...)} really ought to use the actual $_SERVER
names instead of introducing its own. Otherwise authors have
to learn a different set of names for things that
After carefully reading the various posts on this thread, I'd like to
address a couple issues and propose a couple changes to the
MarkupExpressionsExtensions recipe.
1) Some of the content probably should be changed from
MarkupExpressions to Page Variables: Specifically, establish a
$Keywords
In trying to finish up this recipe I came up with a bug...
if (! CondAuth($p, $HandleAuth['source'])) return '';
seems to fail whether or not I have permission or not (defined in
config.php as admin. $p is correct value. Help?
Cheers,
Dan
Also, this does not work at all... I had this problem before and
forgot I had never figured it out. The problem is the $p value even
though it shows up as expected, the strpos cannot find a in it, so
it can't make the test or return the right value
$MarkupExpr['wiki'] =
On Mon, Apr 16, 2007 at 06:03:53PM +, Sandy wrote:
Patrick R. Michaud pmichaud at pobox.com writes:
On Mon, Apr 16, 2007 at 08:28:30AM +0100, Hans wrote:
Sunday, April 15, 2007, 10:41:08 PM, Patrick wrote:
(which is why PHP calls its variable $_SERVER).
Is there a need for a
Just released (renamed actually) a recipe entitled
MarkupExpressionsExtensions which adds a number of extensions to Pm's
recently released MarkupExpressions recipe.
Some of them include:
math
threads
captcha
a group page counter
random number generator
admin attr reader
list formatting
server
IMHO, the problem that the Editor is referring to isn't being addressed.
Rather the problem is ZAPanything always results in ZAPanything appearing
at the bottom of the resulting pmwiki search list. Ideally, a search process
for anything topic should display the results according to the most
On Sun, Apr 15, 2007 at 01:59:55PM -0400, Neil Herber (nospam) wrote:
The Editor wrote:
On 4/15/07, Patrick R. Michaud [EMAIL PROTECTED] wrote:
Since several of these extensions have obvious relation to ZAP
(even going as far as including ZAP in the configuration variable
name or
28 matches
Mail list logo
