制作過程

Yusuke Takahashi edited this page Jan 19, 2017 · 19 revisions

A simple WordPress theme for everyone, build with Underscores and Bootstrap 4.

UnderscoresBootstrap 4を使ってシンプルなWordPressテーマを制作するプロジェクトです。WordPress公式ディレクトリへの掲載を目標としています。

※UnderscoresとBootstrapでブログサイトを構築した、littlebird-themeの続編プロジェクトでもあります。

テーマのコンセプト

  • あまねく世界中の人に広く使ってもらえるテーマ
  • 誰にでも文章を書きやすく想いを伝えやすいテーマ

テーマの特徴

ユーザーフレンドリー

初心者でも使いやすいシンプルな設計。複雑な機能は搭載しない。

モバイルファースト

モバイルデバイスでの読みやすさ、操作しやすさを重視したデザイン。

サステイナビリティー

時代に対応した最新のフレームワークを使用し、いつでもアップデートできる仕組みを導入。

完成イメージ

Requrements(制作ツール)

制作方針

  • スターターテーマとCSSフレームワークのメリットを活かし、必要最低限の工数でテーマの完成を目指す。
  • 最新のBootstrap 4(アルファ版)を使いつつ、将来Bootstrapがアップデートされても対応できる設計にする。
    bower installすれば、いつでも更新できるように)
  • 事前にデザインカンプは作成せず、実際にブラウザでの表示を確認しながら調整を進める、インブラウザデザインの手法を取り入れる。
  • テーマの制作過程にテーマレビューの手法を取り入れ、公式ディレクトリの審査に通りやすい制作フローを追求する。

制作過程

  1. テーマ制作環境の構築
  2. テーマの制作
  3. 公式ディレクトリへの申請準備
  4. デモサイトの作成
  5. 継続的インテグレーション(CI)の導入
  6. 公式サイトの作成

テーマ制作環境の構築

ローカル仮想環境の構築

WordPressの仮想環境を簡単に構築できるVCCWで、ローカルに開発環境を準備しました。
今回はVCCW本体を外部ディレクトリである/vccw/配下へ配置し、プロジェクトフォルダ内には、Vagrantfilesite.ymlだけ設置する形でローカル環境を構築しました。
※この手法について、詳しくはsimple-vccw-env解説記事を参考にしてください。

今回は公式ディレクトリ向けのテーマを作るために、WordPressのあらゆる投稿パターン等を検証できるテーマユニットテストデータを予めインポートすることにしました。(site.ymlに以下の記述を追加)

theme_unit_test: ture
theme_unit_test_uri: https://raw.githubusercontent.com/jawordpressorg/theme-test-data-ja/master/wordpress-theme-test-date-ja.xml

さらに、公式ディレクトリ向けのテーマは、日本語の他に英語版も合わせて検証する必要があるため、ローカルのWordPressをマルチサイト化して、日英2言語のデバッグ環境を同時に構築することにしました。マルチサイト機能を有効にするには、site.ymlに以下のオプションを追加すればOKです。

multisite: true

また、今回はテーマのチェックに利用できるTheme Check等のプラグインもインストールしたかったので、下記のオプションもsite.ymlに追加しました。

plugins:
  - dynamic-hostname
  - wp-total-hacks
  - tinymce-templates
  - theme-check
  - wordpress-importer

以上の設定をした上でvagrant upを実行すると、最初からマルチサイト化&テーマユニットテストデータがインポートされた状態で、ローカル環境のWordPressを利用することができます。

テーマデバッグ環境の構築

マルチサイト化したローカルのWordPress内に、英語デバッグ用の子サイトを作成します。
子サイトの作成は、管理バーのメニュー「参加サイト」→「サイトネットワーク管理者」→「サイト」の「新規追加」から行います。「サイトの言語」はEnglishにしておきましょう。

次に、英語サイトの方にもテーマユニットテストデータをインポートしたかったので、こちらからファイルをダウンロードし、管理画面のTools→Import→WordPressから「Upload file and import」を実行しました。

以上で、一つのテーマファイルを編集しながら、リアルタイムで日英2サイトの表示確認が行えるデバッグ環境を作ることができました。

ローカルでの各言語での検証サイトは下記URLとなります。

日本語 http://tsumugi.local/
英語 http://tsumugi.local/en/

スターターテーマの導入

Underscoresのサイトでテーマ名などを入力して、スターターテーマ一式を生成し、ダウンロードしました。
テーマ(ディレクトリ)名はtsumugiとし、Sassでのカスタマイズが行えるように、Sass版のチェックを入れて生成を行いました。
ダウンロードしたディレクトリ一式をwww/wordpress/wp-content/themes/tsumugi配下に設置し、管理画面から有効化することで、オリジナルのテーマを適用することができます。

※Underscoresの導入は、vagrant ssh後に以下のコマンドを実行する形でも、簡単に行うことができます。

wp scaffold _s tsumugi --theme_name="tsumugi" --author="youthkee" --author_uri="http://littlebird.mobi/" --sassify --activate

この状態では、まだ何もデザインが適用されていない、シンプルな状態となります。

英語版にも同じテーマを適用することで、こちらもテーマユニットテストデータで見た目を確認する環境が整いました。
WP-CLIで子サイトに同じテーマを適用するには、以下のコマンドを実行すればOKです。

wp theme enable tsumugi --network
wp theme activate tsumugi --url=tsumugi.local/en

CSSフレームワークの導入

Bootstrapのインストールとアップデート対応

bowerを使ってテーマフォルダ内にBootstrap 4アルファ版をインストールしました。
また、インストールと同時に不要ファイルを削除し、CSSとJS、Sass、および依存ファイル(tether.js)だけを残すように設定しました。
上記の一連の処理は、package.jsonにコマンドどして登録してあるので、今後はnpm bwupdateを実行するだけでBootstrapのインストールまたはアップデートが可能になります。

Bootstrap Sassファイルの抽出

