ContentBox and PostgreSQL - Spring 2014 Edition

About twice a year, I download ContentBox and hope that I'll be able to use it to replace my old MachBlog installation. I just completed the Spring 2014 evaluation, and sadly I still can't make the switch. ContentBox 1.6 doesn't yet work with PostgreSQL 9.3. You can get pretty close if you do some hacking on several of the CFML ORM components:

  • Find all the components that define an ORM property of boolean type that use an integer for the dbdefault value. These need to be deleted. The components themselves have property defaults, so it shouldn't be necessary to create a column default in the database.
  • Modify modules.contentbox.model.content.Category to change the index name from idx_slug to something else, perhaps idx_category_slug. The stock name conflicts with the index in modules.contentbox.model.content.BaseContent.
  • Modify coldbox.system.orm.hibernate.BaseORMService to evaluate all criteria aimed at boolean columns and swap the integer values for booleans (t or f vs. 1 or 0).

You'll also need to manually create a sequence called hibernate_sequence because the Hibernate ORM PostgreSQL Dialect can't/won't create that when it creates all the DDL statements. You can cut-n-paste from here:


Once the ContentBox schema is setup, the ContentBox installer will try to save some initial configuration values. I gave up at this point. There were just too many exceptions in the ColdBox ORM Services when interacting with Hibernate against PostgreSQL. If I were to continue evaluating ContentBox, I'd abandon PostgreSQL for MySQL. I see that work is being done on ContentBox 2.0 for PostgreSQL compatibility. Maybe I'll try again in Fall.

Oh, and I should mention that I tried all the permutations of Railo,, and, with and EnterpriseDB PostgreSQL 9.3.4 for Mac OS X. The bleeding edge Railo 4.2 has a new issue with WireBox due to a collision in the map() function name. Unfortunate, but unrelated.

Setting up ContentBox

I download a copy of ContentBox 1.6.0 tonight to experiment with it as a personal blog replacement. While I was at it, I grabbed the Apache Tomcat 7.0.52 and Railo 4.2.000 Beta. I'm giving the super-easy a try for local development.

After deploying the Railo WAR file, I went into the Railo Server Administrator to give it a password and set some preferences. I went into Settings - Scope and set cascading to Strict, among other things. I don't often get a chance to configure a CFML engine without regard to legacy applications, so I went hog wild.

I wrote an Apache Ant build script to fetch the ContentBox archive and deploy it into the Tomcat webapps path. I'll put all my source in a Github repo to share later. With ContentBox unzipped, I hit it with a browser. The ColdBox app redirected to a module called contentbox-dsncreator, prompting for the datasource name. I gave it the DSN created in Railo, pointing to my developer version of the database, and clicked the Verify Datasource button. I received a JavaScript alert after the page finished its Ajax request to /modules/contentbox-dsncreator/handlers/verifyDSN.cfm?dsnName=blog:

Error verifying datasource: attribute [datasource] is required, when no default datasource is defined you can define a default datasource as attribute [defaultdatasource] of the tag cfapplication or as data member of the Application.cfc (this.defaultdatasource="mydatasource";)

It's caused because the verifyDSN handler does what we've done in the CFML world for years and years:

<cfparam name="dsnName" default="">

Because I enabled strict scope cascading in Railo, the tag never finds the query string parameter. Setting that Railo option back to "Standard (CFML Default)" makes that line of code behave as intended. Any old-timer reading this will have just exclaimed "Well, duh. Of course." Besides being helpful to anybody that Googles that error message in the future, I'm writing all this is to argue that being scope-explicit is a good thing. I'm as guilty as the next guy/gal about these sorts of unscoped variable references, but I'd like to encourage the CFML community to change their practices. Write arguments when you expect something from the arguments collection; scope with url when you know the parameter is part of the query string; use the query's name when fetching column values, et cetera. Okay, I'll get off my SoapBox and get back to ContentBox now.

Of course, I'll fork the repo, make a tweak, and send a pull request. I mean, duh.

Changing your Adobe email address

There is currently an error in the JSON parsing of saved user billing/shipping information on Adobe's My Information page. It causes the busy overlay to remain, preventing interacting with the forms beneath. The symptom of the problem looks like this:

Adobe My Info Bug Stuck Overlay

I wanted to get in there and change my email address from to because I've recently been getting A TON of spam due to my email address being among the 150 million records in the Adobe data breach last November. Of course, I used a strong, unique password before the data was compromised, so I don't have to worry about my credentials on other websites (I recommend 1Password and LastPass if you're still playing loosey-goosey).

At any rate, this is the cause of the busy overlay being stuck on:

Adobe My Info Bug Javascript Exceptions

Perhaps my data was saved in an old format and their new web application can't parse it correctly. No matter, we can get around the problem by manually deleting that element from the DOM. Just open up the JavaScript console and execute the following:


Et voila! Now the form can be edited. You will receive an error when an Ajax validation attempt is made: "NetworkError: 404 Not Found -" Apparently, they don't use that account status check anymore. Regardless, the form will save the new email address and allow the verify address link to be visible and clicked.

Adobe My Info Bug Overlay Removed

This is yet another reason I recommend creating a unique email address for every website on which you create an account. Seriously, consider it if you have the ability to run your own mail servers. It's interesting to see when specific vendors leak their user's data -- sometimes before they know of the issue or acknowledge it publicly.