drupal8 : Adminアカウントのパスワード忘れの緊急対応方法

タグ

system_management

Adminアカウントのパスワード忘れ

Adminアカウントのパスワード忘れた場合、「パスワード再設定」（/user/password）画面でAdminアカウントの名前か、メールアドレスを入力して、パスワード再設定リンクを発行してもらえます
Adminアカウント名、Mailアドレスが忘れた場合に、直接にDBへアクセスして、users_field_dataテーブル上に記録されたアカウント名、Mailアドレスを参照することができます
アカウント名、またはMailアドレスを「パスワードを再設定」フォームに入力して、送信ボタンをしても、パスワードの再設定メールが来ないケースもあります。このケースでは以下の方法で対応します

直接にパスワードを生成してDBに保存

DrupalのパスワードをHashをかけて暗号化しています。Hashしたパスワードでは複合化することはできません
以下のステップで、新しいパスワードをHashで暗号化してDBに保存、キャッシュのクリアをすればログインはできるようになります
- Webサーバーにログインして、Drupalのルートディレクトリに入り、以下のコマンドで新しいパスワードのHashコードを取得
```
php core/scripts/password-hash.sh "NewPassword"　// 新パスワードを NewPasswordに
```
- 生成されたパスワードのHashコードをコピーして、users_field_dataのAdminユーザーのpassフィールドに更新、保存します
- DBにあるcache_entityテーブルのデータをクリアします
- DBにあるfloodテーブルのデータをクリアします（ログイン失敗情報のクリア）

シリーズ記事一覧

記事カテゴリ

タグ

bug

module

Drupal8がエラーをキャッチしないことがよくあります

デバッグモードでないと、いろいろなエラーがキャッチされなく、そのままスローされてしまい、システムログファイルにも残らず、わからなくなります
- デバッグモード：例、xdebugを有効化にして、xdebug.show_exception_trace = true　を設定すればエラーがDrupalの画面に表示されます
例：Drupal-8.8.5のログインすると、VCCodeのデバッグモードで以下のエラーが表示されます
- Exception has occurred.
  Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[42S02]: Base table or view not found: 1146 Table '2drills-d8.flood' doesn't exist: SELECT 1 FROM {flood} LIMIT 0, 1; Array
  (
  )
- なぜか、Floodというテーブルがないようです
- Floodは、Drupal7時にあるセキュリティ関連モジュール：Floodのことから出たと思います。Drupal8が最初このモジュールをコアーに編入したが、いつの間にかこれモジュールをコアーから外したようです。外した時に、コアーのところに、Floodモジュールのコードがそのまま残っていて、Floodロジックが作動したときに、エラーが発生しました。

アンキャッチされたエラーがそのまま放置か、関連モジュールの導入

この問題では、関連モジュールの動作でエラーを引き起こしましたが、そのままにしてDrupal8に問題はなさそうです
- エラーをスローしたが、最後ではキャッチしていないため、なんの問題を生じませんでした
上記モジュール：Floodがコアーから外されたようで、実際に別のモジュール：Flood Settingが同じ機能を果たしています。このモジュールをインストールすれば、上記エラーは発生しませんでした。
- Flood SettingsがFloodテーブルをDBに作成したので、上記エラーが発生しなくなります
- Floodのロジックは依然作動していて、パフォーマンスに影響は多少あるでしょう。このモジュールをインストールしたといって、問題解決ではありません

シリーズ記事一覧

記事カテゴリ

タグ

system_management

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

レンタルサーバーでの複数のURLをそれぞれのディレクトリに振り分け設定が難しい場合があります。
.htaccessでそれぞれのURLをルートディレクトからサブディレクトリにリダイレクトすることがよく使われます
- root directory(document_root): php ← url（http://2drill.local）がここに来る
- sub directory: 2drills-d8
- URL: http://2drill.local

ここで、.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）が更新されないので、毎回修正する必要はありません

シリーズ記事一覧

記事カテゴリ

タグ

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共有ソースサイトへの移行計画

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

シリーズ記事一覧

記事カテゴリ

タグ

別々のDrupal（バージョン７）ソースのサイトを一つ共有ソースのところにサイト移行

複数のDrupalソースで構築した複数のウェブサイトがありまして、Drupalソースのバージョンアップ、バグ管理などに手間がかかり、一つのDrupal共有ソールの元で複数のサイトを構築しました。
今回は一つのサイトを共有ソースのところに移行を行いました
移行をシンプルにするため、事前に不必要ないくつかモジュール（SyntaxHighlighter含め）をアンインストールしました
移行後に再度モジュール（SyntaxHighlighter含め）をインストールし直します

モジュール(SyntaxHighlighter)インストール後にSyntaxHighlighterライブラリが見つからないエラー

まずSyntaxHighlighterのライブラリ（3.0.83）をダウンロードしてsites/all/libraies/syntaxhighlighter_3.0.83に展開しました
通常の方法でSyntaxHighlighterモジュール（7.x-2.0）をインストールして有効化しました

以前のサイトになっかたエラーメッセージ：

Warning: file_get_contents(sites/all/libraries/flexslider/scripts/shCore.js): failed to open stream: No such file or directory _locale_parse_js_file() (/virtual/drills/public_html/drupal7/includes/locale.inc ファイル　1527行).
Warning: file_get_contents(sites/all/libraries/flexslider/scripts/shBrushPhp.js): failed to open stream: No such file or directory _locale_parse_js_file() (/virtual/drills/public_html/drupal7/includes/locale.inc ファイル　1527行)

shCore.jsがSyntaxHighlighterのライブラリにあるはずなのに、なぜかflexsliderライブラリに関連付けられました（不思議なエラー）

問題：flexsliderのライブラリに同じ名前（shCore.js）のファイルがありました

他に同じようなエラーがあるか、検索してみたが、答えはありませんでした
ソースコードを読んで自力で解決するしかないですね。幸い、複雑なモジュールではなく、SyntaxHighlighterのjsファイルをページロード時にクライアント側に渡すプログラムです
最初は sites/all/modules/syntaxhighlighter/syntaxhighlighter.install をチェックしました。44行目にあるライブラリパス取得関数：sntaxhighlighter_get_lib_location()を注目しました
関数（_syntaxhighlighter_get_lib_location()）は sites/all/modules/syntaxhighlighter/syntaxhighlighter.module にあります。さらに、ライブラリパス取得ロジックを探してみました
syntaxhighlighter.moduleの377行あたりにあるライブラリフォルダスキャン関数：_syntaxhighlighter_scan_lib_location()があります
- ライブラリフォルダスキャンの原理：shCore.jsが含まれているフォルダを取得します
_syntaxhighlighter_scan_lib_location()にwatchdogを入れて、取得したフォルダをログとして出力しました。
結果として、このパス「sites/all/libraries/flexslider/demo/js/shCore.jssites/all/libraries/flexslider/demo/js/shCore.js」を取得しました。
flexSlider/demoの下に同じ名前（shCore.js）のファイルがあるため、flexsliderライブラリに関連づけられました。

解決：demoフォルダ（「sites/all/libraries/flexslider/demo」）を消して、再インストールします

flexsliderのdemoフォルダが邪魔にになってるため、またライブラリにdemoプログラムを使用しないため、demoフォルダを消しました
SyntaxHighlighterモジュールをアンインストールして、再インストールしたら、機能正常に戻りました

シリーズ記事一覧

記事カテゴリ

タグ

やりたいこと：一つDrupalのソースで複数のサイト（複数のドメイン）を構築したいです

Drupalを用いて複数のサイト（ドメイン）を構築する場合、一つサイト（ドメイン）ごとに一つのDrupalソースで構築することがもちろん問題はありません
Drupalソースが分散すると、バージョンアップ、バグ管理などの作業が大変になります
当然一つのDrupalソースの元で複数のサイト（ドメイン）の構築が必要となります
- 一ドメイン ⇒ Drupalソース ⇒ 共有DB
- 一ドメイン ⇒ Drupalソース ⇒ 独立DB
Drupalでは複数のサイト（ドメイン）への対応をしています

sitesディレクトリの下にドメインごとの子ディレクトリを作成してマルティサイトを構築します

複数のドメイン名をDrupalのルートディレクトリに同期します（例：シンボリックリンクでドメイン名をディレクトリと同期します）
- 例： old-pine.net をDrupalのルートディレクトリにシンボリックリンクで同期します
Drupalのルートディレクトリの下に sites ディレクトリがあります。sitesの下に各メイン名に同期したいディレクトリを作成します
- 例：sites/pine を作成します
sites/sites.phpファイルでドメイン名をディレクトと同期設定を行います
- 例： 'old-pine.net' => 'pine' （書き方：ドメイン名 => ディレクトリ名）
```
 $sites = array(
    'old-pine.net' => 'pine',
 );
```
新規作成したディレクトの下にサイトのインストール設定ファイル(settings.php)の作成
- 例：sites/pine/settings.phpを作成します
- settings.phpの内容はsites/pine/default.settings.phpのコピーで良いです（サイト新規作成する場合）
追加したドメイン名でサイトをアクセスして、新規サイトができたことを確認します

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

シリーズ記事一覧

記事カテゴリ

タグ

別々のDrupal（バージョン７）ソースのサイトを一つ共有ソースのところにサイト移行

複数のDrupalソースで構築した複数のウェブサイトがありまして、Drupalソースのバージョンアップ、バグ管理などに手間がかかり、一つのDrupal共有ソールの元で複数のサイトを構築しました。
今回は一つのサイトを共有ソースのところに移行を行いました
移行をシンプルにするため、事前に不必要ないくつかモジュール（SyntaxHighlighter含め）をアンインストールしました
移行後に再度モジュール（SyntaxHighlighter含め）をインストールし直します

モジュール(SyntaxHighlighter)インストール後にSyntaxHighlighterライブラリが見つからないエラー

まずSyntaxHighlighterのライブラリ（3.0.83）をダウンロードしてsites/all/libraies/syntaxhighlighter_3.0.83に展開しました
通常の方法でSyntaxHighlighterモジュール（7.x-2.0）をインストールして有効化しました

以前のサイトになっかたエラーメッセージ：

Warning: file_get_contents(sites/all/libraries/flexslider/scripts/shCore.js): failed to open stream: No such file or directory _locale_parse_js_file() (/virtual/drills/public_html/drupal7/includes/locale.inc ファイル　1527行).
Warning: file_get_contents(sites/all/libraries/flexslider/scripts/shBrushPhp.js): failed to open stream: No such file or directory _locale_parse_js_file() (/virtual/drills/public_html/drupal7/includes/locale.inc ファイル　1527行)

shCore.jsがSyntaxHighlighterのライブラリにあるはずなのに、なぜかflexsliderライブラリに関連付けられました（不思議なエラー）

問題：flexsliderのライブラリに同じ名前（shCore.js）のファイルがありました

他に同じようなエラーがあるか、検索してみたが、答えはありませんでした
ソースコードを読んで自力で解決するしかないですね。幸い、複雑なモジュールではなく、SyntaxHighlighterのjsファイルをページロード時にクライアント側に渡すプログラムです
最初は sites/all/modules/syntaxhighlighter/syntaxhighlighter.install をチェックしました。44行目にあるライブラリパス取得関数：sntaxhighlighter_get_lib_location()を注目しました
関数（_syntaxhighlighter_get_lib_location()）は sites/all/modules/syntaxhighlighter/syntaxhighlighter.module にあります。さらに、ライブラリパス取得ロジックを探してみました
syntaxhighlighter.moduleの377行あたりにあるライブラリフォルダスキャン関数：_syntaxhighlighter_scan_lib_location()があります
- ライブラリフォルダスキャンの原理：shCore.jsが含まれているフォルダを取得します
_syntaxhighlighter_scan_lib_location()にwatchdogを入れて、取得したフォルダをログとして出力しました。
結果として、このパス「sites/all/libraries/flexslider/demo/js/shCore.jssites/all/libraries/flexslider/demo/js/shCore.js」を取得しました。
flexSlider/demoの下に同じ名前（shCore.js）のファイルがあるため、flexsliderライブラリに関連づけられました。

解決：demoフォルダ（「sites/all/libraries/flexslider/demo」）を消して、再インストールします

flexsliderのdemoフォルダが邪魔にになってるため、またライブラリにdemoプログラムを使用しないため、demoフォルダを消しました
SyntaxHighlighterモジュールをアンインストールして、再インストールしたら、機能正常に戻りました

シリーズ記事一覧

記事カテゴリ

タグ

やりたいこと：一つDrupalのソースで複数のサイト（複数のドメイン）を構築したいです

Drupalを用いて複数のサイト（ドメイン）を構築する場合、一つサイト（ドメイン）ごとに一つのDrupalソースで構築することがもちろん問題はありません
Drupalソースが分散すると、バージョンアップ、バグ管理などの作業が大変になります
当然一つのDrupalソースの元で複数のサイト（ドメイン）の構築が必要となります
- 一ドメイン ⇒ Drupalソース ⇒ 共有DB
- 一ドメイン ⇒ Drupalソース ⇒ 独立DB
Drupalでは複数のサイト（ドメイン）への対応をしています

sitesディレクトリの下にドメインごとの子ディレクトリを作成してマルティサイトを構築します

複数のドメイン名をDrupalのルートディレクトリに同期します（例：シンボリックリンクでドメイン名をディレクトリと同期します）
- 例： old-pine.net をDrupalのルートディレクトリにシンボリックリンクで同期します
Drupalのルートディレクトリの下に sites ディレクトリがあります。sitesの下に各メイン名に同期したいディレクトリを作成します
- 例：sites/pine を作成します
sites/sites.phpファイルでドメイン名をディレクトと同期設定を行います
- 例： 'old-pine.net' => 'pine' （書き方：ドメイン名 => ディレクトリ名）
```
 $sites = array(
    'old-pine.net' => 'pine',
 );
```
新規作成したディレクトの下にサイトのインストール設定ファイル(settings.php)の作成
- 例：sites/pine/settings.phpを作成します
- settings.phpの内容はsites/pine/default.settings.phpのコピーで良いです（サイト新規作成する場合）
追加したドメイン名でサイトをアクセスして、新規サイトができたことを確認します

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

シリーズ記事一覧

記事カテゴリ

タグ

別々のDrupal（バージョン７）ソースのサイトを一つ共有ソースのところにサイト移行

複数のDrupalソースで構築した複数のウェブサイトがありまして、Drupalソースのバージョンアップ、バグ管理などに手間がかかり、一つのDrupal共有ソールの元で複数のサイトを構築しました。
今回は一つのサイトを共有ソースのところに移行を行いました
移行をシンプルにするため、事前に不必要ないくつかモジュール（SyntaxHighlighter含め）をアンインストールしました
移行後に再度モジュール（SyntaxHighlighter含め）をインストールし直します

モジュール(SyntaxHighlighter)インストール後にSyntaxHighlighterライブラリが見つからないエラー

まずSyntaxHighlighterのライブラリ（3.0.83）をダウンロードしてsites/all/libraies/syntaxhighlighter_3.0.83に展開しました
通常の方法でSyntaxHighlighterモジュール（7.x-2.0）をインストールして有効化しました

以前のサイトになっかたエラーメッセージ：

Warning: file_get_contents(sites/all/libraries/flexslider/scripts/shCore.js): failed to open stream: No such file or directory _locale_parse_js_file() (/virtual/drills/public_html/drupal7/includes/locale.inc ファイル　1527行).
Warning: file_get_contents(sites/all/libraries/flexslider/scripts/shBrushPhp.js): failed to open stream: No such file or directory _locale_parse_js_file() (/virtual/drills/public_html/drupal7/includes/locale.inc ファイル　1527行)

shCore.jsがSyntaxHighlighterのライブラリにあるはずなのに、なぜかflexsliderライブラリに関連付けられました（不思議なエラー）

問題：flexsliderのライブラリに同じ名前（shCore.js）のファイルがありました

他に同じようなエラーがあるか、検索してみたが、答えはありませんでした
ソースコードを読んで自力で解決するしかないですね。幸い、複雑なモジュールではなく、SyntaxHighlighterのjsファイルをページロード時にクライアント側に渡すプログラムです
最初は sites/all/modules/syntaxhighlighter/syntaxhighlighter.install をチェックしました。44行目にあるライブラリパス取得関数：sntaxhighlighter_get_lib_location()を注目しました
関数（_syntaxhighlighter_get_lib_location()）は sites/all/modules/syntaxhighlighter/syntaxhighlighter.module にあります。さらに、ライブラリパス取得ロジックを探してみました
syntaxhighlighter.moduleの377行あたりにあるライブラリフォルダスキャン関数：_syntaxhighlighter_scan_lib_location()があります
- ライブラリフォルダスキャンの原理：shCore.jsが含まれているフォルダを取得します
_syntaxhighlighter_scan_lib_location()にwatchdogを入れて、取得したフォルダをログとして出力しました。
結果として、このパス「sites/all/libraries/flexslider/demo/js/shCore.jssites/all/libraries/flexslider/demo/js/shCore.js」を取得しました。
flexSlider/demoの下に同じ名前（shCore.js）のファイルがあるため、flexsliderライブラリに関連づけられました。

解決：demoフォルダ（「sites/all/libraries/flexslider/demo」）を消して、再インストールします

flexsliderのdemoフォルダが邪魔にになってるため、またライブラリにdemoプログラムを使用しないため、demoフォルダを消しました
SyntaxHighlighterモジュールをアンインストールして、再インストールしたら、機能正常に戻りました

シリーズ記事一覧

記事カテゴリ

タグ

やりたいこと：一つDrupalのソースで複数のサイト（複数のドメイン）を構築したいです

Drupalを用いて複数のサイト（ドメイン）を構築する場合、一つサイト（ドメイン）ごとに一つのDrupalソースで構築することがもちろん問題はありません
Drupalソースが分散すると、バージョンアップ、バグ管理などの作業が大変になります
当然一つのDrupalソースの元で複数のサイト（ドメイン）の構築が必要となります
- 一ドメイン ⇒ Drupalソース ⇒ 共有DB
- 一ドメイン ⇒ Drupalソース ⇒ 独立DB
Drupalでは複数のサイト（ドメイン）への対応をしています

sitesディレクトリの下にドメインごとの子ディレクトリを作成してマルティサイトを構築します

複数のドメイン名をDrupalのルートディレクトリに同期します（例：シンボリックリンクでドメイン名をディレクトリと同期します）
- 例： old-pine.net をDrupalのルートディレクトリにシンボリックリンクで同期します
Drupalのルートディレクトリの下に sites ディレクトリがあります。sitesの下に各メイン名に同期したいディレクトリを作成します
- 例：sites/pine を作成します
sites/sites.phpファイルでドメイン名をディレクトと同期設定を行います
- 例： 'old-pine.net' => 'pine' （書き方：ドメイン名 => ディレクトリ名）
```
 $sites = array(
    'old-pine.net' => 'pine',
 );
```
新規作成したディレクトの下にサイトのインストール設定ファイル(settings.php)の作成
- 例：sites/pine/settings.phpを作成します
- settings.phpの内容はsites/pine/default.settings.phpのコピーで良いです（サイト新規作成する場合）
追加したドメイン名でサイトをアクセスして、新規サイトができたことを確認します

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

シリーズ記事一覧

記事カテゴリ

タグ

別々のDrupal（バージョン７）ソースのサイトを一つ共有ソースのところにサイト移行

複数のDrupalソースで構築した複数のウェブサイトがありまして、Drupalソースのバージョンアップ、バグ管理などに手間がかかり、一つのDrupal共有ソールの元で複数のサイトを構築しました。
今回は一つのサイトを共有ソースのところに移行を行いました
移行をシンプルにするため、事前に不必要ないくつかモジュール（SyntaxHighlighter含め）をアンインストールしました
移行後に再度モジュール（SyntaxHighlighter含め）をインストールし直します

モジュール(SyntaxHighlighter)インストール後にSyntaxHighlighterライブラリが見つからないエラー

まずSyntaxHighlighterのライブラリ（3.0.83）をダウンロードしてsites/all/libraies/syntaxhighlighter_3.0.83に展開しました
通常の方法でSyntaxHighlighterモジュール（7.x-2.0）をインストールして有効化しました

以前のサイトになっかたエラーメッセージ：

Warning: file_get_contents(sites/all/libraries/flexslider/scripts/shCore.js): failed to open stream: No such file or directory _locale_parse_js_file() (/virtual/drills/public_html/drupal7/includes/locale.inc ファイル　1527行).
Warning: file_get_contents(sites/all/libraries/flexslider/scripts/shBrushPhp.js): failed to open stream: No such file or directory _locale_parse_js_file() (/virtual/drills/public_html/drupal7/includes/locale.inc ファイル　1527行)

shCore.jsがSyntaxHighlighterのライブラリにあるはずなのに、なぜかflexsliderライブラリに関連付けられました（不思議なエラー）

問題：flexsliderのライブラリに同じ名前（shCore.js）のファイルがありました

他に同じようなエラーがあるか、検索してみたが、答えはありませんでした
ソースコードを読んで自力で解決するしかないですね。幸い、複雑なモジュールではなく、SyntaxHighlighterのjsファイルをページロード時にクライアント側に渡すプログラムです
最初は sites/all/modules/syntaxhighlighter/syntaxhighlighter.install をチェックしました。44行目にあるライブラリパス取得関数：sntaxhighlighter_get_lib_location()を注目しました
関数（_syntaxhighlighter_get_lib_location()）は sites/all/modules/syntaxhighlighter/syntaxhighlighter.module にあります。さらに、ライブラリパス取得ロジックを探してみました
syntaxhighlighter.moduleの377行あたりにあるライブラリフォルダスキャン関数：_syntaxhighlighter_scan_lib_location()があります
- ライブラリフォルダスキャンの原理：shCore.jsが含まれているフォルダを取得します
_syntaxhighlighter_scan_lib_location()にwatchdogを入れて、取得したフォルダをログとして出力しました。
結果として、このパス「sites/all/libraries/flexslider/demo/js/shCore.jssites/all/libraries/flexslider/demo/js/shCore.js」を取得しました。
flexSlider/demoの下に同じ名前（shCore.js）のファイルがあるため、flexsliderライブラリに関連づけられました。

解決：demoフォルダ（「sites/all/libraries/flexslider/demo」）を消して、再インストールします

flexsliderのdemoフォルダが邪魔にになってるため、またライブラリにdemoプログラムを使用しないため、demoフォルダを消しました
SyntaxHighlighterモジュールをアンインストールして、再インストールしたら、機能正常に戻りました

シリーズ記事一覧

記事カテゴリ

タグ

やりたいこと：一つDrupalのソースで複数のサイト（複数のドメイン）を構築したいです

Drupalを用いて複数のサイト（ドメイン）を構築する場合、一つサイト（ドメイン）ごとに一つのDrupalソースで構築することがもちろん問題はありません
Drupalソースが分散すると、バージョンアップ、バグ管理などの作業が大変になります
当然一つのDrupalソースの元で複数のサイト（ドメイン）の構築が必要となります
- 一ドメイン ⇒ Drupalソース ⇒ 共有DB
- 一ドメイン ⇒ Drupalソース ⇒ 独立DB
Drupalでは複数のサイト（ドメイン）への対応をしています

sitesディレクトリの下にドメインごとの子ディレクトリを作成してマルティサイトを構築します

複数のドメイン名をDrupalのルートディレクトリに同期します（例：シンボリックリンクでドメイン名をディレクトリと同期します）
- 例： old-pine.net をDrupalのルートディレクトリにシンボリックリンクで同期します
Drupalのルートディレクトリの下に sites ディレクトリがあります。sitesの下に各メイン名に同期したいディレクトリを作成します
- 例：sites/pine を作成します
sites/sites.phpファイルでドメイン名をディレクトと同期設定を行います
- 例： 'old-pine.net' => 'pine' （書き方：ドメイン名 => ディレクトリ名）
```
 $sites = array(
    'old-pine.net' => 'pine',
 );
```
新規作成したディレクトの下にサイトのインストール設定ファイル(settings.php)の作成
- 例：sites/pine/settings.phpを作成します
- settings.phpの内容はsites/pine/default.settings.phpのコピーで良いです（サイト新規作成する場合）
追加したドメイン名でサイトをアクセスして、新規サイトができたことを確認します

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

シリーズ記事一覧

記事カテゴリ

タグ

別々のDrupal（バージョン７）ソースのサイトを一つ共有ソースのところにサイト移行

複数のDrupalソースで構築した複数のウェブサイトがありまして、Drupalソースのバージョンアップ、バグ管理などに手間がかかり、一つのDrupal共有ソールの元で複数のサイトを構築しました。
今回は一つのサイトを共有ソースのところに移行を行いました
移行をシンプルにするため、事前に不必要ないくつかモジュール（SyntaxHighlighter含め）をアンインストールしました
移行後に再度モジュール（SyntaxHighlighter含め）をインストールし直します

モジュール(SyntaxHighlighter)インストール後にSyntaxHighlighterライブラリが見つからないエラー

まずSyntaxHighlighterのライブラリ（3.0.83）をダウンロードしてsites/all/libraies/syntaxhighlighter_3.0.83に展開しました
通常の方法でSyntaxHighlighterモジュール（7.x-2.0）をインストールして有効化しました

以前のサイトになっかたエラーメッセージ：

Warning: file_get_contents(sites/all/libraries/flexslider/scripts/shCore.js): failed to open stream: No such file or directory _locale_parse_js_file() (/virtual/drills/public_html/drupal7/includes/locale.inc ファイル　1527行).
Warning: file_get_contents(sites/all/libraries/flexslider/scripts/shBrushPhp.js): failed to open stream: No such file or directory _locale_parse_js_file() (/virtual/drills/public_html/drupal7/includes/locale.inc ファイル　1527行)

shCore.jsがSyntaxHighlighterのライブラリにあるはずなのに、なぜかflexsliderライブラリに関連付けられました（不思議なエラー）

問題：flexsliderのライブラリに同じ名前（shCore.js）のファイルがありました

他に同じようなエラーがあるか、検索してみたが、答えはありませんでした
ソースコードを読んで自力で解決するしかないですね。幸い、複雑なモジュールではなく、SyntaxHighlighterのjsファイルをページロード時にクライアント側に渡すプログラムです
最初は sites/all/modules/syntaxhighlighter/syntaxhighlighter.install をチェックしました。44行目にあるライブラリパス取得関数：sntaxhighlighter_get_lib_location()を注目しました
関数（_syntaxhighlighter_get_lib_location()）は sites/all/modules/syntaxhighlighter/syntaxhighlighter.module にあります。さらに、ライブラリパス取得ロジックを探してみました
syntaxhighlighter.moduleの377行あたりにあるライブラリフォルダスキャン関数：_syntaxhighlighter_scan_lib_location()があります
- ライブラリフォルダスキャンの原理：shCore.jsが含まれているフォルダを取得します
_syntaxhighlighter_scan_lib_location()にwatchdogを入れて、取得したフォルダをログとして出力しました。
結果として、このパス「sites/all/libraries/flexslider/demo/js/shCore.jssites/all/libraries/flexslider/demo/js/shCore.js」を取得しました。
flexSlider/demoの下に同じ名前（shCore.js）のファイルがあるため、flexsliderライブラリに関連づけられました。

解決：demoフォルダ（「sites/all/libraries/flexslider/demo」）を消して、再インストールします

flexsliderのdemoフォルダが邪魔にになってるため、またライブラリにdemoプログラムを使用しないため、demoフォルダを消しました
SyntaxHighlighterモジュールをアンインストールして、再インストールしたら、機能正常に戻りました

シリーズ記事一覧

記事カテゴリ

タグ

やりたいこと：一つDrupalのソースで複数のサイト（複数のドメイン）を構築したいです

Drupalを用いて複数のサイト（ドメイン）を構築する場合、一つサイト（ドメイン）ごとに一つのDrupalソースで構築することがもちろん問題はありません
Drupalソースが分散すると、バージョンアップ、バグ管理などの作業が大変になります
当然一つのDrupalソースの元で複数のサイト（ドメイン）の構築が必要となります
- 一ドメイン ⇒ Drupalソース ⇒ 共有DB
- 一ドメイン ⇒ Drupalソース ⇒ 独立DB
Drupalでは複数のサイト（ドメイン）への対応をしています

sitesディレクトリの下にドメインごとの子ディレクトリを作成してマルティサイトを構築します

複数のドメイン名をDrupalのルートディレクトリに同期します（例：シンボリックリンクでドメイン名をディレクトリと同期します）
- 例： old-pine.net をDrupalのルートディレクトリにシンボリックリンクで同期します
Drupalのルートディレクトリの下に sites ディレクトリがあります。sitesの下に各メイン名に同期したいディレクトリを作成します
- 例：sites/pine を作成します
sites/sites.phpファイルでドメイン名をディレクトと同期設定を行います
- 例： 'old-pine.net' => 'pine' （書き方：ドメイン名 => ディレクトリ名）
```
 $sites = array(
    'old-pine.net' => 'pine',
 );
```
新規作成したディレクトの下にサイトのインストール設定ファイル(settings.php)の作成
- 例：sites/pine/settings.phpを作成します
- settings.phpの内容はsites/pine/default.settings.phpのコピーで良いです（サイト新規作成する場合）
追加したドメイン名でサイトをアクセスして、新規サイトができたことを確認します

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

シリーズ記事一覧

記事カテゴリ

タグ

別々のDrupal（バージョン７）ソースのサイトを一つ共有ソースのところにサイト移行

複数のDrupalソースで構築した複数のウェブサイトがありまして、Drupalソースのバージョンアップ、バグ管理などに手間がかかり、一つのDrupal共有ソールの元で複数のサイトを構築しました。
今回は一つのサイトを共有ソースのところに移行を行いました
移行をシンプルにするため、事前に不必要ないくつかモジュール（SyntaxHighlighter含め）をアンインストールしました
移行後に再度モジュール（SyntaxHighlighter含め）をインストールし直します

モジュール(SyntaxHighlighter)インストール後にSyntaxHighlighterライブラリが見つからないエラー

まずSyntaxHighlighterのライブラリ（3.0.83）をダウンロードしてsites/all/libraies/syntaxhighlighter_3.0.83に展開しました
通常の方法でSyntaxHighlighterモジュール（7.x-2.0）をインストールして有効化しました

以前のサイトになっかたエラーメッセージ：

Warning: file_get_contents(sites/all/libraries/flexslider/scripts/shCore.js): failed to open stream: No such file or directory _locale_parse_js_file() (/virtual/drills/public_html/drupal7/includes/locale.inc ファイル　1527行).
Warning: file_get_contents(sites/all/libraries/flexslider/scripts/shBrushPhp.js): failed to open stream: No such file or directory _locale_parse_js_file() (/virtual/drills/public_html/drupal7/includes/locale.inc ファイル　1527行)

shCore.jsがSyntaxHighlighterのライブラリにあるはずなのに、なぜかflexsliderライブラリに関連付けられました（不思議なエラー）

問題：flexsliderのライブラリに同じ名前（shCore.js）のファイルがありました

他に同じようなエラーがあるか、検索してみたが、答えはありませんでした
ソースコードを読んで自力で解決するしかないですね。幸い、複雑なモジュールではなく、SyntaxHighlighterのjsファイルをページロード時にクライアント側に渡すプログラムです
最初は sites/all/modules/syntaxhighlighter/syntaxhighlighter.install をチェックしました。44行目にあるライブラリパス取得関数：sntaxhighlighter_get_lib_location()を注目しました
関数（_syntaxhighlighter_get_lib_location()）は sites/all/modules/syntaxhighlighter/syntaxhighlighter.module にあります。さらに、ライブラリパス取得ロジックを探してみました
syntaxhighlighter.moduleの377行あたりにあるライブラリフォルダスキャン関数：_syntaxhighlighter_scan_lib_location()があります
- ライブラリフォルダスキャンの原理：shCore.jsが含まれているフォルダを取得します
_syntaxhighlighter_scan_lib_location()にwatchdogを入れて、取得したフォルダをログとして出力しました。
結果として、このパス「sites/all/libraries/flexslider/demo/js/shCore.jssites/all/libraries/flexslider/demo/js/shCore.js」を取得しました。
flexSlider/demoの下に同じ名前（shCore.js）のファイルがあるため、flexsliderライブラリに関連づけられました。

解決：demoフォルダ（「sites/all/libraries/flexslider/demo」）を消して、再インストールします

flexsliderのdemoフォルダが邪魔にになってるため、またライブラリにdemoプログラムを使用しないため、demoフォルダを消しました
SyntaxHighlighterモジュールをアンインストールして、再インストールしたら、機能正常に戻りました

シリーズ記事一覧

記事カテゴリ

タグ

やりたいこと：一つDrupalのソースで複数のサイト（複数のドメイン）を構築したいです

Drupalを用いて複数のサイト（ドメイン）を構築する場合、一つサイト（ドメイン）ごとに一つのDrupalソースで構築することがもちろん問題はありません
Drupalソースが分散すると、バージョンアップ、バグ管理などの作業が大変になります
当然一つのDrupalソースの元で複数のサイト（ドメイン）の構築が必要となります
- 一ドメイン ⇒ Drupalソース ⇒ 共有DB
- 一ドメイン ⇒ Drupalソース ⇒ 独立DB
Drupalでは複数のサイト（ドメイン）への対応をしています

sitesディレクトリの下にドメインごとの子ディレクトリを作成してマルティサイトを構築します

複数のドメイン名をDrupalのルートディレクトリに同期します（例：シンボリックリンクでドメイン名をディレクトリと同期します）
- 例： old-pine.net をDrupalのルートディレクトリにシンボリックリンクで同期します
Drupalのルートディレクトリの下に sites ディレクトリがあります。sitesの下に各メイン名に同期したいディレクトリを作成します
- 例：sites/pine を作成します
sites/sites.phpファイルでドメイン名をディレクトと同期設定を行います
- 例： 'old-pine.net' => 'pine' （書き方：ドメイン名 => ディレクトリ名）
```
 $sites = array(
    'old-pine.net' => 'pine',
 );
```
新規作成したディレクトの下にサイトのインストール設定ファイル(settings.php)の作成
- 例：sites/pine/settings.phpを作成します
- settings.phpの内容はsites/pine/default.settings.phpのコピーで良いです（サイト新規作成する場合）
追加したドメイン名でサイトをアクセスして、新規サイトができたことを確認します

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

シリーズ記事一覧

記事カテゴリ

タグ

別々のDrupal（バージョン７）ソースのサイトを一つ共有ソースのところにサイト移行

複数のDrupalソースで構築した複数のウェブサイトがありまして、Drupalソースのバージョンアップ、バグ管理などに手間がかかり、一つのDrupal共有ソールの元で複数のサイトを構築しました。
今回は一つのサイトを共有ソースのところに移行を行いました
移行をシンプルにするため、事前に不必要ないくつかモジュール（SyntaxHighlighter含め）をアンインストールしました
移行後に再度モジュール（SyntaxHighlighter含め）をインストールし直します

モジュール(SyntaxHighlighter)インストール後にSyntaxHighlighterライブラリが見つからないエラー

まずSyntaxHighlighterのライブラリ（3.0.83）をダウンロードしてsites/all/libraies/syntaxhighlighter_3.0.83に展開しました
通常の方法でSyntaxHighlighterモジュール（7.x-2.0）をインストールして有効化しました

以前のサイトになっかたエラーメッセージ：

Warning: file_get_contents(sites/all/libraries/flexslider/scripts/shCore.js): failed to open stream: No such file or directory _locale_parse_js_file() (/virtual/drills/public_html/drupal7/includes/locale.inc ファイル　1527行).
Warning: file_get_contents(sites/all/libraries/flexslider/scripts/shBrushPhp.js): failed to open stream: No such file or directory _locale_parse_js_file() (/virtual/drills/public_html/drupal7/includes/locale.inc ファイル　1527行)

shCore.jsがSyntaxHighlighterのライブラリにあるはずなのに、なぜかflexsliderライブラリに関連付けられました（不思議なエラー）

問題：flexsliderのライブラリに同じ名前（shCore.js）のファイルがありました

他に同じようなエラーがあるか、検索してみたが、答えはありませんでした
ソースコードを読んで自力で解決するしかないですね。幸い、複雑なモジュールではなく、SyntaxHighlighterのjsファイルをページロード時にクライアント側に渡すプログラムです
最初は sites/all/modules/syntaxhighlighter/syntaxhighlighter.install をチェックしました。44行目にあるライブラリパス取得関数：sntaxhighlighter_get_lib_location()を注目しました
関数（_syntaxhighlighter_get_lib_location()）は sites/all/modules/syntaxhighlighter/syntaxhighlighter.module にあります。さらに、ライブラリパス取得ロジックを探してみました
syntaxhighlighter.moduleの377行あたりにあるライブラリフォルダスキャン関数：_syntaxhighlighter_scan_lib_location()があります
- ライブラリフォルダスキャンの原理：shCore.jsが含まれているフォルダを取得します
_syntaxhighlighter_scan_lib_location()にwatchdogを入れて、取得したフォルダをログとして出力しました。
結果として、このパス「sites/all/libraries/flexslider/demo/js/shCore.jssites/all/libraries/flexslider/demo/js/shCore.js」を取得しました。
flexSlider/demoの下に同じ名前（shCore.js）のファイルがあるため、flexsliderライブラリに関連づけられました。

解決：demoフォルダ（「sites/all/libraries/flexslider/demo」）を消して、再インストールします

flexsliderのdemoフォルダが邪魔にになってるため、またライブラリにdemoプログラムを使用しないため、demoフォルダを消しました
SyntaxHighlighterモジュールをアンインストールして、再インストールしたら、機能正常に戻りました

シリーズ記事一覧

記事カテゴリ

タグ

やりたいこと：一つDrupalのソースで複数のサイト（複数のドメイン）を構築したいです

Drupalを用いて複数のサイト（ドメイン）を構築する場合、一つサイト（ドメイン）ごとに一つのDrupalソースで構築することがもちろん問題はありません
Drupalソースが分散すると、バージョンアップ、バグ管理などの作業が大変になります
当然一つのDrupalソースの元で複数のサイト（ドメイン）の構築が必要となります
- 一ドメイン ⇒ Drupalソース ⇒ 共有DB
- 一ドメイン ⇒ Drupalソース ⇒ 独立DB
Drupalでは複数のサイト（ドメイン）への対応をしています

sitesディレクトリの下にドメインごとの子ディレクトリを作成してマルティサイトを構築します

複数のドメイン名をDrupalのルートディレクトリに同期します（例：シンボリックリンクでドメイン名をディレクトリと同期します）
- 例： old-pine.net をDrupalのルートディレクトリにシンボリックリンクで同期します
Drupalのルートディレクトリの下に sites ディレクトリがあります。sitesの下に各メイン名に同期したいディレクトリを作成します
- 例：sites/pine を作成します
sites/sites.phpファイルでドメイン名をディレクトと同期設定を行います
- 例： 'old-pine.net' => 'pine' （書き方：ドメイン名 => ディレクトリ名）
```
 $sites = array(
    'old-pine.net' => 'pine',
 );
```
新規作成したディレクトの下にサイトのインストール設定ファイル(settings.php)の作成
- 例：sites/pine/settings.phpを作成します
- settings.phpの内容はsites/pine/default.settings.phpのコピーで良いです（サイト新規作成する場合）
追加したドメイン名でサイトをアクセスして、新規サイトができたことを確認します

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

シリーズ記事一覧

記事カテゴリ

タグ

別々のDrupal（バージョン７）ソースのサイトを一つ共有ソースのところにサイト移行

複数のDrupalソースで構築した複数のウェブサイトがありまして、Drupalソースのバージョンアップ、バグ管理などに手間がかかり、一つのDrupal共有ソールの元で複数のサイトを構築しました。
今回は一つのサイトを共有ソースのところに移行を行いました
移行をシンプルにするため、事前に不必要ないくつかモジュール（SyntaxHighlighter含め）をアンインストールしました
移行後に再度モジュール（SyntaxHighlighter含め）をインストールし直します

モジュール(SyntaxHighlighter)インストール後にSyntaxHighlighterライブラリが見つからないエラー

まずSyntaxHighlighterのライブラリ（3.0.83）をダウンロードしてsites/all/libraies/syntaxhighlighter_3.0.83に展開しました
通常の方法でSyntaxHighlighterモジュール（7.x-2.0）をインストールして有効化しました

以前のサイトになっかたエラーメッセージ：

Warning: file_get_contents(sites/all/libraries/flexslider/scripts/shCore.js): failed to open stream: No such file or directory _locale_parse_js_file() (/virtual/drills/public_html/drupal7/includes/locale.inc ファイル　1527行).
Warning: file_get_contents(sites/all/libraries/flexslider/scripts/shBrushPhp.js): failed to open stream: No such file or directory _locale_parse_js_file() (/virtual/drills/public_html/drupal7/includes/locale.inc ファイル　1527行)

shCore.jsがSyntaxHighlighterのライブラリにあるはずなのに、なぜかflexsliderライブラリに関連付けられました（不思議なエラー）

問題：flexsliderのライブラリに同じ名前（shCore.js）のファイルがありました

他に同じようなエラーがあるか、検索してみたが、答えはありませんでした
ソースコードを読んで自力で解決するしかないですね。幸い、複雑なモジュールではなく、SyntaxHighlighterのjsファイルをページロード時にクライアント側に渡すプログラムです
最初は sites/all/modules/syntaxhighlighter/syntaxhighlighter.install をチェックしました。44行目にあるライブラリパス取得関数：sntaxhighlighter_get_lib_location()を注目しました
関数（_syntaxhighlighter_get_lib_location()）は sites/all/modules/syntaxhighlighter/syntaxhighlighter.module にあります。さらに、ライブラリパス取得ロジックを探してみました
syntaxhighlighter.moduleの377行あたりにあるライブラリフォルダスキャン関数：_syntaxhighlighter_scan_lib_location()があります
- ライブラリフォルダスキャンの原理：shCore.jsが含まれているフォルダを取得します
_syntaxhighlighter_scan_lib_location()にwatchdogを入れて、取得したフォルダをログとして出力しました。
結果として、このパス「sites/all/libraries/flexslider/demo/js/shCore.jssites/all/libraries/flexslider/demo/js/shCore.js」を取得しました。
flexSlider/demoの下に同じ名前（shCore.js）のファイルがあるため、flexsliderライブラリに関連づけられました。

解決：demoフォルダ（「sites/all/libraries/flexslider/demo」）を消して、再インストールします

flexsliderのdemoフォルダが邪魔にになってるため、またライブラリにdemoプログラムを使用しないため、demoフォルダを消しました
SyntaxHighlighterモジュールをアンインストールして、再インストールしたら、機能正常に戻りました

シリーズ記事一覧

記事カテゴリ

タグ

やりたいこと：一つDrupalのソースで複数のサイト（複数のドメイン）を構築したいです

Drupalを用いて複数のサイト（ドメイン）を構築する場合、一つサイト（ドメイン）ごとに一つのDrupalソースで構築することがもちろん問題はありません
Drupalソースが分散すると、バージョンアップ、バグ管理などの作業が大変になります
当然一つのDrupalソースの元で複数のサイト（ドメイン）の構築が必要となります
- 一ドメイン ⇒ Drupalソース ⇒ 共有DB
- 一ドメイン ⇒ Drupalソース ⇒ 独立DB
Drupalでは複数のサイト（ドメイン）への対応をしています

sitesディレクトリの下にドメインごとの子ディレクトリを作成してマルティサイトを構築します

複数のドメイン名をDrupalのルートディレクトリに同期します（例：シンボリックリンクでドメイン名をディレクトリと同期します）
- 例： old-pine.net をDrupalのルートディレクトリにシンボリックリンクで同期します
Drupalのルートディレクトリの下に sites ディレクトリがあります。sitesの下に各メイン名に同期したいディレクトリを作成します
- 例：sites/pine を作成します
sites/sites.phpファイルでドメイン名をディレクトと同期設定を行います
- 例： 'old-pine.net' => 'pine' （書き方：ドメイン名 => ディレクトリ名）
```
 $sites = array(
    'old-pine.net' => 'pine',
 );
```
新規作成したディレクトの下にサイトのインストール設定ファイル(settings.php)の作成
- 例：sites/pine/settings.phpを作成します
- settings.phpの内容はsites/pine/default.settings.phpのコピーで良いです（サイト新規作成する場合）
追加したドメイン名でサイトをアクセスして、新規サイトができたことを確認します

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

シリーズ記事一覧

記事カテゴリ

タグ

別々のDrupal（バージョン７）ソースのサイトを一つ共有ソースのところにサイト移行

複数のDrupalソースで構築した複数のウェブサイトがありまして、Drupalソースのバージョンアップ、バグ管理などに手間がかかり、一つのDrupal共有ソールの元で複数のサイトを構築しました。
今回は一つのサイトを共有ソースのところに移行を行いました
移行をシンプルにするため、事前に不必要ないくつかモジュール（SyntaxHighlighter含め）をアンインストールしました
移行後に再度モジュール（SyntaxHighlighter含め）をインストールし直します

モジュール(SyntaxHighlighter)インストール後にSyntaxHighlighterライブラリが見つからないエラー

まずSyntaxHighlighterのライブラリ（3.0.83）をダウンロードしてsites/all/libraies/syntaxhighlighter_3.0.83に展開しました
通常の方法でSyntaxHighlighterモジュール（7.x-2.0）をインストールして有効化しました

以前のサイトになっかたエラーメッセージ：

Warning: file_get_contents(sites/all/libraries/flexslider/scripts/shCore.js): failed to open stream: No such file or directory _locale_parse_js_file() (/virtual/drills/public_html/drupal7/includes/locale.inc ファイル　1527行).
Warning: file_get_contents(sites/all/libraries/flexslider/scripts/shBrushPhp.js): failed to open stream: No such file or directory _locale_parse_js_file() (/virtual/drills/public_html/drupal7/includes/locale.inc ファイル　1527行)

shCore.jsがSyntaxHighlighterのライブラリにあるはずなのに、なぜかflexsliderライブラリに関連付けられました（不思議なエラー）

問題：flexsliderのライブラリに同じ名前（shCore.js）のファイルがありました

他に同じようなエラーがあるか、検索してみたが、答えはありませんでした
ソースコードを読んで自力で解決するしかないですね。幸い、複雑なモジュールではなく、SyntaxHighlighterのjsファイルをページロード時にクライアント側に渡すプログラムです
最初は sites/all/modules/syntaxhighlighter/syntaxhighlighter.install をチェックしました。44行目にあるライブラリパス取得関数：sntaxhighlighter_get_lib_location()を注目しました
関数（_syntaxhighlighter_get_lib_location()）は sites/all/modules/syntaxhighlighter/syntaxhighlighter.module にあります。さらに、ライブラリパス取得ロジックを探してみました
syntaxhighlighter.moduleの377行あたりにあるライブラリフォルダスキャン関数：_syntaxhighlighter_scan_lib_location()があります
- ライブラリフォルダスキャンの原理：shCore.jsが含まれているフォルダを取得します
_syntaxhighlighter_scan_lib_location()にwatchdogを入れて、取得したフォルダをログとして出力しました。
結果として、このパス「sites/all/libraries/flexslider/demo/js/shCore.jssites/all/libraries/flexslider/demo/js/shCore.js」を取得しました。
flexSlider/demoの下に同じ名前（shCore.js）のファイルがあるため、flexsliderライブラリに関連づけられました。

解決：demoフォルダ（「sites/all/libraries/flexslider/demo」）を消して、再インストールします

flexsliderのdemoフォルダが邪魔にになってるため、またライブラリにdemoプログラムを使用しないため、demoフォルダを消しました
SyntaxHighlighterモジュールをアンインストールして、再インストールしたら、機能正常に戻りました

シリーズ記事一覧

記事カテゴリ

タグ

やりたいこと：一つDrupalのソースで複数のサイト（複数のドメイン）を構築したいです

Drupalを用いて複数のサイト（ドメイン）を構築する場合、一つサイト（ドメイン）ごとに一つのDrupalソースで構築することがもちろん問題はありません
Drupalソースが分散すると、バージョンアップ、バグ管理などの作業が大変になります
当然一つのDrupalソースの元で複数のサイト（ドメイン）の構築が必要となります
- 一ドメイン ⇒ Drupalソース ⇒ 共有DB
- 一ドメイン ⇒ Drupalソース ⇒ 独立DB
Drupalでは複数のサイト（ドメイン）への対応をしています

sitesディレクトリの下にドメインごとの子ディレクトリを作成してマルティサイトを構築します

複数のドメイン名をDrupalのルートディレクトリに同期します（例：シンボリックリンクでドメイン名をディレクトリと同期します）
- 例： old-pine.net をDrupalのルートディレクトリにシンボリックリンクで同期します
Drupalのルートディレクトリの下に sites ディレクトリがあります。sitesの下に各メイン名に同期したいディレクトリを作成します
- 例：sites/pine を作成します
sites/sites.phpファイルでドメイン名をディレクトと同期設定を行います
- 例： 'old-pine.net' => 'pine' （書き方：ドメイン名 => ディレクトリ名）
```
 $sites = array(
    'old-pine.net' => 'pine',
 );
```
新規作成したディレクトの下にサイトのインストール設定ファイル(settings.php)の作成
- 例：sites/pine/settings.phpを作成します
- settings.phpの内容はsites/pine/default.settings.phpのコピーで良いです（サイト新規作成する場合）
追加したドメイン名でサイトをアクセスして、新規サイトができたことを確認します

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

シリーズ記事一覧

記事カテゴリ

タグ

別々のDrupal（バージョン７）ソースのサイトを一つ共有ソースのところにサイト移行

複数のDrupalソースで構築した複数のウェブサイトがありまして、Drupalソースのバージョンアップ、バグ管理などに手間がかかり、一つのDrupal共有ソールの元で複数のサイトを構築しました。
今回は一つのサイトを共有ソースのところに移行を行いました
移行をシンプルにするため、事前に不必要ないくつかモジュール（SyntaxHighlighter含め）をアンインストールしました
移行後に再度モジュール（SyntaxHighlighter含め）をインストールし直します

モジュール(SyntaxHighlighter)インストール後にSyntaxHighlighterライブラリが見つからないエラー

まずSyntaxHighlighterのライブラリ（3.0.83）をダウンロードしてsites/all/libraies/syntaxhighlighter_3.0.83に展開しました
通常の方法でSyntaxHighlighterモジュール（7.x-2.0）をインストールして有効化しました

以前のサイトになっかたエラーメッセージ：

Warning: file_get_contents(sites/all/libraries/flexslider/scripts/shCore.js): failed to open stream: No such file or directory _locale_parse_js_file() (/virtual/drills/public_html/drupal7/includes/locale.inc ファイル　1527行).
Warning: file_get_contents(sites/all/libraries/flexslider/scripts/shBrushPhp.js): failed to open stream: No such file or directory _locale_parse_js_file() (/virtual/drills/public_html/drupal7/includes/locale.inc ファイル　1527行)

shCore.jsがSyntaxHighlighterのライブラリにあるはずなのに、なぜかflexsliderライブラリに関連付けられました（不思議なエラー）

問題：flexsliderのライブラリに同じ名前（shCore.js）のファイルがありました

他に同じようなエラーがあるか、検索してみたが、答えはありませんでした
ソースコードを読んで自力で解決するしかないですね。幸い、複雑なモジュールではなく、SyntaxHighlighterのjsファイルをページロード時にクライアント側に渡すプログラムです
最初は sites/all/modules/syntaxhighlighter/syntaxhighlighter.install をチェックしました。44行目にあるライブラリパス取得関数：sntaxhighlighter_get_lib_location()を注目しました
関数（_syntaxhighlighter_get_lib_location()）は sites/all/modules/syntaxhighlighter/syntaxhighlighter.module にあります。さらに、ライブラリパス取得ロジックを探してみました
syntaxhighlighter.moduleの377行あたりにあるライブラリフォルダスキャン関数：_syntaxhighlighter_scan_lib_location()があります
- ライブラリフォルダスキャンの原理：shCore.jsが含まれているフォルダを取得します
_syntaxhighlighter_scan_lib_location()にwatchdogを入れて、取得したフォルダをログとして出力しました。
結果として、このパス「sites/all/libraries/flexslider/demo/js/shCore.jssites/all/libraries/flexslider/demo/js/shCore.js」を取得しました。
flexSlider/demoの下に同じ名前（shCore.js）のファイルがあるため、flexsliderライブラリに関連づけられました。

解決：demoフォルダ（「sites/all/libraries/flexslider/demo」）を消して、再インストールします

flexsliderのdemoフォルダが邪魔にになってるため、またライブラリにdemoプログラムを使用しないため、demoフォルダを消しました
SyntaxHighlighterモジュールをアンインストールして、再インストールしたら、機能正常に戻りました

シリーズ記事一覧

記事カテゴリ

タグ

やりたいこと：一つDrupalのソースで複数のサイト（複数のドメイン）を構築したいです

Drupalを用いて複数のサイト（ドメイン）を構築する場合、一つサイト（ドメイン）ごとに一つのDrupalソースで構築することがもちろん問題はありません
Drupalソースが分散すると、バージョンアップ、バグ管理などの作業が大変になります
当然一つのDrupalソースの元で複数のサイト（ドメイン）の構築が必要となります
- 一ドメイン ⇒ Drupalソース ⇒ 共有DB
- 一ドメイン ⇒ Drupalソース ⇒ 独立DB
Drupalでは複数のサイト（ドメイン）への対応をしています

sitesディレクトリの下にドメインごとの子ディレクトリを作成してマルティサイトを構築します

複数のドメイン名をDrupalのルートディレクトリに同期します（例：シンボリックリンクでドメイン名をディレクトリと同期します）
- 例： old-pine.net をDrupalのルートディレクトリにシンボリックリンクで同期します
Drupalのルートディレクトリの下に sites ディレクトリがあります。sitesの下に各メイン名に同期したいディレクトリを作成します
- 例：sites/pine を作成します
sites/sites.phpファイルでドメイン名をディレクトと同期設定を行います
- 例： 'old-pine.net' => 'pine' （書き方：ドメイン名 => ディレクトリ名）
```
 $sites = array(
    'old-pine.net' => 'pine',
 );
```
新規作成したディレクトの下にサイトのインストール設定ファイル(settings.php)の作成
- 例：sites/pine/settings.phpを作成します
- settings.phpの内容はsites/pine/default.settings.phpのコピーで良いです（サイト新規作成する場合）
追加したドメイン名でサイトをアクセスして、新規サイトができたことを確認します

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

シリーズ記事一覧

記事カテゴリ

タグ

別々のDrupal（バージョン７）ソースのサイトを一つ共有ソースのところにサイト移行

複数のDrupalソースで構築した複数のウェブサイトがありまして、Drupalソースのバージョンアップ、バグ管理などに手間がかかり、一つのDrupal共有ソールの元で複数のサイトを構築しました。
今回は一つのサイトを共有ソースのところに移行を行いました
移行をシンプルにするため、事前に不必要ないくつかモジュール（SyntaxHighlighter含め）をアンインストールしました
移行後に再度モジュール（SyntaxHighlighter含め）をインストールし直します

モジュール(SyntaxHighlighter)インストール後にSyntaxHighlighterライブラリが見つからないエラー

まずSyntaxHighlighterのライブラリ（3.0.83）をダウンロードしてsites/all/libraies/syntaxhighlighter_3.0.83に展開しました
通常の方法でSyntaxHighlighterモジュール（7.x-2.0）をインストールして有効化しました

以前のサイトになっかたエラーメッセージ：

Warning: file_get_contents(sites/all/libraries/flexslider/scripts/shCore.js): failed to open stream: No such file or directory _locale_parse_js_file() (/virtual/drills/public_html/drupal7/includes/locale.inc ファイル　1527行).
Warning: file_get_contents(sites/all/libraries/flexslider/scripts/shBrushPhp.js): failed to open stream: No such file or directory _locale_parse_js_file() (/virtual/drills/public_html/drupal7/includes/locale.inc ファイル　1527行)

shCore.jsがSyntaxHighlighterのライブラリにあるはずなのに、なぜかflexsliderライブラリに関連付けられました（不思議なエラー）

問題：flexsliderのライブラリに同じ名前（shCore.js）のファイルがありました

他に同じようなエラーがあるか、検索してみたが、答えはありませんでした
ソースコードを読んで自力で解決するしかないですね。幸い、複雑なモジュールではなく、SyntaxHighlighterのjsファイルをページロード時にクライアント側に渡すプログラムです
最初は sites/all/modules/syntaxhighlighter/syntaxhighlighter.install をチェックしました。44行目にあるライブラリパス取得関数：sntaxhighlighter_get_lib_location()を注目しました
関数（_syntaxhighlighter_get_lib_location()）は sites/all/modules/syntaxhighlighter/syntaxhighlighter.module にあります。さらに、ライブラリパス取得ロジックを探してみました
syntaxhighlighter.moduleの377行あたりにあるライブラリフォルダスキャン関数：_syntaxhighlighter_scan_lib_location()があります
- ライブラリフォルダスキャンの原理：shCore.jsが含まれているフォルダを取得します
_syntaxhighlighter_scan_lib_location()にwatchdogを入れて、取得したフォルダをログとして出力しました。
結果として、このパス「sites/all/libraries/flexslider/demo/js/shCore.jssites/all/libraries/flexslider/demo/js/shCore.js」を取得しました。
flexSlider/demoの下に同じ名前（shCore.js）のファイルがあるため、flexsliderライブラリに関連づけられました。

解決：demoフォルダ（「sites/all/libraries/flexslider/demo」）を消して、再インストールします

flexsliderのdemoフォルダが邪魔にになってるため、またライブラリにdemoプログラムを使用しないため、demoフォルダを消しました
SyntaxHighlighterモジュールをアンインストールして、再インストールしたら、機能正常に戻りました

シリーズ記事一覧

記事カテゴリ

タグ

やりたいこと：一つDrupalのソースで複数のサイト（複数のドメイン）を構築したいです

Drupalを用いて複数のサイト（ドメイン）を構築する場合、一つサイト（ドメイン）ごとに一つのDrupalソースで構築することがもちろん問題はありません
Drupalソースが分散すると、バージョンアップ、バグ管理などの作業が大変になります
当然一つのDrupalソースの元で複数のサイト（ドメイン）の構築が必要となります
- 一ドメイン ⇒ Drupalソース ⇒ 共有DB
- 一ドメイン ⇒ Drupalソース ⇒ 独立DB
Drupalでは複数のサイト（ドメイン）への対応をしています

sitesディレクトリの下にドメインごとの子ディレクトリを作成してマルティサイトを構築します

複数のドメイン名をDrupalのルートディレクトリに同期します（例：シンボリックリンクでドメイン名をディレクトリと同期します）
- 例： old-pine.net をDrupalのルートディレクトリにシンボリックリンクで同期します
Drupalのルートディレクトリの下に sites ディレクトリがあります。sitesの下に各メイン名に同期したいディレクトリを作成します
- 例：sites/pine を作成します
sites/sites.phpファイルでドメイン名をディレクトと同期設定を行います
- 例： 'old-pine.net' => 'pine' （書き方：ドメイン名 => ディレクトリ名）
```
 $sites = array(
    'old-pine.net' => 'pine',
 );
```
新規作成したディレクトの下にサイトのインストール設定ファイル(settings.php)の作成
- 例：sites/pine/settings.phpを作成します
- settings.phpの内容はsites/pine/default.settings.phpのコピーで良いです（サイト新規作成する場合）
追加したドメイン名でサイトをアクセスして、新規サイトができたことを確認します

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

シリーズ記事一覧

記事カテゴリ

タグ

別々のDrupal（バージョン７）ソースのサイトを一つ共有ソースのところにサイト移行

複数のDrupalソースで構築した複数のウェブサイトがありまして、Drupalソースのバージョンアップ、バグ管理などに手間がかかり、一つのDrupal共有ソールの元で複数のサイトを構築しました。
今回は一つのサイトを共有ソースのところに移行を行いました
移行をシンプルにするため、事前に不必要ないくつかモジュール（SyntaxHighlighter含め）をアンインストールしました
移行後に再度モジュール（SyntaxHighlighter含め）をインストールし直します

モジュール(SyntaxHighlighter)インストール後にSyntaxHighlighterライブラリが見つからないエラー

まずSyntaxHighlighterのライブラリ（3.0.83）をダウンロードしてsites/all/libraies/syntaxhighlighter_3.0.83に展開しました
通常の方法でSyntaxHighlighterモジュール（7.x-2.0）をインストールして有効化しました

以前のサイトになっかたエラーメッセージ：

Warning: file_get_contents(sites/all/libraries/flexslider/scripts/shCore.js): failed to open stream: No such file or directory _locale_parse_js_file() (/virtual/drills/public_html/drupal7/includes/locale.inc ファイル　1527行).
Warning: file_get_contents(sites/all/libraries/flexslider/scripts/shBrushPhp.js): failed to open stream: No such file or directory _locale_parse_js_file() (/virtual/drills/public_html/drupal7/includes/locale.inc ファイル　1527行)

shCore.jsがSyntaxHighlighterのライブラリにあるはずなのに、なぜかflexsliderライブラリに関連付けられました（不思議なエラー）

問題：flexsliderのライブラリに同じ名前（shCore.js）のファイルがありました

他に同じようなエラーがあるか、検索してみたが、答えはありませんでした
ソースコードを読んで自力で解決するしかないですね。幸い、複雑なモジュールではなく、SyntaxHighlighterのjsファイルをページロード時にクライアント側に渡すプログラムです
最初は sites/all/modules/syntaxhighlighter/syntaxhighlighter.install をチェックしました。44行目にあるライブラリパス取得関数：sntaxhighlighter_get_lib_location()を注目しました
関数（_syntaxhighlighter_get_lib_location()）は sites/all/modules/syntaxhighlighter/syntaxhighlighter.module にあります。さらに、ライブラリパス取得ロジックを探してみました
syntaxhighlighter.moduleの377行あたりにあるライブラリフォルダスキャン関数：_syntaxhighlighter_scan_lib_location()があります
- ライブラリフォルダスキャンの原理：shCore.jsが含まれているフォルダを取得します
_syntaxhighlighter_scan_lib_location()にwatchdogを入れて、取得したフォルダをログとして出力しました。
結果として、このパス「sites/all/libraries/flexslider/demo/js/shCore.jssites/all/libraries/flexslider/demo/js/shCore.js」を取得しました。
flexSlider/demoの下に同じ名前（shCore.js）のファイルがあるため、flexsliderライブラリに関連づけられました。

解決：demoフォルダ（「sites/all/libraries/flexslider/demo」）を消して、再インストールします

flexsliderのdemoフォルダが邪魔にになってるため、またライブラリにdemoプログラムを使用しないため、demoフォルダを消しました
SyntaxHighlighterモジュールをアンインストールして、再インストールしたら、機能正常に戻りました

シリーズ記事一覧

記事カテゴリ

タグ

やりたいこと：一つDrupalのソースで複数のサイト（複数のドメイン）を構築したいです

Drupalを用いて複数のサイト（ドメイン）を構築する場合、一つサイト（ドメイン）ごとに一つのDrupalソースで構築することがもちろん問題はありません
Drupalソースが分散すると、バージョンアップ、バグ管理などの作業が大変になります
当然一つのDrupalソースの元で複数のサイト（ドメイン）の構築が必要となります
- 一ドメイン ⇒ Drupalソース ⇒ 共有DB
- 一ドメイン ⇒ Drupalソース ⇒ 独立DB
Drupalでは複数のサイト（ドメイン）への対応をしています

sitesディレクトリの下にドメインごとの子ディレクトリを作成してマルティサイトを構築します

複数のドメイン名をDrupalのルートディレクトリに同期します（例：シンボリックリンクでドメイン名をディレクトリと同期します）
- 例： old-pine.net をDrupalのルートディレクトリにシンボリックリンクで同期します
Drupalのルートディレクトリの下に sites ディレクトリがあります。sitesの下に各メイン名に同期したいディレクトリを作成します
- 例：sites/pine を作成します
sites/sites.phpファイルでドメイン名をディレクトと同期設定を行います
- 例： 'old-pine.net' => 'pine' （書き方：ドメイン名 => ディレクトリ名）
```
 $sites = array(
    'old-pine.net' => 'pine',
 );
```
新規作成したディレクトの下にサイトのインストール設定ファイル(settings.php)の作成
- 例：sites/pine/settings.phpを作成します
- settings.phpの内容はsites/pine/default.settings.phpのコピーで良いです（サイト新規作成する場合）
追加したドメイン名でサイトをアクセスして、新規サイトができたことを確認します

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

シリーズ記事一覧

記事カテゴリ

タグ

別々のDrupal（バージョン７）ソースのサイトを一つ共有ソースのところにサイト移行

複数のDrupalソースで構築した複数のウェブサイトがありまして、Drupalソースのバージョンアップ、バグ管理などに手間がかかり、一つのDrupal共有ソールの元で複数のサイトを構築しました。
今回は一つのサイトを共有ソースのところに移行を行いました
移行をシンプルにするため、事前に不必要ないくつかモジュール（SyntaxHighlighter含め）をアンインストールしました
移行後に再度モジュール（SyntaxHighlighter含め）をインストールし直します

モジュール(SyntaxHighlighter)インストール後にSyntaxHighlighterライブラリが見つからないエラー

まずSyntaxHighlighterのライブラリ（3.0.83）をダウンロードしてsites/all/libraies/syntaxhighlighter_3.0.83に展開しました
通常の方法でSyntaxHighlighterモジュール（7.x-2.0）をインストールして有効化しました

以前のサイトになっかたエラーメッセージ：

Warning: file_get_contents(sites/all/libraries/flexslider/scripts/shCore.js): failed to open stream: No such file or directory _locale_parse_js_file() (/virtual/drills/public_html/drupal7/includes/locale.inc ファイル　1527行).
Warning: file_get_contents(sites/all/libraries/flexslider/scripts/shBrushPhp.js): failed to open stream: No such file or directory _locale_parse_js_file() (/virtual/drills/public_html/drupal7/includes/locale.inc ファイル　1527行)

shCore.jsがSyntaxHighlighterのライブラリにあるはずなのに、なぜかflexsliderライブラリに関連付けられました（不思議なエラー）

問題：flexsliderのライブラリに同じ名前（shCore.js）のファイルがありました

他に同じようなエラーがあるか、検索してみたが、答えはありませんでした
ソースコードを読んで自力で解決するしかないですね。幸い、複雑なモジュールではなく、SyntaxHighlighterのjsファイルをページロード時にクライアント側に渡すプログラムです
最初は sites/all/modules/syntaxhighlighter/syntaxhighlighter.install をチェックしました。44行目にあるライブラリパス取得関数：sntaxhighlighter_get_lib_location()を注目しました
関数（_syntaxhighlighter_get_lib_location()）は sites/all/modules/syntaxhighlighter/syntaxhighlighter.module にあります。さらに、ライブラリパス取得ロジックを探してみました
syntaxhighlighter.moduleの377行あたりにあるライブラリフォルダスキャン関数：_syntaxhighlighter_scan_lib_location()があります
- ライブラリフォルダスキャンの原理：shCore.jsが含まれているフォルダを取得します
_syntaxhighlighter_scan_lib_location()にwatchdogを入れて、取得したフォルダをログとして出力しました。
結果として、このパス「sites/all/libraries/flexslider/demo/js/shCore.jssites/all/libraries/flexslider/demo/js/shCore.js」を取得しました。
flexSlider/demoの下に同じ名前（shCore.js）のファイルがあるため、flexsliderライブラリに関連づけられました。

解決：demoフォルダ（「sites/all/libraries/flexslider/demo」）を消して、再インストールします

flexsliderのdemoフォルダが邪魔にになってるため、またライブラリにdemoプログラムを使用しないため、demoフォルダを消しました
SyntaxHighlighterモジュールをアンインストールして、再インストールしたら、機能正常に戻りました

シリーズ記事一覧

記事カテゴリ

タグ

やりたいこと：一つDrupalのソースで複数のサイト（複数のドメイン）を構築したいです

Drupalを用いて複数のサイト（ドメイン）を構築する場合、一つサイト（ドメイン）ごとに一つのDrupalソースで構築することがもちろん問題はありません
Drupalソースが分散すると、バージョンアップ、バグ管理などの作業が大変になります
当然一つのDrupalソースの元で複数のサイト（ドメイン）の構築が必要となります
- 一ドメイン ⇒ Drupalソース ⇒ 共有DB
- 一ドメイン ⇒ Drupalソース ⇒ 独立DB
Drupalでは複数のサイト（ドメイン）への対応をしています

sitesディレクトリの下にドメインごとの子ディレクトリを作成してマルティサイトを構築します

複数のドメイン名をDrupalのルートディレクトリに同期します（例：シンボリックリンクでドメイン名をディレクトリと同期します）
- 例： old-pine.net をDrupalのルートディレクトリにシンボリックリンクで同期します
Drupalのルートディレクトリの下に sites ディレクトリがあります。sitesの下に各メイン名に同期したいディレクトリを作成します
- 例：sites/pine を作成します
sites/sites.phpファイルでドメイン名をディレクトと同期設定を行います
- 例： 'old-pine.net' => 'pine' （書き方：ドメイン名 => ディレクトリ名）
```
 $sites = array(
    'old-pine.net' => 'pine',
 );
```
新規作成したディレクトの下にサイトのインストール設定ファイル(settings.php)の作成
- 例：sites/pine/settings.phpを作成します
- settings.phpの内容はsites/pine/default.settings.phpのコピーで良いです（サイト新規作成する場合）
追加したドメイン名でサイトをアクセスして、新規サイトができたことを確認します

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

シリーズ記事一覧

記事カテゴリ

タグ

別々のDrupal（バージョン７）ソースのサイトを一つ共有ソースのところにサイト移行

複数のDrupalソースで構築した複数のウェブサイトがありまして、Drupalソースのバージョンアップ、バグ管理などに手間がかかり、一つのDrupal共有ソールの元で複数のサイトを構築しました。
今回は一つのサイトを共有ソースのところに移行を行いました
移行をシンプルにするため、事前に不必要ないくつかモジュール（SyntaxHighlighter含め）をアンインストールしました
移行後に再度モジュール（SyntaxHighlighter含め）をインストールし直します

モジュール(SyntaxHighlighter)インストール後にSyntaxHighlighterライブラリが見つからないエラー

まずSyntaxHighlighterのライブラリ（3.0.83）をダウンロードしてsites/all/libraies/syntaxhighlighter_3.0.83に展開しました
通常の方法でSyntaxHighlighterモジュール（7.x-2.0）をインストールして有効化しました

以前のサイトになっかたエラーメッセージ：

Warning: file_get_contents(sites/all/libraries/flexslider/scripts/shCore.js): failed to open stream: No such file or directory _locale_parse_js_file() (/virtual/drills/public_html/drupal7/includes/locale.inc ファイル　1527行).
Warning: file_get_contents(sites/all/libraries/flexslider/scripts/shBrushPhp.js): failed to open stream: No such file or directory _locale_parse_js_file() (/virtual/drills/public_html/drupal7/includes/locale.inc ファイル　1527行)

shCore.jsがSyntaxHighlighterのライブラリにあるはずなのに、なぜかflexsliderライブラリに関連付けられました（不思議なエラー）

問題：flexsliderのライブラリに同じ名前（shCore.js）のファイルがありました

他に同じようなエラーがあるか、検索してみたが、答えはありませんでした
ソースコードを読んで自力で解決するしかないですね。幸い、複雑なモジュールではなく、SyntaxHighlighterのjsファイルをページロード時にクライアント側に渡すプログラムです
最初は sites/all/modules/syntaxhighlighter/syntaxhighlighter.install をチェックしました。44行目にあるライブラリパス取得関数：sntaxhighlighter_get_lib_location()を注目しました
関数（_syntaxhighlighter_get_lib_location()）は sites/all/modules/syntaxhighlighter/syntaxhighlighter.module にあります。さらに、ライブラリパス取得ロジックを探してみました
syntaxhighlighter.moduleの377行あたりにあるライブラリフォルダスキャン関数：_syntaxhighlighter_scan_lib_location()があります
- ライブラリフォルダスキャンの原理：shCore.jsが含まれているフォルダを取得します
_syntaxhighlighter_scan_lib_location()にwatchdogを入れて、取得したフォルダをログとして出力しました。
結果として、このパス「sites/all/libraries/flexslider/demo/js/shCore.jssites/all/libraries/flexslider/demo/js/shCore.js」を取得しました。
flexSlider/demoの下に同じ名前（shCore.js）のファイルがあるため、flexsliderライブラリに関連づけられました。

解決：demoフォルダ（「sites/all/libraries/flexslider/demo」）を消して、再インストールします

flexsliderのdemoフォルダが邪魔にになってるため、またライブラリにdemoプログラムを使用しないため、demoフォルダを消しました
SyntaxHighlighterモジュールをアンインストールして、再インストールしたら、機能正常に戻りました

シリーズ記事一覧

記事カテゴリ

タグ

やりたいこと：一つDrupalのソースで複数のサイト（複数のドメイン）を構築したいです

Drupalを用いて複数のサイト（ドメイン）を構築する場合、一つサイト（ドメイン）ごとに一つのDrupalソースで構築することがもちろん問題はありません
Drupalソースが分散すると、バージョンアップ、バグ管理などの作業が大変になります
当然一つのDrupalソースの元で複数のサイト（ドメイン）の構築が必要となります
- 一ドメイン ⇒ Drupalソース ⇒ 共有DB
- 一ドメイン ⇒ Drupalソース ⇒ 独立DB
Drupalでは複数のサイト（ドメイン）への対応をしています

sitesディレクトリの下にドメインごとの子ディレクトリを作成してマルティサイトを構築します

複数のドメイン名をDrupalのルートディレクトリに同期します（例：シンボリックリンクでドメイン名をディレクトリと同期します）
- 例： old-pine.net をDrupalのルートディレクトリにシンボリックリンクで同期します
Drupalのルートディレクトリの下に sites ディレクトリがあります。sitesの下に各メイン名に同期したいディレクトリを作成します
- 例：sites/pine を作成します
sites/sites.phpファイルでドメイン名をディレクトと同期設定を行います
- 例： 'old-pine.net' => 'pine' （書き方：ドメイン名 => ディレクトリ名）
```
 $sites = array(
    'old-pine.net' => 'pine',
 );
```
新規作成したディレクトの下にサイトのインストール設定ファイル(settings.php)の作成
- 例：sites/pine/settings.phpを作成します
- settings.phpの内容はsites/pine/default.settings.phpのコピーで良いです（サイト新規作成する場合）
追加したドメイン名でサイトをアクセスして、新規サイトができたことを確認します

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

シリーズ記事一覧

記事カテゴリ

タグ

別々のDrupal（バージョン７）ソースのサイトを一つ共有ソースのところにサイト移行

複数のDrupalソースで構築した複数のウェブサイトがありまして、Drupalソースのバージョンアップ、バグ管理などに手間がかかり、一つのDrupal共有ソールの元で複数のサイトを構築しました。
今回は一つのサイトを共有ソースのところに移行を行いました
移行をシンプルにするため、事前に不必要ないくつかモジュール（SyntaxHighlighter含め）をアンインストールしました
移行後に再度モジュール（SyntaxHighlighter含め）をインストールし直します

モジュール(SyntaxHighlighter)インストール後にSyntaxHighlighterライブラリが見つからないエラー

まずSyntaxHighlighterのライブラリ（3.0.83）をダウンロードしてsites/all/libraies/syntaxhighlighter_3.0.83に展開しました
通常の方法でSyntaxHighlighterモジュール（7.x-2.0）をインストールして有効化しました

以前のサイトになっかたエラーメッセージ：

Warning: file_get_contents(sites/all/libraries/flexslider/scripts/shCore.js): failed to open stream: No such file or directory _locale_parse_js_file() (/virtual/drills/public_html/drupal7/includes/locale.inc ファイル　1527行).
Warning: file_get_contents(sites/all/libraries/flexslider/scripts/shBrushPhp.js): failed to open stream: No such file or directory _locale_parse_js_file() (/virtual/drills/public_html/drupal7/includes/locale.inc ファイル　1527行)

shCore.jsがSyntaxHighlighterのライブラリにあるはずなのに、なぜかflexsliderライブラリに関連付けられました（不思議なエラー）

問題：flexsliderのライブラリに同じ名前（shCore.js）のファイルがありました

他に同じようなエラーがあるか、検索してみたが、答えはありませんでした
ソースコードを読んで自力で解決するしかないですね。幸い、複雑なモジュールではなく、SyntaxHighlighterのjsファイルをページロード時にクライアント側に渡すプログラムです
最初は sites/all/modules/syntaxhighlighter/syntaxhighlighter.install をチェックしました。44行目にあるライブラリパス取得関数：sntaxhighlighter_get_lib_location()を注目しました
関数（_syntaxhighlighter_get_lib_location()）は sites/all/modules/syntaxhighlighter/syntaxhighlighter.module にあります。さらに、ライブラリパス取得ロジックを探してみました
syntaxhighlighter.moduleの377行あたりにあるライブラリフォルダスキャン関数：_syntaxhighlighter_scan_lib_location()があります
- ライブラリフォルダスキャンの原理：shCore.jsが含まれているフォルダを取得します
_syntaxhighlighter_scan_lib_location()にwatchdogを入れて、取得したフォルダをログとして出力しました。
結果として、このパス「sites/all/libraries/flexslider/demo/js/shCore.jssites/all/libraries/flexslider/demo/js/shCore.js」を取得しました。
flexSlider/demoの下に同じ名前（shCore.js）のファイルがあるため、flexsliderライブラリに関連づけられました。

解決：demoフォルダ（「sites/all/libraries/flexslider/demo」）を消して、再インストールします

flexsliderのdemoフォルダが邪魔にになってるため、またライブラリにdemoプログラムを使用しないため、demoフォルダを消しました
SyntaxHighlighterモジュールをアンインストールして、再インストールしたら、機能正常に戻りました

シリーズ記事一覧

記事カテゴリ

タグ

やりたいこと：一つDrupalのソースで複数のサイト（複数のドメイン）を構築したいです

Drupalを用いて複数のサイト（ドメイン）を構築する場合、一つサイト（ドメイン）ごとに一つのDrupalソースで構築することがもちろん問題はありません
Drupalソースが分散すると、バージョンアップ、バグ管理などの作業が大変になります
当然一つのDrupalソースの元で複数のサイト（ドメイン）の構築が必要となります
- 一ドメイン ⇒ Drupalソース ⇒ 共有DB
- 一ドメイン ⇒ Drupalソース ⇒ 独立DB
Drupalでは複数のサイト（ドメイン）への対応をしています

sitesディレクトリの下にドメインごとの子ディレクトリを作成してマルティサイトを構築します

複数のドメイン名をDrupalのルートディレクトリに同期します（例：シンボリックリンクでドメイン名をディレクトリと同期します）
- 例： old-pine.net をDrupalのルートディレクトリにシンボリックリンクで同期します
Drupalのルートディレクトリの下に sites ディレクトリがあります。sitesの下に各メイン名に同期したいディレクトリを作成します
- 例：sites/pine を作成します
sites/sites.phpファイルでドメイン名をディレクトと同期設定を行います
- 例： 'old-pine.net' => 'pine' （書き方：ドメイン名 => ディレクトリ名）
```
 $sites = array(
    'old-pine.net' => 'pine',
 );
```
新規作成したディレクトの下にサイトのインストール設定ファイル(settings.php)の作成
- 例：sites/pine/settings.phpを作成します
- settings.phpの内容はsites/pine/default.settings.phpのコピーで良いです（サイト新規作成する場合）
追加したドメイン名でサイトをアクセスして、新規サイトができたことを確認します

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

シリーズ記事一覧

記事カテゴリ

タグ

別々のDrupal（バージョン７）ソースのサイトを一つ共有ソースのところにサイト移行

複数のDrupalソースで構築した複数のウェブサイトがありまして、Drupalソースのバージョンアップ、バグ管理などに手間がかかり、一つのDrupal共有ソールの元で複数のサイトを構築しました。
今回は一つのサイトを共有ソースのところに移行を行いました
移行をシンプルにするため、事前に不必要ないくつかモジュール（SyntaxHighlighter含め）をアンインストールしました
移行後に再度モジュール（SyntaxHighlighter含め）をインストールし直します

モジュール(SyntaxHighlighter)インストール後にSyntaxHighlighterライブラリが見つからないエラー

まずSyntaxHighlighterのライブラリ（3.0.83）をダウンロードしてsites/all/libraies/syntaxhighlighter_3.0.83に展開しました
通常の方法でSyntaxHighlighterモジュール（7.x-2.0）をインストールして有効化しました

以前のサイトになっかたエラーメッセージ：

Warning: file_get_contents(sites/all/libraries/flexslider/scripts/shCore.js): failed to open stream: No such file or directory _locale_parse_js_file() (/virtual/drills/public_html/drupal7/includes/locale.inc ファイル　1527行).
Warning: file_get_contents(sites/all/libraries/flexslider/scripts/shBrushPhp.js): failed to open stream: No such file or directory _locale_parse_js_file() (/virtual/drills/public_html/drupal7/includes/locale.inc ファイル　1527行)

shCore.jsがSyntaxHighlighterのライブラリにあるはずなのに、なぜかflexsliderライブラリに関連付けられました（不思議なエラー）

問題：flexsliderのライブラリに同じ名前（shCore.js）のファイルがありました

他に同じようなエラーがあるか、検索してみたが、答えはありませんでした
ソースコードを読んで自力で解決するしかないですね。幸い、複雑なモジュールではなく、SyntaxHighlighterのjsファイルをページロード時にクライアント側に渡すプログラムです
最初は sites/all/modules/syntaxhighlighter/syntaxhighlighter.install をチェックしました。44行目にあるライブラリパス取得関数：sntaxhighlighter_get_lib_location()を注目しました
関数（_syntaxhighlighter_get_lib_location()）は sites/all/modules/syntaxhighlighter/syntaxhighlighter.module にあります。さらに、ライブラリパス取得ロジックを探してみました
syntaxhighlighter.moduleの377行あたりにあるライブラリフォルダスキャン関数：_syntaxhighlighter_scan_lib_location()があります
- ライブラリフォルダスキャンの原理：shCore.jsが含まれているフォルダを取得します
_syntaxhighlighter_scan_lib_location()にwatchdogを入れて、取得したフォルダをログとして出力しました。
結果として、このパス「sites/all/libraries/flexslider/demo/js/shCore.jssites/all/libraries/flexslider/demo/js/shCore.js」を取得しました。
flexSlider/demoの下に同じ名前（shCore.js）のファイルがあるため、flexsliderライブラリに関連づけられました。

解決：demoフォルダ（「sites/all/libraries/flexslider/demo」）を消して、再インストールします

flexsliderのdemoフォルダが邪魔にになってるため、またライブラリにdemoプログラムを使用しないため、demoフォルダを消しました
SyntaxHighlighterモジュールをアンインストールして、再インストールしたら、機能正常に戻りました

シリーズ記事一覧

記事カテゴリ

タグ

やりたいこと：一つDrupalのソースで複数のサイト（複数のドメイン）を構築したいです

Drupalを用いて複数のサイト（ドメイン）を構築する場合、一つサイト（ドメイン）ごとに一つのDrupalソースで構築することがもちろん問題はありません
Drupalソースが分散すると、バージョンアップ、バグ管理などの作業が大変になります
当然一つのDrupalソースの元で複数のサイト（ドメイン）の構築が必要となります
- 一ドメイン ⇒ Drupalソース ⇒ 共有DB
- 一ドメイン ⇒ Drupalソース ⇒ 独立DB
Drupalでは複数のサイト（ドメイン）への対応をしています

sitesディレクトリの下にドメインごとの子ディレクトリを作成してマルティサイトを構築します

複数のドメイン名をDrupalのルートディレクトリに同期します（例：シンボリックリンクでドメイン名をディレクトリと同期します）
- 例： old-pine.net をDrupalのルートディレクトリにシンボリックリンクで同期します
Drupalのルートディレクトリの下に sites ディレクトリがあります。sitesの下に各メイン名に同期したいディレクトリを作成します
- 例：sites/pine を作成します
sites/sites.phpファイルでドメイン名をディレクトと同期設定を行います
- 例： 'old-pine.net' => 'pine' （書き方：ドメイン名 => ディレクトリ名）
```
 $sites = array(
    'old-pine.net' => 'pine',
 );
```
新規作成したディレクトの下にサイトのインストール設定ファイル(settings.php)の作成
- 例：sites/pine/settings.phpを作成します
- settings.phpの内容はsites/pine/default.settings.phpのコピーで良いです（サイト新規作成する場合）
追加したドメイン名でサイトをアクセスして、新規サイトができたことを確認します

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

シリーズ記事一覧

記事カテゴリ

タグ

別々のDrupal（バージョン７）ソースのサイトを一つ共有ソースのところにサイト移行

複数のDrupalソースで構築した複数のウェブサイトがありまして、Drupalソースのバージョンアップ、バグ管理などに手間がかかり、一つのDrupal共有ソールの元で複数のサイトを構築しました。
今回は一つのサイトを共有ソースのところに移行を行いました
移行をシンプルにするため、事前に不必要ないくつかモジュール（SyntaxHighlighter含め）をアンインストールしました
移行後に再度モジュール（SyntaxHighlighter含め）をインストールし直します

モジュール(SyntaxHighlighter)インストール後にSyntaxHighlighterライブラリが見つからないエラー

まずSyntaxHighlighterのライブラリ（3.0.83）をダウンロードしてsites/all/libraies/syntaxhighlighter_3.0.83に展開しました
通常の方法でSyntaxHighlighterモジュール（7.x-2.0）をインストールして有効化しました

以前のサイトになっかたエラーメッセージ：

Warning: file_get_contents(sites/all/libraries/flexslider/scripts/shCore.js): failed to open stream: No such file or directory _locale_parse_js_file() (/virtual/drills/public_html/drupal7/includes/locale.inc ファイル　1527行).
Warning: file_get_contents(sites/all/libraries/flexslider/scripts/shBrushPhp.js): failed to open stream: No such file or directory _locale_parse_js_file() (/virtual/drills/public_html/drupal7/includes/locale.inc ファイル　1527行)

shCore.jsがSyntaxHighlighterのライブラリにあるはずなのに、なぜかflexsliderライブラリに関連付けられました（不思議なエラー）

問題：flexsliderのライブラリに同じ名前（shCore.js）のファイルがありました

他に同じようなエラーがあるか、検索してみたが、答えはありませんでした
ソースコードを読んで自力で解決するしかないですね。幸い、複雑なモジュールではなく、SyntaxHighlighterのjsファイルをページロード時にクライアント側に渡すプログラムです
最初は sites/all/modules/syntaxhighlighter/syntaxhighlighter.install をチェックしました。44行目にあるライブラリパス取得関数：sntaxhighlighter_get_lib_location()を注目しました
関数（_syntaxhighlighter_get_lib_location()）は sites/all/modules/syntaxhighlighter/syntaxhighlighter.module にあります。さらに、ライブラリパス取得ロジックを探してみました
syntaxhighlighter.moduleの377行あたりにあるライブラリフォルダスキャン関数：_syntaxhighlighter_scan_lib_location()があります
- ライブラリフォルダスキャンの原理：shCore.jsが含まれているフォルダを取得します
_syntaxhighlighter_scan_lib_location()にwatchdogを入れて、取得したフォルダをログとして出力しました。
結果として、このパス「sites/all/libraries/flexslider/demo/js/shCore.jssites/all/libraries/flexslider/demo/js/shCore.js」を取得しました。
flexSlider/demoの下に同じ名前（shCore.js）のファイルがあるため、flexsliderライブラリに関連づけられました。

解決：demoフォルダ（「sites/all/libraries/flexslider/demo」）を消して、再インストールします

flexsliderのdemoフォルダが邪魔にになってるため、またライブラリにdemoプログラムを使用しないため、demoフォルダを消しました
SyntaxHighlighterモジュールをアンインストールして、再インストールしたら、機能正常に戻りました

シリーズ記事一覧

記事カテゴリ

タグ

やりたいこと：一つDrupalのソースで複数のサイト（複数のドメイン）を構築したいです

Drupalを用いて複数のサイト（ドメイン）を構築する場合、一つサイト（ドメイン）ごとに一つのDrupalソースで構築することがもちろん問題はありません
Drupalソースが分散すると、バージョンアップ、バグ管理などの作業が大変になります
当然一つのDrupalソースの元で複数のサイト（ドメイン）の構築が必要となります
- 一ドメイン ⇒ Drupalソース ⇒ 共有DB
- 一ドメイン ⇒ Drupalソース ⇒ 独立DB
Drupalでは複数のサイト（ドメイン）への対応をしています

sitesディレクトリの下にドメインごとの子ディレクトリを作成してマルティサイトを構築します

複数のドメイン名をDrupalのルートディレクトリに同期します（例：シンボリックリンクでドメイン名をディレクトリと同期します）
- 例： old-pine.net をDrupalのルートディレクトリにシンボリックリンクで同期します
Drupalのルートディレクトリの下に sites ディレクトリがあります。sitesの下に各メイン名に同期したいディレクトリを作成します
- 例：sites/pine を作成します
sites/sites.phpファイルでドメイン名をディレクトと同期設定を行います
- 例： 'old-pine.net' => 'pine' （書き方：ドメイン名 => ディレクトリ名）
```
 $sites = array(
    'old-pine.net' => 'pine',
 );
```
新規作成したディレクトの下にサイトのインストール設定ファイル(settings.php)の作成
- 例：sites/pine/settings.phpを作成します
- settings.phpの内容はsites/pine/default.settings.phpのコピーで良いです（サイト新規作成する場合）
追加したドメイン名でサイトをアクセスして、新規サイトができたことを確認します

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

シリーズ記事一覧

記事カテゴリ

タグ

別々のDrupal（バージョン７）ソースのサイトを一つ共有ソースのところにサイト移行

複数のDrupalソースで構築した複数のウェブサイトがありまして、Drupalソースのバージョンアップ、バグ管理などに手間がかかり、一つのDrupal共有ソールの元で複数のサイトを構築しました。
今回は一つのサイトを共有ソースのところに移行を行いました
移行をシンプルにするため、事前に不必要ないくつかモジュール（SyntaxHighlighter含め）をアンインストールしました
移行後に再度モジュール（SyntaxHighlighter含め）をインストールし直します

モジュール(SyntaxHighlighter)インストール後にSyntaxHighlighterライブラリが見つからないエラー

まずSyntaxHighlighterのライブラリ（3.0.83）をダウンロードしてsites/all/libraies/syntaxhighlighter_3.0.83に展開しました
通常の方法でSyntaxHighlighterモジュール（7.x-2.0）をインストールして有効化しました

以前のサイトになっかたエラーメッセージ：

Warning: file_get_contents(sites/all/libraries/flexslider/scripts/shCore.js): failed to open stream: No such file or directory _locale_parse_js_file() (/virtual/drills/public_html/drupal7/includes/locale.inc ファイル　1527行).
Warning: file_get_contents(sites/all/libraries/flexslider/scripts/shBrushPhp.js): failed to open stream: No such file or directory _locale_parse_js_file() (/virtual/drills/public_html/drupal7/includes/locale.inc ファイル　1527行)

shCore.jsがSyntaxHighlighterのライブラリにあるはずなのに、なぜかflexsliderライブラリに関連付けられました（不思議なエラー）

問題：flexsliderのライブラリに同じ名前（shCore.js）のファイルがありました

他に同じようなエラーがあるか、検索してみたが、答えはありませんでした
ソースコードを読んで自力で解決するしかないですね。幸い、複雑なモジュールではなく、SyntaxHighlighterのjsファイルをページロード時にクライアント側に渡すプログラムです
最初は sites/all/modules/syntaxhighlighter/syntaxhighlighter.install をチェックしました。44行目にあるライブラリパス取得関数：sntaxhighlighter_get_lib_location()を注目しました
関数（_syntaxhighlighter_get_lib_location()）は sites/all/modules/syntaxhighlighter/syntaxhighlighter.module にあります。さらに、ライブラリパス取得ロジックを探してみました
syntaxhighlighter.moduleの377行あたりにあるライブラリフォルダスキャン関数：_syntaxhighlighter_scan_lib_location()があります
- ライブラリフォルダスキャンの原理：shCore.jsが含まれているフォルダを取得します
_syntaxhighlighter_scan_lib_location()にwatchdogを入れて、取得したフォルダをログとして出力しました。
結果として、このパス「sites/all/libraries/flexslider/demo/js/shCore.jssites/all/libraries/flexslider/demo/js/shCore.js」を取得しました。
flexSlider/demoの下に同じ名前（shCore.js）のファイルがあるため、flexsliderライブラリに関連づけられました。

解決：demoフォルダ（「sites/all/libraries/flexslider/demo」）を消して、再インストールします

flexsliderのdemoフォルダが邪魔にになってるため、またライブラリにdemoプログラムを使用しないため、demoフォルダを消しました
SyntaxHighlighterモジュールをアンインストールして、再インストールしたら、機能正常に戻りました

シリーズ記事一覧

記事カテゴリ

タグ

やりたいこと：一つDrupalのソースで複数のサイト（複数のドメイン）を構築したいです

Drupalを用いて複数のサイト（ドメイン）を構築する場合、一つサイト（ドメイン）ごとに一つのDrupalソースで構築することがもちろん問題はありません
Drupalソースが分散すると、バージョンアップ、バグ管理などの作業が大変になります
当然一つのDrupalソースの元で複数のサイト（ドメイン）の構築が必要となります
- 一ドメイン ⇒ Drupalソース ⇒ 共有DB
- 一ドメイン ⇒ Drupalソース ⇒ 独立DB
Drupalでは複数のサイト（ドメイン）への対応をしています

sitesディレクトリの下にドメインごとの子ディレクトリを作成してマルティサイトを構築します

複数のドメイン名をDrupalのルートディレクトリに同期します（例：シンボリックリンクでドメイン名をディレクトリと同期します）
- 例： old-pine.net をDrupalのルートディレクトリにシンボリックリンクで同期します
Drupalのルートディレクトリの下に sites ディレクトリがあります。sitesの下に各メイン名に同期したいディレクトリを作成します
- 例：sites/pine を作成します
sites/sites.phpファイルでドメイン名をディレクトと同期設定を行います
- 例： 'old-pine.net' => 'pine' （書き方：ドメイン名 => ディレクトリ名）
```
 $sites = array(
    'old-pine.net' => 'pine',
 );
```
新規作成したディレクトの下にサイトのインストール設定ファイル(settings.php)の作成
- 例：sites/pine/settings.phpを作成します
- settings.phpの内容はsites/pine/default.settings.phpのコピーで良いです（サイト新規作成する場合）
追加したドメイン名でサイトをアクセスして、新規サイトができたことを確認します

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

シリーズ記事一覧

記事カテゴリ

タグ

別々のDrupal（バージョン７）ソースのサイトを一つ共有ソースのところにサイト移行

複数のDrupalソースで構築した複数のウェブサイトがありまして、Drupalソースのバージョンアップ、バグ管理などに手間がかかり、一つのDrupal共有ソールの元で複数のサイトを構築しました。
今回は一つのサイトを共有ソースのところに移行を行いました
移行をシンプルにするため、事前に不必要ないくつかモジュール（SyntaxHighlighter含め）をアンインストールしました
移行後に再度モジュール（SyntaxHighlighter含め）をインストールし直します

モジュール(SyntaxHighlighter)インストール後にSyntaxHighlighterライブラリが見つからないエラー

まずSyntaxHighlighterのライブラリ（3.0.83）をダウンロードしてsites/all/libraies/syntaxhighlighter_3.0.83に展開しました
通常の方法でSyntaxHighlighterモジュール（7.x-2.0）をインストールして有効化しました

以前のサイトになっかたエラーメッセージ：

Warning: file_get_contents(sites/all/libraries/flexslider/scripts/shCore.js): failed to open stream: No such file or directory _locale_parse_js_file() (/virtual/drills/public_html/drupal7/includes/locale.inc ファイル　1527行).
Warning: file_get_contents(sites/all/libraries/flexslider/scripts/shBrushPhp.js): failed to open stream: No such file or directory _locale_parse_js_file() (/virtual/drills/public_html/drupal7/includes/locale.inc ファイル　1527行)

shCore.jsがSyntaxHighlighterのライブラリにあるはずなのに、なぜかflexsliderライブラリに関連付けられました（不思議なエラー）

問題：flexsliderのライブラリに同じ名前（shCore.js）のファイルがありました

他に同じようなエラーがあるか、検索してみたが、答えはありませんでした
ソースコードを読んで自力で解決するしかないですね。幸い、複雑なモジュールではなく、SyntaxHighlighterのjsファイルをページロード時にクライアント側に渡すプログラムです
最初は sites/all/modules/syntaxhighlighter/syntaxhighlighter.install をチェックしました。44行目にあるライブラリパス取得関数：sntaxhighlighter_get_lib_location()を注目しました
関数（_syntaxhighlighter_get_lib_location()）は sites/all/modules/syntaxhighlighter/syntaxhighlighter.module にあります。さらに、ライブラリパス取得ロジックを探してみました
syntaxhighlighter.moduleの377行あたりにあるライブラリフォルダスキャン関数：_syntaxhighlighter_scan_lib_location()があります
- ライブラリフォルダスキャンの原理：shCore.jsが含まれているフォルダを取得します
_syntaxhighlighter_scan_lib_location()にwatchdogを入れて、取得したフォルダをログとして出力しました。
結果として、このパス「sites/all/libraries/flexslider/demo/js/shCore.jssites/all/libraries/flexslider/demo/js/shCore.js」を取得しました。
flexSlider/demoの下に同じ名前（shCore.js）のファイルがあるため、flexsliderライブラリに関連づけられました。

解決：demoフォルダ（「sites/all/libraries/flexslider/demo」）を消して、再インストールします

flexsliderのdemoフォルダが邪魔にになってるため、またライブラリにdemoプログラムを使用しないため、demoフォルダを消しました
SyntaxHighlighterモジュールをアンインストールして、再インストールしたら、機能正常に戻りました

シリーズ記事一覧

記事カテゴリ

タグ

やりたいこと：一つDrupalのソースで複数のサイト（複数のドメイン）を構築したいです

Drupalを用いて複数のサイト（ドメイン）を構築する場合、一つサイト（ドメイン）ごとに一つのDrupalソースで構築することがもちろん問題はありません
Drupalソースが分散すると、バージョンアップ、バグ管理などの作業が大変になります
当然一つのDrupalソースの元で複数のサイト（ドメイン）の構築が必要となります
- 一ドメイン ⇒ Drupalソース ⇒ 共有DB
- 一ドメイン ⇒ Drupalソース ⇒ 独立DB
Drupalでは複数のサイト（ドメイン）への対応をしています

sitesディレクトリの下にドメインごとの子ディレクトリを作成してマルティサイトを構築します

複数のドメイン名をDrupalのルートディレクトリに同期します（例：シンボリックリンクでドメイン名をディレクトリと同期します）
- 例： old-pine.net をDrupalのルートディレクトリにシンボリックリンクで同期します
Drupalのルートディレクトリの下に sites ディレクトリがあります。sitesの下に各メイン名に同期したいディレクトリを作成します
- 例：sites/pine を作成します
sites/sites.phpファイルでドメイン名をディレクトと同期設定を行います
- 例： 'old-pine.net' => 'pine' （書き方：ドメイン名 => ディレクトリ名）
```
 $sites = array(
    'old-pine.net' => 'pine',
 );
```
新規作成したディレクトの下にサイトのインストール設定ファイル(settings.php)の作成
- 例：sites/pine/settings.phpを作成します
- settings.phpの内容はsites/pine/default.settings.phpのコピーで良いです（サイト新規作成する場合）
追加したドメイン名でサイトをアクセスして、新規サイトができたことを確認します

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

シリーズ記事一覧

記事カテゴリ

タグ

別々のDrupal（バージョン７）ソースのサイトを一つ共有ソースのところにサイト移行

複数のDrupalソースで構築した複数のウェブサイトがありまして、Drupalソースのバージョンアップ、バグ管理などに手間がかかり、一つのDrupal共有ソールの元で複数のサイトを構築しました。
今回は一つのサイトを共有ソースのところに移行を行いました
移行をシンプルにするため、事前に不必要ないくつかモジュール（SyntaxHighlighter含め）をアンインストールしました
移行後に再度モジュール（SyntaxHighlighter含め）をインストールし直します

モジュール(SyntaxHighlighter)インストール後にSyntaxHighlighterライブラリが見つからないエラー

まずSyntaxHighlighterのライブラリ（3.0.83）をダウンロードしてsites/all/libraies/syntaxhighlighter_3.0.83に展開しました
通常の方法でSyntaxHighlighterモジュール（7.x-2.0）をインストールして有効化しました

以前のサイトになっかたエラーメッセージ：

Warning: file_get_contents(sites/all/libraries/flexslider/scripts/shCore.js): failed to open stream: No such file or directory _locale_parse_js_file() (/virtual/drills/public_html/drupal7/includes/locale.inc ファイル　1527行).
Warning: file_get_contents(sites/all/libraries/flexslider/scripts/shBrushPhp.js): failed to open stream: No such file or directory _locale_parse_js_file() (/virtual/drills/public_html/drupal7/includes/locale.inc ファイル　1527行)

shCore.jsがSyntaxHighlighterのライブラリにあるはずなのに、なぜかflexsliderライブラリに関連付けられました（不思議なエラー）

問題：flexsliderのライブラリに同じ名前（shCore.js）のファイルがありました

他に同じようなエラーがあるか、検索してみたが、答えはありませんでした
ソースコードを読んで自力で解決するしかないですね。幸い、複雑なモジュールではなく、SyntaxHighlighterのjsファイルをページロード時にクライアント側に渡すプログラムです
最初は sites/all/modules/syntaxhighlighter/syntaxhighlighter.install をチェックしました。44行目にあるライブラリパス取得関数：sntaxhighlighter_get_lib_location()を注目しました
関数（_syntaxhighlighter_get_lib_location()）は sites/all/modules/syntaxhighlighter/syntaxhighlighter.module にあります。さらに、ライブラリパス取得ロジックを探してみました
syntaxhighlighter.moduleの377行あたりにあるライブラリフォルダスキャン関数：_syntaxhighlighter_scan_lib_location()があります
- ライブラリフォルダスキャンの原理：shCore.jsが含まれているフォルダを取得します
_syntaxhighlighter_scan_lib_location()にwatchdogを入れて、取得したフォルダをログとして出力しました。
結果として、このパス「sites/all/libraries/flexslider/demo/js/shCore.jssites/all/libraries/flexslider/demo/js/shCore.js」を取得しました。
flexSlider/demoの下に同じ名前（shCore.js）のファイルがあるため、flexsliderライブラリに関連づけられました。

解決：demoフォルダ（「sites/all/libraries/flexslider/demo」）を消して、再インストールします

flexsliderのdemoフォルダが邪魔にになってるため、またライブラリにdemoプログラムを使用しないため、demoフォルダを消しました
SyntaxHighlighterモジュールをアンインストールして、再インストールしたら、機能正常に戻りました

シリーズ記事一覧

記事カテゴリ

タグ

やりたいこと：一つDrupalのソースで複数のサイト（複数のドメイン）を構築したいです

Drupalを用いて複数のサイト（ドメイン）を構築する場合、一つサイト（ドメイン）ごとに一つのDrupalソースで構築することがもちろん問題はありません
Drupalソースが分散すると、バージョンアップ、バグ管理などの作業が大変になります
当然一つのDrupalソースの元で複数のサイト（ドメイン）の構築が必要となります
- 一ドメイン ⇒ Drupalソース ⇒ 共有DB
- 一ドメイン ⇒ Drupalソース ⇒ 独立DB
Drupalでは複数のサイト（ドメイン）への対応をしています

sitesディレクトリの下にドメインごとの子ディレクトリを作成してマルティサイトを構築します

複数のドメイン名をDrupalのルートディレクトリに同期します（例：シンボリックリンクでドメイン名をディレクトリと同期します）
- 例： old-pine.net をDrupalのルートディレクトリにシンボリックリンクで同期します
Drupalのルートディレクトリの下に sites ディレクトリがあります。sitesの下に各メイン名に同期したいディレクトリを作成します
- 例：sites/pine を作成します
sites/sites.phpファイルでドメイン名をディレクトと同期設定を行います
- 例： 'old-pine.net' => 'pine' （書き方：ドメイン名 => ディレクトリ名）
```
 $sites = array(
    'old-pine.net' => 'pine',
 );
```
新規作成したディレクトの下にサイトのインストール設定ファイル(settings.php)の作成
- 例：sites/pine/settings.phpを作成します
- settings.phpの内容はsites/pine/default.settings.phpのコピーで良いです（サイト新規作成する場合）
追加したドメイン名でサイトをアクセスして、新規サイトができたことを確認します

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ

エラー：モジュール(Twitter)をバージョンアップしてフロントページに開くと「EntityFieldQueryException」が発生

モジュール(Twitter)のバージョン：7.x-5.11 ⇒ 7.x-6.2 にアップデートしました（新モジュールから旧モジュールを上書き）

フロントページを開いてみたらエラーが発生し：

EntityFieldQueryException: エンティティー <em class="placeholder">twitter_account</em> にはベーステーブルがありません。 EntityFieldQuery->propertyQuery() (/virtual/drills/public_html/drupal7/includes/entity.inc ファイル　1271行).

画面にエラーしか表示されていないです

原因：Twitter7.x-5.11⇒7.x-6.2にアップデートする場合DBのテーブルが追加されたので、DB更新が必要

原因は比較的に単純的で、Twitter7.x-6.2（7.x-6.0以上になるとデータ構造が変わった）が7.x-5.11よりデータテーブルが追加されました
管理者権限でupdate.phpを実行してデータテーブルを追加します

シリーズ記事一覧

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ

やりたいこと：一つDrupalのソースで複数のサイト（複数のドメイン）を構築したいです

Drupalを用いて複数のサイト（ドメイン）を構築する場合、一つサイト（ドメイン）ごとに一つのDrupalソースで構築することがもちろん問題はありません
Drupalソースが分散すると、バージョンアップ、バグ管理などの作業が大変になります
当然一つのDrupalソースの元で複数のサイト（ドメイン）の構築が必要となります
- 一ドメイン ⇒ Drupalソース ⇒ 共有DB
- 一ドメイン ⇒ Drupalソース ⇒ 独立DB
Drupalでは複数のサイト（ドメイン）への対応をしています

sitesディレクトリの下にドメインごとの子ディレクトリを作成してマルティサイトを構築します

複数のドメイン名をDrupalのルートディレクトリに同期します（例：シンボリックリンクでドメイン名をディレクトリと同期します）
- 例： old-pine.net をDrupalのルートディレクトリにシンボリックリンクで同期します
Drupalのルートディレクトリの下に sites ディレクトリがあります。sitesの下に各メイン名に同期したいディレクトリを作成します
- 例：sites/pine を作成します
sites/sites.phpファイルでドメイン名をディレクトと同期設定を行います
- 例： 'old-pine.net' => 'pine' （書き方：ドメイン名 => ディレクトリ名）
```
 $sites = array(
    'old-pine.net' => 'pine',
 );
```
新規作成したディレクトの下にサイトのインストール設定ファイル(settings.php)の作成
- 例：sites/pine/settings.phpを作成します
- settings.phpの内容はsites/pine/default.settings.phpのコピーで良いです（サイト新規作成する場合）
追加したドメイン名でサイトをアクセスして、新規サイトができたことを確認します

記事カテゴリ

タグ

やりたいこと：レンタルサーバーで申請したドメイン名を特定なディレクトリに同期するシンボリックリンク作成したいです

レンタルサーバー（例：valueserver）で申請したドメイン名を特定なディレクトに同期するツールが提供されています
同期ツールを利用するのは便利だが、設定が誤ると同期先のディレクトリのファイルがすべて削除されてします危険があります
特に、この操作がよく行うことではなく、誤って設定する確率は実は高そうです（実際に設定を誤って、同期先のファイルが消されてしまう事項がありました）

安全のため、シンボリックリンク作成コマンドでディレクト同期をしたほうがよいです

シンボリックリンク作成：
- public_htmlディレクトリ（apacheではdocument root）に入ります
- コマンド： ln -s [ディレクト名] [ドメイン名] （例：ln -s drupal7 old-pine.net）
- コマンド： ls -l　で生成したシンボリックリンクを確認します（例： old-pine.net -> pine）
シンボリックリンクの削除
- コマンド：unlink [ドメイン名] (例：unlink old-pine.net)
- コマンド：ls -l でドメイン名の同期先が消えたことを確認します

安全のため、コマンド(rm)でシンボリックリンクを削除しないこと

シンボリックリンクを削除するのはコマンド(rm)できますが、誤って指定すると、同期先のディレクトリの内容を削除していまう危険があります
シンボリックリンクを削除するには、コマンド(unlink)を使用すべきです

記事カテゴリ

タグ

モジュール（Feature）が開発ソース管理、コンテンツデータ移行などに利用されます

最初モジュール（Feature）が何に使うかはあまりわからなかったです（いろいろな説明がちゅ抽象的）。
実はDrupalの開発ソース管理（例：開発環境ー＞ステージん環境ー＞本番環境）、コンテンツデータの移行に使用されます

データ移行例：コンテンツデータ（Article）＋Viewsで作成したコンテンツ検索一覧画面

データ移行の簡単な例として、既存のコンテンツデータ（例：Article⇒記事）、Viewsで作成したコンテンツ一覧画面を移行します
コンテンツデータ移行に必須なモジュール：
- Feature
- Node Export （FeatureモジュールにサポートするNode export featuresサブモジュールを有効化）
Feature管理画面で必要なモジュール、モジュールの関連、コンテンツデータを選択して、一つのモジュールとして作成し、ダウンロードします
作成されたモジュール（tarファイル）を移行先で通常のモジュールインストールをして、有効化を行います。Feature管理画面で移行元の内容を適用、保存します
具体的な操作はビデオをご参考ください

FeatureがDurupalのすべての設定、構成の移行はできません

移行はモジュール単位で、構成は出力可能なものを中心にしています。以下は移行可能な部分
- Core ： Content Types、 Fields、 Menus、 Taxonomies、 Text formats、 Image styles、 User roles 、 permissions
- Contribute： Views、 CTools、 Context 、 Panels、 Rules 、 Contexts、 Display Suite
移行できない部分は、例：テーマ、コンテンツに挿入した画像などがあります
- コンテンツに含まるメディア（例：写真、ビデオ、ファイルなど）がローカル（sites/default/files）に保存したため、移行先の保存パス修正、およびメディアファイルのコピーが手動で行う必要があります

video

記事カテゴリ

タグ

Drupalの部分的なコンテンツデータを別のDrualサイトに移行する場合そのコンテンツの構造定義とコンテンツCSVデータのエクスポート／インポートができます

背景：Drupal7.54
Drupalのサイト引っ越しなどでデータ移行の必要があります、以下の移行方法はよく利用されます。
- Drupalのモジュール（Feature）を用いてサイト間のデータ移行/開発管理を行います (162)
- 同じDrupalバージョンの単一サイトを複数サイト（ドメイン）の一つDrupalの共有ソースサイトへの移行チャレンジ (161)
ただし、部分的なコンテンツしか移行しない場合、上記方法では難しくなります
ここで、コンテンツ定義とデータを別々でexport/import方法を説明します

Drupalのモジュール（Bundle copy、 Taxonomy CSV import/export）でコンテンツの構成／定義をExport/Importします

モジュール（Bundle copy）でコンテンツの構成／定義を簡単に移行します（具体的にステップは省略）
タクソノミーのタームの構成（フィールドが追加など）が変わらなければ、モジュール（、Taxonomy CSV import/export）でタームリストデータをcsvファイルの出力することはできます
- 出力したCSVデータの別のサイトにインポートする場合、タクソノミーのボキャブラリーとタームIDが変わった可能性があります
- コンテンツのフィールドに「Term Reference」タイプのものがあれば、コンテンツ追加／編集ボタンをクリックすると、「HTTP ERROR 500」エラーが発生するかもしれないです
- 一番簡単な対応方法ではそのフィールドを一回削除して、再作成すればよいです（データインポートする前の段階）

Drupalのコンテンツ構成（フィールド）テーブルのデータをcsvフォーマットに出力します

現時点ではコンテンツのデータをcsvに出力するモジュールはあまり見当たらにです
コンテンツのフィールドをDB上各テーブルを見つけ出します
- コンテンツ（例：Article）のフィールドごとに一つのテールが存在しています
- Title ➡　nodeテーブルの「title」フィールド
- body ➡　field_data_bodyテーブルの「body_value」フィールド（またはbody_summaryなど）
- カスタムフィールド ➡　field_data_CUSTOM_FIELD_NAMEの「field_data_CUSTOM_FIELD_NAME_value」フィールド
これらのテーブルを「node」テーブルを中心してジョインして、新しいテーブルの書き込みます
- すべてのコンテンツは「node」テーブルを基本にしています
- 各フィールドのテーブルに「entity_id」がnodeテーブルの「nid」の関連付けキーとなります
- 全フィールドと同じフィールドの新しいテーブルを一つ作成します（例：new_table）
- 全フィールドをJOINしてデータを新しいテーブル（例：new_table）にコピーします
```
INSERT INTO new_table (title, body, CUSTOM_FIELD_NAME,   ・・・・・・)
SELECT 
   title,
   body.body_value,
   T1.field_data_CUSTOM_FIEDL_NAME_value,
  ・・・・・・
FROM node
   left join field_data_body body on nid = body.entity_id
   left join field_data_CUSTOM_FIELD_NAME  T1  on T1.entity_id = nid
  ・・・・・・
  
```
新しいテーブル（new_table）の内容をｃｓｖフォーマットに出力します

Drupalのモジュール（Feeds Import）でコンテンツｃｓｖデータをインポートします

モジュール（Feeds Import）がよく利用されるものなので、簡単にｃｓｖデータを確認コンテンツにインポートすることができます
Feeds Importの説明は省略します(Drupalのモジュール（Feeds）で手動でデータインポート時の必須設定 (199)、FeedsモジュールでEnityにデータインポート (34)などを参考にしてください)

シリーズ記事一覧

記事カテゴリ

タグ

モジュール（Feature）が開発ソース管理、コンテンツデータ移行などに利用されます

最初モジュール（Feature）が何に使うかはあまりわからなかったです（いろいろな説明がちゅ抽象的）。
実はDrupalの開発ソース管理（例：開発環境ー＞ステージん環境ー＞本番環境）、コンテンツデータの移行に使用されます

データ移行例：コンテンツデータ（Article）＋Viewsで作成したコンテンツ検索一覧画面

データ移行の簡単な例として、既存のコンテンツデータ（例：Article⇒記事）、Viewsで作成したコンテンツ一覧画面を移行します
コンテンツデータ移行に必須なモジュール：
- Feature
- Node Export （FeatureモジュールにサポートするNode export featuresサブモジュールを有効化）
Feature管理画面で必要なモジュール、モジュールの関連、コンテンツデータを選択して、一つのモジュールとして作成し、ダウンロードします
作成されたモジュール（tarファイル）を移行先で通常のモジュールインストールをして、有効化を行います。Feature管理画面で移行元の内容を適用、保存します
具体的な操作はビデオをご参考ください

FeatureがDurupalのすべての設定、構成の移行はできません

移行はモジュール単位で、構成は出力可能なものを中心にしています。以下は移行可能な部分
- Core ： Content Types、 Fields、 Menus、 Taxonomies、 Text formats、 Image styles、 User roles 、 permissions
- Contribute： Views、 CTools、 Context 、 Panels、 Rules 、 Contexts、 Display Suite
移行できない部分は、例：テーマ、コンテンツに挿入した画像などがあります
- コンテンツに含まるメディア（例：写真、ビデオ、ファイルなど）がローカル（sites/default/files）に保存したため、移行先の保存パス修正、およびメディアファイルのコピーが手動で行う必要があります

video

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ

注意点：Drupalのモジュール（Feeds）の設定が間違うと手動でデータインポートができなくなります

環境：Drupal7.54、Feeds7.x-3.0
やりたいこと：手動でデータをインポート（例：csvファイルからのインポートなど）
Feedの基本設定のところある二か所をチェックしないと手動でのインポートができない
- 添付するコンテンツタイプ：スタントアローンのフォームを使う
- 投稿時にインポート
- 初期としてはこの二つ設定を有効にしています
ちなみに、「投稿時にインポート」を無効の場合、バッチでデータインポートすることになります（バッチの設定が必要）
添付するコンテンツタイプ：「スタントアローンのフォームを使う」以外の選択肢を選択すると、インポート画面（ホーム » インポート）に当該インポーターはありません

手動でインポートできないときに画面上に「インポートされた項目はありません」が表示されます

「投稿時にインポート」オプションが無効の場合、手動でデータインポートはできません
インポートデータがあるにはかかわらず、画面上に「インポートされた項目はありません」として表示されます
バッチにインポートジョブを入れたメッセージはありません

記事カテゴリ

タグ

目的

Entity Typeデータにほかのデータ（例：ｃｓｖ、xmlなど）からのインポートを可能にする
Feedsの初期データ変換プロセッサーに「Entity Type」のものがなかった

解決の選択肢

Feed Importモジュールでのデータインポート
Feedsモジュールのカスタマイズをする

ここでの解決：Feedsのカスタマイズ

インストールされたモジュール
- Feeds : 7.x-2.0
- ECK : 7.x-2.0
- Entity API : 7.x-1.5
上記モジュールのインストールと有効化
ECKでインポートデータタイプとBundleを作成する
- 例：　データタイプ：「組織データ」、Bundle：「ｘｘｘの組織データ」
- 「組織データ」のプロパティ：title、uid、created、changedを使用する
- 「ｘｘｘの組織データ」のフィールド：「組織コード」、「正式組織名」をテキストフィールドで追加

Feedsの紹介

Feedsが三つの部分から構成される：Fetcher、Parser、Processor
- Fetcher：インポータデータの取得（例：File upload、external RSS Feedなど）
- Parser：インポートデータの解析方法の指定（csv、xls、xml、RSSなど）
- Processor：インポートデータの作成（Node、terms、usersなどのデータ作成）

FeedsにEntity Typeデータ変換プロセッサーに追加

PatchファイルをFeedsモジュールに当てる
Feedsのデータ変換プロセッサー設定画面にEntity Typeのデータ変換プロセッサー追加前後のイメージ

files

添付	サイズ
feeds_entity_processor-1033202-217.patch_.txt (16.03 KB)	16.03 KB

記事カテゴリ

タグ

エラー：モジュール(Twitter)をバージョンアップしてフロントページに開くと「EntityFieldQueryException」が発生

モジュール(Twitter)のバージョン：7.x-5.11 ⇒ 7.x-6.2 にアップデートしました（新モジュールから旧モジュールを上書き）

フロントページを開いてみたらエラーが発生し：

EntityFieldQueryException: エンティティー <em class="placeholder">twitter_account</em> にはベーステーブルがありません。 EntityFieldQuery->propertyQuery() (/virtual/drills/public_html/drupal7/includes/entity.inc ファイル　1271行).

画面にエラーしか表示されていないです

原因：Twitter7.x-5.11⇒7.x-6.2にアップデートする場合DBのテーブルが追加されたので、DB更新が必要

原因は比較的に単純的で、Twitter7.x-6.2（7.x-6.0以上になるとデータ構造が変わった）が7.x-5.11よりデータテーブルが追加されました
管理者権限でupdate.phpを実行してデータテーブルを追加します

シリーズ記事一覧

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ

やりたいこと：一つDrupalのソースで複数のサイト（複数のドメイン）を構築したいです

Drupalを用いて複数のサイト（ドメイン）を構築する場合、一つサイト（ドメイン）ごとに一つのDrupalソースで構築することがもちろん問題はありません
Drupalソースが分散すると、バージョンアップ、バグ管理などの作業が大変になります
当然一つのDrupalソースの元で複数のサイト（ドメイン）の構築が必要となります
- 一ドメイン ⇒ Drupalソース ⇒ 共有DB
- 一ドメイン ⇒ Drupalソース ⇒ 独立DB
Drupalでは複数のサイト（ドメイン）への対応をしています

sitesディレクトリの下にドメインごとの子ディレクトリを作成してマルティサイトを構築します

複数のドメイン名をDrupalのルートディレクトリに同期します（例：シンボリックリンクでドメイン名をディレクトリと同期します）
- 例： old-pine.net をDrupalのルートディレクトリにシンボリックリンクで同期します
Drupalのルートディレクトリの下に sites ディレクトリがあります。sitesの下に各メイン名に同期したいディレクトリを作成します
- 例：sites/pine を作成します
sites/sites.phpファイルでドメイン名をディレクトと同期設定を行います
- 例： 'old-pine.net' => 'pine' （書き方：ドメイン名 => ディレクトリ名）
```
 $sites = array(
    'old-pine.net' => 'pine',
 );
```
新規作成したディレクトの下にサイトのインストール設定ファイル(settings.php)の作成
- 例：sites/pine/settings.phpを作成します
- settings.phpの内容はsites/pine/default.settings.phpのコピーで良いです（サイト新規作成する場合）
追加したドメイン名でサイトをアクセスして、新規サイトができたことを確認します

記事カテゴリ

タグ

やりたいこと：レンタルサーバーで申請したドメイン名を特定なディレクトリに同期するシンボリックリンク作成したいです

レンタルサーバー（例：valueserver）で申請したドメイン名を特定なディレクトに同期するツールが提供されています
同期ツールを利用するのは便利だが、設定が誤ると同期先のディレクトリのファイルがすべて削除されてします危険があります
特に、この操作がよく行うことではなく、誤って設定する確率は実は高そうです（実際に設定を誤って、同期先のファイルが消されてしまう事項がありました）

安全のため、シンボリックリンク作成コマンドでディレクト同期をしたほうがよいです

シンボリックリンク作成：
- public_htmlディレクトリ（apacheではdocument root）に入ります
- コマンド： ln -s [ディレクト名] [ドメイン名] （例：ln -s drupal7 old-pine.net）
- コマンド： ls -l　で生成したシンボリックリンクを確認します（例： old-pine.net -> pine）
シンボリックリンクの削除
- コマンド：unlink [ドメイン名] (例：unlink old-pine.net)
- コマンド：ls -l でドメイン名の同期先が消えたことを確認します

安全のため、コマンド(rm)でシンボリックリンクを削除しないこと

シンボリックリンクを削除するのはコマンド(rm)できますが、誤って指定すると、同期先のディレクトリの内容を削除していまう危険があります
シンボリックリンクを削除するには、コマンド(unlink)を使用すべきです

記事カテゴリ

タグ

モジュール（Feature）が開発ソース管理、コンテンツデータ移行などに利用されます

最初モジュール（Feature）が何に使うかはあまりわからなかったです（いろいろな説明がちゅ抽象的）。
実はDrupalの開発ソース管理（例：開発環境ー＞ステージん環境ー＞本番環境）、コンテンツデータの移行に使用されます

データ移行例：コンテンツデータ（Article）＋Viewsで作成したコンテンツ検索一覧画面

データ移行の簡単な例として、既存のコンテンツデータ（例：Article⇒記事）、Viewsで作成したコンテンツ一覧画面を移行します
コンテンツデータ移行に必須なモジュール：
- Feature
- Node Export （FeatureモジュールにサポートするNode export featuresサブモジュールを有効化）
Feature管理画面で必要なモジュール、モジュールの関連、コンテンツデータを選択して、一つのモジュールとして作成し、ダウンロードします
作成されたモジュール（tarファイル）を移行先で通常のモジュールインストールをして、有効化を行います。Feature管理画面で移行元の内容を適用、保存します
具体的な操作はビデオをご参考ください

FeatureがDurupalのすべての設定、構成の移行はできません

移行はモジュール単位で、構成は出力可能なものを中心にしています。以下は移行可能な部分
- Core ： Content Types、 Fields、 Menus、 Taxonomies、 Text formats、 Image styles、 User roles 、 permissions
- Contribute： Views、 CTools、 Context 、 Panels、 Rules 、 Contexts、 Display Suite
移行できない部分は、例：テーマ、コンテンツに挿入した画像などがあります
- コンテンツに含まるメディア（例：写真、ビデオ、ファイルなど）がローカル（sites/default/files）に保存したため、移行先の保存パス修正、およびメディアファイルのコピーが手動で行う必要があります

video

記事カテゴリ

タグ

Drupalの部分的なコンテンツデータを別のDrualサイトに移行する場合そのコンテンツの構造定義とコンテンツCSVデータのエクスポート／インポートができます

背景：Drupal7.54
Drupalのサイト引っ越しなどでデータ移行の必要があります、以下の移行方法はよく利用されます。
- Drupalのモジュール（Feature）を用いてサイト間のデータ移行/開発管理を行います (162)
- 同じDrupalバージョンの単一サイトを複数サイト（ドメイン）の一つDrupalの共有ソースサイトへの移行チャレンジ (161)
ただし、部分的なコンテンツしか移行しない場合、上記方法では難しくなります
ここで、コンテンツ定義とデータを別々でexport/import方法を説明します

Drupalのモジュール（Bundle copy、 Taxonomy CSV import/export）でコンテンツの構成／定義をExport/Importします

モジュール（Bundle copy）でコンテンツの構成／定義を簡単に移行します（具体的にステップは省略）
タクソノミーのタームの構成（フィールドが追加など）が変わらなければ、モジュール（、Taxonomy CSV import/export）でタームリストデータをcsvファイルの出力することはできます
- 出力したCSVデータの別のサイトにインポートする場合、タクソノミーのボキャブラリーとタームIDが変わった可能性があります
- コンテンツのフィールドに「Term Reference」タイプのものがあれば、コンテンツ追加／編集ボタンをクリックすると、「HTTP ERROR 500」エラーが発生するかもしれないです
- 一番簡単な対応方法ではそのフィールドを一回削除して、再作成すればよいです（データインポートする前の段階）

Drupalのコンテンツ構成（フィールド）テーブルのデータをcsvフォーマットに出力します

現時点ではコンテンツのデータをcsvに出力するモジュールはあまり見当たらにです
コンテンツのフィールドをDB上各テーブルを見つけ出します
- コンテンツ（例：Article）のフィールドごとに一つのテールが存在しています
- Title ➡　nodeテーブルの「title」フィールド
- body ➡　field_data_bodyテーブルの「body_value」フィールド（またはbody_summaryなど）
- カスタムフィールド ➡　field_data_CUSTOM_FIELD_NAMEの「field_data_CUSTOM_FIELD_NAME_value」フィールド
これらのテーブルを「node」テーブルを中心してジョインして、新しいテーブルの書き込みます
- すべてのコンテンツは「node」テーブルを基本にしています
- 各フィールドのテーブルに「entity_id」がnodeテーブルの「nid」の関連付けキーとなります
- 全フィールドと同じフィールドの新しいテーブルを一つ作成します（例：new_table）
- 全フィールドをJOINしてデータを新しいテーブル（例：new_table）にコピーします
```
INSERT INTO new_table (title, body, CUSTOM_FIELD_NAME,   ・・・・・・)
SELECT 
   title,
   body.body_value,
   T1.field_data_CUSTOM_FIEDL_NAME_value,
  ・・・・・・
FROM node
   left join field_data_body body on nid = body.entity_id
   left join field_data_CUSTOM_FIELD_NAME  T1  on T1.entity_id = nid
  ・・・・・・
  
```
新しいテーブル（new_table）の内容をｃｓｖフォーマットに出力します

Drupalのモジュール（Feeds Import）でコンテンツｃｓｖデータをインポートします

モジュール（Feeds Import）がよく利用されるものなので、簡単にｃｓｖデータを確認コンテンツにインポートすることができます
Feeds Importの説明は省略します(Drupalのモジュール（Feeds）で手動でデータインポート時の必須設定 (199)、FeedsモジュールでEnityにデータインポート (34)などを参考にしてください)

シリーズ記事一覧

記事カテゴリ

タグ

モジュール（Feature）が開発ソース管理、コンテンツデータ移行などに利用されます

最初モジュール（Feature）が何に使うかはあまりわからなかったです（いろいろな説明がちゅ抽象的）。
実はDrupalの開発ソース管理（例：開発環境ー＞ステージん環境ー＞本番環境）、コンテンツデータの移行に使用されます

データ移行例：コンテンツデータ（Article）＋Viewsで作成したコンテンツ検索一覧画面

データ移行の簡単な例として、既存のコンテンツデータ（例：Article⇒記事）、Viewsで作成したコンテンツ一覧画面を移行します
コンテンツデータ移行に必須なモジュール：
- Feature
- Node Export （FeatureモジュールにサポートするNode export featuresサブモジュールを有効化）
Feature管理画面で必要なモジュール、モジュールの関連、コンテンツデータを選択して、一つのモジュールとして作成し、ダウンロードします
作成されたモジュール（tarファイル）を移行先で通常のモジュールインストールをして、有効化を行います。Feature管理画面で移行元の内容を適用、保存します
具体的な操作はビデオをご参考ください

FeatureがDurupalのすべての設定、構成の移行はできません

移行はモジュール単位で、構成は出力可能なものを中心にしています。以下は移行可能な部分
- Core ： Content Types、 Fields、 Menus、 Taxonomies、 Text formats、 Image styles、 User roles 、 permissions
- Contribute： Views、 CTools、 Context 、 Panels、 Rules 、 Contexts、 Display Suite
移行できない部分は、例：テーマ、コンテンツに挿入した画像などがあります
- コンテンツに含まるメディア（例：写真、ビデオ、ファイルなど）がローカル（sites/default/files）に保存したため、移行先の保存パス修正、およびメディアファイルのコピーが手動で行う必要があります

video

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ

注意点：Drupalのモジュール（Feeds）の設定が間違うと手動でデータインポートができなくなります

環境：Drupal7.54、Feeds7.x-3.0
やりたいこと：手動でデータをインポート（例：csvファイルからのインポートなど）
Feedの基本設定のところある二か所をチェックしないと手動でのインポートができない
- 添付するコンテンツタイプ：スタントアローンのフォームを使う
- 投稿時にインポート
- 初期としてはこの二つ設定を有効にしています
ちなみに、「投稿時にインポート」を無効の場合、バッチでデータインポートすることになります（バッチの設定が必要）
添付するコンテンツタイプ：「スタントアローンのフォームを使う」以外の選択肢を選択すると、インポート画面（ホーム » インポート）に当該インポーターはありません

手動でインポートできないときに画面上に「インポートされた項目はありません」が表示されます

「投稿時にインポート」オプションが無効の場合、手動でデータインポートはできません
インポートデータがあるにはかかわらず、画面上に「インポートされた項目はありません」として表示されます
バッチにインポートジョブを入れたメッセージはありません

記事カテゴリ

タグ

目的

Entity Typeデータにほかのデータ（例：ｃｓｖ、xmlなど）からのインポートを可能にする
Feedsの初期データ変換プロセッサーに「Entity Type」のものがなかった

解決の選択肢

Feed Importモジュールでのデータインポート
Feedsモジュールのカスタマイズをする

ここでの解決：Feedsのカスタマイズ

インストールされたモジュール
- Feeds : 7.x-2.0
- ECK : 7.x-2.0
- Entity API : 7.x-1.5
上記モジュールのインストールと有効化
ECKでインポートデータタイプとBundleを作成する
- 例：　データタイプ：「組織データ」、Bundle：「ｘｘｘの組織データ」
- 「組織データ」のプロパティ：title、uid、created、changedを使用する
- 「ｘｘｘの組織データ」のフィールド：「組織コード」、「正式組織名」をテキストフィールドで追加

Feedsの紹介

Feedsが三つの部分から構成される：Fetcher、Parser、Processor
- Fetcher：インポータデータの取得（例：File upload、external RSS Feedなど）
- Parser：インポートデータの解析方法の指定（csv、xls、xml、RSSなど）
- Processor：インポートデータの作成（Node、terms、usersなどのデータ作成）

FeedsにEntity Typeデータ変換プロセッサーに追加

PatchファイルをFeedsモジュールに当てる
Feedsのデータ変換プロセッサー設定画面にEntity Typeのデータ変換プロセッサー追加前後のイメージ

files

添付	サイズ
feeds_entity_processor-1033202-217.patch_.txt (16.03 KB)	16.03 KB

記事カテゴリ

タグ

エラー：モジュール(Twitter)をバージョンアップしてフロントページに開くと「EntityFieldQueryException」が発生

モジュール(Twitter)のバージョン：7.x-5.11 ⇒ 7.x-6.2 にアップデートしました（新モジュールから旧モジュールを上書き）

フロントページを開いてみたらエラーが発生し：

EntityFieldQueryException: エンティティー <em class="placeholder">twitter_account</em> にはベーステーブルがありません。 EntityFieldQuery->propertyQuery() (/virtual/drills/public_html/drupal7/includes/entity.inc ファイル　1271行).

画面にエラーしか表示されていないです

原因：Twitter7.x-5.11⇒7.x-6.2にアップデートする場合DBのテーブルが追加されたので、DB更新が必要

原因は比較的に単純的で、Twitter7.x-6.2（7.x-6.0以上になるとデータ構造が変わった）が7.x-5.11よりデータテーブルが追加されました
管理者権限でupdate.phpを実行してデータテーブルを追加します

シリーズ記事一覧

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ

やりたいこと：一つDrupalのソースで複数のサイト（複数のドメイン）を構築したいです

Drupalを用いて複数のサイト（ドメイン）を構築する場合、一つサイト（ドメイン）ごとに一つのDrupalソースで構築することがもちろん問題はありません
Drupalソースが分散すると、バージョンアップ、バグ管理などの作業が大変になります
当然一つのDrupalソースの元で複数のサイト（ドメイン）の構築が必要となります
- 一ドメイン ⇒ Drupalソース ⇒ 共有DB
- 一ドメイン ⇒ Drupalソース ⇒ 独立DB
Drupalでは複数のサイト（ドメイン）への対応をしています

sitesディレクトリの下にドメインごとの子ディレクトリを作成してマルティサイトを構築します

複数のドメイン名をDrupalのルートディレクトリに同期します（例：シンボリックリンクでドメイン名をディレクトリと同期します）
- 例： old-pine.net をDrupalのルートディレクトリにシンボリックリンクで同期します
Drupalのルートディレクトリの下に sites ディレクトリがあります。sitesの下に各メイン名に同期したいディレクトリを作成します
- 例：sites/pine を作成します
sites/sites.phpファイルでドメイン名をディレクトと同期設定を行います
- 例： 'old-pine.net' => 'pine' （書き方：ドメイン名 => ディレクトリ名）
```
 $sites = array(
    'old-pine.net' => 'pine',
 );
```
新規作成したディレクトの下にサイトのインストール設定ファイル(settings.php)の作成
- 例：sites/pine/settings.phpを作成します
- settings.phpの内容はsites/pine/default.settings.phpのコピーで良いです（サイト新規作成する場合）
追加したドメイン名でサイトをアクセスして、新規サイトができたことを確認します

記事カテゴリ

タグ

やりたいこと：レンタルサーバーで申請したドメイン名を特定なディレクトリに同期するシンボリックリンク作成したいです

レンタルサーバー（例：valueserver）で申請したドメイン名を特定なディレクトに同期するツールが提供されています
同期ツールを利用するのは便利だが、設定が誤ると同期先のディレクトリのファイルがすべて削除されてします危険があります
特に、この操作がよく行うことではなく、誤って設定する確率は実は高そうです（実際に設定を誤って、同期先のファイルが消されてしまう事項がありました）

安全のため、シンボリックリンク作成コマンドでディレクト同期をしたほうがよいです

シンボリックリンク作成：
- public_htmlディレクトリ（apacheではdocument root）に入ります
- コマンド： ln -s [ディレクト名] [ドメイン名] （例：ln -s drupal7 old-pine.net）
- コマンド： ls -l　で生成したシンボリックリンクを確認します（例： old-pine.net -> pine）
シンボリックリンクの削除
- コマンド：unlink [ドメイン名] (例：unlink old-pine.net)
- コマンド：ls -l でドメイン名の同期先が消えたことを確認します

安全のため、コマンド(rm)でシンボリックリンクを削除しないこと

シンボリックリンクを削除するのはコマンド(rm)できますが、誤って指定すると、同期先のディレクトリの内容を削除していまう危険があります
シンボリックリンクを削除するには、コマンド(unlink)を使用すべきです

記事カテゴリ

タグ

モジュール（Feature）が開発ソース管理、コンテンツデータ移行などに利用されます

最初モジュール（Feature）が何に使うかはあまりわからなかったです（いろいろな説明がちゅ抽象的）。
実はDrupalの開発ソース管理（例：開発環境ー＞ステージん環境ー＞本番環境）、コンテンツデータの移行に使用されます

データ移行例：コンテンツデータ（Article）＋Viewsで作成したコンテンツ検索一覧画面

データ移行の簡単な例として、既存のコンテンツデータ（例：Article⇒記事）、Viewsで作成したコンテンツ一覧画面を移行します
コンテンツデータ移行に必須なモジュール：
- Feature
- Node Export （FeatureモジュールにサポートするNode export featuresサブモジュールを有効化）
Feature管理画面で必要なモジュール、モジュールの関連、コンテンツデータを選択して、一つのモジュールとして作成し、ダウンロードします
作成されたモジュール（tarファイル）を移行先で通常のモジュールインストールをして、有効化を行います。Feature管理画面で移行元の内容を適用、保存します
具体的な操作はビデオをご参考ください

FeatureがDurupalのすべての設定、構成の移行はできません

移行はモジュール単位で、構成は出力可能なものを中心にしています。以下は移行可能な部分
- Core ： Content Types、 Fields、 Menus、 Taxonomies、 Text formats、 Image styles、 User roles 、 permissions
- Contribute： Views、 CTools、 Context 、 Panels、 Rules 、 Contexts、 Display Suite
移行できない部分は、例：テーマ、コンテンツに挿入した画像などがあります
- コンテンツに含まるメディア（例：写真、ビデオ、ファイルなど）がローカル（sites/default/files）に保存したため、移行先の保存パス修正、およびメディアファイルのコピーが手動で行う必要があります

video

記事カテゴリ

タグ

Drupalの部分的なコンテンツデータを別のDrualサイトに移行する場合そのコンテンツの構造定義とコンテンツCSVデータのエクスポート／インポートができます

背景：Drupal7.54
Drupalのサイト引っ越しなどでデータ移行の必要があります、以下の移行方法はよく利用されます。
- Drupalのモジュール（Feature）を用いてサイト間のデータ移行/開発管理を行います (162)
- 同じDrupalバージョンの単一サイトを複数サイト（ドメイン）の一つDrupalの共有ソースサイトへの移行チャレンジ (161)
ただし、部分的なコンテンツしか移行しない場合、上記方法では難しくなります
ここで、コンテンツ定義とデータを別々でexport/import方法を説明します

Drupalのモジュール（Bundle copy、 Taxonomy CSV import/export）でコンテンツの構成／定義をExport/Importします

モジュール（Bundle copy）でコンテンツの構成／定義を簡単に移行します（具体的にステップは省略）
タクソノミーのタームの構成（フィールドが追加など）が変わらなければ、モジュール（、Taxonomy CSV import/export）でタームリストデータをcsvファイルの出力することはできます
- 出力したCSVデータの別のサイトにインポートする場合、タクソノミーのボキャブラリーとタームIDが変わった可能性があります
- コンテンツのフィールドに「Term Reference」タイプのものがあれば、コンテンツ追加／編集ボタンをクリックすると、「HTTP ERROR 500」エラーが発生するかもしれないです
- 一番簡単な対応方法ではそのフィールドを一回削除して、再作成すればよいです（データインポートする前の段階）

Drupalのコンテンツ構成（フィールド）テーブルのデータをcsvフォーマットに出力します

現時点ではコンテンツのデータをcsvに出力するモジュールはあまり見当たらにです
コンテンツのフィールドをDB上各テーブルを見つけ出します
- コンテンツ（例：Article）のフィールドごとに一つのテールが存在しています
- Title ➡　nodeテーブルの「title」フィールド
- body ➡　field_data_bodyテーブルの「body_value」フィールド（またはbody_summaryなど）
- カスタムフィールド ➡　field_data_CUSTOM_FIELD_NAMEの「field_data_CUSTOM_FIELD_NAME_value」フィールド
これらのテーブルを「node」テーブルを中心してジョインして、新しいテーブルの書き込みます
- すべてのコンテンツは「node」テーブルを基本にしています
- 各フィールドのテーブルに「entity_id」がnodeテーブルの「nid」の関連付けキーとなります
- 全フィールドと同じフィールドの新しいテーブルを一つ作成します（例：new_table）
- 全フィールドをJOINしてデータを新しいテーブル（例：new_table）にコピーします
```
INSERT INTO new_table (title, body, CUSTOM_FIELD_NAME,   ・・・・・・)
SELECT 
   title,
   body.body_value,
   T1.field_data_CUSTOM_FIEDL_NAME_value,
  ・・・・・・
FROM node
   left join field_data_body body on nid = body.entity_id
   left join field_data_CUSTOM_FIELD_NAME  T1  on T1.entity_id = nid
  ・・・・・・
  
```
新しいテーブル（new_table）の内容をｃｓｖフォーマットに出力します

Drupalのモジュール（Feeds Import）でコンテンツｃｓｖデータをインポートします

モジュール（Feeds Import）がよく利用されるものなので、簡単にｃｓｖデータを確認コンテンツにインポートすることができます
Feeds Importの説明は省略します(Drupalのモジュール（Feeds）で手動でデータインポート時の必須設定 (199)、FeedsモジュールでEnityにデータインポート (34)などを参考にしてください)

シリーズ記事一覧

記事カテゴリ

タグ

モジュール（Feature）が開発ソース管理、コンテンツデータ移行などに利用されます

最初モジュール（Feature）が何に使うかはあまりわからなかったです（いろいろな説明がちゅ抽象的）。
実はDrupalの開発ソース管理（例：開発環境ー＞ステージん環境ー＞本番環境）、コンテンツデータの移行に使用されます

データ移行例：コンテンツデータ（Article）＋Viewsで作成したコンテンツ検索一覧画面

データ移行の簡単な例として、既存のコンテンツデータ（例：Article⇒記事）、Viewsで作成したコンテンツ一覧画面を移行します
コンテンツデータ移行に必須なモジュール：
- Feature
- Node Export （FeatureモジュールにサポートするNode export featuresサブモジュールを有効化）
Feature管理画面で必要なモジュール、モジュールの関連、コンテンツデータを選択して、一つのモジュールとして作成し、ダウンロードします
作成されたモジュール（tarファイル）を移行先で通常のモジュールインストールをして、有効化を行います。Feature管理画面で移行元の内容を適用、保存します
具体的な操作はビデオをご参考ください

FeatureがDurupalのすべての設定、構成の移行はできません

移行はモジュール単位で、構成は出力可能なものを中心にしています。以下は移行可能な部分
- Core ： Content Types、 Fields、 Menus、 Taxonomies、 Text formats、 Image styles、 User roles 、 permissions
- Contribute： Views、 CTools、 Context 、 Panels、 Rules 、 Contexts、 Display Suite
移行できない部分は、例：テーマ、コンテンツに挿入した画像などがあります
- コンテンツに含まるメディア（例：写真、ビデオ、ファイルなど）がローカル（sites/default/files）に保存したため、移行先の保存パス修正、およびメディアファイルのコピーが手動で行う必要があります

video

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ

注意点：Drupalのモジュール（Feeds）の設定が間違うと手動でデータインポートができなくなります

環境：Drupal7.54、Feeds7.x-3.0
やりたいこと：手動でデータをインポート（例：csvファイルからのインポートなど）
Feedの基本設定のところある二か所をチェックしないと手動でのインポートができない
- 添付するコンテンツタイプ：スタントアローンのフォームを使う
- 投稿時にインポート
- 初期としてはこの二つ設定を有効にしています
ちなみに、「投稿時にインポート」を無効の場合、バッチでデータインポートすることになります（バッチの設定が必要）
添付するコンテンツタイプ：「スタントアローンのフォームを使う」以外の選択肢を選択すると、インポート画面（ホーム » インポート）に当該インポーターはありません

手動でインポートできないときに画面上に「インポートされた項目はありません」が表示されます

「投稿時にインポート」オプションが無効の場合、手動でデータインポートはできません
インポートデータがあるにはかかわらず、画面上に「インポートされた項目はありません」として表示されます
バッチにインポートジョブを入れたメッセージはありません

記事カテゴリ

タグ

目的

Entity Typeデータにほかのデータ（例：ｃｓｖ、xmlなど）からのインポートを可能にする
Feedsの初期データ変換プロセッサーに「Entity Type」のものがなかった

解決の選択肢

Feed Importモジュールでのデータインポート
Feedsモジュールのカスタマイズをする

ここでの解決：Feedsのカスタマイズ

インストールされたモジュール
- Feeds : 7.x-2.0
- ECK : 7.x-2.0
- Entity API : 7.x-1.5
上記モジュールのインストールと有効化
ECKでインポートデータタイプとBundleを作成する
- 例：　データタイプ：「組織データ」、Bundle：「ｘｘｘの組織データ」
- 「組織データ」のプロパティ：title、uid、created、changedを使用する
- 「ｘｘｘの組織データ」のフィールド：「組織コード」、「正式組織名」をテキストフィールドで追加

Feedsの紹介

Feedsが三つの部分から構成される：Fetcher、Parser、Processor
- Fetcher：インポータデータの取得（例：File upload、external RSS Feedなど）
- Parser：インポートデータの解析方法の指定（csv、xls、xml、RSSなど）
- Processor：インポートデータの作成（Node、terms、usersなどのデータ作成）

FeedsにEntity Typeデータ変換プロセッサーに追加

PatchファイルをFeedsモジュールに当てる
Feedsのデータ変換プロセッサー設定画面にEntity Typeのデータ変換プロセッサー追加前後のイメージ

files

添付	サイズ
feeds_entity_processor-1033202-217.patch_.txt (16.03 KB)	16.03 KB

記事カテゴリ

タグ

エラー：モジュール(Twitter)をバージョンアップしてフロントページに開くと「EntityFieldQueryException」が発生

モジュール(Twitter)のバージョン：7.x-5.11 ⇒ 7.x-6.2 にアップデートしました（新モジュールから旧モジュールを上書き）

フロントページを開いてみたらエラーが発生し：

EntityFieldQueryException: エンティティー <em class="placeholder">twitter_account</em> にはベーステーブルがありません。 EntityFieldQuery->propertyQuery() (/virtual/drills/public_html/drupal7/includes/entity.inc ファイル　1271行).

画面にエラーしか表示されていないです

原因：Twitter7.x-5.11⇒7.x-6.2にアップデートする場合DBのテーブルが追加されたので、DB更新が必要

原因は比較的に単純的で、Twitter7.x-6.2（7.x-6.0以上になるとデータ構造が変わった）が7.x-5.11よりデータテーブルが追加されました
管理者権限でupdate.phpを実行してデータテーブルを追加します

シリーズ記事一覧

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ

やりたいこと：一つDrupalのソースで複数のサイト（複数のドメイン）を構築したいです

Drupalを用いて複数のサイト（ドメイン）を構築する場合、一つサイト（ドメイン）ごとに一つのDrupalソースで構築することがもちろん問題はありません
Drupalソースが分散すると、バージョンアップ、バグ管理などの作業が大変になります
当然一つのDrupalソースの元で複数のサイト（ドメイン）の構築が必要となります
- 一ドメイン ⇒ Drupalソース ⇒ 共有DB
- 一ドメイン ⇒ Drupalソース ⇒ 独立DB
Drupalでは複数のサイト（ドメイン）への対応をしています

sitesディレクトリの下にドメインごとの子ディレクトリを作成してマルティサイトを構築します

複数のドメイン名をDrupalのルートディレクトリに同期します（例：シンボリックリンクでドメイン名をディレクトリと同期します）
- 例： old-pine.net をDrupalのルートディレクトリにシンボリックリンクで同期します
Drupalのルートディレクトリの下に sites ディレクトリがあります。sitesの下に各メイン名に同期したいディレクトリを作成します
- 例：sites/pine を作成します
sites/sites.phpファイルでドメイン名をディレクトと同期設定を行います
- 例： 'old-pine.net' => 'pine' （書き方：ドメイン名 => ディレクトリ名）
```
 $sites = array(
    'old-pine.net' => 'pine',
 );
```
新規作成したディレクトの下にサイトのインストール設定ファイル(settings.php)の作成
- 例：sites/pine/settings.phpを作成します
- settings.phpの内容はsites/pine/default.settings.phpのコピーで良いです（サイト新規作成する場合）
追加したドメイン名でサイトをアクセスして、新規サイトができたことを確認します

記事カテゴリ

タグ

やりたいこと：レンタルサーバーで申請したドメイン名を特定なディレクトリに同期するシンボリックリンク作成したいです

レンタルサーバー（例：valueserver）で申請したドメイン名を特定なディレクトに同期するツールが提供されています
同期ツールを利用するのは便利だが、設定が誤ると同期先のディレクトリのファイルがすべて削除されてします危険があります
特に、この操作がよく行うことではなく、誤って設定する確率は実は高そうです（実際に設定を誤って、同期先のファイルが消されてしまう事項がありました）

安全のため、シンボリックリンク作成コマンドでディレクト同期をしたほうがよいです

シンボリックリンク作成：
- public_htmlディレクトリ（apacheではdocument root）に入ります
- コマンド： ln -s [ディレクト名] [ドメイン名] （例：ln -s drupal7 old-pine.net）
- コマンド： ls -l　で生成したシンボリックリンクを確認します（例： old-pine.net -> pine）
シンボリックリンクの削除
- コマンド：unlink [ドメイン名] (例：unlink old-pine.net)
- コマンド：ls -l でドメイン名の同期先が消えたことを確認します

安全のため、コマンド(rm)でシンボリックリンクを削除しないこと

シンボリックリンクを削除するのはコマンド(rm)できますが、誤って指定すると、同期先のディレクトリの内容を削除していまう危険があります
シンボリックリンクを削除するには、コマンド(unlink)を使用すべきです

記事カテゴリ

タグ

モジュール（Feature）が開発ソース管理、コンテンツデータ移行などに利用されます

最初モジュール（Feature）が何に使うかはあまりわからなかったです（いろいろな説明がちゅ抽象的）。
実はDrupalの開発ソース管理（例：開発環境ー＞ステージん環境ー＞本番環境）、コンテンツデータの移行に使用されます

データ移行例：コンテンツデータ（Article）＋Viewsで作成したコンテンツ検索一覧画面

データ移行の簡単な例として、既存のコンテンツデータ（例：Article⇒記事）、Viewsで作成したコンテンツ一覧画面を移行します
コンテンツデータ移行に必須なモジュール：
- Feature
- Node Export （FeatureモジュールにサポートするNode export featuresサブモジュールを有効化）
Feature管理画面で必要なモジュール、モジュールの関連、コンテンツデータを選択して、一つのモジュールとして作成し、ダウンロードします
作成されたモジュール（tarファイル）を移行先で通常のモジュールインストールをして、有効化を行います。Feature管理画面で移行元の内容を適用、保存します
具体的な操作はビデオをご参考ください

FeatureがDurupalのすべての設定、構成の移行はできません

移行はモジュール単位で、構成は出力可能なものを中心にしています。以下は移行可能な部分
- Core ： Content Types、 Fields、 Menus、 Taxonomies、 Text formats、 Image styles、 User roles 、 permissions
- Contribute： Views、 CTools、 Context 、 Panels、 Rules 、 Contexts、 Display Suite
移行できない部分は、例：テーマ、コンテンツに挿入した画像などがあります
- コンテンツに含まるメディア（例：写真、ビデオ、ファイルなど）がローカル（sites/default/files）に保存したため、移行先の保存パス修正、およびメディアファイルのコピーが手動で行う必要があります

video

記事カテゴリ

タグ

Drupalの部分的なコンテンツデータを別のDrualサイトに移行する場合そのコンテンツの構造定義とコンテンツCSVデータのエクスポート／インポートができます

背景：Drupal7.54
Drupalのサイト引っ越しなどでデータ移行の必要があります、以下の移行方法はよく利用されます。
- Drupalのモジュール（Feature）を用いてサイト間のデータ移行/開発管理を行います (162)
- 同じDrupalバージョンの単一サイトを複数サイト（ドメイン）の一つDrupalの共有ソースサイトへの移行チャレンジ (161)
ただし、部分的なコンテンツしか移行しない場合、上記方法では難しくなります
ここで、コンテンツ定義とデータを別々でexport/import方法を説明します

Drupalのモジュール（Bundle copy、 Taxonomy CSV import/export）でコンテンツの構成／定義をExport/Importします

モジュール（Bundle copy）でコンテンツの構成／定義を簡単に移行します（具体的にステップは省略）
タクソノミーのタームの構成（フィールドが追加など）が変わらなければ、モジュール（、Taxonomy CSV import/export）でタームリストデータをcsvファイルの出力することはできます
- 出力したCSVデータの別のサイトにインポートする場合、タクソノミーのボキャブラリーとタームIDが変わった可能性があります
- コンテンツのフィールドに「Term Reference」タイプのものがあれば、コンテンツ追加／編集ボタンをクリックすると、「HTTP ERROR 500」エラーが発生するかもしれないです
- 一番簡単な対応方法ではそのフィールドを一回削除して、再作成すればよいです（データインポートする前の段階）

Drupalのコンテンツ構成（フィールド）テーブルのデータをcsvフォーマットに出力します

現時点ではコンテンツのデータをcsvに出力するモジュールはあまり見当たらにです
コンテンツのフィールドをDB上各テーブルを見つけ出します
- コンテンツ（例：Article）のフィールドごとに一つのテールが存在しています
- Title ➡　nodeテーブルの「title」フィールド
- body ➡　field_data_bodyテーブルの「body_value」フィールド（またはbody_summaryなど）
- カスタムフィールド ➡　field_data_CUSTOM_FIELD_NAMEの「field_data_CUSTOM_FIELD_NAME_value」フィールド
これらのテーブルを「node」テーブルを中心してジョインして、新しいテーブルの書き込みます
- すべてのコンテンツは「node」テーブルを基本にしています
- 各フィールドのテーブルに「entity_id」がnodeテーブルの「nid」の関連付けキーとなります
- 全フィールドと同じフィールドの新しいテーブルを一つ作成します（例：new_table）
- 全フィールドをJOINしてデータを新しいテーブル（例：new_table）にコピーします
```
INSERT INTO new_table (title, body, CUSTOM_FIELD_NAME,   ・・・・・・)
SELECT 
   title,
   body.body_value,
   T1.field_data_CUSTOM_FIEDL_NAME_value,
  ・・・・・・
FROM node
   left join field_data_body body on nid = body.entity_id
   left join field_data_CUSTOM_FIELD_NAME  T1  on T1.entity_id = nid
  ・・・・・・
  
```
新しいテーブル（new_table）の内容をｃｓｖフォーマットに出力します

Drupalのモジュール（Feeds Import）でコンテンツｃｓｖデータをインポートします

モジュール（Feeds Import）がよく利用されるものなので、簡単にｃｓｖデータを確認コンテンツにインポートすることができます
Feeds Importの説明は省略します(Drupalのモジュール（Feeds）で手動でデータインポート時の必須設定 (199)、FeedsモジュールでEnityにデータインポート (34)などを参考にしてください)

シリーズ記事一覧

記事カテゴリ

タグ

モジュール（Feature）が開発ソース管理、コンテンツデータ移行などに利用されます

最初モジュール（Feature）が何に使うかはあまりわからなかったです（いろいろな説明がちゅ抽象的）。
実はDrupalの開発ソース管理（例：開発環境ー＞ステージん環境ー＞本番環境）、コンテンツデータの移行に使用されます

データ移行例：コンテンツデータ（Article）＋Viewsで作成したコンテンツ検索一覧画面

データ移行の簡単な例として、既存のコンテンツデータ（例：Article⇒記事）、Viewsで作成したコンテンツ一覧画面を移行します
コンテンツデータ移行に必須なモジュール：
- Feature
- Node Export （FeatureモジュールにサポートするNode export featuresサブモジュールを有効化）
Feature管理画面で必要なモジュール、モジュールの関連、コンテンツデータを選択して、一つのモジュールとして作成し、ダウンロードします
作成されたモジュール（tarファイル）を移行先で通常のモジュールインストールをして、有効化を行います。Feature管理画面で移行元の内容を適用、保存します
具体的な操作はビデオをご参考ください

FeatureがDurupalのすべての設定、構成の移行はできません

移行はモジュール単位で、構成は出力可能なものを中心にしています。以下は移行可能な部分
- Core ： Content Types、 Fields、 Menus、 Taxonomies、 Text formats、 Image styles、 User roles 、 permissions
- Contribute： Views、 CTools、 Context 、 Panels、 Rules 、 Contexts、 Display Suite
移行できない部分は、例：テーマ、コンテンツに挿入した画像などがあります
- コンテンツに含まるメディア（例：写真、ビデオ、ファイルなど）がローカル（sites/default/files）に保存したため、移行先の保存パス修正、およびメディアファイルのコピーが手動で行う必要があります

video

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ

注意点：Drupalのモジュール（Feeds）の設定が間違うと手動でデータインポートができなくなります

環境：Drupal7.54、Feeds7.x-3.0
やりたいこと：手動でデータをインポート（例：csvファイルからのインポートなど）
Feedの基本設定のところある二か所をチェックしないと手動でのインポートができない
- 添付するコンテンツタイプ：スタントアローンのフォームを使う
- 投稿時にインポート
- 初期としてはこの二つ設定を有効にしています
ちなみに、「投稿時にインポート」を無効の場合、バッチでデータインポートすることになります（バッチの設定が必要）
添付するコンテンツタイプ：「スタントアローンのフォームを使う」以外の選択肢を選択すると、インポート画面（ホーム » インポート）に当該インポーターはありません

手動でインポートできないときに画面上に「インポートされた項目はありません」が表示されます

「投稿時にインポート」オプションが無効の場合、手動でデータインポートはできません
インポートデータがあるにはかかわらず、画面上に「インポートされた項目はありません」として表示されます
バッチにインポートジョブを入れたメッセージはありません

記事カテゴリ

タグ

目的

Entity Typeデータにほかのデータ（例：ｃｓｖ、xmlなど）からのインポートを可能にする
Feedsの初期データ変換プロセッサーに「Entity Type」のものがなかった

解決の選択肢

Feed Importモジュールでのデータインポート
Feedsモジュールのカスタマイズをする

ここでの解決：Feedsのカスタマイズ

インストールされたモジュール
- Feeds : 7.x-2.0
- ECK : 7.x-2.0
- Entity API : 7.x-1.5
上記モジュールのインストールと有効化
ECKでインポートデータタイプとBundleを作成する
- 例：　データタイプ：「組織データ」、Bundle：「ｘｘｘの組織データ」
- 「組織データ」のプロパティ：title、uid、created、changedを使用する
- 「ｘｘｘの組織データ」のフィールド：「組織コード」、「正式組織名」をテキストフィールドで追加

Feedsの紹介

Feedsが三つの部分から構成される：Fetcher、Parser、Processor
- Fetcher：インポータデータの取得（例：File upload、external RSS Feedなど）
- Parser：インポートデータの解析方法の指定（csv、xls、xml、RSSなど）
- Processor：インポートデータの作成（Node、terms、usersなどのデータ作成）

FeedsにEntity Typeデータ変換プロセッサーに追加

PatchファイルをFeedsモジュールに当てる
Feedsのデータ変換プロセッサー設定画面にEntity Typeのデータ変換プロセッサー追加前後のイメージ

files

添付	サイズ
feeds_entity_processor-1033202-217.patch_.txt (16.03 KB)	16.03 KB

記事カテゴリ

タグ

エラー：モジュール(Twitter)をバージョンアップしてフロントページに開くと「EntityFieldQueryException」が発生

モジュール(Twitter)のバージョン：7.x-5.11 ⇒ 7.x-6.2 にアップデートしました（新モジュールから旧モジュールを上書き）

フロントページを開いてみたらエラーが発生し：

EntityFieldQueryException: エンティティー <em class="placeholder">twitter_account</em> にはベーステーブルがありません。 EntityFieldQuery->propertyQuery() (/virtual/drills/public_html/drupal7/includes/entity.inc ファイル　1271行).

画面にエラーしか表示されていないです

原因：Twitter7.x-5.11⇒7.x-6.2にアップデートする場合DBのテーブルが追加されたので、DB更新が必要

原因は比較的に単純的で、Twitter7.x-6.2（7.x-6.0以上になるとデータ構造が変わった）が7.x-5.11よりデータテーブルが追加されました
管理者権限でupdate.phpを実行してデータテーブルを追加します

シリーズ記事一覧

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ

やりたいこと：一つDrupalのソースで複数のサイト（複数のドメイン）を構築したいです

Drupalを用いて複数のサイト（ドメイン）を構築する場合、一つサイト（ドメイン）ごとに一つのDrupalソースで構築することがもちろん問題はありません
Drupalソースが分散すると、バージョンアップ、バグ管理などの作業が大変になります
当然一つのDrupalソースの元で複数のサイト（ドメイン）の構築が必要となります
- 一ドメイン ⇒ Drupalソース ⇒ 共有DB
- 一ドメイン ⇒ Drupalソース ⇒ 独立DB
Drupalでは複数のサイト（ドメイン）への対応をしています

sitesディレクトリの下にドメインごとの子ディレクトリを作成してマルティサイトを構築します

複数のドメイン名をDrupalのルートディレクトリに同期します（例：シンボリックリンクでドメイン名をディレクトリと同期します）
- 例： old-pine.net をDrupalのルートディレクトリにシンボリックリンクで同期します
Drupalのルートディレクトリの下に sites ディレクトリがあります。sitesの下に各メイン名に同期したいディレクトリを作成します
- 例：sites/pine を作成します
sites/sites.phpファイルでドメイン名をディレクトと同期設定を行います
- 例： 'old-pine.net' => 'pine' （書き方：ドメイン名 => ディレクトリ名）
```
 $sites = array(
    'old-pine.net' => 'pine',
 );
```
新規作成したディレクトの下にサイトのインストール設定ファイル(settings.php)の作成
- 例：sites/pine/settings.phpを作成します
- settings.phpの内容はsites/pine/default.settings.phpのコピーで良いです（サイト新規作成する場合）
追加したドメイン名でサイトをアクセスして、新規サイトができたことを確認します

記事カテゴリ

タグ

やりたいこと：レンタルサーバーで申請したドメイン名を特定なディレクトリに同期するシンボリックリンク作成したいです

レンタルサーバー（例：valueserver）で申請したドメイン名を特定なディレクトに同期するツールが提供されています
同期ツールを利用するのは便利だが、設定が誤ると同期先のディレクトリのファイルがすべて削除されてします危険があります
特に、この操作がよく行うことではなく、誤って設定する確率は実は高そうです（実際に設定を誤って、同期先のファイルが消されてしまう事項がありました）

安全のため、シンボリックリンク作成コマンドでディレクト同期をしたほうがよいです

シンボリックリンク作成：
- public_htmlディレクトリ（apacheではdocument root）に入ります
- コマンド： ln -s [ディレクト名] [ドメイン名] （例：ln -s drupal7 old-pine.net）
- コマンド： ls -l　で生成したシンボリックリンクを確認します（例： old-pine.net -> pine）
シンボリックリンクの削除
- コマンド：unlink [ドメイン名] (例：unlink old-pine.net)
- コマンド：ls -l でドメイン名の同期先が消えたことを確認します

安全のため、コマンド(rm)でシンボリックリンクを削除しないこと

シンボリックリンクを削除するのはコマンド(rm)できますが、誤って指定すると、同期先のディレクトリの内容を削除していまう危険があります
シンボリックリンクを削除するには、コマンド(unlink)を使用すべきです

記事カテゴリ

タグ

モジュール（Feature）が開発ソース管理、コンテンツデータ移行などに利用されます

最初モジュール（Feature）が何に使うかはあまりわからなかったです（いろいろな説明がちゅ抽象的）。
実はDrupalの開発ソース管理（例：開発環境ー＞ステージん環境ー＞本番環境）、コンテンツデータの移行に使用されます

データ移行例：コンテンツデータ（Article）＋Viewsで作成したコンテンツ検索一覧画面

データ移行の簡単な例として、既存のコンテンツデータ（例：Article⇒記事）、Viewsで作成したコンテンツ一覧画面を移行します
コンテンツデータ移行に必須なモジュール：
- Feature
- Node Export （FeatureモジュールにサポートするNode export featuresサブモジュールを有効化）
Feature管理画面で必要なモジュール、モジュールの関連、コンテンツデータを選択して、一つのモジュールとして作成し、ダウンロードします
作成されたモジュール（tarファイル）を移行先で通常のモジュールインストールをして、有効化を行います。Feature管理画面で移行元の内容を適用、保存します
具体的な操作はビデオをご参考ください

FeatureがDurupalのすべての設定、構成の移行はできません

移行はモジュール単位で、構成は出力可能なものを中心にしています。以下は移行可能な部分
- Core ： Content Types、 Fields、 Menus、 Taxonomies、 Text formats、 Image styles、 User roles 、 permissions
- Contribute： Views、 CTools、 Context 、 Panels、 Rules 、 Contexts、 Display Suite
移行できない部分は、例：テーマ、コンテンツに挿入した画像などがあります
- コンテンツに含まるメディア（例：写真、ビデオ、ファイルなど）がローカル（sites/default/files）に保存したため、移行先の保存パス修正、およびメディアファイルのコピーが手動で行う必要があります

video

記事カテゴリ

タグ

Drupalの部分的なコンテンツデータを別のDrualサイトに移行する場合そのコンテンツの構造定義とコンテンツCSVデータのエクスポート／インポートができます

背景：Drupal7.54
Drupalのサイト引っ越しなどでデータ移行の必要があります、以下の移行方法はよく利用されます。
- Drupalのモジュール（Feature）を用いてサイト間のデータ移行/開発管理を行います (162)
- 同じDrupalバージョンの単一サイトを複数サイト（ドメイン）の一つDrupalの共有ソースサイトへの移行チャレンジ (161)
ただし、部分的なコンテンツしか移行しない場合、上記方法では難しくなります
ここで、コンテンツ定義とデータを別々でexport/import方法を説明します

Drupalのモジュール（Bundle copy、 Taxonomy CSV import/export）でコンテンツの構成／定義をExport/Importします

モジュール（Bundle copy）でコンテンツの構成／定義を簡単に移行します（具体的にステップは省略）
タクソノミーのタームの構成（フィールドが追加など）が変わらなければ、モジュール（、Taxonomy CSV import/export）でタームリストデータをcsvファイルの出力することはできます
- 出力したCSVデータの別のサイトにインポートする場合、タクソノミーのボキャブラリーとタームIDが変わった可能性があります
- コンテンツのフィールドに「Term Reference」タイプのものがあれば、コンテンツ追加／編集ボタンをクリックすると、「HTTP ERROR 500」エラーが発生するかもしれないです
- 一番簡単な対応方法ではそのフィールドを一回削除して、再作成すればよいです（データインポートする前の段階）

Drupalのコンテンツ構成（フィールド）テーブルのデータをcsvフォーマットに出力します

現時点ではコンテンツのデータをcsvに出力するモジュールはあまり見当たらにです
コンテンツのフィールドをDB上各テーブルを見つけ出します
- コンテンツ（例：Article）のフィールドごとに一つのテールが存在しています
- Title ➡　nodeテーブルの「title」フィールド
- body ➡　field_data_bodyテーブルの「body_value」フィールド（またはbody_summaryなど）
- カスタムフィールド ➡　field_data_CUSTOM_FIELD_NAMEの「field_data_CUSTOM_FIELD_NAME_value」フィールド
これらのテーブルを「node」テーブルを中心してジョインして、新しいテーブルの書き込みます
- すべてのコンテンツは「node」テーブルを基本にしています
- 各フィールドのテーブルに「entity_id」がnodeテーブルの「nid」の関連付けキーとなります
- 全フィールドと同じフィールドの新しいテーブルを一つ作成します（例：new_table）
- 全フィールドをJOINしてデータを新しいテーブル（例：new_table）にコピーします
```
INSERT INTO new_table (title, body, CUSTOM_FIELD_NAME,   ・・・・・・)
SELECT 
   title,
   body.body_value,
   T1.field_data_CUSTOM_FIEDL_NAME_value,
  ・・・・・・
FROM node
   left join field_data_body body on nid = body.entity_id
   left join field_data_CUSTOM_FIELD_NAME  T1  on T1.entity_id = nid
  ・・・・・・
  
```
新しいテーブル（new_table）の内容をｃｓｖフォーマットに出力します

Drupalのモジュール（Feeds Import）でコンテンツｃｓｖデータをインポートします

モジュール（Feeds Import）がよく利用されるものなので、簡単にｃｓｖデータを確認コンテンツにインポートすることができます
Feeds Importの説明は省略します(Drupalのモジュール（Feeds）で手動でデータインポート時の必須設定 (199)、FeedsモジュールでEnityにデータインポート (34)などを参考にしてください)

シリーズ記事一覧

記事カテゴリ

タグ

モジュール（Feature）が開発ソース管理、コンテンツデータ移行などに利用されます

最初モジュール（Feature）が何に使うかはあまりわからなかったです（いろいろな説明がちゅ抽象的）。
実はDrupalの開発ソース管理（例：開発環境ー＞ステージん環境ー＞本番環境）、コンテンツデータの移行に使用されます

データ移行例：コンテンツデータ（Article）＋Viewsで作成したコンテンツ検索一覧画面

データ移行の簡単な例として、既存のコンテンツデータ（例：Article⇒記事）、Viewsで作成したコンテンツ一覧画面を移行します
コンテンツデータ移行に必須なモジュール：
- Feature
- Node Export （FeatureモジュールにサポートするNode export featuresサブモジュールを有効化）
Feature管理画面で必要なモジュール、モジュールの関連、コンテンツデータを選択して、一つのモジュールとして作成し、ダウンロードします
作成されたモジュール（tarファイル）を移行先で通常のモジュールインストールをして、有効化を行います。Feature管理画面で移行元の内容を適用、保存します
具体的な操作はビデオをご参考ください

FeatureがDurupalのすべての設定、構成の移行はできません

移行はモジュール単位で、構成は出力可能なものを中心にしています。以下は移行可能な部分
- Core ： Content Types、 Fields、 Menus、 Taxonomies、 Text formats、 Image styles、 User roles 、 permissions
- Contribute： Views、 CTools、 Context 、 Panels、 Rules 、 Contexts、 Display Suite
移行できない部分は、例：テーマ、コンテンツに挿入した画像などがあります
- コンテンツに含まるメディア（例：写真、ビデオ、ファイルなど）がローカル（sites/default/files）に保存したため、移行先の保存パス修正、およびメディアファイルのコピーが手動で行う必要があります

video

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ

注意点：Drupalのモジュール（Feeds）の設定が間違うと手動でデータインポートができなくなります

環境：Drupal7.54、Feeds7.x-3.0
やりたいこと：手動でデータをインポート（例：csvファイルからのインポートなど）
Feedの基本設定のところある二か所をチェックしないと手動でのインポートができない
- 添付するコンテンツタイプ：スタントアローンのフォームを使う
- 投稿時にインポート
- 初期としてはこの二つ設定を有効にしています
ちなみに、「投稿時にインポート」を無効の場合、バッチでデータインポートすることになります（バッチの設定が必要）
添付するコンテンツタイプ：「スタントアローンのフォームを使う」以外の選択肢を選択すると、インポート画面（ホーム » インポート）に当該インポーターはありません

手動でインポートできないときに画面上に「インポートされた項目はありません」が表示されます

「投稿時にインポート」オプションが無効の場合、手動でデータインポートはできません
インポートデータがあるにはかかわらず、画面上に「インポートされた項目はありません」として表示されます
バッチにインポートジョブを入れたメッセージはありません

記事カテゴリ

タグ

目的

Entity Typeデータにほかのデータ（例：ｃｓｖ、xmlなど）からのインポートを可能にする
Feedsの初期データ変換プロセッサーに「Entity Type」のものがなかった

解決の選択肢

Feed Importモジュールでのデータインポート
Feedsモジュールのカスタマイズをする

ここでの解決：Feedsのカスタマイズ

インストールされたモジュール
- Feeds : 7.x-2.0
- ECK : 7.x-2.0
- Entity API : 7.x-1.5
上記モジュールのインストールと有効化
ECKでインポートデータタイプとBundleを作成する
- 例：　データタイプ：「組織データ」、Bundle：「ｘｘｘの組織データ」
- 「組織データ」のプロパティ：title、uid、created、changedを使用する
- 「ｘｘｘの組織データ」のフィールド：「組織コード」、「正式組織名」をテキストフィールドで追加

Feedsの紹介

Feedsが三つの部分から構成される：Fetcher、Parser、Processor
- Fetcher：インポータデータの取得（例：File upload、external RSS Feedなど）
- Parser：インポートデータの解析方法の指定（csv、xls、xml、RSSなど）
- Processor：インポートデータの作成（Node、terms、usersなどのデータ作成）

FeedsにEntity Typeデータ変換プロセッサーに追加

PatchファイルをFeedsモジュールに当てる
Feedsのデータ変換プロセッサー設定画面にEntity Typeのデータ変換プロセッサー追加前後のイメージ

files

添付	サイズ
feeds_entity_processor-1033202-217.patch_.txt (16.03 KB)	16.03 KB

記事カテゴリ

タグ

エラー：モジュール(Twitter)をバージョンアップしてフロントページに開くと「EntityFieldQueryException」が発生

モジュール(Twitter)のバージョン：7.x-5.11 ⇒ 7.x-6.2 にアップデートしました（新モジュールから旧モジュールを上書き）

フロントページを開いてみたらエラーが発生し：

EntityFieldQueryException: エンティティー <em class="placeholder">twitter_account</em> にはベーステーブルがありません。 EntityFieldQuery->propertyQuery() (/virtual/drills/public_html/drupal7/includes/entity.inc ファイル　1271行).

画面にエラーしか表示されていないです

原因：Twitter7.x-5.11⇒7.x-6.2にアップデートする場合DBのテーブルが追加されたので、DB更新が必要

原因は比較的に単純的で、Twitter7.x-6.2（7.x-6.0以上になるとデータ構造が変わった）が7.x-5.11よりデータテーブルが追加されました
管理者権限でupdate.phpを実行してデータテーブルを追加します

シリーズ記事一覧

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ

やりたいこと：一つDrupalのソースで複数のサイト（複数のドメイン）を構築したいです

Drupalを用いて複数のサイト（ドメイン）を構築する場合、一つサイト（ドメイン）ごとに一つのDrupalソースで構築することがもちろん問題はありません
Drupalソースが分散すると、バージョンアップ、バグ管理などの作業が大変になります
当然一つのDrupalソースの元で複数のサイト（ドメイン）の構築が必要となります
- 一ドメイン ⇒ Drupalソース ⇒ 共有DB
- 一ドメイン ⇒ Drupalソース ⇒ 独立DB
Drupalでは複数のサイト（ドメイン）への対応をしています

sitesディレクトリの下にドメインごとの子ディレクトリを作成してマルティサイトを構築します

複数のドメイン名をDrupalのルートディレクトリに同期します（例：シンボリックリンクでドメイン名をディレクトリと同期します）
- 例： old-pine.net をDrupalのルートディレクトリにシンボリックリンクで同期します
Drupalのルートディレクトリの下に sites ディレクトリがあります。sitesの下に各メイン名に同期したいディレクトリを作成します
- 例：sites/pine を作成します
sites/sites.phpファイルでドメイン名をディレクトと同期設定を行います
- 例： 'old-pine.net' => 'pine' （書き方：ドメイン名 => ディレクトリ名）
```
 $sites = array(
    'old-pine.net' => 'pine',
 );
```
新規作成したディレクトの下にサイトのインストール設定ファイル(settings.php)の作成
- 例：sites/pine/settings.phpを作成します
- settings.phpの内容はsites/pine/default.settings.phpのコピーで良いです（サイト新規作成する場合）
追加したドメイン名でサイトをアクセスして、新規サイトができたことを確認します

記事カテゴリ

タグ

やりたいこと：レンタルサーバーで申請したドメイン名を特定なディレクトリに同期するシンボリックリンク作成したいです

レンタルサーバー（例：valueserver）で申請したドメイン名を特定なディレクトに同期するツールが提供されています
同期ツールを利用するのは便利だが、設定が誤ると同期先のディレクトリのファイルがすべて削除されてします危険があります
特に、この操作がよく行うことではなく、誤って設定する確率は実は高そうです（実際に設定を誤って、同期先のファイルが消されてしまう事項がありました）

安全のため、シンボリックリンク作成コマンドでディレクト同期をしたほうがよいです

シンボリックリンク作成：
- public_htmlディレクトリ（apacheではdocument root）に入ります
- コマンド： ln -s [ディレクト名] [ドメイン名] （例：ln -s drupal7 old-pine.net）
- コマンド： ls -l　で生成したシンボリックリンクを確認します（例： old-pine.net -> pine）
シンボリックリンクの削除
- コマンド：unlink [ドメイン名] (例：unlink old-pine.net)
- コマンド：ls -l でドメイン名の同期先が消えたことを確認します

安全のため、コマンド(rm)でシンボリックリンクを削除しないこと

シンボリックリンクを削除するのはコマンド(rm)できますが、誤って指定すると、同期先のディレクトリの内容を削除していまう危険があります
シンボリックリンクを削除するには、コマンド(unlink)を使用すべきです

記事カテゴリ

タグ

モジュール（Feature）が開発ソース管理、コンテンツデータ移行などに利用されます

最初モジュール（Feature）が何に使うかはあまりわからなかったです（いろいろな説明がちゅ抽象的）。
実はDrupalの開発ソース管理（例：開発環境ー＞ステージん環境ー＞本番環境）、コンテンツデータの移行に使用されます

データ移行例：コンテンツデータ（Article）＋Viewsで作成したコンテンツ検索一覧画面

データ移行の簡単な例として、既存のコンテンツデータ（例：Article⇒記事）、Viewsで作成したコンテンツ一覧画面を移行します
コンテンツデータ移行に必須なモジュール：
- Feature
- Node Export （FeatureモジュールにサポートするNode export featuresサブモジュールを有効化）
Feature管理画面で必要なモジュール、モジュールの関連、コンテンツデータを選択して、一つのモジュールとして作成し、ダウンロードします
作成されたモジュール（tarファイル）を移行先で通常のモジュールインストールをして、有効化を行います。Feature管理画面で移行元の内容を適用、保存します
具体的な操作はビデオをご参考ください

FeatureがDurupalのすべての設定、構成の移行はできません

移行はモジュール単位で、構成は出力可能なものを中心にしています。以下は移行可能な部分
- Core ： Content Types、 Fields、 Menus、 Taxonomies、 Text formats、 Image styles、 User roles 、 permissions
- Contribute： Views、 CTools、 Context 、 Panels、 Rules 、 Contexts、 Display Suite
移行できない部分は、例：テーマ、コンテンツに挿入した画像などがあります
- コンテンツに含まるメディア（例：写真、ビデオ、ファイルなど）がローカル（sites/default/files）に保存したため、移行先の保存パス修正、およびメディアファイルのコピーが手動で行う必要があります

video

記事カテゴリ

タグ

Drupalの部分的なコンテンツデータを別のDrualサイトに移行する場合そのコンテンツの構造定義とコンテンツCSVデータのエクスポート／インポートができます

背景：Drupal7.54
Drupalのサイト引っ越しなどでデータ移行の必要があります、以下の移行方法はよく利用されます。
- Drupalのモジュール（Feature）を用いてサイト間のデータ移行/開発管理を行います (162)
- 同じDrupalバージョンの単一サイトを複数サイト（ドメイン）の一つDrupalの共有ソースサイトへの移行チャレンジ (161)
ただし、部分的なコンテンツしか移行しない場合、上記方法では難しくなります
ここで、コンテンツ定義とデータを別々でexport/import方法を説明します

Drupalのモジュール（Bundle copy、 Taxonomy CSV import/export）でコンテンツの構成／定義をExport/Importします

モジュール（Bundle copy）でコンテンツの構成／定義を簡単に移行します（具体的にステップは省略）
タクソノミーのタームの構成（フィールドが追加など）が変わらなければ、モジュール（、Taxonomy CSV import/export）でタームリストデータをcsvファイルの出力することはできます
- 出力したCSVデータの別のサイトにインポートする場合、タクソノミーのボキャブラリーとタームIDが変わった可能性があります
- コンテンツのフィールドに「Term Reference」タイプのものがあれば、コンテンツ追加／編集ボタンをクリックすると、「HTTP ERROR 500」エラーが発生するかもしれないです
- 一番簡単な対応方法ではそのフィールドを一回削除して、再作成すればよいです（データインポートする前の段階）

Drupalのコンテンツ構成（フィールド）テーブルのデータをcsvフォーマットに出力します

現時点ではコンテンツのデータをcsvに出力するモジュールはあまり見当たらにです
コンテンツのフィールドをDB上各テーブルを見つけ出します
- コンテンツ（例：Article）のフィールドごとに一つのテールが存在しています
- Title ➡　nodeテーブルの「title」フィールド
- body ➡　field_data_bodyテーブルの「body_value」フィールド（またはbody_summaryなど）
- カスタムフィールド ➡　field_data_CUSTOM_FIELD_NAMEの「field_data_CUSTOM_FIELD_NAME_value」フィールド
これらのテーブルを「node」テーブルを中心してジョインして、新しいテーブルの書き込みます
- すべてのコンテンツは「node」テーブルを基本にしています
- 各フィールドのテーブルに「entity_id」がnodeテーブルの「nid」の関連付けキーとなります
- 全フィールドと同じフィールドの新しいテーブルを一つ作成します（例：new_table）
- 全フィールドをJOINしてデータを新しいテーブル（例：new_table）にコピーします
```
INSERT INTO new_table (title, body, CUSTOM_FIELD_NAME,   ・・・・・・)
SELECT 
   title,
   body.body_value,
   T1.field_data_CUSTOM_FIEDL_NAME_value,
  ・・・・・・
FROM node
   left join field_data_body body on nid = body.entity_id
   left join field_data_CUSTOM_FIELD_NAME  T1  on T1.entity_id = nid
  ・・・・・・
  
```
新しいテーブル（new_table）の内容をｃｓｖフォーマットに出力します

Drupalのモジュール（Feeds Import）でコンテンツｃｓｖデータをインポートします

モジュール（Feeds Import）がよく利用されるものなので、簡単にｃｓｖデータを確認コンテンツにインポートすることができます
Feeds Importの説明は省略します(Drupalのモジュール（Feeds）で手動でデータインポート時の必須設定 (199)、FeedsモジュールでEnityにデータインポート (34)などを参考にしてください)

シリーズ記事一覧

記事カテゴリ

タグ

モジュール（Feature）が開発ソース管理、コンテンツデータ移行などに利用されます

最初モジュール（Feature）が何に使うかはあまりわからなかったです（いろいろな説明がちゅ抽象的）。
実はDrupalの開発ソース管理（例：開発環境ー＞ステージん環境ー＞本番環境）、コンテンツデータの移行に使用されます

データ移行例：コンテンツデータ（Article）＋Viewsで作成したコンテンツ検索一覧画面

データ移行の簡単な例として、既存のコンテンツデータ（例：Article⇒記事）、Viewsで作成したコンテンツ一覧画面を移行します
コンテンツデータ移行に必須なモジュール：
- Feature
- Node Export （FeatureモジュールにサポートするNode export featuresサブモジュールを有効化）
Feature管理画面で必要なモジュール、モジュールの関連、コンテンツデータを選択して、一つのモジュールとして作成し、ダウンロードします
作成されたモジュール（tarファイル）を移行先で通常のモジュールインストールをして、有効化を行います。Feature管理画面で移行元の内容を適用、保存します
具体的な操作はビデオをご参考ください

FeatureがDurupalのすべての設定、構成の移行はできません

移行はモジュール単位で、構成は出力可能なものを中心にしています。以下は移行可能な部分
- Core ： Content Types、 Fields、 Menus、 Taxonomies、 Text formats、 Image styles、 User roles 、 permissions
- Contribute： Views、 CTools、 Context 、 Panels、 Rules 、 Contexts、 Display Suite
移行できない部分は、例：テーマ、コンテンツに挿入した画像などがあります
- コンテンツに含まるメディア（例：写真、ビデオ、ファイルなど）がローカル（sites/default/files）に保存したため、移行先の保存パス修正、およびメディアファイルのコピーが手動で行う必要があります

video

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ

注意点：Drupalのモジュール（Feeds）の設定が間違うと手動でデータインポートができなくなります

環境：Drupal7.54、Feeds7.x-3.0
やりたいこと：手動でデータをインポート（例：csvファイルからのインポートなど）
Feedの基本設定のところある二か所をチェックしないと手動でのインポートができない
- 添付するコンテンツタイプ：スタントアローンのフォームを使う
- 投稿時にインポート
- 初期としてはこの二つ設定を有効にしています
ちなみに、「投稿時にインポート」を無効の場合、バッチでデータインポートすることになります（バッチの設定が必要）
添付するコンテンツタイプ：「スタントアローンのフォームを使う」以外の選択肢を選択すると、インポート画面（ホーム » インポート）に当該インポーターはありません

手動でインポートできないときに画面上に「インポートされた項目はありません」が表示されます

「投稿時にインポート」オプションが無効の場合、手動でデータインポートはできません
インポートデータがあるにはかかわらず、画面上に「インポートされた項目はありません」として表示されます
バッチにインポートジョブを入れたメッセージはありません

記事カテゴリ

タグ

目的

Entity Typeデータにほかのデータ（例：ｃｓｖ、xmlなど）からのインポートを可能にする
Feedsの初期データ変換プロセッサーに「Entity Type」のものがなかった

解決の選択肢

Feed Importモジュールでのデータインポート
Feedsモジュールのカスタマイズをする

ここでの解決：Feedsのカスタマイズ

インストールされたモジュール
- Feeds : 7.x-2.0
- ECK : 7.x-2.0
- Entity API : 7.x-1.5
上記モジュールのインストールと有効化
ECKでインポートデータタイプとBundleを作成する
- 例：　データタイプ：「組織データ」、Bundle：「ｘｘｘの組織データ」
- 「組織データ」のプロパティ：title、uid、created、changedを使用する
- 「ｘｘｘの組織データ」のフィールド：「組織コード」、「正式組織名」をテキストフィールドで追加

Feedsの紹介

Feedsが三つの部分から構成される：Fetcher、Parser、Processor
- Fetcher：インポータデータの取得（例：File upload、external RSS Feedなど）
- Parser：インポートデータの解析方法の指定（csv、xls、xml、RSSなど）
- Processor：インポートデータの作成（Node、terms、usersなどのデータ作成）

FeedsにEntity Typeデータ変換プロセッサーに追加

PatchファイルをFeedsモジュールに当てる
Feedsのデータ変換プロセッサー設定画面にEntity Typeのデータ変換プロセッサー追加前後のイメージ

files

添付	サイズ
feeds_entity_processor-1033202-217.patch_.txt (16.03 KB)	16.03 KB

記事カテゴリ

タグ

エラー：モジュール(Twitter)をバージョンアップしてフロントページに開くと「EntityFieldQueryException」が発生

モジュール(Twitter)のバージョン：7.x-5.11 ⇒ 7.x-6.2 にアップデートしました（新モジュールから旧モジュールを上書き）

フロントページを開いてみたらエラーが発生し：

EntityFieldQueryException: エンティティー <em class="placeholder">twitter_account</em> にはベーステーブルがありません。 EntityFieldQuery->propertyQuery() (/virtual/drills/public_html/drupal7/includes/entity.inc ファイル　1271行).

画面にエラーしか表示されていないです

原因：Twitter7.x-5.11⇒7.x-6.2にアップデートする場合DBのテーブルが追加されたので、DB更新が必要

原因は比較的に単純的で、Twitter7.x-6.2（7.x-6.0以上になるとデータ構造が変わった）が7.x-5.11よりデータテーブルが追加されました
管理者権限でupdate.phpを実行してデータテーブルを追加します

シリーズ記事一覧

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ

やりたいこと：一つDrupalのソースで複数のサイト（複数のドメイン）を構築したいです

Drupalを用いて複数のサイト（ドメイン）を構築する場合、一つサイト（ドメイン）ごとに一つのDrupalソースで構築することがもちろん問題はありません
Drupalソースが分散すると、バージョンアップ、バグ管理などの作業が大変になります
当然一つのDrupalソースの元で複数のサイト（ドメイン）の構築が必要となります
- 一ドメイン ⇒ Drupalソース ⇒ 共有DB
- 一ドメイン ⇒ Drupalソース ⇒ 独立DB
Drupalでは複数のサイト（ドメイン）への対応をしています

sitesディレクトリの下にドメインごとの子ディレクトリを作成してマルティサイトを構築します

複数のドメイン名をDrupalのルートディレクトリに同期します（例：シンボリックリンクでドメイン名をディレクトリと同期します）
- 例： old-pine.net をDrupalのルートディレクトリにシンボリックリンクで同期します
Drupalのルートディレクトリの下に sites ディレクトリがあります。sitesの下に各メイン名に同期したいディレクトリを作成します
- 例：sites/pine を作成します
sites/sites.phpファイルでドメイン名をディレクトと同期設定を行います
- 例： 'old-pine.net' => 'pine' （書き方：ドメイン名 => ディレクトリ名）
```
 $sites = array(
    'old-pine.net' => 'pine',
 );
```
新規作成したディレクトの下にサイトのインストール設定ファイル(settings.php)の作成
- 例：sites/pine/settings.phpを作成します
- settings.phpの内容はsites/pine/default.settings.phpのコピーで良いです（サイト新規作成する場合）
追加したドメイン名でサイトをアクセスして、新規サイトができたことを確認します

記事カテゴリ

タグ

やりたいこと：レンタルサーバーで申請したドメイン名を特定なディレクトリに同期するシンボリックリンク作成したいです

レンタルサーバー（例：valueserver）で申請したドメイン名を特定なディレクトに同期するツールが提供されています
同期ツールを利用するのは便利だが、設定が誤ると同期先のディレクトリのファイルがすべて削除されてします危険があります
特に、この操作がよく行うことではなく、誤って設定する確率は実は高そうです（実際に設定を誤って、同期先のファイルが消されてしまう事項がありました）

安全のため、シンボリックリンク作成コマンドでディレクト同期をしたほうがよいです

シンボリックリンク作成：
- public_htmlディレクトリ（apacheではdocument root）に入ります
- コマンド： ln -s [ディレクト名] [ドメイン名] （例：ln -s drupal7 old-pine.net）
- コマンド： ls -l　で生成したシンボリックリンクを確認します（例： old-pine.net -> pine）
シンボリックリンクの削除
- コマンド：unlink [ドメイン名] (例：unlink old-pine.net)
- コマンド：ls -l でドメイン名の同期先が消えたことを確認します

安全のため、コマンド(rm)でシンボリックリンクを削除しないこと

シンボリックリンクを削除するのはコマンド(rm)できますが、誤って指定すると、同期先のディレクトリの内容を削除していまう危険があります
シンボリックリンクを削除するには、コマンド(unlink)を使用すべきです

記事カテゴリ

タグ

モジュール（Feature）が開発ソース管理、コンテンツデータ移行などに利用されます

最初モジュール（Feature）が何に使うかはあまりわからなかったです（いろいろな説明がちゅ抽象的）。
実はDrupalの開発ソース管理（例：開発環境ー＞ステージん環境ー＞本番環境）、コンテンツデータの移行に使用されます

データ移行例：コンテンツデータ（Article）＋Viewsで作成したコンテンツ検索一覧画面

データ移行の簡単な例として、既存のコンテンツデータ（例：Article⇒記事）、Viewsで作成したコンテンツ一覧画面を移行します
コンテンツデータ移行に必須なモジュール：
- Feature
- Node Export （FeatureモジュールにサポートするNode export featuresサブモジュールを有効化）
Feature管理画面で必要なモジュール、モジュールの関連、コンテンツデータを選択して、一つのモジュールとして作成し、ダウンロードします
作成されたモジュール（tarファイル）を移行先で通常のモジュールインストールをして、有効化を行います。Feature管理画面で移行元の内容を適用、保存します
具体的な操作はビデオをご参考ください

FeatureがDurupalのすべての設定、構成の移行はできません

移行はモジュール単位で、構成は出力可能なものを中心にしています。以下は移行可能な部分
- Core ： Content Types、 Fields、 Menus、 Taxonomies、 Text formats、 Image styles、 User roles 、 permissions
- Contribute： Views、 CTools、 Context 、 Panels、 Rules 、 Contexts、 Display Suite
移行できない部分は、例：テーマ、コンテンツに挿入した画像などがあります
- コンテンツに含まるメディア（例：写真、ビデオ、ファイルなど）がローカル（sites/default/files）に保存したため、移行先の保存パス修正、およびメディアファイルのコピーが手動で行う必要があります

video

記事カテゴリ

タグ

Drupalの部分的なコンテンツデータを別のDrualサイトに移行する場合そのコンテンツの構造定義とコンテンツCSVデータのエクスポート／インポートができます

背景：Drupal7.54
Drupalのサイト引っ越しなどでデータ移行の必要があります、以下の移行方法はよく利用されます。
- Drupalのモジュール（Feature）を用いてサイト間のデータ移行/開発管理を行います (162)
- 同じDrupalバージョンの単一サイトを複数サイト（ドメイン）の一つDrupalの共有ソースサイトへの移行チャレンジ (161)
ただし、部分的なコンテンツしか移行しない場合、上記方法では難しくなります
ここで、コンテンツ定義とデータを別々でexport/import方法を説明します

Drupalのモジュール（Bundle copy、 Taxonomy CSV import/export）でコンテンツの構成／定義をExport/Importします

モジュール（Bundle copy）でコンテンツの構成／定義を簡単に移行します（具体的にステップは省略）
タクソノミーのタームの構成（フィールドが追加など）が変わらなければ、モジュール（、Taxonomy CSV import/export）でタームリストデータをcsvファイルの出力することはできます
- 出力したCSVデータの別のサイトにインポートする場合、タクソノミーのボキャブラリーとタームIDが変わった可能性があります
- コンテンツのフィールドに「Term Reference」タイプのものがあれば、コンテンツ追加／編集ボタンをクリックすると、「HTTP ERROR 500」エラーが発生するかもしれないです
- 一番簡単な対応方法ではそのフィールドを一回削除して、再作成すればよいです（データインポートする前の段階）

Drupalのコンテンツ構成（フィールド）テーブルのデータをcsvフォーマットに出力します

現時点ではコンテンツのデータをcsvに出力するモジュールはあまり見当たらにです
コンテンツのフィールドをDB上各テーブルを見つけ出します
- コンテンツ（例：Article）のフィールドごとに一つのテールが存在しています
- Title ➡　nodeテーブルの「title」フィールド
- body ➡　field_data_bodyテーブルの「body_value」フィールド（またはbody_summaryなど）
- カスタムフィールド ➡　field_data_CUSTOM_FIELD_NAMEの「field_data_CUSTOM_FIELD_NAME_value」フィールド
これらのテーブルを「node」テーブルを中心してジョインして、新しいテーブルの書き込みます
- すべてのコンテンツは「node」テーブルを基本にしています
- 各フィールドのテーブルに「entity_id」がnodeテーブルの「nid」の関連付けキーとなります
- 全フィールドと同じフィールドの新しいテーブルを一つ作成します（例：new_table）
- 全フィールドをJOINしてデータを新しいテーブル（例：new_table）にコピーします
```
INSERT INTO new_table (title, body, CUSTOM_FIELD_NAME,   ・・・・・・)
SELECT 
   title,
   body.body_value,
   T1.field_data_CUSTOM_FIEDL_NAME_value,
  ・・・・・・
FROM node
   left join field_data_body body on nid = body.entity_id
   left join field_data_CUSTOM_FIELD_NAME  T1  on T1.entity_id = nid
  ・・・・・・
  
```
新しいテーブル（new_table）の内容をｃｓｖフォーマットに出力します

Drupalのモジュール（Feeds Import）でコンテンツｃｓｖデータをインポートします

モジュール（Feeds Import）がよく利用されるものなので、簡単にｃｓｖデータを確認コンテンツにインポートすることができます
Feeds Importの説明は省略します(Drupalのモジュール（Feeds）で手動でデータインポート時の必須設定 (199)、FeedsモジュールでEnityにデータインポート (34)などを参考にしてください)

シリーズ記事一覧

記事カテゴリ

タグ

モジュール（Feature）が開発ソース管理、コンテンツデータ移行などに利用されます

最初モジュール（Feature）が何に使うかはあまりわからなかったです（いろいろな説明がちゅ抽象的）。
実はDrupalの開発ソース管理（例：開発環境ー＞ステージん環境ー＞本番環境）、コンテンツデータの移行に使用されます

データ移行例：コンテンツデータ（Article）＋Viewsで作成したコンテンツ検索一覧画面

データ移行の簡単な例として、既存のコンテンツデータ（例：Article⇒記事）、Viewsで作成したコンテンツ一覧画面を移行します
コンテンツデータ移行に必須なモジュール：
- Feature
- Node Export （FeatureモジュールにサポートするNode export featuresサブモジュールを有効化）
Feature管理画面で必要なモジュール、モジュールの関連、コンテンツデータを選択して、一つのモジュールとして作成し、ダウンロードします
作成されたモジュール（tarファイル）を移行先で通常のモジュールインストールをして、有効化を行います。Feature管理画面で移行元の内容を適用、保存します
具体的な操作はビデオをご参考ください

FeatureがDurupalのすべての設定、構成の移行はできません

移行はモジュール単位で、構成は出力可能なものを中心にしています。以下は移行可能な部分
- Core ： Content Types、 Fields、 Menus、 Taxonomies、 Text formats、 Image styles、 User roles 、 permissions
- Contribute： Views、 CTools、 Context 、 Panels、 Rules 、 Contexts、 Display Suite
移行できない部分は、例：テーマ、コンテンツに挿入した画像などがあります
- コンテンツに含まるメディア（例：写真、ビデオ、ファイルなど）がローカル（sites/default/files）に保存したため、移行先の保存パス修正、およびメディアファイルのコピーが手動で行う必要があります

video

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ

注意点：Drupalのモジュール（Feeds）の設定が間違うと手動でデータインポートができなくなります

環境：Drupal7.54、Feeds7.x-3.0
やりたいこと：手動でデータをインポート（例：csvファイルからのインポートなど）
Feedの基本設定のところある二か所をチェックしないと手動でのインポートができない
- 添付するコンテンツタイプ：スタントアローンのフォームを使う
- 投稿時にインポート
- 初期としてはこの二つ設定を有効にしています
ちなみに、「投稿時にインポート」を無効の場合、バッチでデータインポートすることになります（バッチの設定が必要）
添付するコンテンツタイプ：「スタントアローンのフォームを使う」以外の選択肢を選択すると、インポート画面（ホーム » インポート）に当該インポーターはありません

手動でインポートできないときに画面上に「インポートされた項目はありません」が表示されます

「投稿時にインポート」オプションが無効の場合、手動でデータインポートはできません
インポートデータがあるにはかかわらず、画面上に「インポートされた項目はありません」として表示されます
バッチにインポートジョブを入れたメッセージはありません

記事カテゴリ

タグ

目的

Entity Typeデータにほかのデータ（例：ｃｓｖ、xmlなど）からのインポートを可能にする
Feedsの初期データ変換プロセッサーに「Entity Type」のものがなかった

解決の選択肢

Feed Importモジュールでのデータインポート
Feedsモジュールのカスタマイズをする

ここでの解決：Feedsのカスタマイズ

インストールされたモジュール
- Feeds : 7.x-2.0
- ECK : 7.x-2.0
- Entity API : 7.x-1.5
上記モジュールのインストールと有効化
ECKでインポートデータタイプとBundleを作成する
- 例：　データタイプ：「組織データ」、Bundle：「ｘｘｘの組織データ」
- 「組織データ」のプロパティ：title、uid、created、changedを使用する
- 「ｘｘｘの組織データ」のフィールド：「組織コード」、「正式組織名」をテキストフィールドで追加

Feedsの紹介

Feedsが三つの部分から構成される：Fetcher、Parser、Processor
- Fetcher：インポータデータの取得（例：File upload、external RSS Feedなど）
- Parser：インポートデータの解析方法の指定（csv、xls、xml、RSSなど）
- Processor：インポートデータの作成（Node、terms、usersなどのデータ作成）

FeedsにEntity Typeデータ変換プロセッサーに追加

PatchファイルをFeedsモジュールに当てる
Feedsのデータ変換プロセッサー設定画面にEntity Typeのデータ変換プロセッサー追加前後のイメージ

files

添付	サイズ
feeds_entity_processor-1033202-217.patch_.txt (16.03 KB)	16.03 KB

記事カテゴリ

タグ

エラー：モジュール(Twitter)をバージョンアップしてフロントページに開くと「EntityFieldQueryException」が発生

モジュール(Twitter)のバージョン：7.x-5.11 ⇒ 7.x-6.2 にアップデートしました（新モジュールから旧モジュールを上書き）

フロントページを開いてみたらエラーが発生し：

EntityFieldQueryException: エンティティー <em class="placeholder">twitter_account</em> にはベーステーブルがありません。 EntityFieldQuery->propertyQuery() (/virtual/drills/public_html/drupal7/includes/entity.inc ファイル　1271行).

画面にエラーしか表示されていないです

原因：Twitter7.x-5.11⇒7.x-6.2にアップデートする場合DBのテーブルが追加されたので、DB更新が必要

原因は比較的に単純的で、Twitter7.x-6.2（7.x-6.0以上になるとデータ構造が変わった）が7.x-5.11よりデータテーブルが追加されました
管理者権限でupdate.phpを実行してデータテーブルを追加します

シリーズ記事一覧

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ

やりたいこと：一つDrupalのソースで複数のサイト（複数のドメイン）を構築したいです

Drupalを用いて複数のサイト（ドメイン）を構築する場合、一つサイト（ドメイン）ごとに一つのDrupalソースで構築することがもちろん問題はありません
Drupalソースが分散すると、バージョンアップ、バグ管理などの作業が大変になります
当然一つのDrupalソースの元で複数のサイト（ドメイン）の構築が必要となります
- 一ドメイン ⇒ Drupalソース ⇒ 共有DB
- 一ドメイン ⇒ Drupalソース ⇒ 独立DB
Drupalでは複数のサイト（ドメイン）への対応をしています

sitesディレクトリの下にドメインごとの子ディレクトリを作成してマルティサイトを構築します

複数のドメイン名をDrupalのルートディレクトリに同期します（例：シンボリックリンクでドメイン名をディレクトリと同期します）
- 例： old-pine.net をDrupalのルートディレクトリにシンボリックリンクで同期します
Drupalのルートディレクトリの下に sites ディレクトリがあります。sitesの下に各メイン名に同期したいディレクトリを作成します
- 例：sites/pine を作成します
sites/sites.phpファイルでドメイン名をディレクトと同期設定を行います
- 例： 'old-pine.net' => 'pine' （書き方：ドメイン名 => ディレクトリ名）
```
 $sites = array(
    'old-pine.net' => 'pine',
 );
```
新規作成したディレクトの下にサイトのインストール設定ファイル(settings.php)の作成
- 例：sites/pine/settings.phpを作成します
- settings.phpの内容はsites/pine/default.settings.phpのコピーで良いです（サイト新規作成する場合）
追加したドメイン名でサイトをアクセスして、新規サイトができたことを確認します

記事カテゴリ

タグ

やりたいこと：レンタルサーバーで申請したドメイン名を特定なディレクトリに同期するシンボリックリンク作成したいです

レンタルサーバー（例：valueserver）で申請したドメイン名を特定なディレクトに同期するツールが提供されています
同期ツールを利用するのは便利だが、設定が誤ると同期先のディレクトリのファイルがすべて削除されてします危険があります
特に、この操作がよく行うことではなく、誤って設定する確率は実は高そうです（実際に設定を誤って、同期先のファイルが消されてしまう事項がありました）

安全のため、シンボリックリンク作成コマンドでディレクト同期をしたほうがよいです

シンボリックリンク作成：
- public_htmlディレクトリ（apacheではdocument root）に入ります
- コマンド： ln -s [ディレクト名] [ドメイン名] （例：ln -s drupal7 old-pine.net）
- コマンド： ls -l　で生成したシンボリックリンクを確認します（例： old-pine.net -> pine）
シンボリックリンクの削除
- コマンド：unlink [ドメイン名] (例：unlink old-pine.net)
- コマンド：ls -l でドメイン名の同期先が消えたことを確認します

安全のため、コマンド(rm)でシンボリックリンクを削除しないこと

シンボリックリンクを削除するのはコマンド(rm)できますが、誤って指定すると、同期先のディレクトリの内容を削除していまう危険があります
シンボリックリンクを削除するには、コマンド(unlink)を使用すべきです

記事カテゴリ

タグ

モジュール（Feature）が開発ソース管理、コンテンツデータ移行などに利用されます

最初モジュール（Feature）が何に使うかはあまりわからなかったです（いろいろな説明がちゅ抽象的）。
実はDrupalの開発ソース管理（例：開発環境ー＞ステージん環境ー＞本番環境）、コンテンツデータの移行に使用されます

データ移行例：コンテンツデータ（Article）＋Viewsで作成したコンテンツ検索一覧画面

データ移行の簡単な例として、既存のコンテンツデータ（例：Article⇒記事）、Viewsで作成したコンテンツ一覧画面を移行します
コンテンツデータ移行に必須なモジュール：
- Feature
- Node Export （FeatureモジュールにサポートするNode export featuresサブモジュールを有効化）
Feature管理画面で必要なモジュール、モジュールの関連、コンテンツデータを選択して、一つのモジュールとして作成し、ダウンロードします
作成されたモジュール（tarファイル）を移行先で通常のモジュールインストールをして、有効化を行います。Feature管理画面で移行元の内容を適用、保存します
具体的な操作はビデオをご参考ください

FeatureがDurupalのすべての設定、構成の移行はできません

移行はモジュール単位で、構成は出力可能なものを中心にしています。以下は移行可能な部分
- Core ： Content Types、 Fields、 Menus、 Taxonomies、 Text formats、 Image styles、 User roles 、 permissions
- Contribute： Views、 CTools、 Context 、 Panels、 Rules 、 Contexts、 Display Suite
移行できない部分は、例：テーマ、コンテンツに挿入した画像などがあります
- コンテンツに含まるメディア（例：写真、ビデオ、ファイルなど）がローカル（sites/default/files）に保存したため、移行先の保存パス修正、およびメディアファイルのコピーが手動で行う必要があります

video

記事カテゴリ

タグ

Drupalの部分的なコンテンツデータを別のDrualサイトに移行する場合そのコンテンツの構造定義とコンテンツCSVデータのエクスポート／インポートができます

背景：Drupal7.54
Drupalのサイト引っ越しなどでデータ移行の必要があります、以下の移行方法はよく利用されます。
- Drupalのモジュール（Feature）を用いてサイト間のデータ移行/開発管理を行います (162)
- 同じDrupalバージョンの単一サイトを複数サイト（ドメイン）の一つDrupalの共有ソースサイトへの移行チャレンジ (161)
ただし、部分的なコンテンツしか移行しない場合、上記方法では難しくなります
ここで、コンテンツ定義とデータを別々でexport/import方法を説明します

Drupalのモジュール（Bundle copy、 Taxonomy CSV import/export）でコンテンツの構成／定義をExport/Importします

モジュール（Bundle copy）でコンテンツの構成／定義を簡単に移行します（具体的にステップは省略）
タクソノミーのタームの構成（フィールドが追加など）が変わらなければ、モジュール（、Taxonomy CSV import/export）でタームリストデータをcsvファイルの出力することはできます
- 出力したCSVデータの別のサイトにインポートする場合、タクソノミーのボキャブラリーとタームIDが変わった可能性があります
- コンテンツのフィールドに「Term Reference」タイプのものがあれば、コンテンツ追加／編集ボタンをクリックすると、「HTTP ERROR 500」エラーが発生するかもしれないです
- 一番簡単な対応方法ではそのフィールドを一回削除して、再作成すればよいです（データインポートする前の段階）

Drupalのコンテンツ構成（フィールド）テーブルのデータをcsvフォーマットに出力します

現時点ではコンテンツのデータをcsvに出力するモジュールはあまり見当たらにです
コンテンツのフィールドをDB上各テーブルを見つけ出します
- コンテンツ（例：Article）のフィールドごとに一つのテールが存在しています
- Title ➡　nodeテーブルの「title」フィールド
- body ➡　field_data_bodyテーブルの「body_value」フィールド（またはbody_summaryなど）
- カスタムフィールド ➡　field_data_CUSTOM_FIELD_NAMEの「field_data_CUSTOM_FIELD_NAME_value」フィールド
これらのテーブルを「node」テーブルを中心してジョインして、新しいテーブルの書き込みます
- すべてのコンテンツは「node」テーブルを基本にしています
- 各フィールドのテーブルに「entity_id」がnodeテーブルの「nid」の関連付けキーとなります
- 全フィールドと同じフィールドの新しいテーブルを一つ作成します（例：new_table）
- 全フィールドをJOINしてデータを新しいテーブル（例：new_table）にコピーします
```
INSERT INTO new_table (title, body, CUSTOM_FIELD_NAME,   ・・・・・・)
SELECT 
   title,
   body.body_value,
   T1.field_data_CUSTOM_FIEDL_NAME_value,
  ・・・・・・
FROM node
   left join field_data_body body on nid = body.entity_id
   left join field_data_CUSTOM_FIELD_NAME  T1  on T1.entity_id = nid
  ・・・・・・
  
```
新しいテーブル（new_table）の内容をｃｓｖフォーマットに出力します

Drupalのモジュール（Feeds Import）でコンテンツｃｓｖデータをインポートします

モジュール（Feeds Import）がよく利用されるものなので、簡単にｃｓｖデータを確認コンテンツにインポートすることができます
Feeds Importの説明は省略します(Drupalのモジュール（Feeds）で手動でデータインポート時の必須設定 (199)、FeedsモジュールでEnityにデータインポート (34)などを参考にしてください)

シリーズ記事一覧

記事カテゴリ

タグ

モジュール（Feature）が開発ソース管理、コンテンツデータ移行などに利用されます

最初モジュール（Feature）が何に使うかはあまりわからなかったです（いろいろな説明がちゅ抽象的）。
実はDrupalの開発ソース管理（例：開発環境ー＞ステージん環境ー＞本番環境）、コンテンツデータの移行に使用されます

データ移行例：コンテンツデータ（Article）＋Viewsで作成したコンテンツ検索一覧画面

データ移行の簡単な例として、既存のコンテンツデータ（例：Article⇒記事）、Viewsで作成したコンテンツ一覧画面を移行します
コンテンツデータ移行に必須なモジュール：
- Feature
- Node Export （FeatureモジュールにサポートするNode export featuresサブモジュールを有効化）
Feature管理画面で必要なモジュール、モジュールの関連、コンテンツデータを選択して、一つのモジュールとして作成し、ダウンロードします
作成されたモジュール（tarファイル）を移行先で通常のモジュールインストールをして、有効化を行います。Feature管理画面で移行元の内容を適用、保存します
具体的な操作はビデオをご参考ください

FeatureがDurupalのすべての設定、構成の移行はできません

移行はモジュール単位で、構成は出力可能なものを中心にしています。以下は移行可能な部分
- Core ： Content Types、 Fields、 Menus、 Taxonomies、 Text formats、 Image styles、 User roles 、 permissions
- Contribute： Views、 CTools、 Context 、 Panels、 Rules 、 Contexts、 Display Suite
移行できない部分は、例：テーマ、コンテンツに挿入した画像などがあります
- コンテンツに含まるメディア（例：写真、ビデオ、ファイルなど）がローカル（sites/default/files）に保存したため、移行先の保存パス修正、およびメディアファイルのコピーが手動で行う必要があります

video

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ

注意点：Drupalのモジュール（Feeds）の設定が間違うと手動でデータインポートができなくなります

環境：Drupal7.54、Feeds7.x-3.0
やりたいこと：手動でデータをインポート（例：csvファイルからのインポートなど）
Feedの基本設定のところある二か所をチェックしないと手動でのインポートができない
- 添付するコンテンツタイプ：スタントアローンのフォームを使う
- 投稿時にインポート
- 初期としてはこの二つ設定を有効にしています
ちなみに、「投稿時にインポート」を無効の場合、バッチでデータインポートすることになります（バッチの設定が必要）
添付するコンテンツタイプ：「スタントアローンのフォームを使う」以外の選択肢を選択すると、インポート画面（ホーム » インポート）に当該インポーターはありません

手動でインポートできないときに画面上に「インポートされた項目はありません」が表示されます

「投稿時にインポート」オプションが無効の場合、手動でデータインポートはできません
インポートデータがあるにはかかわらず、画面上に「インポートされた項目はありません」として表示されます
バッチにインポートジョブを入れたメッセージはありません

記事カテゴリ

タグ

目的

Entity Typeデータにほかのデータ（例：ｃｓｖ、xmlなど）からのインポートを可能にする
Feedsの初期データ変換プロセッサーに「Entity Type」のものがなかった

解決の選択肢

Feed Importモジュールでのデータインポート
Feedsモジュールのカスタマイズをする

ここでの解決：Feedsのカスタマイズ

インストールされたモジュール
- Feeds : 7.x-2.0
- ECK : 7.x-2.0
- Entity API : 7.x-1.5
上記モジュールのインストールと有効化
ECKでインポートデータタイプとBundleを作成する
- 例：　データタイプ：「組織データ」、Bundle：「ｘｘｘの組織データ」
- 「組織データ」のプロパティ：title、uid、created、changedを使用する
- 「ｘｘｘの組織データ」のフィールド：「組織コード」、「正式組織名」をテキストフィールドで追加

Feedsの紹介

Feedsが三つの部分から構成される：Fetcher、Parser、Processor
- Fetcher：インポータデータの取得（例：File upload、external RSS Feedなど）
- Parser：インポートデータの解析方法の指定（csv、xls、xml、RSSなど）
- Processor：インポートデータの作成（Node、terms、usersなどのデータ作成）

FeedsにEntity Typeデータ変換プロセッサーに追加

PatchファイルをFeedsモジュールに当てる
Feedsのデータ変換プロセッサー設定画面にEntity Typeのデータ変換プロセッサー追加前後のイメージ

files

添付	サイズ
feeds_entity_processor-1033202-217.patch_.txt (16.03 KB)	16.03 KB

記事カテゴリ

タグ

エラー：モジュール(Twitter)をバージョンアップしてフロントページに開くと「EntityFieldQueryException」が発生

モジュール(Twitter)のバージョン：7.x-5.11 ⇒ 7.x-6.2 にアップデートしました（新モジュールから旧モジュールを上書き）

フロントページを開いてみたらエラーが発生し：

EntityFieldQueryException: エンティティー <em class="placeholder">twitter_account</em> にはベーステーブルがありません。 EntityFieldQuery->propertyQuery() (/virtual/drills/public_html/drupal7/includes/entity.inc ファイル　1271行).

画面にエラーしか表示されていないです

原因：Twitter7.x-5.11⇒7.x-6.2にアップデートする場合DBのテーブルが追加されたので、DB更新が必要

原因は比較的に単純的で、Twitter7.x-6.2（7.x-6.0以上になるとデータ構造が変わった）が7.x-5.11よりデータテーブルが追加されました
管理者権限でupdate.phpを実行してデータテーブルを追加します

シリーズ記事一覧

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ

やりたいこと：一つDrupalのソースで複数のサイト（複数のドメイン）を構築したいです

Drupalを用いて複数のサイト（ドメイン）を構築する場合、一つサイト（ドメイン）ごとに一つのDrupalソースで構築することがもちろん問題はありません
Drupalソースが分散すると、バージョンアップ、バグ管理などの作業が大変になります
当然一つのDrupalソースの元で複数のサイト（ドメイン）の構築が必要となります
- 一ドメイン ⇒ Drupalソース ⇒ 共有DB
- 一ドメイン ⇒ Drupalソース ⇒ 独立DB
Drupalでは複数のサイト（ドメイン）への対応をしています

sitesディレクトリの下にドメインごとの子ディレクトリを作成してマルティサイトを構築します

複数のドメイン名をDrupalのルートディレクトリに同期します（例：シンボリックリンクでドメイン名をディレクトリと同期します）
- 例： old-pine.net をDrupalのルートディレクトリにシンボリックリンクで同期します
Drupalのルートディレクトリの下に sites ディレクトリがあります。sitesの下に各メイン名に同期したいディレクトリを作成します
- 例：sites/pine を作成します
sites/sites.phpファイルでドメイン名をディレクトと同期設定を行います
- 例： 'old-pine.net' => 'pine' （書き方：ドメイン名 => ディレクトリ名）
```
 $sites = array(
    'old-pine.net' => 'pine',
 );
```
新規作成したディレクトの下にサイトのインストール設定ファイル(settings.php)の作成
- 例：sites/pine/settings.phpを作成します
- settings.phpの内容はsites/pine/default.settings.phpのコピーで良いです（サイト新規作成する場合）
追加したドメイン名でサイトをアクセスして、新規サイトができたことを確認します

記事カテゴリ

タグ

やりたいこと：レンタルサーバーで申請したドメイン名を特定なディレクトリに同期するシンボリックリンク作成したいです

レンタルサーバー（例：valueserver）で申請したドメイン名を特定なディレクトに同期するツールが提供されています
同期ツールを利用するのは便利だが、設定が誤ると同期先のディレクトリのファイルがすべて削除されてします危険があります
特に、この操作がよく行うことではなく、誤って設定する確率は実は高そうです（実際に設定を誤って、同期先のファイルが消されてしまう事項がありました）

安全のため、シンボリックリンク作成コマンドでディレクト同期をしたほうがよいです

シンボリックリンク作成：
- public_htmlディレクトリ（apacheではdocument root）に入ります
- コマンド： ln -s [ディレクト名] [ドメイン名] （例：ln -s drupal7 old-pine.net）
- コマンド： ls -l　で生成したシンボリックリンクを確認します（例： old-pine.net -> pine）
シンボリックリンクの削除
- コマンド：unlink [ドメイン名] (例：unlink old-pine.net)
- コマンド：ls -l でドメイン名の同期先が消えたことを確認します

安全のため、コマンド(rm)でシンボリックリンクを削除しないこと

シンボリックリンクを削除するのはコマンド(rm)できますが、誤って指定すると、同期先のディレクトリの内容を削除していまう危険があります
シンボリックリンクを削除するには、コマンド(unlink)を使用すべきです

記事カテゴリ

タグ

モジュール（Feature）が開発ソース管理、コンテンツデータ移行などに利用されます

最初モジュール（Feature）が何に使うかはあまりわからなかったです（いろいろな説明がちゅ抽象的）。
実はDrupalの開発ソース管理（例：開発環境ー＞ステージん環境ー＞本番環境）、コンテンツデータの移行に使用されます

データ移行例：コンテンツデータ（Article）＋Viewsで作成したコンテンツ検索一覧画面

データ移行の簡単な例として、既存のコンテンツデータ（例：Article⇒記事）、Viewsで作成したコンテンツ一覧画面を移行します
コンテンツデータ移行に必須なモジュール：
- Feature
- Node Export （FeatureモジュールにサポートするNode export featuresサブモジュールを有効化）
Feature管理画面で必要なモジュール、モジュールの関連、コンテンツデータを選択して、一つのモジュールとして作成し、ダウンロードします
作成されたモジュール（tarファイル）を移行先で通常のモジュールインストールをして、有効化を行います。Feature管理画面で移行元の内容を適用、保存します
具体的な操作はビデオをご参考ください

FeatureがDurupalのすべての設定、構成の移行はできません

移行はモジュール単位で、構成は出力可能なものを中心にしています。以下は移行可能な部分
- Core ： Content Types、 Fields、 Menus、 Taxonomies、 Text formats、 Image styles、 User roles 、 permissions
- Contribute： Views、 CTools、 Context 、 Panels、 Rules 、 Contexts、 Display Suite
移行できない部分は、例：テーマ、コンテンツに挿入した画像などがあります
- コンテンツに含まるメディア（例：写真、ビデオ、ファイルなど）がローカル（sites/default/files）に保存したため、移行先の保存パス修正、およびメディアファイルのコピーが手動で行う必要があります

video

記事カテゴリ

タグ

Drupalの部分的なコンテンツデータを別のDrualサイトに移行する場合そのコンテンツの構造定義とコンテンツCSVデータのエクスポート／インポートができます

背景：Drupal7.54
Drupalのサイト引っ越しなどでデータ移行の必要があります、以下の移行方法はよく利用されます。
- Drupalのモジュール（Feature）を用いてサイト間のデータ移行/開発管理を行います (162)
- 同じDrupalバージョンの単一サイトを複数サイト（ドメイン）の一つDrupalの共有ソースサイトへの移行チャレンジ (161)
ただし、部分的なコンテンツしか移行しない場合、上記方法では難しくなります
ここで、コンテンツ定義とデータを別々でexport/import方法を説明します

Drupalのモジュール（Bundle copy、 Taxonomy CSV import/export）でコンテンツの構成／定義をExport/Importします

モジュール（Bundle copy）でコンテンツの構成／定義を簡単に移行します（具体的にステップは省略）
タクソノミーのタームの構成（フィールドが追加など）が変わらなければ、モジュール（、Taxonomy CSV import/export）でタームリストデータをcsvファイルの出力することはできます
- 出力したCSVデータの別のサイトにインポートする場合、タクソノミーのボキャブラリーとタームIDが変わった可能性があります
- コンテンツのフィールドに「Term Reference」タイプのものがあれば、コンテンツ追加／編集ボタンをクリックすると、「HTTP ERROR 500」エラーが発生するかもしれないです
- 一番簡単な対応方法ではそのフィールドを一回削除して、再作成すればよいです（データインポートする前の段階）

Drupalのコンテンツ構成（フィールド）テーブルのデータをcsvフォーマットに出力します

現時点ではコンテンツのデータをcsvに出力するモジュールはあまり見当たらにです
コンテンツのフィールドをDB上各テーブルを見つけ出します
- コンテンツ（例：Article）のフィールドごとに一つのテールが存在しています
- Title ➡　nodeテーブルの「title」フィールド
- body ➡　field_data_bodyテーブルの「body_value」フィールド（またはbody_summaryなど）
- カスタムフィールド ➡　field_data_CUSTOM_FIELD_NAMEの「field_data_CUSTOM_FIELD_NAME_value」フィールド
これらのテーブルを「node」テーブルを中心してジョインして、新しいテーブルの書き込みます
- すべてのコンテンツは「node」テーブルを基本にしています
- 各フィールドのテーブルに「entity_id」がnodeテーブルの「nid」の関連付けキーとなります
- 全フィールドと同じフィールドの新しいテーブルを一つ作成します（例：new_table）
- 全フィールドをJOINしてデータを新しいテーブル（例：new_table）にコピーします
```
INSERT INTO new_table (title, body, CUSTOM_FIELD_NAME,   ・・・・・・)
SELECT 
   title,
   body.body_value,
   T1.field_data_CUSTOM_FIEDL_NAME_value,
  ・・・・・・
FROM node
   left join field_data_body body on nid = body.entity_id
   left join field_data_CUSTOM_FIELD_NAME  T1  on T1.entity_id = nid
  ・・・・・・
  
```
新しいテーブル（new_table）の内容をｃｓｖフォーマットに出力します

Drupalのモジュール（Feeds Import）でコンテンツｃｓｖデータをインポートします

モジュール（Feeds Import）がよく利用されるものなので、簡単にｃｓｖデータを確認コンテンツにインポートすることができます
Feeds Importの説明は省略します(Drupalのモジュール（Feeds）で手動でデータインポート時の必須設定 (199)、FeedsモジュールでEnityにデータインポート (34)などを参考にしてください)

シリーズ記事一覧

記事カテゴリ

タグ

モジュール（Feature）が開発ソース管理、コンテンツデータ移行などに利用されます

最初モジュール（Feature）が何に使うかはあまりわからなかったです（いろいろな説明がちゅ抽象的）。
実はDrupalの開発ソース管理（例：開発環境ー＞ステージん環境ー＞本番環境）、コンテンツデータの移行に使用されます

データ移行例：コンテンツデータ（Article）＋Viewsで作成したコンテンツ検索一覧画面

データ移行の簡単な例として、既存のコンテンツデータ（例：Article⇒記事）、Viewsで作成したコンテンツ一覧画面を移行します
コンテンツデータ移行に必須なモジュール：
- Feature
- Node Export （FeatureモジュールにサポートするNode export featuresサブモジュールを有効化）
Feature管理画面で必要なモジュール、モジュールの関連、コンテンツデータを選択して、一つのモジュールとして作成し、ダウンロードします
作成されたモジュール（tarファイル）を移行先で通常のモジュールインストールをして、有効化を行います。Feature管理画面で移行元の内容を適用、保存します
具体的な操作はビデオをご参考ください

FeatureがDurupalのすべての設定、構成の移行はできません

移行はモジュール単位で、構成は出力可能なものを中心にしています。以下は移行可能な部分
- Core ： Content Types、 Fields、 Menus、 Taxonomies、 Text formats、 Image styles、 User roles 、 permissions
- Contribute： Views、 CTools、 Context 、 Panels、 Rules 、 Contexts、 Display Suite
移行できない部分は、例：テーマ、コンテンツに挿入した画像などがあります
- コンテンツに含まるメディア（例：写真、ビデオ、ファイルなど）がローカル（sites/default/files）に保存したため、移行先の保存パス修正、およびメディアファイルのコピーが手動で行う必要があります

video

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ

注意点：Drupalのモジュール（Feeds）の設定が間違うと手動でデータインポートができなくなります

環境：Drupal7.54、Feeds7.x-3.0
やりたいこと：手動でデータをインポート（例：csvファイルからのインポートなど）
Feedの基本設定のところある二か所をチェックしないと手動でのインポートができない
- 添付するコンテンツタイプ：スタントアローンのフォームを使う
- 投稿時にインポート
- 初期としてはこの二つ設定を有効にしています
ちなみに、「投稿時にインポート」を無効の場合、バッチでデータインポートすることになります（バッチの設定が必要）
添付するコンテンツタイプ：「スタントアローンのフォームを使う」以外の選択肢を選択すると、インポート画面（ホーム » インポート）に当該インポーターはありません

手動でインポートできないときに画面上に「インポートされた項目はありません」が表示されます

「投稿時にインポート」オプションが無効の場合、手動でデータインポートはできません
インポートデータがあるにはかかわらず、画面上に「インポートされた項目はありません」として表示されます
バッチにインポートジョブを入れたメッセージはありません

記事カテゴリ

タグ

目的

Entity Typeデータにほかのデータ（例：ｃｓｖ、xmlなど）からのインポートを可能にする
Feedsの初期データ変換プロセッサーに「Entity Type」のものがなかった

解決の選択肢

Feed Importモジュールでのデータインポート
Feedsモジュールのカスタマイズをする

ここでの解決：Feedsのカスタマイズ

インストールされたモジュール
- Feeds : 7.x-2.0
- ECK : 7.x-2.0
- Entity API : 7.x-1.5
上記モジュールのインストールと有効化
ECKでインポートデータタイプとBundleを作成する
- 例：　データタイプ：「組織データ」、Bundle：「ｘｘｘの組織データ」
- 「組織データ」のプロパティ：title、uid、created、changedを使用する
- 「ｘｘｘの組織データ」のフィールド：「組織コード」、「正式組織名」をテキストフィールドで追加

Feedsの紹介

Feedsが三つの部分から構成される：Fetcher、Parser、Processor
- Fetcher：インポータデータの取得（例：File upload、external RSS Feedなど）
- Parser：インポートデータの解析方法の指定（csv、xls、xml、RSSなど）
- Processor：インポートデータの作成（Node、terms、usersなどのデータ作成）

FeedsにEntity Typeデータ変換プロセッサーに追加

PatchファイルをFeedsモジュールに当てる
Feedsのデータ変換プロセッサー設定画面にEntity Typeのデータ変換プロセッサー追加前後のイメージ

files

添付	サイズ
feeds_entity_processor-1033202-217.patch_.txt (16.03 KB)	16.03 KB

記事カテゴリ

タグ

エラー：モジュール(Twitter)をバージョンアップしてフロントページに開くと「EntityFieldQueryException」が発生

モジュール(Twitter)のバージョン：7.x-5.11 ⇒ 7.x-6.2 にアップデートしました（新モジュールから旧モジュールを上書き）

フロントページを開いてみたらエラーが発生し：

EntityFieldQueryException: エンティティー <em class="placeholder">twitter_account</em> にはベーステーブルがありません。 EntityFieldQuery->propertyQuery() (/virtual/drills/public_html/drupal7/includes/entity.inc ファイル　1271行).

画面にエラーしか表示されていないです

原因：Twitter7.x-5.11⇒7.x-6.2にアップデートする場合DBのテーブルが追加されたので、DB更新が必要

原因は比較的に単純的で、Twitter7.x-6.2（7.x-6.0以上になるとデータ構造が変わった）が7.x-5.11よりデータテーブルが追加されました
管理者権限でupdate.phpを実行してデータテーブルを追加します

シリーズ記事一覧

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ

やりたいこと：一つDrupalのソースで複数のサイト（複数のドメイン）を構築したいです

Drupalを用いて複数のサイト（ドメイン）を構築する場合、一つサイト（ドメイン）ごとに一つのDrupalソースで構築することがもちろん問題はありません
Drupalソースが分散すると、バージョンアップ、バグ管理などの作業が大変になります
当然一つのDrupalソースの元で複数のサイト（ドメイン）の構築が必要となります
- 一ドメイン ⇒ Drupalソース ⇒ 共有DB
- 一ドメイン ⇒ Drupalソース ⇒ 独立DB
Drupalでは複数のサイト（ドメイン）への対応をしています

sitesディレクトリの下にドメインごとの子ディレクトリを作成してマルティサイトを構築します

複数のドメイン名をDrupalのルートディレクトリに同期します（例：シンボリックリンクでドメイン名をディレクトリと同期します）
- 例： old-pine.net をDrupalのルートディレクトリにシンボリックリンクで同期します
Drupalのルートディレクトリの下に sites ディレクトリがあります。sitesの下に各メイン名に同期したいディレクトリを作成します
- 例：sites/pine を作成します
sites/sites.phpファイルでドメイン名をディレクトと同期設定を行います
- 例： 'old-pine.net' => 'pine' （書き方：ドメイン名 => ディレクトリ名）
```
 $sites = array(
    'old-pine.net' => 'pine',
 );
```
新規作成したディレクトの下にサイトのインストール設定ファイル(settings.php)の作成
- 例：sites/pine/settings.phpを作成します
- settings.phpの内容はsites/pine/default.settings.phpのコピーで良いです（サイト新規作成する場合）
追加したドメイン名でサイトをアクセスして、新規サイトができたことを確認します

記事カテゴリ

タグ

やりたいこと：レンタルサーバーで申請したドメイン名を特定なディレクトリに同期するシンボリックリンク作成したいです

レンタルサーバー（例：valueserver）で申請したドメイン名を特定なディレクトに同期するツールが提供されています
同期ツールを利用するのは便利だが、設定が誤ると同期先のディレクトリのファイルがすべて削除されてします危険があります
特に、この操作がよく行うことではなく、誤って設定する確率は実は高そうです（実際に設定を誤って、同期先のファイルが消されてしまう事項がありました）

安全のため、シンボリックリンク作成コマンドでディレクト同期をしたほうがよいです

シンボリックリンク作成：
- public_htmlディレクトリ（apacheではdocument root）に入ります
- コマンド： ln -s [ディレクト名] [ドメイン名] （例：ln -s drupal7 old-pine.net）
- コマンド： ls -l　で生成したシンボリックリンクを確認します（例： old-pine.net -> pine）
シンボリックリンクの削除
- コマンド：unlink [ドメイン名] (例：unlink old-pine.net)
- コマンド：ls -l でドメイン名の同期先が消えたことを確認します

安全のため、コマンド(rm)でシンボリックリンクを削除しないこと

シンボリックリンクを削除するのはコマンド(rm)できますが、誤って指定すると、同期先のディレクトリの内容を削除していまう危険があります
シンボリックリンクを削除するには、コマンド(unlink)を使用すべきです

記事カテゴリ

タグ

モジュール（Feature）が開発ソース管理、コンテンツデータ移行などに利用されます

最初モジュール（Feature）が何に使うかはあまりわからなかったです（いろいろな説明がちゅ抽象的）。
実はDrupalの開発ソース管理（例：開発環境ー＞ステージん環境ー＞本番環境）、コンテンツデータの移行に使用されます

データ移行例：コンテンツデータ（Article）＋Viewsで作成したコンテンツ検索一覧画面

データ移行の簡単な例として、既存のコンテンツデータ（例：Article⇒記事）、Viewsで作成したコンテンツ一覧画面を移行します
コンテンツデータ移行に必須なモジュール：
- Feature
- Node Export （FeatureモジュールにサポートするNode export featuresサブモジュールを有効化）
Feature管理画面で必要なモジュール、モジュールの関連、コンテンツデータを選択して、一つのモジュールとして作成し、ダウンロードします
作成されたモジュール（tarファイル）を移行先で通常のモジュールインストールをして、有効化を行います。Feature管理画面で移行元の内容を適用、保存します
具体的な操作はビデオをご参考ください

FeatureがDurupalのすべての設定、構成の移行はできません

移行はモジュール単位で、構成は出力可能なものを中心にしています。以下は移行可能な部分
- Core ： Content Types、 Fields、 Menus、 Taxonomies、 Text formats、 Image styles、 User roles 、 permissions
- Contribute： Views、 CTools、 Context 、 Panels、 Rules 、 Contexts、 Display Suite
移行できない部分は、例：テーマ、コンテンツに挿入した画像などがあります
- コンテンツに含まるメディア（例：写真、ビデオ、ファイルなど）がローカル（sites/default/files）に保存したため、移行先の保存パス修正、およびメディアファイルのコピーが手動で行う必要があります

video

記事カテゴリ

タグ

Drupalの部分的なコンテンツデータを別のDrualサイトに移行する場合そのコンテンツの構造定義とコンテンツCSVデータのエクスポート／インポートができます

背景：Drupal7.54
Drupalのサイト引っ越しなどでデータ移行の必要があります、以下の移行方法はよく利用されます。
- Drupalのモジュール（Feature）を用いてサイト間のデータ移行/開発管理を行います (162)
- 同じDrupalバージョンの単一サイトを複数サイト（ドメイン）の一つDrupalの共有ソースサイトへの移行チャレンジ (161)
ただし、部分的なコンテンツしか移行しない場合、上記方法では難しくなります
ここで、コンテンツ定義とデータを別々でexport/import方法を説明します

Drupalのモジュール（Bundle copy、 Taxonomy CSV import/export）でコンテンツの構成／定義をExport/Importします

モジュール（Bundle copy）でコンテンツの構成／定義を簡単に移行します（具体的にステップは省略）
タクソノミーのタームの構成（フィールドが追加など）が変わらなければ、モジュール（、Taxonomy CSV import/export）でタームリストデータをcsvファイルの出力することはできます
- 出力したCSVデータの別のサイトにインポートする場合、タクソノミーのボキャブラリーとタームIDが変わった可能性があります
- コンテンツのフィールドに「Term Reference」タイプのものがあれば、コンテンツ追加／編集ボタンをクリックすると、「HTTP ERROR 500」エラーが発生するかもしれないです
- 一番簡単な対応方法ではそのフィールドを一回削除して、再作成すればよいです（データインポートする前の段階）

Drupalのコンテンツ構成（フィールド）テーブルのデータをcsvフォーマットに出力します

現時点ではコンテンツのデータをcsvに出力するモジュールはあまり見当たらにです
コンテンツのフィールドをDB上各テーブルを見つけ出します
- コンテンツ（例：Article）のフィールドごとに一つのテールが存在しています
- Title ➡　nodeテーブルの「title」フィールド
- body ➡　field_data_bodyテーブルの「body_value」フィールド（またはbody_summaryなど）
- カスタムフィールド ➡　field_data_CUSTOM_FIELD_NAMEの「field_data_CUSTOM_FIELD_NAME_value」フィールド
これらのテーブルを「node」テーブルを中心してジョインして、新しいテーブルの書き込みます
- すべてのコンテンツは「node」テーブルを基本にしています
- 各フィールドのテーブルに「entity_id」がnodeテーブルの「nid」の関連付けキーとなります
- 全フィールドと同じフィールドの新しいテーブルを一つ作成します（例：new_table）
- 全フィールドをJOINしてデータを新しいテーブル（例：new_table）にコピーします
```
INSERT INTO new_table (title, body, CUSTOM_FIELD_NAME,   ・・・・・・)
SELECT 
   title,
   body.body_value,
   T1.field_data_CUSTOM_FIEDL_NAME_value,
  ・・・・・・
FROM node
   left join field_data_body body on nid = body.entity_id
   left join field_data_CUSTOM_FIELD_NAME  T1  on T1.entity_id = nid
  ・・・・・・
  
```
新しいテーブル（new_table）の内容をｃｓｖフォーマットに出力します

Drupalのモジュール（Feeds Import）でコンテンツｃｓｖデータをインポートします

モジュール（Feeds Import）がよく利用されるものなので、簡単にｃｓｖデータを確認コンテンツにインポートすることができます
Feeds Importの説明は省略します(Drupalのモジュール（Feeds）で手動でデータインポート時の必須設定 (199)、FeedsモジュールでEnityにデータインポート (34)などを参考にしてください)

シリーズ記事一覧

記事カテゴリ

タグ

モジュール（Feature）が開発ソース管理、コンテンツデータ移行などに利用されます

最初モジュール（Feature）が何に使うかはあまりわからなかったです（いろいろな説明がちゅ抽象的）。
実はDrupalの開発ソース管理（例：開発環境ー＞ステージん環境ー＞本番環境）、コンテンツデータの移行に使用されます

データ移行例：コンテンツデータ（Article）＋Viewsで作成したコンテンツ検索一覧画面

データ移行の簡単な例として、既存のコンテンツデータ（例：Article⇒記事）、Viewsで作成したコンテンツ一覧画面を移行します
コンテンツデータ移行に必須なモジュール：
- Feature
- Node Export （FeatureモジュールにサポートするNode export featuresサブモジュールを有効化）
Feature管理画面で必要なモジュール、モジュールの関連、コンテンツデータを選択して、一つのモジュールとして作成し、ダウンロードします
作成されたモジュール（tarファイル）を移行先で通常のモジュールインストールをして、有効化を行います。Feature管理画面で移行元の内容を適用、保存します
具体的な操作はビデオをご参考ください

FeatureがDurupalのすべての設定、構成の移行はできません

移行はモジュール単位で、構成は出力可能なものを中心にしています。以下は移行可能な部分
- Core ： Content Types、 Fields、 Menus、 Taxonomies、 Text formats、 Image styles、 User roles 、 permissions
- Contribute： Views、 CTools、 Context 、 Panels、 Rules 、 Contexts、 Display Suite
移行できない部分は、例：テーマ、コンテンツに挿入した画像などがあります
- コンテンツに含まるメディア（例：写真、ビデオ、ファイルなど）がローカル（sites/default/files）に保存したため、移行先の保存パス修正、およびメディアファイルのコピーが手動で行う必要があります

video

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ

注意点：Drupalのモジュール（Feeds）の設定が間違うと手動でデータインポートができなくなります

環境：Drupal7.54、Feeds7.x-3.0
やりたいこと：手動でデータをインポート（例：csvファイルからのインポートなど）
Feedの基本設定のところある二か所をチェックしないと手動でのインポートができない
- 添付するコンテンツタイプ：スタントアローンのフォームを使う
- 投稿時にインポート
- 初期としてはこの二つ設定を有効にしています
ちなみに、「投稿時にインポート」を無効の場合、バッチでデータインポートすることになります（バッチの設定が必要）
添付するコンテンツタイプ：「スタントアローンのフォームを使う」以外の選択肢を選択すると、インポート画面（ホーム » インポート）に当該インポーターはありません

手動でインポートできないときに画面上に「インポートされた項目はありません」が表示されます

「投稿時にインポート」オプションが無効の場合、手動でデータインポートはできません
インポートデータがあるにはかかわらず、画面上に「インポートされた項目はありません」として表示されます
バッチにインポートジョブを入れたメッセージはありません

記事カテゴリ

タグ

目的

Entity Typeデータにほかのデータ（例：ｃｓｖ、xmlなど）からのインポートを可能にする
Feedsの初期データ変換プロセッサーに「Entity Type」のものがなかった

解決の選択肢

Feed Importモジュールでのデータインポート
Feedsモジュールのカスタマイズをする

ここでの解決：Feedsのカスタマイズ

インストールされたモジュール
- Feeds : 7.x-2.0
- ECK : 7.x-2.0
- Entity API : 7.x-1.5
上記モジュールのインストールと有効化
ECKでインポートデータタイプとBundleを作成する
- 例：　データタイプ：「組織データ」、Bundle：「ｘｘｘの組織データ」
- 「組織データ」のプロパティ：title、uid、created、changedを使用する
- 「ｘｘｘの組織データ」のフィールド：「組織コード」、「正式組織名」をテキストフィールドで追加

Feedsの紹介

Feedsが三つの部分から構成される：Fetcher、Parser、Processor
- Fetcher：インポータデータの取得（例：File upload、external RSS Feedなど）
- Parser：インポートデータの解析方法の指定（csv、xls、xml、RSSなど）
- Processor：インポートデータの作成（Node、terms、usersなどのデータ作成）

FeedsにEntity Typeデータ変換プロセッサーに追加

PatchファイルをFeedsモジュールに当てる
Feedsのデータ変換プロセッサー設定画面にEntity Typeのデータ変換プロセッサー追加前後のイメージ

files

添付	サイズ
feeds_entity_processor-1033202-217.patch_.txt (16.03 KB)	16.03 KB

記事カテゴリ

タグ

エラー：モジュール(Twitter)をバージョンアップしてフロントページに開くと「EntityFieldQueryException」が発生

モジュール(Twitter)のバージョン：7.x-5.11 ⇒ 7.x-6.2 にアップデートしました（新モジュールから旧モジュールを上書き）

フロントページを開いてみたらエラーが発生し：

EntityFieldQueryException: エンティティー <em class="placeholder">twitter_account</em> にはベーステーブルがありません。 EntityFieldQuery->propertyQuery() (/virtual/drills/public_html/drupal7/includes/entity.inc ファイル　1271行).

画面にエラーしか表示されていないです

原因：Twitter7.x-5.11⇒7.x-6.2にアップデートする場合DBのテーブルが追加されたので、DB更新が必要

原因は比較的に単純的で、Twitter7.x-6.2（7.x-6.0以上になるとデータ構造が変わった）が7.x-5.11よりデータテーブルが追加されました
管理者権限でupdate.phpを実行してデータテーブルを追加します

シリーズ記事一覧

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ

やりたいこと：一つDrupalのソースで複数のサイト（複数のドメイン）を構築したいです

Drupalを用いて複数のサイト（ドメイン）を構築する場合、一つサイト（ドメイン）ごとに一つのDrupalソースで構築することがもちろん問題はありません
Drupalソースが分散すると、バージョンアップ、バグ管理などの作業が大変になります
当然一つのDrupalソースの元で複数のサイト（ドメイン）の構築が必要となります
- 一ドメイン ⇒ Drupalソース ⇒ 共有DB
- 一ドメイン ⇒ Drupalソース ⇒ 独立DB
Drupalでは複数のサイト（ドメイン）への対応をしています

sitesディレクトリの下にドメインごとの子ディレクトリを作成してマルティサイトを構築します

複数のドメイン名をDrupalのルートディレクトリに同期します（例：シンボリックリンクでドメイン名をディレクトリと同期します）
- 例： old-pine.net をDrupalのルートディレクトリにシンボリックリンクで同期します
Drupalのルートディレクトリの下に sites ディレクトリがあります。sitesの下に各メイン名に同期したいディレクトリを作成します
- 例：sites/pine を作成します
sites/sites.phpファイルでドメイン名をディレクトと同期設定を行います
- 例： 'old-pine.net' => 'pine' （書き方：ドメイン名 => ディレクトリ名）
```
 $sites = array(
    'old-pine.net' => 'pine',
 );
```
新規作成したディレクトの下にサイトのインストール設定ファイル(settings.php)の作成
- 例：sites/pine/settings.phpを作成します
- settings.phpの内容はsites/pine/default.settings.phpのコピーで良いです（サイト新規作成する場合）
追加したドメイン名でサイトをアクセスして、新規サイトができたことを確認します

記事カテゴリ

タグ

やりたいこと：レンタルサーバーで申請したドメイン名を特定なディレクトリに同期するシンボリックリンク作成したいです

レンタルサーバー（例：valueserver）で申請したドメイン名を特定なディレクトに同期するツールが提供されています
同期ツールを利用するのは便利だが、設定が誤ると同期先のディレクトリのファイルがすべて削除されてします危険があります
特に、この操作がよく行うことではなく、誤って設定する確率は実は高そうです（実際に設定を誤って、同期先のファイルが消されてしまう事項がありました）

安全のため、シンボリックリンク作成コマンドでディレクト同期をしたほうがよいです

シンボリックリンク作成：
- public_htmlディレクトリ（apacheではdocument root）に入ります
- コマンド： ln -s [ディレクト名] [ドメイン名] （例：ln -s drupal7 old-pine.net）
- コマンド： ls -l　で生成したシンボリックリンクを確認します（例： old-pine.net -> pine）
シンボリックリンクの削除
- コマンド：unlink [ドメイン名] (例：unlink old-pine.net)
- コマンド：ls -l でドメイン名の同期先が消えたことを確認します

安全のため、コマンド(rm)でシンボリックリンクを削除しないこと

シンボリックリンクを削除するのはコマンド(rm)できますが、誤って指定すると、同期先のディレクトリの内容を削除していまう危険があります
シンボリックリンクを削除するには、コマンド(unlink)を使用すべきです

記事カテゴリ

タグ

モジュール（Feature）が開発ソース管理、コンテンツデータ移行などに利用されます

最初モジュール（Feature）が何に使うかはあまりわからなかったです（いろいろな説明がちゅ抽象的）。
実はDrupalの開発ソース管理（例：開発環境ー＞ステージん環境ー＞本番環境）、コンテンツデータの移行に使用されます

データ移行例：コンテンツデータ（Article）＋Viewsで作成したコンテンツ検索一覧画面

データ移行の簡単な例として、既存のコンテンツデータ（例：Article⇒記事）、Viewsで作成したコンテンツ一覧画面を移行します
コンテンツデータ移行に必須なモジュール：
- Feature
- Node Export （FeatureモジュールにサポートするNode export featuresサブモジュールを有効化）
Feature管理画面で必要なモジュール、モジュールの関連、コンテンツデータを選択して、一つのモジュールとして作成し、ダウンロードします
作成されたモジュール（tarファイル）を移行先で通常のモジュールインストールをして、有効化を行います。Feature管理画面で移行元の内容を適用、保存します
具体的な操作はビデオをご参考ください

FeatureがDurupalのすべての設定、構成の移行はできません

移行はモジュール単位で、構成は出力可能なものを中心にしています。以下は移行可能な部分
- Core ： Content Types、 Fields、 Menus、 Taxonomies、 Text formats、 Image styles、 User roles 、 permissions
- Contribute： Views、 CTools、 Context 、 Panels、 Rules 、 Contexts、 Display Suite
移行できない部分は、例：テーマ、コンテンツに挿入した画像などがあります
- コンテンツに含まるメディア（例：写真、ビデオ、ファイルなど）がローカル（sites/default/files）に保存したため、移行先の保存パス修正、およびメディアファイルのコピーが手動で行う必要があります

video

記事カテゴリ

タグ

Drupalの部分的なコンテンツデータを別のDrualサイトに移行する場合そのコンテンツの構造定義とコンテンツCSVデータのエクスポート／インポートができます

背景：Drupal7.54
Drupalのサイト引っ越しなどでデータ移行の必要があります、以下の移行方法はよく利用されます。
- Drupalのモジュール（Feature）を用いてサイト間のデータ移行/開発管理を行います (162)
- 同じDrupalバージョンの単一サイトを複数サイト（ドメイン）の一つDrupalの共有ソースサイトへの移行チャレンジ (161)
ただし、部分的なコンテンツしか移行しない場合、上記方法では難しくなります
ここで、コンテンツ定義とデータを別々でexport/import方法を説明します

Drupalのモジュール（Bundle copy、 Taxonomy CSV import/export）でコンテンツの構成／定義をExport/Importします

モジュール（Bundle copy）でコンテンツの構成／定義を簡単に移行します（具体的にステップは省略）
タクソノミーのタームの構成（フィールドが追加など）が変わらなければ、モジュール（、Taxonomy CSV import/export）でタームリストデータをcsvファイルの出力することはできます
- 出力したCSVデータの別のサイトにインポートする場合、タクソノミーのボキャブラリーとタームIDが変わった可能性があります
- コンテンツのフィールドに「Term Reference」タイプのものがあれば、コンテンツ追加／編集ボタンをクリックすると、「HTTP ERROR 500」エラーが発生するかもしれないです
- 一番簡単な対応方法ではそのフィールドを一回削除して、再作成すればよいです（データインポートする前の段階）

Drupalのコンテンツ構成（フィールド）テーブルのデータをcsvフォーマットに出力します

現時点ではコンテンツのデータをcsvに出力するモジュールはあまり見当たらにです
コンテンツのフィールドをDB上各テーブルを見つけ出します
- コンテンツ（例：Article）のフィールドごとに一つのテールが存在しています
- Title ➡　nodeテーブルの「title」フィールド
- body ➡　field_data_bodyテーブルの「body_value」フィールド（またはbody_summaryなど）
- カスタムフィールド ➡　field_data_CUSTOM_FIELD_NAMEの「field_data_CUSTOM_FIELD_NAME_value」フィールド
これらのテーブルを「node」テーブルを中心してジョインして、新しいテーブルの書き込みます
- すべてのコンテンツは「node」テーブルを基本にしています
- 各フィールドのテーブルに「entity_id」がnodeテーブルの「nid」の関連付けキーとなります
- 全フィールドと同じフィールドの新しいテーブルを一つ作成します（例：new_table）
- 全フィールドをJOINしてデータを新しいテーブル（例：new_table）にコピーします
```
INSERT INTO new_table (title, body, CUSTOM_FIELD_NAME,   ・・・・・・)
SELECT 
   title,
   body.body_value,
   T1.field_data_CUSTOM_FIEDL_NAME_value,
  ・・・・・・
FROM node
   left join field_data_body body on nid = body.entity_id
   left join field_data_CUSTOM_FIELD_NAME  T1  on T1.entity_id = nid
  ・・・・・・
  
```
新しいテーブル（new_table）の内容をｃｓｖフォーマットに出力します

Drupalのモジュール（Feeds Import）でコンテンツｃｓｖデータをインポートします

モジュール（Feeds Import）がよく利用されるものなので、簡単にｃｓｖデータを確認コンテンツにインポートすることができます
Feeds Importの説明は省略します(Drupalのモジュール（Feeds）で手動でデータインポート時の必須設定 (199)、FeedsモジュールでEnityにデータインポート (34)などを参考にしてください)

シリーズ記事一覧

記事カテゴリ

タグ

モジュール（Feature）が開発ソース管理、コンテンツデータ移行などに利用されます

最初モジュール（Feature）が何に使うかはあまりわからなかったです（いろいろな説明がちゅ抽象的）。
実はDrupalの開発ソース管理（例：開発環境ー＞ステージん環境ー＞本番環境）、コンテンツデータの移行に使用されます

データ移行例：コンテンツデータ（Article）＋Viewsで作成したコンテンツ検索一覧画面

データ移行の簡単な例として、既存のコンテンツデータ（例：Article⇒記事）、Viewsで作成したコンテンツ一覧画面を移行します
コンテンツデータ移行に必須なモジュール：
- Feature
- Node Export （FeatureモジュールにサポートするNode export featuresサブモジュールを有効化）
Feature管理画面で必要なモジュール、モジュールの関連、コンテンツデータを選択して、一つのモジュールとして作成し、ダウンロードします
作成されたモジュール（tarファイル）を移行先で通常のモジュールインストールをして、有効化を行います。Feature管理画面で移行元の内容を適用、保存します
具体的な操作はビデオをご参考ください

FeatureがDurupalのすべての設定、構成の移行はできません

移行はモジュール単位で、構成は出力可能なものを中心にしています。以下は移行可能な部分
- Core ： Content Types、 Fields、 Menus、 Taxonomies、 Text formats、 Image styles、 User roles 、 permissions
- Contribute： Views、 CTools、 Context 、 Panels、 Rules 、 Contexts、 Display Suite
移行できない部分は、例：テーマ、コンテンツに挿入した画像などがあります
- コンテンツに含まるメディア（例：写真、ビデオ、ファイルなど）がローカル（sites/default/files）に保存したため、移行先の保存パス修正、およびメディアファイルのコピーが手動で行う必要があります

video

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ

注意点：Drupalのモジュール（Feeds）の設定が間違うと手動でデータインポートができなくなります

環境：Drupal7.54、Feeds7.x-3.0
やりたいこと：手動でデータをインポート（例：csvファイルからのインポートなど）
Feedの基本設定のところある二か所をチェックしないと手動でのインポートができない
- 添付するコンテンツタイプ：スタントアローンのフォームを使う
- 投稿時にインポート
- 初期としてはこの二つ設定を有効にしています
ちなみに、「投稿時にインポート」を無効の場合、バッチでデータインポートすることになります（バッチの設定が必要）
添付するコンテンツタイプ：「スタントアローンのフォームを使う」以外の選択肢を選択すると、インポート画面（ホーム » インポート）に当該インポーターはありません

手動でインポートできないときに画面上に「インポートされた項目はありません」が表示されます

「投稿時にインポート」オプションが無効の場合、手動でデータインポートはできません
インポートデータがあるにはかかわらず、画面上に「インポートされた項目はありません」として表示されます
バッチにインポートジョブを入れたメッセージはありません

記事カテゴリ

タグ

目的

Entity Typeデータにほかのデータ（例：ｃｓｖ、xmlなど）からのインポートを可能にする
Feedsの初期データ変換プロセッサーに「Entity Type」のものがなかった

解決の選択肢

Feed Importモジュールでのデータインポート
Feedsモジュールのカスタマイズをする

ここでの解決：Feedsのカスタマイズ

インストールされたモジュール
- Feeds : 7.x-2.0
- ECK : 7.x-2.0
- Entity API : 7.x-1.5
上記モジュールのインストールと有効化
ECKでインポートデータタイプとBundleを作成する
- 例：　データタイプ：「組織データ」、Bundle：「ｘｘｘの組織データ」
- 「組織データ」のプロパティ：title、uid、created、changedを使用する
- 「ｘｘｘの組織データ」のフィールド：「組織コード」、「正式組織名」をテキストフィールドで追加

Feedsの紹介

Feedsが三つの部分から構成される：Fetcher、Parser、Processor
- Fetcher：インポータデータの取得（例：File upload、external RSS Feedなど）
- Parser：インポートデータの解析方法の指定（csv、xls、xml、RSSなど）
- Processor：インポートデータの作成（Node、terms、usersなどのデータ作成）

FeedsにEntity Typeデータ変換プロセッサーに追加

PatchファイルをFeedsモジュールに当てる
Feedsのデータ変換プロセッサー設定画面にEntity Typeのデータ変換プロセッサー追加前後のイメージ

files

添付	サイズ
feeds_entity_processor-1033202-217.patch_.txt (16.03 KB)	16.03 KB

記事カテゴリ

タグ

エラー：モジュール(Twitter)をバージョンアップしてフロントページに開くと「EntityFieldQueryException」が発生

モジュール(Twitter)のバージョン：7.x-5.11 ⇒ 7.x-6.2 にアップデートしました（新モジュールから旧モジュールを上書き）

フロントページを開いてみたらエラーが発生し：

EntityFieldQueryException: エンティティー <em class="placeholder">twitter_account</em> にはベーステーブルがありません。 EntityFieldQuery->propertyQuery() (/virtual/drills/public_html/drupal7/includes/entity.inc ファイル　1271行).

画面にエラーしか表示されていないです

原因：Twitter7.x-5.11⇒7.x-6.2にアップデートする場合DBのテーブルが追加されたので、DB更新が必要

原因は比較的に単純的で、Twitter7.x-6.2（7.x-6.0以上になるとデータ構造が変わった）が7.x-5.11よりデータテーブルが追加されました
管理者権限でupdate.phpを実行してデータテーブルを追加します

シリーズ記事一覧

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ

やりたいこと：一つDrupalのソースで複数のサイト（複数のドメイン）を構築したいです

Drupalを用いて複数のサイト（ドメイン）を構築する場合、一つサイト（ドメイン）ごとに一つのDrupalソースで構築することがもちろん問題はありません
Drupalソースが分散すると、バージョンアップ、バグ管理などの作業が大変になります
当然一つのDrupalソースの元で複数のサイト（ドメイン）の構築が必要となります
- 一ドメイン ⇒ Drupalソース ⇒ 共有DB
- 一ドメイン ⇒ Drupalソース ⇒ 独立DB
Drupalでは複数のサイト（ドメイン）への対応をしています

sitesディレクトリの下にドメインごとの子ディレクトリを作成してマルティサイトを構築します

複数のドメイン名をDrupalのルートディレクトリに同期します（例：シンボリックリンクでドメイン名をディレクトリと同期します）
- 例： old-pine.net をDrupalのルートディレクトリにシンボリックリンクで同期します
Drupalのルートディレクトリの下に sites ディレクトリがあります。sitesの下に各メイン名に同期したいディレクトリを作成します
- 例：sites/pine を作成します
sites/sites.phpファイルでドメイン名をディレクトと同期設定を行います
- 例： 'old-pine.net' => 'pine' （書き方：ドメイン名 => ディレクトリ名）
```
 $sites = array(
    'old-pine.net' => 'pine',
 );
```
新規作成したディレクトの下にサイトのインストール設定ファイル(settings.php)の作成
- 例：sites/pine/settings.phpを作成します
- settings.phpの内容はsites/pine/default.settings.phpのコピーで良いです（サイト新規作成する場合）
追加したドメイン名でサイトをアクセスして、新規サイトができたことを確認します

記事カテゴリ

タグ

やりたいこと：レンタルサーバーで申請したドメイン名を特定なディレクトリに同期するシンボリックリンク作成したいです

レンタルサーバー（例：valueserver）で申請したドメイン名を特定なディレクトに同期するツールが提供されています
同期ツールを利用するのは便利だが、設定が誤ると同期先のディレクトリのファイルがすべて削除されてします危険があります
特に、この操作がよく行うことではなく、誤って設定する確率は実は高そうです（実際に設定を誤って、同期先のファイルが消されてしまう事項がありました）

安全のため、シンボリックリンク作成コマンドでディレクト同期をしたほうがよいです

シンボリックリンク作成：
- public_htmlディレクトリ（apacheではdocument root）に入ります
- コマンド： ln -s [ディレクト名] [ドメイン名] （例：ln -s drupal7 old-pine.net）
- コマンド： ls -l　で生成したシンボリックリンクを確認します（例： old-pine.net -> pine）
シンボリックリンクの削除
- コマンド：unlink [ドメイン名] (例：unlink old-pine.net)
- コマンド：ls -l でドメイン名の同期先が消えたことを確認します

安全のため、コマンド(rm)でシンボリックリンクを削除しないこと

シンボリックリンクを削除するのはコマンド(rm)できますが、誤って指定すると、同期先のディレクトリの内容を削除していまう危険があります
シンボリックリンクを削除するには、コマンド(unlink)を使用すべきです

記事カテゴリ

タグ

モジュール（Feature）が開発ソース管理、コンテンツデータ移行などに利用されます

最初モジュール（Feature）が何に使うかはあまりわからなかったです（いろいろな説明がちゅ抽象的）。
実はDrupalの開発ソース管理（例：開発環境ー＞ステージん環境ー＞本番環境）、コンテンツデータの移行に使用されます

データ移行例：コンテンツデータ（Article）＋Viewsで作成したコンテンツ検索一覧画面

データ移行の簡単な例として、既存のコンテンツデータ（例：Article⇒記事）、Viewsで作成したコンテンツ一覧画面を移行します
コンテンツデータ移行に必須なモジュール：
- Feature
- Node Export （FeatureモジュールにサポートするNode export featuresサブモジュールを有効化）
Feature管理画面で必要なモジュール、モジュールの関連、コンテンツデータを選択して、一つのモジュールとして作成し、ダウンロードします
作成されたモジュール（tarファイル）を移行先で通常のモジュールインストールをして、有効化を行います。Feature管理画面で移行元の内容を適用、保存します
具体的な操作はビデオをご参考ください

FeatureがDurupalのすべての設定、構成の移行はできません

移行はモジュール単位で、構成は出力可能なものを中心にしています。以下は移行可能な部分
- Core ： Content Types、 Fields、 Menus、 Taxonomies、 Text formats、 Image styles、 User roles 、 permissions
- Contribute： Views、 CTools、 Context 、 Panels、 Rules 、 Contexts、 Display Suite
移行できない部分は、例：テーマ、コンテンツに挿入した画像などがあります
- コンテンツに含まるメディア（例：写真、ビデオ、ファイルなど）がローカル（sites/default/files）に保存したため、移行先の保存パス修正、およびメディアファイルのコピーが手動で行う必要があります

video

記事カテゴリ

タグ

Drupalの部分的なコンテンツデータを別のDrualサイトに移行する場合そのコンテンツの構造定義とコンテンツCSVデータのエクスポート／インポートができます

背景：Drupal7.54
Drupalのサイト引っ越しなどでデータ移行の必要があります、以下の移行方法はよく利用されます。
- Drupalのモジュール（Feature）を用いてサイト間のデータ移行/開発管理を行います (162)
- 同じDrupalバージョンの単一サイトを複数サイト（ドメイン）の一つDrupalの共有ソースサイトへの移行チャレンジ (161)
ただし、部分的なコンテンツしか移行しない場合、上記方法では難しくなります
ここで、コンテンツ定義とデータを別々でexport/import方法を説明します

Drupalのモジュール（Bundle copy、 Taxonomy CSV import/export）でコンテンツの構成／定義をExport/Importします

モジュール（Bundle copy）でコンテンツの構成／定義を簡単に移行します（具体的にステップは省略）
タクソノミーのタームの構成（フィールドが追加など）が変わらなければ、モジュール（、Taxonomy CSV import/export）でタームリストデータをcsvファイルの出力することはできます
- 出力したCSVデータの別のサイトにインポートする場合、タクソノミーのボキャブラリーとタームIDが変わった可能性があります
- コンテンツのフィールドに「Term Reference」タイプのものがあれば、コンテンツ追加／編集ボタンをクリックすると、「HTTP ERROR 500」エラーが発生するかもしれないです
- 一番簡単な対応方法ではそのフィールドを一回削除して、再作成すればよいです（データインポートする前の段階）

Drupalのコンテンツ構成（フィールド）テーブルのデータをcsvフォーマットに出力します

現時点ではコンテンツのデータをcsvに出力するモジュールはあまり見当たらにです
コンテンツのフィールドをDB上各テーブルを見つけ出します
- コンテンツ（例：Article）のフィールドごとに一つのテールが存在しています
- Title ➡　nodeテーブルの「title」フィールド
- body ➡　field_data_bodyテーブルの「body_value」フィールド（またはbody_summaryなど）
- カスタムフィールド ➡　field_data_CUSTOM_FIELD_NAMEの「field_data_CUSTOM_FIELD_NAME_value」フィールド
これらのテーブルを「node」テーブルを中心してジョインして、新しいテーブルの書き込みます
- すべてのコンテンツは「node」テーブルを基本にしています
- 各フィールドのテーブルに「entity_id」がnodeテーブルの「nid」の関連付けキーとなります
- 全フィールドと同じフィールドの新しいテーブルを一つ作成します（例：new_table）
- 全フィールドをJOINしてデータを新しいテーブル（例：new_table）にコピーします
```
INSERT INTO new_table (title, body, CUSTOM_FIELD_NAME,   ・・・・・・)
SELECT 
   title,
   body.body_value,
   T1.field_data_CUSTOM_FIEDL_NAME_value,
  ・・・・・・
FROM node
   left join field_data_body body on nid = body.entity_id
   left join field_data_CUSTOM_FIELD_NAME  T1  on T1.entity_id = nid
  ・・・・・・
  
```
新しいテーブル（new_table）の内容をｃｓｖフォーマットに出力します

Drupalのモジュール（Feeds Import）でコンテンツｃｓｖデータをインポートします

モジュール（Feeds Import）がよく利用されるものなので、簡単にｃｓｖデータを確認コンテンツにインポートすることができます
Feeds Importの説明は省略します(Drupalのモジュール（Feeds）で手動でデータインポート時の必須設定 (199)、FeedsモジュールでEnityにデータインポート (34)などを参考にしてください)

シリーズ記事一覧

記事カテゴリ

タグ

モジュール（Feature）が開発ソース管理、コンテンツデータ移行などに利用されます

最初モジュール（Feature）が何に使うかはあまりわからなかったです（いろいろな説明がちゅ抽象的）。
実はDrupalの開発ソース管理（例：開発環境ー＞ステージん環境ー＞本番環境）、コンテンツデータの移行に使用されます

データ移行例：コンテンツデータ（Article）＋Viewsで作成したコンテンツ検索一覧画面

データ移行の簡単な例として、既存のコンテンツデータ（例：Article⇒記事）、Viewsで作成したコンテンツ一覧画面を移行します
コンテンツデータ移行に必須なモジュール：
- Feature
- Node Export （FeatureモジュールにサポートするNode export featuresサブモジュールを有効化）
Feature管理画面で必要なモジュール、モジュールの関連、コンテンツデータを選択して、一つのモジュールとして作成し、ダウンロードします
作成されたモジュール（tarファイル）を移行先で通常のモジュールインストールをして、有効化を行います。Feature管理画面で移行元の内容を適用、保存します
具体的な操作はビデオをご参考ください

FeatureがDurupalのすべての設定、構成の移行はできません

移行はモジュール単位で、構成は出力可能なものを中心にしています。以下は移行可能な部分
- Core ： Content Types、 Fields、 Menus、 Taxonomies、 Text formats、 Image styles、 User roles 、 permissions
- Contribute： Views、 CTools、 Context 、 Panels、 Rules 、 Contexts、 Display Suite
移行できない部分は、例：テーマ、コンテンツに挿入した画像などがあります
- コンテンツに含まるメディア（例：写真、ビデオ、ファイルなど）がローカル（sites/default/files）に保存したため、移行先の保存パス修正、およびメディアファイルのコピーが手動で行う必要があります

video

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ

注意点：Drupalのモジュール（Feeds）の設定が間違うと手動でデータインポートができなくなります

環境：Drupal7.54、Feeds7.x-3.0
やりたいこと：手動でデータをインポート（例：csvファイルからのインポートなど）
Feedの基本設定のところある二か所をチェックしないと手動でのインポートができない
- 添付するコンテンツタイプ：スタントアローンのフォームを使う
- 投稿時にインポート
- 初期としてはこの二つ設定を有効にしています
ちなみに、「投稿時にインポート」を無効の場合、バッチでデータインポートすることになります（バッチの設定が必要）
添付するコンテンツタイプ：「スタントアローンのフォームを使う」以外の選択肢を選択すると、インポート画面（ホーム » インポート）に当該インポーターはありません

手動でインポートできないときに画面上に「インポートされた項目はありません」が表示されます

「投稿時にインポート」オプションが無効の場合、手動でデータインポートはできません
インポートデータがあるにはかかわらず、画面上に「インポートされた項目はありません」として表示されます
バッチにインポートジョブを入れたメッセージはありません

記事カテゴリ

タグ

目的

Entity Typeデータにほかのデータ（例：ｃｓｖ、xmlなど）からのインポートを可能にする
Feedsの初期データ変換プロセッサーに「Entity Type」のものがなかった

解決の選択肢

Feed Importモジュールでのデータインポート
Feedsモジュールのカスタマイズをする

ここでの解決：Feedsのカスタマイズ

インストールされたモジュール
- Feeds : 7.x-2.0
- ECK : 7.x-2.0
- Entity API : 7.x-1.5
上記モジュールのインストールと有効化
ECKでインポートデータタイプとBundleを作成する
- 例：　データタイプ：「組織データ」、Bundle：「ｘｘｘの組織データ」
- 「組織データ」のプロパティ：title、uid、created、changedを使用する
- 「ｘｘｘの組織データ」のフィールド：「組織コード」、「正式組織名」をテキストフィールドで追加

Feedsの紹介

Feedsが三つの部分から構成される：Fetcher、Parser、Processor
- Fetcher：インポータデータの取得（例：File upload、external RSS Feedなど）
- Parser：インポートデータの解析方法の指定（csv、xls、xml、RSSなど）
- Processor：インポートデータの作成（Node、terms、usersなどのデータ作成）

FeedsにEntity Typeデータ変換プロセッサーに追加

PatchファイルをFeedsモジュールに当てる
Feedsのデータ変換プロセッサー設定画面にEntity Typeのデータ変換プロセッサー追加前後のイメージ

files

添付	サイズ
feeds_entity_processor-1033202-217.patch_.txt (16.03 KB)	16.03 KB

記事カテゴリ

タグ

エラー：モジュール(Twitter)をバージョンアップしてフロントページに開くと「EntityFieldQueryException」が発生

モジュール(Twitter)のバージョン：7.x-5.11 ⇒ 7.x-6.2 にアップデートしました（新モジュールから旧モジュールを上書き）

フロントページを開いてみたらエラーが発生し：

EntityFieldQueryException: エンティティー <em class="placeholder">twitter_account</em> にはベーステーブルがありません。 EntityFieldQuery->propertyQuery() (/virtual/drills/public_html/drupal7/includes/entity.inc ファイル　1271行).

画面にエラーしか表示されていないです

原因：Twitter7.x-5.11⇒7.x-6.2にアップデートする場合DBのテーブルが追加されたので、DB更新が必要

原因は比較的に単純的で、Twitter7.x-6.2（7.x-6.0以上になるとデータ構造が変わった）が7.x-5.11よりデータテーブルが追加されました
管理者権限でupdate.phpを実行してデータテーブルを追加します

シリーズ記事一覧

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ

やりたいこと：一つDrupalのソースで複数のサイト（複数のドメイン）を構築したいです

Drupalを用いて複数のサイト（ドメイン）を構築する場合、一つサイト（ドメイン）ごとに一つのDrupalソースで構築することがもちろん問題はありません
Drupalソースが分散すると、バージョンアップ、バグ管理などの作業が大変になります
当然一つのDrupalソースの元で複数のサイト（ドメイン）の構築が必要となります
- 一ドメイン ⇒ Drupalソース ⇒ 共有DB
- 一ドメイン ⇒ Drupalソース ⇒ 独立DB
Drupalでは複数のサイト（ドメイン）への対応をしています

sitesディレクトリの下にドメインごとの子ディレクトリを作成してマルティサイトを構築します

複数のドメイン名をDrupalのルートディレクトリに同期します（例：シンボリックリンクでドメイン名をディレクトリと同期します）
- 例： old-pine.net をDrupalのルートディレクトリにシンボリックリンクで同期します
Drupalのルートディレクトリの下に sites ディレクトリがあります。sitesの下に各メイン名に同期したいディレクトリを作成します
- 例：sites/pine を作成します
sites/sites.phpファイルでドメイン名をディレクトと同期設定を行います
- 例： 'old-pine.net' => 'pine' （書き方：ドメイン名 => ディレクトリ名）
```
 $sites = array(
    'old-pine.net' => 'pine',
 );
```
新規作成したディレクトの下にサイトのインストール設定ファイル(settings.php)の作成
- 例：sites/pine/settings.phpを作成します
- settings.phpの内容はsites/pine/default.settings.phpのコピーで良いです（サイト新規作成する場合）
追加したドメイン名でサイトをアクセスして、新規サイトができたことを確認します

記事カテゴリ

タグ

やりたいこと：レンタルサーバーで申請したドメイン名を特定なディレクトリに同期するシンボリックリンク作成したいです

レンタルサーバー（例：valueserver）で申請したドメイン名を特定なディレクトに同期するツールが提供されています
同期ツールを利用するのは便利だが、設定が誤ると同期先のディレクトリのファイルがすべて削除されてします危険があります
特に、この操作がよく行うことではなく、誤って設定する確率は実は高そうです（実際に設定を誤って、同期先のファイルが消されてしまう事項がありました）

安全のため、シンボリックリンク作成コマンドでディレクト同期をしたほうがよいです

シンボリックリンク作成：
- public_htmlディレクトリ（apacheではdocument root）に入ります
- コマンド： ln -s [ディレクト名] [ドメイン名] （例：ln -s drupal7 old-pine.net）
- コマンド： ls -l　で生成したシンボリックリンクを確認します（例： old-pine.net -> pine）
シンボリックリンクの削除
- コマンド：unlink [ドメイン名] (例：unlink old-pine.net)
- コマンド：ls -l でドメイン名の同期先が消えたことを確認します

安全のため、コマンド(rm)でシンボリックリンクを削除しないこと

シンボリックリンクを削除するのはコマンド(rm)できますが、誤って指定すると、同期先のディレクトリの内容を削除していまう危険があります
シンボリックリンクを削除するには、コマンド(unlink)を使用すべきです

記事カテゴリ

タグ

モジュール（Feature）が開発ソース管理、コンテンツデータ移行などに利用されます

最初モジュール（Feature）が何に使うかはあまりわからなかったです（いろいろな説明がちゅ抽象的）。
実はDrupalの開発ソース管理（例：開発環境ー＞ステージん環境ー＞本番環境）、コンテンツデータの移行に使用されます

データ移行例：コンテンツデータ（Article）＋Viewsで作成したコンテンツ検索一覧画面

データ移行の簡単な例として、既存のコンテンツデータ（例：Article⇒記事）、Viewsで作成したコンテンツ一覧画面を移行します
コンテンツデータ移行に必須なモジュール：
- Feature
- Node Export （FeatureモジュールにサポートするNode export featuresサブモジュールを有効化）
Feature管理画面で必要なモジュール、モジュールの関連、コンテンツデータを選択して、一つのモジュールとして作成し、ダウンロードします
作成されたモジュール（tarファイル）を移行先で通常のモジュールインストールをして、有効化を行います。Feature管理画面で移行元の内容を適用、保存します
具体的な操作はビデオをご参考ください

FeatureがDurupalのすべての設定、構成の移行はできません

移行はモジュール単位で、構成は出力可能なものを中心にしています。以下は移行可能な部分
- Core ： Content Types、 Fields、 Menus、 Taxonomies、 Text formats、 Image styles、 User roles 、 permissions
- Contribute： Views、 CTools、 Context 、 Panels、 Rules 、 Contexts、 Display Suite
移行できない部分は、例：テーマ、コンテンツに挿入した画像などがあります
- コンテンツに含まるメディア（例：写真、ビデオ、ファイルなど）がローカル（sites/default/files）に保存したため、移行先の保存パス修正、およびメディアファイルのコピーが手動で行う必要があります

video

記事カテゴリ

タグ

Drupalの部分的なコンテンツデータを別のDrualサイトに移行する場合そのコンテンツの構造定義とコンテンツCSVデータのエクスポート／インポートができます

背景：Drupal7.54
Drupalのサイト引っ越しなどでデータ移行の必要があります、以下の移行方法はよく利用されます。
- Drupalのモジュール（Feature）を用いてサイト間のデータ移行/開発管理を行います (162)
- 同じDrupalバージョンの単一サイトを複数サイト（ドメイン）の一つDrupalの共有ソースサイトへの移行チャレンジ (161)
ただし、部分的なコンテンツしか移行しない場合、上記方法では難しくなります
ここで、コンテンツ定義とデータを別々でexport/import方法を説明します

Drupalのモジュール（Bundle copy、 Taxonomy CSV import/export）でコンテンツの構成／定義をExport/Importします

モジュール（Bundle copy）でコンテンツの構成／定義を簡単に移行します（具体的にステップは省略）
タクソノミーのタームの構成（フィールドが追加など）が変わらなければ、モジュール（、Taxonomy CSV import/export）でタームリストデータをcsvファイルの出力することはできます
- 出力したCSVデータの別のサイトにインポートする場合、タクソノミーのボキャブラリーとタームIDが変わった可能性があります
- コンテンツのフィールドに「Term Reference」タイプのものがあれば、コンテンツ追加／編集ボタンをクリックすると、「HTTP ERROR 500」エラーが発生するかもしれないです
- 一番簡単な対応方法ではそのフィールドを一回削除して、再作成すればよいです（データインポートする前の段階）

Drupalのコンテンツ構成（フィールド）テーブルのデータをcsvフォーマットに出力します

現時点ではコンテンツのデータをcsvに出力するモジュールはあまり見当たらにです
コンテンツのフィールドをDB上各テーブルを見つけ出します
- コンテンツ（例：Article）のフィールドごとに一つのテールが存在しています
- Title ➡　nodeテーブルの「title」フィールド
- body ➡　field_data_bodyテーブルの「body_value」フィールド（またはbody_summaryなど）
- カスタムフィールド ➡　field_data_CUSTOM_FIELD_NAMEの「field_data_CUSTOM_FIELD_NAME_value」フィールド
これらのテーブルを「node」テーブルを中心してジョインして、新しいテーブルの書き込みます
- すべてのコンテンツは「node」テーブルを基本にしています
- 各フィールドのテーブルに「entity_id」がnodeテーブルの「nid」の関連付けキーとなります
- 全フィールドと同じフィールドの新しいテーブルを一つ作成します（例：new_table）
- 全フィールドをJOINしてデータを新しいテーブル（例：new_table）にコピーします
```
INSERT INTO new_table (title, body, CUSTOM_FIELD_NAME,   ・・・・・・)
SELECT 
   title,
   body.body_value,
   T1.field_data_CUSTOM_FIEDL_NAME_value,
  ・・・・・・
FROM node
   left join field_data_body body on nid = body.entity_id
   left join field_data_CUSTOM_FIELD_NAME  T1  on T1.entity_id = nid
  ・・・・・・
  
```
新しいテーブル（new_table）の内容をｃｓｖフォーマットに出力します

Drupalのモジュール（Feeds Import）でコンテンツｃｓｖデータをインポートします

モジュール（Feeds Import）がよく利用されるものなので、簡単にｃｓｖデータを確認コンテンツにインポートすることができます
Feeds Importの説明は省略します(Drupalのモジュール（Feeds）で手動でデータインポート時の必須設定 (199)、FeedsモジュールでEnityにデータインポート (34)などを参考にしてください)

シリーズ記事一覧

記事カテゴリ

タグ

モジュール（Feature）が開発ソース管理、コンテンツデータ移行などに利用されます

最初モジュール（Feature）が何に使うかはあまりわからなかったです（いろいろな説明がちゅ抽象的）。
実はDrupalの開発ソース管理（例：開発環境ー＞ステージん環境ー＞本番環境）、コンテンツデータの移行に使用されます

データ移行例：コンテンツデータ（Article）＋Viewsで作成したコンテンツ検索一覧画面

データ移行の簡単な例として、既存のコンテンツデータ（例：Article⇒記事）、Viewsで作成したコンテンツ一覧画面を移行します
コンテンツデータ移行に必須なモジュール：
- Feature
- Node Export （FeatureモジュールにサポートするNode export featuresサブモジュールを有効化）
Feature管理画面で必要なモジュール、モジュールの関連、コンテンツデータを選択して、一つのモジュールとして作成し、ダウンロードします
作成されたモジュール（tarファイル）を移行先で通常のモジュールインストールをして、有効化を行います。Feature管理画面で移行元の内容を適用、保存します
具体的な操作はビデオをご参考ください

FeatureがDurupalのすべての設定、構成の移行はできません

移行はモジュール単位で、構成は出力可能なものを中心にしています。以下は移行可能な部分
- Core ： Content Types、 Fields、 Menus、 Taxonomies、 Text formats、 Image styles、 User roles 、 permissions
- Contribute： Views、 CTools、 Context 、 Panels、 Rules 、 Contexts、 Display Suite
移行できない部分は、例：テーマ、コンテンツに挿入した画像などがあります
- コンテンツに含まるメディア（例：写真、ビデオ、ファイルなど）がローカル（sites/default/files）に保存したため、移行先の保存パス修正、およびメディアファイルのコピーが手動で行う必要があります

video

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ

注意点：Drupalのモジュール（Feeds）の設定が間違うと手動でデータインポートができなくなります

環境：Drupal7.54、Feeds7.x-3.0
やりたいこと：手動でデータをインポート（例：csvファイルからのインポートなど）
Feedの基本設定のところある二か所をチェックしないと手動でのインポートができない
- 添付するコンテンツタイプ：スタントアローンのフォームを使う
- 投稿時にインポート
- 初期としてはこの二つ設定を有効にしています
ちなみに、「投稿時にインポート」を無効の場合、バッチでデータインポートすることになります（バッチの設定が必要）
添付するコンテンツタイプ：「スタントアローンのフォームを使う」以外の選択肢を選択すると、インポート画面（ホーム » インポート）に当該インポーターはありません

手動でインポートできないときに画面上に「インポートされた項目はありません」が表示されます

「投稿時にインポート」オプションが無効の場合、手動でデータインポートはできません
インポートデータがあるにはかかわらず、画面上に「インポートされた項目はありません」として表示されます
バッチにインポートジョブを入れたメッセージはありません

記事カテゴリ

タグ

目的

Entity Typeデータにほかのデータ（例：ｃｓｖ、xmlなど）からのインポートを可能にする
Feedsの初期データ変換プロセッサーに「Entity Type」のものがなかった

解決の選択肢

Feed Importモジュールでのデータインポート
Feedsモジュールのカスタマイズをする

ここでの解決：Feedsのカスタマイズ

インストールされたモジュール
- Feeds : 7.x-2.0
- ECK : 7.x-2.0
- Entity API : 7.x-1.5
上記モジュールのインストールと有効化
ECKでインポートデータタイプとBundleを作成する
- 例：　データタイプ：「組織データ」、Bundle：「ｘｘｘの組織データ」
- 「組織データ」のプロパティ：title、uid、created、changedを使用する
- 「ｘｘｘの組織データ」のフィールド：「組織コード」、「正式組織名」をテキストフィールドで追加

Feedsの紹介

Feedsが三つの部分から構成される：Fetcher、Parser、Processor
- Fetcher：インポータデータの取得（例：File upload、external RSS Feedなど）
- Parser：インポートデータの解析方法の指定（csv、xls、xml、RSSなど）
- Processor：インポートデータの作成（Node、terms、usersなどのデータ作成）

FeedsにEntity Typeデータ変換プロセッサーに追加

PatchファイルをFeedsモジュールに当てる
Feedsのデータ変換プロセッサー設定画面にEntity Typeのデータ変換プロセッサー追加前後のイメージ

files

添付	サイズ
feeds_entity_processor-1033202-217.patch_.txt (16.03 KB)	16.03 KB

記事カテゴリ

タグ

エラー：モジュール(Twitter)をバージョンアップしてフロントページに開くと「EntityFieldQueryException」が発生

モジュール(Twitter)のバージョン：7.x-5.11 ⇒ 7.x-6.2 にアップデートしました（新モジュールから旧モジュールを上書き）

フロントページを開いてみたらエラーが発生し：

EntityFieldQueryException: エンティティー <em class="placeholder">twitter_account</em> にはベーステーブルがありません。 EntityFieldQuery->propertyQuery() (/virtual/drills/public_html/drupal7/includes/entity.inc ファイル　1271行).

画面にエラーしか表示されていないです

原因：Twitter7.x-5.11⇒7.x-6.2にアップデートする場合DBのテーブルが追加されたので、DB更新が必要

原因は比較的に単純的で、Twitter7.x-6.2（7.x-6.0以上になるとデータ構造が変わった）が7.x-5.11よりデータテーブルが追加されました
管理者権限でupdate.phpを実行してデータテーブルを追加します

シリーズ記事一覧

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ

やりたいこと：一つDrupalのソースで複数のサイト（複数のドメイン）を構築したいです

Drupalを用いて複数のサイト（ドメイン）を構築する場合、一つサイト（ドメイン）ごとに一つのDrupalソースで構築することがもちろん問題はありません
Drupalソースが分散すると、バージョンアップ、バグ管理などの作業が大変になります
当然一つのDrupalソースの元で複数のサイト（ドメイン）の構築が必要となります
- 一ドメイン ⇒ Drupalソース ⇒ 共有DB
- 一ドメイン ⇒ Drupalソース ⇒ 独立DB
Drupalでは複数のサイト（ドメイン）への対応をしています

sitesディレクトリの下にドメインごとの子ディレクトリを作成してマルティサイトを構築します

複数のドメイン名をDrupalのルートディレクトリに同期します（例：シンボリックリンクでドメイン名をディレクトリと同期します）
- 例： old-pine.net をDrupalのルートディレクトリにシンボリックリンクで同期します
Drupalのルートディレクトリの下に sites ディレクトリがあります。sitesの下に各メイン名に同期したいディレクトリを作成します
- 例：sites/pine を作成します
sites/sites.phpファイルでドメイン名をディレクトと同期設定を行います
- 例： 'old-pine.net' => 'pine' （書き方：ドメイン名 => ディレクトリ名）
```
 $sites = array(
    'old-pine.net' => 'pine',
 );
```
新規作成したディレクトの下にサイトのインストール設定ファイル(settings.php)の作成
- 例：sites/pine/settings.phpを作成します
- settings.phpの内容はsites/pine/default.settings.phpのコピーで良いです（サイト新規作成する場合）
追加したドメイン名でサイトをアクセスして、新規サイトができたことを確認します

記事カテゴリ

タグ

やりたいこと：レンタルサーバーで申請したドメイン名を特定なディレクトリに同期するシンボリックリンク作成したいです

レンタルサーバー（例：valueserver）で申請したドメイン名を特定なディレクトに同期するツールが提供されています
同期ツールを利用するのは便利だが、設定が誤ると同期先のディレクトリのファイルがすべて削除されてします危険があります
特に、この操作がよく行うことではなく、誤って設定する確率は実は高そうです（実際に設定を誤って、同期先のファイルが消されてしまう事項がありました）

安全のため、シンボリックリンク作成コマンドでディレクト同期をしたほうがよいです

シンボリックリンク作成：
- public_htmlディレクトリ（apacheではdocument root）に入ります
- コマンド： ln -s [ディレクト名] [ドメイン名] （例：ln -s drupal7 old-pine.net）
- コマンド： ls -l　で生成したシンボリックリンクを確認します（例： old-pine.net -> pine）
シンボリックリンクの削除
- コマンド：unlink [ドメイン名] (例：unlink old-pine.net)
- コマンド：ls -l でドメイン名の同期先が消えたことを確認します

安全のため、コマンド(rm)でシンボリックリンクを削除しないこと

シンボリックリンクを削除するのはコマンド(rm)できますが、誤って指定すると、同期先のディレクトリの内容を削除していまう危険があります
シンボリックリンクを削除するには、コマンド(unlink)を使用すべきです

記事カテゴリ

タグ

モジュール（Feature）が開発ソース管理、コンテンツデータ移行などに利用されます

最初モジュール（Feature）が何に使うかはあまりわからなかったです（いろいろな説明がちゅ抽象的）。
実はDrupalの開発ソース管理（例：開発環境ー＞ステージん環境ー＞本番環境）、コンテンツデータの移行に使用されます

データ移行例：コンテンツデータ（Article）＋Viewsで作成したコンテンツ検索一覧画面

データ移行の簡単な例として、既存のコンテンツデータ（例：Article⇒記事）、Viewsで作成したコンテンツ一覧画面を移行します
コンテンツデータ移行に必須なモジュール：
- Feature
- Node Export （FeatureモジュールにサポートするNode export featuresサブモジュールを有効化）
Feature管理画面で必要なモジュール、モジュールの関連、コンテンツデータを選択して、一つのモジュールとして作成し、ダウンロードします
作成されたモジュール（tarファイル）を移行先で通常のモジュールインストールをして、有効化を行います。Feature管理画面で移行元の内容を適用、保存します
具体的な操作はビデオをご参考ください

FeatureがDurupalのすべての設定、構成の移行はできません

移行はモジュール単位で、構成は出力可能なものを中心にしています。以下は移行可能な部分
- Core ： Content Types、 Fields、 Menus、 Taxonomies、 Text formats、 Image styles、 User roles 、 permissions
- Contribute： Views、 CTools、 Context 、 Panels、 Rules 、 Contexts、 Display Suite
移行できない部分は、例：テーマ、コンテンツに挿入した画像などがあります
- コンテンツに含まるメディア（例：写真、ビデオ、ファイルなど）がローカル（sites/default/files）に保存したため、移行先の保存パス修正、およびメディアファイルのコピーが手動で行う必要があります

video

記事カテゴリ

タグ

Drupalの部分的なコンテンツデータを別のDrualサイトに移行する場合そのコンテンツの構造定義とコンテンツCSVデータのエクスポート／インポートができます

背景：Drupal7.54
Drupalのサイト引っ越しなどでデータ移行の必要があります、以下の移行方法はよく利用されます。
- Drupalのモジュール（Feature）を用いてサイト間のデータ移行/開発管理を行います (162)
- 同じDrupalバージョンの単一サイトを複数サイト（ドメイン）の一つDrupalの共有ソースサイトへの移行チャレンジ (161)
ただし、部分的なコンテンツしか移行しない場合、上記方法では難しくなります
ここで、コンテンツ定義とデータを別々でexport/import方法を説明します

Drupalのモジュール（Bundle copy、 Taxonomy CSV import/export）でコンテンツの構成／定義をExport/Importします

モジュール（Bundle copy）でコンテンツの構成／定義を簡単に移行します（具体的にステップは省略）
タクソノミーのタームの構成（フィールドが追加など）が変わらなければ、モジュール（、Taxonomy CSV import/export）でタームリストデータをcsvファイルの出力することはできます
- 出力したCSVデータの別のサイトにインポートする場合、タクソノミーのボキャブラリーとタームIDが変わった可能性があります
- コンテンツのフィールドに「Term Reference」タイプのものがあれば、コンテンツ追加／編集ボタンをクリックすると、「HTTP ERROR 500」エラーが発生するかもしれないです
- 一番簡単な対応方法ではそのフィールドを一回削除して、再作成すればよいです（データインポートする前の段階）

Drupalのコンテンツ構成（フィールド）テーブルのデータをcsvフォーマットに出力します

現時点ではコンテンツのデータをcsvに出力するモジュールはあまり見当たらにです
コンテンツのフィールドをDB上各テーブルを見つけ出します
- コンテンツ（例：Article）のフィールドごとに一つのテールが存在しています
- Title ➡　nodeテーブルの「title」フィールド
- body ➡　field_data_bodyテーブルの「body_value」フィールド（またはbody_summaryなど）
- カスタムフィールド ➡　field_data_CUSTOM_FIELD_NAMEの「field_data_CUSTOM_FIELD_NAME_value」フィールド
これらのテーブルを「node」テーブルを中心してジョインして、新しいテーブルの書き込みます
- すべてのコンテンツは「node」テーブルを基本にしています
- 各フィールドのテーブルに「entity_id」がnodeテーブルの「nid」の関連付けキーとなります
- 全フィールドと同じフィールドの新しいテーブルを一つ作成します（例：new_table）
- 全フィールドをJOINしてデータを新しいテーブル（例：new_table）にコピーします
```
INSERT INTO new_table (title, body, CUSTOM_FIELD_NAME,   ・・・・・・)
SELECT 
   title,
   body.body_value,
   T1.field_data_CUSTOM_FIEDL_NAME_value,
  ・・・・・・
FROM node
   left join field_data_body body on nid = body.entity_id
   left join field_data_CUSTOM_FIELD_NAME  T1  on T1.entity_id = nid
  ・・・・・・
  
```
新しいテーブル（new_table）の内容をｃｓｖフォーマットに出力します

Drupalのモジュール（Feeds Import）でコンテンツｃｓｖデータをインポートします

モジュール（Feeds Import）がよく利用されるものなので、簡単にｃｓｖデータを確認コンテンツにインポートすることができます
Feeds Importの説明は省略します(Drupalのモジュール（Feeds）で手動でデータインポート時の必須設定 (199)、FeedsモジュールでEnityにデータインポート (34)などを参考にしてください)

シリーズ記事一覧

記事カテゴリ

タグ

モジュール（Feature）が開発ソース管理、コンテンツデータ移行などに利用されます

最初モジュール（Feature）が何に使うかはあまりわからなかったです（いろいろな説明がちゅ抽象的）。
実はDrupalの開発ソース管理（例：開発環境ー＞ステージん環境ー＞本番環境）、コンテンツデータの移行に使用されます

データ移行例：コンテンツデータ（Article）＋Viewsで作成したコンテンツ検索一覧画面

データ移行の簡単な例として、既存のコンテンツデータ（例：Article⇒記事）、Viewsで作成したコンテンツ一覧画面を移行します
コンテンツデータ移行に必須なモジュール：
- Feature
- Node Export （FeatureモジュールにサポートするNode export featuresサブモジュールを有効化）
Feature管理画面で必要なモジュール、モジュールの関連、コンテンツデータを選択して、一つのモジュールとして作成し、ダウンロードします
作成されたモジュール（tarファイル）を移行先で通常のモジュールインストールをして、有効化を行います。Feature管理画面で移行元の内容を適用、保存します
具体的な操作はビデオをご参考ください

FeatureがDurupalのすべての設定、構成の移行はできません

移行はモジュール単位で、構成は出力可能なものを中心にしています。以下は移行可能な部分
- Core ： Content Types、 Fields、 Menus、 Taxonomies、 Text formats、 Image styles、 User roles 、 permissions
- Contribute： Views、 CTools、 Context 、 Panels、 Rules 、 Contexts、 Display Suite
移行できない部分は、例：テーマ、コンテンツに挿入した画像などがあります
- コンテンツに含まるメディア（例：写真、ビデオ、ファイルなど）がローカル（sites/default/files）に保存したため、移行先の保存パス修正、およびメディアファイルのコピーが手動で行う必要があります

video

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ

注意点：Drupalのモジュール（Feeds）の設定が間違うと手動でデータインポートができなくなります

環境：Drupal7.54、Feeds7.x-3.0
やりたいこと：手動でデータをインポート（例：csvファイルからのインポートなど）
Feedの基本設定のところある二か所をチェックしないと手動でのインポートができない
- 添付するコンテンツタイプ：スタントアローンのフォームを使う
- 投稿時にインポート
- 初期としてはこの二つ設定を有効にしています
ちなみに、「投稿時にインポート」を無効の場合、バッチでデータインポートすることになります（バッチの設定が必要）
添付するコンテンツタイプ：「スタントアローンのフォームを使う」以外の選択肢を選択すると、インポート画面（ホーム » インポート）に当該インポーターはありません

手動でインポートできないときに画面上に「インポートされた項目はありません」が表示されます

「投稿時にインポート」オプションが無効の場合、手動でデータインポートはできません
インポートデータがあるにはかかわらず、画面上に「インポートされた項目はありません」として表示されます
バッチにインポートジョブを入れたメッセージはありません

記事カテゴリ

タグ

目的

Entity Typeデータにほかのデータ（例：ｃｓｖ、xmlなど）からのインポートを可能にする
Feedsの初期データ変換プロセッサーに「Entity Type」のものがなかった

解決の選択肢

Feed Importモジュールでのデータインポート
Feedsモジュールのカスタマイズをする

ここでの解決：Feedsのカスタマイズ

インストールされたモジュール
- Feeds : 7.x-2.0
- ECK : 7.x-2.0
- Entity API : 7.x-1.5
上記モジュールのインストールと有効化
ECKでインポートデータタイプとBundleを作成する
- 例：　データタイプ：「組織データ」、Bundle：「ｘｘｘの組織データ」
- 「組織データ」のプロパティ：title、uid、created、changedを使用する
- 「ｘｘｘの組織データ」のフィールド：「組織コード」、「正式組織名」をテキストフィールドで追加

Feedsの紹介

Feedsが三つの部分から構成される：Fetcher、Parser、Processor
- Fetcher：インポータデータの取得（例：File upload、external RSS Feedなど）
- Parser：インポートデータの解析方法の指定（csv、xls、xml、RSSなど）
- Processor：インポートデータの作成（Node、terms、usersなどのデータ作成）

FeedsにEntity Typeデータ変換プロセッサーに追加

PatchファイルをFeedsモジュールに当てる
Feedsのデータ変換プロセッサー設定画面にEntity Typeのデータ変換プロセッサー追加前後のイメージ

files

添付	サイズ
feeds_entity_processor-1033202-217.patch_.txt (16.03 KB)	16.03 KB

記事カテゴリ

タグ

エラー：モジュール(Twitter)をバージョンアップしてフロントページに開くと「EntityFieldQueryException」が発生

モジュール(Twitter)のバージョン：7.x-5.11 ⇒ 7.x-6.2 にアップデートしました（新モジュールから旧モジュールを上書き）

フロントページを開いてみたらエラーが発生し：

EntityFieldQueryException: エンティティー <em class="placeholder">twitter_account</em> にはベーステーブルがありません。 EntityFieldQuery->propertyQuery() (/virtual/drills/public_html/drupal7/includes/entity.inc ファイル　1271行).

画面にエラーしか表示されていないです

原因：Twitter7.x-5.11⇒7.x-6.2にアップデートする場合DBのテーブルが追加されたので、DB更新が必要

原因は比較的に単純的で、Twitter7.x-6.2（7.x-6.0以上になるとデータ構造が変わった）が7.x-5.11よりデータテーブルが追加されました
管理者権限でupdate.phpを実行してデータテーブルを追加します

シリーズ記事一覧

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ

やりたいこと：一つDrupalのソースで複数のサイト（複数のドメイン）を構築したいです

Drupalを用いて複数のサイト（ドメイン）を構築する場合、一つサイト（ドメイン）ごとに一つのDrupalソースで構築することがもちろん問題はありません
Drupalソースが分散すると、バージョンアップ、バグ管理などの作業が大変になります
当然一つのDrupalソースの元で複数のサイト（ドメイン）の構築が必要となります
- 一ドメイン ⇒ Drupalソース ⇒ 共有DB
- 一ドメイン ⇒ Drupalソース ⇒ 独立DB
Drupalでは複数のサイト（ドメイン）への対応をしています

sitesディレクトリの下にドメインごとの子ディレクトリを作成してマルティサイトを構築します

複数のドメイン名をDrupalのルートディレクトリに同期します（例：シンボリックリンクでドメイン名をディレクトリと同期します）
- 例： old-pine.net をDrupalのルートディレクトリにシンボリックリンクで同期します
Drupalのルートディレクトリの下に sites ディレクトリがあります。sitesの下に各メイン名に同期したいディレクトリを作成します
- 例：sites/pine を作成します
sites/sites.phpファイルでドメイン名をディレクトと同期設定を行います
- 例： 'old-pine.net' => 'pine' （書き方：ドメイン名 => ディレクトリ名）
```
 $sites = array(
    'old-pine.net' => 'pine',
 );
```
新規作成したディレクトの下にサイトのインストール設定ファイル(settings.php)の作成
- 例：sites/pine/settings.phpを作成します
- settings.phpの内容はsites/pine/default.settings.phpのコピーで良いです（サイト新規作成する場合）
追加したドメイン名でサイトをアクセスして、新規サイトができたことを確認します

記事カテゴリ

タグ

やりたいこと：レンタルサーバーで申請したドメイン名を特定なディレクトリに同期するシンボリックリンク作成したいです

レンタルサーバー（例：valueserver）で申請したドメイン名を特定なディレクトに同期するツールが提供されています
同期ツールを利用するのは便利だが、設定が誤ると同期先のディレクトリのファイルがすべて削除されてします危険があります
特に、この操作がよく行うことではなく、誤って設定する確率は実は高そうです（実際に設定を誤って、同期先のファイルが消されてしまう事項がありました）

安全のため、シンボリックリンク作成コマンドでディレクト同期をしたほうがよいです

シンボリックリンク作成：
- public_htmlディレクトリ（apacheではdocument root）に入ります
- コマンド： ln -s [ディレクト名] [ドメイン名] （例：ln -s drupal7 old-pine.net）
- コマンド： ls -l　で生成したシンボリックリンクを確認します（例： old-pine.net -> pine）
シンボリックリンクの削除
- コマンド：unlink [ドメイン名] (例：unlink old-pine.net)
- コマンド：ls -l でドメイン名の同期先が消えたことを確認します

安全のため、コマンド(rm)でシンボリックリンクを削除しないこと

シンボリックリンクを削除するのはコマンド(rm)できますが、誤って指定すると、同期先のディレクトリの内容を削除していまう危険があります
シンボリックリンクを削除するには、コマンド(unlink)を使用すべきです

記事カテゴリ

タグ

モジュール（Feature）が開発ソース管理、コンテンツデータ移行などに利用されます

最初モジュール（Feature）が何に使うかはあまりわからなかったです（いろいろな説明がちゅ抽象的）。
実はDrupalの開発ソース管理（例：開発環境ー＞ステージん環境ー＞本番環境）、コンテンツデータの移行に使用されます

データ移行例：コンテンツデータ（Article）＋Viewsで作成したコンテンツ検索一覧画面

データ移行の簡単な例として、既存のコンテンツデータ（例：Article⇒記事）、Viewsで作成したコンテンツ一覧画面を移行します
コンテンツデータ移行に必須なモジュール：
- Feature
- Node Export （FeatureモジュールにサポートするNode export featuresサブモジュールを有効化）
Feature管理画面で必要なモジュール、モジュールの関連、コンテンツデータを選択して、一つのモジュールとして作成し、ダウンロードします
作成されたモジュール（tarファイル）を移行先で通常のモジュールインストールをして、有効化を行います。Feature管理画面で移行元の内容を適用、保存します
具体的な操作はビデオをご参考ください

FeatureがDurupalのすべての設定、構成の移行はできません

移行はモジュール単位で、構成は出力可能なものを中心にしています。以下は移行可能な部分
- Core ： Content Types、 Fields、 Menus、 Taxonomies、 Text formats、 Image styles、 User roles 、 permissions
- Contribute： Views、 CTools、 Context 、 Panels、 Rules 、 Contexts、 Display Suite
移行できない部分は、例：テーマ、コンテンツに挿入した画像などがあります
- コンテンツに含まるメディア（例：写真、ビデオ、ファイルなど）がローカル（sites/default/files）に保存したため、移行先の保存パス修正、およびメディアファイルのコピーが手動で行う必要があります

video

記事カテゴリ

タグ

Drupalの部分的なコンテンツデータを別のDrualサイトに移行する場合そのコンテンツの構造定義とコンテンツCSVデータのエクスポート／インポートができます

背景：Drupal7.54
Drupalのサイト引っ越しなどでデータ移行の必要があります、以下の移行方法はよく利用されます。
- Drupalのモジュール（Feature）を用いてサイト間のデータ移行/開発管理を行います (162)
- 同じDrupalバージョンの単一サイトを複数サイト（ドメイン）の一つDrupalの共有ソースサイトへの移行チャレンジ (161)
ただし、部分的なコンテンツしか移行しない場合、上記方法では難しくなります
ここで、コンテンツ定義とデータを別々でexport/import方法を説明します

Drupalのモジュール（Bundle copy、 Taxonomy CSV import/export）でコンテンツの構成／定義をExport/Importします

モジュール（Bundle copy）でコンテンツの構成／定義を簡単に移行します（具体的にステップは省略）
タクソノミーのタームの構成（フィールドが追加など）が変わらなければ、モジュール（、Taxonomy CSV import/export）でタームリストデータをcsvファイルの出力することはできます
- 出力したCSVデータの別のサイトにインポートする場合、タクソノミーのボキャブラリーとタームIDが変わった可能性があります
- コンテンツのフィールドに「Term Reference」タイプのものがあれば、コンテンツ追加／編集ボタンをクリックすると、「HTTP ERROR 500」エラーが発生するかもしれないです
- 一番簡単な対応方法ではそのフィールドを一回削除して、再作成すればよいです（データインポートする前の段階）

Drupalのコンテンツ構成（フィールド）テーブルのデータをcsvフォーマットに出力します

現時点ではコンテンツのデータをcsvに出力するモジュールはあまり見当たらにです
コンテンツのフィールドをDB上各テーブルを見つけ出します
- コンテンツ（例：Article）のフィールドごとに一つのテールが存在しています
- Title ➡　nodeテーブルの「title」フィールド
- body ➡　field_data_bodyテーブルの「body_value」フィールド（またはbody_summaryなど）
- カスタムフィールド ➡　field_data_CUSTOM_FIELD_NAMEの「field_data_CUSTOM_FIELD_NAME_value」フィールド
これらのテーブルを「node」テーブルを中心してジョインして、新しいテーブルの書き込みます
- すべてのコンテンツは「node」テーブルを基本にしています
- 各フィールドのテーブルに「entity_id」がnodeテーブルの「nid」の関連付けキーとなります
- 全フィールドと同じフィールドの新しいテーブルを一つ作成します（例：new_table）
- 全フィールドをJOINしてデータを新しいテーブル（例：new_table）にコピーします
```
INSERT INTO new_table (title, body, CUSTOM_FIELD_NAME,   ・・・・・・)
SELECT 
   title,
   body.body_value,
   T1.field_data_CUSTOM_FIEDL_NAME_value,
  ・・・・・・
FROM node
   left join field_data_body body on nid = body.entity_id
   left join field_data_CUSTOM_FIELD_NAME  T1  on T1.entity_id = nid
  ・・・・・・
  
```
新しいテーブル（new_table）の内容をｃｓｖフォーマットに出力します

Drupalのモジュール（Feeds Import）でコンテンツｃｓｖデータをインポートします

モジュール（Feeds Import）がよく利用されるものなので、簡単にｃｓｖデータを確認コンテンツにインポートすることができます
Feeds Importの説明は省略します(Drupalのモジュール（Feeds）で手動でデータインポート時の必須設定 (199)、FeedsモジュールでEnityにデータインポート (34)などを参考にしてください)

シリーズ記事一覧

記事カテゴリ

タグ

モジュール（Feature）が開発ソース管理、コンテンツデータ移行などに利用されます

最初モジュール（Feature）が何に使うかはあまりわからなかったです（いろいろな説明がちゅ抽象的）。
実はDrupalの開発ソース管理（例：開発環境ー＞ステージん環境ー＞本番環境）、コンテンツデータの移行に使用されます

データ移行例：コンテンツデータ（Article）＋Viewsで作成したコンテンツ検索一覧画面

データ移行の簡単な例として、既存のコンテンツデータ（例：Article⇒記事）、Viewsで作成したコンテンツ一覧画面を移行します
コンテンツデータ移行に必須なモジュール：
- Feature
- Node Export （FeatureモジュールにサポートするNode export featuresサブモジュールを有効化）
Feature管理画面で必要なモジュール、モジュールの関連、コンテンツデータを選択して、一つのモジュールとして作成し、ダウンロードします
作成されたモジュール（tarファイル）を移行先で通常のモジュールインストールをして、有効化を行います。Feature管理画面で移行元の内容を適用、保存します
具体的な操作はビデオをご参考ください

FeatureがDurupalのすべての設定、構成の移行はできません

移行はモジュール単位で、構成は出力可能なものを中心にしています。以下は移行可能な部分
- Core ： Content Types、 Fields、 Menus、 Taxonomies、 Text formats、 Image styles、 User roles 、 permissions
- Contribute： Views、 CTools、 Context 、 Panels、 Rules 、 Contexts、 Display Suite
移行できない部分は、例：テーマ、コンテンツに挿入した画像などがあります
- コンテンツに含まるメディア（例：写真、ビデオ、ファイルなど）がローカル（sites/default/files）に保存したため、移行先の保存パス修正、およびメディアファイルのコピーが手動で行う必要があります

video

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ

注意点：Drupalのモジュール（Feeds）の設定が間違うと手動でデータインポートができなくなります

環境：Drupal7.54、Feeds7.x-3.0
やりたいこと：手動でデータをインポート（例：csvファイルからのインポートなど）
Feedの基本設定のところある二か所をチェックしないと手動でのインポートができない
- 添付するコンテンツタイプ：スタントアローンのフォームを使う
- 投稿時にインポート
- 初期としてはこの二つ設定を有効にしています
ちなみに、「投稿時にインポート」を無効の場合、バッチでデータインポートすることになります（バッチの設定が必要）
添付するコンテンツタイプ：「スタントアローンのフォームを使う」以外の選択肢を選択すると、インポート画面（ホーム » インポート）に当該インポーターはありません

手動でインポートできないときに画面上に「インポートされた項目はありません」が表示されます

「投稿時にインポート」オプションが無効の場合、手動でデータインポートはできません
インポートデータがあるにはかかわらず、画面上に「インポートされた項目はありません」として表示されます
バッチにインポートジョブを入れたメッセージはありません

記事カテゴリ

タグ

目的

Entity Typeデータにほかのデータ（例：ｃｓｖ、xmlなど）からのインポートを可能にする
Feedsの初期データ変換プロセッサーに「Entity Type」のものがなかった

解決の選択肢

Feed Importモジュールでのデータインポート
Feedsモジュールのカスタマイズをする

ここでの解決：Feedsのカスタマイズ

インストールされたモジュール
- Feeds : 7.x-2.0
- ECK : 7.x-2.0
- Entity API : 7.x-1.5
上記モジュールのインストールと有効化
ECKでインポートデータタイプとBundleを作成する
- 例：　データタイプ：「組織データ」、Bundle：「ｘｘｘの組織データ」
- 「組織データ」のプロパティ：title、uid、created、changedを使用する
- 「ｘｘｘの組織データ」のフィールド：「組織コード」、「正式組織名」をテキストフィールドで追加

Feedsの紹介

Feedsが三つの部分から構成される：Fetcher、Parser、Processor
- Fetcher：インポータデータの取得（例：File upload、external RSS Feedなど）
- Parser：インポートデータの解析方法の指定（csv、xls、xml、RSSなど）
- Processor：インポートデータの作成（Node、terms、usersなどのデータ作成）

FeedsにEntity Typeデータ変換プロセッサーに追加

PatchファイルをFeedsモジュールに当てる
Feedsのデータ変換プロセッサー設定画面にEntity Typeのデータ変換プロセッサー追加前後のイメージ

files

添付	サイズ
feeds_entity_processor-1033202-217.patch_.txt (16.03 KB)	16.03 KB

記事カテゴリ

タグ

エラー：モジュール(Twitter)をバージョンアップしてフロントページに開くと「EntityFieldQueryException」が発生

モジュール(Twitter)のバージョン：7.x-5.11 ⇒ 7.x-6.2 にアップデートしました（新モジュールから旧モジュールを上書き）

フロントページを開いてみたらエラーが発生し：

EntityFieldQueryException: エンティティー <em class="placeholder">twitter_account</em> にはベーステーブルがありません。 EntityFieldQuery->propertyQuery() (/virtual/drills/public_html/drupal7/includes/entity.inc ファイル　1271行).

画面にエラーしか表示されていないです

原因：Twitter7.x-5.11⇒7.x-6.2にアップデートする場合DBのテーブルが追加されたので、DB更新が必要

原因は比較的に単純的で、Twitter7.x-6.2（7.x-6.0以上になるとデータ構造が変わった）が7.x-5.11よりデータテーブルが追加されました
管理者権限でupdate.phpを実行してデータテーブルを追加します

シリーズ記事一覧

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ

やりたいこと：一つDrupalのソースで複数のサイト（複数のドメイン）を構築したいです

Drupalを用いて複数のサイト（ドメイン）を構築する場合、一つサイト（ドメイン）ごとに一つのDrupalソースで構築することがもちろん問題はありません
Drupalソースが分散すると、バージョンアップ、バグ管理などの作業が大変になります
当然一つのDrupalソースの元で複数のサイト（ドメイン）の構築が必要となります
- 一ドメイン ⇒ Drupalソース ⇒ 共有DB
- 一ドメイン ⇒ Drupalソース ⇒ 独立DB
Drupalでは複数のサイト（ドメイン）への対応をしています

sitesディレクトリの下にドメインごとの子ディレクトリを作成してマルティサイトを構築します

複数のドメイン名をDrupalのルートディレクトリに同期します（例：シンボリックリンクでドメイン名をディレクトリと同期します）
- 例： old-pine.net をDrupalのルートディレクトリにシンボリックリンクで同期します
Drupalのルートディレクトリの下に sites ディレクトリがあります。sitesの下に各メイン名に同期したいディレクトリを作成します
- 例：sites/pine を作成します
sites/sites.phpファイルでドメイン名をディレクトと同期設定を行います
- 例： 'old-pine.net' => 'pine' （書き方：ドメイン名 => ディレクトリ名）
```
 $sites = array(
    'old-pine.net' => 'pine',
 );
```
新規作成したディレクトの下にサイトのインストール設定ファイル(settings.php)の作成
- 例：sites/pine/settings.phpを作成します
- settings.phpの内容はsites/pine/default.settings.phpのコピーで良いです（サイト新規作成する場合）
追加したドメイン名でサイトをアクセスして、新規サイトができたことを確認します

記事カテゴリ

タグ

やりたいこと：レンタルサーバーで申請したドメイン名を特定なディレクトリに同期するシンボリックリンク作成したいです

レンタルサーバー（例：valueserver）で申請したドメイン名を特定なディレクトに同期するツールが提供されています
同期ツールを利用するのは便利だが、設定が誤ると同期先のディレクトリのファイルがすべて削除されてします危険があります
特に、この操作がよく行うことではなく、誤って設定する確率は実は高そうです（実際に設定を誤って、同期先のファイルが消されてしまう事項がありました）

安全のため、シンボリックリンク作成コマンドでディレクト同期をしたほうがよいです

シンボリックリンク作成：
- public_htmlディレクトリ（apacheではdocument root）に入ります
- コマンド： ln -s [ディレクト名] [ドメイン名] （例：ln -s drupal7 old-pine.net）
- コマンド： ls -l　で生成したシンボリックリンクを確認します（例： old-pine.net -> pine）
シンボリックリンクの削除
- コマンド：unlink [ドメイン名] (例：unlink old-pine.net)
- コマンド：ls -l でドメイン名の同期先が消えたことを確認します

安全のため、コマンド(rm)でシンボリックリンクを削除しないこと

シンボリックリンクを削除するのはコマンド(rm)できますが、誤って指定すると、同期先のディレクトリの内容を削除していまう危険があります
シンボリックリンクを削除するには、コマンド(unlink)を使用すべきです

記事カテゴリ

タグ

モジュール（Feature）が開発ソース管理、コンテンツデータ移行などに利用されます

最初モジュール（Feature）が何に使うかはあまりわからなかったです（いろいろな説明がちゅ抽象的）。
実はDrupalの開発ソース管理（例：開発環境ー＞ステージん環境ー＞本番環境）、コンテンツデータの移行に使用されます

データ移行例：コンテンツデータ（Article）＋Viewsで作成したコンテンツ検索一覧画面

データ移行の簡単な例として、既存のコンテンツデータ（例：Article⇒記事）、Viewsで作成したコンテンツ一覧画面を移行します
コンテンツデータ移行に必須なモジュール：
- Feature
- Node Export （FeatureモジュールにサポートするNode export featuresサブモジュールを有効化）
Feature管理画面で必要なモジュール、モジュールの関連、コンテンツデータを選択して、一つのモジュールとして作成し、ダウンロードします
作成されたモジュール（tarファイル）を移行先で通常のモジュールインストールをして、有効化を行います。Feature管理画面で移行元の内容を適用、保存します
具体的な操作はビデオをご参考ください

FeatureがDurupalのすべての設定、構成の移行はできません

移行はモジュール単位で、構成は出力可能なものを中心にしています。以下は移行可能な部分
- Core ： Content Types、 Fields、 Menus、 Taxonomies、 Text formats、 Image styles、 User roles 、 permissions
- Contribute： Views、 CTools、 Context 、 Panels、 Rules 、 Contexts、 Display Suite
移行できない部分は、例：テーマ、コンテンツに挿入した画像などがあります
- コンテンツに含まるメディア（例：写真、ビデオ、ファイルなど）がローカル（sites/default/files）に保存したため、移行先の保存パス修正、およびメディアファイルのコピーが手動で行う必要があります

video

記事カテゴリ

タグ

Drupalの部分的なコンテンツデータを別のDrualサイトに移行する場合そのコンテンツの構造定義とコンテンツCSVデータのエクスポート／インポートができます

背景：Drupal7.54
Drupalのサイト引っ越しなどでデータ移行の必要があります、以下の移行方法はよく利用されます。
- Drupalのモジュール（Feature）を用いてサイト間のデータ移行/開発管理を行います (162)
- 同じDrupalバージョンの単一サイトを複数サイト（ドメイン）の一つDrupalの共有ソースサイトへの移行チャレンジ (161)
ただし、部分的なコンテンツしか移行しない場合、上記方法では難しくなります
ここで、コンテンツ定義とデータを別々でexport/import方法を説明します

Drupalのモジュール（Bundle copy、 Taxonomy CSV import/export）でコンテンツの構成／定義をExport/Importします

モジュール（Bundle copy）でコンテンツの構成／定義を簡単に移行します（具体的にステップは省略）
タクソノミーのタームの構成（フィールドが追加など）が変わらなければ、モジュール（、Taxonomy CSV import/export）でタームリストデータをcsvファイルの出力することはできます
- 出力したCSVデータの別のサイトにインポートする場合、タクソノミーのボキャブラリーとタームIDが変わった可能性があります
- コンテンツのフィールドに「Term Reference」タイプのものがあれば、コンテンツ追加／編集ボタンをクリックすると、「HTTP ERROR 500」エラーが発生するかもしれないです
- 一番簡単な対応方法ではそのフィールドを一回削除して、再作成すればよいです（データインポートする前の段階）

Drupalのコンテンツ構成（フィールド）テーブルのデータをcsvフォーマットに出力します

現時点ではコンテンツのデータをcsvに出力するモジュールはあまり見当たらにです
コンテンツのフィールドをDB上各テーブルを見つけ出します
- コンテンツ（例：Article）のフィールドごとに一つのテールが存在しています
- Title ➡　nodeテーブルの「title」フィールド
- body ➡　field_data_bodyテーブルの「body_value」フィールド（またはbody_summaryなど）
- カスタムフィールド ➡　field_data_CUSTOM_FIELD_NAMEの「field_data_CUSTOM_FIELD_NAME_value」フィールド
これらのテーブルを「node」テーブルを中心してジョインして、新しいテーブルの書き込みます
- すべてのコンテンツは「node」テーブルを基本にしています
- 各フィールドのテーブルに「entity_id」がnodeテーブルの「nid」の関連付けキーとなります
- 全フィールドと同じフィールドの新しいテーブルを一つ作成します（例：new_table）
- 全フィールドをJOINしてデータを新しいテーブル（例：new_table）にコピーします
```
INSERT INTO new_table (title, body, CUSTOM_FIELD_NAME,   ・・・・・・)
SELECT 
   title,
   body.body_value,
   T1.field_data_CUSTOM_FIEDL_NAME_value,
  ・・・・・・
FROM node
   left join field_data_body body on nid = body.entity_id
   left join field_data_CUSTOM_FIELD_NAME  T1  on T1.entity_id = nid
  ・・・・・・
  
```
新しいテーブル（new_table）の内容をｃｓｖフォーマットに出力します

Drupalのモジュール（Feeds Import）でコンテンツｃｓｖデータをインポートします

モジュール（Feeds Import）がよく利用されるものなので、簡単にｃｓｖデータを確認コンテンツにインポートすることができます
Feeds Importの説明は省略します(Drupalのモジュール（Feeds）で手動でデータインポート時の必須設定 (199)、FeedsモジュールでEnityにデータインポート (34)などを参考にしてください)

シリーズ記事一覧

記事カテゴリ

タグ

モジュール（Feature）が開発ソース管理、コンテンツデータ移行などに利用されます

最初モジュール（Feature）が何に使うかはあまりわからなかったです（いろいろな説明がちゅ抽象的）。
実はDrupalの開発ソース管理（例：開発環境ー＞ステージん環境ー＞本番環境）、コンテンツデータの移行に使用されます

データ移行例：コンテンツデータ（Article）＋Viewsで作成したコンテンツ検索一覧画面

データ移行の簡単な例として、既存のコンテンツデータ（例：Article⇒記事）、Viewsで作成したコンテンツ一覧画面を移行します
コンテンツデータ移行に必須なモジュール：
- Feature
- Node Export （FeatureモジュールにサポートするNode export featuresサブモジュールを有効化）
Feature管理画面で必要なモジュール、モジュールの関連、コンテンツデータを選択して、一つのモジュールとして作成し、ダウンロードします
作成されたモジュール（tarファイル）を移行先で通常のモジュールインストールをして、有効化を行います。Feature管理画面で移行元の内容を適用、保存します
具体的な操作はビデオをご参考ください

FeatureがDurupalのすべての設定、構成の移行はできません

移行はモジュール単位で、構成は出力可能なものを中心にしています。以下は移行可能な部分
- Core ： Content Types、 Fields、 Menus、 Taxonomies、 Text formats、 Image styles、 User roles 、 permissions
- Contribute： Views、 CTools、 Context 、 Panels、 Rules 、 Contexts、 Display Suite
移行できない部分は、例：テーマ、コンテンツに挿入した画像などがあります
- コンテンツに含まるメディア（例：写真、ビデオ、ファイルなど）がローカル（sites/default/files）に保存したため、移行先の保存パス修正、およびメディアファイルのコピーが手動で行う必要があります

video

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ

注意点：Drupalのモジュール（Feeds）の設定が間違うと手動でデータインポートができなくなります

環境：Drupal7.54、Feeds7.x-3.0
やりたいこと：手動でデータをインポート（例：csvファイルからのインポートなど）
Feedの基本設定のところある二か所をチェックしないと手動でのインポートができない
- 添付するコンテンツタイプ：スタントアローンのフォームを使う
- 投稿時にインポート
- 初期としてはこの二つ設定を有効にしています
ちなみに、「投稿時にインポート」を無効の場合、バッチでデータインポートすることになります（バッチの設定が必要）
添付するコンテンツタイプ：「スタントアローンのフォームを使う」以外の選択肢を選択すると、インポート画面（ホーム » インポート）に当該インポーターはありません

手動でインポートできないときに画面上に「インポートされた項目はありません」が表示されます

「投稿時にインポート」オプションが無効の場合、手動でデータインポートはできません
インポートデータがあるにはかかわらず、画面上に「インポートされた項目はありません」として表示されます
バッチにインポートジョブを入れたメッセージはありません

記事カテゴリ

タグ

目的

Entity Typeデータにほかのデータ（例：ｃｓｖ、xmlなど）からのインポートを可能にする
Feedsの初期データ変換プロセッサーに「Entity Type」のものがなかった

解決の選択肢

Feed Importモジュールでのデータインポート
Feedsモジュールのカスタマイズをする

ここでの解決：Feedsのカスタマイズ

インストールされたモジュール
- Feeds : 7.x-2.0
- ECK : 7.x-2.0
- Entity API : 7.x-1.5
上記モジュールのインストールと有効化
ECKでインポートデータタイプとBundleを作成する
- 例：　データタイプ：「組織データ」、Bundle：「ｘｘｘの組織データ」
- 「組織データ」のプロパティ：title、uid、created、changedを使用する
- 「ｘｘｘの組織データ」のフィールド：「組織コード」、「正式組織名」をテキストフィールドで追加

Feedsの紹介

Feedsが三つの部分から構成される：Fetcher、Parser、Processor
- Fetcher：インポータデータの取得（例：File upload、external RSS Feedなど）
- Parser：インポートデータの解析方法の指定（csv、xls、xml、RSSなど）
- Processor：インポートデータの作成（Node、terms、usersなどのデータ作成）

FeedsにEntity Typeデータ変換プロセッサーに追加

PatchファイルをFeedsモジュールに当てる
Feedsのデータ変換プロセッサー設定画面にEntity Typeのデータ変換プロセッサー追加前後のイメージ

files

添付	サイズ
feeds_entity_processor-1033202-217.patch_.txt (16.03 KB)	16.03 KB

記事カテゴリ

タグ

エラー：モジュール(Twitter)をバージョンアップしてフロントページに開くと「EntityFieldQueryException」が発生

モジュール(Twitter)のバージョン：7.x-5.11 ⇒ 7.x-6.2 にアップデートしました（新モジュールから旧モジュールを上書き）

フロントページを開いてみたらエラーが発生し：

EntityFieldQueryException: エンティティー <em class="placeholder">twitter_account</em> にはベーステーブルがありません。 EntityFieldQuery->propertyQuery() (/virtual/drills/public_html/drupal7/includes/entity.inc ファイル　1271行).

画面にエラーしか表示されていないです

原因：Twitter7.x-5.11⇒7.x-6.2にアップデートする場合DBのテーブルが追加されたので、DB更新が必要

原因は比較的に単純的で、Twitter7.x-6.2（7.x-6.0以上になるとデータ構造が変わった）が7.x-5.11よりデータテーブルが追加されました
管理者権限でupdate.phpを実行してデータテーブルを追加します

シリーズ記事一覧

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ

やりたいこと：一つDrupalのソースで複数のサイト（複数のドメイン）を構築したいです

Drupalを用いて複数のサイト（ドメイン）を構築する場合、一つサイト（ドメイン）ごとに一つのDrupalソースで構築することがもちろん問題はありません
Drupalソースが分散すると、バージョンアップ、バグ管理などの作業が大変になります
当然一つのDrupalソースの元で複数のサイト（ドメイン）の構築が必要となります
- 一ドメイン ⇒ Drupalソース ⇒ 共有DB
- 一ドメイン ⇒ Drupalソース ⇒ 独立DB
Drupalでは複数のサイト（ドメイン）への対応をしています

sitesディレクトリの下にドメインごとの子ディレクトリを作成してマルティサイトを構築します

複数のドメイン名をDrupalのルートディレクトリに同期します（例：シンボリックリンクでドメイン名をディレクトリと同期します）
- 例： old-pine.net をDrupalのルートディレクトリにシンボリックリンクで同期します
Drupalのルートディレクトリの下に sites ディレクトリがあります。sitesの下に各メイン名に同期したいディレクトリを作成します
- 例：sites/pine を作成します
sites/sites.phpファイルでドメイン名をディレクトと同期設定を行います
- 例： 'old-pine.net' => 'pine' （書き方：ドメイン名 => ディレクトリ名）
```
 $sites = array(
    'old-pine.net' => 'pine',
 );
```
新規作成したディレクトの下にサイトのインストール設定ファイル(settings.php)の作成
- 例：sites/pine/settings.phpを作成します
- settings.phpの内容はsites/pine/default.settings.phpのコピーで良いです（サイト新規作成する場合）
追加したドメイン名でサイトをアクセスして、新規サイトができたことを確認します

記事カテゴリ

タグ

やりたいこと：レンタルサーバーで申請したドメイン名を特定なディレクトリに同期するシンボリックリンク作成したいです

レンタルサーバー（例：valueserver）で申請したドメイン名を特定なディレクトに同期するツールが提供されています
同期ツールを利用するのは便利だが、設定が誤ると同期先のディレクトリのファイルがすべて削除されてします危険があります
特に、この操作がよく行うことではなく、誤って設定する確率は実は高そうです（実際に設定を誤って、同期先のファイルが消されてしまう事項がありました）

安全のため、シンボリックリンク作成コマンドでディレクト同期をしたほうがよいです

シンボリックリンク作成：
- public_htmlディレクトリ（apacheではdocument root）に入ります
- コマンド： ln -s [ディレクト名] [ドメイン名] （例：ln -s drupal7 old-pine.net）
- コマンド： ls -l　で生成したシンボリックリンクを確認します（例： old-pine.net -> pine）
シンボリックリンクの削除
- コマンド：unlink [ドメイン名] (例：unlink old-pine.net)
- コマンド：ls -l でドメイン名の同期先が消えたことを確認します

安全のため、コマンド(rm)でシンボリックリンクを削除しないこと

シンボリックリンクを削除するのはコマンド(rm)できますが、誤って指定すると、同期先のディレクトリの内容を削除していまう危険があります
シンボリックリンクを削除するには、コマンド(unlink)を使用すべきです

記事カテゴリ

タグ

モジュール（Feature）が開発ソース管理、コンテンツデータ移行などに利用されます

最初モジュール（Feature）が何に使うかはあまりわからなかったです（いろいろな説明がちゅ抽象的）。
実はDrupalの開発ソース管理（例：開発環境ー＞ステージん環境ー＞本番環境）、コンテンツデータの移行に使用されます

データ移行例：コンテンツデータ（Article）＋Viewsで作成したコンテンツ検索一覧画面

データ移行の簡単な例として、既存のコンテンツデータ（例：Article⇒記事）、Viewsで作成したコンテンツ一覧画面を移行します
コンテンツデータ移行に必須なモジュール：
- Feature
- Node Export （FeatureモジュールにサポートするNode export featuresサブモジュールを有効化）
Feature管理画面で必要なモジュール、モジュールの関連、コンテンツデータを選択して、一つのモジュールとして作成し、ダウンロードします
作成されたモジュール（tarファイル）を移行先で通常のモジュールインストールをして、有効化を行います。Feature管理画面で移行元の内容を適用、保存します
具体的な操作はビデオをご参考ください

FeatureがDurupalのすべての設定、構成の移行はできません

移行はモジュール単位で、構成は出力可能なものを中心にしています。以下は移行可能な部分
- Core ： Content Types、 Fields、 Menus、 Taxonomies、 Text formats、 Image styles、 User roles 、 permissions
- Contribute： Views、 CTools、 Context 、 Panels、 Rules 、 Contexts、 Display Suite
移行できない部分は、例：テーマ、コンテンツに挿入した画像などがあります
- コンテンツに含まるメディア（例：写真、ビデオ、ファイルなど）がローカル（sites/default/files）に保存したため、移行先の保存パス修正、およびメディアファイルのコピーが手動で行う必要があります

video

記事カテゴリ

タグ

Drupalの部分的なコンテンツデータを別のDrualサイトに移行する場合そのコンテンツの構造定義とコンテンツCSVデータのエクスポート／インポートができます

背景：Drupal7.54
Drupalのサイト引っ越しなどでデータ移行の必要があります、以下の移行方法はよく利用されます。
- Drupalのモジュール（Feature）を用いてサイト間のデータ移行/開発管理を行います (162)
- 同じDrupalバージョンの単一サイトを複数サイト（ドメイン）の一つDrupalの共有ソースサイトへの移行チャレンジ (161)
ただし、部分的なコンテンツしか移行しない場合、上記方法では難しくなります
ここで、コンテンツ定義とデータを別々でexport/import方法を説明します

Drupalのモジュール（Bundle copy、 Taxonomy CSV import/export）でコンテンツの構成／定義をExport/Importします

モジュール（Bundle copy）でコンテンツの構成／定義を簡単に移行します（具体的にステップは省略）
タクソノミーのタームの構成（フィールドが追加など）が変わらなければ、モジュール（、Taxonomy CSV import/export）でタームリストデータをcsvファイルの出力することはできます
- 出力したCSVデータの別のサイトにインポートする場合、タクソノミーのボキャブラリーとタームIDが変わった可能性があります
- コンテンツのフィールドに「Term Reference」タイプのものがあれば、コンテンツ追加／編集ボタンをクリックすると、「HTTP ERROR 500」エラーが発生するかもしれないです
- 一番簡単な対応方法ではそのフィールドを一回削除して、再作成すればよいです（データインポートする前の段階）

Drupalのコンテンツ構成（フィールド）テーブルのデータをcsvフォーマットに出力します

現時点ではコンテンツのデータをcsvに出力するモジュールはあまり見当たらにです
コンテンツのフィールドをDB上各テーブルを見つけ出します
- コンテンツ（例：Article）のフィールドごとに一つのテールが存在しています
- Title ➡　nodeテーブルの「title」フィールド
- body ➡　field_data_bodyテーブルの「body_value」フィールド（またはbody_summaryなど）
- カスタムフィールド ➡　field_data_CUSTOM_FIELD_NAMEの「field_data_CUSTOM_FIELD_NAME_value」フィールド
これらのテーブルを「node」テーブルを中心してジョインして、新しいテーブルの書き込みます
- すべてのコンテンツは「node」テーブルを基本にしています
- 各フィールドのテーブルに「entity_id」がnodeテーブルの「nid」の関連付けキーとなります
- 全フィールドと同じフィールドの新しいテーブルを一つ作成します（例：new_table）
- 全フィールドをJOINしてデータを新しいテーブル（例：new_table）にコピーします
```
INSERT INTO new_table (title, body, CUSTOM_FIELD_NAME,   ・・・・・・)
SELECT 
   title,
   body.body_value,
   T1.field_data_CUSTOM_FIEDL_NAME_value,
  ・・・・・・
FROM node
   left join field_data_body body on nid = body.entity_id
   left join field_data_CUSTOM_FIELD_NAME  T1  on T1.entity_id = nid
  ・・・・・・
  
```
新しいテーブル（new_table）の内容をｃｓｖフォーマットに出力します

Drupalのモジュール（Feeds Import）でコンテンツｃｓｖデータをインポートします

モジュール（Feeds Import）がよく利用されるものなので、簡単にｃｓｖデータを確認コンテンツにインポートすることができます
Feeds Importの説明は省略します(Drupalのモジュール（Feeds）で手動でデータインポート時の必須設定 (199)、FeedsモジュールでEnityにデータインポート (34)などを参考にしてください)

シリーズ記事一覧

記事カテゴリ

タグ

モジュール（Feature）が開発ソース管理、コンテンツデータ移行などに利用されます

最初モジュール（Feature）が何に使うかはあまりわからなかったです（いろいろな説明がちゅ抽象的）。
実はDrupalの開発ソース管理（例：開発環境ー＞ステージん環境ー＞本番環境）、コンテンツデータの移行に使用されます

データ移行例：コンテンツデータ（Article）＋Viewsで作成したコンテンツ検索一覧画面

データ移行の簡単な例として、既存のコンテンツデータ（例：Article⇒記事）、Viewsで作成したコンテンツ一覧画面を移行します
コンテンツデータ移行に必須なモジュール：
- Feature
- Node Export （FeatureモジュールにサポートするNode export featuresサブモジュールを有効化）
Feature管理画面で必要なモジュール、モジュールの関連、コンテンツデータを選択して、一つのモジュールとして作成し、ダウンロードします
作成されたモジュール（tarファイル）を移行先で通常のモジュールインストールをして、有効化を行います。Feature管理画面で移行元の内容を適用、保存します
具体的な操作はビデオをご参考ください

FeatureがDurupalのすべての設定、構成の移行はできません

移行はモジュール単位で、構成は出力可能なものを中心にしています。以下は移行可能な部分
- Core ： Content Types、 Fields、 Menus、 Taxonomies、 Text formats、 Image styles、 User roles 、 permissions
- Contribute： Views、 CTools、 Context 、 Panels、 Rules 、 Contexts、 Display Suite
移行できない部分は、例：テーマ、コンテンツに挿入した画像などがあります
- コンテンツに含まるメディア（例：写真、ビデオ、ファイルなど）がローカル（sites/default/files）に保存したため、移行先の保存パス修正、およびメディアファイルのコピーが手動で行う必要があります

video

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ

注意点：Drupalのモジュール（Feeds）の設定が間違うと手動でデータインポートができなくなります

環境：Drupal7.54、Feeds7.x-3.0
やりたいこと：手動でデータをインポート（例：csvファイルからのインポートなど）
Feedの基本設定のところある二か所をチェックしないと手動でのインポートができない
- 添付するコンテンツタイプ：スタントアローンのフォームを使う
- 投稿時にインポート
- 初期としてはこの二つ設定を有効にしています
ちなみに、「投稿時にインポート」を無効の場合、バッチでデータインポートすることになります（バッチの設定が必要）
添付するコンテンツタイプ：「スタントアローンのフォームを使う」以外の選択肢を選択すると、インポート画面（ホーム » インポート）に当該インポーターはありません

手動でインポートできないときに画面上に「インポートされた項目はありません」が表示されます

「投稿時にインポート」オプションが無効の場合、手動でデータインポートはできません
インポートデータがあるにはかかわらず、画面上に「インポートされた項目はありません」として表示されます
バッチにインポートジョブを入れたメッセージはありません

記事カテゴリ

タグ

目的

Entity Typeデータにほかのデータ（例：ｃｓｖ、xmlなど）からのインポートを可能にする
Feedsの初期データ変換プロセッサーに「Entity Type」のものがなかった

解決の選択肢

Feed Importモジュールでのデータインポート
Feedsモジュールのカスタマイズをする

ここでの解決：Feedsのカスタマイズ

インストールされたモジュール
- Feeds : 7.x-2.0
- ECK : 7.x-2.0
- Entity API : 7.x-1.5
上記モジュールのインストールと有効化
ECKでインポートデータタイプとBundleを作成する
- 例：　データタイプ：「組織データ」、Bundle：「ｘｘｘの組織データ」
- 「組織データ」のプロパティ：title、uid、created、changedを使用する
- 「ｘｘｘの組織データ」のフィールド：「組織コード」、「正式組織名」をテキストフィールドで追加

Feedsの紹介

Feedsが三つの部分から構成される：Fetcher、Parser、Processor
- Fetcher：インポータデータの取得（例：File upload、external RSS Feedなど）
- Parser：インポートデータの解析方法の指定（csv、xls、xml、RSSなど）
- Processor：インポートデータの作成（Node、terms、usersなどのデータ作成）

FeedsにEntity Typeデータ変換プロセッサーに追加

PatchファイルをFeedsモジュールに当てる
Feedsのデータ変換プロセッサー設定画面にEntity Typeのデータ変換プロセッサー追加前後のイメージ

files

添付	サイズ
feeds_entity_processor-1033202-217.patch_.txt (16.03 KB)	16.03 KB

記事カテゴリ

タグ

エラー：モジュール(Twitter)をバージョンアップしてフロントページに開くと「EntityFieldQueryException」が発生

モジュール(Twitter)のバージョン：7.x-5.11 ⇒ 7.x-6.2 にアップデートしました（新モジュールから旧モジュールを上書き）

フロントページを開いてみたらエラーが発生し：

EntityFieldQueryException: エンティティー <em class="placeholder">twitter_account</em> にはベーステーブルがありません。 EntityFieldQuery->propertyQuery() (/virtual/drills/public_html/drupal7/includes/entity.inc ファイル　1271行).

画面にエラーしか表示されていないです

原因：Twitter7.x-5.11⇒7.x-6.2にアップデートする場合DBのテーブルが追加されたので、DB更新が必要

原因は比較的に単純的で、Twitter7.x-6.2（7.x-6.0以上になるとデータ構造が変わった）が7.x-5.11よりデータテーブルが追加されました
管理者権限でupdate.phpを実行してデータテーブルを追加します

シリーズ記事一覧

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ

やりたいこと：一つDrupalのソースで複数のサイト（複数のドメイン）を構築したいです

Drupalを用いて複数のサイト（ドメイン）を構築する場合、一つサイト（ドメイン）ごとに一つのDrupalソースで構築することがもちろん問題はありません
Drupalソースが分散すると、バージョンアップ、バグ管理などの作業が大変になります
当然一つのDrupalソースの元で複数のサイト（ドメイン）の構築が必要となります
- 一ドメイン ⇒ Drupalソース ⇒ 共有DB
- 一ドメイン ⇒ Drupalソース ⇒ 独立DB
Drupalでは複数のサイト（ドメイン）への対応をしています

sitesディレクトリの下にドメインごとの子ディレクトリを作成してマルティサイトを構築します

複数のドメイン名をDrupalのルートディレクトリに同期します（例：シンボリックリンクでドメイン名をディレクトリと同期します）
- 例： old-pine.net をDrupalのルートディレクトリにシンボリックリンクで同期します
Drupalのルートディレクトリの下に sites ディレクトリがあります。sitesの下に各メイン名に同期したいディレクトリを作成します
- 例：sites/pine を作成します
sites/sites.phpファイルでドメイン名をディレクトと同期設定を行います
- 例： 'old-pine.net' => 'pine' （書き方：ドメイン名 => ディレクトリ名）
```
 $sites = array(
    'old-pine.net' => 'pine',
 );
```
新規作成したディレクトの下にサイトのインストール設定ファイル(settings.php)の作成
- 例：sites/pine/settings.phpを作成します
- settings.phpの内容はsites/pine/default.settings.phpのコピーで良いです（サイト新規作成する場合）
追加したドメイン名でサイトをアクセスして、新規サイトができたことを確認します

記事カテゴリ

タグ

やりたいこと：レンタルサーバーで申請したドメイン名を特定なディレクトリに同期するシンボリックリンク作成したいです

レンタルサーバー（例：valueserver）で申請したドメイン名を特定なディレクトに同期するツールが提供されています
同期ツールを利用するのは便利だが、設定が誤ると同期先のディレクトリのファイルがすべて削除されてします危険があります
特に、この操作がよく行うことではなく、誤って設定する確率は実は高そうです（実際に設定を誤って、同期先のファイルが消されてしまう事項がありました）

安全のため、シンボリックリンク作成コマンドでディレクト同期をしたほうがよいです

シンボリックリンク作成：
- public_htmlディレクトリ（apacheではdocument root）に入ります
- コマンド： ln -s [ディレクト名] [ドメイン名] （例：ln -s drupal7 old-pine.net）
- コマンド： ls -l　で生成したシンボリックリンクを確認します（例： old-pine.net -> pine）
シンボリックリンクの削除
- コマンド：unlink [ドメイン名] (例：unlink old-pine.net)
- コマンド：ls -l でドメイン名の同期先が消えたことを確認します

安全のため、コマンド(rm)でシンボリックリンクを削除しないこと

シンボリックリンクを削除するのはコマンド(rm)できますが、誤って指定すると、同期先のディレクトリの内容を削除していまう危険があります
シンボリックリンクを削除するには、コマンド(unlink)を使用すべきです

記事カテゴリ

タグ

モジュール（Feature）が開発ソース管理、コンテンツデータ移行などに利用されます

最初モジュール（Feature）が何に使うかはあまりわからなかったです（いろいろな説明がちゅ抽象的）。
実はDrupalの開発ソース管理（例：開発環境ー＞ステージん環境ー＞本番環境）、コンテンツデータの移行に使用されます

データ移行例：コンテンツデータ（Article）＋Viewsで作成したコンテンツ検索一覧画面

データ移行の簡単な例として、既存のコンテンツデータ（例：Article⇒記事）、Viewsで作成したコンテンツ一覧画面を移行します
コンテンツデータ移行に必須なモジュール：
- Feature
- Node Export （FeatureモジュールにサポートするNode export featuresサブモジュールを有効化）
Feature管理画面で必要なモジュール、モジュールの関連、コンテンツデータを選択して、一つのモジュールとして作成し、ダウンロードします
作成されたモジュール（tarファイル）を移行先で通常のモジュールインストールをして、有効化を行います。Feature管理画面で移行元の内容を適用、保存します
具体的な操作はビデオをご参考ください

FeatureがDurupalのすべての設定、構成の移行はできません

移行はモジュール単位で、構成は出力可能なものを中心にしています。以下は移行可能な部分
- Core ： Content Types、 Fields、 Menus、 Taxonomies、 Text formats、 Image styles、 User roles 、 permissions
- Contribute： Views、 CTools、 Context 、 Panels、 Rules 、 Contexts、 Display Suite
移行できない部分は、例：テーマ、コンテンツに挿入した画像などがあります
- コンテンツに含まるメディア（例：写真、ビデオ、ファイルなど）がローカル（sites/default/files）に保存したため、移行先の保存パス修正、およびメディアファイルのコピーが手動で行う必要があります

video

記事カテゴリ

タグ

Drupalの部分的なコンテンツデータを別のDrualサイトに移行する場合そのコンテンツの構造定義とコンテンツCSVデータのエクスポート／インポートができます

背景：Drupal7.54
Drupalのサイト引っ越しなどでデータ移行の必要があります、以下の移行方法はよく利用されます。
- Drupalのモジュール（Feature）を用いてサイト間のデータ移行/開発管理を行います (162)
- 同じDrupalバージョンの単一サイトを複数サイト（ドメイン）の一つDrupalの共有ソースサイトへの移行チャレンジ (161)
ただし、部分的なコンテンツしか移行しない場合、上記方法では難しくなります
ここで、コンテンツ定義とデータを別々でexport/import方法を説明します

Drupalのモジュール（Bundle copy、 Taxonomy CSV import/export）でコンテンツの構成／定義をExport/Importします

モジュール（Bundle copy）でコンテンツの構成／定義を簡単に移行します（具体的にステップは省略）
タクソノミーのタームの構成（フィールドが追加など）が変わらなければ、モジュール（、Taxonomy CSV import/export）でタームリストデータをcsvファイルの出力することはできます
- 出力したCSVデータの別のサイトにインポートする場合、タクソノミーのボキャブラリーとタームIDが変わった可能性があります
- コンテンツのフィールドに「Term Reference」タイプのものがあれば、コンテンツ追加／編集ボタンをクリックすると、「HTTP ERROR 500」エラーが発生するかもしれないです
- 一番簡単な対応方法ではそのフィールドを一回削除して、再作成すればよいです（データインポートする前の段階）

Drupalのコンテンツ構成（フィールド）テーブルのデータをcsvフォーマットに出力します

現時点ではコンテンツのデータをcsvに出力するモジュールはあまり見当たらにです
コンテンツのフィールドをDB上各テーブルを見つけ出します
- コンテンツ（例：Article）のフィールドごとに一つのテールが存在しています
- Title ➡　nodeテーブルの「title」フィールド
- body ➡　field_data_bodyテーブルの「body_value」フィールド（またはbody_summaryなど）
- カスタムフィールド ➡　field_data_CUSTOM_FIELD_NAMEの「field_data_CUSTOM_FIELD_NAME_value」フィールド
これらのテーブルを「node」テーブルを中心してジョインして、新しいテーブルの書き込みます
- すべてのコンテンツは「node」テーブルを基本にしています
- 各フィールドのテーブルに「entity_id」がnodeテーブルの「nid」の関連付けキーとなります
- 全フィールドと同じフィールドの新しいテーブルを一つ作成します（例：new_table）
- 全フィールドをJOINしてデータを新しいテーブル（例：new_table）にコピーします
```
INSERT INTO new_table (title, body, CUSTOM_FIELD_NAME,   ・・・・・・)
SELECT 
   title,
   body.body_value,
   T1.field_data_CUSTOM_FIEDL_NAME_value,
  ・・・・・・
FROM node
   left join field_data_body body on nid = body.entity_id
   left join field_data_CUSTOM_FIELD_NAME  T1  on T1.entity_id = nid
  ・・・・・・
  
```
新しいテーブル（new_table）の内容をｃｓｖフォーマットに出力します

Drupalのモジュール（Feeds Import）でコンテンツｃｓｖデータをインポートします

モジュール（Feeds Import）がよく利用されるものなので、簡単にｃｓｖデータを確認コンテンツにインポートすることができます
Feeds Importの説明は省略します(Drupalのモジュール（Feeds）で手動でデータインポート時の必須設定 (199)、FeedsモジュールでEnityにデータインポート (34)などを参考にしてください)

シリーズ記事一覧

記事カテゴリ

タグ

モジュール（Feature）が開発ソース管理、コンテンツデータ移行などに利用されます

最初モジュール（Feature）が何に使うかはあまりわからなかったです（いろいろな説明がちゅ抽象的）。
実はDrupalの開発ソース管理（例：開発環境ー＞ステージん環境ー＞本番環境）、コンテンツデータの移行に使用されます

データ移行例：コンテンツデータ（Article）＋Viewsで作成したコンテンツ検索一覧画面

データ移行の簡単な例として、既存のコンテンツデータ（例：Article⇒記事）、Viewsで作成したコンテンツ一覧画面を移行します
コンテンツデータ移行に必須なモジュール：
- Feature
- Node Export （FeatureモジュールにサポートするNode export featuresサブモジュールを有効化）
Feature管理画面で必要なモジュール、モジュールの関連、コンテンツデータを選択して、一つのモジュールとして作成し、ダウンロードします
作成されたモジュール（tarファイル）を移行先で通常のモジュールインストールをして、有効化を行います。Feature管理画面で移行元の内容を適用、保存します
具体的な操作はビデオをご参考ください

FeatureがDurupalのすべての設定、構成の移行はできません

移行はモジュール単位で、構成は出力可能なものを中心にしています。以下は移行可能な部分
- Core ： Content Types、 Fields、 Menus、 Taxonomies、 Text formats、 Image styles、 User roles 、 permissions
- Contribute： Views、 CTools、 Context 、 Panels、 Rules 、 Contexts、 Display Suite
移行できない部分は、例：テーマ、コンテンツに挿入した画像などがあります
- コンテンツに含まるメディア（例：写真、ビデオ、ファイルなど）がローカル（sites/default/files）に保存したため、移行先の保存パス修正、およびメディアファイルのコピーが手動で行う必要があります

video

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ

注意点：Drupalのモジュール（Feeds）の設定が間違うと手動でデータインポートができなくなります

環境：Drupal7.54、Feeds7.x-3.0
やりたいこと：手動でデータをインポート（例：csvファイルからのインポートなど）
Feedの基本設定のところある二か所をチェックしないと手動でのインポートができない
- 添付するコンテンツタイプ：スタントアローンのフォームを使う
- 投稿時にインポート
- 初期としてはこの二つ設定を有効にしています
ちなみに、「投稿時にインポート」を無効の場合、バッチでデータインポートすることになります（バッチの設定が必要）
添付するコンテンツタイプ：「スタントアローンのフォームを使う」以外の選択肢を選択すると、インポート画面（ホーム » インポート）に当該インポーターはありません

手動でインポートできないときに画面上に「インポートされた項目はありません」が表示されます

「投稿時にインポート」オプションが無効の場合、手動でデータインポートはできません
インポートデータがあるにはかかわらず、画面上に「インポートされた項目はありません」として表示されます
バッチにインポートジョブを入れたメッセージはありません

記事カテゴリ

タグ

目的

Entity Typeデータにほかのデータ（例：ｃｓｖ、xmlなど）からのインポートを可能にする
Feedsの初期データ変換プロセッサーに「Entity Type」のものがなかった

解決の選択肢

Feed Importモジュールでのデータインポート
Feedsモジュールのカスタマイズをする

ここでの解決：Feedsのカスタマイズ

インストールされたモジュール
- Feeds : 7.x-2.0
- ECK : 7.x-2.0
- Entity API : 7.x-1.5
上記モジュールのインストールと有効化
ECKでインポートデータタイプとBundleを作成する
- 例：　データタイプ：「組織データ」、Bundle：「ｘｘｘの組織データ」
- 「組織データ」のプロパティ：title、uid、created、changedを使用する
- 「ｘｘｘの組織データ」のフィールド：「組織コード」、「正式組織名」をテキストフィールドで追加

Feedsの紹介

Feedsが三つの部分から構成される：Fetcher、Parser、Processor
- Fetcher：インポータデータの取得（例：File upload、external RSS Feedなど）
- Parser：インポートデータの解析方法の指定（csv、xls、xml、RSSなど）
- Processor：インポートデータの作成（Node、terms、usersなどのデータ作成）

FeedsにEntity Typeデータ変換プロセッサーに追加

PatchファイルをFeedsモジュールに当てる
Feedsのデータ変換プロセッサー設定画面にEntity Typeのデータ変換プロセッサー追加前後のイメージ

files

添付	サイズ
feeds_entity_processor-1033202-217.patch_.txt (16.03 KB)	16.03 KB

記事カテゴリ

タグ

エラー：モジュール(Twitter)をバージョンアップしてフロントページに開くと「EntityFieldQueryException」が発生

モジュール(Twitter)のバージョン：7.x-5.11 ⇒ 7.x-6.2 にアップデートしました（新モジュールから旧モジュールを上書き）

フロントページを開いてみたらエラーが発生し：

EntityFieldQueryException: エンティティー <em class="placeholder">twitter_account</em> にはベーステーブルがありません。 EntityFieldQuery->propertyQuery() (/virtual/drills/public_html/drupal7/includes/entity.inc ファイル　1271行).

画面にエラーしか表示されていないです

原因：Twitter7.x-5.11⇒7.x-6.2にアップデートする場合DBのテーブルが追加されたので、DB更新が必要

原因は比較的に単純的で、Twitter7.x-6.2（7.x-6.0以上になるとデータ構造が変わった）が7.x-5.11よりデータテーブルが追加されました
管理者権限でupdate.phpを実行してデータテーブルを追加します

シリーズ記事一覧

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ

やりたいこと：一つDrupalのソースで複数のサイト（複数のドメイン）を構築したいです

Drupalを用いて複数のサイト（ドメイン）を構築する場合、一つサイト（ドメイン）ごとに一つのDrupalソースで構築することがもちろん問題はありません
Drupalソースが分散すると、バージョンアップ、バグ管理などの作業が大変になります
当然一つのDrupalソースの元で複数のサイト（ドメイン）の構築が必要となります
- 一ドメイン ⇒ Drupalソース ⇒ 共有DB
- 一ドメイン ⇒ Drupalソース ⇒ 独立DB
Drupalでは複数のサイト（ドメイン）への対応をしています

sitesディレクトリの下にドメインごとの子ディレクトリを作成してマルティサイトを構築します

複数のドメイン名をDrupalのルートディレクトリに同期します（例：シンボリックリンクでドメイン名をディレクトリと同期します）
- 例： old-pine.net をDrupalのルートディレクトリにシンボリックリンクで同期します
Drupalのルートディレクトリの下に sites ディレクトリがあります。sitesの下に各メイン名に同期したいディレクトリを作成します
- 例：sites/pine を作成します
sites/sites.phpファイルでドメイン名をディレクトと同期設定を行います
- 例： 'old-pine.net' => 'pine' （書き方：ドメイン名 => ディレクトリ名）
```
 $sites = array(
    'old-pine.net' => 'pine',
 );
```
新規作成したディレクトの下にサイトのインストール設定ファイル(settings.php)の作成
- 例：sites/pine/settings.phpを作成します
- settings.phpの内容はsites/pine/default.settings.phpのコピーで良いです（サイト新規作成する場合）
追加したドメイン名でサイトをアクセスして、新規サイトができたことを確認します

記事カテゴリ

タグ

やりたいこと：レンタルサーバーで申請したドメイン名を特定なディレクトリに同期するシンボリックリンク作成したいです

レンタルサーバー（例：valueserver）で申請したドメイン名を特定なディレクトに同期するツールが提供されています
同期ツールを利用するのは便利だが、設定が誤ると同期先のディレクトリのファイルがすべて削除されてします危険があります
特に、この操作がよく行うことではなく、誤って設定する確率は実は高そうです（実際に設定を誤って、同期先のファイルが消されてしまう事項がありました）

安全のため、シンボリックリンク作成コマンドでディレクト同期をしたほうがよいです

シンボリックリンク作成：
- public_htmlディレクトリ（apacheではdocument root）に入ります
- コマンド： ln -s [ディレクト名] [ドメイン名] （例：ln -s drupal7 old-pine.net）
- コマンド： ls -l　で生成したシンボリックリンクを確認します（例： old-pine.net -> pine）
シンボリックリンクの削除
- コマンド：unlink [ドメイン名] (例：unlink old-pine.net)
- コマンド：ls -l でドメイン名の同期先が消えたことを確認します

安全のため、コマンド(rm)でシンボリックリンクを削除しないこと

シンボリックリンクを削除するのはコマンド(rm)できますが、誤って指定すると、同期先のディレクトリの内容を削除していまう危険があります
シンボリックリンクを削除するには、コマンド(unlink)を使用すべきです

記事カテゴリ

タグ

モジュール（Feature）が開発ソース管理、コンテンツデータ移行などに利用されます

最初モジュール（Feature）が何に使うかはあまりわからなかったです（いろいろな説明がちゅ抽象的）。
実はDrupalの開発ソース管理（例：開発環境ー＞ステージん環境ー＞本番環境）、コンテンツデータの移行に使用されます

データ移行例：コンテンツデータ（Article）＋Viewsで作成したコンテンツ検索一覧画面

データ移行の簡単な例として、既存のコンテンツデータ（例：Article⇒記事）、Viewsで作成したコンテンツ一覧画面を移行します
コンテンツデータ移行に必須なモジュール：
- Feature
- Node Export （FeatureモジュールにサポートするNode export featuresサブモジュールを有効化）
Feature管理画面で必要なモジュール、モジュールの関連、コンテンツデータを選択して、一つのモジュールとして作成し、ダウンロードします
作成されたモジュール（tarファイル）を移行先で通常のモジュールインストールをして、有効化を行います。Feature管理画面で移行元の内容を適用、保存します
具体的な操作はビデオをご参考ください

FeatureがDurupalのすべての設定、構成の移行はできません

移行はモジュール単位で、構成は出力可能なものを中心にしています。以下は移行可能な部分
- Core ： Content Types、 Fields、 Menus、 Taxonomies、 Text formats、 Image styles、 User roles 、 permissions
- Contribute： Views、 CTools、 Context 、 Panels、 Rules 、 Contexts、 Display Suite
移行できない部分は、例：テーマ、コンテンツに挿入した画像などがあります
- コンテンツに含まるメディア（例：写真、ビデオ、ファイルなど）がローカル（sites/default/files）に保存したため、移行先の保存パス修正、およびメディアファイルのコピーが手動で行う必要があります

video

記事カテゴリ

タグ

Drupalの部分的なコンテンツデータを別のDrualサイトに移行する場合そのコンテンツの構造定義とコンテンツCSVデータのエクスポート／インポートができます

背景：Drupal7.54
Drupalのサイト引っ越しなどでデータ移行の必要があります、以下の移行方法はよく利用されます。
- Drupalのモジュール（Feature）を用いてサイト間のデータ移行/開発管理を行います (162)
- 同じDrupalバージョンの単一サイトを複数サイト（ドメイン）の一つDrupalの共有ソースサイトへの移行チャレンジ (161)
ただし、部分的なコンテンツしか移行しない場合、上記方法では難しくなります
ここで、コンテンツ定義とデータを別々でexport/import方法を説明します

Drupalのモジュール（Bundle copy、 Taxonomy CSV import/export）でコンテンツの構成／定義をExport/Importします

モジュール（Bundle copy）でコンテンツの構成／定義を簡単に移行します（具体的にステップは省略）
タクソノミーのタームの構成（フィールドが追加など）が変わらなければ、モジュール（、Taxonomy CSV import/export）でタームリストデータをcsvファイルの出力することはできます
- 出力したCSVデータの別のサイトにインポートする場合、タクソノミーのボキャブラリーとタームIDが変わった可能性があります
- コンテンツのフィールドに「Term Reference」タイプのものがあれば、コンテンツ追加／編集ボタンをクリックすると、「HTTP ERROR 500」エラーが発生するかもしれないです
- 一番簡単な対応方法ではそのフィールドを一回削除して、再作成すればよいです（データインポートする前の段階）

Drupalのコンテンツ構成（フィールド）テーブルのデータをcsvフォーマットに出力します

現時点ではコンテンツのデータをcsvに出力するモジュールはあまり見当たらにです
コンテンツのフィールドをDB上各テーブルを見つけ出します
- コンテンツ（例：Article）のフィールドごとに一つのテールが存在しています
- Title ➡　nodeテーブルの「title」フィールド
- body ➡　field_data_bodyテーブルの「body_value」フィールド（またはbody_summaryなど）
- カスタムフィールド ➡　field_data_CUSTOM_FIELD_NAMEの「field_data_CUSTOM_FIELD_NAME_value」フィールド
これらのテーブルを「node」テーブルを中心してジョインして、新しいテーブルの書き込みます
- すべてのコンテンツは「node」テーブルを基本にしています
- 各フィールドのテーブルに「entity_id」がnodeテーブルの「nid」の関連付けキーとなります
- 全フィールドと同じフィールドの新しいテーブルを一つ作成します（例：new_table）
- 全フィールドをJOINしてデータを新しいテーブル（例：new_table）にコピーします
```
INSERT INTO new_table (title, body, CUSTOM_FIELD_NAME,   ・・・・・・)
SELECT 
   title,
   body.body_value,
   T1.field_data_CUSTOM_FIEDL_NAME_value,
  ・・・・・・
FROM node
   left join field_data_body body on nid = body.entity_id
   left join field_data_CUSTOM_FIELD_NAME  T1  on T1.entity_id = nid
  ・・・・・・
  
```
新しいテーブル（new_table）の内容をｃｓｖフォーマットに出力します

Drupalのモジュール（Feeds Import）でコンテンツｃｓｖデータをインポートします

モジュール（Feeds Import）がよく利用されるものなので、簡単にｃｓｖデータを確認コンテンツにインポートすることができます
Feeds Importの説明は省略します(Drupalのモジュール（Feeds）で手動でデータインポート時の必須設定 (199)、FeedsモジュールでEnityにデータインポート (34)などを参考にしてください)

シリーズ記事一覧

記事カテゴリ

タグ

モジュール（Feature）が開発ソース管理、コンテンツデータ移行などに利用されます

最初モジュール（Feature）が何に使うかはあまりわからなかったです（いろいろな説明がちゅ抽象的）。
実はDrupalの開発ソース管理（例：開発環境ー＞ステージん環境ー＞本番環境）、コンテンツデータの移行に使用されます

データ移行例：コンテンツデータ（Article）＋Viewsで作成したコンテンツ検索一覧画面

データ移行の簡単な例として、既存のコンテンツデータ（例：Article⇒記事）、Viewsで作成したコンテンツ一覧画面を移行します
コンテンツデータ移行に必須なモジュール：
- Feature
- Node Export （FeatureモジュールにサポートするNode export featuresサブモジュールを有効化）
Feature管理画面で必要なモジュール、モジュールの関連、コンテンツデータを選択して、一つのモジュールとして作成し、ダウンロードします
作成されたモジュール（tarファイル）を移行先で通常のモジュールインストールをして、有効化を行います。Feature管理画面で移行元の内容を適用、保存します
具体的な操作はビデオをご参考ください

FeatureがDurupalのすべての設定、構成の移行はできません

移行はモジュール単位で、構成は出力可能なものを中心にしています。以下は移行可能な部分
- Core ： Content Types、 Fields、 Menus、 Taxonomies、 Text formats、 Image styles、 User roles 、 permissions
- Contribute： Views、 CTools、 Context 、 Panels、 Rules 、 Contexts、 Display Suite
移行できない部分は、例：テーマ、コンテンツに挿入した画像などがあります
- コンテンツに含まるメディア（例：写真、ビデオ、ファイルなど）がローカル（sites/default/files）に保存したため、移行先の保存パス修正、およびメディアファイルのコピーが手動で行う必要があります

video

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ

注意点：Drupalのモジュール（Feeds）の設定が間違うと手動でデータインポートができなくなります

環境：Drupal7.54、Feeds7.x-3.0
やりたいこと：手動でデータをインポート（例：csvファイルからのインポートなど）
Feedの基本設定のところある二か所をチェックしないと手動でのインポートができない
- 添付するコンテンツタイプ：スタントアローンのフォームを使う
- 投稿時にインポート
- 初期としてはこの二つ設定を有効にしています
ちなみに、「投稿時にインポート」を無効の場合、バッチでデータインポートすることになります（バッチの設定が必要）
添付するコンテンツタイプ：「スタントアローンのフォームを使う」以外の選択肢を選択すると、インポート画面（ホーム » インポート）に当該インポーターはありません

手動でインポートできないときに画面上に「インポートされた項目はありません」が表示されます

「投稿時にインポート」オプションが無効の場合、手動でデータインポートはできません
インポートデータがあるにはかかわらず、画面上に「インポートされた項目はありません」として表示されます
バッチにインポートジョブを入れたメッセージはありません

記事カテゴリ

タグ

目的

Entity Typeデータにほかのデータ（例：ｃｓｖ、xmlなど）からのインポートを可能にする
Feedsの初期データ変換プロセッサーに「Entity Type」のものがなかった

解決の選択肢

Feed Importモジュールでのデータインポート
Feedsモジュールのカスタマイズをする

ここでの解決：Feedsのカスタマイズ

インストールされたモジュール
- Feeds : 7.x-2.0
- ECK : 7.x-2.0
- Entity API : 7.x-1.5
上記モジュールのインストールと有効化
ECKでインポートデータタイプとBundleを作成する
- 例：　データタイプ：「組織データ」、Bundle：「ｘｘｘの組織データ」
- 「組織データ」のプロパティ：title、uid、created、changedを使用する
- 「ｘｘｘの組織データ」のフィールド：「組織コード」、「正式組織名」をテキストフィールドで追加

Feedsの紹介

Feedsが三つの部分から構成される：Fetcher、Parser、Processor
- Fetcher：インポータデータの取得（例：File upload、external RSS Feedなど）
- Parser：インポートデータの解析方法の指定（csv、xls、xml、RSSなど）
- Processor：インポートデータの作成（Node、terms、usersなどのデータ作成）

FeedsにEntity Typeデータ変換プロセッサーに追加

PatchファイルをFeedsモジュールに当てる
Feedsのデータ変換プロセッサー設定画面にEntity Typeのデータ変換プロセッサー追加前後のイメージ

files

添付	サイズ
feeds_entity_processor-1033202-217.patch_.txt (16.03 KB)	16.03 KB

記事カテゴリ

タグ

エラー：モジュール(Twitter)をバージョンアップしてフロントページに開くと「EntityFieldQueryException」が発生

モジュール(Twitter)のバージョン：7.x-5.11 ⇒ 7.x-6.2 にアップデートしました（新モジュールから旧モジュールを上書き）

フロントページを開いてみたらエラーが発生し：

EntityFieldQueryException: エンティティー <em class="placeholder">twitter_account</em> にはベーステーブルがありません。 EntityFieldQuery->propertyQuery() (/virtual/drills/public_html/drupal7/includes/entity.inc ファイル　1271行).

画面にエラーしか表示されていないです

原因：Twitter7.x-5.11⇒7.x-6.2にアップデートする場合DBのテーブルが追加されたので、DB更新が必要

原因は比較的に単純的で、Twitter7.x-6.2（7.x-6.0以上になるとデータ構造が変わった）が7.x-5.11よりデータテーブルが追加されました
管理者権限でupdate.phpを実行してデータテーブルを追加します

シリーズ記事一覧

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ

やりたいこと：一つDrupalのソースで複数のサイト（複数のドメイン）を構築したいです

Drupalを用いて複数のサイト（ドメイン）を構築する場合、一つサイト（ドメイン）ごとに一つのDrupalソースで構築することがもちろん問題はありません
Drupalソースが分散すると、バージョンアップ、バグ管理などの作業が大変になります
当然一つのDrupalソースの元で複数のサイト（ドメイン）の構築が必要となります
- 一ドメイン ⇒ Drupalソース ⇒ 共有DB
- 一ドメイン ⇒ Drupalソース ⇒ 独立DB
Drupalでは複数のサイト（ドメイン）への対応をしています

sitesディレクトリの下にドメインごとの子ディレクトリを作成してマルティサイトを構築します

複数のドメイン名をDrupalのルートディレクトリに同期します（例：シンボリックリンクでドメイン名をディレクトリと同期します）
- 例： old-pine.net をDrupalのルートディレクトリにシンボリックリンクで同期します
Drupalのルートディレクトリの下に sites ディレクトリがあります。sitesの下に各メイン名に同期したいディレクトリを作成します
- 例：sites/pine を作成します
sites/sites.phpファイルでドメイン名をディレクトと同期設定を行います
- 例： 'old-pine.net' => 'pine' （書き方：ドメイン名 => ディレクトリ名）
```
 $sites = array(
    'old-pine.net' => 'pine',
 );
```
新規作成したディレクトの下にサイトのインストール設定ファイル(settings.php)の作成
- 例：sites/pine/settings.phpを作成します
- settings.phpの内容はsites/pine/default.settings.phpのコピーで良いです（サイト新規作成する場合）
追加したドメイン名でサイトをアクセスして、新規サイトができたことを確認します

記事カテゴリ

タグ

やりたいこと：レンタルサーバーで申請したドメイン名を特定なディレクトリに同期するシンボリックリンク作成したいです

レンタルサーバー（例：valueserver）で申請したドメイン名を特定なディレクトに同期するツールが提供されています
同期ツールを利用するのは便利だが、設定が誤ると同期先のディレクトリのファイルがすべて削除されてします危険があります
特に、この操作がよく行うことではなく、誤って設定する確率は実は高そうです（実際に設定を誤って、同期先のファイルが消されてしまう事項がありました）

安全のため、シンボリックリンク作成コマンドでディレクト同期をしたほうがよいです

シンボリックリンク作成：
- public_htmlディレクトリ（apacheではdocument root）に入ります
- コマンド： ln -s [ディレクト名] [ドメイン名] （例：ln -s drupal7 old-pine.net）
- コマンド： ls -l　で生成したシンボリックリンクを確認します（例： old-pine.net -> pine）
シンボリックリンクの削除
- コマンド：unlink [ドメイン名] (例：unlink old-pine.net)
- コマンド：ls -l でドメイン名の同期先が消えたことを確認します

安全のため、コマンド(rm)でシンボリックリンクを削除しないこと

シンボリックリンクを削除するのはコマンド(rm)できますが、誤って指定すると、同期先のディレクトリの内容を削除していまう危険があります
シンボリックリンクを削除するには、コマンド(unlink)を使用すべきです

記事カテゴリ

タグ

モジュール（Feature）が開発ソース管理、コンテンツデータ移行などに利用されます

最初モジュール（Feature）が何に使うかはあまりわからなかったです（いろいろな説明がちゅ抽象的）。
実はDrupalの開発ソース管理（例：開発環境ー＞ステージん環境ー＞本番環境）、コンテンツデータの移行に使用されます

データ移行例：コンテンツデータ（Article）＋Viewsで作成したコンテンツ検索一覧画面

データ移行の簡単な例として、既存のコンテンツデータ（例：Article⇒記事）、Viewsで作成したコンテンツ一覧画面を移行します
コンテンツデータ移行に必須なモジュール：
- Feature
- Node Export （FeatureモジュールにサポートするNode export featuresサブモジュールを有効化）
Feature管理画面で必要なモジュール、モジュールの関連、コンテンツデータを選択して、一つのモジュールとして作成し、ダウンロードします
作成されたモジュール（tarファイル）を移行先で通常のモジュールインストールをして、有効化を行います。Feature管理画面で移行元の内容を適用、保存します
具体的な操作はビデオをご参考ください

FeatureがDurupalのすべての設定、構成の移行はできません

移行はモジュール単位で、構成は出力可能なものを中心にしています。以下は移行可能な部分
- Core ： Content Types、 Fields、 Menus、 Taxonomies、 Text formats、 Image styles、 User roles 、 permissions
- Contribute： Views、 CTools、 Context 、 Panels、 Rules 、 Contexts、 Display Suite
移行できない部分は、例：テーマ、コンテンツに挿入した画像などがあります
- コンテンツに含まるメディア（例：写真、ビデオ、ファイルなど）がローカル（sites/default/files）に保存したため、移行先の保存パス修正、およびメディアファイルのコピーが手動で行う必要があります

video

記事カテゴリ

タグ

Drupalの部分的なコンテンツデータを別のDrualサイトに移行する場合そのコンテンツの構造定義とコンテンツCSVデータのエクスポート／インポートができます

背景：Drupal7.54
Drupalのサイト引っ越しなどでデータ移行の必要があります、以下の移行方法はよく利用されます。
- Drupalのモジュール（Feature）を用いてサイト間のデータ移行/開発管理を行います (162)
- 同じDrupalバージョンの単一サイトを複数サイト（ドメイン）の一つDrupalの共有ソースサイトへの移行チャレンジ (161)
ただし、部分的なコンテンツしか移行しない場合、上記方法では難しくなります
ここで、コンテンツ定義とデータを別々でexport/import方法を説明します

Drupalのモジュール（Bundle copy、 Taxonomy CSV import/export）でコンテンツの構成／定義をExport/Importします

モジュール（Bundle copy）でコンテンツの構成／定義を簡単に移行します（具体的にステップは省略）
タクソノミーのタームの構成（フィールドが追加など）が変わらなければ、モジュール（、Taxonomy CSV import/export）でタームリストデータをcsvファイルの出力することはできます
- 出力したCSVデータの別のサイトにインポートする場合、タクソノミーのボキャブラリーとタームIDが変わった可能性があります
- コンテンツのフィールドに「Term Reference」タイプのものがあれば、コンテンツ追加／編集ボタンをクリックすると、「HTTP ERROR 500」エラーが発生するかもしれないです
- 一番簡単な対応方法ではそのフィールドを一回削除して、再作成すればよいです（データインポートする前の段階）

Drupalのコンテンツ構成（フィールド）テーブルのデータをcsvフォーマットに出力します

現時点ではコンテンツのデータをcsvに出力するモジュールはあまり見当たらにです
コンテンツのフィールドをDB上各テーブルを見つけ出します
- コンテンツ（例：Article）のフィールドごとに一つのテールが存在しています
- Title ➡　nodeテーブルの「title」フィールド
- body ➡　field_data_bodyテーブルの「body_value」フィールド（またはbody_summaryなど）
- カスタムフィールド ➡　field_data_CUSTOM_FIELD_NAMEの「field_data_CUSTOM_FIELD_NAME_value」フィールド
これらのテーブルを「node」テーブルを中心してジョインして、新しいテーブルの書き込みます
- すべてのコンテンツは「node」テーブルを基本にしています
- 各フィールドのテーブルに「entity_id」がnodeテーブルの「nid」の関連付けキーとなります
- 全フィールドと同じフィールドの新しいテーブルを一つ作成します（例：new_table）
- 全フィールドをJOINしてデータを新しいテーブル（例：new_table）にコピーします
```
INSERT INTO new_table (title, body, CUSTOM_FIELD_NAME,   ・・・・・・)
SELECT 
   title,
   body.body_value,
   T1.field_data_CUSTOM_FIEDL_NAME_value,
  ・・・・・・
FROM node
   left join field_data_body body on nid = body.entity_id
   left join field_data_CUSTOM_FIELD_NAME  T1  on T1.entity_id = nid
  ・・・・・・
  
```
新しいテーブル（new_table）の内容をｃｓｖフォーマットに出力します

Drupalのモジュール（Feeds Import）でコンテンツｃｓｖデータをインポートします

モジュール（Feeds Import）がよく利用されるものなので、簡単にｃｓｖデータを確認コンテンツにインポートすることができます
Feeds Importの説明は省略します(Drupalのモジュール（Feeds）で手動でデータインポート時の必須設定 (199)、FeedsモジュールでEnityにデータインポート (34)などを参考にしてください)

シリーズ記事一覧

記事カテゴリ

タグ

モジュール（Feature）が開発ソース管理、コンテンツデータ移行などに利用されます

最初モジュール（Feature）が何に使うかはあまりわからなかったです（いろいろな説明がちゅ抽象的）。
実はDrupalの開発ソース管理（例：開発環境ー＞ステージん環境ー＞本番環境）、コンテンツデータの移行に使用されます

データ移行例：コンテンツデータ（Article）＋Viewsで作成したコンテンツ検索一覧画面

データ移行の簡単な例として、既存のコンテンツデータ（例：Article⇒記事）、Viewsで作成したコンテンツ一覧画面を移行します
コンテンツデータ移行に必須なモジュール：
- Feature
- Node Export （FeatureモジュールにサポートするNode export featuresサブモジュールを有効化）
Feature管理画面で必要なモジュール、モジュールの関連、コンテンツデータを選択して、一つのモジュールとして作成し、ダウンロードします
作成されたモジュール（tarファイル）を移行先で通常のモジュールインストールをして、有効化を行います。Feature管理画面で移行元の内容を適用、保存します
具体的な操作はビデオをご参考ください

FeatureがDurupalのすべての設定、構成の移行はできません

移行はモジュール単位で、構成は出力可能なものを中心にしています。以下は移行可能な部分
- Core ： Content Types、 Fields、 Menus、 Taxonomies、 Text formats、 Image styles、 User roles 、 permissions
- Contribute： Views、 CTools、 Context 、 Panels、 Rules 、 Contexts、 Display Suite
移行できない部分は、例：テーマ、コンテンツに挿入した画像などがあります
- コンテンツに含まるメディア（例：写真、ビデオ、ファイルなど）がローカル（sites/default/files）に保存したため、移行先の保存パス修正、およびメディアファイルのコピーが手動で行う必要があります

video

記事カテゴリ

タグ

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コピーの方式は上級者向けですね。常にエラーの調査、修正にが必要となります

記事カテゴリ

タグ