OleinPressというWordPressテーマを公式リポジトリに申請して承認されるまでの流れ

OleinPress@wordpress.org

昨年くらいからかな?一昨年くらいからかな?Twitterでたまに「公式にテーマ申請したいな」というようなことをつぶやき始めてました。しかし、ずーっとやるやる詐欺を続けていたわけですが、今回やっと承認されて晴れて公式リポジトリに掲載されました!

今回は簡単なテーマ申請の流れと所管、あとどうやったら僕みたいなのが簡単にテーマ申請できたかという秘話(?)も少しお伝えできればな、と思います。

公式リポジトリへの申請から承認までの流れ

では、簡単に最初の申請から承認までの流れを追って説明してみようと思います。

2017年8月1日にテーマを申請するためにアップロード

メールの履歴を見てみると、最初に申請のためにアップロードをしたのは、2017年8月1日となっていました。ここから、長い間順番待ちをしておりました。

結果、承認されたのが10月14日なので、承認までに2ヶ月半かかったということになります。長い道のりでした。

アップロードして当分は開発をストップしていた

レビュー開始までまだまだ長い道のりということもあり、開発をほぼほぼストップしておりました。

というのも、最初にアップロードしたテーマの状態といったら、お世辞にも褒められたものではなく、ただただエラーが出ずに申請が可能なレベルというだけで、レスポンシブ対応も全然していないし、PCでの表示を最低限整えただけ(スクリーンキャプチャ用に)といった形でした。

9月中旬くらいから徐々に開発を再開

GitHubの履歴からみると、9月中旬くらいから徐々に開発を再開していたみたいです。

というのも、僕が申請を行なった履歴をチケットで見てもらうと分かると思うんですが、バージョン1.0.2で大幅にデザインが変更になっています。メニューの位置とか機能とかも、ほとんど全てコーディングし直しています。

あまり大した理由はないのですが、なぜか「気に食わん。作り直そう」と思ってしまい、ざっと作り直してしまいました。

10月2日にレビュー開始

とりあえず形を整えてレビューには備えていました。大した機能は全く付いていません。カスタマイザーのカスタムもしていません。まずは、レビューをクリアして掲載されることを目的としていたので、機能などは後ほどのアップデートで改善できれば良いと思っていたので、割り切ってました。

そして、10月2日、レビュアーがセットされてレビューが開始されました。

10月5日、最初のレビューが届く

3日後、最初のレビュー内容が届きました。

2つ目と3つ目の項目がいまいちよく理解できませんでした。なので、もう少し詳しく教えて欲しいと甘えてみました。

自分なりに至極丁寧にこねくり回して英文を書きました。正直、この時点で「めんどくせーな、こいつ。はい、closeな」とかされるんじゃないかとビビってるくらいには無慈悲な場所なんじゃないかと思ってました。

しかし、後から知ったんですが、担当してくれたレビュアーさんがテーマレビューのモデレーターの1人だったらしく、そのおかげもあったのか親切に返事は帰って来ました。

けれど、ん〜それ必要なん?って思う内容ではあったのですが、ここでゴネるほど度胸はありません。素直に従います。

後にミルコン先生にはこう言われましたが…

最終的に…

最終的にはレビューで引っかかったのが、独自実装していたパンくずリスト機能部分でして、どうも納得いかなかったんで機能全体をざっくり削除してしまって、レビュワーに返しました。

そして…

メールが届いてから少し後にチェックしたんですが、「すぐに反映されるよ」って書いてあったのでテーマのページを見に行ってみると…

「あった…!」

「あったぁぁぁーーー!!!!!」

