Grabit Admin Sonata Bundle Laravel Package

Getting Started

grabit-admin-sonata-bundle is a Sonata Admin bundle (Symfony, not Laravel) that gives you a back-office UI for defining and running "grab" configurations — scraping/API sources described by templates. v1.3 is the first release worth onboarding against because the template catalogue is now broad enough to cover the common cases without hand-writing a config from scratch.

First steps:

1. Install the bundle and its Sonata Admin dependency, register it in config/bundles.php, and import the admin services. Confirm the "Grabit" section appears in the Sonata dashboard before touching templates.
2. Open TemplateConfigurationType in the admin — this is the form that materialises a template into a concrete, editable configuration. Read it before reading anything else; it tells you exactly which fields a template can expose.
3. Pick the closest shipped template rather than starting blank:
   • ticketmaster_api — JSON API with auth, good reference for paginated API pulls (docs added in v1.3).
   • francebillet — a second API-flavoured template, useful to diff against ticketmaster_api to see which parts are convention vs. template-specific.
   • php — escape hatch for arbitrary PHP-driven extraction.
   • github_release — small, readable template; the best first read for understanding the template contract end-to-end.
4. First real use case: pick one source you already scrape by hand, model it on github_release or ticketmaster_api, fill in the configuration form, and run it once in a staging environment.

Implementation Patterns

Template-first, config-second. The intended workflow is: choose a template, let TemplateConfigurationType render the fields that template declares, then only fill in values. Resist adding bundle-level config for something a template already parameterises — you lose the upgrade path.

content_replace for output normalisation. v1.3 adds content_replace to TemplateConfigurationType backed by TemplateContentReplace. Use it to strip boilerplate, rewrite relative URLs, or normalise whitespace/encoding at the template level so downstream consumers get clean strings. This is the right layer for it: it runs as part of the grab, so the replacement rules are versioned and visible in the admin alongside the source definition, rather than buried in an application subscriber.

Compose replacements narrowly. TemplateContentReplace is best treated as an ordered list of literal find/replace (or regex, depending on the field options) rules. Keep each rule single-purpose and named after the problem it solves — a 40-rule blob is unmaintainable and impossible to test, whereas ten small rules can be toggled and debugged individually.

New source = new template, contribution-shaped. v1.3 added four templates. If you need a source that isn't covered, write it as a template in your own bundle namespace and register it — that keeps your customisations out of the vendor tree and makes future upstream templates drop-in rather than conflicting. Model the class on github_release for structure and ticketmaster_api for auth/HTTP concerns.

Integration tip for Laravel shops. This is a Symfony/Sonata package; you will not composer require it into a Laravel app. Two realistic patterns: (a) run it as a separate Symfony admin service that writes grabbed content into a shared database or queue your Laravel app consumes; or (b) treat the template classes as a reference implementation and port the template contract into your own Laravel grabber. Option (a) is far less work — do not fork the admin UI to make it Laravel-shaped.

Stagger template adoption. Because this release adds four templates at once, validate them individually against real sources before wiring any of them into a scheduled workflow. A template can be structurally correct and still mis-parse when the upstream markup or API shape has drifted.

Gotchas and Tips

• v1.3 has an opaque commit. 6upgrade (PR #7) is an uninformative commit message on what looks like a dependency/framework bump. Check the diff for composer.json and any constructor signature changes before upgrading, and pin your Sonata Admin version — admin-bundle bumps are the most common source of "the form renders but the field is empty" breakage.
• No changelog detail on template behaviour. The release notes list template names but not their field contracts. Read the template classes directly; do not assume content_replace behaves identically across all five templates.
• content_replace ordering is a real pitfall. Rules apply sequentially, so a URL-rewriting rule placed before a whitespace-stripping rule can produce different output than you expect. When output looks wrong, bisect the rule list rather than rewriting the source config.
• Debugging a bad grab: isolate the layer first — fetch (did the template get bytes?), extract (did fields populate?), transform (content_replace), then persist. Logging the post-fetch, pre-transform payload is usually enough to tell extraction bugs from replacement bugs.
• Templates are a public extension point. If you need a field the template doesn't declare, add it in a template subclass in your own namespace rather than patching the vendor template, or the next release will overwrite you.
• Missing documentation is a gap, not a blocker. Only ticketmaster_api got documentation in this release; francebillet, php, and github_release did not. Budget reading time proportional to template complexity — the php template in particular is the most powerful and least constrained, so treat anything it runs as privileged code and review before enabling it in production.
• Ticketmaster API credentials follow the standard API-template pattern; keep them in environment variables referenced from config, not in the admin-editable fields, so they don't end up in database dumps.
• Version this assessment on v1.3. With no v1.2 assessment to diff against, treat v1.3 as the baseline and re-evaluate when template documentation catches up with the template count.