In my scenario, I have a custom post type that uses the add_meta_box() function to add a few custom fields. As a matter of fact, those are the only fields available… the title, body, etc, have all been removed. Furthermore, I save those custom fields in a new table, because I need to perform additional actions outside of WordPress with that data, and storing them separately will make that a lot easier.

WordPress allows you to perform four actions with any post type, which meant I needed four hooks in order to keep the data in my table in sync with the status of the post. Those actions are: saving, moving something to the trash, restoring it from the trash, and permanently deleting.

It seems that WordPress is a bit inconsistent in the naming convention of those hooks, which is why it took some trial and error, but after spending some time with it, I’ve tested and confirmed the following four hooks to be the ones you need:

Saving

add_action('save_post', 'custom_save_function');

Trashing

add_action('wp_trash_post', 'custom_trash_function');

Restoring

add_action('untrash_post', 'custom_restore_function');

Deleting

add_action('delete_post', 'custom_delete_function');

Hooks that didn’t act the way I expected were: trash_post, wp_untrash_post, trash_custom-post-type, and untrash_custom-post-type. For instance, trash_post only worked with built-in post types, such as pages and posts, but save_post works even with custom post types.

Hopefully this two minute blog post will save someone some time, because those four hooks are pretty much necessary if you’re working with custom fields (unless you disable trash entirely and just permanently delete).

-RS

The easiest way to change it is to browse to the following folder on your Windows computer: <installation directory>\defaults\pref. Your installation directory will most likely be either Program Files or Program Files (x86). By the way, make sure Firefox is completely closed before doing this.

In that folder is a file called channel-prefs.js. Copy that file to your Desktop (select the file, press CTRL+C, go to your Desktop and press CTRL+V). Now open it with Notepad, which you can do by right-clicking on it, choosing open with, and then selecting Notepad.

Change the second line from:

pref("app.update.channel", "esr");

to:

pref("app.update.channel", "release");

Now save the file and close Notepad. Select the file on your Desktop and cut it (CTRL+X), then go back to your pref folder and press CTRL+V. Windows will ask you to confirm this, just press Continue.

Next time you launch Firefox and go back to Firefox > About, you’ll see that you’re now on the “release” update channel and it will start downloading Firefox 12.0.

Let me know if you have any questions or problems!

PS: If you’ve read to use about:config to change the update release channel, this is deprecated and will no longer work.

-RS

As you can see, I did find the CPU and therefore added a few eBay auctions to my watch list. Perhaps I can get one of those similar machines with heavy cosmetic damage, but an intact CPU that’s compatible with this model

-RS

Every major site caches content in one way or another, whether it’d be entire pages, a subset of content, or only database queries. Having a caching system in place allows you to not only serve content to the user faster, but also reduces the strain on your server. The thing to remember is that just because you can cache content, doesn’t mean you should.

Let’s say you’re parsing a complex XML file and display its contents to the user, but the XML file only changes on a daily basis. If 100 users view that page and your server has to run that parsing script 100 times, it will have more of an impact on the server than sending back a static file. You may want to cache the results of the parsing script for 24 hours and then run the parsing script again to update the cache.

On the other hand, let’s say you’re running a daily deal website that displays a counter of how many users bought the deal. If you have a limited number of deals available, it’s in your and the user’s best interest to know when a deal has sold out. That number has to be pretty much up to date and you can’t reliably determine when to update a cache, so in that case, caching may not be desired.

Lastly, there’s something called triggers. My professor used to say that a computer in itself is pretty dumb and that it needs to be told exactly what to do. A cache doesn’t get updated unless something triggers it. If I want something to happen every 24 hours, for example, that’s what you’d use a cron job for, but in our instance, we only want to update the cache when someone is actually trying to retrieve the data and the cache is expired, so for our project below, the vistor will be the trigger.

Project

The goal is to build a simple caching feature into a script that will cache the results for a predefined duration.

Requirements

• Allow caching to be turned on and off.
• Ability to set the cache’s duration before it expires.
• Set a location on where the cache will be stored.

Solution

When a user requests a page that contains the script, it will first check whether caching is enabled. If it is, it will check to see if a cached version already exists that can be displayed. If that is also true, it will compare the cache’s creation time with the current time and determine whether the cache is expired or not. If it is, it will execute the script and cache its content, but if it isn’t, it will display the cache to the user. If caching is turned off or the cache file doesn’t exist, the script will always execute the full script.

