For a while now, I’ve been using the amazing Trello to help me keep track of various tasks. Sure, I use various bug trackers like Mantis and GitHub Issues too, but for some of the more high-level tasks it’s just easier with Trello. One job it’s particularly good at is helping me keep track of plugin compatibility testing.
I recently had to enable user registrations on a WordPress multisite, so that shops on that site could allow customers to register. I don’t want users to register any other way, only through specific applications on specific subsites. Enabling user registrations adds a “register” link to the wp-login.php script page. That invites trouble!
If you need to have SKUs on products in WooCommerce, but don’t want to show them on the front end, you can’t just untick an option in the WooCommerce settings: you can either have and show SKUs or not have them at all. So here’s a quick snippet that lets you have them, but remove them from the front end.
Running a blog, even a low-volume out-of-the-way blog like mine, attracts spammers. It’s a simple fact of life. If you have comments turned on, you will get spam. There’s lots of ways to deal with that, but no way to stop it coming. Lately, it’s been hammering the server hosting my blog, so I decided to change how I was dealing with spam by essentially outsourcing most of the problem to Disqus.
WordPress custom post types can be very useful for storing all sorts of different types of data in WordPress — and I should really write a post about that some time. But the date a post was published, i.e. its post_date, isn’t important for many custom post types. So why have a drop-down list of dates to filter your custom posts types by if you don’t need it?
I’ve been using the fabulous WP Migrate DB Pro since June; it makes it really easy to duplicate the data from one WordPress website onto another, something that developers need to do frequently, and it handles the problems of moving serialised data from one server to another without breaking it. When pulling data from a production server to a development or test environment, it also (by design) replaces all your settings, which might mean that test emails go to your clients — can anyone say, “Dear Rich Bastard?” Thankfully, it also offers a couple of save-your-backside solutions.
When integrating non-WordPress PHP software into WordPress, sometimes the two butt heads over little things; pagination is one such thing. WordPress likes to move pagination into the pretty URL and out of query parameters. If your non-WordPress software generates content with URLs that have page= in query parameters, that means a redirect each time such a URL is fetched. A little regular expression magic can help fix that, with some assembly required.
Gravity Forms plus its PayPal add-on make for a very easy donations form (and so does my Gravity Forms eWAY add-on). But the PayPal item description is pretty formulaic, and probably doesn’t represent the donation very well especially when there are multiple options. A simple filter hook with a few lines of code can easily fix that though.
As Debugging in WordPress explains, it’s easy to get good debugging information into a debug.log file while developing WordPress plugins and themes. Unfortunately, it sets the PHP error reporting level to
E_ALL, which includes
E_STRICT and can throw so much noise into the log that you can’t find the useful information. What we need is a way to turn on the debug log but specify the error reporting level.