drupal8 : URLをサブディレクトリに転送じに生じたエラー及び対処法

drupal
system_management

レンタルサーバーでDrupal8のURLをサブディレクトにリダイレクト

  • レンタルサーバーでの複数のURLをそれぞれのディレクトリに振り分け設定が難しい場合があります。
  • .htaccessでそれぞれのURLをルートディレクトからサブディレクトリにリダイレクトすることがよく使われます
  • ここで、.htaccessより2drills-d8サブディレクトリにリダイレクトの記述は以下のよう 
    RewriteEngine on 

# automatically load sub-directory: 2drills-d8 <- 2drill.local
#site
#RewriteCond %{HTTP_HOST} ^2drill\.local$ [NC]
RewriteCond %{HTTP_HOST} ^2drill\.local$ [NC]
RewriteRule ^$ 2drills-d8/index.php [L]

#files
RewriteCond %{HTTP_HOST} ^2drill\.local$ [NC]
RewriteCond %{DOCUMENT_ROOT}/2drills-d8%{REQUEST_URI} -f
RewriteRule .* 2drills-d8/$0 [L]

#url's
RewriteCond %{HTTP_HOST} ^2drill\.local$ [NC]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ 2drills-d8/index.php?q=$1 [L,QSA]

     

  • Drupal8のインストールは無事できました

サブディレクトリよりページがリダイレクト時ににエラーが発生

  • Drupal8インストール直後に、サブディレクトリがURLに反映されています。例：ログインページ→http://2drill.local/2drills-d8/user/login
  • サブディレクトリをURLから削除して、ログインページにもアクセスができます
    • 各リンクのサブディレクト名を消すために、DB上ですべてのキャッシュを消す必要があります 
      TRUNCATE `cache_bootstrap`;
TRUNCATE `cache_config`;
TRUNCATE `cache_container`;
TRUNCATE `cache_data`;
TRUNCATE `cache_default`;
TRUNCATE `cache_discovery`;
TRUNCATE `cache_dynamic_page_cache`;
TRUNCATE `cache_entity`;
TRUNCATE `cache_menu`;
TRUNCATE `cache_page`;
TRUNCATE `cache_render`;

       

  • サブディレクトなしで、ログインページ（http://2drill.local/user/login）でログインをすると、以下のエラーが発生サブディレクトありのエラー
    • Redirects to external URLs are not allowed by default, use \Drupal\Core\Routing\TrustedRedirectResponse for it.
  • このメッセージを調べてみたら、coreのRedirectResponseSubscripber.phpから出たものです
    リダイレクト時にエラーが発生
  • 原因：  $safe_response = LocalRedirectResponse::createFromRedirectResponse($response);　に、LocalRedirectResponseに、サブディレクトが含まれると、エラーが発生します
  • ここの記述から見ると、LocalRedirectResponseを使用せず、TrustedRedirectResponseを使用すれば、エラーが発生しないです

サイトの設定ファイル（settings.php）でサブディレクトを消去

  • coreのRedirectResponseSubscripber.phpを修正することができます
    • LocalRedirectResponseを使用せず、TrustedRedirectResponseを使用するように修正
    • この修正が次のDrupal8更新時に消されるでしょう（Drupalのアップグレード）
    • アップグレード都度にこの修正を行うのはナンセンスです
  • Googleで同じ問題の対処法を調べてみたら、サイトの設定ファイル（settings.php）にサブディレクトを消去する方法があります
    • ＄GLOBALS['request']のSCRIT_NAMEにあるサブディレクト名を消す記述を追加します 
      if ( 
		isset($GLOBALS['request']) && 
		preg_match('/\/2drills-d8/', $GLOBALS['request']->server->get('SCRIPT_NAME') )
	) {
	$GLOBALS['request']->server->set('SCRIPT_NAME', preg_replace('/\/2drills-d8/','',$GLOBALS['request']->server->get('SCRIPT_NAME')) );
}
    • Drupalのアップグレード時に、サイトの設定ファイル（settings.php）が更新されないので、毎回修正する必要はありません

 

drupal
development
drupal
performance optimaization

Drupal サイト構築時にコンテンツ構造、表示設定、機能構成が重要なポイントになる

Drupalが非常に柔軟性、拡張性のあるフレームワークである。それこっそ、サイト構築時にいろいろな構造を注意しないとパフォーマンス問題になる。

  • どのようにコンテンツを構成するか
  • どのように表示を設定するか
  • どのように機能を構成するか

​コンテンツを構成する

コンテンツがサイト構成の一番基本な要素なので、コンテンツ分析、分類、構成するのはサイト構築の第一歩である

  • フィールド(Field)とコンテントタイプ(Content Types)を一緒に検討する。
  • フィールド/コンテントタイプの種類、数が少ないほうがいい

