@alexialg05 I don't think so, as the demo site appears not to have it enabled by default. You can install Plone locally, then follow Working copy support.

Also please read and follow First-time contributors, especially Things not to do, Contributing to Plone, and Contributing to Volto.

@alexialg05, @stevepiercy is correct. It is not enabled in the demo. You can do this locally. To see:

it's a bug not a enhancement. Working copy is broken without this and is a regression from classic.

For this to work in Plone Site, you would need to enable versioning in it. See:

https://github.com/plone/plone.app.iterate/blob/1908aa1f4e9c95c37143fae88655469b72ea451a/plone/app/iterate/browser/control.py#L51-L52

@mauritsvanrees @davisagli @jensens do you see any problem with this?

Working copy of Plone Site sounds tricky, but enabling versioning behavior should be fine. I did not try it though.

Working copy of Plone Site sounds tricky

I was trying to create a Plone Site inside another one. But I realized that this was getting weird. Even if I managed to do this, I would still have permission issues. Usually the user who can change the Portal cannot create a new Portal. So I changed the approach, to create a Document as a working copy of the Portal. Then I copy the fields from the Portal into the Document. Does this look ok?

I managed to create a working copy of the portal using Document as the working copy. I had to change 3 packages:

plone.app.iterate
Products.CMFEditions
plone.restapi

It seems to be working. Can I create the PRs?

Could be interesting, yes. I may not have time to review this though.

But what if the Plone Site and Document types are too different? Maybe they have been customised, and both have extra fields and behaviors, but not the same ones.

Or what if you create a working copy and then add some images in there, referenced by blocks. Do those get taken over when checking the document in? I guess that could work though, assuming that this currently works for standard folders, or indeed plone.volto Documents.

But what if the Plone Site and Document types are too different? Maybe they have been customised, and both have extra fields and behaviors, but not the same ones.

@mauritsvanrees All fields that Plone Site and Document have in common will be copied from Document to Plone Site on checkin. The Plone Site schema is used as a base. See:

https://github.com/plone/plone.app.iterate/blob/01dca2a0c95df2a712dbf1900bc51370a77fb03d/plone/app/iterate/dexterity/copier.py#L227

In the code above, baseline would be Plone Site and self.context would be Document.

Fields that are not common would remain unchanged. However, the main fields of interest for the working copy would be the fields related to blocks. And these fields are common. So I think it would be fine like this.

Or what if you create a working copy and then add some images in there, referenced by blocks. Do those get taken over when checking the document in? I guess that could work though, assuming that this currently works for standard folders, or indeed plone.volto Documents.

Yes it works.

How badly would things break if the working copy was an instance of Document with its portal_type set to "Plone Site" so that it uses the Plone Site schema?

I'd be interested to review the implementation, but can't promise to get to it quickly.

How badly would things break if the working copy was an instance of Document with its portal_type set to "Plone Site" so that it uses the Plone Site schema?

@davisagli I don't know if I understood your suggestion very well. You say to dynamically change the portal_type from Document to Plone Site, after creating the copy? Would that work? I'll test it.

@wesleybl That's right. I'm not sure if it will work, but it might.

That's right. I'm not sure if it will work, but it might.

@davisagli This worked! When editing the working copy, only the Plone Site fields appeared. The only difference is that the working copy did not appear in the navigation menu, since Plone Site does not appear there. But I don't think that's a problem.

Thanks for the suggestion!

@djay @mauritsvanrees @davisagli I created the following PR:

• Allows versioning of the Plone Site type for the portal working copy to work Products.CMFEditions#113
• Allows working copy of Plone Site - 5.x plone.app.iterate#128

With these PRs, you can now test the working copy in Plone 6.0 Classic. You will need to create a new Plone Site.

There are missing PRs in restapi and Volto to make it work in Volto.

@djay @mauritsvanrees @davisagli I've made PRs on plone.restapi and Volto. This allows you to test the changes on Volto. I've included the PRs in the issue description. Please test them when you have time. Thanks!

I must say I am having a doubt about including this in Plone 6.0, as this needs changes in no less than four backend packages. Maybe it is okay. At least some of the PRs are small and safe enough that it seems fine to make the change. But if you would be okay with targeting this at Plone 6.1 only, I would be happier.
I am at this point not yet saying no to 6.0, just expressing a doubt. I have not tried it out, nor viewed all PRs.

For 6.1 it would be good to have this if it works. I have added a link here.

Could you add a PLIP configuration for 6.1 in buildout.coredev? There are some examples in the plips directory. Just add the relevant packages to auto-checkout and add [sources] with the branches. That makes it easier to try out.

Finding time for a proper review is hard currently. And I don't want this to really hold up a 6.1 beta release. But I would say it should be fine to include this a bit later in the beta stage still.

But if you would be okay with targeting this at Plone 6.1 only, I would be happier.

I would like to have this in Plone 6.0 too. I think it would be safe.

Could you add a PLIP configuration for 6.1 in buildout.coredev?

Done in plone/buildout.coredev#966