Planet Drupal

Going fullscreen in JavaScript/jQuery

I'm no fan of Flash. Even the name annoys me :-) But I feel that recreating its capabilities using the trio HTML/CSS/JavaScript (isn't there an acronym for these 3 interrelated technologies?) is often non-trivial.

A case in point: I recently added to Sheetnode the feature of editing the spreadsheet fullscreen. While every Flash component has a fullscreen option, I couldn't even find a jQuery component that implements this functionality.

Overriding menu item themes

In an earlier article, I tried to argue, somewhat inconvincingly, that theming menu items is less than ideal. I think my example was not well chosen. Fortunately, real life furnished me with a perfect example, during the course of my work.

A client required to associate specific icons with menu items, by specifying a custom class for specific menu items. A legitimate request that has been around for years on desktop menu systems. How to implement this on Drupal? Not so simple using the current menu theming setup.

Dealing with deep arrays in PHP

Drupal code is heavily array-based, and it utilizes array structures that can be many levels deep. Here are a couple of complementary functions to query and manipulate such arrays:

<?php /** * Search for a key in an array, returning a path to the entry. * * @param $needle * A key to look for. * @param $haystack * A keyed array. * @param $forbidden * A list of keys to ignore. * @param $path * The intermediate path.

Keeping views under control

It's no secret that version control on Drupal is hard. Specifically, the problem of iteratively building a site on a staging server, then moving it to a running production system has been the source of countless wasted hours, lost data, pulled hair, blog posts, and modules promising a solution. On Twitter, some would say #drupal #migration #fail.

This post is not the answer to this problem. I just want to show actual code that helps with a small part of it, namely keeping views under version control.

Fun with Views and Location

For my day job, I've been using the Location module quite extensively. Thanks to its many contributed modules, it integrates with various parts of the Drupal ecosystem, including Views, making it a good base to start developing your own location-aware features. Here are some puzzles I faced during the past few days:

Filtering views with existing cities

The city filter is a text field. That's not ideal because it does not give users a hint about existing cities in the database.

4 years of Drupal and no going back!

In late 2004, I convinced a couple of friends to start an open source-based consultancy in Cairo, Egypt. I had discovered FOSS during my Master's at Université de Montréal, and going back to Microsoft technologies soon felt unbearable. I quit my job, spent a sabbatical year, then started developing Web applications on WAMP as a freelancer. I wanted to be useful to my community, instead of developing software for inhuman corporations!

A function to simplify SQL queries

Every time I have to write one of these SQL query loops, I feel unclean:

// Oh no, not another db_query loop!
$resource = db_query("SELECT nid, title FROM {node}");
  while (
$row = db_fetch_array($resource)) {
$result[$row['nid']] = $row['title'];
// Get on with your normal life here...

So I decided to create a function that encapsulates the common scenarios for SQL queries.

A community of practice network on

I often wish had more social networking features. I feel they would enhance my ability to act as a productive Drupal community member, both benefiting and benefiting from the great platform that we're using.

For example, when I receive a new issue in my modules' queues, I usually check the interaction record of the posting member, just by looking at the "Track" tab of their account. It gives me a context through which I (think I can) better interact with the member towards resolving the issue positively.

Social networking has connotations of frivolity - think Facebook.

Automatically populating YouTube playlist upon new Embedded Video Field submission

Here's a little action I wrote recently, to automatically populate a specific YouTube playlist as new videos are being posted to a Drupal site, using modules Trigger or Rules. The same concept can also be used retroactively on existing content, using Views Bulk Operations: select all existing video nodes and apply the action to them.

Less code, more logic

The aim of Drupal architecture is to implement the logic demanded by the application while resorting to a minimal amount of new code written. Modules are used as logic blocks that are assembled to yield the desired software structure that will acquire, store and display the site's content.

Coding for Drupal involves mainly creating reusable modules that implement specific logical manipulations of information. The crucial reason why this modular approach works in Drupal is that each module exposes hooks that allow other modules to extend its own functionality.

Syndicate content