Configuration.

php artisan vendor:publish --tag=custom-fields-config

The package works with the file unpublished. Publish it to change a tenant resolver, a table name, the model key type, or write-time validation.

return [

    'tenant_resolver' => null,

    'tables' => [
        'definitions' => 'custom_field_definitions',
        'values' => 'custom_field_values',
    ],

    'model_key_type' => env('CUSTOM_FIELDS_MODEL_KEY_TYPE', 'int'),

    'validate_on_write' => env('CUSTOM_FIELDS_VALIDATE_ON_WRITE', true),

];

tenant_resolver

The class that answers which tenant the application is acting for. It must implement ByRcsc\LaravelCustomFields\Contracts\TenantResolver, and it is resolved from the container, so it may take constructor dependencies.

null means detect: SpatieTenantResolver when spatie/laravel-multitenancy is installed, and NullTenantResolver, which treats every definition as global, when it is not. That is the right answer for both, so most applications never touch this key.

Name a class to override the detection:

'tenant_resolver' => App\Tenancy\SubdomainTenantResolver::class,

A spatie application that wants one shared set of fields rather than a set per tenant names ByRcsc\LaravelCustomFields\Tenancy\NullTenantResolver here.

A value that is not a resolver throws InvalidTenantResolverException the first time the resolver is needed, naming the config key. It is checked then rather than at boot, so a misconfigured application still boots and the failure is readable. See tenant scoping.

tables

'tables' => [
    'definitions' => 'field_definitions',
    'values' => 'field_values',
],

Rename these to fit your schema conventions. The models and the shipped migrations read the same values, so nothing else changes.

Set them before migrating. Renaming a table that already holds definitions or values takes a migration of your own, and the package's own migration will not do it for you.

Both tables carry explicitly named indexes built from the table name, rather than names Laravel generates from every indexed column. A generated name for the unique index runs past MySQL's 64-character limit on the default table name alone, and PostgreSQL truncates at 63 without saying so. A long custom table name can still reach those limits.

model_key_type

The key type of the models custom field values are attached to. It shapes the model_id column on the values table:

Anything else throws an InvalidArgumentException while the migration runs.

Set it before running the migration. Changing it afterwards takes a migration of your own. One key type covers the whole installation, since the values table holds rows for every model you add the trait to, so pick string if you genuinely mix key types.

Reads CUSTOM_FIELDS_MODEL_KEY_TYPE from the environment.

validate_on_write

Whether writing a custom field through the trait validates the value against the field's rules first, throwing Laravel's ValidationException when it fails.

On by default, because the alternative is a field whose rules only apply on the surfaces that remember to ask for them. Turn it off when the application validates every write itself with the generated rules and would rather not pay for the check twice:

'validate_on_write' => false,

Type coercion is a separate layer and always runs. A value the field cannot store throws InvalidValueException whichever way this is set. See validation.

Reads CUSTOM_FIELDS_VALIDATE_ON_WRITE from the environment, so it can be turned off in a seeding or migration environment without changing the file.

Publishing tags

What to read next

• Installation and setup for the order these are set in.
• Tenant scoping for what the resolver changes.
• Validation for what validate_on_write turns off.