As I understand, the ability to edit related objects directly from their including object's content/edit is handled with ezorl_edit_object client-side; server-side, at submission of the including object, its orl attribute calls handleAllCustomHTTPActions on related objects, so that they get a chance to interpret the form's content too.

Problem is, those objects call handleCustomObjectHTTPActions on each one of their orl attributes, which in turn call handleAllCustomHTTPActions related objects, and so on.

Recursivity is limited by eZContentObject::recursionProtect; it avoids one same object to be called twice… or one million times.

But what to avoid one million objects to be called once?

I'm currently working at a national radio/tv broadcaster, with a pretty database of artists, news about them, interviews and so on. So when I modify a news, the artist(s) it links to gets fetched by the 'artist' orl attribute. In turn, this loads artists linked by the 'similar artists' of the artist. Their own 'similar artists' gets fetched too, and so on, in a magnificient recursive call which ends in a PHP killed due to max memory allowed.

I suggest this: instead of fetching all objects that could be related so that each one tests the form for content it is interested in, we should make every embedded editing template insert a hidden input to tell that object n has been presented for editing, and thus should be called.

This is what I do in the attached template, however I have not tested it, we're not using linked content embedded editing (imagine the frustration to discover the crash was due to something we don't even use!).