Five small TTW debugging tricks

Sometimes doing debugging through-the-web is unavoidable. Templates are a prime example - I just spent the better part of two hours trying to work out why my use of metal:macro was not playing ball with a Five browser view (hint: understand what macro you're actually calling...). Sometimes I also simply don't know enoug about how something works to write a reliable and more easily debuggable test, and some trial-and-error is needed.

A few things can make it more bearable, though:

1. 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.
2. Add an external method with a pdb break point. e.g. I have Extensions/debug.py, which contains only:
   
   def debug(self):
   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.
   
3. 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:
   
   tal:content="python:foo._secretVariable.__of__(context).aq_chain"
   
   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.
4. 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...
   
5. 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 :)