Implementation

First we’re going to setup a few variables to use in the script:

1
2
3

$ENABLE_CACHE = true;
$CACHE_TIME_HOURS = 12;
$CACHE_FILE_PATH = './.cache/news.txt';

$ENABLE_CACHE = true;
$CACHE_TIME_HOURS = 12;
$CACHE_FILE_PATH = './.cache/news.txt';

• On line 1 we have a bool (true/false) that determines whether caching should be on or off.
• On line 2 we’ll use an integer that tells the script after how many hours the cache is expired.
• On line 3 is a string that indicates the path and filename of the cache file. Make sure that directory is writable by apache. Also notice that I created a new folder called “.cache” that begins with a period. I do that for two reaons: (1) all folders with a symbol, such as a period, are sorted higher than the other folders, so I can find it easily and (2) a folder with a period is a system folder to me, which means it should never be directly accessed by the public. By the way, the “./” at the beginning of the string means “this directory” and refers to the directory the script is executing from — it’s a relative path.

Now that we have our variables, let’s write a condition in which to display the cache:

1
2
3
4
5

if($ENABLE_CACHE && file_exists($CACHE_FILE_PATH) && (time() - filemtime($CACHE_FILE_PATH) < ($CACHE_TIME_HOURS * 60 * 60))) {
  // display cache
} else {
  // run script and save cache
}

if($ENABLE_CACHE && file_exists($CACHE_FILE_PATH) && (time() - filemtime($CACHE_FILE_PATH) < ($CACHE_TIME_HOURS * 60 * 60))) {
	// display cache
} else {
	// run script and save cache
}

• On line 1 we do the following checks: if the variable $ENABLE_CACHE is set to true, and the file at ./.cache/news.txt exists, and the current time (let’s say 1/4/12 4:00pm) minus the file’s creation time (let’s say 1/4/12 3:00pm) — which equals 1 hour — is less than 12 hours (1 is less than 12), then display the cache.

Let’s complete the script as follows:

1
2
3
4
5
6
7
8
9
10
11

$ENABLE_CACHE = true;
$CACHE_TIME_HOURS = 12;
$CACHE_FILE_PATH = './.cache/news.txt';
 
if($ENABLE_CACHE && file_exists($CACHE_FILE_PATH) && (time() - filemtime($CACHE_FILE_PATH) < ($CACHE_TIME_HOURS * 60 * 60))) {
  echo @file_get_contents($CACHE_FILE_PATH);
} else {
  // your script runs here and the result is stored in a variable called $output
  @file_put_contents($CACHE_FILE_PATH, $output);
  echo $output;
}

$ENABLE_CACHE = true;
$CACHE_TIME_HOURS = 12;
$CACHE_FILE_PATH = './.cache/news.txt';

if($ENABLE_CACHE && file_exists($CACHE_FILE_PATH) && (time() - filemtime($CACHE_FILE_PATH) < ($CACHE_TIME_HOURS * 60 * 60))) {
	echo @file_get_contents($CACHE_FILE_PATH);
} else {
	// your script runs here and the result is stored in a variable called $output
	@file_put_contents($CACHE_FILE_PATH, $output);
	echo $output;
}

• On line 6 I use an @ sign to suppress any errors (error control operator).
• On line 8 is where you would do your XML parsing and then store the output in a variable called $output.
• On line 9 you save the entire output to the file.
• On line 10 you display all of the output on the screen.

Conclusion

As you can see, in its simplest form, it’s quite easy to implement. Now, if you had multiple scripts that required the caching of data, you might want to create functions or even an object class and with member functions, so that you can streamline changes, but I’ll save that for another how-to.

If you have any questions or comments, as always, feel free to leave them below.

-RS

(PS: In terms of ratings, 1/5 refers to the least and 5/5 to the most.)

1. HTTPS Everywhere

Easy of use: 5/5, Convenience: 5/5

This plugins basically has a list of popular sites programmed in it, such as Facebook, Twitter, Google, etc. that offer a secure https connection. Whenever you visit one of those sites, it forces Firefox to use the secure connection instead of the standard (http) one. Https is a protocol that encrypts data between you and the website you’re interacting with. If you were wondering what the little “s” after http stands for, the answer is “secure” .

The only note I have about this is that one of the websites on that list is Netflix, and even though Netflix supports logging in securely, it doesn’t properly work when trying to manage your queue, so you may have to disable it just for that site. Other sites may exhibit problems as well, but I haven’t come across any of them yet.

