Maintaining sub-blogs: Turn a category into its own blog

Thanks to some suggestions on the forums, especially by Robert Lender and Marc "Col. Kurtz" Gärtner, I have contributed a plugin that allows basic modification of a category into its own blog.

First off, the changes needs a fresh 0.9 SVN checkout, as some important plugin hooks were added to support the changes. On top of that you will need the new plugin serendipity_event_categorytemplates ("Properties/Templates of categories"), which is put into CVS and will be available via Spartacus shortly. You may also need the serendipity_event_sidebarhider ("Toggle Sidebar state") plugin for some advanced usage.

Now let me describe what the plugin does. It adds three new fields to the properties of each category. There you can now define the individual template used when viewing that category, define the amount of entries to be pulled (fetchLimit) and define whether the category is allowed to show entries of the future or not. All those settings override your global default, when a visitor comes to your page.

You need to enter the relative path for the template into the input box - a select dropdown may get available in the future. You can not only choose a different maintemplate ("blue", "kubrick", "moz-modern" etc.) - you can even select a sub-template of your template. Like "kubrick/category1", "kubrick/category2" and so forth. The directory structure of a "sub-template" is the same as a completely different template. So you have all options to fully tweak your templates dependant on the selected category.

Now, wouldn't it be nice to only show certain sidebar plugins on specific categories? For that, you can use the Sidebarhider plugin. You can toggle a list of categories that is allowed to display each sidebar plugin. That means you might want to show the Calendar plugin in Category A, B and C - but not in category D. Or you might want to show a special HTML nugget only in Category A. No problem. :-)

Of course there might be some bugs popping up, which is why it also requires Serendipity 0.9. Feel free to report errors on our bugtracker, the forums, mailinglist or whatever you prefer. I personally prefer the Sf.Net Bugtracker, though.

This extra flexibility is just another brick in the wall of showing the nice featureset of Serendipity, and what can be achieved with plugins. Be inspired and have fun!

Improving the CacheSimple plugin

Today I have committed version 0.2 of the cachesimple plugin. It features:

  1. Use of Conditional GET to prevent "cache busting"
  2. Shortcircuit larger parts of the Plugin API to gain some extra performance.

It is very important for the plugin's full performance that you place the cachesimple plugin as your first plugin in the Event plugin queue. The only plugins that should come before this plugin are

  1. serendipity_event_loginform
  2. serendipity_event_templatechooser
  3. serendipity_event_karma
  4. serendipity_event_phpopentracker
  5. serendipity_event_filter_entries
  6. serendipity_event_randomblogdescription

(if you do not want to loose their functionality, that is)

If the plugin is not first in the queue, it results in all the other plugins being initialised before the cachesimple plugin is able to exit the serendipity Framework.

Feedback, improvements/patches and reports if this breaks any functionality is heartly welcome. The plugin should be available in spartacus tomorrow, you can of course download the diff from the URL location above; this should be available in a few hours.