Numiko Labs

It wasn’t obvious how I could add new node reference fields to a content type. I had to work it out from node_reference_field_info() and from examining existing fields with field_info_field(). After some experimentation, this worked:

  $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.

Working on a project the other day I came across a problem with some existing CSS where the selectors for basic elements all included the ID’s for the layout containers.

#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!

Here are two related articles (by Mike Mooney) where I found myself agreeing with every point and feeling relief that others have come to the same conclusions as I have over the years.

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.

Everyone knows about the big changes in Drupal 7 but the details matter too, especially when they’re the kind of details that make life simpler and save time every day. Here’s some nice ones in Drupal 7.

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.

If you’re having problems getting the facebook login callback to fire – for example,  you’re using one of the social plugins and are not getting redirected back to the right place on login – you might be looking to set the “Post-Authorize Redirect URL” – except, it’s not there any more!

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.

Useful query – shows how many users registered on a Drupal site each month:

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;

Unit PNG Fix is a great workaround for those projects which require the use of alpha transparency in IE6. As well as being very compact—just over 1KB—it is also very easy to implement. However, using Unit PNG Fix on a secure domain can result in a “This page contains both secure and non–secure items…” error in IE.

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!

If  you come across this when trying to add developers to a Facebook app – yes, it’s a bug and no,  it doesnt seem to have been fixed despite its status having been set to RESOLVED – but dont worry! There’s another way to add developers to your app (thanks for pointing it out Numikon Ry!)

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!

Console.log is great for debugging JS code with Firefox’s Firebug plugin. However leaving your console.log calls in the JS code will cause it to fail silently and mysteriously on Firefox without Firebug. After a morning of confusion on a recent project, we turned up this Heisenbergian gotcha. Here’s a full explanation.

OK totally quick post this. Was getting this error inexplicably in the console, couldn’t work out what was causing it, commented out all but the most simple lines of code….. Still there! If in doubt – check the version of jQuery you’re using and try upgrading it. Worked for me. Incidentally this had nothing to do with AJAX/JSON – as I was still getting the error even without making any calls to any AJAX methods, BUT all the search results I’d found seemed to suggest a probelm in this area.