WordPressのプラグインで評判のいい『シンタックスハイライト』は「Highlighting Code Block」だが、ブロックエディタとか、ビジュアルエディタでの運用のみになっていて、テキストエディタ（HTML）では動作しない。
以下、「Crayon Syntax Highlighter」「Code Prettify」「WP Code Prettify」も同様。
「Syntax Highlighter Evolved」はテキストエディタ（HTML）でも動作する。
ショートコード［code］で括ること。＜code＞ではダメ。
SyntaxHighlighter Evolved – 記事の中でソースコードを綺麗に表示できるWordPressプラグイン
１．環境
AWS Linux、nginx、php-frm、WP
２．インスタンスをコピー
イメージの作成でAMIを作ってそこから起動
セキュリティグループに 22を追加して後で塞いでおく
３．PHP バージョンアップ
yum -y remove php-*
yum -y remove httpd-tools
yum clean all
yum install php73 php73-cli php73-common php73-fpm php73-imap php73-json php73-mbstring
yum install php73-mysqlnd php73-opcache php73-pdo php73-process php73-xml php73-gd
e /etc/php-fpm-7.3.conf
service php-fpm restart
service nginx restart
gdをインストールし忘れて後からインストールするとき、libwebpを１回削除してからいれること
（curlのバージョンも上げておく）
yum remove libwebp
yum –disablerepo=epel –enablerepo=amzn-updates install libwebp
yum install php73-gd
yum install curl
php-frm の設定ファイル（/etc/php-fpm.d/www.conf）の内容をコピー
listen.owner = nginx
listen.group = nginx
ここはエラー（WARNING: [pool www] ACL set, listen.owner = ‘nginx’ is ignored）になるので、
コメントアウトすること。
WordPressを管理画面で立ち上げるとエラーになるときは、ログを確認
tail /var/log/nginx/error.log
Slider Revolutionのバージョンが古く、立ち上がらなかったので、FTPでプラグインフォルダを削除して
公式サイトから最新版をダウンロードして入れ替えたら動いた
続く・・・かも
エクスポート先に「WP CSV Exporter」プラグインを入れる。
普通に入れる場合は問題ないと思うが、ZIPを自分で展開するときは、以下のフォルダに書き込み属性を付けておく。
/wp-content/plugins/wp-csv-exporter/download/
CSVファイルは UTF8になっているので、EXCELに入れるときはそのまま読まないでインポートする
データ ＞ テキストまたはCSVから ＞ 65001：Unicode(UTF-8)
EXCELで加工したあと、CSVに書き出す。
この場合、項目が引用符（ダブルコーテーション）で囲まれないので、テキストエディタで適宜加工する。
すでに引用符で囲まれていた場合は、正規表現で置換。
hogehoge(..)”,”fugafuga # 置換前（2桁の数字が入る）
hogehoge\1,fugafuga # 置換後（￥1）
インポート先に「Really Simple CSV Importer」プラグインを入れる。
元データはゴミ箱に入れてから完全削除する。
大きなデータファイルをインポートする場合、標準の4MBでは足りないことがほとんどです。
nginxとphp-frmを入れている環境で最大値を増やすには次の箇所を確認します。（やれるところはすべてやる）
※ 最後の php-frmの設定以外効いていないのがミソ！
「504 Gateway Time-out」が出るときも同様です。
php.iniの場所確認
# php -i | grep php.ini
Configuration File (php.ini) Path => /etc
Loaded Configuration File => /etc/php.ini
php.iniの編集
# nano /etc/php.ini
post_max_size = 10M
upload_max_filesize = 10M
nginx.confの編集
# nano /etc/nginx/nginx.conf
client_max_body_size 10M;
fastcgi_read_timeout 180; #タイムアウトを延ばす
php-fpm設定の編集
# nano /etc/php-fpm.d/www.conf
request_terminate_timeout = 180 #タイムアウトを延ばす
php_admin_value[upload_max_filesize] = 10M
php_admin_value[post_max_size] = 10M
関係あるかどうかわかりませんが、AWS（EC2）のロードバランサーのタイムアウトも延長しておきました。
アイドルタイムアウト 180 秒
reloadで十分ですが、念のため再起動します。
# service nginx restart
# service php-fpm restart
ここまでやると、最大値が10MBになります。たぶん。
最後の /etc/php-fpm.d/www.conf を書き換えないで実行するとタイムアウト系のエラーが出ます。
設定がちぐはぐでタイムアウトしてる
504 Gateway Time-out
とか
upstream timed out (110: Connection timed out)
client_max_body_size が足りないときに出るエラー413 Request Entity Too Large
WordPressの引っ越し話でのことなんですが、Jetpack機能がインストールされているサイトを移すと画像が全滅！
ちょっと特殊なテンプレートを使っていたせいもあって、原因がすぐにはわからずプチパニック！
ちゃんと調べたら、JetpackのCDN機能がONになっていたせいでした。
どういうものかというと、画像ファイルのURLが i?.wp.com というような URLに書き換えられるものです。
http://i2.wp.com/hogehoge.com/wp-content/uploads/2018/05/hogehoge.jpg?resize=400%2C300
引っ越ししてテストしている最中のサイトの場合、旧サイトが DNS上では生きていて（httpsはダメな状態）、
テスト環境では、新サイト（httpは httpsへリダイレクト）が見えているわけですが、Jetpackの CDNが
画像を引っ張ってこようとする先は旧サイトで、アクセスは httpsで取ってこようとするので、取れないという感じ
になるわけです。
それ以外にもデメリットがあるそうなので列挙。
１．キャッシュを削除できない（上書きNG）
２．他の画像処理系のプラグインと相性が悪い
３．CDNが効くのはデータベース経由でリンクされている画像のみ
４．画質が劣化する
１と４が致命的ですね。
ということで、Jetpackを入れた場合、設定 ＞ 執筆 ＞ 画像を私たちのサーバーから提供 ＞ OFF
にしておきましょう。