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.
WooCommerce is a great e-commerce plugin for WordPress. It has some very nice basic features, but it’s also easy to customise and extend. On single product pages, you can add to cart with a quantity other than just one, and on the purchase page you can add to cart via AJAX without leaving the page. Wouldn’t it be nice to add to cart with both quantity and AJAX?
Events Manager + Events Manager Pro is a great plugin team for taking bookings for events on WordPress websites. One hitch I’ve struck is that if you as webmaster need to edit a user, and the user hasn’t filled in all their details, Events Manager Pro won’t let you save without filling in all of its required fields (basically, address details). And of course, the chances are that you won’t know what those fields should contain.
The WordPress drag-and-drop menus make it easy to build a custom menu for your website, but adding a login/logout link requires a little PHP code. It’s very simple though, and easy to add to any theme.
WordPress has a good API for adding admin menu items. Unfortunately, it doesn’t allow you to specify a direct link to something, only a “slug” that links your menu item to a callback function to run when your menu item is selected. But fortunately, there’s a hack.
A common problem with input forms is that users get impatient and click the submit button twice. This can lead to double (or triple, or quadruple!) form submissions, which can really mess things up (especially if you’ve added a billing step to your form!) Stopping it can be surprisingly complex, but here’s a simple piece of browser script that will prevent most users from making multiple submissions with Gravity Forms.
When you create a custom post type in WordPress, you can ask register_post_type to generate a default UI for managing your post type in the admin. When you edit your post type, WordPress generates the familiar post editor, just for your post type. You can change it through a variety of hooks, e.g. if you want to add some new meta boxes. But what if you don’t want any meta boxes, not even the standard ones?
In my quest to bring an object oriented separation of concerns to my WordPress plugins, I tend to separate the administration of each custom post type into its own class. I do this by looking at the global variable
$typenow after the admin_init action is fired. But
$typenow isn’t always set after admin_init, so I have to improvise a little.