As useful as the ZMI is for providing through-the-web (TTW) access to your content, sometimes you really want a commandline tool to be able to "poke" at things. Something, for example, like the python interpreter. The debug option to zopectl gives you exactly that: it launches the python interpreter, puts the Zope directories in the import path and defines an app object that represents the root object of the ZODB.

Let's take a look at an example:

  >zopectl debug
  Starting debugger (the name "app" is bound to the top-level Zope object)
  >>> for o in app.objectIds():
  ...   print o
  ...
  acl_users
  Control_Panel
  standard_html_header
  standard_html_footer
  standard_error_message
  QuickStart
  index_html
  temp_folder
  browser_id_manager
  session_data_manager
  Examples
  error_log
  standard_template.pt

This should look like the list of objects you see when you look at your Zope's ZMI (although not sorted).

Useful things to do using the debug interface:

These examples assume a Rhaptos site has been created with the id plone

Get a plone member by ID

member = app.plone.portal_membership.getMemberById("foo")

List all registered members

This example makes use the the CatalogMemberDataTool Product: members = app.plone.member_catalog()

Search for all members with Rice email addresses

This example also makes use of Dieter Maurer's amazingly powerful AdvancedQuery Product:

    from Products.AdvancedQuery import MatchGlob
    rice = app.plone.member_catalog.evalAdvancedQuery(MatchGlob('email', '*@rice.edu'))

List the groups to which a member belongs

groups = app.plone.portal_membership.getMemberById("Crouton").getGroups()

List the members of a particular group

members = app.plone.member_catalog(getGroups="group_wg82")(Note the group_ prefix on the group ID)

Get a published module

module = app.plone.content.getRhaptosObject("m0000", "latest")

Notes

• If you do not use ZEO, you must stop your running zope server process in order to use zopectl debug. If you use ZEO (which you should anyway) you can run the debug process concurrently with the zope server. On that case the debug process simply becomes an additional front-end
• Changes made in the debug interface are not committed unless you enter get_transaction().commit() This means you can experiment as much as you want without fear of corrupting the live data.

  Warning: The one exception to this is module publication: because CVS is not aware of Zope's transaction machinery, modules published under zopectl debug will appear in CVS even if you don't commit the transaction.

• If you need to get changes to the ZODB made by other frontends after your debug session started, enter app._p_jar.sync() This will sync ZODB changes other frontends have commited into the memory image of your frontend.

• Holger Krekel's rlcompleter2 makes the debug interface even more useful by adding <tab>-completion for functions and object attributes. To use it, install the package and then place the following in ~/.pystartup :

      import rlcompleter2
      rlcompleter2.setup()
      del rlcompleter2
  

Then pass this file as an argument to zopectl debug: zopectl debug ~/.pystartup . Note: this will only work if you patch your zope instance to allow passing arguments to debug. This should be sent in as a contribution to Zope.

• By default, the debug interface runs as the anonymous user. If you want to switch to, say the Crouton user, run the following:

      from AccessControl.SecurityManagement import newSecurityManager
      user = app.plone.acl_users.getUserById('Crouton')
      newSecurityManager(None, user)
  

• Some Zope object's methods require a valid REQUEST object. To do this:

      from Testing.makerequest import makerequest
      app=makerequest(app)