- What is bagisto/bagisto-standard, and is it a Composer library I can install into an existing Laravel app?
- bagisto/bagisto-standard is the Composer project skeleton for a self-hosted Bagisto storefront, comparable to laravel/laravel for a Laravel application. It is not a package you require into an existing codebase: there is no integration path into your own app. You adopt it as the starting point for an entire store, or you do not adopt it at all. If you only want the ecommerce features, install the maintained Bagisto distribution instead.
- Is bagisto/bagisto-standard still maintained?
- No. The repository is archived, has roughly 10 stars and zero dependents, and its last release was on 2020-07-06, whose only published change was a composer install fix. Treat it as a reference template rather than a maintained baseline. An archived dependency means your team owns every future fix, security patch, and upgrade.
- Which PHP and Laravel versions does bagisto-standard require?
- This snapshot is pinned to PHP 7.x with Laravel 7 to 8 era constraints, so it will not install cleanly on a modern PHP 8 stack. Its Node build toolchain also relies on node-sass binaries that fail on current Node versions. Current Bagisto releases support modern PHP and Laravel versions, so confirm upstream requirements before planning a build.
- How do I install bagisto/bagisto-standard?
- Create the project with Composer from the repository, copy the environment file, set your database credentials and app URL, run the migrations and seeders, then build the frontend assets. Expect the asset build to need a legacy Node version because of the old node-sass dependency. Because the packages/Webkul modules ship in-tree rather than in vendor, treat your composer.lock as sacred and avoid blind composer update runs.
- Should I use bagisto-standard or the maintained bagisto/bagisto distribution for a new store?
- For a new store, scaffold from the maintained Bagisto distribution and pin your versions; use bagisto-standard only to read the shape of the application. It is genuinely useful as a reference, since the catalog, checkout, admin datagrids, ACL nodes, and Concord contracts show how the platform is assembled. It is not defensible as a production baseline given its age and archived status.
- Does Bagisto support multi-channel, multi-currency, and multi-locale stores?
- Yes. Bagisto ships multi-channel, multi-currency, and multi-locale scaffolding across the catalog, pricing, and checkout layers. Before enabling it, decide whether the business actually needs that channel dimension, because it gets applied to almost every query and carries ongoing complexity. Adding it later is far cheaper than carrying capability you never exercise.
- Do I need Elasticsearch and queue workers to run Bagisto in production?
- Assume you do. Queue workers are not optional: indexers, mail, and integration listeners all expect a running worker. Catalog search also degrades sharply without Elasticsearch or OpenSearch once you pass a few thousand SKUs, so that infrastructure decision must land before the catalog import, not after performance complaints. Provision MySQL, Redis, and a supervised queue process as part of your baseline.
- How do I integrate Bagisto with an ERP, PIM, or payment provider?
- Integrations are a separate build against Bagisto's events and contracts, not something the skeleton provides. Payment and shipping methods extend abstract base classes with clear seams for authorize, capture, refund, and per-carrier rate calculation, and order, shipment, and refund events give you an ERP and analytics path that does not touch the revenue path. Note that payment webhooks are public, CSRF-exempt routes and belong on your security review list, and that 2020-era payment SDKs need a deliberate patch cadence.
- How do I test a Bagisto store before going live?
- Plan for staged and automated checks rather than relying on the skeleton: exercise checkout, tax, shipping, and refund flows against your payment and carrier sandboxes. Run the queue worker and search engine in every test environment, because behaviour differs sharply without them. Verify the frontend asset build on your CI Node version early, since the legacy toolchain is a common failure point.
- What are the alternatives to bagisto/bagisto-standard for Laravel ecommerce?
- Within Laravel, the closest comparisons are Aimeos, Lunar, and Vanilo, alongside the maintained Bagisto distribution itself; outside PHP there is Sylius and hosted platforms such as Shopify. Choose based on whether you want to own the commerce stack and extend a monolith, or call a managed service from your channels. Either way, decide early whether commerce is something you extend or something other apps call, because retrofitting that boundary is the most expensive refactor in the codebase.