Personally I am really enjoying the drupal/autosave_form in localgov_microsites. It is a neat and unobtrusive way to avoid losing content changes. It has also been used in Thunder for a while.

Just had a look at installing drupal/autosave_form again. I noticed that there's a time setting before autosaving, which defaults to 60 seconds - this is quite long.

If implementing this, we probably want to reduce this, though I guess it might have some performance implications.

I think it makes sense to add this to LGD core, probably with a timeout of 20 seconds or something.

I agree we should add it to LGD core, it's pretty neat.

One consideration is that it can get a bit annoying if you don't want to continue editing a draft, or if you are not sure. Say you've visited a node edit form for a bit, made some random or accidental changes, left without saving, then come back some time later. I wonder if reducing the default time to 20 seconds would increase this?

@msayoung I think that in the LocalGov Microsites building and testing, the autosave form got annoying at times. Can you recall if we had any specific feecback from test users and would that suggest a shorter or longer default time?

@finnlewis when I've played around with this (admittedly not for very long) I get a message when I return to a page asking whether I want to continue with the autosaved draft, or to discard changes.

Personally I was thinking of a shorter autosave time, maybe 5 seconds or less. We're migrating from another CMS and our content designers are accustomed to what's perceived as 'instant' autosaving, similar to e.g. Google Docs, Word.

Would love to hear about any user feedback on this though @msayoung as we haven't tried this at all yet and so I'm in the dangerous land of assumptions!

Does autosaving make any Drupal requests.
An issue we are encountering at BHCC is Acquia counts any hit to the PHP application against our 'views' quota, which is starting to have an impact with ajax requests and can lead to cost implications.
So we need a way of turning this off, or opting into it only.

@andybroomfield autosave will certainly be making hits and that is interesting to know about Acquia's quotas and charging model.

One thing to remember is that the distribution / install profile is a starting point meant for further customisation. If a module like autosave_form is installed and configured by default, it is simple enough to uninstall it or reconfigure it for your specific use case. So these sort of decisions about things to inlude in the distribution do not imply that all users need to use it. To turn it off you would just uninstall the module.

@benhillsjones - out of interest, is the autosave_form functionality something that you think other council content designers want?

This functionality request has triggered a discussion around the question:

"What is the policy for adding modules to default install LocalGov eg. autosave"

See #485 (comment)

So just gathering interest on this specific feature while drafting a policy.

Possible alternative:

• Auto Save Form (but different module) Uses browser local storage, and supports all forms so could also be useful for webforms.
• Save Form State Is another local storage option. Uses jQuery Sisyphus

This issue has highlighted the question of how we decide what features to add and enable by default in the distribution.

I've started drafting a policy here:
https://github.com/localgovdrupal/localgov/wiki/%5BDraft%5D-Policy-for-adding-a-new-feature,-functionality-or-modules-to-LocalGov-Drupal

It would be good to answer the questions raised so far on this issue:

1. Does more than one council want this feature? / Does a significant proportion of our users want this feature?
2. Can the feature be disabled after installation without any dependency problems?
3. Does the product group / product owner / product lead want to prioritise this feature?
4. Will this enhancement be communicated to users with an existing installation? (e.g. release notes / README.md / drupal_set_message )

Let's take them one by one.

1. Does more than one council want this feature? / Does a significant proportion of our users want this feature?

We know that at @keelanfh (Essex) is keen on this feature, so are there other councils that also want or already use autosave? @benhillsjones @willguv @Boosmith @

2. Can the feature be disabled after installation without any dependency problems?

Yes, I've tested this and after installing the profile with this module being enabled, I can uninstall the autosave_form module without any problems.

3. Does the product group / product owner / product lead want to prioritise this feature?

@willguv can we make some time to discuss this from the product perspective?

4. Will this enhancement be communicated to users with an existing installation?

I think release notes should suffice for this, but happy to look at some other messaging with update hooks or similar if others feel strongly.

Thanks for kicking off this wider discussion @finnlewis . With conversations about the Roadmap Group, I’ve been thinking about it too. Set aside time this week?

Its probably best we separate the discussion of how modules get added to the distribution onto its own ticket so the discussion on autosave functionality does not get lost.

