Introduction

Craft comes with a powerful plugin framework coupled with a robust set of APIs that paves the way for a wide variety of plugins.

Assumed Knowledge #

Craft plugins are very much like little applications in and of themselves. We’ve made it as simple as we can, but the training wheels are off. A little prior knowledge is going to be required to write a plugin.

For the purposes of the plugin docs, we’re going to assume that you know PHP and SQL, as well as some semi-advanced concepts like object-oriented programming and PHP namespaces.

Anatomy of a Plugin #

There are several different classes your plugin can have, which handle different aspects of your plugins’ duties. They all aren’t necessary; you can pick and choose which of these you actually need when writing your plugin.

Primary Plugin Class #

Your primary plugin class tells Craft same basic information about the plugin, such as its name and version number. It also handles a few oddball things like installation/uninstallation and hooks.

This is the only required plugin class. For some plugins, it may even be the only file that’s needed.

Controllers #

If your plugin will be handling incoming HTTP requests, it will need a controller. Controllers have “action functions” that will automatically get their own HTTP endpoints that forms and URLs can point to.

There’s no limit to what your controllers’ action functions can do, but they are typically just middlemen between the outside world and your plugin’s services.

Services #

If your plugin provides any core functionality, it should be placed within a service. Services’ public methods are available globally throughout the system, for both your plugin and other plugins to access. They can be accessed via craft()->serviceHandle->methodName().

Variables #

You can think of variables as the template-facing version of services. Your primary variable class can be accessed from any template via craft.pluginName.

Models #

Any data that your plugin manages should be represented by models, and you should use them to pass that data around between your controllers, services, and templates.

Records #

If your plugin needs to store data in its own database table, you should create a record. Records have two purposes: When your plugin gets installed, Craft will refer to them in order to know which custom tables it should create and how they should be designed, and your plugin can use them to select, update, and insert data within that table.

Field Types #

If your plugin provides a new type of custom field, it can do that with a field type. Field types handle all of the type-specific functions of the field, such as its settings, what the input HTML should be, and how its data should be stored.

Dashboard Widgets #

If your plugin provides a new type of dashboard widget, it can do that with a widget. Widgets handle all of the type-specific functions of the dashboard widget, such as its settings and what the body HTML should be.