a Drupal初心者がここで最初のモジュールを作成しようとしているDrupal 7。
私のサイトでは、サイトの管理者のフロントエンドから新しいコンテンツタイプ(マシン名:抽象)を作成しました。ユーザーは、FAPIを使用して定義したフォームを使用して、このコンテンツタイプの新しいインスタンスを追加できます。このフォームの送信機能では、次のことを行います。
function form_add_abstract_submit($form, &$form_state) {
global $user;
$node = new stdClass();
$node->type = 'abstract';
node_object_prepare($node);
$node->title = $form_state['values']['abstract_title'];
$node->language = LANGUAGE_NONE;
$node->uid = $user->uid;
// ... fill the rest of the node's fields here [...]
if($node = node_submit($node)) {
node_save($node);
// Not sure about this way of defining the path to the created node
$path = 'abstract/' . $node->nid;
$node->path = array('alias' => $path);
node_save($node);
drupal_set_message(t('Abstract submitted');
} else {
form_set_error('description', t('ERROR'));
}
$form_state['redirect'] = 'index.php';
}
上記のように、これらのノードへのパスを「abstract/[its-node-id]」と定義します。次に、ユーザーがこのURLにアクセスすると、2つのタブが表示されます。1つはユーザーがノードのフィールドを表示できるようにし、もう1つはフォームにリンクしてフォームを編集できるようにします。私は私のhook_menu関数に次の3つのメニュー項目を追加することによってそれを実装しようとしました:
$items['abstract/%'] = array(
'title callback' => 'abstract_page_title',
'title arguments' => array(1),
'page callback' => 'abstract_page_view',
'page arguments' => array(1),
'access callback' => TRUE,
'type' => MENU_CALLBACK,
);
$items['abstract/%/view'] = array(
'title' => 'View',
'type' => MENU_DEFAULT_LOCAL_TASK,
'weight' => -10,
);
$items['abstract/%/edit'] = array(
'title' => 'Edit',
'page callback' => 'drupal_get_form',
'page arguments' => array('my_module_form_abstract_edit', 1),
'access callback' => TRUE,
'file' => 'my_module_forms.inc',
'type' => MENU_LOCAL_TASK,
);
ただし、abstract/[a-node's-id]にアクセスすると、abstract_page_view関数が呼び出されず、コンテンツタイプをレンダリングするためのデフォルトビューが表示されます。このビューの「編集」タブは、次のように、abstract/[the-node's-id]/editではなく、abstract/[the-node's-id]#overlay = node/[the-node's-id]/editにもリンクしています。そうしたいです。
何が悪いのですか?コンテンツタイプを管理者のバックエンドからではなくプログラムで定義する必要がありますか、それとも他の場所で問題がありますか?
あなたが何をしようとしているのか理解している場合は、ノードの追加/編集ページとノードビューページを「抽象」コンテンツタイプに合わせてカスタマイズする必要があります。
drupalが既に何をしているかを明確な理由もなく再現しようとしているようです。あなたのコードは、drupal (提供したコードサンプルから)はまだ機能していません(補足として、実際に何を達成しようとしているのですか?)
もしそうなら、私は完全にカスタムページを作成することはないでしょう。 Drupalはフックを提供するため、デフォルトで提供するものを変更できます。
たとえば、ノードの追加/編集ページ(node/add/abstract&node/[nid]/edit)は、 hook_form_BASE_FORM_ID_alter() または hook_form_FORM_ID_alter() を使用して変更できます。 。これらのフォームを変更するフォームで、追加の送信を行う必要がある場合は、独自の検証および送信関数を追加できます。
パスエイリアスの場合は、 pathauto モジュールを使用します。これにより、ページのパスエイリアスをabstract/[nid]に設定できます。ただし、通常は、abstract/[title] SEOと使いやすさのために。
ノード追加ページの場合、admin/config/search/pathに移動してパスエイリアスを追加できます。次に、node/add/abstractの代わりに、abstract/addのようなものにできます。
Drupalフィールドは、特に date 、 link 、 email のようなモジュールの助けを借りて、処理したいほとんどすべてのデータを処理できるはずです。 =、その他多数。
いくつかのノードデータを外部データベースに保存する必要があることがわかったので、この次の部分に興味があります。これらのノードフックを使用すると、ノードCRUDシステムにフックできます。
本当に追加のデータが必要な場合(それほど一般的ではないため、通常はフィールドで必要なことを行うことができます)、たとえば、カスタムのデータを別のデータベーステーブルに格納する場合は、フック hook_node_view( ) ノードビューページにカスタムデータを表示するための hook_node_load() ロードされるたびにカスタムデータをノードオブジェクトにロードする hook_node_delete() ノードが削除されたときにカスタムデータを削除するには、 hook_node_insert() ノードの作成時にカスタムデータを挿入します hook_node_update() ノードがカスタムデータを更新するには保存されます。
検索インデックスと検索結果にデータを追加するために、リビジョンと検索インデックスに関連するものを使用している場合のリビジョン関連のものなど、他のフックもあります。ここでそれらを参照してください- http://api.drupal.org/api/search/7/hook_node_
また、drupalフィールドにない外部データベースのノードにデータを追加する場合、 Entity モジュールが提供するAPIにも興味があるかもしれません。特に、データをエンティティのプロパティとして定義できるため、ルールや検索apiなどのモジュール(およびエンティティapiを利用する他のモジュール)で簡単に処理できます http:// drupal .org/node/1021466
本当にそのようにする必要がある場合は、hook_menu()にもいくつかの問題があります。メニューパスの%文字は、実際には%nodeに置き換える必要があります。これにより、node_loadが呼び出され、パスのnidが適切に検証されます。メニューのワイルドカードローダーの詳細については、 http://drupal.org/node/22417 を参照してください。
また、abstract /%はMENU_CALLBACKであってはならず、MENU_NORMAL_ITEMでなければなりません。
基本的に、node /%node /%/ view node /%/ editページを複製しようとしているので、これらのアイテムのnode_menu()にノードモジュールが持っているものをコピーしてみますが、パスを変更するだけです。次に、node /%node /%/ viewおよびnode /%/ editでノードモジュールが行うことを実行する新しいパスを設定できます。ただし、node /%/ somethingパスを追加する他のモジュールに問題があります(そのようなモジュールを使用している場合)。この場合、ノードページの余分なタブは、パスが一致しないため、ページに表示されません。
したがって、本当にabstract /%/ editが必要な場合を除いて、メニューはそのままにして、パスautoを使用してabstract/[nid]またはabstract/[title]にし、編集ページをnode/[nid] /のままにします。編集。
ユースケースに適しているかどうかに応じた代替ソリューションは、ノードシステムをまったく使用せず、独自のカスタムエンティティタイプを作成することです。したがって、ユーザー、ノード、分類用語などの抽象的なエンティティタイプがあります。
ノードシステムが提供する機能を実際に使用していない場合は、これがより良い解決策になる可能性があります。それを行うのは比較的簡単ですが、欠点は、既存の多くのcontribモジュールがノードでのみ機能し、他のエンティティタイプでは機能しないことです。したがって、必要になる可能性のある追加機能も、自分でコーディングする必要があります。したがって、必要な追加のカスタム作業を実行する時間があるかどうか、またはノードを利用したほうがよいかどうかに依存するため、すぐに互換性を得ることができます。