Edit in place

Posted by karens on March 19, 2008 at 3:27pm

It would be great to develop edit-in-place capability where you can be viewing a page and click on the content and have it turn into an editable text area without going to a separate edit form, or be viewing a Views list and click on a field in the list and have it turn into an editable field that you can use to update the value. When using this with Views, it could almost be like having spreadsheet capabilities. This would be a killer feature.

There were people talking about this at one time, but I don't think anything ever got done. Anyone interested in this should do some research to see what, if any, work has happened in the past that you could maybe build on. There was a jQuery edit-in-place plugin somewhere that I thought might be useful for this, but I can't find it now.

Unfortunately, I don't have time to flesh this idea out more, but would love to see something happen here, so if there's interest, maybe others can jump in.

Comments

+1 - comments, nodes, etc.

Posted by greggles on March 19, 2008 at 4:03pm

Wordpress has a nice feature like this for comments which I find is a pleasure to use (when it works).

There is also editview which does the "edit a node inside of a view" but it's at a whole node level, not a per field level.

--
_{Open Prediction Markets | Drupal Dashboard}

knaddison blog | Morris Animal Foundation

Cross-posted to JS group

Posted by webchick on March 19, 2008 at 4:05pm

I think this is a wicked idea. Just needs a little more fleshing out and we could take it over to http://drupal.org/google-summer-of-code/2008/ideas-list.

Yes! Very handy feature.

Posted by crashtest_ on March 19, 2008 at 4:29pm

I have used this, and have seen it popping up in a few other applications, such as editing titles and links for language translations - in place. I have seen this on Magento Commerce, and it is SLICK.

Awesome idea

Posted by jbrauer on March 19, 2008 at 4:43pm

This would be a great idea... For broad acceptance it would need to work with the WYSIWYG type editors.

--
Blog: Adding Understanding | Drupal Developer Search | Drupal Services: Brauer Ranch

--
Blog: Joshua Brauer dot com

Activeedit in Javascript Tools

Posted by nedjo on March 19, 2008 at 4:45pm

is an edit in place implementation that I sketched in but haven't put a lot more time into.

The approach is, load a form for e.g. the comment but only display a single field, then submit the form through the regular submission url, but override the regular return value so you get the rendered content.

I'd be happy to see a student or someone else take the start I made and run with it. I'm splitting up Javascript Tools in any case for 6.x and am looking for maintainers or co-maintainers for the individual modules.

Interested as a student

Posted by buddhika on March 22, 2008 at 10:04am

I was actually going to put this question 'isn't ActiveEdit enough for the task ?'. But now I understand what's more we can do to achieve the real 'Edit in place' effect. I'd like to help this task as a student if a mentor is willing to guide this in SoC.

