<?php if (is_front_page()) : ?>
    <ul class="featuredServices">
    <?php for ($i = 1; $i <= 3; $i++) : ?>
      <li class="<?php echo ($i == 3) ? "col-last" : "col"; ?>">
        <h3>
          <a href="<?php echo get_post_meta(get_the_ID(), "Col$i Link", $single) ?>">
            <?php echo get_post_meta(get_the_ID(), "Col$i Title", $single) ?>
          </a>
        </h3>
        <p>
          <?php echo get_post_meta(get_the_ID(), "Col$i Text", $single) ?>
        </p>
      </li>
    <?php endfor; ?>
    </ul>
  <?php endif; ?>

All the site editor has to do is edit the custom fields named Col1-3 Title, Text and Link and the code displays the data as an unordered list which can be styled as columns. An improvement would be do add the ability to do a varying number of columns as the number of columns is hard-coded into the theme but it wasn't necessarily for this project and would just have added another custom field to confuse the editor.

Please let me know what you think via the comments and if you have any suggestions for improving the code / doing it in a different way that would be great too.

- @Prydie

<?php
function redirect($location, $delay = 0) {
	if (!headers_sent()) {
		if ($delay > 0) {
			header("Refresh: $delay; url=$location");
		} else { header("Location: $location"); }
	} else {
		?>
		<script type="text/javascript" charset="utf-8">
			$(function () { 
				setTimeout(function() { 
					window.location.replace('<?php echo $location; ?>');
				}, <?php echo $delay*1000; ?>); 
			});
		</script>
		<noscript>
			<meta http-equiv="refresh" content="<?php echo $delay; ?>;url=<?php echo $location; ?>">
		</noscript>
		<?php
	}
}
?>

The script first tries to redirect the page using the header() function. If the headers have not been sent and then falls back to jQuery, resorting finally to a meta refresh if javascript is disabled.

jQuery + Apache

jQuery (and most other major Javascript libraries) when executing AJAX requests use a specific header to show that they are doing so. This header can be requested and accessed as a variable as long PHP is installed as an Apache module. This method requires no change to your Javascript (jQuery) code however if PHP isn't installed as an Apache module there is a slightly less elegant workaround below that does require you to edit your Javascript.

<?php
$headers = apache_request_headers();
if( !empty($headers['X-Requested-With']) && ($headers['X-Requested-With'] == 'XMLHttpRequest')) { 
	header("Content-type: application/json"); }
}
?>

The above code firstly requests the headers and stores them in the variable $headers and then if the header is present sets the content type to application/json so that the browser treats the data as JSON. We use two clauses in the IF statement to avoid PHP displaying a warning about $headers['X-Requested-With'] being undeclared when Javascript is disabled.

Then when returning data (such as error information) you can use the same if statement to return a JSON encoded array if Javascript is enabled or just simple HTML if not.

jQuery with another webserver

PHP does not (to my knowledge) provide a platform independent method of getting the request headers. Therefore we can simply add another data field to our jQuery $.ajax request to be used as a differentiator.

$(".button").click(function() {
	var firstName = $("input#firstName").val();
	var lastName = $("input#lastName").val();
	var email = $("input#email").val();
	var dataString = 'firstName=' + firstName + '&lastName=' + lastName + '&email=' + email + '&js=1';
	$.ajax({
		type: "POST",
		url: "add.php",
		data: dataString,
		success: function(result) {
			// do something
		}
	});
    return false;
});

By adding &js=1 to the request in the Javascript we can use the $_POST['js'] variable in PHP to differentiate between jQuery $.ajax requests and browser requests.

if (!empty($_POST['js'])) { 
	header("Content-type: application/json"); 
}

I hope you found this useful, if you have any comments or suggestions (especially on a more universal method of reading request headers) please let me know in the comments.

- Andrew Pryde

I watched Chris Coyier's excellent screencast #87 Moving up with MAMP (you certainly should too) on the subject of transferring a WordPress blog from a local server (or other development server) to a production server. Though he covered a lot of ground and set out a process perfect for less advanced users, especially those with no experience of the Terminal there are a few tricks that more advanced users will be able to use to save a lot of time and headaches.

1. Moving files

The only files that you need to upload are those specific to your installation of WordPress which are contained within the wp-content directory (with one notable exception but we will get to that later). The rest of the files can be fetched straight from the WordPress servers eliminating the lengthy period of time it takes even the better FTP clients to upload all the core WordPress files. This is done by connecting to the production server via SSH and issuing the following commands.

