WP-Members

WP-Members is a free member management system. It is based on giving site administrators the ability to block and unblock posts and pages from public viewing. For example, blocked pages are only viewable to members, while unblocked pages are viewable by the general public. Unlike many other membership plugins, WP-Members has a registration system included which does not require rerouting users through the generic WordPress log-in page. Thus, your users stay within your custom theme, resulting in a simplified experience. It is important to note, though, that since the plugin is free you will not be be provided with the support options or increased functionality that typically comes with paid, licensed plugins. An example of this is WP-Members lack of support for paid memberships.

s2 Membership

By implementing the s2 Membership plugin to your site, you add the capability of making specific post/pages available only through “Buy Now” access. Some particularly nice features of s2 include its ability to integrate with BuddyPress, protect downloadable files, provide streaming audio/video, and offer paid memberships through standard PayPal. The s2 Membership plugin is free, but there is an add-on module available called s2 Membership Pro. This module adds:
• PayPal Pro
• PayPal
• Pro Form Generators
• Authorize.net AIM/ARB integration
• Pro Form coupon codes
• Unlimited membership levels
• Custom “Thank You” pages.

There are two different levels of pricing for the Pro module. A single site license is $69, while an unlimited license is $129. Note that the “unlimited” site license is NOT a developer’s license where you can re-use the plugin again and again… It is only intended as being “unlimited” for those with multiple domains.

MagicMembers

MagicMembers is a robust member management system capable of:
• Unlimited membership levels
• Complete control of members billing
• Integration with most major ecommerce gateways (view the complete list »)
• Download management
• Guest purchases
• Auto responder integration with AWeber, GetResponse, Constant Contact, iContact, Auto Response Plus and MailChimp

Two particularly unique features of this plugin include the ability to “drip feed” content to users (the ability for administrators to set an amount of time when certain content is viewable) and help desk support Monday-Friday.

The pricing for the MagicMembers plugin is $97 for a single license and $297 for an unlimited license. However, this unlimited license IS a true developer’s license and allows for multiple installations on different sites.

Your Members

The Your Members plugin includes much of the functionality listed with the plugins above, including:

• Members import/export
• Time limited posts
• WordPress role levels
• Custom login/registration pages
• Member management
• Coupons and discounts
• Mail manager integration with AWeber integration, Campaign Monitor, and more
• Amazon S3 and Cloudfront integration for protection of downloadable and streaming content
• Dime sales, fire sales and other limited offers (with the addition of the Adaptive Pricing Module)

This plugin also has the following payment gateways integrated:
• PayPal
• Authorize.net
• WorldPay
• Click Bank
• and more.

Your Members offers four pricing packages, each of which give additional amounts of functionality:
• Starter $95
• Basic $115
• Pro $150
• Ultimate $300

The Ultimate package’s high cost is due to it being a true developer’s license, providing unlimited installs. Regardless, each license gets one year of free upgrades with a “small” fee beyond the first year. This support is offered through the forums on the developer’s website. However, with the purchase of a Pro or Ultimate license you also get “premium” support for the first year. With premium support you get the following coverage:
• Notification of Upgrades
• Priority of Upgrades
• Premium content guides and articles
• Private Forums Access
• Free Site Doctor Audit (essentially one of the developers of the plugin will look at your site and give you a short report on the functionality of the entire site.)

There is additional coverage that can be purchased. The price is based three levels of support and on how many contacts (per seat) that will be using the support. The following is the pricing for the different packages:
• Basic ($30/quarter per seat)
• Developer ($200/year per seat)
• Enterprise ($1000/year per seat)

WishList Member

The Wishlist Member plugin also has a long list of features:
• Unlimited Membership Levels
• Sequential Content Delivery
• Content view controls
• Member management
• Shopping cart integration with PayPal, Click Bank (and more)

However, the lack of Authorize.net integration is a bit dumbfounding though and is a serious set-back for this plugin. It can be integrated into the plugin non-natively, yet even this is quite a pain to maintain.

The purchase price is $97 for a single license and $297 for unlimited domains. Much like the s2 Membership, this unlimited license is NOT a developer’s license. It is only intended for those with multiple domains or servers, not separate sites.

As a developer you do have the option to purchase a commercial license, priced at $300 for 5 sites and $500 for 10 sites. Support is carried out through submitting a support request ticket, with 1 year of unlimited upgrades and support.

WRAP UP

After going through membership-related plugins, we were taken aback by the hidden costs of some of them. It further reinforces the need to always read the fine-print before purchasing a plugin.

When looking for the perfect membership plugin for your site, it is best to evaluate the needs of your site along with whatever future membership functionality for which it may call. There is no single answer for what the “best” membership plugin is… It is truly a matter of the “best” plugin for the job.

