Staticpage plugin 2.1

The static page Plugin in version 2.1 has been upgraded to allow password protected, static pages. The password is not remembered in a cookie currently, so you have to enter it time and again.

I hope this new feature is useful for somebody. ;-)

User Permission Groups

I've spent some time to improve the Serendipity User management.

The result of this is a patch which create Usergroups. You can give each usergroup a set of permissions the members are able to perform (like "Maintain Entries", "Maintain Users", ...). The privileges can easily be enhanced. An author can be member of more than one group.

This kind of obsoletes the old "Userlevel" mechanism we have, but I've tried to incorporate the patch in a way so that old plugins depending on the Userlevel should still work, because the 'userlevel' column is not yet dropped.

This mechanism seems to work fairly well, I've also upgrade the entryproperties plugin so that you can define by which usergroups an entry can be read.

Volunteers please try out the patch here: usergroup.diff. Please report any problems you face and if you like the direction where it's headed at. The diff is made against 0.9-alpha2 and will eventually be committed to SVN somewhen next week, depending on the feedback. :-)

Have fun!

Coppermine Plugins

Thanks to Matthew Maude we now have a bundle of two new plugins to integrate with the Coppermine-Gallery:

  • serendipity_plugin_coppermine takes care of embedding Gallery images into your sidebar
  • serendipity_event_cpgselector allows you to insert images from the Gallery into your entries (kind of replaces the internal Serendipity media gallery)

I myself do not use the Coppermine Gallery, but Matthew's plugins look very promising. Feel free to look into the plugins if you're using Coppermine and report your experiences! :-)

Plugins should be available via Spartacus or CVS: plugin_coppermine and event_cpgselector.

Spartacus Problems identified

The debugging modifications I described recently helped to identify a problem with our Spartacus Remote Repository Tool

The problem occured only in a bunch of plugins. Our plugins repository sometimes contains directories with both a sidebar plugin AND an event plugin in that same folder. Even though the Spartacus Plugin properly fetches the files, it would only transfer the name of the directory depending on whether you first installed the event plugin or the sidebar plugin.

An example for this is the My Calendar plugin. In our repository, the files are in a folder called "serendipity_event_mycalendar". If you now installed that plugin via the Sidebar Plugin Manager, Spartacus would create a folder "serendipity_plugin_mycalendar" and of course fail when later trying to load the plugin from that directory.

Thus, an updated version 1.2 of Spartacus now fixes the problem, and returns the right target directory.

Note that you could also bypass the wrong behaviour of Spartacus in earlier versions by just installing the "other" plugin. That means if you tried to install the Calendar as Sidebar plugin, just try it again via the Event plugin.

If you care to notice why we often have plugins as both Event and Sidebar plugins: Basically we enforced a strict separation of those two plugins to make it easier for the user to differ if a plugin is shown in a sidebar, or if it enhances the flexibilities of Serendipity. And because only Sidebar plugins can be "moved around" graphically (via left/right side and placement) it would be hard to make an Event plugin have a Sidebar component and move that around.

Having trouble with Spartacus?

Since some users occasionaly report having trouble with Spartacus and me having too little debugging information on what's going on, I have updated the Spartacus Plugin to be more verbose.

It now tells you what it's fetching and where it's saving the information. Anyone having trouble, please download the plugin here and save it in your plugin directory.

Here's a list of the reasons why Spartacus usually fails:

  • Spartacus has no write privileges to your plugins/ directory. It needs write access to download plugins and store it on your server.
  • Your Server's PHP module/firewall settings do not allow a PHP utility to open socket connections to other hosts and download files
  • The SourceForge ViewCVS service has sporadic problems and timeouts or does not deliver content
  • The plugin is successfully downloaded (so they files are on your server) but the plugin fails to install properly. This may be because your server saves the files without propper read permissions to Serendipity depending on your server setup. Or Safe Mode restrictions do not allow to include a file as the ownership of them differs.

Please alway check those issues above, and then please report any additional problems. I am eager to solve them, but since the problem heavily relies on propper permissions and outgoing connection, it's not always possible for me to fix those errors in the PHP-code.

Thanks for your feedback!

XML-RPC Services

Today I was notified by Marco that there were still some re-occuring problems with our XMLRPC interface, and gave me a link to Tim Putnam, who successfully patched the XML-RPC facility.

I already integrated a patch by him for the 0.8 release, but sadly I was not aware of the forthcoming patches he made so that editing an article should now work via XML-RPC using Ecto, MarsEdit or whatever.

The patch has been committed to our 0.9 SVN Repository. Since I personally do not use the XML-RPC service and like our interface, I'd love to hear some feedback from people who actually use it.

A major thanks of course to Tim Putnam. If you happen to make any more patches, please let me know. :-)