Serendipity Forums

[garvinhicking]

Hi!

I just had a small thought.

Wouldn't it be nice, if templates could fake to also contain plugins? The plugin API event hooks are usually seperate through plugin objects that can be bundled easily with a template. So if you want a special plugin to do something that is very theme-related, you would need to bundle an external plugin.

Like, your template couldn't easily add special backend entryproperties to the entrycrfeation, or emit any speciallinks inside the "Linklist" of the s9y adminsuite.

But now it can (recent s9y SVN). You can simply create a serendipity_plugin_api_event_hook() function, that uses the same datastructures like in the Plugin API.Like, you can use the backend_header event name and emit something special.

There should be a LOT of ways to use this to your advantage when creating custom (commercial?) serendipity templates with special functionality.

Since those things to not act as real s9y plugins, they do notshow up in the plugin manager and have no configuratoin.This must be done from the usual template administration instead.

What do you think? Judebert, Don, YellowLED? Yay or Nay?

(I made a sample implementation of thisin bulletproofs config.inc.php)

Regards,
Garvin

[Don Chambers]

I don't quite understand this.... can you elaborate a bit more with a few practical examples how/when this would be used, and why this method is superior?

[yellowled]

Wouldn't it be nice, if templates could fake to also contain plugins?

You just want to turn us template designers into plugin developers!!1

There should be a LOT of ways to use this to your advantage when creating custom (commercial?) serendipity templates with special functionality.

For example?

What do you think? Judebert, Don, YellowLED? Yay or Nay?

I haven't looked at the latest svn snapshot yet, but I have to admit I have no idea what you might possibly be talking about.

YL

[garvinhicking]

Hi!

You just want to turn us template designers into plugin developers!!1

I was afraid my intentions were too obvious. Dang! Judebert, to the rescue?

I'll think of some examples. Magazine templates should benefit from it, as they can offer radiobuttons and other nice stuff on the entry creation screen, interface to the media management (like offer radio buttons for more sizes than just one), it could even hook into core initialization routine to allow templatechoosers, offer custom markup texts (like have some [split] tag that would split an entry into different tabs), ...

I'll be gone again on the weekend, need to wrap my head around some personal matters, so give me some time.

Best regards,
Garvin

[yellowled]

Magazine templates should benefit from it, as they can offer radiobuttons and other nice stuff on the entry creation screen, interface to the media management (like offer radio buttons for more sizes than just one), it could even hook into core initialization routine to allow templatechoosers, offer custom markup texts (like have some [split] tag that would split an entry into different tabs), ...

I have to admit I'm getting a little tired of magazine templates myself, but this sounds very interesting anyway. So it's definitely a yay, I think

YL

[Don Chambers]

.... so give me some time.

Take all the time you need... I still do not understand the concept. Would this in some way lessen the need for custom entry properties?

[judebert]

Don, I think that's part of what he's getting at.

I'll admit to some confusion as well. I'd have to check out the latest SVN to see what's up, and I'm too busy with personal stuff to do that just now.

The original explanation seems to indicate that you could call existing hooks with a new call in your config.inc.php. But that would have very limited use, so I think it's actually supposed to be the exact backwards of that: your template can now listen to events, just like a plugin.

In that case, your template could add a checkbox for "featured entry" on the regular entry form, or for "members only". It could add a button to the editing toolbar. It could add a radio button for "large/medium/small" images, or a drop-down for article type. You could add a media chooser for an entry watermark or background.

Obviously, the majority of what a template might want to do is in the article editing. But the new capability would also let you handle other events, like entry saving and category editing. You could even get redundant and listen to the header event, so the template could output something in the head.

Oooh, category manipulations. Instead of choosing the various category placements in the template configuration, you could add them to the categories themselves. The user would expect to see them there anyway. You'd just listen to the appropriate hook in your config.inc.php, and output a drop-down form so the user could select whether entries in this category were hot news, news, human interest, also-rans, or just headlines.

If I'm right, it's an interesting idea. I can see where it might improve usability. I can also see where it could result in designers doing ridiculous things. But it would make it so templates don't have to interface with extended properties any more.

[garvinhicking]

Hi!

If I'm right, it's an interesting idea.

Why shouldn't you be?

I'm having a hard time thinking of cool examples, but Judebert's got it right: Templates can "listen" to events and interface with anything, that previously only plugins could do. This makes templates much more stand-alone.

I still need to think some more about the absolute killer-feature so that you understand why this might be great.

Regards,
Garvin

[lordcoffee]

Hey that would be nice! I've also thought (and told ) about it.
While I'm still (yes!) porting magazeen template the thought was to provide a possiblity
to force entryproperties. I think there can be a lot more!

[Don Chambers]

I still need to think some more about the absolute killer-feature so that you understand why this might be great.

Regards,
Garvin

Had enough time to think about a way to demonstrate this new concept?