npm bwupdateを実行すると、/bower_components/bootstrap/内のSassファイルをコピーして、/sass/bootstrap/配下へ配置するように設定しました。
/sass/フォルダには、Underscore用のSassファイルが格納されているので、これによって作業用のSassファイルが/sass/配下に集約される形になります。
Bootstrapがアップデートされた際は、再度npm bwupdateを実行することで、Bootstrap用のSassファイル一式も更新されるようにしました。

コンパイル環境の構築

gulpfile.jsにタスクを記述して、Sassのコンパイル設定を追加しました。
コンパイルに必要なパッケージは、package.jsonに記述してあるので、npm iコマンドを実行することでインストールできます。

gulpまたはnpm startを実行すると、/sass/配下で編集したSassファイルが、/配下の各ディレクトリへCSSとして書き出されます。
※今回はBootstrapオリジナルのCSSは基本上書きを行わず、BootstrapのSassをコピーしたtsumugi.scssのみを編集することにしました。

Underscoreの元CSSのフォーマットになるべく合わせるため、コンパイラはRuby Sassを使い、csscombとgulp-frepで整形を行なっています。
そのため、Sassを編集する際は、プロジェクトフォルダで下記コマンドを実行し、指定したバージョンのSassとCompassをインストールしてください。
(SassとCompassのバージョンをプロジェクトで統一するため)

bundle install --path=vendor/bundle --binstubs=vendor/bin

今回のテーマで読み込まれるCSSファイルおよびその読み込み順は、以下の通りとなる予定です。

/wp-content/themes/tsumugi/bower_components/bootstrap/dist/css/bootstrap.min.css
/wp-content/themes/tsumugi/style.css
/wp-content/themes/tsumugi/bootstrap/tsumugi.css

テーマの制作

ストラクチャーの構築

まずは色彩や装飾などのビジュアル要素ではなく、骨組み部分のスタイリングのみを行うフェーズ。
レイアウトやタイポグラフィ、各要素の大きさや余白、デバイス切替時の表示・動作の調整などを行います。

CSSとJSの読み込みを追加

functions.phpに以下の記述を追加して、CSSとJavaScriptの読み込みを指定しました。
jQueryはWordPressデフォルトのjQueryを使用し、BootstrapのJSはフッタに読み込ませる形にしました。
各CSS, JSには、それぞれ適切な依存関係とバージョンを指定しています。

function tsumugi_scripts() {
	wp_enqueue_style( 'bootstrap-style', get_template_directory_uri() . '/bower_components/bootstrap/dist/css/bootstrap.min.css', array(), '4.0.0-alpha.2', 'all' );
	wp_enqueue_style( 'underscores-style', get_stylesheet_uri(), array('bootstrap-style'), '1.0.0', 'all' );
	wp_enqueue_style( 'tsumugi-style', get_template_directory_uri() . '/bootstrap/tsumugi.css', array('underscores-style'), '1.0.0', 'all' );

	wp_enqueue_script( 'tether-js', get_template_directory_uri() . '/bower_components/tether/dist/js/tether.min.js', array('jquery'), '1.2.0', true );
	wp_enqueue_script( 'bootstrap-js', get_template_directory_uri() . '/bower_components/bootstrap/dist/js/bootstrap.min.js', array('tether-js'), '4.0.0-alpha.2', true );

	wp_enqueue_script( 'tsumugi-navigation', get_template_directory_uri() . '/js/navigation.js', array(), '20151215', true );

	wp_enqueue_script( 'tsumugi-skip-link-focus-fix', get_template_directory_uri() . '/js/skip-link-focus-fix.js', array(), '20151215', true );

	if ( is_singular() && comments_open() && get_option( 'thread_comments' ) ) {
		wp_enqueue_script( 'comment-reply' );
	}
}
add_action( 'wp_enqueue_scripts', 'tsumugi_scripts' );

BootstrapのCSSが適用されたことで、見た目が少し変わりましたが、まだデザインはシンプルなままです。

ウィジェット部分も、フッターにただ項目のリストが羅列されているだけの状態です。

normalize.cssの重複分を削除

BootstrapとUnderscoresでは、デフォルトのCSSに同じnormalize.cssが使われているので、後から読み込まれるUnderscoresのSassからインクルードを解除し、重複しているスタイル記述を削除しました。

オリジナルSassの初期設定

オリジナルSassの初期設定を行ないました。
bootstrap.scssをコピーしてtsumugi.scssを作成し、カスタマイズに必要なモジュールだけをインクルードするようにしました。
その際、オリジナルSassに読み込む各モジュールは、_*.scss_*_tm.scssのように接尾辞を付けてリネームすることとしました。
もし、Bootstrapがアップデートされた場合は、基本的に_*.scss_*_tm.scssを比較しながら、差分のみをマージしていく予定です。

.conteinerタグの追加

全体のコンテンツ幅を調整するため、HTMLテンプレート側にBootstrapの.conteinerタグを追加しました。
ヘッダとフッタ、コンテンツの各領域を100%幅でもデザイン調整できるよう、それぞれ.conteinerタグで囲む形にしました。

フォントサイズの調整

見出し回りのフォントサイズが、初期設定だと少し大き過ぎるので、以下のように_variables_tm.scss内の変数の値を修正しました。

修正前
$font-size-h1:               2.5rem !default;
$font-size-h2:               2rem !default;
$font-size-h3:               1.75rem !default;
$font-size-h4:               1.5rem !default;
$font-size-h5:               1.25rem !default;
$font-size-h6:               1rem !default;
修正後
$font-size-h1:               1.75rem !default;
$font-size-h2:               1.6rem !default;
$font-size-h3:               1.45rem !default;
$font-size-h4:               1.3rem !default;
$font-size-h5:               1.15rem !default;
$font-size-h6:               1rem !default;

また、ナビゲーションメニューやフッター、エントリーの日時やカテゴリー表記、ウィジェット部分などは小さいフォントサイズにしたかったので、それぞれのSassのモジュールでサイズ指定しました。
その際、Bootstrapには$font-size-sm$font-size-xsなどの変数が定義されているので、こちらを利用しました。 これによって、実際には0.875rem0.75remなどの相対サイズが適用されます。

