How do I enable 'Compare' with versioningbehavior ?
(Versioning is working, but I miss the 'grey buttons' (I have view and Revert (after 'clicking view')
News Item:
My Content Type:
You need to visit the ZMI to opt your content type into Compound Diff for Dexterity Types in /portal_diff/manage_difftypes, or in your setup profile, you can add a diff_tool.xml that looks like:
<?xml version="1.0" encoding="UTF-8"?>
<object>
<difftypes purge="false">
<type portal_type="my_portal_type_here">
<field name="any" difftype="Compound Diff for Dexterity types"/>
</type>
</difftypes>
</object>
1 Like
Thanks a lot.
Is there any reason for not adding this to all content types?
Maybe plonecli should add this by default (?)
Honest big picture opinion: this should not be scaffolding, and it should not be a problem for add-on developers or add-on tooling (like bobtemplates or plonecli) to solve — Plone should have better convention-over-configuration around this, but:
- In an ideal world, CMFEditions should be completely rewritten/replaced, and is long-overdue for such.
- it is overly complex and has impossibly opaque/incorrect assumptions around portability for export/import cases (the fact that replay is the only option for import is a bad smell, very frustratingly has cost me weeks of time I would rather have been developing other things).
- CMFEditions is over-engineered, and its heavy dependence on pure-object-state snapshot is both over-engineered and a magnet for cruft gremlins.
- CMFEditions is too may tools, too many configurable options unused by 99.5% of installs.
- I would contribute significant volunteer time to any efforts to replace CMFEditions with a lighter-weight replacement that "just works" with simpler arrangements (e.g. store JSON serializations in ZODB, don't store copies of objects that can break over time of many in-place upgrades).
- the only contract for replacement is likely:
- preserves existing high-level API semantics for Plone REST API
- allows for event subscribers or some other simpler hook point for modifiers (or similar normalization) that isn't as complex as CMFEditions.
- Ideally, using serialization for historic versions means how the objects are stored (ZODB or somewhere else) is agnostic, pluggable
- but it is difficult to be motivated to do this on my own; I may at some date be motivated to write a proof of concept around this, if there is community interest.
- the only contract for replacement is likely:
2 Likes