GCPへのWordPress移行でAll in one Migrationが100%のまま動かない

###はじめに

Local by Flywheelで開発を行い、GCP(Google Cloud Platform)にAll in one Migrationでデータを全て移行しようと試みたが、データが移行出来ませんでした。今回はその対応方法についてまとめます。

---

###対象となる読者

All in one Migrationを実行しているのに、100%からプロセスが進まない方。

---

###環境
Local by Flywheel
- WordPress 5.8.3
- php 8.0.0 (Supports 64bit values)
- Server version    mysql 8.0.16
- Server architecture	Darwin 21.1.0 x86_64
- Web server	Apache/2.4.43 (Unix)
- Theme Divi 4.14.6

GCP
- WordPress 5.8.3
- php 7.4.27 (Supports 64bit values)
- Server version	10.3.32-MariaDB
- Server architecture	Linux 4.19.0-18-cloud-amd64 x86_64
- Web server	Apache/2.4.52 (Unix) OpenSSL/1.1.1d
- Theme Divi 4.14.6

---

###結論

結局All in one Migrationのみでの移行は出来ませんでした。そのためDBの情報はAll in one Migrationで移行し、残りのデータ(wp-content)はFTPで移行しました。

---
###問題の詳細
####WordPressにアップするファイルサイズの上限を引き上げる

今回WordPressのホスティングにはWordPress Certified by Bitnami and Automatticの仮装マシンを使用しました。

![WordPress Bitnami.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/170254/14796065-80db-99af-686f-6f8f4a06b9e3.jpeg)

Bitnamiではファイルアップロードの上限がデフォルトで80MBだったため、まずはphp.iniから対象の箇所を操作しました。
php.iniの操作はGCPの管理画面からSSH接続して行います。
仮装マシンによってはファイル構成が違うので、findコマンドで検索をするのが良いです。

```shell
sudo find / -name php.ini
```
Bitnamiの場合は `/opt/bitnami/php/etc/php.ini` のファイルで以下の内容をnanoコマンドで書き換えました。

```shell
sudo nano /opt/bitnami/php/etc/php.ini
```

- upload_max_filesize = 512M
- post_max_size = 512M
- memory_limit = 256M
- max_input_time = 500

ファイルを保存するだけでは、WordPressの管理画面でファイルアップロードサイズは変更前のままで、更新されません。ファイルの変更を反映させるためにはサービスをrestartする必要があります。

```shell
sudo /opt/bitnami/ctlscript.sh restart
```

BitnamiではなくClick to Deploy of WordPressなどの仮装マシンを使っている場合は、コマンドが変わります。詳しくはこちらのブログが参考になりました。

https://www.bloggerlessons.com/amp/increase-wordpress-file-upload-size-limit-on-gcp/

#### All in one Migrationが100%から進まない

GCPに移行させようとしていたファイルは120MB前後と、upload_max_filesizeの上限以下でした。しかし100%になった状態からどれだけ待てど、プロセスは進みませんでした。

ただ、100%になった時点で管理画面のConsoleから413のErrorが起こっていることを発見しました。

![All in on Migration Console](https://gyazo.com/9f38a2f1c975b0e1b7c385647ee9cc45.gif)

Consoleのエラーから他のリファレンスを確認すると、どうやらphp, mysqlのversionの違いによる影響や、`all-in-one-wp-migration-file-extension` の使用で解決される例もありました。残念ながら `all-in-one-wp-migration-file-extension` は2021年8月に無料ダウンロードは終了しておりました。涙

そこで今回は **DBのみAll in one Migrationで移行、他はFTPでwp-contentで移行**という手法を取りました。

#### All in one MigrationでDBのみExport

![WordPress All in one Migration.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/170254/391a38c6-0400-4211-59b8-1fb86ff905a7.jpeg)

All in one MigrationのオプションでDBだけを移行するために、不要な箇所にチェックボックスを入れてDBの情報を書き出します。

#### GCPのwp-contentをFTPで入れ替える

GCPのVMインスタンスにFTP接続する方法については [GCPのVMインスタンスにssh接続しFTP, PhpMyAdminを利用する](https://qiita.com/bonjour_ken/items/6362c7525b4861a6d933)を参照ください。

FTPから権限がなく、wp-contentをアップ出来ない場合は、適宜権限を変更して、ファイルをアップしましょう。こちらの[GCPでFTPが拒否された場合](https://rencontru.com/blog/2020/04/09/gcp-ftp/)の記事が役に立ちました。

#### テーマの見た目が崩れる
ファイルが無事にアップ出来てこれで一安心と思いきた、Diviで作成したフロントが大いに崩れていました。スーパーリロードをしても直らない。Divi Builderで確認すると問題ない。
最終的な原因は`wp-content`の中に作成されている`et-cache`の影響でした。

```shell
/opt/bitnami/wordpress/wp-content/et-cache
```

この中に出来ていたディレクトリ、ファイルを削除することで見た目が崩れる問題が解消出来ました。

###最後に一言
**All in one Migration**はWordPressの引越しで大変便利ですが、移行先のServerの影響でスムーズに動作しないこともあるので、同じエラーに出くわした方にとって、この記事が少しでも役に立てば嬉しいです。