UnderscoresのSassでBootstrapの変数を利用する形になるので、style.scssに以下の一行を追加しておきます。

@import "bootstrap/variables_tm";
Navbarの組み込み

ヘッダーのナビゲーション部分に、BootstrapのNavbarを組み込みたかったので、header.phpを以下のように改修しました。

navタグにnavbar navbar-lightのclassを追加し、 メニュー部分は<?php wp_nav_menu(); ?>タグで自動で生成されているので、 'menu_class' => 'menu collapse navbar-toggleable-xs'のようにパラメーターを追加する形でclassを追加しています。

修正前
<nav id="site-navigation" class="main-navigation" role="navigation">
	<button class="menu-toggle" aria-controls="primary-menu" aria-expanded="false"><?php esc_html_e( 'Primary Menu', 'tsumugi2' ); ?></button>
	<?php wp_nav_menu( array( 'theme_location' => 'primary', 'menu_id' => 'primary-menu' ) ); ?>
</nav><!-- #site-navigation -->
修正後
<nav id="site-navigation" class="main-navigation navbar navbar-light" role="navigation">
	<button class="navbar-toggler hidden-sm-up" type="button" data-toggle="collapse" data-target="#primary-menu">
		&#9776;
	</button>
	<?php wp_nav_menu( array( 'theme_location' => 'primary', 'menu_id' => 'primary-menu', 'menu_class' => 'menu collapse navbar-toggleable-xs' ) ); ?>
</nav><!-- #site-navigation -->

ただし、このままだとUnderscores標準のメニューは、完全にレスポンシブ対応されておらず、モバイル端末で表示した際にも、通常のドロップダウンメニューが表示されてしまいます。

そこで、Media Queriesを利用して、狭いデバイス幅の場合はスマホ風のリストメニューに変わるよう、CSSを調整しました。その際のブレークポイントは、Bootstrapのmixinsを使って以下のように分岐させています。

@include media-breakpoint-up(sm) {
	544px以上で適用されるスタイル
}

@include media-breakpoint-down(xs) {
	543px以下で適用されるスタイル
}

また、UnderscoresのCSS上でBootstrapのmixinsを使用するため、style.scssに以下の読み込みも追加してあります。

@import "bootstrap/mixins";

以上で、メインナビゲーションにBootstrapのNavbarを組み込み、さらにレスポンシブ対応させることができました。
尚、スマートフォンで表示した際は、ドロップダウンではなく、サブメニューも含めて通常のリストで展開される形になります。

左:モバイル対応前のメニュー。右:モバイル対応後のメニュー。

ウィジェットのレイアウト調整

ウィジェット部分ですが、1カラムだとリスト部分の余白が空いてしまい、冗長な感じになってしまうので、コンパクトにプレーンテキストとして並べる形にしたいと思います。
そこで、_widgets.scssを以下のように修正し、リスト部分のスタイルをインライン要素に修正しました。

.widget {
	margin: 0 0 1.5em;
	font-size: $font-size-sm;
	text-align: center;

	select {
		max-width: 100%;
	/* Make sure select elements fit in widgets. */
	}
	ul {
		display: inline;
		padding-left: 0;
		li {
			display: inline;
			&::before {
				content: ' | ';
			}
			&:first-child {
				&::before {
					content: '';
				}
			}
			li {
				&:first-child {
					&::before {
						content: ' | ';
					}
				}
			}
		}
	}
}
HTML タグとフォーマットの調整

テーマユニットテストデータのサンプルを参考に、引用 (Blockquote) やテーブル、定義リストの他、codeタグ、preタグなどHTML要素タグのスタイリングを行いました。
Bootstrapのスタイルを適用したい箇所はtsumugi.scssを編集し、Underscoresのスタイルを適用したい箇所はstyle.scssを編集する形で、それぞれがバッティングしないよう調整しています。
これによって、WordPressの投稿画面でユーザーがHTMLタグを使用した際にも、それぞれ適切なスタイルが適用されることになります。

コメント欄とフォーム回りの調整

コメント部分の表示の調整を行いました。
コメントの一覧部分は、初期状態では番号付きリストになっているので、list-style: none;にして、フォントサイズなどを調整しました。

また、合わせてコメント入力欄の調整を行い、送信ボタンにはBootstrapの標準ボタンスタイルを当てることにしました。
これにはSassの@extend機能を使って、送信ボタンの要素そのものに.btnclassのスタイルを適用する形を取っています。

input[type="submit"],
.more-link {
  @extend .btn, .btn-primary;
}

また、合わせて検索ボックスやパスワード入力欄など、フォーム回りの調整を行い、「続きを読む」リンクのスタイリングも行いました。
「続きを読む」のスタイルは、先ほどの送信ボタンと同じく、Bootstrap標準ボタンを適用しています。

ここまでの作業で、シンプルなワンカラム風のレスポンシブ・レイアウトに調整することができました。

フッターのウィジェット部分も、ワンカラム向けにスタイリングしたことで、デバイスの幅に関わらず、コンパクトな見た目を実現しています。

スキンの装飾

スケルトンで構造が組み終わり、色味やアイコン、パーツなど装飾部分のスタイリングを行うフェーズ。
構造とスキンを明確に分けて構築することで、今後スキンを追加できるような設計も考慮に入れる予定です。

Webフォントの読み込み

サイトタイトルと、ウィジェットのタイトル部分にWebフォントを適用したかったので、Google Fontsを読み込ませることにしました。

function.phpに以下の記述を追加することで、Google Fontsを読み込ませることができます。

まず、以下の部分でtsumugi_fonts_urlという関数を定義しているのですが、テーマを多言語対応させる際に、各言語ファイル内にonと記述することで、Webフォントを有効化できるようにしてあります。(日本語環境では、タイトル部分に英語表記を用いた場合のみ、Webフォントが有効になります)

