D6 to D7 アップグレード実施とその後

先日、Drupal6.22からDrupal7.8にアップグレードした際の手順とその後について記載します。

このサイトでは、D6⇒D7⇒D6⇒D7⇒D6と2度アップグレードを試しましたが満足いく結果にならなかったのもあり、現在はDrupal6で稼動しています。

アップグレード手順自体は通常のDrupal6コアのマイナーバージョンのアップグレード手順と大筋は変わりません。
大変なのはサイトにあったアップグレード手順を選定するための情報収集などの調査です。

参考サイト:Upgrade process

作業前準備

1.事前に以下のバックアップが完了しているとして進めます。

(1)Drupalシステム

Drupalファイルシステムにある独自のファイルはファイルサイズが膨大なためシステムとは別にバックアップを取得したほうがリストアのときに便利です。

(2)Drupalデータベース

mysqladminやmysqldumpなどで取得します。

2.念のためcron.phpのスケジュール実行を停止しておきます。

3.不要モジュールのアンインストール

Drupal7で使用しないモジュールもしくはアップグレードに対応していないため一旦アンインストールが必要なモジュールは事前にアンインストールを済ませておいてください。
※アンインストール(admin/build/modules/uninstall)のページから操作してください。
※アンインストールに未対応のモジュールは一覧には表示されません。
※すべてのモジュールがアンインストールに対応しているわけではないので、アンインストール方法はモジュールごとのドキュメントを参照してください。
※アンインストール工程が必要ないモジュールの場合は削除するだけになります。
※アンインストールする行為はデータベース上の関連テーブルや独自データ自体が削除されてしまい、D7アップグレード後には新規モジュールインストールおよびデータの登録をしないと元に戻せないことを意味していますのでミスがないようにしてください。
※CCKのmigrateの対処となるモジュール(フィールド関連のモジュール)はアンインストールしないでください。

※その他、D7コアにアップグレード後にモジュールのアップグレードをするモジュールはアンインストールしないでください。

4.キャッシュ機能の停止とキャッシュクリア

パフォーマンス(admin/settings/performance)ページでキャッシュの設定を無効にしておくほうがよいと思います。
また、以下手順6までにキャッシュクリアを実行しておいたほうが良いと思います。
※手順6でDrupalのファイルを削除してしまうのでDrupalシステムを利用できません。

Drupal7へのアップグレード

手順1.ID1の管理ユーザでログイン

Drupalインストール時に作成された管理ユーザ(ユーザID番号=1)でサイトにログインします。

手順2.サイトをメンテナンスモードに変更

※サイトメンテナンス(admin/settings/site-maintenance)にアクセスして操作します。
drupal_20110921001

手順3.テーマを変更

デフォルトのテーマを「Garland」に変更します。
※「テーマ(admin/build/themes)」にアクセスして操作します。
drupal_20110921005

手順4.モジュールの無効化

コア(必須)とコア(任意)以外のすべてのモジュールを無効に設定します。
※モジュール(admin/build/modules)にアクセスして操作します。
drupal_20110921003
drupal_20110921004

ここからの作業は転送ソフトの機能かサーバにリモートログインして作業することになります。

手順5.「default.settings.php」ファイルを削除

「sites/default/default.setting.php」ファイルを削除します。

手順6.Drupal6コアのファイルとディレクトリを削除

削除するのは以下のファイルとディレクトリです。

cron.php
includes
index.php
misc
modules
profiles
scripts
themes
update.php
xmlrpc.php
※以下は任意
CHANGELOG.txt
COPYRIGHT.txt
INSTALL.mysql.txt
INSTALL.pgsql.txt
INSTALL.txt
LICENSE.txt
MAINTAINERS.txt
UPGRADE.txt
※さくらのレンタルサーバではindex.phpを削除した時点でディレクトリ一覧が表示されてしまうと思います。
※以下は念のためローカルPC上にコピーしてください。
.htaccess
※このファイルをディレクトリから削除した瞬間にアクセス制限などが無効になり外部から直接ファイルにアクセスできてしまう可能性がありますので削除しないほうが安全です。さくらのレンタルサーバの場合は、空のindex.htmlファイルを作成しておけば少しはましかもしれません。
robots.txt 
※robotstxtモジュールを導入している場合は設定画面の内容をコピーしてください。