以下はよくある問題と解決案

  • 問題：　コンテントタイプ(Content Types)が多すぎる.
  • 結果：　コンテンツを作成時に何を使うかは迷う
  • 例：　コンテントタイプ(Content types) “news” と “article,” 　⇦　この二つタイプの大半は同じ
  • 解決：　コンテントタイプ作成基準を明確し、できるだけ再利用する。

 

  • 問題：　各コンテントタイプに新しいフィールド(Fields)を定義する
  • 結果：　リソースの消耗、パフォーマンス問題になる
  • 例：　二つのフィールド： school city and teacher city　⇦　性質が同じ、再利用可能
  • 解決：　フィールドの再利用と作成基準を明確化する　⇦　フィールドの再利用に賛否両論があり、データベースなどに左右される

 

 

  • 問題：　コンテントタイプにノード(nodes)がない
  • 結果：　必要なないコンテントタイプがサイト構成に複雑になる
  • 解決：　コンテントタイプ作成基準を明確し、できるだけ再利用する

 

表示の設定

DrupalがViews, Panels, and Context modulesなどのモジュールを利用して、コンテンツを違う場所、フォーマットで各種表示には強力なツールである。

  • 表示構成をよく計画する
  • 表示の最適化と再利用する
  • ロジックとプレゼン層をしっかり分ける
  • 単一、基本のthemeから表示の仕組みを学習する


以下はよくある問題点と解決案

  • 問題：　すべてのリストに一つビューで対応
  • 例：　別々のビューで仕事場所がロンド、パリ、ベルリンを表示する
  • 解決：　Contextualフィルタ、Selection Rulesなどを利用して、同じビューで違うコンテンツを表示する

 

  • 問題点：　テンプレート(.tpl)、データ定義にロジックのPHPコードが混入される
  • 解決：　Drupalのファイル、モジュール構造を理解して、正しいカスタマイズを行う

 

サイトの機能を構成

サイトの目的、必要な機能を計画し、必要最低限のモジュールの採用と一部分のコーティングでサイトのパフォーマンスを向上する

  • サイトの機能をよく計画し、機能の重複を減らす
  • 機能により必要最低限のモジュールをインストールする
  • 一部分の機能しか使わないモジュールを改造して、シンプルなモジュールにする
  • 重要なモジュール(例：Views、Panelsなど)がエクスパートに作成されので、そのままにして改造しないこと
  • Drupalのコード改造基準、コーティング基準などをよく理解する

