Voting starts in March for the Drupal Association Board election.
- 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).
- Determine edit access for all editables during view.
- 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.
- Entity access:
- Field + property access: @todo
- Block/plugin access: @todo
- Config object access: @todo
- Annotate editable pieces of content
- Leverage the RDF module API to annotate editables.
- 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:
- — replace form-driven CRUD of entities/fields/properties
- 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.
- @todo Annotate entity title and retain its annotation even when it is turned into the page title.
- — only related if we choose to support editables in input filters though.
- Move Edit module into core
- Provides in-place editing (i.e., with the ^^ above dependencies).
- Move Inline module into core
- Enables inline macros in text fields.
- Handling of non-HTML text formats, and input filters that alter the output
- 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:
- 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)
- to signal a simple "(true) WYSIWYG editing" compatibility.
- Revamp text formats and filter processing:
- Almost every input filter means that
- Add Aloha module to core
- Enabling Aloha Editor integration (i.e., with the ^^ above dependencies).
- Editor plugin API and toolbar/plugin configuration
- 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.
- Allow to use alternative client-side editor libraries
- 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:
- Ensure the chosen WYSIWYG editor can be disabled and other editors get the same integration capabilities.
- Add a module for Aloha Editor integration to core.
- This module can be disabled, separately from the other support code/module for in-place editing. Thus, an alternative module can be used.
- 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.
- Generally limit the amount of Aloha Editor-dependent code.
- Explore VIE integration in contrib, ideally Wysiwyg module.
- Auto-save edits into "draft" revisions in the background
- 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.
- might be an option.
- Different revision types seems to be the most favored approach.
- @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.
- Upgrade path from non-HTML markup/text formats
To be solved by contrib, since contrib introduced those formats in the first place.
- Original discussion happened in a Google Doc.