Btw, About me, I'm Laknath (http://luckycala.wordpress.com) , a last year successful SoC participant (http://code.google.com/soc/2007/gnome/appinfo.html?csaid=80FB0FA809768E72) and a 3rd year undergraduate IT student in Sri Lanka. I've been also working as a part time web developer for Vesess (http://vesess.com) where I do most of CMS stuff and Drupal is my life saver literally :-) I've lead developing stuff of few Drupal powered projects (ex : http://www.plex.lk) and a module developer for Drupal(http://drupal.org/project/requestinvitation). So now I'm interested working for Drupal this year SoC and wonder if any one interested in guiding (mentor) me.

I blog @ http://mytechgossips.com

It would also be cool to

Posted by karens on March 19, 2008 at 4:58pm

It would also be cool to allow edit-in-place in blocks as well as nodes, so a good solution would work for that, too.

And we need a system to turn the feature on or off for specific fields, and check permissions, etc. I had been thinking about something where you add #editinplace to a field in a node array to turn it on and use AHAH to return the field.

CCK in D6 has a method where you can request an individual field form element without retrieving the whole node form, so that could be useful. Then you would need a option in Views to indicate whether this field qualifies and a function or path that will return the form element, and I think that sort of thing might not be too hard to add into Views 2 which now has all sorts of cool ways to add options to views fields.

The solution for translatable objects?

Posted by sun on April 27, 2008 at 10:16pm

Based on recent discussions on the development list, I could imagine that a feature like you described here would be the solution for on-screen edit-in-place translation of contents in Drupal - based on forms, individual fields, access permission checks, and finally whether a field is #translatable.

Just one caveat: All of this works only if we can somehow guarantee that an #edit-in-place (or similar named) FAPI property would add the required FAPI field/key information to the rendered output.

Daniel F. Kudwien
unleashed mind

Daniel F. Kudwien
netzstrategen

With Jeditable

Posted by carlitus on March 19, 2008 at 5:06pm

I'm sure there are more JQuery plugins but i know this:
http://www.appelsiini.net/projects/jeditable

Neurotic web design

That's the one I was trying

Posted by karens on March 19, 2008 at 5:07pm

That's the one I was trying to think of :) Thanks!

I agree it would be pretty

Posted by tjholowaychuk on March 19, 2008 at 5:09pm

I agree it would be pretty intuitive for some portions of the site. Dragging blocks into respective regions may be nice, but D6 makes a fairly good advance in usability with tabledrag. IMO some of this would yes be cool for us savvy users, however to be honest I think it may just confusing a lot of people who are used to seeing forms. That being said I think it is still interesting and could be implemented nicely into a lot of areas. Perhaps even simple things like changing the site title, click it, press enter, bam there you have it

vision media
350designs
Print Huge Edmonton Printing Services
Design Inspiration Gallery

Tj Holowaychuk

Vision Media - Victoria BC Web Design
Victoria British Columbia Web Design School

I did an implementation a

Posted by Steve McKenzie (not verified) on March 19, 2008 at 5:10pm

I did an implementation a while back before jQuery hit 1.0 and John Resig created the plugin for me.

The hard part was dealing with the node permissions and making sure proper permissions were checked on everything and also making sure all themes would use the right markup since you use a css selector to select the elements on the page. (node fields merging into the body field)

I think Drupal 6 might make it easier especially since how the theme layer changed.

An option for thickbox

Posted by jbrauer on March 19, 2008 at 5:26pm

It would also be nice to have an option to have a thickbox-style floating window to open and edit in front of the page which may help with some of the issues around user confusion and also provide options for places where the edit in place form would be too large to fit in the page.

--
Blog: Adding Understanding | Drupal Developer Search | Drupal Services: Brauer Ranch

--
Blog: Joshua Brauer dot com

agreed

Posted by matt v. on March 19, 2008 at 9:00pm

I caught the tail end of a demo of ExpressionEngine at SXSW recently. The next version of EE apparently includes exactly that — a "thickbox-style floating window" option when editing the main content of a page. That was one of the features that the audience seemed to really like.

I love the idea. It might be

Posted by alex_b on March 21, 2008 at 8:38pm

I love the idea.

It might be easier to tackle this problem with small steps: keep it simple what entities should be edited in place. If we had something that would allow us to reliably inline-edit

simple CCK fields (text and number)
titles
teasers/bodies

that would be awesome.

Alex

http://www.twitter.com/lxbarth

This has been tried before

Posted by chx on March 23, 2008 at 2:57pm

In 2005, Steven himself tried the results are at http://cvs.drupal.org/viewvc.py/drupal/contributions/sandbox/unconed/soc/

The biggest hurdle is that, due to Drupal's flexible text processing system, we cannot derive the original text from the HTML. Thus, we either need to pass the unprocessed text along with each post (the approach taken by this prototype) or we need a round-trip to the server to fetch that text when you start editing.

Both approaches are undesirable. Regardless, there is the downside that they cannot accomodate the many different kinds of forms that a Drupal node can have. Thus, it is only really useful for simple posts.

Also note that this was only a third of Steven's work that summer.

Well, there have been lots

Posted by karens on March 23, 2008 at 3:40pm

Well, there have been lots of changes since then (FAPI, and AHAH and jQuery in core). In particular we may be able to make something like this work for individual CCK fields, since we have a lot of information about them.

In saying this was only a third of Steven's work, are you saying this is too simple to be a SOC project?

FWIW, I disagree with

Posted by karens on March 24, 2008 at 11:38am

FWIW, I disagree with rejecting this idea. How can something be both 'infeasible' and 'too small'? That doesn't even make sense.

There is obviously a lot of interest in this, and although it was tried before, that was before FAPI, CCK, AHAH, configurable node types in core, jQuery in core, and a whole new theme system in core, all of which will make the task a lot different. I think it's extremely feasible that you could create something that would use the new features in D6 CCK where you can retrieve the form element for an individual field without retrieving the whole node form to allow you to edit a CCK field in place within a View, for instance.

And as for it being too small, if doing this for the node body and CCK fields is not enough, there are several other ideas above that will require additional work and time, like trying to find a way to integrate it into a field that uses a WYSIWYG editor. This feels like a substantial project to me. And if it's not, would someone please whip this up ASAP :)

I still would love to see this.

re-activated

Posted by catch on March 24, 2008 at 11:43am

I agree with Karen. Things have moved on a lot since 2005, so I re-edited the original post to ask for more discussion.

A few things I'd like to see - editing of taxonomy term information from the taxonomy/term view.
Inline path alias editing.
To name just two things that are absolute pigs to deal with at the moment.

I do believe that inline

Posted by manolism on March 24, 2008 at 1:24pm

I do believe that inline editing is a relatively big project for a SoaS (summer of a student :) ). And frankly i don't really feel that it will make such a big difference. Maybe it would be nice-to-have on a wiki but for most other relatively large real life installations the "edit" button works fine: the content does not change that often.

