Need to sort a page hierarchy based on the last published date. So the page which is being published last should be visible first.
The problem looks very simple but it was not that simple. Using an AEM query, pages can be sorted based on "cq:lastReplicated" and it works perfectly fine for the author. But when the code is being deployed in the publish server, the query was not giving the same results as the author.
Here is the query to sort pages based on cq:lastReplicated:
path=/content/we-retail
type=cq:Page
orderBy=@jcr:content/cq:lastRelicated
orderby.sort=dec
Why the query was not providing the same results in Publish as an author?
The publish server doesn't have "cq:lastReplicated" property and that’s how the logic is getting failed.
What I tried?
Approach 1: After a bit of research, I found out that "cq:lastReplicationAction, cq:lastReplicated, cq:lastReplicatedBy properties are not carried over the publish by OOTB AEM design". In order to carry these properties, disable this component "com.day.cq.replication.impl.ReplicationPropertiesFilterFactory" in the author instance.
Fig1: com.day.cq.replication.impl.replicationPropertiesFactory Component
The components gets enabled when the server restarts.To make it not getting enabled on server restart, Use "ACS AEM Commons -OSGi Component disabler" OSGi configuration to disable it permanently.
Fig2: ACS AEM Commons-OSGiComponent Disabler COnfiguration
After this, when a page gets activated, all the replication properties started to be carried over to the publishing server and it seems that the problem is solved now, but still, the results were not the same as expected.
Why this approach didn't work out?
1. If a new page gets created in the author at 2:00 AM and publishes the page then there is no cq:lastreplicated in the publish server for the first time.
2. If you have a page being published at 2:00 AM and now you are again publishing it at 3:00, the lastReplicated Date in the publish server will be 2:00 AM because when a node gets replicated from the author, first it goes it to publish and then it updates the date in author. So by this, publishers were not having the replicated date matched by the author but one step behind the author.
cq:lastReplicated Date in author ≠ cq:lastReplicated Date in publish
So making "cq:lastReplicated" property available to publish didn’t solve the problem.
Approach 2: Then I realized that the "cq:lastReplicated" date in the author is the same as "cq:lastModified" date in publishing. Because for publish when it gets the data, it consider that as last modified for the node.Ideally, these values will be the same (ignoring seconds), if a page gets published and it immediately goes to the publish server.
Note: publish server doesn't take the cq:lastModified date from the author, but it updates its own date based on when it gets the data.
The components gets enabled when the server restarts.To make it not getting enabled on server restart, Use "ACS AEM Commons -OSGi Component disabler" OSGi configuration to disable it permanently.
Fig2: ACS AEM Commons-OSGiComponent Disabler COnfiguration
After this, when a page gets activated, all the replication properties started to be carried over to the publishing server and it seems that the problem is solved now, but still, the results were not the same as expected.
Why this approach didn't work out?
1. If a new page gets created in the author at 2:00 AM and publishes the page then there is no cq:lastreplicated in the publish server for the first time.
2. If you have a page being published at 2:00 AM and now you are again publishing it at 3:00, the lastReplicated Date in the publish server will be 2:00 AM because when a node gets replicated from the author, first it goes it to publish and then it updates the date in author. So by this, publishers were not having the replicated date matched by the author but one step behind the author.
cq:lastReplicated Date in author ≠ cq:lastReplicated Date in publish
So making "cq:lastReplicated" property available to publish didn’t solve the problem.
Approach 2: Then I realized that the "cq:lastReplicated" date in the author is the same as "cq:lastModified" date in publishing. Because for publish when it gets the data, it consider that as last modified for the node.Ideally, these values will be the same (ignoring seconds), if a page gets published and it immediately goes to the publish server.
Note: publish server doesn't take the cq:lastModified date from the author, but it updates its own date based on when it gets the data.
It means cq:lastModified date is not carried over to publish from the author.
So then how we can conclude this:
cq:lastReplicated Date in author ≅
So then how we can conclude this:
cq:lastReplicated Date in author ≅
cq: lastModified date in publish
Conclusive Points: So now there are two ways:
1. Either you can make your query based on the "cq:lastModified" date for both author/publish but you need to make the author aware that in author, results are based on last modified but in publish, it will be based on like the last Published date.
2. Or you can make your query based on the run modes. If run mode is author make the query based on "cq:lastreplicated" date. But in case of publish, make the query based on the "cq:last Modified" date.
So that's how Approach 2 solved the issue.
Source: http://www.sgaemsolutions.com/2020/04/issues-in-sorting-results-based-on.html
Conclusive Points: So now there are two ways:
1. Either you can make your query based on the "cq:lastModified" date for both author/publish but you need to make the author aware that in author, results are based on last modified but in publish, it will be based on like the last Published date.
2. Or you can make your query based on the run modes. If run mode is author make the query based on "cq:lastreplicated" date. But in case of publish, make the query based on the "cq:last Modified" date.
So that's how Approach 2 solved the issue.
Source: http://www.sgaemsolutions.com/2020/04/issues-in-sorting-results-based-on.html
No comments:
Post a Comment
If you have any doubts or questions, please let us know.