Customizable Plugin Sidebar locations

For ages, Serendipity has given users the flexibility to move around plugins in the left/right sidebar. Two sidebars were a usual concept for blogs in the days past, and for surely some more days to come.

But some themes, like the Hemingway theme give people a different approach to surrounding their blog content. The result of a porting discussion on the forums lead me to patch our plugin API.

Serendipity 1.1 already support custom theme options (like special navigation bars, colorsets etc.), and what came out of my recent patch is the functionality to define multiple custom sidebars.

With this, you can add a "top", "bottom", "middle" or whatever else sidebar locations to your themes, and put them in the smarty templates using the function {serendipity_printSidebar side="XXX"} wherever you like.

It's as easy as adding a file to your template, add a $template_config array value like this:

$template_config = array(
       'var'     => 'sidebars',
       'title'   => 'Sidebars',
       'type'    => 'string',
       'default' => 'left,hide,right,bot'
(or modify existing config arrays) and save the file. When you now enter your plugin configuration section, you will see each of the sidebar locations next to another, so that you can move around plugins from one to the other location.

There are two things to watchout: If you use locations other than 'left' and 'right', other templates may not output plugins that were put to a location like 'bot'. So if you switch templates, you must watch out on where you put your sidebar plugins into.
The other thing to pay attention: Only use "," to separate the sidebar item names (no spaces!) and never use more than 6 characters for your locations.

Please have a test with these new possibilities, tell us if you like it, and show us the results you made with it!

This functionality has been implemented into recent Serendipity 1.1 nightlies (currently 1.1-beta4)

Plugin Execution Permissions

Despite my downtime, I was able to find the time to commit some changes I was having up my sleeve to the 1.1 beta version.

It involves, what many people have asked for: Specify, which user/usergroups are able to have access to certain plugins. My standpoint until now was, that plugins should implement the versatile permission management of Serendipity, available since version 0.9.

However, reality got me when I saw that no plugin was really ported yet to use that permission management setup to provide custom permission sets. But people wanted to have the ability to say "The staticpage plugin is only available to user XY".

Thus, I implemented a rather hackish way into the groupmanagement: You can now specify complete plugins, or specific event hooks which are forbidden for a usergroup. This way, you can say that group X is not allowed to execute a 'Staticpage' plugin.

This approach should work quite well for many usage scenarios - the upside is, that all old plugins are supported instantly. However, the neater approach of course is to modify plugins so that they provide their own permissions for more granulate control of what you want to achieve.

To enable this functionality you must first enable the option "Enable Plugin ACL for usergroups" in the serendipity configuration. The reason why you must explicitly enable this is, because those plugin checks decrease the performance of the plugin API. Every executed plugin hook must be checked against the blacklist, and those checks would hurt bloggers that do not intent to use this feature. To satisfy everyone, you have an option for this.

You can try the feature in the nightly builds created today, or using an SVN checkout. The feature is contained in 1.1-beta4.

New Serendipity Releases: 1.0.1 and 1.1-beta1

The Serendipity Team is proud to offer two new releases:

Serendipity 1.0.1 addresses a few minor bugfixes in the otherwise very well-received 1.0 stable release. Those are related to utf8-iconv conversion on older PHP setups, sending comment mails to users without an email address and a WYSIWYG image insertion issue.

The most important fix and reasing for the 1.0.1 release is a security issue that has been reported by Sebastian Nohn using the cool new Security-Scanner Chorizo. The only reported issue by Chorizo was the possibility of Users who could add plugins to the installation (usually only Administrators) to insert file references to other arbitrary PHP files that are then included. We feel this is a minor impact, because usually all administrators already would have full access to the PHP filebase and could include remote files with different means. Also note that users with safemode/open_basedir restrictions would not be affected by this.

Users with multi-users installations, giving plugin access to untrusted users are urged to upgrade to the latest release!

Serendipity 1.1-beta1 brings the long awaited new features to a first public release. The 1.1-alpha versions have been tested in the past quite well and are thought to run quite stable.

The 1.1 version brings those major new features (also see an earlier blog entry for details):

"New Serendipity Releases: 1.0.1 and 1.1-beta1" vollständig lesen