WordPress Plugin Development Strategies
When I say “general strategies”, I’m referring the things like the basic file / folder organization, the naming scheme for your files, the organization of functions within files, and the way that resources are loaded. It is best if you make an effort to keep these aspects constant throughout your development. When you use the same basic strategies for each of your projects, and throughout each individual project, you will find that it dramatically improves your workflow and the overall quality of your work.
Imagine you are writing a plugin that has upwards of 10,000 lines of code; which do you think is easier to enhance and debug, a plugin that has the 10,000 lines separated into meaningfully named files and folders, or a plugin that has all 10,000 lines in a single file? If you have answered with a single file, then I’d highly advise you to think about it a little longer, or challenge yourself to go write a very large plugin, and do it all in one file. You will quickly find that it’s highly disadvantageous.
I would like to discuss and share several aspects of my personal development strategy. Some of these are simply things that should be done because WordPress Coding Standards dictates that we should (with good reason), and some of them are strategies that I have simply found to be extremely helpful in development.
Use a Unique Prefix for Everything
This is one of the first rules of development, and it should never, ever be broken. When you write your plugin, everything absolutely must receive a unique prefix specific to your plugin. This includes function names, class names, global variables, option names, database tables and more.The primary reason for always, without exception, using prefixes is that it prevents conflicts. If two plugins (or themes) use the same name for a function, and both are active at the same time, they will cause a fatal error, since all function names must be unique.
For example, you might have a function in your plugin like this:
001 | load_plugin_scripts() { |
002 | // script loading happens here |
003 | } |
001 | lpa_load_plugin_scripts() { |
002 | // script loading happens here |
003 | } |
Define Constants for File Paths and URLs
This mostly applies to large plugins, but can be useful with smaller ones as well. The absolute path to your plugin’s folder can be used for including extra plugin files, loading templates, and a few other things. I usually define a constant with the path to the plugin’s directory like this:001 | // plugin folder path |
002 | if (!defined( 'LPA_PLUGIN_DIR' )) { |
003 | define( 'LPA_PLUGIN_DIR' , plugin_dir_path( __FILE__ )); |
004 | } |
It is also a good idea to define a constant for the plugin directory’s URL. This will be used for loading assets, like images, CSS files and Javascript files.
001 | // plugin folder path |
002 | // plugin folder url |
003 | if (!defined( 'LPA_PLUGIN_URL' )) { |
004 | define( 'LPA_PLUGIN_URL' , plugin_dir_url( __FILE__ )); |
005 | } |
Organize Your Plugin Into Multiple Files
When you are working with a plugin that has a large amount of code, then separating it into multiple files is one of the best things you can do. You should separate your code into “blocks” that are organized based on what they do. For example, all of your short code definitions should go into a file called “shortcodes.php” (or similar). All of your code that relates to loading CSS or jQuery should go into a file named perhaps “scripts.php”.By separating your code into “blocks” that are each placed into meaningfully named files, you make your job as the developer much easier on yourself. It is suddenly dramatically easier to locate the code you’re looking for, especially when debugging errors. When you want to enhance the functionality of your plugin, perhaps by adding another short code, you immediately know where the new code should go: shortcodes.php.
With smaller plugins, this is not always the case, however. A small plugin with just 100 lines of code could easily be all placed into a single file and still be very manageable, but even in this case, I would still advise you to separate it into multiple files. The main reason for doing this is that it opens the door to further development and expansion. It is a lot easier to organize your plugin early on when there is only a small amount of code than it is to reorganize later once you have thousands of lines.
Once your plugin is separated into multiple files, you will pull the files into the main plugin file like this:
001 | include_once ( LPA_PLUGIN_DIR . 'includes/shortcodes.php' ); |
My plugin folder structure usually looks something like this:
- my_plugin_folder_name
- includes
- admin-pages
- templates
- js
- css
- images
- includes
Format Your Code
There is very little more frustrating to a developer than opening some one else’s code and finding that it is a formatting nightmare. Messy code is usually bad code. A very simple way that you can dramatically help yourself in your development, and help anyone that works with your code, is by taking the time to format your code nicely and consistently.Code should have even indention (I prefer tabs, not spaces) and consistent line breaks. When a chunk of code is nested inside of conditional or switch (or other) statements, it should be indented. Take this bad code for example:
001 | if ( $conditional ) { |
002 | do_action( 'some_action_here' ); |
003 | execute_some_function(); |
004 | } |
001 | if ( $conditional ) { |
002 | do_action( 'some_action_here' ); |
003 | execute_some_function(); |
004 | } |
Do yourself and everyone else a favor: indent and format.
Do Not Reinvent the Wheel
There are a lot of APIs and methods built into WordPress that are designed to make your job as a developer easier, so utilize them and save yourself the trouble of building your own solution.For plugin options, use the Settings API. This API can be a bit confusing to work with at first, but once you figure it out, it is really quite simple, and extremely powerful. Tom McFarlin wrote a phenomenal tutorial series on using the Settings API, if you are unsure about it then definitely check his series out.
For showing data in your plugin in a table format (like Posts and Pages), there is a class called WP_List_Table. This class will do all of the heavy lifting for you, including pagination, filtering, bulk actions, etc, all you have to (to start at least) is provide an array of data to populate the table with.
When creating custom admin screens, make sure of core WordPress CSS. There is absolutely no reason to write dozens (or hundreds) of lines of CSS to style your custom admin pages when, instead, you could use the core styles included with WordPress. There is a pretty decent guide to admin styles at One Extra Pixel.
There are many other general strategies that you can use during development, but these alone will help you tremendously if you choose to follow them.
No hay comentarios:
Publicar un comentario