Author: Brent Stromberg

Jank-Free Full Screen ‘vh’ Sections with a Simple jQuery Hack

Get that jank outta here!

Making sections of a page span the full width and height of the screen is a pretty cool look for a website. I’m a huge fan of using the entire screen and not keeping your site stuck in a box. After all, we don’t watch TV on only part of our television screens, right? So why do the same on the internet? Any way, I digress…

Making sections of your site span the full height of the screen requires the use of the CSS3 unit of measurement called ‘viewport height’ or vh. The browser calculates the vertical height of the viewport, where 1vh equals 1/100th of the viewport height. So to make a section of a website span the full height of screen is a cinch with the use 100vh.

The one (rather large) caveat of using vh is that mobile browsers don’t really play very nicely with vh. Upon page load in most mobile devices, namely iPhone and Android phones, the viewport height is based on the device screen height. For the Samsung S6 (the device I have and use on a daily basis) the pixel height of my viewport is 640px. The viewport height in pixels for an iPhone 5 and iPhone 6 is 568px and 667px respectively. But the issue that comes up with vh in mobile devices such as these is that the viewport height is calculated using their screen pixel heights MINUS the browser bar, which is about 60px, on first page load. So once a user scrolls down on their phone, the browser bar scrolls up out of sight, and viewport height gets recalculated by the browser. Most resize and animation events only fire once the screen stops moving, which results in some quite unpleasant jank once you stop scrolling. See the gif below to view it in action.

a moving gif showing the jankyness of the vh shift that sucks so much

So basically, that sucks. If one was to want to click on a button after scrolling, the screen would jump as vh is recalculated resulting in missing the intended button and possibly clicking on something they didn’t want to click on. Not a good user experience.

One way around this is to set the min-height to something that is agreeable to most devices. In the past I have used this technique and just set my full screen sections with a min-height of 100vh to something like min-height: 600px on mobile devices. It’s a decent workaround, but not as cool being able to use vh without issue.

So I came up with a different workaround. It may seem like a bit of a hack, but I think it works pretty well. First, since this is a WordPress site, I added a mobile body class which uses the wp_is_mobile() function to detect a mobile device and adds a class of ‘mobile’ to the body tag. Paste this into your functions.php file to achieve this:

