Heute ist WorldPloneDay. Überall auf der Welt treffen sich Plonistas und Interessierte. So auch gleich um 18:30 in Innsbruck. Zeit, um sich die neuesten Entwicklungen anzuschauen.

Die neue Release kommt ... bald

Das OpenSource CMS Plone geht nach über 10 Jahren auf die nächste große Version zu. Wie bei vieler freier Software gilt: Es ist fertig wenn es fertig ist. Aber abzusehen ist eine Release im Laufe des Sommers. Die Beta2 steht schon jetzt zum Download zur Verfügung.

Einfacher, Schneller, Effizienter, Schöner

Plone 4 ist viel schneller geworden. Bei der normalen Darstellung einer Seite sind gegenüber dem Vorgänger 3.3 etwa 50% mehr Speed rausgeholt worden. Viel besser ist es für den Redakteur: Es fühlt sich wirklich schneller an!

Das Bedienen macht mehr Spass. Der neue Editor TinyMCE macht auch das Layout von Seiten einfacher und stellt dennoch mehr Möglichkeiten zur Verfügung.

Mit dem neuen Design sieht Plone nicht nur moderner aus. Anpassungen sind jetzt in kürzerer Zeit machbar. Und das Design ist so neutral, daß man es als Intranet gleich so hernehmen kann.

Unter der Motorhaube zugelegt

Unter der Motorhaube hat Plone 4 kräftig zugelegt. Die Programmiersprache Python ist in der Version 2.6 und damit effizienter im Speicherverbrauch.

Der Zope Applikationsserver liegt in der Version 2.12 vor. Viele kleine Verbesserungen im Bereich Effizienz wurden gemacht, aber auch alte Zöpfe abgeschnitten, die gebremst haben.

Die Zope-Datenbank mit Unterstützung für große Dateien (BLOBs) fasst jetzt ohne Problem Videos, Audios oder große Bilder.

Es gibt keine Unterscheidung mehr zwischen großen Ordnern und normalen Ordnern im Plone. Einer für alles!

Details, Details, Details.

Schaut man in den Changelog sieht man viele kleine Verbesserungen. Die viele kleinen Dinge sind es aber, die Plone 4 so viel angenehmer erscheinen lassen. Die Standard-Skalierungen für Bilder können in den Einstellungen definiert werden. Die Grundlagen um Dexterity - ein neues System um Plone zu erweitern - zu verwenden wurden eingebaut. Indexer wurden optimiert. Und noch viel viel mehr.

Wichtige Addons verbessert

Auch die Add-Ons erfahren updates. Das HTTP-Caching-Subsystem wurde vollständig überarbeitet, die Mehrsprachingkeit mit LinguaPlone wurde verbessert. Andere Addons sind grade in Arbeit oder Folgen bald.

How websites were themed before

Almost always Web Designers have to know at least some internals about the templating system if they want to deliver a complete theme, ready to integrate in the particular Content Management System. Often, Web Developers have then to touch the templates again to fit to their and the CMS needs. But most of the time a static HTML template is created by a Web Designer which has to be transformed by a Web Developer to the template language in use.

The only things left to the Web Designer for easy modification are the CSS files. If the Web Designer has no access to the project's development repository, the Web Developer has again to integrate them. In the case of Plone, there is the portal_skins/custom folder which allows theme updates through the web - but all of these cases aren't optimal.

And then there was Deliverance

With Deliverance a revolutionary web design workflow was introduced.

PyPi says: "Deliverance does transformations of HTML to 'theme' pages, similar in function to XSLT but using a simpler XML-based language to express the transformation." [3]

Okay, we could have used XSLT before and besides to the Deliverance development team many kudos also have to go to those XML heads. But i hardly know someone who uses XSLT for theming websites. XSLT alone cant make the design workflow much easier as it is.

With deliverance we create a file where we express transformation rules which define how content-bits from the source HTML (which comes from the CMS system) should replace specific tags or their contents in a target theme (which is the static HTML template) - all in an easily understandable XML syntax. All elements from source and target are selectable via CSS selectors or XPath expressions. The target HTML template should be tagged with id- or class attributes, so that the relevant elements can be easily accessed via CSS selectors.

This allows empowers Web Designers to constantly improve their theme as long as they respect the Deliverance rules which modify their template on the fly.

For more information about writing rules read the Deliverance documentation [4].

Now everything with Dropbox

Dropbox [5] is a commercial file sharing provider which offers 2GB space in the cloud for free. The cool thing with Dropbox is, that it provides a client program which creates a folder in your home directory where local copies of the files from your online Dropbox folder are stored. You can edit those files or create new ones and the changes are immediately pushed to the server - and in the case of a shared folder to all subscribers of that folder. Dropbox also comes with basic versioning support.

The uncool thing with Dropbox is, that the protocol and Dropbox daemon are closed source. The other parts of the Dropbox client are open sourced, at least for Linux.

