The INDIGO blog series is aimed at end users who want to better understand the software they are using.

Roles, groups, permissions, workflows, states, transitions are all a part of Plone's robust security model. But you don't have to be a guru to understand the basic Plone permissions you will encounter on a daily basis.

Definitions

Let's start off with some basic terminology. Permissions are individual rights that give the user the ability to perform an action. Roles are a combination of permissions. Both users and groups can be assigned roles.

Roles

Roles are a combination of permissions that you will assign to your users. Plone comes with a basic set of roles, each of which already has certain permissions assigned. Below you will learn a little bit about the defaults for each role.

Most of your site users have the "Member" role. By default, a Member can see anything that is published, see the contents of a folder, see a list of other portal members and groups, and see portlets. Depending on how your site is customized, Members may not have access to certain portlets or specific parts of the site. I keep track of what a Member has access to by reminding myself that a Member cannot change content and can only see what has been published. You will want to assign the Member role to your every day, normal users who will not be changing content. Everyone who joins your site should be assigned this role.

Reader

The Reader role may be almost the opposite from the Member role. Readers can view content items that are in the private state, but cannot make any changes. You should assign people the Reader role when you want them to review a piece of content that is not yet published. The Reader role is great for when you want only certain people to see a piece of content. You can also use the Reader role as part of a document review cycle for users who would like to review your document but not make changes to the document.

Contributor

A user with a Contributor role can do all the things a member can, plus add content, use version control, and view content that is not in the published state. A contributor cannot modify (edit) another user's content. The Contributor role should be given to users who will create content but not edit another person's content.

Owner

The owner role is inherited when a user adds a piece of content. You have to have another role, like Contributor, that has the ability to add content. Once you add a piece of content, you are automatically assigned the Owner role over this content. When you are the Owner of a piece of content, you can modify that piece of content whenever you wish, no matter what state the content is in.

Editor

A user with the Editor role by default does not have the ability to add content, but can modify(edit) content and use version control. An Editor can also manage properties of content and can submit content for publication. The Editor role should be used when a Contributor is sending a piece of content for review. The Editor will review, and change, the content and then submit it for publication.

Reviewer

A Reviewer role picks up where the Editor leaves off. While a Reviewer does not have as many rights as the Editor, the Reviewer can publish content that has been sent to the submit for publication state or send it back to the owner. The Reviewer also has a special portlet just for content that needs to be reviewed. Once an Editor has submitted content for publication, the Reviewer will review the content and then has the option to Publish or send back the content for the Contributor to review. The Reviewer has the final say if something gets published or not.

Manager

The Manager role is the role that can do everything. A user with the Manager role is a Site Administrator. Manager privileges are not given out lightly as this role can add, delete, and make changes to any thing in the site. While more than one person should have this role, it definitely should not be handed out to large numbers of people. Your site Manger has access to the control panel, where many site wide settings can be changed and updated. The Manager can also manage things via the ZMI (Zope Management Interface).

Giving out permissions

The easiest way to hand out permissions is to assign roles to groups. You can create a group and assign that group a role. Then, whenever you want to give someone certain permissions, you can add that user to that group. Assigning roles on a group level allows you to more easily manage large numbers of users.

Local Roles

There may be some situations where you don't want your group to have a specific role across the entire site. You can manage that easily too. When setting up your group in the Site Setup, do not assign it a role. Go to the folder where you want the group to have specific permissions and assign the group that role on the sharing tab for the folder. You can assign individual users permissions at this level as well. Simply add the user to the sharing tab and assign the permission to that user. When you assign roles at an object level like this, you are assigning local roles. Local roles give users (or groups) extra permissions in a very specific context. For example, you may have two groups: pirates and ninjas. The ninjas probably don't want the pirates mucking about with their content. In this case, you could create a folder for the ninjas and assign their group to have a local role of Owner over the folder. Uncheck the inherit permissions box and now your ninjas have their own folder where they can add content and the pirates cannot see or add anything to this folder. Similarly, if only the pirate captain should have access to a folder, add the pirate captain user to the sharing tab and select the correct permission. Don't forget to uncheck the inherit permissions box, otherwise your folder will inherit permissions from the rest of the site.

