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

  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

  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

  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

  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

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

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

Notes

Comments

Wim Leers’s picture

Title:[meta] D8 WYSIWYG blockers» [meta] D8 WYSIWYG + in-place editing blockers
Wim Leers’s picture

Issue summary:View changes

Updated issue summary.

sun’s picture

Title:[meta] D8 WYSIWYG + in-place editing blockers» [meta] In-place editing, inline macros, editables, and Wysiwyg in core
Issue tags:+wysiwyg, +Killer End-User Features, +inline, +editinplace

I've completely revamped the issue summary.

sun’s picture

Issue summary:View changes

Revamped issue summary.

Wim Leers’s picture

Issue summary:View changes

Clarification about filter classifications. Plus minor improvements.

Wim Leers’s picture

I like the "Killer End-User Features" tag :)

Made some improvements to sun's improvements: http://drupal.org/node/1706688/revisions/view/2271820/2271926.

Then I removed my original issue summary.

Wim Leers’s picture

Issue summary:View changes

Remove the original issue summary; keep sun's revamped issue summary, with the modifications I made in the previous revision.

sun’s picture

Issue summary:View changes

Merged 8. In-place editing of entity properties into 3. Annotate editables.

sun’s picture

Issue summary:View changes

Clarified Editor plugin API and toolbar/plugin configuration.

sun’s picture

Issue summary:View changes

Added Edit module, Inline module, Aloha module steps.

fago’s picture

I guess #1026616: Implement an entity render controller is also somehow related.

Wim Leers’s picture

Thanks, @fago :)

webchick’s picture

We're having a BoF in Chamonix RIGHT NOW, here's the notes: https://docs.google.com/a/acquia.com/document/d/12YYnypQtnruKJ2PGWpXkSzx...

webchick’s picture

Issue summary:View changes

Added back what got lost in the "Merged 8. In-place editing of entity properties into 3. Annotate editables." revision.

moshe weitzman’s picture

Local storage is unsuitable, since size is limited, and data is lost when switching to a different client.. This reads like a final judgement. I'm pretty sure we could live with those limitations, if we want to. It would be super quick to implement. We should consider it if we get close to feature freeze without a better solution.

webchick’s picture

Issue tags:+Spark

Tagging as a Spark issue.

Bojhan’s picture

Issue tags:+Usability

Just wondering, why WYSIWYG is part of this. Thought the idea was to split of the WYSIWYG from the inplace editing stuff.

Wim Leers’s picture

Bojhan: it might be wise to do that, yes, but OTOH, many of these things are interrelated. E.g. when selecting a WYSIWYG editor, you also have to take into account how it can/could/should work on the front-end.

Wim Leers’s picture

Issue summary:View changes

Updated issue summary.

andrewmacpherson’s picture

Issue summary:View changes

updating with issue number for aloha-in-core

quicksketch’s picture

I added #1833716: WYSIWYG: Introduce "Text editors" as part of filter format configuration to the summary as the base issue for "allow integration with other 3rd party libraries". It initially attempted to integrate directly with filter.module, but per @sun's request it's now a separate editor.module. It allows for basic binding between text formats and textarea fields, and puts the configuration of client-side editors and filters on the same configuration page.

quicksketch’s picture

Issue summary:View changes

Adding http://drupal.org/node/1833716 as issue for using alternative editors.

webchick’s picture

Issue summary:View changes
Status:Active» Fixed

Since both WYSIWYG and in-place editing are now in core, and since almost all of the issues in the meta here are now marked fixed, tentatively closing this one out. More specific work for missing functionality is likely best left to other issues.

Status:Fixed» Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.