I think that also works and will prevent the root issue - which is an unintended site transfer of content

Even, I remove the site dropdown from the publish section. You still can get into the issue whenever you create new content.

What if we actually store the site identifier on the form, which should be the id that you originally wanted. Then use that as the setter instead.

Change the dropdown to a special transfer site . This way, the designator is not the current working site or the dropdown. But the original site id you initially opened the editor with.

That covers editing, but not new content. If it’s a new piece of content, you still need the setter for the site, which if you remove, then you can’t persist a newly created content. Thus the dilema, that new content will also have the issue.

I feel like we’re overcomplicating this and adding site to excludes on line 267 and removing the explicit setSite on line 270 of the pages.cfc handler solves the issue.

Then you can just add this after the post-population isNew check ( with a custom transferSite variable on existing content you want to transfer ):

Having that manual setter and having the rc key for site brought in from the current site and allowing it to be populated is just a recipe for inadvertent site switching IMHO.

Actually, this scenario would apply whether you have the population or not. Right now it uses the population method, but if I remove it, I still need to designate the site, which then becomes explicit with a setter to the prc.oCurrentSite which if I changed in another tab, now the current site has changed as well. So I end up moving the content on either approach.

So at this point, this can become an issue for any content you are editing and you decide to switch sites on another tab.

Maybe a async checker in the editor that checks if you changed your current site and gives you a warning? Ideas?