How to Create a new KAS section

KAS Sections

Required after deploying new or changed KAS sections

Editing kas/core/init_sections.php defines the section in source. It does not create the installation's menu and option records until KAS is initialized.

  1. Deploy the new section files and the updated init_sections.php to the intended installation.
  2. Log out of KAS. Open https://YOUR-INSTALLATION/kas/init while logged out. Run initialization on each target KAS installation after deploying its section definitions.
  3. Accept the native confirmation that KAS sections will be re-installed. Wait for initialization to complete and return to the login page.
  4. Sign in again. Verify the new section under its intended menu/submenu, then test its native routing and controls.

Initialization uses KAS's existing section/menu architecture to create the records from the definitions. The route is rewritten to kas/index.php?init=true. Run it on each installation receiving the change; initializing one installation does not update other installations.

A non-menu Add page is different: create its Core PHP file under the registered main section and link to it with getPath() and its explicit option string. For example, getPath('SECTION', 'SUBSECTION', 'ADD ITEM', 'FAH') opens the native Add form. It intentionally has no normal-menu option record. A registered menu page still requires initialization after its section definition is deployed.

Example section, subsection and page names are placeholders. Use the names from your actual KAS section registration and the matching Core page filename.

Creating KAS sections

Use normal registration for a page that belongs in the administrator menu. Source: init_sections.php builds the architect object; architect.class.php defines registration methods; option_types.php interprets options.

Registration pattern

In init_sections.php, reuse the existing section/subsection objects when adding a page to an existing hierarchy. This example creates a generic hierarchy; names, privileges and schema are examples to adapt, not new required built-in sections:

$CATALOG = $KAS_SECTIONS->addSection([
    'name' => ['en' => 'CATALOG', 'es' => 'CATALOGO', 'fr' => 'CATALOGUE'],
    'icon' => 'document', 'privilege' => 4
]);
$CATEGORIES = $CATALOG->addSubSection([
    'name' => ['en' => 'CATEGORIES', 'es' => 'CATEGORIAS', 'fr' => 'CATEGORIES'],
    'privilege' => 4
]);
$CATEGORIES->setOption([
    'name' => ['en' => 'VIEW CATEGORIES', 'es' => 'VER CATEGORIAS', 'fr' => 'VOIR CATEGORIES'],
    'privilege' => 4, 'type' => 'VRNLH'
]);

Array registration is the current architect API. Legacy comma-separated names and positional signatures remain compatible; setOption's icon parameter is deprecated. Choose the privilege for the real page rather than assuming the example's 4 is universal.

For a Core main section, VIEW.php loads kas/includes/<ENGLISH_MAIN_SECTION>/<ENGLISH_PAGE_NAME_WITH_UNDERSCORES>.php; a matching project theme override can replace it. These angle-bracket names are placeholders, not existing files. menu_config.php controls Core section classification: when introducing a new main section, inspect its existing Core-name marking logic as well as registration.

Options used by these guides

Option Meaning
V Table View
R / N Search / pagination
L / H Live editing / color-picker assets; independent flags
F / A / U Form / INSERT / UPDATE
B Category filter
P Row-position sorting, not header-column sorting

Letters are case-sensitive and tested independently. Define only the supported behavior the page needs. Source comments can be older than actual option handling; inspect option_types.php.

Source registration alone does not create menu records. Follow initialization after deployment and updater registration for new Core files. For hidden Add/Edit pages, use non-menu sections, not duplicate menu entries.

Hierarchy and landing option

Provide en/es/fr names: initialization reads all three keys. The hierarchy is main section → subsection → menu option. Keep the returned objects and call each child API on its parent. setOption requires name and type; its array supports privilege (default 5) and main (default false). Set 'main' => true on the intended landing option: the main-menu renderer selects MAIN=1 ordered by KSMOID. Avoid competing main options when defining a single landing page. The legacy fifth positional argument is the same main flag. addSection supports required (default 1); choose it deliberately for optional sections. Existing Core-name classification in menu_config.php is separate from the architect name.

Project/theme registration

Core includes kas_root("/themes/$theme/_SECTIONS.php") during registration. kas_root() prepends the configured KAS directory, so the default physical location is kas/themes/<theme>/_SECTIONS.php, not the public-site themes directory. The active KAS theme registration file receives the existing $KAS_SECTIONS object. Use the same addSection → addSubSection → setOption API there for project-owned sections, with generic names adapted to the project. Theme files are not shared Core release files.

// In the active KAS theme's _SECTIONS.php (generic example).
$PROJECT = $KAS_SECTIONS->addSection([
    'name'=>['en'=>'PROJECT TOOLS', 'es'=>'HERRAMIENTAS', 'fr'=>'OUTILS DU PROJET'], 'icon'=>'tools', 'privilege'=>5, 'required'=>0
]);
$TOOLS = $PROJECT->addSubSection(['name'=>['en'=>'TOOLS', 'es'=>'HERRAMIENTAS', 'fr'=>'OUTILS'], 'privilege'=>5]);
$TOOLS->setOption([
    'name'=>['en'=>'VIEW ITEMS', 'es'=>'VER ITEMS', 'fr'=>'VOIR ITEMS'], 'type'=>'VRN', 'privilege'=>5, 'main'=>true
]);

For a theme-owned main section, VIEW.php loads kas/themes/<theme>/<ENGLISH_MAIN_SECTION>/<ENGLISH_PAGE_WITH_UNDERSCORES>.php. The same location can override a Core page. Public-site /themes/ is also project-owned, but it is not this registration hook. Implement shared reusable framework behavior in Core; put customer-specific behavior/navigation in the appropriate theme. Never infer generic architecture from a single project's customization.

After either Core or theme section definitions change, follow logged-out initialization. Removing an option from source also needs initialization to rebuild menu records; removing a PHP file alone does not remove menu records. See multiple forms/views when several blocks belong on one page, and non-menu pages for forms that should have no menu option.