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

Allow comments for registered users only

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.

Custom Permalink URLs, Part 3

The patch for custom permalinks proposed last week has now been committed to our 0.9-alpha SVN. For those of you who use the nightlies, this might have a huge impact on your blog. Please report any bugs you may face (or also positive reports) to our php-blogs-dev mailinglist or here in the comments. I will try to take care of them as soon as possible.

SQL Speedup patch / Plugin API performance

Thanks to Isotopp I discovered today that the load_plugin() method of the Plugin API did perform some unneccessary SQL queries when loading/searching for a plugin.

I have created this patch (can be applied to both 0.9 SVN and 0.8.1) - it will properly detect the plugin path setting and now only perform the SQL query when needed.

This should cut down one SQL query per plugin that is loaded; in a standard install with 14 plugins this is 14 less SQL queries. But thanks to MySQL and other caching systems, the impact of those superfluous small queries is not that large.

The patch will be part of a possible 0.8.2 release and has been committed to the CVS backport and SVN branches already.

(Update: Some more changes to the patch)