Configuration

Overview

Configuration for Pyle is separated into individual files under config/pyle. You can either override the different config options adhoc or you can publish all the configuration options and tweak as you see fit.

php artisan vendor:publish --tag=pyle

Database Table Prefix

pyle/database.php

So that Pyle tables do not conflict with your existing application database tables, you can specify a prefix to use. If you change this after installation, you are on your own - happy renaming!

    'table_prefix' => 'pyle_',

Database Connection

pyle/database.php

By default, the package uses the default database connection defined in Laravel. Here specify a custom database connection for Pyle.

'connection' => 'some_custom_connection',

If you are using a custom database connection that is not the default connection in your Laravel configuration, you need to specify it in the .env file as well.

ACTIVITY_LOGGER_DB_CONNECTION=some_custom_connection

In our package, we utilize Spatie's laravel-activitylog for logging. The mentioned configuration allows the activity logger to use a different database connection instead of the default database connection.

Orders

pyle/orders.php

Here you can set up the statuses you wish to use for your orders.

'draft_status' => 'awaiting-payment',
'statuses' => [
    'awaiting-payment' => [
        'label' => 'Awaiting Payment',
        'color' => '#848a8c',
    ],
    'payment-received' => [
        'label' => 'Payment Received',
        'color' => '#6a67ce',
    ],
],

Media

pyle/media.php

Transformations for all uploaded images.

'transformations' => [
    'zoom' => [
        'width' => 500,
        'height' => 500,
    ],
    'large' => [
        // ...
    ],
    'medium' => [
        // ...
    ],
    'small' => [
        // ...
    ],
],

Products

config/admin-panel.php

'disable_variants' => false,
'sku' => [
    'required' => true,
    'unique'   => true,
],
'gtin' => [
    'required' => false,
    'unique'   => false,
],
'mpn' => [
    'required' => false,
    'unique'   => false,
],
'ean' => [
    'required' => false,
    'unique'   => false,
],

Storage Disks

config/pyle.php

Defines the default filesystem disks used by imports, exports, generated files, media uploads, and data feed connectors.

'default_private_disk' => env('DEFAULT_PRIVATE_DISK', 'private'),
'default_public_disk' => env('DEFAULT_PUBLIC_DISK', 'public'),
'default_spaces_disk' => env('DEFAULT_SPACES_DISK', 'private'),
'excel_import_export_file_disk' => env('EXCEL_IMPORT_EXPORT_FILE_DISK', env('DEFAULT_PRIVATE_DISK', 'private')),
'datafeed_disk' => env('DATAFEED_DISK', env('DEFAULT_PRIVATE_DISK', 'private')),

Key	Default	Purpose
default_private_disk	private	The filesystem disk used for private generated files, reports, quote PDFs, imports, exports, and data feed files.
default_public_disk	public	The filesystem disk used for public media such as product images and documents.
default_spaces_disk	private	The filesystem disk used for Spaces-style shared files when an app needs a separate disk.
excel_import_export_file_disk	default_private_disk	The filesystem disk used to store Excel import and export files.
datafeed_disk	default_private_disk	The filesystem disk (defined in config/filesystems.php) where data feed files are stored after download.

Set DATAFEED_DISK in your .env file to override the default:

DATAFEED_DISK=local

When upgrading from legacy disk names (s3, floorbox-admin-s3, or s3-bucket), the framework migration 2026_06_02_120000_standardize_private_disk_names.php updates excel_imports.file_disk and excel_exports.file_disk to pyle.default_private_disk.

Model Overrides

config/pyle.php

Registers application model overrides that the manifest resolves at boot time. Each key is either the framework contract class or the framework model class; the value is the application class that should be used in its place.

'overrides' => [
    'models' => [
        \CBOX\Framework\Models\Contracts\Order::class => \App\Models\Order::class,
    ],
],

Convention-based overrides (an App\Models\X that extends CBOX\Framework\Models\X) are discovered automatically and do not require an entry here. See Extending Models for the full registration guide.

Command Overrides

config/pyle.php

Registers direct framework console command overrides resolved by the framework command manifest. Each key is the framework command class, and the value is the application command class that should replace it.

'overrides' => [
    'commands' => [
        \CBOX\Framework\Console\Commands\InstallDependenciesCommand::class => \App\Console\Commands\InstallDependenciesCommand::class,
    ],
],

Each override class must be the same framework command class or extend the framework command it replaces.

Use pyle.overrides.commands only for direct framework console commands. Action-backed command overrides belong in pyle.overrides.actions, and application-owned commands should be registered by the application through Laravel's normal command registration flow (for example, Laravel Actions command registration). CommandManifest no longer reads generated bindings.commands.

Mail Overrides

config/pyle.php

Registers application mailable overrides resolved by the mail registry. Each override key is the framework mailable class, and the value is the application mailable class. The application mailable must extend the framework mailable it replaces.

'overrides' => [
    'mails' => [
        \CBOX\Framework\Mail\ForCustomer\OrderConfirmationEmail::class => \App\Mail\ForCustomer\OrderConfirmationEmail::class,
    ],
],

Create framework mailables with FrameworkMail::make(...) or app(FrameworkMail::class, [...]) so configured overrides are honored. Use FrameworkMail::resolvedClass() only when a Laravel or package API requires a class string. Do not use generated mail bindings, CBOX::mail(...), or direct new FrameworkMail(...) in new code.

Pricing

pyle/pricing.php

If you want to store pricing inclusive of tax then set this config value to true.

'stored_inclusive_of_tax' => false,