Timeline for Publishing binares with Default Finish Action (PublishBinariesInPackage) vs AddBinary
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 21, 2014 at 13:43 | comment | added | James Scott | But what if the image had the same file name as the original file, this would cause a conflict would it not? Another reason for keeping the tcm ID on the end of the image is so that as editor uploads more images you can grantee a unique image. E.g. I have seen many images being uploaded as logo.jpg in the same publication. | |
| Oct 21, 2014 at 12:57 | comment | added | user3760419 | scenario you describe is not possible as localizing image (and changing it) in publication C and publishing would deploy a new binary to the file system. What I am interested in is how to prevent the same binary to be in the file system two (or more) times (which is built in PublishBinariesInPackage tbb and I want to replicate with AddBinary) | |
| Oct 21, 2014 at 12:44 | comment | added | James Scott | I think in this instance it would be safer to have 2 images and different references to them from each site. The reason I say this is if you had both sites looking at PictureX.jpg and then later down the line Publication B decides to localise the image and publish it out Publication C would also be updated as it references the same image. Again if Publication C where to publish the image again Publication B would then be, incorrectly, updated too. I think this could lead to editorial confusion especially if you have different editors managing the two different publications. | |
| Oct 21, 2014 at 12:36 | comment | added | user3760419 | I would like to see if I can reduce number of deployed binaries with the same content (the same way PublishBinariesInPackage is doing) | |
| Oct 21, 2014 at 10:16 | review | First posts | |||
| Oct 22, 2014 at 20:29 | |||||
| Oct 21, 2014 at 10:11 | history | answered | James Scott | CC BY-SA 3.0 |