Over at #1824500-94: In-place editing for Fields, @catch voiced very solid concerns about Edit module breaking render caching of entities because of
edit_preprocess_field() (which adds metadata to every rendered field), plus the fact that would slow down page rendering too much. The solution we settled on (#1824500-95: In-place editing for Fields) was to retrieve the metadata in an AJAX callback; the result can be seen in #1824500-95: In-place editing for Fields. (Note that the result is not an
AjaxResponse, but a
JsonResponse, i.e. no Drupal AJAX command framework commands, but simply JSON.).
Now this is much better already, but what's still problematic is that this AJAX request is now being requested on every page where there are fields annotated with metadata. So for many pages, there will actually be 2 requests to the server instead of one. Of course, the first one can now conceivably be cached by a reverse proxy such as Varnish, but it's still two requests.
Figure out a solution that triggers the metadata AJAX call less often; in other words: figure out heuristics that allow us to *not* perform the metadata retrieval.
- more granular permissions: permission to edit just node fields, or just user fields, etc., which would allow the JS to determine no metadata is needed when only things that are not editable by the current user exist on the page
- caching in localStorage, trivial to implement, but then the problem becomes cache invalidation — keep in mind that Drupal allows for arbitrarily complex (or weird) access permissions, which might mean that caching metadata in localStorage becomes pointless
User interface changes