We currently have a published Item that is live on our site.
We would like to add an additional value to an existing attribute.
The new value requires the model geometry to be altered and new logic to be added.
I have cloned the Item, Main, and Model that are used for the current setup.
The updates have been added to the clones.
What is the best practice for updating a current Item with this scenario?
Can I assign the revised Main asset to the existing Item without losing the current renders?
In terms of timing, when this new value goes live, Does the Publish/Unpublish option keep these renders from going live?
Would the Branching Beta option help with this scenario?
When it comes to renders, every render in the system is composed of a file in the file service with a fileId and a layer entry in the layer service with a layerId. The layerId is associated with a configuration and points to the fileId. This layerId is an entry in the database that stores the configuration association. These layer entries in the layer service cannot be associated with multiple configurations at the same time. They exist for every render permutation of a given layer in the layer comp for a given item. When cloning items, these layers in the layer service will not be cloned as well.
You can certainly make use of the new cloned item, but you would either have to re-render all images on the new item (which is not ideal), or run a script which uses the rest api to clone the entries in the layer system to associate the rendered files with the cloned item’s assetId.
Here’s a link to the layer api: Layers Service (Renders & AR)
You can use Get List Of Layers for an Item Get List of Layers to get the configuration data for each layer, and then use the Create Layer API Create Layer to create the new copies on the cloned item with the same configuration and fileIds.
In your case, it sounds like you’re taking this approach because you would like to make changes to assets before pushing them live, without the risk of a migration pushing these changes live before they’re ready. In this case, branching would indeed be the better way to handle this than cloning items, but I understand that we are not currently enabling branching for any other customers at this time.
I think your only option at this time would be to either develop the script I mention above, or avoid running migrations until you’re ready with the changes.
@AndreiSE Thanks for the suggestion to clone all the separate pieces of the item tree. What we’re really looking for is a way to make changes to an active product without having to meticulously time out our data transfers. Due to the complexity of our product, it can take us weeks to make certain types of changes. However, we really don’t like the idea of blocking the data transfer process for that long. We do a new product launch almost every week, which has the potential to need multiple data transfers depending on the feedback cycle. Here are some ideas we’ve had that would get us to where we want to be and why they won’t work as far as we can tell:
Concept: Prevent certain work-in-progress items from going through the data transfer process Blocker: No ability to restrict data transfer to anything but an all or nothing transfer
Concept: Use the Publish/Unpublish feature to lock down our player in our production instance to only published items. Make all changes in unpublished state so that when the data transfer happens it doesn’t change the published version of the item Blocker: Really not sure that’s how that feature is supposed to work because it didn’t work when I tried it. I may need some additional guidance here. The bigger issue for us is that it doesn’t appear that the Fast Compositor shows respect to the publish stage of an item, which we use extensively.
Concept: Mentioned above; Clone the item, break the connection to our site via custom ID and metadata, make changes to the clone, “activate” the clone when ready by changing metadata & custom ID to make active on our site. Blocker: Cloned items don’t also clone the layers & files that come along with it so we’d need to spend significant development effort to create a script to clone all of the pieces of the item/asset/layer tree.
We would be so grateful to hear any ideas you might have. Thank you for your time Andrei!
The publishing workflow is not designed for updating existing assets. It’s only intended to enable or disable items from appearing on the front-end. For updating assets in the way you’re describing, it sounds like your only practical option right now is to write that script I mentioned that duplicates the layer entries for the renders.
Sorry I don’t have a better option for you guys at this time.