Limiting access to Drupal content types

Filed under: drupal,web development — jaydublu @ 1:43 pm

There are contributed modules that extend Drupal’s innate desire that all content should be publicly visible – notably node privacy byrole and Content Access. If you’ve defined your own node in a module, you can also use node_access() to set access rights to that node type. But what if it’s a core or CCK content type and you want to keep things simple?

Well here’s a ‘light’ way to restrict access to a given content type (‘mytype’ in this instance) to the owner of the node and any given role (‘administer nodes’ in this instance although it could be anything). Put this anywhere convenient and off you go.

 * Implementation of hook_nodeapi()
 * Limit viewing of mytype nodes to owner and admins.
function mymodule_nodeapi(&$node, $op, $a3 = NULL, $a4 = NULL) {
  global $user;
  if ($node->type == 'mytype' && $op == 'view') {
    if (!user_access('administer nodes', $user) && $user->uid != $node->uid) {

Storing dates in Drupal Schema API

Filed under: drupal,web development — jaydublu @ 6:25 pm

This one caught me out for a good while – I’ve got my own data stored in a database using Drupal’s Schema API and one field I want is a date, so I used the ‘datetime’ type. But whenever I came to use a value anywhere I couldn’t get any of Drupal’s date formatting functions to work – they were expecting a unix timestamp (makes sense) but the Schema API uses ‘datetime’ as a field type on MySQL so was getting a MySQL date string in return.

The answer was not to use datetime as a schema type, but int, and when passing data make sure you pass a timestamp. format_data() and views_handler_field_date etc. will then work as expected.

But it makes you wonder who left this mantrap lying around for foolhardy developers like me to fall into?

Mobile Stylesheets

Filed under: mobile,opinion,web development — jaydublu @ 2:41 pm

In an article on A List Apart ‘Return of the Mobile Stylesheet‘, Dominique Hazaël-Massieux starts by reviewing the ‘ideal’ approach to making a site mobile friendly:

Ideally, site authors would be able to meet the growing demand for a quality mobile experience without changing a line of code. But the reality is that a site designed specifically with mobility in mind will always provide a much better user experience to mobile users, even when they are equipped with the device du jour. It’s not merely a question of network costs and delays or memory and CPU limitations. Rather, the mobile experience merits its own design, as discussed in a growing body of literature, including the W3C’s very own Mobile Web Best Practices, released in July 2008 as a W3C Recommendation. The formula for a mobile experience provided by Little Springs Design sums up the goal nicely: mobilize, don’t miniaturize. Mobile users operate in a very different usage context than PC users, and providing them with an experience customized to their needs is likely to be the best service you can offer to them.

But then he goes on to describe “a first step toward mobile design that uses CSS to maximize interoperability across platforms” asserting that “by starting simple, you can provide a decent initial experience, solicit user feedback, and iterate toward a more mobile-friendly design.

Shame – because the likelihood is that if you put all your effort into a CSS solution, which is sub-optimal (in my view) because devices still have to load bloated code, and you probably end up with compromises for bot mobile and ‘normal’ browsers amongst other reasons, you’re much less likely to make the bigger step of producing a version of the site optimised for the mobile experience.

Many platforms make it quite simple to do this – there are mobile modules and plugins I’ve seen (and used) for WordPress, Drupal etc. – if you’ve got server side logic, and preferably some form of content management / delivery system going on, it should be not much more than switching to a simpler theme for your presentation when a mobile device is detected.

But then that’s easy for me to say, because I still haven’t done it in anger to any large extent (yet).