Zope Management Interface know-how for better Plone development

Question

As a typical 'integrator' programmer customising Plone, what should I know about the ZMI to help me code more effectively? What are the settings, tools, pitfalls, shortcuts and dark corners that will save me time and help me write better code?

Edit: take it as read that I am coding on the filesystem, using GenericSetup profiles to make settings changes. I know making changes in the ZMI is a bad idea and generally steer clear. But occasionally the ZMI sure is useful: for inspecting a workflow, or examining a content item's permissions, or installing only one part of a profile via portal_setup. Is there really nothing worth knowing about the ZMI? Or are there other useful little tidbits in there?

Answer 1

The portal_historiesstorage tool can eat a lot of disk space. Any content type set to save revisions saves them here, and by default Plone keeps all revisions (see the portal_purgepolicy tool).

I want all revisions on the production Data.fs, but after taking a copy for development the first thing I do is purge portal_historiesstorage. The procedure is:

• Go to your Plone site in the ZMI
• Delete the portal_historiesstorage tool
• Go to portal_setup, Import tab
• Under 'Select Profile or Snapshot' choose 'CMFEditions'
• Select the step with handler Products.GenericSetup.tool.importToolset
• Uncheck 'Include dependencies?'
• Hit 'Import selected steps' to re-add portal_historiesstorage
• Pack the Data.fs and delete the resulting Data.fs.old from the filesystem

On my 3G Data.fs, this little sequence removes 2.5G!

I have only ever done this on a development Data.fs. Without advice from someone who really knows, I don't recommend doing this on your production site.

Answer 2

If you want to write code for Plone, it's best to avoid the ZMI. The concept of doing things through the ZMI is very limited and discouraged - more and more things are not available in there and it will go away at some point.

The actual Plone control panels offer you most of the configuration options you can use. For anything else the file system is the best place to look.

Answer 3

The key thing to know is that while many ZMI tools provide quick, through-the-web customization, the customizations that you make this way are hard to export out of the database. So, they don't move easily from development to production environments or from one deployment to another.

Ideally, a new developer should use the ZMI to explore and find points of intervention. Then, learn how to implement the same changes in policy add ons (products) that move from one deployment to another much more reproducibly.

Answer 4

There is usually no reason for an integrator or a developer to touch the ZMI other for possible maintenance tasks. Almost any customization can be done using Python or a GenericSetup profile. The advantage of profiles are: repeatability - being able to maintain on the filesystem - being able to put files under revision control.

Being able to work and configure stuff through the ZMI is partly working against Plone - especially when Plone is doing extra stuff under the hood. So the only recommendation can be: stay of the ZMI if you can. The ZMI is not a suitable replacement for using the Plone UI and should only be touch if you really know what you are doing.

Answer 5

Yep, the ZMI is for the occasional maintenance task or, when pressed, a quick-and-dirty CSS or template tweak. It's not meant for any real "coding" work, and in the context of Plone is best thought of as an odd and minimally useful leftover from Zope history.

Answer 6

There are a few places in the ZMI that I find myself returning to for diagnostic information:

• /Control_Panel/Database: Select a ZODB mountpoint. Cache Parameters tab shows how much of your designated ZODB cache size has been used. Activity tab shows how many objects are being loaded to cache and written over time.

• /Control_Panel/DebugInfo/manage: Lots of info, including showing what request each thread is serving at the current moment. The 'Cache detail' and 'Cache extreme detail' links give info on what classes of objects are currently in the ZODB cache.

• Components tab of the Plone site root: Quick way to see what local adapters and utilities are registered. DON'T HIT THE APPLY BUTTON!

• Undo tab of most objects: See who has committed transactions affecting the object lately.

• Security tab: See what permissions are actually in effect for an object. You really don't want to change permissions here 90% of the time; it's too hard to keep track of where permissions are set and they are liable to be reset by workflow. Use the Sharing tab in the Plone UI to assign local roles instead. (The one exception is that I often find it handy to enable the add permission for a particular type in specific contexts.) In Zope 2.12, there is a new feature on this tab to enter a username and see what permissions and roles would be in effect for that user, which is handy.

• Catalog tab of portal_catalog: See what index data and metadata is stored for a particular path. (Can also remove bogus entries from the index.)

• Index tab of portal_catalog: Select an index, then click its Browse tab to get an overview of what keys are indexed and which items are associated with each key.

Answer 7

portal_actions is also useful for more flexible top level navigation. but again best configured via gnericsetup.

Answer 8

I agree with the other posters that you shouldn't configure too much via the ZMI, as it's not in version control and you can easily lose track of the changes.

But the ZMI is still very useful for debugging and to see specific site configurations.

Here are some tools in the ZMI that I regularly consult:

• portal_javascripts: To turn debugging on off. Checking which scripts are there, what are their conditions for rendering and are they found?
• portal_css: Basically the same as portal_javascripts but for stylesheets.
• portal_types: To see what a type's properties are. Can it be created globally? What types can you create inside it? What is its default view? Etc.
• portal_catalog: What indexes are there? What metadata is there in the catalog? You can clear and rebuild the catalog and even browse the catalog.
• portal_workflow: What states/transitions/permissions are there in a certain workflow? What workflow is active on a certain type?
• portal_properties/site_properties: View and set site-wide properties. A lot of these settings are in the plone_control_panel (i.e outside of the ZMI), but here they are on one page and the ZMI is quicker to navigate.
• portal_skins: See which skins folders are installed. See the ordering of the skin layers (via the properties tab). You can also edit the templates, stylesheets and javascripts in the skins directories. Not recommended! But useful for debugging.
• portal_setup: Some very big and complex Plone websites can break if you just willy-nilly add/remove/reinstall add-ons. Often it's safer to just run a specific GenericSetup update. For example, if you have added a new portlet, rather import the specific (portlets.xml) step via portal_setup (the import tab), then reinstalling the whole product.
• portal_actions: Configure which actions are visible/present.
• portal_quickinstaller: Quickly reinstall, uninstall add-ons. Often quicker and more lightweight than loading Plone Control Panel's equivalent.
• acl_users: Sometimes when using an add-on like LDAPUserFolder, you'll have to dig around in acl_users to configure and test it. You can also create users here, although it's better to do this via the Plone Control Panel (i.e not in ZMI)

There are many more tools and things to tweak (and break your site with) in the ZMI, but the above ones are what I use 90% of the time.