[meta] In-place editing, inline macros, editables, and Wysiwyg in core

Goal

• Native support for in-place editing for content in Drupal core.
• Native support for "inline" macros (oEmbed/token-alike) to embed content into other text in Drupal core.
• Native support for WYSIWYG editors (and potentially shipping a certain one out of the box).

Battle plan

1. Determine edit access for all editables during view.

   Issue: @todo

   • In-place editing requires the system to know what the current user is allowed to edit — during regular view. This not only applies to high-level things like entities, but also to every piece of property, field, etc within.
   • If the edit access check yields a positive result, then the piece of content is marked up as editable.
   • In its full extent, in-place editing is also supposed to work with other page elements; e.g., blocks, page title, etc — which do not have a generic access API currently.

   Related issues

   • Entity access: #1696660: Add an entity access API for single entity access
   • Field + property access: @todo field_access()
   • Block/plugin access: @todo
   • Config object access: @todo

2. Annotate editable pieces of content

   Issue: @todo

   • Leverage the RDF module API to annotate editables.
   • Challenges:
     • Entity properties (e.g. node author & creation date) cannot be rendered separately, they are rendered through the theme system, not through Field/Entity API. Thus, they cannot be re-rendered after in-place editing. They are also rendered on their own without wrapping container. (workaround example)
     • Entity properties don't have standalone forms/widgets (like fields). FAPE module implements a massive workaround for that, but this needs to be solved properly for core.
     • Title on pages where the entity title becomes the page title. (workaround example)
   • Long-term, ideally leverage CreateJS and VIE.js, which attempts to introduce a standard for annotating editables, so it becomes possible to use any client-side editor library that understands the annotations. The semantic standard even allows to create forms on the client-side.

     However, the dependencies and requirements for that are quite big:

     1. #1696648: [META] Untie content entity validation from form validation — replace form-driven CRUD of entities/fields/properties
     2. Figure out support for Field API's rich set of customizable/extensible widgets and formatters.

     Given the limited time-frame for D8, we might have to postpone this to D9. However, also note that VIE.js/IKS aims for a stable release at end of 2012.

   Related issues

   • #1706612: remove 'submitted' variable in templates for ease of theme development
   • #1346214-29: [meta] Unified Entity Field API
   • #1346214-33: [meta] Unified Entity Field API
   • @todo Annotate entity title and retain its annotation even when it is turned into the page title.
   • #226963: Context-aware text filters (provide more meta information to the filter system) — only related if we choose to support editables in input filters though.

3. Move Edit module into core

   Issue: @todo

   • Provides in-place editing (i.e., with the ^^ above dependencies).

4. Move Inline module into core

   Issue: @todo

   • Enables inline macros in text fields.

5. Handling of non-HTML text formats, and input filters that alter the output

   Issue: @todo

   • Almost every input filter means that input != output, but WYSIWYG actually means input == output.
   • Limiting allowed HTML tags should be possible, but any other filters are not really compatible.
   • Other text formats (e.g., Markdown, Textile, etc) are not compatible either.
   • Formats/filters need to be classified:
     1. to not apply a certain class of filters that do not make sense for WYSIWYG editing (e.g. don't apply the "transformation" class of filters, such as Typogrify)
     2. to signal a simple "(true) WYSIWYG editing" compatibility.
   • In any case, the edited user input will be sent through the server-side format/filter system before it is displayed in the front end again, since JavaScript is not able to safely replicate the server-side input filtering process.

   Related issues

   • Revamp text formats and filter processing: #807996: [meta] Input filters and text formats
   • #1782838: WYSIWYG in core: round one — filter types

6. Add Aloha module to core

   Issue: #1809702: WYSIWYG: Add Aloha Editor to core

   • Enabling Aloha Editor integration (i.e., with the ^^ above dependencies).

7. Editor plugin API and toolbar/plugin configuration

   Issue: @todo

   • We need a way to configure the Wysiwyg editor's toolbar.
   • Modules need to be able to expose plugins — which may or may not appear on the toolbar (some plugins may extend or adjust the editor on a low extension-level only).
   • Some plugins might be configurable, so we need a way to configure plugins.
   • Some plugins might be constrained through other configuration elsewhere; e.g., the HTML filter's configuration for allowed tags potentially limits what plugins can be used.
   • It might make sense to put/merge the editor toolbar/plugin configuration into Filter module's text format + filter configuration page — although that could get very convoluted/cluttered, and there will be editor plugins that do not depend or relate to formats/filters.

8. Allow to use alternative client-side editor libraries

   Issue: #1833716: WYSIWYG: Introduce "Text editors" as part of filter format configuration

   • Avoid a lock-in to a particular client-side editor library in the middle to long term. Account for the fact that the front-end world is moving much faster than Drupal (core) does. At the point Drupal would have fully adopted a particular library, there will be a dozen of new libraries and approaches that are faster, smaller, better, and more compatible with challenges such as mobile/touch devices, etc.
   • Essentially, Wysiwyg module in core.
   • However, given the limited time-frame for D8, we might only achieve this:
     1. Ensure the chosen WYSIWYG editor can be disabled and other editors get the same integration capabilities.
     2. Add a module for Aloha Editor integration to core.
     3. This module can be disabled, separately from the other support code/module for in-place editing. Thus, an alternative module can be used.
     4. Provide editor plugin support code for inline macro filters (the server-side counterpart for editables/Aloha Blocks) that are generic, so they can be re-used by other client-side editor libraries.
     5. Generally limit the amount of Aloha Editor-dependent code.
     6. Explore VIE integration in contrib, ideally Wysiwyg module.

   Related issues

   • #807996-15: [meta] Input filters and text formats

9. Auto-save edits into "draft" revisions in the background

   Issue: @todo

   • Inspiration: Wordpress' editor automatically saves revisions during editing. When the content is saved manually, the automatically created revisions are cleaned up. I.e., they have two separate revision types: auto vs. manual.
   • Local storage is unsuitable, since size is limited, and data is lost when switching to a different client.
   • #1642062: Add TempStore for persistent, limited-term storage of non-cache data might be an option.
   • Different revision types seems to be the most favored approach.

   Related issues

   • #218755: Support revisions in different states
   • @todo Perform auto-saving on the backend; figure out which strategy to use and how these revisions should be tagged/typed.
   • @todo Leverage the same approach for in-place editing.

10. Upgrade path from non-HTML markup/text formats

    To be solved by contrib, since contrib introduced those formats in the first place.

Notes

• Original discussion happened in a Google Doc.