Data Type not being transferred to live environment
Hi all,
I need a little help with deploying into Uaas.
I'm trying to deploy content via backend - I can't get a data type to be transferred.
First time I tried to deploy, none of the custom data types were moved. (That felt a bit wierd, I was expecting all to be moved automatically, but I wasn't sure if they should). So then I tried manually creating one of them on live and redeploying, just to check if I need to manually create them. Weirdly enough, this time all datatypes appeared on live, and a the one I created was now redundant.
However, deployment still failed because of some un-synched stuff.
Then I deleted the redundant datatype, hoping Uaas will redeploy it next time, but that didn't work.
Tried updating the datatype on dev, to trigger some new commits, but that didn't work either.
From that point I can't get that datatype transferred on live.
Just tried to create a new document with a new custom data type. I can't get that deployed either.
All files are committed, but when trying to commit the content with that type I get that the document type and data type are not in sync.
So basically simple Uaas deployment does not work.
In my case the problem was caused by a new bug introduced with an Umbraco upgrade done by Uaas. However, the problem was fixed the same day after yelling at support.
This was in February, hope Uaas didn't commit it again :).
I think we found what caused the problem for you UaaS installation. Currently there is a issue with the MultiNode Treepicker unfortunately http://issues.umbraco.org/issue/COU-327
Looks like MNTP requires a start node ID, and doesn't yet work with just having a XSLT expression.
The Console Log didn't bring anything up. But using a "secret - only use in an emergency or you'll break stuff" back entrance to see the courier logs, brought up some answers.
These core datatype problems should be fixed with a matter of urgency, as its causing a un-necessary headache and cost (and loss of time) for clients. We aren't paying 99+ Euros a month to be guinea pigs.
Is this fix in this weekend's courier update that hopefully has the fixes for those costly deployment issues? Haven't seen the release notes yet so can't tell and I could really do with it this weekend.
Data Type not being transferred to live environment
Hi all,
I need a little help with deploying into Uaas. I'm trying to deploy content via backend - I can't get a data type to be transferred. First time I tried to deploy, none of the custom data types were moved. (That felt a bit wierd, I was expecting all to be moved automatically, but I wasn't sure if they should). So then I tried manually creating one of them on live and redeploying, just to check if I need to manually create them. Weirdly enough, this time all datatypes appeared on live, and a the one I created was now redundant. However, deployment still failed because of some un-synched stuff.
Then I deleted the redundant datatype, hoping Uaas will redeploy it next time, but that didn't work.
Tried updating the datatype on dev, to trigger some new commits, but that didn't work either. From that point I can't get that datatype transferred on live.
Any ideas?
Just tried to create a new document with a new custom data type. I can't get that deployed either. All files are committed, but when trying to commit the content with that type I get that the document type and data type are not in sync.
So basically simple Uaas deployment does not work.
Got the same problem - and still awaiting a response/fix/reason back from the UAAS team.
Com'on HQ - you can do better than this, surely
Hi Paul,
In my case the problem was caused by a new bug introduced with an Umbraco upgrade done by Uaas. However, the problem was fixed the same day after yelling at support. This was in February, hope Uaas didn't commit it again :).
Hi Paul,
I think we found what caused the problem for you UaaS installation. Currently there is a issue with the MultiNode Treepicker unfortunately http://issues.umbraco.org/issue/COU-327
Best,
/Dennis
Looks like MNTP requires a start node ID, and doesn't yet work with just having a XSLT expression.
The Console Log didn't bring anything up. But using a "secret - only use in an emergency or you'll break stuff" back entrance to see the courier logs, brought up some answers.
These core datatype problems should be fixed with a matter of urgency, as its causing a un-necessary headache and cost (and loss of time) for clients. We aren't paying 99+ Euros a month to be guinea pigs.
Is this fix in this weekend's courier update that hopefully has the fixes for those costly deployment issues? Haven't seen the release notes yet so can't tell and I could really do with it this weekend.
is working on a reply...