In the article below, we will review the following:

• What are the market share statistics for web browsers?
• What are the most common screen and resolution sizes of those that view the web?
• What do recent statistics say about platform/device market share?
• What does this mean for web developers

NOTE: All data is current as of May 2012. Unless indicated, all statistics were collected via w3schools.com. If you are a mobile-first advocate, none of this should matter anyway.

WEB BROWSER MARKET SHARE
Ahhh, web browsers. Performing cross-browser compatibility checks are always listed among web developers as a favorite past-time activity… Right along with watching Dora the Explorer and listening to the latest boy-band sensation. Yet, as many things in life – Justin Bieber excluded – testing your site within major browsers is a necessary evil.

So, where do we stand when it comes to browser market share? Which browsers can we finally let go of, and which do we need to pay special attention to?

 What You Need To Know:

• Chrome now leads browser market share by a single percentage point over Firefox.
• Chrome and Firefox together make up 73.6% of all web browsers in use today.
• Of Chrome’s 37.3% market share, 31.9% can be attributed to Chrome 17 users. All other versions combine for only 5.4%.
• Of Firefox’s 36.3% market share, 24.2% can be attributed to Firefox 10 and 11 users. All other versions combine for only 12.1%.
• IE is down to a 18.9% market share (hooray!).
• IE 8 and 9 account for 15.5% of IE’s 18.9% market share. IE 6 and 7 are virtually unused.

WEB USER SCREEN & RESOLUTION SIZE
Remember when web developers only had to worry about 3 screen sizes (1024×768, 800×600, 640×480)? Well, those days are long gone.

 What You Need To Know:

• 98% of web users are viewing sites on screens with a resolution of 1024×768 or above.
• Only 1.4% of web traffic come from mobile devices.

PLATFORM & DEVICE SPECIFIC MARKET SHARE
As most web developers know, testing a site only on a Mac and a PC will no longer cut it. Not only are there multiple operating systems on both platforms, but there are hundreds of mobile devices thrown into the mix. From iPhones to iPads and from Androids to Blackberries, these devices range not only in their screen size, but also in their individual capabilities.

Let’s return to the statistics one final time:

 What You Need To Know:

• The iPhone and iPad make up .74% of device traffic, while Android only accounts for .44%.
• Yet, major research indicates that by 2014, global internet usage will be done via mobile devices, not desktop devices.

THE BOTTOM LINE
Simply put, the web landscape is a mess. Just when “desktop” computer users finally begin to eclipse the standard 1024×768 screen resolution, screens size suddenly are predicted to become irrelevant. And just when we get past old version of IE and Netscape, Chrome and Firefox’s combined 31 browser versions take over the majority of web browsing.

Whether you are a proponent of mobile first or responsive web design, only one thing is clear: Building for only one or two screen sizes and platforms will soon (if not already) be a huge mistake. It is time for web developers, site administrators, and business owners to begin putting together a device agnostic web strategy or be left behind in the near future.

At Malphurs Interactive, we develop a ton of mobile sites. Without a doubt, one of the most common requests we receive is to implement a “View Full Site” link into a client’s mobile site.

Redirecting mobile users from a “desktop” site to a mobile-friendly site is actually quite easy. Simply embed the following code between the opening and closing head tags of your “desktop” (non-mobile) website:

