add support for google analytics

[willnorris]

optionally append query parameters to the redirect URL to track usage (see example in http://aaronparecki.com/URL_Shortener_as_a_Search_Interface)

[pfefferle]

What do you think about adding a filter to legacy_redirect and redirect_request so everyone could add the params he need?

For example like that:

  function redirect_request( $type, $id ) {
    $url = apply_filters("hum_redirect_base_{$type}", false);
    if ( $url ) {
      $url = trailingslashit($url) . $id;
      $url = apply_filters("hum_redirect_url", $url);
      wp_redirect( $url );
      exit;
    }
  }

and

  function legacy_redirect() {
    if ( is_404() ) {
      global $wp;
      $post_id = apply_filters('hum_legacy_id', 0, $wp->request);
      if ( $post_id ) {
        $permalink = get_permalink($post_id);
        if ( $permalink ) {
          $permalink = apply_filters("hum_redirect_url", $permalink);
          wp_redirect($permalink, 301);
          exit;
        }
      }
    }
  }

[willnorris]

yeah, that would probably be the cleanest approach. Would only be a few lines of code, and allows it to work for other analytics engines as well.

For redirect_request, I think it really only makes sense to add analytics data for destination URLs you control. So that would certainly include all WordPress-hosted content, and could potentially include non WordPress-hosted. Maybe just passing the $type as part of the filter call would be sufficient? That puts a bit more work on the person implementing the hook, but I'm not sure it's avoidable since they're the only ones who would know if a given destination URL is one they control and should therefore include analytics data.

[pfefferle]

Passing the $type is a good idea because it supports both, adding params to every url or only to a specific type of urls.

[willnorris]

For the simple case, where only WordPress-hosted content should have params add, we could have a separate filter that is only called from within redirect_local. It still operates on the same array of parameters, but makes it much easier for developers to hook into local content only, without having to check the type.

I'll take a stab at it.

[willnorris]

hmm... looking at this does make me question one of the earlier design decisions. Right now, hum_request is setup as an action, and functions that hook into are expected to actually do the redirecting themselves. For example, look at redirect_request_i. This makes it difficult to have a generic method for things like appending query arguments to the final redirect URL. I think things will need to be restructured such that hum_request is instead a filter, so that query args can be uniformly attached before the redirect.

That could be done in a backwards-compatible way if we use new names for the filters. Unfortunately, I don't have a sense for how many people have actually hook into those actions, to know if backwards compatibility is really a concern.

[pfefferle]

I have kind of the same problems with refactoring the webfinger plugin! let me know if i can help you in any way!

[willnorris]

heh, actually thinking more about it, if I switch this to using a filter on the URL, rather than an action, there's no need to do anything else. Anyone could just add a late priority filter that appends whatever query parameters. Much simpler :)