WYSIWYG and in-place editing for structured content

Karen McGrane gave a great keynote at DrupalCon Portland on future-friendly content with Drupal. It's worth watching the video recording. I agree with Karen's vision for the future. With the proliferation of different devices, screen sizes and input devices, there is a growing need for structured content that can be reused in multiple channels.

From the early days, Drupal has been doing structured content and content reuse better than most competitors. Drupal's node system was introduced in Drupal 3 in 2001, and was ahead of its time compared to the "page tree"-model used by most competitors. With every release, Drupal has gotten better and better at structured content and content reuse, leading to things like CCK and Views in core. Still to date, Drupal is one of the leaders in modeling structured content and content reuse. It is is one of the primary reasons we've seen so much growth. It was great to see that recognized by Karen.

One of the biggest gaps in Drupal has been the authoring experience. Two of the most noticeable authoring experience improvements that we are adding to Drupal 8 core are WYSIWYG editing and in-place editing. Where I disagree with Karen is with her belief that in-place editing and WYSIWYG editing are bad. Sure, WYSIWYG and in-place editing definitely can be problematic when combined with structured content. However, I believe we’ve implemented them in a good way -- it can't be compared to Microsoft Word's blob-like approach. I wish that Karen better understood how we have implemented this functionality. It would have been helpful if she had offered concrete suggestions on what better solutions would look like. Until we know what better tools look like, I'm convinced that Drupal 8's approach to WYSIWYG and in-place editing are a big step forward. It makes for another intermediate step towards a bigger vision.

We've been talking about the advantages and disadvantages of WYSIWYG for more than 10 years now, and we still haven't figured out better approaches. The best we've been able to do is to evolve WYSIWYG editing and in-place editing to apply to individual chunks instead of the entire page, to generate clean markup and to better guide authors to make them aware that their input may end up in many forms of output.

While implementing Drupal 8's WYSIWYG and in-place editing functionality, a lot of attention was spent on ensuring that these features are compatible with structured content:

  • WYSIWYG editors used to generate bad markup. Drupal 8's WYSIWYG editor guarantees clean markup thanks to the new "Advanced Content Filter" feature in CKEditor.
  • Drupal applies WYSIWYG editors to individual form fields instead of the entire page. You are encouraged to break up your content in many fields. Similarly, in-place editing is triggered on the entity level, not the page level, which means the user declares his intent to edit a specific entity and can then edit a specific field within that entity. In-place editing is only designed for quick edits, it wants to delight the author for those small edits, rather than forcing him to go back to the potentially overwhelming back-end form every time. At no point are authors given the impression they are editing the entire page.

For a more detailed explanation, see Wim's article: “Drupal 8: best authoring experience for structured content?”.

Want more features in Drupal 8? Help fix bugs!

In Drupal core, we use issue thresholds to manage technical debt. Both critical (release-blocking) and major (non-release-blocking, high-impact issues) are considered. When we have more open issues than our thresholds, we do not commit new features.

Currently, we have 27 critical bugs, 41 critical tasks, 155 major bugs, and 149 major tasks. This is more than twice our current thresholds for critical issues, and about 50% more than our thresholds for major issues. We need your help to resolve these issues so that we can resume adding new features to Drupal 8. That would be a very exciting place to get to!

There are many ways to help, including not only programming but also updating these issues' summaries, testing the patches, and making sure the patches still apply. I encourage everyone to collaborate on major and critcal issues, and to consider making them a focus at the DrupalCon Portland sprints.

Reducing risk in the Drupal 8 release schedule

Post-Drupal 8's feature freeze, we find ourselves in a similar state as we did after Drupal 7's feature freeze:

  • Some initiatives are mostly done, and now onto clean-ups.
  • Others are mostly architecturally there, but still have some pretty big gaps.
  • Still others are either not yet architecturally complete, have a major amount of integration/conversion work left, and/or have many outstanding critical/major bugs.

From here on out, we need to be more strategic about what patches we do and do not allow into Drupal core directly, and this means we have to make some tough decisions. Every patch we commit needs to not move Drupal 8 further from a "shippable state".

There are essentially two categories of initiatives (both official and unofficial) that are incomplete:

  1. Code already in HEAD, that we do not plan on reverting, and completion of which is critical to releasing Drupal 8. Examples are CMI, Entity NG, Router conversions. Incremental patches committed to these issues help move Drupal towards release.
  2. Code not currently in HEAD, or libraries that are sitting around effectively unused by the rest of Drupal. Examples are Twig, CSS re-organization, and parts of SCOTCH. Incremental patches committed to these issues move Drupal towards "uncharted territory", and could put the release of Drupal 8 at risk.

Therefore, the core committers plan to employ the following strategy when deciding what we do/don't commit to Drupal 8 going forward:

Commit decision flowchart

First, a patch will be evaluated to see if it belongs to a larger "meta" issue. For the vast majority of issues in the Drupal 8 queue, the answer will be no. For example, routine bug fixes and self-contained DX (Developer Experience) improvements can simply be committed once they're ready.

If an issue is part of a larger meta issue, the question will be whether that meta issue is critical to shipping Drupal 8. If so, the "does this move us towards release?" question is satisfied, and these patches will be committed as they're ready. An example of this is individual CMI conversions; we cannot ship Drupal 8 without all parts of it being deployable through the configuration management system. Similarly, we cannot ship with two methods of declaring routes.

If the meta issue is not deemed critical for release, but we can still ship Drupal 8 with part of it done, then we will also commit patches as they're ready. Views conversions are a good example of this. While it would be nice to ship Drupal 8 with all administrative pages converted to Views, we can still ship Drupal 8 with some converted and others not.

If the patch is part of a larger, non-critical meta issue, but getting part of it done is worse than getting none of it done (an incomplete state will hold up release of Drupal 8), then we're in a "danger zone" and need to look at possible options:

  1. First, we should see if the patch can be re-worked, or parts of it split off, into self-contained issues. Then those issues' patches can just be committed via the normal process.
  2. If there is no other option than completing the entire meta issue, then core maintainers will work with each individual team to determine a "cut-off date" for their work (which allows sufficient time prior to July 1 for integration), as well as the safest way for their work to continue without holding up the release. Possible strategies could include:
    • a larger patch containing the meta issue in its entirety, with no follow-ups, where it is still feasible to use a patch-based workflow (e.g. CSS re-organization).
    • a branch off the Drupal core repository that is merged in when deemed acceptable in the case of larger conversion efforts (e.g. Twig)
    • a sandbox project where larger refactoring is still necessary (e.g. SCOTCH).
    If the work is ready in its entirety (i.e. working upgrade path, passing all core gates) by the cut-off date, it will be eligible for Drupal 8. However, if not ready in time, it will have to be postponed to Drupal 9. While this is definitely painful for teams that have worked so hard but yet still miss the deadline, it is preferable to delaying the Drupal 8 release indefinitely.

Summary

The bottom line is that every patch we commit to Drupal 8 from now on has to help us get to a shippable state: it has to work, be performant (or be a required stepping stone towards more performant code), be well-documented and well-tested, and provide the right developer experience (DX). Getting Drupal 8 ready for release will take a big effort, and the core contributors could use all the help they can get. Now is the time to jump in and help.

Alex Pott

I'm pleased to share that Alex Pott (alexpott on drupal.org) has accepted my invitation to become another Drupal 8 co-maintainer, to help move along important issues as we gear up to head into code freeze and then release.

Alex has been working in Drupal for almost 6 years. While relatively new to the core development team, he has nevertheless been an instrumental force in the Drupal 8 Configuration Management Initiative (CMI). This development experience has given him a detailed understanding of various underlying Drupal 8 APIs, which makes him ideally suited to the task of reviewing and signing off on highly technical patches. Alex is furthermore thorough and patient in his technical reviews, and he has been a reliable leader and problem-solver during the Drupal 8 cycle. He is also currently taking time off from work, in order to have more time to dedicate to his family and to Drupal. It's a perfect fit.

When catch, webchick and myself were discussing who would be best to join the core maintainer team, Alex's name was enthusiastically +1ed from each of us. Please make him feel welcome!

The Red Press of Drupal

A couple of weeks ago Acquia, the Red Hat of Drupal, reached out to fellow CMS founder, Matt Mullenweg of WordPress, to see if he would consider switching to Drupal. As luck would have it, this was enticing to Matt. He has long understood the value of the Drupal community and has been looking for ways to leverage our community to make WordPress even better. When Acquia suggested switching to Drupal, it dawned on Matt that this was certainly the easiest way to integrate with Drupal without irritating his webmaster.

"I have always wanted to be part of the Drupal community, where technical expertise is sought after to create some of the most advanced websites. This move demonstrates the synergy between WordPress and Drupal without the possibility of function name conflicts." - Matt Mullenweg

We, at Acquia, couldn't be more excited to have Matt and the Automattic team on board, because some things are just better together ... like e-mail and spam filters.

Several months ago I started working with some of our top developers to try to come up with a practical integration strategy between Drupal and WordPress. We had been struggling with this for some time when webchick said jokingly: "It would be a lot easier if they would just use Drupal instead".

To be honest, I felt a bit silly even talking to Matt about using Drupal, but I didn't know at the time that he had been struggling with exactly the same goal and the same problems. webchick's inadvertent idea has ushered in new possibilities for innovation and frankly this is such a fundamental change for us I can't even imagine the world as it was before.

