For a long time, premium WordPress plugins and themes were sold as a one-time payment. So for example, if you wanted to buy a new WordPress theme, you would make a single purchase and own the theme indefinitely, with no future payments due. Then somewhere along the way, a recurring pricing model became popular. These days, it is very common for themes and plugins to be sold via recurring payment scheme. So for example, if you want to use some awesome pro plugin or theme, you pay an annual or in some cases monthly fee.

WordPress plugins that clean up after themselves are pure awesome sauce. If you are developing a plugin that adds any sort of data to the WordPress database, it is important that the plugin removes any unwanted or unused data if and when the plugin ever is uninstalled. This complete guide explains useful techniques for doing this using the powerful and handy uninstall.php file.

There are numerous ways to add custom content to your WordPress feeds. If you’re not using a plugin, it’s possible to just add a code snippet to your theme’s functions.php file. For most cases, I think probably going the plugin route is the easiest way to add custom content to your WordPress RSS/feeds. Just install, activate, add your content and done. But for WordPress developers and designers who want more fine-grained control, this article explains how to add custom feed content programmatically using the WP API. So whether you need to add copyright text, advertisements, hyperlinks, or virtually anything at all, this post explains how to make it happen.

If you are a WordPress developer, you may have used the WordPress hook wp_print_scripts to add any necessary inline JavaScript. Alternately, you may have used the function wp_localize_script() to add your inline scripts. But did you know that not too long ago, WordPress added a new function for adding inline JavaScript? Yep, as of WordPress version 4.5 and better, we can use the superior function wp_add_inline_script() to do the job.

One of the nice things about this newer function is that you can associate it with any registered script AND include more than just JavaScript variables. This DigWP article explains how wp_add_inline_script() works, why it’s better than either of the alternate inline methods, and how to support older (pre-4.5) versions of WordPress. Along the way, we’ll look at some example code that you can customize and use in your own WordPress projects.

WordPress provides a widget that can be used to display recent posts in any sidebar or widgetized location. Likewise many WordPress themes provide some sort of “recent post” functionality, so users can display their latest posts in specific locations around the theme. Such functionality is great and useful for displaying recent posts just about anywhere in your theme. Problem is, those methods don’t work for displaying recent posts inside of posts, pages, and custom post types. Like inside of post content itself. For that, we can use a shortcode.

One of the few regrets anyone can have in an online business is the failure to collect email addresses of their visitors. Simply put, the failure to have a list.
More often than not, you will hear people say, “the money is in the list” and that by itself is a statement of truth. Email list gets people coming back to your website, and by extension increases profit in business, because you are already dealing with a targeted audience.

Previously we posted a list of available WordPress Developers & Designers. Lots of great people and companies shared their information, but a lot has changed since then. So rather than try to contact everyone on the list and ask them to update their infos, here is a new post of current WordPress developers & designers.

One of the most annoying things in the WordPress universe are plugins and themes that don’t conditionally load their scripts and styles (i.e., JavaScript and CSS files). For example, you install a dashboard plugin and it loads its scripts in the entire Admin Area and the frontend. Instead, the developer should have used conditional logic to NOT load the script on the frontend (e.g., via !is_admin()), or anywhere in the Admin Area EXCEPT the dashboard (e.g., via get_current_screen()). It’s just basic human decency.