Usync complete can't synchronised not-published nodes correctly

[bielu]

Describe the bug
Bug is related to synchronization of unpublished content, which was never published.

Version (please complete the following information):

• Umbraco Version: 13.0.2
• uSync Version 13.0.0
• uSync.Complete Version 13.0.0

To Reproduce
Steps to reproduce the behavior:
1.Create node, add block editor, add content, save but not publish
2. try to synchronised it to other server

Current result
Node was created in other server, but was missing all properties!

Expected behavior
Node is created in other server with all properties.

[KevinJump]

Hi,

It is a bug, but the other wat around - uSync.Publisher only syncronised published content, so ideally the default behavior would be the item does not get published at all.

i think what is happening is that our PublishedContentHandler, does only deal in published values, but it is syncing the undering content item, and then not setting the properies, ideally it should not publish the item!

(you can in theory change the behavior of uSync.Publisher by swapping out the PublishedContentHandler for the normal 'contentHandler' in config - i can dig that out if you need it).

[bielu]

HI Kevin,
if you can dig out this, it would be great!

[bielu]

@KevinJump did you had chance to look and fit bit of configuration which you mentioned?

[KevinJump]

Hi,

yeah sorry. settings below.

  "uSync": {
    "Publisher": {
      "Handlers": {
        "DisabledHandlers": [
          "PublishedContentHandler",
          "ContentTemplateHandler"
        ]
      },
      "Settings": {
        "IncomingEnabled": true,
        "AppId": "YOUR-APP-ID-HERE",
        "AppKey": "YOUR-APP-KEY-HERE"
      }
    }
  }

So the default (when this isn't set) is to disable the content Handler and ContentTemplateHandler, so the "PublishedContentHandler" manages the content, this swaps that back.

the diffrence between the two handlers is small. PublishedHandelr uses the PublishedValue Content handler uses the EditedValue

[marcemarc]

Suggestion for when using the PublishedContentHandler, and there are later changes saved for the node, that it would be good to report a warning:
"Content includes Unpublished Changes, which have not been transferred"

The editor confusion is in the message "Completed without any issues at all, nothing to worry about here"

Not sure if empty nodes should be created though.

[bielu]

@KevinJump i had look into this issue and i have idea how to resolve it, but it would require breaking change... You already have method GetPropertyValue(IPropertyValue value) which decide how it synchronizing content, but for published it would be good to have context of item, so we can dynamically check if item is published and than use either item.PublishedValue or item.EditedValue
in this way I would we would be able to have dedicated handler specifically for publisher which handle it in this way when normal usync would Published/Content handlers.
What you think?

[KevinJump]

there probibly a non-breaking way of adding this, (new method, calls old method by default). I think passing the content item and the options along at the same time would give us the most flexibility. I will take a quick look.

[KevinJump]

(v15 version of this commit KevinJump/uSync@0fa8ec0)

will also add it back to v13 (but not v14 that is in support only now 🙂)

[KevinJump]

I might well also add this functionality as an option in publisher (now we pass it over) - I just need to think of the implications (and whether or not its worth documenting them)

*Sometimes it's better to leave the option in code, and then anyone using it will have explicitly understood what they are doing, vs changing an option and getting unexpected results.

[bielu]

@KevinJump it might be worth do similar things as we done in Translation manager, advance settings where we can do Optional Setting -> Include properties for unpublished content, and than you can modify PublishedContentSerializer to

  protected virtual object GetPropertyValue(TObject content, IPropertyValue value, SyncSerializerOptions options)
        =>content.Published || !settingEnabled  ? value.publishedvalue : value.EditedValue;

so it would kept old behaviour as published value if not enabled, but do edited value for unpublished items when enabled?

[KevinJump]

yeah that is probably what the published serializer inside complete will end up looking like :)

[bielu]

hey @KevinJump any eta on solution to this issue?

[KevinJump]

yes, i just need to check the status of other things in v13 - I think we should be able to release it this week.

[evans-t]

Has this been fixed in v13? We're using 13.1.7 and the node is created, but content and related media is missing.

[bielu]

@evans-t it wasn't yet, as workaround you still need use #221 (comment)

[KevinJump]

this is a think, i was almost certain i remember doing, and then i can't find the code.

from v13.1.9 (Jan 20th 2025), the signature of the GetPropertyValue was updated to match @bielu's comment

e.g

protected virtual object GetPropertyValue(TObject content, IPropertyValue value, SyncSerializerOptions options)

This means you can now override the publihsedSerializer if you want and do as above with your own method. but we didn't change the core behavior which means it still returns the publishedValue.

Now i thought we did, but maybe i did and then in testing removed it, so i will need to check, but in principle we could add this to the core behind a setting.

[bielu]

@KevinJump having it behind setting would be great instead of need maintaining custom versions of handler. but yeah maybe even toggle in ui for editors to decide if they want publish or preview version synced?

[evans-t]

Thank you @bielu and @KevinJump. Love the idea of allowing the editors to decide which version they want!

[KevinJump]

We are always a bit reluctant to just add a new option (especially for editors). In an effort to keep things as simple as possible, we might be able to hide it behind some advanced settings or something and see what that looks like.

[bielu]

@KevinJump I am happy to be your guinea pig with it behind advanced setting as I was on multiple other changes :)

[KevinJump]

test version with options (for admin, not for editor).

https://dev.azure.com/jumoo/Public/_artifacts/feed/nightly/NuGet/uSync.Complete/overview/13.1.11-build.20250416.1

this version adds a couple of options to a server's advance settings.

• Send Edited value will as it says send the edited value each time (so this is like disabling the handlers above, without having to do that).
• Fallback to Edited Value: - will try to send the published value, but if its not there or not the latest value then the edited one is used.

for reference while testing this is what the GetPropertyValue method actually looks like in the code:

 protected override object GetPropertyValue(IContent content, IPropertyValue value, SyncSerializerOptions options)
 {
     // One: Edited value is set, this may or may not be the published value but it will be the latest value 
     //      in the content, but it might then be published on the target, even if it isn't published on the source.
     if (options.GetSetting(uSyncExpansions.WellKnownSettings.SendEditedValue, false) is true)
         return value.EditedValue;

     // Two: simple case (current default), the content is published and at the latest version.
     if (content.Published && content.PublishedVersionId == content.VersionId) return value.PublishedValue;

     // Three: the "published fallback" setting is false, send published version.
     // (this might not be the latest saved version of the content, or for new unpublished content it might be blank/null)
     if (options.GetSetting(uSyncExpansions.WellKnownSettings.PublishFallback, false) is false) return value.PublishedValue;

     // Four: the content is not published or has a version beyond the published version, send the edited value.
     return value.EditedValue;
 }

the slightly difference with @bielu 's code on this - is we check both if the content is published and if the publishedVersion of the content is the same as the latest version, if they are not then there is a chance the values have been updated but not yet published so we use them.

(i.e.. content.Published will return true when version 19 is published but version 20 has been created but not published)

[Navya-Sinhaa]

@KevinJump Just checking in to see if there's any an estimated timeline for this to be released. Thanks