2. NoScript

Easy of use: 4/5, Convenience: 3/5

This plugin is a lifesaver. Most malicious things on a website, whether it’s a fake security warning that your PC is infected or something that tries to hijack your browser, are created by using scripts, or more specifically, JavaScript. This add-on basically prevents all scripts from executing without explicit permission from you. The problem is, most websites use and rely on scripts. Scripts in themselves aren’t dangerous at all, they are quite useful, it just depends on what they do. So blocking all scripts on all websites is not the solution.

The purpose of the add-on is to block them by default and then you specifically allow the scripts you need. This sounds very complicated and it is at first, but after a while you’ll be able to recognize what seems legitimate and what not. My approach is this: I try to use a website the best I can without scripts. If something doesn’t work, I enable the most obvious ones first. If I’m on Yahoo!’s website for example, I’ll enable scripts from yahoo.com first, then try it again, and if it still doesn’t work, I’ll enable other scripts. I’ll probably have to create another post down the road that explains what the “other scripts” are in more detail.

In it’s most simplest form, if you don’ know anything about scripts, enable them all on the sites you trust, however, often you’ll find yourself googling a topic of interest and you may visit many unfamiliar and untrusted websites when following those search results. For those sites, always block all scripts. If the site doesn’t come up or something looks weird, leave the site and try another result.

3. Web of Trust (WOT)

Easy of use: 5/5, Convenience: 5/5

How great would it be to know whether a website is dangerous or not before you visit it? Imagine a little circle next to all links that could have one of three colors: green (this website is safe), yellow (this website may be suspicious), and red (this website is dangerous). Would be awesome, right? Well, someone’s thought of that.

I give you the Web of Trust add-on. That’s exactly what it does. With it installed, for example, you’ll see little colored circles on all the links in a Google search result and that will tell you whether you should go to that website or not. On top of that, even if you click on a website that doesn’t have a circle and it was rated dangerously or maybe it was red and you accidentally clicked it, an intermediate screen will appear asking you to confirm whether you really want to visit that website or not. The great thing is that WOT is community based, so it takes other people’s reviews in consideration when rating websites.

Sometimes sites aren’t rated (like this one here), which is indicated by a gray circle and a question mark. It’s up to you whether you want to visit it or try another site.

There you have it, the 3 best add-ons for Firefox in terms of security. If I missed something or there’s another great add-on you can recommend, leave it in the comments below.

-RS

1. ColorZilla

Purpose: This add-on adds a little eyedropper icon after your Firefox search bar. If you click it, you can sample any color on a webpage.

Usage: I use it to sample a color on a webpage and it automatically copies the hex value so I can use it in a stylesheet (CSS) file.

2. Firebug

Purpose: To inspect HTML, CSS, and JavaScript code on a webpage, view any connections that are initiated and their response, and see the variables currently loaded in the DOM. You can activate the window via the F12 key (Windows).

Usage: I mostly use it to inspect and manipulate elements on a webpage. For example, right-click anywhere and select “Inspect element”. Firebug will jump right to the code and you can alter the HTML on the left and the CSS on the right. This makes tweaking styles and duplicating content very easy. Furthermore, I use it to monitor AJAX responses on the “Net” tab, which tells me whether I get the expected results or not.

3. FireShot

Purpose: To take screenshots of a full, partial, or custom area on a webpage.

Usage: Often I’m asked to show a demo of a webpage in a meeting or perhaps a client is asking for it via email. FireShot adds a little bar in the status bar of Firefox, which gives me an icon to select either a full page screenshot (from top to bottom), a partial screenshot (anything that’s viewable without scrolling), or I can drag a custom rectangle over the area I want. I can then save the image or copy it to my clipboard.

4. Web Developer

Purpose: It lets you modify how your webpage will be rendered in your browser and provides tools to work with images and elements on a webpage.

Usage: This add-on does a lot, but I only use a subset of features. I use it for turning off JavaScript on a webapge (Disable > JavaScript > All), deleting or disabling cookies (Cookies > Disable Cookies > All Cookies), getting a div’s size (Information > Display Element Information… click on a page element), and to measure something on a webpage (Miscellaneous > Display Ruler… click and drag with mouse to create a box).

5. WorldIP

Purpose: Displays server’s location, IP address, provider, and your IP address.

