Zope management interface know-how for better Plone development

Question

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

Edit: Assume that I am encoding a file system using GenericSetup profiles to change settings. I know that making changes to ZMI is a bad idea and usually understandable. But sometimes ZMI is of course useful: for checking the workflow or checking permissions of content elements or setting only one part of the profile through portal_setup. Is it really worth it to know about ZMI? Or are there other useful little tidbits?

Answer 1

There are several places in ZMI where I return to the diagnostic information:

• / Control_Panel / Database: select the mount point of the ZODB. The Cache Settings tab shows how much of your designated ZODB cache size has been used. The tab “Activity” shows how many objects are loaded into the cache and recorded over time.

• / Control_Panel / DebugInfo / manage: a lot of information, including showing which request each thread is currently serving. The "Cache detail" and "Cache extreme detail" links provide information about which classes of objects are currently in the ZODB cache.

• The Components tab of the Plone root site: A quick way to find out which local adapters and utilities are registered. DO NOT FIND THE APPLICATION BUTTON!

• Undo the tab of most objects: see who made transactions that affect the object recently.

• Security tab: see what permissions actually apply to the object. You really do not want to change permissions here in 90% of cases; it's too complicated to keep track of where permissions are set, and they can be reset by the workflow. Use the Sharing tab in the Plone user interface to assign local roles instead. (The only exception is that I often find it convenient to enable permission to add a specific type in certain contexts.) In Zope 2.12, there is a new function on this tab to enter a username and see what permissions and roles will be in effect for that user which is convenient.

• Directory Portal Directory Directory Tab: See what index data and metadata are stored for a specific path. (You can also remove dummy entries from the index.)

• Portal "portal" Index tab: portal_catalog: select the index, then click the "Browse" tab to get an overview of which keys are indexed and which items are associated with each key.

Answer 2

The main thing to know is that although many ZMI tools provide quick configuration via the web interface, the settings you make in this way are difficult to export from the database. Thus, they do not easily move from development to production environments or from one deployment to another.

Ideally, the new developer should use ZMI to study and search for points of intervention. Then, learn how to implement the same changes in adding policies (products) that go from one deployment to another much more reproducibly.

Answer 3

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

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

Answer 4

I agree with other posters that you should not configure too much through ZMI, since it is not in version control, and you can easily lose track of changes.

But ZMI is still very useful for debugging and viewing specific site configurations.

Here are some tools in ZMI that I regularly advise:

• portal_javascripts . To disable debugging. Checking there are scenarios, what are their conditions for rendering and are they found?
• portal_css : basically the same as portal_javascripts, but for a stylesheet.
• portal_types . To find out what type properties are. Can it be created globally? What types can you create inside it? What is its default view value? Etc.
• portal_catalog . What indexes exist? What metadata is there in the directory? You can clear and rebuild the directory and even browse the directory.
• portal_workflow : what states / transitions / permissions are there in a particular workflow? What workflow is active on a particular type?
• portal_properties / site_properties . View and set site properties. many of these settings are located in plone_control_panel (i.e. outside of ZMI), but here they are on the same page, and ZMI is faster than navigation.
• portal_skins . See which skin folders are installed. See the ordering of skin layers (through the properties tab). You can also edit templates, style sheets and javascripts in skin directories. Not recommended! But useful for debugging.
• portal_setup . Some very large and complex Plone websites can break if you just add / remove / reinstall add-ons perforce. It's often safer to just run a specific GenericSetup update. For example, if you added a new portlet, import the specific (portlets.xml) step through the portal_setup (import tab), and then reinstall the entire product.
• portal_actions . Set what actions are visible / present.
• portal_quickinstaller . Quick reinstall, remove add-ons. Often faster and easier than loading the control panel Plone equivalent.
• acl_users Sometimes when using an add-in such as LDAPUserFolder, you will need to dig into acl_users to configure and test it. You can also create users here, although it is better to do this through the Plone Control Panel (i.e. Not in ZMI)

There are many more tools and things in ZMI that you can customize (and break down your site), but the ones I use in 90% of the cases I used above.

Answer 5

The portal_historiesstorage tool can consume a lot of disk space. Any type of content intended for saving changes saves them here, and by default, Plone saves all changes (see the portal_purgepolicy tool).

I want all versions to be processed by Data.fs, but after receiving a copy for development, the first thing I do is clear the portal_historiesstorage. The procedure is as follows:

• Go to the Plone website in ZMI
• Delete portal_historiesstorage tool
• Go to the portal_setup tab, Import tab
• Under "Select profile or snapshot" select "CMFEditions"
• Choose a step with the Products.GenericSetup.tool.importToolset handler
• Uncheck "Enable dependencies?"
• Click "Import Selected Steps" to re-add portal_historiesstorage
• Pack Data.fs and delete the resulting Data.fs.old from the file system

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

I only ever did this while developing Data.fs. Without advice from someone who really knows, I do not recommend doing this on your work site.

Answer 6

As a rule, there is no reason for the integrator or developer to touch the ZMI of another for possible maintenance tasks. Almost any configuration can be done using Python or the GenericSetup profile. The advantage of profiles: repeatability - the ability to support the file system - the ability to place files under version control.

The ability to work and tune things through ZMI partially works against Plone - especially when Plone does extra things under the hood. Therefore, the only recommendation may be: stay ZMI, if possible. ZMI is not a suitable replacement for using the Plone user interface and should only apply if you really know what you are doing.

Answer 7

Yes, ZMI is designed for the occasional maintenance task or, when pressed, quick and dirty CSS or template settings. This is not intended for any real "coding" work, and in the context of Plone it is best to be considered as odd and minimally useful from the history of Zope.

Answer 8

portal_actions is also useful for more flexible top-level navigation. but again, it’s best to configure through gnericsetup.