Hello, my name is Alex Mansfield. I am primarily a freelance WordPress developer, but I occasionally work on other design and development projects.

Updating a Plugin in the WordPress.org Repository

As of this writing, I have only two plugins in the WordPress.org repository. I periodically update these plugins, but not often enough to memorize all the steps required to get things right on the first try. So for my own future reference (and maybe yours as well) here are all the steps laid out in order.


WordPress, CDNs, and jQuery

Last week, Pippin Williamson published a post titled “Why Loading Your Own jQuery is Irresponsible.” This very issues was brought up tonight at the Seattle WordPress meetup, which led to a lively discussion and referenced Pippin’s post. Please, for the love of the WordPress community, just use the version of jQuery bundled in WordPress core…

However, if you’re going to load jQuery irresponsibly, don’t do it such a half hearted way by loading whichever version of jQuery is the latest at the time! Throw caution to the wind and use the new “Random jQuery” plugin! It loads a random version of jQuery from Google’s CDN with no fallback! It supports versions 1.2.3 all the way through 1.9.1! Also it will save people hours of work because rather than being forced to debug a theme that hard coded it’s own version of jQuery, troubleshooters can simply deactivate the plugin! It’s a win/win for everyone! Yes, I did just use an exclamation point at the end of every sentence in this entire paragraph!

Download the “Random jQuery” plugin now!

  • PublishedMarch 15, 2013
  • Posted InHacks

Passing Arguments to Callback Functions

Let’s say you want to use add_action() to attach a function to an existing action, but you want to pass your function a few arguments. This seems to be a common problem with no good solution. Yes, you could use global variables, but that’s rather messy, especially if you want to attach the same function to a number of different actions but with different arguments each time. After running into this issue again a few weeks ago, I set out to see if there wasn’t a better way to do this. Here’s what I came up with…


Thoughts on WordPress Data Portability

Data portability within WordPress is a big deal. However, best practices regarding how to properly make data portable are hazy at best. Where should custom post types be defined? What should happen to the data when a user switches themes?

In this post I will attempt to summarize the various arguments, point out one overlooked fact, and offer a limited solution that can be implemented regardless of your particular views on data portability.

Attempted Summary: Themes vs Plugins

For the sake of simplicity, I will be discussing data portability as it applies to custom post types. It seems that the true question that everyone is trying to answer is this:

What is the most user friendly way to implement theme-related custom post types, and what should happen to the data when a user switches themes?

For example, let’s say you’re creating a portfolio theme using a custom post type to hold the portfolio items. At first glance, it appears that defining the custom post type within your theme would make the most sense, because the data is specific to your theme.

However, more and more developers are pointing out that if a user switches themes, their portfolio items will disappear, both from the front end and the back end. Obviously, this is not an ideal end-user experience, and so the suggestion is made to define the custom post type in a plugin. Now if the user switches themes, the data is visible on the back end, although it still disappears from the front end.

Is this a step in the right direction? Yes, probably. However, let’s not pretend that this is good usability. Which is more confusing, trying to figure out why your data is missing completely, or why it’s only missing on the front end? I really don’t have an answer for that. Neither of them are good options. (more…)

WordPress Editor: Fullscreen vs. Distraction Free

WordPress distraction-free editor

Update: The full screen editor keyboard shortcut was removed in WordPress 3.5. At the end of this article, I’ve included a few lines of code to add a full screen editor toggle button instead.

WordPress 3.2 brought the introduction of the “distraction-free” editor. Its aim was to clean up the editing space and allow authors to concentrate on their content. It is an undeniably beautiful feature, but in stripping down the editing screen, distractions were not the only things removed. The “kitchen sink” was removed as well (For those not familiar with the “kitchen sink” it is the second row of buttons in the WordPress editor). Many authors (such as myself) rely on the buttons available in that second row. Consequently, as nice as the distraction-free editor was, we just couldn’t bring ourselves to use it due to the limited functionality. However, all is not lost. After trying in vain to find a way to display the kitchen sink in the distraction-free editor, I came upon what appears to be a little known feature of the WordPress editor.



  • PublishedNovember 14, 2012
  • Posted InBlogging

Apache mod_rewrite in Ubuntu/Mint

There are many tutorials for setting up mod_rewrite for Apache, but most of them are missing one critical step. To be honest, I’m writing this as much for myself as I am for anyone else. I’m tired of looking around for the missing step every time I setup mod_rewrite on a new machine. So here it is. (more…)

  • PublishedSeptember 13, 2012
  • Posted InLinux

Year Three

Just a few days ago marked the third birthday of this website. Once again, I didn’t give the site the attention I had planned to. Nevertheless, I’ll publish a review of the year as a whole and look at what the next year might bring.