Moving ahead

Now that you are familiar with the basic concept of permissions, roles, and groups, we can learn more about workflows, states, and transitions. Workflows are intricately tied to permissions and are a helpful way of managing content that multiple users must review. In my next blog post, I'll cover the basic workflows and how your users interact with them.

There are a few automagical scripts in Plone of which many developers may not be aware. These helpful scripts are used throughout the default Plone skin, and are available for you to use in your templates as well. The nice part is that you don't need to know JavaScript to be able to use them, you just have to know how to structure your code properly for the existing JS to find it. The original .js files can all be found in CMFPlone/skins/plone_ecmascript/

form_tabbing.js

FormTabbing is a way of splitting up content into multiple screens, without having to refresh the page. The most common place this is seen in Plone is the edit screen.

The JS file that does this magic is form_tabbing.js, and it even includes instructions on how to use it yourself. It's as simple as this:

<dl class="enableFormTabbing">
  <dt id="fieldsetlegend-unique-id1">button one</dt>
  <dt id="fieldsetlegend-unique-id2">button two</dt>
  <dd id="fieldset-unique-id1">content one</dd>
  <dd id="fieldset-unique-id2">content two</dd>
</dl>

The two <dt>s serve as the buttons at the top that toggle which content to view. The id for the buttons must start with "fieldsetlegend-" and end the same as its <dd> conterpart (which starts with "fieldset-").

The code can also work in this way:

<form class="enableFormTabbing">
  <fieldset id="fieldset-[unique-id]">
    <legend id="fieldsetlegend-[same-id-as-above]">Title</legend>
  </fieldset>
</form>

table_sorter.js

The table sorter JS allows you to sort tables by column. To see an example, login and visit a folder_contents page. You will see a table like the one below. Click on the "Title" header, and all the rows will then sort alphabetically by title.

To use this in your own template, your table will need the following code:

• class="listing" applied to the table

• a unique id for the table

• use of <thead> and <tbody>

• make sure to use <th> in the <thead>

Here is an example:

<table class="listing" id="my-table">
  <thead>
    <tr><th>Numbers</th></tr>
  </thead>
  <tbody>
    <tr><td>123463</td></tr>
    <tr><td>7632</td></tr>
    <tr><td>459629</td></tr>
    <tr><td>27963</td></tr>
  </tbody>
</table>

Clicking on the header "numbers" will sort the table by that column. Clicking on it again will sort in the reverse direction.

An important thing to realize is that by default, the table_sorter.js is set to not work for anonymous. You can see in the ZMI > portal_javascripts, that there is a condition set on table_sorter.js. To allow this for everyone, just clear out the condition. The code for jsregistry.xml should look like this:

<javascript cacheable="True" compression="safe"
  conditionalcomment="" cookable="True" enabled="True"
  expression="" id="table_sorter.js" inline="False"/>

collapsiblesections.js

Collapsible sections gives you an easy way to reduce the amount of clutter on a page. An example of this is the History information on an item in Plone. It starts out collapsed, and displays all the hidden information when you click on the title.

This effect can be achieved with the following code:

<dl class="collapsible collapsedOnLoad">
  <dt class="collapsibleHeader">
    Clickable Title
  </dt>
  <dd class="collapsibleContent">
    <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit.</p>
  </dd>
</dl>

The collapsedOnLoad class is what sets the item to be collapsed when the page loads. Remove this class to have the item start out open. collapsiblesections.js provides helpful documentation if you have more questions.

cookie_functions.js

This one does require some JS knowledge, but it is helpful nonetheless. If you have a need to create a cookie on your site, Plone already has some Javascript set up for that. You just need to be aware of the two functions:

