Bagisto Bulk Upload Laravel Package

Product Decisions This Supports

• Prioritising catalog operations as a real merchant need, not a checkbox. Bulk CSV/XLS import is the difference between a merchant onboarding that takes days of manual data entry and one that lands in an afternoon. This package is a running reference for that workflow: admin upload UI, field/category/attribute mapping, image handling, row-level validation, and SKU-based create-or-update. If catalogue onboarding, supplier migration, seasonal price/stock refreshes, or staging-store resets are anywhere on the roadmap, this is evidence that a bulk-import capability is table stakes rather than a nice-to-have.
• Framing the build vs. fork vs. buy decision with real numbers. The package is MIT-licensed with zero dependents and an archived upstream, so the realistic choice is not "adopt" but "fork, vendor, and own" — or "use it as a spec and build a thin importer on maatwebsite/excel driving Bagisto's ProductRepository." A short time-boxed spike against this codebase prices all three options far more cheaply than a blank-page estimate.
• Sizing the self-serve path inside the catalogue epic. Import/export is a prerequisite for several downstream roadmap items: self-serve merchant onboarding, PIM/ERP sync, multi-store expansion, and paid migration services. Deciding how much of that is self-serve tooling versus white-glove service is a product call, and this package bounds the cost of the self-serve branch.
• Forcing explicit scope decisions the package surfaces — and constrains. Its column-mapping model (attributes must exist, belong to the chosen attribute family, and are often whitelisted) tells you exactly how much configuration surface you must expose: attribute-family selection, channel/locale scope, product-type and parent-SKU handling for configurables, category-before-product ordering, and image/media handling. Each is a decision about what the merchant sees versus what is hidden behind a sane default.
• Making the segment and monetisation trade-off deliberately. A reliable importer reduces onboarding friction for long-tail merchants (where manual migration isn't economic) while potentially cannibalising a paid "we migrate your catalogue" service. That cannibalisation should be a decision, not a post-launch discovery.
• Defining success metrics up front. Time-to-first-catalogue, import success rate, partial-failure rate, rows processed per minute, support tickets per import, and the share of imports needing manual remediation. These are the levers that tell you whether the importer is genuinely self-serve or quietly becoming a support queue — and they should be instrumented before the first merchant touches it.
• Calibrating how much roadmap weight to give it. 24 stars, zero dependents, archived, last release January 2024, low opportunity score. Read this as a tactical accelerator worth weeks of head start, not a strategic platform bet worth years of dependency. The decision record should say so explicitly.

When to Consider This Package

Consider it only when all of the following hold:

• The storefront is Bagisto, on the version line the package actually targets — the documentation and the v1.3.3 release note point at the Bagisto 1.x / Laravel 8–9 era. If you are on Bagisto 2.x, the admin surface and package layout have moved and this will not drop in cleanly.
• You need CSV-driven product create/update by SKU from the admin panel, with validation and per-row error reporting, and you need it soon — a pilot, an MVP, or a migration deadline.
• Your catalogue is small-to-moderate and imports can run synchronously or under a simple chunked queue. You are not importing 100k+ SKUs with media on day one.
• You can accept default channel/locale landing for imported values and handle multi-store specifics programmatically afterwards.
• You have — or will name — an internal owner. Archived status means maintenance, compatibility work, and security patching transfer entirely to you. Budget for a fork, a pinned dependency set, CI coverage, and a decision record explaining why the fork exists and when it retires.
• MIT licensing fits your legal posture and forking is acceptable to the organisation.

Look elsewhere when:

• You are not on Bagisto, or not on a compatible Bagisto version. Decoupling it from Bagisto's admin, product models, and repositories costs more than writing a thin importer against Laravel Excel.
• Bagisto core already ships bulk import in your version — then this package is redundant and a pure maintenance liability. Verify this before anything else.
• You need vendor support, SLAs, or security patching on a published cadence. There is none, and the community surface is negligible.
• You need true idempotent upserts at scale, granular multi-channel/multi-locale import, configurable-product association in a single pass, or custom attribute logic the mapper does not whitelist. The known pattern is to read the file yourself with maatwebsite/excel and drive ProductRepository from a queued job.
• File-upload security is compliance-scoped for you: CSV formula injection, oversized XLS, zip bombs, and remote media URLs all need controls this package does not credibly provide.
• You need XLS at volume. PhpSpreadsheet loads whole workbooks into memory; CSV should be the default and XLS converted on ingest.
• You operate a multi-tenant or multi-store SaaS needing per-tenant isolation, audit trails, and rollback guarantees the module's results-log model does not offer.

How to Pitch It (Stakeholders)

For executives. Bulk import is one of the highest-leverage operational features in a commerce platform: it converts merchant onboarding from a services cost into a self-serve capability. This package offers a genuine head start on that workflow — an admin UI, CSV import, SKU-based create-or-update, and row-level validation — under a permissive MIT licence, so there is no procurement or licensing cost. The honest framing is accelerator, not platform: the upstream is archived, adoption is minimal (24 stars, zero dependents), and there will be no future compatibility or security work from the authors. Recommend a short time-boxed spike to confirm version fit and check whether Bagisto core already covers this, then a fork-and-own plan with named ownership, a hardened fork as the deliverable, and explicit exit criteria. Expect roughly one to two weeks to validate and three to four weeks to harden for production; the dominant lifetime cost is internal maintenance, not acquisition. Building the same importer from scratch is a comparable or larger effort with no head start.

For engineering. Treat this as a Bagisto feature module to vendor, not an independent dependency. Confirm the bagisto/bagisto and laravel/framework constraints against our stack first; if we are on 2.x, stop. Fork into an internal namespace, pin Composer dependencies and the lock file, and wrap the import entry point behind an internal service or adapter so the admin UI and import engine stay separable and replaceable. Prefer Bagisto's repository/service contracts over direct model writes so events and validation still fire. Add CI covering install, route registration, small import, large import, malformed file, duplicate SKU, and rollback. Harden in this order: file-size and type validation below php.ini limits, CSV formula-injection controls, header normalisation (BOM, whitespace, casing), duplicate and missing-SKU handling, explicit transaction boundaries, then queued and chunked processing with isolated media handling. Define failure behaviour per case — reject the file, skip the row with a report, or roll back the batch — because silent partial success is the most damaging outcome for catalogue integrity. Budget a knowledge-transfer walkthrough: the code is Bagisto-specific and there is no upstream to ask.

For operations and support. Admin ramp-up is modest if we keep the UI. Users need documented accepted formats, the authoritative sample column spec, required fields per attribute family, file-size limits, and a clear answer to "what do I do when an import half-succeeds?" Provide a runbook covering error codes, the results log, retry procedures, and escalation, plus monitoring on failure rates and queue health. Set expectations that imported values typically land on the default channel and locale, with follow-up work required for other stores.

Risks to state plainly. Archived upstream, no security patching, low ecosystem validation, version-sensitive compatibility, synchronous-import resource spikes, and the possibility that Bagisto core later absorbs this capability and renders the fork redundant. Each has a mitigation in the plan above, and the decision record should name the trigger for retiring the fork in favour of core functionality or a first-party importer.