Pupeno has written a nice article titled "COREBlog2 as homepage on Plone", but it's really a general purpose guide to the ins and outs of making folderish content items work as default pages.

Pupeno covers redirects, rewrites (with virtual host monster and Apache), renaming to index_html, and his preferred solution, setting "blog" as a default object.

For what it's worth, I use a VHM rewrite here at ThePloneBlog, and find that it mostly works quite well.  Pupeno says, "I couldn't make it work, so that's all I have to say."  Hmm... all I did was put in an entry in the VHM for my instance that maps "*.theploneblog.org" to "/ploneblog/blog".

PS If you're a manager of planet.plone.org, you should http://pupeno.com/blog/RSS to the list of feeds it aggregates.

I was very excited to get an email from Gareth Bult this morning announcing his release of PloneRSS.  It provides a solid, scalable, smart way to create content items in Plone from inbound RSS feeds, and is based on the lessons he learned in creating CMFFeed last year.

This is a capability that has been missing from Plone until now (although Gareth made an initial run at it with CMFFeed) and I think it's a tremendous boon to sites that need to aggregate content from a network of partners... for example groups running a coalition or collaborative activism campaign, or maybe different departments in a university.  (I wrote about the need for better aggregation tools a while back.)

PloneRSS uses MySQL to store its data, which allows feeds to be cached and shared among many Plone instances.  RSS news items are then transferred into local ZODB's to allow for local searching, etc.  PloneRSS uses cron to automate the refreshing of feeds.  Gareth does a nice job of laying out the rationale behind his design choies in the PloneRSS Design Document.

I'm very excited to start putting this through its paces, and I'm confident that this will be the building block for some really cool collaboration functionality in Plone.  I hope it will get some attention as the Snow Sprinters think about aggregation and syndication.

Thanks, Gareth!

UPDATE: Clarified that items are transferred from MySQL to ZODB, thanks Gareth!

UPDATE 1/26: New URL for project's permanent homepage.

As the plone-site tag shows, Plone is getting a lot of use in the nonprofit community.

Open-source content management is a hot topic in the nonprofit sector right now, and lots of nonprofits (large and small) are extremely interested in what Plone and its open-source peers have to offer.

The 2006 Nonprofit Technology Conference, being held this year in my hometown of Seattle, March 22-24, is a really good opportunity for Plone consultants and developers to mix and mingle with US nonprofit technology users, consultants and vendors.   It might even be interesting for the Plone Foundation to consider doing a vendor booth at the "Science Fair."

My colleagues and I from ONE/Northwest will be there, of course.  And we strongly encourage any Plone developers or consultants who have an interest in the nonprofit sector to consider attending. 

Just got an email from Roland Tanglao of Bryght, inviting me to attend (and publicize!) the upcoming, free Open Source CMS Summit in Vancouver, BC this February 7-9. 

http://www.oscms-summit.org/

There are two tracks to it: CMS specific tracks (a set of sessions specific to a system, eg. the Drupal CMS-specific part will have many sessions since well over 50 Drupal developers and users will be coming and we will have tracks for Plone, Wordpress, etc) and a Cross-CMS track (open source systems can win by co-operating: sessions on templating, identity, spam, etc.).

My understanding is that Vancouver resident Andy McKay will be there to represent Plone.  Figured this should be on the radar screen of the wider Plone community.  The agenda appears very much under development, and the list of topics is quite intruiguing:

Confirmed Topics

• Identity
• Joint discussion on identity solutions
  
• Licensing
•  General licensing issues, GPLv3 (Zak Greant)

Potential Topics

• PHP: something from Rasmus, perhaps PHP5 or APC/caching/performance
• Code repositories: overview by James Blackwell, with specific discussion of bzr
  
• APIs and interfaces
  
• MetaWeblog, Atom
• Search
• UI/Usability
• WYSIWYG Editing
• Privacy
• Template systems and theming
• Spam
• Security
• Internationalization aka i18n
• Best practices for development & deployment
• Business practices and open source
• Large scale and high availability
• Hosting Models
• Partner and Certification Programs
• Media Management
• Data interchange, microformats, and structured blogging
• AJAX
• Databases
• Frameworks and components
• Geodata, mapping, and location
  
• add yours!
  

I just noticed that Alexander Limi and Alan Runyan are going to be keynoters at next month's PyCon 2006, the annual conference of the Python community.   I'll be looking forward to watching the recording.

Over on my personal blog, Will Parks just asked:

I’ve also seen quite a few of your sites on del.icio.us, you do excellent work modifying the layout of Plone. This is my first time at this blog, did you ever write an entry about the customization process you use?

In fact, I haven't.  But I'm really proud of many of the sites my talented colleagues here at ONE/Northwest have launched since we picked up the Plone habit in early 2004.  (You can find many of them listed at Del.icio.us, and you should tag other Plone sites with the "plone-sites" tag, too.  But I digress.)  And there's quite a lot I could say about how we do what we do with Plone, in the hopes that it will be useful to others who are using Plone to build websites that are "cheap, fast and good."

Graphic design

Out of the box, Plone is about the cleanest and most usable CMS out there, thanks to the considerable talents and tender love of Mr. Alexander Limi!  And that's what a CMS should be, clean and usable. But it's a little... plain.

Making Plone look good starts with pure-and-simple graphic design.  (Surprise!)  We actually spend some focused graphic design time on every site we do.  We've got a talented graphic designer, Laurie Kellogg, on staff here, as well as a handful of friends that we call on for bigger jobs.  Some of our clients even bring their own graphic designers to the table.  We're fine with that. Thanks to Plone's excellent separation of content and design code, it's generally pretty easy for us to integrate a visual design into Plone quickly.

