Attribute management in eZ Publish with eep, and robust dev practices

I recently had a lucky moment and was saved by a happy combination of things, including Assembla, eep, and a couple bits of dev-ops.

We have a piece of code that we reuse over a number of different clients and to which we are always adding tweaks and features. (Specifically, the ONIX Data Bridge.)

Several months ago, I added a major feature that required some new content classes and some specific content structure. In practice, this sort of thing is a nuisance in eZ land because, on the one hand, it is important to get it right and, on the other, it's easy to goof it up -- especially if you have to do it manually across a bunch of instances (say, local dev, staging, and production; or clients A through Z).

Well, eep to the rescue. Rather than do it manually in just a few minutes: I modified some XML to spec out the new attributes; which I pushed into git; wrote a trivial bash script to do almost all the work, which I put into the relevant Assembla ticket; and sent it all back to the guy who requested the work.

A typical Mugo workflow

This is pretty typical of our workflow at Mugo. Anyone can be responsible to anyone else for delivering a piece of work, and we use Assembla to manage the transaction. It's just a really nice ticketing system with all the bells and whistles we need. We use old tickets all the time to track issues, commits, and all the discussion around a piece of work. It's difficult to imagine living without it. In this case, my colleague Ben deployed my updates to all the client sites and the new feature was rolled out.

I said "all the client sites," but I really meant "all the client sites that needed the update." A couple of days ago, I pushed an unrelated change on one of the other sites and sent my previous code along with it. Bit of a screw up on my part, but here's where Mugo practice and the wisdom of the Previous Me came into play.

Saved by our dev practices

First thing, I got a huge red email from the site I'd just broken warning me that something was wrong. Thanks, Previous Me! 

"Hmm," I thought to myself, trying to buy some time.

So, I had a quick look and the eZ log file pointed out that there were some missing content classes.

"Ah ha!" I thought to myself, "You're an idiot."

So I pulled up the ticket, copy and pasted the eep commands into a command line, cleared some cache, and the Data Bridge process was back in business.

For a possible reader's edification, this is verbatim from the ticket:

(One thing to note, "cc" is a shortcut that eep recognizes to mean "contentclass".)

# create the content class which will root the custom category list
eep cc createclass "Custom category folder" "ONIX"
# result: created custom_category_folder ok

# add the one attribute to the custom category container
eep at update custom_category_folder extension/onix2import/bin/eep/new-attributes/add-cust-cat-title.xml
# result: Attribute with ID nnn added

# set the rules for content-object title and content-object url
eep cc setfield custom_category_folder contentobject_name "<title>"
eep cc setfield custom_category_folder url_alias_name "<title>"
eep cc setfield custom_category_folder is_container 1

# create content class for the custom categories
eep cc createclass "ONIX Custom category" "ONIX"
# result: created onix_custom_category ok

# and create the one attribute for the custom categories
eep at update onix_custom_category \
extension/onix2import/bin/eep/new-attributes/add-cust-cat-category.xml
# result: Attribute with ID nnn added

eep cc setfield onix_custom_category contentobject_name "<custom_category>"
eep cc setfield onix_custom_category url_alias_name "<custom_category>"

# create an instance of the container
eep create quick 2 custom_category_folder | awk '/new object id/ {print $4}' | xargs -I OID eep attribute fromstring OID title "Custom Categories"
# intermediate result: new object id 752 new node id 740

# update onix_product by adding object-relation-list to point to the onix_custom_category objects
# NOTE! -- you will have to move the browse location to the custom category container node id (above)
eep at update onix_product extension/onix2import/bin/eep/new-attributes/add-obj-reln-cust-cat.xml
# result: Attribute with ID ### added / Percent complete: 100.00%

To sum up, this creates two rather simple content classes, but does it properly. It creates an instance of one of the classes, initializing a value in the instance. And it updates an existing content class with a new attribute -- a content class with 100,000 instances, which eep does reliably and restartably, if that's a word. The ‘restartable’ feature here perhaps merits emphasis: in some cases you can find yourself in trouble with a server or network that sucks and then you can run the risk that a long-running process will fail leaving your system in some weird state. For this operation, eep will allow you to rerun the command and resume converting content classes smoothly.

Last note, even though I’m a fan of scripting everything, sometimes it is truly faster to just do something manually. So, yes, this script could have automated the two manual steps as well, but the goal is to be fast and reliable, not merely reliable.