Hi, my name is Mike McLin and in this video I am going to talk about the 2 files that are required for Grunt Task Runner to function. The first is the package.json file which we’ll use to describe metadata about our project, like the name, version number, etc. We will also use this file to load the necessary plugins required by Grunt. From there I’ll discuss the second file required for Grunt to function, which is the Gruntfile.js. This is your main configuration file, and where we’ll spend most of the time in this video. The Gruntfile.js is where everything really happens. So, let’s get started by creating our package.json file.

Creating a package.json file

There are a couple of ways you can create your package.json file. You can run the ‘npm init’ command in your command line tool of choice, or you can use a tool called grunt-init, which is a handy project scaffolding tool that can build your whole project structure for you based on a project template. While, this is an awesome tool, we aren’t quite ready for that yet, so we are going to go with the easiest most straightforward way, which is copy and paste. I’ll head over to the Getting Started page on the Grunt website, and copy their package.json example. Now, I’ll paste it into a new document and save it as package.json in my project’s directory.

Now, let’s configure the file. First off, I want to point out that the file uses 2-space indents, and camelCasing. Personally, I prefer tabs, but it is always a good practice to use the coding standards established by the project. Since this is a Node Package Manager file, I will adopt their coding style. Both the name and version fields are required for Node Package Manager, and for Grunt to run, we will need to install the Grunt plugin along with any other dependencies by using the devDependencies field. Let’s change the name of our project to ‘hog-wild’. Notice the naming convention. You are not allowed to use non-url-safe characters, and your name can’t begin with a period or underscore character. The version value is a 3-number value that follows the Semantic Versioning Standard, which can be found at semver.org. The first number is the major version, the second number is the minor version, and the final number is the patch version. Right now, we have a major version of 0, which is what is used for initial development. Since, we don’t have a working app yet, this is a good version value to start off with.

You’ll notice that the devDependencies value is an object, which has it’s own key:value pairs. The keys are the names of the Grunt plugins we need to install, and the values are the plugin versions we need to install. Notice there is a tilde character in front of the versions. This means, that Node Package Manager should install the newest version of the plugin, all the way up to the next major revision range. So, for example, Node Package Manager will install the newest version of Grunt 0.4. So, if version 0.4.8 is the newest version, then it will download that. However, it will not jump to the next revision range. In other words, it will not install Grunt 0.5.0, because that might not be completely backwards compatible with your project and could break functionality.

For now, don’t worry about the devDependencies section. I will show you how to create your own devDependencies object later on as we work with Grunt. I do want to point out that this is a bare minimum example of a package.json file. If you take a look at the package.json file for my MikeMcLin.net website, you’ll see several other values. You can learn more about the various options you can add, by heading to the Node Package Manager package.json webpage. For now, let’s move on to the Gruntfile.js.

Creating a Gruntfile.js

Similar to the package.json file, the Gruntfile can be created in a few different ways. Since we are just starting out, I’ll copy the sample Gruntfile that is on the Grunt website. Now, I’ll paste it into a new file and save it as Gruntfile.js, in my project’s root directory, right next to my package.json file. Also, notice that it shares a similar coding style with Node Package Manager, like 2-space indents and so on, so we’ll continue to build this file using those same coding styles.

The Gruntfile wrapper function

First thing you’ll notice is the wrapper function. All the code goes inside of this function. This is boilerplate markup that never changes. You don’t really need to understand what is going on here to use Grunt.

Inside of the wrapper function there are 3 main sections. The first is your configuration, which is the meat and potatoes of your Grunt file. The next section is where you load the plugins that are required for your Grunt tasks, and the final section is for your task lists.

Setting up the Gruntfile.js config

OK, let’s jump into the config, to see what is going on. I’m going to remove a lot of these task configurations, so the config doesn’t look so overwhelming. The first thing you’ll see is a pkg property which is storing the contents of our package.json file. Once again, this is pretty much boilerplate stuff, you will probably never change this, and therefore all you need to know is that it is loading in the contents of your package.json file, and storing the data into the pkg parameter.

