Datinglibre App Bundle Laravel Package

Getting Started

Confirm the framework before writing any code. Despite the Laravel framing of this task, the -bundle suffix, DatingLibre lineage, and Symfony conventions mean you should assume this is a Symfony bundle. There is no DatingLibreServiceProvider, no Laravel auto-discovery, and it will not drop into a Laravel app. If you're in a Laravel codebase, treat this as vendored source to port or as a reference implementation — not a dependency.

Minimal steps for a Symfony app:

composer require datinglibre/datinglibre-app-bundle

1. Register the bundle in config/bundles.php:

   DatingLibre\AppBundle\DatingLibreAppBundle::class => ['all' => true],
   

2. Read DependencyInjection/Configuration.php first. It's the authoritative map of what you can configure without touching vendor code. Read it before src/.
3. Import the bundle's routes if it ships them — look for Resources/config/routing.xml or routing.yaml.
4. Map the seams. The description says "overridable core code," so browse these five directories and note what's final, what's abstract, and what's an interface:
   • src/Entity/ — profiles, photos, preferences
   • src/Controller/ — profile, search, messaging, moderation
   • src/Form/ — profile editing, preference selection
   • src/Service/ — matching, messaging, moderation
   • Resources/views/ — templates you'll override

First use case: extend the bundle's member/profile entity rather than editing vendor code, then override one form type and one template end-to-end. That single path exercises Doctrine inheritance, DI/service overrides, and template overrides — it validates your wiring before you build features on top. Concretely: subclass the profile entity, add one custom field (e.g., displayPronouns), render it in the profile edit form, and confirm it persists.

Implementation Patterns

Entity extension via inheritance. The expected pattern for an "overridable core" bundle is a non-final base entity mapped as @MappedSuperclass or a concrete parent. Your app class extends it, points at the same table, and adds fields. Verify with bin/console doctrine:mapping:info that the inherited mapping resolves — if the bundle ships XML/YAML mappings for the parent, your subclass won't inherit them silently and you'll need @ORM\AttributeOverrides or to re-declare the mapping in PHP attributes.

// src/Entity/Member.php
#[ORM\Entity]
#[ORM\Table(name: 'dl_member')]
class Member extends \DatingLibre\AppBundle\Entity\Member
{
    #[ORM\Column(nullable: true)]
    private ?string $displayPronouns = null;
}

Service decoration, not replacement. For messaging or matching behavior, decorate rather than swap — you keep the bundle's wiring intact and add your logic at the seam:

# config/services.yaml
App\Service\InstrumentedMatcher:
    decorates: datinglibre.matcher
    arguments: ['@.inner']

Where you must replace, alias the interface and point it at your class, letting the bundle's container resolve your implementation. This keeps upstream upgrades cheap because you're still using the bundle's tags, event subscriptions, and service graph.

Controller and route overrides. If the bundle lets you override routes, do it in your own config/routes.yaml with the same route name — Symfony's router picks the first match, so your app-level definition wins. Otherwise, import the bundle's routing, then add your own controller extending or wrapping the bundle's and remap individual routes.

Template overrides go in the bundle override path, never in vendor/:

templates/bundles/DatingLibreAppBundle/Profile/edit.html.twig

Copy the original, change the parts you need. This keeps vendor clean and survives composer update.

Form types. Prefer FormTypeExtension over rewriting a form type — extend the profile-edit form by adding your custom field, and the bundle's view layer keeps working:

class ProfileTypeExtension extends AbstractTypeExtension
{
    public static function getExtendedTypes(): iterable
    {
        return [\DatingLibre\AppBundle\Form\ProfileType::class];
    }
}

Messaging and moderation integration. Wire your business rules (rate limits, profanity filters, abuse escalation) as event subscribers on the bundle's messaging and reporting events rather than editing the services. This is the extension point that survives upstream changes best — if the bundle dispatches MessageSentEvent, subscribe to it; don't override the message service unless you must.

Schema and migrations. Run the bundle's migrations first, then your own. Keep a strict ordering: bundle migrations in vendor (untouched), your app migrations in migrations/. Never edit an upstream migration — deployment and rebasing both break.

Testing the seams. Add a functional test that boots the kernel and confirms your profile extension persists, and one that confirms a template override renders. These are cheap and catch the highest-frequency regressions after an upstream bump (mapping breaks, template precedence breaks, service decoration ordering breaks).

Gotchas and Tips

• Laravel is a hard blocker. Every Laravel expectation (service provider, config publishing, facade, Eloquent models) is wrong here. Budget for a port or run the bundle as a separate Symfony service behind an API boundary — don't try to graft Doctrine entities into Eloquent.
• Zero signals means you own everything. No stars, no dependents, no score. There is no security disclosure path and no responsive maintainer to fall back on. Pin the version explicitly in composer.json, vendor the lockfile, and name an owner for the fork before you ship anything with real user data.
• Override drift. Every override you add is a future merge conflict. Keep a running list in your repo of what you extend and why — that list is the first thing you consult on every upstream bump. If an override gets complex enough that you're fighting the code, extract the behavior and rewrite it natively instead.
• Config cache masks overrides. After registering the bundle, adding a decoration, or changing services.yaml, run bin/console cache:clear. In dev, container changes occasionally need a full cold boot to take effect.
• Debug commands are your onboarding:

  bin/console debug:container datinglibre      # what services exist and how they're aliased
  bin/console debug:router                    # what routes the bundle registers
  bin/console doctrine:mapping:info           # whether your entity subclass is resolved
  bin/console debug:twig DatingLibreAppBundle # confirms template override paths
  

• Doctrine inheritance traps. MappedSuperclass parents resolve cleanly; a concrete parent entity mapping the same table needs your subclass to be the mapping root (or use #[ORM\AttributeOverrides]). If a query in the bundle's repository suddenly returns the parent instead of your subclass, that's the symptom — the parent is the mapping root.
• Decoration order matters. Multiple decorators on datinglibre.matcher apply in decoration_priority order. If a rate limit or a logging decorator isn't firing, verify priority — a missing decorator is a silent failure, not an error.
• Template override precedence is bundle-path first, then app templates. If your override "isn't loading," confirm the exact bundle name casing (DatingLibreAppBundle) in templates/bundles/ — Symfony is case-sensitive here.
• PII and verbose errors. Dating platforms handle sensitive data. Before exposing to users, audit the bundle's default templates for leaked fields in error pages and disable Symfony's dev exception pages in production. Moderation, age verification, and payment compliance are all on you — the bundle does not ship them.
• Don't scale-block. Confirm early whether the bundle ships caching, queue, and search abstractions, or expects you to add them. Dating workloads are read-heavy on profile browsing and write-heavy on messaging; know where you'll add caching and search before you need to.
• When in doubt, fork. Given the assessment signals, the realistic adoption model is fork-and-own, not depend-and-upgrade. Price that in before committing roadmap capacity, and set a timeboxed spike with a go/no-go gate on framework fit, override ergonomics, and the true cost.