function my_body_classes($c) {
wp_is_mobile() ? $c[] = 'mobile' : null;
return $c;
add_filter('body_class','my_body_classes'); ?>

Next, I added the following into my footer (or add it into your custom javascript file to keep things nice a tidy):

<script type="text/javascript">
jQuery(document).ready(function($) {
$heightOnLoad = $('.vc_row.vc_row-o-full-height.welcome-message-wrapper').height();
$(window).resize(function() {
$(' .vc_row.vc_row-o-full-height.welcome-message-wrapper').css({

The snippet above results in a smooth, jank-free scroll of the website on a mobile device. Check it!

a moving gif showing the site scrolling JANK-FREE!!!

What it does is calculate the vertical height of the viewport after the page has finished loading and stores the height value in pixels in a variable called $heightOnLoad. It then applies ‘min-height’ inline to the sections specified in the function with the value of $heightOnLoad on mobile devices only. In my case, I wanted to only target the first section of the site you see in the gifs because it is the only section of the site that will have a min-height that will fit into the vertical height of the viewport, so adjust your script accordingly to fit your specific circumstance.

So, this could be the perfect fix for some, but I’m sure I’ve missed something. Go ahead, poke holes in it, because I think this is a pretty good workaround, but I’m probably wrong.

Why doesn’t WordPress have a ‘not-home’ body class?

For real though…why doesn’t WordPress have a ‘not-home’ body class?

It’s a question I’ve asked myself many times. For the life of me I can’t figure out why its not in there! Other CMS’s, like Drupal, have this out of the box, but not WordPress. It has a home body class, as well as several other useful body classes, but no not-home body class. So I said to myself “the tyranny and bullshit has gone on long enough” and I did something about it. I’ve come up with a quick little snippet you can add to your theme’s functions.php file to add the ‘not-home’ body class to any WordPress template. It’s one of the first things I do when starting a new project.

But, first, why would you want this? Well, in a lot of the projects I work on for Uptown Studios our designers will have separate styles created in their PSD mockups for the home page elements and the internal page elements. The home page will often times have larger headings to draw more emphasis to the items highlighted on the home page or have different colors to stand out on darker backgrounds. And this is pretty normal I think, but it presents an issue when trying to designate styles for things such as <p>, <h1> through <h6>, and <button> tags on internal pages. So the not-home body class can come in real handy. So without further ado, paste the following into your themes functions.php file to get the not-home body class of your WordPress site.

// Add not-home to body class
function add_not_home_body_class($classes) {
if( !is_front_page() ) $classes[] = 'not-home';
return $classes;

What we’re doing here is creating a function that hooks into the built in WordPress function body_class and pushing a new value into the $classes array. We’re using the is_front_page() filter to add the body class to all pages except the home page. Sometimes the is_front_page() filter can return inconsistent results from template to template, so if it’s not working as expected you can try the following (note: the following snippet assumes that your home page has the slug of “home”):

// Add not-home to body class
function add_not_home_body_class($classes) {
if( !is_page('home') ) $classes[] = 'not-home';
return $classes;

You can also take this opportunity to add any other body classes you’d like to the body tag that will only show up on pages that aren’t the front page. I’m not sure what those other classes might be or what you’d need them for but, shit, I don’t know you’re life! Do what you gotta do.

How to make a Sticky Header with classie.js

So I’ve been tinkering lately with adding my own sticky-header functionality to the sites I develop for work. Most of the time templates we work with will have this feature built in, but sometimes they don’t. I’ve built a few sites in the last few weeks using a template that is solid at its core, but lacking in some of the more modern techniques, so enabling a sticky-header has been a manual process.

Luckily there is a really handy jQuery library that will assist in this quite nicely. It’s called classie.js and it is really cool. Classie.js is an awesome, super lightweight script that allows you to add, remove, toggle, and check for classes in the DOM very easily.

So what I’m doing to enable my sticky header is to add a class to the body tag after I have scrolled down the past the length of the header. I achieve this by delaring a variable that is equal to the height of the header. Instead of inputting a fixed height into my script variable I am using the .height(); method to get the height of my header and then using that to add a class to the body tag. Paste the code snippet below into the footer of your website (be sure to put it inside a <script> tag):

function init() {
window.addEventListener('scroll', function(e){
var distanceY = window.pageYOffset || document.documentElement.scrollTop,
shrinkOn = jQuery('#header').height(),
header = document.querySelector("body");
if (distanceY > shrinkOn) {
} else {
if (classie.has(header,"sticky-header")) {
window.onload = init();

What this snippet does is dynamically get the height of the #header element and store that height as a variable called shrinkOn. We are also creating another variable called distanceY to track how far down the page we scroll. We compare the number stored in distanceY against shrinkOn, and if distanceY is more than shrinkOn classie.js adds the class sticky-header to the body tag. We can then use this class to stick the header to the top of the page. Paste the following into your stylesheet:

body.sticky-header div#main-nav {
position: fixed;
top: 0;

This will fix the #main-nav (which is presumably your main navigation container) to the top of the page once you scroll down the number of pixels equal to the height of the #header. You might also want to add some padding to the top of the #header equal to the header height so the page doesn’t jump up and down when sticky-header is added/removed from the body tag by classie.js. You can do that with some simple jQuery as well, but that is for a different tutorial.

So that’s about it! Try it out and let me know how it works for you in the comments below!

10 Point Strategy To Beef Up Security On Your WordPress Site

WordPress is the most popular CMS on the internet. There are over 74 MILLION sites running on WordPress. Running a website on such a popular platform also means that it’s one of the most highly targeted platforms by hackers. However, while WordPress’ code base is rock solid and is continuously developed to ensure that it stays as secure as possible, there is always the possibility of good ol’ human error that can come into play, making a WordPress site easy prey for those pesky hackers.

At Uptown Studios, where I work as Web Manager, we host and manage close to 130 sites running on WordPress, so ensuring they are all in tip-top shape in the security department is one of my top priorities. To stay on top of it all, I have put together 10 Point Strategy to Beef Up Security on your WordPress Site.


Install some sort of login attempts plugin. There is a really simple one called Limit Login Attempts that works great. It says its really old in the WP plugin repository, but everywhere I read about this plugin says that for the purpose it serves, it does not matter that it’s so old. There is also Jetpack’s Protect option. It comes bundled with Jetpack, a plugin by Automattic. Or there is Wordfence Security. I can’t recommend WordFence enough. It’s great.


I also lock down attempts to open and edit files inside wp-includes and the wp-config.php file by adding a few lines to my .htaccess file. Add this to the top of the .htaccess file:

# Block the include-only files.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ – [F,L] RewriteRule !^wp-includes/ – [S=3] RewriteRule ^wp-includes/[^/]+\.php$ – [F,L] RewriteRule ^wp-includes/js/tinymce/langs/.+\.php – [F,L] RewriteRule ^wp-includes/theme-compat/ – [F,L] </IfModule>
# Block access to the wp-config.php file
<files wp-config.php>
order allow,deny
deny from all


Also, create another .htaccess file inside the uploads folder. Since this folder has to have 777 permissions on most servers, hackers will exploit this and add PHP files to do malicious deeds to the various folders inside the uploads folder. To prevent PHP file execution inside the Uploads directory, create the file inside wp-content/uploads and add this to it:

<Files “*.php”>
Order Deny,Allow
Deny from All


For the life of me I can’t understand why WordPress still allows file editing from within the WP admin console. If you hover over Appearance you will see ‘Editor’ and also in Plugins you will see ‘Editor.’ While this may be super convenient for some, this is a HUGE security hole. Unless you are limiting login attempts, a hacker or spam bot can bash their way in to your WordPress admin area and then have their way with all of the template and plugin files. To disable the editor, open the wp-config.php file in your favorite text editor application and then add the following line to the bottom of the document just before the /* That’s all, stop editing! Happy blogging. */ line:

define(‘DISALLOW_FILE_EDIT’, true);

And voila!


Another way to harden the site is, if you have access to Linux Command Line for your server, to change ownership for all files in a specific vhost (or domain) to a single user that is not the root user on the server. You can do this by first creating this new user, then cd-ing into the directory above your all of a domain’s website files and running a command in the command line. Here is an example of how it looks on our server:

[root@cloud-server-01 ~]# cd /var/www/vhosts/
[root@cloud-sever-01 vhosts]# chown -R username:groupname *

The directory tree could be different for your server, but the chown command would be the same. The document root folder and vhost folder would still need to be owned by either the root user or apache, but all of the files inside the document should be owned by a user with far less privileges on the server. That way, if the user is ever compromised only that specific vhost is subject to being subverted, not the entire sever.


You also want to make sure all files and folders in your WordPress install have been set with the proper permissions. Files should have permissions set to 644 and folders to 755, with the exception being the uploads folder and all of its child folders.


When installing WordPress, the default username that most people set up as their administrator account is simply called ‘admin’. If your installs have a user called admin, delete it! That is the first thing hackers will attempt when bashing into your site. You can do this by first creating a new user in WordPress. Call it something random. Don’t use the website name or company name or any other commonly used names (such as webmaster, administrator, or webadmin). Give this user an Administrator role – then, log out and log back in using this new user. Go to Users again and delete the old admin user. When asked what to do with its posts, attribute them to the new Administrator you just created. Once that is done, go back into the new users settings and give it a nickname of something that is neither the website name, company name, nor username. Sometimes the nickname can be a give away to hackers as to what the username is.


Another thing you should do is change the database table prefix. This is always one of the first things I do when setting up a new WordPress site. If you are creating a brand new WordPress site, you can make this edit inside the wp-config.php file prior to installing WordPress on the server for the first time. To do this, open wp-config.php and edit the line that looks like this:

$table_prefix = ‘wp_’;

And make it look something like this:

$table_prefix = ‘xh4523i_’;

When hackers attempt to inject malicious SQL code into your database, knowing what the table prefixes are is a like giving them a helping hand in messing your site up. By assigning a random value to your database prefixes, you can make a hackers life much harder and your life much easier.

If you have a pre-existing WordPress site, then this kind of thing can be a bit tricky. Be sure you backup all of your database tables before attempting this and then check out this article for how to change your database table prefixes:


Hackers are quite good at guessing passwords. Hackers have programs that can make thousands of guesses per second, so even the most secure passwords of 12 to 16 characters (consisting of letters, numbers and symbols) can be cracked in only a matter of days. By using secure Pass Phrases (such as ‘river dancing creeps me out’) as opposed to Passwords we can turn that 3-day turnaround into about a half a millennium turnaround. Check out this classic xkcd comic strip explaining how this works:

an xkcd comic explaining how secure passwords work


The last recommendation I have for you is to always stay up to date on plugins and especially the WordPress core. The greatest strength WordPress has is its community. They are constantly finding new holes and exploits and as a result, the WordPress team churns out security updates all the time. Lately it has been pretty frequent (something like 12 this year) but usually there are about 3 to 4 times per year. The way they get reported is usually in a quite responsible manner so hackers only learn about them once WordPress releases the update and tells people about it. So update as soon as possible to keep things secure.

So there you have it – my top 10 tips for securing your WordPress site. The above should definitely be a huge help to hardening your WordPress installs. If you need any help or have additional questions, drop me a line and I’ll see what I can do to help.