acquia

Field API: Get mentored and help out!

The Field API is major new functionality in Drupal 7 to provide custom data types just like CCK did for previous versions of Drupal. Field API became part of Drupal 7 February, 2009, but there is still plenty of work to do. We need your help, and we’ll help you learn what you need to know to contribute.

The Field API is a great way to get yourself involved directly in Drupal core development. We realize, however, that Field API is a big, new, scary chunk of code that is not the easiest thing to jump into. The Field API team wants to help you get up to speed, so we’ve created the Field API mentoring process. Here’s our promise: If you assign a Field API issue to yourself and take responsibility for it, the Field API mentors will help you learn what you need by participating in the issue and answering questions on IRC.

We’ve created a Field API contributor page at drupal.org that describes (most of) the open issues and their degree of difficulty. If you want to grab one but have some questions about that part of Field API, ask about it over at Field API: What do you want to know? and we can add it to the documentation.

Field API: What would you like to know?

The Field API is major new functionality in Drupal 7 to provide custom data types just like CCK did for previous versions of Drupal. The Field API team has written fairly thorough API documentation but that is more useful as reference material than as a tutorial or HOWTO handbook.

So, here’s your chance to tell the Field API team what you want to know how to do. Comment on this post telling us what we should explain.

One option is to give us the title of HOWTO pages you’d like to read, such as:

  • What is the difference between a Field, Bundle, and Field Instance?
  • How do I add a Text field to a node type?
  • How do I add an Image field to users?
  • How do I get a list of all defined Fields and Field Instances?
  • etc.

Special thanks to chx for having the idea and offering to write some of the articles! (No good deed goes unpunished…)

The DX Files: A voice from the field

This is part five of my series, The DX Files: Improving Drupal Developer Experience. Today I am simply posting, verbatim, a message that a potential new Drupal developer sent me. The point here is just to understand how Drupal's DX influences the way it is perceived and the kind of people that want to work with it.

The DX Files: Static caching in Drupal

This is part four of my series, The DX Files: Improving Drupal Developer Experience. I started this series with fairly simplistic suggestions. They proved not very popular and some of them I agree were of questionable benefit due to PHP’s nature. I was pleased to discover, however, that they nevertheless had quite an impact on raising the visibility of “Developer Experience” within the Drupal community. I am therefore ready to move on to some of the more complex DX issues in Drupal.

The most important DX change Drupal needs to make is switching from a form-driven model to an API-driven model. There are many parts to such a change. Today’s topic: static caching.

The DX Files: Abandon Anonymous Arrays of Attributes

This is part three of my series, The DX Files: Improving Drupal Developer Experience. This time, I’m suggesting changing some of Drupal’s most basic data structures and APIs by replacing anonymous arrays with well-defined data structures. I fully expect lots of disagreement.

Tainted Bugs (or, Automatically detecting XSS security holes)

With apologies to Gloria Jones and a variety of others...

Sometimes I feel there has to be a way
To improve securi-tay
To automatically prevent attacks
The bugs we fix seem not to help one bit
To make the exploit-tays
Not come back. They should stay away!
Oh! Tainted bugs!

As part of Acquia's security testing for Acquia Drupal, I've been experimenting with automated methods for detecting security vulnerabilities in Drupal and contributed modules. The time has come to report on my progress. If you want to learn more about this and are going to DrupalCon Hungary 2008, vote for my session proposal.

Data tainting is a kind of dynamic program analysis (it operates while the program is running) that can automatically detect one of the most frequent sources of security vulnerabilities: insufficiently validated user input. The idea behind data tainting is that when data is received from an untrusted source (such as GET request parameters or some parts of the database), it is marked as "tainted." Any data derived from tainted data (such as by string concatenation, passing function arguments, etc.) is also marked tainted. When tainted data is passed to a security-sensitive destination (such as the HTML response to a page request), a taint error is raised. Finally, when tainted data is validated in specific ways, the taint mark is removed so the data can be used freely.

What I am calling "Taint Drupal" is based on Taint PHP work by Wietse Venema along with some Drupal-specific customization particularly regarding the database. For more details, keep reading.

The DX Files: Defined constants as API arguments

This is part two of my series, The DX Files: Improving Drupal Developer Experience.

Many Drupal APIs accept a boolean argument (TRUE or FALSE) to determine some behavior. I believe that practice should be banned in all but exceptional cases, instead using a defined constant with a descriptive name.

Here is a perfect example from Drupal core:

<?php
    $output
= node_view($node, FALSE, TRUE);
?>

Now, quick! Who can tell me what passing FALSE as the second argument and TRUE as the third argument means?

The DX Files: Improving Drupal Developer Experience

I am declaring a personal crusade to improve Drupal’s “Developer Experience,” which I hereby abbreviate as “DX.”

Acquia Web 2.0 Expo Launch Pad video

On April 24, Jeff Whatcott and I gave a 5-minute Drupal demonstration and Acquia pitch at the Web 2.0 Expo Launch Pad event. Here's the video (larger version here).