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!
Every time I have to write one of these SQL query loops, I feel unclean:
<?php
// 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...
do_something_useful($result);
?>So I decided to create a function that encapsulates the common scenarios for SQL queries.
I often wish Drupal.org 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.
If you are ready to sponsor the creation of these modules, or want to help with their development, please contact me! And if they exist already, do let me know :-)
An infinite scroll Views 3.x pager plugin. The auto-scroller would refresh the view page with the contents of the next page, as returned by the pager.
Exporters (based on CTools Exportables) for blocks, menus, taxonomies and other core objects.
Single-field editor popups (based on Popups API).
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.
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.
Originally published at OpenCraft
Using the CCK + Views platform, we can replicate the traditional ER (Entity-Relationship) framework into a rapid application development environment that minimizes procedural and SQL programming by replacing most of it with "Visual ER programming": a way to specify data model and behaviour in terms of SQL-like abstractions directly inside the runtime Drupal environment - and reaping the benefits of incremental, always functional output.
ER modeling deals with defining entities and relations among them.
Originally published at OpenCraft.
Google Spreadsheets are cool, but their problem is that they are hosted at Google instead of in your intranet portal. That means that they don't integrate easily with your other Web documents, in terms of classification, indexing, permissions, etc. The API provided by Google does help there, it's true. But what about adding new features? Google Docs simply isn't open source, and therefore is not ideal.
Actions are a convenient way to package functionality in reusable chunks that can be called upon specific events. Countless modules expose actions, and at least the following consume them:
I found it useful to manually call actions in the business logic as well, typically during form submissions or in hook_nodeapi.
UPDATE: The comment by jtsnow resolves the general problem of overriding theme functions in a module using hook_theme_registry_alter(). Woohoo! But the specific problem described below to override the rendering of menu items remains.
I am trying to instruct the menu system to display each item's description underneath the item text, in a smaller font. I located the theme_menu_item() function in menu.inc that currently performs this task.
