Content preview <-> fields linking and inline editing

[thibaudcolas]

We should implement "anchor links" or a similar mechanism so users can move from previewed/rendered pages’ sections to the relevant blocks or fields within the editor form.

Is your proposal related to a problem?

TL;DR; it’s often frustrating to spend time searching where a field is for a given portion of the page content.

When working with content in Wagtail, there is a big separation between the content editing form, and how the content is displayed on pages. This separation is desirable (see Zen of Wagtail), but for CMS users it creates friction, when they have to go back and forth between a preview and the form to understand where to edit content.

• This back and forth can be very time-consuming, as the page’s rendering is often much simpler than the form. It becomes hard to locate where to make a given change.
• It’s a source of friction in particular where content quality checks report issues with page content but don’t make it easy to pinpoint where to fix them.

Describe the solution you'd like

This can be based on Wagtail’s existing “content path” mechanism to create links to specific blocks or fields, extended with a new capability to inject those content path anchor links within the rendered page. If implemented, this would also make it possible to implement reverse linking: from a given block or field, pinpoint the specific part(s) of the page it’s used on.

Describe alternatives you've considered

None

Additional context

This new linking would allow us to:

• Speed up navigation back and forth for editors
• Support synchronised scrolling: so editors don’t have to manually manage the scrolling of both the form and the preview panel when they are side by side.
• Connect content check issues from rendered page, back to the relevant field, which would make it easier to implement auto-fixing of those issues (related: #12260)
• Display Wagtail comments on the site’s front-end / allow creation of comments for the front-end, similar to the legacy wagtail-review package. Similar to the Vercel toolbar comments or Netlify Drawer comments
• Create inline / visual editing concepts: click part of the rendered page to get an "inline" editing form to update the correct field. See for example Netlify Visual Editing and Vercel Visual editing

Here is an illustration of what the "linking" functionality could look like, connecting a heading from the page to its occurrence within the page editor form:

Working on this

This requires a lot of technical exploration to review different ways to implement the functionality. A critical first step is to decide which option(s) to support to locate Wagtail fields within the rendered content. This targeting can be supported with:

1. Developers manually tagging their templates. This can be in the form of a template tag, or data- attributes, or HTML comments with a special syntax.
2. Automated encoding of this targeting information within the values returned by Wagtail/Django, via Unicode Private Use Areas code points and some cleverness overriding how people access blocks’ values.
3. Target by value (for example if a <h1> has the same value as the page’s title, connect that h1 element and the Title field).
4. Automated creation of "source maps" based on the AST of the templates.

Those options vary a lot on complexity, upsides, downsides. So there’s lots of work needed, possibly a Wagtail RFC, before moving to implementation.

[joeyjurjens]

Would this maybe also be a solution to the "it’s often frustrating to spend time searching where a field is for a given portion of the page content." problem?

[thibaudcolas]

@joeyjurjens I think so!

[thibaudcolas]

Just some R&D notes while we’re still exploring the feasibility of different techniques.

StreamField:

• render methods for structural block types (or all block types?)
• include_block template tag

Rich text:

• Rich text filter
• RichText value class
• data-block-key attributes

Target by value:

• URL text fragment selectors

[Nigel2392]

Currently this seems limited to pages alone.

I would like to expand on this - Wagtail is built on django, and many Wagtail users still like to use core- django.

It would be great to have some inclusions for regular models; most sites implement a detailview sooner or later - it would be unfortunate to leave out regular django models from this improved workflow.

[thibaudcolas]

@Nigel2392 👍️ we use "pages" as a shorthand often. In this case, the goal is to support this for anything that uses Wagtail’s previews. This would likely only work with the userbar loaded as well, ref #13471.

[thibaudcolas]

More R&D notes - @laymonage did an excellent prototype in our AI package, repurposing browser support for text fragments. Ideally there would be a proper programmatic API we could use for that.

[thibaudcolas]

I think the next step for this is #12187, a concrete scenario where we want to bridge the gap between preview and editor.