Archive for the 'WP Tips' Category

WordPressのデータをCSVでエクスポート/インポート

エクスポート先に「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」プラグインを入れる。
元データはゴミ箱に入れてから完全削除する。

WordPressのインポート最大容量を増やす

大きなデータファイルをインポートする場合、標準の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

JetpackのCDNはOFFに

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
にしておきましょう。

WordPressのサイトを丸ごと引っ越し

いろいろ訳あって、WordPressのサイトを丸ごと別のサーバーへ移すことになりました。
また訳あって、現在のサーバーには、http(80)はアクセスできますが、その他ポートがすべて塞がれています。
SSH(22)も FTP(21)も https(443)も全部です。

そういう環境で、まずは WordPressの環境を丸ごとバックアップしなければなりません。
WordPressには、Duplicatorという優秀なプラグインがあります。
Duplicator – WordPress Migration Plugin(作成者: Snap Creek)

これをまず入れます。
有効化したら、すべてそのままで実行します。
大抵1か所くらいは Noticeが出ると思いますが、そのまま使うわけではないので、詳細はパスです。
Duplicator > Create New > Next > Yes. Continue with the build process! > Build

もしファイルが大きくてエラーになる場合は、まず、Databaseのみバックアップします。
Duplicator > Create New > Files > Archive Only the Database >・・・> Build

次に画像ファイル以外を取ります。
Duplicator > Create New > Files > Enable File Filters > [wp-uploads] >・・・> Build

画像ファイルは、Website Explorer(WordPressのプラグインではない)でバックアップします。
Website Explorer > ツール > フォルダ・ダウンロード

すべてのバックアップが終わったら、Archiveファイルをダウンロードします。
この中に大切なものが全部入っています。

新しい方のサーバーに WordPressを入れておきます。
Amimotoを使っている場合は、wp-setup hogehoge.com でいいでしょう。
入れ物だけが必要です。(すでに入っている場合は消しておきましょう)

# rm /opt/local/hogehoge.com.json
# rm /opt/local/createdb-hogehoge.com.sql
# mysql -u root -p
drop database hogehoge_com;
# wp-setup hogehoge.com

ACM(Amazon Certificate Manager)で、*.hogehoge.com(別名で hogehoge.comも登録しておくこと)を取ってる場合は、ロードバランサーのリスナー(証明書)に追加しておきます。
また、テスト段階では、hostsに ロードバランサー(の片方)の URLを登録しておきましょう。(下の例では 1.1.1.55)
# vim C:\Windows\System32\drivers\etc\hosts
1.1.1.55 hogehoge.com
1.1.1.55 www.hogehoge.com

http://hogehoge.com にアクセスすると、WordPressインストールが始まるはずなので、EC2のインスタンスコードを入れて進めます。
WordPressシステムの更新やプラグイン、テーマなどを最新にします。
それから先ほど取ったバックアップファイルから手動で必要なファイルを FTPでコピーします。

/wp-content/themes/
/wp-content/plugins/ (標準でインストールされなかったものだけ)
/wp-content/uploads/

Website Explorerで画像のバックアップを取った場合は、PC環境で使われているファイルのみ保存されていますので、スマホは小さいサイズの画像を使うようなテンプレートの場合は、Regenerate Thumbnails などのプラグインでサムネイル画像の再構成をしておいた方がいいでしょう。

念のため、mysqldump でこの時点のバックアップを取っておきます。
# mysqldump -u root -p -h localhost hogehoge_com > hogehoge_com.sql;

さて、Archiveファイルの database.sql を書き換えます。
必ず修正するところは2か所だけ。(ここを書き換えないとリダイレクト地獄になります)

INSERT INTO `wp_options` VALUES (1,’siteurl’,'https://www.hogehoge.com’,'yes’);
INSERT INTO `wp_options` VALUES (2,’home’,'https://www.hogehoge.com’,'yes’);

あとは、httpを取るか、httpsに書き換えます。

http://hogehoge.com/wp-content/uploads/ ⇒ /wp-content/uploads/

http://hogehoge.com/ ⇒ https://hogehoge.com/

保存したファイルを FTPでアップして(とりあえず db1.sqlに保存)、mysqlで実行します。
# mysql -u root -p
use hogehoge_com;
source /var/www/vhosts/hogehoge.com/db1.sql;

で、新しいサーバーにまったく同じサイトが構築できました。
Route 53 の Alias Targetを書き換えて完了です。
テストで書き換えた hostsも戻すのを忘れずに。

WordPress> adminログインで2段階認証


TechCrunchのこの記事「全世界のWordPressサイトに大規模攻撃; デフォルトのアドミンユーザ名’admin’がねらわれている」にドキッとした方も多いのではないだろうか。

弊社で管理しているサイトの90%はWordPressでできているといっても過言ではないので、正直他人事ではないです。
対策としてとれる方法は次の通り。(簡単順)

  1. 新しく管理権限ユーザーを作って、adminユーザーを削除する。adminユーザーの持っていた投稿は新しいユーザーに移す
  2. WPのDBを直接書換え。adminのIDと名前を書き換えるだけなので影響が少ないが、phpMyadminなどでの操作が必要。
    UPDATE wp_users SET user_login=’newuser’, user_nicename=’newusername’ WHERE ID=xxx;
  3. 追記:WPをマルチサイト対応にしている場合は、wp_sitemetaのsite_adminsも変更すること。
    そうしないと、ネットワーク管理者になれなくなる。
  4. adminのログインに二段階認証を入れる

 
 
