DrupalからYiiにアップグレードする7つの理由

Drupalが好きな理由に基づいています。

JiLiZARTのリクエストに応じて公開（翻訳、私も理解しているように、彼も）。

オリジナル： erickennedy.org







記事の日付は1年前なので、翻訳の期間は保存されます





Drupal 7は間もなくリリースされるため、多くの組織はDrupal 5または6からアップグレードするかどうかを決定する必要があります。Drupalは、多くのサイトを構築し、多くのコードを記述せずに迅速に新しいサイトを作成する必要がある場合、または単に必要な場合に適していますステロイドのブログ。



Drupalでの作業は、伝統的な家を買う余裕がない場合、 倍幅 （カードの家）に住むようなものです。 Drupalで構築され、フルタイムの開発者を使用できるほど成長したサイトがある場合は、サイトをYii PHPフレームワークに移行する必要があります（PHP嫌いな人はOnionに従い、Django Pythonフレームワークを使用できますが、より多くの時間、言語とフレームワークの変更）



私は2010年4月30日にDrupalからYiiに切り替えたサイトのテクニカルディレクターです。 当時、私たちが移籍について話し合っていたとき、正しい情報を見つけることは困難でした。Yiiに関する本すらありませんでした。 DrupalからYiiへの切り替えについての言及がいくつかありましたが、落ち着いておくのに十分なデータが含まれていませんでした。 Yiiが高度に最適化されたDrupalインストールよりも遅くなるのではないかと心配していたため、30日間でサイトのコアの20％（すべての機能の80％を提供しました）を書き換えることにしました。 フレームワークの生産性と生産性をテストするのに最適な方法のようです。Yiiが1か月の作業を経ても結果が出ない場合は、いつでもDrupalに戻って新しいデータを戻すことができます。



Yiiは、150,000ノード（それぞれ書き換えられたURL）と1日あたり50,000人の訪問者を持つDrupalサイトよりもはるかに高速でした。 はい、私たちはこの30日間（そして次の15日間）狂ったように働きましたが、それだけの価値はありました。 Yiiでの開発時に、Drupalで遅いクエリをトラップして修正するために使用していた時間を使用していました。 Yiiの本当のメリットは、後でサイトを再設計したときに現れました。

Yii MVCでは、Drupalの数十に対してレイアウトファイルを2つだけ変更しました。



1年前に交差しなかったことを申し訳ありません。 学んだことは次のとおりです。

1. Drupalは最初から始めるのに最適な方法ではありません 。 Drupalの主なセールスポイントは、「 なぜ独自のCMSを作成するのですか？」です。 」 多くのWeb開発者と同様に、すべてのWebアプリケーションを最初から（ 1999年と2000年に ）作成し、認証、検証、SQLインジェクションなどを処理するための独自のコードを書くのではなく、アプリケーション固有のビジネスニーズに焦点を当てる機会に感謝しています。
   
   2007年の初めに私が見つけた会社にはDrupalサイトのプロトタイプがあり、Ruby On Railsにドロップする前にDrupalで何ができるかを見る準備ができていました。 Rubyの流行は、1997年のJavaの流行を思い起こさせました。 私は1997年から99年にかけてWebExの競争相手のインターンでしたが、サーバーハードウェアとVMの最適化がスケーラビリティを可能にする前にJavaでサーバーを記述し始めたため、生産性が低下しました。 PHPはFriendsterとFacebookのリメイクで実証されており、Rubyでスケーラビリティの問題が発生した場合、ユーザーはクジラの失敗を見たくありません。
   
   
   
   もちろん、PHPで各行を自分で記述するよりもDrupalから始める方が簡単です。 しかし、2008年に開始され、 2009年にテストされたPHP 5フレームワークがたくさんあります。 PHP開発者は、現在Webアプリケーションを作成し始めています（そして今後もサイトで作業を続けます）。フレームワークを選択するか、PHPライブラリ（PECLまたはPEAR）を使用してゼロから開始します。
   
   