WordPress.orgのアカウントにもちゃんと掲載されていました。(知らない間にTransration Contributorにもなってるけど、これはコアの翻訳のあれかな?

なんかバッジが増えて、ちょっと嬉しいぜ!

underscoresを使えば僕みたいなのがテーマ作者になれる

正直、自分のスキルには全然満足していなくて、お仕事でもWordPressを触らせてもらってるし、WordBench岐阜でも毎回登壇させてもらっているけど、ぜんぜん納得していない。

というのも、自分が想像しているものを形にできている感覚がまだないから納得できていないんだと思うのです。

まぁ、かろうじてコーディング部分ではある程度、頭に描いたようにコーディングできるようにはなってきたのが唯一の救いといったところ。

で、なんで僕レベルの人間でもテーマ作者になれたか、というとAutomattic社が開発しているunderscoresを使っているからなんです。

underscores(_s)をフル活用

今回申請したテーマは、ゼロからフルスクラッチで作らずに、underscores(_s)を利用して作りました。

機能部分に関しては、ほぼそのままです。

若干、テンプレート構造だけはget_template_part()で読み込まれているところが、コンテンツ部分にあるので、そこらの仕組みだけは理解しなくてはなりませんが、一度読み解いておくとすごく使い勝手が良いスターターテーマだと、個人的には思っています。

こちらをベースにして、構造部分 (簡単に言うとPHP部分)と表示部分(HTML/CSS/JavaScript)をカスタマイズしていきます。

underscoresをベースにしておけば、ほぼエラーは出ない

テーマをアップロードできるレベルにするために、欠かせない記述などがあるのですが、それらもunderscoresをベースにしておけば、かなり簡単にカバーすることができます。

Theme Checkプラグインなどを利用して、エラーを事前に消したりするのですが、underscoresから脱線した開発をしない限り、そもそも大したエラーは出ません。とても楽にテーマを作ることができますよ。

必要なファイルは全て揃っている

テーマを申請するにあたり必要なファイルは全て揃っています。

当然、テーマとして機能する状態なのですが、ライセンス情報を記述するLISENCEファイルや、readme.txtなどのファイルもあらかじめ内封されています。これらをベースに記述するだけですぐに準備完了になってしまうんです。楽チン。

テーマ作者になってみるメリット

んじゃ、公式テーマの作者になってみるメリットってなんだろう?って考えると、こんなポイントがあるのかなと思っています。

「今」の最適なコードの記述が学べる

技術は進化するものです。ですので、WordPressも数多くのバージョンアップを日常的に行われています。

それらバージョンアップが行われるということは、いずれ古い技術は薄れていくということでもあります。ですから、スピードはさておき、常に進化・成長しているのがWordPressなんですね。

そして、その中で使うものの1つがテーマです。プラグインも同じなんですが、その時代、要するに「今」必要な記述が求められます。

そういった部分を直に学べるのがテーマ制作なのかなと考えています。

我流のコードを正せる

上にも共通するかもしれませんが、未だにheader.phpにCSSを直接読み込んでいたりする制作者も少なくないんじゃないでしょうか。

それが悪とは言いませんが(クライアントワークでやってたら悪かもしれませんね)、WordPressの良さをできるだけ長い期間活用できるテーマを作るという観点で言えば、良いとは言えません。

その他にも、どうしても我流で書いてしまっているコードというのは多く存在します。それらを一定の基準を持って補正してくれるというのも、公式テーマを作ってみて得られるものだと思います。

なんとなくWordPressの全体像がわかってくる

これは制作技術の話だけではありません。WordPressのコミュニティの役割だったり、WordPressがなぜここまでシェアを伸ばして来たのか、といったことがなんとなく分かるようになってきます。

また、外部のライブラリを使用するためにライセンスを気にするようになったりします。WordPress公式テーマは100%GPLでないといけませんからね。

そういった、テーマだけではなく、その背景や周りも少しだけ気にして見ることができるようになる。そんな気がします。

次はプラグイン

テーマ作者にはとりあえず成れたので、次はプラグイン作者になってみようかなと思います。

といっても、技術が追いついていないので、めっちゃ簡単なプラグインでも良いので公開できるものを作って見たいと思います。


長々と書いてきましたが、テーマを作ってみて、色々と理解が深まることばかりでした。若干の英語力も必要になるとは思いますが、Google翻訳をはじめ、最近では素晴らしいツールもあるので、どんどん活用していけばなんとかなります。

また、どうしても詰まった時には、僕もそうですがインターネット上でテーマを作ったことのある人を探して質問してみたらいいんです。5人くらいに質問したら、1人くらいはちゃんと返事してくれるはずです!(みなさん忙しかったりしますしね)

少しでもテーマ制作に興味を持ってもらえるように、いろんな人に今後も伝えて行きながら、自分もスキルアップしていければと考えています。

事業サイトをWordPress公式リポジトリに掲載されているテーマを使ってリニューアルしてみました

OleinDesignのウェブサイトを子テーマで作ってみました

最近、お仕事でもWordPressに関わることがめっきり多くなってきました。そして、その中でもほとんどのお仕事はオリジナルテーマの制作となってきます。

実際にデザインを制作することもありますし、完成したデザインをいただいて実装だけ行う場合もあります。

そして、そうやって業務をこなしていく上で感じていたことは「オリジナルテーマだけがWordPressじゃないよな」ということ。いや、当然なんですよ。仕事だからオリジナルテーマを作ることが多いだけで、実際のユーザーさんの統計を取ってみると、既存テーマを使ったブログやウェブサイトの方が多いはずです。

であれば僕も実験的に公式リポジトリに掲載されているテーマを使って事業用ウェブサイトを作ってみようかな、と思いつきました。
続きを読む 事業サイトをWordPress公式リポジトリに掲載されているテーマを使ってリニューアルしてみました

[WordPress]テーマ制作を手軽にスタートできるスモールスターターテーマを作りました

WordPressのテーマを作ろうと、いざコーディングを始めても、書くのは毎回同じようなコードだったりしませんか?

レイアウトもヘッダーがあってコンテンツとサイドバー、下にフッターというオーソドックスな形だと書くコードも似てくることがほとんどです。

当然、デザインによって違ってくる部分も大きいと思いますが、同じ記述部分をベースに、案件によって違う必要な部分を加えたり削除したりする。

そうすることによって、ゼロから築き上げていく工数を削除して、スピード感をもって制作を進めることができます。

また、クライアントには実際に触ってもらえるレベルにまで早く持っていくことができますので、コンテンツの入力をスタートしてもらうことも場合によっては可能ですし、好きなように触っていただいてウェブサイト運営開始前にWordPressに親しんでもらう機会も生み出せるでしょう。

まさに自分のために作ったWordPressスモールスターターテーマではありますが、肌感覚の合う方にはぜひ活用していただければと思います。

ファイル群の紹介

まずは、テーマ内にあるファイルについて説明します。

上の画像の左上から順に補足を表にまとめてみました。

ファイル名 役割
404.php アクセスしたページが存在しない場合に表示します。
検索やカテゴリー、タグクラウドなどのウィジェットを表示して再訪問を促しています。
archive.php カテゴリーやタグでの記事一覧を表示します。category.phpやtag.phpなどはこちらをベースに作成します。
comments.php コメントフォームやコメント表示部分のテンプレートです。
footer.php フッター部分のテンプレートです。全ページ共通です。
複製して別のパターンを作りwp_footer( '***' );といった感じで読み込んでもOK
functions.php よく使う機能や記述をまとめてあります。(常に使わなくてもよく使う記述は、今後、コメントアウトにて増やしていく予定)
header.php ヘッダー部分のテンプレートです。全ページ共通です
index.php ブログトップページのテンプレートです。今後コーポレートサイトに対応するためにfront-page.phpを作成した際には管理画面での設定やファイル名の変更(そのままにしておくと初期でトップページになってしまうので)などが必要になると思います。
page.php 固定ページのテンプレートです。スラッグごとのテンプレートなどを作る場合にはベースにします。
prepros-6.config これはGitHubには上がっていないローカル専用のファイルなので無視してください。(コンパイルソフトのPreprosの設定ファイルになります)
readme.html、readme.md GitHubでの説明用のドキュメントなので基本無視してください
screenshotフォルダ GitHubの説明箇所で掲載しているスクリーンショットを格納しているフォルダです。削除して構いません。
scssフォルダ 詳しくは後述します
search.php サイト内検索の結果を表示するテンプレートです。
sidebar.php サイドバーのテンプレートです。全ページ共通です。
single.php 記事詳細を表示するテンプレートになります。カスタム投稿タイプの記事専用のテンプレートなどを作る際にベースにすることができます。
style.css CSSファイルです。scssフォルダ内のstyle.scssをコンパイルして書き出しています。

scssフォルダ内にはこのようなファイルが入っています。

ファイル名 役割
_settings.scss ページ内各箇所の幅やメディアクエリのブレイクポイントなどの変数を設定しています
style.scss ベースとなるCSSを書き出しSCSSファイルです
ownedフォルダ mixinや変数、各種リセット用CSSなど自由に選ぶことができるように格納しています。_myresets.scssには自身でよく使うリセット系の記述をまとめてあります。

ざっくりとテーマ内に含まれているファイルはこのようなものがあります。実際のソースはGitHubにてご覧ください。

当テーマ制作の際に気をつけていること

テーマを作り始めると、どんどん便利な機能をつけたくなってしまいます。例えば、

  • カスタマイザーで背景色や文字色を変える
  • 痒いところに手がとどくウィジェットエリアを数多く作る
  • Google Fontを切り替えられる

などなど、便利な機能というのは際限なく浮かんできてしまいます。

しかし、販売したり公式サイトに掲載したりするためのテーマであれば、そういう機能が喜ばれたりするのですが、当テーマを作った趣旨としては「クライアントワークでWordPressテーマを作る際のスタートダッシュを素早く切れるスモールスターターテーマ」ということを考えていましたので、あまりにも多機能にして使わないものを増やすことはしたくありませんでした。

また、クライアントワークでカスタマイザーを利用したカスタマイズに対応することも経験上さほどありませんでしたので、このケースではあまり重宝しないだろうと思い、最低限のカスタマイザー対応で良いかと考えています。(カスタム背景とかカスタムヘッダー程度)

あとは、何にせよテーマ制作をスピーディーにできるように考えています。このまま有効化してもテーマとして当然機能しますが、かなりシンプルな作りになっています。

そこにスタイルや機能、動きを案件によって必要なものだけ付け加えていく。もしくは削っていく。そういった形で制作をスムースに進められるように配慮しています。

デモサイトについて

実際にプレーンのOD-Baseを触っていただけるようデモサイトを用意しました。

http://demo.olein-design.com/od-base/

今後の開発について

今後の開発については、このような点を考えています。

  • よく利用する細かな機能や関数を事前にコメントアウトで用意
  • よくあるレイアウトに対応できるようにテンプレートを増やす?(たぶんやらない)
  • SCSSファイルをもっと読みやすくする(でもモジュールごとに別ファイルにはしない)

日々草を生やしながらGitHubにて開発を進めていこうと思います。ご意見等お待ちしています。

[WordPress]投稿や固定ページ、カスタム投稿タイプの使い分け方

WordPressはブログシステムを構築することをベースとして作られています。その上で、様々な機能やプラグインを利用してコーポレートサイトも構築することができる、ということです。ですので、あくまでも基本はブログシステムだと僕は考えています。(最近ではコーポレートサイトを作るが多くなってきましたが)

そして、WordPressにてページを作る上でベースとなるものとして「投稿」と「固定ページ」があります。

使い分け方としては、読んで字のごとくではあるのですが、ブログもしくはコーポレートサイトを構築するにあたってサイト構成を考えると思います。そして、「このページは投稿で作ろう」「このページは固定ページで実現しよう」などと構成を検討するかと思います。

この「ウェブサイトを構成する仕組み」はとても大切で重大なものでして、家づくりで例えるならば基礎部分の設計に値すると言っても過言ではありません。後から「やはり6畳部屋をここに追加」なんてことは簡単にできないのと似ていて、ページを追加する分には良いのですが、構成を後から変更することは設計をひっくり返してしまう可能性もあるので、しっかりと検討した上で制作を進めなくてはなりません。

今回は、これらを設計する上で「投稿」「固定ページ」はたまた「カスタム投稿タイプ」をどのように理解して使い分けて考えていけば良いのかを、僕の考えを元にまとめてみたいと思います。

投稿は時系列をともなくページに採用する

 WordPressをブログとして利用する場合、この「投稿」部分は「ブログ投稿」として利用されます。実際のブログの記事ページを記事ごとに生成するということですね。
 
コーポレートサイトとしてWordPressを利用する場合でも、企業ブログとしてこの「投稿」を利用することが多いです。

この「投稿」の特徴としては、時系列を持ったページを作る際に用いることをおすすめします。

時系列と言われてもピンとこないかもしれませんね。

例えば先ほども出てきた「ブログ記事」。このブログ記事は書けば書くほど、どんどん新しい記事を生み出します。そして、記事の投稿を繰り返していくと、昔書いた記事は古い、最近書いた記事は新しい日付が記載(されないものもありますが一般的に)されます。そして、時系列を持って管理されます。

コーポレートサイトで言うと、「お知らせ」ページなどは似たような要素を含んでいます。

GW営業のお知らせ、お盆休業のお知らせ、年末年始休業のお知らせなど、毎年知らせることになりますし、古いお知らせから新しいお知らせまで様々ですね。こういった時系列をもった情報を扱う場合には「投稿」がおすすめです。

固定ページは階層構造を持つページに採用する

WordPressにおいて固定ページは、主に「お問い合わせ」ページに使われたり、「企業概要」などの紹介に用いられたりすることが多いです。

これは先ほど説明した「投稿」とは大きく異なる性質を持つからです。

固定ページでは、階層構造を持つことができます。階層構造と言われても難しいので、図にしてみました。

このように、親ページがあり、その下に子ページがあり、兄弟ページもある場合もありますが、さらに孫ページを持たせることもできます。

例えば、コーポレートサイトを構築する際に、会社の商品やサービスを紹介したいと考えたとします。タイトルとしては「商品(サービス)紹介」というページを作ります。こちらが親ページになります。

そして、まずは商品やサービスをジャンルごとに分けて説明するページを作るとします。例えば、ジャンルA、ジャンルB、ジャンルCというような具合です。こちらは、先ほど作った「商品(サービス)紹介」ページを親とする子ページという位置づけで設定します。

そして、それらサービスの商品を詳しく説明するページを紹介・説明するページを作成します。ジャンルAの中の商品A、商品B、商品Cといった感じです。こちらが孫ページとなります。

このように、コンテンツを階層に分けて管理することができるという点が、固定ページの大きな特徴の1つと言えるでしょう。

他にも「投稿」「固定ページ」ともに特徴がありますので、まとめてみます。

投稿と固定ページの特徴まとめ

投稿の特徴 固定ページの特徴
時系列で表示される 階層構造を持つことができる
期間別のアーカイブを持たせられる 日付によるアーカイブがない
カテゴリーやタグによる分類ができない
(カスタマイズして使用できるようにすることは可能)
ページ属性によって、カスタムテンプレートを利用したり、順序をつけることができる
階層構造を持たない パーマリンクを設定するとスラッグでURLを管理することができる

ざっくりですが、このような特徴がそれぞれあります。上手に使い分けることによって、WordPressはとても便利なCSMにもなりますし、逆に使い方を間違えるととても使いにくくなってしまうので注意が必要です。

カスタム投稿はそれら以外のまとまったジャンルのページ群が必要な場合に採用する

WordPressには独自にカスタム投稿タイプというものを作ることができます。

例えば、コーポレートサイトなどで「お知らせ」を掲載したいが、「投稿」とは別に投稿タイプとして独立して作りたい。会社の商品を掲載するために独自の投稿タイプを設置したい。こういった場合に利用されることが多いです。

カスタム投稿タイプの特徴としては、

  • 階層構造を持たせることができる(「固定ページ」の特徴)
  • 複数のカスタム分類で分類できる(「投稿」の特徴)
  • 時系列構造を持たせることもできる(「投稿」の特徴)
  • ページ属性で順序をつけて表示させることもできる(「固定ページ」の特徴)
  • 非公開の投稿タイプをつくることもできる

という点が挙げられます。ほとんどの項目をみていただくとわかる通り、先ほどまで説明してきた「投稿」と「固定ページ」の特徴を持ったものがカスタム投稿タイプということになります。

ですので、「投稿に混ぜ込んで一緒に運用しようと思っていたけど…」というようなお知らせ機能だったり、「固定ページを増やして作っていた商品ページ」をカスタム投稿タイプで独立させてしまう、ということができるようになります。

正しい使い方をすれば、とても便利な機能です。

まとめ

簡単にWordPressの「投稿」「固定ページ」「カスタム投稿タイプ」について書いてみました。

ウェブサイトやブログを作るとき、もしくは制作を依頼するときに、これくらいの軽い知識を持っておくだけで、設計段階からも相手の言っていることが理解でき利用になると思いますし、とんでもない要望を出すこともなくなると思います。

「ほう、なるほどな」と少しでも気づきを生み出せる記事になれば幸いです。

[WordPress]カスタムメニュー機能の設定と設置と書き出されるソースコードを分かりやすく紹介します

WordPressテーマ制作の案件を多く受託することがあるんですが、残念ながら今までしっかりとWordPressに備え付けられているカスタムメニューという機能を活用することを前提に、設計・デザイン・コーディングされた案件に出会ったことがありませんでした。

WordPressを多く扱っている者としては普通と認識していることでも、周りがそうとは限りません。そして、せっかくユーザーにも便利に活用してもらえる機能なだけに、もっと中から外へ情報を発信していかないといけないのではないかと思いました。

今回はその、カスタムメニューの使い方についてまとめてみました。

カスタムメニューとは

カスタムメニューとは、管理画面から簡単に操作でき、任意の投稿や固定ページを任意の場所に表示することができるメニューのことを言います。

固定ページの一覧を表示する関数はすでにありますが、固定ページとカテゴリー、投稿などを混在させたり、順序を自由に決めることができません。カスタムメニューではそれらの不満を解消することができます。

メニューの作り方

まずは【管理画面】→【外観】→【メニュー】と進みます。

未だカスタムメニューを作成したことがない場合には、下のような表示になると思います。ここでは試しに[global]という名前のメニューを作成してみます。メニュー名を入力して【メニューを作成】を押します。

左側から任意のページを選んでみましょう。

チェックをして【メニューに追加】を押すと、

追加されましたね。カスタムメニューは「リンク先URL」と「ラベル」を設定することができます。管理しているWordPress内のページ以外の外部のサイトにリンクを張る場合に利用できます。

下のように、カスタムメニューに登録できる項目は、【投稿】【固定ページ】【カスタムリンク】【カテゴリー】の4項目となります。

メニューの位置については、詳しく後述します。

では、実際にテーマにカスタムメニューの位置を定義していきましょう。

カスタムメニューの位置をfunctions.phpに定義する

では、functions.phpファイルを開いて、カスタムメニューの位置を設定していきます。

順に説明していきます。

1行目のif文ですが、lab_setup()がない場合にlab_setup()を読み込む、という条件分岐になります。こうしておくことによって、子テーマでlab_setup()を定義した際に上書きすることができます。

2行目からlab_setup()関数を定義していきます。

カスタムメニューの位置を定義するには、register_nav_menus()を使います。今回は複数の位置を定義してみます。1つだけしか定義しない場合にも同じように1つだけ書けば大丈夫です。

参照:関数リファレンス/register nav menus

最後に、after_setup_themeのタイミングでlab_setup()が実行されるようにアクションフックを追加します。

先ほど後述すると書いてあったメニュー位置ですが、こちらが方法になります。次は実際に表示させてみましょう。

カスタムメニューを表示する

カスタムメニューを表示させるためには、wp_nav_menu()を利用し、パラメータで先ほど定義した位置やメニューを囲むタグ、メニューの表示階層数などを指定します。

参照:テンプレートタグ/wp nav menu

1行目:スタイリングしやすいように、div要素にglobal-naviクラスを付けてメニューを囲っています。
3行目:wp_nav_menu()でメニューを表示させます
4行目:theme_locationでどのテーマ位置のテーマを表示するかを指定します
5行目:メニュー自体を囲うタグをdiv要素に指定します
6行目:メニューを何階層表示するかを指定します。1と指定しているので親メニューだけを表示させるよう指定しています(0を指定すると全階層表示)

現状、実際の表示はこのようになります。

何もスタイリングしていないので、まっさらなHTML表示になっています。書き出されているHTMLはこのようになります。

Codexにもありますが、wp_nav_menu()で設定できるパラメータは以下のようになります。テンプレート的に使えますのでご利用ください。

こちらの書き出されるHTMLコードは以下になります。

こちらの書き出されるコードをちょっと理解しておくだけで、デザインが実現可能かどうか判断できると思います。(当然、デザイナーも少しはマークアップできるという前提ですが)

カスタムメニューをデザインする

では、このように書き出されたHTMLをどのようにデザインするのかを簡単に説明します。

先ほど掲載したHTMLソースコードをご覧いただくとわかるかと思うのですが、ほぼ全ての要素に自動的にIDやClassが設置されているので、CSSでのスタイリングにIDやClassに関して困ることはほぼないでしょう。

自動的に付与されるよく使うCSSクラス名

より一層、スタイリングをスマートに行う為にも、この書き出されるIDやClassの規則性を理解しておくことが必要となります。

下の表によく使うclass名と説明を掲載しておきますので参考にしてみてください。

class 説明
menu-item 全てのメニューに共通して付与されるクラス名
menu-item-object-[pbject] 全てのメニュー項目に付与されて、表示されているメニュー項目のタイプによって[object]部分が[page]:固定ページ、[post]:投稿、[custom]:カスタムメニュー、[category]:カテゴリーと変わります
current-menu-item 現在表示しているページのメニュー項目に付与される
current-menu-parent 現在表示しているページの親ページにあたるメニュー項目に付与される
current-menu-ancestor 現在表示しているページの祖先ページにあたる項目に付与される
menu-item-home トップページの項目に付与される

任意のCSSクラス名を追加する

管理画面から任意のメニュー項目に独自のCSSクラス名を付与することもできます。

まずは【管理画面】から【外観】→【メニュー】に進みます。すると、管理画面右上のあたりに【表示オプション】というタブが【ヘルプ】とならんで見えると思いますのでクリックします。

表示されたタブの中に【CSSクラス】という項目があるはずなので、そちらにチェックを入れます。

先ほど追加したメニューの項目(画面では「サンプルページ」という名前の固定ページ)の右側にある▲マークをクリックして、中身を展開してみましょう。

すると、先ほどまではなかった【CSSクラス(オプション)】という項目が表示されているはずです。こちらに任意のCSSクラス名を入力することによって、自由にメニュー項目にクラス名を追加することができます。

例として画像のように【sample-page】というクラス名を固定ページ:サンプルページに追加した際の、書き出されるHTMLソースコードを確認してみましょう。

ご覧の通り、4行目のli要素にclass名sample-pageが追加されていることが分かります。とても便利な機能ですので活用してみてください。

まとめ

長々とカスタムメニューについて説明してみましたが、どのような記述をすればどのようなソースコードを書き出されるのか、を理解しておけば、実際のどんなデザインが実現可能なのかを把握しておくことも可能です。

個人的な経験ですが、デザイン在りきの制作の場合、デザインを優先するがためにカスタムメニューという機能を捨てざるを得ない場合が過去にありました。

それは確かにクライアントの望んでいるデザインだったのでしょうが、それと同じように「クライアントが管理しやすいカスタムメニュー機能」を提案の一つに入れることも、クライアントにとって有意義となる可能性もあります。

私がディレクションして制作してきたWordPressを利用したウェブサイトに関しては、過去にもほぼすべてにカスタムメニュー機能を実装してきました。

それは、管理されるのが私たちのような専門家ではなく、クライアントさんであることが多いという点もあるかもしれません。

比較的豊富な予算をお持ちのクライアントさんの場合であれば、管理も請け負うこともできますので、メニュー構造の変更など技術があれば誰でもできます。

しかし、それほど豊富な予算を持たず、管理・運営はできる限り自分たちで行いたいというクライアントさんも多くみえます。そういった方々のことを考えた際に、メニュー項目の修正に毎度修正費用を負ってもらい専門家が修正する流れよりも、クライアントさん側で修正しトライ&エラーができる環境の方が双方においても有意義だと僕は考えています。

こういった便利な機能をしっかりと提案して活用しながら、クライアント自身が触りやす・扱いやすいウェブサイトを提供していく必要があるのではないかと日々思うわけです。

今回のカスタムメニュー機能もぜひご利用ください。