WordPressのSSL化

WordPressのSSL化

ブログも今や常時SSL をすることが望まれる時代になってきました。
Google社はSSLで保護されているWebサイトかどうかを検索順位を付ける際の要素とすると言っていますし。
また、WordPress環境を提供してくれるレンタルサーバー会社も無料のSSLを提供してくれるなど、常時SSL化の流れができているようです。

WordPressのSSL化の方法

WordPressをSSL化は、以下の手順で行います。
1)SSLサーバー証明書の入手/設定
2)WordPrssでの設定

SSL証明書の入手/設定

まずは、SSL証明書を入手する必要があります。
現在は、無料のものもありますし、もちろん有料のものもあります。

一方、最近はWordPress環境を提供してくれるレンタルサーバー会社も無料のSSLを提供してくれるところがあります。
私が使用している、IXWebHosting + StarDomain の組み合わせでもSSL化できます。
また、最近契約した StarServer では、ボタンクリックのみでSSLの環境を提供してくれます。
StarServer では、StarDomain 契約で StarServer で DNS を管理している場合にのみですが、SSL証明書入手して、そのままWebサーバーに設定するまでの作業を自動で行ってくれます。

自分の環境に合わせ、SSL証明書を手に入れ、Webサーバーに設定します。

参考までに StarDomain での「Let’s Encryptで無料のSSLを取得する」を紹介しておきます。
また、「IX Web Hosting SSLを設定する(初回設定)」も合わせて紹介しておきます。

WordPrssでの設定

プラグインでの設定が一番間違いないと思います。
お勧めのプラグインは Really Simple SSL です。
Really Simple SSL は、設定なしでサイトを SSL 対応にする軽量プラグインです。
※2018-05-11追記
Search Console Accelerated Mobile Pages に『ページにユーザー作成の JavaScript がある(重大な問題)ページからカスタム JavaScript のコードをすべて削除してください。AMP ページにカスタム JavaScript があると、Google 検索結果に AMP 固有の表示機能が表示されないことがあります。 詳細』と以下のような通達が来ました。

重大な問題のある AMP ページ

重大な問題のある AMP ページ


Really Simple SSL は設定によってJavaScriptを出力します。他のサイトでも Really Simple SSL を使用しているのですがこの警告?通達?通告?は出ていないので Really Simple SSL が悪さをしているとは限りませんが、他のプラグインでJavaScript を出力するものは無いので。。。
そのうち改修されるかも知れませんが、私は Really Simple SSL を使うのを止めました。
※2018-05-11追記終了

その他のお手軽な方法は.htaccessを使う方法があります。
httpからhttpsへの301リダイレクトさせます。
リダイレクトの設定は.htaccessに以下のように追加します。

RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://(ドメイン名)/$1 [R=301,L]

もしくは、

RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

その後、WordPressの設定→一般のWordPress アドレス (URL)とサイトアドレス (URL)を Https に書き換えます。
また、内部で参照している画像等を http → https にしないと「保護されていません」とか「i」表示とかになり、「保護された通信」となりません。
チェックの仕方はありますがかなり面倒かと。。。
チェックの仕方は Google chrome の場合は、「F12」を押し、「console」を見るとエラーや警告が色づけされ表示されます。
一枚を直すのは苦じゃないですが大量にあると苦行になります。。。

Really Simple SSL の設定方法

プラグインの新規追加から Really Simple SSL を検索し、インストールします。

WordPressSSL化-Really Smiple SSLインストール

WordPressSSL化-Really Smiple SSLインストール

インストール後、有効にするボタンをクリックします。

WordPressSSL化-Really Smiple SSL有効化

WordPressSSL化-Really Smiple SSL有効化

すると、以下のような確認メッセージとともに表示されますので、

Really Simple SSL - SSLを化有効にする

Really Simple SSL – SSLを化有効にする

「はい、SSLを有効化します」ボタンをクリックします。

以上でSSL化が有効化され、かつ http から https への 301リダイレクト されるそうです。

また、上の.htaccess で行った時と決定的に違うのが、内部で参照している画像等を http → https に自動で行ってくれるので修正する必要がありません。
非常に便利です。

念のため、WordPressの設定→一般のWordPress アドレス (URL)とサイトアドレス (URL)を Https に書き換えましょう。

以上、WordPressのSSL化の紹介でした。

WordPress リビジョン管理 プラグイン

WordPress リビジョン管理

今回はWordPressの便利情報、 WordPress リビジョン管理 プラグインを紹介します。
WordPressにはデフォルトで過去の記事を履歴として残す リビジョン管理 機能があります。
2017/8/10 追記しました。追記にあるように 簡易な管理 なら追記の方法で十分でした。
修正前のものをきちんと残しておきたい場合は、追記の方法ではできません。プラグインで管理してあげる必要があります。

リビジョンとは

WordPress の記事を書いていると、下の方にリビジョンが表示されていることに気付きますよね?
記事をある タイミング で保存し、後から見たときにいつの時点でどのような 変更 や修正 を掛けたかを 確認する機能 です。

WordPress リビジョン管理

WordPress リビジョン管理


上のように、いつも知らないうちに溜まってます。
30個くらい溜まってたこともありました^^;

そもそもリビジョンとは、修正作業等の変更を表す改訂番号のことです。例えば誤字脱字の修正を行ったときにリビジョンの値を上げて記事をリリースします、でリリースした記事がいつリリースされたか? どのように修正されたか?などを(古い記事を保存じて)確認できるようにしているデータです。
先ほども書きましたが、 WordPress も デフォルト でリビジョン管理機能を持っています。

WordPressのリビジョン管理とは

WordPressのリビジョン管理は、以下のような時にリビジョンを作るようです。
・下書き保存をした時
・下書き中の記事を変更してプレビューした時
・記事を公開した時
・公開した記事を変更し、最初に「自動下書き保存」した時
・公開した記事の変更をプレビューした時
・公開した記事を更新した時
・ゴミ箱に記事を移動した時
・ゴミ箱から記事を戻した時

これらの操作でほぼ自動でリビジョンが作成され管理されています。
ちなみに、 WordPress には リビジョン を 比較する機能 や 復元する機能 も付いています。
私はこの機能を「へぇ~」って思って見たいただけで、実はほぼなにも使っていません。

これだけ細かく管理する必要があるのかは個人の見解に依るでしょうが、個人的なブログであれば必要ないと思います。
商売でやってる人には履歴はあった方が良いのでしょうが。
私のような人も多いのでは。。。と。

リビジョン管理の問題点

問題点と言うほどの問題点も実は無いのですが。。。
・データベースのデータ量が少し増える、それに合わせて少し重くなる。
・パーマリンクの番号が増える。
・下にだらだらリビジョンが有ってなにこれ?ってなる。

私はリビジョン管理を見るたびに、不要なデータは要らないから作らない方が良いのではと思ったり、まぁ、作っても良いけどだらだら表示しない程度にデータ量を少なくしてって感じたり、そんな感じで少しだけ気を取られてその後は忘れてしまってます。

最初に気になったころ、phpに手を入れてリビジョンそのものを作らないようにすることも可能だと思い、その方法もググってみたりしました。結局は、php改修は大変そうだし、そこまでやらなくても良いかなって思い放置していました。

追記:2017/8/10
難しい改修をしなくても wp-config.php のみで少し制御できることがわかりました。

■ そもそも保存しない
そもそも保存をしないようにするには、下の一文
define(‘WP_POST_REVISIONS’, false);
を、最下行の require_once(ABSPATH . ‘wp-settings.php’); より前に入れてあげればOKです。
下のように記述すればOKです。

if ( !defined(‘ABSPATH’) )
define(‘ABSPATH’, dirname(__FILE__) . ‘/’);

define(‘WP_POST_REVISIONS’, false);

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . ‘wp-settings.php’);

■ 保存数を制限
作成されるリビジョンの数を制限するには、下の一文
define( ‘WP_POST_REVISIONS’, X );
を、最下行の require_once(ABSPATH . ‘wp-settings.php’); より前に入れてあげれば OK です。
X は数字で保存数を指定します。3 つ分保存ならを 3 指定します。
指定した数だけ保存され、古いものは自動的に削除されていきます。
下のように記述すれば 3 つ分保存されます。

if ( !defined(‘ABSPATH’) )
define(‘ABSPATH’, dirname(__FILE__) . ‘/’);

define(‘WP_POST_REVISIONS’, 3);

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . ‘wp-settings.php’);

このやり方だと、直近 3 つ分しか残りませんが、私個人はプラグインを利用しても細かな制御をしないのでそんなに変わらないかと思います。このやり方でいいかな^^;
とりあえず試しに直近 3 つ分しか残こらないように実行してみますね。
(結果)
いとも簡単にできてしまいました。
プラグインよりお手軽便利です^^
プラグインアンインストールしちゃおうかな^^
そうしますね^^;
–追記終わり

有るとき不意に、プラグイン の存在を思い出し、ググってみました。

リビジョン管理 プラグイン を導入する

で、やっと本題の WordPress リビジョン管理 プラグイン です。

リビジョン管理を全くしないわけでなく、今まで通り自動で作くり、古いリビジョンから消していくという折衷案で、プラグインを導入してしまうのが良いのかと。
サクッと調べてみると下の3つが有名な プラグイン でした。私も一部使ってみました。

Optimize Database after Deleting Revisions 設定英語、リビジョンの保存数を自由に設定できる。
Revision Control 日本語設定、リビジョンの保存数を自由に設定できる。
Better Delete Revision 英語設定、記事の古いリビジョンを一括削除してデータベース容量を減らせる。

個人的に「Optimize Database after Deleting Revisions」と「Revision Control」を別々の二つのサイトで使っていますが、どっちもどっちの感想です。特にこちらが使いやすいとかもなく。
日本語の設定で簡単にできる「Revision Control」の方が楽なような気もしますが、「Optimize Database after Deleting Revisions」の方が細かく設定出来るので良いと思い人もいるかも。

インストール方法 や 管理の仕方 を細かく教えてくれているサイトもあるので、「Optimize Database after Deleting Revisions」と「Revision Control」を検索して好みの方を利用してみてください。

参照先:『WordPress Codex 日本語版 リビジョン管理』
以上、「 WordPress リビジョン管理 」プラグインの紹介でした。

WordPress ページビュー数を確認するプラグイン「 WordPress Popular Posts 」

WordPress ページビュー数を確認するプラグイン

私の「WordPressでブログ」をご覧いただきありがとうございます。
せっかくブログを書いていても、誰も読んでくれないと寂しいですからね。。。

で、思ったのがどの記事がどれくらい読まれてるかを知りたいなぁと。
実際に読まれたかどうかを測ることはできませんが、記事が表示されたどうかなら測ることができるそうです。
そう、この記事のタイトル「ページビュー数を確認するプラグイン」のプラグインが「WordPress Popular Posts」らしいのですが。。。

そもそも「WordPress Popular Posts」ってなに?って私も思ってます。
ページビュー数の確認ができるらしいのですが、うーん。
とりあえず、インストールしてみます。

WordPress Popular Posts インストール画面

WordPress Popular Posts インストール画面


うーん、私の使っている最新版へのテストが済んでいないようです。「お使いのバージョンの WordPress ではテストされていません」と出ています。
まぁ、問題が出たら削除する方針でインストールしてみます。あくまでも自己責任で。。。

インストールは出来ました。
有効化も出来ました。

WordPress Popular Posts 設定画面

WordPress Popular Posts 設定画面


英語で良くわかりません。。。

グーグル先生に日本語化できないか聞いてみました。
すると、wordpress popular posts 日本語 最新翻訳ファイル
作者の方、ありがとうございますm(_ _)m

で、早速指示の通りインストールしてみました。

WordPress Popular Posts設定日本語画面

WordPress Popular Posts設定日本語画面


めでたく日本語化しました。本当にありがとうございます。

統計は、人気のない「WordPressでブログ」なので30日間で設定しました。が単なるボタンのようで、クリックすると下の欄にその期間のカウントが表示されます。
ツールを見ました。
・サムネイル・・・なんだろう?
・データ・・・・・「ログの閲覧権限」??英語で確認しました「Log views from」でした。閲覧者のログを取る範囲のことでしょうね。日本語訳ちょっと心配。。。「訪問者のみ」で
後は見てもさっぱり分かりません。

ということで、おいおい考えて設定したいと思います。

と、書いていたら表示されました。

WordPress Popular Posts結果表示

WordPress Popular Posts結果表示


WordPress 作成者を表示・非表示・変更するが見てもらえました^^

後は何ができるのかな。。。
「ダッシュボード」の「外観」>「ウィジェット」を見ると「WordPress Popular Posts」が表示されています。

WordPress Popular Posts 設定ウィジェット

WordPress Popular Posts 設定ウィジェット

「WordPress Popular Posts」をクリックしてみました。

WordPress Popular Posts ウィジェット設定1

WordPress Popular Posts ウィジェット設定1


とりあえず、「ウィジェットエリア1」を選んで、「ウィジェットを追加」をクリックしました。

すると、「ウィジェットエリア1」に「WordPress Popular Posts」が追加されました。

WordPress Popular Posts ウィジェット設定2

WordPress Popular Posts ウィジェット設定2

「WordPressでブログ」Webサイトを表示してみると、ちゃんとWordPress Popular Postsウィジェットが表示されていました。

WordPress Popular Posts ウィジェット表示

WordPress Popular Posts ウィジェット表示

取りあえずはこれで良いのですが、もう少し調べてみたいと思います。
以上、「WordPress ページビュー数を確認するプラグイン」の紹介でした。

Google Sitemap by BestWebSoft でサイトマップを登録

Google Sitemap by BestWebSoft でサイトマップを登録

Google Sitemap by BestWebSoft でサイトマップを登録
Google Sitemap by BestWebSoft でサイトマップを登録することにしてみました。

設定はGoogle XML Sitemapsの方が使いやすいです。
とりあえずはインストールはでき、サイトマップも作成できました。
ウェブマスターツールでサイトマップの登録もできました。
インデックスに登録済が保留のままですが、おいおい登録されて行ってくれればと思います。

Google Sitemap by BestWebSoft でサイトマップを登録

なぜこのプラグインを選んだかと言うと、理由は無いです。
使用している人が10,000+人って出てたので、その辺りが決め手でした。
インストールはごく簡単に済みました。
FTPでアップロードするわけでもなくすんなり入りました。

気になるのはwwwrootにサイトマップを置くのですが、wwwrootのアクセス権をとりあえず緩めましたが、緩める必要あるのかな?
後でテストしてみたいと思います。

それから自動で更新してくれるかも今は良く分かりません。
これもテストしてみます。

テストしてみました

サイトマップは自動で更新してくれます。wwwrootのアクセス権も緩めなくても大丈夫でした。
しかし、Googleへの通知はしてくれません。
Google Sitemap by BestWebSoftへウェブマスターツールへのアクセス許可を与えれば自動でやってくれるようですが、怖くてできませんでした。
適宜自分でアップすることにしました。

やはりGoogle XML Sitemapsの方が安心して使えますね。
Google XML Sitemaps4.0.8からバージョンが上がったら再挑戦してみます。

とりあえずはこんな感じの報告で。
またなにか有ったら報告します。

Google XML Sitemapsでサイトマップが更新されない

Google XML Sitemapsでサイトマップが更新されない現象が発生しています。
期間はここ3日間です。
インストール当初は問題なく稼働していました。新しく記事を書いても、記事を修正して更新しても、Google側に通知されしばらくすると保留も解除されてていました。

サイトマップが更新されない現象について

現象に気が付いたのは新規の記事を書いても送信が増えないことから気が付きました。そこで送付されているサイトマップを開いて確認したところ、新規の記事が記載されていませんでした。

更に自分のWebサイト(ブログサイト)に戻り、設定の中からXML Sitemapsを開き、上部に記載されているサイトマップをクリックし直に確認したところ、Googleに送信したサイトマップと同じでした。
このバージョンはサイトマップ自体は動的に作られるのかな?
最近WordPressを始めたので、その辺りは理解できていませんが、実態が存在しないので動的に作っていると思います。

サイトマップが更新されない対応について

「Google XML Sitemaps 更新されない」をキーにしてググってみると、他の方の現象はバージョンが4.0系に変わった際の不具合報告が多く、私と同じ不具合の人を見つけるもバージョンをダウングレードすると言う対策を取っているようです。

とりあえずGoogle XML Sitemaps一回停止して、この記事を投稿して確認してみようと思います。
それでだめなら、一回アンインストールして、再インストールをしてみようと。

一回停止して、この記事を投稿して確認

Google XML Sitemaps一回停止して、この記事を投稿して確認してみました。
記事のURLは以下のとおりです。
Google-XML-Sitemaps不具合04

投稿をしたところ、Google XML Sitemapsの設定画面は以下のとおりでした。
Google-XML-Sitemaps不具合01

Googleのウェブマスターツールでサイトマップを確認すると
Google-XML-Sitemaps不具合02
保留になり、通知されたことがわかります。
で、/index.php?xml_sitemap=params=を確認すると
Google-XML-Sitemaps不具合03
見事に/p=326が居ません。
これを見る限り、2015-06-05 09:45を最後に更新をしていないようです。

アンインストールしてみる

アンインストールしてインストールしても再構築されませんでした。以前のままです。
これって、どこかに覚えてるのかな?

以前の記事を更新してみると

以前の記事を更新してみました。すると、
Google-XML-Sitemaps不具合05
面白いことに、2015-06-06 17:08に更新されていました。
2015-06-07 02:08との差は9時間ですので、米国タイムで記載されてるのかな?
このことから、既に記載された記事に関しては更新されることがわかりました。
アンインストールしたかかな?確認してなかったので今となっては不明です。

再度、再インストールしました

アンインストールするとGoogle XML Sitemapsのフォルダごと削除されていました。

特に何かを独自で持っているわけでもなさそうなので、公開と更新をトリガーにして、「SELECT * FROM wp_brog_posts WHERE post_status = ‘publish’ ORDER BY post_date」を発行しサイトマップを作っているだけなんでしょうね。
難しいプログラムでないので、なんとなく処理の流れがわかったのですが、PHPは経験がが無いので、ソースを見るとかこれ以上は調べるのを止めます。

結果・対策

他の人たちがやっているように素直に諦めダウングレードするか違うプラグインを入れたいと思います。
難しくない処理なのに何がいけなかったんでしょうね。

報告は以上です。。。