Bit a of a strange one, I edited a page on the staging server, but did not publish it. When the page was transferred using courier to the live server, the page in the tree view still showed it had been edited with the small star on the icon, but the page was actually published in this edited state.
is there a setting that publishes when transferring? if so, should it not also remove the edited but not published icon from the tree view?
I'm getting the same behavior with fresh installs of Umbraco 4.7.1.1 and Courier 2.5.4.1 under a pretty much default configuration.
If you publish an item and courier it across, it works as expected. If you courier an item that is not published but saved, it also works as expected. If you have a published item with an unpublished (saved) version it does not transfer across properly. That is, if the item appears in the content tree with black text and has a unpublished changes decal, courier will mess it up with the resulting document being published as well as appearing with the unpublished changes decal.
While it could just be a case of a config switch, the fact that it publishes the transferred version even if it's not published on the source definitely sounds like (what appears to be a relatively serious) bug in the transfer functionality. I've attempted to fix some of this behavior with an ItemDataResolverProvider (as described in http://nightly.umbraco.org/UmbracoCourier/Data%20Resolvers.pdf ), but I think that actually extending this behavior into courier properly is pretty nontrivial (and revolves around working around Courier quite a bit).
I hope that there is a config setting that makes this just work, but I wouldn't hedge my bets on it.
It is an issue in the the current version as well, I'm working on a fix for it, but it is really not trivial to get around, as you have multiple scenarios and there is really not one single solution that will make everyone happy.
But the options are:
- Only transfer published content (this could be bad for people who transfer everything and then publish on the live env)
- Transfer latest content, but do a check to see if latest version should be published This sounds fine, but if there is no content there already, then you'll have no fallback content, so no page This happens if you publish a page, edit and save, then transfer, so you transfer unpublished content, to a place where the page doesnt exist and it then only have the unpublished content to put there, which is not good either.
- Change couriers architecture so instead of transfering documents, you transfer document versions This is a huge refactor and could lead to futher issues then it solves. And it will also add further overhead to a already heavy process (more complexity == slower transfer and resolution)
So right now I'm mostly a fan of adding a configuration setting that makes the user decide on which of the first 2 options he wants to use, as some enviroments will use one, and some will use another
Staging system that is used by all users to edit/prepare/approve new content and changes - publicly available, but not advertised. Live system that is locked down - no edits/publishing allowed - publicly available and advertised (main site). Editors can edit/create content in Staging & send to publish, then Admins can publish on Staging and email link to external reviewers for approval. Admins can then Courier approved content to Live - they may do this on bulk (i.e. from the root node, or from a sub folder), or for individual files/pages.
So, based on your options above, I think we fall into category 1. I would be happy to trial this - I have a dev (local) copy I am using to evaluate Courier, and could install beta/test versions. I can see the complexity of the issue you describe, and I think your solution of a config setting to suit different environments makes sense. Please let me know if I can provide any further info, or help test/evaluate in any way.
publishing transferred pages
Bit a of a strange one, I edited a page on the staging server, but did not publish it. When the page was transferred using courier to the live server, the page in the tree view still showed it had been edited with the small star on the icon, but the page was actually published in this edited state.
is there a setting that publishes when transferring? if so, should it not also remove the edited but not published icon from the tree view?
I'm getting the same behavior with fresh installs of Umbraco 4.7.1.1 and Courier 2.5.4.1 under a pretty much default configuration.
If you publish an item and courier it across, it works as expected. If you courier an item that is not published but saved, it also works as expected. If you have a published item with an unpublished (saved) version it does not transfer across properly. That is, if the item appears in the content tree with black text and has a unpublished changes decal, courier will mess it up with the resulting document being published as well as appearing with the unpublished changes decal.
While it could just be a case of a config switch, the fact that it publishes the transferred version even if it's not published on the source definitely sounds like (what appears to be a relatively serious) bug in the transfer functionality. I've attempted to fix some of this behavior with an ItemDataResolverProvider (as described in http://nightly.umbraco.org/UmbracoCourier/Data%20Resolvers.pdf ), but I think that actually extending this behavior into courier properly is pretty nontrivial (and revolves around working around Courier quite a bit).
I hope that there is a config setting that makes this just work, but I wouldn't hedge my bets on it.
Hi Psib3r & CJM,
Did either of you get any further with resolving this issue?
I am seeing the same behaviour on Umbraco 4.7.1.1 with Courier 2.7.3
Any help would be appreciated.
Kind regards,
Simon
TBH, I have not had a chance to check if this is still an issue
It is an issue in the the current version as well, I'm working on a fix for it, but it is really not trivial to get around, as you have multiple scenarios and there is really not one single solution that will make everyone happy.
But the options are:
- Only transfer published content
(this could be bad for people who transfer everything and then publish on the live env)
- Transfer latest content, but do a check to see if latest version should be published
This sounds fine, but if there is no content there already, then you'll have no fallback content, so no page
This happens if you publish a page, edit and save, then transfer, so you transfer unpublished content, to a
place where the page doesnt exist and it then only have the unpublished content to put there, which is not good either.
- Change couriers architecture so instead of transfering documents, you transfer document versions
This is a huge refactor and could lead to futher issues then it solves. And it will also add further overhead
to a already heavy process (more complexity == slower transfer and resolution)
So right now I'm mostly a fan of adding a configuration setting that makes the user decide on which of the first 2 options he
wants to use, as some enviroments will use one, and some will use another
/Per
Our scenario is:
Staging system that is used by all users to edit/prepare/approve new content and changes - publicly available, but not advertised.
Live system that is locked down - no edits/publishing allowed - publicly available and advertised (main site).
Editors can edit/create content in Staging & send to publish, then Admins can publish on Staging and email link to external reviewers for approval.
Admins can then Courier approved content to Live - they may do this on bulk (i.e. from the root node, or from a sub folder), or for individual files/pages.
So, based on your options above, I think we fall into category 1.
I would be happy to trial this - I have a dev (local) copy I am using to evaluate Courier, and could install beta/test versions.
I can see the complexity of the issue you describe, and I think your solution of a config setting to suit different environments makes sense.
Please let me know if I can provide any further info, or help test/evaluate in any way.
Kind regards,
Simon
is working on a reply...