eliashaeussler / typo3-form-consent
Extension for TYPO3 CMS that adds double opt-in functionality to EXT:form
Installs: 9 125
Dependents: 0
Suggesters: 0
Security: 0
Stars: 7
Watchers: 1
Forks: 2
Open Issues: 5
Type:typo3-cms-extension
Requires
- php: >= 7.4 < 8.2
- ext-json: *
- doctrine/dbal: ^2.13 || ^3.0
- psr/event-dispatcher: ^1.0
- psr/http-factory: ^1.0
- psr/http-message: ^1.0
- psr/log: ^1.0 || ^2.0 || ^3.0
- symfony/console: ^4.4.30 || ^5.3.7 || ^6.0
- symfony/dependency-injection: ^4.4.30 || ^5.3.7 || ^6.0
- symfony/expression-language: ^4.4.30 || ^5.3.7 || ^6.0
- symfony/mailer: ^4.4.30 || ^5.3.7 || ^6.0
- symfony/mime: ^4.4.30 || ^5.3.7 || ^6.0
- symfony/polyfill-php80: ^1.24
- typo3/cms-backend: ~10.4.11 || ~11.5.1
- typo3/cms-core: ~10.4.11 || ~11.5.1
- typo3/cms-extbase: ~10.4.11 || ~11.5.1
- typo3/cms-fluid: ~10.4.11 || ~11.5.1
- typo3/cms-form: ~10.4.11 || ~11.5.1
- typo3/cms-frontend: ~10.4.11 || ~11.5.1
- typo3/cms-install: ~10.4.11 || ~11.5.1
Requires (Dev)
- armin/editorconfig-cli: ^1.5
- captainhook/plugin-composer: ^5.3
- codeception/c3: ^2.6
- codeception/codeception: ^4.1.11
- codeception/module-asserts: ^2.0
- codeception/module-db: ^2.0
- codeception/module-webdriver: ^2.0
- ergebnis/composer-normalize: ^2.15
- helhum/config-loader: ^0.12.5
- helhum/typo3-console: ^6.6 || ^7.0.5
- helmich/typo3-typoscript-lint: ^2.5
- jangregor/phpstan-prophecy: ^1.0
- nikic/php-parser: ^4.12
- oqq/codeception-email-mailhog: ^2.1
- phpspec/prophecy-phpunit: ^2.0
- phpstan/phpstan: ^1.2
- phpstan/phpstan-phpunit: ^1.0
- phpunit/phpcov: ^8.2
- phpunit/phpunit: ^9.3
- saschaegerer/phpstan-typo3: ^1.0
- ssch/typo3-rector: ^1.0@dev
- symfony/process: ^4.4.30 || ^5.3.7 || ^6.0
- typo3/cms-dashboard: ~10.4.11 || ~11.5.1
- typo3/cms-filelist: ~10.4.11 || ~11.5.1
- typo3/cms-fluid-styled-content: ~10.4.11 || ~11.5.1
- typo3/cms-lowlevel: ~10.4.11 || ~11.5.1
- typo3/cms-scheduler: ~10.4.11 || ~11.5.1
- typo3/cms-tstemplate: ~10.4.11 || ~11.5.1
- typo3/coding-standards: ^0.5.0
- typo3/testing-framework: ^6.14
Suggests
- typo3/cms-dashboard: Adds a custom form consent widget to the TYPO3 dashboard (~10.4.11 || ~11.5.1)
- typo3/cms-scheduler: Allows garbage collection of expired consents (~10.4.11 || ~11.5.1)
Conflicts
- typo3/cms-form: 11.5.13 - 11.5.15
This package is auto-updated.
Last update: 2023-05-27 09:04:50 UTC
README
TYPO3 extension form_consent
📦 Packagist | 🐥 TYPO3 extension repository | 💾 Repository | 🐛 Issue tracker
An extension for TYPO3 CMS that adds double opt-in functionality to EXT:form. It allows the dynamic adaptation of the entire double opt-in process using various events. In addition, the extension integrates seamlessly into TYPO3, for example to delete expired consents in compliance with the GDPR.
🚀 Features
- Custom
Consent
form finisher for EXT:form - Stores all submitted form data as JSON in database
- System-dependent hash-based validation system (using TYPO3's HMAC functionality)
- Plugin to approve or dismiss a consent
- Possibility to invoke finishers on consent approval or dismissal
- Several events for better customization
- Scheduler garbage collection task for expired consents
- Dashboard widget for approved, non-approved and dismissed consents
- Compatible with TYPO3 10.4 and 11.5 LTS
🔥 Installation
composer require eliashaeussler/typo3-form-consent
Alternatively, you can download the extension via the TYPO3 extension repository (TER).
Once installed, make sure to include the TypoScript setup at
EXT:form_consent/Configuration/TypoScript
in your root template.
⚡ Usage
Finisher
A new finisher Consent
is available in the backend form editor.
It saves all submitted form data in the database and sends a
corresponding mail to either approve or dismiss a given consent.
The last inserted consent is populated with the finisher variable
provider. It can be accessed as {Consent.lastInsertedConsent}
in
the .form.yaml
configuration.
Example:
finishers: - options: table: tx_myextension_domain_model_mymodel mode: insert databaseColumnMappings: consent: value: '{Consent.lastInsertedConsent.uid}' identifier: SaveToDatabase
Plugin
A plugin is required for approval or dismiss of the consent. The associated page containing the plugin must then be specified in the finisher settings.
📂 Configuration
TypoScript
The following TypoScript constants are available:
TypoScript constant | Description | Required | Default |
---|---|---|---|
plugin.tx_formconsent.persistence.storagePid |
Default storage PID for new consents | – | 0 |
plugin.tx_formconsent.view.templateRootPath |
Path to template root for consent mail and validation plugin | – | – |
plugin.tx_formconsent.view.partialRootPath |
Path to template partials for consent mail and validation plugin | – | – |
plugin.tx_formconsent.view.layoutRootPath |
Path to template layouts for consent mail and validation plugin | – | – |
Finisher options
The following options are available to the Consent
finisher:
Finisher option | Description | Required | Default |
---|---|---|---|
subject |
Mail subject | – | Approve your consent |
recipientAddress |
Recipient e-mail address | ✅ | – |
recipientName |
Recipient name | – | – |
senderAddress |
Sender e-mail address | – | System default sender e-mail address |
senderName |
Sender name | – | System default sender name |
approvalPeriod |
Approval period | ✅ | 86400 (1 day), 0 = unlimited |
showDismissLink |
Show dismiss link in consent mail | – | false |
confirmationPid |
Confirmation page (contains plugin) | ✅ | – |
storagePid |
Storage page | – | plugin.tx_formconsent.persistence.storagePid |
templateRootPaths |
Additional paths to template root | – | – |
partialRootPaths |
Additional paths to template partials | – | – |
layoutRootPaths |
Additional paths to template layouts | – | – |
💡 Note: Template paths that are configured via form finisher options are only applied to the appropriate form. They are merged with the default template paths configured via TypoScript.
Extension configuration
The following extension configuration options are available:
Configuration key | Description | Required | Default |
---|---|---|---|
persistence.excludedElements |
Form element types to be excluded from persistence (comma-separated list) | – | Honeypot |
✍️ Customization
The lifecycle of the entire consent process can be influenced in several ways. This leads to high flexibility in customization while maintaining high stability of the core components.
Events
PSR-14 events can be used to modify different areas in the consent process. The following events are available:
Invoke finishers on consent approval or dismissal
After a user has given or revoked consent, it is often necessary to execute certain form finishers. For example, to send an admin email or redirect to a specific page.
To achieve this, after the user gives or revokes consent, the originally
completed form is resubmitted. During this resubmission of the form, the
selected finishers can now be overwritten using the isConsentApproved()
or isConsentDismissed()
conditions in a form variant.
Requirements
The following requirements must be met for the form to be resubmitted:
- Form variant at the root level of the form must exist
- Form variant must redefine the finishers used
- Conditions
isConsentApproved()
orisConsentDismissed()
must exist in the variant
Example
The following form variant is stored directly on the root level of the
form definition (that is, your .form.yaml
file). It specifies the form
finishers to be executed in case of successful approval by the user.
variants: - identifier: post-consent-approval-variant-1 condition: 'isConsentApproved()' finishers: - identifier: EmailToReceiver options: # ... - identifier: Redirect options: # ...
In this example, an admin email would be sent after the consent has been given and a redirect to the configured confirmation page would take place.
The same behavior can be achieved in case the user revokes his consent. The
condition isConsentDismissed()
must then be used instead.
🚧 Migration
0.6.x → 0.7.0
Global form settings
Form settings for Frontend requests (plugin.tx_form
) are no longer included
globally.
- Make sure to add the static TypoScript setup at
EXT:form_consent/Configuration/TypoScript
to your root template.
0.3.x → 0.4.0
Generic consent state
The current state of form consents is now represented in a more generic way.
- Database field
tx_formconsent_domain_model_consent.approved
was renamed totx_formconsent_domain_model_consent.state
.- Upgrade wizard
formConsentMigrateConsentState
needs to be executed.
- Upgrade wizard
- Database field
tx_formconsent_domain_model_consent.approval_date
was renamed totx_formconsent_domain_model_consent.update_date
.- Upgrade wizard
formConsentMigrateConsentState
needs to be executed. - Note: The database column is now nullable.
- Upgrade wizard
$consent->setApproved()
does no longer accept any parameters.- Use
$consent->setState()
instead.
- Use
$consent->getApprovalDate()
was removed.- Use
$consent->getUpdateDate()
instead.
- Use
$consent->setApprovalDate()
was removed.- Use
$consent->setUpdateDate()
instead.
- Use
Post-consent dismissal finishers
Custom finishers can now be executed after consent was dismissed.
- Event listener was renamed.
- Change references to
EliasHaeussler\Typo3FormConsent\Event\Listener\InvokeFinishersListener
. - Adapt your service configuration, if needed.
- Change references to
- Listener method was renamed.
- Use
onConsentApprove($event)
instead of__invoke($event)
.
- Use
- Event listener identifier
formConsentInvokeFinishersOnApproveListener
changed.- Change references to
formConsentInvokeFinishersOnConsentApproveListener
.
- Change references to
0.2.x → 0.3.0
Post-consent approval finishers
Custom finishers can now be executed after consent was approved.
- Database field
tx_formconsent_domain_model_consent.original_request_parameters
was added.- Manual migration required.
- Database field should contain an JSON-encoded string of the parsed body sent with the original form submit request.
- Database field
tx_formconsent_domain_model_consent.original_content_element_uid
was added.- Manual migration required.
- Database field should contain the content element UID of the original form plugin.
- Post-approval finishers can now be defined as described above.
- Manual migration required.
- Create form variants and configure the post-approval finishers.
Consent
model
Form values are now represented as an instance of JsonType
.
- Method
getDataArray()
was removed.- Use
getData()->toArray()
instead.
- Use
- Return type of
getData()
was changed toJsonType|null
.- If you need the JSON-encoded string, use
json_encode($consent->getData())
instead.
- If you need the JSON-encoded string, use
- Parameter
$data
ofsetData()
was changed toJsonType|null
.- If you need to pass a JSON-encoded string, use
$consent->setData(new JsonType($json))
instead. - If you need to pass a JSON-decoded array, use
$consent->setData(JsonType::fromArray($array))
instead.
- If you need to pass a JSON-encoded string, use
Codebase
- Minimum PHP version was raised to PHP 7.4.
- Upgrade your codebase to support at least PHP 7.4.
- Several classes were marked as
final
.- If you still need to extend or override them, consider refactoring your code or submit an issue.
🧑💻 Contributing
Please have a look at CONTRIBUTING.md
.
💎 Credits
Icons made by Google from www.flaticon.com.
⭐ License
This project is licensed under GNU General Public License 2.0 (or later).