Now, we get to our first task, which is the concat task, which takes multiple files and joins them into one file. Inside the task, we have an optional options property, that can override some of the defaults for that task. Beneath that we have what is called a target. This task only has one target configured, but you can create multiple targets. We can name our target whatever we want as long as it’s a valid JavaScript identifier. Just stick with camel case target names, and you should be alright.

Target’s can also have their own options parameter, which will override the task’s options parameter. Inside of the target we are declaring some files. Since most of Grunt’s tasks are file related, understanding how to configure your files is very important. There are several ways you can tell Grunt which files you want to use. This method is called the Compact Format. It is best suited for read-only tasks that don’t have a destination file, like linting. This particular concat task is setup to grab all of the JavaScript files within the src directory and any of it’s subdirectories. In other words, it grabs what is set in the src parameter, and then performs it’s operation, which in this case is to concatenate all of the files. After concatenation, it needs a place to store the new file, which is set in the dest parameter, which is short for destination. In this case, the dest value is using a template to help name the file. We’ll go over templates in a bit. So, the issue is, what if we want to grab a different group of files and concatenate them as well? Well, you could create another target, however targets are usually used to divide tasks so that they can be run individually in different circumstances. Now we are seeing the limitations of the Compact Format. Let’s upgrade this to what is called the Files Object Format.
Now, we use the dest as the key, and the src as the value. We can easily add more file mappings while separating them with a comma.

While this works well, there is also another format called the Files Array Format, which seems to be more popular and flexible. This is the format I choose for the majority of my file-based tasks.

Using globbing patterns to specify files in your Gruntfile.js

Now that we know how to format our src and dest parameters, let’s take a look at how we can use globbing patterns to specify the files we want to use.

The first example is the most basic. You can simply type out the relative path to the file. Note that all paths are relative to the Grunt file.

The second example is an array of files. It will include those three files.

The third uses an asterisk wildcard which means any character except the slash character. So this would include the three files mentioned in the previous example, plus any other JavaScript file that is in the foo directory that begins with ‘th’.

Now, what if the foo directory has subdirectories in it? Well, those files will not be included. So, how do we include those? Well, we can use a double-asterisk, which will now look for JavaScript files in all of foo’s subdirectories, and their subdirectories and so on.

We also have a single node-glob pattern which I rarely use, but it’s there if you need it. You basically can create a comma-separated list of values inside of curly braces, and it will go through each entry as if it were it’s own.

It is important to note that the order that you place your files into an array matters. In the second example, the concatenated file would have this.js, followed by that.js and then the-other.js. This is really important when certain files require others to be loaded before they are. A good example would be a jQuery plugin needs to be loaded after jQuery has loaded. Whenever you use an asterisk, it loads the files in alphabetical order. If a file needs to be loaded prior to the other files, you can do so by putting it before the wildcard files in the array.

One of the most powerful tools is removing files from an array. You do that by prepending an exclamation point to the front of the filepath. This example will load in all JavaScript files in the foo directory, except for the bar.js file. This is also a handy way to load a file last. You can add all of the files using the asterisk, then remove the file, and now re-add the file and it will be added to the end.

Using templates in your Gruntfile.js

Finally, the last thing I want to talk about when discussing file paths is templates. Nearly everything in the Grunt config can be used as a template, which feels very similar to a variable. Templates follow the following format using less than and greater than characters and percent characters as delimiters. We’ve already seen a template earlier in our Grunt file. The dest for our concat task is using a template to set the destination file name. In this case, it is going to assign the value of the name parameter in the pkg object. Well, we are reading the contents of the package.json file, and storing it into the pkg object. So, essentially the pkg object contains the same data as the package.json object. So, the pkg.name value is ‘hog-wild’, since that’s the value we gave the name property in our package.json file.

Alternatively, we could use the separator property as a template if we wanted. If we changed this to concat.options.separator, the filename would now be semi-colon. Of course, this example isn’t realistic, but I just wanted to point out that nearly everything in the config can be used as a template. Templates will eventually be one of your best friends, and we’ll be using them a lot throughout this video series.

Gruntfile.js Plugins Configuration

