Descommarket Feeds Laravel Package

Getting Started

Start by installing the package and publishing its config, since almost everything in a feed package is driven by configuration rather than by writing feed XML by hand:

composer require descom/descommarket-feeds
php artisan vendor:publish --tag=descommarket-feeds-config

Then read, in this order:

1. The published config file — this is the real entry point. It will define the feed "channels" (Google Shopping, Facebook Catalog, Idealo, etc.), the storage disk, the output format, and the model/query each feed is built from.
2. The service provider — check what it registers (commands, routes, bindings, facades). That tells you whether you drive the package via Artisan, HTTP, or both.
3. The commands directory — a feed package almost always exposes something like php artisan feed:generate {name}. That command name is your fastest path to a first successful run.

Your first real use case should be the smallest possible end-to-end loop: point one feed at a single Eloquent model (e.g. Product), map three or four fields (id, title, price), generate it, and open the output file. Do not start by mapping every attribute — get one feed rendering, confirm the file lands on the right disk and is publicly reachable, then expand the mapping.

If the README is thin (likely, given the package's age and adoption), treat the source as the documentation. Grep for config( and class ... extends to find the extension points before writing any custom code.

Implementation Patterns

Config-driven feed definitions. The intended pattern is to declare each marketplace feed in config and let the package handle serialization and delivery. Keep these definitions in config/descommarket-feeds.php (or split into per-channel files and merge), and keep the mapping logic declarative — field name to model attribute or closure.

Scheduled regeneration. Feeds are stale the moment a price or stock level changes. The standard workflow is to schedule the generation command and let it rebuild on a cadence appropriate to the marketplace:

// routes/console.php or Kernel::schedule()
$schedule->command('feed:generate google')->hourly()->withoutOverlapping();
$schedule->command('feed:generate facebook')->dailyAt('03:00');

Use withoutOverlapping() — feed generation on a real catalog routinely outlives the interval.

Model-level mapping via accessors or a dedicated presenter. Rather than stuffing feed formatting into config closures, expose feed-ready values on the model (or a small DTO/presenter) and reference those. This keeps currency formatting, image URL resolution, and availability logic testable outside the feed pipeline.

Multi-channel with a shared product source. One query/scope feeds many channels; only the attribute mapping differs. Define a single "feedable products" scope (published, in stock, has image) and reuse it across every channel config so you never ship a channel that includes drafts.

Storage and delivery. Publish to the public disk and let the marketplace pull the URL, or write to a private disk and push via SFTP/API if the package supports a destination driver. Prefer the pull model where possible — no credentials to rotate.

Invalidation hooks. Wire model events (saved, deleted on Product) to mark a feed dirty, and have the scheduled command regenerate only dirty feeds. This is the difference between a feed that runs every hour regardless and one that runs only when something changed.

Testing. Assert on the generated artifact, not on internal calls: generate a feed with a handful of factory products, then parse the XML/CSV and assert on rows and required attributes. Snapshot the output so mapping regressions surface as diffs.

Gotchas and Tips

• Memory and timeouts on real catalogs. Even modest catalogs (10k+ SKUs) will blow past default PHP limits if the generator hydrates everything at once. Look for chunking support in the source; if it is not there, constrain the query and run per-category or per-vendor batches.
• Zero stars means zero Stack Overflow answers. Every non-obvious behavior must be answered from the source. Budget time for reading it, and pin the version in composer.json (exact or ~) so a patch release does not silently change your output schema.
• Marketplace validation is strict and unforgiving. Missing gtin, a price without currency, a relative image URL, or a shipping block absent for a required country will get the whole feed rejected — often with an error that does not name the offending row. Validate locally against the marketplace's spec before uploading.
• Image URLs must be absolute and publicly reachable. The most common silent failure is generating correct data with http://localhost or a signed/expiring URL baked in. Resolve image URLs through Storage::disk(...)->url() or a configured CDN base, never asset() in a queued context.
• Escaping and encoding. XML feeds break on unescaped & in product titles and on invalid UTF-8 from supplier imports. If the package's serializer does not escape for you, sanitize at the mapping layer.
• Currency and locale are per-feed, not per-app. Do not assume config('app.currency'). Each channel config should carry its own currency and locale, and prices should be formatted from integers/minor units rather than floats.
• The "last release" date is not a maturity signal. Verify the package actually boots against your Laravel version before building on it — check the illuminate/* constraints in composer.json. If it targets an older major, expect to fork or shim the service provider.
• Debugging checklist when a feed is empty or malformed: confirm the query returns rows outside the package, confirm the disk is configured and writable, confirm the scheduled command is actually registered (php artisan schedule:list), and check whether the package swallows exceptions during row mapping — silent per-row failures are common and produce a valid-looking feed with missing entries.
• Extension points to look for: a field-transformer/resolver interface, a custom source/destination driver contract, and events fired around generation. If these exist, prefer them over editing the published config with closures; closures in config are not cacheable and not testable.
• Do not run generation inside a web request. A visitor triggering a feed rebuild will time out and may corrupt a partially written file. Always write to a temp path and move into place, or generate in a queued job.