doublejosh

Setup Drupal Coding Standards Sniffer

Nothing quite as lovely as knowing your code is squeaky clean when it’s going out for public consumption. Well there is… when you can automate the nit picky bits. Here’s how to setup the Drupal coding standards sniffer tool within your IDE or via command line (online version here, only for live git repos).

1. First of all PHP Code Sniffer is a PEAR extension, so you’ll need to setup PEAR, depending on your machine. Normally this is via “sudo apt-get install php-pear” but you can also do so with macports as “sudo port install php5 +pear” or even use a homebrew formula.
2. Next get the Code Sniffer extension via the pear extension manager: “pear install PHP_CodeSniffer” then depending on your install method you’ll need to set your include_path in php.ini to point to the right place. With macports this is: include_path = “.:/opt/local/lib/php”, see the homebrew link above for that location.
3. Now you’re ready to get the Drupal coding standards definitions from the DrupalCS project page for your sniffing rules. This is added to the code sniffer folder or sym-linked (I just dropped it in the folder). BTW: Testing should now work via command line.
4. Lastly you need to setup a quick tool in your IDE to run this tool on the currently file (though it’s possible some IDEs may allow this to run inline). The DrupalCS page includes instructions for a few major editors, but I’ve seen results for others pop up so some Googling will probably return whatever you’re using at the time.
5. NOTE: If you now have a conflict with the command line PHP version always being 5.3 (current mac native) while MAMP is still in 5.2 (while running the D6 site), try setting up a drush alias like so (I do so in ~/.profile)… alias drush="/Applications/MAMP/bin/php/php5.2.17/bin/php /usr/local/bin/drush.php" yet you will also need to place path updates in ~/.bash_profile for the freshen script like so… export PATH=/Applications/MAMP/Library/bin:/usr/local/bin/drush:/usr/bin:$PATH

Pick a domain name

Picking a domain name is hard. Here are a few great sites (two new resources for me from @RobOusbey).

Combine words, check availability, and make use of alternate TLDs…

• leandomainsearch.com
• bustaname.com
• domai.nr

Find new words you hadn’t thought of yet…

• OneLook Reverse Dictionary (my secret weapon)

Simple Touch Enabled Web Form App

I recently needed to create a simple, few-slide, info capture, mobile web-form survey, “iPad app” via the web. You can create a pretty slick app-like experience, certainly not quite native feeling, but there are lots of little pieces and gotchas. I’ve collected some of the key tips here.

The final result is this: datageek

First things first, make it so adding the webpage to the home screen will create an app like experience with no address bar or resizing.

<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=0, minimum-scale=1.0, maximum-scale=1.0">
<meta name="apple-mobile-web-app-capable" content="yes">
<meta name="apple-mobile-web-app-status-bar-style" content="black">

There are plenty of posts about adding home screen icons, so I’ll let you read one of those. For example this one from GigaOM.

Next you’ll probably want to kill off that horrible gray box when clicking on stuff.

<style>
 /* Remove that lame gray box when clicking items */
 a,input{-webkit-tap-highlight-color:transparent;}
</style>

I was dealing with a form so I needed to improve the touchy-feely experience therein.

<script>
$(document).ready(function() {
  // iPad fixes:
  if ((navigator.userAgent.match(/iPad/i))) {
 
    // Guess what: hovering doesn't exist.
    // You'll want to alter the look on click.
    $('#myForm input[type=submit]').click(function() {
      $(this).toggleClass('clicked')delay(500).toggleClass('clicked');
    });
    // Or perhaps you'd prefer a touch feedback class.
    $('#myForm input').bind('touchstart', function(e) {
      $(this).toggleClass('hover');
    });
    $('#myForm input').bind('touchend', function(e) {
      $(this).toggleClass('hover');
    });

    $('#myForm input').bind('touchend', function(e) {
      $(this).toggleClass('hover');
    });

    // Prevent vertical "bouncing" from touches.
    document.ontouchmove = function(event){
      event.preventDefault();
    }

    // Guess what, clicking labels doesn't work.
    // You'll need to link clicking labels to the radio/checkbox inputs.
    $('label[for]').bind('click', function() {
      var el = $(this).attr('for');
      if ($('#' + el + '[type=radio], #' + el + '[type=checkbox]').attr('selected', !$('#' + el).attr('selected'))) {
        // Yarg, the clickin be done here.
        return;
      } else {
        $('#' + el)[0].focus();
      }
    });
 
  }
});
</script>

My form was split into a bunch of “slides” which needed to auto-advance when a choice was made as well as be navigable via swiping as you’d expect. After burning through jQueryMobile, JQTouch and not exactly wanting what they offered… and actually looking for less structure. I wanted to try jQueryUIswipable but it was beyond the version of jQuery in my CMS, the touchSwipe library looked promising as well as dead. But I landed on SwipeJS which was perfect for what I needed.

With one line of code I swipe-ified my form like so…

// Make fieldsets swipable, and create slider container.
var appCards = new Swipe(document.getElementById(‘myForm’));

Just sure your form is setup like this…

<form id="myForm">
  <div class="form-inner">
    <fieldset>
      <input type="text" class="continue">
    </fieldset>
    <fieldset>
      <input type="text">
      <input type="text" class="continue">
    </fieldset>
    <fieldset>
      <input type="text">
      <input type="submit">
    </fieldset>
  </div>
</form>

Then link specific clicks to moving slides…

<script>
  $('#myForm input.continue').each(function() {
    // Continue when clicked.
    $(this).bind('click', function() {
      appCards.next();
    });
  });
</script>

Then if you plan to allow desktop users to see this, you might want to kill the tab key.

<script>
// Kill tab key
var TABKEY = 9;
$('#webform-client-form-15993 input').keydown(function(e) {
  if (e.which == TABKEY) {
    console.log('tabbed');
    e.preventDefault();
    return false;
  }
});
</script>

As you might guess there were more, but this is enough to get you pretty far along with a simple swipe form app. Here is the result: /datageek

Fields or Taxonomy

Little philosophy of organizing systems…

#1) Use taxonomy to classify content.

#2) Use taxonomy to manage permissions.

#3) Use fields for everything else.

Bottom line: You don’t want to organize just by virtue of data matching. (At least not when you’re designing a schema.)

The post I was reading, while trying to make a decision http://www.johnandcailin.com/blog/cailin/drupal-cck-vs-taxonomy