• 学ぶのが難しい
• 高いデータベース負荷
• 文盲構造
• OOPの欠如
• 奇妙なキャッシュ
• モジュールの非互換性
• 面倒なカスタマイズ

原則として、それは同じですが、詳細であるため、さらに読むことはできません。

背景

Drupalの学習を開始してから3か月が経過しました。 勉強しながら、Drupal 6で強力で堅牢なアプリケーションを構築する本を読んで、Drupal 6のモジュール開発を学び、Pro Drupal開発を学びました。 また、使用中は、Drupal'aとそのAPIのドキュメントを参照する必要がありました。 9月末頃、母国の大学のウェビナーでDrupalの講義を行い、Drupalとは何か、Drupalで何ができるのか、Drupalで学んだことについて話しました。



多くの情報源で、私はフレーズや図に出くわしました。その本質は、もう少しすれば、Drupalが開発のための理想的なツールになるということでした...待ちませんでした、病気になりました！

基本的な問題

すでにセミナーでレポートを読んだとき、多くの人が書いて話し合っているDrupalの問題をいくつか特定しました。研究の複雑さとデータベースの高負荷です。 私の報告には、すでに約1年間彼をいじくり回して、彼を非常に嫌っていた男性が出席しました。 彼は、データベースの負荷はほぼ最悪のDrupalパラメーターであり、ほとんどすべての人にとって損失であると述べました。 そして、多数のユーザーに関する美しい数字はすべて誇張されていますが、実際には、Drupalは1日あたり1000人を超える訪問者を保持できません。 drupal.orgについての私の発言に対して、彼は笑っただけで、drupal.orgにはすでに非常に多くのパッチが詰め込まれていて、drupalからは名前だけが入っていると言っていました。



しかし、私はDrupal'eでプロジェクトを終了しなければならなかったので、ひらひら続けなければなりませんでした。 深くなるにつれて、レポートを作成したときに思っていたよりも多くの問題がDrupalにあることに気付き始めました。 最初で最も頻繁に不安になったのは、Drupalキャッシュです。 私はまだそれがどのように機能するか理解していません。 たとえば、モジュール内の関数を変更すると、実行される場合とされない場合があります。 これは、管理インターフェイスから利用できるすべてのキャッシュ設定がオフになっているという事実にもかかわらずです。 モジュールの機能の追加と削除により、状況はさらに悪化します。 追加するときに「お気に入り」キャッシュを更新することが依然として簡単な場合、関数を削除すると、致命的なエラーがポップアップすることがあります。 それを扱うことは常に可能とはほど遠く、多くの場合、すでにペンでデータベースからすべてのキャッシュデータを削除する必要があります。



今後、この問題は現在研究中のシンフォニーには存在しないと言います。 その中には環境があります（おそらくロシア語では「環境」になりますが、もしそうであれば公式に間違って翻訳されているかもしれません！）、大まかに言うと、各環境はサイトの特定の構成です。 デフォルトでは、開発環境と本番環境（もしあればテストもあります）、それぞれ開発と本番（つまり、開発とリリースのための環境）があります。 devでは、ほとんどすべてのキャッシュが無効になっているため、何が起こったのかを推測するために髪を引き裂く必要はありません。構文エラーまたはキャッシュが更新されていません。



余談：一般に、おそらく、上記で述べたことも、以下で述べたことも、唯一の真の真実ではないでしょう。 私の場合のDrupalのマイナス面は、その研究に付随するいくつかの要因とも関係しています。現在、Drupal 6の研究を開始しました。現在、ほとんどの本は書かれていません。 最後まで本を終わらせなかった プロジェクトが突然陥り、徹底的なピッキングの時間はありませんでした。



Drupalの2番目の問題は、テンプレートのカスタマイズです。 私にはこのように思われました。レイアウトの適切な場所に挿入する必要がある変数のセットを提供します。 しかし、これはそうではないことが判明しました。 まず、各Drupalモジュールは独自のhtmlコードを提供できます。 Drupalにはいわゆるテーマ機能（つまり、標準出力をオーバーロードする機能）がありますが、最後に到達するのは必ずしも簡単ではありません。コンテンツを提供します）htmlの一部は既に変数にあります。 第三に、htmlが関数から返されるようにどこで見られますか？ その結果、完全に読み取り不能なコードが作成されます。