• createCookie, which takes the arguments name, value, and days (for expiration).

• readCookie, which only takes a name, and returns the value.

Conclusion

Without much effort, these scripts will help you to build functional, easy-to-use templates. Put together with custom styling, you can utilize these frameworks to work seamlessly in your site.

Learning to theme a site in Plone? Here are some quick tips to help get you started with your CSS styling once you have installed your theme product.

Turn on CSS debug mode

To turn on the CSS debug mode, go to portal_css in the ZMI. Check the box next to "Debug/development Mode", and save. Turning this on allows you to see your CSS changes when you refresh the page, without having to restart your instance.

Use base_properties.props

The default Plone styles use these variables, so changing some of the values will allow for quick, site-wide changes.

A few useful ones:

• logoName: The filename of the logo you want the site to use. Put the image in your theme's images folder. logoName does not need to be changed if you upload a logo with the filename "logo.jpg", this will just override the default Plone logo.

• textTransform: Ever notice how a lot of items on a default Plone site are in lowercase? Change this value to "none" to set them all back to normal.

• columnOneWidth/columnTwoWidth: Controls the width of the left and right portlet columns.

You can also add your own variables to base_properties to be used within your custom stylesheets.

Using variables from base_properties

Create an override of ploneCustom.css.dtml. The ".dtml" at the end, along with the following code, is what allows you to use variables from base_properties:

/* <dtml-with base_properties> (do not remove this :) */
/* <dtml-call "REQUEST.set('portal_url', portal_url())"> (not this either :) */

/* </dtml-with> */

All your CSS will go in between the <dtml-call> and </dtml-with>. You can now use variables in this way:

body {
  background-image: url(&dtml-portal_url;/bg.jpg);
  color: &dtml-fontColor;;
}

Notice that the variables start with an ampersand, and end with a semicolon (separate from the semicolon that ends the declaration).

Setting a Fixed Width

If your site is going to use a fixed width instead of fluid, this should be set on #visual-portal-wrapper, not the body. If a width is set on the body, this will mess with with the kupu editor and reference browser window by adding a horizontal scroll.

Stay out of the main_template

If at all possible, don't change the main_template.pt. With Plone 3, it is very possible to theme an entire site without having to touch this template. Keeping the main_template pure will make it easier for you to migrate your site to newer versions of Plone in the future.

Use Classes to Your Advantage

Plone adds classes to the body based on current section or template. For example, you can use .template-document_view in your selector to make changes only to the document view. Or you can use the "section-" class to give headers a different color based on what section of the site you are viewing.

z3c.jbot is Your Friend

Look into z3c.jbot for overriding viewlets and portlets. z3c.jbot gives you the ability to make changes to a viewlet's template without changing any zcml or Python code.

More information

Hopefully these tips will help you to get a bit of a jump start on your theme. To get more in depth into the theming process, check out the Plone 3 Theming book by Veda Williams.

Last month, the first annual Open Source Bridge conference was held in Portland. The Open Source Bridge was a volunteer run conference focusing on all things open source. Kudos to all the volunteers that put this event together. It seemed like they had been putting this event on for years, I was quite impressed.

One of the really nice things about the conference was the diverse crowd. There were people ranging from kernel developers to documentation writers. There were also a lot of languages being represented including Python, Ruby, Perl and PHP. The only majority of people that I noticed were Portland natives. There was a decent showing of Plone folks at the conference as well, about 12 total. We set up a booth in the exhibition hall and handed out Plone stickers and Top Fifteen Questions About Plone pamphlets.

Along with the diverse crowd was a large selection of sessions. The sessions were split up into five categories (cooking, chemistry, business, culture, hacks) and split across eight rooms! Each session choice was really difficult since there were so many great talks packed into the schedule. One of the highlights for me was the keynote by Portland's mayor Sam Adams. He talked about how he wanted government to be a lab to push open source innovation forward. Portland really seems to want to embrace open source. There couldn't have been a better venue for this conference.

