Automated updates

The Coder Upgrade module provides a powerful, automated solution to assist developers wishing to upgrade a module for changes in the Drupal core API (or the API provided by any contributed module into Drupal 7. For an example of this, click here.) This tool relies on the Grammar Parser library to upgrade a module's code files.

Migrating content from another site

Once your new Drupal site is up and running, your next challenge may be to port possibly years worth of content from a previous site.

There are probably as many ways to do this as there are sites on the web. Therefore no one method works for everyone, but you usually do not need to start from scratch. Various migration methods have been contributed to the community. There are even Drupal modules to convert an entire site from other standard CMSs into Drupal.

Policy on projects without code: coordination, namespaces, and pointers

There are at least three situations where a project can be created without code on Drupal.org. This page describes which situations are allowed (even if only temporarily) and which are not.

OK: Projects without artifacts, or with artifacts that can't reasonably be hosted on drupal.org

Two examples would be the Governance project, which does not have code artifacts, and the Quickstart project, whose artifacts are too large to be hosted on drupal.org, so are hosted elsewhere.

Temporarily OK: claiming namespaces

You may find yourself in a situation where you create a project page before there is any actual code. This is a great idea so that you can broadcast the fact that you are about to build a module with a specific purpose so that others interested in the topic can collaborate with you.

However, if you do so you should be certain to note several things on the project page.

  • Clearly state that it is placeholder page and that you plan to release the full project in the future.
  • Explain the purpose of the project - even if you don't have code you can explain what you intend to ultimately do.
  • Give an estimated timeline for completion. This timelime should be days rather than weeks.

Field API tutorial

In previous Drupal versions, most modules defined their own tables, handled writing and reading data from tables, managed data entry and controlled presentation. Although Content Construction Kit (CCK) existed, few modules integrated with CCK. Generally, CCK was simply too unwieldy for modules to use. In Drupal 7, field API is in core and is an API (Application Programming Interface).

With CCK, the primary way to create a field was to administer a node type, add/modify a field and set up all this via the browser. Although it was possible to create fields programatically, it was a bolt on and not an easy task to accomplish. In field API, the primary way to create a field is through calling an API (using code) and the field UI (user interface) is an optional module which still allows the management of fields via the browser.

With Drupal 7, most modules will use field API for the tasks outlined above. One example of this is Organic Groups which relies on field API instead of using custom tables. Drupal 7 coding is becoming more “precision surgery” as most of the work is done by the field API, you just need a few well placed alter statements to get the customization you need.

Making a Drupal patch with Git

This page documents a high-level overview of the current best practice recommendations for contributing change requests, in the form of a patch file, to projects (e.g., modules, themes, Drupal core, etc) hosted on Drupal.org using Git. For a more advanced workflow with Git, please refer to the Advanced patch contributor guide. Drush issue queue commands makes it easier and faster to create and work with patches.

Pages

Subscribe with RSS Subscribe to RSS - Programmers