Blake Simpson

If you have the problem when working on a local wordpress installation where you need to do an upgrade or install a plugin, you may be presented with the following screen asking for FTP details to the server.

Lets assume you need to install a plugin. One option would be to manually download the plugin and move it into the wordpress plugins directory, but this is frustrating and slow. The better way is to let wordpress handle everything for you.

My Mac no longer had Apache or PHP working after the upgrade to Mac OSX 10.9, Mavericks. This is caused by the system upgrade removing the main configuration files for each service and creating backups instead.

Here are the steps I used to fix it, open a terminal window and use the following commands:

Fix Apache

cd /etc/apache2/
sudo mv httpd.conf httpd.conf.backup
sudo mv httpd.conf.pre-update httpd.conf
sudo apachectl restart

Once complete, Apache should be back up and running as before. Next, PHP can be repaired like so:

Fix PHP

cd /private/etc/
sudo mv php.ini-5.2-previous php.ini
sudo apachectl restart

That's it! These steps simply move the configuration files back to their correct location and restart the web server.

Notes:

• I am assuming you use the original Apache/PHP install that comes with OSX, instead of a custom solution like MAMP.
• Your PHP ini file may have a different name if you are not using version 5.2

I have recently discovered a small bug in Google Analytics that prevents an event from being collected in the reporting if the event "label" is a number.

The situation I encountered this issue in was when using my Google Analytics Wrapper to track custom events. I had the 3rd label argument as the funnel step number that the visitor was currently on, it was simply an integer (1, 2, 3...) and after some waiting time I realised that Google Analytics was not accepting these events.

After testing I simply added a "step" prefix to the value, making it a string ("step-1") and the events immediately began recording as expected.

This may be a bug but may in fact be a method that Google uses to prevent a developer from tracking specific users, which is against the terms of service, where Google assume that an integer is a user ID or similar.

If anyone else has run into this issue and has any further insight, it would be great to hear.

Here is a little trick that enables you to apply retina images to your web pages in pure CSS, no JavaScipt hacks or "-webkit" prefixes required!

The best part is that only a single retina image is required as opposed to requiring a "2x" and an unscaled version to be present in your project.

How to make a retina image

To begin with a "retina" image is required, which is just a buzz-word for an image that has double the normal resolution. You can create an image like this in Photoshop by making it twice the normal size (a 16x16 pixel icon would be 32x32 instead) and giving it a density of 144, rather than the default 72.

When saved, the file traditionally has "@2x" at the end of the filename and is in PNG format (e.g. "home-icon@2x.png").

CSS Integration

To apply the retina graphic to the web page, we use a solution that takes the double scaled retina image and resizes it to fit the unscaled version.

.home-icon {
  width: 16px;
  height: 16px;
  background-image: url("images/home-icon@2x.png");
  background-position: center center;
  background-repeat: no-repeat;
  background-size: 16px 16px;
}

This CSS snippet gives the icon a 16 pixel square size and we know the "home-icon@2x.png" image is 32 pixels square, so the background-size property fits them to match.

On a regular screen, everything will look normal, however on a "Retina" or other high resolution display, the icon will be displayed in it's true quality without any blur or defects.

The reasons I chose this solution are:

• Pure CSS
• Works across browsers
• Works on mobile
• Only requires a single image (efficient)

For an example, check out the differences of the image in this JS Fiddle on and off a high resolution display such as an iPhone: http://jsfiddle.net/UxK4N/

During development of recent project, I have had to realize a JavaScript solution that will detect when a visitor swipes the page and then perform an action based on the swipe direction and distance.

Of course this is not a new challenge and many solutions have already been found. jQuery mobile ships with a built in swipe event but I did not require such an extensive framework and decided to write the cleanest answer that solved the problem.

Below you will find the source code to a jQuery plugin I call "Swipe.JS", which provides the same swipe event to any DOM node.

Usage

First I will show how to use the plugin. Multiple swipe events can be bound to different nodes but for the sake of example, we will use the "body".

