Posts Tagged ‘plugin’

Foursquare Checkins, Maps And WordPress; Now With MOAR Maps

If you’re an avid Foursquare user you can already display your last checkin, visualised on a map, in the sidebar of your WordPress powered site with the WP Quadratum plugin. Foursquare, checkins and maps … what more could you ask for? Maybe the answer is more maps.

Version 1.1 of the WP Quadratum plugin, which went live this morning, now has added maps. The previous versions of the plugin used Nokia’s maps, because I work for Nokia’s Location & Commerce group and I wanted to use the maps that I work on. But if Nokia’s maps aren’t the maps for you then how about Google’s, or maybe CloudMade’s OpenStreetMap maps or perhaps OpenLayers’ OpenStreetMap maps.

Thanks to the Mapstraction JavaScript mapping API, WP Quadratum now allows you to choose which mapping provider you’d like to see your checkins appear on. And if you don’t want a map on the sidebar of your site, you can embed the checkin map in any post or page with the plugin’s shortcode too.

As usual, the plugin is free to download and use, either from the official WordPress plugin repository or from GitHub.

As a fully paid up and self confessed map geek I may be somewhat biased but surely most things can be improved with the simple addition of more maps.

Written and posted from home (51.427051, -0.333344)

Tracking Down Use Of Deprecated WordPress Functions Or Arguments

If you’ve been running your blog or site on WordPress for any period of time, you may well have come across a message about a deprecated function or argument in your PHP log file or across the top of a page on your site. The message might look something like this …

Notice:  get_bloginfo was called with an argument that is deprecated since version 2.2! The siteurl option is deprecated for the family of bloginfo() functions. Use the url option instead. in /var/web/htdocs/site/wp-includes/functions.php on line 2712

… this often appears after you’ve installed or upgraded a new theme or plugin. This message is helpful but really only 50% useful. The PHP file and line number that’s being reported isn’t where the deprecated function or argument is being used; it’s where it’s being reported from. Often, even after you’ve searched through the source code of the new plugin or theme you’re still none the wiser about where the troublesome piece of PHP that WordPress is telling you about actually lives. WordPress is a complicated mix of PHP, JavaScript and CSS; there’s a lot more going on under the hood than most of us are remotely aware of.

Thankfully WordPress also helps provide an answer, through an undocumented action hook called deprecated_argument_run; that’s undocumented in the WordPress Codex, it is documented in the core WordPress source code, if you know where to look. The clue to unlocking this problem is a comment in wp-includes/functions.php which says There is a hook deprecated_argument_run that will be called that can be used to get the backtrace up to what file and function used the deprecated argument. So here’s how to get that backtrace.

Put the following code somewhere on your site, maybe in your theme’s functions.php, where it will get called by WordPress. Now I know this seeminly contradicts what I said in an earlier post but this is a temporary piece of debugging code and not a permanent feature of your site; I might just make it a plugin some day though.

add_action ('deprecated_argument_run', 'deprecated_argument_run', 10, 3);

Now add the hook function that gets called when a deprecated argument is detected.

function deprecated_argument_run ($function, $message, $version) {
	error_log ('Deprecated Argument Detected');
	$trace = debug_backtrace ();
	foreach ($trace as $frame) {
		error_log (var_export ($frame, true));
	}
}

Reload a page on your site and you’ll see a back trace in your PHP error log of precisely where the deprecated argument is being used.

This technique isn’t limited to deprecated arguments, there’s also action hooks for deprecated functions (deprecated_function_run), deprecated files (deprecated_file_included) and something being incorrectly called (doing_it_wrong_run), all of which can use the same form of back trace technique.

You’ll probably need to ensure that WP_DEBUG is enabled in your wp-config.php and don’t forget to remove your debug code and disable WP_DEBUG after you’ve finished.

Written and posted from home (51.427051, -0.333344)

Of CSS, Pointers, Archive Pages and Meta Boxes; WP Biographia Reaches v3.2

