Read-only fields for Forms

[stuartcusackie]

I'm just wondering how I would add an editable introduction field to a form, e.g. "Please answers all these questions and someone will be in touch...". My forms are utilised in modals, so they're not attached to an entry where I can define content fields. The only option I seem to have at the moment is to hard code the introductions in my template files.

If a simple wyiswyg field was available for each form then that would solve it, or for more flexibility - the ability to assign a content field blueprint, as well as the existing fillable fields blueprint per form.

UPDATE: I've run into more problems that could be solved with additional blueprints. See my latest comment.

[simonhamp]

Why not create a Collection for your forms, with each Entry representing a Form. In that you have 2 fields: intro and form.

The intro field lets you do what you're asking here, and the form field references your available forms, so you can select one from the list.

Then in your modal template, instead of loading the form directly, you load it via the relevant Entry, through which you will have access to intro?

It's a bit more work, but it's way more flexible - you could add more fields later if you need to, it could be localizable etc etc

[stuartcusackie]

I was trying to avoid that approach because I worry that the administrator wont get it (i.e. create form > create form entry > add form to form entry), but I guess I could try and label things clearly to help them along.

Thanks for the advice!

[stuartcusackie]

I've run into more problems that could be solved by additional blueprints per form. Imagine this scenario:

I have a form that, on submission, I would like to send some data to an API. I also have other forms that I don't want to send to the API.

In order to achieve this I added the Form to a custom collection called 'Form Containers', and within each entry I have fields that determine if the form should be sent to the API and which API list to use. This gives the marketing admin the ability to send selected data to the API themselves.

Achieving this seems overly complicated with the current set up. Yes I can listen to Statamic's form submitted events and send all data to the API, but how do I get my 'Form Container' and its API settings for the form when these events fire? It's easy to get the form when I have the form container entry, but there's no easy way to find the form container entry when you just have the form provided by the event. My solution is a complex once using custom Livewire forms and custom events.

This would have been much easier if forms could have secondary blueprints, and my original point about it being more intuitive for the marketing admin still stands - At the moment I'm trying to explain to the marketing admins the difference between Statamic Forms and my Form Containers.

[jackmcdade]

Do you mean Blueprints or fields? It seems like you could have a read-only field that you could set (or similar) that would solve this?

[stuartcusackie]

My 'Form Container' Entry has these fields:

• Send to API (toggle)
• API List ID (text)
• Fields to exclude (list)

The form itself is passed along with the Statamic\Events\FormSubmitted event so it's easy to access form fields, but these additional Form Container fields are difficult to retrieve.

I guess I could have three hidden fields but that wouldn't be as nice as being able to use toggle and list fields, or a select field if I needed one.

[jackmcdade]

I'm really confused, honestly. Can you record a quick video of how it all works together?

[stuartcusackie]

Haha. I'm sorry. It's just a crazy idea I had.

Here's a temporary video link on a service I've never used: https://file.re/2021/07/28/2021-07-28-20-58-45/ Red link down the bottom. Automatically gets deleted tomorrow.

[jackmcdade]

Downloaded it so I won't lose it – will review tomorrow!

[stuartcusackie]

Thanks! I hope its not too silly an idea, and I have a solution so no big deal.

Another way to explain, I am allowing my content editors to create forms and fields, but I want them to use my custom settings on each form they create. My form container collection solves this but it would be easier if these settings were directly on the form. I also need to grab the form settings after it is submitted on the front end via the form submitted event.

[jackmcdade]

I got it now! If we let you add a section tab and had access to all the fieldtypes, that should solve what you're looking to do. I like this idea. 👍

[stuartcusackie]

That sounds like it will do the job. Section Tabs similar to the other blueprints, one for the front end fields, one for my form settings. As long as I can grab fields by sections and determine which is which (wouldn't want my settings fields show to the front-end user).

Finally I've had a good idea. ☺️

[stuartcusackie]

Oh yeah, one more thing. It would be ideal if the permissions could be split up as well. At the moment I have to grant the full 'Edit blueprints' permission to my marketers, which unfortunately opens up my complicated blueprint configuration to them, when all I really want is to let them create form questions for visitors.

So maybe there could be a 'Form Fields' permission that's separate from the general blueprints, or something like that? This would also solve this other idea .

[jasonvarga]

What if you had a forms collection that could be used for storing this extra content, and then you have the actual form itself.

Give the content editors permission to edit the collection, but not permission to edit the form.

[jackmcdade]

That's what he's doing now and it's confusing for the editors.

[stuartcusackie]

That's what he's doing now and it's confusing for the editors.

And not just that. It's majorly complicated to get the form collection entry data back after a form has been submitted.

[stuartcusackie]

Sorry guys, another caveat popped into my head. I'm not sure if 'read-only' fields will solve this, but then again, I'm not so sure what you mean by 'read-only'.

In my head a form is a special type of collection with a front-end blueprint rather than an back-end blueprint, if you get my drift. What I want is to have standard back-end settings for each form. For example, I could have a send_data_to_klaviyo toggle in my form settings blueprint. This should be visible when the editor is creating a new form. I shouldn't have to add it to each form afterwards.

My current workaround is to create a 'form_container' collection and add each form to an entry in this collection. It works fine but it seems unintuitive. Additionally, it's very difficult to determine the corresponding form_container on the FormSubmitted event. The event provides the form but you can't get the form_container entry from that. I am listening for this event and then handling the form's settings, e.g. should I send the submitted data to Klaviyo or not?

One solution would be that a form could have two blueprints (I don't know if that's possible):

Front-end blueprint (Visitor submission fields, e.g. first_name):

• This the way form blueprints currently work.
• Unique to each form.
• I'd like editors to be able to create these.
• New permission to allow creation of front-end form blueprints. This way editors can create forms, but they can't mess up the other collection blueprints.

Back-end blueprint (Adming settings fields, e.g. send_data_to_klaviyo):

• New feature but very similar to the way collection blueprints currently work.
• Standard across all forms, just like a collection blueprint would be standard across all entries.
• Only super admins will be setting these up. No extra permission needed.

[jasonvarga]

That's what he's doing now and it's confusing for the editors.

Oops sorry, skimmed this too quickly.

[stuartcusackie]

I'm still convinced that a separate form controls blueprint and a fields blueprint would be cool. I could use them to allow my admins to have more control over the forms that they build:

• create their own forms and fields (need a new permission here for form blueprints)
• edit success messages
• customise the form email text
• choose from a select field of various actions to be performed after submission
• view additional data for the submission (e.g. what entry this form was submitted through, e.g. the job entry for a specific application)

Something like this could give a sort of Gravity Forms flexibility to the system. At the moment form building is not possible for my content managers, you have to give them full blueprint permission, so only super-users / developers can build anything useful.

Here's the solution I'm going with at the moment. I would much prefer if everything was under 'Forms':