if ( ! function_exists( 'tsumugi_fonts_url' ) ) :
/**
 * Register Google fonts for tsumugi.
 *
 * Create your own tsumugi_fonts_url() function to override in a child theme.
 */
function tsumugi_fonts_url() {
	$fonts_url = '';
	$fonts     = array();
	$subsets   = 'latin,latin-ext';
	/* translators: If there are characters in your language that are not supported by Annie Use Your Telescope, translate this to 'off'. Do not translate into your own language. */
	if ( 'off' !== _x( 'on', 'Annie Use Your Telescope font: on or off', 'tsumugi' ) ) {
		$fonts[] = 'Annie Use Your Telescope';
	}
	/* translators: If there are characters in your language that are not supported by Source Sans Pro, translate this to 'off'. Do not translate into your own language. */
	if ( 'off' !== _x( 'on', 'Source Sans Pro font: on or off', 'tsumugi' ) ) {
		$fonts[] = 'Source Sans Pro:300';
	}
	if ( $fonts ) {
		$fonts_url = add_query_arg( array(
			'family' => urlencode( implode( '|', $fonts ) ),
			'subset' => urlencode( $subsets ),
		), 'https://fonts.googleapis.com/css' );
	}
	return $fonts_url;
}
endif;

次に、以下のように記述することで、設定したWebフォントがテーマ内に読み込まれます。

function tsumugi_scripts() {

…

    wp_enqueue_style( 'tsumugi-fonts', tsumugi_fonts_url(), array(), null );

…

}
add_action( 'wp_enqueue_scripts', 'tsumugi_scripts' );

最後に、CSS側でWebフォントを適用したい箇所に、以下のようにフォントファミリーを指定してください。

.site-title {
  font-family: 'Annie Use Your Telescope', cursive;
}

.widget-title {
    font-family: 'Source Sans Pro',sans-serif;
}
アイコンフォントの組み込み

テーマ内でアイコンフォントを使用したかったので、Font Awesomeを組み込むことにしました。

Font Awesomeは、CDN経由で直接フォントを読み込むこともできるのですが、公式テーマディレクトリのガイドラインでは、CDNでのファイルの読み込みは認められていません。そこで、Font Awesomeのサイトからzipファイルをダウンロードして、必要なファイルをテーマ内に直接設置する必要があります。

「Download」リンクから落としたファイルのうち、フォントの表示に必要な/fonts//css/フォルダのみを抜き出して、テーマディレクトリの直下の/font-awesome/フォルダ内に設置しました。その上で、functions.phpに以下のようにっ記述すれば、アイコンフォントの読み込みはOKです。

function tsumugi_scripts() {

…

    wp_enqueue_style( 'font-awesome', get_template_directory_uri() . '/font-awesome/css/font-awesome.min.css', array(), '4.6.3', 'all' );

…

}
add_action( 'wp_enqueue_scripts', 'tsumugi_scripts' );

Font Awesomeのアイコンフォントは、例えば各投稿の日付や投稿者の表示部分のアイコンに使用しています。

テンプレート/inc/template-tags.php内では、下記のように<i>タグでアイコンフォントを挿入しました。

	$posted_on = sprintf(
		esc_html_x( '%s', 'post date', 'tsumugi' ),
		'<i class="fa fa-calendar" aria-hidden="true"></i> <a href="' . esc_url( get_permalink() ) . '" rel="bookmark">' . $time_string . '</a>'
	);
	$byline = sprintf(
		esc_html_x( '%s', 'post author', 'tsumugi' ),
		'<i class="fa fa-user" aria-hidden="true"></i> <span class="author vcard"><a class="url fn n" href="' . esc_url( get_author_posts_url( get_the_author_meta( 'ID' ) ) ) . '">' . esc_html( get_the_author() ) . '</a></span>'
	);

各アイコンごとのタグのソース例は、Font Awesomeのアイコン一覧ページを参照してください。

テーマロゴの作成

サイトタイトルの部分に、ロゴを組み込みたかったので、テーマロゴを作成しました。
今回はSketchでこんな感じのロゴを作成し、PNG形式で書き出してあります。
(サイズはレスポンシブ向けに、少し大きめの480x480pxにしました)

テーマロゴの組み込み

このテーマは、ロゴ画像が入ることを前提にデザインしていますが、公式ディレクトリで配布するテーマに、個人や企業のブランディング目的のロゴを含めるのは相応しくありません(テーマレビューの際に、そのように指摘されました)。
そこで、WordPress 4.5から搭載された「カスタムロゴ」機能を使って、ユーザー自身が好きなロゴ画像を組み込めるような実装にしました。

カスタムロゴを有効にするには、functions.phpに以下のような記述を追加します。

	add_theme_support( 'custom-logo', array(
		'height'      => 190,
		'width'       => 190,
		'flex-height' => true,
		'flex-width'  => true,
	) );

次に、ロゴを挿入したい部分に、以下のタグを記述すると、カスタムロゴが表示されます。(カスタムロゴは、テーマカスタマイザーからユーザー自身が選んだ画像を設定できます)

<?php if ( function_exists( 'the_custom_logo' ) ) { the_custom_logo(); } ?>

カスタムロゴを実装した上での、ヘッダー部分のソースは以下のようになりました。

		<div class="site-branding">
			<?php
			if ( is_front_page() && is_home() ) : ?>
				<h1 class="site-title"><?php if ( function_exists( 'the_custom_logo' ) ) { the_custom_logo(); } ?><br class="hidden-md-up"><a href="<?php echo esc_url( home_url( '/' ) ); ?>" rel="home"><?php bloginfo( 'name' ); ?></a>
				</h1>
			<?php else : ?>
				<p class="site-title"><?php if ( function_exists( 'the_custom_logo' ) ) { the_custom_logo(); } ?><a href="<?php echo esc_url( home_url( '/' ) ); ?>" rel="home"><br class="hidden-md-up"><?php bloginfo( 'name' ); ?></a></p>
			<?php
			endif;
			$description = get_bloginfo( 'description', 'display' );
			if ( $description || is_customize_preview() ) : ?>
				<p class="site-description"><?php echo $description; /* WPCS: xss ok. */ ?></p>
			<?php
			endif; ?>

			<?php if ( get_header_image() ) : ?>
				<div class="custom-header">
					<img src="<?php header_image(); ?>" width="<?php echo esc_attr( get_custom_header()->width ); ?>" height="<?php echo esc_attr( get_custom_header()->height ); ?>" alt="">
				</div>
			<?php endif; // End header image check. ?>

		</div><!-- .site-branding -->