手順7.モジュールファイルを削除

※この作業をすすめるには事前に不要なモジュールかどうかの選定作業が必要です。

関連記事:D6 to D7アップグレード検討と健闘

アンインストールしたモジュールや不要なモジュールは削除してください。
モジュールは「sites/all/modules」または「sites/*/modules」にあります。
※ここで*(アスタリスク)はall以外の文字列を意味しています。通常はallですが、allは優先順位が一番低いのでその他のディレクトリ以下にmodulesがあればそちらが優先して使われますがallのしたのmodulesも利用されます。通常は*の部分はドメイン名です。会社をイメージして組織単位(支店-本店や各部署-全社)で使用可能なモジュールを階層で権限により管理することを想定していると考えればわかりやすいと思います。

手順8.Drupal7コアモジュールの配置

ダウンロードしたDrupal7コアモジュールを解凍しDrupalディレクトリに配置します。
※配置するのは解凍したフォルダ内のすべてのファイルとディレクトリです。
※robots.txt以外の拡張子が「.txt」のファイルは特に必要ありません。

手順9.サイト個別ファイルを編集

手順8の「robots.txt」と「.htaccess」をサイトにあわせて編集します。
※編集は先ほど手順6でローカルPCに退避させたファイルを参考にしてください。
※D7のファイルにマージするのがお勧めです。

(1)robots.txt

検索エンジンが参照するファイルなので、アップグレードには直接は関係ないと思いますので事後でも編集はOKです。
robots.txtファイルのD6とD7のデフォルトの状態の比較(D7で追加された分)

33行目 Disallow: /INSTALL.sqlite.txt
44行目 Disallow: /filter/tips/ 
50行目 Disallow: /user/logout/
54行目 Disallow: /?q=filter/tips/
60行目 Disallow: /?q=user/logout/
(2).htaccess

アクセス制御やRewiteRuleなどの影響でアップグレードプロセスが正常に進行しない可能性がありますので必ずサイトにあわせて編集してください。

以下はさくらインターネットのレンタルサーバでの設定例です。
この設定を間違えると、同じユーザIDで公開している他のサイトにも影響がありますので注意してください。

11行目をコメント

Optionsディレクティブが使用不可の対応

# Don't show directory listings for URLs which map to a directory.
#Options -Indexes
14行目をコメント

Optionsディレクティブが使用不可の対応

# Follow symbolic links in this directory.
#Options +FollowSymLinks
26行目に/index.phpを追加、index.htmlとindex.htmは削除(あっても問題ないはず)

Options -Indexes(11行目)を無効化した対応(ディレクトリ以下の一覧表示をさせない)

# Set the default handler.
DirectoryIndex index.php /index.php

以下はmod_rewriteが利用可能なApacheサーバのみに有効

78行目をコメント

ダウンロード制限のようですがよくわからなかったのでコメントにして無効化

#RewriteRule "(^|/)\." - [F]
93行目と94行目をコメントにし、95行目と96行目に追記

「wwwあり」を「wwwなし」にリダイレクトして検索エンジンで統計が分散されないようにする対応(SEO対策)
※この設定ではコメントにあるように「wwwなし」から「wwwあり」へはリダイレクト不可。
※さくらのサーバコントロールパネルのドメイン設定と矛盾のないようにしてください。

#RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
  #RewriteRule ^ http://%1%{REQUEST_URI} [L,R=301]
  RewriteCond %{HTTP_HOST} ^www\.phoenixknight\.jp$ [NC]
  RewriteRule ^(.*)$ http://phoenixknight.jp/$1 [L,R=301]

※さくらのレンタルサーバでは、Apacheのドキュメントルートはphoenixknight.sakura.ne.jpサイトに使用しているのでデフォルトのままだとそれ以下のローカルディレクトリにあるサイトがすべてphoenixknight.jpにリダイレクトされる可能性があります。そのためドメイン名を追加してルール適用をこのサイトに制限させています。

以下はデフォルトの行数から2行ずれています。
※98行目から106行目のRewriteBaseを利用する場合は、上記ドキュメントルートの場所を考慮しないとおかしな動作をします。
※たとえば106行目の「RewriteBase /」を有効にすると、ホームディレクトリ/wwwに置き換わるのでDrupalルートディレクトリとは別の場所になってしまいます。
※もし指定する場合はDrupalルートディレクトリをサーバローカルの絶対パスで記述すればうまくいくはずです。

113行目を「/index.php」に変更

108行目~113行目はDrupal6のときとは目的が変わっているようなのでDrupal7オリジナルに修正を加えました。
※Drupal6のときはRewriteによりクエリが取り除かれないようにとのコメントがありましたが、Drupal7ではコメントが変わっているのでできるだけそのままで使用するようにしました。
※Drupal6のときも「index.php」を「/index.php」へ変更したのみでした。

# Pass all requests not referring directly to files in the filesystem to
  # index.php. Clean URLs are handled in drupal_environment_initialize().
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteCond %{REQUEST_URI} !=/favicon.ico
  RewriteRule ^ /index.php [L]

※この箇所をDrupal6の記述(  RewriteRule ^(.*)$ /index.php?q=$1 [L,QSA] )にしたときだったと記憶していますが、環境設定(admin/config)のページ表示不可(Internal Server Error 500がでたりでなかったりで表示はできず)とサイトの状態(/admin/reports/status)ページの表示が異常に遅く「Internal Server Error 500」が発生しました。
※ちなみにadmin/config以下のたとえばパフォーマンス(admin/config/development/performance)ページに直接URLを指定してアクセスする場合にはすぐに表示できました
※もともとサイトの状況のページのアクセスは他に比べえ遅かったのでphp.iniに「max_execution_time=120」を追記しました。
※「さくらのサーバコントロールパネル」からエラーログの表示をすれば、リアルタイムでApacheサーバのエラーログをチェックすることで確認できます。

ループが発生しているケースでのエラーログのサンプルです。メッセージからループの最大値に到達していることがわかります。

mod_rewrite: maximum number of internal redirects reached. Assuming configuration error. Use 'RewriteOptions MaxRedirects' to increase the limit if neccessary.

「.htaccess」と「robots.txt」以外は、サーバの環境次第では「php.ini」の編集が必要になるかもしれません。
たとえばデータベースサーバにあわせてMySQLの場合であれば「extension=php_pdo.dll」と「extension=php_pdo_mysql.dll」が必要になったりするケースもあります。
※さくらのレンタルサーバではこれらを指定してしまうとextensionsには存在しないのでエラーになります。phpinfoを見る限りではデフォルトでDSOサポートのようです。
それ以外にも「max_execution_time」や「memory_limit」の値を変更しないとアップグレードプロセス中に制限値を超えてしまいエラーで処理が中断する可能性もあります。

手順10.「settings.php」のパーミッション変更

「sites/default/settings.php」あるいは「sites/ドメイン名/settings.php」ファイルのパーミッションを変更し書き込み可能な状態にします。
これは、アップグレードプロセス中にサイトの「settings.php」にD7用の記述を追記するためです。
対象ファイルは実際にサイトで使用されている「settings.php」ですので、初期インストール時に入力したデータベースサーバ名やユーザ名、パスワードが記載されているものになります。
コアのアップグレードが完了すると「settings.php」のファイル末尾にD7用の$databaseと$drupal_hash_saltが追加され、パーミッションも変更されます。

手順11.コアのアップグレードの実行

(1)update.phpのアクセス制限解除

通常はID=1の管理ユーザとupdete実行権限をもつ管理ユーザがupdate.phpを実行できるようになっていますので不要に思いますが、実際にはアクセス制限を解除してフリーにしないとupdate.phpが正常に動作しないケースがあるようです。※(2)のVerify requiementsでエラーになります。
手順10でパーミッションを変更した「settings.php」をテキストエディタで編集して「$update_free_access = FALSE;」を「$update_free_access = TRUE;」に変更します。
ファイル転送ソフトで編集する場合は通常はパーミッションの影響で変更内容が保存できませんが、手順10で書き込めるようにしてあるのでそのまま保存できるはずです。
viエディタで編集する場合は「:w!」で強制上書き可能ですが今回は不要です。
ファイルを編集後はかならずファイルを閉じておいてください。

(2)update.phpの実行

ブラウザのアドレスバーに「サイトドメイン名/update.php」と入力してupdate.phpを実行します。

実行が開始されると以下の順序で処理されます。
・Verify requiements(要件のチェック)
・Overview
・Review updates(アップグレード内容の表示)
「Apply pending updates」ボタンをクリックするとアップデートが実施されます。
drupal_20110921006
・Run updates(アップグレードの実施)
・Review log(実行結果の表示)
drupal_20110921007

表示される実行結果に目を通し問題なければ次の2箇所もチェックしておいたほうが良いと思います。
・サイトの状態(admin/reports/status)
・最近のログ(admin/reports/dblog)

※php.iniのerrorlevelの設定値および管理画面のエラー表示の設定によってはメッセージが大量に出ている可能性があります。
※Drupalの管理ページにも出力するエラーメッセージの種類を設定できますが、php.iniのほうはE-ALLにして管理画面で調整するのがおすすめかもしれません。

Drupal7コアの一覧

drupal_20110921002
drupal_20110921008

手順12.データベースのバックアップ

次の作業でデータベースが破損してしまう可能性があるため、その場合に備えてデータベースのバックアップを取得します。

手順13.フィールドのmigrate

参考サイト:Learn more about migrating content from CCK to Core Fields.
(1)最新バージョンのCCKモジュールをダウンロードして入手します。
(2)CCK Content Migrateモジュールを有効にします。

drupal_20110921009

(3)Migrate Fields ページを表示します。(admin/structure/content_migrate)

Available Fields
※Migrate可能なフィールドがない状態です。
drupal_20110921010

Converted Fields
※Migrate実施後のフィールドタイプとコンテンツタイプです。
drupal_20110921011

Unavailable Fields
※赤色で囲んだ箇所がAvailable Filedsにするための条件になります。
drupal_20110921012
drupal_20110921013

(4)Migrate可能条件になっているモジュールを入手します。

Unavailable Fieldsの一覧にあるフィールドをMigrateの可能な状態にするためには、Maigrate先になるモジュールが必要になりますのでMigrate Fieldsページを参考に必要なモジュールをダウンロードしてモジュールを「sites/all/modules」もしくは「sites/*/modules」に配置します。

