WP-カスタマイズ

PHP7.2にして、Wordpressを動かして見ると、

count(): Parameter must be an array or an object that implements Countable in …(ファイルパス)/wp-includes/post-template.php on line 284

なワーニングメッセージが。

調べてみるとPHP7.2 になって count関数 が変わった模様。
PHP 公式マニュアル

バージョン 説明
7.2.0 count() will now yield a warning on invalid countable types passed to the array_or_countable parameter.

引数が配列かカウントできるオブジェクトじゃないとワーニングを出しますよー。
ってことになったらしい。

で、件の post-template.php では

if ( $page > count( $pages ) ) // if the requested page doesn't exist
	$page = count( $pages ); // give them the highest numbered page that DOES exist

と $pages がどんなオブジェクトがわからないまま、count関数の引数に使われているのでワーニングが出た模様。

$pages が空(NULL)の場合にワーニングが出るので、count関数を使う前に$pagesが空かどうかのチェックを入れればOK。
空の場合は0を入れてあげます。

if ( ! empty( $pages )) {
    if ( $page > count( $pages ) ) // if the requested page doesn't exist
    	$page = count( $pages ); // give them the highest numbered page that DOES exist
} else {
    $page = 0;
}

コンピュータプログラムの世界では 空(NULL) = 0 かどうかか環境依存だったりするので、ややこしいですね。

ひとまず該当箇所を修正して、ファイルを上書きすればワーニングは出なくなります。

昨今、Webサイトの常時SSL化は必須の流れになってきています。
その流れに沿って自分の管理しているサイトもSSL化していますが、wpXサーバーでのWordpressサイトの独自SSL化でハマった箇所があったのでメモ。

wpXでの独自SSL化は管理画面のメニューにもあり、マニュアルもあるので大半は流れに沿っていけば問題ないかと思います。
[ 独自SSL設定 | wpXクラウド – WordPress専用のクラウドサービス ]

その中でハマったのが、マニュアルに沿って一通り設定が完了し、サイト自体もSSL化がされた鍵マークがついたので訪問者が閲覧する分には問題ありません。

が、Wordpressの管理画面内、一般設定のWordpressアドレスとサイトアドレスが http:// のままなのです。
直接編集しようにもグレーアウトされ入力は不可となっています。
一応、phpMyAdmin でデータベース内のデータを確認してみると、こちらは optionテーブル内の home と siteurl はきちんとhttpsに変わっています。
wpXのSSL化補助機能を使った結果できちんと反映されています。
が、WPの管理画面では反映されていない。なぜ？why?

いろいろ調べてみるとwp-config のファイル内で siteurl や home が定義されていると管理画面内ではグレーアウトするようです。

なるほど。wp-config で定義されている可能性があるな。
しかしwpX サーバーへFTPアクセスできるフォルダは wp-content フォルダ。 wp-config があるのはその一つ上のフォルダ。アクセスできんじゃないか！！
と思ったが、ちゃんと解決策もあるようで、wpXのFTP接続設定のオプションで接続先フォルダを変更できるものがあったようだ。

FTPオプションを変更して、wp-config にアクセスして(これもそのままじゃ権限の関係で編集できないので、アクセス権の変更が必要です)、案の定 home と siteurl が定義されていたので https に変更して、ようやくひと段落です。

原因が分かればさくっと解決できたのだが、何事もその原因追求に時間と手間がかかるのよねー。

そもそもSSL化補助機能で wp-config の変更もやってくれればよかったのにね。

結構前に利用していたWordpressのプラグインの「wp-tegaki」。
長い間、更新されていないし、利用PHPのバージョンを7.1に上げた(*)際に、エラーで管理ページも開けなくなったので代替としてWebフォントを使うことに。
(* サーバーはさくらインターネットを利用しています。)

WordPressでは星の数ほどテーマはありますが、配信されているテーマをそのまま使うことはほとんど無く、カスタマイズした「子テーマ」として利用します。

子テーマ自体は他のサイトで沢山
[ 子テーマ – WordPress Codex 日本語版 ]

子テーマの設定

子テーマが実装された当初は style.css に親のstyle.cssを @import で読み込むことが定番だったけれど、昨今はfunction.phpで読み込み処理をするのが定番なのね。

style.css

/*
 Theme Name:   Twenty Fifteen Child
 Template:     twentyfifteen
*/

スタイルシートヘッダにはいろいろ記載項目はありますが、最低限子テーマの名前となる「Theme Name」と親テーマとなる「Template」を設定してれば子テーマとして認識されます。
ちなみにTemplateは親テーマの名前ではなく、フォルダ名なので注意です。

