9

I have a Schema called MySchema with a field called Field1 and would like to rename the field to Field2. I did a test and it seems that changing the name of a field does not update the field in Components already deriving from this Schema (related documentation - requires login).

What is the correct way to rename a field and have it change in all derived Components?

  • +1 for a clearly defined "Component Synchronization" question. It's a Good Thing schema changes don't automatically change components based on them. Aside from performance in terms of updating all components per schema save, a single save could break templates or worse, remove content. I explain the "safe" changes in this post. Even the synchronization option in Content Porter only handles adds, removes, and re-orders. – Alvin Reyes Jun 8 '13 at 11:30
12

When you opened your Schema to edit it, you got a notification indicating that your changes would not be updated in derived Components.

(in 2013 it mentions Changes to this Schema will affect all related items. together with a Show Where Used button, agreed this isn't as clear as it was stated in older versions, but I believe this is the least read message anyways, so no matter what it said, people just don't seem to be willing to read it ;o).

Also the documentation you mentioned specified this with the following note:

Note: Existing items based on the Schema are not automatically updated. For example, if you remove a field from a Component Schema, Components based on that Schema that have a value set for the removed field will continue to contain that value. The value will only be removed when the Component is opened and saved, either in the Content Manager Explorer GUI or when using the Content Porter application.

To update all derived Components, you have to (manually) edit all those Components. On some changes, the UI will already try to fix your changes (like removing values for fields which are no longer in the Schema, or reordering fields according to the Schema), but I don't think a field rename is something that the UI can cater for (apart from the order there is no way of identifying which field you renamed).

So options you have are:

  1. Manually open all Components and fix the content
  2. Write a (Core Service) script which will change the content of all affected Components

Last thing, which is not a real option perhaps, don't make the change, just change the description of the field in the Schema and leave the XML name as is.

  • Thanks Bart. In my "real life" problem "1" is not an option for me as I have thousands of components derived from the schema. I'm happy to use number "2" but thought there might be another easier way (many/most Tridion users are not programmers). – Kevin Brydon Jun 7 '13 at 11:59
  • 1
    @KevinBrydon true, but most regular Tridion users might also not have the rigths to change a Schema, certainly not the need to change the XML name of a Schema field (as that is only used by Template developers anyways?). So considering you already have a lot of content created on the existing Schema, I'm assuming there will also be at least one or two Component Templates based on it, I would NOT make the change of the XML field name (change the description if needed that is non intrusive). – Bart Koopman Jun 7 '13 at 12:31
  • @KevinBrydon If that is still not an option, can you edit your question and give more insight as to why you want/need to change the XML field name in the Schema, then perhaps I can update my answer towards the new info? – Bart Koopman Jun 7 '13 at 12:31
  • I'm currently in the process of adding a lot of data (tens of thousands of components) into Tridion. I'll get round to creating the component templates etc afterwards. I need to change the field name because I've changed the Schema design slightly and what the field is currently called doesn't make sense anymore. However, I was looking for an answer in a more general sense, not specific to my problem. – Kevin Brydon Jun 7 '13 at 13:28
  • @KevinBrydon Schema changes are always a huge topic of discussion, there will be some that say you should never do it, but I also understand that insights can change over time. Still, if you have a lot of content already based on a Schema, I would vote against changing XML field names and live with (and document) a less descriptive name. – Bart Koopman Jun 7 '13 at 13:33
3

As Bart says, I would strongly recommend that you do this using the core service.

In addition to this, whenever I have done this in the past, I have always done this in two 'passes'. The first pass iterates through all of the Components and just copies the contents of Field1 to Field2. (This then gives chance for testing to take place, whilst maintaining the original content.) The second pass would then remove Field1 and re-save the Components.

Obviously you will also want to fully back-up your Tridion CM database before starting this work.

  • You don't need to do this. Versioning still works fine across a schema change. But yes - a db backup is always prudent! :-) – Dominic Cronin Jun 10 '13 at 19:14
  • It was the potential data loss (in the Components) rather than the changes to the Schema, that was the reason for taking this approach and just copying the content first. – Jonathan Williams Jun 19 '13 at 21:02
  • Versioning in a component should still work across a schema change, shouldn't it? I mean, you'd have to revert the schema to be able to do anything sensible with the components, but I wouldn't expect data loss. But now you have me doubting myself... :-) – Dominic Cronin Jun 19 '13 at 21:31
  • Ah, makes sense now. Yes, I agree that you would have to revert the Schema changes before being able to work with the Components again. Thanks for your clarification Dominic. – Jonathan Williams Jun 20 '13 at 6:10
2

For some kinds of schema changes, generic tools like the component synchroniser can be used, but for a field rename, you need to take care of it yourself. The obvious technology for this is XSLT. A field name would be a straightforward identify transform plus an explicit template to take care of the field in question.

To execute this, you can just do a where-used on the schema. A while ago I blogged about the poor man's component synchroniser. The example is written against the TOM, but you could easily update it to work against the core service.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.