A few things can make it more bearable, though:
- Customise default_error_message. That is, go to portal_skins/plone_templates in the ZMI and customise this template. Remove the call to metal:use-macro="here/main_template/macros/main".
Why? Because rendering Plone's full 404 template takes a few seconds on my machine. For some reason, this template has always been dog slow. For debugging, all you care about is the error message. By not referencing main_template, you get a plain-text error message, which renders instantly.
While you're at it, change <dd translate="" content="structure err_value"> to >dd translate="" content="err_value">, removing the structure keyword. This gives you a plain-text error message, which will not hide thing slike
in when the browser things its HTML.
- Add an external method with a pdb break point. e.g. I have Extensions/debug.py, which contains only:
import pdb; pdb.set_trace()
Then, either in the portal_skins/custom folder or just the root of the Plone site, add an External Method in the ZMI, with name debug-ex, module debug, method debug.
With this in place, you can go to http://localhost:8080/Plone/foo/debug-ex. Make sure you run Zope in the foreground (zopectl fg). Your browser will hang, but on the console that you launched Zope, you will get a pdb session, where self refers to the current context (i.e. foo in the URL above).
Here, you can do whatever you want, such as inspect the object or mutate it. Remember, you can import other code, call protected methods - do pretty much anything you can do on the interpreter shell. Type pp
to pretty-print a variable or an expression. Type c and press Enter to get your browser back.
- If you're using a Five browser view with a template (either via the template argument to the
ZCML directive or via an explicitly invoked ViewPageTemplateFile/ZopeTwoPageTemplateFile, remember that this does not have security assertions the way .pt files in portal_skins does. That is, you can do things like:
So long as you're in debug mode, the you can reload the page and see the output of that statement. This is quite useful for trying things out and quick-inspecting variables.
- Be ruthless with pdb. Sometimes you are wondering how something works deep inside Zope. So long as you revert your changes afterwards, you can put a pdb statement almost anywhere. For example, whilst debugging a security problem, enable verbose-security in zope.conf and try to put a pdb statement in AccessControl.ImplPython.validate(). You'll have to restart Zope obviously for this to take effect...
- Interleave your work. Sometimes, you need to restart Zope. This is slow. :) Learn to do two things at once, e.g. work on improving tests for other parts of the code, writing new interfaces or updating documentation while Zope is restarting, or go help someone with their problems on #plone on IRC :)