Posts categorized: Plugins
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.
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.
!is_admin()), or anywhere in the Admin Area EXCEPT the dashboard (e.g., via
get_current_screen()). It's just basic human decency.
Just to be crystal clear, this post is all about displaying basic statistics about your site, not about your visitors. So if you are thinking something like, "duh, just use Google Analytics or whatever," then imagine a giant buzzer sound telling you that you're incorrect. Sure, Google Analytics gives you information about your visitors, like how many, where from, how long, and so forth. But GA et al do NOT provide information about your site itself. Things like the number of registered users, number of posts and pages, number of comments, and all the other cool little details about your site. That is what we'll be covering in today's DigWP tutorial. So grab some popcorn and enjoy the show! ;)
Just a quick post to share some recommended useful resources for anyone working with the new Gutenberg Block Editor. Our book Digging Into WordPress now links to this post, so readers can learn more and dive deep into Gutenberg. Or just bookmark for future reference. What does that mean? It means that this page will be updated with any new useful and official resources. And by "official" just means the information is sourced/hosted at WordPress.org.
Previously, we covered numerous techniques to disable Gutenberg. For example, you can disable Gutenberg on specific post types, user roles, post IDs, and so forth. But what about doing the opposite and conditionally enabling Gutenberg? For example, if Gutenberg is disabled by default, you could then selectively enable it on whichever post types, user roles, or whatever criteria that's required. So this tutorial explains how to enable Gutenberg using simple WordPress filter hooks. You'll learn how to enable Gutenberg for any single posts, new posts, post meta, categories, tags, and post types. Plus some juicy tips and tricks along the way!
During the latest site redesign, I removed the Subscribe to Comments plugin. Wisely, the plugin does not delete any subscriber information from the database. So as a part of the site's redesign slash clean-up, I wanted to export/save and then delete all subscriber information to decrease overall database size. After searching and not finding any specific solution or preferred technique for this process, I rolled my own. Actually it's just a simple SQL query to get it done! :)
I think many WordPress users probably underestimate the amount of data that is made available via the REST API. Just about everything is available to anyone or anything that asks for it: posts, pages, categories, tags, comments, taxonomies, media, users, settings, and more. For most of these types of data, public access is useful. For example, if you have a JSON-powered news reader, it can basically replicate your entire site structure virtually anywhere. But that easy access invites potential abuse. Just like with RSS feeds, RESTfully delivered JSON content is easily scraped and used for spam, phishing, plagiarism, adsense, and other foul things.
Gutenberg soon will be added to the WordPress core. This is great news for some, not so great for others. With 99.9999% (estimate) of all WordPress sites currently setup to work without Gutenberg, the massive changes barreling down the pike are going to affect literally millions of websites. And as swell as the whole "Gutenberg" experience may seem, the simple truth is that a vast majority of site owners will not be prepared when it finally hits. Nor will many small business have time or budget to test and update client sites to accommodate ol’ Gut’.
Gutenberg is coming soon to your WordPress, whether you like it or not. Debate and drama aside, it's time that we start looking for practical ways to adapt current WordPress sites to the many imminent changes brought to us by G7G. One of these changes involves Custom Fields. Currently, and hopefully this will change in a future update, Custom Fields are not displayed on Gutenberg-enabled screens. Which is kind of a bummer, considering the millions of websites, plugins, and themes that make good use of them.
I've been working on updating my collection of WordPress plugins for the imminent Gutenberg update. So far it has not required much time to learn, and the API is straightforward. It will however take significantly longer to integrate Gutenberg support into 20+ plugins. To help keep things organized, I will be posting tips and snippets here at DigWP.com. Blocks are the foundation of all things Gutenberg, so this first post is all about block recipes. Some of these code snippets are far less useful than others, hopefully they will be useful to others.
There has been lots of discussion about the new WordPress "Gutenberg" project. Some people love it, some hate it, and most WP users probably have no idea about it. And that's too bad, because it means many changes will be required for thousands of WordPress plugins and themes. We're talking about MANY collective work hours to make it happen, even in a best-case rollout scenario.
As you work in the WordPress Admin Area, you'll undoubtedly encounter "admin notices" that let you know about errors, updated settings, required actions, and so forth. Most default admin notices are provided by WordPress out of the box, but it's up to plugins and themes to provide any custom notices that may be required. This DigWP tutorial digs deep into WordPress admin notices and explains how to implement, customize, and everything in between.
A frequent question in the WordPress community is "how many plugins is too many?" We've heard responses that vary from "zero" to "no limit, man".
So for this DigWP Poll, I figured it would be interesting to see what people think about it. To give you a better idea, I've posted some screenshots of sites running LOTS of plugins. So check ’em out and then cast your vote!