WP Biographia v3.2 got pushed to the WordPress plugin repository this afternoon. In the grand scheme of things it’s not a massive release but it goes a long way to solving some of the most frequently asked questions that arrive in my Inbox and via the plugin’s support forums.

As I’ve mentioned a few times in the past, it’s nigh on impossible to test a WordPress plugin against the myriad combinations of themes and plugins that exist in the WordPress ecosystem. Especially where CSS is concerned, plugins and themes frequently don’t play well together and bleed over from another theme or plugin’s CSS often makes WP Biographia’s formatting look … interesting. This tends to happen in two places. Firstly in the formatting of the contact links in the Biography Box and secondly in the positioning of the user’s avatar image.

Wp Biographia v3.2 provides two workarounds for this. The plugin’s CSS now uses the !important CSS specifier to ensure the CSS is applied as it should be in as many cases as is possible.

But sometimes this isn’t enough to fix formatting issues, especially if the plugin’s the_content filter priority has been dropped below the default value of 10, to get the Biography Box to appear in the right order with the output of other plugins. In this case, the WordPress wpautop filter, which automagically adds paragraph tags, runs after the Biography Box is produced. In this situation you can now tell the plugin to synchronise the wpautop filter to run after the Biography Box is produced.

WordPress v3.3 added support for Pointers; helpful little pop-ups in the WordPress admin screens that display useful information. WP Biographia now supports these and when you install or upgrade you’ll see a what’s new popup, plus a guided tour of the plugin’s settings tabs.

Another frequently requested feature was the ability to break down the display of the Biography Box on archive pages from an all or nothing basis to one where you can select which one of the author, category, date or tag archives you want the Biography Box to appear on. WP Biographia v3.2 now supports this ability.

The full list of new features and bug fixes for v3.2 looks something like this.

  • Added: Support for synchronising the use of wpautop via the the_content and the_excerpt filters to ensure these filters fire before the Biography Box is produced when the plugin’s filter priority is less than the default filter priority to avoid formatting issues for contact links.
  • Added: Support for WordPress Pointers to display “what’s new” information post install or upgrade and to provide a “guided tour” of the plugin’s settings and options.
  • Added: Support for displaying the Biography Box as a widget.
  • Added: Support for a shorter biography to the user’s profile to be used in conjunction with the Biography Box widget.
  • Added: Support to display the Biography Box for all types of archive page; author, category, date and tag.
  • Added: Custom meta boxes to the post/page/custom-post creation/editing screens to hide the Biography Box, making it easier to define the Admin screen’s Exclusion settings.
  • Added: Support for the shortcode’s user attribute; deprecating support for the author attribute.
  • Added: Increased the width of text and select boxes for the Admin and Exclusion admin tabs to allow for longer category names and longer lists of post IDs to be displayed.
  • Added: Wrap the plugin’s avatars (if present) in plugin specific CSS code to prevent theme specific CSS bleeding into the Biography Box.
  • Fixed: The layout of the Biography Box for feeds now ignore displaying contact links as icons and formats them as plain text.
  • Fixed: Example use of the wp_biographia_feed filter in readme.txt.
  • Fixed: Bug where the wp_biographia_feed filter was never called in the context of a feed.
  • Fixed: Formatting of HTML for the Biography Box post/page hiding options in the user’s profile.
  • Fixed: Use the term “hide” consistently across the plugin and documentation; previous versions used “hide” and “suppress” interchangeably.
  • Fixed: Use the term “user” consistently across the plugin and documentation; previous versions used “author” and “user” interchangeably.
  • Fixed: Bug where the last page of a multiply paged post was not correctly detected, resulting in the Biography Box being displayed for all pages.

So where does WP Biographia go from here? That’s a very good question. Unless there’s a major feature which the plugin doesn’t support and which no-one has (yet) asked for I think the plugin will stay pretty much as is for the foreseeable future. For now, the plugin is relatively flexible and fast and I want it to stay that way. Unless you know better. In which case, let me know in the comments.

