entity_reference formatters should be in Core

+++ b/core/lib/Drupal/Core/Field/Plugin/Field/FieldFormatter/EntityReferenceEntityFormatter.php
@@ -2,14 +2,15 @@
+// @todo

mh?

I think that this specific exception is useful to keep because

1) it's not really tied to a single field type, file/image references could have the same problem via the file_entity module
and 2) it forces the site builder/content editor to address the problem instead of letting it go potentially unnoticed and maybe melting down the server if the "silently stop rendering down the tree" threshold is not low enough.

Otherwise, +1 to this issue!

Can we also move the ER formatters tests to core as well here?

Yeah EntityReferenceItemTest is also in the er module

Silently stopping the rendering at least means that nothing breaks in the rare case where this happens ?

Sure, nothing will "break" in that case, except that it will be much harder to figure out why some content is not displayed, while the exception clearly states (in the dblog) what happened. We need to keep in mind that production sites will not display the exception itself (if configured properly), but a nice message that something went wrong and the site admin can easily see the problem in watchdog.

I think my reply above is actually making a case to at least emit a warning in watchdog if we decide to get rid of the exception :)

Thought a bit more about this and I realized that I was considering only the site builder/admin perspective, but this issue can also come up when a regular site user has access to edit an entity form with a reference field, in which case he cannot easily "do something about it".

So yes, let's drop the exception and switch to "silently stop rendering down when threshold reached" + logging.

Should we do it in this issue or in #2073753: Fix and add tests for the recursive rendering protection of the 'Rendered entity' formatter?

This looks good. Can you answer #9 and #10? Other then that it is RTBC.

Something like this ?

Yes, exactly! Looks perfect to me. Let's move those tests as well and get this in.

For the logging level, 'error' looked appropriate to me because the output of some pages is potentially broken. As for the channel, I don't have anything better than 'entity' in mind :)

This issue is a normal task so we need to outline how it fits within the allowable Drupal 8 beta criteria. Can someone add Drupal 8 beta phase evaluation template to the issue summary.

this issue makes me wonder how long we will actually continue to have entity_reference.module ;)

I think we're just left with widgets, the selection plugin, views integration and support for configurable entity reference fields in general (I recently noticed that it is not possible to have one, e.g. in a kernel test, due to missing/incomplete config schema support in core).

this issue makes me wonder how long we will actually continue to have entity_reference.module ;)

Not too long in fact :) I'll finish that patch for #entity_autocomplete and #entity_select Form API elements soon which means the selection plugins will also be moved to Core, and after that moving everything else should be trivial.

Should any of entity reference's config schema be moving too?

Thanks back to RTBC.

This makes things easier for contrib and core - less dependencies.

Committed 3fe7cb5 and pushed to 8.0.x. Thanks!

Thanks for adding the beta evaluation to the issue summary.

Count me as part of the very confused party that I thought I needed a dependency on entity_reference from contrib D8 code, but 8 months later have realized that core provides the field type now.