Pete and Andy try Plone 7

[tisto]

ToDo

• Download a container image and fire it up / Plone Distribution?
• Support uploading your own logo TTW #291 Allow uploading your logo
• Allow customizing the seconday navigation entries (Log in, Sitemap, GitHub) #302 Allow changing the header and footer information
• Allow choosing between the internet and intranet header #304 Choose between Internet and Intranet header
• robots.txt can't be set via the control panel #319 Robots.txt from control panel (ongoing)
• tbc

Original Blog Post

Blogpost by Martin Aspeli from 2009:

PETE AND ANDY TRY PLONE 4 by Martin Aspeli

A tale from the future of Plone. To avoid any confusion: This article has nothing to do with the actual release now to be called Plone 4. It was written as a thought experiment to see how I'd like Plone to be in the future.

Pete and Andy are two IT consultants, both of them generalists. They know a bit of Java, a bit of HTML and CSS, but not very much Python. They've never used Plone before.

One day, their manager tells them to find a CMS for a customer project. Some quick Googling and a Power Point presentation outlining the possible contenders later, they settle on Plone, because it's slick-looking and seems to do most of what they want out of the box.

They set about getting to know the system, when they are told that the deadline has been moved forwards and they now need to deliver a working system in two weeks. Yikes!

The clients' requirements are of course highly confidential, but basically they want:

A custom-branded public website
A custom-branded editing environment where their staff can make updates to web pages, publish news and events and maintain the site structure
Some forms for capturing some basic information from the public
A security model with internal and external users being granted various levels of access and various collaborative tools, depending on their roles
Some custom content types, with custom workflow, to capture project-specific information and share it among relevant users
Of course, this is all a piece of cake with Plone 4. Armed with a good book, the #plone chatroom and a development laptop each, they get going.

Day 1 - setting up a development environment
Following the official Plone documentation, Pete and Andy download an installer for Plone 4. They pick a Developer's Version that includes some development tools and "kickstart" templates. Perfect!

The installer creates them a buildout. The buildout configures the Paste system to orchestrate a web server for running Zope and Plone using the Repoze set of components. It also has options for building the Varnish cache server and CacheFu, it's Plone counterpart, for enabling Deliverance and for creating all kinds of interesting pipelines with WSGI. Not knowing what any of that's for, they just leave the configuration alone and go with a vanilla, stand-alone Plone instance.

Luckily, they already have a Subversion server, so they check the buildout into that. Now they can both share the development environment and work in parallel.

The rest of the day is spent on trial-and-error, getting to know how to start and stop the server, where the data is stored (in the mysterious Data.fs file) and so on. They also read up on a lot of documentation - including a short tutorial called "So I Installed Plone - Now What?" - and bookmark the tutorials that touch on the things they know they will need to do later.

Day 2 - setting up the initial information architecture and security model
With Plone feeling a little more familiar, it's time to configure the site using the options Plone provides through its GUI. Working independently, Pete and Andy setup up a rough folder structure to reflect the client's information architecture requirements, create some Collections to collate content in the right places, pick a workflow that fits their review-and-control needs and create users and groups with local rights over different parts of the site, using the Sharing tab in Plone.

Towards the end of the day, they need to merge what they've done and show it to their manager. This is a bit tricky, since they each have a local Plone site - for which they didn't even pick the same name - and they have some overlapping changes.

Consulting the documentation, they realise that they should use Generic Setup to export a profile of their settings. Using the Big Blue Button in Plone's Configuration Management control panel, they each dump a profile to the filesystem. With some manual work, they can merge their profiles and quickly check it into their code repository.

However, Pete thinks it'll be a pain to export-and-synch settings each time they make changes, and so he looks at a tutorial helpfully named "Manging Configuration in Development Projects". This advises him to run a simple command (using one of the tools that came with the developer's installation of Plone, called paster create) that generates a skeleton "policy" package, which he then adds to buildout. Replacing the example profile that comes with this package with the export created by the Big Blue Button, he is able to replicate the settings simply by installing the policy package using Plone's installation control panel.

