6. The Features of Plone¶
In-depth user-manual: https://old.plone.org/documentation/manual/plone-4-user-manual
Starting and Stopping Plone¶
We control Plone with a small script called “instance”:
$ ./bin/instance fg
This starts Plone in foreground mode so that we can see what it is doing by monitoring console messages. This is an important development method. Note that when Plone is started in foreground mode, it is also automatically in development mode. Development mode gives better feedback, but is much slower, particularly on Windows.
You can stop it by pressing
ctrl + c.
The instance-script offers the following options:
$ ./bin/instance fg $ ./bin/instance start $ ./bin/instance stop $ ./bin/instance -O Plone debug $ ./bin/instance -O Plone run myscript.py 4 ./bin/instance adduser
Depending on your computer, it might take up to a minute until Zope will tell you that its ready to serve requests. On a decent laptop it should be running in under 15 seconds.
A standard installation listens on port 8080, so lets have a look at our Zope site by visiting http://localhost:8080
As you can see, there is no Plone yet!
We have a running Zope with a database but no content. But luckily there is a button to create a Plone site. Click on that button (login: admin:admin). This opens a form to create a Plone site. Use
Plone as the site id.
You now have the option to select some addons before you create the site. Since we will use Dexterity from the beginning we select
Dexterity-based Plone Default Types. This way even the initial content on our page will be built with dexterity by the addon
plone.app.contenttypes which will be the default in Plone 5.
You will be automatically redirected to the new site.
Plone has many message-boxes. They contain important information. Read them and make sure you understand them!
Let’s create our first users within Plone. So far we used the admin-user (admin:admin) configured in the buildout. This user is often called “zope-root” and is not managed in Plone but only in by Zope. Therefore the user’s missing some features like email and fullname and won’t be able to use some of plone’s features. But the user has all possible permissions. As with the root user of a server, it’s a bad practice to make unnecessary use of zope-root. Use it to create Plone sites and their initial users, but not much else.
You can also add zope-users also via the terminal by entering:
$ ./bin/instance adduser <someusername> <supersecretpassword>
That way you can access databases you get from customers where you have no Plone-user.
To add a new user in Plone, click on the name admin in the top right corner and then on Site setup. This is Plone’s control panel. You can also access it by browsing to http://localhost:8080/Plone/@@overview-controlpanel
Click on Users and Groups and add a user. If you’d have configured a mail server, Plone could send you a mail with a link to a form where you can choose a password. We set a password here because we haven’t yet configure a mail server.
Make this user with your name an administrator.
Then create another user called
testuser. Make this one a normal user. You can use this user to see how Plone looks and behaves to users that have no admin-permission.
Now let’s see the site in 3 different browsers with three different roles:
- as anonymous
- as editor
- as admin
Configure a Mailserver¶
We have to configure a mailserver since later we will create some content-actions that send emails when new content is put on our site.
Please do not abuse this. We’ll disable this account after the training.
Walkthrough of the UI¶
Let’s see what is there...
- personaltools: name, logout etc.
- logo: with a link to the frontpage
- portal-columns: a container holding:
- portal-column-one: portlets (configurable boxes with tool like navigation, news etc.)
- portal-column-content: the content and the editor
- edit bar: editing options for the content
- portal-column-two: portlets
- portal-footer: viewlets
These are also the css-classes of the respective div’s. If you want to do theming you’ll need them.
On the edit bar, we find options affecting the current context...
- folder contents
Some edit bar options only show when appropriate; for example,``folder content`` and
add are only shown for Folders.
rules is currently invisible because we have no content rules available.
Edit a page:
- Edit front-page
Plone Conference 2014, Bristol
Create a site-structure:
- Add folder “The Event” and in that ...
- Folder “Talks”
- Folder “Training”
- Folder “Sprint”
- In /news: Add News Item “Conference Website online!” with some image
- In /news: Add News Item “Submit your talks!”
- In /events: Add Event “Deadline for talk-submission” Date: 10.10.2014
- Add Folder “Register”
- Delete Folder “Members” (Users)
- Add Folder “Intranet”
The default content-types:
- News Item
Please keep in mind that we use plone.app.contenttypes for the training. Therefore the types are based on Dexterity and slightly different from the types that you will find in a default-Plone 4.3.x-site.
- Go to ‘the-event’
- explain title/id/url
- explain /folder_contents
- change order
- dropdown “display”
- Add a page to ‘the-event’: “The Event” and make it the default-page
- The future:
- add a new collection: “all content that has pending as wf_state”.
- explain the default collection for events at http://localhost:8080/Plone/events/aggregator/edit
- explain Topics
- mention collection-portlets
- constraints, e.g.
- Create new rule “a new talk is in town”!
- New content in folder “Talks” -> Send Mail to reviewers.
Show and explain; mention versioning and its relation to types.
Manage members and groups¶
- add/edit/delete Users
- Add group “Editors” and add the user ‘editor’ to it
- Add group:
- add group:
juryand add user ‘jurymember’ to it.
Take a look at the
state drop-down on the edit bar on the homepage. Now, navigate to one of the folders just added. The homepage has the status
published and the new content is
Let’s look at the state transitions available for each type. We can make a published item private and a private item published. We can also submit an item for review.
Each of these states connects roles to permissions.
publishedstate, the content is available to anonymous visitors;
privatestate, the content is only viewable by the author (owner) and users who have the
can viewrole for the content.
A workflow state is an association between a role and one or more permissions. Moving from one state to another is a
transition. Transitions (like
submit for review) may have actions — like the execution of a content role or script — associated with them.
A complete set of workflow states and transitions make up a
workflow. Plone allows you to select among several pre-configured workflows that are appropriate for different types of sites. Individual content types may have their own workflow. Or, and this is particularly interesting, no workflow. In that case, which initially applies to file and image uploads, the content object inherits the workflow of its container.
An oddity in the all of the standard Plone workflows: a content item may be viewable even if its container is not. Making a container private does not automatically make its contents private.
Published content, even in an intranet setting, can pose a special problem for editing. It may need to be reviewed before changes are made available. In fact, the original author may not even have permission to change the document without review. Or, you may need to make a partial edit. In either case, it may be undesirable for changes to be immediately visible.
Plone’s working copy support solves this problem by adding a check-out/check-in function for content — available on the actions menu. A content item may be checked out, worked on, then checked back in. Or abandoned if the changes weren’t acceptable. Not until check in is the content visible.
While it’s shipped with Plone, working copy support is not a common need. So, if you need it, you need to activate it via the add-on packages configuration page. Unless activated, check-in/check-out options are not visible.
Working-copy support is not yet available for content types created via Dexterity. This is on the way.
You may need to have different workflows in different parts of a site. For example, we created an intranet folder. Since this is intended for use by our conference organizers — but not the public — the simple workflow we wish to use for the rest of the site will not be desirable.
Workflow Policy Support package gives you the ability to set different workflows in different sections of a site. Typically, you use it to set a special workflow in a folder that will govern everything under that folder. Since it has effect in a “place” in a site, this mechanism is often called “Placeful Workflow”.
As with working-copy support, Placeful Workflow ships with Plone but needs to be activated via the add-on configuration page. Once it’s added, a
Policy option will appear on the state menu to allow setting a placeful workflow policy.
Workflow Policy support is not yet available for folderish content types created via Dexterity. This is on the way.