Download the PHP package wwwision/neos-submissions without Composer

Form submissions for Neos

Neos package that stores submissions of Neos.Fusion.Form forms and provides a backend module to browse, search and export them

How it works

• Submissions are grouped into presets that are declared in Settings.yaml – for example one preset per form type ("Contact", "Event registration", ...)
• Every preset stores its submissions in a dedicated database table that is created and migrated via a CLI command
• The package ships a Fusion.Form action (Wwwision.Neos.Submissions:StoreSubmission) that persists the submitted form data as JSON
• Each submission gets a label (e.g. "Doe, John ([email protected])") and a form label (e.g. the title of the document containing the form) that are generated via configurable Eel expressions
• The backend module lists submissions per preset, allows to filter them by form and search term, shows the details of a single submission, exports the current selection as CSV file and allows to protect and delete submissions
• CLI commands allow to set up the storage, export submissions and re-generate labels

Usage

1. Install the package via composer:

2. Grant access to the backend module to the corresponding roles via Policy.yaml:

3. Declare a first preset via Settings.yaml:

4. Create the database table(s):

[!NOTE] The command is safe to run repeatedly (e.g. as part of every deployment): it only creates missing tables, columns and indexes

5. Add the StoreSubmission action to your Fusion form:

6. Navigate to the new backend module

Log in as Neos administrator and navigate to the new "Submissions" module underneath the "Administration" main module, or head straight to /neos/administration/submissions

The StoreSubmission action

The action stores the submitted data and supports the following options:

• preset – id of the preset to store the submission in (required)
• formId – string identifying the form the submission belongs to (required). Using the identifier of the node containing the form allows the default form label expression to resolve the form's title. Any other string of up to 255 characters works as well, though
• data – the submitted form data, usually ${data} (required)

The action can be combined with any other Fusion.Form action (e.g. Neos.Fusion.Form.Runtime:Email to send a notification, Neos.Fusion.Form.Runtime:Message to render a confirmation, ...).

[!NOTE] The data is stored as JSON, so nested values (e.g. from Neos.Fusion.Form:FieldContainer with a field.name like contact[emailAddress]) are preserved and rendered as nested lists in the backend module and as contact.emailAddress columns in the CSV export

Declaring presets

Presets are declared underneath the Wwwision.Neos.Submissions.presets setting:

Every preset supports the following settings:

• title – label displayed in the backend module (defaults to the preset id)
• submissionLabel – configuration of the submission label generator
• formLabel – configuration of the form label generator
• options.tableName – name of the database table (defaults to wwwision_neos_submissions_<presetId>)

A preset can be disabled by setting it to ~ (null).

Submission labels

The submission label is displayed in the list and detail views of the backend module and is exported as label column in the CSV file. By default, it is generated from an Eel expression that has access to the following context variables:

• submissionId – the unique id of the submission
• data – the submitted form data (as array)

The default expression is ${submissionId}.

Form labels

The form label is displayed in the form filter of the backend module and in the detail view of a submission. By default, it is generated from an Eel expression that has access to the following context variables:

• formId – the id that was passed to the StoreSubmission action
• preset – the corresponding Preset instance
• site – the current site node (in the live workspace)

The default expression is ${q(site).find("#" + formId).get(0).label}, i.e. it assumes the formId to be the identifier of a node.

[!NOTE] Labels must never prevent a submission from being stored: if an expression fails or yields an empty result (e.g. because the corresponding node has been deleted), the label falls back to the submission or form id respectively. Labels are generated when a submission is stored, use the regeneratelabels command to update the labels of existing submissions after adjusting the expressions

Custom label generators

For cases that can't be expressed via Eel, custom label generators can be provided by implementing the SubmissionLabelGeneratorFactory and/or FormLabelGeneratorFactory interfaces:

The factory is referenced via the factory setting of the corresponding preset; its options are passed to the create() method:

Backend module

The "Submissions" module underneath the "Administration" main module provides:

• A preset switch (only shown if more than one preset is declared)
• A form filter to narrow down the list to submissions of a single form (only enabled if submissions for more than one form exist)
• A search that matches the submission label as well as the raw submitted data
• A paginated list of submissions with label and creation date
• A detail view rendering the submitted data (including nested values, dates and booleans)
• A CSV download of all submissions matching the current filter
• Protection of single submissions (lock icon in the list and detail view). Protected submissions are highlighted in the list and can't be deleted
• Deletion of a single (unprotected) submission in the detail view and of all unprotected submissions matching the current filter in the list view (after confirmation)

[!NOTE] Submissions are never removed from the database by the module. "Deleting" a submission sets its archivedAt timestamp instead – archived submissions are excluded from the module, the CSV export and the CLI commands

The CSV export contains the fixed columns id, formId, presetId, label, createdAt, archivedAt and protected followed by one column per (flattened) form field. Submitted form fields that happen to have the same name as a fixed column are exported with a data. prefix.

[!NOTE] Submitted data is user input. The backend module escapes all values and the CSV export neutralizes cells that spreadsheet applications would otherwise interpret as formulas

CLI commands

Storing submissions programmatically

The FormSubmissionServiceFactory can be injected in order to interact with submissions from PHP, for example to import submissions from another source:

The same service provides handleArchiveSubmission(), handleArchiveUnprotectedSubmissions(), handleProtectSubmission() and handleUnprotectSubmission() to change submissions as well as findSubmissions(), getSubmission() and findForms() to read data (archived submissions are excluded).

Storage

Submissions are stored via Doctrine DBAL in one table per preset, using the default Flow database connection. MySQL/MariaDB, PostgreSQL and SQLite are supported.

A different storage can be provided by implementing the ForStoringSubmissions port and a corresponding ForStoringSubmissionsFactory, and wiring it to the FormSubmissionServiceFactory via Objects.yaml.

Contribution

Contributions in the form of issues or pull requests are highly appreciated.

License

See LICENSE