Deutsche Version

Back to overview

Support Form: Technical Details

Live Demo: Try this and other plugins live — no installation, no risk: demo.markus-michalski.net

Flow of a request

Storefront and Shop API run into the same processing. There the event is dispatched first, and the request only continues if no listener rejects it.

graph TD
    A["Customer: POST /support"] --> B{"Form valid?"}
    H["Client: POST /shop/support-requests"] --> I["Entity validation"]
    I --> J["Check subject against select list"]
    J --> K["Validate answers with form rules"]
    B -->|Yes| M["Derive answers and e-mail address"]
    K --> M
    M --> N["Resolve subject code into label"]
    N --> O["PRE_PERSIST event"]
    O --> Q{"Rejected by a listener?"}
    Q -->|Yes| U["Storefront: error message, API: 422"]
    Q -->|No| R["Store request"]
    R --> S["Mail to the operator"]
    R --> T["Confirmation to the customer"]
    S --> V["Storefront: success message, API: 201"]
    T --> V

The processing (SupportRequestSubmissionHandler) is the only place where requests are stored and notifications are sent. Controller and API processor only call it. Each of the two mails has its own error guard: if one fails, the request is still stored and the other one goes out. Only the exception class and code are logged, never the message, because it can contain personal data.

Dual mode at a glance

Plugin structure

src/
├── Api/                  # Shop API processor and provider, answer validation, subject choices as a DTO
├── Command/              # SetupCommand, PurgeSupportRequestsCommand
├── Controller/           # SupportRequestController (storefront)
├── DependencyInjection/  # Bundle extension (empty configuration)
├── Entity/               # SupportRequest, SupportFormField (+ translation), SupportFormChannelConfiguration, enums
├── Event/                # SupportRequestEvents, SupportRequestPrePersistEvent
├── Factory/              # SupportFormFieldFactory
├── Form/Type/            # SupportRequestType and the admin forms
├── Handler/              # SupportRequestSubmissionHandler
├── Mailer/               # SupportRequestMailer, Emails
├── Menu/                 # Admin sidebar entry in the "MMKreativ Plugins" group
├── Migrations/           # Three Doctrine migrations
├── Repository/           # Repositories of the three resources
├── Resolver/             # Subject choices, answer collector, privacy link
└── Twig/                 # PluginVersionExtension
config/
├── grids/                # Three admin grids
├── routes/               # admin.yaml, shop.yaml
├── twig_hooks/           # admin.yaml, shop.yaml
└── mailer.yaml           # Two e-mail templates
templates/
├── admin/                # Title blocks and forms, detail view
├── emails/               # Notification and confirmation
└── shop/                 # Form and footer link
translations/             # messages, validators, flashes in de and en

Tables and migrations

The plugin creates six tables.

graph LR
    A["support_request"] -->|"channel_id, SET NULL"| C["sylius_channel"]
    B["support_form_channel_configuration"] -->|"channel_id, CASCADE"| C
    B --- D["configuration_product"]
    B --- E["configuration_taxon"]
    F["support_form_field"] --- G["support_form_field_translation"]

The answers to the extra fields are stored as a JSON list of label and value in the field_values column of the request, not in a table of their own. The plugin never reads them individually, only together with the request. Because each answer carries its label, it stays readable when you later change or delete the field.

The channel_id column of a request is set to NULL when a channel is deleted, whereas the channel's configuration is deleted with it.

Admin details

• The plugin reads no bundle configuration, the configuration class is empty.
• The plugin attaches grids and Twig hooks to the application configuration itself, so no import of your own is needed.
• The form for channel configurations uses the Sylius autocomplete fields for products and categories. The plain select field wouldn't provide a working selection in this Sylius version.
• The admin title block shows the installed plugin version (Twig function support_form_plugin_version(), reads Composer\InstalledVersions). For a tagged release this is the version number, for a local path installation it is dev-main plus the first characters of the commit hash.
• The menu entry lives in the "MMKreativ Plugins" group. Each plugin creates the group itself if it is missing. Several MMKreativ plugins therefore share one sidebar entry.