(5)ダウンロードしたモジュールを有効にします。

モジュール(admin/builds/modules)を表示して配置したモジュールを有効にします。

(6)Migrate Fieldsの実行

条件を満たせばUnavailable Fields欄からAvailableFieldへ移動しますのでMigrate可能な状態になっているはずです。

※Unavailable Fieldsに表示されているフィールドがすべてMigrate完了するまで(3)から(6)を繰り返します。一度にすべて実行することも可能です。

手順14.モジュールとテーマのアップグレードの実行

参考サイト:Upgrading contributed modules and themes from Drupal 6 to Drupal 7
(1)各モジュールに付属しているUPGRADE.txtをチェックします。
(2)site/all/modulesからD6モジュールを削除します。
(3)sites/all/modulesにD7モジュールを配置します。
(4)update.phpの実行

手順15.レポートをチェック

手順16.update.phpのアクセス制限

「sites/all/setting.php」を編集して、「$update_free_access = TRUE;」を「$update_free_access = FALSE;」に戻します。
※コアのアップグレード完了後は「settings.php」のファイルパーミッションが変更され書き込み権がなくなっていると思いますので、強制書き込みできる方法をとるか一旦書き込み権を与えてからでないと変更内容を保存できません。
 

手順17.メンテナンスモードを解除

