Victor Font Consulting Group, LLC

The DEX Intranet Specialists

Victor M. Font Jr.

Add Snapchat to Simple Social Icons

By

Authors Note: The code in this article only works for Simple Social Icons Versions prior to the 2.0 release in December 2016. The 2.0 version switched from using icon fonts to using SVG graphics for the icons. The code below has been deprecated. See this post for further details: Simple Social Icons Ver. 2.0
Snapchat icon, public domain image from pixabay.com

Many users like to use the Simple Social Icons plugin with their Genesis Framework based child themes. Authored by Nathan Rice, Brian Gardner and the Studio Press team, it works very well with Genesis. After all, they are the framework's authors. And in keeping with the Genesis philosophy for making everything fairly simple to modify if you know how, the Simple Social Icons plugin makes use of filters to allow a developer to easily modify its content and display. A common request these days is to add the Snapchat icon to Simple Social Icons. This article shows you how to do that.

First, we need to add Snapchat to the plugin's profile and glyphs definitions. Add this to your child theme's functions.php:

Unfortunately the font icon set included with Simple Social Icons does not include the Snapchat ghost. For the purpose of this article, I've used FontAwesome for the glpyh. If you have a different preference, you can use any icon font you'd like, but you're on your own for figuring out the code. I've found that one of the best ways to include FontAwesome on your site is to install the Better Font Awesome plugin.

Finally, add this to you child theme's style.css:

This code was tested in my local environment with the Executive Pro theme.

Genesis Deactivate Superfish Menu Support

By

Genesis Deactivate Superfish Menu, public domain image from pixabay.com

The Genesis Framework includes the popular jQuery Superfish Dropdown Menu Plugin. For most themes, the superfish extension is activated by default. Ever since the inclusion of superfish in Genesis, the method for deactivating it was as simple as including the following code snippet in your child theme's functions.php file:

Since the release of Genesis 2.2 however, the above snippet no longer works. This is because of the new accessibility features built into the Genesis Framework. The superfish extension is required if you enable drop-down-menu support for accessibility. Among other things, superfish provides the following functionality:

  • Support for touch devices
  • Timed delay on mouseout
  • Animations
  • Keyboard accessibility
  • Supports the hoverIntent plugin
  • Indicates the presence of submenus by adding CSS-based arrows to relevant anchors
  • Can show the path to your current page

With the support superfish provides, if you want a WCAG 2.0 compliant website, you need to leave the extension activated.

Deactivating Superfish

The Genesis function that tests for superfish support is genesis_superfish_enabled(). The source code is:

See the section in the return statement that reads genesis_a11y( 'drop-down-menu' ). This is the test for accessibility drop-down-menu support. So if you are using the Genesis accessibility features, you now have to turn off support for dropdown menus if you want to deactivate superfish. Look for a line similar to the following in your child theme's functions.php file:

Delete 'drop-down-menu', from the above line and add the following to functions.php:

Infinite Scroll and MatchHeight.js

By

Overview

Infinite Scroll and MatchHeight.js Arm Wrestling public domain image from Pixabay.com

Every once in a while, writing and testing code can be a little like arm wrestling or maybe even like pulling teeth. Things can be going along smooth as silk and then all of a sudden you hit a requirement that, on the surface at least, seems easy enough. But, as you dive into its construction, it turns out to be difficult and time consuming to find just the right combination of plugins, extensions, or algorithms that work, especially when executing them through Ajax callbacks.

Such is the case for a problem solved for Southern Home Design Plans, a site for selling custom home designs, owned and operated by a very talented architectural firm in Cary, North Carolina. The site is built with a highly customized Genesis Framework child theme and WooCommerce.

The Requirements

The WooCommerce shop page is highly customized. In fact, when you see it, you wouldn't even know that it's WooCommerce because other than displaying 3 house plans per row, there is no further resemblance to anything WooCommerce vanilla. The first requirement for the catalog page is to display all the house plans using infinite scroll for pagination. As you know, infinite scroll works by invoking an Ajax script when a user scrolls to the bottom of the page. The Ajax routine loads new products and extends the size of the page.

To satisfy this requirement, we used the very popular Animated Infinite Scroll plugin available from Code Canyon. The plugin is easy enough to setup and it works like a charm. And SBThemes, the author, provides great support.