ロゴの直後に、以下の<br>タグを入れていますが、Bootstrapの汎用classでスマートフォン/タブレットの時だけ表示するようにしているので、これによってタイトル部分もモバイルデバイスで閲覧した時だけ1カラム表示になります。

<br class="hidden-md-up">

以上で、ヘッダー部分のデザイン処理は完了です。

リンクカラーとパーツカラーの設定

テーマ内の各種リンクカラーとパーツの色味を設定しました。

今回のテーマでは、サイトロゴとサイトタイトルに使用している『渋みのあるブルー』がメインカラーとなるので、ヘッダーのナビゲーションメニューやボタン類は同系色で、また本文中のリンクカラーは補色となる赤系統の色にすることにしました。
(どちらにも属さないウィジェット内のリンクや、投稿時間・投稿者などのリンクは、テキストと同じ黒系統の色で統一しています。)

尚、それらの配色パターンを検討する上で、日本の伝統色を集めた日本の伝統色 和色大辞典 - Traditional colors of Japanというサイトを参考にさせていただきました。

各パーツ毎の色名称と色コードは、それぞれ以下の通りです。

パーツ 色名称 色コード
サイトロゴ 浅縹(あさはなだ) #84b9cb
サイトタイトル 藍色(あいいろ) #165e83
メニューリンク
ウィジェットタイトル
続きを見るボタン
紺碧(こんぺき) #007bbb
テキストリンク 紅緋(べにひ) #e83929
見出しスタイルの作成

エントリー本文内で使用されるh1h6の見出しタグのスタイルを作成しました。

このテーマでは、エントリータイトルをh1にしているので、通常はh2から使用される想定ですが、ユーザーの使い方によっては様々なケースが考えられるので、念のためh1からきちんとスタイルを定義しています。

見出しの装飾についても、サイトタイトルやリンクカラーと同じく、青系のメインカラーを基調に配色を調整しました。

カスタムヘッダー対応

最後に、ヘッダー部分にユーザーが好きな画像を挿入できる「カスタムヘッダー」機能の実装を行いました。

この機能は、当初搭載しなくてもいいと思っていたのですが、公式ディレクトリ申請に必要となるテーマのスクリーンショットを作成していた際に、どうしても見栄えが物足りなく感じられたため、写真を掲載した場合のサンプルとして、ヘッダーに組み込むことにしました。

Underscoresは標準でカスタムヘッダーに対応しているので、導入するのは非常に簡単です。hrader.phpの任意の箇所に、以下のように記述するだけでOKです。

この場合、ifタグで条件分岐しているので、ユーザーがテーマカスタマイザーからヘッダー画像を登録した場合だけ、サイト上に表示される形になります。

			<?php if ( get_header_image() ) : ?>
				<div class="custom-header">
					<img src="<?php header_image(); ?>" width="<?php echo esc_attr( get_custom_header()->width ); ?>" height="<?php echo esc_attr( get_custom_header()->height ); ?>" alt="">
				</div>
			<?php endif; // End header image check. ?>

また、公式ディレクトリ申請用のスクリーンショットは、1200x900pxとなっており、かなり大きめなので、広いディスプレイサイズで見た場合の見栄えがかなり重要な要素になります。さらに、公式テーマディレクトリの検索画面で見ると、286x214pxのサムネイルで表示されるので、このサイズに縮小した場合の見え方も考慮する必要があります。

以上のことを踏まえてヘッダー画像のサイズを検討し、合わせてPCで閲覧した場合はサイトタイトルも大きく表示されるように、ブレークポイント毎のサイズを微調整しました。

以上で、スキンの装飾を含めて、テーマの制作が一通り完了しました。

ちなみに、今回作成したテーマのスクリーンショットを公式ディレクトリの検索ページ、詳細ページで見た場合のサムネイルの見え方は、それぞれ以下のようなイメージになります。

公式ディレクトリへの申請準備

テーマの制作をいったん終えて、公式ディレクトリへの申請準備をする段階のタスク。

翻訳ファイルの作成

Underscoresは英語向けに作られたスターターテーマなので、国内ユーザー向けにテーマ内の英語部分を日本語化するための翻訳ファイルを作成しました。

テーマを翻訳するには、まず翻訳部分のテキストを抽出する必要がありますが、Underscoresにはすでに翻訳用のテンプレートファイルが含まれているので(Translation Readyの状態)、このファイルを元に翻訳を行えばOKです。

翻訳ファイルの作成は、コマンドラインツール等でもできるそうですが、今回はPoeditというソフトを使って翻訳を行いました。

Poeditで翻訳するには、「ファイル」→「POTファイルを元に新しいカタログファイルを作成します」から、すでにテーマフォルダに入っているlanguages/tsumugi.potというファイルを開き、ja.poのファイル名で保存。後は、ウィンドウの『翻訳』という欄に対応する日本語を入力していくだけで実行できます。

Underscoresの日本語ファイルを作成

ところで、Underscoresは国内でも多数のユーザーに使用されていると思われますが、すでに日本語の翻訳ファイルなどは存在しないのでしょうか?

そう思って探してみると、naokomcさんや、gatespaceさんが作成された日本語ファイルがGitHubに公開されていました。

そこで、今回はこれらのファイルを参考に、まずUnderscoresの日本語ファイルを作成し、次に今回制作するテーマ用に、必要な箇所を書き換える流れで翻訳を行いました。