<script language="javascript" type="text/javascript">
function detectMobileAndRedirect(a,b){

if(/android|webOS|avantgo|blackberry|blazer|elaine|hiptop|ip(hone|od)|kindle|midp|mmp|mobile|o2|opera mini|palm( os)?|pda|plucker|pocket|psp|smartphone|symbian|treo|up\.(browser|link)|vodafone|wap|windows ce; (iemobile|ppc)|xiino/i.test(a)||/1207|6310|6590|3gso|4thp|50[1-6]i|770s|802s|a wa|abac|ac(er|oo|s\-)|ai(ko|rn)|al(av|ca|co)|amoi|an(ex|ny|yw)|aptu|ar(ch|go)|as(te|us)|attw|au(di|\-m|r |s )|avan|be(ck|ll|nq)|bi(lb|rd)|bl(ac|az)|br(e|v)w|bumb|bw\-(n|u)|c55\/|capi|ccwa|cdm\-|cell|chtm|cldc|cmd\-|co(mp|nd)|craw|da(it|ll|ng)|dbte|dc\-s|devi|dica|dmob|do(c|p)o|ds(12|\-d)|el(49|ai)|em(l2|ul)|er(ic|k0)|esl8|ez([4-7]0|os|wa|ze)|fetc|fly(\-|_)|g1 u|g560|gene|gf\-5|g\-mo|go(\.w|od)|gr(ad|un)|haie|hcit|hd\-(m|p|t)|hei\-|hi(pt|ta)|hp( i|ip)|hs\-c|ht(c(\-| |_|a|g|p|s|t)|tp)|hu(aw|tc)|i\-(20|go|ma)|i230|iac( |\-|\/)|ibro|idea|ig01|ikom|im1k|inno|ipaq|iris|ja(t|v)a|jbro|jemu|jigs|kddi|keji|kgt( |\/)|klon|kpt |kwc\-|kyo(c|k)|le(no|xi)|lg( g|\/(k|l|u)|50|54|e\-|e\/|\-[a-w])|libw|lynx|m1\-w|m3ga|m50\/|ma(te|ui|xo)|mc(01|21|ca)|m\-cr|me(di|rc|ri)|mi(o8|oa|ts)|mmef|mo(01|02|bi|de|do|t(\-| |o|v)|zz)|mt(50|p1|v )|mwbp|mywa|n10[0-2]|n20[2-3]|n30(0|2)|n50(0|2|5)|n7(0(0|1)|10)|ne((c|m)\-|on|tf|wf|wg|wt)|nok(6|i)|nzph|o2im|op(ti|wv)|oran|owg1|p800|pan(a|d|t)|pdxg|pg(13|\-([1-8]|c))|phil|pire|pl(ay|uc)|pn\-2|po(ck|rt|se)|prox|psio|pt\-g|qa\-a|qc(07|12|21|32|60|\-[2-7]|i\-)|qtek|r380|r600|raks|rim9|ro(ve|zo)|s55\/|sa(ge|ma|mm|ms|ny|va)|sc(01|h\-|oo|p\-)|sdk\/|se(c(\-|0|1)|47|mc|nd|ri)|sgh\-|shar|sie(\-|m)|sk\-0|sl(45|id)|sm(al|ar|b3|it|t5)|so(ft|ny)|sp(01|h\-|v\-|v )|sy(01|mb)|t2(18|50)|t6(00|10|18)|ta(gt|lk)|tcl\-|tdg\-|tel(i|m)|tim\-|t\-mo|to(pl|sh)|ts(70|m\-|m3|m5)|tx\-9|up(\.b|g1|si)|utst|v400|v750|veri|vi(rg|te)|vk(40|5[0-3]|\-v)|vm40|voda|vulc|vx(52|53|60|61|70|80|81|83|85|98)|w3c(\-| )|webc|whit|wi(g |nc|nw)|wmlb|wonu|x700|xda(\-|2|g)|yas\-|your|zeto|zte\-/i.test(a.substr(0,4))){

if(/ipad/i.test(a)){

return false;

}

location.href=b;

}

}

var mobilesite = "http://YourMobileSite.com/";

detectMobileAndRedirect(navigator.userAgent||navigator.vendor||window.opera,mobilesite);

</script>

Within the script above, simply edit…

 var mobilesite = "http://YourMobileSite.com/"; 

… to point to your mobile site location and you’re good to go.

But, what if we want to do the opposite? What if we want to redirect mobile users to a “desktop” site with a “View Full Site” link? If we create such a link and simply link it back to the “desktop” site, the mobile user will just hit the mobile redirect script again and be sent right back to the mobile site. NOT what we intended.

This is a tricky problem to solve. The answer lies in a mix of javascript, cookies, and good old fashioned linking fun! So, lets get going.

Step 1 – The Javascript
Start by copying the following code:

<script type="text/javascript">

function setCookie(c_name, value, exdays) {

c_name = c_name.toLowerCase();

var exdate = new Date();

exdate.setDate(exdate.getDate() + exdays);

var c_value = escape(value) + ((exdays == null) ? "" : "; expires=" + exdate.toUTCString());

document.cookie = c_name + "=" + c_value;

}

function getCookie(c_name) {

c_name = c_name.toLowerCase();

var i, x, y, ARRcookies = document.cookie.split(";");

for (i = 0; i < ARRcookies.length; i++) {

x = ARRcookies[i].substr(0, ARRcookies[i].indexOf("="));

y = ARRcookies[i].substr(ARRcookies[i].indexOf("=") + 1);

x = x.replace(/^\s+|\s+$/g, "");

if (x == c_name) {

//alert("x = " + x);

return unescape(y);

}

}

}

function getQuerystring(key, default_) {

key = key.toLowerCase();

//alert("key : " + key);

//alert("default_ : " + default_);

if (default_ == null) default_ = "";

key = key.replace(/[\[]/, "\\\[").replace(/[\]]/, "\\\]");

var regex = new RegExp("[\\?&]" + key + "=([^&#]*)");

var qs = regex.exec(window.location.href.toLowerCase());

if (qs == null) {

//alert("default_ : " + default_);

return default_;

}

else {

//alert("qs[1] : " + qs[1]);

return qs[1];

}

}

