![\"A](\"https:\/\/wpmudev.com\/blog\/wp-content\/uploads\/2014\/11\/cleaners.jpg\")
1. Not Enqueueing Google Fonts<\/h2>\n
Google fonts are added to a theme or plugin either by hardcoding them, or by allowing users to choose them. If you allow users to choose the fonts, the code behind it can get a bit complex and you may forget that adding a link in the header is not the way forward. Enqueueing them is just as easy as any other stylesheet:<\/p>\n
Please update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n Note that the fonts should only be included on pages they are actually used on. See the next section for more information.<\/p>\n Another common practice is to use the enqueues like the example above, but without regard to when they are actually needed.<\/p>\n On the front-end you will probably want to use your fonts on all pages, but on the admin side you may\u00a0only be using them\u00a0on your plugin’s setting page.<\/p>\n Let’s take a look at some ways to target enqueued assets better:<\/p>\n On the user-facing side of your website,\u00a0template tags<\/a> are your friend. The Twenty Fourteen default WordPress theme gives us a great example when enqueueing the comment reply script, which gives us the inline comment form:<\/p>\n Please update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n This script is loaded only when three conditions are met at once: We must be on a single post, comments must be open, and the Another example I like to mention as often as possible is how you can enqueue scripts and styles for shortcodes. If you have assets which are only needed when the shortcode is actually displayed you can register the assets as usual, but only enqueue them in the shortcode. Here’s a quick example:<\/p>\n Please update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n Admin assets can be targeted in two ways. Functions hooked into Please update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n Hook is an extremely confusing name for this parameter, but I have left it in since the WordPress Codex uses this convention.<\/p>\n This is a good way to go about things if you want to target a specific page, but what if you want to target the edit page for a single page (and not a post)? Both instances would be This gives you a lot<\/em> more info about where you are so you can target pages more effectively. To target only edit pages for the page post type, you could use the following:<\/p>\n Please update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n One great way to determine what hook you should use is to look at the codex. If the codex creates admin menus by hooking into Often your features will work no matter which pre-header hook you choose. This doesn’t mean you are writing good code. If a developer wants to modify your code or you come back a year later you will have no idea why your If you are creating a plugin and you end up adding a great number of entries into the options table, you are doing something wrong. The solution here is to save all your options as an array. Remember, you don’t have to worry about saving your data as a string, WordPress takes care of all that behind the scenes.<\/p>\n Please update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n The only time you should use multiple options is if you have sets of options which really aren’t needed all the time. If you only need some options on an admin options panel, you could create a separate options field for that and specifying that it should not be auto-loaded.<\/p>\n Please update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n If something seems like there should be a function for it, more often than not, there is. I’ve seen people shy away from using Please update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n This has the drawback of being completely un-modifiable by hooks as well as doing something WordPress can do on its own:<\/p>\n Please update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n This can be applied to many, many use cases. From pagination to uploading files and obfuscating email address, WordPress has functions for tons of things.<\/p>\n Part of the reason people try to reinvent the wheel is not knowing a function is there. This is fine, after a few Google searches these problems are solved. The other reason is optimization. The urge to “return only IDs instead of post data” drives people to try and write more efficient code.<\/p>\n What people forget is that in 99 percent of cases convention should win over configuration. WordPress is by no means perfect, but it is well-optimized. The speed gain from most of these ventures is negligible compared to the loss of code clarity and standardization.<\/p>\n This has to do with making sure that your plugin cleans up after itself. If your plugin is deleted it should leave no trace of its existence in the file system or in the database. Make sure to remove all options and other data \u00a0you’ve created.<\/p>\n There are two ways to go: The uninstall hook or the inclusion of uninstall.php. Since uninstall.php is recommended, I will not go into detail about the hook itself. To read more about this, take a look at Plugin Developers \u2013 Use Uninstall.php Please<\/a>\u00a0at WP Tavern.<\/p>\n Please update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n This is one of my pet peeves as it has caused me a lot of headaches with users before. Even if you are changing a single line of CSS or you are just increasing the excerpt size of a downloaded theme, use a child theme<\/strong>.<\/p>\n Child themes provide the only way of being able to update a theme after you’ve modified it (without loosing your changes). Child themes\u00a0will always use the files of their parent theme, unless that file is specified inside the child theme.<\/p>\n One notable exception is the functions.php file, which is loaded before<\/em> the parent’s functions file to ensure it can overwrite it.<\/p>\n Child themes are so easy to create. If you want to modify Twenty Fourteen, just create a directory in your themes folder, name it anything you want and add a stylesheet with the following content:<\/p>\n Please update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n Create a Please update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n On the flip\u00a0side of the coin are themes which have poor child theme support. There are roughly two things you need to do here: Make sure to use Please update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n The above 2-in-1 example shows how you can make sure child themes can re-define your functions and how the usage of In this day and age of our interconnected society, there’s just not reason not to make your work multilingual. It’s so easy to do, all you need is to use the language functions and make sure WordPress uses the language files if they exist.<\/p>\n Please update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n To make a string translatable simply wrap it in the Please update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n For more information on how translation works and how you can generate the language files, take a look at the l18n for WordPress Developers<\/a> article in the Codex.<\/p>\n There are a lot of little tidbits\u00a0WordPress users\u00a0\u2013 including myself \u2013 do wrong. If you have any pet peeves of your own, or you know of something major I’ve left out please do let us know in the comments.<\/p>\n2. Enqueueing Resources Where They Are Not Needed<\/h2>\n
Front-End Targeting<\/h3>\n
thread_comments<\/code> must not be empty. This makes sure that the script is only used when it is truly needed.<\/p>\nAdmin Targeting<\/h3>\n
admin_enqueue_script<\/code> receive the file name of the current screen you are viewing.<\/p>\nedit.php<\/code> with our example above. In these cases you can use the get_current_screen()<\/code> function.<\/p>\n3. Using The init Hooks For Everything<\/h2>\n
init<\/code> and admin_init<\/code> is the first hook available after WordPress has loaded but headers haven’t been sent. As such, they are the go-to solution for all our pre-header needs. From legitimate uses of adding post types and text domains, to unnecessary upgrade routines and functionality specific things like enqueuing and adding menus, developers use them for everything.<\/p>\nadmin_init<\/code> (it doesn’t), then go for it. Since it’s apparent that admin menus use a dedicated admin_menu<\/code>, that is what should be used.<\/p>\nremove_action()<\/code> call isn’t working.<\/p>\n4. Too Many Options<\/h2>\n
5. Reinventing The Wheel<\/h2>\n
WP_Query<\/code> because it pulls so much data \u2013 they just need IDs. So they end up writing something like this:<\/p>\n6. Database Clutter<\/h2>\n
7. Not Using Child Themes<\/h2>\n
functions.php<\/code> and use enqueuing to pull the stylesheet of the parent:<\/p>\n8. Not Supporting Child Themes<\/h2>\n
get_stylesheet_directory_url()<\/code> instead of get_template_directory_url()<\/code> where appropriate, and wrap overwritable functions in “if” statements.<\/p>\nget_stylesheet_directory_url()<\/code> is helpful. Otherwise WordPress would always look for the image in the parent directory.<\/p>\n9. Incorrect\/Missing Language Support<\/h2>\n
__()<\/code> function or the _e()<\/code> function if you’re echoing it, and make sure to add your text domain:<\/p>\nThe List Goes On?<\/h2>\n