Assuming there is a want for autosaving, I still think we should consider the other modules, especially as the most useful part is having autosave whilst writing a new page which the module here does not do without a patch. Also there are merits around saving it locally and not doing round trips to server (network issues, offline editing).
The clincher will be which one is better at handling autosaves from paragraphs.

Thanks @andybroomfield.

I think the questions above are directly related to adding the autosave functionality to the localgov install profile, so hoping to get more input this week from other councils and the product group and either build momentum for including this in the profile or look at adding it as an optional feature in some way.

I've not tried any of the other modules you suggest, but on first glance autosave_form has significantly more usage and is covered by the security advisory policy.

I've created a spearate issue (#488) for discussing the general question of adding features to LocalGov Drupal and look forward to discussing that more this week.

Thanks @andybroomfield, clearly a few things to think about here. One disadvantage of local storage could be that if someone uses multiple browsers/devices to edit content, autosave wouldn't carry across them. I have no idea if this is a common use case or not.

I am very much anchored by the functionality in our old CMS (which essentially just creates a new draft revision automatically - which is then visible to other CMS users as well). So I am maybe not the best at uncovering underlying needs here.

Having tested autosave_form and the modules I discovered above, I'm not able to get this working with paragraphs.
I assume it must do with microsites, but I can't see any patches added to localgov_microsites.

There looks like quite a few core patches and patches to the module needed to get it to a workable state

The module works out of the box for normal content entity forms, but if you have nested entity reference inline forms then you would require entity deep serialization. For that please take a look at the following Drupal Core issues
#2824097: Deep serialization for content entities to make an exact snapshot of an entity object's structure based on its current state
and
#2844229: [PP-1] Serializing content entity form objects should deeply serialize the entity in case of nested/inline entity forms.

I'd have concerns about adding a lot of patches to support an optional feature, more like something we should suggest if others wanted to give it a try.

It sounds like we should spec out a feature set first for autosave, before deciding on a module to incorportate.

@keelanfh The reason for offline storage (aside from not using up our Acquia hit quota) is that it works when the netwrok is offline, so can recover from a page refresh. Typically users would edit on one device and currently even autosave_form won't support transfering the edit to other users.

Lizzie and David say this would be AMAZING!

Other CDs would prefer this to be configurable on a council by council basis. Sometimes you may want to have a play with the page and not save changes

Keelan: has installed on LGD, throws up errors relatively frequently. Past CMS had it, Google docs and others have it - general expectation?

Andy: Has to reduce frequency of browser requests. Happy if:

• can opt in
• divert to local browser storage (needs exploration)
• option enabled to only save if there's a change

Module only works on pages that have already been saved once, relies on content ID. Showstopper

Keelan: how to deal with mandatory fields?

Stephen: set to save every minute on microsites, not excessive. Other options above mitigate server load. Might cause havoc with autosave

Possible showstopper: only saves content for the user, not saved into workflow. If author doesn't hit "save" when they leave, other content designers don't see the latest version

We also set to save every minute.

Here's a common error that we get with autosave_form:

That's a mouthful! Thanks for the screenshot.

And another one:

Content group 23 May could be very handy if tested with block concurrent editing

@stephen-cox please install on test

@andybroomfield need to consider requests on server - either override timer, opt in or only save when changes are made

@stephen-cox - just tested again on the demo microsite. The autosave does occur every minute. Worked fine with text I added a body field on an event page. But when I tried to add content to a text paragraph on a service page it didn't save.

@willguv I have deployed the Autosave Form to the test site with default settings: https://test.localgovdrupal.org

Posting thoughts here as I go

1. Before first save, there's no warning if I click away from the page. This might not be an issue

2. Have saved page and added content. Wasn't sure autosave was working until I saw this later

Should we give some indication that pages are being autosaved to reassure editors? (Just saw "Saving" back box bottom right, not very clear, also not very frequent on test site)

3. Message needs work

4. Haven't noticed any conflicts with content lock so far. What were we expecting?

Two councils on the call use paragraphs heavily, so wouldn't be able to use this. Are there any other modules (or bespoke work) that would take this into account @stephen-cox

We should write "how to" doc so councils have this as a option

Our accessibility audit picked up a WCAG non-compliance with autosave_form, which I've raised in its repository with a fix:
https://www.drupal.org/project/autosave_form/issues/3368261

BLOCKED as this module does not support autosaving of paragraphs content - further discussion needed