Sites we've done have spent from a few hundred dollars to $3000-4000 on graphic design work.  A low-end example is Herons Forever; a high-end example is Snow Leopard Trust, which was designed by our friends at Light Sky Designs.

The bottom line is that making Plone look good starts with some creative talent.

Integrating Graphic Design Into Plone

Integrating the graphic design into Plone is pretty straightforward.  We used to just do it by customizing templates through the ZMI; about a year ago we discovered the joys of filesystem-based skin development, and we haven't looked back.  Today, our basic graphic design integration bag of tricks consists of:

• DIYPloneStyle, which we use as a basis for creating filesystem skin products.
  
• Subversion, which we use to manage our skin products -- makes have multiple people working on stuff reasonably easy.  And it lets us roll back our mistakes. (We make lots.)
  
• A few "stupid python/ZPT tricks" for doing stuff like random banner images or per-section logos.  These just get dropped into page templates.
  

Deeper Magic: Customizing Plone Functionality

Plone out-of-the-box is pretty close to the way our clients want their sites to work, but we've discovered a bunch of tweaks we make to pretty much every site we do.  This includes things like:

• Disabling new member signups (most of our sites aren't public 'community' sites)
• Hiding the login & join links
• Adding an email signup portlet (virtually all of our clients have email newsletters)
• Creating "images" and "files" folders to give users convenient, standard places to put, um, images and files.
• Making Plone use US-style date formatting (e.g. May 13, 2005).
  
• Changing the colophon to read "Powered by Plone | Site by ONE/Northwest"
• And more minor stuff like this...
  

We've wrapped all of these little tweaks up into a product we call "ONENWTemplate" and it gets installed into most of our new sites as soon as we start creating them.  We keep it under version control and are constantly tweaking it in small ways.

"Pigeonhole" -- Extra Special Kung-Fu Power

For our more complex sites, that have lots of content and serve multiple audiences, we have developed a generic product called "Pigeonhole" that is basically some custom and customizable metadata fields that can be applied to content objects.  Things like "audience" and "program area."  These are then used, often in combination with Keywords to help link together related content from across the site, and to build portlets of related content.  Pigeonhole also includes a couple of generic content types we use for many sites, such as a Quotes portlet and a simple Poll/Quiz portlet.

"Kickstart" -- Ultra-Rapid Site Wireframe Build-Out

The final main ingredient in our recipie for a tasty Plone site is a little tool we call "Kickstart."  Technically, it's part of the "ONENWTemplate" product I mentioned above. But it's cool enough (IMHO) to deserve a separate mention. 

As you may have discovered, creating twenty or more folders and all of the portal_action entries for a typical mid-sized site through-the-Plone is just slow enough to be maddening, and doing it via Python is too complicated for most of our project managers (myself included).  So we created Kickstart to bridge the gap. It's designed to make building out a site from an initial sitemap really, really fast.  

Basically, it's just a little textarea box that appears in portal_migrations, which accepts text input that we create in a simple Excel worksheet.   Each row is a folder or page, and can be designated to appear in the main nav, the utility nav or in our Pigeonhole-powered audience nav.  Things can be given parent folders (or root) and it can optionally generate an index page for a folder. 

This lets our project managers rip out site maps in Excel, often working collaboratively with the client, and then cut-and-paste the sitemap into the ZMI to build out the site in a flash.  Then the client can get started putting content into their "clickable prototype" while we work on design integration and any custom programming.

Conclusions

So, there you have it. Our Plone development scheme in a nutshell.  Graphic design, design integration, Pigeonhole-enhanced metadata and Kickstart-powered wireframing.

What I'd like to know is: what kinds of tricks do you use?  Some of you readers are lots more clever than we are. I bet there are lots more 'smart practices' for building simple Plone sites.

As I upgraded my personal blog to WordPress 2.0 today, I noticed that WordPress now bundles a new anti-spam plugin called Akismet.  Akismet is a new web service that promises to can comment and trackback spam.  It's run by Matt Mullenweg, who also is the creator of WordPress.  (How convenient!) 

Akismet is free for personal/non-commercial use ($2200/year for enterprise use) and requires a Wordpress.com API key.  Looks pretty neat.  There already two Python wrappers for it.

I'm thinking that turning one of these Python implementations into a Plone product would be hugely useful for folks (like me) who want to open up comments on a Plone blog to non-registered users, perhaps by using a product like VisitorComments, or any of several blogging products.  When Tim Hicks' plonetrackback product finally pushes through to release, providing site-wide trackback functionality for Plone sites, solid spam protection is going to be even more important, even if you're not running a blog yourself. 

Some might object that nobody should run a site that allows comments by anonymous users, and that trackback is obsolete and thus not worth supporting.  I'm not without some sympathy to those lines of reasoning.   But I think that there are valid use cases for commenting by unregistered users -- requiring registration puts up a barrier to that initial burst of participation in a comment thread, and for some sites, that failure to snare "drive-by" visitors can be a killer.  And I think that trackback, while not used very consistent, can be very helpful in building cross-site links between conversations.  (It would be helped tremendously if there was consistent use of an trackback spam solution, too!)

It's also true that there are few comment spammers targeting Plone right now.  All the more reason to get out in front of the problem by putting together a solid defense now.

Just a thought for those of you interested in Plone's blogging features.