以下はよくある問題と解決案

  • 問題：　インストールされ、有効化したモジュールが多すぎる（例：200以上、各種試しモジュールを含め）
  • 結果：　パフォーマンスの問題になる
  • 例：　最初が多言語対応検討だが、実際に日本語しか表示していていない(多言語対応モジュールがインストール、有効化されたまま）
  • 解決：　不必要なモジュールを無効化、アンインストールを行う。ローカル環境でテスト後に本番環境にモジュールの導入

 

 

  • 問題：　ユーザーのロール(権限設定)が多すぎる
  • 結果：　サイトのメンテナンス性とセキュリティチェックが複雑になる
  • 例：　最初はより多いロールを検討してサイトを構築したが、結局多いロールが使用されていない。またはロール間の明確な区別をつかない。
  • 解決：　ロールと権限を分析し、グルーピングする。ルール、権限を階層化して、継承する

 

  • 問題：　カスタマイズしたコードが実際にあるモジュール(contrib module)にその機能が含まれている
  • 解決：　カスタマイズする前に、機能相似のモジュールのコードをよく読んで、コード上に参考できる部分をコピーして利用し、機能重複を避ける

 

  • 問題：　コーアモジュール、contrib modulesを改造する
  • 結果：　アップデートしたらサイトの動作が変わる
  • 解決：　hooksを利用して、コーアモジュール、contrib modulesに提供されていない機能をカスタマイズする、または動作を変更する(sites/pine/modulesに作成)

 

  • 問題：　違うhooks、またはDrupal API　を使用してしまった
  • 例1：　ある特定なページでhook_initを使用して、すべてのページがロードする際にこの関数を呼び出してしまう
  • 例2：　nids、tidsとvidsなどのidを直接にコードに挿入してします。将来これらのコードが変わった場合ページが表示されなくなるし、発見するのも難しい
  • 解決：　Drupal API、構造、コーティングルールなどをよく理解して、慎重にカスタマイズする

 

drupal
development
module usage

Drupal共有ソースサイトへの移行計画

  • Drupal7で複数のサイト（ドメイン）を構築しました。それぞれのバージョンアップ、ソースのバグ管理に手間がかかります。
  • 一つの共有ソースにすれば、Drupalのバージョンアップ、ソースのバグ管理に効率は良いと考えられています
  • 例：以下イメージのようにサイト移行
  • サイト移行時の両側の違い：
    • Drupalのバージョンは同じ：７
    • モジュール：共有ソース側の方が多い、また同じモジュールに違うバージョンが存在している可能性があります
    • DB：移行先に各サイトは別々のDBで違うコンテンツを有します

サイト移行の一番大きな問題点：メディア保存のフォルダが変わる

  • サイト移行にどんな方法を使っても、元サイトのメディア（例：写真など）保存フォルダー（sites/default）が、共有ソース側に別名のフォルダ（それぞれのサイトのメディア保存フォルダ）に変わります
  • 元サイトにあるメディア（写真、ファイル、ビデオなど）のパスが共有ソース側に移行先フォルダ名で書き換えなければならないです

移行方法１：共有ソース側で新規サイトを構築して、Featureモジュールで旧サイトの設定、Node Exportモジュールでコンテンツを移行します

  • 共有ソース側で以降先のフォルダ（例：pine ⇒ sites/pine）を作成します
    • defaultフォルダ（sites/default）にあるdefault.settings.phpをコピーして、移行先のフォルダ（pine）にペストし、settings.phpに名前を変更します
    • sites.php（sites/sites.php）設定ファイルに移行元のドメイン名とフォルダ名を関連つけます（設定方法：「Drupalのソースを共有する複数サイトの構築」をご参考）
  • 設定されたドメイン名で新サイトへアクセスし、Drupalのインストール手法で新しいサイトを構築します（新しいサイト、移行元のものはなにもない状態）
  • モジュール（Feature）で元サイトの設定を移行します(Drupalのモジュール（Feature）を用いてサイト間のデータ移行/開発管理を行いますをご参考)
    • すべての元サイト設定移行はできません。例：テーマの設定が最初からやり直しが必要はあります（結構手間がかかる作業）
  • モジュール（Node Export）でコンテンツ（例：Article）を元サイトから出力して、移行先にインポートします
    • 大量なコンテンツがある場合、Drushのコマンドで出力したほうが良いでしょう
    • コンテンツに含まれている画像、ビデオ、ファイルなどのパスを移行先のフォルダ名に合わせて変更しなければならない（今回：sites/default ➡ sites/pine すべてのパスを検索して、変更）
  • 元サイトのメディア保存フォルダ(sites/default)にあるすべての内容（settings.php除外）を移行先にフォルダ（sites/pine）にコピーします
  • 移行先でファイルシステム設定画面（ホーム » 管理 » 環境設定 » メディア » ファイルシステム）の元サイトと同じファイルパス設定を行います

移行方法２：元サイトのDBとメディア保存フォルダを移行先にコピーします

  • 元サイトのすべてのものをそのままで移行先にコピーできれば、一番楽です
  • 重要なのは、両サイトが側のDrupalバージョン、モジュールバージョンが完全一致していれば、うまく行きます
    • バージョンが合わなければ、移行後にサイトからエラーがでて、完全に動かなくなりことがあります（以下のエラー例で、実は一つのモジュールバージョン差で引き起こされています）
    • 移行する前にモジュールのバージョン合わせに十分に気を付ける必要はあります
    • もちろん、移行先にでのモジュールバージョンを変えると、他のサイトにも影響を与えるので、調整が必要となります
  • 移行する前に、移行先と移行元のDB、メディアファイルフォルダ（sites/default）の内容をバックアップします（うまく行かなければ、バックアップで戻します）
  • 移行するサイトのすべてDBテーブルをSQL文に出力（MySql：mysqldump）します
    • 出力されたファイルにあるすべてのメディア保存フォルダパスを移行先のフォルダパスに書き換えます（sites/default ➡ sites/pine）
    • もしドメイン名も変わる場合、新しいドメイン名で古いのを書き換えます
  • 移行元のメディア保存フォルダにすべての内容（settings.phpも含む）、移行先にのメディア保存フォルダにコピーします（sites/default ➡ sites/pine）
  • 移行先でファイルシステム設定画面（ホーム » 管理 » 環境設定 » メディア » ファイルシステム）の元サイトと同じファイルパス設定を行います
  • ブラウザで移行先のページにアクセスし、管理者権限でデータベース更新（http://your-site-domin/update.php）を行います（Drushでも更新可能）

結論：新規サイト構築はエラーが少ないが手間がかかります。DBコピーは便利だがエラーが出やすいです。

  • 安心で、きれいに移行する場合新規サイトを構築したほうが良いでしょう。多少手間がかかっても、難しいことは少ないです
  • DBコピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります