てくてく について

日頃はVisual StudioとSQL Serverで仕事をしているアラフィフティのおじさんです。 趣味は歩くこと、本を読むこと、映画を見ること、アニメをみること Wordpressについていろいろ書いていきたいと思います。よろしく!

WordPress の日本語版と英語版の違い

WordPress の日本語版と英語版の違い

一昨日 WordPress 4.9.3 がリリースされましたが、今朝になってまた WordPress 4.9.4 がリリースされました。
どうやら 4.9.3 の重大なバグが発見され、緊急修正・リリースされようです。

今は自動リリースされてしまうので既に WordPress 4.9.3 になっています。
そんな重大なバグなら早速と思ったのですが、自動更新ができな不具合を修正したみたいですね。慌てることもないかな。
でもまぁこの際忘れて放置も困るので 4.9.4 に更新しとくのが良いかと。
日本語版は出ていないようなのでとりあえず、オリジナルの英語版の英語版を入れることになるのですが、そこで今更ながらオリジナルの英語版と日本語版の主な違いを調べてみました。

ちなみに、-jaが付くものが日本語版です。
英語版は WordPress 4.9.4
日本語版は WordPress 4.9.4-ja 「 WordPress.org 」からダウンロードできます。

WordPress の日本語版と英語版の主な違い

・ WordPress に日本語翻訳ファイルが付いてくるかどうか
・ WP Multibyte Patch プラグインの同梱
・ readme.html の日本語化
・ wp-config-sample.php の日本語化
・ version.php に $wp_local_package = ‘ja’; が付加されている
・ 新規インストール時の設定初期値が日本語版は、タイムゾーンが東京、サイトの言語が日本語

英語版の日本語化

もともと日本語版の WordPress がインストールされていれば、何もする必要はないようです。

初めてインストールする場合のみ、日本語化します。
で、 WordPress は多言語対応なので、英語版の言語設定を変更するだけで日本語化できるようです。
上の差異から、
・サイトの言語
・ユーザー毎の言語
を変更して、
・WP Multibyte Patchプラグインをインストール

とりあえず、・タイムゾーンを東京もかな?
しなくても日本語化になるけど、、、

以上で、日本語化完了です。
気になるようなら、WordPress 4.9.4-ja が出るのを待って更新すれば良いですし。

以上、「WordPress の日本語版と英語版の違い」についてでした。

WordPress 4.9.4 メンテナンスリリース

WordPress 4.9.4 メンテナンスリリース

2018年1月6日、WordPress 4.9.4 がリリースされました。

WordPress 4.9.4 では 4.9.3 の重大なバグが修正されています。
重大なバグとは、自動更新が出来なくなってしまった不具合だそうです。
自動バックグラウンド更新をサポートするサイトでも自動的に更新されませんので、4.9.4 に更新されるための手動で実施する必要があります。

詳しくは下のWordPress Codex 日本語版 Version 4.9.4 のページで確認してください。(2018/2/7日時点では日本語版のページが作成されていません)
『WordPress Codex 日本語版 Version 4.9.4』
『WordPress Codex Version 4.9.4』

WordPress 4.9.3メンテナンスリリース

WordPress 4.9.3 メンテナンスリリース

2018年2月5日、WordPress 4.9.3 がリリースされました。

WordPress 4.9.3 では、Customizer チェンジセット、ウィジェット、ビジュアルエディタ、および PHP 7.2との互換性に関する修正を含む、4.9の34のバグが修正されています。

詳しくは下のWordPress Codex 日本語版 Version 4.9.3 のページで確認してください。(2018/02/07 日時点では日本語版ページが作成されていません)
『WordPress Codex 日本語版 Version 4.9.3』
『WordPress Codex Version 4.9.3』

WordPress 4.9.2セキュリティ・メンテナンスのリリース

WordPress 4.9.2セキュリティ・メンテナンスのリリース

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 の投稿ページにサイドバーを付ける

テーマ Twenty Eleven の投稿ページにサイドバーを付ける

少し前に「テーマ Twenty Eleven の投稿ページにサイドバーを付ける」を投稿したので、ここは投稿ページにもサイドバーを付けてみようかと思い調査しました。
投稿ページは、固定ページみたいに簡単に付きませんでした。
が、ググってみると簡単にできますというWebサイトを見つけたので参考にしながら試行錯誤して付けてみました。
ちなみに、ググって見つけたWebサイトのやり方では表示されるのですが、下に付く形で表示されてしまい「なんだかぁ~」って感じになってました。

テーマ Twenty Eleven の投稿ページにサイドバーを付ける方法

試行錯誤で試しながら付けたため、どのWebサイトでも正常に表示されるか保証はできません。
でも、テーマ Twenty Eleven を使っているなら、たぶん正常に表示されると思います。

single page の css を変更する

「 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 が入って居なかったため、子テーマディレクトリに 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(); ?>

この作業までだと、サイドバーは表示されるのですが、正常な位置・表示して欲しい位置に表示されません。
パソコン表示では、本文の下に表示されるような形になってしまいました。

body要素に「 singler 」クラスを追加するフィルタを削除します


/**
 * 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 クラスを追加するフィルタを削除する関数を追加する

3つの作業で、テーマ Twenty Eleven の投稿ページにサイドバーが表示されるようになります。

以上、「テーマ Twenty Eleven の投稿ページにサイドバーを付ける」でした。

テーマ Twenty Eleven の固定ページにサイドバーを付ける

テーマ Twenty Eleven の固定ページにサイドバーを付ける

Twenty Eleven をお気に入りで使っていますが、「固定ページにもサイドバーを付けられたらな」と思っていました。
今までは簡単にできないのだろうと諦めモードに済ませていたのですが(調べて対応するのが面倒だったので。。。^^;)。

テーマ Twenty Eleven の固定ページにサイドバーを付ける方法

先日ふと、固定ページの表示位置を見直そうと思い確認していたところ、「固定ページの属性」の「テンプレート」に[ Sidebar Template ]を見つけました。
下の図の真ん中の「テンプレート」です。

固定ページにサイドバーを付ける「固定ページの属性」

固定ページにサイドバーを付ける「固定ページの属性」


早速、[ Sidebar Template ]に更新をしたところ、無事に表示されるようになりました。

以上、「テーマ Twenty Eleven の固定ページにサイドバーを付ける」でした。

プラグインの更新エラー&プラグインの新規追加不具合

プラグインの更新エラー&プラグインの新規追加不具合

多分特殊なケースだと思うのですが、備忘録としても残しておきます。

[現象]
「IX Web Hosting」から「Netowl StarServer」に移行時に発生した不具合です。
WordPress PHP バージョン 5.4.10 ⇒ PHP バージョン 7.1.4 への移行になりました。
不具合は起きないんだろうなぁ。。。と楽観してたのですが、以下の不具合がすぐに発生しました。

・WordPressのプラグインを更新すると、エラー表示が出るものの更新されている模様。
・プラグインの新規追加をしようと検索を行うと、検索のまま戻ってこない。
・画面の左上に「?」が表示されている。

[対応]
最初に上の2つが気になって、ググって調査をするものの、同じようなケースが見つけられず、途方に暮れるものの「FTPでファイルを更新、追加を行うと正常に設定できる」ので後回しとし、一番下の「画面の左上に「?」が表示されている」の調査を行いました。
ヘッダー作成時のゴミでも入ったかと思いましたが、ファイルに触っていないので入るはずもなく。。。

とりあえず、「?」が変なところに入っていまいか探しまくりました。
すると!

プラグイン設定時の不具合原因の「?」

プラグイン設定時の不具合原因の「?」


なんと! wp-config.php の先頭に?が居ました。

ちなみに、FTPで移行した元ファイルには「?」は入って居ませんでした。
FTPのバイナリでローカルにダウンロード・アップロードしたので、おかしくなると思っていなかったのですが。。。でも、FTPでファイル操作したときに混入したと思われます。

早速、「?」を削除して「?」が出てないか確認したところ無事に表示されなくなりました。

で、不思議なことにうえの2つも正常になりました。
原因はwp-config.php の先頭の「?」でした。

とりあえず、分かっている不具合がなくなったのでこれで良しとしました^^
なかなか、WordPress は奥が深いですね。

以上、「プラグインの更新エラー&プラグインの新規追加不具合」の対応備忘録まで。

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 対応にする軽量プラグインです。

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

RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://(ドメイン名)/$1 [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化の紹介でした。

常時SSLとは

常時SSLとは

読んで字のごとく、常にSSL状態にあることを言いますが、どうやら全てのコンテンツ・ページがSSLで守られてることを言うそうです。

言い換えるとHTTPSしか使わないWebサイトのことになります。
今までは、Webサイトのログインページページ、メールなどの問い合わせページなど特定のページだけをSSLで保護していましたが、常時SSLは、その他すべてのページをSSL化することです。

常時SSL化はセキュリティ強化だけでなく、ユーザとウェブサイト運営者の双方にさまざまなメリットがあります。

どのページも安全

SSLでデータの通信を暗号化し、盗聴や改ざんを防ぐとで、SSL化されたウェブサイトは、URLの頭が「HTTPS」となり、通信の暗号化が保証されます。
どのページも安全になり、訪問者も安心して見ることができます。

Googleの検索順位が上がるかも

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/2とは、HTTPより、高速に表示させるための通信プロトコルです。
主要なWebブラウザはHTTP/2をサポートしています。
ただ、Webブラウザにおいては、HTTP/2は https 上でのみサポートされているので、SSL化されていないと HTTP/2 は使用されません。
他にもWebサーバー事態にも HTTP/2 モジュールが導入されていないとダメですが、随時使用できるようになると思います。

尚、以前はHTTPSの導入で表示が遅くなったと言う話が聞かれましたが、PCの高機能化やサーバーの高機能化に伴い暗号化/復号化にかかる時間が短縮されたため現在は気にする必要が有りません。

SSLとは

SSL

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サイト運営組織が本当に存在しているかどうかは確認できません。
そのため、悪意のある個人や組織がパスワードやクレジットカード番号を盗み取ろうとするフィッシング詐欺に利用されるケースもあり、利用者側で注意が必要になります。

<2>通信内容の暗号化

SSLを利用すると、通信される情報を暗号化できます。
インターネットは送受信中に情報を見られることがあります。
しかし、暗号化することによって情報が守られ、簡単に盗み見されることはありません。

ただし、SSLに使われる暗号方式によっては、危険があります。
例えば、TLS 1.2ではすでに危殆化したDES、RC4、MD5、SHA1が選択可能であり、この事が脆弱性の原因となっています。
TLS 1.2を使用しかつDES、RC4、MD5、SHA1で暗号化していた場合、最悪情報は盗み見されます。
しかし、あくまでも可能性の話ですので、適切にSSLを利用したWebサイトを利用している限りほぼ大丈夫です。

WordPressにおけるSSL

WordPressにおいてのSSLは、WebサーバーとWebブラウザーとの間で、データを暗号化し送受信できる通信方法です。
WordPressはもともと情報発信をするブログなので個人情報やクレジットカード情報をやり取りすることはありません。
コメントを登録する際に個人情報の一部を登録することになりますが、ニックネームやyahooメールなどを利用すれば十分ですので、あえて本名やメインメールアドレスを書くことはないと思います。
企業がWordPressで大々的な販売システムや情報システムやホームページを運営している場合は、上のことは当てはまりませんが、個人でブログ運営は上の通りと思います。

しかし、今やGoogle社が考えている通り、通常からSSLを使用する(常時SSL)のが当たり前となりそうです。
実際、WordPress環境を提供するレンタルサーバー会社は無料のSSLを提供しています。
ここは時代の流れと思い、WordPressにもSSL化をすべきでしょう。