Usage: I work with many different servers at a time and sometimes I move websites around. This little add-on tells me where the current website is located, its IP address, and who it’s hosted with. When I’m not using it for my stuff, I just find it interesting to see where everyone host’s their website .

There you have it, the 5 best Firefox add-ons for me in 2012. If you have something you use a lot that makes your life easier, feel free to share it in the comments below.

-RS

Here are some of the memory related bugs that were fixed:

• 669815 Type inference uses too much memory
• 646913 Massive memory usage when viewing www.cnn.com
• 678997 memory leak in widget/src/android/AndroidBridge.cpp
• 148636 Enormous memory usage rendering with lots of form elements
• 124608 Imagelib memory usage issues
• 503108 Memory usage climbs slowly but continuously on downloadstats.mozilla.com

-RS

1. Identify all areas that allow for user input. In other words, what can the user manipulate? It’s not necessarily just the form field you provided for them to fill out, but maybe a piece of data that you’re passing in via a query string, a hidden form field, or a browser header.
2. Determine what is valid input. The more specific you are in asking for a piece of data, the more granular you can be when it comes to validating. For example, instead of loosely asking for an address, you’d ask for the street, city, state, and zip code, which allows you to validate each piece of data separately.
3. Understand how you’re going to use that data. Whether you display it back on the screen, pass it to another program, or simply store it in a database, each application has its specific needs and requirements. For example, if you display data with HTML code on the screen, you won’t see the code, you’ll see the rendered version — which may or may not be desired — but if you’re storing this data in the database, you’d be OK.

After you’ve asked yourself those questions and thought about your data, you’ll have a good idea on where to start, but just knowing the concept won’t help you with implementation, so let’s take a closer look at each of these.

1. Identify all areas that allow for user input

There are a lot of places a user can change your data, so the best way to look at it is so: if you’re using a piece of data that you did not create and are not in control of every step of the way, you need to validate it. As a side note, filtering, validating, and escaping data are technically speaking three different things, but for simplicity sake, when I refer to validatation, I’m really refering to some or all of those aspects.

Let’s take a look at how you might receive user controllable data:

• Form fields: these are the most obvious of all, because you’re directly asking the user for data.
• Hidden form fields: even though the average user doesn’t see those fields, anyone can easily alter the contents of them. So make sure to double check that data before you use it and verify that your script gracefully halts if that piece of data is missing or invalid.
• Cookies: if you ever store data in a cookie, you need to double check that the value inside has not been altered and doesn’t contain anything that might cause your script to break.
• Query strings: if your application relies on reading information from the URL, you also need to check that the values you grab are valid. If you’re using a value as an ID number to make a database query, it’s a good idea to ensure that the value truly consists of digits.
• JavaScript: on occasion you may use JavaScript on your page to pass in a query string or POST data to your script, so keep that in mind before using that particular data.
• Browser headers: sometimes an application uses information from the user’s browser, such as the referer or user agent, so it’s important to remember that this data can be manipulated as well.
• Responses: if your script receives data from other applications or servers that you don’t control, that would also be considered user input. For example, maybe you’re parsing an RSS feed or work with JSON reponses.

Checking the above does several things for you:

• It reduces the risk of your application being used for illicit purposes e.g. compromising your database or sending spam email.
• It provides you with more control over the data that enters your system e.g. ensuring that a phone number is really a phone number.
• It allows you to be more efficient in processing the data e.g. if you look up a product in the database via its ID number, but you notice the ID number consists of letters as apposed to a number, there’s no need to make a database query in the first place.

2. Determine what is valid input

This is a pretty tricky subject, because if you’re too specific, you might miss a scenario where perfectly valid data is rejected, but if you’re too unrestrictive, you’ll get data that’s not useful. Some of the things you can control are the length of characters — you should always set a limit — ranges e.g. a number between zero and fifty, and their data type e.g. a number or a string. You can validate input by using some of PHP‘s built-in functions like is_int, ctype_alpha, ctype_alnum, or something more custom like a regular expression or a user-defined function.

In addition, there are two approaches to validating user input: inclusive and exclusive. Inclusive means that you specifically tell your application what is acceptable input, and exclusive let’s you specify the kind of data you don’t want.

An inclusive example would be to say that you want a number greater than zero, but less than fifty. You’re telling the system what to expect. The exclusive version would state that a number less than zero or greater than fifty is unacceptable. Here you told the system what to prevent. A different example would be checking that a phone number consists of only digits, parenthesis, or hyphens (inclusive) versus ensuring that the phone number doesn’t contain any letters or other symbols (exclusive).

Most of the time you’ll probably end up using a combination of the two, depending on whichever scenario is easier to test.

3. Understand how you’re going to use that data

Here are several ways your data can be used and what the best practices are for working with such data:

1. Database: if you’re planning on storing the data in a database, you need to escape it. Different database languages may have different ways of escaping, so pay attention to which one you’re using, but for MySQL, which is a popular and open source relational database management system (RDBMS), any data must pass through the mysql_real_escape_string() PHP function. It protects your database from injections.
2. Display: if you’re going to display user supplied data on your website, you should pass it through PHP’s htmlspecialchars() function. It protects your website from cross-site scripting (XSS).
3. URL: it’s possible that you need to send or save data from a user in the URL. If that’s the case, everything should pass through the urlencode() PHP function. This ensures that your URL remains valid.
4. Files: perhaps you’re saving information in a log file. Generally speaking, you can store it anyway you want, but if you know which method you’ll be using to read that data, you should store it accordingly. If the file’s contents will be displayed on the screen, use method #2 described above.
5. Transmission: sometimes you may be sending data from one server or application to another. You should validate your data before transmission appropriately and if you’re on the receiver’s end, you should validate it again to ensure that it hasn’t been modified somewhere in between. It’s similar to the concept of loose coupling, where each system is unaware of what the other system is doing, therefore you can’t assume that it has been validated on the other end.

The purpose of this article was to give you an idea of the methods, data, and its application in systems. There are exceptions to every rule, but now that you know what’s possible and how things are commonly utilized, you have the knowledge to take that and apply it to your own specific project.

If you have suggestions or questions, feel free to leave comments below.

-RS

I did a bit of research and it’s definitely a bug. There are at least four bug reports I could find on Google’s Android project:

1. 12282 IMAP email deletion not working
2. 13195 Certain emails reappear after deletion
3. 16293 IMAP does not work! — a little dramatic
4. 16484 Email client reload all previously deleted mail
   

From what I gather, most complaints are coming from Samsung users (tablet and phone), but I found a few users that reported a similar bug on the Motorola XOOM, which appears to have been resolved. What’s happening is that Android lost track of the folder that keeps your deleted messages, so when you delete something, it disappears momentarily on the screen, assuming that the command executed successfully, but since Android doesn’t know where to put that deleted message, it simply keeps it in the inbox. Then when you refresh your inbox to retrieve new messages, it shows back up.

So what can we do about this? There are three workarounds I currently know about.

1. Move your email message to the trash as apposed to using the delete button

This is probabaly the least convenient option, as it involves more steps, but it is the quickest to implement. When you’re looking at your list of emails, press the menu key and then the move to folder button. Select the messages you want to “delete” and click on the move to folder button. Then choose your folder, whether it’s trash (will be stored locally) or something like INBOX.Trash (will be stored in trash on server), and your message(s) will be moved.

2. Use another email client such as K-9 Mail (free)

You basically download an entirely different application and setup all your email accounts on it. The delete command has been confirmed working in K-9 according to users who have my phone and switched. This application is available for free in the Android market and seems the most recommended.

3. Root your phone and edit a database file

This is the only permanent solution that let’s you keep your stock email application, however, before you can edit this file your phone must be rooted, otherwise you don’t have access/permissions to do so. If you browse to /data/data/com.android.email/databases/EmailProvider.db on your phone and open this file with a text editor, you can edit your specific email account and reassign that folder. There are more details in a comment on Android’s project page that discusse another bug report called Email app doesn’t handle IMAP folder prefixes properly, but that same user recommended this fix for being able to delete your messages.

I personally will probably use the first method until I get a firmware update. If the issue then isn’t fixed, I’ll consider option #2 or #3.

If someone knows of another solution, I’d love to hear it! As always, feel free to leave comments below.

-RS

I’ve built a lot of forms in my day, and to be honest, it’s not one of my favorite things to do. The designing and building aspect is fun, but the validation and error reporting, ehh. We all know that server-side validation is a must, and technically speaking, client-side validation optional, but if you love your users, you’ll do it anyway. The challenge then for you, as the web developer, is to vigorously ensure that the client-side (jQuery) and server-side (PHP) validation are identical, so you don’t have discrepancies that confuse your users. The reason client-side validation makes users happy, is because the errors pop up right away and the page doesn’t need to be reloaded.

What if you could trade the pain of writing a client-side validation script with making  server-side validation instantaneous? Yes, AJAX comes to mind, however, the one thing people tend to do with that is display all the errors grouped together, because the AJAX response either updates or adds a div below or above the form, making the user have to figure out which error belongs to which field.

Project

The goal is to validate forms in the most efficient and user-friendly way, without having to compromise speed or security.

Requirements

• Completely omit client-side validation
• Display errors instantaneously next to corresponding fields
• Prevent the page from being refreshed

Solution

The user fills out a form and it gets submitted via jQuery. If the submission takes just a bit longer, a processing message will appear. A separate processing script will validate each field and upon error, store that error in an array using the field’s label as the array item’s key and the error as the array item’s value. At the end of the validation, it will send the form back by calling the form’s function — a user-defined PHP function — with the error array as an argument. jQuery then replaces the existing form on the page with a new form that displays the errors underneath each field. jQuery’s on event handler then ensures that the replaced form is re-submittable.

Implementation

Below is the user-defined PHP function that creates the HTML form:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

// Returns a login form
// @param (array) errors [optional]
// @return (string) login form
function getLoginForm($errors = false) {
  $output .= '<form action="#" name="login" method="post">';
    $output .= '<h2>Sign in to ' . APPNAME . '</h2>';
    $output .= '<div class="field">';
      $output .= '<label for="username">Username</label>';
      $output .= '<input type="text" id="username" name="username" autofocus="autofocus"' . getPostValue('username')  . ' />';
      if(isset($errors['username'])) {
        $output .= '<div class="help">' . $errors['username'] . '</div>';
      }
    $output .= '</div>';
    $output .= '<div class="field">';
      $output .= '<label for="password">Password</label>';
      $output .= '<input type="password" id="password" name="password"' . getPostValue('password')  . ' />';
      if(isset($errors['passsword'])) {
        $output .= '<div class="help">' . $errors['username'] . '</div>';
      }
    $output .= '</div>';
    $output .= '<div class="message"></div>';
    $output .= '<div class="button">';
      $output .= '<button type="button" name="commit" disabled="disabled">Login</button>';
    $output .= '</div>';
  $output .= '</form>';
  return $output;
}

// Returns a login form
// @param (array) errors [optional]
// @return (string) login form
function getLoginForm($errors = false) {
	$output .= '<form action="#" name="login" method="post">';
		$output .= '<h2>Sign in to ' . APPNAME . '</h2>';
		$output .= '<div class="field">';
			$output .= '<label for="username">Username</label>';
			$output .= '<input type="text" id="username" name="username" autofocus="autofocus"' . getPostValue('username')  . ' />';
			if(isset($errors['username'])) {
				$output .= '<div class="help">' . $errors['username'] . '</div>';
			}
		$output .= '</div>';
		$output .= '<div class="field">';
			$output .= '<label for="password">Password</label>';
			$output .= '<input type="password" id="password" name="password"' . getPostValue('password')  . ' />';
			if(isset($errors['passsword'])) {
				$output .= '<div class="help">' . $errors['username'] . '</div>';
			}
		$output .= '</div>';
		$output .= '<div class="message"></div>';
		$output .= '<div class="button">';
			$output .= '<button type="button" name="commit" disabled="disabled">Login</button>';
		$output .= '</div>';
	$output .= '</form>';
	return $output;
}

• On line 4 you see the optional argument. The variable is set to false so that PHP doesn’t complain when the function is called without a parameter.
• On line 6 I’m using a named constant to display what the user is logging into. You could replace that with static text.
• On line 9 I have another custom function called getPostValue() that basically escapes the user’s input before displaying it inside the field.
• On line 10 we’re checking to see whether an array item with a key, that matches the field’s label, exists. If it does, we know to display an error, if not, that whole help div container is omitted.

Here is how the rendered form looks like in HTML:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

<div class="init">
  <form action="#" name="login" method="post">
    <h2>Sign in to SME</h2>
    <div class="field">
      <label for="username">Username</label>
      <input type="text" id="username" name="username" autofocus="autofocus" />
    </div>
    <div class="field">
      <label for="password">Password</label>
      <input type="password" id="password" name="password" />
    </div>
    <div class="message"></div>
    <div class="button">
      <button type="button" name="commit" disabled="disabled">Login</button>
    </div>
  </form>
