.installファイルまたは.moduleファイルにプログラムで新しいコンテンツタイプを追加しますか？

プログラムで新しいコンテンツタイプを作成するには、2つの方法があります。

• まず一つは、私も使用した、カスタムモジュールの中でそれを作成することです.install内のファイルhook_install()使用node_type_save()してもフィールドを取り付けるhook_install()とfield_create_field()してfield_create_instance()。
• Node Exampleモジュールで使用される2つ目は、カスタムモジュールの.moduleファイルにそれをhook_node_info()作成し、hook_node_type_insert()

私の気持ちはそれを維持する方が良い（つまり、を介して新しいフィールドを追加/更新するhook_update_N()）と言っており、.installファイルに適しているので、私は最初の方法を好みます。しかし、Node Exampleモジュールでそれが他の方法で行われる理由を自問しています。

両方の方法を使用してコードで新しいコンテンツタイプを作成するCONとPROを知っている人はいますか？

などの一部のフックhook_deleteは、ノードのコンテンツタイプを定義するモジュールでのみ呼び出されます。を使用してコンテンツタイプをデータベースに保存すると、node_type_save()「モジュールによって定義された」と認識されない場合があります。これは、ユーザーが作成したコンテンツタイプとして機能します。もちろん、$info['module']モジュールを指すように設定しない限り-その場合、作成されたエントリは同じように機能するはずです。

3番目の方法は、特にノードタイプが時間の経過とともに変化する場合に、維持しやすいことがよくあります。これは、機能を使用してノードタイプ、フィールド、およびフィールドインスタンスをエクスポートすることです。エクスポートされた機能モジュールにカスタムコードを追加することもできます。機能はそのカスタムコード（および追加のファイル）を将来のエクスポートで保持します。

以前は.installファイルメソッドを使用していましたが、Featuresの安定性とUI / drushの統合で十分なので、フィールド情報とノードタイプ情報を手動で取得する時間を大幅に節約できます。

ノードタイプ/フィールドなどを変更し、機能モジュールを再エクスポートする場合、UIで機能を更新するか、drush feature-revertまたはを使用できfeatures-revert-allます。

問題ありません... updateメソッドを使用すると、新しいコンテンツタイプを作成できます...