Plone 4 ist die jüngste Version des "State-of-the-Art" Open Source CMS. Es ist schneller, leistungsfähiger und attraktiver als zuvor.

"Ich habe die schallaburg.at website testweise auf Plone 4 migriert.
Zeitinvestment: 15min
Speed: unfassbar schnell.
Bin voll und ganz beeindruckt!! Plone 4 rocks. Diesmal wirklich!"

Roland Fasching ist Entwickler bei der Niederösterreich Kulturwirtschaft GmbH und betreut dort über 30 Plone Portale.

Was ist neu in Plone 4?

Plone 4 ist seit September 2010 als offizielle Release verfügbar. Es legt das Hauptaugenmerk auf Geschwindigkeit, Skalierbarkeit und Benutzerfreundlichkeit — Alles verbunden mit einfacher Installation sowohl für Neuinstallationen als auch Upgrades bestehender Sites.

Plone ist ein ausgefeiltes, leistungsfähiges und benutzerfreundliches Content Management System. Wenn Sie Plone schon kennen, werden Sie Plone 4 als angenehme und wertvolle Weiterentwicklung entdecken. Die Vorteile sind sofort für alle Benutzer-Gruppen fühlbar – Endanwender, Redakteure und Entwickler werden begeistert sein. Wenn Sie Plone erstmalig entdecken, werden Sie verstehen, warum Plone zwar nicht Mainstream ist, aber wegen seiner herausragenden Eigenschaften von vielen großen Organisationen gegenüber weniger sicheren und unflexibleren Systemen bevorzugt wird.

Plone 4 ist...

• Sauschnell. Plone 4 ist im Allgemeinen über 50% schneller als Plone 3, mit deutlichen Verbesserungen sowohl für Webbesucher als auch für angemeldete Benutzer. Plone 4 ist eine der schnellsten Open-Source CMS Plattformen am Markt.

• Attraktiv. Plone 4 besitzt ein brandneues Standard Design mit dem Namen "Sunburst". Es ist aufgeräumt, minimalistisch, modern und leicht anzupassen.

• Benutzerfreundlich. Das Plone 4 Interface wurde rundum feingeschliffen und aufpoliert, um es deutlich intuitiver zu machen. Plone 4 bietet ab sofort einen neuen leistungsfähigeren grafischen HTML Editor (TinyMCE) an, bietet deutlich weiterentwickelte Voreinstellungsmöglichkeiten und einiges mehr.

• Leicht installierbar und zu aktualisieren. Wie für die vorhergehenden Versionen von Plone, sind downloadbare "One-Klick" Installer für Windows, Mac und Linux verfügbar. In 10 Minuten haben Sie ein Plone auf Ihrem Rechner in Betrieb. Plone 4 lässt sich hervorragend von Plone 3 upgraden.

Unter der Haube

• Plone 4 geht wesentlich effizienter mit Speicher um und kann große Dateien wie Bilder und Videos wesentlich schneller ausliefern.
• Das ganze auf Python & NoSQL basierende System wartet im neuen barrierefreien Design darauf mit Leichtigkeit auf Anwenderbedürfnisse angepaßt zu werden.

Plone Powered

• Große Unternehmen, KMU's, Non-Profit Organisationen, Universitäten und Regierungs-Organisationen um die ganze Welt wählen Plone für ihre Websites, Intranets und Extranets. Immer wenn Sicherheit, Skalierbarkeit, Barrierefreiheit and Anpassbarkeit an die geforderte Struktur zählt — liefert Plone die Basis der Lösung.
• Plone kann Referenzen von Sites von Nokia, Amnesty International, Discover Magazine, der Brasilianischen Regierung, des Nordic Council, der Universitäten des MIT, Harvard & Penn State, Bonn, München, Freiburg und Berlin, die Site der Free Software Foundation und tausende namhafte Referenzen vorweisen.

Mehr infos auf deutsch?

Deutschsprachige Informationen rund um Plone und den von Plone verwendeten Applikationsserver Zope finden Sie auf -> www.zope.de

Tipp: Besuchen Sie die Plone Vorträge auf der DZUG-Tagung der Deutschsprachigen Zope User Group vom 15.-17. September an der TU Dresden -> www.zope.de

