Welcome to my corner of the web. Here you'll find my ramblings about faith, church, drupal, Geeks and God (my podcast), and my other unrelated interests.

While you can subscribe to all posts here from the Subscribe link on the right, there are two other main feeds. There is the drupal and other technology feed along with the faith and church feed.

Why Inline Editing In Drupal Is Hard

Posted on: Thu, 2009-04-09 15:12 | By: matt | In:

Mark Boulton and Leisa Reichelt have suggest drupal provide inline editing in the interface. This is a fantastic idea and one I would love to see in drupal. But, (I hate this part) inline editing in drupal is a difficult feature to add. So, before everyone wonders whey we don't offer it or why it's going to take some work let's look at why this is hard.

An example

I think a good way to see some of the problems in action is to look an example of what would happen. For example, let's look at the process of editing the body of a page inline.

  1. A user clicks on something to convert the body as displayed into a field to edit.
  2. The page calls back to drupal to get the content of this field as someone would edit it. The content drupal displays goes through a filter system before it's displayed. This cleans out XSS and other security measures and lets other drupal modules plug-in to alter content too. An example of this altering is Filtered HTML which strips out unwanted tags.
  3. A user updates this text and submits it.
  4. This updated text needs to go back to the server, run through the filters, and returned to the page for display.

We might think this is where the fun stops. But, it doesn't. Many of the fields displayed by drupal are computed fields. A simple example of that is the teaser for the body text. In many cases this is computed by a number of conditions. How will this be handled? How will other computed fields be handled in updating the live page?

Not The First Time

This is not the first time someone has tried to add inline editing into drupal. Some, like Steven Wittens, have tried to do it in the past. This is a difficult problem to solve and is a product of drupals loved and utilized power.

Let's Figure It Out

I think we should try to figure it out. I love the idea. It means we have to make decisions and changes will touch some complex code. But, I think understanding a problem is a good place to start solving it. So, who wants to start rolling this patch?

Update: This post is based on a conversation in #drupal between leisa, chx, myself, and others.

Comments

#1 Popups API?

Submitted by Rob Loach on Thu, 2009-04-09 16:47.

Although it's kind of not exactly what they were looking for, the Popups API and Popups Subedit modules are going in this direction. Starbow has done some awesome work on them, and I'm really looking forward to improving upon it.

#2 Easier in D7

Submitted by matt on Thu, 2009-04-09 16:56.

This should get easier in drupal 7. In HEAD you can pass back a JavaScript settings array (like Drupal.settings) and send them through the behavior calls.

What Starbow did may be a good place to start. I'll be interested to see how they handle the tough questions (like handling computed fields) and if those same answers are OK for core.

#3 Cheater!

Submitted by chx on Thu, 2009-04-09 20:34.

Most of this post is my knowledge, my thoughts told on IRC while you were listening. You forgot to mention this little tidbit. Giving credit is essential.

#4 Sorry

Submitted by matt on Thu, 2009-04-09 20:40.

chx, I didn't mean to steal credit. Sorry I didn't post about you in here.

Though, I am very familiar with the filter system and why the problems are present. I knew everything I posted here, except that Steven had worked on the problem, long before today.

This post was after a conversation in IRC with chx.

#5 Why do you always have to go

Submitted by Anonymous on Thu, 2009-04-09 23:28.

Why do you always have to go around pulling other people down in your blog and posts and indulging in name calling? Being a core developer who works on the innards of Drupal doesn't mean you don't have to civil in your dealings online.

Grow up or the day isn't far off when people start hesitating to interact with you.

#6 But what about..?

Submitted by Damien McKenna on Fri, 2009-04-10 00:25.

What if there was a way for fields to determine if they could be edited inline, e.g.:

  • computed fields would say "nuh-uh",
  • a textfield or textarea would say "bingo, here's the field,"

and maybe extend it further to allow e.g.:

  • imagefields would have a field to upload a new image but also a section to update the imagecache preset being used
  • a computed field could show the fields used to build the result

Food for thought.

#7 Why not restrict it to

Submitted by Gerard McGarry on Fri, 2009-04-10 15:21.

Why not restrict it to title, body and taxonomy fields? I think it's a brilliant idea, if it could be executed. Imagine not having to fully reload the edit screen to make a trivial change to a post. However difficult inline editing might be to achieve, it would be a massive usability win.

But if you're going to do it, maybe it would be good to offer the same functionality for registered users editing their own comments for maybe up to 60 seconds after posting?

#8 Added to DrupalSightings.com

Submitted by Jim on Fri, 2009-04-10 08:21.

Added to DrupalSightings.com

#9 Hard, but a must

Submitted by Anonymous on Fri, 2009-04-10 11:47.

Agree, we have to figure it out. Sites like Squarespace are so solidly designed, that failure to act, might in fact just allow competitors to pull ahead.

#10 Input vs Output Filtering

Submitted by micah on Fri, 2009-04-10 19:42.

I don't know if this quite fits into the topic, but I've always found it confusing that this process is referred to as an Input Filter when, in fact, it's applied during rendering. In my mind, that would be better named as an Output Filter. This was a bit of a usability issue in my early Drupal days.

I would expect an Input Filter to do exactly what it says it does and remove all filtered tags, etc, before saving the node data. Oddly enough, I would also expect the enhancing tags (adding line breaks, rendering URLs as links, etc) to still be applied during the output stage, so I suppose my expectations are a little inconsistent. But the bottom line is that I originally expected filtered tags to be stripped at the beginning. Somehow, I think that would fix some of the mess that some WYSIWYG editors create.

There have been some really good efforts to make existing rich editors work with Drupal, but it makes sense that the best solution would be Drupal-native. An editor built to understand Drupal's Input Filter system from the onset would have a distinct advantage in its ability to understand and coexist with these filters.

Just my $0.02.

Micah

#11 Thanks for Popups API and

Submitted by Guix on Thu, 2009-04-30 10:03.

Thanks for Popups API and Popups, I didn't know these projects.

Inline should be mentionned too here and WYSIWYG API too.

#12 Drupal is hard ... period

Submitted by Dean Peters on Thu, 2009-05-14 14:56.

Drupal is hard, period.

Oh I've done it, and I get it.

Problems begin when you need to pass along and/or delegate the responsibilities of running a drupal-driven site to someone else.

Taxonomies v. categories v. forums v. content ...

... meaning, provided that a user gets to the right place to inline edit, then they 'enjoy' the issues you've nicely enumerated above.

#13 d7ux

Submitted by matt on Mon, 2009-05-18 14:20.

I agree that drupal can be hard.

Yes, drupal has issues. That's why there is a massive amount of usability work going on. If you had followed the link to the stuff on inline editing you would have seen the usability effort and all the other tie ins.

This blog post was just to explain why it's hard so when they go to do it as part of the larger effort they have some insight and people who wonder about it now have some more insight into why it's the way it is.