- Is se/bmecat a Laravel package, and does it work with Laravel 10 or 11?
- se/bmecat is a framework-agnostic PHP object model that serializes BMEcat catalogs to XML, so it has no service provider, facade, config publishing or Artisan commands and is not a Laravel package in the conventional sense. That is fine: it installs via Composer and runs inside Laravel 9, 10 or 11 because it never touches framework internals. Wrap it behind your own exporter service, register that in a service provider, and invoke it from a queued job that writes artefacts to object storage.
- How do I install se/bmecat and generate a basic catalog?
- Install it with composer require se/bmecat from Packagist; it is MIT licensed. You then build catalog, product and feature objects with its builder classes and pass them to the XML serializer to produce the document. On a modern Laravel app expect to fork and widen the PHP constraint first, since the released version targets PHP 7.x.
- Does se/bmecat support PHP 8.1, 8.2 and 8.3?
- The last tagged release is from January 2019, so the Composer constraints almost certainly target PHP 7.x and a clean install on PHP 8.1 to 8.3 will likely fail without a fork. The code surface is thin, so widening the constraint and fixing implicit nullable parameters or dynamic property notices is usually a few days of work rather than weeks. Add a PHP 8.x CI matrix and snapshot tests so the fork stays verifiable.
- Which BMEcat versions does se/bmecat support, 1.2 or 2005?
- The model targets the DACH-region BMEcat standard, which in practice means the 1.2 and 2005 variants consumed by German, Austrian and Swiss distributors, marketplaces and buying portals. The two versions are not identical, so confirm which one your target partner expects before building the mapping layer. Test a representative export against that specific dialect rather than assuming both are fully covered.
- Does the generated XML validate against the official BMEcat XSD?
- There is no evidence of an XSD or DTD validation test suite in the project, so schema conformance is not guaranteed out of the box. Treat acceptance by the target portal as the only meaningful criterion: export a 100-SKU fixture, validate it against the official BMEcat 2005 schema, and ingest it into a partner test environment. Add that validation as a required gate in your fork's CI.
- Does se/bmecat support update and delete transactions like T_UPDATE_PRODUCT and T_DELETE_PRODUCT?
- Support for delta transactions is unverified; the documented focus is generating product catalogs, which typically means full-catalog replacement. If your integration needs T_UPDATE_PRODUCT or T_DELETE_PRODUCT feeds, test this early or plan to extend the object model yourself. Scheduling periodic full-catalog exports is the safer starting assumption.
- Does se/bmecat handle MIME_INFO attachments, classifications like eCl@ss or ETIM, and user-defined features?
- Coverage is undocumented and may be partial, so MIME_INFO attachments, PRODUCT_REFERENCE, classification taxonomies such as eCl@ss, ETIM and UNSPSC, multilingual text and user-defined features should each be verified in the builder classes. Where an element is missing, extend the object model in your fork and lock the behaviour with a golden-file snapshot test. Mapping these fields is usually the bulk of the integration work, not the XML serialization itself.
- What character encoding does se/bmecat output, and should I use UTF-8 or ISO-8859-1?
- BMEcat catalogs are frequently consumed as ISO-8859-1, and UTF-8 output containing umlauts is a classic silent rejection at a buying portal. Check what encoding the serializer emits, make it explicit and configurable, and cover it with a test. Confirm the expected encoding with the actual partner before going live.
- How does se/bmecat perform with large catalogs of 10,000 or 50,000 SKUs?
- The library assembles the catalog as a full in-memory document tree, so large catalogs risk memory exhaustion and long runtimes. Measure at 10k and 50k SKUs on your own hardware rather than guessing, and always run exports in queued jobs that write to object storage instead of inside a web request. If memory is the bottleneck, chunk exports or stream the serializer in your fork.
- Is se/bmecat still maintained, and should I fork it or write my own serializer?
- The repository is archived with around six stars and no dependents, so there is no bug triage, security patching or community support and you become the maintainer on day one. Because the API is small and the library touches no framework internals, forking under your own organization is a days-not-weeks job and does not constrain your Laravel or PHP upgrade path. For most teams that is cheaper and lower risk than writing a BMEcat serializer from scratch.