In this post, I talked about the idea of an open-source business plan website.

I’m planning to set it up with a few components: a Digg-like voting system for entering ideas and voting on them, a random idea generator along the lines of my cheese plate generator, and possibly a Wiki for writing more detailed notes, which is tied in with the voting system (e.g. each idea has a Wiki page assigned to it upon creation). All of this will be public-accessible so other people can use this repository if they want.

The only piece I wasn’t sure about how to do was the Digg-like system. There are quite a few CMSes out there for this, including Pligg and Hotaru (a Pligg fork, as it turns out). Pligg seemed like the right thing to use - the default install looks great, and it’s set up to do exactly what I want out of the box. There didn’t seem to be too much flexibility beyond that, but I thought that was probably OK.

I thought I’d write up the rather frustrating resulting experiences I had so that others can take them into account when making the same decision I did. Note that I’m certainly not a PHP genius, though I do know enough about it to write functional hacks to do pretty much whatever I want. That will be the perspective of this article - smart hackers may not be too sympathetic to my complaints!

Installation and initial testing

Pligg has a fairly slick install script so getting it on the server, and setting it up, was easy. I submitted a test story; so far, so good.

Next, I attempted to modify the default layout so that I could exclude some of the default items that Pligg wants to show on every page (Top News, Top Comments, things like that). These aren’t appropriate for what I’m trying to do, which is create a news voting site with encyclopedic elements.

Pligg’s templating system

In Drupal and Wordpress, you can literally use checkboxes for this sort of thing. If worse comes to worst, it’s pretty easy to find the code that generates the offending elements, and change it or switch it off.

No checkboxes in Pligg. So I looked for ways to simply comment out the appropriate PHP and HTML for the page elements I didn’t want. But… where do I find the file that controls this? Ah, templates? Yes. OK. Which one? I’ll guess “sidebar.tpl”. Not that one. Alright, maybe “sidebar2.tpl”. Something like this looks promising…

The {bracketed stuff} in the code is the result of the templating system that Pligg uses, called Smarty. Actually, to be more specific, it uses a Smarty variant called “Template Lite” which as of this writing has a non-functional site. The idea behind Smarty is that it makes the template layouts more versatile and easier to use.

And yet you’ll notice that in this case, the bracketed tag takes the place of text like “Top Users” or “Top Comments” in the HTML, which means that I can’t figure out what to comment out of a file like this. Instead, you have to find a different file that contains the definitions for these tags.

I could see how this would be very useful if you are running a site in several languages. All the text is centralized in one file, so you just translate it, and you’re set.

But if you are running a huge, multilingual site, are you really using Pligg as your CMS? And if, on the other hand, you are just starting out, do you need this additional complexity? Here’s what Smarty says about when it should be used:

Smarty is commonly a good fit when the roles of developers and designers are separated.

I would be interested to know how often this happens in Pligg’s target market. And why Wordpress (for example), doesn’t work the same way. As for for me, I found constantly switching between PHP files to make edits incredibly painful.

The same problems happen with what are called “hooks” that let you make Pligg do certain things when particular events are triggered (say, a story is submitted). They look like this:

{checkActionsTpl location="tpl_pligg_sidebar_end"}

But where do you find the code that gets executed at this location? Well, first you have to find what .php file corresponds with the “tpl_pligg_sidebar_end” location, and that list of indices may not all be stored in one place - I resorted to searching the entire code tree each time. Then you have to open the correct file, whichever one that may be, and start editing.

This is not the first time I’ve seen a templating system; I know how to deal with Drupal and I’ve written (very simple) modules for Wordpress. But there is something about the way Pligg implements this that is frustrating to use. The amount of work, to make even simple changes, seems high. And the system for doing it is weirdly proprietary, which means very little support is out there.

Changing site mechanics

I moved on to trying to tweak the submit process to my liking. Basically, what I wanted to do is have a one-step submit in which a URL is submitted together with everything else. (I didn’t want to turn the URL submission off completely, which is an option provided in the settings).

I mean, this shouldn’t be too hard, right? I can just move the URL input to the page with all the other inputs, and modify the code to look for that form input during submit step 2 instead of submit step 1.

I couldn’t figure this one out either. For some reason, Pligg won’t let you move the URL acceptance and validation code to the do_submit2() function. Compounding the problem was that the templating engine seems to do some fairly aggressive input / output filtering, or is perhaps just broken, so I couldn’t reliably get debugging information (such as variable values) out of my scripts while I was working on them.

I was defeated, I am guessing, by not following the correct templating syntax, or by re-instantiations of the Link or Smarty objects in between submission steps. But in Drupal, I’ve done things like this by moving a few lines of code around. Not ideal, probably, but it works. And that’s all I need it to do - work.

Changing the front page around

I was frustrated that I had now accomplished very little. But I wanted to get the project done, so I lowered my expectations and moved on. One other thing I wanted was a front page “tag cloud”, like the “ingredient tags” entry I have on this blog. There is a “tag cloud” sidebar item, but it’s just a link as far as I can tell.

Well, I thought, I ought to be able to modify the full-page tag cloud so that it just produces tag cloud content - a few words in varying sizes, with no additional HTML surrounding them. Should be OK, right? By this time I had learned that Smarty has an {include_php} directive that ought to allow me to run the output for that page.

Nope. No matter what I did, “tag cloud” was just a plain link to the tag cloud page. I tried taking out lots of code, putting it back in, echoing and var_dumping for hours. Pligg didn’t want to deal with it. Again, in Drupal and Wordpress I’ve never had a problem moving code around and having it work well enough. But there is something going on with Pligg that doesn’t allow you to deviate from what’s already set up.

Conclusion

At this point, I figured it was time to cut my losses and walk away. I did some research and found that someone had actually written a social voting module for Drupal, called Drigg. While I’m not sure how actively it’s maintained, it seems to work just fine for now.

Being based on Drupal has immense advantages - much larger community (I never did find anybody else who was trying to do what I was trying to do with Pligg), free (rather than paid) modules, and of course I already knew my way around Drupal.

Three hours later, I had a fully-functioning prototype of my site, with everything (almost) just as I wanted it. Thank goodness I gave up on Pligg when I did; I saved myself hours of frustration by doing so.

I think what was so frustrating about Pligg was that all of this complexity seems…  completely unnecessary. I just couldn’t see what all of the extra work gives you that compensates for the extremely difficulty modifying and understanding the code. WordPress is arguably much more capable overall than Pligg, even though the feature set doesn’t overlap, and yet it’s pretty darn easy to write modules for it, move things around, etc. Same with Drupal, for sure.