Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

DataObjectManager Module /

Discuss the DataObjectManager module, and the related ImageGallery module.

Moderators: martimiz, UncleCheese, Sean, Ed, biapar, Willr, Ingo, swaiba

Using ManyManyDataObjectManager on the belongs_many_many side

Go to End

25 Posts   6991 Views


Forum Moderator, 4102 Posts

5 September 2009 at 4:49am

Umm, before I go any further, did you guys know that you don't have to define $belongs_many_many? I have at times mistakenly defined both as $many_many and it works fine.

Maybe try that first?

I never got the whole belongs_many_many thing, anyway.


Community Member, 288 Posts

5 September 2009 at 4:57am

I have actually tried that and it kind of works.

The problem with defining many_many on both sides is that you end up with two separate independent linking tables so the relationship ends up being one sided.

The functionality I'm after is having a DataObjectManager on one side (the ProductPage) and then linking that to a SoftwarePage. When editing a SoftwarePage I might change my mind and want to change that relationship. As things are today you can either represent the relationship from the belongs_many_many side with a checkBoxSetField or you would have to save the SoftwarePage and then go to the ProductPage in question and change the relationship there.

Looking at the code for ManyManyComplexTableField it looks like they planned on it working the way I have described but someone borked the code for finding the linking table from the belongs_many_many side.

If you go for many_many on both sides relating a ProductPage to a SoftwarePage won't make a SoftwarePage related to a ProductPage since the relationships will be independent of eachother.

Chris Dangerfield

Community Member, 8 Posts

10 September 2009 at 11:37am

Hey guys,

Really appreciate your work on this. I have been thinking, and I wondered if it was possible to NOT call 'getCMSFields_forPopup()' when the only permission that is set is 'show'. Because, if you have a page-to-page relationship you probably wouldn't need to add or edit the information from the dataobjectmanager. Let me know what you think.


Community Member, 176 Posts

4 February 2010 at 3:32am

UncleCheese will Smurkas code ( post268318 ) be included in the next version of ManyManyDataObjectManager? It solved the issue for me and allowed me to use ManyManyDataObjectManager at both sides of the relationship.

Also in possibly an unrelated issue I found that using the name of the class as the array name brakes things:

// This doesn't work
static $belongs_many_many = array(
'Species' => 'Species'

// This does work
static $belongs_many_many = array(
'ProjectSpecies' => 'Species'


Community Member, 288 Posts

4 February 2010 at 3:59am

Hi Martijn.

I don't think that code is ready to be included partially since you seem to have found a bug I'll have to take a look at and because it kind of breaks the way things normally work.

Fixing the bug is doable but I'm very unsure if there is a satisfactory solution to the infite loop since that's simply how DOM/Complextablefield is built. They all have the functionality of defaulting to getCMSFields() and this fix breaks that functionality in a pretty huge way.

Since this seems to be a pretty rare scenario that break might be kind of acceptable but that decision is up to UncleCheese. IE we would have to inform people that using DOM on the belongs_many_many side means you have to setup separate popup-getters, otherwise everything explodes.


Community Member, 56 Posts

9 February 2010 at 12:33am

Thanks Marijn. This solved an issue I was having.


Community Member, 288 Posts

9 February 2010 at 12:51am

Edited: 09/02/2010 12:52am

Nice to see that the code is getting some use.

I haven't had the time to look at the problem you reported Martijn but I'll hopefully get to it in the next couple of days and see if I can figure out what goes wrong when you use the same name as key/value.

I just wanted to add that there is one more scenario where this will break rather messily and that is when you have several many_many relations to the same object, for example

public static $many_many = array(
    "Scenes" => "Scene"
    "MoreScenes" => "Scene"

This is probably a pretty rare scenario but if it applies to anyone trying this fix then know that this will break it. The big problem here (which I don't think there is a real solution to within the boundaries of how this works today) is that there's no way for the belongs_many_many class to figure out which one of the two relations above is the one that applies and thus it can't reliably find the correct relationship table.

If there's just one many_many relationship to a class then it works, if there's more it doesn't. I am going to have a look at how (or if) SilverStripe solves this with it's getters, if we're lucky there is actually a solution to this somewhere in the code.


Community Member, 56 Posts

27 January 2011 at 6:19am

Edited: 27/01/2011 6:20am

Hey Smurkas,

It looks like the 'belongs_many_many' is still a problem. Iv done a quick hack to stop FormScaffolder building anything on these types of relationships and submitted a patch here;