function detectMobileAndRedirect(a,b){

// alert(location.href);

if(/android|webOS|avantgo|blackberry|blazer|elaine|hiptop|ip(hone|od)|kindle|midp|mmp|mobile|o2|opera mini|palm( os)?|pda|plucker|pocket|psp|smartphone|symbian|treo|up\.(browser|link)|vodafone|wap|windows ce; (iemobile|ppc)|xiino/i.test(a)||/1207|6310|6590|3gso|4thp|50[1-6]i|770s|802s|a wa|abac|ac(er|oo|s\-)|ai(ko|rn)|al(av|ca|co)|amoi|an(ex|ny|yw)|aptu|ar(ch|go)|as(te|us)|attw|au(di|\-m|r |s )|avan|be(ck|ll|nq)|bi(lb|rd)|bl(ac|az)|br(e|v)w|bumb|bw\-(n|u)|c55\/|capi|ccwa|cdm\-|cell|chtm|cldc|cmd\-|co(mp|nd)|craw|da(it|ll|ng)|dbte|dc\-s|devi|dica|dmob|do(c|p)o|ds(12|\-d)|el(49|ai)|em(l2|ul)|er(ic|k0)|esl8|ez([4-7]0|os|wa|ze)|fetc|fly(\-|_)|g1 u|g560|gene|gf\-5|g\-mo|go(\.w|od)|gr(ad|un)|haie|hcit|hd\-(m|p|t)|hei\-|hi(pt|ta)|hp( i|ip)|hs\-c|ht(c(\-| |_|a|g|p|s|t)|tp)|hu(aw|tc)|i\-(20|go|ma)|i230|iac( |\-|\/)|ibro|idea|ig01|ikom|im1k|inno|ipaq|iris|ja(t|v)a|jbro|jemu|jigs|kddi|keji|kgt( |\/)|klon|kpt |kwc\-|kyo(c|k)|le(no|xi)|lg( g|\/(k|l|u)|50|54|e\-|e\/|\-[a-w])|libw|lynx|m1\-w|m3ga|m50\/|ma(te|ui|xo)|mc(01|21|ca)|m\-cr|me(di|rc|ri)|mi(o8|oa|ts)|mmef|mo(01|02|bi|de|do|t(\-| |o|v)|zz)|mt(50|p1|v )|mwbp|mywa|n10[0-2]|n20[2-3]|n30(0|2)|n50(0|2|5)|n7(0(0|1)|10)|ne((c|m)\-|on|tf|wf|wg|wt)|nok(6|i)|nzph|o2im|op(ti|wv)|oran|owg1|p800|pan(a|d|t)|pdxg|pg(13|\-([1-8]|c))|phil|pire|pl(ay|uc)|pn\-2|po(ck|rt|se)|prox|psio|pt\-g|qa\-a|qc(07|12|21|32|60|\-[2-7]|i\-)|qtek|r380|r600|raks|rim9|ro(ve|zo)|s55\/|sa(ge|ma|mm|ms|ny|va)|sc(01|h\-|oo|p\-)|sdk\/|se(c(\-|0|1)|47|mc|nd|ri)|sgh\-|shar|sie(\-|m)|sk\-0|sl(45|id)|sm(al|ar|b3|it|t5)|so(ft|ny)|sp(01|h\-|v\-|v )|sy(01|mb)|t2(18|50)|t6(00|10|18)|ta(gt|lk)|tcl\-|tdg\-|tel(i|m)|tim\-|t\-mo|to(pl|sh)|ts(70|m\-|m3|m5)|tx\-9|up(\.b|g1|si)|utst|v400|v750|veri|vi(rg|te)|vk(40|5[0-3]|\-v)|vm40|voda|vulc|vx(52|53|60|61|70|80|81|83|85|98)|w3c(\-| )|webc|whit|wi(g |nc|nw)|wmlb|wonu|x700|xda(\-|2|g)|yas\-|your|zeto|zte\-/i.test(a.substr(0,4))){

if(/ipad/i.test(a)){

return false;

}

location.href=b;

}

}

function removeQueryString(url) {

return url.split("?")[0];

}

var FullSiteCookie = getCookie("viewFullSite");

var viewFullSite = getQuerystring("viewFullSite");

var renderFullSite = new Boolean();

renderFullSite = false;

