Cypht has a modular design. Instead of an application with a plugin API, Cypht is an application
comprised entirely of plugins, or as we call them, "module sets". There is only one required set,
the "core" modules. These can be added to, or even replaced, by site specific modules. All the
functionality of Cypht is broken out into module sets, and each set is built from small pieces
that are also easy to override. The module system is powerful, but also a bit complex. First let's
take a look at the module sets that come with Cypht:
TOTP based 2 factor authentication using the Google Authenticator mobile app
UI features for admins to create accounts, and for users to update passwords (when using the built-in DB authentication). Functional, but could use more admin features.
Contact management. Requires at least one contact backend module set to be enabled.
Simple locally stored contact support.
Support for contacts stored in LDAP (read only for now).
Read-only support for Gmail contacts with an Oauth2 enabled Gmail account.
Handles page layout, login/logout, and the default settings pages.
For development, provides resources and installation details. Only available in "debug mode".
Allows user to authenticate against a list of popular mail services, or to auto-discover the services for the specified E-mail address.
RSS/ATOM feed support.
Github repository tracking
Example module set with lots of comments.
Simple list of messages read since login.
Controls idle time and automatic logout
IMAP E-mail account support.
IMAP E-mail folder management support.
View messages inline in a reading pane instead of on a new page.
Adds support for site navigation and actions using the keyboard.
Access the NASA APOD API content.
Friendly new user experience. Quickly add common E-mail services, and view development updates. Needs help text added.
POP3 E-mail account support
Profiles to set reply-to, name, and signature to associated E-mail accounts.
Enable Recaptcha on the login form.
Ability to recover user settings after an external password change.
Save and re-run searches easily.
Site specific overrides. Used to control other module sets without hacking the code.
Send outbound E-mail using SMTP servers.
Tag content for easy searching/filtering. Not yet functional
Change the UI using CSS.
WordPress.com notifications and freshly pressed lists
Module sets are setup in the hm3.ini file. With the exception of the core module, they can all be enabled or disabled independently (though module sets can rely on each other, like the nux module). When the site build process is run, module assignments are calculated and saved in the configuration file (so they don't need to be re-calculated at run-time). There is also a debug mode in which modules are activated dynamically (for the most part) to make development easier.
Module set names in the ini file match the directory the module code is in under modules/. Files in a module have pre-defined names. Any other required code should be included from one of these files.
This is where a module set defines it's own modules and assigns them to request identifiers. This file must return an array of valid input and associated types in order for the module code to have access to it..
This is where the actual module code lives. If you have external libraries to include this is a good place to do so.
Optional file to include CSS for the module set.
A module set can also include an assets sub-directory. Anything in that directory will be made availble in the browser. An example of this is the HTML WSIWYG editor for the smtp module set. In debug mode the module site.css and site.js files are included directly if they exist. In production mode combined and optionally minified versions are used consisting of a single js file and a single CSS file generated by the build process. Minifying programs can be specified in the hm3.ini file.
Input and Output
There are two kinds of modules: Input processing modules called "handler modules", and output formatting modules called "output modules". Modules can pass data to each other, and output modules have access to all the data input modules create. By default, module output is immutable and can't be stepped on by other modules. Data can be marked writable and an "appendable" data type is also supported. The typical job of a handler module is to analyze user input and do some work based on it, which it then sends to the output modules. The typical job of an output module is to take the results of an input module and format it for the browser.
For more information, check out the "hello world" module set. It illustrates how modules work and has loads of comments that explain what is going on: