Deutsche Version

Back to overview

Support Form: Troubleshooting and FAQ

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

Troubleshooting

Symptom: The "Support form" entry is missing under "MMKreativ Plugins" in the admin sidebar.
Check: Is the bundle registered in config/bundles.php? Is the admin route mmd_sylius_support_form_plugin_admin_support_form_channel_configuration_index imported (see Installation)?
Solution: Add the missing entry and run bin/console cache:clear. The menu entry only appears once the admin routes are imported. If the import is missing, the plugin hides the entry instead of breaking the admin menu.

Symptom: /support returns a 404 error.
Check: Is the plugin's shop.yaml file imported in your routes?
Solution: Add the import mmd_sylius_support_form_shop from the installation. bin/console mmd:support-form:setup reports missing route imports and prints the matching snippet.

Symptom: mmd:support-form:setup aborts and reports that the migrations are unknown to Doctrine.
Check: Is the bundle registered, and was the cache cleared since? Is sylius_core.prepend_doctrine_migrations not set to false?
Solution: Check the bundle entry and the setting, clear the cache and run the command again.

Symptom: mmd:support-form:setup aborts and points to open Sylius migrations.
Check: Are migrations of Sylius itself still pending, for example after a Sylius update?
Solution: Run bin/console doctrine:migrations:migrate first, then the setup command again.

Symptom: The form shows a free-text field for the subject instead of the expected select list.
Check: Is there a channel configuration for the channel? Is the subject source set to "Products" or "Categories", and is the list of that source filled?
Solution: Create the configuration and select products or categories. Without a configuration, or with an empty active list, the form deliberately shows a free-text field.

Symptom: Requests appear in the admin, but no notification arrives.
Check: Does the channel configuration have a recipient e-mail, or does the channel have a contact e-mail? Does the log contain Failed to send the support request notification email (or ... confirmation email for the customer confirmation)?
Solution: Enter one of the two addresses. If the channel has no recipient address, the plugin sends no notification. If the log entry is there, the problem is in the mail delivery. Only the exception class and code are logged, never the message. The request itself is stored in any case.

Symptom: The customer doesn't receive a confirmation mail.
Check: Is there an extra field of type E-mail, and did the customer answer it?
Solution: Create a field of type E-mail (see Configuration). The confirmation only goes to the address from an answered e-mail field.

Symptom: The link to the privacy policy is missing in the consent text.
Check: Is a page entered in the channel configuration? Does the route exist if you entered a route name?
Solution: Add or correct the entry. An unknown route name makes the consent appear without a link.

Symptom: The Shop API answers POST /shop/support-requests with 422 and The subject must be one of the channel's available choices.
Check: Does the channel have subject choices? What does GET /shop/support-form-subject-choices return?
Solution: Send one of the value entries from that list as subject.

Symptom: After installing on PostgreSQL, tables are missing or the migration fails.
Check: Which database is running?
Solution: There is none. The migrations are MySQL DDL, PostgreSQL is not supported.

Known limitations

• No spam protection of its own. The form doesn't protect itself against bots. The extension points (see Extensibility) are prepared for it, but a ready-made protection is not part of the plugin.
• The confirmation mail goes to any typed address. Without spam protection, a bot can make your shop send mails to arbitrary third parties. The mail repeats subject and answers exactly as submitted, as text and not as HTML. An attacker can therefore have their own text delivered under your sender. Add the protection before you link the form publicly.
• No name to pre-fill. For logged-in customers the plugin only pre-fills the e-mail address, through the first field of type E-mail. There is no fixed name field.
• Extra fields apply to all channels. Only subject source, recipient and privacy link can be set per channel.
• The admin search only covers e-mail and subject. The answers to extra fields are stored in a column that can't be searched.
• MySQL/MariaDB only.
• No automatic deletion. Without a cron job (see Installation) requests are stored indefinitely.

FAQ

General

Does a failure in sending mail block the request? No. The request is stored before the mails go out. If a mail fails, only the type of error is logged, and the other mail is still sent. The customer sees no error.

What happens to requests if I delete a channel? They are kept. Only the channel reference is cleared.

Can I edit a request afterwards? No. Incoming requests can be viewed and deleted.

Configuration

Does the form have to ask for a name? No. Apart from subject and consent nothing is fixed. If you want a name, you create a text field for it.

Can I exclude a channel from the form? There is no setting for that. The form at /support is reachable for every channel. Without a configuration it shows a free subject.

What changes in old requests if I rename a field? Nothing. Each request stores the label of the field at the time of submitting.

Compatibility

Does the plugin work with Sylius 2.2 and 2.3? Yes, both versions are tested.

Does the plugin work with API Platform 4 and 5? Yes. The only difference visible to clients is the status code for a wrong data type of consent, see Shop API.

Does the plugin replace the Sylius contact form? No. It sits next to it independently at /support.