オフラインモードからオンラインモードに変更し、メンテナンスモードを解除します。

以上でアップグレードは終了です。



導入後の不都合

導入後に発生した不都合についてピックアップしておきます。
一部、上記アップグレード手順の中と重複する箇所もあります。

(1)tokenモジュールのエラー

事象:サイトの状態(admin/reports/status)でtokenのエラーが表示される

以下のようなエラーです。
drupal_20110921014

対処:tokenモジュール(token-7.x-1.0-beta5)内の「token.tokens.inc」を差し替え

以下のサイトから「token.tokens.inc」をダウンロードして差し替えで改善しました。
http://drupalcode.org/project/token.git/commit/f147805

tokenモジュールに関しては新規インストール(D6で一旦削除)とアップグレードの2通りを実施しましたが、どちらの場合も発生しました。
ただし、D7コアを新規でインストールした場合には発生しなかったようです。
※tokenモジュール自体はモジュールメニューのアンインストールには対応していないらしく削除してからD7にしてもあまり意味がないのかもしれません。
 

状況:解決済み

(2)tokenのNoticeメッセージ

事象:最近のログメッセージ(admin/reports/dblog)にtokenのNoticeメッセージが出力される。

1回目のアップグレードで発生していましたが、詳細メッセージを失念してしまいました。(1)の対処をしても改善はしません。