wget http://wordpress.org/latest.tar.gz
tar xzf latest.tar.gz

You can then go ahead and upload the contents of the wp-content directory via FTP. However one file in particular will be missing - the .htaccess file used by WordPress to create the permalink structure of your site. You may wish to upload this from your WordPress directory but because the filename is prefixed with a . you are unlikely to be able to see it without changing the settings of your FTP client. The easiest thing is simply to ensure that when the site is uploaded you have WordPress rewrite these rules by disabling and then re-enabling permalinks in the WordPress settings panel.

2. References to the development domain in the DB

In the WordPress database multiple references are made in different records and tables to WordPress' location (i.e. the domain it resides on). When installing on a local development machine these settings are of course different from those of your production server and it is these settings which you will find in the database. This can be avoided however by editing your /etc/hosts file on OSX and Linux (or \Windows\system32\drivers\etc\hosts file on Windows) so that locally the production domain points to your development server.

On Linux / Mac open Terminal and type "sudo nano /etc/hosts", enter your password and add the following at the bottom of the file.

127.0.0.1 www.productiondomain.com

On windows just browse to the \Windows\system32\drivers\etc\ folder and open the hosts file with Notepad and add the same line.

This enables you to configure WordPress as if you were using the production domain and your computer will just redirect your requests for www.productiondomain.com to your local server.

If you haven't done this are your database is littered with references to your development domain no need to fear. All you need to do is find and replace the instances of your local development domain within the exported database dump you will be uploading to the production server. This can be done by executing the following command on the database dump file in Terminal.

sed -i.bak 's/localhost/www.productiondomain.com/g' db.sql

What this does is replace all instances of the string "localhost" with the string "www.productiondomain.com" so that all your database records will reference the new domain rather than your local development version. This command only available on OSX and Linux but one could also use the find and replace functionality of your favourite text editor as long as the database wasn't to large.

Anyhow, I hope you find this useful and that it speeds up the process a little. Let me know what you think in the comments and if there are any particular requests I will expand upon some more of the minutia of moving WordPress from a localhost to live.

I have been testing out TextExpander and for the most part have been really impressed by its time saving goodness. I like the inbuilt bit.ly snippet which enables you to shorten any URL copied to your clipboard and insert the shortened URL into any text area on your mac. However I have been using the cl.ly service from @getcloudapp which produces URLs only 16 17 characters long (nice for saving space in tweets) and so I decided to code my own cl.ly URL shortener in Applescript for use in TextExpander. Here is the result.

set Username to "user@email.com"
set Pword to "passwordhere"
set the ClipURL to (the clipboard as string)

ignoring case
	if ((characters 1 through 4 of ClipURL as string) is not "http") then
		return "Malformed URL."
	else
		set curlCMD to "curl --digest -u '" & Username & ":" & Pword & "' -H 'Accept: application/json' -H 'Content-Type: application/json' -d '{ \"item\": { \"name\": \"" & ClipURL & "\", \"redirect_url\": \"" & ClipURL & "\" } }' http://my.cl.ly/items"

		-- Run the script and get the result:
		set clURL to (do shell script curlCMD)
		set oset to offset of "http://cl.ly/" in clURL
		set clURL to text (oset) thru (oset + 16) of clURL
		return clURL
	end if
end ignoring

Implementation

To implement this function create a new text expander snippet and change its content type to AppleScript (this is so it doesn't paste the code when you trigger the abbreviation but executes it). Then paste in the above code filling the email and password variables with your account details (not got one? Get one here).

This is by no means a perfect solution. For a start you have to enter your credentials in plaintext into the script for it to run (a security concern and not great for distribution). Secondly due to AppleScirpt’s complete lack of text phrasing functionality if @getcloudapp changes the length of their URL which they are likely to do as there are only 226,920 permutations of 3 character case-sensitive alpha-numeric strings, the script will fail with very little grace.

Update: They filled the URL space (all 226,920 permutations) and now the URLs are 17 characters long. The script has been updated accordingly. They may fill the URL space happen again however there are now 13,388,280 permutations of 4 character case sensitive alphanumeric strings available so we are safe for now.

Anyway, please let me know what you think via commenting bellow as I am looking at ways of improving this and suggestions are most welcome.