Is there a difference between the actions that publish content in Umbraco? I'm curious about the differences between: 1. "Save and Publish" on a content node 2. On a parent content node, select all in the Content List View and bulk Publish 3. On a parent content node click Publish with Descendants It appears that the Save and Publish action will make an entry in the audit history to make a change, while the Publish with Descendants (bulk publish) options do not. I'm running into an issue with uSync not picking up changes to about 2500 content nodes (missing media objects). The only time it picks up changes is by actually clicking Save and Publish on a node again. Then the sync works just fine and picks up the media object and places it on production. Trouble is, that is 2500 nodes to have to click that on one by one. 😬 I think a few things are at play, but I was trying to understand what and why there is a difference between publishing content. Is there a comparison going on that says what a change is to say, oh yea this was updated, sync it?

I don't know about currently, but yes there used to be different behaviours occuring, I just can't remember how they all tied together. So the different scenarios I was aware of that used to happen were: 1. Node has changes pending - Save and Publish on the node would, as the name suggests, Save and Publish those changes. 2. Publishing parent node with Descendants - would publish pending changes from parent and "republish" the current versions of the children -- If the children have pending changes they would only be published if the checkbox of "Include unpublished" is enabled. 3. List view bulk publish - I seem to think this would only "republish the existing versions" - so isn't publishing a draft version, unless the entire item was unpublished There was also a process that used to "only re-publish the already published content by re-loading it from the database cache". Some of this is memories from v7/v8 days, and things have changed a bit now, but I thought I'd mention it incase a bug has cropped in somewhere.

I've just done some testing and can see the same thing. The "published" event only gets triggered if a change is saved; so changing a property of a child node and publishing parent with descendants will trigger an entry in audit (or as you say, saving/pub the node directly). uSync has the "clean" export function which deletes all uSync history and gives a full set of fresh data - I don't know if this is applicable to your situation?

This is a performance feature. You really don't want editors being able to publish every single node in the tree, this is a seriously heavy operation. If you need to do something special, I'd recommend attaching a notification handler on publish (not sure if you can do it with descendants?) and one by one publish each node (in a foreach descendant). And maybe make sure that it only does this for people with

admin

roles or something like that 🙈 ⏳

Sounds like a "with great power comes great responsibility", enhancement could be like with examine index rebuild, or memory/database cache rebuild.. add a confirmation prompt "you are about to publish over 100 nodes which could take some time and impact performance" are you sure?

That's not a decision for editors though, if we build anything at all, it should be somewhere in the developers section with all those other warnings.

Is it not? they can hit delete on the site root and empty the recycle bin? And if it's actually stopping the usual use case of publish with descendants only hitting <10 nodes ???

Yes, that is very unfortunate legacy behavior (well, even more unfortunate that they can't see the recycle bin).

Thank you for taking the time to check this out. I'm not sure what the clean feature is but Definitely worth looking into. And i agree we don't need the the editors doing this sort of publish all the time, we are just in a spot where usync isn't picking up the media and we have a ton of nodes with no media and no longer being synced without going and hitting the button for save and publish directly. 😬 We also have an issue when saving or publishing and the action doesn't complete (either invalid required field or another reason) we end up with duplicate nodes. That may be unrelated to this entirely tho but it makes using the api to save and publish specific ones a challenge to cleanup duplicates. We are Definitely going to continue troubleshooting here. Maybe there is a usync feature that can get us an export of just some of the content we need and we can resync things.

I you know which items they are you could pick them off disk, each item is just a file in the uSync folder. And did you try a Full Import? https://cdn.discordapp.com/attachments/1163628213902254110/1163842003197513780/image.png?ex=65410b54&is=652e9654&hm=155797079143635dd415ed07157b58b9a2e3de8d28bb238e62754ac3218ffbc3&

I belive the full import option was looked at but I can't say if they chose to not go that route for one reason or another, I will have to ask. I think it timed out and took a long time (and then we run into duplicates too which worsens our problem). I saw this exporter content app in usync. It let's you pick folders of media. I was trying to find docs on how that works but I didn't see anything. It sounds like the nodes are not being saved & published tho (for performance reasons), and that's why usync isn't picking up changes for those nodes. It's so weird cuz it got them moved initially it just didnt bring the media assigned too. I also don't usync for content often so this is new to me for what is available.

I have a question for the group that might clarify this. What is the difference between the PostSave (pushing the Save and Publish button in the backoffice) and using contentService.SaveAndPublish(contentid) in code? In theory, these would be one and the same thing. But in our testing/situation, the PostSave button push does "enough" to cause uSync to see the media needs to sync. The SaveAndPublish api call does not (nor does the bulk publish or save/publish with decendants).

@rockerby thank you for posting the github link. I followed the thread there and I'm happy to see that its being investigated! 😄

Sorry , coming back from holiday, and trying to get my head around this from a uSync point of view. are we talking about uSync or uSync.Complete or both ? whenever an item is saved uSync will write it to disk, so the act of adding media to a page, and saving (it doesn't need to be published) will mean the uSync config file has the media reference in, i don't think you can add media to a page and not have uSync pick that change up on disk. for uSync.Complete there is a cache, to speed up operations and that does update when a bit of content is published, so i thought maybe it was that missing the event, but i have just done a quick check (v12.2) and that seems to be ok too (its not using the published notifications but some of the lower level ones, and i think its picking up the change there). How can I reproduce this ? for uSync Complete - I have tried - changing/adding a media item on a child page and only saving that page. - going to the parent page and doing publish with descendants. - pushing the whole site to another server this picks up the media change, and the new media item ?