if (FullSiteCookie != null && FullSiteCookie != "") {

if (FullSiteCookie.toLowerCase() == "true") {

if (viewFullSite.toLowerCase() == "false") {

setCookie("viewFullSite", false, 1);

}

else {

renderFullSite = true;

//alert("Set 11");

}

}

else {

if (viewFullSite != null && viewFullSite != "") {

if (viewFullSite.toLowerCase() == "true") {

renderFullSite = true;

//alert("Set 2");

setCookie("viewFullSite", true, 1);

}

else {

if (viewFullSite.toLowerCase() == "false") {

setCookie("viewFullSite", false, 1);

}

renderFullSite = false;

//alert("Set 3");

}

}

else {

renderFullSite = false;

//alert("Set 4");

}

}

}

else {

viewFullSite = getQuerystring("viewFullSite");

//alert("viewFullSite 1 : " + viewFullSite);

if (viewFullSite != null && viewFullSite != "") {

if (viewFullSite.toLowerCase() == "true") {

renderFullSite = true;

//alert("Set 5");

setCookie("viewFullSite", true, 1);

}

else {

renderFullSite = false;

//alert("Set 6");

}

}

else {

renderFullSite = false;

//alert("Set 7");

}

}

//alert("renderFullSite : " + renderFullSite);

if (!renderFullSite) {

//alert("location href before: " + location.href);

var mobilesite = "http://YourMobileSite.com";

var locationhref = removeQueryString(location.href);

//alert("location href after: " + locationhref);

if (locationhref == "http://YourSite.com") {

mobilesite = "http://YourMobileSite.com/index.php";

}

detectMobileAndRedirect(navigator.userAgent || navigator.vendor || window.opera, mobilesite);

}

function BookMark() {

$('#BookmarkImg').animate({ "top": "-81px" }, 1000);

baseCookieName = "rwbookmark";

var exdate = new Date();

var expiredays = "1";

exdate.setDate(exdate.getDate() + expiredays);

//use of arbritary stop point so no endless loop occurs

for (var i = 0; i < 10000; i++) {

var curName = baseCookieName + i;

if (document.cookie.indexOf(curName) < 0) {

document.cookie = curName + "=" + escape(window.location.href) + "[#]contentid=" + document.getElementById("inputContentID").value + "[#]title=" + GetPageTitle() + ";expires=" + exdate.toGMTString() + ";path=/;domain=YourSite.com;";

break;

}

}

var link = document.getElementById('BookmarkLink');

link.onclick = null;

link.style.cursor = "default";

}

function GetPageTitle() {

var titlefromdom = "";

var titlefromdomarray = "";

$(document).ready(function() {

titlefromdom = document.title;

});

titlefromdomarray = titlefromdom.split("|");

if (titlefromdomarray.length > 0) {

titlefromdom = titlefromdomarray[titlefromdomarray.length - 1];

}

return titlefromdom;

}

</script>

Now, place this in your favorite text editor so we can edit it as needed.

Step 2 – Customizing the Javascript
Now that we have the script, we need to customize it in several different areas by setting the:

1. Mobile site location
2. Non-mobile, “desktop” site location
3. Cookie duration
4. Desktop domain name

Begin by looking for line 215:

var mobilesite = "http://YourMobileSite.com";

Set this variable to your mobile site location.

Next, further down the page find line 221:

if (locationhref == "http://YourSite.com")

Set this to be the location of your “desktop” site. (This is the site where you want your mobile visitors to go when they click “View Full Site”.)

The next line (223) contains the following code:

mobilesite = "http://YourMobileSite.com/index.php";

Again, change this to be the location of your mobile site.

Third, look on line 239 for:

var expiredays = "1";

This is the length of time the cookie we set with the script will last. In other words, this is the number of days the mobile visitor will see the “desktop” site instead of the mobile site when viewing it on their mobile device. You can set this to any amount of time, though we typically stick with 1 day.

Finally, look on line 251 for our last domain name change:

document.cookie = curName + "=" + escape(window.location.href) + "[#]contentid=" + document.getElementById("inputContentID").value + "[#]title=" + GetPageTitle() + ";expires=" + exdate.toGMTString() + ";path=/;domain=YourSite.com;";

Simply change “domain=YourSite.com” to your desktop site’s domain.

Step 3 - Putting it all together
Everything is easy from here on out… Simply take the javascript we created and place it between the head tags of your entire "desktop" site.

Then, to complete the process, add the "View Full Site" link to your mobile site page(s):

<a href="http://www.YourSite.com/?ViewFullSite=true">View Full Site</a></p>

The important thing to note here is the ?ViewFullSite=true piece of code. This is necessary to add to your link because it is what the javascript will look for to ensure your mobile visitors get sent to the "desktop" site instead of the mobile one.

Volia! You're done.

Bonus Tip
Want to link to specific pages on your "desktop" site? Simply add ?ViewFullSite=true after the link to the page. For example:

<a href="http://www.YourSite.com/AboutUs.php?ViewFullSite=true">View Full About Us Page</a></p>

Now, you can have any mobile page on your site link to its corresponding "desktop" version.

Conclusion
We hope that the mobile redirect script detailed above helps you on your next mobile project. Considering the number of times we have used this handy piece of code, you should have no problem making use of it when your client asks for "View Full Site" functionality!

1) Install WP Security Scan

WP Security Scan is a great plug-in that scans and verifies the vulnerabilities of your WordPress install. As the name implies, it will scan your installation and give you suggestions of security measures to take in order to secure your site. Some examples of suggestions that the plug-in makes include:

a) Name your database using a prefix other than “wp_”

With this being the default prefix it makes it easier for a hacker to plan a massive attack on the database. This suggestion can actually be done right with the plugin. But, note that it can also be done from the beginning of development. For example, when you first install WordPress and are setting up the wp-config file, the installer gives you an option of what prefix you would like to use for the database files. Doing so then will keep you from having to worry about doing it later!

b) Do not use “admin” for the administrator username

When a hacker is attempting to access your site, the first username they will go after is the oft-used ”admin”. So, using a different username for the administrator only makes it harder for the person that is trying to compromise your site. Simple, but effective.

c) Create additional .htaccess files

Another level of protection can be added through implementation of a .htaccess file within your wp-admin and wp-content directory (within the WordPress installation). This provides another level of security to the files that are often used to gain the information that provides additional access to other areas of your site.

For further reading, here is a great resource for creating strong .htaccess files for an Apache server.

2) Backup, Backup, Backup

WordPress security arsenal is the ability to backup your site files and database(s). If your site gets taken down, this will act as your life preserver and allow you to bring the majority of the site files back to life. The plug-in we prefer to use is BackUpWordPress. This nifty tool creates a backup of a site’s files, code and database. And, it even allows you to schedule the frequency of the backups within the plug-in’s settings panel.

3) Limiting Log-in Attempts

When a hacker is trying to access your site one of the ways to gain access is by guessing your password. Possibly using a script to guess your password. Through limiting the login attempts this will lock out whoever enters the wrong password a specified amount of times and will also be locked out for a specified time. This can be done by installing the Limit Login Attempts plugin. You can access the Settings in the WordPress admin and fill out how many attempts you want to allow and how long the lock out should be. These is just a few of the settings available with this plugin.

Wrap Up

These are just a few techniques that can be used to defend a WordPress site from an attack. Malphurs Interactive is continuously looking for ways to better secure sites that we develop, and subsequently apply these techniques to the sites we have already developed. As the WordPress community continues to grow, there will be more opportunities for attack. Yet, there will also be even better security measures to implement. We hope that the tips presented help you develop more secure custom WordPress sites and avoid the headaches a hacked site can bring.

So, when should we start developing for this new model and what should we pay particular attention to? Lets take a deeper look.

The Adoption Rate
One of the first questions we come to is when we should begin building (or upgrading) our iPad apps to be optimized for the new version of the iPad. By looking at the latest data, the adoption rate for the latest iPad model makes up 8% of the total iPad market. This is a small, yet telling number. Considering that the iPad was released only in mid-March, this is actually a stunningly fast adoption rate.

Add to this that sales currently show no signs of slowing (just try to get one on – or at -  the Apple Store), it is safe to say that we will see at least a quarter of the iPad market consist of the newest version by summer. This data makes it clear that it is indeed time to consider building and optimizing apps for the new iPad.

The Resolution
Now that we know that we should be looking to build for the new device, what exactly does that mean? We could – of course – take advantage of the nice upgrade in processor. But, unless you are really wanting to slow things down for users of earlier iPad models, it is best to play it safe and develop with the previous generation of devices in mind.

Thus, the biggest area change comes in developing for the device’s new retina display. Whereas before we could safely build for 1024×768 at 72 dpi, we now must move up to a staggering 2048×1536 at 264 dpi. This means your projects will grow an average of 3x the size of which you are accustomed.

Complicating things, should you choose to work at the higher resolution of the new device, be weary of making the app universal. By doing so, you will now be generating 3 different files for the same image:

• 1 for the newest iPad
• 1 for older iPads
• 1 for misc. smartphone devices

Fear not, though… If you choose not to develop for the higher resolution yet, iOS 5,1 will scale your app up to the new resolution. The tradeoff? Your graphics will get a little washed out and a bit fuzzy.

The Icons
So, what else does this resolution change entail? For starters, you now must create higher resolution icons. The following is a run down of mandatory sizes for each icon in order for your app to be “retina display compliant”:

• Application icon: 144 x 144
• App Store icon: 1024 x 1024
• Launch Image: 1536 x 2008 (portrait) / 2048 x 1496 (landscape)
• Spotlight Search icon: 100 x 100
• Settings icon: 58 x 58
• Toolbar, Navigation and Tab Bar icons: 40 x 60

Note that Apple has some great tips for creating resizable images. You can read more about them on the iOS developer site. This great resource will help make the process of creating your app’s icons much more manageable.

There is no doubt that there are many other changes in store for those of us who develop for the new iPad. But, by optimizing your graphics and icons, you will also be taking a great step forward in optimizing the app experience for millions of users. And, maybe, just maybe making it into the new “Great Apps for the New iPad” category of the App Store!

OVERVIEW

At Malphurs Interactive, we recently we came upon an issue that required a bit of innovation. How can an animation show no matter what device is being used to view it? Flash is nice, yet is incompatible with many mobile devices and tablets. HTML5 is sweet, but only shows on the most modern of browsers. Is there a happy medium? After much discussion, we determined we needed a solution that would display our animation regardless of which browser or device is being used… New or old… Mobile or “desktop”.

THE STRATEGY

We decided that our strategy would be to offer Flash first. If the device being used to view the page does not support Flash, it would fall back to HTML5. If neither are supported, a simple image is displayed so at least something will appear for the user.

Upon our initial search we could find no such solution. We did find many examples of Flash to HTML5 video fallbacks, but nothing that involved taking an animation and allowing it to degrade gracefully from Flash to HTML5 and then to a static image. So, we created our own solution, one which involves the following steps:

• Create a Flash animation
• Convert the Flash into an HTML5 animation
• Place the HTML5 scripts and animation within an HTML document
• Place the Flash scripts and animation within an HTML document
• Tell the browser which to play

The following details each step.

1) Create the Animations

Our initial animation was quite complex and – out of necessity – created in Flash. But, knowing that Flash support is waning and incompatible with many mobile devices, we converted our Flash animation into an HTML5 animation using Google swiffy. When doing such a conversion, it is important that the swiffy guidelines are strictly followed. Pay particular attention that:

• the file is a subset of SWF 8
• all scripting is done using ActionScript 2.0

(There are more detailed guidelines documented on the Google swiffy site.)

You may use another method to get your HTML5 animation, but the steps should still be similar to those detailed here.

2) Implement the HTML5 Code

At this point, we have a Flash SWF and an HTML5 document containing the animation. We will be using the code from within this HTML5 document quite often, so keep it handy. So, onto our next step… implementing the HTML5 animation and its code.

Begin by creating a new HTML5 document. Paste the following lines of code within the <head> tags of this document:

<script type="text/javascript" src="http://www.gstatic.com/swiffy/v4.0/runtime.js"></script>

This code is the javascript Google provides in order to run swiffy created animations. We could download this file and link to it locally, but swiffy is a beta product and is updated quite often. So, by linking to it directly, we ensure we are always using the newest version available. Be sure to take the time to save and name the document as needed. For this article, we will refer to this page as “animation.html”.

Next, we need to display the actual HTML5 animation itself. Looking at the animation’s code, it is quite long and complex. Instead of directly embedding the animation, lets keep our code clean by placing this long code into a separate file. We can then simply call it from within the animation.html document. Do so by going back to the HTML5 file that swiffy produced from our original Flash file. Look for the script we used in step 2. Directly below that is the script and code we need. Copy this entire script, ensuring you get everything between the opening and closing script tags. Then, create a new blank document and paste the script within. Save the file as a javascript document (such as “animation.js”) and call it from within the <head> of animation.html:

<script src="http://www.mysite.com/js/animation.js" type="text/javascript"></script>

As with all such examples in this article, be sure to replace the generic names we have placed within the script with those you have created.

Now that the HTML5 animation scripts are in place, we just need to place the code that will display the animation within the page. Let’s do so by once again going back to the swiffy HTML5 document. Right within the opening and closing <body> tags is the code we need… It should look something like this:

<div id="animation" style="width: XXXpx; height: XXXpx;"></div>

<script>
var stage = new swiffy.Stage(document.getElementById('animation'), swiffyobject);
stage.start();
</script>

Note that the text “animation” within the script is the name of the DIV id where the animation will play. Feel free to change this to match the name of your DIV.

Now, test the animation in an HTML5 compatible browser to ensure that the script was properly implemented and is working as intended.

3) Implement the Flash

We now have our HTML5 animation and its scripts placed and working perfectly. Lets now move on to implementing the Flash animation.

