2

In Publication properties, I changed the value for Images Path and Images URL to \media\mysite and /media/mysite/

While publishing the image, it is stored in the Broker database by appending tcmid to the image name

I am able to access it, if I append Publication ID to the path http://{domain}/media/mysite/{image-name}_tcmxx-xx.jpg

But I don't want TCM URI appended to the images name ex: http://{domain}/media/mysite/{image-name}.png.

Actually we also tried writing custom code (TBB), in DB it is storing in proper format but when I am retrieving the image it is appending with ./index at the end.

Please help on this. Is there any other alternatives without TCM URI appending?

1
  • 1
    Try storage extension. That will be the best option for this kind of requirement. Commented Apr 29, 2017 at 3:41

1 Answer 1

2

+1 for what Sayantan said.

Now, This behavior avoids duplicacy of binaries and is default nature. It also appends width & height in some case (Ex: ballon-burner_tcm5-258_w1024_h311_n.jpg).

Little bit of background on this

The Default Finish Action Template contains a TBB called - Publish binaries for component It uses a PublishBinariesComponent, which calls ConstructFileName of BinaryPublisher.

    private static string ConstructFileName(Component mmComp, string variantId)
    {
        Regex re = new Regex(@"^(.*)\.([^\.]+)$");
        string fileName = mmComp.BinaryContent.Filename;
        if (!String.IsNullOrEmpty(fileName))
        {
            fileName = Path.GetFileName(fileName);
        }
        return re.Replace(fileName, string.Format("$1_{0}_{1}.$2", mmComp.Id.ToString().Replace(":", ""), variantId.Replace(":", "")));
    }

This method returns the binary file name at Rendering - engine.PublishingContext.RenderedItem.AddBinary(). One of the overload method AddBinary(Stream, String, String, Component, String) also give liberty to set filename of your choice but this is limited i believe.

Look at the code below: If you see the else part - ConstructFileName(mmComp, currentTemplate.Id) is called when targetStructureGroupUri is not null, this value comes from your parameter schema of Publish binaries for component TBB.

    if (targetStructureGroupUri == null)
    {   
    ....
    Binary binary = engine.PublishingContext.RenderedItem.AddBinary(mmComp);
    publishedPath = binary.Url;
    log.Debug(string.Format("binary is published to url {0}", publishedPath));
    }
    else
    {
    Component mmComp = (Component)engine.GetObject(item.Properties[Item.ItemPropertyTcmUri]);
    string fileName = ConstructFileName(mmComp, currentTemplate.Id);
    StructureGroup targetSG = (StructureGroup)engine.GetObject(targetStructureGroupUri);
    itemStream = item.GetAsStream();
    ....
    log.Debug(string.Format("publishing mm component {0} to structure group {1} with variant id {2} and filename {3}", mmComp.Id, targetStructureGroupUri.ToString(), currentTemplate.Id, fileName));
    Binary b = engine.PublishingContext.RenderedItem.AddBinary(item.GetAsStream(), fileName, targetSG, currentTemplate.Id, mmComp, mmComp.BinaryContent.MultimediaType.MimeType);
    publishedPath = b.Url;    
    log.Debug(string.Format("binary is published to url {0}", publishedPath));
    }

So if you write a TBB (Create your custom default finish action Template) and add it.. right after Publish Binary for Component TBB to process received Output from Publish binaries for componentTBB then you might have some chance. The output should have publishedPath which is what you would need to get to your desired url.

Your Publish binaries for component parameter schema has all the values i guess which is used in the final binary url. Specially sg_PublishBinariesTargetStructureGroup value in your case.

There could be better ways indeed.

1
  • 1
    The reason why the file names (and URLs) of Binaries are suffixed with a TCM URI (or actually something that resembles a TCM URI) is to ensure that the file name (and URL) is sufficiently unique to distinguish it from other Binaries. The first part of the file name is taken from the (original) file name of the Binary Content of the Multimedia Component. However, the system does not enforce that those (original) file names are unique. Since (by default) all Binaries are published in the same location, only the (original) file name may not be sufficiently unique. Commented May 1, 2017 at 17:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.