【備忘録】<「１」はWPML 3.2.3で解決予定> WPMLプラグイン関連トラブル（投稿が表示できない、他の言語にリダイレクトされる）#wpml

本日はこの２つのトラブルに見舞われたので備忘録しておきます。
※私の特殊環境かもしれないので（ちょっと多忙で完全に確認できていない）、その点はご留意ください。

「１」については、サポートへ報告したところ、バグだったとのこと。
WPML 3.2.3 devでテストした所、問題なく動作したので、3.2.3がリリースされたら解決するでしょう。2015年8月13日

1. 各言語で同じスラッグ（タグ）を利用するとメイン言語に強制転送されてしまう。

WPML3.2.2で確認しました。WPMLのサポートフォーラムに投稿（Cannot work in case of using same tags in each language）しておきました。まぁとりあえず時間ないから、ざっくりとした説明しかしなかったんですけどね...

http://◯◯/test  ：日本語
http://◯◯/en/test：英語

とします。ここでのタグは、「test」です。

http://◯◯/en/test にアクセスすると、http://◯◯/test に飛ばされてしまう。

という状況に陥ったということです。
いままではいけていましたし、過去にもそういったトラブルがありました。

- https://wpml.org/forums/topic/2nd-level-pages-with-same-slug-redirecting-to-main-language/

のでバグだろうなぁと思います。バグじゃなく仕様なら、そもそも同一タグを設定できないようにしておかないとねぇ。

2. WordPress 4.3.2にアップデートしたら投稿、固定ページ等一覧表示がでなくなった

データはあるようなのですが、管理画面の一覧表示にでなくなったという現象が手持ちのWPML導入サイト（16サイト）で同時に出てました。固定ページなど表示ページの「編集」や直接URLをタイプするとアクセスできるので、WPML 3.1.9.7とWordPress 4.3.2の相性問題かなと思います。
WordPress の方は順調にWP-CLI (コマンドラインツール「wp-cli」を利用したWordPressプラグインアップデートの自動化などを参考）による自動アップデートが動作したのでアップグレードされていたのですが、するとWPML3.1.9.7を利用していたサイトで問題が発生したということです。

解決策：WPML 3.2.2 へアップグレード

WPML 3.1.9.7から 3.2.2への自動アップグレードが、どうも正しく動作していないようで
（独自方式を採用）、そのためエラーがでていたって感じです。

手動でログインして全サイト（16サイト）をアップグレードするのは、超面倒なのでWP-CLIとシェルスクリプトを組み合わせて一括処理パッチを作成してやっちゃいました。

（
そういえば、以前WPMLのフォルダがミスってアップデートされており、一括フォルダ変更が必要だったときもパッチ作成したなぁ。
（詳細は、【トラブル】WPML 3.1.8.5にアップデート失敗して動作しない（解決策あり）参照）

プラグインの半自動アップデート方法（WPML編）

WordPressに導入しているプラグインを、ダウンロードした同プラグインに一括で置き換えたい！！それをWP-CLIでどうやるかというちょっと濃い話です。Linuxなどでコマンドでゴリゴリやるのが好きな方は受け入れてもらえるかな〜とか思います。

流れとしては

1. WordPressサイトの導入ディレクトリの絶対パスを書きだしたリストを用意
2. リストから、指定プラグインをリネームした上で、置き換えるスクリプトパッチへ流し込むパッチを生成
3. 流し込むパッチを目視確認の上、１つだけ実行して動作するか確認
4. 動作したらえいやってやってしまう。

まぁこの手の一括処理はよほど自信があるか、あるいはバックアップしなくてもリカバリーできるよ！！って分かっている人以外は、バックアップしてからやってくださいな。

1. WordPressサイトの導入ディレクトリの絶対パスを書きだしたリストを用意

all-sitelist ファイル

/◯◯/wordpress1

/◯◯/wordpress2

/△△/wordpress3

と書き出していると仮定します。

2. リストから、指定プラグインをリネームした上で、置き換えるスクリプトパッチへ流し込むパッチを生成

ここはGeekっぽいですけど、

• cat all-sitelist | awk '{print "csh -f WPML-autoupdate.csh "$1" sitepress-multilingual-cms $1"}'

catは無くてもいけるんですけど、分けて考えるのに便利なのであえてcatしてます。
つまり、

• awk '{print "csh -f WPML-autoupdate.csh "$1" sitepress-multilingual-cms $1"}' all-sitelist

が本来の形です。
もう少し分かりやすい形になおしてみます。

• cat all-sitelist | awk '{printf "csh -f WPML-autoupdate.csh %s sitepress-multilingual-cms $1¥n", $1}'

printをprintfに直しただけです。

どっちも分かんないよ〜かもしれません。

cat all-sitelist は、all-sitelist ファイルの中身を表示するだけです。
表示先を | でもって、次のプログラムの標準入力に引き継ぎます。

awk は読み込みファイルを指定されていなければ、標準入力からデータを読み込むので、つまりは all-sitelistの中身を一行ずつ、次のawkで読み込むってことになります。

でそれを printfならそれで表示することになります。

csh -f WPML-autoupdate.csh %s  sitepress-multilingual-cms $1

が表示されるはずなのですが、%sは、$1で置き換えよって指定しています。
$1とは、この場合読み込んだファイルの１つ目の要素です。
awkは何も指定しなければ、スペース区切りで読み込むので

all-sitelist ファイル

/◯◯/wordpress1

/◯◯/wordpress2

/△△/wordpress3

なら、一行ずつ処理されるので、

• csh -f WPML-autoupdate.csh /◯◯/wordpress1  sitepress-multilingual-cms $1
• csh -f WPML-autoupdate.csh /◯◯/wordpress2  sitepress-multilingual-cms $1
• csh -f WPML-autoupdate.csh /△△/wordpress3  sitepress-multilingual-cms $1

と出てきます。¥nは改行です。

WPML-autoupdate.csh はアップデートするためのパッチ（CSH シェルスクリプト）です。csh -f の先頭は、cshプログラムで、WPML-autodate.cshを実行するというのを明示的に指定します。これを指定しない場合、WPML-autodate.cshに実行権限を与えた上で、先頭に #!/bin/csh -f など何で実行するのかを書き出しておく必要があります。

• WPML-autoupdate.csh  WordPressの絶対パス  プラグイン名  アップグレードしたいプラグインファイル（zipファイル）

というある程度汎用的なパッチです。

今回の例では

• WPML-autoupdate.csh /△△/wordpress3 sitepress-multilingual-cms sitepress-multilingual-cms.3.2.2.zip

のような形で実行するという感じになります。

WPML-autoupdate.csh の動作説明

WordPressの絶対パス の存在チェック（なければ何もせず終了）
WordPressのプラグインの存在チェック（なければ何もせず終了）
　プラグイン導入してないとアップグレードはしない（不要）のため
アップグレードしたいプラグインファイルの存在チェック（なければ何もせず終了）

という一通りのエラーチェックをした後に、/tmp/ に一時的にアップグレードしたいプラグインファイルをコピーした上で展開（解凍）し、置き換え前のプラグインを一つ上の wp-content 直下に、プラグイン名-年月日.時分秒 でバックアップした上で、置き換えます。
そして、/tmpに展開したアップグレードするプラグインは置き換えた後に、アクセス権限を変更します（ユーザーがapache, グループがnobody）。このあたりは適宜ウェブサーバーによって変更。

最後に、/tmpにコピーしたファイルを削除するっていう感じです。

文章にするとわかりにくくなっちゃうんですけどね。

以下、WPML-autoupdate.cshの全文です。

自前のよく分かっている環境でやるなら、この程度のスクリプトで充分です。
ただ複雑な環境であるなら、もう少しチェックをいれたほうがいいですけどね。

WPML-autoupdate.csh

GitHubとかに載せるほどでもないので、ここにアップしておきます。

パッチを作成して処理できるサーバー管理者なら、これぐらいは些末事というか日常的にされているでしょうし、、、。

===== WPML-autoupdate.csh =====

#!/bin/csh -f

set wp_dir = "$1"

set plugin_name = "$2"

set plugin_file = "$3" # zip compress file

if (! -d "$wp_dir" ) then

  echo "Cannot access to $wp_dir directory!"

  exit

endif

if(! -d "$wp_dir/wp-content/plugins/$plugin_name") then

  echo "Cannot access to $plugin_name directory!"

  exit

endif

if(! -f "$plugin_file") then

  echo "Cannot access to $plugin_file"

  exit

endif

cp -p $plugin_file /tmp/$plugin_file

cd /tmp

unzip $plugin_file 

cd $wp_dir/wp-content/plugins

mv $plugin_name  "../${plugin_name}-`date +%Y%m%d.%H%M%S`"

mv /tmp/$plugin_name .

chown -R apache.nobody $plugin_name

cd $wp_dir

wp plugin activate  $plugin_name

rm -f /tmp/$plugin_file

echo "Updated $plugin_file in $wp_dir"

===== ここまで =====