~ Merge queries using db_merge 和訳 ~

Merge query は少し特殊なクエリです。SQL 2003 の仕様では定義されているものですが、ほとんどのデータベースは、標準の構文をサポートしていません。ほとんどがそれぞれデータベース固有の構文の実装で代替されています。Drupal のマージクエリは抽象化されたオブジェクトであり、それぞれのデータベースにおける適切な構文にコンパイルすることが出来ます。これは「UPDATE」と「INSERT」を足し合わせたようなもので、しばしば「UPSERT」と呼ばれます。

コア: 
Drupal7

Drupal のエンティティ(の種類)を簡単に追加出来るモジュールです。

エンティティとは、Drupal 7 から導入された概念で、ノード、ユーザー、タクソノミーターム、コメントなど、サイトの主な構成要素の「実態」を表すもので、これらは共通の様式で扱えるようになっています。(これにより、ノードだけでなくコメントやタクソノミーターム、ユーザーにも同じ様式でフィールドを追加することが出来るようになりました。)

Drupal にはこれらの既存のエンティティに加えて、独自のエンティティ(の種類)を追加する機能があります。
これはカスタムモジュールに hook_entity_info() を実装することで可能となりますが、ECK モジュールはこれをもっと容易にし、さらに管理画面上の UI も提供します。

コア: 
Drupal7
~ Log Site Activity with Message and Rules 和訳 ~

メッセージモジュールは Drupal サイト構築でログの記録&管理機能を実装するのに利用できる汎用の実用的なツールです。例えば全てのブログ投稿のログを記録し、サイドカラムに設置したブロックにそれらの最新リストを表示したいとします。メッセージモジュールを使えば、そのようなことは 1行のコードも書くことなくとても簡単に実現できます。

コア: 
Drupal7
~ Message Module API 和訳 ~

メッセージモジュールは実用的な汎用のログ記録ツールです。Drupal サイトで発生するあらゆるタイプのアクティビティーを記録することができます。私は以前に Rules モジュールを使ったメッセージモジュールの使い方に関する記事を書きました。

コア: 
Drupal7

Message モジュールを使って、サイト上の様々なイベントや、ユーザーのアクション(アクティビティー)を記録、表示することができます。

ここで扱う Message はひとつのエンティティ(※1)として実装されます。ノード、ユーザー等と同様に任意のフィールドを持たせることが可能で、用途ごとにメッセージタイプとしてバンドル(※2)を構成します。このために大きな柔軟性、拡張性を持ち、様々な用途に利用できます。

たとえばSNS(ソーシャルネットワーキングサービス)のような機能を持つサイトでは、ユーザーの様々なアクション(アクティビティ)を表示する機能として使えます。具体的な例としては

コア: 
Drupal7

カスタムモジュールを制作するなど、Drupal を高度にカスタマイズしたい場合は、必須のモジュールになると思います。Devel には開発者にとって、あると便利な機能がたくさん入っています。

まずいちばんよく使うのは dpm() でしょう。Drupal のコーディングによるカスタマイズは、基本的にはフック関数を記述しその中で行ないますが、引数として渡される変数の中身を確認したい場面が多々あります。また、Drupal のAPI の関数を利用して、得た値を変数に格納し、その中身を確認したい場合もあるでしょう。そんなときは次のように、

dpm($確認したい変数);

として、引数に確認したい変数を渡し、カスタムコードの中で dpm() をコールしてやると、図のように変数の中身を確認できます。変数が配列やオブジェクトの場合は、その要素やプロパティの値も得られます。階層構造がある場合は、すべて展開しそれらの中身を確認することもできます。

プログラムからノードの特定のフィールドだけを修正/更新したいとき、このようなコードを考えるかもしれません。

$node = node_load($nid);
$node->field_fieldname[LANGUAGE_NONE][0]['value'] = '更新したフィールドの値';
node_save($node);

node_load() でいったん変更したいノードの完全なデータを読み込み、修正/変更したいフィールドを操作して、node_save() で保存する。

「しかしこれでは無駄が多い」と感じてしまいますね。まず変更する必要のないフィールドもすべて読み込まなければなりません。そして変更していないフィールドや、ノード自体もすべて保存し直すことになります。フィールドの数が3つや4つならまだしも、10 や 20、50 ~ものフィールドがあったらどうでしょうか?それで1つか2つのノードを変更したいならまだしも、数千ものノードを連続で修正したい場合は?

コア: 
Drupal7
~ Field Api 和訳 ~

Drupalのエンティティ(ノード、ユーザーなどの概念)にカスタムデータフィールド(属性情報)を持たせる。

フィールドAPIは、Drupalのエンティティにカスタムデータフィールドを持たせ、フィールドデータの保存、ロード、編集そしてレンダリングをサポートします。フィールドAPIを利用することで、(ノード、ユーザーなどの)あらゆるエンティティタイプは、カスタムフィールドを持つことが出来るようになります。他のモジュールはウェブブラウザーからカスタムフィールドを操作するためのユーザーインターフェース、および様々な種類のデータタイプ、フォーム部品、そしてディスプレイフォーマットを提供することが出来ます。

コア: 
Drupal7
~ Controlling Nodes in Drupal 7 和訳 ~

Drupal のコンテンツのアクセスコントロールにはいくつかの方法があります。コアに組み込まれている機能、あるいは追加モジュールによって提供されるもの、またはいくつかの追加モジュールの組み合わせによって実現するものなどです。いくつかの機能は互いに互換性があります。

コア: 
Drupal7

Drupal ではデフォルトで、匿名ユーザーのコメントの掲載には管理者の承認が必要ですが、承認待ちのコメントを確認するには承認待ちのコメント一覧ページ(/admin/content/comment/approval)にアクセスする必要があります。

これをどこからでも確認できるように、Views を使ってブロックで表示したいと思います。

コア: 
Drupal7

ページ