This is a super-quickie — when you’re developing a responsive site and your test-devices don’t seem to recognize the actual viewport dimensions (say, 768 x 1024) — the culprit is often a single <meta> statement:

<meta name="viewport" content="width=device-width, initial-scale=1.0" />

I’ve run into this problem before and conveniently forgot all about it in the meantime. While testing changes to this site’s theme I found that on the iPad the screen width was always 768 pixels, regardless of the device orientation. Adding this <meta> statement solved the problem.

Thanks to alwaystwisted.com for the updated reminder — don’t dick around with the minimum or maximum settings unless you want to mess around with users’ ability to zoom on touchy-touchy devices.

The post FIX: Responsive Viewports on Mobile Devices appeared first on Mister Piercy.

I’m still in the process of scratch-building a responsive WordPress theme with Bootstrap and today decided to tackle the search widget styling. Well, to be completely honest I’m not quite scratch-building it — I’m adapting Automattic’s Toolbox theme, but I’m hand-rolling most of the responsive features.

If you’re not using Bootstrap, the process of styling the search widget is pretty straightforward — just modify (or define) the relevant CSS classes and you’re good to go. In order to use Bootstrap icons, however, it helps to restructure the the form input element. Since Bootstraps’ icons (from Glyphicons) are all stored in single sprite you can’t link directly to an individual icon in order to set it as a CSS element’s background property. Instead you specify the icon by CSS class name, which positions the element’s viewport over the selected part of the sprite.

For example, the HTML code

<i class="icon-search"> </i>

invokes this CSS:

.icon-search {
  background-position: -48px 0;
}

The default search form input type won’t work with Bootstraps’ icon syntax, so it helps to change the input type to a button. Rather than fiddle around with the WordPress internals and modify the default search widget I found a more elegant solution by looking at the WordPress codex entry for the function, which calls the  get_search_form() widget. It turns out that the function attempts to load the file searchform.php, but if the file doesn’t exist it loads the default form widget. I created the file with the following contents, modified from the example in the codex entry:

<form action="/" method="get">
<fieldset><input id="search" type="text" name="s" value="<?php the_search_query(); ?>" />
 <button class="btn" type="submit">
 <i class="icon-search"> </i>
 </button></fieldset>
</form>

And that’s all there is to it! Note the btn class on the button element– it’s another snazzy little bit of kit from Bootstrap which handles the size of the input element and its contents based on the form context. Neat! Just in case you’re not reading this post on my site (shame on you), here’s what the search form looks like with default, out-of-the-box Bootstrap styling:

The post Styling WordPress Search Forms with Bootstrap Icons appeared first on Mister Piercy.

The Bootstrap front-end framework is pretty cool and extremely easy to use, but it’s not always obvious that everything is working properly after installation. You’ll see the new style sheets right away, but testing the Javascript takes a little bit of extra effort.

Here’s an overview of the process:

1. Download and install the Bootstrap framework
2. Modify functions.php and header.php to load and Javascript and stylesheets
3. Test Javascript with a Bootstrap-specific feature

Downloading and installing Bootstrap is a breeze. Grab the project from GitHub, extract it, then upload it to your WordPress theme. I installed the Bootstrap directories (css/, img/, js/) in my theme’s root directory — /wp-content/themes/my_theme/.

Please note that I am creating a new WordPress theme based on the Toolbox theme from Automattic and therefore some things are missing from my theme which might be present (and look a little different) in yours. For example, your theme likely already loads jQuery and has one or more scripts registered and enqueued in your theme’s functions.php. Mine did not, which is why I’m using the custom function in the following example. Also, I’m using a different method to call jQuery, which blends Google CDN and local sources. Please adapt the example as necessary.

Next, edit your theme’s functions.php file to register the Bootstrap Javascript and jQuery (if necessary). I’m using the minified version of the Bootstrap code to save on loading time. My minimal theme uses the following custom script to register the resources:

//Register Javascript...
function load_javascript() {
	wp_register_script('jQuery', get_template_directory_uri().'/js/jquery.js');
	wp_register_script('bootstrapMin', get_template_directory_uri().'/js/bootstrap.min.js');
	//wp_enqueue_script('jQuery');
	wp_enqueue_script('bootstrapMin');
}
add_action('init', 'load_javascript');

Once the changes are complete in functions.php, add the necessary links in header.php. Note that I’m not enqueuing jQuery in functions.php — the conditional test in the header decides which source it loads from.

<script type="text/javascript" src="//ajax.googleapis.com/ajax/libs/jquery/1.9.0/jquery.min.js"></script><script type="text/javascript">
if (typeof jQuery == 'undefined') {
		document.write(<?php wp_enqueue_script('jQuery'); ?>);
	}
</script>
 	<link href="<?php echo get_template_directory_uri().'/css/bootstrap.min.css'; ?>" rel="stylesheet" media="screen" />
 	<link href="<?php echo get_template_directory_uri().'/css/bootstrap-responsive.min.css'; ?>" rel="stylesheet" media="screen" />

Finally, we should test the installation by inserting some code to call a Bootstrap-specific function. I chose this modal example from the Bootstrap documentation, which I added right after the opening <BODY> tag in header.php. When you refresh the page the modal link should appear in the upper left-hand corner and should work similarly to the documentation example. The styling might not be identical, thanks to style collisions between the Bootstrap CSS and other, non-Bootstrap CSS.

<!-- Button to trigger modal -->
<a class="btn" role="button" href="#myModal" data-toggle="modal">Launch demo modal</a>

<!-- Modal -->
<div class="modal hide fade" id="myModal" tabindex="-1" role="dialog">
<div class="modal-header">
<button class="close" type="button" data-dismiss="modal">×</button>
<h3 id="myModalLabel">Modal header</h3>
</div>
<div class="modal-body">One fine body…</div>
<div class="modal-footer"><button class="btn" data-dismiss="modal">Close</button>
 <button class="btn btn-primary">Save changes</button></div>
</div>

As always, please leave a comment if I’ve made any egregious mistakes and I’ll fix them right away.

The post Testing a Bootstrap Installation on WordPress appeared first on Mister Piercy.

Here’s a quick fix for WordPress theme developers who want jQuery delivered from Google’s CDN whenever possible, but also want a local copy to fall back on if the CND isn’t available. I’ve also included a couple of extra lines of code you can use to test your configuration.

Since I’m developing a custom theme based on a bare-bones starter theme (Toolbox from Automattic), I didn’t have a local copy of jQuery. I downloaded the current version and installed it as /wp-content/themes/my_theme/js/jquery.js. If you already have an installed copy of jQuery that you’d rather use, substitute the appropriate path where necessary.

Next, register jQuery in functions.php.  If you’re not building your own theme, jQuery is probably already registered. Here’s what to add to your functions.php if it isn’t:

function load_javascript() {
 wp_register_script('jQuery', get_template_directory_uri().'/js/jquery.js');
 }
 add_action('init', 'load_javascript');

By the way — if you’re developing a theme from scratch, keep this function in mind for registering future Javascript code.

Also, note that wp_enqueue_script() is not being called at this point. It will be called from the page header within a conditional statement. Non-theme developers can comment this equivalent line out in functions.php:

function load_javascript() {
 wp_register_script('jQuery', get_template_directory_uri().'/js/jquery.js');
 //wp_enqueue_script('jQuery');
 }
 add_action('init', 'load_javascript');

Add the following to header.php somewhere before the </HEAD> tag (click for the current Google CDN jQuery link):

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.9.0/jquery.min.js"></script>
 <script type="text/javascript">
 if (typeof jQuery == 'undefined') {
 document.write(<?php wp_enqueue_script('jQuery'); ?>);
 }
 </script>

Assuming that all of the paths and file names are correct, it should work.  It’s tough to tell, though, unless a serious error occurs.  I tested a couple of ways to check whether the right version of jQuery is loading from the the right source, just make sure.

Add this below the <BODY> tag and refresh the page so we can see whether or not jQuery is running at all:

<script type="text/javascript">
 if (typeof jQuery == 'undefined') {
 alert('missing');
 }
</script>

If there’s no alert dialogue, jQuery is running. Now modify your <HEAD> Javascript by corrupting the CDN file name and refresh the page:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.9.0/jquery.min999.js"></script>

There still should not be an alert dialogue. Try commenting out the embedded PHP in the <HEAD> Javascript and refreshing the page:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.9.0/jquery.min999.js"></script>
<script type="text/javascript">
 if (typeof jQuery == 'undefined') {
 document.write(<?php /*wp_enqueue_script('jQuery');*/ ?>);
 }
</script>

Now the ‘missing’ dialogue should appear. When you’re satisfied that everything’s running correctly, fix the CDN file name, uncomment the embedded PHP and remove the alert Javascript from the <BODY>.

Please leave a comment if you discover any errors in these instructions. My primary motivation in writing this post was because I couldn’t find a succinct, error-free example of how to accomplish the above task. Other authors either went into too much detail on the wp_register_script() and wp_enqueue_script() functions or had included so much buggy code that their examples wouldn’t work. The typos and coding errors were especially galling, so don’t hesitate to let me know if I’ve made any of the same mistakes so I can correct them as quickly as possible.

The post Loading jQuery from Google CDN with a Local Backup on WordPress appeared first on Mister Piercy.

Skip the background and jump to the code snippets

I was recently asked to provide a solution for a client whose site host was shutting down their email servers and needed a new webmail provider. The hosting company was throwing all of the business to Rackspace for $2.00 per email address per month with a five-address minimum. Ten dollars a month isn’t bad (I like Rackspace — I’m a satisfied customer), but the client was only using one address. Gmail, on the other hand, is no longer free for businesses, but at about $50.00 per year per address it was a better deal for my client. Not to mention the other advantages that come with it, including virus/malware protection and smartphone app ubiquity.

Everything went pretty well until I had to modify the client’s Swift Mailer contact form to talk to Gmail. The solution isn’t complicated, but it took some creative Googling and trial-and-error experimentation to get everything to work. The following isn’t a fully coded solution, but it covers the two main issues I needed to address.

First, the original developer coded the contact form with the mail server credentials in an external configuration file. Here are the three values necessary to connect to the mail server:

$mailHostname = 'smtp.gmail.com';
 $mailAuthUser = 'you@whereeveryouare.dom';
 $mailAuthPassword = 'your_password';

Then I needed to make sure the mail server connection was being created on the right port with the correct SSL encoding. Here’s what worked for me:

$smtp =& new Swift_Connection_SMTP($mailHostname, 465, Swift_Connection_SMTP::ENC_SSL);
 $smtp->setUsername($mailAuthUser);
 $smtp->setpassword($mailAuthPassword);
 $swift =& new Swift($smtp);

Like I said, it’s not the whole enchilada, but the second part was the key and I had a hard time finding the right answer. Hopefully this will spare someone a little unnecessary frustration.

The post Using Gmail SMTP with PHP Swift Mailer appeared first on Mister Piercy.