The whitespace that you love and defend, day in and day out, it just sits there. It sits there mocking all of your effort and energy in fighting for its right to exist. The right to party. This particular white space has no right to party. Much more it has no right to even exist. It just sits there shouting "Hey! Look at me! Forget about that perfectly calculated, good looking, and fair design above me... I'M JUST HERE AND I'M SUPER HARD TO LOOK AWAY FROM!"

Such an asshat.

To illustrate:

Here's how I deal with it, and it's super simple:

So you have your footer (add class or not, just use the same 'ol footer):

<footer>
...
</footer>

Let's make sure that we have the box shadow mixin already in your stuff:

// Box Shadow
// 
@mixin box-shadow($value) {
    -webkit-box-shadow: $value;
    -moz-box-shadow: $value;
    box-shadow: $value;
}

Here's the mixin for our extended background:

// Extend the background of the bottom most element (footer) to eliminate
// white space if content is not sufficient to fill the viewport.
//
@mixin bgExtend($color) {
  &::after {
    content: "";
    @include box-shadow (0px 500px 0px 500px $color);
    display: block;
    width: 100%;
    position: absolute;
  }
}

And in your main scss:

footer {
  @include bgExtend(#000);
}

This simple mixin is how I get rid of that entitled white space at the bottom of my pages, if you have a better solution please let me know!

Thanks for reading, until I write stuff & things again, I'll catch you on the flip side.

January 1, 2017 was that "sometimes" for me. I did indeed make my way into the office to correct that problem this very day. I did spend much of the following week explaining what had happened and what I failed to do over and over again to my collegues. Lastly, I'm still left wondering how I let this one slip through. Nevertheless, I am the one who "done goofed". I learned from my mistake and so should you.

When you have a date range that spans over a year change you should, most definitely, remember to make an exception for that. The problem is simple:

• Show specific stuff between the month of November and the month of February.
• Don't show that specific stuff any other month.

Your initial date range is probably something like this:

10/01/yyyy - 03/01/yyyy

// Define our variables
// 
// current date and current year
var currentDate = new Date(); 
var currentYear = new Date().getFullYear(); 
// min and max variables
var minDate = new Date('10/31/' + currentYear); 
var maxDate = new Date('03/01/' + currentYear);

// Set our Date Range
//
// start of range 
if (currentDate >= minDate && currentDate <= maxDate ){ 
  $("#condition1").show(); 
  $("#condition2").hide();  
// end of range  
} else { 
  $("#condition1").hide(); 
  $("#condition2").show(); 
}

That's all well and good if the months fall in the same year but they don't so you simply adjust for the next year as follows:

10/01/yyyy - 03/01/yyyy+1

// Define our variables
//
// current date and current year
var currentDate = new Date(); 
var currentYear = new Date().getFullYear();
// next year variable 
var nextYear = new Date().getFullYear()+1;
// min and max variables 
var minDate = new Date('10/31/' + currentYear); 
var maxDate = new Date('03/01/' + nextYear);

// Set our Date Range
// 
// start of range 
if (currentDate >= minDate && currentDate <= maxDate ){ 
  $("#condition1").show(); 
  $("#condition2").hide(); 
// end of range   
} else { 
  $("#condition1").hide(); 
  $("#condition2").show(); 
}

It's not that simple because the months falling in the next year are now out of range. Initially I failed to do that simple step and stopped at adding "+1" to the date range causing the "specific stuff" to not show on the first of the new year. Enter the exception:

01/01/yyyy - 03/01/yyyy

// Define our variables
//
// current date and current year
var currentDate = new Date(); 
var currentYear = new Date().getFullYear();
// next year variable  
var nextYear = new Date().getFullYear()+1;
// min and max variables  
var minDate = new Date('10/31/' + currentYear + ', 4:00:00 PM'); 
var maxDate = new Date('03/01/' + nextYear);
// exception min and max variables
var minDateException = new Date('01/01/' + currentYear); 
var maxDateException = new Date('03/01/' + currentYear); 

// Set our Date Range
//
// start of range  
if (currentDate >= minDate && currentDate <= maxDate ){ 
  $("#condition1").show(); 
  $("#condition2").hide();  
// the exception to our range
} else if (currentDate >= minDateException && currentDate <= maxDateException ){ 
  $("#condition1").show(); 
  $("#condition2").hide(); 
// end of range 
} else { 
  $("#condition1").hide(); 
  $("#condition2").show(); 
}

We, at this point, accounted for that but the month of February is a tricky one with all that Leap Year business. Lets modify our variables and try again:

10/01/yyyy - (03/01/yyyy+1)-1
01/01/yyyy - (03/01/yyyy)-1

// Define our variables
// 
// current date and current year
var currentDate = new Date(); 
var currentYear = new Date().getFullYear();
// next year variable  
var nextYear = new Date().getFullYear()+1;
// min and max variables   
var minDate = new Date('10/31/' + currentYear); 
var maxDate = new Date('03/01/' + nextYear);
// exception min and max variables
var minDateException = new Date('01/01/' + currentYear); 
var maxDateException = new Date('03/01/' + currentYear); 

// Modify our maxDate and maxDateException variables 
// 
maxDate.setDate(maxDate.getDate() - 1);
maxDateException.setDate(maxDateException.getDate() - 1);

// Set our Date Range
// 
// start of range 
if (currentDate >= minDate && currentDate <= maxDate ){ 
  $("#condition1").show(); 
  $("#condition2").hide(); 
// the exception to our range 
} else if (currentDate >= minDateException && currentDate <= maxDateException ){ 
  $("#condition1").show(); 
  $("#condition2").hide();
// end of range  
} else { 
  $("#condition1").hide(); 
  $("#condition2").show(); 
}

Just as I thought that we had this all wrapped up and ready to go I remembered that there was yet another small step to take into account: we want the date range to begin at a specific date and time. Thus, here is our final code:

// Define our variables
// 
// current date and current year
var currentDate = new Date(); 
var currentYear = new Date().getFullYear();
// next year variable  
var nextYear = new Date().getFullYear()+1;
// min and max variables  
// add specific time when we want our date range to begin on 
var minDate = new Date('10/31/' + currentYear + ', 4:00:00 PM'); 
var maxDate = new Date('03/01/' + nextYear);
// exception min and max variables
var minDateException = new Date('01/01/' + currentYear); 
var maxDateException = new Date('03/01/' + currentYear); 

// Modify our maxDate and maxDateException variables 
// 
maxDate.setDate(maxDate.getDate() - 1);
maxDateException.setDate(maxDateException.getDate() - 1);

// Set our Date Range
// 
// start of range 
if (currentDate >= minDate && currentDate <= maxDate ){ 
  $("#condition1").show(); 
  $("#condition2").hide();
// the exception to our range  
} else if (currentDate >= minDateException && currentDate <= maxDateException ){ 
  $("#condition1").show(); 
  $("#condition2").hide(); 
// end of range 
} else { 
  $("#condition1").hide(); 
  $("#condition2").show(); 
}

To wrap it all up here is a pen that illustrates how our final date range script works. Adjust the date and/or time in the testDate variable to show and hide the condition# divs. For testing purposes I made sure to write some of the key variables to the document below the divs.

See the Pen Date Range with Exception by Asim (@asimanov) on CodePen.

"This is simple stuff folks! Make sure that you test and code review before and after releasing any new product and/or update." — said everyone who's ever failed to follow their own advice.

Thanks for reading, until I write stuff & things again, I'll catch you on the flip side.

All of those "free" platforms were great for exploration and the occasional moaning about the myriad of mundane and annoying crap that no one really cares about; However, you still wrote that garbage because it got likes, attention, and occasional comments of support and comradery. If you wanted more control of your platform you had to think a little harder past your hotmail address and a seriously weak password. Did I mention that there were also free forum solutions like ProBoards?

Now that I covered most of the legacy social communication solutions let's take a look at the age of blogging. The giant of that domain started to emerge in the midst of Mambo and Joomla (and eventually Drupal) slapping contest, which were the first popular and fully functioning php based content management systems. I'm talking about Wordpress. WP was a simple, flexible, blog-first CMS. Downloading, deploying, and customizing WP installations wasn't exactly a cake-walk in the beginning but with a little know-how and research it was actually quite easy compared to its predecessors. At some point if you had a shared hosting account with BlueHost (I still do, it's great), or another major shared web hosting provider, your Control Panel received an update that allowed you to install WP with a single click, how awesome is that?!

It is, indeed, very much the "bees-knees" but it also ushered in the age of php-based vulnerabilities and WP bloat. Now we have an ocean of WP blogs, some real and a legion of abandoned and never updated installs, alongside WP hosted accounts (basically more of the same thing but franchised). With well deserved accolades and attention came a whirlwind of php developers building anything from social media plugins to full on professional and pricey themes. The Achilles' heel of this wonderful software is, and always will be, security.

As anyone can expect popular software receives a lot of good and equally bad attention. The good stuff was in the aforementioned plugin and theme development. Anything that you could ever need or want was probably already developed, all you have to do is search for it in the WP plugin directory. What was also plentiful and already developed were security hacks and code made specifically to exploit the myriad of vulnerabilities plaguing the system. Right. There. In. The. Plugins. Major and intermittent versions of WP kept on rolling out in an attempt to plug the onslaught of security leaks but two main facts remain constant to this day: thousands of rogue and abandoned installs remain unchanged, WP remains the most targeted CMS in terms of security and brute force attacks.

It's important to note that I'm not running a WP smear campaign. I have worked with and maintained WP installs in the past and find the CMS actually quite useful and user friendly. WP is hands down the easiest and most common-sense solution for projects/websites that are meant to be put up quickly and have multiple contributors right away, or in a sitution that demands a quick blog solution RIGHT NOW (WP target audience). This article is part 1 of my post entry and automation process, it has nothing to do with WordPress aside from highlighting the popular blogging platform and the number one reason that I abandoned it.

Next up, "Post Entry Process - The Setup"

For more research concerning WP security woes:

• Vulnerability tracker
• A brief history of security issues
• Interview with WordPress.org's Security Czar, Nikolay Bashiyski
• WordPress white paper
• Protecting yourself

Thanks for reading, until I write stuff & things again, I'll catch you on the flip side.