drupal

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.

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…)

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.

Following on the Data Architecture Design Sprint during a cold and snowy Chicago week in February, two Drupalcon presentations, a lot of writing, and even more debating, I am really looking forward to next week's Fields in Core code sprint. Our goal is to re-organize Drupal's content APIs and data storage around Fields instead of Nodes; think of it as "CCK in core, except for the admin UI." When the dust settles, everything will continue work just as it does now, but we will have a framework in place to allow Drupal and the community to get maximum leverage from what it is best at: Adding Value to Content.

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.

Both Drupal and Dries Buytaert have received many honors recently. As an MIT alum (6-3 '92), however, I'm particularly pleased to see both of them in the TR35: Technology Review's annual list of leading young innovators. Since I'm already 38, this is probably the closest I'll ever come to making that particular list. :-)

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.

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.

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?

I recently started using a Mac for web development (I don't love it but that's another story). At the recommendation of several friends I'm using MAMP instead of the native Apache, PHP, and MySQL; they said it was much easier to set up. Yesterday, I discovered that MAMP's PHP install does not come with the OpenSSL extension so, for example, you cannot visit HTTPS sites from within PHP.