Socialpage Widget Laravel Package

Getting Started

This is still a Symfony bundle, not a Laravel package. It provides a single Victoire DCMS widget that renders a "social page" block (a Facebook-page-style embed) inside Victoire's page builder. If you are a Laravel developer evaluating it, treat it as reference code for how a CMS widget is packaged — you will not be able to composer require it into an app/.

What changed in 2.0.0: the version number moved to a major release, but the release notes are empty. That is the single most important fact to internalize. A major bump with no changelog means you must not assume anything: not the Symfony constraint, not the template markup, not the widget contract, not even that it is still a Victoire widget bundle. Read composer.json and the diff before you plan around it. It could be a Symfony 4+/5 port, a cleanup sweep, a namespace rename, or a tagged-but-abandoned commit. The previous assessment's assumption of "Symfony 2.8/3.x-era APIs" is now unverified rather than true.

Minimal steps (Symfony/Victoire context):

1. Open composer.json on the 2.0.0 tag first. Check the PHP and Symfony constraints and the Victoire widget-bundle dependency version — this tells you in thirty seconds whether the release is a modernized port or a cosmetic bump.
2. Confirm your project is actually running Victoire DCMS. Victoire itself is dormant, so most adopters are on legacy stacks; if 2.0.0 requires a newer Symfony than your Victoire install supports, you are pinned to the 1.x line.
3. composer require friendsofvictoire/socialpage-widget:^2.0 (or add it as a path/VCS repository if Packagist metadata lags the tag).
4. Register the bundle in AppKernel::registerBundles() (or bundles.php on a ported app).
5. cache:clear, and assets:install if the bundle ships Resources/public.
6. Open a Victoire page in edit mode and confirm the widget appears in the picker.

Where to look first:

• composer.json — the diff against the previous tag is the only changelog you have. Start here.
• The widget class under Widget/ — getName(), getCategory(), configureForm(), and the template it renders. If 2.0.0 changed the form fields, this is where you will see it.
• Resources/views/ — the Twig template. The embed markup is the piece most likely to have (or not have) been refreshed, and the piece you will almost certainly override.
• DependencyInjection/ — service wiring for the widget; skim once to check whether the service id or tag changed, since that breaks registration silently.

First use case: place the widget in a widget zone, point it at a social page URL, fill whatever options the form exposes, save, and verify the front-end render. Do that end-to-end pass before reading any more code — it tells you in ten minutes whether 2.0.0 modernized the embed or just bumped a version, which is the only question that matters for adoption.

Implementation Patterns

Widget configuration is the primary workflow. Victoire widgets are configured through the page editor, not YAML. Place widget → fill the form → save → preview. The fields defined in configureForm() are the only knobs unless you fork. Re-check that form after 2.0.0: if fields were renamed, existing page data may not hydrate into the new form, so audit any pages already using the widget before upgrading in place.

Pin the version deliberately. With an undocumented major release, ^1.0 and ^2.0 are meaningfully different bets. Pin an exact version in composer.json, upgrade in a branch, and diff the rendered output of one known page before and after. Do not let a composer update decide this for you.

Override the template rather than editing vendor code. The standard Symfony/Victoire override path lets you replace the embed markup without touching the package. This remains the pattern you will live in regardless of what 2.0.0 changed, because social embed markup rots on a schedule set by Facebook, not by this repo.

Use it as a reusable block, not a one-off. Define a dedicated widget zone (footer, sidebar, "contact" column) and let editors drop the social widget there on every page template. One place to override, one place to debug.

Pair with Victoire's i18n and zone features. On multilingual sites, configure per locale and confirm the form stores locale-aware values; if it does not, duplicate the widget per locale zone rather than fighting the form.

Extension points, in order of preference:

1. Twig template override — cheapest, safest, survives minor releases.
2. Subclass the widget class and re-register the service — lets you add form fields.
3. Service decoration on the widget service — post-process the configured URL or data before render. Verify the service id against 2.0.0's DependencyInjection/ before wiring this.
4. Fork the bundle — now more attractive given you may need to write your own changelog anyway.

If you are porting the concept to Laravel: the architecture maps cleanly. A Blade partial replaces the Twig template; a settings model or JSON column replaces the widget form; a view composer replaces the widget service. Use a current oEmbed or social-embed library for the markup rather than copying the bundle's template — that is the part most likely to have rotted, and it is the only part worth carrying over.

Gotchas and Tips

• 2.0.0 shipped with no release notes. Treat the tag as unreviewed code. Read the diff, check the constraints, and test one page before committing. An undocumented major bump is a stronger warning sign than an old version number.
• The maintenance picture is still poor. Prior to this tag the project had not released since 2016, with minimal stars and dependents. A new tag without a changelog does not establish active maintenance — it establishes that someone pushed a tag. Assume no support, no security process, and no answers to issues until you see sustained commits.
• Victoire DCMS itself is dormant. Even a perfectly working widget bundle is only as useful as the CMS around it. Verify your Victoire install is viable before investing here.
• The social embed markup is still the most likely breakage. Facebook/Graph API versions and embed SDK behavior have moved on substantially since the original template. If 2.0.0 did not refresh the markup, expect the front end to fail or degrade even when the widget configures and saves correctly. Start debugging in the template, not the widget class.
• Registration failures look like "widget missing from picker." Clear the cache, confirm the bundle is registered before Victoire's widget bundle, and check the service tag. Nine times out of ten it is registration order, a changed service id, or a stale cache — the last two are especially plausible across a major bump.
• Upgrading in place can orphan page data. If 2.0.0 changed form field names or serialization, existing pages will silently render with empty config. Snapshot the page data table before upgrading and compare one edited page afterward.
• Assets are easy to forget. If the widget references CSS/JS from Resources/public, run assets:install (and assetic:dump on older stacks), or the block renders unstyled with no error.
• Template override paths are version-sensitive. Symfony's override directory changed across versions; if your override silently does nothing, you are writing to the wrong path for your Symfony version. Confirm by temporarily editing the vendor template and watching the change appear.
• Do not put credentials or page tokens in the widget form. Config lands in Victoire's page data and may be exposed to editors or in exports. Keep API tokens in application parameters and reference them from your overridden template via a Twig global or a small helper service.
• Treat the repo as a specification, not a dependency. The highest-value use remains reading the widget class to learn Victoire's widget contract, then writing your own small bundle (or Laravel equivalent) with current embed markup — unless the 2.0.0 diff proves a genuine modernization, in which case evaluate adoption on that evidence rather than on the version number.