However, there are several simple things that can be done towards easier administration :

-- a simple "configure" button / tab on blocks in administration view
-- an easier way to change weights (possibly using up/down buttons and keeping the values hidden from the user)
-- edit buttons on category pages etc.

I can think of many more and i'm sure other will have many more ideas. Maybe a "quick links" menu could be introduced.

There is a need for a usability enchancements, i believe a SOC project can deliver them, starting with a survey of developers and users, and work towards simplifying the most common and the most time-consuming tasks.

An example where this would

Posted by karens on March 25, 2008 at 12:21pm

An example where this would be a vast improvement over the current process:

I have a site where I track fishing tournament results -- for each day the tournament runs we track the number of fish, total weight, etc. for each team using CCK fields on a custom content type. Then we post the results in a big Views table. When I look at the results, I can often see mistakes that need to be corrected. It would be nice to be able to click on the field with the wrong info and instantly correct it, while looking at it in context with the rest of the results. But currently the only way to fix it is to first find a link to the node that has the error (it won't be the field itself, it will be another field, like the title field), which will let me view the node, then click the edit tab on the node, make the change (if I remember what needed to be changed by that time), save the node, go back to the view and re-generate it, and see if I got it right.

Edit in place would be a huge timesaver here, and this is a 'relatively large real life installation', and there are lots of other 'relatively large real life installations' that could have situations like this.

Your other suggestions are easier ways to get to the edit form, which would also be nice, but are not the same thing at all.

Adding a few thoughts...

Posted by bradfordcp@drup... on March 25, 2008 at 6:05am

A thought as I read this, would it be possible to somehow hook into the input form built to create the node and pull out appropriate form element types? For instance if a custom module uses a drop down in a certain location of the input form, have the edit in place use the same drop down.

~Chris

The right solution will

Posted by karens on March 25, 2008 at 12:24pm

The right solution will absolutely pull out the right element form types for the field at hand, that's the whole point of this :)

If the element is a CCK field, we have an automatic way to get the right widget for that field. For other elements, it will require playing around with the node form using FAPI.

I love it

Posted by b.andy on March 25, 2008 at 1:54pm

I love the idea. I'd really like to work on this. I'm a 3d year student in electrical engeneering but I'm also empoyed and my work involves creating small drupal modules and customizations, I've also used jquery with these modules. Altough I've worked mostly with drupal 5 I'd like to do this for 6, it will allow me to get better accustomed to changes in the APIs since I've only done a couple of small modules in D6.

Coordinating with popups

Posted by davideads on March 25, 2008 at 3:04pm

+1 -- in place editing, when done carefully, is a very elegant technique.

It would be useful to coordinate this work with the popups project to strategically map out where these sorts of functionality would be most useful within common Drupal interfaces in the hopes of a having more comprehensive and strategic approach to improving Drupal usability with these sorts of affordances.

I have worked with jEditable in the past (for a project written in Django) and it did the job with a very minimum amount of effort -- I doubt there is much use in reinventing a Drupal specific solution for this.

I totally agree on not

Posted by karens on March 25, 2008 at 3:12pm

I totally agree on not reinventing a Drupal-specific solution for the jQuery part of this, assuming jEditable is GPL. But we'll still need to integrate it into our Drupal form and view handling, and there's probably plenty to do there. But if jEditable is not GPL, things get more problematic...

It would not be very hard to

Posted by tjholowaychuk on March 25, 2008 at 4:21pm

It would not be very hard to craft similar functionality for our own use. Keep in mind that CCK field modules would need to display their form fields as well, not always just textarea's etc, I dont know what the limitations are with this jQuery plugin.

vision media
350designs
Print Huge Edmonton Printing Services
Design Inspiration Gallery

Tj Holowaychuk

Vision Media - Victoria BC Web Design
Victoria British Columbia Web Design School

MIT license

Posted by davideads on March 25, 2008 at 5:34pm

jEditable is MIT licensed, so I assume it is out of the question, but a little edit-in-place system would not be hard to write.

dual licensing

Posted by catch on March 25, 2008 at 6:08pm

Some jQuery plugin authors will relicense their stuff as GPL for use with drupal modules. Worth asking.

self-made dual licensing

Posted by jpetso on March 25, 2008 at 7:57pm

MIT is GPL-compatible, which means that it can be transformed to GPL when necessary. (See the FSF licensing page if you don't believe me, X11 == MIT license.)

Nobody needs to ask the authors for dual licensing to bundle MIT (or LGPL, or BSD) software with GPL stuff. You can just add the GPL header and COPYRIGHT.txt files by yourself, and are legally allowed to do that. You wouldn't even need to add the GPL to the MIT software, because by bundling it into one piece, the whole of it becomes GPL automatically, by implication so to say.

drupal.org's policy not to include external software is mainly caused by the impossibility to have maintainers update their imported copy as fast (for security updates) or steady (for bug fixes) as the original provider does. However, incompatibility with LGPL, BSD and MIT is not a reason for that. Even if it's a long-standing false myth that's widely believed to be true in Drupal-world.

I have always asked authors

Posted by mfb on March 25, 2008 at 8:49pm

I have always asked authors if they could re-release under GPL (aka dual-license) similar to what happened with jQuery. This seems like the most courteous approach even if you can legally get away with not doing it.

Ok, I give up

Posted by jpetso on March 26, 2008 at 2:20am

I guess it doesn't make much sense round here to explain what pretty much every other open source project takes for granted. But let's just have one last try before I let go of it:

LGPL, BSD and MIT are explicitely chosen as license because they want to be used in other software, including GPL. Those licenses allow everything that the GPL allows, and a bit more, so the GPL is a subset of each of those licenses. If I want to be courteous, I tell other developers that I use (or would like to use) their software, that I love it, and if they agree to me using that software even if they don't have the legal standing to disallow that. There's a lot of politeness that can and absolutely should be applied to every other developer who throws out good software, even more so for public usage.

However, dual-licensing GPL-compatible stuff under the GPL is pointless, unnecessary, confusing, and doesn't cause any change in the legal behaviour of the software. Those licenses outright should not be dual-licensed when used in combination with the GPL, because in that context, they are the GPL.

To me the issue is not what

Posted by mfb on March 26, 2008 at 3:30am

To me the issue is not what you are legally bound to do but about community. The BSD communities maintain a large collection of BSD-licensed software. If you re-release software under GPL you are (to some degree) forking it because, any GPL bugfixes and improvements cannot be reabsorbed into the BSD-licensed project unless the BSD project doesn't mind being "contaminated" by GPL code.

...

Posted by jpetso on March 26, 2008 at 3:38am

Right, and forking is bad, so you don't fork it and use the original BSD version of that software in combination with your GPL code, which is perfectly fine for everyone: prevents forks, prevents unnecessary dual-licensing, and leaves more time for work that has any positive effect.

Not the point

Posted by Crell on March 29, 2008 at 10:03pm

That's not really the point. Yes, it's legal to include BSD, MIT, and other non-copyleft Free Software licenses in GPL code. However, Drupal has a policy of "if it's not GPL, don't put it in our CVS". That's as much for clarity as legality. That way someone downloading from Drupal's CVS knows that what they're getting is GPL, completely GPL, and nothing but GPL. There's no question of "except for that part with is MIT, or that part which is PHP licensed", etc.

Indeed the point for jEditable

Posted by jpetso on March 30, 2008 at 9:51am

I was making that point for jEditable which is external software and therefore is disallowed to be imported into Drupal's CVS anyways. Personally, I find the GPL-but-not-LGPL-and-BSD policy a bit paranoid (how about explicitely allowing LGPL, BSD and MIT as those are known not to cause trouble and get converted to GPL implicitely on distribution?) but I accept it as such. What I don't accept is people saying that you can't distribute GPL and MIT software together at all.

Defining the problem

Posted by nedjo on March 25, 2008 at 6:55pm

There is a set of problems that any Drupal edit in place approach will need to meet. My Activeedit module implements one set of approaches to solving these problems, and so will probably be a very useful reference for anyone who tackles the problem, whether or not they use any of my approaches.

We need a way to identify the page elements for in-place editing to attach to. This problem is significant because in Drupal theme differences mean that there is little we can count on in terms of common structure or selectors.
We need a way for users to trigger the behaviour.
We need a way to load forms that contain the data to be edited (which often will differ from the data rendered on the page). Steven's examples, above, are relevant here.
We need to test access such that only users with appropriate access can see the UI or access AJAX callbacks.

Typical edit-in-place jQuery or other js libraries don't help much with these problems and are often completely inapplicable.

Here is an example data structure from Activeedit, describing a datum (the logo file) to be made editable:

<?php
  $access = user_access('administer site configuration');
  $submit_text = t('Save configuration');
  $elements['logo_path'] = array(
    '#title' => t('logo file'),
    '#selector' => '#logo > a',
    '#submit_text' => $submit_text,
    '#target' => 'admin/themes/settings',
    '#access' => $access,
    '#form' => array(
      'system_theme_settings' => array(
        array(
          'logo', 'logo_upload',
        ),
      ),
    ),
  );
?>

We define a default selector, '#selector' => '#logo > a',, which can then be overridden on a theme-specific basis. We define access restrictions and the form and element(s) to be loaded. A significant point is that we avoid exposing new callbacks, instead relying on regular form submission.

A subset of these data are passed to the client for users with the applicable access and used to attach the behaviour.

The UI details I've roughed in for Activeedit (buttons to trigger the behaviour, loading of forms in place, etc.) are unimportant and easily changed. The basic approach is worth studying and maybe reworking and building off.

Custom pages

Posted by b.andy on March 25, 2008 at 7:02pm

Dose the code for GSOC has to be in a module or can we do modifications(patches) to core?
So the way i see it we need attach the necesary info(form element needed, primary key of the table the update has to be executed upon etc.). I see problems with modules using nodeapi and custom themeing for the node view or any other kind of page where we customize the output. I was thinking to do something like this $output.=theme('editable',$custom_output,array(form_id,form_element,table,table_field,primary_key));
and we would have to do this for every element in the row returned from the database(if we want it displayed and editable) wich isn't so pleasant. I'll think of some other ways to get the info needed to succesfully edit an item into the page display.
As for the other modules, as some allready said, if they're not GPL there's no problem, it's not that hard to do the JQuery part. The biggest problem i see is making sure this works for all(or most) kinds of content.
And I'd also like to do editable/sortable tables and also adding SUM, MAX, MIN, AVG and other stuff like this.

I would say you must make

Posted by karens on March 26, 2008 at 11:33am

I would say you must make this as a module, not as patches to core. We have zero chance of getting patches into Drupal 6, so you won't have anything that actually works that we can use if you do that.

I would not worry about making every field on a form editable, I would pick out the most likely candidates -- title, body, CCK fields, etc.

I would do this by creating a hook of some kind that fields that want to be editable can respond to. Create the hook in the code to handle core fields, and let other modules that want to create one create it. They should respond to the hook by passing in a form element that you can use for that form. The form element should have its own validation already in the form using #element_validate so you don't have to worry about making sure the element gets validated. They can also handle access in the hook if they are given the uid of the person doing the editing as one of the hook parameters by adding #access to the element they return, or by return no form for users without access.

Or you could do this by letting fields add #editable to their element on the node array which would tell you this is an editable field, then you could use module_invoke() to get the replacement, or add form elements to the node array itself for fields that are editable in addition to the 'view' array that they now provide.

All those are for node forms, but I would also like to see a way to do this in Views. Figuring out how to do that would take some more thinking.

Anyway, I think creating a basic system for modules to provide you with form elements that can replace their views will be the key to making this flexible and extensible.

Anyway, I think creating a

Posted by alex_b on March 26, 2008 at 2:41pm

Anyway, I think creating a basic system for modules to provide you with form elements that can replace their views will be the key to making this flexible and extensible.

This is an interesting difference to nedjo's activeedit: in the approach you describe a module that implements inline edit functionality would expose 'mini forms' with their own validation and submit handlers, right?

http://www.twitter.com/lxbarth

Remark

Posted by jpetso on March 26, 2008 at 6:35pm

Just to state the obvious: Modules that expose 'mini forms' with their own validation and submit handlers already exist under the name "CCK widgets".

Or you could do this by

Posted by karma.code on October 21, 2010 at 2:33pm

Karen, I am trying to use your example. Can you clarify this portion please. Specifically, I don't understand how the module_invoke portion would be used. Thanks.

What is everyones thoughts

Posted by tjholowaychuk on March 25, 2008 at 7:44pm

What is everyones thoughts on how to display these edit-in-place forms? Personally I think dialogs would be the way to go, which is not really 'edit in place' but personally I think that would just be very messy and almost counter intuitive. For example clicking the logo, you would be presented with a file field in its place? meanwhile deforming the box model of the current theme, I would way rather see this kind of functionality in nice little popups.

vision media
350designs
Print Huge Edmonton Printing Services
Design Inspiration Gallery

Tj Holowaychuk

Vision Media - Victoria BC Web Design
Victoria British Columbia Web Design School

Good question - the problems

Posted by alex_b on March 26, 2008 at 2:45pm

Good question - the problems you describe (and the ones that chx came up with further up the thread) make me believe that inline editing can't be for anything on your site, but rather for very defined cases: the title of a node, the caption of a picture, the bio on your profile... think of how e. g. flickr does it. you can't change anything with inline edit, but the most important things: captions and titles. and this helps you a lot in working quick with a site and avoiding page loads, etc.

That's the kind of functionality I would aim for: creating the possibility to offer inline editing for selected elements.

http://www.twitter.com/lxbarth

Another danger

Posted by davideads on March 26, 2008 at 8:25pm

Users need to KNOW something is inline editable. The curse of Flickr was/is that you sometimes don't know that something is inline-editable. Providing proper cues to the user is essential here. Perhaps that goes without saying, but on the other hand, I don't know that you can say it enough.

Nice little popups

Posted by davideads on March 26, 2008 at 8:32pm

As I've mentioned before in this thread, this process needs to be coordinated with the popups project, and a strategy needs to be worked out for address where a popup makes more sense, and where inline editing makes more sense. Or not. But it would be nice if it happened. It would be almost like a toolkit of widely-used and desired Javascript functionality, applied to Drupal in a consistent way.

Probably, this needs to be coordinated with Gabor's work on WYSIWYG in core for D7, as well, though more for the popups side than the inline-editing side of things.

Where is documentation on

Posted by tjholowaychuk on March 26, 2008 at 9:13pm

Where is documentation on this WYSIWYG project?

vision media
350designs
Print Huge Edmonton Printing Services
Design Inspiration Gallery

Tj Holowaychuk

Vision Media - Victoria BC Web Design
Victoria British Columbia Web Design School

The link...

Posted by davideads on March 26, 2008 at 9:51pm

On Gabor's blog.

There was a BoF discussion at DrupalCon which I attended, but I don't have much time to worry about until a project I'm working on is wrapped.

Form API

Posted by sirkitree on March 25, 2008 at 9:57pm

With the new AHAH in FAPI, I think it would make sense for inline editing to be defined within FAPI's AHAH. This way a designator could be defined per field. Thoughts?

Popups is the way to go

Posted by nedjo on April 1, 2008 at 6:42am

The Popups module has solved most of the more difficult problems. I'm working on a a form-alter UI module based on Popups. Development is extremely quick--thanks, starbow! When I'm done I may have a go at rewriting Activedit to depend on Popups. I think this will largely involve highlight code, press delete button.

Here's a preview of the approach. The basic idea:

find elements to be processed (e.g., for same-page editing, a title or body field in node view)
wrap element in an a element with href pointing to relevant form
attach mouseover and mouseout events for visual cues
bind popups behavior to the link.

Drupal.behaviors.formAlterUi = function (context) {
  $('form:not(.form-alter-ui-processed)').each(function () {
    var formId = $('input[name=form_id]', this).attr('value');
    var url = $(this).attr('action');
    url += ((url.indexOf('?') == -1) ? '?' : '&') +'form_alter_ui_form_id=' + formId;
    $(this)
      .addClass('form-alter-ui-processed')
      .prepend('<div><label><input class="form-alter-ui-enable" type="checkbox" /> '+ Drupal.t('Form customization mode') +'</label></div>')
      .find('input.form-alter-ui-enable')
      .click(function () {
        var checked = $(this).is(':checked');
        $('.element-marker-marked:not(.form-alter-ui-processed)', this.form)
          .each(function () {
            var id = $(this).attr('id');
            var elt = null;
            var marker = Drupal.settings.element_marker[id];
            // Only process if we have data available.
            if (marker) {
              var a = document.createElement('a');
              $(a)
                .attr('href', url +'&form_alter_ui_element='+ marker.join('|'))
                .addClass('form-alter-ui');
              if (checked) {
                var link = $('#'+ id +'-wrapper')
                  .wrap(a)
                  .mouseover(function(event) {
                    $(this)
                      .addClass('form-alter-ui-active');
                  })
                  .mouseout(function(event) {
                    $(this)
                      .removeClass('form-alter-ui-active');
                  })
                  .parent('a.form-alter-ui')
                  .get(0);
                Drupal.behaviors.popups(link);
              }
              else {
                $('#'+ id +'-wrapper')
                  .unbind('mouseover')
                  .unbind('mouseout')
                  //.parent('a')
                  //.replaceWith(this);
              }
            }
          });
      });
  });
};

Prototype posted

Posted by nedjo on April 4, 2008 at 6:16am

I've posted a completely stripped down version of activeedit for D6, http://drupal.org/project/activeedit.

Thanks to Popups, the .js file went from over 300 lines to under 40.

To try it, install, use Garland as the default theme, click on the checkbox in the upper right to enable active editing, and scroll down to the footer area and mouseover it. The content is highlighted and clickable. Click and get a popup form to edit the footer. Submit and, okay, it doesn't yet do what you'd expect (save, give a message, then update the original footer content), but you get the idea.

It's nothing more than a prototype, and leaves many important questions unanswered. But hey, it's a start, and if anyone feels like digging in or looking at this as a start to build on, e.g., for SOC, I'd welcome it.

popups subedit

Posted by highvoltage on March 13, 2009 at 3:24am

http://drupal.org/project/popups_subedit allows for some subform editing of fieldgroups at this point.

AHAH edit in place

Posted by rorymadden on March 25, 2009 at 2:05am

In searching for a solution to this issue I came across a project for Drupal 5 AHAH Edit in Place.

This seems to deliver what is being requested in this post however I cannot validate it as I am using drupal 6 and as a n00b I don't know how to port this across. The maintainer of the module will not port it to Drupal 6.

Are there any takers in this group? I'd really appreciate this functionality on a site that I'm trying to put together.

rorymadden : you clearly

Posted by adeb on April 27, 2010 at 3:21pm

rorymadden : you clearly skipped down to the bottom of this thread right away.

Anyway, it's an old thread but it is still very relevant to me.
I assume there is nothing that will do "edit place" / "in-line editing" at the moment for CCK ?

I'm considering to start working on a module that will implement this.
But I'm afraid it will be tailored too much for my specific needs / template for anyone else to be useful.
Also since time is an issue I might have to take some short cuts here and there.

Good article on "Why inline editing is hard"

Posted by tronathan on April 27, 2010 at 3:42pm

Wanted to post this resource to add to the conversation:

http://www.mattfarina.com/2009/04/09/why-inline-editing-in-drupal-is-hard

The article doesn't say much besides "many fields are computed" and I agree that often there are dependencies between fields. Not sure how to handel these dependencies when we're validating one field that is dependent upon another.

That said, +1, Drupal needs this!

Nedjo said, of http://drupal.org/project/activeedit "leaves many important questions unanswered". Is it safe to assume that those questions are being asked and answered in the activeedit issue queue?

If so, seems to me that this issue can be closed as the activeedit module solves this issue (unless the issue is more related to SoC than Edit In Place).

If not, what are those issues?

incorporated in Drupal 7

Posted by adeb on April 27, 2010 at 5:17pm

I just discovered this is possible in Drupal 7!
Even though D7 is currently in Alpha and we have little modules available I might just use D7 for my new project.

Love it!

Edit: Ok it's not truly inline editing yet (jQuery popup) but it comes close enough for my needs.

How?

Posted by san7 on June 9, 2010 at 9:39pm

What module are you using?
I'm testing D7alpha5 and don't see any inline/popup editing capabilities for individual fields.

For those just finding this thread

Posted by jditzel on September 12, 2010 at 6:45pm

one option to consider is http://drupal.org/project/editablefields .

please clarify

Posted by karma.code on October 21, 2010 at 2:32pm

Karen, I am trying to use your example. Can you clarify this portion please. Specifically, I don't understand how the module_invoke portion would be used. Thanks.

Has this been found yet?! I'm

Posted by webadpro on April 4, 2011 at 9:48pm

Has this been found yet?!

I'm looking for a popup way of changing a part of a form element field by field would be the best solution.

Thanks

jQuery UI

Posted by zarkinfrood on April 5, 2011 at 12:41am

Allows for a UI Modal dialog that you can snap in as an interstitial solution.

http://jqueryui.com/demos/dialog/

the methods and documentation are very clean, unobtrusive and easier than any of the other plugins I have used. I would be interested in developing a drupal module for this, but would need some D7 expertise before beginning.

This looks promising too: http://drupal.org/node/1491142 (wysihtml5).

Comments

Group organizers

New groups

Group notifications