僕は昨年の夏、Drupal 8 の一部として Aloha Editor を採用するであろうことを発表した。その主たる理由は Aloha がインプレース（「本当」の WYSIWYG）編集をサポートしている唯一の WYSIWYG エディターだったからだ。それはインプレース編集に対する僕たちの理想像を実現するために必要なものだった。Aloha Editor の開発者たちは Drupal 側のニーズに対して本当によく配慮してくれた。ただ、彼らのエディターは「本当の WYSIWYG」というコンセプトに基づいているので、その性質から来る若干の問題にぶつかった。（Drupal の）バックエンドで使用した場合に遭遇する、Aloha Editor のユーザー エクスペリエンスとアクセシビリティーに関連した案件だ（それらには現在、Aloha Editor 側の人々が積極的に取り組んでいる）。
昨夏の発表以来、CKEditor が追いついてきた。今や、僕たちのニーズに関して言えば、Aloha Editor に肩を並べる機能を提供するまでになった。CKEditor の作者フレデリコ クナッベン（Frederico Knabben）は、CKEditor と Drupal の動作をよりよくかみ合わせるためならどんなサポートでもすると申し出てくれた。彼らはすでに Aloha Editor 最大の武器である「ブロック（Blocks）」システムに対する代替案として十分な説得力のあるプロトタイプを作り上げた（ブロック システムはテキスト コンテンツ内において構造化されたやり方でコンテンツを管理するという Drupal のニーズにぴったり合っている）。それに加えて僕たちが気づいたのは、API、ドキュメンテーション、そしてプロジェクトを取り囲むエコ システムに関しては CKEditor の方が成熟しているということだ。というわけで、何日にもわたる調査と、そこからさらに何週間にもわたる議論の結果、僕たちにとっては CKEditor を選択するのがベストであるという統一見解に至った。
こうしたことから、Drupal 8 コア用（のエディター）は Aloha から CKEditor へと切り替えることになる。この切り替えでは、より成熟した WYSIWYG エディターが得られるというだけではない。Drupal のオーサリング エクスペリエンスにおける他の部分に取り組んでいるリソース（人的、時間的な資源）を解放することにもなる。CKEditor チームは、僕たちが検出した 8 つの機能的なギャップを今後リリースされる 2 つのバージョン内で修正すると明言してくれた。
今回のように期限ギリギリで結論を出す（変える）のは決してやさしいことではない。ただ、こうした結論は Drupal にとっての最善策をとるためのものだ。ここで Aloha Editor チーム、CKEditor チームの両方に対して感謝の意を表したい。彼らは僕たちがそれぞれのエディターを評価、検討することに協力してくれた。また、機能的なギャップを埋めるため、Drupal コミュニティーと共に取り組んでくれた。ただ、（今後も）Aloha Editor から目をそらしてはいけない。Aloha Editor は Web の将来を示す兆しをたくさん抱え続けていくエディターだ。