WordPressの構築を見直す2015

留守中の姉の部屋で食べる「きのとや」のチーズタルトおいしいです ŧ‹”ŧ‹”(•ㅂ•)ŧ‹”ŧ‹”

シルバーウィークの間、札幌の実家に帰省中です。といってもほぼ毎日、仕事をしているわけですが…

久しぶりに、WordPressの案件が入りました。最近は新着情報など小さな組み込みが続いたので、まとまった案件はほぼ一年ぶりです。
いずれにしてもいちから作り直しになるので、テーマやプラグインを見直すことにしました。

参考にした資料

WordPressの人気テーマ「BizVektor」を公開している株式会社ベクトルさんが、よりカスタマイズに特化したテーマ「Lightning」をリリースしています。

https://wordpress.org/themes/lightning/

また、先月開催された「WordFes NAGOYA」は、ウェブサイトそのものがオープンソースとなっており、最終のプラグインとテーマ一式が、GitHubで公開されています。

https://github.com/WordBenchNagoya/WordFes2015

これらを参考に、知らない関数を調べながら見直しを行いました。

あわよくば、そのまま使えれば…などと思いましたが、何が入るかわからない前提で作られている一般配布用のテーマは実務制作には冗長すぎ、やっぱり部分的に引用させてもらう感じです。

META関連の見直し

META関係のプラグインは長年「All in One SEO」を使ってきたのですが、最近評価が高い「Yoast SEO」の方が、SNSも含めた細かい調整がしやすいことがわかったので、今回から変更することにしました。

https://ja.wordpress.org/plugins/wordpress-seo/

また、WordPress4.1から、title要素の自動生成がコアに実装されたこともわかりました。

http://wpdocs.osdn.jp/関数リファレンス/add_theme_support

functions.phpに以下の一行を書くと自動生成が有効になり、header.php内にtitle要素を書く必要がなくなります。

add_theme_support( 'title-tag' );

つまり「Yoast SEO」などのプラグインを併用すると、WordPressは案件ごとにMETAを書き換える必要が一切なくなったことになります。これはけっこうすごいことですね。
具体的には以下の通りです。IE9対応もやめたいくらいです。

<!DOCTYPE html>
<html <?php language_attributes(); ?>>
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1">
<!--[if lt IE 9]>
<script src="https://oss.maxcdn.com/html5shiv/3.7.2/html5shiv.min.js"></script>
<script src="https://oss.maxcdn.com/respond/1.4.2/respond.min.js"></script>
<![endif]-->
<?php wp_head();?>
</head>

インクルードファイルの整理

WordPressテーマでは、別ファイルを呼び出すときはinclude・requireではなく、get_template_part関数を使用することが推薦されています。

http://wpdocs.osdn.jp/関数リファレンス/get_template_part

これの第一引数に「スラッシュ」を含められることを知りませんでした。
例えば、以下のように書けばテーマ内の「module/functions-posttype.php」を呼び出すことになります。

get_template_part( 'module/functions', 'posttype' );

すべてのインクルードファイルをmoduleディレクトリに入れ、ネームスペースをつけることで、かなりテーマの保守性が向上しました。

ページネーション生成関数の追加

これまで、WordPressのページネーションはプラグインを利用するしかありませんでしたが、4.1からついにコア関数が実装されました。
こちらの記事で、各引数が詳しく紹介されています。

WordPressにページネーションを出力できるthe_posts_pagination()とget_the_posts_pagination() – YOUNG FLAVOR

とても嬉しい話ですが、以下の通りスクリーンリーダー向けのh2要素が問答無用で入ってしまいます。理想を追い求めるWordPressらしい仕様ですが現実としては邪魔です。

<nav class="navigation pagination" role="navigation">
	<h2 class="screen-reader-text">投稿ナビゲーション</h2>

・・・
</nav>

現状ではフックも用意されていないので、bootstrapを利用するなら、以下の通りreplaceをかませて「sr-only」クラスを追加するのが無難でしょう。

<?php
	$args = array(
		'mid_size' => 3,
		'prev_text' => '&laquo;',
		'next_text' => '&raquo;',
	);
	$navigation = get_the_posts_pagination($args);
	echo str_replace('screen-reader-text', 'screen-reader-text sr-only', $navigation);
?>

共通パーツ管理の見直し

トップページやサイドバー、フッタの住所表記など、納品後にクライアント側が変更する可能性がある箇所は、これまで専用のカスタム投稿タイプを作って管理していました。

「カスタム投稿タイプ」機能で編集可能エリアを作る | WordPress | CMSテクニック集 | CM3S

Movable Type案件でウェブページを使っての管理がクライアント側の感触が良かったことや、WordPressのテーマを直接編集させるとPHPエラーで真っ白になってしまう危険があったことからです。

ですが、最近のWordPressはテーマカスタマイザーの操作性がとても良くなったので、ウィジェットにした方が、見たまま編集ができていいかなと考えています。

何年経っても変わらない不具合

いろいろと新しい機能が増えましたが、どういうわけか、何年経っても改善されないものもあります。
wp_get_archives関数で生成するアーカイブリストに「年」がつかない不具合です。

これはLightningテーマでも修正用フックが書かれていますが、カスタム投稿タイプのアーカイブには効かない様子なので、多言語対応でなくてもいいなら、下記のTIPSを参照ください。

wp_get_archivesの年別リストに「年」が付かないバグを回避する | WordPress | CMSテクニック集 | CM3S

テーマの書式に悩む

細かい話ですが、コーディングルールでも悩んでいたりします。
WordPressテーマには、厳密なコーディングルールがあります。将来的にはなにか配布したいので、今から併せておきたいところです。

https://wpdocs.osdn.jp/WordPress_コーディング基準

このうち「インデントはタブで書く」ということになっているのが悩ましいです。
タブはエディタにより体裁が変わってしまうので、HTMLコーディングには使いたくないです。

他にもたくさんありますが、細かすぎてきりがないので、この辺で切り上げます。

「アンラーン（Unlearn）」という言葉があります。「学び壊し」という意味で、これまで見に付けた古い学びを一旦捨てて、自己の成長を即すというものです。

先日のWCANで「CMS構築における知識の停滞」について話しました。制作の王道パターンができてしまうとそれ以上学ばなくなり、古い知識をいつまでも使うようになります。
私の場合、案件の割合が少ないWordPressがそうなりやすいので、できる限り効率が良く、新しい情報を得るようにしたいものです。

Blog