Using custom template tags with WP to Twitter

Yesterday, I received a support request asking about how somebody could parse a URL out of their post title and post that as the shortened URL attached to their Tweet. They always used the same format to add the URL<a href="http://thedomain.com">The Title</a>.

Well. Not a standard use, certainly — but it is something that you can do using WP to Twitter, with a little custom code.

So this is a good time to write up the custom template tag filter in WP to Twitter. It’s designed to take the value of a custom field and modify it; but it can be used to add almost any custom data to your Tweet.

The filter is wpt_custom_shortcode, and accepts three arguments: the original value coming from the custom field defined in your custom template tag (such as [[custom_field]]), the ID of the current post, and the name of the custom field.

So, if you’re adding a custom template tag like [[custom_field]], the default is to simply grab the singular value of that custom field and add it to your Tweet. if the field is an array, this breaks. If the field doesn’t exist, nothing happens – normally.

However, you can use this filter to custom define almost anything custom field and make it produce the desired result, even if no custom field by that name exists.

In this case, the total code (placed in your theme’s functions.php file) is this:


add_filter( 'wpt_custom_shortcode', 'my_url', 10, 3 );
function my_url( $value, $post_ID, $field ) {
    if ( $field == 'my_url' ) {
        $title = get_the_title( $post_ID );
        preg_match( '/<a href="(.+)">/', $title, $match );
        $url = $match[1];
        return apply_filters( 'wptt_shorten_link', $url, strip_tags( $title), $post_ID, false );
    }
    return $value;
}

Line by line, this adds the filter with the function my_url as a callback. That function, when it detects a field named ‘my_url’, parses the title, gets the URL, then sends that URL through the shortener filter.

This isn’t exactly a richly featured regex – but regex is not exactly ideal for parsing HTML, and this particular user only needed to be able to isolate a URL between double quotes with no other attributes, so it worked for that.

The point, however, is that you can return just about any data — or customize the format of your data — using this filter.

I described another example of this filter in a WordPress support forums thread that you may find interesting.

Another simple example somebody requested via support was to generate a timestamp. WP to Twitter includes a date field by default, but they needed the actual time — so I suggested this, for a custom timestamp:


add_filter( 'wpt_custom_shortcode', 'my_timestamp', 10, 3 );
function my_timestamp( $value, $post_ID, $field ) {
    if ( $field == 'timestamp' ) {
        return date( 'h:i a' );
    }
    return $value;
}

Using custom filters in WordPress is a great way to extend and expand the capabilities of many plugins and themes — hopefully, you’ll be able to benefit from this tip for WP to Twitter!

Taking over GrayBit.com

Mike Cherim and Jonathan Fenocchi, creators of the GrayBit service for showing a site design converted into grayscale, needed to move on. The time and expense of maintaining GrayBit was too much – and since Mike Cherim has moved out of the web development and accessibility world, it was necessary to make some changes. They recently shut down GrayBit.com, not having received any word that anybody wanted to take the site over.

I was too late to save the domain, which is now a travel magazine, but I have saved the service: GrayBit can now be found at http://gray-bit.com. I just did the move this morning, in about an hour, so there may be issues still to be seen – let me know if you encounter any problems!

For now, I’ve moved the service from being advertising supported to being donation supported; so, if you’re a supporter of GrayBit — please consider making a donation! I don’t know yet just what this service might end up costing me…

My Calendar Admin Notice

Admin Notice: The showkey, shownav, showjump, and toggle shortcode attributes have been deprecated. Use above and below instead.

If you’ve recently upgraded My Calendar to version 2.2.0, you may be seeing this notice at the top of your public calendar. This is because I’ve introduced a change in version 2.2.0, and although those four shortcode attributes will continue to work for now, I do intend to remove them completely down the road — so I need people to stop using them sooner rather than later.

The notice is only displayed for logged-in administrators – but it is possible that if you’re using a caching plug-in that the caching plug-in could pick this up; so it’s not impossible for it to be shown to the public.

To make it as easy as possible to switch, I’m going to explain right here (for those who do a search on this error message), what they need to do.

If you’re seeing the message, it means that the shortcode that’s producing your calendar uses one or more of these shortcode attributes:

  • showkey (controls the category key)
  • shownav (controls the previous/next navigation)
  • showjump (controls the quick navigation jumpbox)
  • toggle (controls the list/grid format toggle)

Rather than require a separate attribute to control each of these features, I’ve introduced two simple new attributes: above and below. With these shortcodes, you simply define which fields you want to see, in which position. This gives much greater control — you can now have your previous/next navigation both above and below if you want. You can place the format toggle before the navigation, or after.

Both new attributes support seven values, used as a comma-separated string. The replacement attributes for the original four are:

  • nav (turns on prev/next navigation)
  • toggle (turns on format toggle)
  • jump (turns on quick navigation)
  • key (turns on category key)