Don’t Go There, Go Here; A WordPress Redirection Plugin

Despite having written 5 plugins for WordPress I’ve only just scratched the surface of what it’s possible to make WordPress do. So when I want to make WordPress do something that I’m not sure a) how to do and b) whether it’s even possible or not, I turn to a search engine. More often than not I get an answer. Often that answer seems to start along the lines of

put the following code in your theme’s functions.php file

It’s not that this is wrong but I have a slight issue with hacking a theme’s functions.php file, for a number of reasons. Firstly this is theme specific; change your theme and your modifications still exist, they’re just in your old theme and you’ll need to remember to copy and paste them over to the new theme. Secondly, any file which is part of a theme can, and probably will, be overwritten on a theme update and unless you’ve saved a copy of your changes to functions.php, you can wave them goodbye.

So whenever I see the magic phrase put the following code in your theme’s functions.php file, nine times out of ten I mentally read this as this should really live in a plugin.

Which is exactly what happened when I wanted to set up a redirection so that anyone hitting the URL of a certain post on my blog would be automagically redirected to another URL. The most common solution to this was to set up a custom field, called something like redirect and then hook into template_redirect, check for the custom field in the post metadata and then fire off an HTTP 301 redirect via wp_redirect. Where should I do this? In my theme’s functions.php of course. I naturally read this as this should be in a plugin. A quick search through the WordPress plugin repository revealed that there were plugins that sort of did this, but none of them did precisely what I wanted.

Thus was WP Avertere born. It was originally going to be called WP Redirect but that plugin name was already taken and so, in line with some of my other WordPress plugins, WP Biographia and WP Quadratum, WP Avertere, named from the latin for “divert” came into being.

The plugin does all of the above custom field mangling, template_redirect hooking and wp_redirect redirecting that I could have done in functions.php. But it does this … cleaner.

The plugin adds a custom meta box to the Admin Edit screen for posts, for pages and for any custom post type. It allows you to check your redirection URL for well formed-ness. It allows you to set up temporary and permanent redirections. It hooks into the page_link and post_link hooks so that whenever you see a permalink to the old URL it’ll read as a permalink to the new, redirected URL. And most importantly of all, it allows you to cancel an existing redirection for those times when you decide you don’t want a URL to be redirected after all.

As with all the WordPress plugins I’ve written, and this is plugin number 6, the code is up for forking and hacking around on GitHub. It’ll also be on the WordPress Plugin Repository once I’ve published this post and submitted the plugin to the benevolent WordPress plugin overlords. Until then, you can download the plugin’s source in one convenient archive right here, as GitHub’s downloads don’t, for some reason, include Git submodules.

But one final caveat. What happens if the original post or page that you want to redirect has comments? With this first version of the plugin the comments will still be there but you won’t be able to see them as the redirect will automagically push you to the new, redirected, URL. I’m well aware that this is a shortcoming and the next version of the plugin will support the ability to copy the comments from the source post to the new, redirected, post.

WordPress Shortcodes; Documenting The Undocumentable

WordPress shortcodes. A great idea. Small snippets of text with a special meaning, enclosed in left and right angle brackets. Put one of these in a WordPress post or page and WordPress automagically expands the shortcode and replaces it with the thing that the shortcode does.

WordPress has a built-in set of shortcodes and many plugins add to this repertoire, adding one or more of their own shortcodes. But here’s the problem. Shortcodes are meant to be expanded and in 99.999% of cases, that’s just what you want to do. But what happens if you’re one of those 0.001%; you’ve written a plugin that adds a shortcode and you want to document it. You can’t just write the shortcode in a post as WordPress will go ahead and expand it for you.

You could take the time and effort to replace the [ and ] characters which surround a shortcode, writing something like [shortcode], which is exactly what I’ve been doing since I released the first version of WP Biographia. But this is a long and laborious process. Frankly, it’s boring and a pain in the backside.

