Check for PHP version compatibility problems in WordPress plugins, with support for just a few files running in PHP 5.2.
The Gravity Forms Add-on Framework makes the job of creating an add-on really easy. But there’s a couple of problems with letting it load our text domain for us:
PHP has some handy Date classes, including one for specifying date intervals. But you need to be wary of some idiosyncrasies, as I just found out.
Sometimes the WooCommerce out of stock message isn’t quite appropriate. Here’s a couple of ways to change that message.
Ever needed to search for a post by something other than the title or post content? If you’ve built a website with custom post types that have additional fields, it’s a good chance that admins will need to search on your custom meta.
Customising the AJAX output of WordPress plugins can often be a breeze, when the authors oblige other developers by peppering their code with action and filter hooks. But if they don’t, you can always fall back on hacking the plugin’s AJAX action.
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.
I’ve heard many times that PHP doesn’t really do Unicode, or not properly. In seven years of working primarily in PHP, always in UTF-8, I’ve never really hit a problem, so I always figured it was something esoteric and unimportant for me. But already this year I’ve seen this problem twice, in different ways.
I struck an odd problem recently with some code using closures. I use closures extensively for WordPress filter and action hooks when building custom plugins and themes for websites, and all usually works well on any version of PHP from 5.3 up. But I was finding that my closures weren’t being called on some PHP 5.4 websites. The problem was eAccelerator.
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.
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.