OK, that’s it for the config object. I’m going to wrap the remaining parts of the Gruntfile up pretty quickly. As mentioned earlier, these are the Grunt plugins that we require to run our tasks. Since, we’ve deleted a good amount of our config section, we now are only left with the concat task. Therefore, this is the only task that we will need to load. So, how do we know what plugins are available to us? Well, you would head to the Grunt website and browse their plugins section. I will be picking out various plugins and installing them throughout this course, so don’t worry if none of this makes much sense to you right now, or seems overwhelming. It is actually very easy.

Creating Task Lists in your Gruntfile

Finally, the task lists… These tell Grunt which tasks to run, and in which order. This Grunt file has 2 task lists. The first one is named ‘test’. The test class will run the jshint task, followed by the qunit task. Obviously we’ve removed those tasks from our config, so this task would no longer work. The second task list is called default, and it is…well, the default task list.

So, how do we run these tasks lists. Well we run them using the command line. I would navigate to my project’s folder. Then, if we type the grunt command, like I did in the first video, the default task will run. If I want to run a specific task, I will type the grunt command plus a space, and then the name of the task list I want to run. For example, in this file, I might want to run the test task list, so I would type the command ‘grunt test’.

OK, that’s it for this video. If you are somewhat confused, don’t worry. The hard part is definitely behind you. This was a lot to take in, and it’ll all start making sense when we begin building real-life examples. Speaking of which, that’s what we’ll do in the next video, where we’ll look at how to concatenate and minify our JavaScript files.

Hi, my name is Mike McLin and in this video series we are going to be talking about Grunt. Grunt is a JavaScript Task Runner. So, what does that mean exactly? Well, the tool is built with JavaScript, and runs on Node.js. You do not need to know any JavaScript or know anything about Node.js to use the tool however. OK, so what is a task runner? A task runner performs automated tasks like compilation, linting, unit testing, concatenation, minification and so on. Let’s take a look at this tool in action.

Grunt Task Runner Example

I am currently in my project’s directory using my command line tool. All, I need to do is type the word “grunt”, and the default task runner begins. After just a few seconds, it has completed. So, what has Grunt done for us?

What did Grunt.js do for me?

It ran my JavaScript files against JSHint to make sure they are lint-free, executed all of my JavaScript unit tests, cleaned up my production JavaScript directory, concatenated all of my jQuery plugins and 3rd party JavaScripts into one file, minified all of my JavaScript files and saved them in my production directory, cleaned up my production image directory, crunched all my source PNG and JPEG images and saved them to the production image directory, copied my gifs to the production directory, compiled all of my SASS files into a single CSS file, added the necessary WordPress comment block to the top of my style.css file and saved it to the production directory, and finally cleaned up some image sprites that were no longer needed. It basically completed tasks that would have totaled a couple minutes of work on my end, in only a few seconds. Also, please note that I have only setup about 6 or 7 tasks compared to the hundreds of tasks that Grunt can perform.

The beauty of this tool is not only the speed, but the ease of use. Now, anybody that works on your project will not need to know how all of your tools work. Instead, they just have to type the word “grunt”, and the task runner will perform the tasks for them which will lead to more consistent, higher-quality content.

How to Install Grunt.js Task Runner

We will end this video by installing the Grunt, which is extremely easy. First you need to make sure that your computer has Node.js installed. To install Node.js, simply head to the Node.js website and download the installer. Now install the program just like you would any other Mac or Windows program. Once installation is complete, you might need to restart your computer before installing Grunt.

To install Grunt, open up the command line tool of your choice. Now type in the command “npm install -g grunt-cli”. If the install fails, you most likely need to run the command as a superuser on Mac or an Administrator on Windows. This is very easy. On Mac, just type in the word “sudo” plus a space before the command. It will prompt you for your password. On Windows, open your command line by right clicking it and choosing “Run as Administrator”. Now type in the command, and everything should work appropriately.

So now that we have Grunt installed onto our computers, and we have a basic idea of what Grunt does, We’ll get started building our first Gruntfile in the next video…

Hi, my name is Mike McLin, and in this video I am going to talk about truncating text. First I’ll demonstrate how to truncate text using the CSS text-overflow property. From there we’ll take a look at cross browser support. Finally, we will view some experimental features of the property and how to accomplish a multi-line truncate.