※2016年4月時点での最新の日本語ファイルを、こちらのリポジトリにアップしているので、よろしければお使いください。

テーマ用に日本語ファイルを編集

先ほど作成した翻訳ファイルja.poと、自動的に生成されるja.moの2つが入っていれば、WordPressは翻訳ファイルを認識し、翻訳部分が日本語で表示されます。ただし、このままだとテーマ名や作者名、URLなどがUnderscoresの初期状態のままの表記になってしまうので、これらは書き換えておいた方がいいでしょう。

そこで、tsumugi.potja.poをそれぞれテキストエディタで編集し、必要な箇所の書き換えを行いました。「Last-Translator」等の欄も、Poeditで変換した場合はソフトに設定した翻訳者名とメールアドレスが挿入されますが、必要があれば適切な表記に修正しておきます。

エディタ等で直接編集した場合は、そのままでは自動的に反映されないので、ja.poをPoeditで開き直してから、再度保存しましょう。

以上で、テーマの翻訳・日本語化の作業が完了しました。

パブリッシュの設定

制作段階では、テーマフォルダ内に様々な開発用のファイルが存在するため、公式ディレクトリへの申請に備えて必要なファイルだけを抽出してパッケージ化する仕組みを構築しました。
この仕組みは、今後の運用フローにて、テーマを更新する際にも使用する予定です。

公開用のファイル一式をパブリッシュするため、gulpfile.jsに以下のタスクを追加しました。

gulp.task('build', function() {
  return gulp.src(paths.dist, {read: false})
    .pipe(shell(['bash zip.sh']));
});

このタスクは、zip.shという外部シェルスクリプトを呼び出し、実行します。

#!/bin/bash

VERSION='1.0.0'

function build_tsumugi() {
  mkdir tsumugi
  cp -rpf bootstrap tsumugi/
  cp -rpf fonts tsumugi/
  cp -rpf inc tsumugi/
  cp -rpf js tsumugi/
  cp -rpf languages tsumugi/
  cp -rpf template-parts tsumugi/
  mkdir tsumugi/bower_components
  mkdir tsumugi/bower_components/bootstrap
  mkdir tsumugi/bower_components/tether
  cp -rpf bower_components/bootstrap/dist tsumugi/bower_components/bootstrap/
  cp -rpf bower_components/tether/dist tsumugi/bower_components/tether/
  cp *.php tsumugi/
  cp *.txt tsumugi/
  cp *.css tsumugi/
  cp bower.json tsumugi/
  cp screenshot.png tsumugi/
  cd release
  zip tsumugi.$VERSION.zip -r ../tsumugi -x "*.DS_Store"
  rm -rf ../tsumugi
  return
}
if [[ -f tsumugi.$VERSION.zip ]]
then
  rm -rf tsumugi.$VERSION.zip
fi
build_tsumugi

これによって、gulp buildというコマンドを実行すると、下記の一連の処理が実行されます。

  • テーマフォルダ内から必要なファイルやフォルダだけ取り出し、/tsumugi/フォルダへコピー
  • /tsumugi/フォルダ内のファイル一式を、バージョン番号を付けたtsumugi.1.0.0.zip等の名前でzipファイルに圧縮
  • /tsumugi/フォルダを削除

以上で、いつでも公開用のテーマファイル一式を作成することができるようになりました。
バージョン番号は、zip.sh内に変数として記述しているので、こちらを書き換えれば、別ファイル名で/release/下に公開用ファイルが保存されていく形になります。
コマンド一発でパブリッシュできるので、公開用ファイルの更新やバージョン管理が簡単に行えそうですね。

公開申請

公式テーマディレクトリのUpload Your Themeから、必要なファイルをzipにまとめてアップロードし、公式ディレクトリへの公開申請を行いました。
「パブリッシュの設定」で、すでにzipファイルの作成フローを確立しているので、そちらを選択してアップロードするだけでOKです。

初回のアップロード時に、自動的にテーマファイルのスキャンが実行され、問題のある箇所が見つかると、注意や警告が表示されます。
「WARNING」の項目があると、申請が完了できないので、ファイルの該当箇所を修正して、再度アップロードしましょう。
(初回アップロード時に実行される自動テストは、Theme Checkプラグインの結果とほぼ同じようなので、テスト環境で事前にテーマチェックを実施しておくとよいでしょう)

全ての必須項目がクリアされると、画面上に「Pass」と表示され、テーマファイルのアップロードが完了します。
申請完了後のテーマには、Make WordPressのサイトにチケットが発行され、以後そのページ上でレビューのやり取りを行う形になります。

レビュー対応

公式ディレクトリには、毎日のように新しいテーマが申請されているし、現在はレビュワーが不足気味ということもあり、テーマの申請からレビューの開始まで平均して5〜6ヶ月ほどかかります。しばらく気を長くして待ちましょう。

無事レビュワーが付いて、テーマレビューが開始されると、登録したメールアドレス宛てに通知が届きます。そこから、最初に発行されたチケットのページへ行くと、レビュワーからのコメントを確認することができます。

レビュワーからのコメントには、テーマをチェックした上で直すべき点が書かれていますが、大体こんな感じで「Required(必須事項)」「Recommended(推奨事項)」といった項目ごとに、修正点を箇条書きされていることが多いです。

最後には『You have 7 days to fix your theme.』と書かれていて、一週間以内という期限が設けられているのですが、焦らずに一つずつ対応していきましょう。

私の場合は、主に以下のようなポイントを指摘されました。

  • 非推奨タグの削除
  • テーマ内で使われていない関数の削除
  • ライセンスの表記(スクリーンショット内に使われている写真・素材等も含む)
  • CSSファイルは圧縮版だけでなく、オリジナルも含める
  • アイコンフォントはCDNで読み込まない
  • テーマに固有のロゴを含めない

テーマを修正したら、テーマのバージョン番号を変えてzipファイルを作成し(tsumugi.1.0.0.zipの次だとしたら、tsumugi.1.0.1.zipまたはtsumugi.1.1.0.zipなど)、再度Upload Your ThemeのページからアップロードすればOKです。この時、readme.txtstyle.css内のバージョン番号も変更するのを忘れないようにしましょう。

