Feature: Adding Custom Fields to Products
This commit is contained in:
@@ -0,0 +1,40 @@
|
||||
<?php
|
||||
|
||||
use Illuminate\Database\Migrations\Migration;
|
||||
use Illuminate\Database\Schema\Blueprint;
|
||||
use Illuminate\Support\Facades\Schema;
|
||||
|
||||
/**
|
||||
* Per-product, customer-authored input fields — a personalized-statue
|
||||
* product needing a reference photo upload and an optional engraving
|
||||
* textarea, for example. Deliberately NOT modeled as a Lunar ProductOption
|
||||
* (see Modules\Core\Catalog\Contracts\ProductOptionTypeInterface's own
|
||||
* docblock): an option's values are a fixed, admin-authored list that
|
||||
* define variants (Red/Green/Blue) — a photo upload has no such list, it's
|
||||
* unique per order, and creates no variant at all. This is a genuinely
|
||||
* different concept that happens to configure on the same product page.
|
||||
*
|
||||
* Array of {key, type: 'text'|'textarea'|'file', label, required} — `key`
|
||||
* is what a submitted answer is keyed by in CartLine/OrderLine.meta (both
|
||||
* already have a `meta` json column — see Modules\Core\Cart\Services\
|
||||
* CartService::addLine()'s own $meta parameter), not a new table, since
|
||||
* this is small, rarely-queried per-product config, the same reasoning
|
||||
* ShippingMethod.data/PaymentMethod.data already follow for their own
|
||||
* per-row settings.
|
||||
*/
|
||||
return new class extends Migration
|
||||
{
|
||||
public function up(): void
|
||||
{
|
||||
Schema::table(config('lunar.database.table_prefix').'products', function (Blueprint $table) {
|
||||
$table->json('custom_fields')->nullable()->after('attribute_data');
|
||||
});
|
||||
}
|
||||
|
||||
public function down(): void
|
||||
{
|
||||
Schema::table(config('lunar.database.table_prefix').'products', function (Blueprint $table) {
|
||||
$table->dropColumn('custom_fields');
|
||||
});
|
||||
}
|
||||
};
|
||||
Reference in New Issue
Block a user