Drupalのモジュールについて言及する価値はあります。 標準モジュールの構造は次のとおりです。

• module_name.info（ モジュールに関する情報はここに保存されます ）
• module_name.install（ モジュールのインストール方法に関する情報はここに保存されています ）
• module_name.module（ モジュールコードはここに保存されています; ALL！ ）

module_name.moduleファイルのサイズの範囲は1〜109（私の場合）キロバイトです。 最も恐ろしく巨大なファイルの場合、これは3000行のコードです。 そのようなコードを読んだり管理したりすることは可能ですか？ そして、そのような構造は、このCMFの標準によって採用されています。

より深く掘る

これは、Drupalでの作業への道のりで待っていた問題の始まりに過ぎません。 次の問題は、モジュールの非互換性です。 先駆者によって書かれ、コミュニティによって推奨されていないモジュールからの互換性を期待すべきでないことは明らかです。 しかし、私は完全に完成し、実績のあるモジュールを入れました：

• 開発-開発者向けの一連のユーティリティ（開発から開発）は、特に、メニューにクリアキャッシュボタンを導入します（これが必要な理由を上記参照）
• FCKeditor-WYSIWYGエディター
• TinyMCEは別のWYSIWYGエディターです。なぜ次の2つを読む必要があるのですか
• ローカリゼーションクライアント-Drupalにはロシア語への通常の翻訳がないため、インターフェースをローカライズするための便利なAjaxクライアント
• Ubercart-オンラインストア

FCKeditorとLocalization Clientの間で最初の非互換性が明らかになりました。 エディターを貼り付けるページに2つ以上のテキストエリアがある場合、ページは気まぐれになり始め、保存を拒否しました。 まあ、TinyMCEをインストールしましたが、このエディターへの愛を込めて、サイト管理の一部として機能させることができませんでした。 FCKeditorとは異なる構成になっているためです。 TinyMCEを有効にするには、エディターが表示されるページのパスを指定する必要があります。 また、FCKeditorはid'shnikami textareaによって構成されます。 その結果、一方にはFCKがあり、もう一方にはTinyMCEがあります。 残念ながら、TinyMCEも残しておく必要がありました。画像をサイズ変更できる画像を挿入するモジュール（Imagepicker）は、それだけで機能するからです。



誰もが大好きなDevelは、後にUbercartとの非互換性を明らかにし、オンラインストアカタログのカテゴリページでプロジェクト全体を殺しました。

Drupalは開発者向けではありません

Symfonyに初めて会ったとき、Drupalの使用をやめることにしました。 作成が大好きな開発者として、Drupalではほとんどの場合、自転車のボルトを締めて、三輪車が回転し、チェーンがプラチナで作られるようにしました。 また、バージョン6が今年リリースされたという事実にもかかわらず、OOPの臭いさえありません。 開発者はこれを非常に簡単に説明し、文字通り次のように述べています。

「はい、DrupalにはOOPはありませんが、その原則の多くは私たちによって実装されています。原則として、あなたは自由に感じます。」 しかし、違いはまだ非常に顕著です。 そうでなければ、アカウントは長い間発明されてきたので、なぜ電卓を使用する必要がありますか！

しかし、それほど悪くない

練習では、コインには2つの側面があることが示されています。 すべてが非常に悪い場合、Drupalのような悪いものを使用する人はいませんでしたが、彼らは使用します。 Drupalは、Habra（Swabrashvabraの例を参照）などの強力なリソースを非常に迅速にデプロイする必要がある人に適していますが、カスタマイズとその機能にあまり煩わされません。 ただし、使用するモジュールの機能の境界を超えると、問題が発生する可能性があることに注意する必要があります。その一部は上記で説明しました。



この記事は、CMF Drupalについての著者の個人的な意見であり、その経験の要約です。 気分を害した場合は蹴らない



upd：カルマのプラス記号のおかげで、Drupalブログに転送するには少し足りませんでした

upd2： FCKeditorとDevelの間に最初の非互換性が現れるというフレーズに少し嘘をついていることがわかりました。DevelではなくLocalization Clientがあります。 おaびします！