Wrong in many ways

I’m occasionally working on building plugin bridges or integrating some third party APIs on WordPress. Just as often I struggle with unmaintainable code.

Seems like too many people have read the “How To Write Unmaintainable Code” article so I’d better elaborate on this one.

Today I’ve been working on a project using a plugin for various WordPress components, one of them being a search form. I’ve always had a thing about search forms, as being too general as a concept and too vague at all – you will always get to the point that you need another field to search on, or in another way, with different validations and conditions, maybe autocomplete/suggestion, tips and so on. The WordPress default search is also not a perfect framework of building different form solutions but still this could be surrounded on a lower level.

The search form is being placed in the template in the site as a shortcode (with arguments). The shortcode callback function looks like that:

[php]

function search( $args=array() ) {
/* Arguments */
$defaults = array(
‘arg1’ => ‘default1’,
‘arg2’ => ‘default2’
);

$args = wp_parse_args( $args, $defaults );
extract( $args, EXTR_SKIP );

… // one or two conditionals

$display = null;

// 100% static HTML
// using $_REQUEST for input values
if( $arg1 == ‘something’) {
$display .= “<div…><input … value=”{$_REQUEST[‘search’]}” /></div>”;
}
return $display;
}
[/php]

There are various ways to implement a similar functionality, but there are several drawbacks in this code when it comes to extensibility.

  1.  There is no filter for the $args, one cannot filter incoming args (and this is a shortcode, there are unlimited input variables that a user could utilize)
  2. There is no filter for $display either, which has the markup of everything
  3. The $display itself is a concatenated markup that depends on almost nothing…
  4. … but unfiltered $_REQUEST variables.
  5. Besides, if the arg1 value isn’t a match, then the $display would be null

This whole case makes the code both static and unmaintainable. There is no clean way to add new arguments and use them furthermore, the markup would be all the same, unprotected by the incoming requests as well.

A good start is watching Modular Plugins by Pippin.

Leave a Reply

Your email address will not be published. Required fields are marked *