Plugin Call

[cmb]

The plugin is only meant to be able to edit userfuncs.php in admin mode.

[Tata]

I see. Actually it is correct. Would it be downloadable, commented, with help etc.? Looking forward.

[cmb]

Hi Tata, hi manu,

I've thought a quite lot about this topic. My conclusion: online editing of userfuncs.php in the back-end might not be the best solution. Neither are a several special plugin calls. At least as far as possible, we might consider offering a set of functions, which should cater for many/most typical use cases---and get rid of the PLUGIN notation.

What about simple value assignments?

What about defining the following function:

Code: Select all

function set(&$var, $val)
{
    $var = $val;
} 

This could be used like so:

Code: Select all

{{{SET($title, 'CMSimple + PHP = simply powerful!');}}}

Or for more complex cases:

Code: Select all

{{{SET($tx['locator']['text'], 'A new locator text:');}}}

Compare that to CMSimple scripting:

Code: Select all

#CMSimple $tx['locator']['text'] = 'A new locator text:';#

which is only slightly better readable.

Another useful application of this function:

Code: Select all

{{{SET('template_variable', 'text for this page');}}}

and in the template:

Code: Select all

<?php echo $template_variable;?>

Something like {{{HOME}}}?

If we have the following function:

Code: Select all

function home($text = 'Home')
{
    return a(0, '') . $text . '</a>';
} 

one could call

Code: Select all

{{{HOME();}}}

or

Code: Select all

{{{HOME('Start');}}}

And there are situations when some special "if...else" can be used or switching of some functions' parameters

This is catered for by PHP's ternary operator. Generally instead of

Code: Select all

if ($condition == 1) {
    echo 'one';
} else {
    echo 'two';
} 

one can write

Code: Select all

echo ($condition == 1) ? 'one' : 'two' ; 

So one could write:

Code: Select all

{{{boilerplate($s == 0 ? 'firstpage' : 'otherpages');}}}

We might consider adding a function which allows to output something, as neither echo() nor print() can be used:

Code: Select all

function output($text)
{
    return $text;
} 

In combination with the ternary operator this could be used like:

Code: Select all

{{{OUTPUT($s == 0 ? 'Welcome on my website' : '');}}}

some stylings etc.

The following simple function might already suffice:

Code: Select all

function styles($styles)
{
    global $hjs;

    $hjs .= '<style type="text/css">' . $styles . '</style>';
} 

so one can write:

Code: Select all

{{{STYLES('p {color:red}');}}}

Please note that all these functions are basically one-liners, so they won't introduce noticeable performance penalties. On the contrary I believe they will be faster than any other solution. And it seems to me, they are simpler and more flexible than any other solution.

Christoph

[manu]

Good morning

If we have the following function:

Code: Select all

    function home($text = 'Home')
    {
        return a(0, '') . $text . '</a>';
    } 

one could call

Code: Select all

    {{{HOME();}}}

Code: Select all

    {{{HOME('Start');}}}

We should decide if we want to have a specific "HOME" function which should link to the index 0 page or
a "ILINK" function which links to a specific internal page, default value is "Home".

[cmb]

Hmm, I'm not so sure, if HOME()/ILINK() is necessary at all. I had given it as example, that it's possible to avoid special markers (and special handling) for the plugin call. The links to internal pages can be set from the editor (a link list is available in tinyMCE and CKEditor), what has the advantage, that these links can be checked by the link checker (without taking care for checking the parameter of this function). But if we introduce such function, I would prefer ILINK() as it's more generally useful.

[manu]

Hmm, I'm not so sure, if HOME()/ILINK() is necessary at all....

+1
can easily be solved by insert internal link in the editor.

[Tata]

Hmm, I'm not so sure, if HOME()/ILINK() is necessary at all....

+1
I also think that this would make the use of internal links little confusing. However, there are things that could be inserted the {{{ }}} way. Maybe just to define the "call" as mentioned before (PluginFunction, CoreFunction, Variable...). And I would maybe allow using of alternative calls: #cmsimple...#, {{{...}}} or hi_pdscripting. Each of it can be preferred from specific reasons (e.g. if the website is to be mainained by author himself, or if it is made for an experienced user, or for someone who is poorly able to write the content.
E.g.:

Code: Select all

{{{PF:events();}}}
{{{PF:editevents();}}}
{{{CF:lastupdate();}}}
{{{V:$news=News01;}}}

[cmb]

Hello Community,

And I would maybe allow using of alternative calls: #cmsimple...#, {{{...}}} or hi_pdscripting. Each of it can be preferred from specific reasons (e.g. if the website is to be mainained by author himself, or if it is made for an experienced user, or for someone who is poorly able to write the content.

Well, having different levels of possiblities for more or less experienced users is reasonable. But allowing exactly the same possibilities for CMSimple scripting and the plugin call, would mean to have only one level. As it is now, CMSimple scripting allows basically arbitrary PHP; the plugin call only allows to call functions. The latter has the benefit, that in case a unexperienced user misspells the name of a function, the plugin call evaluator is able to detect that there is no such function and give an appropriate error message. Misspelling a function name in CMSimple scripting results in a "500 Internal server error", and the unexperienced user might not easily be able to get back to the page. For instance try:

Code: Select all

#CMSimple PhotoGalerie();#

OTOH the plugin call is more powerful and equally more dangerous than it may seem on first glance. Although it only evaluates a function call, a lot more can be done through the use of complex expressions given as arguments to a (dummy) function. The following, for instance, assigns the global variable $my_var the value 123 without producing any visible output:

Code: Select all

{{{PLUGIN:sprintf('', $my_var=123);}}}

And of course one can produce a "500 Internal Server Error" with the following:

Code: Select all

{{{PLUGIN:sprintf('', doesnotexist();}}}

In the long run we may consider to go further, and actually check the arguments for being simple values, thereby making the plugin call really beginner friendly. For now I suggest to just make assignment of global variables via the argument "trick" mentioned above impossible. I assume this "feature" has been inadvertently introduced, and probably nobody uses it.

However, I've thought about changing the notation of the plugin call again. IMO the simplest and useful solution that is backward compatible to existing plugin calls, is to make "PLUGIN:" not only optional, but to treat anything before the actual function call up to the first ":" as a comment. This way the following will work:

Code: Select all

{{{PLUGIN:FotoGalerie(1);}}}
{{{quoteoftheday();}}}
{{{PF:events();}}}
{{{CF:lastupdate();}}}
{{{Display the 2012 sommer holiday photos:FotoGalerie(17);}}}

I have implement this in r665, thereby being able to greatly simplify the plugin call evaluation. For simplicity I also reversed the evaluation order of multiple plugins calls on the same page (now it's from last to first); I don't expect any problems with it (usually the evaluation order shouldn't matter). Besides this I improved the error message regarding a failed plugin call, which was discussed in http://cmsimpleforum.com/viewtopic.php?f=29&t=5565.

Christoph