Contact Requests: Troubleshooting and FAQ
Sylius Contact Requests Plugin - common installation and operation problems, known limitations (no spam protection, MySQL/MariaDB only) and frequently asked questions
Contact Requests: Troubleshooting and FAQ
Live Demo: Try this and other plugins live — no installation, no risk: demo.markus-michalski.net
Troubleshooting
Symptom: The "Contact Requests" 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_contact_requests_plugin_admin_contact_request_index imported (see Installation)?
Solution: Add the missing entry and run bin/console cache:clear. The menu entry points directly at this route and only appears once it exists.
Symptom: The contact-form e-mails arrive, but nothing shows up under Admin → Contact Requests.
Check: Search the logs for Failed to persist contact request (level error). Does the table mmd_sylius_contact_requests_contact_request exist at all, that is, was mmd:contact-requests:setup run?
Solution: If the table is missing, run the setup command. If the log entry is there although the table exists, the exception class and code point you in the right direction. The actual error message is deliberately not logged (see Technical Details).
Symptom: mmd:contact-requests:setup aborts and reports that the migrations are not registered with Doctrine.
Check: Is the bundle registered, and has the cache been 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: After installing on PostgreSQL, the table is missing, or sylius:fixtures:load fails for this resource.
Check: Which database is running? The migration skips itself without an error on every platform except MySQL/MariaDB.
Solution: There is none. This plugin does not support PostgreSQL (see "Known limitations").
Known limitations
- MySQL/MariaDB only. The migration contains MySQL DDL and skips itself on other platforms without failing. The table then simply doesn't exist there, which trips up generic Sylius tooling such as the fixture purger.
- No built-in spam protection. The plugin stores every request, spam included. The ALTCHA plugin for Sylius helps against bots.
- No per-channel on/off switch. Requests are stored shop-wide as soon as the bundle is registered. There is no admin setting that excludes individual channels.
- Message not searchable. The
messagefield is deliberately excluded from the search, because the column (LONGTEXT) has no index. - No public Shop API. Stored requests are only reachable through the API with admin authentication (see Admin API).
- No automatic deletion. Without your own cron job (see Installation), old requests stay stored indefinitely.
FAQ
General
Does a storing failure block the e-mail send? No. The request is stored first, and a failure there is only logged. The e-mail is sent anyway.
Configuration
Can I turn the plugin off for a single channel? Not through the admin, there is no setting for it. You would have to write your own decorator.
Compatibility
Does the plugin work with a custom contact form? Only if it still sends through Sylius' ContactEmailManagerInterface (the contact form in the shop or the Shop API). A completely separate send path is not captured.