The Open Source Bridge was not your typical conference in more ways than just being volunteer run. At the end of the first day there was a yoga session entitled "Get Off Your Asana and Move!". It was the perfect end to the day, and wasn't just talk either, it was a 45 minute yoga session. As if that wasn't cool enough, at the end of the second day there was a meditation session. During all three days there was an all hours hacker lounge set up at the top of the Hilton downtown. I didn't make it out till the last night, but it had an incredible view and a nice vibe going on. It was a place were you could go hack on some code or get some work done if you needed to.

The last day of the conference was an unconference day. They handed the conference over to the attendees. This was my first exposure to such an event. Each person that wanted to lead a session went up to the podium, spoke about their topic briefly and then posted their session idea on the board. Once the dust settled there was a full schedule of talks produced by the attendees. One of the best sessions I attended was during the unconference day where we talked about writing documentation. It was a small group of folks who all had a lot of great ideas and experience writing docs.

The conference and the host city were both incredible. Portland was infused with technology. The buses and light rail are GPS enabled so the times on the website are always up-to-date. A lot of businesses use Twitter to communicate with the public. The best example was Bailey's Taproom where they tweet what's being tapped! I think we need to host a Plone Conference in Portland, did I mention that Portland has more breweries and brewpubs per capita than any other city in the United States. Another bonus was free public transportation downtown, so you could hop on the MAX from the hotel and go right to the convention center without paying a dime.

Getting started doesn't require that you know the myriad of options and commands that exist in Subversion. Let's say for example you wanted to participate in the periodic Plone Tune-Ups. You are going to want to check out the latest stable development environment to start hacking. According to the Tune-Up site you need to grab the Plone 3.3 plonenext buildout.

Here's how you do it:

centaur% svn checkout http://svn.plone.org/svn/plone/plonenext/3.3 plonenext-3.3

The result of this command will be a new directory named plonenext-3.3 on your computer in the directory where you ran the command. If you just started up your command prompt, most likely this will be in your home directory.

Subversion provides some shortcuts to many of its commands. So in this case you could have just typed this and gotten the same result:

centaur% svn co http://svn.plone.org/svn/plone/plonenext/3.3 plonenext-3.3

One of my favorite commands has many shortcuts that aren't necessarily shorter, but are more politically correct. In this case the svn blame command can also be written as svn praise, svn annotate, or svn ann. I'll go over that command in more detail in a future post.

With any of these commands you have instance access to Subversion's help system at all times. You can access the general help and command listing by typing svn help and for help with a specific command you can type svn help checkout and read up on all the various options available to you.

There are many great reasons to use a Source Control Management (SCM) system. If you are looking to get involved with an Open Source project or manage small and large projects of your own, you are going to need to know how to use a SCM.

This process works well for a large group of developers on a large code project, but a single developer can also benefit from using a SCM. The big benefit is an archive of all code changes over time so you can revert and compare changes. This will keep a whole history of the project in a timeline so we can pinpoint any problems that may arise.

The conventions we use are very standard in the Plone and Subversion communities. The folks over at CollabNet have put together a great list of best practices.

If you were to ask another Plone consulting company that utilizes the community best practices to help you with your code, they would be up and running in no time since we have followed these best practices. Plus, any new developers your team would bring on would benefit from the quick spin up due to the use of subversion and buildout.

Another good reason to use Subversion is that is provides some accountability for code changes. We can track who changed the code down to the line. This allows for a more orderly management of the code and helps reduce the chaos of sharing changes back and forth. That will eliminate knowing who has what code and what environment is running what version of the code too.

When working on larger features that might introduce instability for other developers is the time to leverage the power of branching. Being able to branch for larger features allows you as a developer to work and commit code without breaking other developers checkouts. Doing this allows you to continue the best practices of committing often. Maintenance branches also allow you to release small fixes while larger development is still moving forward. In either of these cases, once the development is complete you can just merge or reintegrate your changes to the trunk.

