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

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

WordPress Taxonomy Tabs

Jason Schuller of Press75.com mentioned on Twitter yesterday that the taxonomy UI in the WordPress admin could use some improvement.

In regards to custom taxonomies, it would be nice to have just one tabbed box within the editor instead a separate box for each taxonomy.
Jason Schuller

I thought that sounded like a good idea, so I went about figuring out how such a change could be made. (more…)

  • PublishedNovember 1, 2011
  • Posted InWordpress
  • DifficultyIntermediate

Simple CSS Drop Down Menus

Update: After further testing, it appears that a bug in Internet Explorer prevents the drop down menu from opening. There are a number of ways to get around this IE bug, but I’m not going to go into that here.

I was building a drop down menu while working on a personal project and I decided to see how lightweight I could make it. This is a pure CSS drop down menu, no Javascript is used. Only 50 lines of generously spaced CSS were needed to create a cross-browser drop down menu and the entire demo file weighs in at just over 1kb. It uses the same HTML structure as the default WordPress menu system, so it can easily be used in WordPress themes as well. (more…)

  • PublishedOctober 29, 2011
  • Posted InCSS
  • DifficultyIntermediate

Setting the Default Editor for a Custom Post Type

Recently I was working on a project where I was writing some PHP and HTML source code documentation and publishing it via WordPress. As you may know, the WordPress visual editor isn’t ideal when it comes to handling such code. Consequently, I went looking for a way to set the default editor to HTML rather than Visual. However, I didn’t want to cause the HTML editor to be the default across the entire site, so I created a custom post type for my code documentation. Then I changed the default editor for only that post type with the following piece of code:

add_filter('wp_default_editor', 'set_default_editor');

function set_default_editor( $type ) {
    global $post_type;
    if('code-doc' == $post_type) 
        return 'html';
    return $type;

All you need to do to use this piece of code is change “code-doc” to reflect the name of your custom post type.

  • PublishedOctober 7, 2011
  • Posted InWordpress
  • DifficultyIntermediate
  • Tested With3.2.1

« Older Entries Newer Entries »