Contact Laravel Package

Getting Started

sylius/contact is a split read-only subpackage of the Sylius monorepo — it ships only the domain model for a contact request (a ContactRequest entity with firstName, lastName, email, message, createdAt, plus ContactRequestInterface and a ContactRequestRepositoryInterface). There is no controller, no form type, no route, and no DI extension here.

Minimal steps:

1. Don't composer require this directly. It is archived and marked read-only; the canonical dependency is sylius/sylius or, if you're building standalone, sylius/contact-bundle. The component is pulled in transitively.
2. First place to look: src/Model/ContactRequest.php and src/Model/ContactRequestInterface.php. That's essentially the whole surface area. Read the interface first, then the concrete class to see default property initialization.
3. First use case: persisting a contact-form submission. In a Sylius app you already have sylius.contact.repository.contact_request (or similar) available through the resource system — retrieve the repository from the container and call add() / flush() (from Sylius\Resource\Doctrine\ORM\EntityRepository) with a ContactRequest you construct manually or via the resource factory.

$contactRequest = new ContactRequest();
$contactRequest->setFirstName('Ada');
$contactRequest->setEmail('[email protected]');
$contactRequest->setMessage('Hello');

$repository = $container->get('sylius.contact.repository.contact_request');
$repository->add($contactRequest);

If you're on a recent Sylius version, prefer sylius/contact-bundle + the ContactRequest resource alias in config/packages/_sylius.yaml so the factory and repository are wired for you.

Implementation Patterns

Treat this as a model-only package in a larger stack. The realistic patterns are:

• Resource-based persistence. In Sylius, ContactRequest is a Sylius Resource. Configure or override the resource alias (sylius.contact.contact_request) to swap in your own class, repository, or factory. This is the standard Sylius extension point and the one you'll use most days.
• Model overriding. Extend Sylius\Component\Contact\Model\ContactRequest (or better, implement ContactRequestInterface) and override the resource's classes.model in YAML. This is how you add fields like subject, phone, or a consent boolean without forking the component.
• Repository customization. Override classes.repository to add domain methods (findByEmailSince(), countSince()) instead of leaking QueryBuilder logic into services.
• Bundle integration. In practice you install sylius/contact-bundle, which registers the resource, the form type, and the controller. The component is the DTO/entity you actually write assertions against in tests.
• Testing. Unit tests on your model just instantiate the class and assert getters/setters — there's no framework coupling. Functional tests hit the bundle routes.
• Wiring into your own controllers/services. Type-hint against ContactRequestRepositoryInterface, never the concrete class, and let Sylius's resource registry resolve the implementation.

A common pattern is to keep the component untouched and wrap the submission flow in your own service:

final class SubmitContactRequest
{
    public function __construct(
        private ContactRequestRepositoryInterface $requests,
    ) {}

    public function __invoke(ContactRequestInterface $request): void
    {
        $this->requests->add($request);
    }
}

Gotchas and Tips

• Archived / READ-ONLY. File issues and PRs against Sylius/Sylius, not here. Don't pin your project to this repo intentionally — pin sylius/sylius or the bundle.
• The component ships no migrations. It's schema-less by design; you generate a migration in your application after overriding the resource class. Forgetting this is the #1 source of "table does not exist" errors.
• No DI extension, no routes, no forms. Expecting composer require sylius/contact to give you a working contact page will disappoint. Only the bundle provides that wiring.
• Interface-first everywhere. ContactRequestInterface is the contract; the concrete ContactRequest has nullable/?string typed properties and defaults set in the constructor. If you override, your subclass must remain compatible (return types, nullable signatures).
• createdAt is not auto-populated by the component. You either set it manually or rely on the bundle's factory / Doctrine lifecycle callbacks you configure yourself. This is a classic silent bug — requests land with null timestamps.
• Debugging: bin/console debug:container sylius.contact and bin/console debug:config sylius_resource contact_request in a Sylius app reveal the resolved classes. If the wrong model is being persisted, your resource override YAML isn't loaded (check bundle order).
• Extension points worth knowing: classes.model, classes.repository, classes.factory, and (in the bundle) classes.form under sylius_resource. These are your levers — you should never need to touch the component's source.
• Given 0 dependents and 4 stars, budget for DIY. If your project needs anything beyond a stub entity (attachments, spam filtering, notifications, multi-recipient routing), you're writing it yourself; there is no community layer here to lean on.
• Version drift. Split packages from a monorepo are tagged in lockstep with Sylius releases; the "latest tag" here may lag the monorepo. Always check compatibility against the sylius/sylius version you actually run.