$("body").swipe(function( direction, offset ) {
  console.log( "Moving", direction.x, "and", direction.y );
  console.log( "Touch moved by", offset.x, "horizontally and", offset.y, "vertically" );    
});

Testing a static website can be done simply by opening the HTML files in a web browser, but for some functionality to perform correctly, such as local AJAX calls, the files need to be served from a web server.

Alternatively, you may want to check out some static files on your mobile device. You can do this easily by starting a simple web server for the project and navigate to your computers IP address with the given server port.

Python Server

The easiest way to do this on UNIX based systems is to use the Python Simple HTTP Server, like so:

python -m SimpleHTTPServer 8080

Run this command in the same directory as your project from the terminal, then point your browser to http://localhost:8080.

This is a great way to get a server running in seconds, for basic testing, but I have found that as the number of files in the project increases, the stability of the server decreases. Often files will not be passed to the client and 404 errors are encountered. For these reasons I have investigated a stronger solution that is still simple to setup. This leads me to Node.JS.

Node Server

Node.JS is no stranger to web servers, in fact this is often the primary task of a Node application.

"Connect" is a Node.JS middleware application that makes the creation of simple web servers trivial.

To get Connect running, first install it via npm:

npm install -g connect

Here is a web server that can be used, simply paste the code into a file called "server.js" in your project's root directory.

var connect = require( 'connect' ),
  http = require( 'http' );

app = connect()
  .use( connect.logger( 'dev' ) )
  .use( connect.static( __dirname ) );

http.createServer( app ).listen( 8080 );

Finally run the server from the terminal like so:

node server.js

If no error was received, the server is running and files can be viewed by browsing http://localhost:8080, just like in the Python example.

I have not had any trouble with the Connect version of my server and it comes built with a nice development logger, showing what files were requested and with what status. This output can be viewed live in the terminal window as requests come in.

I've recently been investigating web page performance and focusing on CSS efficiency to see where performance gains can be made. After using the Chrome CSS profiler, I came to the conclusion that my "reset" CSS file was taking a long time to parse and match selectors, slowing down the browser paint process.

Reset CSS files are used to normalise default DOM element styles, so that your custom styles will work effortlessly across all browsers.

Naturally then, the reset CSS must target many elements in order to change their style. However, how can this be done in the most efficient manner?

This useful website, CSSReset.com provides 5 popular reset methods for you to use.

For my experiment I have used each of the provided codes and implemented them in turn into my web page. I then run though a "script" of accessing certain parts of the website while the Chrome CSS profiler is running and measure the results of each. I have performed the script multiple times with each code snippet to ensure a valid result.

In short, my findings are: normalize.css has the best efficiency, by quite a long way, with YUI coming in second place.

The reason normalize.css is highly more efficient is that unlike the other scripts, it does not select all DOM elements in a single comma separated declaration, but breaks up the declarations into smaller segments.

Due to my project not using many DOM elements, the browser can skip parsing for many of these declarations making overall performance better.

This is interesting as normalize.css is the least used code snippet on the website, at the current time of writing.

I'd be interested to follow up on this and here any arguments for or against using a reset CSS in this manner.

There are certain CSS best practices that should be followed in order to increase CSS performance in the browser. These will help the browser to perform less DOM parsing and reduce the time of repaint events.

1. Browser reflow and repaint

If you are unfamiliar with the concepts of reflow and repaint, here are some articles that will get you up to speed:

• https://developers.google.com/speed/articles/reflow
• http://www.stubbornella.org/content/2009/03/27/reflows-repaints-css-performance-making-your-javascript-slow/
• https://www.google.com/search?btnG=1&pws=0&q=browser+repaint+and+reflow

2. Remove unused styles

Simply having styles that aren't used causes the browser to search the DOM for matches needlessly. This is wasted processor time. Additionally, the CSS file will have a higher page weight that is needlessly sent over the wire to the client.

It may not seem to make a huge difference but removing dead CSS code will greatly increase performance and additionally improve the project stability and maintainability.