Form Color Picker

Documentation location: Form Views → Form Fields.

The native Form View field type is exactly colorPicker, with a capital P. This differs from the Table View's lowercase colorpicker. Use option type H to load the color-picker CSS and JavaScript. For an Add form use FAH: F enables the form, A selects the native INSERT action, and H enables the picker. A normal submitted form does not need L. Use FUH for a normal Update form.

Complete Add form example

This example uses placeholder section/page names and an existing EXAMPLE_ITEMS table with ITEM_ID, NAME, and COLOR columns. Adapt them to your actual schema and registration. The visible ITEMS page must be registered before routing back to it. The non-menu ADD ITEM page has no normal-menu entry.

Link to the non-menu page with:

getPath('EXAMPLE', 'ITEMS', 'ADD ITEM', 'FAH');

In kas/includes/EXAMPLE/ADD_ITEM.php:

$dbtable = 'EXAMPLE_ITEMS';
$idfield = 'ITEM_ID';
$case_title = 'ADD ITEM';
$message = 'Item created successfully';
$nexturl = getPath('EXAMPLE', 'ITEMS', 'ITEMS');
$form = 'open';
include('core/form_view.php');

addField([
    'type' => 'text',
    'label' => 'NAME',
    'name' => 'NAME',
    'attributes' => 'required'
]);
addField([
    'type' => 'colorPicker',
    'label' => 'COLOR',
    'name' => 'COLOR',
    'value' => '#000000',
    'attributes' => 'required maxlength="7" pattern="#[0-9A-Fa-f]{6}"'
]);
addField('button', 'add', 'ITEM');
$form = 'close';
include('core/form_view.php');

Use translate() for labels and messages in application pages; the literal labels here keep the example short. Use the translation conventions supported by the current KAS Core API.

Field properties

name is the submitted database column and also becomes the default input id. label is the visible label. value sets the initial color; for an Edit form it can be the stored database value. Prefer the default id matching name; the native preview lookup uses the input ID while the rendered preview box uses its name. Use distinct field names for multiple pickers. attributes, class, and style affect the text input. blockClass and blockStyle affect its surrounding block. privilege uses the standard form field visibility handling. The field emits a native preview box (showColor_ followed by the field name).

Legacy syntax remains supported:

addField('colorPicker', 'COLOR', 'COLOR', '#336699');

Value format and save behavior

Supply and store a six-digit hexadecimal CSS color, for example #336699. Core removes hashes from the supplied initial value and renders one leading hash; the native picker writes # plus six hexadecimal digits on selection. A blank initial value renders #, so supply a valid initial color for a required Add field. Core does not independently validate the hex format on the server; the example's required, maxlength, and pattern attributes provide browser validation.

Selecting a color updates the input and preview. It does not immediately write to the database. The standard form submission saves the field with the other inputs. $nexturl must be set before opening the form; native Form View emits it as a hidden input, and native save handling returns to the requested page after success.

Implementation: kas/core/formFields.php (case 'colorPicker'), kas/core/header.php, kas/core/header/option_types.php, kas/js/colorpicker.js, and kas/core/form_view.php.

Initialize newly deployed sections

After deploying a new or changed section definition in kas/core/init_sections.php, log out and open /kas/init on that installation. Accept the native section re-installation confirmation, wait for the login page, and sign in again before testing the menu and routes. Run initialization on each target KAS installation after deploying its section definitions. Source definitions alone do not create installation menu records. A non-menu Add page uses its Core file and explicit getPath option string and intentionally has no normal-menu record.

See How to Create a new KAS section for the required initialization workflow.