Terminal Commands Cheat Sheet

When working with files and databases on a web server it’s often quicker, and sometimes essential if file sizes are large, to use SSH via terminal (or command line) to perform certain actions, such as zipping and unzipping folders, importing large MYSQL database, checking in via GIT and so on. So I have compiled some of the most common terminal functions I use as a quick cheat sheet below:

Zipping and Unzipping Folders

Extremely handy for ensuring all files transfer from one server to another, or for simply downloading large sites via FTP.


zip -r mynewfilename.zip pathtofolder/foldertozip/


unzip file.zip -d destination_folder

or more simply:

unzip file.zip

Finding location of MySQL

which MYSQL

Importing a MYSQL database

mysql -u username -p password database_name < filename.sql

Exporting a MYSQL database

mysqldump -u USER -p PASSWORD DATABASE > filename.sql

Uploading via SSH in the command line

Open terminal and navigate to the folder on your computer where the file is you want to upload (then you can remove the /filelocation from the snippet below):

scp /filelocation/filename username@

Downloading via SSH in the command line

scp [email protected]:filename /some/local/directory

GIT version control common commands

git push –tags

git add  .

git commit -m “Message goes in here”

git push -u origin [branchname]

git branch [branchname]

git checkout [branchname]

git pull

Some useful WordPress Template Snippets

Out of the box WordPress comes as a useful tool for creating simple brochure websites. The mass of community plugins also add real value to WordPress as a platform for building simple websites. When creating bespoke templates there are a few useful code snippets, which I have listed some of below, that come in handy when coding specific features into your PHP template files within your theme.

1. Embedding a Menu Snippet into a template

This piece of code enables you to put a custom menu anywhere into your templates:

<?php wp_nav_menu( array(‘menu’ => ‘Homepage Links’ )); ?>

(where ‘Homepage Links’ is the NAME of your custom menu)

2. Creating a new widget region

To create a new widget region that you can place widgets in you need to edit your functions.php file AND then the template file you want to place the region into. Firstly in functions.php you need to add:

register_sidebar( array(
‘name’ => __( ‘Homepage News’, ‘twentyten’ ),
‘id’ => ‘news’,
‘description’ => __( ‘News section on homepage’, ‘twentyten’ ),
‘before_widget’ => ‘<li id=”%1$s” class=”widget-container %2$s”>’,
‘after_widget’ => ‘</li>’,
‘before_title’ => ‘<h3 class=”widget-title”>’,
‘after_title’ => ‘</h3>’,
) );

This adds a new region called ‘Homepage News’, in this case within the twentyten template structure. The before and after widget code enables you to add custom styles and HTML tags before and after each widget placed within the region.

Then, within your template file (i.e. sidebar.php) where you want it to appear you need to place the region:

<?php if ( !function_exists(‘dynamic_sidebar’) || !dynamic_sidebar(“Homepage News”) ) : ?><?php endif; ?>

You are now free to add widgets to the region and they will appear on your site.

3. The template directory

In your template files if you need to place a link to a file in your template directory, for example to a css of javascript file, you can use this snippet to ensure it remains dynamic and not hard coded:

<?php bloginfo(‘template_directory’); ?>

Homepage settings for multi-language sites in Drupal

When creating multi-language websites in Drupal you can use a number of modules to provide languages and translations. These include the Locale and i18n modules. However you may get stuck wondering why, despite translating your homepage node (for example node/1) into another language, it does not switch to the translated node when you choose a different language – like the other pages of your site do.

This is because in the site settings you have one node set as the front page, and Drupal does not recognise this needs to be dynamic. So there is a small change needed to your settings.php file in order to use a multilingual variable as the homepage, instead of a fixed node.

Step 1:

In your settings.php file add the following code, this creates a multilingual variable:

/* Multilingual settings
This variable can be set up for each language when i18n is enabled.
$conf[‘i18n_variables’] = array(
// Different front page for each language

Step 2

Now go to your Admin > Site Information page and you will see that next to the front page box there is now a note that this is a multilingual variable:

This means you can set a DIFFERENT front page node for each language simply by visiting this settings page from within each language, i.e.



Handy htaccess and htpassword access restrictions

Using a htaccess file to restrict access to your website can be extremely useful for both development and live environments. Here are a couple of my favourites:

Restrict access by IP address

This snippet only allows access to the site to people browsing from the IP address specified (given here as aaa.bbb.ccc.ddd):

<limit get=””>
order deny,allow
deny from all
allow from aaa.bbb.ccc.ddd

Restrict access by password

This snippet goes in the .htpasswd file (not htaccess) and allows users to login to access the site:


It’s that simple!


Restricting Orientation on Apps built in Titanium Appcelerator

If you are using Titanium Appcelerator to developer applications for mobile devices you may want to restrict which Orientations the app is allowed to use on your devices. This is a fairly simple process and requires you adding some code into your app’s tiapp.xml file.


The example below allows portrait only on the iphone and all orientations on the iPad:

<orientations device=”iphone”>
<orientations device=”ipad”>

For Android

Locking orientation on Android can also be done in your app’s tiapp.xml file. It’s more complex though. The primary configuration file for Android apps is the AndroidManifest.xml file. At build time, entries in your project’s tiapp.xml file are used to create the AndroidManifest that’s packaged with your app. To force orientation support, you’ll need to copy some entries from generated AndroidManifest file back into tiapp.xml, modify them, then build your app again.

  • In Studio, open the tiapp.xml file and display its XML contents.
  • Adjust the <android> node:
  • From the line that reads <android xmlns:android=”http://schemas.android.com/apk/res/android”/>, delete the “/” at the end (to change it from an empty tag to an opening tag).
  • Add a new closing </android> tag
  • Between those tags, add new <manifest></manifest> tags.
  • Open the ‘yourProject/build/android/AndroidManifest.xml’.
  • Copy all <activity> lines from that file
  • Then paste between the <manifest></manifest> tags in the tiapp.xml file. Each time your app is built from this point on, Titanium will copy the activity tags to the AndroidManifest file. You’re can now specify the UI orientation.

Each “heavyweight” window has a corresponding activity. And for each of those, you’ll find an entry that reads something like android:configChanges=”keyboardHidden|orientation”. Delete the “|orientation” from each of them.

<android xmlns:android=”http://schemas.android.com/apk/res/android”>
<activity android:name=”ti.modules.titanium.ui.TiTabActivity”

Why Drupal needs care and attention to its backend

As an agency that has often used Drupal as its CMS and development environment we’ve come across countless projects that have had varying levels of experience from the customer who ultimately uses it. We’ve often been outsourced to by other agencies who have used us for the nuts and bolts development, while providing their own project management, wire framing and sometimes design. One major problem we’ve noticed is that backend wire framing often gets overlooked. Detailed front end wireframes are generally always provided, but backend admin is often left to default Drupal layout or Adkins themes.

Drupal’s default admin backend is NOT very friendly.

For developers and experienced users it’s great, which is why it’s often overlooked as something that would benefit from a little customisation. The end user, that is the site editors and administrators are more often than not non Drupal experts of course.

Some careful attention to the layout and options shown in the backend is all that is needed to provide a friendlier user interface that requires less training and hand holding.

Here are some quick tips for making the backend a simpler experience for your customers:

1. Always use a super user AND administrator or editor roles. Remove permission on that administrator role or anything they do not need to see

2. Use a custom admin theme. Consider what your users need to see and do and create custom menu structures for them.

3. Maybe use the Admin Bar module

4. Test, test and test again with non Drupal users

5. Provided a simple step by step training guide

6. The standard content list is not that searchable or friendly, consider using a view instead

7. Provide description snippets for all your custom content types and features

In short, treat your administrators as someone who has never used Drupal before. And ask yourself, ‘can I find my way quickly to all the tasks I need to perform?’

Using Titanium Appcelerator

For a recent project we have given Titanium’s Appcelerator a go to build an iPhone and android application for Birmingham Book Festival. This was because it was a fairly simple mobile app designed to integrate with WordPress so that the Book Festival could manage up to date content from their existing WordPress website. The app is designed to provide additional event, news, location and feedback features to festival goers.

Data is passed from WordPress to the app via standard JSON feeds dated using the existing WordPress API.

Developing using Titanium has been an interesting experience, so here’s some of my thoughts on it.

Firstly it was recommended to me by a colleague, and initially it seemed to fit the bill well. During early development though I ran across a few problems and was shortly told by the same colleague not to use appcelerator, he’d changed his mind and that it was a poor SDK to work with.

This was somewhat depressing, having got quite a long way down the development track already. At that point I was also trying to use online resources for Appcelerator as well as forums posts for a couple of the tricker features. It very quickly struck me that it was in fact the supporting documentation and community contributed forums that was lacking. Advice given on certain subjects is often wrong, full of poor coding examples or simply absent altogether. As someone who often uses and contributes to the open source community I found this a bit unusual and off-putting.

However, once I realised that I could not 100% trust the online forums development suddenly became a lot easier. Instead of looking for help when stuck it made me dig down and find the solutions ourselves. And before too long the app was running smoothly without any memory leaks or crashing on simulators and devices alike. The coding structure is fairly logical, and the Environment is good. I would however think twice about using it for anything particularly complex, but for information and feedback based application, with social media integration and maps, it works a treat.

So in summary I would use Appcellerator again, but I would definitely pick my projects to use it with. And for anything especially complex I would consider going back to working directly with objective c in Apple’s own development environment.

Some of other features used successfully:

  • Data passed back and forth using JSON feeds
  • integration with WordPress
  • maps and location data
  • photo slideshows
  • twitter feeds
  • tables and lists
  • webviews

I’d give it a 6 out of 10 at this point in time.

Generating ImageCache Image Derivatives in a module

So you’re writing a custom module in Drupal 6 and you want to be able to create your own ImageCache Preset, and generate image derivatives on the fly? Look no further!

Below is a snippet used to generate a preset:

$imagecachepreset = imagecache_preset_save(array(‘presetname’ => ‘PRESET_NAME’));

Now, what I chose to do was store this imagecache preset as a variable, so I could call upon it whenever I wanted:

variable_set(‘custom_imagecache_preset’, $imagecachepreset);

Ideally, that bit of code would run in your hook_install() function, so that the preset is only created once. Best to flush Drupal caches after this too.

Then we’ll want to apply an action to this preset. Now, I put this in an admin form, so the admin user could create new presets as they wanted, but you can add this segment straight into your module:

$imagecachepreset = variable_get(‘custom_imagecache_preset’, ”);

$imagecacheaction = new stdClass ();

$imagecacheaction->presetid = $imagecachepreset[‘presetid’];
$imagecacheaction->module = ‘imagecache’;
$imagecacheaction->action = ‘imagecache_scale_and_crop’;
$imagecacheaction->data = array(
‘width’ => (int)WIDTH,
‘height’ => (int)HEIGHT,

drupal_write_record(‘imagecache_action’, $imagecacheaction);

As you can see, we first recall our image preset fromt he vraibles table, then add the action and save it.

Next, you’ll want to apply the preset to an image. This is best handled in your _form_submit() function, after using the file_save_upload() function. First, we recall our preset again:

$imagecachepreset = variable_get(‘custom_imagecache_preset’, ”);

And then simply generate the image:

imagecache_generate_image($imagecachepreset [‘presetname’], FILEPATH);

And that’s all there is to it! The new derivative should have been created and stored, and can be easily recalled using the theme function below, but first, we need to call our preset from the variables table again:

$imagecachepreset = variable_get(‘custom_imagecache_preset’, ”);

$output .= theme(‘imagecache’, $imagecachepreset [‘presetname’], FILEPATH);

SagePay Test Cards

I thought it might be useful for us to have a page to reference SagePay Test cards.

SagePay says;

Which means;

Billing Address: 88

Set BillingAddress1 to 88

Billing PostCode: 412

Set BillingPostCode to 412

These billing address values are the only values which will return as Matched. Any other values will return a Not Matched.

For completeness here is the rest of the above link’s data;

· Expiry date: any future date

· CV2: 123

Card Type

Protx Card Name

Card Number

Issue Number





Visa Delta




Visa Electron UK Debit








UK Maestro




International Maestro








American Express




Japan Credit Bureau (JCB)




Diners Club





Hope this helps everyone who needs it!

Using join in CodeIgniter Active Record delete

You might try this, using CodeIgniter’s Active Record class:

$this->db->join("table2", "table1.thing_id = table2.id")
  ->where("table2.otherthing_id", $id)


This doesn’t work, as CodeIgniter ignores joins when doing Active Record deletes.

Instead, you’ll have to write out the SQL ‘manually’ – something like this:

$sql = "DELETE t1 FROM table1 t1
  JOIN table2 t2 ON t1.thing_id = t2.id
  WHERE t2.otherthing_id = ?";
$this->db->query($sql, array($id));

Solving ‘MySQL server has gone away’ errors in Codeigniter

Problem: a long-running PHP script (in this case, a cron-job with a sleep() function in it) was triggering ‘MySQL server has gone away’ errors in a Codeigniter application.

Solution: after each sleep() call, do this:


Problem solved.

PS We’re actually using a little function called _randomsleep(), that goes like this:

function _randomsleep()
 $sleep = rand(11, 61);
 echo "Sleeping for " . $sleep . " seconds";

Drupal Block visibility PHP

This snippet when used in Drupal block visibility (PHP mode) will show the block on the URL news and for node type 'news' too.
if (arg(0) == 'news') {
return TRUE; 
if (arg(0) == 'node' && is_numeric(arg(1))) {
$node = node_load(arg(1));
if ($node->type == 'news') {
 return TRUE;