The contents created on server 1 have many hyper links to other nodes of the same site. After I created Courier package and transfer to server 2, all the hyper links to nodes within same Umbraco instance become <a href="#">.
All the links pointing to media library and external links are preserved correctly.
I opened umbraco.config and saw the Xml content looks correct
<a href="
/{localLink:1887}
" target="_blank">Go to</a>,
the ID 1887 is the target node on server 1, but after transferred and installed on server 2, the ID of the target node is no longer 1887. I guess this is the reason why all hyperlinks failed.
Courier should pick up these links in your content, as long as it's in the RTE, it should also replace the IDs with guids which it then translates back on the target server. so it sounds like the links aren't found at all, or the resolver responsible for this is not recognising the datatype you are using
Hi, I'm having the same issue as mentioned above, RTE links aren't getting updated with new node ID after transfer from one server to another (<a href="/{localLink:1320}" stays localLink:1320 etc).
This is happening in a custom node type, (the node is getting transfered, but its RTE content isn't getting updated). Should this work out of the box or do we need to implement a Data Resolver or something similar?
It should work out of the box, if you use the standard RTE datatype, ensure you have umbraco.courier.dataresolvers dll in your /bin, as thats the one that handles the links
I am confused. In your response to my ticket you mentioned locallink issue will be fixed in Courier 2.7. But here you still say it should work out of box.
Sorry for the confusion, it is supposed to work out of the box in 2.6, but some have had issues with locallinks (like you) and as part of making macro and link spotting more robust, it seems 2.7 has fixed the issue for those affected.
Courier failed to transfer content's hyper links
Courier 2.5.4.1 with Umbraco 4.7.1.1.
The contents created on server 1 have many hyper links to other nodes of the same site. After I created Courier package and transfer to server 2, all the hyper links to nodes within same Umbraco instance become <a href="#">.
All the links pointing to media library and external links are preserved correctly.
Anybody experienced same issue before?
I opened umbraco.config and saw the Xml content looks correct
<a href="
/{localLink:1887}
" target="_blank">Go to</a>,
the ID 1887 is the target node on server 1, but after transferred and installed on server 2, the ID of the target node is no longer 1887. I guess this is the reason why all hyperlinks failed.
Any solution how to fix it?
Hi Hardy
Courier should pick up these links in your content, as long as it's in the RTE, it should also replace the IDs with guids which it then translates back on the target server. so it sounds like the links aren't found at all, or the resolver responsible for this is not recognising the datatype you are using
/per
Yes, I created my own data type by using RTE.
Unfortunately the local links fail to convert. And the CSS associated my my own data type was not transfered as well.
Hi, I'm having the same issue as mentioned above, RTE links aren't getting updated with new node ID after transfer from one server to another (<a href="/{localLink:1320}" stays localLink:1320 etc).
This is happening in a custom node type, (the node is getting transfered, but its RTE content isn't getting updated). Should this work out of the box or do we need to implement a Data Resolver or something similar?
Thanks
Jeff
Hi Jeff
It should work out of the box, if you use the standard RTE datatype, ensure you have umbraco.courier.dataresolvers dll in your /bin, as thats the one that handles the links
Hi Per,
I am confused. In your response to my ticket you mentioned locallink issue will be fixed in Courier 2.7. But here you still say it should work out of box.
Sorry for the confusion, it is supposed to work out of the box in 2.6, but some have had issues with locallinks (like you) and as part of making macro and link spotting more robust, it seems 2.7 has fixed the issue for those affected.
is working on a reply...