Created 2017.04.13
Rather than copying and pasting code between projects, plugins can be created for easy reuse. A bug found in Website B can be fixed and easily shipped to Website A.
In a multisite install, that plugin can be made available to all subsites. This approach can also be used to install and update proprietary plugins, which have not been published to the plugin directory.
A successful website has great content and is easy to update and thus keep current.
This means placing the focus on functionality before design.
Get the editor experience right first. Add the required functionality via plugins. The editor can use a stock WordPress theme to start entering their content.
When the editors are happy and content writing is well underway, start building a new theme. Add the plugins to the new theme. The functionality comes along for the ride.
When a plugin is not activated, any shortcode associated with it will display as a raw shortcode.
This means that shortcodes can be used to quickly scaffold out a front-end, then later replaced with custom plugins. The raw shortcode serves as a reminder that the plugin is yet to be created (or activated).
On a local theme, a centralised plugin folder provides a central location for plugin development, rather than copying code between themes.
- A plugin requires a unique identifier
- A plugin requires a folder structure (organisation)
- A plugin should have a single purpose and do it well
All of these 'limitations' are just best practices when writing DRY, testable code.
Themes are meant to change the design of your WordPress website. Ideally, it should be visual. But in this golden age of WordPress, theme developers often include functional features in their themes in order to stay competitive in the market. This it was supposed to be, but it is.
This is the invasion of the plugin territory. We can define "plugin territory" in simple terms: Functional parts of code are inside the borders of this territory. Every bit of code that changes the functionality of your website needs to be served as a plugin, if it's not already been served in the WordPress core.
Non-design related functionality is not allowed.
Examples of plugin territory functionality:
- Analytics or tracking support
- SEO options
- Contact forms
- Non-design related meta boxes
- Resource caching
- Dashboard widgets in the admin area
- Custom Post Types and Shortcodes
- Social media “like”, “follow” and “share” buttons
A large number of WordPress sites are promoting the use of a 'Site-specific' or 'functionality' plugin, in place if functions.php.
The idea is that snippets which add shortcodes etc should be portable across themes.
It's not a radical idea, but for more serious functionality, it undermines the plugin community. People can create private plugins rather than building useful helpers which anyone could use.
Another issue is that a developer may build many sites with similar functionality, with these being bundled over and over again into site-specific plugins.