The scenario: My WooCommerce store has no need for the Order Notes field. In fact, up until now I had it hidden on the checkout page. But what my site does need is an EU VAT ID field. The portion of my business that takes place in Europe is, so far, well below the VAT reporting threshold, but I am increasingly being asked by customers to provide an invoice containing their VAT ID.

Well, my site does already produce PDF invoices. But there was no way for customers to include their VAT ID on the invoice. Until now.

A simple code snippet converts the existing WooCommerce Order Notes field into an EU VAT ID field, including changing it from a <textarea> to an <input type="text"> field. Put this in your theme’s functions.php file, or wherever else is appropriate in your setup:

add_filter('woocommerce_checkout_fields', function($fields) {
    $fields['order']['order_comments'] = array_merge(
        $fields['order']['order_comments'],
        array(
            'class' => array('eu-only'),
            'label' => 'EU VAT ID',
            'type' => 'text',
        )
    );
    return $fields;
}, 10, 1);

That’s it. You can stop right here. But you may notice a line in there that seems unnecessary: 'class' => array('eu-only')

What’s that all about? Well, I’m using that with a bit of jQuery to enhance the functionality: only showing my new EU VAT ID field when the user’s selected Billing Country is an EU country.

Here’s a JavaScript function you can use to dynamically show/hide elements with an .eu-only CSS class, depending on a given passed-in value:

function showHideEUOnly(val) {
    var eu = ['AT', 'BE', 'BG', 'HR', 'CY', 'CZ', 'DK', 'EE', 'FI', 'FR', 'DE', 'GR', 'HU', 'IE', 'IT', 'LV', 'LT', 'LU', 'MT', 'NL', 'PL', 'PT', 'RO', 'SK', 'ES', 'SE', 'GB'];
    if (eu.indexOf(val) != -1) {
        jQuery('.eu-only').show();
    }
    else {
        jQuery('.eu-only').hide();
    }
}

I obtained the list of EU VAT-applicable countries here, and I decided to include 'GB' (the United Kingdom) in the list, despite… y’know, uh… Brexit, because I have the vague impression that UK customers may still be impacted by VAT policies. (Being a dumb American, I don’t know much about it. I think maybe the UK has its own VAT now? Anyway, suffice to say, you may want to modify your list of 2-digit country codes in the eu array, as applicable to your situation.)

This function isn’t going to do anything unless it’s called though, so let’s do that. Here’s a bit of jQuery that will call it both on the initial page load and any time the Billing Country field changes:

jQuery(function() {
    if (jQuery('body').hasClass('woocommerce-checkout')) {
        jQuery('select[name="billing_country"]').on('change', function() {
            showHideEUOnly(jQuery(this).val());
        });
        showHideEUOnly(jQuery('select[name="billing_country"]').val());
    }
});

Both of these JavaScript snippets can go in a script.js file in your theme, or wherever else is appropriate in your setup.

That’s the end of the story, but there’s more…

Incidentally, there’s more to my custom setup. I’ve significantly modified the layout of my checkout page. I’ve got WooCommerce configured for billing addresses only, with this setting in Shipping Options:

I then used CSS to hide everything else in the second column (including, up until now, the Order Notes field) and moved the product summary and payment information up into that space. Explaining all of that is outside the scope of this post, but one thing you may find useful is my CSS for hiding the “Additional Information” <h3> heading. This selector is a bit of overkill, but it works:

body.woocommerce-checkout .woocommerce > form.checkout .col2-set > .col-2 .woocommerce-additional-fields > h3:first-child { display: none; }

There’s context in my CSS file to justify all of that, but you should be able to accomplish the same with just this:

.woocommerce-additional-fields > h3 { display: none; }

I’ve been building websites since there was no alternative to the command line when it came to configuring web servers. Well… unless you were using a Mac as a server, which didn’t have a command line back then. (And, yes, it could be done. The ISP I started working at in 1996 ran entirely on Macs, except for one Sun SPARCstation we were using as a DNS server.)

I still prefer the command line, and when I have a choice, I build web servers on a VPS from a vanilla install of Ubuntu Linux. I used to use Digital Ocean, but now Linode is my preferred host.

But if a client already has their site hosted somewhere else, I’ll work with what they’ve got. I take the “if it ain’t broke, don’t fix it” approach. As long as the client doesn’t have major issues with their current hosting provider, it’s usually much easier to keep things where they are than to move their site somewhere else.

Even if that current hosting provider offers, ah-hem, “Managed WordPress Hosting.” I cringe at that phrase, because what it really means is that I have less control to set things up the way I like.

The way I like things isn’t the way they have to be, of course, but it would be nice if their easy-to-use tools actually made things easier to use.

Let’s take rewrites, for instance. Editing the .htaccess file can be a dark art, but once you know the basics and can handle regular expressions, it’s not that difficult.

Launching a new site that’s replacing an existing one almost always involves setting up rewrites. You want to make sure URLs from the old site, especially ones that people might have bookmarked or, even more importantly, Google might have indexed, automatically shunt users over to the corresponding URL of the new site.

Often a client will give me a fairly large spreadsheet of URLs to map. Setting this up in a text file, especially if you use an editor with good find-and-replace, is a snap.

Flywheel offers SFTP access to your site, and it even contains an .htaccess file