plonewars.com

There is a rule number one: everything must be stored in svn. If you have pieces of configuration…

How I structure plone projects

Originally from [Technorati] Tag results for plone

L’Associazione ZOPE Italia, con il contributo della Regione Abruzzo, organizza OPEN-L, la prima Conferenza Nazionale sul Software Libero e Plone per le Aziende, gli Enti e le Pubbliche Amministrazioni. L’evento si svolger  il 9 giugno prossimo a Pescara, presso la facolt  di Architettura dell‘Universit  G. D’Annunzio, in viale Pindaro dalle ore 9.30 alle ore 13.30. Tutte le informazioni re…

Report post as spam 
Help Strategicboard stay spam free by reporting spammers

Conferenza Nazionale su Plone per le Aziende, gli Enti e le Pubbliche Amministrazioni.

Originally from Strategicboard spam free blog search results on plone by TF

I’m really excited that Dave Fowler got funded by Google’s “Summer of Code” program to do some work…

Improving Plone Comments

Originally from [Technorati] Tag results for plone

Martin Aspeli

plone.org — plone.org

Originally from del.icio.us/tag/plone by tan.yi.1976

Setup using GenericSetup — plone.org

Originally from del.icio.us/tag/plone by tan.yi.1976

I’m really excited that Dave Fowler got funded by Google’s “Summer of Code” program to do some work on Plone’s comments system.  It’s not received much attention in the past few releases, and although it’s still pretty solid, it’s starting to show some wear around the edges.  With Plone 3.0 almost out the door, and sporting lots of cool UI tricks (most notably KSS), it’s a great time to look at overhauling the comments system.

Following are some thoughts that I’ve had over the past couple of years of using Plone, and drawing on ONE/Northwest’s experiences implementing around a hundred public-facing Plone sites for small nonprofit organizations.  I offer them with the hopes that Dave and others who will be working on Plone’s comments this summer might find some inspiration and ideas.

Things worth looking at

Two existing Plone add-on products that add features to Plone’s commenting systems are PloneComments from Quintagroup and EasyCommenting from Kai Diefenbach.

PloneComments extends Plone’s existing comments by enabling:

• Comments from anonymous users
• Moderation of comments
• Email notifications (to owners/managers) of new comments

All of these are welcome features that address obvious gaps in Plone’s “out of the box” comment experience.  qPloneComments has quite a few rough edges in its UI — most notably that it takes a lot of clicks to go from an email notification to actually moderating a comment.   I can’t offer an opinion about whether its implementation is technically sound, but it’s worth a close look to see whether its ideas could be integrated into a new solution.

EasyCommenting is a more ambitious attempt to re-implement commenting.  Kai appears to have recently started again with Zope 3 technologies, so it’s not quite clear where this project sounds.

Things I’d Like to See

Most of the improvements I’d like to see in Plone’s commenting system revolve around two related goals:

1) Making it easier for site visitors to comment without having to register and log in, while…

2) … Resisting comment spam.

While not every site requires (or desires!) unauthenticated users to be able to comment, it’s an extremely common feature of blogging software and of other lightweight CMS systems, and for good reason: it knocks down a big psychological barrier to participation for a casual site visitor. 

I’ve been using WordPress for a couple of years now (but don’t worry, Plone is my first love! .  As widely used, dedicated “blog” software, it puts a lot of effort into its commenting system, and the WordPress team have done a good job of making it possible to allow commenting by non-authenticated users without opening the floodgates to spam.

WordPress does this in a couple of interesting ways.  First, the Wordpress team have actually developed an extremely effective spam-detection service, known as Akismet.  Akismet is not open-source, nor is it free for commercial use, but it works really well, and has a simple, well-documented API along with a Python library.  Although it wouldn’t be a silver bullet, implementing an Akismet module for the Plone commenting system would be a quick, easy and effective way to fend off a lot of spam (both comment spam and trackback spam, too!).  I’ve written a bit about this before.

A second thing that WordPress does is to ask each anonymous commenter for their email address.  It doesn’t show that address to the public, but it remembers it, so that if their comment is approved, it can automatically approve additional comments from that email address.  This feature is optional, and only available if comment moderation is enabled. It’s a very simple and effective way to make sure that your “frequent commenters” don’t have to get moderated for each comment.

A third thing WordPress does is to send out rich hyperlinks in its email notifications of new comments.  Each comment notification message has three links:

1) Delete this comment
2) Approve this comment
3) View the comment moderation queue

The URLs for options 1 & 2 immediately perform the specified action.  Option 3 takes you to a moderation screen.

On that moderation screen, WordPress implements another simple-yet-highly-effective user interface trick that Plone would do well to emulate.  It has javascripted radio buttons to:

1) Mark all queued comments for deletion
2) Mark all queued comments as spam (which deletes them and notifies Akismet)
3) Approve all queued comments

These javascripted buttons change the equivalent selection radio buttons on each individual comment all at once, and the comment manager can then individually mark any exceptions, then hit submit to execute the entire batch of approvals.

This simple scheme makes it possible to efficiently moderate hundreds of comments with just a few clicks.

Captchas?

I’ve not used them much, but some folks are fond of using captchas to differentiate legitimate commenters from spam-spewing robots.  PloneCaptcha and Plone Captchas are two (different, but similarly-named) products that implement captchas for Plone. 

Plone co-founder and usability guru Alex Limi has pointed out the potential for accessibility issues with captchas in the past.  These concerns are real, but modern captcha systems seem to deal with them effectively, either by presenting an audio alternative to an image-recognition task or by using a simple logic puzzle (e.g. what is 2 plus 5?) instead of an image recognition.

I’ve noticed that Drupal (a popular PHP-based CMS) has an add-on product that implements simple logic captchas as described above.  I suspect this would provide a simple, accessibility-compliant captcha mechanism that might be very effective for preventing comment spam, especially in the absence of Akismet.

Other random ideas

Here are a few other brainstorms that might be worth considering, although I think they’re all less important than the ideas I mentioned above.

1. Include a (small) user portrait alongside authenticated users’ comments.  Ploneboard does this (although the portraits are a bit large), and it looks nice.

2. Visually highlight comments by the document creator or owner.  Many blogs to do this, and it does a nice job of making the blogger’s responses to comments stand out.
3. Include a Zope 3-style “recent comments” portlet as a user-addable portlet.  This could be based on the existing “recent items” portlet.  (I’m actually rather shocked that we don’t already have one!)
4. Include a “comments on this item” RSS feed for objects that have comments.  This makes it easy for interest parties to monitor comments on an object over time.
5. Include an RSS feed for all site comments” on the site homepage (or maybe on all pages).  Again, this makes it easy to follow all the discussion on a site.

Do you have ideas about how Plone comments could be better?  Share them here, in the comments!

Jon Stahl: Improving Plone Comments

Originally from Planet Plone by Jon Stahl

There is a rule number one: everything must be stored in svn. If
you have pieces of configuration outside of svn, you’re in for
pain. I’ve had to work my way through Products/ directories trying
to figure out which versions were in there. version.txt helps a bit,
but once it is a version of which you cannot find a .tgz, you’re done
for. Or, if it is an svn checkout: is it safe to update it or does it
need to be a specific revision?

Which pieces of configuration should you include? Well, which products
are installed. Which plone version. The apache config file(s). Perhaps
an awstats config. A cronjob for /etc/cron.d. Those config files
are simple: just store them somewhere in your svn, I’ll get to the
location later. For the list of products and the plone version you’ve
got basically three choices:

• A "readme" file that lists your plone version and add-on
  products. You’d better keep those up to date!
• Put the zipfiles in some svn directory of your choice. Your svn
  repository won’t really like that, neither the backup of your svn
  repository.
• Put the list of products (and download locations) in some script
  that downloads and installs them.

I use the last method, by using instancemanager. Basically a config
file like this (URLs shortened to keep ‘em on one line):

archive_sources = [
    {'source': 'qPloneGoogleSitemaps-0.3.0.tar.gz',
     'url': 'http://surf..../qPloneGoogleSitemaps-0.3.0.tar.gz',
     },
    {'source': 'RedirectionTool-1.1.tar.gz',
     'url': 'http://plon.....s/1.1/RedirectionTool-1.1.tar.gz',
     },

Instancemanager will reliably download those files and put them in
your Products directory. Works for bundles, too. A good custom shell
script or stuff like buildout can also help here. Nobody has to wonder
which products and which versions to use: just look at (or use…) the
config file.

For a small project with just one custom product, I normally add
an instancemanager directory inside that custom product. Which, of
course, is in your svn repository. In there, I put the instancemanager
config with the specification of the project (other add-ons, plone
version, zope version). Perhaps another directory for some
documentation and an apache config file.

For a big project, you’ll probably end up with a couple of specific
svn checkouts of add-on products and a set of custom products. Svn
bundles to the rescue! I normally make sure I only have to grab one
svn checkout to set me up completely. Inside that checkout I’ve got
the following directories:

myproject/externalproducts

An svn bundle of the external add-on products for which I need a specific
checkout instead of a regular zip file. Perhaps a branch on which I’m
doing fixes. Or a specific revision. The exact configuration is
again explicitly in svn in this way!

myproject/products

An svn bundle of the add-ons I’m developing myself. Project-specific
stuff. It somehow is handy to differentiate between "products" and
"externalproducts" as you’ve got to take greater care with changes
in products that other people are using than with changes in your
own project-specific products. Put your DIYplonestyle theme in here,
for instance.

integration

Here’s where I put the configuration for bigger projects. I normally
subdivide it further into subdirectories

integration/instancemanager

Instancemanager configuration files. Often a projectname.py for
regular development and a specific production.py with the current
stable production server’s configuration.

integration/apache_etc

The apache configuration files.

integration/cron_d

Some cronjobs you want to put in to /etc/cron.d

integration/doc

Documentation for the whole project. Explanation of how to set up
the server. Backup/restore documentation.

This way of setting up projects slowly developed during a few years of
setting up projects like this. We also use it at zest software for
the majority of our projects. One thing that’s not fully crystallized
yet is how to deal with production bundles and development
bundles. The needs for this tend to differ wildly per project. Some
only do an update once every two months, others try out a quick change
in preview and put it into production right away as they need a more
rapid cycle.

I hope this is of help to some people. It would be interesting to hear
of other setups or recipes. If you don’t have a blog yourself, feel
free to email me.

Reinout van Rees: How I structure plone projects

Originally from Planet Plone by reinout

Daniel Nouri’s Blog : /

Originally from del.icio.us/tag/plone by cjohansen

Busman’s Holiday: Setting up Plone on Ubuntu Feisty Fawn

Originally from del.icio.us/tag/plone by gerd.storm

Fraterdeus Web Log - Apache RewriteEngine Rules for Plone

Originally from del.icio.us/tag/plone by a.rodier