Remove DEFINER clauses from MySQL dumps

If you have triggers or views in a MySQL database, a dump of that database will have clauses like:

/*!50017 DEFINER=`root`@`localhost` */

To import this dump into a new MySQL server (e.g., going from a production environment to local development), you’ll run into problems if you don’t have the same users defined on both systems.

As far as I can tell, there’s not an easy way to exclude these clauses from the dump, but with just a bit of post-processing, your SQL file can become portable. You can replace the user in the DEFINER clause with CURRENT_USER and it will use the current user when you import the SQL.

$ mysqldump > non_portable_dump.sql
$ sed -E 's/DEFINER=`[^`]+`@`[^`]+`/DEFINER=CURRENT_USER/g' non_portable_dump.sql > portable_dump.sql

Note: Depending on your version of sed, you might need to use the flag -r (for GNU sed) instead of -E (for BSD sed).

Add File Name to WordPress Media Browser

If you have a lot of images in your WordPress media library, especially if those images are visually similar, it can be somewhat awkward finding the correct file using the new media UI. You just have images, with no text to help identify them without clicking on each one.

media-browser

I wanted to add an overlay to each image so that I could see the filename, allowing easier skimming of the media library. The template for the HTML here comes from the function wp_print_media_templates(). It doesn’t really have any hooks for filtering the HTML, but we can wrap it in an output buffer and tweak it before rendering the template.

// hook in at the beginning of the footer to see if we need to add our wrapper
add_action( 'in_admin_footer', 'my_wrap_media_template_callback', 10, 0 );
 
// if the media templates are going to be rendered on this page, remove
// the default hook and put our wrapper in its place
function my_wrap_media_template_callback()  {
	if ( has_action( 'admin_footer', 'wp_print_media_templates' ) ) {
		remove_action( 'admin_footer', 'wp_print_media_templates' );
		add_action( 'admin_footer', 'my_wp_print_media_templates_wrapper' );
	}
}
 
// get the default templates, but add our HTML in the correct location
function wp_print_media_templates_wrapper() {
	ob_start();
	wp_print_media_templates();
	$output = ob_get_clean();
 
	// make sure to keep all of the whitespace here
	$to_find = '<div class="thumbnail">
					<div class="centered">
						<img src="{{ data.size.url }}" draggable="false" />
					</div>
				</div>';
	// this is the HTML that will render our filename
	$to_add = '
				<div class="filename">
					<div>{{ data.filename }}</div>
				</div>';
	$output = str_replace( $to_find, $to_find.$to_add, $output );
	echo $output;
}

A fairly simple wrapper. We’re just adding a <div> in the right spot, and WordPress handles the work of formatting it and populating the correct values.

media-browser-labeled

Integrate fail2ban with CloudFlare

Following my previous post about using fail2ban to stop malicious requests to xmlrpc.php, I set up a CloudFlare account. In doing so, I ran into two issues:

First, my access logs were only showing CloudFlare’s IP address, not those of the users making the requests. That’s due to how CloudFlare proxies every request. Fortunately, CloudFlare provides an Apache module to translate the IP addresses for your logs.

Second, even with the correct IP address in the logs, fail2ban was no longer effective in stopping requests (since it handled the requests before the Apache module translated the IP addresses). I needed to stop the requests at CloudFlare, before they ever made it to my server. Fortunately, it’s simple to set up a fail2ban action that utilizes the CloudFlare API to block those requests. Create an action including:

actionban = curl -s "https://www.cloudflare.com/api.html?a=ban&key=<ip>&u=<account>&tkn=<token>"
actionunban = curl -s "https://www.cloudflare.com/api.html?a=nul&key=<ip>&u=<account>&tkn=<token>"

And set your filter(s) to use that action.

Stop Hack Attempts on WordPress xmlrpc.php

I recently noticed a lot of requests to this and other WordPress sites’ xmlrpc.php file. By “a lot”, I mean about 10-20 every second. It wasn’t particularly breaking anything (there aren’t any currently vulnerabilities there that I’m aware of), but it was increasing the load on my server.

My first step was to set an .htaccess rule to give a 403 response. That at least avoided hitting PHP with all those requests. But Apache still had to process them, so I wanted to take it a step further. I’m already using fail2ban, so I wanted to figure out how to stop these requests at that level instead of waiting until they reach Apache.
Continue reading

WordPress Form API

The short version: I made a Form API for WordPress. Use it in your plugin. Make better forms. Give back and help us all make better forms.

Introduction

If you’ve every written a WordPress plugin, chances are you’ve had to create a form, be it for a settings page, custom post/user meta, widget configuration, front-end user input, or a myriad of other possibilities. If you look at WordPress core or most plugins, you’ll see all of them using pretty much the same method for creating a form field, something very similar to:

 
sprintf( '<input type="text" value="%s" name="%s" />', $current_value, $field_name ');

There are a few special kinds of fields that have pre-existing functions, such as wp_dropdown_pages() or wp_dropdown_categories(). But generally speaking, we’re writing HTML in our PHP (maybe dressed up as a template include).

Lament

I want something better than that. I want a robust API that lets me create forms (or individual form elements), modify them, validate, and process user input. I want themes to have control over the display of forms. I want other plugins to be able to modify and extend my forms.

I tried a variety of existing libraries. Zend_Form from the Zend Framework has a lot to offer, in terms of a robust, object-oriented API. But it’s not very pluggable, and loading the entire Zend Framework just for the Form API is overkill.

I used to spend a lot of time in Drupal, and its Form API is somewhat pleasurable to work with. Forms are amazingly extensible and themeable. But I’m not thrilled with the array-based syntax, and porting it to WordPress would be inappropriate for a multitude of reasons.

Toward a Solution

In the grand hacker tradition, I was dissatisfied with the existing options, so I made my own. I’ve dubbed it WP Forms, and you can download/clone/fork it from its home on GitHub.

What does it do? It’s an API for forms in WordPress. You can use it to create simple form elements. You can use it to create entire forms. You can validate your forms. You can process the submitted information. You can change how elements are rendered. You can wrap elements in themeable markup.

There’s a lot of documentation. It should answer a lot of your questions. And those that I didn’t anticipate, I’d be delighted to answer.

Request for Feedback

WP Forms is surely incomplete. I’m personally not thrilled with the API around adding optgroups to select elements, but I’m not yet sure how to improve it. The API for decorating elements is probably a little complicated for beginning developers, so I’m open to suggestions for a better way to handle that (or at least provide a facade for most common operations). Beyond that, I just don’t know how people would want to use the API. I know how I would use it, but I’m not “people”, and I’m definitely not you; I’m just me.

I can think of several features to add: conditional fields/content, ajax submissions, multipage forms, media uploads, more built-in field types/validators. What features would you want to see?

Request for Contributions

WP Forms will be much more powerful if we can get behind it as a community, extending it, improving it, using it, testing it, documenting it. Do you want an awesome form API in WordPress? I hope you’ll help me make one.