井上 研一 以前にDockerでWordPressの開発環境を作る方法について書いたのですが、その続きといえば続きで、巨大なWordPressサイトのwordmove（pull）でいろいろ困ることがあったので、その対応方法について書いておきます。
完全に、将来の自分のための記事ですね。他のどなたかのお役に立てば幸い。
uploadsディレクトリをどうするか
巨大なWordPressサイトなので、uploadsディレクトリも巨大です。ここはスパッと諦めるというのが良いかと思います。
WordPressサイトの改修をやっていて、ユーザーが投稿した画像とかのファイルが手元にないと作業できないということは、まずないと思うので。なので、wordmoveのpullオプションから、-uを外します。
wordmove pull -p -t -d
まずは、プラグイン、テーマ、データベースで良いかと思います。-w（WordPress本体）や-l（翻訳ファイル）もpullするかはケースバイケース。
データベースのpullから巨大なテーブルを除外する
ログ系とか分析系のプラグインが巨大なテーブルを作っていることがあります。そのテーブル自体がないとWordPressサイトが動かないとかなら仕方ありませんが、そうでないならwordmoveでpullする際にそのテーブルを除外する方法があります。
wordmove.ymlのデータベースの設定で、mysqldump_optionsに除外したいテーブル名を列記します。（他の項目は、Dockerを使って開発環境を構築しているので、それに沿った設定になっていますが、ここはテーブルの除外とは関係ありません。）
database:
name: "<%= ENV['PRODUCTION_DB_NAME'] %>"
user: "<%= ENV['PRODUCTION_DB_USER'] %>"
password: "<%= ENV['PRODUCTION_DB_PASSWORD'] %>"
host: "<%= ENV['PRODUCTION_DB_HOST'] %>"
mysqldump_options: "--default-character-set=utf8 --ignore-table=データベース名.除外したいテーブル名"
MySQL server has gone awayになる
pullしている最中に、MySQL server has gone awayのエラーになることがあります。大抵、max_allowed_packetの設定が問題です。
Docker（compose）で環境構築している場合、docker-compose.ymlに下記の設定を追記します。
この、max_allowed_packetの行だけですね。
mysql:
image: mysql:5.7
command:
- "--character-set-server=utf8"
- "--collation-server=utf8_unicode_ci"
- "--max_allowed_packet=512M"
`gsub!’: invalid byte sequence in UTF-8 (ArgumentError)になる
ユーザーさんが投稿しまくっていると、変なコードの文字が入ったりして、invalid byte sequenceのエラーが出ることがあります。
その場合は、WordMoveのsql_adapter/default.rbにちょっとコードを追記します。
@sql_content ||= File.open(sql_path).read.encode("UTF-16be", :invalid=>:replace, :replace=>"?").encode('UTF-8')
一旦、UTF-16BEに変換して、その際にinvalidなbyte sequenceがあったら?に変換してしまおうという方法です。その上で、UTF-8に変換します。
このファイルは、/usr/local/bundle/gems/wordmove-5.2.1/lib/wordmove/sql_adapter/default.rbにあります。
だいたいこれで対応できるのではないかと思います。