Development - 22 – Serendipity

As already foretold in this entry, I have committed a patch to our 0.9 SVN trunk which enables Serendipity to have multiple group permission privileges.

You can read more in my posting on the mailinglist.

The bottom line is: We now need some bug- and QA testers who need this functionality and are willing to testdrive it. Huge problems are not expected, but the more people testing it, the better.

On a related sidenote, I have added a "Current state of SVN" box in our blog on the right hand side. There you can easily spot in the future if the current nightlies are considered stable or unstable. Thanks a lot and have fun!

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!

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.

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!

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. :-)

After this feature was requested many times on the forums but I always disagreed to it, I finally got over myself and implemented an updated version of a plugin to support that.

The former user self-registration plugin serendipity_plugin_adduser as been enhanced. It can now be configured to add users that are only allowed to log in and maintain their configuration; those users cannot post entries. To support that you will need the latest changes committed to the 0.9 SVN branch.

A new event plugin serendipity_event_adduser has been added as well. This plugin takes care to forbid users posting comments if they are not logged in. Also the plugin directly offers an interface to let users register themselves.

When a new user registers, a pending account will be created for him and he will get an activation Email. As soon as he confirms a link, the author account will be created.

If you enable the feature that only allows posting comments to registered users, only logged in users (cookie needed!) will see the "Post entry" form. Others will see a message to get themselves an account. Also note that even though users may still enter their username and Email, it is resetted to their real username+email they maintain in their profile.

Of course this is a bit beta-ish once again, so I'd love to hear feedback about it.