$field = array(
    "field_name"=>"field_field_name",
    "label"=>"Field label",
    "type"=>"node_reference",
    "settings"=>array(
      "referenceable_types"=>array(
        "gallery_image"=>"gallery_image"
      ),
    ),
    "cardinality"=>"-1"
  );

  field_create_field($field);

  $instance = array(
    "field_name"=>"field_field_name",
    "label"=>"Field label",
    "type"=>"node_reference",
    "widget"=>array(
      "type"=>"options_select"
    ),
  );

  $instance["entity_type"] = "node";

  foreach(array("type1", "type2", "type3") as $type){
    $instance["bundle"] = $type;  
    field_create_instance($instance);
  }

“gallery_image” is the machine name of the type that will be referenced by the field – put as many in here as you need (yes, the format really is “machine_name”=>”machine_name”). “cardinality” is the number of references in the field, -1 being unlimited. In the example, the field will be added to 3 types – type1, type2 and type3.

#main #content #inner h3

this was causing huge problems when any external mark-up was dropped into the page. The generic styles were already so specfiic that they were over-riding most other CSS styles. Before you know it you needed to tag everything with:

#main #content #inner #something .get .my .point

to make the styles to cascade properly.

It’s worth remembering that although

#main #content a {color:black}

looks fairly innocuous but when you later to need to change the style of an anchor tag you’ll be stuck needed to add a lot of specification and worse external mark-up, unaware of your overly described selectors will end up being overridden. Before you know it your rules are flowing off the page and every new change requires a train of selectors, tags and classes.

It’s worth then noting how CSS decided what styles to use – Other people have done a better job than I would manage so I’ll just point you towards a few articles that cleverly explain the problem:

http://iamacamera.org/default.aspx?id=95

http://coding.smashingmagazine.com/2007/07/27/css-specificity-things-you-should-know/

Enjoy!

The Framework Myth says you don’t need an internal omnipotent framework. I agree – over the years we have built up a small collection of re-usable code, based on experience of actually needing that code in our situation. Coders love to code, and I have to admit feeling a thrill at writing my own APIs but “you are probably not getting paid to fulfill your dreams, you are getting paid to write the damn code.”

Reusable Code is Bad is a headline in the tradition of hyperbolic blog post headlines, but “never build something to be reused until you actually have two systems that actually need to reuse it right now.” is something that makes sense to me.

Crucially, I think, everybody’s situation is different so you always have to judge for yourself. But as I look back over a decade of projects, how much unused reusable code did I write? How many times did I sweat over whether to take the time to “add another layer of abstraction and logical branching to my function” and how many times was I wrong when I decided to? Less and less as experience has taught me not to.

You should understand the principles of code reuse, no doubt, but learn to use your own judgement in your current situation. As with all advice, just because Google/Facebook/37 Signals/some-guy-with-a-blog says it’s a good idea, doesn’t mean it is for you.

db_query

No need to mess about with fetching rows any more, db_query() returns a Traversable object which can be foreach-ed. Also, placeholders no longer need quote marks. (The Numiko API has taken care of these conveniences for a while now, glad they are no longer needed).

Comments

It’s now easy to output comments separately, meaning they can be placed anywhere on a node. No more hacking it.

Profiling

The Devel module now integrates the XHProf Profiler, which looks useful for finding bottlenecks in code.

Checkboxes

Now simple and logical to create on types. Previously I always had to refer to how I did it the last time.

More Granular Permissions

Which is good, and they are more logical. It will require a bit more thought from developers when defining roles e.g. all of the following permissions would generally be required as a base for a site editor: “Use the administration toolbar”, “View the administration theme”, “Use the administration pages and help”, “Access the administrative overlay”, “View the administrative dashboard, “Access the content overview page”.

Thankfully the infamous “Administer content” permission has been tamed.

Content List Page

This page now has sortable columns, and an “Updated” column, instantly making content easier to find and identify. AJAX auto-complete filtering here would make it complete.

Facebook seems to read this from the canvas URL now instead – so try setting that to be the same as your Site URL.

Incidentally, I only had this problem when working from localhost – with sites on the public Internet,  setting the site URL only worked fine.

SELECT count(uid), 

  MONTH(FROM_UNIXTIME(created)) as bmonth, 

  YEAR(FROM_UNIXTIME(created)) as byear 

FROM users 

GROUP BY bmonth, byear 

ORDER BY byear, bmonth;

Thankfully, this is pretty straightforward to fix…

The error is caused by src=”javascript:void(0)” on line 3 of the unifpngfix.js file and there are two ways to work around this:

1. Replace javascript:void(0) with javascript:false;.
2. Insert a link to an empty file in place of the javascript:void(0). You should note that this creates an extra server call and is my less favoured solution of the two. You could get around this by using a blank page and have the cache never expire on it as suggested here.

And that’s that!

1. Go to the Application Profile Page (linked to from right hand col on your app’s main page (where it shows stats, your app id, site url etc)

2. From Application Profile Page click on “Edit Application” – left hand col underneath profile pic

3. On the Edit App page there’s a list of app devs in the right hand col – just click on the “Add” link

4. Phew!