But then I noticed a crucial phrase in the documentation for the WordPress Shortcode API

The shortcode parser uses a single pass on the post content. This means that if the $content parameter of a shortcode handler contains another shortcode, it won’t be parsed

… in other words, if you put one shortcode inside another shortcode, the shortcode inside won’t be automagically expanded by WordPress for you. Which is exactly what I wanted to stop me from constantly having to write posts using the HTML entities for [ and ].

So, despite the irony inherent in writing a plugin to stop the shortcode from another plugin working, I hacked together WP Shortcode Shield. As far as plugins go, it doesn’t really do much, it just defines two shortcodes, one called [wp_scs] and a slightly more long-winded one called [wp_shortcode_shield] which allows me to wrap references to other shortcodes in a post without WordPress doing what it’s supposed to do, but which I don’t want it to do.

Which means I can write this post … without having to worry about WordPress shortcodes. Of course, this feature of the WordPress shortcode API may well be fixed at some point, in which case WP Shortcode Shield will promptly stop working, but for now, it does the job. As with all of the other plugins for WordPress I’ve written, it’s sitting in the WordPress Plugin Repository right now, as well as living on GitHub.

Photo Credits: Erik Hersman on Flickr.
Written and posted from the Hilton Berlin Hotel, Berlin (52.51191, 13.3926)

Two WordPress Plugins And The (Missing) Nokia Map

It’s a glaringly obvious oversight but a few month’s back I realised that given what I do for a living, there’s something missing from my blog and that something is a map.

There’s a whole slew of “where am I” style WordPress plugins out there, but after some careful research I decided that none of them did precisely what I wanted, which was to show the last check-in I made on Foursquare, on a map, in the sidebar of my blog.

Those that did come close still didn’t do the key thing I wanted and that was to use the map I work on as part of my day job. Now don’t get me wrong, I’ve got nothing against the maps that I could have used; Google, Bing, Mapquest and OpenStreetMap produce very fine maps and they all have the JavaScript API I’d need to display my last checkin. But none of them used my map and that means a Nokia Map.

So taking what I’d learnt about WordPress plugins during the course of producing 12 versions of the WP Biographia plugin, I rolled up my sleeves (mentally and literally) and started work on what would become WP Quadratum. I seem to have a thing about naming my plugins using a Latin derivation of their name; I have no idea why, but it seems to be better than something along the lines of WP Yet Another Foursquare Checkin Plugin. But I digress.

Several months later, after wrestling with getting a plugin to authenticate with Foursquare via OAuth 2 and learning how to write not only a WordPress plugin but also a WordPress widget, WP Quadratum appeared on the sidebar on my blog. It’s over there right now, towards the top right of your browser screen, unless your reading this on a mobile device, in which case you’ll just have to take my word for it for now.

Now Nokia allows free and unauthenticated use of the JavaScript Maps API, but only up to a certain number of transactions over a lifetime. So I also built in support for supplying Nokia’s Location API credentials as well. But then I stopped. Why build custom support for authentication and credentials into a plugin, only to probably have to copy-and-paste the code into another plugin I write that will use the same Maps API? So I digressed again and wrote another plugin, WP Nokia Auth, that handles the Nokia credentials for me, and then made WP Quadratum play nicely with WP Nokia Auth, if it’s installed, active and configured.

It took a while, but v1.0 of both plugins are now up on the WordPress plugin repository and on GitHub as well, for the usual forking, downloading, hacking and poking around. Whether they get the same number of downloads as WP Biographia has (over 7,000 to date) I somewhat doubt, but unless I release these, I’ll never know, so that’s just what I’ve done.

Written and posted from home (51.427051, -0.333344)

Finally WP Biographia v3.0 Makes It Off Of The Starting Blocks

It’s taken a while but I just did this …

$ rsync --recursive --verbose --exclude '.git' * ~/Projects/svn/wp-biographia/trunk/
$ svn up
$ svn stat
$ svn ci -m 'Updating with v3.0 changes from master on github'
$ svn cp trunk tags/3.0
$ svn ci -m 'Tagging v3.0'

