October CMS and Auto Save (autosave)

[ghost]

Been using October CMS for many years, but one thing in the back of my mind is autosave. All professional systems should have an autosave feature!

Is there a way or does October CMS already have this feature?

I would like to see autosave on all form widget fields (not list).

For example some screenshots I was thinking in my mind:

Autosave

Normal Save

This has been something I have been thinking about ever since I talked to Luke about the annoying save spinner in October CMS backend.

Before Luke says "Create a PR for it", I would like to say this would most likely be beyond my scope of knowledge and not so straight forward.

I think all form fields need to have it, I also think repeater fields would need to have it and other conditional fields inside the form field. So not so straight forward.

From talking to people they say, jquery ajax is the way to go for it and two example libararies are:

https://github.com/geniuscarrier/autoSave

https://github.com/nervetattoo/jquery-autosave

Please note they both seem very old and use jQuery V1 which worries me for security loop holes.

Anyway, I will raise this to the October CMS team because I think if you want to make October CMS a professional product - it should have an autosave feature as standard.

[LukeTowers]

Before Luke says "Create a PR for it", I would like to say this would most likely be beyond my scope of knowledge and not so straight forward.

😂

How do you envision this working though? Auto save could be implemented many different ways with greatly varying definitions of "auto save". Are you talking about storing field values in the client's localStorage? Are you talking about periodically saving partially incomplete records in the DB? There's a lot that goes into even just defining what the functionality is before you can even think about how to implement it.

[ghost]

Totally agree with you! Your questions about localstorage and periodically saving to the db - I was also thinking about? I would say a balance of funcationality and security, that covers most user cases.

I leave this open up to discussion and further ideas, as it not so straight forward to add, but would be a welcomed feature I believe.

[amdad]

Cool feature, but more important than auto save at this moment, is to make sure 2 (or more) admins do not save the same record over on each other. When edit same record at the same time.

[ghost]

Here's some initial goals:

• User doesn't lose their input data due to bad internet and need to start again to fill out the form
• Reduction of having to click on the save button to update the form fields
• Bypass method when the plugin is in development mode
• Logic to prevent or notify multiple admin users editing the same record at the same time

[w20k]

How I see, it should be done, and not that hard, because if we go straight to saving either to local storage or DB directly, the most problematic part would be - 'Data Validation'. Pain in di butt!

What I would suggest to have instead - Revision table for 'BackendForms'. Where data isn't validated, but stored directly to DB + local storage for cache (I guess for performance ;) ). Revision could have a field values, but the model is still empty :) Initial version, and still needs thinking, but that what I would do. If OctoberCMS would be a PURE flat file system, that would be much more easier :D

[LukeTowers]

Note that I don't want this to be something that is enabled for everything by default, I'd rather have this provided as a feature that developers can enable as desired, or perhaps as a plugin.

[osmanzeki]

Tell me if I'm a bit too off-topic here but would having a Revisioning system built-in enable these kind of features automatically? Meaning that the autosave would create a "Revision" (that keeps on getting updated for the time that the edit is being done) that could be then eventually be "applied" or "unapplied" (on save, on revert).

This could potentially also solve the problem of users editing an entry concurrently (concurrent saves would create a revision each) as mentioned by @amdad. Detecting that another user is editing the view and showing an alert is also nice outside of this specific approach (like what is available in WordPress for example).

I know that there is already a trait to implement some lightweight revisioning (diffs) but I'm not sure how what is currently in place (db tables, traits, etc) could be leveraged or if is scalable to the entire OctoberCMS system. What do you guys think?

[LukeTowers]

@osmanzeki that's an interesting thought. I don't think we want to get too deep into the weeds with concurrent editing however, see https://ckeditor.com/blog/Lessons-learned-from-creating-a-rich-text-editor-with-real-time-collaboration/ for how complex that can get.

[osmanzeki]

Oh god no hahah I wasn't thinking about anything like that. Reimplementing Google Docs-like collab is no small task. I've programmed multiplayer games in the past so all kinds of horrible things happen when you do get into realtime and networking. Especially with lag, packet loss, etc, etc. :)

My idea was simpler than that, if you're a cms user and you route into a FormController for a given model, then an insertion could be made in the db somewhere that keeps track of who's editing what. Could be a polymorphic relation too (user morphMany lockableModels or something like that). I suspect we would need a new table, I'm not sure if something like this exists already.

My vision is very similar to the WordPress Post Locking feature. That feature is an autosave of sort too.

https://codex.wordpress.org/Post_Locking

[munxar]

@osmanzeki there is already a logging feature that keeps track of every change you do in file and displays a nice diff. to enable it: backend / settings / Log Settings / Log theme Changes (enabled) In theory this could be extended to revert back and forth to any version of a file (like git). At least for the CMS or StaticPage part. After having such a feature, it's

a) safe to save at any time because we just append changes to the log (undo is easy) b) concurrent saves could be just appended too, the user that last saves gets notified and even a merge could be implemented c) deleting files is a log entry too, so could be reverted.

@ayumihamsaki imho auto save without a nondestructive undo chain is very very dangerous. right now the ctrl-s feature of october is a killer feature that most clients love and if they work on different cms like wordpress will miss.

[ghost]

I really like @munxar idea of a git style, allowing a type of archive system, so you can go back and forth. This idea creates an extra layer to the system where future features could be built on top of it.

[seanthepottingshed]

Would this be able to tied in with the current Revisionable trait somehow?

[munxar]

@ayumihamsaki i think it's already implemented. we only need a control in the pages section that displays the data from the cms_theme_logs table.

[seanthepottingshed]

Ignore me, I've just noticed @osmanzeki comment above! ( https://github.com/octobercms/october/issues/3863#issuecomment-430876383 )

[Denoder]

Hmm to use the theme log for the cms pages, i believe the pages must use a unique identifier for each page so that when accessing the theme log it knows what page template it's associated with (the cms is not tied to the database)

[munxar]

@Teranode let's look at the db schema of the cms_theme_log:

CREATE TABLE `cms_theme_logs` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `type` varchar(20) COLLATE utf8mb4_unicode_ci NOT NULL,
  `theme` varchar(191) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
  `template` varchar(191) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
  `old_template` varchar(191) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
  `content` longtext COLLATE utf8mb4_unicode_ci,
  `old_content` longtext COLLATE utf8mb4_unicode_ci,
  `user_id` int(11) DEFAULT NULL,
  `created_at` timestamp NULL DEFAULT NULL,
  `updated_at` timestamp NULL DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `cms_theme_logs_type_index` (`type`),
  KEY `cms_theme_logs_theme_index` (`theme`),
  KEY `cms_theme_logs_user_id_index` (`user_id`)
) ENGINE=InnoDB AUTO_INCREMENT=18 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

the theme holds the name of the used theme identifier (which is unique), where the template holds the name of the used file which is unique in the theme too. imho each change can be traced in a unique way.

[LarryBarker]

I've been wondering about the Revisionable trait in the Rain library as well. AFAIK, there are no implementations of it thus far. Does anyone have any idea how to use it?

[github-actions[bot]]

This issue will be closed and archived in 3 days, as there has been no activity in the last 30 days. If this issue is still relevant or you would like to see action on it, please respond and we will get the ball rolling.

[github-actions[bot]]

This issue will be closed and archived in 3 days, as there has been no activity in the last 30 days. If this issue is still relevant or you would like to see action on it, please respond and we will get the ball rolling.