アップロードが完了すると、同じチケット内に修正版のテーマファイルが反映されるので、そこからレビューが継続されます。どこをどう直したのか等、英語できちんと返信しておくと良いでしょう。

テーマの掲載

レビューに対する修正対応は、何度か繰り返されることがありますが、最終的にレビュワーのチェックがOKになったら、チケットのステータスが「reviewing」から「approved」に変更されます。

この状態で、すでに承認は取れているとも言えるのですが、再度キーレビュワーと呼ばれる人の最終チェックを受けてから、ステータスが「live」に変わると、晴れて公式ディレクトリへ掲載という形になります。

私の場合、レビュワーの審査完了から約一ヶ月後に、そのまま公式ディレクトリに無事掲載となりましたが、キーレビュワーの審査で再度修正が入ることもあるそうです。

正式にテーマが承認されると、以下のようなURLが発行され、公式ディレクトリに公開されます。この時点で、WordPressの管理画面「外観」→「テーマ」→「新規追加」からも検索できるようになっているし、運がいい時は最初に出てくる『おすすめ』にピックアップされていることもあります。

tsumugi — 無料の WordPress テーマ

デモサイトの作成

ユーザーが実際のテーマの表示・動作を確認しやすくするために、デモサイトを制作しました。
デモサイトは、海外/国内の両方のユーザー向けに、日英2言語分を制作します。
デモサイトには、各言語のテーマユニットテストデータをインポートした状態で、WordPressの本番環境を構築しました。
(サイトの内容自体は、ローカルに構築した制作・デバッグ環境とほぼ同じものを再現しています)

URL

継続的インテグレーション(CI)の導入

公開後のテーマの運用を効率的に行うために、継続的インテグレーション(CI)を導入することにしました。
Travis CIを利用して、GitHubへのプッシュと同時に、テーマのテストと合わせて、リリース版のファイルをreleaseブランチへ自動ビルドするようにしました。
また、バージョンごとにGitHubのRelease機能を用いてタグを作成し、いつでも各バージョンの配布版ファイルを入手できるようにしています。

リポジトリの整理

このプロジェクトでは当初、simple-vccw-envという手法を用いて、VCCWの環境ごとGitHubリポジトリで管理していましたが、公式ディレクトリへの公開に伴って、テーマファイルのみの構成に変更しました。

公式ディレクトリのページから、GitHubリポジトリへリンクしているし、他のテーマ開発者の方からプルリクなどのリアクションを送ってもらいやすくするためです。

Gitリポジトリ内の階層構造を変更する場合、ドラッグ&ドロップ等で移動してしまうと、ファイルのログが追えなくなってしまうので、git mvコマンドを使って以下のようにコマンドを実行しました。