There are also three new attributes, configuring additional features:

  • timeframe (toggles to switch between month, week, and day)
  • print (turn on the print view link)
  • feeds (turn on the RSS and iCal feed links

Some of these features — in particular the print view and the feed links — will only show up if they have also been enabled in settings.

Hope that’s helpful!

Update to My Calendar: version 2.2.0

After over 3 months since my last release in the 2.1 series for My Calendar, I’m finally ready to release the next version of My Calendar. There are a lot of changes in this new version — and I think they represent some distinct improvements.

The complete list of changes can be seen in the Change log. That document goes through every change of substance I made. However, some of the more key items include:

  • Basic event search: It’s not complicated, but it sets the stage for future updates.
  • Simple integration with WP to Twitter
  • Time frame toggle: switch your view between month, week, and day view.
  • Variable recurrence schemes: No more “weekly or biweekly” — events happening every 3 weeks or every 6 months are equally supported.
  • Set the order of regions above or below the calendar: No longer just turning nav on or off; now, you can set whether nav is above or below the calendar, whether it’s before or after the jumpbox, etc.
  • aria-live support for AJAX navigation
  • Many other changes and bug fixes!

It’s been a long haul with a lot of testing, but I’m sure it’s not 100% bug free. Find something? Let me know!

Using a shortcode to fetch WordPress plug-in information

I may have a low threshold for managing information, but I find that with seven plug-ins in the WordPress repository it’s a struggle to keep my local information on those plug-ins always up to date. I have a page here about each plug-in, and it’s not uncommon that I’ll publish an update and go to check my local information just to find that my own page on that plug-in is six months out of date…

One way to keep that information nicely in sync is to actually import it directly from the WordPress plug-in repository’s information API. The API documentation is available, if you want to roll your own, but here’s a very basic bit of code to grab it yourself.

Creating a shortcode in WordPress is crazy-easy:


add_shortcode( 'plugin', 'get_plugin' );
function get_plugin( $atts ) {
    extract(shortcode_atts(array(
        'slug'=>''
      ), $atts));
    if ( $slug ) return show_plugin_info( $slug );
}

Woo hoo! You have a shortcode. This shortcode takes one attribute, “slug”, which will be the plug-in slug as seen in the repository. Now, technically speaking, what you have right now is a fatal error, because we haven’t actually defined the ‘show_plugin_info’ function. Fair enough — let’s do that.


function show_plugin_info( $slug ) {
    $body = (object) array( 'slug' => $slug );
    $post_data = array('action' => 'plugin_information', 'request' => serialize($body));
    $return = wp_remote_post( 'http://api.wordpress.org/plugins/info/1.0/', array( 'body' => $post_data ) );
    $plugin = unserialize($return['body']);	
    $return = "
            <p>Current Version: $plugin->version<br />
            Requires: $plugin->requires<br />
            Tested to: $plugin->tested<br />
            Downloads: ".number_format($plugin->downloaded)."<br />
            Last updated: $plugin->last_updated</p>";
    return $return . wpautop($plugin->sections['description']);
}

This is a pretty simple bit of scripting -- and, practically speaking, it's customized to show what I actually do on my own site. You may not want to even use this much code!

I'm using the WordPress wrapper for http requests to get the data -- this is much more reliable than using something like cURL or fopen, because the wrapper will query whatever transport is actually available, rather than depending on the specific wrapper you've defined.

The API is looking for very simple information -- just the slug for the plug-in, and the knowledge that we're accessing the plugin_information API.

With that, we retrieve an object containing all the basic information for the plug-in, largely drawn from the plug-in's readme.txt file. I've only chosen to incorporate a few fields into my site - but you can also grab several other fields this way. These fields are detailed at Dion's API information site, so I won't repeat them here.

This is a very basic shortcode -- simply place [plugin slug='wp-accessibility'] in your post or page and you'll get all the information about the plug-in you referenced.

Not sure how many other people are likely to find this useful...but for my purposes, it's pretty handy.

Speaking at WordCamp MSP on April 27th

It’s official – I’ll be speaking at WordCamp Minneapolis 2013 on April 27th, talking about WordPress and Accessibility. Speaking locally is pretty rare for me, so I’m really looking forward to meeting some other local WordPress people at the event. Oh, and the learning. That, too. :)

The official description of my talk, in the ‘Continuing Education’ track, is:

Covers a wide range of accessibility topics including but not limited to implementing best practice accessibility in theme building, discussing current progress and goals from the WordPress Accessibility P2 group, and address general principles of accessibility that might be of interest to WP developers and designers.

The organizers of the WordCamp are still setting up their speaker matrix, so I don’t yet know yet what my target audience will be — so this is a good time to think about who wants to learn!

Integrating Accessibility with WordPress is a broad topic — and the description reflects it. Are you attending WordCamp Minneapolis (just say yes) and have something you really want to know? Let me know in the comments or via Twitter! I’m listening!

WordCamp Minneapolis 2013
April 27th
Minneapolis Community & Technical College
1501 Hennepin Ave,
Minneapolis, MN 55403

Accessibility Percolation

After a trip to a great accessibility conference like CSUN, I inevitably end up with massive lists of great ideas for things I could work on to promote and improve accessibility.

It is equally inevitable that I will forget some of these and fail to complete others — but documentation helps.

Coming out of the conference, here are a few of the great ideas I’ve talked about with other people here or just had pop into my brain without warning.

  • Incorporate the QUAIL project for dynamically detecting accessibility issues into my WP accessibility plug-in.
  • Develop a WordPress plug-in for using the new WAVE5 API to generate statistics and analysis of WordPress site accessibility.
  • Establish a blueprint-like language for designing wireframes and web design proofs that include accessibility information that is not visibly part of the design. Came out of a conversation with Mike Guill on the problem with developers who only build what’s shown on the wireframe/proof.
  • Finish my already 75% written accessible video management plug-in for WordPress
  • Finally learn more about working with others* through Github or Bitbucket so that I can take advantage of others expertise to improve my accessibility projects.

There’s a good probability that there are other things I’ve thought about this week that aren’t in here. Most likely, I’ve already forgotten them, and will think of them again next year…

“Works well with others” was not a comment my elementary school teachers ever wrote on my report cards.

Page 1 of 42123102030Last

Return to Top