Oct 26

Leevi Graham - How to start developing your own add-ons

Categories:
ExpressionEngine
Tags:
expressionengine, extension, leevi graham, module, plugin
Published:
11:27am on Monday 26th October, 2009

Leevi Graham runs Newism in Australia, and has developed more than 25 add-ons over the last two years. His first and most profitable add-on was LG Better Meta, and Leevi was named 2008 Add-on Developer of the Year on Devot:ee.

Download Leevi’s slides (PDF) here: http://bit.ly/efYkA, or watch the video of his presentation on Vimeo.

About Add-Ons

  • Plugins render front-end tags. They are simple to build, offer custom field text formatting, use a single file, have no Control Panel administration, no settings, and can’t process forms. 99% of plugins are for the front-end
  • Modules are 50/50 front-end and back-end. It is easy to upgrade a plugin to a module; they can process form submissions, use multiple files, but have no settings
  • Extensions let you “take control” of EE. They extend existing tags or the control panel, have a built-in settings form, and are all done through EE’s built-in hooks. Extensions must be activated to use, and don’t offer tag parsing. Hook registration can be complex for beginners
  • Hooks hook into the core EE processing, and there are over 170 of them. An extension’s class method is called when it’s hook is executed; you can see which hooks are used where on Devot:ee
  • Your code should always check whether someone else has already used the same hook
  • If you are developing a combined extension and module, I recommend you put settings specific to the extension into the extension, rather than in the parent module
  • Add-Ons combine extensions, modules and plugins. This means lots of files in different locations, with dependencies on one another
  • Where to find add-ons: Official repository (144), the EE forums (?), Devot:ee (480), GitHub (114)
  • For help developing add-ons, there is documentation and a list of hooks on the EE site
  • If you put your code on GitHub, community has adopted the xxx.my_addon_name.ee_addon naming convention

Leevi’s Development Process

  • I’ve started providing templates and themes incorporating the add-on so that users can see that the add-on works, rather than struggling to work through the code themselves
  • Always end extension classes with _ext to prevent class naming conflicts
  • Documentation is important; it’s the most boring job, but if you do it properly and provide examples, your support requests will more than halve
  • If an add-on is worth writing, it probably should be for sale - so charge for your extensions
  • But without releasing free stuff initially, I wouldn’t be in the position I’m in now, so it’s a balancing act
  • Currently offers email-based support (Brandon Kelly uses GetSatisfaction)
  • Free LG or NSM add-on licenses for everyone at EECI2009!

Q&A

Is it worth spending the time to build a payment system handler so you can sell?
Yes - you might spend a week building something, but you can then use that to sell for years.

Leslie Camacho (EllisLab President) noted that lots of hooks were stripped out of EE2.0 for the beta phase to limit developers and reduce bug report complexity.

I'd love to hear what you think - please use the form below to leave your comments. Anything I consider too offensive, off-topic, or spammy will be deleted at my discretion. Some HTML is permitted, or you can use Textile.

Commenting is not available in this weblog entry.
  1. Nobody has commented on this article yet - why not be the first?