As part of the Spark project, we've been working on in-place editing, including "true WYSIWYG" editing on the front-end. The reception of Spark by the community at DrupalCon Munich was very positive. Thanks to that, we want to proceed with getting in-place editing in Drupal core.
The first step towards inline editing is getting WYSIWYG in core.
At this time, it looks like we'll have the following rounds (assuming they go well, of course):
- Round one: filter types and allowed tags —
- Round two: Aloha.module (this issue)
- Round three: ability to insert images, and caption images (not Media module)
- Further rounds: polish!, the ability to configure the order of the buttons of the WYSIWYG editor, potentially adopt Create.js, macro filter tags, migration path, and more.
Only the first two rounds must be done before feature freeze (Dec 1), the others can potentially be done before code freeze.
After round two, it is probably best to start working on preparing the Edit module for core inclusion.
(For a complete picture, please see this meta issue:.)
What this is about
The core problem: Drupal core is probably the last mainstream CMS on the planet that doesn't have a WYSIWYG editor included out of the box. While it’s certainly possible to configure a fully-featured WYSIWYG editor with contributed modules, it requires both fairly sophisticated knowledge of Drupal core’s filter system security, and is also a lot more work than Drupal’s competitors to achieve the same thing. This is hurting Drupal badly from an adoption standpoint; easier-to-use, less capable solutions are being chosen in many cases where Drupal would be a perfect fit. That makes this a critical feature to resolve in 8.x.
The problem is, most WYSIWYG editors suck. They generate crappy mark-up. Often, you have to create a custom CSS file to make it look "as much as possible but not quite" as the eventual result while editing. We need a solution that will work with the actual site’s styling, and doesn’t rely on kludgy workarounds like iframes and an approaching reimplementation of the site’s “actual" CSS.
Furthermore, Drupal has a “preview problem." In order to make a text change on the front end, a content author needs to click a link, be taken to a completely separate form that looks nothing like the content they’re trying to edit (especially if they’re using an administrative theme), and previewing this content displays it on the backend only; not in the context of the rest of their site with sidebars and so forth. What we want to eventually achieve is that previewing content through some sort of action is no longer necessary, because you're editing the content while it has its actual styling, in the exact context where it will be used.
The way to fix this is with “in-place" editing, where a content author just clicks on, for example, the node body and starts typing, with some indications to make it clear that you’re editing the body, plus a formatting toolbar above the node body (which might follow along as you type). So we also need a WYSIWYG solution that will allow for editing the content while it has its actual styling, in the exact context where it will be used.
Our goal is to ship Drupal 8 with a WYSIWYG editor that is better integrated than any other CMS's WYSIWYG editor. Through extensive research, and community consensus building we’ve arrived at Aloha Editor to fill this need. You can view a demo of Aloha Editor’s capabilities by its creator, Haymo Meran, at about 15:20 in the DrupalCon Munich Spark Core Conversation video.
Aloha Editor has the following things going for it:
- was selected together with the community ( ) to ensure the best choice possible was made
- can be used on both the front-end (to achieve "editing the content while it has its eventual styling, in the exact context where it will be used") as well as on the back-end
- has deep Drupal integration for better UX: ability to insert a link to another piece of content in your Drupal site, or any image uploaded to your site (no matter which field or module)
- has a custom UI, so that it doesn't feel alien
- has a custom UI that is ready for high pixel density displays ("Retina") through the use of icon fonts
- has a strong plug-in architecture ("ability to change/override anything"), much like Drupal has
- aims to be the most accessible WYSIWYG editor
- is future-proof because it is based on standards, yet as browsers evolve, various compatibility shims can be removed so we can send less bytes over the network.
- has stellar support for copy/pasting from Microsoft Office, Google Docs, etc.
For even more information about Aloha Editor and why it was chosen, see http://wimleers.com/blog/spark-update-wysiwyg-choice and http://buytaert.net/spark-update-wysiwyg-editing-for-drupal.
What Aloha Editor definitely is not: 100% ready yet, neither in terms of the WYSIWYG editor itself, nor in terms of its integration with Drupal).
Known bugs on our end (to be resolved before commit):
Known bugs/limitations in AE (to be incorporated over time, as they’re fixed):
- critical: — being fixed upstream
- critical: — upstream changes for accessibility will likely make this trivial to solve
- major: — being fixed upstream
- normal: — being fixed upstream
- minor: — being fixed upstream
Still to be done before feature freeze:
- critical: — being fixed/improved upstream
- major: — specifically see ; relates to round 3 in the roadmap
- Nice-to-have: make Drupal core use a single, swappable, site-wide icon font (that any and all modules can use so that the icons used everywhere are consistent). This would allow site owners to give their sites a custom feeling by simply building their own icon font. The Aloha core patch in this issue will for now include the Spark iconfont that lives over at http://drupal.org/project/admin_icons, because we don't want to deal with the "swappable, site-wide icon font" feature right now.
Reviews that happened already:
- @sun reviewed the PHP code:
- @nod_ reviewed & approved the JS code for core inclusion already: — the code has changed somewhat since though, but it should be in pretty good shape overall
- @psynaptic reviewed & cleaned up the CSS code: — more reviews needed, though that could potentially happen post-feature freeze
Besides the already long list above, it is easy to spot more rough edges, minor bugs, major bugs, and so on. The ones above should contain the most important issues. Please be aware that the Spark team is committed to continuing to work on improving the WYSIWYG editor (both in terms of Drupal changes and upstream changes) all the way to code freeze, and beyond.
With the above ambitious goals, it is impossible to get this in "near perfect" shape (which is what is necessary for something to ship with core) either in this patch, or before feature freeze.
This issue aims to get "something that works reasonably well, for some value of reasonable" in Drupal core, as a basis to continue iterating from in the months to come.
User interface changes
Once you enable the Aloha module, it will provide the ability to edit text areas (that have a text format selector) through Aloha Editor, *if* the currently selected text format is compatible. In practice, this is on node, comment, taxonomy term, block body and user signature forms.
(To figure out a full list of consumers, this command may be handy to you:
egrep -rn "'text_format'" --exclude=filter.module --exclude=form_test.module --exclude=FormTest.php . | grep -v "*")
- Currently no API changes.
- Addition of the aloha.module to Drupal core.
- Preferably we'd update the standard install profile to configure the "Filtered HTML" and "Full HTML", but we can do that later on. Patch already attached to show what that would look like. (This patch was originally part of the patch, but has been removed from that patch in .)
Testing the patch
The easiest way to test this patch is to use the Spark demo site at http://spark.webchick.net/8.x/ which is running the 8.x-1.0-alpha2 version of Spark, which contains all of the below steps already set up.
Note that this patch doesn't get us inline editing; only WYSIWYG editing on the backend, so you have to go to a page like node/2/edit to see it. Edit module is still undergoing clean-up for core proposal.
If you want to test this patch manually against a vanilla copy of 8.x, you’ll need to do the following:
- patch link) — this issue is still in flux, so please use the patch in this specific comment (
- Apply the attached "Aloha module" first, then the "Aloha Editor build" patches. I specifically separated out the "Aloha Editor build" patch so that we can evolve the actual module code separately from the Aloha Editor build patch. (Note that you could alternatively download the 8.x version of the Aloha module and install that. The patches are generated automatically from that.)
- OPTIONAL: The attached "install profile" patch if you want to do a fresh Drupal 8 installation and don't want to mess with filter system settings.
Alternatively, we've provided a handy shell script that does all of the above for you (including the optional "install profile" patch).
If you're using core's
filter_url filters, it's not compatible (because they generate HTML). If you're using the
filter_html filter, then please add the
<p> tags to the list of allowed tags. If you applied the optional "install profile" patch, then you can do a fresh install and all should be pre-configured for you.
Whew! :) That’s everything. We really look forward to your reviews, and help in driving this closer to home.
|#74||drupal_wysiwyg-in-core-round-two-aloha-module-74.patch||218.58 KB||Wim Leers|
|PASSED: [[SimpleTest]]: [MySQL] 48,784 pass(es). |
[ View ]
|#74||drupal_wysiwyg-in-core-round-two-aloha-build-74-do-not-test.patch||990.97 KB||Wim Leers|
|#74||interdiff.txt||32.78 KB||Wim Leers|
|#72||drupal_wysiwyg-in-core-round-two-aloha-module-72.patch||226.95 KB||Wim Leers|
|PASSED: [[SimpleTest]]: [MySQL] 48,264 pass(es). |
[ View ]
|#72||drupal_wysiwyg-in-core-round-two-aloha-build-72-do-not-test.patch||990.97 KB||Wim Leers|