Paul Burdick - Add-On Development: EE Expects That Every Developer Will Do His Duty

Categories:

ExpressionEngine, PHP

Tags:

expressionengine, extension, javascript, jquery, module, paul burdick, performance, plugin

Published:

12:24pm on Monday 26th October, 2009

Paul Burdick is the ex-CTO of EllisLab, and now works as Lead Developer for ExpressionEngine add-on shop Solspace.

Download Paul’s slides here in PDF form: http://bit.ly/addons_eeci2009.

All about add-ons

• What are add-ons? There are three types - extensions, modules and plugins
• Extensions extend basic EE functionality, allow you to interpose your own code. Developers are extending the idea by adding their own hooks in their modules. Typically extensions don’t have a database table, but do have settings in the Control Panel
• Modules are the “mighty workhorses” of EE. They typically have a Control Panel area, database tables, and their own template tags
• Plugins have no settings and no install process. They offer text manipulation via template tags or custom fields
• On Devot:ee the add-ons currently break down as 51% plugins, 35% extensions, 15% modules
• EE 2.0 will introduce Accessories - tools, references and abilities that go at the bottom of the CP. They can have database tables, and use View files. Defaults include Learning, Notes, Tips

Developing add-ons

• Necessary skills you will need to be an add-on developer: PHP (learn at php.net, w3schools, and Zend), SQL (note that Active Record is part of EE 2.0)
• View files are HTML with PHP in, and are used in EE 2.0 (they can also be used in 1.6.x with Solspace’s Hermes). They are much easier to write than using the Display class
• Build your UI in static HTML/CSS/JavaScript first before converting to View files. It’s easier to test that way, and specialist UI developers don’t need to know PHP
• jQuery is available by default in EE 2.0 (although it’s not the best way to learn JavaScript). EE 2.0 also makes it easy to use other JS libraries
• Never, ever just start coding! Don’t just write code and release it. Do research - look at previous releases, how are big companies doing it, What are your required features
• There are a lot of add-ons that do not need to exist. The Query module, or JavaScript+AJAX can do a lot
• Is a module required? Could an extension do it? Or a plugin that outputs weblog data?
• Tell a story - how would a user do this? What would Apple do? Eliminate steps, follow your instincts
• Map out features - major, minor, and “icing”
• Include your own hooks for future expansion
• Database structure - plan your tables, with separate ones for preferences and data. How does your add-on interact with EE’s own tables? Normalization - eliminate data duplication
• Use specific, sensical field names
• Use indexes
• When naming template tags, give them a good name, and describe the parameters and variables in the comments. Explain what each one does
• Make tag name simple and obvious. I want to be able to read the template and know what it does. No abbreviations
• Parameters - use prefixes to namespace parameters and group functionality
• Variables - there should be no ambiguity and no abbreviations. Name variables the same as their corresponding database field, then you can just loop through a query result row to find and replace. Prevent collisions in variables.
• Underscores are recommended
• Get feedback - revise your add-on spec until solid

Building an add-on

• Break the Control Panel page into sections: Data (create, modify, delete); Preferences/Settings/Permissions (copy preferences is a handy tool to provide); Actions - recount records, cache management; display the version number and documentation link
• Keep it simple - build what is necessary and no more
• Build it in HTML/CSS/JavaScript first; use a view file, put the PHP into the HTML (not the other way around), and ignore IE6 (EE 2.0 and Solspace do)
• Have goals and milestones not deadlines. Don’t release software until you think it’s ready
• Writing code - follow the EllisLab developer guidelines! Comment well and properly. EE code has jokes and ASCII art in it
• Sanitize and escape everything. Assume all data is tainted - sanitize and escape at the query, not at the top of your class
• Abstraction - use twice, write once. Create libraries - reduces work and mistakes
• Simplify - bail out of the process first, as soon as you find a problem, do the actual work second
• Reduce database work. Multiple queries are okay; validate, check pagination with a COUNT query, and only then retrieve data
• Consider using a Model to abstract queries
• Per page load caching - use $SESS->cache[‘modules’][‘module_name’][some_cache’] = array(); to cache query results, preferences, etc. Use a reference
• If you need weblog data, just use the Weblog module - include() it and call its methods
• Provide tools for keeping things tidy - remove old data/caches, optimize tables (regularly or provide a button to do so)

Debugging and improving performance

• Debugging and performance are the same thing
• Turn on error reporting - no PHP errors ever!
• Turn on SQL queries - review your queries, check CP, settings, tags in templates - eliminate duplicate queries!
• Are certain queries necessary on every page load? Validate and check cache. Evaluate queries for performance - to improve things, try adding a WHERE clause on an indexed field, and remove extraneous JOINs
• De-normalization - duplicate data to reduce work. Abstract methods for data consistency
• Learn about MySQL performance - mysqlperformanceblog.com is a good resource
• Turn on Template Debugging - what code is taking the longest to run? You can add debug entries in your code, e.g. before and after a query or loop, using $TMPL->log_item();
• Embeds are heavy - they run all the “new page” queries for each one. Automated actions - slow down your add-on. Use AJAX instead
• Use trigger_error() to throw errors for deprecated code
• Ask for help. Often just discussing a problem will lead to a solution