It’s a story as old as time. You work hard to build a great site. You have all of the right properties, with descriptive names that the content authors recognize, and know how to use. Everything is going according to plan. The site is good. Life is good. The client is happy. Then BAM! A property requirement change comes along, you go in and make the change and everything is great again, except the zombie property apocalypse has just started, and they are coming after your content authors!

Okay, so the zombie properties won’t really eat your  brains. They are more commonly referred to as orphaned properties (but really, zombie properties just sounds so much cooler), and they are really more of an annoyance, but they can cause some confusion with your content authors.

The Steps that led to the Apocalypse

A new change request comes in; apparently the Marketing department wants to have more options when setting teaser text, so they are asking that the text area property for Teaser Text be changed to a rich text area. This is a pretty easy request, and probably won’t take that long.

You go into the code, and add a new Xhtml property. You give it the same display name as the old property, but a new property name, because you know that you can’t just change the property type.

The code builds correctly, the new property appears in the EditUI where you expect,

so you go on to update the views to use the new property. Once that is done, and everything works correctly, you delete the old property since it is no longer needed.

However, when your content authors go into edit the page, they see a new property at the top of the content tab labeled ‘TeaserText’. It has the old text, is not the rich text field that they wanted, and just looks like a string field.

So, what happened?

When you delete a property from code, at site start up Optimizely reads through all of the code in the model classes, and updates the properties in the database, add new properties, update existing properties, and attempting to remove deleted properties. However, if the deleted property already has a value on the page or block anywhere on the site, Optimizely goes for a more cautious approach and leaves the property in the database rather than deleting content values.

The good news is that since the views have already been updated, the old property will not be used, but it does clutter up the EditUI interface, and can cause some confusion if the content authors are updating that old field, and not seeing the changes on the page.

The Solution

This really comes down to a bit of CMS clean up at this point, but requires access to the AdminUI section.

Go to Admin > Content Type, and find the content type that has the zombie property, and click on the display name to see all of the properties. As you scan down the list of properties, you will see in the ‘From code’ column, and entry with ‘No’. That likely indicates a property that is no longer present in the code, but is still in the database. If this is your zombie property, click on the three vertical dots on the far right, and select ‘Delete’.

That’s it. Your zombie property should now be gone.

 

Zombie properties are anything but an apocalypse type of issue.  They are really more of an annoyance that only take a few minutes to clean up from your site. Just remember that you will have to repeat these steps on every site in your environment as your code changes move through the deployment process. But by doing all of this, you will be doing your part to prevent the dreaded Zombie Property Apocalypse, and everyone’s brains will be spared.