The information collection feature makes it possible to gather user input when a node referencing an information collector object is viewed. It is typically useful when it comes to the creation of feedback forms, polls, etc. An object can collect information if at least one of the class attributes is marked as an information collector.
When the object is viewed, each collector attribute will be displayed using the chosen datatype’s data collector template. Instead of just outputting the attributes’ contents, the collector templates provide interfaces for data input. The generated input interface depends on the datatype that represents the attribute.
This bundle re-implements the information collection feature for eZ Platform/Ibexa stack.
Note
This documentation assumes you have a working knowledge of the Symfony Framework and eZ Platform DXP. If you’re not familiar with Symfony, please start with reading the Quick Tour from the Symfony documentation and for eZ Platform DXP visit the eZ Platform Developer Documentation.
Overview¶
Overview¶
WIP.
Introduction¶
WIP
How it works¶
Information collection renders form based on content type fields. In order to completely utilize the power of this bundle we to add some fields to content type. It must contain following: * fields marked as information collectors (mandatory) * email field with identifier recipient * email field with identifier sender * text field with identifier subject * some other fields with success text or something else (those are not mandatory)
In case when content type does not contain recipient, sender or subject, bundle by default will use values specified in yaml configuration (default_variables tree). Then define content view for given content type (content_view.yml) specifiying netgen_information_collection.controller.collect_information as controller:
ezpublish:
system:
frontend_group:
content_view:
full:
my_content_type_with_information_collectors:
template: '@Acme/content/full/my_content_type.html.twig'
controller: netgen_information_collection.controller.collect_information
match:
Identifier\ContentType: my_content_type
Controller will return standard eZ ContentView with additional two variables form and is_valid. form contains Symfony form and it is up to you it will be rendered and is_valid signals when form is valid and submitted.
Example template:
{% extends '@Acme/pagelayout.html.twig' %}
{% block content %}
<div class="my-content-type clearfix">
{% if is_valid is defined and is_valid %}
<div class="confirmation-message">
{% if not ez_is_field_empty( content, "success_text" ) %}
<div class="att-success-text">
{{ ez_render_field( content, "success_text" ) }}
</div>
{% endif %}
</div>
{% else %}
<h1 class="page-header">{{ ez_render_field( content, "title" ) }}</h1>
{% if not ez_is_field_empty( content, "full_intro" ) %}
<div class="intro">
{{ ez_render_field( content, "full_intro" ) }}
</div>
{% endif %}
{% if not ez_is_field_empty( content, "body" ) %}
<div class="body">
{{ ez_render_field( content, "body" ) }}
</div>
{% endif %}
{{ form_start(form, { 'attr': { 'class': 'contact-us form-default' } } ) }}
{{ form_errors(form) }}
<div class="form-group">
<div class="control-label">
{{ form_label( form.first_name ) }}:
</div>
{{ form_widget( form.first_name, {'attr': {'class': 'form-control'} } ) }}
{{ form_errors( form.first_name ) }}
</div>
<div class="form-group">
<div class="control-label">
{{ form_label( form.last_name ) }}:
</div>
{{ form_widget( form.last_name, {'attr': {'class': 'form-control'} } ) }}
{{ form_errors( form.last_name ) }}
</div>
<div class="form-group">
<div class="control-label">
{{ form_label( form.email ) }}:
</div>
{{ form_widget( form.email, {'attr': {'class': 'form-control'} } ) }}
{{ form_errors( form.email ) }}
</div>
<div class="form-group">
<div class="control-label">
{{ form_label( form.comment ) }}:
</div>
{{ form_widget( form.comment, {'attr': {'class': 'form-control'} } ) }}
{{ form_errors(form.comment) }}
</div>
<div class="form-group button-area">
<button type="submit" class="btn btn-primary">Send</button>
</div>
{{ form_rest(form) }}
{{ form_end(form) }}
{% endif %}
</div>
{% endblock %}
Configuration¶
For advanced configuration documentation and examples please check [documentation](CONFIGURATION.md).
Actions¶
What is action ? Action defines what needs to be done when information collection for is submitted. For every content type action list must be defines. When form is submitted, handler travers over list and executes actions.
[Actions](ACTIONS.md)
Field handlers¶
By default every field value is transformed (cast) to string, if end developer needs customized string of some field value then custom field value handler must be implemented.
[Field handlers](FIELD_HANDLERS.md)
Features¶
WIP
Getting started¶
Getting started¶
WIP.
Installation instructions¶
Requirements¶
PHP 7.3+
eZ Platform 2.0+
Installation steps¶
Use Composer¶
Run the following from your website root folder to install NetgenInformationCollectionBundle:
$ composer require netgen/information-collection-bundle
Activate the bundle¶
Activate required bundles in app/AppKernel.php file by adding them to the $bundles array in registerBundles method:
public function registerBundles()
{
...
$bundles[] = new Netgen\Bundle\EzFormsBundle\NetgenEzFormsBundle();
$bundles[] = new Netgen\Bundle\InformationCollectionBundle\NetgenInformationCollectionBundle();
return $bundles;
}
Include routing configuration¶
In your main routing configuration file probably routing.yml add:
_netgen_information_collection:
resource: '@NetgenInformationCollectionBundle/Resources/config/routing.yml'
Enable auto_mapping for Doctrine¶
Add this to config.yml, it will make Doctrine automatically load the mappings from our bundle:
doctrine:
orm:
auto_mapping: true
Configuration¶
Set siteaccess aware configuration¶
Here is sample configuration for actions, the developer will need to define a list of actions to be run depending on the content type. Configuration needs to be added in app/config/config.yml or app/config/ezplatform.yml:
netgen_information_collection:
system:
default:
action_config:
email:
templates:
default: '@Acme/email/default.html.twig'
default_variables:
sender: 'sender@example.com'
recipient: 'recipient@example.com'
subject: 'Subject'
actions:
default:
- email
- database
Don’t forget to create default email template.
Clear the caches¶
Clear the eZ Publish caches with the following command:
$ php app/console cache:clear
For more detailed configuration, please check documentation reference.
Content curation¶
WIP
Cookbook¶
Cookbook¶
WIP.
Creating a custom action¶
To develop custom action, end developer needs to implement ActionInterface and define custom action as service tagged with netgen_information_collection.action and some custom alias which is used as action identifier (required for configuration).
Action example:
<?php
namespace Acme\Bundle\AcmeBundle\MyCustomActions;
use Netgen\Bundle\InformationCollectionBundle\Action\ActionInterface;
use Netgen\Bundle\InformationCollectionBundle\Event\InformationCollected;
class CustomAction implements ActionInterface
{
/**
* @inheritDoc
*/
public function act(InformationCollected $event)
{
// do some magic ...
}
}
And service definition:
acme_bundle.my_actions.custom:
class: Acme\Bundle\AcmeBundle\MyCustomActions\CustomAction
tags:
- { name: netgen_information_collection.action, alias: custom_action }
Configuration:
netgen_information_collection:
system:
default:
actions:
default:
- email
- database
content_types:
my_content_type:
- email
- database
- custom_action
Creating a custom field value handler¶
Creating custom field handlers¶
To develop custom field handler, end developer needs to implement CustomFieldHandlerInterface and define custom action as service tagged with netgen_information_collection.field_handler.custom.
Field handler example:
<?php
namespace Acme\Bundle\AcmeBundle\MyCustomFieldHandlers;
use Netgen\Bundle\InformationCollectionBundle\FieldHandler\Custom\CustomFieldHandlerInterface;
use eZ\Publish\API\Repository\Values\ContentType\FieldDefinition;
use eZ\Publish\Core\FieldType\Value;
use eZ\Publish\Core\FieldType\Integer\Value as IntegerValue;
class IntegerFieldHandler implements CustomFieldHandlerInterface
{
/**
* @inheritdoc
*/
public function supports(Value $value)
{
return $value instanceof IntegerValue;
}
/**
* @inheritdoc
*/
public function toString(Value $value, FieldDefinition $fieldDefinition)
{
// do some magic ..
}
}
And service definition:
acme_bundle.my_custom_handlers.integer:
class: Acme\Bundle\AcmeBundle\MyCustomFieldHandlers\IntegerFieldHandler
tags:
- { name: netgen_information_collection.field_handler.custom }
Creating a custom field anonymizer¶
WIP
Adding Captcha to forms¶
WIP
Creating a custom export formatter¶
WIP
How to override field value view in admin¶
WIP
How to handle a form via Ajax¶
WIP
How to override something on info collector form¶
<?php
declare(strict_types=1);
namespace Acme\Form;
use Acme\Validator\Constraints\MyValidator;
use Netgen\Bundle\EzFormsBundle\Form\Type\InformationCollectionType;
use Netgen\Bundle\EzPlatformSiteApiBundle\View\ContentValueView;
use Symfony\Component\Form\AbstractTypeExtension;
use Symfony\Component\Form\Extension\Core\Type\TextType;
use Symfony\Component\Form\FormBuilderInterface;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\RequestStack;
final class InvoiceNumberFormExtension extends AbstractTypeExtension
{
/**
* @var \Symfony\Component\HttpFoundation\RequestStack
*/
private $requestStack;
public function __construct(RequestStack $requestStack)
{
$this->requestStack = $requestStack;
}
public function getExtendedType(): string
{
return InformationCollectionType::class;
}
public function buildForm(FormBuilderInterface $builder, array $options): void
{
$request = $this->requestStack->getCurrentRequest();
if (!$request instanceof Request || !$builder->has('invoice_number')) {
return;
}
if (!$request->attributes->has('view')) {
return;
}
$view = $request->attributes->get('view');
if (!$view instanceof ContentValueView) {
return;
}
$invoiceNumberOptions = $builder->get('invoice_number')->getOptions();
$invoiceNumberOptions['constraints'][] = new MyValidator();
$builder->add('invoice_number', TextType::class, $invoiceNumberOptions);
}
}
acme.form.invoice_number_extension:
class: Acme\Form\InvoiceNumberFormExtension
arguments:
- '@request_stack'
tags:
- { name: form.type_extension, extended_type: Netgen\Bundle\EzFormsBundle\Form\Type\InformationCollectionType }
Reference¶
Reference¶
Container parameters¶
Available Container parameters:
netgen_information_collection.default.admin.max_per_page - controls how many items will be displayed per page
netgen_information_collection.default.form.use_csrf - controls whenever will CSRF token be used on forms or not
netgen_information_collection.ezadminui.pagelayout - controls which template will be used for admin pagelayout
netgen_information_collection.default.admin.tree_limit - controls which template will be used for admin pagelayout
netgen_information_collection.default.admin.pagelayout - controls which template will be used for admin pagelayout
netgen_information_collection.ezadminui.pagelayout - controls which template will be used for admin pagelayout
Symfony dependency injection tags¶
The following lists all dependency injection tags and their usage available in Netgen Information Collection:
Note
All available Symfony dependency injection tags defined by Netgen Information Collection Bundle are registered for autoconfiguration. So if, within you service definition file have autoconfiguration enabled, your services are going to be tagged automatically. For more information about autoconfiguration please refer to Symfony documentation.
netgen_information_collection.action
¶
Purpose: Adds a new block definition handler
When registering a new block definition handler, you need to use the
identifier
attribute in the tag to specify the unique identifier of the
block definition:
app.block.block_definition.handler.my_block:
class: AppBundle\Block\BlockDefinition\Handler\MyBlockHandler
tags:
- { name: netgen_layouts.block_definition_handler, identifier: my_block }
netgen_information_collection.anonymizer.visitor.field
¶
Purpose: Adds a new block handler plugin
When registering a new block definition handler plugin, you can use the
priority
attribute in the tag to specify the order in which your handler
plugin is executed in regard to other existing plugins:
app.block.block_definition.handler.plugin.my_plugin:
class: AppBundle\Block\BlockDefinition\Handler\MyPlugin
tags:
- { name: netgen_layouts.block_definition_handler.plugin, priority: 10 }
netgen_information_collection.field_handler.custom
¶
Purpose: Adds a new query type handler
When registering a new query type handler, you need to use the type
attribute in the tag to specify the unique identifier of the query type:
app.collection.query_type.handler.my_handler:
class: AppBundle\Collection\QueryType\Handler\MyHandler
tags:
- { name: netgen_layouts.query_type_handler, type: my_handler }
netgen_information_collection.export.formatter
¶
Purpose: Adds a new parameter type
app.parameters.parameter_type.my_type:
class: AppBundle\Parameters\ParameterType\MyType
tags:
- { name: netgen_layouts.parameter_type }
Twig usage¶
Netgen Layouts includes a number of Twig functions and tags to make it easier to work with layouts and blocks in your Twig templates.
Some of the functions are used by the frontend and backend layout and block templates, while others are used exclusively in the administration interface of Netgen Layouts.
List of built in Twig functions¶
The following lists all Twig functions built into Netgen Layouts.
info_collection_captcha_is_enabled
¶
This function is used to render a block:
{{ nglayouts_render_block(block) }}
This will render the provided block in the view context of the template from
which you called the function or in the default
view context if the calling
template is not rendered by the Netgen Layouts view layer.
You can transfer a list of custom parameters to the function, which will be injected as variables into the block template:
{# layout.html.twig #}
{{ nglayouts_render_block(block, {'the_answer': 42}) }}
{# block.html.twig #}
{{ the_answer }}
Finally, you can render the block with a view context different from the current one:
{{ nglayouts_render_block(block, {}, 'my_context') }}
info_collection_captcha_get_site_key
¶
This function is used to render a block:
{{ nglayouts_render_block(block) }}
This will render the provided block in the view context of the template from
which you called the function or in the default
view context if the calling
template is not rendered by the Netgen Layouts view layer.
You can transfer a list of custom parameters to the function, which will be injected as variables into the block template:
{# layout.html.twig #}
{{ nglayouts_render_block(block, {'the_answer': 42}) }}
{# block.html.twig #}
{{ the_answer }}
Finally, you can render the block with a view context different from the current one:
{{ nglayouts_render_block(block, {}, 'my_context') }}
info_collection_render_field
¶
This function is used to render a block:
{{ nglayouts_render_block(block) }}
This will render the provided block in the view context of the template from
which you called the function or in the default
view context if the calling
template is not rendered by the Netgen Layouts view layer.
You can transfer a list of custom parameters to the function, which will be injected as variables into the block template:
{# layout.html.twig #}
{{ nglayouts_render_block(block, {'the_answer': 42}) }}
{# block.html.twig #}
{{ the_answer }}
Finally, you can render the block with a view context different from the current one:
{{ nglayouts_render_block(block, {}, 'my_context') }}
List of built in Twig global variables¶
The following lists all Twig global variables built into Netgen Layouts.
netgen_information_collection_admin
¶
This global variable is used by the administration interface of Information collector. Currently, only one variable is available:
nglayouts_admin.pageLayoutTemplate
This variable holds the name of the pagelayout template for the admin interface. The idea behind it is that you can change the pagelayout of the administration interface without having to change the administration templates themselves. This can be achieved by setting this variable to a desired template name before admin interface is rendered (e.g. in an event listener).
Events¶
Netgen Layouts dispatches some events in a lifecycle of displaying the page with a resolved layout that you can listen to and act upon.
The following lists all available events.
netgen_information_collection.events.information_collected¶
Event class: Netgen\InformationCollection\API\Value\Event\InformationCollected
This event will be dispatched when the view of a value is being rendered. It can be used to inject custom variables into the view before the view is sent to Twig for rendering.
Configuration reference¶
Layout type configuration¶
The following lists all available layout type configuration options:
netgen_layouts:
layout_types:
# Layout type identifier
my_layout:
# The switch to enable or disable showing of the layout type in the interface
enabled: true
# Layout type name, required
name: 'My layout'
# The full path to layout icon
icon: '/path/to/icon/my_layout.svg'
# A collection of zones available in the layout type, required
zones:
# Zone identifier
left:
# Zone name, required
name: 'Left'
# List of block definitions which are allowed in the zone
allowed_block_definitions: []
right:
name: 'Right'
allowed_block_definitions: [title]
Block definition configuration¶
The following lists all available block definition configuration options:
netgen_layouts:
block_definitions:
# Block definition identifier
my_block:
# The switch to enable or disable showing of all block types
# related to block definition in the interface
enabled: true
# Identifier of a handler which the block definition will use.
# The value used here needs to be the same as the identifier
# specified in handler tag in Symfony DIC.
# If undefined, the handler with the same identifier as the
# block definition itself will be used.
handler: ~
# Block definition name, required
name: 'My block'
# The full path to block definition icon
icon: '/path/to/icon/my_block.svg'
# Specifies if the block will be translatable once created
translatable: false
# The list of collections the block has. Only one collection named
# "default" is supported for now. Omit the config to disable the collection.
collections:
default:
# The list of valid items for the collection. Use null to
# allow all items, an empty array to disable adding manual
# items, and a list of items to limit the collection to
# to only those items.
valid_item_types: null
# The list of valid query types for the collection. Use null to
# allow all query types, an empty array to disable dynamic collections,
# and a list of query types to limit the collection to
# only those query types.
valid_query_types: null
# This controls which forms will be available to the block.
# You can either enable the full form, or content and design forms.
# If full form is enabled, all block options in the right sidebar
# in the layout editing app will be shown at once, otherwise,
# Content and Design tabs will be created in the right sidebar
forms:
full:
enabled: true
type: Netgen\Layouts\Block\Form\FullEditType
design:
enabled: false
type: Netgen\Layouts\Block\Form\DesignEditType
content:
enabled: false
type: Netgen\Layouts\Block\Form\ContentEditType
# The list of all view types in a block definition, required
view_types:
# View type identifier
my_view_type:
# Switch to control if the view type is shown in the interface or not
enabled: true
# View type name, required
name: 'My view type'
# The list of allowed item view types for this block view type
item_view_types:
# Item view type identifier
my_item_view_type:
# Switch to control if the item view type is shown in the interface or not
enabled: true
# Item view type name, required
name: 'My item view type'
# Use this configuration to control which block parameters will be displayed
# when editing a block in specified view type. Use null to display all
# parameters, an empty array to hide all parameters and a list of parameter
# names to list specific parameters to show. You can also prefix the parameter
# with exclamation mark to exclude it.
valid_parameters: null
Block type and block type group configuration¶
The following lists all available block type and block type group configuration options:
netgen_layouts:
block_types:
# Block type identifier
my_block_type:
# The switch to enable or disable showing the block type in the interface
enabled: true
# Block type name, if undefined, will use the name of a block definition
# with the same identifier as the block type itself.
name: ~
# The full path to block type icon
icon: '/path/to/icon/my_block_type.svg'
# Block definition identifier of the block type, if undefined, will use the
# block definition with the same identifier as the block type itself.
definition_identifier: ~
# Default values for the block
defaults:
# Default name (label) of the block
name: ''
# Default view type of the block. If empty, will use the first available view type.
view_type: ''
# Default item view type of items inside the block. If empty, will use the first
# available item view type in regards to chosen block view type.
item_view_type: ''
# Default values for block parameters
parameters:
param1: value1
param2: value2
block_type_groups:
# Block type group identifier
my_group:
# The switch to enable or disable showing the block type group in the interface
enabled: true
# Block type group name, required
name: 'My group'
# List of block types to show inside the group
block_types: [my_type_1, my_type_2]
Query type configuration¶
The following lists all available query type configuration options:
netgen_layouts:
query_types:
# Query type identifier
my_query_type:
# The switch to enable or disable showing of the query type in the interface
enabled: true
# Identifier of a handler which the query type will use.
# The value used here needs to be the same as the identifier
# specified in handler tag in Symfony DIC.
# If undefined, the handler with the same identifier as the
# query type itself will be used.
handler: ~
# Query type name, required
name: 'My query type'
Value type configuration¶
The following lists all available value type configuration options:
netgen_layouts:
# The list of value types available to build items from
value_types:
# Value type identifier
my_value_type:
# Value type name, required
name: 'My value type'
# The switch to enable or disable showing the value type in the interface
enabled: true
# The switch to enable or disable support for manual items. If disabled,
# the system will not require for you to implement Content Browser support
# for manually selecting items
manual_items: true
Design configuration¶
The following lists all available design configuration options:
netgen_layouts:
# The list of all designs available in the system
design_list:
# Key is the design identifier, while value is the list of all
# themes available for the design. Note that ``standard`` theme
# is automatically included as a fallback and there's no need to
# specify it
my_design: [theme1, theme2]
# Specifies which design, from the list of configured designs, is currently active
design: my_design
Tip
In eZ Platform integration, currently active design is siteaccess aware, meaning, you can use configuration similar to this:
netgen_layouts:
system:
cro:
design: my_design
eng:
design: my_other_design
Administration interface configuration¶
The following lists all available configuration options for Netgen Layouts admin interface:
netgen_layouts:
admin:
# The list of JavaScript files which will be injected into admin interface
javascripts:
- /path/to/script1.js
- /path/to/script2.js
# The list of stylesheets which will be injected into admin interface
stylesheets:
- /path/to/style1.css
- /path/to/style2.css
Layout editing app interface configuration¶
The following lists all available configuration options for Netgen Layouts layout editing interface:
netgen_layouts:
app:
# The list of JavaScript files which will be injected into layout editing interface
javascripts:
- /path/to/script1.js
- /path/to/script2.js
# The list of stylesheets which will be injected into layout editing interface
stylesheets:
- /path/to/style1.css
- /path/to/style2.css
Other configuration¶
The following lists assorted configuration options that do not fit in other categories:
netgen_layouts:
# This flag activates debug mode in Netgen Layouts. This flag is primarily used
# for development of Netgen Layouts themselves and is not useful in project context
# and should be kept disabled
debug: false
# This configures the main pagelayout of your app which resolved layout templates
# will extend and which will be used as a fallback if no layout is resolved
pagelayout: '@App/my_pagelayout.html.twig'
# Generic configuration used for specifying various API keys for 3rd party services.
# Currently used only internally, and cannot be extended.
api_keys:
# API key used for displaying a Google Maps map inside the Maps block
google_maps: 'foo'
Configuration¶
Some advanced use cases.
Specifiying which action to run per content type
By default all actions set by default under actions tree will be executed for all content types.
actions:
default:
- email
- database
To run only specific action for given content type, for example my_content_type and email add this to configuration:
actions:
default:
- email
- database
content_types:
my_content_type:
- email
Or to execute only database action for my_content_type_2:
actions:
default:
- email
- database
content_types:
my_content_type:
- email
my_content_type_2:
- database
## Specifiying which email templates to use per content type
In case when want to split email templates per content type, rather than using default one all, add this to configuration:
action_config:
email:
templates:
default: '@Acme/email/default.html.twig'
content_types:
my_content_type: '@Acme/email/my_content_type.html.twig'
my_content_type2: '@Acme/email/my_content_type2.html.twig'
Symfony commands¶
The following is a list of Symfony commands available in NetgenInformationCollection.
nginfocollector:anonymize
¶
This script can be used to export one or more layouts or mappings to JSON format.
To specify the type of the entity you wish to export, you need to provide it to the script as the first argument.
To specify the ID of the entity to export, provide it to the script as the second argument.
For example, to export the layout with ID of 1, call the script like this:
$ php bin/console nglayouts:export layout 1
Or to export a mapping with an ID of 1, call the script with:
$ php bin/console nglayouts:export rule 1
You can also specify the list of IDs which will then be exported together:
$ php bin/console nglayouts:export layout 1,2,3
If you want to export to file, you can redirect the standard output:
$ php bin/console nglayouts:export layout 1,2,3 > layouts.json
eZ Platform Policies¶
The following is a list of Symfony commands available in Netgen Layouts used for exporting/importing Netgen Layouts data.
Note
This documentation assumes you have a working knowledge of the Symfony Framework and eZ Platform DXP. If you’re not familiar with Symfony, please start with reading the Quick Tour from the Symfony documentation and for eZ Platform DXP visit the eZ Platform Developer Documentation.
Command name |
Purpose |
---|---|
|
This script can be used to export one or more layouts or mappings to a file in JSON format |
|
This script can be used to import one or more layouts from a JSON format stored in a file |
|
This script can be used to import one or more layouts from a JSON format stored in a file |
|
This script can be used to import one or more layouts from a JSON format stored in a file |
Builtin info collector actions¶
Available actions¶
This bundle has some already developed actions: * database - stores collected data to database * email - sends collected data to recipient
Database¶
Database action stores form data to database, to be specific, to ezinfocollection and ezinfocollection_attribute tables.
For advanced configuration please refer to [configuration](CONFIGURATION.md) part.
Email¶
Email action sends email with form data to configured email address, that may be set in content type or configuration. For every content type different Twig template can be applied. Default template for emails must be specified.
For advanced configuration please refer to [configuration](CONFIGURATION.md) part.
Email template¶
To define how email would look like you need to create email template. Email body needs to be added inside email block {% block email %} … email content … {% endblock %}. Inside template you have exposed: * event - instance of InformationCollected class * collected_fields - array of all collected values * content - form content * default_variables - values from configuration like sender, recipient and subject
Some simple email template would look like this:
{% block email %}
{% for field_name, field_value in collected_fields %}
{% if content.fields[field_name] is defined and content.fields[field_name] is not empty %}
<div class="label">
{{ ez_field_name(content, field_name) }}:
</div>
<div class="value">
{{ field_value }}
</div>
<br>
{% endif %}
{% endfor %}
{% endblock %}
Sender, recipient and subject¶
By default InformationCollectionBundle will check first if sender, recipient and subject blocks exist inside email template. If yes it allows you to some custom magic, like this:
{% block subject %}
{# imagine that our subject from configuration equals to 'Information collected' #}
{# and we want to add value from collected field name #}
{{ default_variables.subject ~ ' for ' ~ collected_fields.name }}
{# this will generate 'Information collected for Some name' if Some name was entered on form #}
{% endblock %}
{% block email %}
{# email block #}
{% endblock %}
In case when none of the blocks exist in template, bundle will use values from content (fields sender, recipient and subject) and in case when any of those is empty as last fallback values provided in configuration will be used instead.
Crucial actions¶
Any custom action can be marked as Crucial by implementing CrucialActionInterface. To have crucial action means that if case of failure none of the actions that comes next will be ran. For example database action is marked crucial as there is not point to do any actions if you cannot save data to database.
Upgrades¶
Upgrades¶
Upgrade from 1.x to 2.0¶
WIP
Changelog¶
All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.
Unreleased¶
Please see all Unreleased Changes for more information.
1.1.0 - 2019-02-15¶
Added¶
Danish translation from [@frederikspang](https://github.com/frederikspang).
Georgian translation from [@tatocaster ](https://github.com/tatocaster).
Changelog inconsistency section in Bad Practices
Changed¶
Fixed typos in Italian translation from [@lorenzo-arena](https://github.com/lorenzo-arena).
Fixed typos in Indonesian translation from [@ekojs](https://github.com/ekojs).
1.0.0 - 2017-06-20¶
Added¶
New visual identity by [@tylerfortune8](https://github.com/tylerfortune8).
Version navigation.
Links to latest released version in previous versions.
“Why keep a changelog?” section.
“Who needs a changelog?” section.
“How do I make a changelog?” section.
“Frequently Asked Questions” section.
New “Guiding Principles” sub-section to “How do I make a changelog?”.
Simplified and Traditional Chinese translations from [@tianshuo](https://github.com/tianshuo).
German translation from [@mpbzh](https://github.com/mpbzh) & [@Art4](https://github.com/Art4).
Italian translation from [@azkidenz](https://github.com/azkidenz).
Swedish translation from [@magol](https://github.com/magol).
Turkish translation from [@karalamalar](https://github.com/karalamalar).
French translation from [@zapashcanon](https://github.com/zapashcanon).
Brazilian Portugese translation from [@Webysther](https://github.com/Webysther).
Polish translation from [@amielucha](https://github.com/amielucha) & [@m-aciek](https://github.com/m-aciek).
Russian translation from [@aishek](https://github.com/aishek).
Czech translation from [@h4vry](https://github.com/h4vry).
Slovak translation from [@jkostolansky](https://github.com/jkostolansky).
Korean translation from [@pierceh89](https://github.com/pierceh89).
Croatian translation from [@porx](https://github.com/porx).
Persian translation from [@Hameds](https://github.com/Hameds).
Ukrainian translation from [@osadchyi-s](https://github.com/osadchyi-s).
Changed¶
Start using “changelog” over “change log” since it’s the common usage.
Start versioning based on the current English version at 0.3.0 to help translation authors keep things up-to-date.
Rewrite “What makes unicorns cry?” section.
Rewrite “Ignoring Deprecations” sub-section to clarify the ideal scenario.
Improve “Commit log diffs” sub-section to further argument against them.
Merge “Why can’t people just use a git log diff?” with “Commit log diffs”
Fix typos in Simplified Chinese and Traditional Chinese translations.
Fix typos in Brazilian Portuguese translation.
Fix typos in Turkish translation.
Fix typos in Czech translation.
Fix typos in Swedish translation.
Improve phrasing in French t