2. Drupalフレームワークなら、 Ruby Goldberg Machineのみがそれを愛します （ 複雑な方法で単純なアクションを実行するMachine ）。 Drupalは、PHPプログラミングの知識がなくても拡張できるように設計されています。 これは、単純なコンテンツでサイトを単純にスタイル設定する場合、またはトラフィックの少ないサイトがある場合に適しています。 フォームの変更と機能の追加のためにフルタイムでモジュールを作成する場合、フレームワーク上で作成するよりも、必要のないDrupal機能の抑制により多くの時間を費やすことになります。 Yiiには反対のアプローチがあります。Rubyon RailsのようなORMが十分に高速で、MySQLに書き換える必要があるクエリの10％のみを最適化する場合は、 Rubyを使用できます。
   
   
3. コミュニティが提供するモジュールは、 特徴主義 （「詐欺」？）になりやすく、過度の複雑さに起因するエラーが発生します。
   
   Drupalには非常に多くのcontribモジュールがあります。フルタイムの開発者がいる場合は、追加モジュールの一部を自分のものに同化するために、おそらく私たちがそれをどのように行うかを決めるだけです。 Drupalの画像編集およびキャッシングモジュールは、代表的な例です。 モジュールは一般的な問題を解決するように設計されているため（任意の数の他のモジュールと連携できるように！）、 決して使用しない機能が多数含まれています 。 私たちの場合、ImageMagickを使用して取得するいくつかのサイズのプレビューを作成する必要があります。 これを行うには、2つのデータベーステーブルにサムネイルを作成する実際のコマンドの代わりに、それぞれが多数のPHPファイルを持つImageAPI、ImageMagickのImageAPI、ImageCache、ImageCache UIの4つのモジュールを含める必要がありました。 モジュールチェーンの一部を更新するときに問題が発生した場合、必要なことだけを行うのではなく、理由を見つけるのにかなり時間がかかります。
   
   
   
   Yiiには、画像を操作するための拡張機能（Kohanaから適応）もありますが、必要のない機能（回転！フリップ！）が含まれており、ImageMagickとGDを透過的に切り替えるように設計されているため、複雑です（GDには2MBを超えるファイルの問題があります） ） これにもかかわらず、プレビューが存在しない場合、RewriteRuleを使用してその場で画像のサイズを変更することはできません。
   
   そこで、画像専用のサーバーでRewriteRuleリクエストを処理し、シールドシェルコマンドを送信してバイナリに直接変換するindex.phpファイルを作成しました。 これは、これらのRewriteRuleリクエストがYiiのindex.phpファイルに影響を与えないことを意味し、オーバーヘッドを削減し、画像のサイズ変更とキャッシュのリセットに必要な時間を削減します。 これは、バイナリへの1回の呼び出しで渡される引数を取るphpの1ページにすぎず、ImageMagickが更新されているかどうかのサポートとテストがはるかに簡単です。
   
   
4. DrupalにはPHP 4の手荷物互換性が含まれています。 かつて、PHPフレームワークを検討することにしたとき、私はすぐに100％PHP5 OOPフレームワークが必要だと気付きました。 フックシステムがOOPアプローチよりも優れていると主張する人はあまりいません。 Drupal 7には、CodeIgniter 1.0やその他の古いPHPフレームワークのようなPHP5が必要ですが、依然として多くの互換性があります。 誰がそのような荷物を望んでいますか？
   
   
5. Drupal 6または7でDrupal 5サイトの速度を低下させたくないですか？ 時代遅れのjQueryに対処したくないですか？ ほとんどのサイトでは、これは正常です。 GoogleとMicrosoftは、ユーザーが高速サイトに忠実であることを示しているため、速度を重視しています。 2009年、Drupal 6が安定したとき、測定可能な速度の利点のために、Drupal 5にとどまりました。 問題は、Drupal 5にjQuery 1.0が含まれていることです。 contribモジュールをインストールして、jQueryを1.2にパッチします（およびそれを参照するDrupal関数を更新します）が、このバージョンも古いです。 jQuery 1.3xとDrupal 5は忘れてください。
   
   
6. DrupalのDrupal Field /（CCK）APIはあなたを夢中にさせます 。 これはDrupal 7コアの一部です 。 $ node-> field_ip [0] ['value']を使用できるのに、$ node-> ipを使用する理由。 また、2つの異なるタイプのコンテンツに同じ名前のフィールドを持たせたい場合、CCKはそれらを驚くべき列名（field_ip_value）を持つ独自のテーブル（content_field_ip）に入れます。 もちろん、Drupalはノードのロード時にこの混乱を理解できますが、それを見るのは良くありません。 MySQLクエリでは、追加のCCKテーブルをすべて処理するために多くのLEFT JOINが必要です。また、スロークエリログで頻繁に終了する不要な複雑なクエリも必要です。 最終的に、これらすべての低速クエリを最適化しようとするのにうんざりし、CCKを削除することに決めました。これにより、PHPフレームワーク、そしてYiiに至りました。
   
   データをYiiに移行するには、Drupalにとどまっている間にCCKモジュールを削除するのと同じ時間がかかりました。 それでも、Drupalが内部のニーズに使用する追加のテーブルをすべて使用せずに、クリーンなデータベースで開始することができました。 古いデータベースには173個のテーブルがあり、新しい54個にはありました。
   
   
7. DrupalはYiiよりもはるかに遅いです。
   
   
   
   ボード上のmemcachedとAPCでALLをキャッシュし、すべての遅いリクエストを書き換えると、Drupalは拡張可能です。 l（）を呼び出すたびに別のデータベースクエリが生成されるため、すべてのリンクにSEOアドレスを使用する場合、キャッシュは特に重要です。 したがって、平均ページには50以上のリクエストがありますが、Yiiでは3〜5です。 移行後、Googleウェブマスターツールによると、平均ダウンロード時間は163ミリ秒から63ミリ秒に短縮されました。 さらに良いことに、Yii + APCは非常に高速であるため、memchachedを使用する必要がなく、コードと操作を簡素化できます。
   
   

私たちのサーバー統計は、それ自体を物語っています。 訪問者（Apacheプロセス）からの同時リクエスト数が同じ場合、データベースとCPUの使用が低下しました。 メモリ使用量はほぼ同じままです。 過去1年で、トラフィックは月に60％増加し、1か月あたり150万人の訪問がありましたが、MySQLの負荷は66％減少しました