Page tree
Skip to end of metadata
Go to start of metadata

Directory Structure

The base directory structure of the framework is outlined below:

  • __swift
    • cache: A volatile file cache store. Contains cached templates, javascript files, xml files etc.
    • config: This directory contains the default config file, template, language files etc.
    • files: The files directory is used to store non volatile data like attachments, profile images etc.
    • geoip: The GeoIP directory contains the CSV GeoIP database files.
    • includes: This directory contains all procedural code files.
    • library: The library directory is used to store all the publicly accessible PHP Classes.
    • locale: This directory stores the PHP based locale strings.
    • logs: The log directory contains all the log files created by SWIFT.
    • apps: This directory contains the pre-built apps. Example: core, base etc.
    • models: This directory contains all base model classes.
    • javascript: This directory consists of all javascript files.
    • themes: The themes directory contains the client support center and admin/staff interface images and stylesheets.
    • thirdparty: This directory is used to store all third party code.
  • __apps
    • knowledgebase
    • livechat
    • news
    • parser
    • reports
    • tickets
    • troubleshooter
  • admin
  • api
  • console
  • cron
  • staffapi
  • tests
  • rss
  • setup
  • staff
  • visitor


Any directory created in the parent level and not named as '_swift' or '_apps' is treated as an interface. The interfaces allow segregation of functionality of a product. An interface is not restricted to a base set of apps but can be used to call a controller in any public or in-built app.

App Structure

Each app acts as an extension to the product and can have independent locale strings, configuration data, libraries or hook files.

The basic app structure of the tickets app is outlined below, the optional directories are prefixed with (O) and the interface directories are prefixed with (I). For detailed description and how-to's on creation of a app, please refer to the App Development section of KDN.

  • (I) admin
  • (I) staff
  • (I) client
  • (I) api
  • *(O) library
    • Ticket
    • Macro
    • View
  • (O) Models
    • Ticket
    • Macro
    • View
  • (O) locale
    • en-us
  • (O) hooks
  • config
  • staffapi
  • console
  • javascript
  • cron
Interface Directory

The Interface directories contains all the controller and view files. These are dynamically executed based on the call requests.

For example, a call to staff/index.php?/Tickets/View/Insert will result in execution of the Insert() function of staff/class.Controller_View.php file in the Tickets app.

Library Structure

Both the base library directory and the app library directory follow the same standardized structure of organizing the reusable OOP classes in the product. The basic library structure is outlined below:

  • Ticket
    • class.SWIFT_Ticket.php
    • class.SWIFT_TicketEmail.php
    • class.SWIFT_Ticket_Exception.php
    • class.SWIFT_Ticket_Interface.php

Whenever the Ticket library is loaded, SWIFT will automatically load both the Ticket_Exception and Ticket_Interface files as long as the naming convention is followed.

It is required that all individual files inside the library directory be prefixed with the same directory name. Creating a file called class.SWIFT_EmailTicket.php would break the naming convention followed throughout the system

Locale Structure

To enforce standardization and allow ease of management, both the base locale directory and the app locale directory follow the structure similar to what is outlined below:

  • en-us: The language code
    • ticketdefault.php
    • ticketmain.php
    • ticketlist.php

The language files are loaded dynamically based on the default language set by a staff user.

It is required that the naming convention of locale files be kept simple and explanative

  • No labels