Without this functionality, I am using extended properties for various things. One thing that has never been appropriate for an extended property field is a simple boolean... so, can you demonstrate a checkbox (checked=true, default=unchecked) on the edit entry page... then a way to know if an entry has this checkbox marked or not?

[garvinhicking]

Hi!

Here's a code example:

Code: Select all

<?php
// CODE EXAMPLE:  How to save custom field variables within the serendipity "Edit/Create Entry" backend.
//                Any custom variables can later be queried inside the .tpl files through
//                  {if $entry.properties.special_switch == 'true'}...{/if}
// NOTE THAT THE PROPERTY IS ACCED *WITHOUT* the ep_ prefix! EP_ only comes from entryproperties.

// Helper function to get the variable content of a variable (TRUE/FALSE)
function helper_get_value($special_key, &$eventData) {
    global $serendipity;
    $value = (isset($eventData['properties'][$special_key]) && serendipity_db_bool($eventData['properties'][$special_key]))
            || (isset($serendipity['POST']['properties'][$special_key]) && serendipity_db_bool($serendipity['POST']['properties'][$special_key]))
            ? true
            : false;

    return $value;
}

// Helper function to store form values into the serendipity database, so that they will be retrieved later.
function helper_store($special_key, $special_val, &$eventData) {
    global $serendipity;

    $q = "DELETE FROM {$serendipity['dbPrefix']}entryproperties WHERE entryid = " . (int)$eventData['id'] . " AND property = '" . serendipity_db_escape_string($special_key) . "'";
    serendipity_db_query($q);

    if (!empty($special_val)) {
        $q = "INSERT INTO {$serendipity['dbPrefix']}entryproperties (entryid, property, value) VALUES (" . (int)$eventData['id'] . ", '" . serendipity_db_escape_string($special_key) . "', '" . serendipity_db_escape_string($special_val) . "')";
        serendipity_db_query($q);
    }
}

function serendipity_plugin_api_pre_event_hook($event, &$bag, &$eventData, &$addData) {
    global $serendipity;

    // Check what Event is coming in, only react to those we want.
    switch($event) {

        // Displaying the backend entry section
        case 'backend_display':
            // INFO: The whole 'entryproperties' injection is easiest to store any data you want. The entryproperties plugin
            // should actually not even be required to do this, as serendipity loads all properties regardless of the installed plugin

            // The name of the variable
            $special_key = 'special_switch';

            // Check what our special key is set to (checks both POST data as well as the actual data)
            $is_special = helper_get_value($special_key, $eventData);


            // This is the actual HTML output on the backend screen.
            echo '<pre>' . print_r($eventData, true) . '</pre>';
            echo "Do you want this entry to be special? ";

            echo '<input type="radio" name="serendipity[properties][' . $special_key . ']" value="true" ' . ($is_special ? 'checked="checked"' : '') . ' id="' . $special_key . '_true">';
            echo '  <label for="' . $special_key . '_true">' . YES . '</label> ';

            echo '<input type="radio" name="serendipity[properties][' . $special_key . ']" value="false" ' . (!$is_special ? 'checked="checked"' : '')  . ' id="' . $special_key . '_false">';
            echo '  <label for="' . $special_key . '_false">' . NO . '</label> ';
            break;

        // To store the value of our entryproperties
        case 'backend_publish':
        case 'backend_save':

            // Call the helper function with all custom variables here.
            helper_store('special_switch', $serendipity['POST']['properties']['special_switch'], $eventData);
            break;
    }

}

?>


[Don Chambers]

Is this added to config.inc.php? Will this only work in the latest svn trunk, or should it work in 1.4.1 as well?

You you SURE this is better/easier than supporting different field types in entry properties.. ie checkbox, select, radio? I realize this technique does not require the extended properties for entries plugin, but it sure looks like a lot of effort, especially if a template needed several additional "fields".

[garvinhicking]

Hi!

Is this added to config.inc.php?

Yes.

Will this only work in the latest svn trunk, or should it work in 1.4.1 as well?

Most recent 1.5 only.

You you SURE this is better/easier than supporting different field types in entry properties.. ie checkbox, select, radio? I realize this technique does not require the extended properties for entries plugin, but it sure looks like a lot of effort, especially if a template needed several additional "fields".

At least this is an easy way to implement. Having checkbox, select etc. in entryproperties would require some sort of interface, and I wouldn't know how to do this. And I do NOT want to implement an ugly syntax like the dynamic contactform configuration in there.

Regards,
Garvin

[Don Chambers]

Thanks again Garvin - unfortunately, it might take me awhile to even test this as other priorities have come up. I will get to it ASAP though.

[blog.brockha.us]

With this technique is it possible, to add extra config entries for plugins, too?
This would be nice.. I could implement some "tabbing" for the plugin display than.

Could you give a code example for this, to make it easier to understand (for me), what it's all about, Garvin?

Thanks!

P.S.: But I have the opinion, this could be a very cool enhancement!