Cms Contact Bundle Laravel Package

Getting Started

The first thing to know: this bundle is archived (last release Feb 2014) and targets Symfony 2.x / PrestaCMS 1.x. Before writing any code, open composer.json in the repo and confirm the Symfony and presta/cms-block-bundle version constraints. If you're on a modern Symfony stack, budget time for a fork rather than expecting a clean composer require.

Minimal setup:

1. Add the dependency, pinned to a tag (not dev-master, since the repo is frozen but tags are reproducible):

   composer require presta/cms-contact-bundle:~1.0
   

   If Composer refuses on platform constraints, resolve by downgrading the host app or forking; do not silently use --ignore-platform-reqs in production.
2. Register the bundle in app/AppKernel.php:

   new PrestaCMS\ContactBundle\PrestaCMSContactBundle(),
   

   It must load after PrestaCMSBlockBundle and PrestaCMSCoreBundle.
3. Inspect DependencyInjection/Configuration.php and DependencyInjection/PrestaCMSContactExtension.php — this is where the recipient address, sender, and template name live. Copy the tree into app/config/config.yml under presta_cms_contact:.
4. Clear the cache and look in the block palette of the CMS admin: app/console cache:clear.
5. First use case: create a test page, add the Contact block to a zone, fill the block settings, submit the form on the frontend, and confirm the mail lands (check app/logs/dev.log for mailer errors if it doesn't).

Where to look first, in order:

• Block/ — the ContactBlockService (this is the entry point; it wires the form, the template, and the request handling).
• Resources/views/ — the Twig template for the block (Block/contact.html.twig-style).
• Form/ — the form type and its validation constraints.
• Controller/ — the submit handler (it may be inside the block service rather than a controller; PrestaCMS blocks often handle their own POST via a BlockService call).
• Resources/config/services.yml — the service ID and the presta_cms.block tag.

Implementation Patterns

Placing the block on a page. PrestaCMS treats this as a "block" — a reusable content unit you drop into a page zone through the admin UI. Day-to-day, editors add it via the page editor, configure the block's settings (recipient, subject, success message), and the frontend renders the form. You do not write route/controller code for the frontend; the block service handles both render and POST.

Overriding the template (the most common task). Never edit vendor. Copy the Twig file to app/Resources/PrestaCMSContactBundle/views/Block/contact.html.twig (Symfony 2 bundle override path) and adjust markup there. Keep the form_start / form_widget / form_end calls intact or the CSRF token and field names will break.

Overriding the block service. Subclass or replace ContactBlockService, re-register it under the same service ID in app/config/config.yml, and preserve the presta_cms.block tag plus the alias/name tag attributes — PrestaCMS resolves blocks by alias, so a wrong alias means the block disappears from the palette. Clear the cache after this; block metadata is cached aggressively.

Persisting submissions. The bundle is designed around mail delivery, not storage. If you need a record of submissions, the cleanest path is to decorate the block service: wrap handleForm/submit (check the actual method name in the source), call the parent, then persist your own ContactSubmission entity via Doctrine. Alternatively, attach a Symfony event listener if a submission event is dispatched — verify in the source before assuming one exists.

Reusing the form outside a CMS page. The form type is a normal Symfony form type. You can instantiate it in your own controller for a standalone /contact route ($this->createForm(ContactType::class)-style, minus the block wiring), which is often the pragmatic move if you don't need the CMS placement UI.

Mailer integration. Submissions go through the mailer service (Swiftmailer in this era). Configure swiftmailer transport properly — synchronous sendmail in dev is fine, but in production use an SMTP transport or a mailer that doesn't block the request. Consider using the async spool (swiftmailer: spool: type: memory) so a slow SMTP server doesn't tie up the request.

Multi-page embedding. If the same block appears on several pages, the forms share field names. PrestaCMS generates a unique block ID per placement; make sure that ID is included in the form action/ID so submissions route to the right block instance.

Gotchas and Tips

• It is archived and unmaintained. With 2 stars and 0 dependents, treat every behavior as unverified. Read the source before trusting it; there's no community to ask. If you adopt it, fork it into your own vendor namespace and treat that fork as the source of truth.
• Symfony 2.x only. The code predates PSR-4 autoloading in places, uses old getBlockPrefix-era or earlier form APIs, and may reference swiftmailer directly. On a modern stack you will be rewriting rather than integrating.
• Silent mail failures. If swiftmailer is misconfigured or the recipient config key is empty, the block may render fine and accept the form yet never send. Add logging around the mail call in your override, and always check dev.log.
• Config key names drift between README and code. The README was written for an older version. Trust Configuration.php, not the docs, for the exact key names (recipients vs to, template vs view, etc.).
• Block alias mismatches. PrestaCMS identifies blocks by the alias/name tag attribute. If you override the service and change it, the block vanishes from the admin palette or renders with a different template. Keep the alias identical to the original.
• Cache everywhere. Block service definitions, Twig templates, and form metadata are all cached. After any service override run app/console cache:clear (both dev and prod if you're debugging a "works in dev, broken in prod" issue).
• Form field collisions. Rendering the block twice on one page (e.g., in a sidebar and main zone) can produce duplicate field IDs and break CSRF/label association. Ensure the block template prefixes IDs with the block's unique identifier.
• Validation is thin. Check Resources/config/validation.yml (if present) and the Form/ type. Expecting server-side email/message validation out of the box is risky — add explicit constraints to your override rather than assuming.
• No CSRF-free API path. If you want a JSON endpoint, the default form relies on session CSRF tokens. Either disable CSRF explicitly for that route or build a separate form type; don't hack around it by stripping the token from the rendered template.
• Extension points to prefer: template override → form type override → service decoration. Avoid modifying vendor/, and avoid monkey-patching the controller-less flow; the block service is the seam.
• Debugging tip: app/console debug:container | grep -i contact and app/console debug:container --tag=presta_cms.block quickly reveal the registered service ID, tag attributes, and class — usually faster than grepping the bundle.