Bitballoon’s (POST) form handler normally responds with a generic Bitballoon-branded “thanks” page.  If you have a reseller platform, you can customize this across your customer sites to brand it on your own. 

But individual sites, and in fact individual forms, can customize their own “thanks” page.  To set up a custom “thanks” page:

  • Build a page in your site tree called “thanks.html” (or anything else — but it must have the .html suffix)
  • In your <form> HTML, set the form’s @action to point to the thanks page, with the .html suffix.  

So, for example: <form action=”/thanks.html”>

Bitballoon will strip out the .html suffix on the page itself and in the form action attribute, so the deployed site will have <form action=”/thanks”> instead.  The form submission will be captured in the Bitballoon database and the user will see your “thanks” page as the response (including seeing the URL /thanks in the address bar).

Using this technique you can point all of the forms on a Bitballoon site to the same thanks page, or to a distinct page per form.  In fact (though I haven’t tested this) you could even point a form to submit back to the same page that the form is on.

When Bitballoon responds to a form POST, it will also inject a special Javascript snippet into the page head.  This javascript will set a global variable called “FormSubmission”, which will be an object containing all the submitted form data (in and some metadata like the submission’s unique non-sequential id, the timestamp of the submission, and the name of the form that was submitted.

You can use this to place conditional content on your page: with Javascript, check for the existence of the FormSubmission variable.  If it’s set, then you know that this is the response to a POST request that submitted a particular form, and you can display a “thanks” message, or fill in the data on the form if you’re submitting back to the same page, etc.

Filed December 21st, 2013 under bitballoon

On a Bitballoon site, you can customize the 404 page by including a file called “404.html” in the root of your website tree.

Bitballoon will strip out the “.html” suffix so the page will be served at /404, and will also be served whenever a request is made to a nonexistent page.

Note that (at least currently) this feature does not work with the following variations:

  • The file you upload cannot be called “/404″ — it must be “/404.html” with the suffix.
  • The file you upload cannot be called “/404/index.html” (even though this trick works for “regular” pages) — it really must be exactly “/404.html”.


Filed December 21st, 2013 under bitballoon

This openfsm project export is really slow.  Still only at “f”s.

Filed December 16th, 2013 under Uncategorized

The openfsm project export is happily chugging along (it’s been running all night; we’re almost through the “e”s) so this is a good time to circle back and write up some opencore build troubles I ran up against yesterday.  It had been about a month since I last built an opencore site, so, as usual, the build stopped working.  Here’s the problems I ran into:

  1. The setuptools bootstrapping code in decided to fetch setuptools 2.0 (!there’s a 2.0 now!?) which doesn’t support Python 2.4.  Normally we install the venerable setuptools 0.6c11.  The bootstrapping code already has built-in logic to look for an existing setuptools egg in one of several filesystem locations before resorting to the internet.  So I just had to add a step to wget setuptools-0.6c11-py2.4.egg into the root of the build directory before fetching and executing, in the rebuild-opencore-site script.  I added that here.
  2. The opencore build was set up to use an editable SVN checkout of zope.dottedname 3.4.5 for some reason instead of just installing that release from PyPI.  This wasn’t working yesterday, probably because of the recent Zope SVN move.  So I just changed the build requirements to install the release from PyPI instead.
  3. Wait, no, that broke everything!  After building an opencore with that release from PyPI, my Zope environment had gone crazy: attempting to start it up at all failed with an `ImportError: no module interface` during `from zope.interface import Interface`.  At first I assumed I had somehow pulled in some post-3.4 zope.* egg that ended up installing a whole parallel zope universe.  But this opencore-dev thread gave me a useful hint.  It turns out that fassembler’s version of pip deals badly with namespace packages installed non-editably: doing that non-editable install of zope.dottedname caused pip to clobber the entire zope.* namespace.  So instead I changed the build requirements to install the release editably from Github.
  4. Last problem … the build needs to download two large tarballs (Zope, and opencore’s Plone Product bundle) from, which is a Github Pages site.  It seems that Github has decided to throttle downloads aggressively from the server I’m building on: both downloads get 20-80% complete and then hang indefinitely, whether I’m using the fassembler build code or wget.  So I had to download the tarballs to my local computer, scp them to the server, put them in the root of the build directory, and then convince fassembler not to re-download them.  I haven’t yet cleaned up & committed the code for this one — I just edited it locally to comment out the download logic — so I’ll circle back to it before my next rebuild.
Filed December 15th, 2013 under openfsm

Today I am:

  • Copying the live openfsm site’s Data.fs to a backup location
  • Building a new opencore site (frontdown.openfsm) against the copied Data.fs
  • Running the full export procedure against the newly built site 

And also:

  • (code to import member account notifications)

Next step will be to run the full import procedure:

  • Build a new opencore site with a fresh ZODB
  • Run the import scripts
  • Test


Filed December 14th, 2013 under openfsm