Best practices for plugin development

Create a WordPress plugin from scratch

Andrea Sciamanna

present● Lead developer for WPML

● responsible and active developer of the WPML plugin and add-ons

past● Web and desktop application

developer (mostly using .net framework)

Agenda

● Quick introduction about:a. code readabilityb. documentationc. patterns

● Some references● Creating a WordPress plugin from scratch● (time allowing) Introducing IDEs and OOP

Code readability

1. Use coding standardsa. Use WordPress PHP Coding Standards: http://goo.

gl/FTMm0ab. Comment with PhpDOC: http://www.phpdoc.orgc. Don't repeat yourself (DRY): http://blog.codinghorror.

com/curlys-law-do-one-thingd. Don’t go crazy trying to follow standards: just get used

to them.

References

● WordPress Codex: http://codex.wordpress.org● Stack Overflow: http://stackoverflow.com

○ WordPress Development: http://wordpress.stackexchange.com

● Google: seriously, do I need to tell you?

Create a WordPress plugin from scratch

A “Fancy” plugin for your galleriesIntegrate Fancybox in the standard WordPress gallery.

Planned Functionalities

● Show images in a Fancybox/lightbox, rather than opening them in a different page

● Do not interfere with the active theme● Make it “SEO proof”● Pseudo-Watermark images without modifying

them● Allow some customization

Goals

● Learn how to:○ enqueue scripts and styles○ use actions and filters○ use WordPress Settings API

● Learn best practices, of course!● ...and the Fancybox plugin

Standard plugin structure

● Single file: unique file name (my-own-plugin.php)

● Complex structure:○ unique folder name (/wp-content/plugins/my-own-

plugin/)○ bootstrap script: plugin.php or any name

● Main plugin file: Standard Plugin Information● readme.txt file

Skeleton

Main plugin file

● Define useful constants, for later use:○ Plugin version○ Plugin path○ Plugin folder○ Plugin URL

● Include dependencies○ Shared functions○ Core class○ Options class

➔ Remember to namespace your functions, by either using unique plugins, or unique class names

➔ Do not use actual PHP namespaces!

Hooks

● What are they?○ Actions -> They do things○ Filters -> They return something

● How they must be used?○ “Hook” a filter, or action to a custom function

● When?○ At the right time: it’s a bit tricky and needs practices,

some cheat sheet, or asking the community

Hook to some actions and filters

● The loader class: why?○ Decoupling functionalities○ Specialized classes

● Hook to actions:○ ‘plugins_loaded’ -> the actual entry point (usually)○ ‘wp_enqueue_scripts’ -> scripts and CSS goes here

● Hook to filters:○ ‘wp_get_attachment_link’

Implement hooks

● Hook to actions○ Add scripts and styles

■ Main script and styles■ Fancybox, helpers and more■ Pass data to scripts: wp_enqueue_script()

● Hook to filters○ Tweak the gallery item link

Plugin options definitions and handling

● Implement plugin options○ A new class => a new file○ The options loader class

WP Settings API

● WP Settings API○ register_setting()○ add_settings_section()○ add_settings_field()○ callbacks○ options_do_page

● Some thoughts about the APIs:○ Counterintuitive○ Old

Honestly, we ought to take the time to learn the Settings API however the steep the learning curve, and start working with it. It is the definitive way to go about creating options pages, and it is the current version of the API that we have available.

Tom McFarlin (http://tommcfarlin.com/wordpress-settings-api-wrapper)

Plugin options page

● Show the plugin options page○ OTGS_Fancybox_Gallery_Options::get_setting static

method: why is static?○ Add a menu item in “Settings” menu○ Add some javascript and enqueue the script in the

back-end

Refine the main class

● Handle plugin options● Take advantage of $wp_object_cache in

OTGS_Fancybox_Gallery::get_attachment_link

The main gallery.js

● Do not use $ (in WordPress)!● Implement jquery.fancybox()● Cache jQuery elements● Play with plugin options

Test it

Questions?