Uploaded image for project: 'PUBLIC - Liferay Portal Community Edition'
  1. PUBLIC - Liferay Portal Community Edition
  2. LPS-142150

Always update document-urls in Web Contents to deliver the actual media ressource




      This Problem has been discussed with supoort in https://help.liferay.com/hc/en-us/requests/52488?page=1. 

      The issue is that images and links refering to urls from document & media are not updated in the webcontent if you change/edit the document in the document&media library. Normally the timestamp should be updated so the browser loads the updated media even if cached.

      In LPS-140954 the solution is to replace the timestamp with a TransformerListener. But that doesn't fix everything. If the layout is cached in Liferay this listener isn't called and the timestamp stays the same/old.

      The support asked me to open a ticket here:

      'Regarding the cache problem, currently, this is a product limitation. Our engineers have thought about it, and currently the only way of solving it would be to parse the content of all the JournalArticles: analyze all the journal table when modifying each file entry, which could have a very big impact in the portal performance. The only way to avoid this limitation would be to use non-cacheable templates since the proper solution, which would be to store these relations between Web Contents and Documents in a normalized way by using a new table, would be out of the scope of a regular fix. We invite you to create a feature request to study if it is feasible to solve this in future product releases.'


      Steps to reproduce the Fix from LPS-140954 and the cache problem

      1. start a vanilla liferay fp 13 with the hotfix from LPS-140954 installed
      2.  upload a normal text document to the document library
      3. check the download link for this document and take a note of the timestamp in the download-url
      4. go to "Content & Data" and "Web Content" and add a basic web content
      5. add a text
      6. mark the text and add a link to the previously added text document in the document library via "select item dialog"
      7. publish the web content
      8. open the preview of the web content and compare the timestamp in the url with the timestamp of the download-url - they are the same
      9. go to the document library
      10. edit the previously uploaded text document and upload a new text file
      11. check the download link for this document and take a note of the timestamp in the download-url - it has changed it is a different timestamp (parameter t)
      12. open the preview of the previously created web content and take a note of the document link - the url and the timestamp are still the old ones, nothing changed
      13. Stop Liferay
      14. Start Liferay
      15. open the preview of the previously created web content and take a note of the document link - the timestamp is now the new and same as the download-url in the the document library
      16.  go to "Content & Data" and "Web Content" and edit the previously added basic web content
      17. you will see that there is still the old url and timestamp.

      Actual result
      A changed document is only updated in the web content display view after a reboot of the system. In in the web content display edit-mode it is never updated.

      Expected result
      If you change a document every web content which refers to it should be updated with the new link with the actual timestamp.

      To fix the isssue completely the Liferay cache of Web Contents which refer to a document should be cleared if the document gets updated. To make that possible the relations between Documents and Web Contents should be stored. That could be done when saving (adding,update,delete) a content in the JournalArticleService.

      Updating the articles using a Document could be done in the DLAppService.


      We implemented a solution like I described and store the relations with a service builder service and implemented overrrides of DLAppService and JournalArticleService. Additionally we don't just clear the cache. We do what the TransformerListenerFix would do. We parse the content of the article for the updated FileEntry(document) and update the timestamp.  With that solution we don't need the Fix with the TransformerListener any more. We will test our solution in the next days and will be in production after the 18.11.2021.

      After that we will see if there are any performance issues. 


      Maybe our soultion could be a help to solve it your way.

      Reproduced in


        Issue Links



              pablo.agulla Pablo Agulla
              christian.roese Christian Roese
              2 Vote for this issue
              3 Start watching this issue




                  Version Package