When working on projects it is very important to do releases from tags and to use branches and the trunk to collaborate. This will lead to more consistent releases and the ability to more easily roll back incase of a larger regression that isn't caught in time.

We have started responding to many documents now using plain text files since it is very easy to manage and to collaborate with other team members. Now, what if you want to send off a professional looking formatted structured document with a table of contents. You also want it to be in a common format so that others can annotate on it or send you feedback. PDF is perfect for this, but how do you get your very functional markdown to a very pretty PDF presentation?

Markdown.pl ~/Desktop/mytextfile.markdown | SmartyPants.pl | htmldoc --book --footer . -f output.pdf -

Enjoy! As a bonus I included SmartyPants, which is also by the creator of Markdown and it gives you some nice typographical elements just as smart quotes and em-dashes. Also, I would check out the documentation on htmldoc, it is pretty powerful and can even embed background images and custom headers and footers.

Six Feet Up is firmly entrenched in Open Source. We focus on a product called Plone, and at least once a month our developers donate their time to contribute bug fixes back to the Plone Community. We use several open source products such as FreeBSD on our servers, the nginx web server, Varnish, and Pound. I am a Unix Administrator and not much of a programmer at all, so I've never really felt part of that Community; that is, until the last few weeks.

Six Feet Up is now the official host of plone.org. This doesn't seem like a big deal, but it is. We, and by "we" I am referring to Six Feet Up, are now hosting the official community site of a very large open source project. As a Unix Administrator, at least part of the responsibility of keeping the environment for that site stable sits firmly on my shoulders. And with that, I realized that I too can contribute back to the Open Source Community as a whole.

The second thing that has happened in the last few weeks was a bit of an epiphany. We have an Open Source product that we are hosting for three customers called the Knowledge And Resource Locator or KARL for short. That product is being rewritten from scratch for its 3.0 release. We were asked if we would provide server space, and some development time for the upcoming migration from version 2.x to version 3. I was selected to work on the server configuration and log any bugs I find during the setup, as well as document any snags encountered along the way.

For the first three weeks it was mostly the status quo for me: not really part of the community, but perhaps supporting some of the infrastructure the community needs. It wasn't until one Friday afternoon after a week of tracking down problems and eventually closing all of my tickets, with help from Shane Hathaway, for that week that it hit me. I am part of the Open Source Community! Providing the infrastructure required for developers in place is as important as the developers themselves. Paul Everitt told me it takes more than just programmers to get projects like this done.

I would like to extend a thank you to Paul. What he said really helped me see the worth I do provide the community as a whole using the skill set I have. For everyone else on that project, it's been fun working with all of you. You're all a bunch of rockstars, and the team we have could likely accomplish great things together! It's been an honor to provide a workspace for you to use and abuse.

I was resistant at first also. When I first picked up Zope in 1998, the first thing I asked was if I could store all of my data in MySQL. I didn't know what I was missing yet, but I'm glad it only took me one project to realize the true strength of using a Object Oriented Database with an Object Oriented application server.

Things have come a long way since then, and now it could even be considered trendy to be using an Object Oriented Database. Is the Relational Database Doomed? is a decent article that outlines some of the big benefits people are seeing today using OODBs.

Zope was just way ahead of their time, but now they have the benefit of experience behind them as they continue to develop on the ZODB. Out of the box the ZODB comes packed with features and tools to help manage itself such as hot incremental backup tools and full blob support now as of ZODB 3.8.

Another big benefit for me is not dealing with the database much at all. As a Zope developer, most of the time I don't even notice it is there since it handles things like transactions fairly transparently. I don't have to deal with the extra layer of an ORM or manually do SQL joins to gather my objects up. I can also establish relationships between objects purely based on their proximity to other objects in the database.

