Mmm,

I've just done a clean install of 4.0.4.2 with runway, duplicated the site & db, installed courier in both sites and to transfer a node with depenendent nodes that dont exist on the tagret server and recieved the same error. I don't now know if Courier is supposed to transfer dependent nodes? Isn't that kinda the point, in that it ensures integrity of the transferred content?

Hi Guys,

I've just tried the same test using the flagship products (Clean install of Umbraco 4.5.2 with runway & Courier 1.3)  and I get the same error. I'm still running on ASP.NET 3.5 though.

Am I to understand that dependency checking/resolving does not stretch to creating dependent nodes?

I hope I'm missing somthing really obvious here.

Also, I understand that Courier is a closed source product and having a obfuscated licencing dll makes sense, but I was very disappointed to find that the entire courier dll was obfuscated preventing me from debugging this entirely unhelpful error message myself.

Same here. Trying in trial mode to see if it's worth the fee.

This would indicate no. It's a shame, there's so much potential here. It's advertised as right-click-and-go.

Yea, I had a reply from a support request that said they "don't think linked content documents will be transfered."

Well, my client has multiple content editors and they need to a central body approving the changes before pushing them to the live environemnt, so I think I'm going to have to knock up a dashboard control that keeps track of changed nodes (using document_save/publish events) and hopefully indicate which ones have been Couriered across to live.

I was planning on using a HttpModule to attach a Response.Filter to parse the messages that get sent to the Courier progress dialog to determine when a node has been Couriered (unless they've implimented events in Courier!)

I've just got this when using Transfer to Staging via Courier on all nodes. Does anyone have any idea how to resolve it?

Hi Essy,

This error (in my case) meant that Courier was unable to resolve a nodeId or mediaId on the target server. e.g. the node or media item being linked to hadn't been transferred yet.

TTFN

Ant

Hiya Ant ... yes it seems that Courier doesn't cope well with the interdependencies. I did find that if you re-do the Transfer to Staging then the next time round it succeeds (presumably because the dependants now exist). So it seems that just repeating until you get no errors is the workaround.

I have to say that I'm somewhat disappointed given the marketing claim "With a single click you can deploy both new versions of content or updates to content including all dependencies." but hey I guess it works after a fashion.

I'm moving on to the next layer of bugs since although this *appears* to transfer everything OK, media and content links are corrupted throughout the site :(

I had issues where the Courier was doing a global replace of nodeIds in a document e.g.

Document 1: Source NodeId = 100, Target NodeId = 101

Document 2: Source NodeId = 101, Target NodeId = 100

so courier updated links from nodeId 100 to nodeId 101, then links from 101 to 100 - so links to both documents were getting updated to point to the same document.

At first I thought this was a peculiarity with my set up, but if you're transferring sites between databases, you're likely to have a similar number of nodes on each site so the nodeIds are going to be fairly similar.

Is "fairly similar" good enough? Just thinking of all my corrupted links and wondering if this is part of the same problem?

Are you finding that any links out of a document are being replaced with links to another node that is also linked to from the same document? or are they being corrupted in some other way?

Just trying to suss it out now ... from what I can tell at the moment links which are created directly on the page using contentPicker or are created automatically from the XML structure (e.g. auto-navs) are OK but links created deeper (e.g. a contentPicker associated with a media file or in a macro) are bugged so that when the NiceURL function is called it returns "#" rather than the correct URL.

On further investigation it appears that the values held in a contentPicker variable set in a macro or against a media type (and possible other situations) are not updated (ie. it still has the old value from the source site which no longer points to the same/or any content on the target site) :(

Yes, I was just about to suggest that. Have you read the bit in the Courier Manual regarding the various xxxDataTypes nodes in courier.config? You have to tell Courier how to find the nodeId/mediaIds in your content.

Yes I read that in the Courier manual too but mediaPicker and contentPicker appeared to be in the config already - only one which wasn't was the macro container and couldn't figure out the syntax for it - any ideas?

I noticed that Courier 1.3 has config nodes called contentPickerMacroPropertyTypes & mediaPickerMacroPropertyTypes which presumably are to update ids in macro parameters. They're not mantioned in my Courer 1.2 manual so I guess they're new in 1.3 (Just like the security/contextMenu/userType config nodes)

I am using Courier 1.2 too ... but these nodes were already in the config file:

<contentPickerMacroPropertyTypes>
      <macroPropertyType>contentPicker</macroPropertyType>
      <macroPropertyType>contentCurrent</macroPropertyType>
      <macroPropertyType>contentRandom</macroPropertyType>
    </contentPickerMacroPropertyTypes>

    <mediaPickerMacroPropertyTypes>
      <macroPropertyType>mediaCurrent</macroPropertyType>
    </mediaPickerMacroPropertyTypes>

I have left them alone but wondering now if I should modify them somehow. Do you have a link to the 1.3 manual by any chance?

is working on a reply...