WordPressのプラグインで評判のいい『シンタックスハイライト』は「Highlighting Code Block」だが、ブロックエディタとか、ビジュアルエディタでの運用のみになっていて、テキストエディタ(HTML)では動作しない。
以下、「Crayon Syntax Highlighter」「Code Prettify」「WP Code Prettify」も同様。

Syntax Highlighter Evolved」はテキストエディタ(HTML)でも動作する。
ショートコード[code]で括ること。<code>ではダメ。

参考

SyntaxHighlighter Evolved – 記事の中でソースコードを綺麗に表示できるWordPressプラグイン

  1. 前提
    • AWS / EC2, Certificate Manager, Route 53
    • Amimoto
  2. さらに読む

1.環境
  AWS Linux、nginx、php-frm、WP

2.インスタンスをコピー
  イメージの作成でAMIを作ってそこから起動
  セキュリティグループに 22を追加して後で塞いでおく

3.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を1回削除してからいれること
(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で取ってこようとするので、取れないという感じ
になるわけです。

それ以外にもデメリットがあるそうなので列挙。
1.キャッシュを削除できない(上書きNG)
2.他の画像処理系のプラグインと相性が悪い
3.CDNが効くのはデータベース経由でリンクされている画像のみ
4.画質が劣化する

1と4が致命的ですね。
ということで、Jetpackを入れた場合、設定 > 執筆 > 画像を私たちのサーバーから提供 > OFF
にしておきましょう。