To demonstrate the basics of how to truncate text with CSS, I’ll use this quick demo. For the HTML markup, we have a simple paragraph of Lorem Ipsum text. I’ve also added both width and border declarations to the paragraph element.

Setting up text-overflow: ellipsis

Eventually, we will want to use the text-overflow CSS property to add three dots after our text, which is also known as an ellipsis, but before we can do that, we must make the text overflow. We can prevent the paragraph from wrapping into multiple lines by assigning the white-space property a value of “nowrap”. This will cause the text to appear on a single line, and overflow outside of the paragraphs box.

Now, to prevent the text from overflowing outside of the box, we will add an overflow value of “hidden”. The only thing left is to add the final declaration, which is assigning the text-overflow property a value of “ellipsis”.

Now, we have the truncating effect we desire. There is a bit of a gotcha here, however. The text overflow property will only work on block-level elements. So, If I change the paragraph tags to emphasis tags, we will see the effect go away. We can simply restore the effect by manually changing the display property of the element to a block.

Text-overflow Browser Support

It is that simple to create this effect using on CSS. I we view the property on the “caniuse” website, we see that browser support is very strong. Older versions of Opera and Opera Mobile, plus all versions of Opera Mini will require a vendor-specific declaration to render the effect appropriately. That is as simple as rewriting the text-overflow property and prepending a “-o-” in front of it.

When looking at Mozilla Developer Network page for the text-overflow property, you will see that there are some other implementations, most notably a 2-value syntax that allows you to place an ellipsis before and after the body of text. These extra features appear to only currently work in Firefox, and therefore are pretty much useless to most developers at this time. It should be noted that the text-overflow property has been reduced down to working draft level, so the property could see some changes in the future.

Text-overflow Multiline Truncate

Usually the first question that somebody asks when seeing text being truncated with an ellipsis by the text-overflow property is if it will allow you to truncate values that overflow height-wise from a box. In other words, can we have a multiline truncate? The answer is no. Text-overflow only calculates text that overflows on the horizontal sides of the box. However, there are some workarounds.

Setting Up -webkit-line-clamp Multiline Truncate

As pointed out by David Desandro, there is a property for webkit browsers called “-webkit-line-clamp” that will allow you to do multiline truncates when used in conjunction with a few other experimental webkit-only properties.

First, we need to set the display property to a value of “-webkit-box”. Next, we will set the -webkit-box-orient property to a value of “vertical”. Finally, we use the -webkit-line-clamp property to set the number of lines we want to display.

This would seem to be a perfect answer to our multiline truncating woes, but obviously it will only work in webkit browsers, plus these properties are considered experimental, and unsupported.

Truncate text with an Ellipsis using jQuery

To be honest, the best way to achieve multi-line truncation is to use JavaScript. There are many different plugins and scripts that can give you this feature. I found a jQuery plugin called “dotdotdot” that appears to solve the problem, plus enhance the functionality by adding additional features like adding hyperlinks after the truncated text ellipsis.

Final thoughts about text-overflow ellipsis

So, that’s it. As you can see truncating text isn’t quite an exact science. However, the majority of the browsers today are up to the task of truncating single-line text using only CSS or performing more complex truncations by falling back to JavaScript.

Hi, my name is Mike McLin and in this video I am going to explain why WordPress’s wp_kses() function (if that’s how you pronounce it) is better than PHP’s strip_tags() function when it comes to sanitizing data for security. The purpose of both of these functions is to filter data by only allowing certain HTML tags, while removing all other tags. We usually will run one of these functions (or a similar function) whenever we are accepting user input, for example comments on a blog, to prevent any type of unexpected or malicious behavior. OK, Let’s get started.

Setting up

First off I’ll create a snippet of HTML, and assign it to the $string variable. This HTML consists of 2 paragraphs, the first one also containing an anchor link. If we echo out the string, we can see that it renders properly.

PHP string_tag() function

Now, let’s place the $string variable inside of PHP’s strip_tags() function and echo the result. We can see that the text is still there however, all of the HTML tags have been removed. The PHP strip_tags() function accepts 2 parameters. The first is the string that is to be filtered, and the second optional parameter is a string of all of the allowed tags. Let’s go ahead and allow paragraph tag.

