9

We have binaries which are both dynamic, but can also be manually added to components. PDF's in this particular case.

  • The binary is unpublished
  • The references to the components it was linked to have been removed
  • The related pages (where the components where on) have been re-published.

But, the binary (PDF) is still available when requested directly. Yes, cache had been cleared ;-)

What am I missing here?

Update: They are being published using the XSLT Mediator, so in the C# code the binary is published using:

this._engine.PublishingContext.RenderedItem.AddBinary(component);

  • 1
    It is important to know how the binary was published in the first place, if it was published as a managed multimedia component or variant, then when not referenced anymore it will be removed, but if it was made available as an unmanaged binary, then the file has to be removed manually. What do you know about the template code which made this binary available in the first place? – Bart Koopman Jun 3 '13 at 13:36
  • Added this information to the question – Hendrik Beenker Jun 3 '13 at 13:49
  • The default AddBinary method should generate a managed binary (the filename will contain a TCMURI), so if that is still there, it sounds like there is still a reference to it somewhere (might want to check the information in the broker for that) – Bart Koopman Jun 3 '13 at 14:21
9

As you probably know by now, the decision to remove a binary is taken by the deployer based on the number of references to that binary. Once the number of references reaches 0, the deployer will remove the binary.

If you have access to the Broker database, you can try to find which items reference a given binary by running a query +/- like this:

select * from REFERENCE_ENTRIES where REFERENCED_URI='tcd:pub[13]/binarymeta[1625]'

Where pub[13] should be updated to match your publication ID and binarymeta[1625] should be updated to match your binary's component ID. This will give you a list of the Component Presentations and/or Pages that reference that binary. If you get 1 or more results, it means that the deployer cannot remove the binary because it's still needed. If you do get 0 results then you may be in the "unmanaged binary" scenario described by Bart & Pankaj.

| improve this answer | |
  • How much do old versions get in the way of this? It shouldn't matter, right? And other publications? – Hendrik Beenker Jun 3 '13 at 19:42
  • Only "published" versions, the deployer couldn't care less about CM versioning, and only "in current context". The same binary published in a different publication will not interfere with this reference count - as far as the deployer is concerned, it's NOT the same binary (and that could very well be true, it could be a translated PDF for instance) – Nuno Linhares Jun 3 '13 at 19:56
  • It took a while, but upon inspection in the database there were some "faulty" references still stuck to the binary. It must have happened somewhere with database replication or testing during a development process. – Hendrik Beenker Jun 14 '13 at 8:57
8

Please understand following:

Every time you publish a PDF, SDL Tridion maintains a reference count in the Broker database. On the other hand, when you un-publish a PDF the reference count is reduced.

Once the reference count hits zero the PDF will be removed from the file system.

Now check even after un-publishing whether it is still available on the file system and that should be only reason it is appearing while requesting directly.

My suggestion, try "Where Used" for the PDF and un-publish all the components/pages it is associated with in addition to un-publishing the PDF individually with the dynamic template.

Additionally, you may try creating a fresh PDF component, and try your publishing-un-publishing process to check if it getting removed from the file system or not.

| improve this answer | |
  • I was hoping on a an answer that doesn't require unpublishing and republishing. Usually a re-publish should remove any reference information of binaries. – Hendrik Beenker Jun 3 '13 at 13:54
  • You are right, my suggestion is just to ensure that there is nothing related to the template. As @Bart has also mentioned it depends what was the code publishing it dynamically. – Pankaj Gaur Jun 3 '13 at 14:09
4

I've seen this problem after synchronizing DTAP environments (DB restore from PROD to ACC) where the binary was removed on PROD and there is no way left to remove the reference from the ACC broker...

Can you verify this problem is reproduce-able with new items? So creating a new MM component, putting it "into a page" via a component link and publishing the MM component itself, then removing the MM component from the page (by breaking the component link) and then republishing the page and unpublishing the component?

Does that always leave you with no references to the binary in the broker and a removed file (the expected situation for a working product scenario)? Or is the result different?

| improve this answer | |
  • Bjørn, we did not do any restores or other synchronizing. But, I did try to recreate this issue with new items. I wasn't able to, so I guess something somewhere didn't work out along the line... – Hendrik Beenker Jun 7 '13 at 11:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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