I am very excited about this collaboration. WordPress and Drupal form a killer combination that can't be beat in today's CMS market. I can hardly wait for the WordPress developers to get their drupal.org accounts set up, so we can work together in ways that were never possible before. I also suggested xjm to setup extra "WordPress tables" at the DrupalCon Portland code sprint.

A new Drupal module has been created to ease the transition. The "WordPress_iframe" module will be available on drupal.org soon. It facilitates a rapid integration of existing WordPress sites into their Drupal counterparts. We are excited about the debut of this new module because it embodies the Drupal community's open acceptance of this partnership while it allows us to roll out literally millions of these new Drupal/WordPress sites over the coming weeks.

As part of the agreement, Matt didn't want to completely move away from the WordPress branding, so we have incorporated it into Acquia's logo. Phonetically Acquia is pronounced ah-kwee-uh, so we've swapped out our Q for the well-known WordPress "W". The name is still pronounced "ah-kwee-uh" but will now be spelled "Acwuia". This visually puts WordPress right in the center of our logo - exactly where it belongs. This is WordPress, powered by Drupal.

Red press of drupal logo

We are very proud of this partnership and look forward to serving many more customers as a result. You can expect many more great things from Acwuia coming soon.

Matt, your Red Press of Drupal t-shirt is on the way. Let's stand together as brothers, united in Drupal!

Red press of drupal tshirt

Drupal and Red Nose Day

Last week it was Red Nose Day, a UK-wide fundraising event organized by Comic Relief every two years. A combination of television programs, local community events, social media and Drupal websites were used to raise £75 million ($113 million) in one day. On Red Nose Day everyone is encouraged to cast inhibitions aside, put on a Red Nose and do something funny for money. The money is used to make a difference to the lives of countless people across Africa and the UK who are facing terrible injustice or living in desperate poverty.

Rednoseday.com and Comicrelief.com are built in Drupal and the Acquia team have been supporting their talented web team with Drupal expertise and use of the Acquia Cloud to ensure a stable and massively scalable platform.

During the live show there were massive peaks in website traffic and every hour there were special heartfelt appeals within the program which results in a frenzy of donations. To deal with the sudden, massive spikes (they call them 'slams'), we had to employ 24 load balancers, 28 web heads and 2 database servers. We had an additional 12 load balancers and 2 web nodes ready for failover. This happens so quickly that it would not give you enough time to spin up additional servers once the traffic starts to ramp up. Along with the hardware, Acquia had 11 people helping with the infrastructure the night of the event.

As you can imagine, there is nothing like a live, six-hour televised national charity event where millions of dollars are at risk, to put fear into the hearts of any web team. To be able to do help inspiring charities such as Comic Relief gives the entire Acquia team an exceptional sense of accomplishment. I am very proud of their dedication and commitment to this project.

In fact, we've been doing our bit with some Harlem Shake videos from both our Reading (UK) and Burlington (US) offices to raise donations. It's not too late to help this tremendously worthwhile and life changing cause: https://www.rednoseday.com/donate.

New Mollom content moderation platform launched

Today I'm excited to announce that we've released the next generation of Mollom - our Content Moderation Platform. For the past five years, we have worked hard to help companies stay ahead of the curve when it comes to content moderation. With today's release, I feel like we've secured our place as the leading enterprise-ready content moderation system.

With over 2 years in development, and 600 beta users, the new content moderation platform is built to help companies handle extensive amounts of user generated content with ease. The main features of the Content Moderation platform are:

  • Easy team management. Site admins can add moderators, assign privileges, and monitor how moderators are performing - keeping an eye on productivity while trusting that no malicious content is making it to their site.
  • Fast moderation. If we know it's spam, your team never sees it. If we're sure it's good content - we'll publish it to your site. For the content we're unsure about - moderators now have a very easy user interface where they can view the contributor, their comment, and their reputation, spam, and profanity score all within seconds. They can approve or decline, and even take bulk actions to speed things up.
  • Custom filters. The system allows each user to create custom filters so they can focus on a specific subset of commenters. If they only want to see users with low spam and profanity scores - creating a filter takes just a couple seconds and they now have a customized view.
  • Multi-site management. All customers can have from one to hundreds of sites in their system - which makes moderation for big brands with multiple site properties very easy. Adding a site takes just a couple minutes, and customers can view analytics separately across all site properties.

You can learn more on the Mollom site, the video below, or in the press release we issued this morning.

I'm really excited to finally show this off to the world, and continue to help more companies embrace social without fear!

Pages

© 1999-2014 Dries Buytaert Creative Commons Attribution-NonCommercial-ShareAlike 3.0 License.
Drupal is a Registered Trademark of Dries Buytaert.