We can now see that the 2 paragraphs have been restored. Let’s also allow the anchor tag. Now, we can see that the anchor link has been restored.

WordPress’ wp_kses() function

Now let’s go through the same steps using WordPress’ wp_kses() function. Just like strip_tags(), we’ll pass the string as the first parameter. However, unlike strip_tags, the second parameter is not optional. It is required, and it needs to be an array value, not a string. So, let’s just pass an empty array to strip out all tags.

Now, let’s go ahead and allow paragraphs and anchors. Let’s break the array out so it is easier to read. You’ll notice that the $allowed_tags variable is an array of tags, and each tag is a nested array. We store the allowed HTML attributes for each tag in the nested arrays. I’ll just leave them empty for now and see what we get.

Now it looks like everything rendered properly. We can see both of our paragraphs and our link. However, when I inspect the link, you can see that the href attribute is missing. That is because we didn’t add it to our anchor tag’s attribute array in the wp_kses() function. You can see that the strip_tags() renders out the whole anchor tag as expected. While this might make wp_kses() a bit more cumbersome to initially setup, it also adds another level of control when filtering your data.

Let’s go ahead and allow the href attribute for anchors, along with the title attribute. You’ll notice that these have a value type of an array too. Basically everything in the wp_kses() $allowed_tags variable equals an array. Now, we can see that the anchor is outputting the href attribute as expected.

When comparing these 2 functions, many people stop here and miss out on 2 other important advantages that wp_kses() has over strip_tags(). The first is it is just a smarter function. Let’s go ahead and add this little arrow, pointing to the link and see what happens.

wp_kses is smarter than strip_tags

You can see that this completely broke the expected result from PHP’s strip_tags() function. The less-than symbol appeared to be an opening character for a potential HTML tag, a tag that wasn’t passed into the second parameter of the strip_tags() function, and therefore wasn’t rendered. The wp_kses() function rendered the HTML properly.

wp_kses is more secure than strip_tags

The other advantage wp_kses() has is probably it’s biggest advantage of all. It helps prevent JavaScript attacks. Many times, the purpose of these functions is to help prevent such attacks, and when somebody does something like this… The JavaScript is denied successfully. Instead of executing the JavaScript alert, it has just output the value as harmless plain-text.

Now, let’s see what happens when we try something a little more clever. We’ll sneak our JavaScript code into our anchor href attribute and see what happens. When I click on the strip_tags() link, the JavaScript is executed. When I click on the wp_kses() link, the JavaScript is not executed, and we are sent to whatever URL the link has sent us to.

If I go back and inspect the anchors, you can see that the javascript is still present in the strip_tags() anchor href, while it has been removed from the wp_kses() anchor.

About the $allowed_protocols parameter in wp_kses

This occurs because wp_kses() actually has a 3rd parameter that can be passed to it, which is an array of allowed protocols. Nearly all popular protocols are accepted by default like http, https, mailto and so on, but JavaScript isn’t. You’ll probably never want to overwrite these default protocols, but if you do, you can always read more about them on the wp_kses() page in the WordPress codex.

So, that’s the end of this tutorial. My name is Mike McLin, and I hope you have seen why wp_kses() is more powerful, flexible, smarter and more secure than PHP’s strip_tags() function.

Hi, my name is Mike McLin, and in this video I am going to talk about Markdown, what it is, why I use to despise it, and why I now love it. I’ll walk through some basic Markdown examples, but more importantly, I’ll explain what Markdown really is, and why you should embrace it. So let’s get started.

Starting out with Markdown Syntax

My first experience with Markdown was probably similar to most other web developers out there. I decided to get on the Github bandwagon (pun intended) and noticed that one of their first recommended steps when creating a repository, was to create a README file, and the README file was suppose to be in Markdown syntax.

