Building WordPress Plugins — Best Practices for Beginners and Veterans Alike

A talk first delivered on March 19, 2014 at @WP518 in Saratoga Springs, NY

Plugin repo: https://github.com/jchristopher/no-hello

Transcript

1. Building WordPress Plugins Best Practices for Beginners and Veterans Alike Jonathan Christopher irontoiron.com mondaybynoon.com @jchristopher
2. What is a plugin? A WordPress Plugin is a program, or a set of one or more functions, written in the PHP scripting language, that adds a specific set of features or services to the WordPress weblog, which can be seamlessly integrated with the weblog using access points and methods provided by the WordPress Plugin Application Program Interface (API). http://codex.wordpress.org/Writing_a_Plugin
3. Classifying plugins What defines a plugin? How do you know what to include in a theme instead? What should be made into a plugin?
4. Creating a plugin Create a folder ~wp-content/plugins/your-plugin Create a file with the proper header meta block How do you actually build a plugin?
5. Best practices: basics No rules per se, but many helpful guidelines Code formatting. WordPress has Coding Standards (PHP, HTML, CSS, and JavaScript) but at the very least: be consistent with your formatting
 http://codex.wordpress.org/WordPress_Coding_Standards Comments! WordPress is open source, write comments as though a complete stranger is going to read them. Break up code into files/folders as appropriate (e.g. classes, assets, etc.) Continued… Are there rules to writing plugins?
6. Best practices: basics Let WordPress do as much work for you as possible (it will do a ton) Good function/variable names: prefixed (if not in a class), descriptive
 In other words: do everything in your power to prevent collisions with other code, especially WordPress core itself Use hooks! Learn by example: well written plugins like bbPress Are there rules to writing plugins?
7. WordPress Hooks What are hooks? Actions and Filters (explained next) Where can we find out about what hooks are available?
 http://codex.wordpress.org/Plugin_API
 http://codex.wordpress.org/Plugin_API/Action_Reference
 http://codex.wordpress.org/Plugin_API/Filter_Reference How do you use hooks? Hooks make extending WordPress possible
8. WordPress Filters How do you use filters? Example: filter the_title to swap ‘hello’ with ‘hey there’ add_filter(); // you utilize a filter in place
 apply_filters(); // you implement a hook-able filter How do you write your own filters? Applying filters where necessary to make customization available Filters aim to modify data
9. WordPress Filters Simple things to very complex things • Modify content • Modify parameters • Hijack search results What else can filters do?
10. WordPress Actions Like filters, WordPress has Actions littered throughout the code base that allow us to essentially enqueue our own functions to happen at certain points in time during a WordPress page execution. This allows us to effectively add our function to WordPress core without editing the files themselves. That’s a big deal. Hook-able points in time during execution
11. WordPress Actions You’ve likely already used a WordPress action to properly enqueue a custom stylesheet https://codex.wordpress.org/Function_Reference/wp_enqueue_style#Examples How to use actions Actions make my aspects of plugin development possible
12. WordPress Hooks Hooks may be confusing/intimidating at first Understand the concept of ‘enqueueing’ your functions into WordPress core Remember that filters filter, actions are actionable Keep in mind data integrity, return the expected type else you can wreak havoc down the line. They’re kind of a big deal
13. Adding Menus & Screens Decisions over options
 http://nacin.com/2011/12/18/in-open-source-learn-to-decide/ Appropriately give your plugin a UI UI is nice but hooks can usually suffice and shouldn’t be thought of as an inconvenience, they make WordPress WordPress Hooks are not the end-all-be-all, sometimes you want to create a settings screen or even an entire Menu section (which is honestly super rare) — be humble when making that decision.
14. Adding a Settings screen A very good place for plugin settings The WordPress admin has a Settings menu we can utilize WordPress also has a Settings API. It needs some love, but it’s there.
 https://codex.wordpress.org/Settings_API
15. Saving your plugin settings What’s the best way to go about it? Mind the database, don’t abuse it WordPress has built in functionality that makes data storage simple, automatic serialization/unserialization Use as few records as possible (minding database performance) Read and write as few times as possible http://kovshenin.com/2012/the-wordpress-settings-api/
16. Internationalizing your plugin What’s the big deal? Internationalization is something baked right into WordPress __() and _e() make everything work Language packs can be programmatically generated by native speakers and sent to you for inclusion
 http://codex.wordpress.org/Writing_a_Plugin#Internationalizing_Your_Plugin
17. Saving other data What if your plugin uses more than settings? WordPress has you covered with object metadata Posts, Comments and Users have a dedicated metadata API, use it wisely.
 http://codex.wordpress.org/Metadata_API NOTE: While the generic Metadata API exists, you should not use it directly! There are meta functions for each object type available.
18. Data storage strategy Should you have a plan when storing metadata? Metadata is great but it’s slow, as a result it’s often abused Keep in mind that it’s very valuable to have metadata be stored in such a way that facilitates outside queries (i.e. keep metadata separated) That goes against optimization in a way, but it increases the usefulness of your plugin if other developers can use your metadata in other ways (e.g. WP_Query meta_query) If your data is locked inside a serialized array, you lose all benefit of querying by specific meta_values when running custom queries
 http://codex.wordpress.org/Class_Reference/WP_Query#Custom_Field_Parameters
19. Data storage strategy Are comments and users different than posts? Storage of comment and user metadata works in the same way. WordPress has hooks available to customize both the forms used for editing those objects, and you can manipulate the workflow in the same way.
20. Data storage strategy Sanitize/validate going in, escape going out Data sanitization (and escaping) is extremely important Do not try and do it yourself, WordPress has you covered
 https://codex.wordpress.org/Data_Validation NO data is trustworthy, especially when you consider hooks.
21. Object Oriented Plugin Development Best practices apply here too There’s nothing wrong with procedural plugins, in fact there are some reasons to use procedural patterns when building WordPress plugins. Utilizing classes, however, makes things a bit more organized and put together. Let’s convert No Hello into a class-based plugin…
22. What else? Let’s continue the conversation… • Making your plugin available — .org? GitHub? • Unique (but helpful) actions — e.g. plugin activation • Database queries (WordPress has an awesome class for this) • Debugging and optimizing your plugin • Where to go when you have no idea where to start • WordPress Cron … anything else?