The next time he or Andy make a change they want to keep, they use the Little Blue Button (next to the big one) in the Plone control panel to export the configuration differences to the correct file inside the policy product, which the Configuration Management control panel lets them select. They now have a way to synchronise settings made through the web with settings made on the filesystem - perhaps obtained via a Subversion update that incorporates changes made by the other developer.

Day 3 - applying an HTML template for public branding
With the basic infrastructure in place and the site configured well enough for a first demo, Pete and Andy turn to the external look of the site. Plone looks good and all, but it's not the aesthetic the client wants. A web designer has already provided them a basic HTML template, plus some mock-ups of a few key pages in the site.

Consulting a tutorial called "Branding Plone", they decide to enable Deliverance in their development buildout. This gives them a directory called templates where they stick the HTML template, style sheets and images from the web designer. There is also a blank file called overrides.css where they can override aspects of Plone's own CSS.

The default Deliverance rules file shows how to wrap Deliverance around Plone with a basic template that replaces the logo and colour scheme and shows how to pull in the navigation tree, tabs and breadcrumbs. Taking this as an example, they quickly get a rough layout where page titles, body content and navigation elements are pushed from Plone into the template.

Andy decides to continue to tweak the CSS and HTML layout. Using an option in Plone's Theme Management control panel, he switches off the "public" stylesheets from vanilla Plone so that they do not interfere with the new theme. He also ticks the box that means logged-in users see a standard Plone GUI, devoid of any theme. This allows him to concentrate on the public theme for now. Later, he plans to generalise the theme so that it can handle Plone's editing environment as well.

Meanwhile, Pete is learning how to use Plone's Layout Page content type. With this, he can create front pages for the various sections of the website that adhere to the mockups the designer has provided. These include static text as well as dynamic listings, managed in the same way as the Collections he has already been setting up. With a bit of CSS added to the overrides.css file in the Deliverance theme, this looks good enough for now.

Day 4 - adapting the HTML template to brand the editing environment
The next day is spending tweaking the theme and layout. Pete and Andy feel they are close enough to a final "static content" management system that they arrange a workshop with the client to get feedback. The web designer has some suggestions for improvements. He is amazed when Pete shows him the Deliverance theme and tells him to make the changes to the HTML and CSS as he pleases. Pete keeps an eye on the rules file so that it all continues to work.

Meanwhile, Andy has completed an alternative Deliverance rules file that applies to logged-in users. He is able to use the same basic HTML template and leaves Plone's authoring CSS intact, but also registers a new style sheet to provide a few specific overrides. Using the Conditional Theming options inside the Theme Management control panel, he enables this new theme for logged-in users. Other options include having different themes for different areas of the site or for different groups of users. Behind the scenes, this is all managed with clever WSGI pipelines, but what does he care. So far, he hasn't even had to restart Zope since he first enabled Deliverance.

Day 5 - setting up production and testing environments
The client is now excited about the project and wants to let a few of their staff try out the new site. Consulting the tutorial called "Setting up a Server for Plone", Pete begins by checking the buildout and profile out on the server. This time, he invokes the build with two additional options: mod_wsgi deployment and caching support. They also copy a Data.fs file with some example content to the server and install their policy profile using Plone's Configuration Management control panel.

The tutorial shows Pete how to modify the server's Apache configuration to enable mod_wsgi and point it at the Plone site, all thanks to the magic of Repoze. An appropriate example configuration has been generated by buildout, and he is able to paste it in with little modification. He also look at the paste configuration to ensure that virtual hosting is enabled, and sets up the appropriate RewriteRules in Apache.

Meanwhile, Andy has read up on caching reverse proxies. Buildout has already downloaded, compiled and configured Varnish, so all he needs to do is to start it. He then goes into Plone's Hosting Management control panel. From here, he enables a default caching policy that is recommended for standard Plone and most third-party content types. There are many more options to tweak, but it all seems to work well so he leaves it alone. Like most of the Plone GUI, this control panel has contextual help that provides useful hints and explanations. Andy feels confident that he can understand the remaining options if it turns out that he'll need to. For now, he sends the client the link to the site, makes sure it's up and running and head down to the pub. It's Friday!

