Problems, need help? Have a tip or advice? Post it here.
29 posts Page 3 of 3
My suggestion is that we use the already implemented drafts feature

If I'm correct pages and drafts are saved by a javascript function in the couch core code, if so ... maybe by simple adding a setInterval function to those could solve this.
I load frameworks and write bugs on top of them, after that I rearrange the code so that it looks like a cool product.
OK, I've overlooked the already existing drafts functionality.
But the problem is that the user might already use the draft functions and there can be MANY drafts for one article.
If the autosave function just creates a yet another draft for an article, how would it then determine which draft should it fetch? Should autosaved drafts be invisible for the users?

About the existing drafts functionality ... as I understand this it is loaded on the active window that's how it's determine which draft should it fetch.

Should autosaved drafts be invisible for the users?

Yes, I think so it should be only a safety net for the user they can always check the drafts menu if something happens. The only drawback I can see is the user has to set the draft back to the original version.

But the problem is that the user might already use the draft functions and there can be MANY drafts for one article.

Are you sure one version can have many drafts ? I never tried this but it wouldn't be handy I think.
I load frameworks and write bugs on top of them, after that I rearrange the code so that it looks like a cool product.
Are you sure one version can have many drafts ? I never tried this but it wouldn't be handy I think.

I did try this you are right..

Anyhow this wouldn't be a problem I suppose when there is some workflow in place...... like:

1. create a draft from the page your working on
2. the draft window has the auto save function
3. update the original when ready editing.

This safety feature is then only available when working on a draft and not on the original version. So when the user knows this and work accordingly the problem would be solved.
I load frameworks and write bugs on top of them, after that I rearrange the code so that it looks like a cool product.
If I get to implementing it myself, which I'll do if KK and cheesypoof won't do it before me, I'll ignore the existing draft functionality and will use BOTH of my proposed solutions. Here's why:
1. MySQL solution is the most reliable and easy to implement for many autosaved articles.
2. localStorage solution will be a backup solution in case of internet connection error, expired session, database error and so on.
3. The Save button will NOT in any circumstance refresh the page. Refreshing is proved to be very unsafe. AJAX only. This will make it possible to notify the user if saving fails for any reason.

Back to original problem, my user agreed to prepare and save her work in MS Word beforehand and keep her drafts in .docx, so the problem is solved for us.
eklipse2009 wrote: The JavaScript warning thing was the first issue I've made sure is present in my Couch installation before even making the templates.


And why not add the javascript warning to the github repository?

The solution @cheesypoof wrote for this issue (viewtopic.php?p=12133#p12133) used jQuery to go with the new admin panel design, so it is incompatible with the current versions of Couch. The new admin panel has been delayed longer than anyone expected because it involved reworking quite a bit of the core code. viewtopic.php?p=16352#p16352

I tried, but I lacked the skills to be able to translate @cheesypoof's code to work with the current admin panel. As @potato pointed out, the majority of the Couch community, almost by design, is unable to get very far trying to modify or contribute to the core.

If you'd be willing to share the code you're using to warn users about unsaved data, it could be very helpful to the rest of us. I think it could be hacked into templates with the message-type editable region by designers unable or unwilling to modify the core files.

A javascript warning would catch most cases of accidental data loss, and give us time to develop a more robust system to prevent the less likely causes.

The "Tips and Tricks" section of the forum is probably the best place to share useful code for now. CouchCMS on github is only a few months old. I don't know if there's a place for this sort of thing there yet. Cheesypoof would know more about that.
I imagine 3 layers of protection.

1. Pop-up warning when surfing away from unsaved data. This already exists (but not for the current version), the code base is very light, and it can prevent the majority of accidental losses.

2. Autosave to database. This is constantly working in the background and provides robust protection even against catastrophic failures like power outages. If, as @eklipse2009 says, it's also easy to implement, so much the better. It does, however, add some clutter to the admin panel and new tables in the database.

3. Save to localStorage. I see this as a safety net in case something goes wrong while saving. If the save is successful, the localStorage can be purged. Otherwise, you have the opportunity to save the data again.

#1 and #3 together might be enough for a lightweight, unobtrusive system that protects data quietly without any attention from the user at all unless there's a problem.

The idea about not refreshing the page, but using AJAX to save data is very interesting. Page refreshes can be problematic. But it seems like a radical change. I wonder if it might require too big a change to the way Couch works to be practical in the short term while maintaining the stability of the application.
Hi everybody :)

Myself and @cheesypoof have been watching this thread with utmost interest.
Thank you all for the suggestions. They'll certainly be extremely helpful in addressing the data loss issue under discussion.

From what we see about the problem, broadly there are three reasons for it -

1. User related: e.g. close window, refresh, go back, fail to hit save button
2. CMS related: e.g. cookie expires, nonce expires
3. External factors: network fails, hard drive crashes, computer catches fire etc.

We feel, and maybe you'll agree, that reason 1 alone accounts for 90% of all data loss episodes.
A simple prompt warning the user about unsaved changes can rectify that completely.

Regarding reason nos. 2 and 3., as correctly suggested by many, only a combination of client-end local storage and a live (e.g. every 2 seconds) backup to the server can help.
Mind you, even these measures won't fully cater to reason 3.

Coming to the solutions -
For reason 1: This was actually already done in @cheesypoof's new admin design.
After this issue was raised, we got down to port the code to MooTools. @cheeypoof is currently reviewing it pending which we'll incorporate the fix in 1.4.5RC2 with immediate effect.

For reason 2 and 3: Implementing the discussed solutions won't be trivial and will take time and planning. It'll add to the already stretched queue of things under development for the upcoming version but it, nevertheless, needs to be done

So we have decided that, for now, we'll add the unsaved data prompt to 1.4.5RC2 (along with a few more accumulated changes) and promote it to be the main 1.4.5 Release version available for download from the official page. As is, it has plenty of improvements over the current 1.4 and it'd be a waste to keep it in wraps for this long.

The new version being developed will cater to the autosave etc. features.

Also, since the version under development has grown to be radically different from the current versions (in looks.. not working), we'll call it v2.0 (whenever it arrives).

Hope that'll put to rest the apprehensions of all involved in this thread :)
A quick and partial solution to auto-save page to server:
Code: Select all

      var form = $( 'form' );
      var method = form.attr('method').toLowerCase();      // "get" or "post"
      var action = form.attr('action');                    // url to submit to
      $[method](action, form.serialize(), function(data){
   // doing so every 10 seconds

Best placed in 'content_form.html' of your custom admin theme.

Pros: background saving, no effort required. Saves repeatable regions, text inputs, textarea, dropdowns.
Cons: script fails to cater to richtext/nicedit/checkbox fields.

I post this to up the thread and get more attention towards user experience..

My Documentation, Addons, Functions.
Join COUCH:TALK telegram channel
29 posts Page 3 of 3