Add option to automatically create an entity reference view when a new content type is created

I don't fully get it since entity reference has this functionality and you don't even need a view for it ?

Agreed with @swentel, it's quite easy to create an entity reference field that references a certain content type without the need for a view specific to that content type. Maybe we're both missing something here? :)

Okay, so entity_reference maintainers disagree.

Let's bring some more disagreement from views as well. As a site builder, I want things to be explicit, not explicit, behind the scene. Just imagine you create some field,
the view is added automatically in the background and booom you have some security issue on your site, because this data was rendered somehow.

All this kind of black magic stuff is just wrong, IMHO

Yeah, also agree this does not really make too much sense. You could end up with tons of views you don't want without realising. This would also open up a can of worms with regard to configuration of that view. You would need something similar to the views wizard?

Sounds like this is one to close?

Let's close that.

For example, in the case of albums and tracks what I want on the Album node is a view of tracks where each track has the track name, number and duration as well as an audio file with a play button. For that I must create an entity reference view, correct?

Yes, that's correct :)

I think the "enabled by default" part is what most people who commented here didn't like, but if you are ok with having it unchecked by default, I don't see any reason not to do this.

There are a few small things that should be discussed before starting a patch though, for example: what happens to that view when the content type is deleted? Should we delete it automatically? What if it's also used in other places as well, maybe even with some additional displays?

@tkoelary

But on a more serious note, I'd be fine making the option unchecked by default (though I would prefer the reverse) which I think resolves the question of "stuff happens in the background that may cause me problems in the future."

Cool. Can we agree to not make a special UI for nodes though?

But on a more serious note, I'd be fine making the option unchecked by default (though I would prefer the reverse) which I think resolves the question of "stuff happens in the background that may cause me problems in the future."

We are just optimizing for some arbitrary unknown user here. Making this explicit instead of implicit, explaining people what happens so they are empowered to do more is my philosophy,
because well, it allows users to jump over the local optima and find a good global optima.

What you are missing is that the common use case is not what entity reference provides OOTB, which is just a list of links, but a full view of rendered entities. For example, in the case of albums and tracks what I want on the Album node is a view of tracks where each track has the track name, number and duration as well as an audio file with a play button. For that I must create an entity reference view, correct?

By picking a "Rendered entity" formatter for the entity reference field and choosing a view mode in the formatter settings, you could display the track name, number, duration and play the audio when VIEWING an album. What you can't do without involving a view is filter the tracks displayed, or show any of these fields as part of the widget when EDITING the entity.

@tkoleary could you clarify whether the "common use case" you envisage is when viewing or editing the hypothetical album? The viewing case does seem to be the 90% use case.

Moving to right component