Here’s a quick look at some details of the blog this year:

  • Blog posts: 8 (exactly the same as last year)
  • Visits: 13,896
  • Visitors: 12,693
  • Pageviews: 17,488
  • Avg. time on the site: 0:34
  • Backlinks (as measured by Open Site Explorer): 318
  • Google Pagerank: 3
  • Alexa site rank: 890,930

Just like last year, I failed to even post once a month, but visits, vistors, and pageviews grew substantially. However, the average time on site decreased by over 10 seconds and visitors finding my site through a search engine increased to almost 85%. I wrote a number of shorter posts this year, so that might be partially responsible for the change in numbers. My site also made it into the top million sites on the internet according to Alexa.com. A million is quite a few, so I’m not sure if that’s something to be proud of or not. (more…)

  • PublishedJune 4, 2012
  • Posted InProgress

Font-size and Line-height for <pre>, <code>, and Other Monospaced Fonts

While attempting to create a consistent cross-browser font baseline, I ran into the following strange behaviour in certain browsers (not IE for once!). Any monospaced font was rendered smaller than the surrounding text, even when specifically set to display at 1em. I found this to be true in both Firefox and Chrome. After a bit of searching, I found that these browsers also contain a strange bug, although in this case it almost becomes a feature. If the font-family is set to monospace twice, suddenly the font displays at the proper size:

pre, code, kbd, samp, tt, textarea{
	font-family: monospace, monospace;

However, in Chrome, this threw off the line height, which ruined the vertical rhythm I was working to create. After some trial and error, I discovered that setting the vertical-align property to “top” took care of the problem. I’ll be the first to admit that this isn’t the most elegant solution, but as far as I can tell, it works in every modern browser. Here is my final code:

pre, code, kbd, samp, tt, textarea{
	font-family: monospace, monospace;
	vertical-align: top;

Please let me know if you find any browsers that don’t render this properly. Thanks!

  • PublishedFebruary 25, 2012
  • Posted InCSS
  • DifficultyIntermediate

CSS vs jQuery: Screen Widths and Scrollbars

Update: The first piece of code had an unexpected side effect that is addressed in the update at the bottom of this post.

CSS media queries and jQuery window width calculations each handle scrollbars differently. This can cause unexpected (and ugly) results when they are used together. I was recently building a responsive menu system that relied on CSS media queries to create a vertical menu for small screens, such as mobile devices. I then used a jQuery width measurement to determine whether or not to create a button for toggling the visibility of the vertical menus. However, I was in for a nasty surprise. Unfortunately, when a CSS media query measures the width of the window it includes the width of the scrollbar. On the other hand, when jQuery measures the width of the window it does not include the width of the scrollbar. When there was no vertical scrollbar, both my CSS media query and jQuery function would fire at the same window size. However, when the page content was long enough to require a scrollbar, the jQuery function would fire first. Eventually, I realized that I could disable scrolling momentarily while I placed the window width into a variable for use later in the script. Here is what it looks like:

jQuery('body').css('overflow', 'hidden');
jQuery('html').css('overflow-y', 'hidden');
var window_width = jQuery(window).width();
jQuery('body').css('overflow', 'auto');
jQuery('html').css('overflow-y', 'auto');

Update: After working with this section of code for a time, I realized that setting “overflow” to hidden caused the page to jump to the top whenever the page was reloaded or the window was resized. So I set off across the internet in search of a script that would measure the width of the scroll bar, rather than measuring the width of the window without the scroll bar. That is how I came across this script by Jonathan Sharp. However, I didn’t need to know the scrollbar width on short pages that didn’t scroll, so I modified it to only return a value when a scrollbar is present on the page.

/* Calculates scrollbar width in pixels */
function scrollbar_width() {
	if( jQuery('body').height() > jQuery(window).height()) {
		/* Modified from: http://jdsharp.us/jQuery/minute/calculate-scrollbar-width.php */
		var calculation_content = jQuery('<div style="width:50px;height:50px;overflow:hidden;position:absolute;top:-200px;left:-200px;"><div style="height:100px;"></div>');
		jQuery('body').append( calculation_content );
		var width_one = jQuery('div', calculation_content).innerWidth();
		calculation_content.css('overflow-y', 'scroll');
		var width_two = jQuery('div', calculation_content).innerWidth();
		return ( width_one - width_two );
	return 0;

This can then be added to the window width to get the full width of the window including the scrollbar:

var window_width = jQuery('body').width() + scrollbar_width();

Change Default Media Settings on Theme Activation

Let’s face it, if you’re a developer you want to make things as simple as possible for your clients. One way to do this is to set the default media sizes when your theme is activated. Your users should never need to try to figure out the width of the content area. They shouldn’t have find where the default settings are located. They shouldn’t have to worry about any of that. When they upload an image or use an embed code, the correct sizes should already be set. Here’s how you can do that for them.


  • PublishedNovember 3, 2011
  • Posted InWordpress
  • DifficultyIntermediate

« Older Entries Newer Entries »