So, I immediately entered Markdown into my Google machine, and found the Daring Fireball site that has all the information about Markdown. Right off the bat, I see the first sentence “Markdown is a text-to-HTML conversion tool for web writers” and I began to frown. I mean really? Do we really need another text to HTML tool out there? I already had to learn wikitext, textile, bbcode and so on… Now, I have to learn another one? I was thinking, isn’t HTML a simple enough language where anybody that has the skillset to use GitHub should be able to learn a little bit of HTML syntax?

Regardless, I proceeded, because the cool kids were using GitHub, and I wanted to be invited to their parties, if only for the cake. So, I jump straight over to the syntax section to begin my reluctant journey. I notice they have an overview section that includes the philosophy for the project. I roll my eyes as I skip over to the Block Elements section, so I can actually start writing code, because the clock is ticking, and I don’t have time for this.

Learning the Markdown Syntax Language

I see that paragraphs are just blocks of text with a blank line separating them, what a shocker. OK, now I see there are 2 different ways to create headings. We can use this first method which is called setext (or however you pronounce it). It uses either either equal signs or dashes on the line below the text to turn it into a heading. What a waste of time and characters I thought. OK, I also see that we can use pound symbols before the text to declare a heading which is apparently called the atx style. Even better, I can place pound symbols after the heading too, so it almost feels like HTML. Perfect!

I move on and see that I can create a blockquotes, but I have to put these greater symbols in front of the text on each line of text…what a pain. Then I realize I only actually need to place it on the first line, and I’m thinking, ok I can handle that. List items work as I expected, I can use either an asterisk, plus symbol, or a dash, and decide I’ll use the dash because it doesn’t require the use of the shift key.

Now, I see ordered lists actually have the number preceding them, and I immediately think how unintuitive. Now, if I need to insert a list item somewhere in the middle of the list, I have to retype all the following numbers. Luckily, I scroll down and notice that any number will work. Perfect, I’ll just use all 1’s, like this example.

Eventually, I find my way down to the span elements. Emphasized or italic items have a single asterisk wrapping them, while strong or bold-faced items have a double asterisk surrounding them. Pretty common stuff.

Finally I come to the links, and see that I need to place the link text in brackets, and then place the url in parenthesis behind it. I scroll down and see something about reference-style links, where you actually place the url of the links somewhere else on the page, and I chuckle to myself as I think, why are they making something as simple as links so trivial. Did I mention I hate that I am having to learn this right now.

So, I create my README file, and it looks something like this. I download a plugin for my text editor that shows me the HTML preview of the Markdown, and I am satisfied with the HTML result, but still loathe Markdown.

I finally come full circle about Markdown

So, a few months go by, and I see someone ask what Markdown is on a forum or something, and I see someone respond saying that the purpose of Markdown is to make your text files easier to read…and that’s when it hit me. I had been using Markdown completely wrong, and misunderstood the whole project. I hurry back to the website that introduced me to Markdown and this time read the philosophy…and there it was in plain text… “Readability, however, is emphasized above all else.”

This completely change my outlook on Markdown. I mean, I love to document stuff. I get all nerdy with my CSS comments, and I’m not the only one. Take a look at any popular framework, like HTML5 Boilerplate or Twitter Bootstrap and you’ll see that they are meticulously commented. It makes us feel warm and fuzzy to create these beautifully spaced and formatted comments. Unfortunately, not everyone creates comments in the same fashion, so it gets hard to decide how to format your comments. Well, Markdown has solved that problem, at least for our documentation and README files.

So, I reread the Markdown syntax and realize that it usually gave me 2 options on how to format something, and almost every time I picked the wrong option. Maybe not syntactically, but spiritually, based on the motives of the Markdown project, I picked the wrong choices.

So, I decided to use the setext style headings, and not skimp out on those greater-than characters for my blockquotes. I began to use real numbers for my ordered lists, use those reference-style links that I previously thought were unnecessarily complex, when I wanted to use anchors in a paragraph.

Now, I look at this simple text file, and it is beautiful, and easy to read. If I compare the same document written in HTML, there is no comparison when it comes to readability. So, now I embrace markdown, and understand the need for it.

So, thats the end of my Markdown journey. My name is Mike McLin, and I hope this helped you understand Markdown language a little better, and hopefully you’ll agree with me, that it is a great tool in our development community.