サイトをブロックエディタ化した話【Kansai WordPress Meetup@KyotoのLTの補足】

先日のWordPress Meetup KyotoでLT枠でサイトをブロックエディター化した話をしたので、少し詳細をこちらにまとめたいと思います。

その時のスライドはこちら

スタイルの設定

編集画面の右サイドに出てくる、「スタイル」という設定項目をカスタマイズしました。

画像ブロックや引用ブロックなど一部のブロックにはデフォルトで入っているのですが、普通は「高度な設定」のところにクラス名を手動で入れないといけないところを、目で見て選択できるようになるというものです。
あらかじめ設定されたクラスがつくだけなので、やっていることは高度な設定と同じですが、コーディング苦手な人にも優しいつくりになります。

今回やったのはソースコードブロックに対してスタイルを設定しました。

prism.jsというシンタックスハイライターを使って、記事に埋め込んだソースコードをハイライトできるようにクラス名をつけるようにしています。
prism.jsでは「language-{言語名}」というクラスをpreタグにつけると、その中のソースコードをハイライトしてくれるという機能があるので、それにそってクラスがつくようになっています。

エディター用のJSに下記のように書いて、functions.phpで読み込むだけです。

//コードシンタックスブロック
wp.blocks.registerBlockStyle( 'core/code', {
	name: 'language-html',
	label: 'HTMLシンタックス',
	isDefault: false,
} );
wp.blocks.registerBlockStyle( 'core/code', {
	name: 'language-css',
	label: 'CSSシンタックス',
	isDefault: false,
} );
wp.blocks.registerBlockStyle( 'core/code', {
	name: 'language-js',
	label: 'JSシンタックス',
	isDefault: false,
} );
wp.blocks.registerBlockStyle( 'core/code', {
	name: 'language-php',
	label: 'phpシンタックス',
	isDefault: false,
} );

こういった技術系の話をする記事ではソースコードを入れることがよくあるので、用意しておくと記事を書くスピードがだいぶ上がっていい感じです。

固定ページもブロックエディターでつくる

もともと静的サイトからWordPress化したこともあって、固定ページは静的なHTMLがほとんどの状態で書いていました。

元々のソースコード(一部抜粋)

<div class="about__block about__block-profile">
  <h2 class="about__ttl">Profile</h2>
  <div class="profile__img"><img src="<?php echo get_template_directory_uri(); ?>/images/img_mine.jpg" alt=""></div>
  <dl class="profile__content profileList">
    <dt>Name</dt>
    <dd>西村 依泰</dd>
    <dt>Birth/Age</dt>
    <dd>1988.04.01/30歳</dd>
    <dt>Live</dt>
    <dd>大阪府</dd>
    <dt>Work</dt>
    <dd>元小学校教諭(〜2015)<br>マークアップ・CSSコーディング(2016〜)<br>ディレクション(2018〜)</dd>
    <dt>hobby</dt>
    <dd>楽器(ピアノ・ギター)、推理小説、TVゲーム</dd>
    <dt>Like</dt>
    <dd>コーヒー、甘味</dd>
    <dt>Community</dt>
    <dd>Word Camp Kansai 2016 実行委員<br>Word Camp Kyoto 2017 実行委員<br>Word Camp Osaka 2018 実行委員</dd>
  </dl>
</div>

<div class="about__block about__block-skill">
  <h2 class="about__ttl">Skill</h2>
  <div class="skill__content skill__content-tools">
    <h3>Tools</h3>
    <ul>
      <li>Photoshop</li>
      <li>Illustrator</li>
      <li>Adobe XD</li>
      <li>Dreamweaver</li>
      <li>Atom</li>
      <li>Google Analytics</li>
      <li>Github</li>
    </ul>
  </div>
  <div class="skill__content skill__content-language">
    <h3>Language</h3>
    <ul>
      <li>HTML</li>
      <li>CSS</li>
      <li>SCSS</li>
      <li>Javascript</li>
      <li>jQuery</li>
      <li>Vue.js</li>
      <li>PHP</li>
      <li>WordPress</li>
    </ul>
  </div>
</div>

これをブロックエディターに置き換えてみました。

基本はデフォルトのブロックをつかって、「高度な設定」にクラス名を設定することでレイアウトを作っていきました 。

ただ、上記コードにもあるように、dlタグを使っているところがあったので、そこは勉強もかねて、ネット上の情報の参考に自分で作ってみることにしました。

コードを入れると長くなるので省略しますが、下記のサイトを参考に進めました。

Gutenbergブロック開発

カスタムブロックは割となんでも作れる感じですが、学習コストが高めなので、CSSを用意しておいて高度な設定でクラス名をつけることで対応する方がやりやすそうだと思いました。
クライアントワークでは前述のスタイルをカスタマイズするか、再利用ブロックを活用することで扱いやすくなるかと思います。

フロントとエディターの見た目を合わせる

フロント(サイト側)の見た目とエディター(編集画面)の見た目があっている方が編集時に完成系がわかりやすくていいということがGutenbergハンドブックに書いてある(意訳)ので、それもやってみようと思います。

こんな風に。

フロント
エディター

やることとしては、エディター用のCSSをつくって、functions.phpで読み込むだけなのですが、厄介だったのはエディター側で生成されるhtmlが階層が深くてややこしかったということです。

グループブロックなどを使うとdivが二重三重になる上に、独自のクラスがつくので、単純にフロント用のCSSを持ってくるだけではうまくレイアウトが整えられないということがありました。

結局、枠やリストなどのスタイルをSCSSでmixinにして、それをフロント用とエディター用でそれぞれ読み込むようにしました。
それでも割と複雑なファイルができてしまったので、その辺りをうまく設計してSCSSファイルをもう少し簡潔にできないか、今後考えていきたいです。

まとめ

コアのブロックとCSSの設定だけでもそれなりにページを作ることはできたと思います。
とりあえず触ってみようと思う人は、まずはコアのブロックでいろいろ試してみるのがいいかなと思います。

これまでカスタムフィールドでやってたことを置き換えられないかと試行錯誤していますが、なかなかそこまでやるのは骨が折れるなぁと感じています。
今後の課題ということで。

トップへ戻る