Removing `load_plugin_textdomain` and leaving only `load_textdomain`. This is standard as per new WordPress practices. Ultimately, it makes language files more portable as they are still accessible via WordPress even if the plugin developer did not include them with the plugin itself. Related #120 
|9 years ago|
|plugin-name||9 years ago|
|.gitignore||11 years ago|
|ChangeLog.md||9 years ago|
|README.md||9 years ago|
WordPress Plugin Boilerplate
The WordPress Plugin Boilerplate serves as a foundation and aims to provide a clear and consistent guide for building your WordPress plugins.
- The Plugin Boilerplate is fully-based on the WordPress Plugin API.
- Uses PHPDoc conventions to document the code.
- Example values are given, so you can see what needs to be changed.
- Uses a strict file organization scheme to make sure the assets are easily maintainable.
- Note that this boilerplate includes a
.potas a starting translation file.
- Notes on managing assets prior to deployment are covered below
- Tools used for translation are below
The WordPress Plugin Boilerplate includes the following files:
- This README, a ChangeLog, and a
- A subdirectory called
plugin-namethat represents the core plugin file.
- Copy the
plugin-namedirectory into your
- Navigate to the Plugins dashboard page
- Locate the menu item that reads TODO
- Click on Activate
This will activate the WordPress Plugin Boilerplate. Because the Boilerplate has no real functionality, nothing will be added to WordPress; however, this demonstrates exactly how your plugin should behave while you're working with the Boilerplate.
The WordPress Plugin Boilerplate uses a variable to store the text domain used when internationalizing strings throughout the Boilerplate. To take advantage of this method, there are tools that are recommended for providing correct, translatable files:
Any of the above tools should provide you with the proper tooling to localize the plugin.
The WordPress Plugin Boilerplate includes native support for the GitHub Updater which allows you to provide updates to your WordPress plugin from GitHub.
This uses a new tag in the plugin header:
* GitHub Plugin URI: https://github.com/<owner>/<repo>
Here's how to take advantage of this feature:
- Install the GitHub Updater
<owner>with your username and
<repo>with the repository of your plugin
- Push commits to the master branch
- Enjoy your plugin being updated in the WordPress dashboard
The current version of the GitHub Updater supports tags/branches - whichever has the highest number. It also supports different branches using the
GitHub Branch: header. All that info is in the project
In future versions, there will be steps to specify branches or tags rather than the
The WordPress Plugin Boilerplate is licensed under the GPL v2 or later.
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License, version 2, as published by the Free Software Foundation.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
The WordPress Plugin Boilerplate is licensed under the GPL v2 or later; however, if you opt to use third-party code that is not compatible with v2, then you may need to switch to using code that is GPL v3 compatible.
Note that if you include your own classes, or third-party libraries, there are three locations in which said files may go:
plugin-name/includesis where shared functionality should be placed between
plugin-name/admin/includesis where dashboard-specific classes and dependencies should be placed
plugin-name/public/includesis where public-specific classes and dependencies should be placed
The assets directory provides two files that are used to represent plugin header images.
When committing your work to the WordPress Plugin Repository, these files should reside in their own
assets directory, not in the root of the plugin. The initial repository will contain three directories:
You'll need to add an
assets directory into the root of the repository. So the final directory structure should include four directories:
Next, copy the contents of the
assets directory that are bundled with the Boilerplate into the root of the repository. This is how the WordPress Plugin Repository will retrieve the plugin header image.
Of course, you'll want to customize the header images from the place holders that are provided with the Boilerplate.
Plugin screenshots can be saved to one of two locations:
- The old way is to keep them in the root of the plugin directory. This will increase the size of the download of the plugin, but make the images accessible for those who install it. This is deprecated in the WordPress Plugin Boilerplate
- With the alternative way, you can save the screenshots in the
assetsdirectory, as well. The repository will look here for the screenshot files as well; however, they will not be included in the plugin download thus reducing the size of the plugin. As of its latest version, the WordPress Plugin Boilerplate now follows this convention.