Tipp: Die Internationale Plone Konferenz ist 2010 wieder in Europa – vom 25. bis 31. Oktober in Bristol, England -> ploneconf2010.org

Ansprechpartner der BlueDynamics Alliance sind auf der DZUG-Tagung und der Plone Conference vertreten. Wir stehen für Sie zur Verfügung!

Wenn Sie nicht selbst anreisen können: Die Talks der Plone Conference werden live gestreamt und sind in der Regel später online verfügbar.

Vielen Dank an Armin Stroß-Radschinski für die Übersetzung des Original-Textes von plone.org und
die Ergänzung um für den deutschen Sprachraum interessante Informationen.

PyPI - the official Python Package Index is sometimes on its limits and times out. This can happen and I'am sure people do best work to keep it up and running. But from a company-perspective its good to always have the files from PyPI available.

So we need to mirror. And here we need a full mirror. So this includes packages not hosted on PyPI, but on third party servers. In past those links to externally hosted packages made major problems. And yes - murphys law - the foreign server is down when its needed urgent.

Existing Software

So what do we have?

1. pep381client (see PEP 381 'Mirroring infrastructure for PyPI'),
2. z3c.pypimirror (see also its project page),
   
3. collective.eggproxy a caching proxy for eggs from eggservers,
4. yopypi self balancing instance that will redirect your PYPI request when PYPI is down to a default (or predefined) PYPI mirror.

Maybe theres more but thats my most important findings.

pep381client sounds good, sounds official. But it really creates a more or less 1:1 mirror of PyPI. Good? Yes - it is what I expect from a mirror. But not if you want externally hosted packages mirrored as well. But thats exactly what we need for our use-case.

z3c.pypimirror mirrors PyPI plus externally hosted packages and also follows externally hosted index pages. It supports incremental updates. Good? It's more than a mirror, because it aggregates packages - and yes, its exact what our use-case is.

collective.eggproxy is an caching proxy, so it caches only requested eggs. It's nice to speed up local development, but not sufficient for production servers.

yopipy is a nice helper if you usally want to query official PyPI but fallback to a mirror if PyPI has problems.

Setting up z3c.pypimirror

So we decided to set up z3c.pypimirror. After hitting some problems with externally hosted packages I contacted the authors and got write access on the Launchpad project to fix these problems. I released version 1.0.16 and everything described below works with this version.

First: I'am buildout addicted and so here it is: The buildout to set up my mirror, here the buildout.cfg

[buildout]
parts = mirror mirror-cfg

[mirror]
recipe = zc.recipe.egg:scripts
eggs = z3c.pypimirror

[dirs]
recipe = z3c.recipe.mkdir
mirror-base = PATH/TO/mirror
mirror-files = ${:mirror-base}/files
paths = 
    ${:mirror-files}

[mirror-cfg]
recipe = collective.recipe.template
input = ${buildout:directory}/pypimirror.cfg.in
output = ${buildout:directory}/pypimirror.cfg
url = http://pypi.MYDOMAIN.TLD
mirror-path = ${dirs:mirror-files}
lockfile = ${buildout:directory}/mirror.lock
logfile = ${dirs:mirror-base}/mirror.log

And the configuration template pypimirror.cfg.in:

[DEFAULT]
# the root folder of all mirrored packages.
# if necessary it will be created for you
mirror_file_path = ${:mirror-path}

# where's your mirror on the net?
base_url = ${:url}

# lock file to avoid duplicate runs of the mirror script
lock_file_name = ${:lockfile}

# days to fetch in past on update
fetch_since_days = 1

# Pattern for package files, only those matching will be mirrored
filename_matches =
    *.zip
    *.tgz
    *.egg
    *.tar.gz
    *.tar.bz2

# Pattern for package names; only packages having matching names will
# be mirrored
package_matches = 
    *

# remove packages not on pypi (or externals) anymore
cleanup = True

# create index.html files
create_indexes = True

# be more verbose
verbose = True

# resolve download_url links on pypi which point to files and download
# the files from there (if they match filename_matches).
# The filename and filesize (from the download header) are used
# to find out if the file is already on the mirror. Not all servers
# support the content-length header, so be prepared to download
# a lot of data on each mirror update.
# This is highly experimental and shouldn't be used right now.
# 
# NOTE: This option should only be set to True if package_matches is not 
# set to '*' - otherwise you will mirror a huge amount of data. BE CAREFUL
# using this option!!!
external_links = True