… and after much coding, rewriting, testing and documenting, v3.0 of WP Biographia has finally made it off of the starting blocks.

As per usual, you can read the change log here, grab the source here, or download it here.

But what I really want to say, right here, is what you’ll find in the Acknowledgements side bar after you’ve installed the latest version.

The fact that you’re reading this wouldn’t have been possible without the help, bug fixing, beta testing, gentle prodding and overall general warmth and continued support of Travis Smith and Bruce Munson. Travis and Bruce … you’re awesome. Thank you.

Photo Credits: tableatny on Flickr.
Written and posted from home (51.427051, -0.333344)

Hacking WP Biographia’s Appearance With CSS

The contents of the Biography Box that the WP Biographia WordPress plugin produces are easily customisable through the plugin’s settings and options. The upcoming new version of the plugin will add to this, allowing almost limitless options for adding to the Biography Box though cunning use of the WordPress filter mechanism. But what if you’re happy with the content of the Biography Box, but want to change the way in which the Biography Box looks? This is easily achievable with a little bit of CSS know-how.

The layout of the Biography Box that WP Biographia produces looks something like this …

<div class="wp-biographia-container-xxx" style="background-color:#FFFFFF;">
<div class="wp-biographia-pic" style="height:100px; width:100px;">
<img ... />
</div> <!-- end image div -->
<div class="wp-biographia-text">
<h3>Biography heading</h3>
<p>Biography text</p>
<div class="wp-biographia-links">
<small><ul class="wp-biographia-list wp-biographia-list-xxx">
</ul>
</small>
</div> <!-- end links div -->
</div> <!-- end biography text div -->
</div> <!-- end biography container div -->

The main container is styled by wp-biographia-container-xxx, where xxx is one of top, around or none depending on your chosen Biography Box border option.

The author’s photo, if present, is styled by wp-biographia-pic; note that the photo size is not CSS style-able as it’s specified by the plugin’s settings and the plugin emits the style="height:size-px; width:size-pix;" for you based on that setting.

The biography text and social media/contact links are styled by wp-biographia-text, the biography text by wp-biographia-text p and the links by wp-biographia-list and wp-biographia-list-xxx, where xxx is one of text or icon dependent on whether you’ve selected the links to be text or icons (oddly enough).

The links are also styled by ul.wp-biographia-list-xxx li (again xxx is one of text or icon) and if you’re using icons there’s also .wp-biographia-list-icon a:link and .wp-biographia-list-icon a:visited. Finally, the icon size is styled by .wp-biographia-item-icon.

All of this is in the plugin’s CSS file which is usually located at /wp-content/plugins/wp-biographia/css/wp-biographia.css.

Hopefully all of this will give you enough information to go on to add/tweak the CSS to your liking, but …

Where does the CSS you’ve tweaked go? There are several schools of thought on this.

Firstly, you can just hack the plugin’s CSS directly. It’s quick. It’s easy. But it’s also fraught with risk. Not only are you messing with the plugin, which may have strange and unforeseen side effects, but your changes will be over-written when you update the plugin to a new version.

Secondly, you can just hack your theme’s CSS directly. But as with the plugin’s CSS, this will get overwritten with an updated version when you upgrade the theme.

The third way, is to add the CSS to a new file and to use the theme’s functions.php file to load the CSS into your pages and posts. Now granted, the theme’s functions.php file may still be overwritten during an upgrade but themes tend to be updated less than plugins and you are still able to isolate the CSS in a file which isn’t part of the WordPress core, the plugin or the theme.

So here’s how you do this. Put the CSS you want in a file, let’s call it custom.css, and place this into the same directory as the root of your theme. If you’re using the TwentyTen theme for example, the path would look something like …

/wp-content/themes/twentyten/custom.css

