2018年10月18日、昨日Drupal Core - Multiple Vulnerabilities - SA-CORE-2018-006というセキュリティアラートが出たので、お客様サイトを優先しつつ、関わっているDrupalサーバーのリビジョンアップを実施した。
Drupal 8.6.2リビジョンアップの作業
特に困ったのは、8.5.6で動かしていたこのBlogサイトだ。バックアップを取って、いつもの通り、
composer outdated
で確認した上で、
composer update --with-dependencies
で環境を更新した。
その後、
drush entup
drush updb
をやれば最新版の8.6.2になって終わり（entupは正常終了するまで繰り返し適用で今回は4回）なのだが、今回は2つの問題が起きた。
一つ目は、Google Adsenseが効かなくなった。少額とは言え広告料が入らなくなるから大問題だ。二つ目は、タグが表示されなくなった。これもDrupal関連の記事一覧とかが見られなくなるのでうれしくない。
まずは、セキュリティ問題を起こさないために一旦8.5.8に上げる事にした。Google Adsenseは動くし、タグも表示される。ただし、drush updbはエラーが出る。とはいえ、この段階で良い事にしてページは公開状態にした。
原因分析と対処
いずれにしても、やがて8.6に上げるので、8.6.2で原因を調べて見ると結局以下の３つの問題に引っかかっている事が判明した。
Custom blocks are no longer displayed and no longer appear in the custom block library
Orphan term hierarchy records can cause taxonomy_update_8502 to enter an infinite loop
Primary language taxonomy terms unpublished during 8.6.0 upgrade
1. Google Adsense問題
この問題は、Custom blocks are no longer displayed and no longer appear in the custom block libraryのカスタムブロックライブラリが表示されなくなる問題が原因である。
げっ、Google AdsenseもSocialログインも消えている、という事から、
ホーム > 管理 > サイト構築 > ブロックレイアウト > カスタムブロックライブラリ
を確認するカスタムブロックが丸ごと消えている。という事で、
update drupal 8.5 to 8.6 block
でググって見ると、上記の記事にたどり着いた。30分位だろうか。読み込んでいくと、これがentup/updbで走らせるべきデータパッチの不具合であることが理解できた。さらに、記事♯9にワークアラウンドが出ている。
drush sqlq "update block_content_field_data set reusable = 1;"
当サイトの場合、全部に適用しても問題なさそうだし、とにかく適用して見ると、無事各カスタムブロックが復活した。内容から言って、副作用もなさそうなのでこれで解決とした。
2. タグ消失問題
updbでtaxonomy_update_8502が失敗するので、まずこの問題を解く必要がある。ググるとOrphan term hierarchy records can cause taxonomy_update_8502 to enter an infinite loopが見つかるので、読んでみると、どうやら何らかの理由でゴミがたまっているとアップデートに心配するらしい。当サイトではボキャブラリは3つ、タームは計20弱しか使っていないが、いろいろ実験してみているので途中で何かやらかしていたのだろう。
記事#45にパッチがついているので、このパッチを当て、正常稼働していた8.5.6のDBに戻した上で、entup/updbをかけると無事正常終了。めでたし、めでたし、と思った。管理者でログインしている限りは予期したとおりの挙動になる。しかし、ログアウトしてる状況では、やはりタグが出ない。データは消えていないが、一般ユーザーからは見えない状況になってしまっている。
3. タグ非掲載(unpublish)問題
さらにググるとPrimary language taxonomy terms unpublished during 8.6.0 upgradeが引っかかった。当サイトは日本語単一環境なので、表題はそのものずばりには思えないが、非掲載状態になっているという症状は明らかに怪しい。読み込んでも汎用的なワークアラウンドは見つからない。当サイトではボキャブラリは３つ、タームは２０弱しか使っていないので、手作業でも良いやと思って、この記事を参考にして対処することにした。
Nodeと異なりTermの掲載状態は、通常の管理画面では確認できない。上記の記事を読むと、翻訳管理の中で当該翻訳の掲載(publish)状態が悪さをしているらしいことが分かる。日本語単一環境だといじれないので、言語に英語を足し、Content Translationモジュールを有効化する。適当なタームを選んで編集しても掲載状態は見えないが、そのタームの英語の翻訳を（値はそのままで）作成すると「この翻訳を掲載」が出てくる。保存して、日本語の方を編集すると、今度は翻訳の属性が現れ、ここでオフになっている「この翻訳を掲載」をオンに変えて保存すると、ログアウト状態でもそのタグが見られるようになった。
次いで、英語の翻訳を削除すると掲載状態のまま日本語だけが残る。美しくはないが、約30のタームに対して同様の操作を行い、動作を確認して、最後にContent Translationモジュールを無効化して、英語を言語セットから外した。これで、正常化したと考えているが、また何かゴミは残ってしまっている可能性はあるだろう。将来、別の問題として発症するかも知れない。
所感と考察
Drupal 7は良く枯れていて、私は最近リビジョンアップで問題に当たったことは無い。一方、Drupal 8は残念ながら、リビジョンが変わるといろいろと不具合が出る。8.0.0が出たのが2015年11月19日なので、既にほぼ3年が経過している。この事実は重い。7.0.0が出たのは2011年で3年後の2014年には、今のD8に比べれば安定度は高かったと思う。もちろん今のD7と比較すれば、いろいろ面倒は多かったから、D8もやがて安定度を増すだろうと期待している。
おまけと今後
当サイトはさくらのクラウドで小さな環境（サーバー一台）で動かしている。お客様のものではないので、安易に本番環境で手を入れているが、ちょっと工夫すれば、丁寧なテスト環境を再現できる。もう一台、サーバーを立ち上げてIPアドレスを確保しておき、稼働中の本番からアーカイブを作って、そこからディスクを作成し、テスト用のサーバーのディスクと入れ替えれば簡単にクローンが作れる。ネットワークインタフェース(/etc/network下)をコンソールで入れ替えれば、そのまま使えてしまう。しかも、休眠させているサーバーはディスク以外課金されない。
改めて便利な時代になったと思うのである。今まで、今回のような面倒には直面してこなかったので、テスト環境をあまり真剣に考えてこなかったが、自社環境、個人環境であっても、もう少し環境を考えておいた方が良いと思う。コンテナを使うのも一興だろう。