General Architecture

Keyring is separated into a number of files and directories to try to make it easier to navigate and find things. Here is a snapshot of what it should look like when you have a full copy of the plugin (note some directories are left unexpanded for clarity)

Keyring File Listing

Most of the files correlate to major concepts within Keyring, as outlined below:

  • admin-ui.php: Everything related to the main (optional) UI of Keyring lives in this file. If you disable the admin UI (by defining KEYRING__HEADLESS_MODE as true), this file will not be loaded at all.
  • keyring.php: The core file that bootstraps Keyring, handles requests etc. More on this below.
  • service.php: An abstract base class that defines the functionality of all Services. Any Service definition should extend this base class (Keyring_Service) either directly, or via one of the provided classes in the package. This file also auto-loads all Service definitions in /includes/services/core/ and then those in /includes/services/extended/
  • store.php: Similar to /service.php, only providing no base functionality, this file defines an abstract base class which all Token Store classes should extend. It also auto-loads all files in /includes/stores/.
  • token.php: Defines a base class, and then 2 specific extensions of that class (Keyring_Request_Token and Keyring_Access_Token) which are used to handle all authentication tokens/information for all Services. These native object types must be used in all Services and Stores.

What do you think?