Let’s begin by calling the Flash javascript embed code. Add the following script to the <head> of the animation.html document.

<script src="http://www.mysite.com/js/swfobject_modified.js" type="text/javascript"></script>

Next, we need to place the Flash embed code into the body of our document so the animation can actually play. The following is an example of such code:

<object id="FlashID2" classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" width="895" height="535">
<param name="movie" value="http://www.mysite.com/animation.swf" />
<param name="quality" value="high" />
<param name="wmode" value="opaque" />
<param name="swfversion" value="6.0.65.0" />
<!-- This param tag prompts users with Flash Player 6.0 r65 and higher to download the latest version of Flash Player. Delete it if you don’t want users to see the prompt. -->
<param name="expressinstall" value="http://www.mysite.com/js/expressInstall.swf" />
<!-- Next object tag is for non-IE browsers. So hide it from IE using IECC. -->
<!--[if !IE]>-->
<object type="application/x-shockwave-flash" data="http://www.mysite.com/animation.swf" width="895" height="535">
<!--<![endif]-->
<param name="quality" value="high" />
<param name="wmode" value="opaque" />
<param name="swfversion" value="6.0.65.0" />
<param name="expressinstall" value="Scripts/expressInstall.swf" />
<!-- The browser displays the following alternative content for users with Flash Player 6.0 and older. -->
<div>
<h4>Content on this page requires a newer version of Adobe Flash Player.</h4>
<p><a href="http://www.adobe.com/go/getflashplayer"><img src="http://www.adobe.com/images/shared/download_buttons/get_flash_player.gif" alt="Get Adobe Flash player" width="112" height="33" /></a></p>
</div>
<!--[if !IE]>-->
</object>
<!--<![endif]-->
</object>

Take this code and place it within the same DIV we placed the HTML5 animation code. Verify that the Flash has been properly implemented by testing the page within a Flash enabled browser.

4) Implementing Conditional Statements

At this point, we have a an HTML5 animation and a Flash animation playing within the page. Obviously, we only want one to play. So, lets add some conditional statements to help browsers determine which version to play. Begin by placing the following code within the <head> tags of the animation.html document:

<script src="http://www.mysite.com/js/swfobject_modified.js" type="text/javascript"></script>
<!--[if !IE]>--><![IGNORE[--><![IGNORE[]] > <script src="http://www.gstatic.com/swiffy/v4.0/runtime.js"></script> <!--<![endif]-->
<!--[if !IE]>--><![IGNORE[--><![IGNORE[]] >  <script src="http://www.mysite.com/js/animation.js" type="text/javascript"></script> <!--<![endif]-->

These conditional statements are telling Internet Explorer browsers to pass over the HTML5 animation and scripts and instead run the Flash version of the animation. Why would we do this? The reason is that as of now Internet Explorer does not support HTML5 animation well. But, it handles Flash just fine. Similarly, you can add more conditional statements to target other browsers and suit your project’s specific needs.

Now that we have IE ignoring the HTML5, lets tell the browsers that do not support Flash to ignore the Flash script and play the HTML5 version instead.

We can do so by moving a piece of code we have already placed within animation.html. Within the Flash embed code, look for the following snippet:

<div>
<h4>Content on this page requires a newer version of Adobe Flash Player.</h4>
<p><a href="http://www.adobe.com/go/getflashplayer"><img src="http://www.adobe.com/images/shared/download_buttons/get_flash_player.gif" alt="Get Adobe Flash player" width="112" height="33" /></a></p>
</div>

Replace this code by moving the following script into its place:

<script type="text/javascript">// <![CDATA[
var stage = new swiffy.Stage(document.getElementById('animation'), swiffyobject);
stage.start();
// ]]></script>

Cool! We now have browsers running the Flash animation when they can and simply ignoring the HTML5 animation. And, vice versa… We have browsers that don’t support Flash simply ignoring it and playing the HTML5 animation instead.

Remember to always cross-browser test to ensure all is working as planned.

5) Implementing an Image Fallback

This step is the easiest of all. Simply create a piece of CSS code that renders an image within the animation’s DIV background:

#animation {
width: 895px;
height: 535px;
overflow: hidden;
background-image: url(images/animation.jpg);
background-repeat: no-repeat;
}

This provides yet another fallback for the rare case when a device can not support either Flash or HTML5.

CONCLUSION

In the course of everyday programming challenges, it is always great to be able to come across a convenient solution. However, due to the multitude of variables we run into when dealing with such a wide variety of devices and browsers, there is hardly ever a “one size fits all” solution. Hopefully, this article will assist you in getting around some of the limitations and challenges faced when dealing with a site and the animations within.