Unexpected behaviour versioning/draf with many_many relations

[Friksel]

After some unexpected behaviour in the framework/cms I did some tests and found out the versioning/drafting system isn't working as expected and therefore causing unnecessary mistakes in my opinion. I would like to share this with you, 'cause in my opinion this is very important in the core of Silverstripe to work as expected, to let the framework/CMS have a reliable feel for its users.

SITUATION A
An editor published a page with 1 widget (many_many relation). Everything fine. All visitors see 1 widget on that page.
A week later the same editor adds a second widget to that page and publishes it. Still fine. All visitors see 2 widgets now.
A month later the editor uses versioning to go back to the first version again.
But what happened?? The amount of widgets connected did not change!! So the visitors still see 2 widgets, even though the editor got back to the previous version where he had only 1 widget!!!
That's not what we expect to happen. The editor gets confused and is having selfdoubts and it's probably changing he's feeling about the stability of the system, 'cause he doesn't understands this behaviour.

SITUATION B
An editor published a page with 2 widgets (many_many relations).
A week later this editor got back from a meeting with his company. The company wants a third widget, but wants to preview it first before this goes online and it's not suppose to be on the open before a special date.
No problem, the editor thinks. I have my draft system in Silverstripe. So I just edit the page without publishing it, only save the page (in draft mode).
So the editor adds a third widget to the page and is about to change the contents of that third widget.
What this editor does not know is that EVEN BEFORE SAVING THIS PAGE (NOT EVEN PUBLISHING) website visitors already see this third widget on the live website!!!!
This could be a very huge problem for this company and can even cost this company money and/or the editors job! While the editor thought right in my opinion: he was working in draft mode, with a preview in the CMS.

SITUATION C
An editor had a published page with 3 widgets.
A week after publishing this page he wants to know how it would look if the third widget was not there. So he removes the widget-relation from within the gridfield. He is very carefull not to save the page, because he now has a problem trusting the draft system in Silverstripe because of earlier experience and the times he had to explain his boss about this.
At that time his boss comes in and yells at him: 'how could you take that widget offline?? I didn't ask you to do that'... He stumbles that he didn't publish the page... that he didn't even SAVE the page...

SITUATION D
This one I just had myself. I give pages Tags using the TagField module. Every Tag is a DataModel.
Everything was working perfectly fine, until I started to remove tags from the admin panel. I figured Silverstripe would handle the clearup of all pages linking to this tag by looking at the many_many table and just removing those records. But it was abviously not doing that.
I didn't find out until I had an error. For some reason a newly created tag got the same ID as a Tag that was removed before. Probably the module was looking for the first free ID number in the Tags table. Can't blame the module for that. It's suppose to be fine.
But because the many_many relations between Page and Tags were not cleaned up, suddenly some pages got this new Tag connected to it (wich was wrong ofcoarse) and the tagging system wasn't working anymore!!!
also refering to the issue here:
silverstripe/silverstripe-framework#5290

CONCLUSION
Looking in the database there's only one table for each many_many relation, where all DataModels have 3 tables (one for draft, one for live and one for versioning). This explains the above behaviours, but I also wonder why this is.

The versioning/draft system is slowing down the CMS by extra db-writes, so it would be great if it would work as expected: cleaning up many_many relations and having versioning for these many_many relations too.

[tractorcow]

Yeah, unfortunately there is no support for versioned many_many relationships. If you want to version widgets, then you'll need to explicitly add versioned extension to Widgets and handle the cascading publishing yourself.

If you have a look at silverstripe/silverstripe-framework#4932 we are planning to implement a solution in 4.0 to address these usability issues.

One of two solutions we are likely to implement are:

• has_many_through
• Actually versioning the many_many mapping table

We have already implemented cascading publishing actions, which allow you to specify certain objects as "owners" of child objects, and have those children automatically published along with the parent.

The issue with orphaned many_many records hanging around is a real issue, I agree. It's covered by silverstripe/silverstripe-framework#5290 though. ;)

I'm going to close this issue as it's already covered by silverstripe/silverstripe-framework#4932.

[Friksel]

Wow! Silverstripe 4 is really looking promising. Seems like a lot of longawaited features/improvements will be in there. You guys really have been busy. Seems like a very elegant solution to this issue too and well documented proposal. Can't wait to use ss4! Keep up the good work!