Old PDF File Appears Cached Even After Update

So there’s this PDF link that has been shared publicly. The client or stakeholder then wants to change the content of that file. However, he wants to preserve the old link. In a large organization, a content author jumps in to update that file but then he could not see the changes to that document, so he taps a developer to investigate the issue. Bells rang along the lines of Media caching in Sitecore, but before anything else, maybe, it was a process-related error to begin with. This is what happened to our old PDF link.

Upon investigation, I have retraced the issue with the following steps:

Initial Upload:

• An initial pdf file was uploaded in the CM Media Library folder (master)
• Sitecore then creates an item corresponding to it, with the actual pdf file attached as part of the Media field
• Content author publishes the Sitecore item to CD (web)
• The link is then provided to the stakeholders/client

File Update:

• The client/stakeholder requests to update the pdf file for new content changes
• Since the original link has been used for previous live links, the same Sitecore item will be updated so that the old link is preserved 
• Upon receiving the updated file, the content author deletes the current Sitecore item from CM
• The new file then is renamed with the same name with that of the old file
• File is then reuploaded in the same folder in the Media Library, thus creating the Sitecore item with the same name and new file attached
• Author then publishes the file to CD (web)
• Upon visiting the old link, instead of the updated file displaying, the old one renders

Root Cause:

• This happens because the old Sitecore item in the web database is still there AND the new item with the same name exists in the same folder
  
• When Sitecore finds two Media items with the same name on a same path, by default Sitecore renders the oldest one to live, thus the users see the initially uploaded pdf file.

Solutions:

1. To avoid this conundrum in the future, manually delete the published same-name Media item/s in the CD (if you have access to it) then upload and publish a new file from CM; or 
2. If you don’t have an access to CD, from CM, Unpublish, Delete, Add, Publish the Media item by following the steps below:
   • Show the Standard fields by going to the Content Editor Ribbon > VIEW tab and check the Standard fields
     
   • Then from the current Media Item that you wish to unpublish, click the Field Navigation button and start to type in “Never Publish” then click the field
     
   • Publish the item. This will remove the existing one in the CD (web database).
   • Once that has been successfully unpublished, delete this current Media item
   • Then just like the first solution, add a new pdf file and Smart Publish it.
   • NOTE: This is assuming that only one item of the same name is already in the CD.
3. If you are sure that only one Media item exists in the CD, a simple Media attach in the current Media item in the CM works
   • Navigate to the Media field and re-attach the new pdf file (detaching and attaching is the same as attaching only)
   • Save the current Media item.
   • Smart Publish.

Media Cache Clear:

• I have tried clearing the folder called /mediaIndexing inside the /App_Data manually in the Azure App Service file system and recreated the issue several times, but clearing it from either CD or CM instances did not have a different effect as with the solutions mentioned above.
• Therefore, a scheduled Media Cache clearing agent may not need to be implemented, if the steps above are correctly followed when updating a Media file.
• Disclaimer: If in some ways, this issue still persists, refer to following links for implementation: media cache clear or media indexing.
• NOTE: This scheduler implementation will require a CM/CD restart.