I just copied the content, macro's and templates from my local development environment to my test-environment with a package. But now I noticed that in my test-environment the id's of my content-items are changed. In the package.xml the correct ID's are used.
It is default behaviour. If you imported a package into a site with existing content, you wouldn't want the the imported id's clashing with the existing id's.
You cannot rely on content item id's in your packages. As stated in this answer, you can perhaps add a step to update ID's in relating xslt-files or other places after the content has been created.
thanks for the answer, although it's not making me happy ;) This standard behaviour might cause some issues in an environment when the production environment is beign used and filled with content and the developers are implementing new functionalities.
Another option is using a GUID as itemID instead of an int. This way the packager can re-use these ID's as they should be unique and the packager could aks the user to overwrite or skip the item in case of a duplicate id.
* EDIT * I heard this is going to be changed in Version 5 :)
You're right about the Guid offcourse, but unfortunately Umbraco isnt using guid's for document identifiers, so on 4.7 and earlier you will have to handle this situation in your code, since the Umbraco codebase isn't going to change in this regard.
About v5, it may very well be true that it will use GUID's as document identifiers, v5 has been recoded from the ground up and will as I understand it among other things be using a whole new persistence model (Hive), that will also make it much easier to link to external data sources in Umbraco. There will be an entire session about this on Codegarden 11.
I had a small twitter "conversation" with Niels Hartvig about the use of GUIDs and as I understood, version 5 is going to use them, among a complete re-coding of the core :) Too bad I'm missing Codegarden 2011 :(
Package changing ID's of content items
I just copied the content, macro's and templates from my local development environment to my test-environment with a package.
But now I noticed that in my test-environment the id's of my content-items are changed. In the package.xml the correct ID's are used.
Is this default behavior?
Hi Martijn,
It is default behaviour. If you imported a package into a site with existing content, you wouldn't want the the imported id's clashing with the existing id's.
You cannot rely on content item id's in your packages. As stated in this answer, you can perhaps add a step to update ID's in relating xslt-files or other places after the content has been created.
Regards
Jesper Hauge
Hi Jesper,
thanks for the answer, although it's not making me happy ;)
This standard behaviour might cause some issues in an environment when the production environment is beign used and filled with content and the developers are implementing new functionalities.
Another option is using a GUID as itemID instead of an int. This way the packager can re-use these ID's as they should be unique and the packager could aks the user to overwrite or skip the item in case of a duplicate id.
* EDIT * I heard this is going to be changed in Version 5 :)
Hi Martijn,
You're right about the Guid offcourse, but unfortunately Umbraco isnt using guid's for document identifiers, so on 4.7 and earlier you will have to handle this situation in your code, since the Umbraco codebase isn't going to change in this regard.
About v5, it may very well be true that it will use GUID's as document identifiers, v5 has been recoded from the ground up and will as I understand it among other things be using a whole new persistence model (Hive), that will also make it much easier to link to external data sources in Umbraco. There will be an entire session about this on Codegarden 11.
Regards
Jesper Hauge
Hi Jesper,
I had a small twitter "conversation" with Niels Hartvig about the use of GUIDs and as I understood, version 5 is going to use them, among a complete re-coding of the core :)
Too bad I'm missing Codegarden 2011 :(
Regards,
Martijn
is working on a reply...