# similar to 'external_links' but also follows an index page if no
# download links are available on the referenced download_url page
# of a given package.
#
# NOTE: This option should only be set to True if package_matches is not 
# set to '*' - otherwise you will mirror a huge amount of data. BE CAREFUL
# using this option!!!
follow_external_index_pages = False

# logfile 
log_filename = ${:logfile}

Add a bootstrap.py to the directory and run

python2.6 bootstrap.py
./bin/buildout

. If the process stops for some reason just re-run it, it won't download packages twice.

./bin/pypimirror -I -c -v pypimirror.cfg

Finally add a cron-job to fetch the updates - i.e. every two hours, like so:

* 0-23/2 * * /PATH/TO/pypimirror/bin/pypimirror -U /PATH/TO/pypimirror/pypimirror.cfg

Now a webserver is needed. I took nginx and added a site to /etc/nginx/sites-enabled:

server {
        listen IPADDRESS;            
        server_name pypi.MYDOMAIN.TLD;
        location / {
            root /PATH/TO/mirror/files;
        }
}

 Reload nginx and done! The mirror is ready.

Using the mirror

I use buildout almost everywhere. To use the mirror simple add one line to your buildouts main section:

[buildout]
....
index = http://pypi.MYDOMAIN.TLD
...

For more information consult the official docs.

Image Green Tree Python by nasmac (Ian C) under a CC-License edited by Jens Klein

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/
  

So why?

1. repoze.bfg rocks for building webapps.
   
2. zc.buildout rocks for configuring controlled Python environments.
3. gunicorn rocks as wsgi-server, because its simple, pure python and serves hundreds to thousands of concurrent requests to fast clients and (slow) backends.

If you try this you need an webapp. I consider you have one, othwerwise take one of the example apps from the repoze.bfg tutorials. For this example I consider you have your app as an egg in a subversion under http://foo.org/svn/myapp/trunk

Create some directory and cd into it.

Copy your webapps paste.ini file to the new directory.

Copy a bootstrap.py to the new diretory. I prefer the one from distribute.

Then create a buildout.cfg with following contents:

[buildout]
parts = gunicorn gunicornctl
extensions = mr.developer
sources = sources
always-checkout = force
auto-checkout = *

[sources]
myapp = svn http://foo.org/svn/myapp/trunk

[var]
recipe = plone.recipe.command
dir = ${buildout:directory}/var
command = mkdir ${:dir}

[gunicorn]
recipe = zc.recipe.egg:scripts
dependent-scripts = true
eggs = 
    myapp 
    eventlet 
    gunicorn

[gunicornctl]
recipe = collective.recipe.template
mode = 755
input    = ${buildout:directory}/gunicornctl.in
output   = ${buildout:directory}/bin/gunicornctl
pidfile  = ${var:dir}/instance.pid
logfile  = ${var:dir}/instance.log
pasteini = ${buildout:directory}/paste.ini
workers  = 2

 create another file gunicornctl.in containing:

#!/bin/sh

# Specify path variable
PATH=/sbin:/usr/sbin:/bin:/usr/bin

# Kill me on all errors
set -e

case "$1" in
  start)
    ${buildout:directory}/bin/gunicorn_paster -D \
        -w ${:workers} \
        -p ${:pidfile} \
        --log-file=${:logfile} \
        ${:pasteini}
    ;;
  stop)
    kill `cat ${:pidfile}`
    ;;    
  *)
    echo "Usage: $0 {start|stop}"
    exit 1
    ;;
esac

Now run buildout with
/path/to/python2.6 bootstrap.py -d

Next run build with
./bin/buildout

Then start your app with gunicorn
./bin/gunicornctl start

Watch the logifle using
tail -f var/gunicorn.log

Take you webbrowser and connect to the address given in your paste.ini. I.e. http://localhost:8080.

And stop it later with
./bin/gunicornctl stop

Do not expose Gunicorn to the web. You clients are somewhere in the internet and slow. Let NGINX be Gunicorns fast client. Read more about deployment and how to configure it.

Image "Unicorn Sign" at Flickr by Steffe under a CC-License