- What is Dashed Ecommerce Core and what does it include?
- Dashed Ecommerce Core is a Laravel Composer package that supplies the foundational domain layer for an online store. It covers catalog management for products, variants and pricing, cart and checkout abstractions, order lifecycle and status handling, plus extensible contracts and events for custom business logic. It also ships Laravel-native models, migrations and configuration. It is a domain layer rather than a complete storefront or admin application.
- How do I install Dashed Ecommerce Core in a Laravel application?
- Install it with composer require dashed/dashed-ecommerce-core in a Laravel project. The service provider is auto-discovered, so the next step is publishing the config and migrations with vendor:publish and then running php artisan migrate. From there you bind or override the package contracts in your own service provider to plug in your business rules.
- Which Laravel and PHP versions does Dashed Ecommerce Core support?
- The package is built around modern Laravel conventions, and typical evaluations target Laravel 10, 11 or 12 with PHP 8.2 and above on MySQL 8 or PostgreSQL. Because the supported version matrix is defined in composer.json, check those constraints against your application before committing. Also confirm the CI status against your current Laravel LTS.
- Does Dashed Ecommerce Core include an admin panel or storefront UI?
- No. The package provides the commerce domain primitives such as models, migrations, configuration, contracts and events, not user interfaces. You build the storefront and admin surface yourself, using Blade or Livewire in the same app or a separate API and SPA. This keeps the core headless-friendly but means front-end work is entirely your responsibility.
- Does Dashed Ecommerce Core handle payments, tax and shipping out of the box?
- It exposes abstractions and contracts intended for payments and fulfillment rather than shipping concrete gateway implementations. Tax calculation, shipping rates and payment provider integration are edges you own and implement against those contracts. Verify in the source whether a gateway interface exists or whether you need to wrap the order pipeline with your own services.
- How is money represented and does it support multiple currencies?
- This cannot be determined from the package metadata alone, so audit the source before using it with real transactions. Check whether prices and order totals are stored as integer minor units or as floats, since floats introduce rounding risk in carts and refunds. Multi-currency and tax-inclusive pricing support should also be verified explicitly in the models and migrations.
- Can I extend or override the product, cart and order models?
- The package is described as extensible, with contracts and events designed for custom business logic, so overriding models and swapping repositories in a local service provider is the intended integration path. You can hook into the checkout and order pipeline through events instead of editing vendor code. How much of the internals is truly contract-driven versus tied to concrete classes needs to be read from source before you plan the work.
- Is Dashed Ecommerce Core production-ready?
- Treat it with caution. It has effectively zero stars and zero dependents, which means no public battle-testing and no community answers when something breaks, and the release timestamp metadata appears future-dated, so the cadence signal is not trustworthy until verified on Packagist. It is MIT licensed, so forking is an option, but plan to own maintenance and audit the cart, order state transitions and inventory logic line by line.
- What other DashedCMS packages does Dashed Ecommerce Core depend on?
- Core packages in a CMS ecosystem frequently pull in siblings such as admin, payment driver or media packages. Check the composer.json require block and the published config to see which DashedCMS packages are hard dependencies versus optional integrations. Each additional unproven dependency multiplies your audit surface, so pin and review them individually.
- Do the migrations namespace their tables and can they be rolled back?
- Inspect the published migration files before running them in an existing database. Confirm that tables and config keys are prefixed or otherwise namespaced so they do not collide with your application's own tables. Also check that each migration is additive and reversible, since commerce tables hold financial records you will not want to drop casually.