HOW TO - Create a Squarespace Website for Simple and Free Reporting

Hi all,

I'm struggling here. I am an enthusiastic Squarespace (SS) professional user. As a creative agency we like the flexibility of the SS platform, the user friendly CMS and the customisations through CSS / Javascript. Please help, I'll try to describe things as structured as possible.

SITUATION / OBJECTIVES

I created a simple SS website (spooroverlast.nl, it's in Dutch) to allow people in my neighbourhood to make an online report anytime a train passes by (we live very close to a very busy train track) that involves a lot of sound- or vibration disturbance (that might damage our homes). As we plan to have 4 week long reporting campaigns, we want to make 'making a report' as simple as possible. The site worked somewhat and had a straight forward setup:

• home page, info
• newsletter page, signup
• reporting page:
  • 3 'one-click report buttons' (SS collapsable forms) "JUST NOW, HERE"
    • pre-filled and hidden form field "severity" = 1  (2 and 3)
    • pre-filled and hidden form field 'IP_address' = <stored value derived from browser through Javascript>
    • connected to Google Sheet (resulting in Timestamp + Severity + IP address)
  • 1 custom report form "SOME MOMENT, SOMEWHERE"
    • date
    • time
    • severity (1,2,3)
    • any remarks (text)
    • pre-filled and hidden form field 'IP_address' = <stored value derived from browser through Javascript>
• this allowed for a resulting Google Sheet that gave us an indication of the real address through the IP address (al be it too rough, because it really is a neighbourhood problem, stretching along the railroad for app 10km). but still. It worked.

Than, in May 2023, SS changed its coding of forms and the code broke. Not allowing to pre-fill form fields any longer. I searched for help on SS Forum, but to no avail. See below.

QUESTION / SOLUTION

Does someone know how to get this code working again? Then again: as I realise that the IP address is a poor proxy for a real address getting my prior working code back to work... maybe is not the greatest solution (although it will help and has advantages cross device). Realise that most people who will do the reporting will be subscribing to the newsletter or do some reporting onboarding or whatever in which case they will voluntarily provide their real addresses. In which case it only become a matter of connecting this 'reporter' to every of his 'reportings'. Seems like such a simple problem. I can think of 2 solutions:

• SIMPLEST: one first report, ask for address, store the address in a long living client side cookie (of course after asking for permission etc), then on all new reports, look for cookie, prefill address in report form and allow for 1-click reporting WITH address
• ALTERNATIVE: create a membership area (behind login) and situate the 1-click reporting buttons there. I have no experience with getting data in/out membership area's allowing for the same simple results somewhere (in a Google Sheet or comparable) gathering the data:
  • time
  • date
  • severity of disturbance
  • address

I would so much appreciate some help with this – probably – shamefully simple problem. I which case I do apologise to the readers for my lengthy Post. Thnx so much in advance!

Stefan
Amsterdam Area
(the Netherlands)

Try Settings > Circle Labs > Enable this option

Hi @tuanphan, your option to opt-out of the (new) localized forms is working! It has brought back the functionality that disappeared in May this year. Thnx so much! It's a start.

My big follow-up question would be as I mentioned in my post (see below)... how to not even have to use the IP address, but instead just do a read/write cookie to store the address or a unique 4digit userID that connects to their userID in the mailinglist/Google Sheet world. This would be more elegant and a true connection to a real address instead of a poor IP proxy.

Thanks so much in advance!

Stefan

On 8/22/2023 at 2:12 PM, ZZESTO said:

Then again: as I realise that the IP address is a poor proxy for a real address getting my prior working code back to work... maybe is not the greatest solution (although it will help and has advantages cross device). Realise that most people who will do the reporting will be subscribing to the newsletter or do some reporting onboarding or whatever in which case they will voluntarily provide their real addresses. In which case it only become a matter of connecting this 'reporter' to every of his 'reportings'. Seems like such a simple problem. I can think of 2 solutions:

• SIMPLEST: one first report, ask for address, store the address in a long living client side cookie (of course after asking for permission etc), then on all new reports, look for cookie, prefill address in report form and allow for 1-click reporting WITH address

SS forms use the autocomplete attribute to auto fill some fields.

It might be easier to go that route than coding your own.

Hi Thomas @creedon, thanks for this option. I can see it working in the custom form... does it use its own cookies on the bacground to populate the autocomplete functionality? Because much of the reports are made, waking up from vibrations, reaching to your phone and clicking the 'app' link to the website the ease of keeping the  1-click-report button,

1 moderate nuisance
2 serious nuisance
3 very serious nuisance

seems important to me. The fourth report (scroll down) could totally have the autopopulation feature, but I don't see it kick in. Is it only triggered by drop down select buttons? Have a look at the site as I now prepared it.

 https://spooroverlast-nl.translate.goog/melden?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=nl&_x_tr_pto=wapp

Thanks to you and @tuanphan both, for your never waning responsiveness. Much appreciated!

Stefan

On 8/27/2023 at 12:38 AM, ZZESTO said:

use its own cookies on the bacground to populate the autocomplete functionality?

It doesn't use cookies. Each browser has its own storage method and settings. You may have to educate your form users a bit on the autocomplete features of their browsers.

HTML attribute: autocomplete

This doesn't handle all field types or make a one click situation. It's just a potential way to speed things up.

The autocomplete feature is under the control of the user so if they've turned it off it won't work.

Also the autocomplete won't work until the user has entered info at least once.

I don't have any easy answers.

9 hours ago, creedon said:

I don't have any easy answers.

Thnx Thomas. I understand, I do use the autocomplete function myself as I have it populated by 1Password. What makes why you seem to advise away from using something simple (I'd say) as just checking for a browser Cookie and if not finding it writing and storing it?
 

Quote

why you seem to advise away from using something simple (I'd say) as just checking for a browser Cookie and if not finding it writing and storing it?

I try to use existing functionality when possible so as not to reinvent the wheel, if it makes sense in the context of the project.

Working with Squarespace's latest forms can be a major pain and a lot more work than it used to be. Some tasks currently seem impossible with the new internationalized forms. It all depends on the needs of the project.

I would use LocalStorage instead of using cookies. It is easier to work with. If you do end up rolling your own.

There isn't an issue using cookies or LocalStorage functionality itself. It is getting that info into SS forms that can be problematic with SS's new internationalized forms. There are several threads covering some of the pain points of the new forms. I don't have any specific pointers to them.