Day 6 - customizing visual aspects of the site
On Monday morning, Pete and Andy notice a few emails from the client. They are excited by the new site, but as expected they have a long shopping list of things they'd like to change.

Most of the changes are simple and can be managed through the Deliverance theme or simple settings in Plone's control panel. However, a few deeper changes are more tricky. Consulting a tutorial called "Cusomising Plone's Visual Elements", they install an add-on product called Plone Introspector. This came with the Plone Development Version installer, but they have not needed it until now.

The introspector adds a link on every page that takes them to a screen full of information about what they're looking at. They quickly realise how to hide and move viewlets to make the UI a little more logical. They then click the customize button next to a viewlet and edit its template through-the-web. For this, they need to understand Zope Page Templates syntax, but the online documentation makes this pretty straightforward. They continue this process, customising a few images, viewlets, portlets as well as a couple of full-page views.

Pete asks himself where all of these templates are being stored. Following a tutorial, he types http://localhost:8080/plone/manage into his browser. Yikes! That's some scary-looking stuff. After a brief poke around, he sees how Plone's site structure is exposed and finds the container where the customised templates as stored. Satisfied, he closes the browser window and hopes never to have to go back there again.

At the end of the day, the developers return to the Configuration Management control panel and clicks the Little Blue Button. Their settings synchronise to the filesystem profile. This time, however, they are asked a new question - save customised resources? The contextual help makes it clear what this means. So far, their customisations have stayed in the ZODB, but as they know this is hard to manage across environments. By picking the package housing the policy profile, they can write the ZPT files, images and other resources down to the filesystem. These end up in a nicely managed directory structure, thanks to z3c.jbot.

Pete decides to make a few more changes to some of the templates. Instead of going through the Plone Introspector, he simply makes the changes on the filesystem. They are reflected immediately, no restart or re-installation required. He also deletes a few customisations that turned out to be unnecessary.

Day 7 - creating a form
With the client's initial comments taken care of, it's time to move on to some more advanced functionality - forms! There doesn't seem to be any way to create custom forms from standard Plone, so Andy looks in Plone's Add-ons control panel. This gives him some instructions and warnings about third-party components. There is also a list of "recommended" add-ons.

One of them is called Plone Form Generator. He clicks the Download & Install button. A few minutes later, he is asked to restart Plone for the new functionality to become available. He clicks the Restart button and waits a few seconds for Plone to come back.

Immediately, he notices a new Form content type that is available to administrators. Adding a form, he is able to create a set of fields and buttons. For now, he chooses to save all form responses inside the form object itself, and publishes the form so that Pete can test it.

The form content type comes with lots of other options too - emailing responses to a specified email address, allowing users to see each other's responses, enabling tools to analyse responses in aggregate. Pete and Andy experiment with different settings and different forms. They also test the form data export functionality that enables the user to get results out to Excel, XML or SQL.

Day 8 - creating a new content type
The client now expresses a need for a new content type to capture information specific to their use cases. Pete and Andy are unsure how to do this, so they look at a tutorial called "Getting Started with Custom Content Types".

The first step is to run another paster create command, this time to create a content type product. Following the on-screen instructions, they give their package a name, choose a name and some basic properties for the content type, and install it into their buildout. Looking at the results, they see a couple of lines of Python and an XML file. The Python (in a file called staffdirectoryentry.py) looks like this:

from plone.app.dexterity import api as dexterity

class IStaffDirectoryEntry(dexterity.Schema):
pass

class StaffDirectoryEntry(dexterity.NonFolderishContent):
pass
There is also a configure.zcml file that contains this:

<plone:contentType
schema=".staffdirectoryentry.IStaffDirectoryEntry"
class=".staffdirectoryentry.StaffDirectoryEntry"
configuration="staffdirectoryentry.xml"
/>

