Embed code is different after save

I have noticed that the embed code is different after enabling the embed and then after closing the model.

After enabling:

After saving and closing the model:

This has caused us lot of headaches, because I used to copy the code straight after enabling it, but it was then invalid.

Can you please sort this out and as mentioned here: Feedback & suggestions, Shapediver, appbuilder and Shopify integration - #3 by HaRo Please let us update a model without a new code every time!!! I have copy/pasted and done all the same steps probably 100 times by now… it’s so tedious and error prone and the only reason for it is that you decided it should work like that. There is no technical reason I can think of that you shouldn’t be able to simply replace a .gh file.

Just thinking loud here, as i can read, there are big changes needed in the infrastructure to create a desktop connection from GH to shapediver. Could a solution be to have a ticket override module i GH?

If you have a model in shapediver that is iframed or connected to other apps/integrations and you want to make small changes/tweaks or a new version you can apply a previous ticket code to the new GH file and upload it and override a previous version?

I tried to reproduce this problem, but couldn’t. Can you reproduce this easily? If so, please let me know.

We are aware of this challenge for tickets and are taking steps to improve the developer experience of this. We are developing a solution that will allow to assign tickets to different versions of a model.

Please note that when using App Builder the models can be identified using their slug, which already allows for a kind of versioning, because the slug can be edited and therefore reassigned to newer versions of a model.

Yes, it happens every time as shown in the screenshots. I enable embedding and a code is generated, then I press Save and then Close. Now I go to the Developer Tab and the direct embed code is different with the one generated before being invalid.

I don’t quite understand. So I upload a new model, edit the slug and give it the same slug as the previous model? But doesn’t that mean that I have to delete the model to be replaced first, otherwise there would be 2 models with the same slug. That would mean that as soon as I upload a new model and rename the slug I already have to delete the current model, meaning the live website doesn’t have any model for a few minutes and if anything goes wrong I have to reupload the old model again. That actually seems even worse than what we are doing currently, because now you can revert the embed code in the app builder easily, because we keep a list of all the models. Having to rename models constantly, seems like it would get even more messy.

I want to be able to upload 1 model and then have a button to upload a new version. Then there is a simple dropdown to choose which version is the live one. That would mean when I log in I see 1 model and it has 100 versions, not 100 models that are all completely standalone. I know it might be difficult with how you built your system, but I am not sure why this was not immediately obvious from the beginning. Nobody just creates 1 version of a script for Shapediver that is immediately perfect, but you go through a lot of iterations.

Could you describe exactly the steps that lead you to see two different tickets? I just did this:

  • Upload a model
  • Enable direct embedding. I then see a ticket.
  • Save the model.
  • Leave the edit page and visit the model page.
  • In the developers tag, the ticket is the same one I got on the edit page.

If you are following different steps, let me know so I can try to reproduce it on my end.

Regarding your comments about versioning: implementing a proper versioning mechanism is one of our absolute priorities for next year. Over the past months, we have considered it from multiple angles (your embedding use case is just one of many). We believe that a versioning feature doing what you need, and working closely to the user experience you describe, should be implemented soon in the platform. We will keep you updated as we make progress about this topic.

1 Like

Of course it’s one of those Schrödinger’s Bugs. When I record my screen to show you, it doesn’t do it any more.

I will keep note under what circumstances it happens, but the 2 screenshots in my first post were of the same model taken 27 seconds apart as you can see from the file name.

Glad to hear that versioning is coming and that it’s a top priority!