Right now its wide open and you can assign something to be a child of a basic page and other such tomfoolery. It's not perfect, but we can define an entity reference view that restricts the autocomplete to only collections and paged content. If we want to go further and restrict pages to paged content and everything else to collections, we'd have to break those out into their own content types to use two different settings for field_member_of.
I agree that's tomfoolery but we are in the middle of loading (into 7.x) some scrapbooks that have pages.... and foldouts on some pages, which we are modeling as children of pages. So some crazy people do want to do crazy things. Maybe what is filtered out or in could be a configurable option?
It's all config @mjordan. What I'm suggesting is to update the field config to use a view instead of leaving it wide open. You can always edit that view or configure the field to restrict by content type or not at all.
However, I'm still looking for the line between giving implementors freedom and providing a more guided experience out of the box. It's a tricky balance. So if this sounds totally undesirable, we can just document how to do it for those who are interested.
Using a View to constrain what shows up as allowable types, that can be tweaked for local needs, sounds optimal.
Most helpful comment
Using a View to constrain what shows up as allowable types, that can be tweaked for local needs, sounds optimal.