対処:未対応
状況:未対応

(3)Undefined indexのNoticeメッセージ

事象:最近のログメッセージ(admin/reports/dblog)にUndefined indexのNoticeメッセージが出力される。
# Notice: Undefined index: name in system_requirements() (line 40 of 【省略】/modules/system/system.install).
対処:Drupalルートディレクトリ直下のprofilesを残したままコアのアップグレードを実施

1回目のアップグレードではD6で使用していたprofilesフォルダを削除してD7のprofilesに置き換えてしまってました。
それがダメだったらしく、初期インストール時のプロファイル(default)がなかったためにうまくコアのアップグレードができていなかったようです。
なお、アップグレード手順には反映しました。

※profilesフォルダは無関係のようです。アップグレード時の状態が1回目と2回目で異なっていたようで、実際は何が影響していたのかは不明です。
また、D7になるとコンテンツに「Article」と「Base Page」ができるはずですが、アップグレードのたびにこれらができたりできなかったりでした。これらが作成されていないときに上記のエラーがでているようにも思えますがはっきりとしたことが言えません。

状況:解決済み

(4)PDOException: SQLSTATE[XXXXXX]:のメッセージ

事象:最近のログメッセージ(admin/reports/dblog)にPDOException: SQLSTATE[xxxxxx]:関連のメッセージが出力される。

1回目のアップグレードではできるかぎりContribモジュールはアンインストールしたのちアップグレードしましたのでこのメッセージは出力されませんでした。
上記メッセージは、2回目のできるだけContribモジュールを残して(アップグレードすること前提)で行った際に発生しました。

対処:D6モジュールからのアップグレード忘れが原因の場合が多く、D7モジュールにアップグレードして対応

特にViewsを使ったページなどを表示する際に発生するようで、該当モジュールをD7にアップグレードすれば改善しました。
ただし、D7モジュールがないなどアップグレードに対応していない場合はどうしようもないかもしれません。
アップグレード忘れが原因でない場合は、モジュール個別の別の原因も考えられます。

状況:解決済み

(5)Dateフィールドが削除できない

事象:D6の管理画面からフィールド一覧を表示しても存在しないフィールドがCCK Migrate時には一覧に表示される。

サイト立ち上げ当初、Calanderモジュール+dateモジュールを導入した経緯があり、すでにアンインストールしていましたが、アンインストール手順がわるかったのかdateウィジットを使用しているフィールドがデータベース上(content_node_filedとcontent_node_field_instance)に存在しているため、CCK Migrate一覧に表示されてしまいます。

対処:D7アップグレード前のD6の状態で該当データベース内のdateに関するエントリを削除

CCK Migrate一覧に残ってしまうだけで害はないと思いますが削除しました。
ちなみに、CCK Migrateでは存在するフィールドをすべて対象と考えているので不要なものは削除しておくべきだと思います。このときフィールドが使用しているウィジットも考慮しないとContribモジュールによってはDateモジュールのようにカスタムウィジットを使えるようにするものもあります。また、フィールドを使用しているコンテンツタイプが作成されてしまいますので複数のコンテンツタイプで併用されているフィールドが不要なものであってもMigrateしてしまうと、それが登録されているコンテンツタイプすべてが作成されてしまいます。

状況:解決済み

(6)特定の管理ページが表示できない

事象:環境設定(admin/config)とサイトの状態(admin/reports/status)のページがいつまで経っても表示できないもしくは「Internal Server Error 500」になる。

どちらも他のページの表示よりは少し遅いかな程度の印象でしたが、全く表示できなくなってしまいました。
環境設定(admin/config)に関しては、その下位ページを直接URLで指定すれば問題なく表示できます。
なお、この事象はアドレスに直接入力してアクセスしたケースとメニューからアクセスしたケースの両方で同じ症状になります。
 

対処:「.htaccess」に記載したRewriteRuleの影響でループが発生していたらしく修正しました。

ループが発生している場合は、Apacheサーバのエラーログに以下のメッセージが出力されていました。