If the static HTML template is developed in an shared Dropbox folder and integrated into Deliverance via a symlink, all changes to the templates are immediately visible by all developers with that setup - normally within 5 seconds.

And because the need for design changes don't stop with website deployment, this setup can also be used for a live server. All involved parties just have to be aware about the risk of breaking the site if a modified HTML structure interferes with the Dropbox rules. But this allows Web Designers to tweak the design independently of Web developers. And this is cool.

This technique was used for the new website of Grüne Akademie Steiermark [6]. A simmilar setup without Dropbox integration on the server was first used for the Gnome WGO project [7].

Some tips when using Dropbox in your buildout environment

Let's say, the static HTML templates are developed in this folder:

/home/USER/Dropbox/website-template

and Deliverance expects it's template-directory here:

/home/USER/dev/website-buildout/static

To use the Dropbox templates with deliverance, just link the directory like so:

ln -s /home/USER/Dropbox/website-template /home/USER/dev/website-buildout/static

If you don't want to use Dropbox on your live server - for what some heavy reasons can be found - you can check in the files into your favorite Version Control System. Since you may want to check in all the files and not only the symlink, you may have to mount the Dropbox folder instead of linking it:

mount --bind /home/USER/Dropbox/website-template /home/USER/dev/website-buildout/static

Attention: Don't delete your website-buildout directory because this would also delete the Dropbox folder! You have to unmount it before or use the '-o ro' mount option for read only access.

References

• [1] http://www.coactivate.org/projects/deliverance/introduction
• [2] http://en.wikipedia.org/wiki/Dropbox_%28storage_provider%29
• [3] http://pypi.python.org/pypi/Deliverance/
• [4] http://deliverance.openplans.org/
• [5] https://www.dropbox.com
• [6] http://gruene-akademie.at/
• [7] http://svn.plone.org/svn/collective/gnomeweb-plone/
  

If you have to change some portal_transforms settings you can't use a Generic Setup config file for this (as of 2010-03-25, Products.PortalTransforms 2.0b4). But you can change it with python and a Generic Setup import step. Here's how to do it.

Warning: Security: The configuration shown below allows users to use nasty HTML tags which can be a security issue if not used carefully.

Let's say we have a plone package called MY.PACKAGE.

Writing an Generic Setup Import Step Method

This setup method is definded in MY.PACKAGE/setuphandlers.py. It configures the safe_html portal_transform a bit less paranoid about nasty tags and valid_tags, so that content managers are allowed to insert iframe, object, embed, param, script, style, tags and more into the TinyMCE editor:

import logging
from Products.CMFCore.utils import getToolByName
from Products.PortalTransforms.Transform import make_config_persistent

logger = logging.getLogger('MY.PACKAGE.setuphandlers')

def isNotThisProfile(context, marker_file):
    return context.readDataFile(marker_file) is None

def setup_portal_transforms(context):
    if isNotThisProfile(context, 'MY.PACKAGE-PROFILENAME.txt'): return

    logger.info('Updating portal_transform safe_html settings')

    tid = 'safe_html'

    pt = getToolByName(context, 'portal_transforms')
    if not tid in pt.objectIds(): return

    trans = pt[tid]

    tconfig = trans._config
    tconfig['class_blacklist'] = []
    tconfig['nasty_tags'] = {'meta': '1'}
    tconfig['remove_javascript'] = 0
    tconfig['stripped_attributes'] = ['lang', 'valign', 'halign', 'border',
                                     'frame', 'rules', 'cellspacing',
                                     'cellpadding', 'bgcolor']
    tconfig['stripped_combinations'] = {}
    tconfig['style_whitelist'] = ['text-align', 'list-style-type', 'float',
                                  'width', 'height', 'padding-left',
                                  'padding-right'] # allow specific styles for
                                                   # TinyMCE editing
    tconfig['valid_tags'] = {
        'code': '1', 'meter': '1', 'tbody': '1', 'style': '1', 'img': '0',
        'title': '1', 'tt': '1', 'tr': '1', 'param': '1', 'li': '1',
        'source': '1', 'tfoot': '1', 'th': '1', 'td': '1', 'dl': '1',
        'blockquote': '1', 'big': '1', 'dd': '1', 'kbd': '1', 'dt': '1',
        'p': '1', 'small': '1', 'output': '1', 'div': '1', 'em': '1',
        'datalist': '1', 'hgroup': '1', 'video': '1', 'rt': '1', 'canvas': '1',
        'rp': '1', 'sub': '1', 'bdo': '1', 'sup': '1', 'progress': '1',
        'body': '1', 'acronym': '1', 'base': '0', 'br': '0', 'address': '1',
        'article': '1', 'strong': '1', 'ol': '1', 'script': '1', 'caption': '1',
        'dialog': '1', 'col': '1', 'h2': '1', 'h3': '1', 'h1': '1', 'h6': '1',
        'h4': '1', 'h5': '1', 'header': '1', 'table': '1', 'span': '1',
        'area': '0', 'mark': '1', 'dfn': '1', 'var': '1', 'cite': '1',
        'thead': '1', 'head': '1', 'hr': '0', 'link': '1', 'ruby': '1',
        'b': '1', 'colgroup': '1', 'keygen': '1', 'ul': '1', 'del': '1',
        'iframe': '1', 'embed': '1', 'pre': '1', 'figure': '1', 'ins': '1',
        'aside': '1', 'html': '1', 'nav': '1', 'details': '1', 'u': '1',
        'samp': '1', 'map': '1', 'object': '1', 'a': '1', 'footer': '1',
        'i': '1', 'q': '1', 'command': '1', 'time': '1', 'audio': '1',
        'section': '1', 'abbr': '1'}
    make_config_persistent(tconfig)
    trans._p_changed = True
    trans.reload()