git mv www/wordpress/wp-content/themes/tsumugi/* ./ -k

以上で、GitHubリポジトリ内が、配布版のテーマファイルと同じく、テーマディレクトリ直下から始まる一般的なファイル構成になりました。

Travis CIの導入

Travis CIを利用するには、Travis CIのトップページから「Sign Up」または「Sign in with GitHub」をクリックして、GitHubアカウントで認証してください。

次に「My Repositories」の隣りにある「+」ボタン(Add New Repository)をクリックして、リポジトリ一覧のページへ進み、該当のリポジトリをONに設定してTravis CIと連携させます。(チェックマークが付いたら連携がONの状態)

以上で、Travis CIとの連携準備は完了です。GitHubのリポジトリ直下に.travis.ymlというファイルを設置することで、テストコードの実行などを行うことができるのですが、今回は合わせてreleaseブランチへの自動ビルドを実行したいので、まずはブランチの作成を行います。

releaseブランチの作成

masterブランチには、テーマファイル以外にも、テーマの開発に必要なSassファイルやgulpfile.js、またそれらに必要なパッケージ群を記述したpackage.jsonなど、制作用のファイルが多数含まれています。

そういったものを取り除き、常に配布版のテーマファイルと同一の状態を保ったブランチを作りたかったので、新たにreleaseブランチを作成することにしました。

このreleaseブランチには、Travis CIから自動的にファイルをプッシュすることを想定しているため、masterの履歴を引き継がない空のブランチを作成する必要があります。

そのような「空ブランチ」を作成するには、ローカルで以下のようにコマンドを実行すればOKです。

git checkout --orphan release

上記コマンドで作成したreleaseブランチは、masterの履歴を引き継いではいませんが、現時点での作用コピーの中身が全て新規ファイルとしてコミット対象に上がってきてしまいます。
そこで、下記コマンドを実行し、全てを削除して最初からやり直すことにしました。

git rm -rf .

ただし、何もファイルがない状態ではコミットできず、正式なブランチとして認識されないので、リモートへのプッシュもできません。
そこで、以下のように--allow-emptyオプションを付けて「空コミット」を行い、リモートへのプッシュすることにしました。

git commit --allow-empty -m "initial commit"

以上で、Travis CIとの連携に使用するreleaseブランチの作成が完了です。

自動ビルドの設定

リポジトリ直下に設置したTravis CIの設定ファイル.travis.ymlには、以下のように記述しました。

language: node_js

branches:
  only:
    - master

script:
    - ls -al style.css
    - ls -al bootstrap/tsumugi.css
    - ls -al bower_components/bootstrap/dist/css/bootstrap.min.css
    - ls -al bower_components/bootstrap/dist/js/bootstrap.min.js
    - ls -al bower_components/tether/dist/js/tether.min.js
    - ls -al js/navigation.js
    - ls -al js/skip-link-focus-fix.js

after_success: bash ./bin/deploy.sh

env:
  global:
  - GH_REF: github.com/littlebirdjp/tsumugi.git
  - secure: "RSFk7zAzoCJzkCWaJs3Qfcvflc0ncsUMn1AxrA4uDQ6V4Bmoq+qXvTKLJdYOd3DSSZ+5HKABVSmyZVpGzPAkJPLeRor446LebSxzu5D0pGoj/dwipq6KJECslgZcVFwHXtFoILV03q66bmNqHzqXTbkk5otKDopS8xvvG0VmXJ20o6P3+UT941d7PzW0J42rLcychldXh4h2uzpNu2zglOUJJ3begCVI6jg30+hBSEMsYCUDu11BrTv+NQN5WnAz1R2qnYAM075o9RIumphJnVpm7o2CAxQnvyfGp9h6teeT6hWZ/fBJoQfFEktawNuQiv8e8TdWIxpuCSwdmcRrasgg5disYaStmV1TtrAMYYFcBVvzoIIvcgWObsGTu/EhHo64yuH5XSIC99eupD/16yMjXYyGEpOmSOmfdtvGBa4YWPB1oalpOQ3n9F2UGrURHIT3Lp6R7oOVyjDrjVj40ON5/pRB2k14tweTttlBfw00sALqkf7f8ACkxOywRDgj6OsunQQYJHNLS4DKDSfdlbn8EqTZcvdTePxTfxBljR5fkjlrIXIytin5n+h6J1vdoy0S0D9oG8AOSpIInbY178U8LpoNXByaCqnw8keJVynRVYcIfW4uLo+gBs2abe3KRB0wQ/e7kg3UHGM777LyAS68Nl+UNdp3XjcaLCkFRPg="

masterブランチにプッシュされた際に、scripts:以下に書かれたテストコードが実行されますが、現在はテーマの表示に必要なCSSやJSファイルの存在確認だけを行なっています。(追って本格的なテストコードを導入する予定です)

次にafter_success:で指定されたスクリプトを実行し、ここでテーマの配布に必要なファイルのみ抜き出して、releaseブランチへのプッシュを行っているのですが、Travis CIからGitHubへプッシュするには、アクセストークンの設定が必要になります。

「Settings」→「Personal access tokens」→「Generate new token」へ進んで、Travis CI用のアクセストークンを作成してください。
『Select scopes』は、「repo」にチェックが入っていればOKです。

ここで発行されたアクセストークンを、Travis CIの環境変数GH_TOKENに割り当てて暗号化する必要があるので、下記のようにリポジトリ名とアクセストークンを入力し、コマンドを実行してください。

npm install travis-encrypt -g
travis-encrypt -r littlebirdjp/tsumugi GH_TOKEN=[ここにアクセストークンを入力]

この後、ターミナルに表示される文字列を、.travis.ymlsecure:から始まる項目内に記述すれば設定完了です。

続いて、ビルド用のスクリプトdeploy.shには、以下のように記述しました。
masterブランチ内のファイルのうち、不要なものを.gitignoreに記述して除外してから、releaseブランチへプッシュを行なっています。

#!/usr/bin/env bash

set -e

if [[ "false" != "$TRAVIS_PULL_REQUEST" ]]; then
	echo "Not deploying pull requests."
	exit
fi

if [[ "master" != "$TRAVIS_BRANCH" ]]; then
	echo "Not on the 'master' branch."
	exit
fi

rm -rf .git
rm -r .gitignore

echo ".csscomb.json
.editorconfig
.jscsrc
.jshintignore
.travis.yml
bower.json
Gemfile
Gemfile.lock
gulpfile.js
LICENSE
package.json
/bin/
/layouts/
/node_modules/
/release/
/sass/
/screenshots/
/symbols-for-sketch-master/
*.md" > .gitignore

git init
git config user.name "Travis CI"
git config user.email "youthkee@gmail.com"
git add .
git commit --quiet -m "Deploy from travis"
git clean -fdx
git rm -fr .gitignore
git commit --quiet -m "Deploy from travis"
git push --force --quiet "https://${GH_TOKEN}@${GH_REF}" master:release > /dev/null 2>&1

以上で、masterへプッシュすると、自動的に配布版の最新ファイルがreleaseブランチへ反映される、自動ビルドのワークフローが完成しました。

※テストコードやビルド用スクリプトの実行状況は、masterへのプッシュ直後にTravis CIのサイトへ行くとリアルタイムに確認することができるので、気になる場合は、随時チェックしてみましょう。

リリース版の作成

GitHubのRelease機能を使うと、各バージョンごとの配布ファイルを簡単に作成・管理することができます。
すでに、releaseブランチ内は、配布用のファイルしか含まないクリーンな状態に保ってあるので、このブランチを元にリリース版の管理を行いましょう。

GitHubのリポジトリのトップページから、「releases」をクリックしてReleaseページへ移動し、「Draft a new release」ボタンをクリックしてください。

次に、ターゲットとなるブランチを選択し、バージョン名(タグ)とタイトル、説明文を入力してから、「Publish release」をクリックすれば、リリースの完了です。
説明文には、前バージョンからの変更点を箇条書きで記入すると分かりやすいと思いますが、ここは公式ディレクトリへのアップデートの際にもreadme.txtに記入する項目なので、同じ内容を入れておけばいいでしょう。

リリースを作成すると、リポジトリのRelease画面から、各バージョンごとのテーマファイル一式をzipまたはtar.gz形式でダウンロードできるようになるので、テーマの配布やデバッグの際に非常に便利です。

一般ユーザーは公式ディレクトリからダウンロードするケースがほとんどだと思いますが、GitHubから利用される開発者向けには、こちらのRelease機能を用いて提供するのが良いのではないでしょうか?

公式サイトの作成

テーマの説明や使い方等を掲載する公式サイトを制作しました。
公式サイトは、GitHub Pagesを使って公開しているため、制作用のファイルも同じリポジトリのdocs配下にアップしてあります。
尚、公式サイト自体もBootstrapを使って構築しています。(現在、鋭意制作中)

URL

英語

http://littlebirdjp.github.io/tsumugi/

日本語

http://littlebirdjp.github.io/tsumugi/ja/

Clone this wiki locally
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.