function.php

add_action( 'wp_enqueue_scripts', 'theme_enqueue_styles' );
function theme_enqueue_styles() {
    wp_enqueue_style( 'parent-style', get_template_directory_uri() . '/style.css' );

}

function.php では親テーマのcssファイルを読み込むコードを書きます。

Webフォントの選択

Webフォントを公開しているサイトはいろいろありますが、Googleでも公開されています。
日本語フォントも試験的に提供されています。

[ Google Fonts ]

[ Google Fonts + 日本語 早期アクセス • Google Fonts + Japanese Early Access ]

Webフォント用に funtion.php の編集

Webフォントを利用するのに読込が必要なCSSファイルがあります。

たとえば Google Fonts日本語のM+1pフォントを使う場合

<link href="https://fonts.googleapis.com/earlyaccess/mplus1p.css" rel="stylesheet" />

href属性で指定してる部分が読み込むCSSファイルになります。

これを読み込み処理を function.php に追加します。

function WebFontCSS() {
    wp_enqueue_style('mpuls1','https://fonts.googleapis.com/earlyaccess/mplus1p.css', array(), null, 'all');
}
add_action('wp_enqueue_scripts', 'WebFontCSS');

CSSでWebフォントの適用

style.css

.wf-mplus1p { font-family: "Mplus 1p"; }

使いたい箇所のCSSクラスのfont-family に追加したWebFontを設定してあればOKです。

photo credit: Defence Images via photopin cc

先日二重認証を行ったがブルートフォースアタックはまだあるみたいなのでBASIC認証も行うようにしてみた。

BASIC認証用のID/パスワードファイルを作成・設置

[ .htaccess ファイルを簡単作成「.htaccess Editor」 ]
.htaccess Editor のサイトで .htaccess ファイルも作成できるので便利。

パスワードファイルを置く場所はサイトからアクセスできない場所が望ましい。
さくらインターネットであれば、/home/ユーザー名/www/ 以下がサイトで利用する場所なので、www ディレクトリと同じ階層にディレクトリを作成してその中にパスワードファイルをアップロードすればよい。

wp-admin ディレクトリをBASIC認証の対象にする

htaccess Editorでパスワードファイルを作成時にきちんとパスワードファイルのアップロード場所まで確定しているのであれば、htaccess Editorで作成された .htaccess ファイルをそのまま wp-admin フォルダにアップロード。

.htaccess ファイル例

AuthType Basic
AuthName "Secure Area"
AuthUserFile "/home/xxxx/.htpasswds/passwd"
require valid-user


設置後管理画面にアクセスすると認証用のダイアログが出ると思うのでパスワードファイル作成時のID と パスワードでログインできればOK。

wp-login.php を BASIC認証の対象にする

WordPressのログイン画面も認証するように。
Wordpress設置時に作成された .htaccess ファイルに上記のwp-adminのBASIC認証と同じ認証するように追加する。


<FilesMatch "wp-login.php">
AuthType Basic
AuthName "Secure Area"
AuthUserFile "/home/xxxx/.htpasswds/passwd"
require valid-user
</FilesMatch>


これで管理画面へログインする際に、BASIC認証 → WordPressログイン という二段構えになる。

参考サイト：[ WordPress の wp-login.php をブルートフォースアタックから守る | Web Design Leaves ]

photo credit: Michael Heilemann via photopin cc

WordPressにて運用していくうちにカテゴリ名を変えたり、タグ名を変えたりして記事の再整理を行うことがままあります。

通常であればカテゴリとタグはそれぞれ別IDで管理され互いに干渉することは無いのですが、名前の変更操作で両方の名前とスラッグが同じにしてしまうと、カテゴリとタグが同一扱いになってしまいます。
そうなってしまうとカテゴリ名だけを変えたのにタグの名前も変わってしまったり、その逆の場合も起こります。

自分の管理しているサイトもその状況になってしまい管理画面からは分離作業が行えないため、データベースを直接書き換えなきゃだめかな・・・と思ってたとき下記記事を発見しました。

[ WordPressでカテゴリ・タグを作成する際に気をつけるべきこと | blog.ks-product.com ]

新たに別名のタグを作成し、該当記事にタグ付をして、古いタグを削除する という方法です。

カテゴリとタグとで名前の変更が連動してしまったため、削除も片方を削除すると両方削除されてしまうのではないか…と危惧してましたが連動してしまうのは名前付けのところだけとのことで、不要なタグの方は削除しても問題なかったです。

カテゴリやタグの名前を変更するときは気を付けましょうね。