In our last blog post, Built To Last, we mentioned the necessity of building into the core of WordPress and never modifying existing Plugins, themes, or core files. We wanted to expand on this topic a bit and explain more about these best practices with what we’re calling “Plugin Strategy”.
WordPress was traditionally a blogging platform and has evolved into a full featured Content Management System (CMS). It is even more than that to PHP developers. WordPress serves as a PHP framework—providing many tools and resources for developers to design their Plugins with.
Despite all that WordPress has to offer developers, many don’t necessarily take the time to learn what all the core can do. This can mean reinventing the wheel by bringing in performance costing library files that otherwise aren’t necessary, making custom User Experience (UX) elements that don’t match WordPress, or creating Plugins that are essentially islands to themselves based on how they store data and only mildly hook into WordPress.
Let’s examine the WordPress framework to enlighten ourselves on how core developers built the platform to be extended. To begin, here’s a fairly complete list of current WordPress core API features. These interfaces are built and maintained by the WordPress core team and offered to the WordPress developer community:
- Administrative user experience (icons, messages, buttons, forms, tables, pagination)
- Administrative Dashboard Widgets
- Categorization (taxonomy, tags, categories)
- Conditional tags (situation checks)
- Cron (time based execution) system
- Debugging (logging, unit testing)
- File headers (media detection, thumbnails, storage)
- Hook (action and filter) system (Plugins modify behavior of the page generator)
- Internationalization and Localization (translations)
- JavaScripts (jQuery libraries and AJAX capabilities)
- Multisite (networking, sharing users Plugins themes across sites)
- Options (general settings storage)
- Plugin activation, deactivation, deletion (action triggers)
- Post Metadata (per post/page custom fields, new post types and meta boxes, attachments)
- Sanitization and Validation (escaping, security)
- Security (roles, capabilities, nonces, validation, sanitization, db abstraction, sql escaping)
- Settings (plugin settings pages)
- Shortcodes (hooks within specific pages or posts)
- Template tags (theme developers)
- Transients (session data)
- User Metadata (authentication, per user roles, capabilities, profiles, additional fields)
- URL Rewriting (manipulating page controller)
- Widgets (sidebar items, footer items)
- Web Services HTTP (API server)
The idea of building to the core is to utilize the above APIs as needed for as many purposes as possible, including: data storage, manipulation, and page rendering. In this way, Plugins can interact with the site’s content and with each other as intended by the WordPress core team. A plugin should be thought of as an extension to the core, something that can be enabled or disabled, combined with other Plugins, and whose output is compatible with other quality Plugins and themes.
Our next building to the core concept is “no hacking”. The idea here is to never alter existing Plugins, themes, or core files (code). Doing so will break future community contributions, updates, and security fixes trickling down from those project contributors. The Plugins that one uses should perform all the necessary functionality within their scope, ideally a single service, and other Plugins can be written to add or change most behaviors that WordPress itself offers control over. Thus, there is little reason to even consider modifying an existing plugin, theme, or core file. The cost of doing so will come back to bite in the short term. You’re better off building to the core with any custom projects you may have, plus for any existing Plugins you use stick with only quality projects.
Thank you for taking the time to read this post. Note that we really appreciate feedback about what we’ve written as well as what topics you’d like us to discuss in future posts so please do let us know.
beAutomated 