Registering the Import Step Method with Generic Setup

Add an import step in MY.PACKAGE/MYPROFILESDIR/PROFILENAME/import_steps.xml like so:

<?xml version="1.0"?>
<import-steps>
  <import-step
    id="MY.PACKAGE-portal_transforms"
    handler="MY.PACKAGE.setuphandlers.setup_portal_transforms"
    title="MY.PACKAGE portal_transforms setup"
    version="1.0">
    <dependency step="plone-final"/>
  </import-step>
</import-steps>

And create the File MY.PACKAGE/MYPROFILESDIR/PROFILENAME/MY.PACKAGE-PROFILENAME.txt, so that this import step is not run for any profile but just for this one.

Calling the Import Step Method in ZMI, portal_setup

Goto your site's portal_setup in ZMI, select your registered profile and import the import step "MY.PACKAGE portal_transforms setup". That's it.

Plone 4 is much faster than Plone ever was. But anyway, you want caching in front of it. So I do.

We're using the chain browser -> nginx -> varnish [-> pound] -> Zope -> (ZEO).

Plan is to

1. let the browser cache as much as possible,
2. let varnish cache as much as possible,
3. let Zope purge pages in varnish after update.

With Plone 4 we get a complete new caching infrastructure. Its plone.app.caching and its dependencies plone.caching, z3c.caching, plone.cachepurging and plone.transformchain.

Now, at time of writing, Plone 4 is beta and all caching infrastructure is alpha. To make it work you better take it from subversion. Take your buildout (with mr.developer as usal) and modify it like so:

[buildout]
# ...
auto-checkout +=
#   ...    
    plone.app.caching
    plone.cachepurging
    plone.caching
    z3c.caching
    plone.transformchain

# ...

[sources]
# ...
plone.app.caching = svn https://svn.plone.org/svn/plone/plone.app.caching/trunk/
plone.cachepurging = svn https://svn.plone.org/svn/plone/plone.cachepurging/trunk/
plone.caching = svn https://svn.plone.org/svn/plone/plone.caching/trunk/
z3c.caching = svn http://svn.zope.org/repos/main/z3c.caching/trunk/
plone.transformchain = svn https://svn.plone.org/svn/plone/plone.transformchain/trunk/

[versions]
# ...
z3c.form = 2.2.0

[instance]
eggs = 
#   ...
    plone.app.caching

Now let buildout run, (re)start your instance and apply the profile of plone.app.caching (HTTP caching support).

In Plones control panel theres now a new item Caching - here you get verbose instructions how to configure it.

Photo by dugspr at Flickr under CC-License.

betabug: ftp is meant for the dumpster of digital technology anyway
hpeter: webdav is already running ... client wants ftp
hpeter: that's why i tried ftp-proxy
betabug: hpeter: state security concerns, ftp is insecure, webdav can be run over https
betabug: only terrorists use ftp
betabug: or worse: if we still use ftp, the terrorists have won!

[Fill in Usual Disclaimers] + You don't want to do this on a shared instance since your're patching the ftp-server of your instance!

I found the suspected code in the __init__ method of zope_ftp_channel in ZServer/FTPServer.py.

You only have to change self.path='/' into self.path='/[whatevernameyouwant]' and your entering path for ftp will change to that url. You can still do a CWD and enter any other directory you have the permission to.

from ZServer.medusa.ftp_server import ftp_channel
from ZServer import requestCloseOnExec
from ZServer.FTPServer import zope_ftp_channel 

def patched_ftp__init__ (self, server, conn, addr, module):
    ftp_channel.__init__(self,server,conn,addr)
    requestCloseOnExec(conn)
    self.module=module
    self.userid=''
    self.password=''
    self.path='/plone'
    self.cookies={}

print "patched ftp root for login redirection"

zope_ftp_channel.__init__ = patched_ftp__init__

I'm certain there is a better, nicer,... way of doing this, that's the nature of a patch ;-)

Picture by Egan Snow under cc by-sa http://www.flickr.com/photos/egansnow/268912449/