2008年にDrupalについて初めて耳にしたとき、私はそれを試してみたかったのです。当時はWordpressとJoomlaしか知らなかったからです。 起源の歴史と名前の意味を知らなかったので、私にはあまりにも真剣で信頼できるように思えました。 たぶん、それは何かに関連していたのか、それとも何か深刻なものと調和していたのかもしれません... それにもかかわらず、時が来て、私は私にとって最も深刻なCMSに精通することにしました。 知り合いは完全に失望しました！ Joomlaフレームワークに慣れている私は、コンポーネントやプラグインのない生活を想像するのが怖かったです。 一般に、Drupalで過ごした時間は短命で、非常に非生産的でした。 そして、少なくとも長い間、最大の利益として彼女と別れることにしました。
この分離は非常に長いことが判明しました。 Drupalに戻るのは昨年の終わりで、バージョン番号7が大衆に突入し続けたときだけでしたが、2番目のイニシアチブによって、私には未知の深刻さと深刻さを考えるようになりました。 たぶんその理由は標準的なテンプレートだったのでしょう。「服を着て会う」ことを誰もまだキャンセルしていないからです。 しかし、私は自分自身を圧倒し、勇気を得て、このCMSをもう一度インストールしました。 今回は、前回よりも少し深くして、このシステムがプログラマーにとって本当に理想的かどうかを理解することを計画しました。 すぐに私はプログラマーではないこと、そして私のphpの知識が多少とも高度なゲストブックに十分であることを予約します。これは友人の厳しい指導の下で書きました。
今回、Drupalを学習するための適切なアプローチは、Drupalがどのように機能するかを理解し、おなじみのCMSとの類似点を探すことだと判断しました。 基本的な概念に精通すると、すべてが頭の中に収まり始めました。 コンポーネント、モジュール、プラグインがあったJoomlaステレオタイプを折りたたみました。 概念では、再構築して類推を見つける必要がありました（例：Joomlaモジュール≤Drupalブロック、Joomlaコンポーネントとプラグイン≤Drupalモジュール）。 それほど時間はかかりませんでした。 私の同志によれば、柔軟性と全能性を隠していたDrupalの強みを認識する必要がありました。
浸漬
かつて私の友人「Drupalist」は、Viewsモジュールの複雑さを学べば、サイト上で情報を出力したり提示したりすることに関して、実質的に不可能なことは何もないと教えてくれました。 私はその言葉を受け入れ、しばらくして最初の問題で彼に目を向けました。 当時、私にとって問題は解決不可能だったことを覚えており、このDrupalは私には複雑すぎると友人に不平を言いました。 二度と考えずに、彼は人気のあるCMSの面白い学習曲線を送ってくれました。
長い間、私はこの写真を見て、この曲線に自分自身を見つけようとしました。 たぶん、サミットを征服することなく、すでに倒れた人々のせいかもしれませんか？ もっと注意深く調べてみると、これは真実の一粒の漫画写真に過ぎないことに気づきました。 先に進む気分で、私は悲観的な考えを捨て、解決策を探し始めました。 Drupalの公式Webサイトで質問に対する回答のほとんどを見つけました。 ロシア語のフォーラムは自分自身に悪い印象を残しました。 無料で支援する人はほとんどいません。 それにも関わらず、それでも、視野を広げる非常に有用な情報を共有する人がいます。
すべてのステレオタイプを捨てて、私はより深く潜り始めました。 より多くの場合、私は自分のために設定されたタスクのソリューションを独自に見つけ、ビュー、ルールモジュール、さまざまなテーマなど、Drupalの魅力の多くを認識しました。 これらのトピックを100％ではありませんが知っていたので、コーディングをしなくてもDrupalで多くのことができることを理解しました。 このようなCMSに出くわすすべての人にそのような理解がもたらされないのは残念です...
Drupalはプログラマ向けではありませんか？
かつて、ある友人が、ある厳しいプログラマーによってDrupalの助けを借りて作成されたサイトの処理を手伝ってほしいと頼まれました。 私は喜んで助けの要請に応じましたが、サイトにアクセスできたので、少しショックを受けました。 サイトは通常のアプローチを使用せずに作成されました。メニューについては、そのサイトの作成者がモジュールを作成しました。 分類は分類法を使用せずに行われました。 多くの情報ブロックがテンプレートに直接縫い付けられました。 多くのphpプログラマーは、Drupalの可能性を最大限に活用せずに、Drupalを数パーセントしか使用していないことに気付きました。 残りはモジュールに、時にはテンプレートに直接、時にはファイルを追加します。これらは本質的にDrupalのコアです。
これが必要ですか？ あなた自身の何かを書くために？ 時々そうですが、これはめったに起こりません。 ほとんどのタスクには、すでにテストされ、多くの作業プロジェクトに正常に適用された優れたモジュールがあります。 もちろん、モジュールがまだ書かれていないタスクに出会うこともできますが、この場合でも、タスクを達成するためのアプローチを変えることで何かを思いつくことができます。 多くの場合、不可能なタスクを少し異なって見る必要があり、ソリューションが表面にあり、独自の何かをフェンスする必要がないことが明らかになります。
当然、プログラミングなしではできないタスクがありますが、カーネルコード、テンプレート、またはサードパーティモジュールに触れることなく、これを正しく行うことができます。 Druaplでは、箱から出してすぐに、Webインターフェースを介して直接プログラムすることができます：マテリアル内、ブロック内、またはビュー内。 私の意見では、このようなコードは検出と保守がはるかに簡単です。
おわりに
上記から、特定の問題を解決する方法は通常1つではないことは明らかです。 そして、プログラマーが使用するものには場所があります。 しかし、私の質問は残っています：なぜ、親愛なるプログラマーに、Drupalや別のCMSが必要なのでしょうか？ フレームワークに切り替える時が来たのかもしれませんが、もっと頻繁にそこにコーディングする必要があります。