Type: Feature Request
Status: Pending Further Research
Affects Version/s: 7.2.X
Fix Version/s: None
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.
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
- start a vanilla liferay fp 13 with the hotfix from
- upload a normal text document to the document library
- check the download link for this document and take a note of the timestamp in the download-url
- go to "Content & Data" and "Web Content" and add a basic web content
- add a text
- mark the text and add a link to the previously added text document in the document library via "select item dialog"
- publish the web content
- 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
- go to the document library
- edit the previously uploaded text document and upload a new text file
- 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)
- 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
- Stop Liferay
- Start Liferay
- 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
- go to "Content & Data" and "Web Content" and edit the previously added basic web content
- you will see that there is still the old url and timestamp.
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.
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.