So I think that Zope made the right choice long, long ago. We still use RDBMSes when it makes sense, but the ZODB and OODBs in general are a great choice for content driven applications.

Using the right tool for the right job

Six Feet Up loves Plone, but using Plone as a blogging tool has never been a strong point. Blogging isn't something that we felt that Plone did well out of the box. Much like most Plone products, you have to add in various third party products or create your own products if you want to get some of the really nice features that many of the typical blogging platforms like WordPress offer today like pingbacks. We had tried quite a few of these ways of stuffing blogging into Plone and ran into various issues of dependencies or incompatibilities along the way so we decided to go for a solution that wasn't in Plone.

Zine is a blogging platform written in Python and supports being deployed as a WSGI application, so it seemed like the perfect fit. Zine is basically a python clone of WordPress and has all the nice goodies and plugins that modern blogging platforms have come to enjoy. It is also relatively easy to theme and write plugins to extend its behavior.

We can also run Plone as a WSGI application by using the Repoze application repoze.zope2 instead of the standard Zope ZPublisher. The big benefit is that we can run multiple WSGI applications in a single process and utilize WSGI middleware like Deliverance to theme all of the applications as they are delivered. This type of setup can simplify deployment greatly and all works well with buildout, which we have a lot of knowledge about already.

Bringing together the pieces

Let's start by getting repoze.zope2, zine and deliverance added to our buildout. I added four additional parts to our existing buildout profile to get this process started.

[buildout]
...
parts = 
  ...
  repoze # this needs to be before the zope2 part or plone won't work
  ...
  deliverance # these have to go at the end or paster won't get all the right eggs listed
  zine-deps
  zine

I also added this to the [buildout] section to pin the version of the zopelib:

find-links =
    ...
    http://dist.repoze.org/zope2/latest/zopelib-2.10.7.0.tar.gz

...
versions=versions

[versions]
zopelib = 2.10.7.0

In these four new parts we will add in the new bits required to host the full WSGI stack for our deployment. Here are the parts we added:

[repoze]
recipe = zc.recipe.egg
eggs =
     PasteScript
     WSGIUtils
     repoze.zope2
     ${plone:eggs}
index = http://dist.repoze.org/plone/latest/simple

[deliverance]
recipe = infrae.subversion
as_eggs = true
urls =
    http://codespeak.net/svn/z3/deliverance/trunk deliverance

[zine-deps]
recipe = zc.recipe.egg
extra-paths = parts/zine/lib/zine
interpreter = python
eggs = Paste
       PasteScript
       PasteDeploy
       ${instance:eggs}
       ${repoze:eggs}
       ${deliverance:eggs}
       SQLAlchemy>=0.5.0
       Jinja2>=2.1.0
       Werkzeug>=0.4
       simplejson
       html5lib
       pytz
       Babel>=0.9.4
       lxml>=2.0
       Pygments>=0.9
       docutils==0.5
       zinebuildout>=0.4
       MySQL-python

[zine]
recipe = zc.recipe.cmmi
url = http://zine.pocoo.org/releases/Zine-0.1.2.tar.gz
extra_options = --python=python

With all of that added to your buildout profile you need to re-run buildout and it will download and install all the needed parts for you.

Configuring the paster WSGI stack

Before we can start up the new WSGI stack with paster, we will need to create a paster.ini for the WSGI stack and a rules.xml file for deliverance to use.

You can put both of these files in the root of your buildout. The paste.ini is using the zinebuildout egg to allow us to use Zine as an application in our paster stack. It is configured in the [app:zine] section. You will need to make an empty zine directory in your buildout that will contain the zine.ini once Zine has been configured through the web.

The paste.ini file configures two pipelines, one for each application. The blog pipeline has the deliverance filter applied to it so you get the Plone theme applied to the Zine blog.

paste.ini

[DEFAULT]
debug = True

[app:zine]
use = egg:zinebuildout
instance_folder = %(here)s/zine