Now you need to get your theme to load the custom CSS. To do this you need to add a function to load the CSS to the wp_enqueue_scripts hook and then within that function, make the CSS get loaded in addition to the other CSS your theme uses. This code goes into your theme’s functions.php and looks something like this …


add_action ('wp_enqueue_scripts', 'add_custom_css');
function add_custom_css () {
	$uri = get_stylesheet_directory_uri ();
	wp_enqueue_style ('custom-css', $uri . '/custom.css');
}

Written and posted from the Marriott Marquis, San Francisco (37.7581, -122.4056)

WP Biographia Hits v2.1.1 In Time For Christmas

WP Biographia’s always had the ability to suppress the display of the plugin’s Biography Box for all users; unfortunately that’s been accomplished by simply not installing the plugin. But judging from requests on the WordPress forums as well as emails hitting my Inbox, suppressing the display of the Biography Box for some users ranks highest on the list of requested features.

So it’s good to be able to say that as of v2.1.1 of the plugin, you can now do this and v2.1.1 is now live and able to be downloaded from GitHub as well as from within WordPress or via the WordPress plugin repository.

New!

As well as supporting the latest v3.3 version of the WordPress core, the complete list of changes for this latest version of the plugin is …

  • Add ability to suppress the Biography Box from being displayed on posts, on pages and on posts and pages on a per user basis
  • Add settings link to Settings / WP Biographia admin page from the plugin’s entry on the Dashboard / Plugins page
  • Add checks for avatar display in the Biography Box being requested with avatar support not enabled in the Settings / Discussions admin page
  • Add Help & Support sidebar box to Settings / WP Biographia admin page
  • Handle upgrades to configuration settings gracefully; fixed bug that didn’t persist unused/unchanged configuration settings
  • Cleaned up the wording for the Settings / WP Biographia admin page and made terminology consistent across all configurable options
  • Tweaked admin CSS to introduce padding between the settings container and sidebar container that changed in WordPress 3.3

As always, the WP Biographia home page has the full details. Consider this, if you will, an early visit from Santa. What’s next for the plugin? Internationalisation is probably on the cards as well as converting the plugin to use classes and not a simple set of WordPress PHP functions; but all of that will have to wait until after the Holiday season.

Photo Credits: Sam. D. on Flickr.
Written and posted from home (51.427051, -0.333344)

WP Biographia v2.0 Goes Into Beta

I continue to be genuinely gobsmacked at the reception that WP Biographia has received since I first released it in August of this year. People are downloading it; people are emailing me about it; people are discussing it and asking for new features on the WordPress forums and since I put the code up on GitHub, people are even forking it, improving on it and sending me pull requests. But I’ve been buried deep in my day job over the last month or so and as a result coding has had to play second fiddle to what I do for a living.

But thanks to Travis Smith getting in touch with me via Twitter and taking the time to make his changes and bug fixes on a GitHub fork there’s now a new beta version of WP Biographia up on GitHub for testing or for those who like to live on the bleeding edge.

NEW & IMPROVED 50% BRIGHTER LIGHTS

In addition to Travis’ changes I’ve also reworked the plugin structure to reflect the recommended WordPress plugin file and directory layout and this, coupled with 6 other new features and big fixes is sufficient, I think, to up the version number straight to v2.0.0. Here’s what’s new.

  • You can now set the size of the author’s Gravatar image
  • The plugin now supports the [wp_biographia] shortcode
  • You can now exclude the Biography Box from specific posts based on the post’s ID
  • You can now place the Biography Box at the top of the post as well as the bottom of the post
  • You can now further customise the behaviour of the plugin through a short circuit filter
  • The issues with CSS on some WordPress installations have been fixed.

Once the beta’s been tested out and given the general community nod of approval I’ll push the new version to the WordPress Subversion repository so people who are using the plugin and don’t want to manually update the plugin or test the new version out will get the automagic update notification in their WordPress dashboard.

Photo Credits: Leo Reynolds on Flickr.
Written and posted from Theresa Avenue, Campbell, California (37.2654, -121.9643)