</div>

<div class="init">
	<form action="#" name="login" method="post">
		<h2>Sign in to SME</h2>
		<div class="field">
			<label for="username">Username</label>
			<input type="text" id="username" name="username" autofocus="autofocus" />
		</div>
		<div class="field">
			<label for="password">Password</label>
			<input type="password" id="password" name="password" />
		</div>
		<div class="message"></div>
		<div class="button">
			<button type="button" name="commit" disabled="disabled">Login</button>
		</div>
	</form>
</div>

• On line 1 we need to wrap the form in a div, so we can later monitor it with jQuery. What happens is that jQuery will replace the entire form with one that shows the errors. Because that new form is a new object to the page, jQuery doesn’t know about it. It needs a fixed element on the page, such as the init div, whose contents it can monitor.
• On line 2 you’ll notice that the action attribute is empty. This particular project requires users to have JavaScript turned on, but if you expect users without JavaScript, it’s a good idea to enter the path of the processor,.
• On line 12 we will show a message to the user when the button gets clicked, so they know the form is processing.
• On line 14 you’ll notice that I used the button tag to render a button as apposed to the classic <input type=”submit”>. I do that simply so I can style my text fields without having to worry that it will affect my buttons. My button is by default disabled and I then enable it with JavaScript, that way if JavaScript is turned off, the form can’t be submitted. Lastly, my button is of type=”button”, which by default doesn’t do anything (I assign an event handler with jQuery later). You’d make it of type=”submit” if you wanted that button to work without JavaScript.

Below is the jQuery that is in charge of submitting the form:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

$(document).ready(function(){
 
  initBinding();
 
  // Send any form to its specific processor
  $('body').on('submit', 'form', function(e){
    var form = $(this);
    form.find('button[name=commit]').attr('disabled', 'disabled');
    form.find('.message').delay(100).queue(function() {
      $(this).html('<div class="pending">Sending your request... please wait...</div>');
    });
    $.post('process.php?p=' + form.attr('name'), form.serialize(), function(response) {
      form.parent('div').html(response);
      initBinding();
    });
    e.preventDefault();
  });
 
  function initBinding() {
    // Enable the form's submit button and assign event handler
    $('button[name=commit]').removeAttr('disabled').click(function() {
      $(this).trigger('submit');
    });
  }
 
});

$(document).ready(function(){

	initBinding();

	// Send any form to its specific processor
	$('body').on('submit', 'form', function(e){
		var form = $(this);
		form.find('button[name=commit]').attr('disabled', 'disabled');
		form.find('.message').delay(100).queue(function() {
			$(this).html('<div class="pending">Sending your request... please wait...</div>');
		});
		$.post('process.php?p=' + form.attr('name'), form.serialize(), function(response) {
			form.parent('div').html(response);
			initBinding();
		});
		e.preventDefault();
	});

	function initBinding() {
		// Enable the form's submit button and assign event handler
		$('button[name=commit]').removeAttr('disabled').click(function() {
			$(this).trigger('submit');
		});
	}

});

• On line 3 I’m calling a function that enables my disabled submit button and assigns a click event to it, so it can submit the form, since my button doesn’t natively do that.
• On line 6 we’re using jQuery’s on event handler, which basically monitors the HTML body and looks for changes in a form element. This is important so that the form can be resubmitted. When the form gets replaced, it’s an unknown object on the page, however, since jQuery is monitoring it, it will convert the newly replaced form to a submittable form.
• On line 8 I’m disabling the button, so while the form is processing, it can’t be submitted a second time.
• On line 9 you’ll notice that we delay the “processing” message slightly, because if it submits right away, there’s no reason to flash it on the screen, but if it takes a bit longer, the user should know that something is happening.
• On line 12 is where we actually post the form. I’m sending it to process.php, which contains a switch control structure that receives the form attribute’s name, so that the processor knows which fields to expect and validate.
• On line 14 I’m calling initBinding() again, so that the newly replaced form’s submit button will be re-enabled and can submit again.

Conclusion

You get an easily maintainable and secure form for which you don’t have to write any client-side validation. The form is submitted via jQuery, which doesn’t require the page to be reloaded, and the validation appears almost instantaneous to the user, just as if you had used client-side validation.

If you have any questions or suggestions, please feel free to leave comments below.

-RS