The tutorial explains that this gives them a fully-fledged content type, with an interface/schema that can be used by other components. The type is managed by an XML file, which contains basic type information (name, where it is addable, whether comments are enabled and so on), a schema (a series of fields with associated options) and the definition of an edit form and a view.

Rather than editing the configuration file directly, Pete and Andy start up Plone and go to the Content Types Management control panel. They pick their new content type package from a list and are taken to a screen where then edit all the basic content type properties. They can also create, edit, re-arrange and delete fields in the schema and manage views through-the-web. At the end, all of this is written down to the same XML file, ensuring that their settings will be retained even if Zope is restarted.

Along the way, Pete tests the content type with input from the client, who is on-site for the day. Making changes to the schema and seeing the results is quick and easy. It's all done though the web, no restarts required.

Towards the end of the day, Andy stumbles upon a tool called Genesis. This is able to take a UML model and turn it into a content type, by generating the same type of XML file they have been using already. He installs it, and to his surprise discovers that it is able to read the file for the content type he's been working on. Making a few changes to test this different UI, he saves the XML file and returns to Plone to reload the content type. As expected, the changes take effect immediately. Andy makes a mental note to use Genesis if more complex needs arise later, since he prefers the model-driven user interface. Pete is less sure, but agrees that getting a quick UML representation of the content types is very useful.

Day 9 - adding additional behaviour to content objects
The client is happy with the new content type, but requests a few changes. They want a custom vocabulary with some customised logic, they want an email to be sent when a certain field exceeds a certain value, and they want the navigation tree to behave a little differently for the new content type.

This is a challenge, since none of these things can be achieved through the web GUI. Pete and Andy put on their developer hats, keep their Python and Plone books close to hand, and play around with the Plone Introspector in order to discover the APIs supported by various objects they see in Plone. A tutorial called "Advanced Content Type Programming" provides them with plenty of good examples, too.

Pete quickly realises why the content type package had a class and an interface in Python. These serve as "hooks" for components that they now register - a utility for the new vocabulary, an event handler for the email functionality, an adapter for the navigation tree customisation. Using examples and suggestions provided by the friendly people in the Plone chatroom and liberal copy-and-paste programming, they manage to write get this functionality working. They even write a few unit tests, using the test skeleton provided in the content type package.

During development, they use the package refresh functionality in Plone's control panel for changes to take effect. This provides helpful error messages when they get the syntax or logic wrong, and attempts to isolate the package so that a bad change doesn't take down all of Plone. Restarts are quick enough when they are required.

Day 10 - deploying a static copy of the initial site
While Pete and Andy have been polishing off the functionality, the client have busily added content to the testing instance. For the time being, they do not want to use the production Plone instance directly, since their IT people are a bit nervous about taking over a new application server. Instead, they'd like to just host a static copy of the anonymous web site. They have a server with Apache and PHP that they'd like to use.

Andy goes to Plone's Deployment control panel. There he finds a Big Green Button. He pushes it and covers his eyes. A minute later, a bunch of static HTML files appear in a directory on the server, covering the Plone site, with basic navigation and a site map. Search is provided via a form that posts to Google for search results on the current site.

However, the static site is using the standard Plone skin. Andy returns to the Deployment control panel and changes a few options - he chooses the public theme from a list of known themes, and ticks the PHP output option. This gives much the same look-and-feel, but as a bonus it has a better integrated search function and portlets such as the RSS portlet continue to work. Nice!

Behind the scenes, all of this is managed with a bridging technology called Entransit. Reading up on it, Andy sees that it can support a number of deployment scenarios, including one target platforms such as ASP.NET and SQL-based content stores, although these sometimes requires some custom programming. For now, the basics will do, as the client is likely to use a full-blown Plone-behind-Apache setup for the final deployment. Still, it's nice to have options.

THE END

(now all we need to do is to make this all reality)

--

Source: https://web.archive.org/web/20180929032104/http://www.martinaspeli.net/articles/pete-and-andy-try-plone-4