Make autosave optional and implement a "save button" views field

Or have the option to save automatically and not need a save button.

We now have the ability to autosave on simple form fields. I guess this obsoletes this issue?

You might also want to disable the ajax edit function in case some fields were dependent on other fields.

Are you talking about states-style dependency?

Moving the issues back to the main project.

Soooo we need to consolidate all the EF form elements per row/page/whatever into a single form? This is a great idea, but harder than just ajaxing the individual forms into the page.

Select save method would be a great feature for editablefields!
Ajax auto save and a edit button just works fine but I also would like (and need) a "global" save changes" button to save all the changes once after confirmation click. Also a nice additional possibility should be the row based save button but I think with a lower priority...

subscribe

It would be an excellent option.

Suscribing

I don't use editablefields at the moment because without a global save button as a "confirm changes" option I could loose content without a chance to recover it.

Any update here? Will a save button added in a future release?

@JohnnyX speaking for myself this seems like a reasonable and useful request. If you want to submit patches or otherwise sponsor the development of this feature I'm sure myself and the other maintainers would be all ears :-).

I think a page-wide submit button should probably come first since it could be Views-agnostic.

I feel like this subject came up once before...

I needed the use of editable fields and I understand the need of users to have a save button or data is not saved. Here is what i did to make it happen. It's going to be long so sit back, relax and read carefully.

This change was tested on text/select/combo fields and image fields. sooner or later i will have to do something with reference fields and i hope i will have time to update this post.

I chose to do all my changes on the JS side, I just use the ajax capability of every field which means that it's still a separate save process to every field and i would like to turn it to one bulk update but this is a start.

1. changes to the Drupal.behaviors.editablefields_submit function
I removed the click trigger on field changes and replaced it with an attribute. This way i can sign to the button what fields need to be saved.
$this.find('input.form-submit').attr('tosave','true');
For image fields I created an attribute on the submit button that remembers the last fid. I also made the button hidden.

if ($this.find('input[type="hidden"][name*="fid"]').length == 1) {
	//hide the button
	$this.find('input[type="submit"][name="submit-"]').hide();
	//add the last fid
	$this.find('input[type="submit"][name="submit-"]').attr('fid',$this.find('input[type="hidden"][name*="fid"]').val());
}

2. creating a button. (I used doc.ready to the button creation, later in the process i will create a function that runs only when needed)
This is the nice part but it is also assuming that the whole page is one form. It was enough for me. I was looking for the lowest parent that is a parent of all fields so I actually used a function that I found on Stack overflow named .commonAncestor

$parent=$('.editable-field input[type="submit"][name="submit-"]').commonAncestor()

Then we need to append the button :

$parent.css('min-height','300px').append('<div id="editable-fields-global-save" class="button-shape"><a href="#klum">Save</a></div>');
//css it to the corner of the page
$('#editable-fields-global-save').css({
		'position' : 'absolute',
		'bottom': '0',
		'right': '0'
});

And to the click event. for regular fields - find all submit buttons that have a "to-save" (and change it to false); for images - find all changed fids (and change to the new fid); shoot clicks to all of them.

$('#editable-fields-global-save a').click(function(){
	//click on every item that needs to be saved
	// for input with tosave attribute
	$('.editable-field input[type="submit"][name="submit-"][tosave="true"]').click();
	$('.editable-field input[type="submit"][name="submit-"][tosave="true"]').attr('tosave','false');
	// for images
	$('.editable-field .field-type-image').each(function(){
		if($(this).next().find('input[type="submit"][name="submit-"]').attr('fid')!=$(this).find('input[type="hidden"][name*="fid"]').val()){
			$(this).next().find('input[type="submit"][name="submit-"]').attr('fid',$(this).find('input[type="hidden"][name*="fid"]').val());
			$(this).next().find('input[type="submit"][name="submit-"]').click();
		}
	});
});

That is it. It has to be improved, this is a beginning of an idea. my preference is to turn the whole thing to one ajax request and to have a bulk save on the php side.

attached is my js file (it has one more change involving the drop-down/enter problem)

Can you attach the JS file that you mentioned?

Or a patch?

If we take the following approaches in mind:

1. All fields in a row have autosave enabled. Ex. multiple select lists for taxonomy terms
2. A limited number of select fields in a row has auto-save enabled. Ex. taxonomy term is auto-save, title is not
3. None of the rows should auto-save, and there should be a save button for each row.
4. None of the rows should auto-save, and there should be a save button for the entire view/current page

How do we approach this?

1. This one may be easy to do - just allow each field to have a parameter - "auto save this field".
2. Similar to #1.
3. #3 and #4 would need a seperate section where we can change the save setting to be either "per row", "per view/page", "both". For the entire view, it sounds more like we'd need to generate a submit button for each row, and each of those would have to be submitted. Or maybe even each submit button per field would have to be submitted? That seems very wasteful though.

The problem is let's say there are 50 nodes in a view. How do we update them all properly via AJAX and not have things interrupted? Using a batch seems against the flow of things but I don't see another way. The idea that we are updating a large number of nodes at once is a batch after all.

A "global" save button would be great. A button per row maybe nice.
But I think a button for each field is to much...
As additional option use auto save is also fine.

What's the current status of this issue

I´m interested in a fix, anyone want to help?
@ymeiner can you post that patch/module that you talked about?

Thanks

nico

I'm trying to implement this behavior by building a Field Group (drupal.org/project/field_group) display widget called "Form". This means you can drag any number of fields into a field group on the display of a node (or any entity) and set that field group type to "form". You then get the standard form elements for each item and a submit button. I think it's a clean approach to this problem since you get to group similar fields where appropriate.

The page that contains the work-in-progress module is: http://drupal.org/node/1482876
although something that's blocking this from working with a stock copy of field_group is: http://drupal.org/node/1482958

I see a save button on the bottom of the page but it doesn't appear to work.

I can see the "Save" button at the bottom of the view too.

I've noticed that the button apears because of line

  // Set our form callback.
  $views_field->views_form_callback = 'editablefields_views_form';

And button is created in the file views.module. There is a check

  if (property_exists($field, 'views_form_callback')) {

but I didn't manage to hide it too

I've chosen this solution http://drupal.org/node/1245324#comment-5002336 temporary

subscribing

@auraell - Fyi. There is a "follow" button on the top of issues so you can click on that for ones you'd like to watch. Cheers!

Has anyone found a way to hide the "Save" button that appears at the bottom and doesn't really do anything other than redirect to the homepage?

I solved this problem by using css. You can hide the button just by using the node id which is unique for each page.

.page-user- .view-id-my_account #views-form-my-account-block #edit-actions--2 #edit-submit--2 {
display: none !important;

Thanks.

This worked for me:
#homebox-block-views_update_courses-block #edit-actions #edit-submit {
display: none !important;
}

Some of the other CSS I tried also hid the login button so I need to check that nothing else that shouldn't be hidden is being hidden...

my dears, i have problem with save button og editablefields.for some fields after i click save button i am redirected to front page.

edit field, save button
after click save, i'm redirected to front page.

i dont know why some editable field after click on save button redirect to home page and some field no redirected and work correctly.

have any idea?

use this module instead https://www.drupal.org/project/editableviews
+1 #28, i added a new view with same fields, same content, diferent url, modify view machine name, and added #28 clases with .view-machine-name

pinueve, if i use editableviews, every row resaves entity and makes a couple of rules executions in my case.

If someone has js file from comment #14, please, upload it. I'm trying to make it, but it doesn't work(

This is my attempt to reproduce the solution from comment #14

As a pretty hacky fix for the complex field issue (e.g., firing an ajax request on every checkbox change), I had some basic JS to handle updating when a users mouse leaves a field (in addition to hiding the save buttons, per #28):

Example:

var parentfield = document.getElementsByClassName("views-field-field-mcl-grade-taught");

for (i = 0; i < parentfield.length; i++) {
    parentfield[i].addEventListener('mouseleave', function() {
        this.firstElementChild.firstElementChild.firstElementChild.nextSibling.firstChild.click();
        console.log("button-clicked");
    });
}

Caveats:

1. Your setup will probably require different navigation from the selected view element to the save button
2. This will not play nice with concurrent editing - whereas out of the box, editablefields would produce minimal conflicts (because only if two people were editing the same field would this change), here, simply mousing over a field that someone else has added content to would clear it, if editing concurrently