The second requirement, also known as the better half of this challenge, is making sure the custom image areas are all the same size per each row. To visualize what I mean, look at the following image from the development site. (This is still a work in progress so please don't be too critical.)

Row of house plans from http://shdplans.com/

The width of these images is 332px. As you can see, their heights are very different. This is the nature of house plans. When you drive down the street or walk through your neighborhood, the homes may appear to be similar in width or design, but their heights can be very different. The requirement is to keep the appearance of the catalog images consistent so each product in a catalog row presents with the same height. The rows have to be even.

To accommodate this, the image is wrapped in a parent div:

To make certain that the parent container is the same height within each row, we use the jQuery MatchHeight.js extension. This extension calculates the height of each parent div after the images load and adjusts them to the same height if necessary. It does a great job and is fairly easy to use.

The Challenge

As well as these two tools work individually, getting them to work together in concert proves challenging. This is directly related to how Ajax works in browsers. We've discussed this before in a previous post, Formidable Pro: Invoke Ajax on Submit, so we won't repeat the details here. But in summary, the problem boils down to a timing issue. The Ajax callback in the Animated Infinite Scroll plugin executes the matchHeight function before all of the images load. This results in an uneven page.

The Solution

The solution to this problem requires holding back on the matchHeight function until all the images load. But how do we do that? Some recommendations suggest using the jQuery(window).load() function. This sounds like a great idea except that the page will often load before all images have been downloaded. Again, this results in incomplete results and an uneven page.

The first thing we tried is the jQuery waitForImages extension. After spending several hours trying every conceivable combination of parameters, this plugin just won't work in the Ajax callback. The results were always the same. The rows were never completely balanced.

Then we tried the jQuery ImagesLoaded extension. There are two versions of this extension, the first is very simple jQuery code written by Paul Irish in 2010. The second is a much more complex version by David DeSandro that is still being maintained. Both of these versions work well to allow Animated Infinite Scroll and jQuery MatchHeight.js to work in concert.

If you're interested, the code used in the On Pagination End callback is:

jQuery.ajax() and Microsoft Browsers

By

jQuery.ajax() and Microsoft Browsers, Freeimages.com/Svilen Milev

The Problem

You gotta love Microsoft! Sometimes I think they've taken liberties with their browsers that are designed just to be annoyances for the programming community at large. Case in point, we recently inherited a Formidable Pro project that uses a jQuery.ajax() call to retrieve a confirmation number from a database on a remote server when a user clicks on the form's submit button (See here). The remote server runs Windows and Internet Information Server (IIS). After refactoring the code to improve performance and overcome a timing issue, it all appeared to be working perfectly in all browsers, except that is…, (yes, you guessed it!), Internet Explorer. Now to only figure out why.

The Analysis

The jQuery.ajax() request as originally written looked like this:

The content is a well-formed XML record built with the values from the Formidable Pro form. Since we inherited this project, this code had already been built. We assumed that it was written to satisfy the specification provided by the customer. We did not have access to the original specifications to verify the work.

Rule Out Cross-Site Scripting

The path to the remote server is a subdomain of the primary domain. To help with the troubleshooting, we added a field to the Formidable Pro form and created a function to write to it as an error log. One of the errors recorded in a failed submission has a jqXHR status code of 0. Status code 0 is generally triggered when there is an attempt at cross site scripting and access is denied, or the connection is refused at the server. With this setup it could be one or both of these issues. We decided to rule out cross-site scripting first.

With cross-site scripting, subdomains are considered different than the primary domain and will fail the Same Origin Policy unless both domains declare the same document.domain DOM property (and even then, different browsers behave differently). The fact is that we are sending a request from a primary domain to a subdomain. To our eyes, this shouldn’t be a problem, but this is a problem for some browsers. Maybe it's a problem for IE? It certainly wasn't an issue for Firefox, Chrome, or Safari during our testing. The link to the Same Origin Policy provides some remedies for relaxing the cross site scripting issues. Adjusting the jQuery.ajax() request is as simple as adding "crossDomain: true" to the function's parameters. Again, this worked with every browser except IE. Cross-site scripting is eliminated as the cause for the IE failure.

HTTP GET vs. HTTP POST

When we tested with IE, as soon as the function was invoked we could see in the Network tab of the browser's development tools that the browser cancelled the request. It would not send the request to the server. Why would the browser cancel the request?

As it turns out, this was due to a long ago forgotten fact about Internet Explorer. IE is designed to restrict URLs to a length of 2083 characters. The records produced by the form easily exceed that length. If a URL is longer than the restricted length, IE will not process the request.

Ajax data can be sent over the Internet either through a HTTP GET or HTTP POST request. POST requests supply additional data from the client (browser) to the server in the message body. In contrast, GET requests include all required data in the URL. Ajax requests can use either method by specifying the type of the request as either "POST" or "GET" (default) in the Ajax function. The method specified determines how the data is submitted to the server. When the method is GET, all data is encoded into the URL, appended to the action URL as query string parameters. Remember query strings? Because of the GET, this request was being formed as //path-to-remote-server/?action=ajax-action&param1=param-value1&param2=param-value2&param3=param-value3, etc.. GET requests can create very long URLs. With POST, the data appears within the message body of the HTTP request, which effectively overcomes IE’s URL length limitation. Changing the Ajax request type to POST solved this problem.

Content Type

Changing the request type to POST introduced yet another problem. This time, viewing the Network request/response cycle in the browser's development tools, we could see that IE was sending the request, but the server was responding with a HTTP 500 internal server error.

POST request require a content type of "application/x-www-form-urlencoded; charset=UTF-8" (jQuery.ajax() default) regardless of the actual type of data being sent. The jQuery.ajax() request was sending data in XML format with its content type set to text/xml. IIS didn't like this. The solution was to remove contentType: "text/xml" from the request function so jQuery.ajax() used its default.

Encoding Special Characters

One last issue remained. IIS immediately rejected any Ajax request where one of the XML values included a special character. For example, if the value of a business name field was "Sanford & Sons, Inc.", the request choked because of the ampersand. Special characters need to be converted to HTML entities when sent through Ajax requests. Neither jQuery nor JavaScript have a direct function for converting special characters to HTML entities. The following quick 3-line function solves this issue.

This function works by creating a div in memory. The div does not exist on the page. The function assigns the passed parameter to the div's inner text, then returns the encoded content. To use this you simply pass the form's field value as the parameter.

Conversely, you can decode HTML entities into special character by reversing the text() and html() functions.

The Resolution

After all is said and done, here is the final code for the jQuery.ajax() call: