2018年1月16日、WordPress 4.9.2 がリリースされました。
これは、WordPress 3.7以降のすべてのバージョンのセキュリティおよびメンテナンスリリースです。
すぐにサイトを更新することを強くお勧めします。
WordPress 4.9.2で21個のバグが修正されました。
詳しくは下のWordPress Codex 日本語版 Version 4.9.2 のページで確認してください。
『WordPress Codex 日本語版 Version 4.9.2』
少し前に「テーマ Twenty Eleven の投稿ページにサイドバーを付ける」を投稿したので、ここは投稿ページにもサイドバーを付けてみようかと思い調査しました。
投稿ページは、固定ページみたいに簡単に付きませんでした。
が、ググってみると簡単にできますというWebサイトを見つけたので参考にしながら試行錯誤して付けてみました。
ちなみに、ググって見つけたWebサイトのやり方では表示されるのですが、下に付く形で表示されてしまい「なんだかぁ～」って感じになってました。
試行錯誤で試しながら付けたため、どのWebサイトでも正常に表示されるか保証はできません。
でも、テーマ Twenty Eleven を使っているなら、たぶん正常に表示されると思います。
「 Twenty Eleven Child w/ Sidebar Support 」と言う、Twenty Eleven の子テーマを見つけて参考にしました。
下のようにマージンや表示幅を変更します。
私の場合は、既に子テーマを作ってしまっていたため、自分の子テーマの style.css に追加する形をとりました。
/* Singular */
.singular #primary {
float: left;
margin: 0 -26.4% 0 0;
width: 100%;
}
.singular #content,
.left-sidebar.singular #content {
margin: 0 34% 0 2%;
width: 64%;
}
.singular .entry-header,
.singular .entry-content,
.singular footer.entry-meta,
.singular #comments-title {
margin: 0 auto;
width: 100%;
}
私の場合は、子テーマに single.php が入って居なかったため、子テーマディレクトリに single.php をコピーしました。
FTPで Twenty Eleven の single.php をローカルにダウンロードして、子テーマにアップロードしました。
その後、サイドバー呼び出す関数 php get_sidebar() を下のように追加しました。
修正前：
</div><!-- #content --> </div><!-- #primary --> <?php get_footer(); ?>
修正後：
</div><!-- #content --> </div><!-- #primary --> <?php get_sidebar(); ?> <?php get_footer(); ?>
この作業までだと、サイドバーは表示されるのですが、正常な位置・表示して欲しい位置に表示されません。
パソコン表示では、本文の下に表示されるような形になってしまいました。
/**
* Add two classes to the array of body classes.
*
* The first is if the site has only had one author with published posts.
* The second is if a singular post being displayed
*
* @since Twenty Eleven 1.0
*
* @param array $classes Existing body classes.
* @return array The filtered array of body classes.
*/
function twentyeleven_body_classes( $classes ) {
if ( function_exists( 'is_multi_author' ) && ! is_multi_author() )
$classes[] = 'single-author';
if ( is_singular() && ! is_home() && ! is_page_template( 'showcase.php' ) && ! is_page_template( 'sidebar-page.php' ) )
$classes[] = 'singular';
return $classes;
}
add_filter( 'body_class', 'twentyeleven_body_classes' );
Twenty Eleven は、上のようにbody要素に「 singler 」クラスを追加するフィルタを追加しています。
子テーマの functions.php は、親テーマの機能を上書きできません。
親の functions.php に追加する形が一般的です。
と言うか、親テーマのファイルの 直前 に読み込まれるので上書きは無理ですし、エラーになります。
そこで、親テーマがフィルタを追加した後に、削除する方法を取ります。
add_action( 'after_setup_theme', 'my_child_theme_setup' );
function my_child_theme_setup() {
remove_filter( 'body_class', 'twentyeleven_body_classes' );
}
これで、singlerクラスが body 要素に追加されるフィルタを削除できます。
・single page の css を変更する
・single.php にサイドバー表示（get_sidebar()）を追加する
・function.php に singler クラスを追加するフィルタを削除する関数を追加する
３つの作業で、テーマ Twenty Eleven の投稿ページにサイドバーが表示されるようになります。
以上、「テーマ Twenty Eleven の投稿ページにサイドバーを付ける」でした。
Twenty Eleven をお気に入りで使っていますが、「固定ページにもサイドバーを付けられたらな」と思っていました。
今までは簡単にできないのだろうと諦めモードに済ませていたのですが（調べて対応するのが面倒だったので。。。^^；）。
先日ふと、固定ページの表示位置を見直そうと思い確認していたところ、「固定ページの属性」の「テンプレート」に[ Sidebar Template ]を見つけました。
下の図の真ん中の「テンプレート」です。
固定ページにサイドバーを付ける「固定ページの属性」
以上、「テーマ Twenty Eleven の固定ページにサイドバーを付ける」でした。
多分特殊なケースだと思うのですが、備忘録としても残しておきます。
[現象]
「IX Web Hosting」から「Netowl StarServer」に移行時に発生した不具合です。
WordPress PHP バージョン 5.4.10 ⇒ PHP バージョン 7.1.4 への移行になりました。
不具合は起きないんだろうなぁ。。。と楽観してたのですが、以下の不具合がすぐに発生しました。
・WordPressのプラグインを更新すると、エラー表示が出るものの更新されている模様。
・プラグインの新規追加をしようと検索を行うと、検索のまま戻ってこない。
・画面の左上に「？」が表示されている。
[対応]
最初に上の２つが気になって、ググって調査をするものの、同じようなケースが見つけられず、途方に暮れるものの「FTPでファイルを更新、追加を行うと正常に設定できる」ので後回しとし、一番下の「画面の左上に「？」が表示されている」の調査を行いました。
ヘッダー作成時のゴミでも入ったかと思いましたが、ファイルに触っていないので入るはずもなく。。。
とりあえず、「？」が変なところに入っていまいか探しまくりました。
すると！
プラグイン設定時の不具合原因の「？」
ちなみに、FTPで移行した元ファイルには「？」は入って居ませんでした。
FTPのバイナリでローカルにダウンロード・アップロードしたので、おかしくなると思っていなかったのですが。。。でも、FTPでファイル操作したときに混入したと思われます。
早速、「？」を削除して「？」が出てないか確認したところ無事に表示されなくなりました。
で、不思議なことにうえの２つも正常になりました。
原因はwp-config.php の先頭の「？」でした。
とりあえず、分かっている不具合がなくなったのでこれで良しとしました^^
なかなか、WordPress は奥が深いですね。
以上、「プラグインの更新エラー＆プラグインの新規追加不具合」の対応備忘録まで。
ブログも今や常時SSL をすることが望まれる時代になってきました。
Google社はSSLで保護されているWebサイトかどうかを検索順位を付ける際の要素とすると言っていますし。
また、WordPress環境を提供してくれるレンタルサーバー会社も無料のSSLを提供してくれるなど、常時SSL化の流れができているようです。
WordPressをSSL化は、以下の手順で行います。
１）SSLサーバー証明書の入手/設定
２）WordPrssでの設定
まずは、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を設定する（初回設定）」も合わせて紹介しておきます。
プラグインでの設定が一番間違いないと思います。
お勧めのプラグインは Really Simple SSL です。
Really Simple SSL は、設定なしでサイトを SSL 対応にする軽量プラグインです。
※2018-05-11追記
Search Console Accelerated Mobile Pages に『ページにユーザー作成の JavaScript がある（重大な問題）ページからカスタム JavaScript のコードをすべて削除してください。AMP ページにカスタム JavaScript があると、Google 検索結果に AMP 固有の表示機能が表示されないことがあります。 詳細』と以下のような通達が来ました。
重大な問題のある AMP ページ
その他のお手軽な方法は.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 を検索し、インストールします。
WordPressSSL化-Really Smiple SSLインストール
インストール後、有効にするボタンをクリックします。
WordPressSSL化-Really Smiple SSL有効化
すると、以下のような確認メッセージとともに表示されますので、
Really Simple SSL – SSLを化有効にする
以上でSSL化が有効化され、かつ http から https への 301リダイレクト されるそうです。
また、上の.htaccess で行った時と決定的に違うのが、内部で参照している画像等を http → https に自動で行ってくれるので修正する必要がありません。
非常に便利です。
念のため、WordPressの設定→一般のWordPress アドレス (URL)とサイトアドレス (URL)を Https に書き換えましょう。
以上、WordPressのSSL化の紹介でした。
読んで字のごとく、常にSSL状態にあることを言いますが、どうやら全てのコンテンツ・ページがSSLで守られてることを言うそうです。
言い換えるとHTTPSしか使わないWebサイトのことになります。
今までは、Webサイトのログインページページ、メールなどの問い合わせページなど特定のページだけをSSLで保護していましたが、常時SSLは、その他すべてのページをSSL化することです。
常時SSL化はセキュリティ強化だけでなく、ユーザとウェブサイト運営者の双方にさまざまなメリットがあります。
SSLでデータの通信を暗号化し、盗聴や改ざんを防ぐとで、SSL化されたウェブサイトは、URLの頭が「HTTPS」となり、通信の暗号化が保証されます。
どのページも安全になり、訪問者も安心して見ることができます。
Googleは、2014年8月に、ウェブサイトがHTTPS(常時SSL)かどうかを検索順位の決定要因にすることを発表しました。
すべてのWebサイトに対してHTTPからHTTPSへの切り替えを推奨しています。
また2015年12月には、常時SSL化されたウェブサイトでHTTPページとHTTPSページが同じコンテンツであれば、HTTPSページを優先的にインデックスするというアナウンスを行いました。
また、「HTTPサイトは安全でない」と主要ブラウザが警告強化を出すようになってきています。
これらの動きは、訪問者が安心してWebサイトを見ることができるためのインフラ整備と考えて良いと思います。
安全な環境を整備することで「ユーザが安心して利用ができる優良なコンテンツである」と評価されることになります。
リファラ（ Referrer ）を参照することで、どこからそのページに要求が来たのかを知ることができ、アクセス解析に利用できます。
しかし、https: から http: へのリンクでは、 リファラは送らないことになっています。
そのため、常時SSL化していないとアクセス解析が漏れるケースが出てきます。
Google検索自体は既に常時SSL化されています。
訪問者がGoogleで検索した検索結果をクリックしてウェブサイトに来た場合、WebサイトがHTTPSであればGoogle検索から来た訪問者としてアクセスログに残ります。
HTTP/2とは、HTTPより、高速に表示させるための通信プロトコルです。
主要なWebブラウザはHTTP/2をサポートしています。
ただ、Webブラウザにおいては、HTTP/2は https 上でのみサポートされているので、SSL化されていないと HTTP/2 は使用されません。
他にもWebサーバー事態にも HTTP/2 モジュールが導入されていないとダメですが、随時使用できるようになると思います。
尚、以前はHTTPSの導入で表示が遅くなったと言う話が聞かれましたが、PCの高機能化やサーバーの高機能化に伴い暗号化/復号化にかかる時間が短縮されたため現在は気にする必要が有りません。
SSLとは、Secure Sockets Layer の略のことで、1994年にNetscapeによって開発された世界標準のセキュリティーテクノロジーです。
現在は、Transport Layer Security（トランスポート・レイヤー・セキュリティ、TLS）が正式な名称ですが、TLSの元になったプロトコルがSSLであったため、現在でもSSLと呼ばれることが多いです。
TSLもSSLも、インターネットなどの公開されたコンピュータネットワークにおいて安全性を担保し通信を行うためのプロトコルです。
主な機能として、「通信相手の認証」、「通信内容の暗号化」、「改竄の検出」があります。
バージョンは、以下のように推移しています。
SSL 1.0 ：実装されず破棄されました。
SSL 2.0 ：1995年
SSL 3.0 ：1996年 後に脆弱性が問題になりTLSへ移行
TLS 1.0 ：1999年
TLS 1.1 ：2006年
TLS 1.2 ：2008年 2017年12月現在に至る
TLS 1.3 ：草案中
SSLを利用するためには、Webサーバーに証明書を登録する必要が有ります。
証明書のレベルにもよりますが、一定以上の証明と言えるでしょう。
しかし、フィッシング詐欺に使われることもありますので、注意が必要です。
SSLサーバ証明書は大きく分けて2つの種類があります。
ドメイン認証型と企業認証型のSSLサーバ証明書です。
企業認証のSSLサーバ証明書は、SSLによる暗号化機能に加えて、Webサイト運営組織が本当に存在しているかをSSL証明発行者が直に確認して発行されるSSLサーバ証明書です。
企業・組織の実在性を、登記事項証明書や第三者データベースに基づくインターネットを経由しない「電話による確認」が行われるため、ドメイン認証型よりも高い信頼性を実現しています。
そのため企業認証型のSSLサーバ証明書は、個人や個人事業主が取得することはできません。
ドメイン認証のSSLサーバ証明書は、SSL/TLSの暗号化のみに特化したSSLサーバ証明書です。
ドメイン名の所有名義を確認して、SSLサーバ証明書を発行します。
個人でも取得できます。
ドメイン名を所有していれば、誰でもSSLサーバ証明書の取得が可能なため、Webサイト運営組織が本当に存在しているかどうかは確認できません。
そのため、悪意のある個人や組織がパスワードやクレジットカード番号を盗み取ろうとするフィッシング詐欺に利用されるケースもあり、利用者側で注意が必要になります。
SSLを利用すると、通信される情報を暗号化できます。
インターネットは送受信中に情報を見られることがあります。
しかし、暗号化することによって情報が守られ、簡単に盗み見されることはありません。
ただし、SSLに使われる暗号方式によっては、危険があります。
例えば、TLS 1.2ではすでに危殆化したDES、RC4、MD5、SHA1が選択可能であり、この事が脆弱性の原因となっています。
TLS 1.2を使用しかつDES、RC4、MD5、SHA1で暗号化していた場合、最悪情報は盗み見されます。
しかし、あくまでも可能性の話ですので、適切にSSLを利用したWebサイトを利用している限りほぼ大丈夫です。
WordPressにおいてのSSLは、WebサーバーとWebブラウザーとの間で、データを暗号化し送受信できる通信方法です。
WordPressはもともと情報発信をするブログなので個人情報やクレジットカード情報をやり取りすることはありません。
コメントを登録する際に個人情報の一部を登録することになりますが、ニックネームやyahooメールなどを利用すれば十分ですので、あえて本名やメインメールアドレスを書くことはないと思います。
企業がWordPressで大々的な販売システムや情報システムやホームページを運営している場合は、上のことは当てはまりませんが、個人でブログ運営は上の通りと思います。
しかし、今やGoogle社が考えている通り、通常からSSLを使用する（常時SSL）のが当たり前となりそうです。
実際、WordPress環境を提供するレンタルサーバー会社は無料のSSLを提供しています。
ここは時代の流れと思い、WordPressにもSSL化をすべきでしょう。
現在、IX Web Hosting からネットオウルのスターサーバー(StarServer)へサーバー移動をしています。
その際、ネットオウルのスターサーバー(StarServer)では、移転前動作確認URLを利用できるのですが、少し悩んだのでメモしておきます。
ただ、特にWordPressに関係する話ではないので、自分の備忘録です。
移転前動作確認URLは、ドメインのネームサーバーを変更する前にサイトを確認できるURLを発行できます。
既に他社でサイトを運営している場合のサイト移転などの確認に活用できます。
ただ、注意点があります。
最初にドメインを登録した後、SSLを使用する前にすぐに取得する必要が有ります。
SSLを取得後は、発行の依頼を運営に行う必要が有り、時間を食うことになります。
取得した移転前動作確認URLの後ろにサブドメインを含むURLを付加します。
例）
このドメインは「bia.jp」です。
サブドメイン「wordpress」です。
http://bia-jp.check-netowl.jp/wordpress.bia.jp/ でアクセスします。
この他、bia.jpのルートディレクトリの .htaccess ファイルでリダイレクトする方法も有るようです。
以上、備忘録まで。
2017年11月30日、WordPress 4.9.1 がリリースされました。
WordPress 4.9.1は、WordPress 4.9 およびそれ以前のバージョンで、4件の潜在的にマルチベクトル型攻撃の一部として機能し得るセキュリティ問題が存在していました。
セキュリティ強化コアチームの継続的なコミットにより、WordPress 4.9.1 でそのセキュリティ問題が修正されました。
また、セキュリティに関する問題に加えて WordPress 4.9.1 では11件のメンテナンス修正が実施されています。
詳しくは下のWordPress Codex 日本語版 Version 4.9.1 のページで確認してください。
『WordPress Codex 日本語版 Version 4.9.1』
2017年11月15日、WordPress 4.9 が公開されました。
4.9 の新機能は、デザインワークフローをスムーズにし、コーディングエラーのミスをしなくて済むようにチェックをしてくれます（らしいです）。
その他に、下書きから公開までを予約できたり、記事の編集を複数で行っている場合の編集衝突防止や、公開前にプレビューを編集者以外にも見えるようにするプレビューリンクなどがあります。
まだいろいろな機能が追加・変更されています。
詳しくは下のWordPress Codex 日本語版 Version 4.9 のページで確認してください。
『WordPress Codex 日本語版 Version 4.9』