Use reverse replication

Out-of-the box, only cq:Page nodes are reverse replicated. For any other node, it's necessary to use the two last methods, as a project-specific implementation.

There are three possibilities:

Use the SlingPostServlet (that is, do not create any custom post servlets or POST.jsp to handle the incoming requests) so that it implicitly triggers a related PageEvent. Then set a property name "cq:distribute" and set its value to "true" on the nodes you want to reverse replicate. To implement this solution, it's unnecessary to write any code. You can use the Form component to set all the necessary hidden fields.

Use your own code that accesses the repository, modify the properties "cq:lastModified," "cq:lastModifiedBy" and "cq:distribute." Posted data can be controlled, internal code writes the data. To implement this solution, it's necessary to write the code for your project.

Use your own code that calls the replicate method from Replicator service with options to use distribution mode. Replication is controlled from your code. To implement this solution, write the code specific for your project.

Replication queue issues

Editors can create content, but the activated pages are not updated on the CQ5 publish instance.

Make sure that each replication agent is enabled and configured correctly

Go to the list of replication agents (/etc/replication/agents.author.html).

For each replication agent, do the following:

Make sure that the agent is enabled.

Verify the connectivity with the publish instance by clicking Test Connection. If it fails, make sure that on TCP network level, the server hosting the CQ author instance can connect to the port of the publish instance.

Open the replication log via the "View Log" link and check when the last replication attempt was successful.

Note the first payload path in the replication queue. Then try to clear the first element of the replication queue. Then, verify whether the replication resumes (starting with CQ5.4). Once it resumes, activate the first payload noted in the queue again.

Check with the CRX Content Explorer, and make sure that there is no /bin/receive node on the publish instance. Otherwise, delete it.

Check with the CRX Content Explorer, and make sure that there is no /bin/replicate node on the author instance. Otherwise, delete it.

If the logs show no replication attempt for a few minutes, restart the replication bundle in the Felix console. If there's still no replication attempt in the replication logs, then restart the Apache Sling Event Support bundle:
(http://<host>:<port>/system/console/bundles/org.apache.sling.event)

ACL replication

It's not possible to replicate ACLs anymore (that is, from the author instance to the publish instance). This behavior is by design.

The ACLs in CQ5 are content-centric, and not user-centric as in CQ4. Usually you have different access rights on publish and author from a content perspective. So it makes no sense to replicate the content-centric ACLs anymore.

With a CUG (closed user group), Adobe is working on an out-of-the-box solution. In the pageprops of a page, it allows you to protect this page (and all subpages) by a specific CUG. That way, only users that are members of a specific group have access. The ACL on the publish is set on the publish itself automatically if the page is activated. For more information, see http://helpx.adobe.com/experience-manager/kb/ACLReplication.html.