mod_rewrite: maximum number of internal redirects reached. Assuming configuration error. Use 'RewriteOptions MaxRedirects' to increase the limit if neccessary.

サイトの状態(admin/reports/status)に関しては、表示が遅い場合があるのでPHPの「max_execution_time」の値を調整する必要があるかもしれません。

状況:解決済み

その他、メッセージの詳細は失念しましたが、最近のログメッセージに「includes/cache.inc」関連のメッセージが出力されていました。
これは2回目のアップグレード後に発生していましたが、update.php実行直後からErrorメッセージが3個(同じincファイルのエラー)が発生しているにもかかわらず、そのまま実行したことに関係しているのかそれともキャッシュをクリアせずに実施したことに関係しているのかなど推測できますが、よくわかりません。
とりあえず手順にはキャッシュクリアしてからアップグレードするようにしてあります。

(7) 「PHP Notice:  unserialize() function.unserialize Error」 のメッセージ

事象:「PHP Notice:  unserialize() function.unserialize Error at offset 109 of 1122 bytes in 【Drupalルートディレクトリ】/includes/bootstrap.inc on line 555」のメッセージが出力される。

以下の画像が実際のメッセージです。毎回3行セットで出力されます。
drupal_2011100701

Drupal6のときには操作画面にもログレポートにも表示はされていませんでしたが、2回目のupdate.phpを実行するときから出力されるようになり何かの操作をするたびに画面に表示されるようになりました。

原因:Variableテーブルの不具合

Variableテーブル内に不都合があると上記のメッセージが表示されるようです。

対処:原因箇所を調査し、その箇所を直接削除

Drupal6のころからも出ていたメッセージのようで、現在稼動しているDrupal6でもメッセージをファイルに出力していましたがずっと出ているようです。必ず3行セットで出力されます。
VariableテーブルをチェックするモジュールがD6およびD7ともにありますので、それを導入してチェックを実行(admin/reports/variablecheck)しました。

以下のように3箇所がチェックにひっかかりました。(3行同時に出力されるのと一致)
drupal_2011100801

原因の箇所はzenテーマに関連するものですが、以前、一時的に導入した記憶はありますが削除しました。
そのときのものらしいのですが、この中身をみるとパンくずリストのセパレート文字の箇所が文字化けしています。おそらくこれがメッセージの原因だと思います。
※ほかにもzenに関係するデータが格納されていますが相違点は文字化けした文字の有無です。

原因箇所の削除は、D7の場合はvariablecheckから削除できるような表示になっていますが削除はできませんでした。また、「Check Variable System」メニューの下位メニューに「Delete System Variables」がありますが、こちらはFormがないらしく表示でエラーになってしまいましたので、削除はデータベースに直接アクセスして削除するしかなさそうです。
※削除前には必ずデータベースのバックアップをとってからにしてください。以前、SystemテーブルやValiableテーブル内の使っていないモジュールのデータを削除したためにupdate.php実行時のVerify requiementsでFatalエラーが発生したことがあります。致命的なエラーですので作業をすすめることは不可能になります。

Delete System Variables(D7)
drupal_2011100802

状況:解決済み

補足:D7にアップグレード後にメッセージの出力が増えてしまうのはおそらく「ログとエラーメッセージ」(admin/config/development/logging)の設定の影響だと思います。Drupalで設定しているエラーに関する設定は操作画面(標準出力または標準エラー出力)に表示するメッセージを選択するものだと思います。PHPの設定で行う「error_reporting」のレベルとはまた別物だと思いました。イメージではis_set()関数やerror_reporting()関数などで表示を制御しているような・・・
なお、Drupal6のエラー報告(admin/settings/error-reporting)では、出力先をログメッセージと画面とで変更できるだけでしたので、エラーレベルを変えることは管理画面からはできませんでした。
Noticeのメッセージは、Drupal7にアップグレードして気付くこともあるのかもしれません。ただ、NoticeのメッセージはPHPが実行されただけでも表示されるケースがあるようですので必ずしも対処が必要とは限りません。それゆえにNoticeなのだと思います。

※現在はDrupal6で稼動しています。D7での稼動は途中までうまくいっていましたが、ローカルの動画アップロードで不都合があり、致命的だと判断してD6に戻しました。内容はAcquia Dev Desktop環境では気付けない事項です。