This article introduces one of the most important topics in WordPress development: WordPress hooks, including action hooks and filter hooks. Hooks are at the core not only of how WordPress plugins work, but nearly all code in the WordPress ecosystem: most WordPress themes use hooks heavily, as does “WordPress core” itself. WordPress hooks are absolutely a must-know topic in WordPress development.

It’s a common complaint when you run your WordPress site through any “page speed score” tool: “defer parsing of JavaScript” and/or “remove render-blocking JavaScript.” Today, building on an article Fred first wrote in 2015, I’m going to discuss a was to solve that. It’s been possible since WordPress 4.1, which introduced of a new filter, script_loader_tag. This filter lets us easily change the HTML markup of enqueued script elements—that is, of JavaScript files that were correctly added into a WordPress site using WordPress’s wp_enqueue_script function.

Debugging WordPress starts with WP_DEBUG, but can go far beyond that. In this article, we will:

This course covers the key points of two of WordPress’s most powerful APIs for defining custom post data: custom fields (also called post meta), and custom taxonomies. The course introduces each tool, and then—since some problems can be addressed by either tool—covers practical guidelines for when to use custom fields and when to use custom taxonomies.

Coding makes you follow rules – every language has its own syntax to which you have to adhere if you want your code to compile or run. But there is another set of rules, that while isn’t essential for the actual running the code, helps in peripheral parts of coding. These rules are called Coding Standards.

WordPress posts have two types of texts associated with them: the post’s content, and its excerpt. The content is the main part of the post, and the excerpt is either filled out in its own field or generated by WordPress by extracting the first part of the content.

Internationalization makes WordPress accessible in other languages, and it’s a must-have for work intended for wide distribution.

One could (and perhaps I should) write a whole course on “how to debug in WordPress.” This (unfortunately) isn’t that post, but rather a quick summary of the best first step in debugging WordPress. It is almost the one step you MUST take if you’d going to debug just about anything in WordPress: make sure WordPress is showing the errors by settings WP_DEBUG to true. This isn’t super complicated, but just an invaluable thing to know.