[app:zope2]
paste.app_factory = repoze.obob.publisher:make_obob
repoze.obob.get_root = repoze.zope2.z2bob:get_root
repoze.obob.initializer = repoze.zope2.z2bob:initialize
repoze.obob.helper_factory = repoze.zope2.z2bob:Zope2ObobHelper
zope.conf = %(here)s/parts/instance/etc/zope.conf

[filter:errorlog]
use = egg:repoze.errorlog#errorlog
path = /__error_log__
keep = 20
ignore = paste.httpexceptions:HTTPUnauthorized
       paste.httpexceptions:HTTPNotFound
       paste.httpexceptions:HTTPFound

[pipeline:zope]
pipeline = egg:Paste#cgitb
           egg:Paste#httpexceptions
           egg:repoze.retry#retry
           egg:repoze.tm#tm
           egg:repoze.vhm#vhm_xheaders 
           errorlog
           zope2

[pipeline:blog]
pipeline = egg:Paste#cgitb
           egg:Paste#httpexceptions
           errorlog
           deliverance
           zine

[filter:deliverance]
use = egg:deliverance#main
rule_filename = %(here)s/rules.xml

[server:main]
use = egg:repoze.zope2#zserver
host = localhost
port = 51047

[composite:main]
use = egg:Paste#urlmap
/blog = blog
/zope = zope

Configuring Deliverance to theme Zine with the Plone site theme

Deliverance is configured in the rules.xml file and points to the Plone application's main_template to get the look and feel. The rest of the rules drop bits that aren't needed and throw the Zine portlets and content into the right places in the Plone theme. We created a Zine plugin to wrap the Zine portlets with a more Plone like structure so that they blend right into the Plone theme.

rules.xml

<ruleset>
<theme href="/zope/Plone/main_template" />
<rule>
  <prepend theme="//head" content="//head/link" nocontent="ignore" /> 
  <prepend theme="//head" content="//head/style" nocontent="ignore" />
  <append theme="//head" content="//head/script" nocontent="ignore" />    
  <append theme="//head" content="//head/meta" nocontent="ignore" />
  <replace theme="//head/title" content="//head/title"  nocontent="ignore" />
  <!-- we don't need the reddit zine links -->
  <drop content="//div[@class='reddit']"/>
  <!-- let's drop the breadcrumbs from the plone theme -->
  <drop theme="#portal-breadcrumbs"/>
  <!-- let's drop the plone login box -->
  <drop theme="//td[@id='portal-column-one']/div/div"/>
  <!-- put the zine portlets in column one -->
  <append theme="//td[@id='portal-column-one']/div" content="//div[@class='sidebar']/*" nocontent="ignore"/>
  <!-- put the body of the zine in the content region -->
  <append theme="children:#region-content" content="children://div[@class='contents']" nocontent="ignore" />
  <!-- put the administrative links in column two -->
  <prepend theme="children:#portal-column-two" content="//div[@class='body']/ul" nocontent="ignore"/>
  <!-- make sure the login box has a spot when we need it -->
  <append theme="#viewlet-above-content" content="//div[@class='login-box']" nocontent="ignore"/>
</rule>
</ruleset>

Time to start up paster

Once these are all in place and you have created the zine directory at the root of your buildout, we can start the paster server. It is started like this:

bin/paster serve paste.ini

Now in your browser you can go to http://localhost:8080/zope to see the Zope/Plone instance. You will need to add a Plone Site to your instance. In my demo I gave it an id of "Plone". If you have a Plone Site with a different id, you will need to change the path to the in your rules.xml.

Now, when you go to http://localhost:8080/blog you will be presented with the Zine setup screens. If all went well, the screens should look like your Plone Site theme. At this point you will need to setup a MySQL database to hold the blog data and provide connection information as you go through the Zine setup wizard.

Now you can fix up and modify the rules.xml and theme in your Plone site to make the Zine blog blend into your site seamlessly. Enjoy!