2番目の対策でやれば楽ちんなんだけど、今後adminだけの話ではなくなる可能性は十分あるので、今回は3番目の二段階認証でやってみることにします。まず、スマホ(Android)に AUTHYをインストール。iPhoneでもたぶん同じ。

  1. PCから、AUTHYにSign Inする。CLOUDFLAREなどの大手も使っているみたいだから大丈夫だと思う。
  2. Email、Country、Cellphone、Passwordを入れる。Countryは「Japan(+81)」、Cellphoneは頭のゼロを取る「9012341234」
  3. そうすると、携帯にメッセージ(SMS)が来る。https://www.authy.com/install からアプリをインストールしてねというメッセージなので、Playストアで AUTHYをインストールする。(無料)
  4. Android版 AUTHYをインストールする際も、Country、Cellphone、Passwordを聞かれるので再度入力。6桁のPINコードがメッセージ(SMS)で送られてくるので、それを入力すればインストール完了。
  5. Android版 AUTHYを起動すると、20秒ごとに TOKENが表示される。

 
 
スマホ(Android)で AUTHYが動くようになったら、PCでログイン。

  1. AUTHYでログイン。EmailとPasswordは先ほど入力したもの。
  2. Authy Token画面になるので、携帯に表示された TOKENを入力する。
  3. ダッシュボードが表示されたら「Create new application…」をクリック。Application Nameは適当に決める。
  4. Api Tutorial画面になったら、「or go to your dashboard」をクリック。
  5. 左サイドバーにいま決めた「Application Name」が表示されるので、これをクリック。
  6. このページの「Api Key」をコピーしておく。

 
 
AUTHYの「Api Key」が無事入手できたら、WordPressにプラグインを入れる。

  1. プラグインの新規追加で「Authy Two Factor Authentication」を検索、追加。
  2. 有効化したら、Settings画面で「Api Key」を設定。誰(権限)に対して二段階認証を行うかも設定できる。
  3. 「Disable external apps that don’t support Two-factor Authentication」にチェックを入れると、外部アプリが二段階認証をパスすることになるので、よく考えて設定すること。しない方がいいと思う。
  4. これが済んだら、ユーザープロフィールに移って、個人ごとの設定を行う。
  5. Two-Factor Authentication を Enableに。Country、Cellphoneを入力したら、携帯にメッセージが送られてきて完了。

※ 山本一郎氏がYahoo!に書くくらいだから、相当底辺まで広まったとみて、adminを変更する2番目の方法をとりました。

Google XML Sitemapsプラグインはいいよ!

マルチサイト対応ができていなかったので使っていなかったのですが、β版でサポートを開始したので使ってみることに。
β版はこちらからダウンロードできます。
http://www.arnebrachhold.de/redir/sitemap-dl-beta/

Google ウェブマスターツールにサイトマップを追加します。

bingウェブマスターにもサイトマップを追加します。

しばらく使ってみて、またレポートします。

WordPressのthe_post_thumbnail()、すごくない?!

the_post_thumbnail()って、アイキャッチ画像を表示させたりするのに超絶便利な関数なんだけど、altや titleに余計なものをセットして面倒くさいなぁと思ってました。
で、get_the_post_thumbnail()で変数に受けてから、それを preg_replaceとかしてたわけなんですけど、なんとなんと、そんなことしなくてもいいんです。

<?php the_post_thumbnail( array(150,150), array('class' => 'imgLeft') ); ?>

この用例をみてわかるように、なんでもセットできるんです。
array(‘title’ => get_the_title(), ‘alt’ => get_the_title()) みたいなことでOKなんです。
よくできてますね!

WordPressに関連投稿を追加する「WordPress Related Posts」プラグインを導入する

投稿した記事に関連した記事を自動的に追加してくれるプラグインを入れておきましょう。

 

設置は通常のプラグインのインストールと同様に「WordPress Related Posts」で検索してインストールします。
赤丸のところだけ変更しておきましょう。

 

WordPressにSNSボタンを追加する「Sharebar」プラグインを導入する

投稿した記事を Twitterや Facebookで取り上げていただくのは SEO対策の基本ですね。
できるだけ簡単に取り上げていただけるよう、ハードルを下げておきましょう。

WordPressでサイトを作っている場合、一番簡単な対処法は、「Sharebar」というプラグインを入れることです。

設置の方法や、Facebookの幅調整などは、こちら「ソーシャルボタンSharebar(シェアバー)の使い方と設置方法。WordPressプラグイン。」が詳しいです。

 

WordPressで作ったサイトをSEOチェックしたとき、「URLの正規化」ワーニングがでたときにとる対処法

WordPressで作ったサイトをSEOチェックしたとき、「URLの正規化」ワーニングがでることがあります。
ワーニングの原因は、index.php、index.htmlが別ものとして扱われるためです。

対策する理由
index.html(index.php)のあるURLとないURLが混在していると、重複コンテンツとみなされ、SEOの評価を著しく下げる可能性があります。検索エンジンは重複したコンテンツを登録を行うことは基本的にありません。この理由は、同じコンテンツを重複してインデックスしていくと、ある検索クエリに対する検索結果として同一内容を持つ異なるURLを複数表示することになり、検索ユーザーの検索体験の質低下を招くからです。
SEOスカウターβ版より

 

WordPressをインストールすると、インストールディレクトリにこんな感じの .htaccessができます。

# .htaccess
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

これだと、index.htmlが入ってきたとき、index.phpとは別扱いされて、404エラーになってしまいます。
これを以下のように書き換えます。

# .htaccess
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
Options +FollowSymLinks
RewriteBase /
#RewriteRule ^index\.php$ - [L]
RewriteCond %{THE_REQUEST} ^.*/index.(html|php)
RewriteRule ^(.*)index.(html|php)$ http://%{HTTP_HOST}/$1 [R=301,L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

これで、example.com/ と example.com/index.php と example.com/index.html がすべて同一になります。

次ページへ »