CMSの管理画面でクラス名を変更できるようにしたことを後悔している


コーディングとCMSのテーマ設計の話です。かなりCMS構築に慣れていないと理解しづらい内容になるので、順を追って説明します。

モジュール型のサイト設計

CMSで運用されるサイトは、トップページや下層ページのサイドバーで、投稿の新着やナビゲーションなどの「モジュール」を埋め込む前提で構築やコーディングをします。
ここでは「モジュール」としていますが、CMSによって名称は異なります。よく知られているのはWordPressの「ウィジェット」です。

コーディングにについては、以前書いた記事「CMSの構築を考慮したコーディングとかクラスの命名規則の話」で詳しく書いていますが、つまりはこの場合、それぞれのモジュール(=ウィジェット)はクラス名が付与されたdivで包括される前提となります。

例えば、WordPressの人気テーマ「Lightning」のトップページで、新着記事を表示している箇所は以下のようにマークアップされています。

<div class="widget widget_vkexunit_post_list" id="vkexunit_post_list-13">
(新着記事リスト)
</div>

自由モジュールであることを示す「widget」、テーマ専用パーツであることを示す「widget_vkexunit_post_list」のクラスに加え、一意のIDが付与されています。
これによって似たようなモジュールをページに複数配置しても、クラスかIDで区別してCSSスタイルを調整できます。

モジュールのクラス名を自由に決められるようにしてみる

DrupalのBlockやViewsでは、先述した包括divに付与するクラス名を変更できる機能があります。コーダー側のコーディングルールを活かせるので、とても魅力的な機能です。


ヘッダ、フッタのボタン、包括divの属性を変更できるようにした例


このクラス名変更機能を、a-blog cmsのモジュール設定に組み込んだのが、二年ほど前に公開したテーマ「echo_zero」でした。

モジュールの外観のカスタマイズ | はじめての方へ | 解説資料 | echo_zeroデモサイト

このテーマは当時はかなり満足していて、安定したウェブサイトをサクサク構築できるので、いくつかの案件にそのまま採用していました。
…が、二年が経って、一部の案件でこの機能が足を引っ張るようになってしまいました。

クラス名を見つけられない

完全納品ではなく、納品後も改修をお手伝いする案件だと、半年ほど経ってコンテンツが増えてきてから、二段階目の改修を依頼されることがあります。
モジュールの追加やデザイン変更などが発生しますから、コーディングも変わってきます。以前はイベント新着関係のモジュールが一個しかなかったのに、似たようなモジュール(関連イベント・現在位置から近い順)が増えたりします。

半年も経つと、自分の作ったテーマでも細かい構造は忘れています。このクラスは、どのモジュールで使用していたろうかと、テーマをクラス名の一部、例えば「module-event」などで検索してみても…見つかりません。
クラス名はCMS側で管理しているので、ローカル環境のエディタの全文検索ではヒットしないのです。
こうなると、a-blog cmsの管理画面に入って「モジュールID」の一覧から該当のモジュールを探すことになります。かなりの手間です。

CMSで何もかも管理すればいいわけでもない

一般に配布するテーマであれば、クラス名を変更できる機能は非常に便利です。
利用する人の大半は、モジュールごとに細かくCSSを調整したり、コーディングルールにこだわったりすることがないので、メリットの方が大きいでしょう。

ですが、自分がいちからテーマを作成していて、改修も多い場合は、修正すべき箇所をローカル検索できないというのは、毎回の時間のロスは大したことがないものの、けっこうストレスが貯まります。

そんなこんなで最近は、多くの人がやっているように、記事リストを呼び出す箇所を共通のインクルードファイルにして、クラス名や繰り返すコンポーネント名を変数で渡す構築になっています。
以下はa-blog cmsの場合です。a-blog cmsはJSON形式で変数を渡せます。これなら検索にもヒットします。

@include("/include/module/summary.html", {"class": "c-module-event-top", "mid": "summary_event_top", "loop": "event"})

ここまで書いて、どのくらいの人にこの文章が伝わっているのだろうか…と思いはじめていますが…

よく考えたら、モジュールの包括divを、制作者以外が変更できるようにする必要は基本的にないわけです。配布テーマでは便利でも、制作者が不便になるような機能は制作段階で外しておかなければと、改めて反省しています。


投稿者名 うぇびん 投稿日時 2019年09月23日 | Permalink

クイズメーカーでWordPressとMTとa-blog cmsのクイズを作った感想


今日からウェビングスタジオの2019年の営業開始です。宜しくお願いいたします。

今年もいろいろとCMSで変わったことをするつもりですが、正月休みにさっそくやっていました。
簡単にクイズを作れるサービス「クイズメーカー」で、WordPressとMovable Typeとa-blog cmsの横断知識がないと満点を取れないというクイズを作って公開しています。

すべての知識がなくても、どれかが詳しければ6割は正解できるようにしています。興味がある方は挑戦してみてください。

https://quiz-maker.site/quiz/play/JtfVPB20190102113456

裏付けを取る

軽い気持ちで作り始めたものの、10問揃うのには丸二日かかりました。問題が正しいかの裏付けを取らなくてはならなかったからです。

例えば4問目の「以下のうち、初期状態でダッシュボードに『最近の投稿』が表示されているCMSはどれか。」はすべてのCMSの最新バージョンのダッシュボードをチェックしなくてはいけませんでした。自社開発のa-blog cmsは、しれっと機能が増えていたりするので…

それを逆利用したひっかけ問題もあります。

思ったより正解率が低い

横断知識が必要なものの、すべて選択方式にするなど、個人的には割と簡単にしたつもりでした…が、正解率は現時点で40%くらいです。ううむ、問題文が分かりづらかったのだろうか。正直すまんかった。

WordPressの基本用語を問う1問目の回答率が、これを書いている時点で33%でした。
私は勉強会で、初心者の人には用語は無理に覚えなくていいと話しています。しかし実務で頻繁に使うようになり、テクニカルディレクションをする場合は話は別です。基本用語の正確な使用は、資料作成の際に、読み手=更新担当者の理解度に直結します。MTユーザーが多かったのかな?と思いつつも、この結果はちょっと残念です。

全く同じ機能は少ない

横断知識を問う問題を作りはじめた段階で、CMS間で機能の概要は同じでも、完全に同じとは限らないということに気付いてけっこう悩みました。

特にテンプレートタグは、細かいオプションが異なるとか、適用範囲が異なるとかの障害が多く、思ったより問題を作ることができませんでした。「これはどのCMSのタグ?」なんて簡単すぎますし…

10問目の問題文に「各CMSの記事中には、常に一点の画像もしくはアイキャッチが存在する前提とする。また、属性は無視する。」という冗長な前提が書いてあるのもそのためです。WordPressのthe_post_thumbnail関数は属性も出力するためです。
更に細かいことを言うと、10問目のMovable Typeは、このタグだけでは期待した動作にはなりません。前後を「記事中にアップロードされたアセットを呼び出す」ブロックタグで囲む必要があります。ここで間違えて「ファンクションタグ」と書こうとしてMovable Typeの公式ドキュメントを調べに行ったのは内緒です。

「クイズを作る」というブレインストーミング

このような高難度クイズになってしまいましたが、せっかくなのでもっとたくさんの人にやってみてほしいです。

クイズを作りながら「CMS間の横断知識を書いたサイト」を作るための構想を練っていました。これは数年前から考えていたことで、「○○をするには△△のCMSでどのようにすればよいか」というのをまとめたいのです。クイズのような軽いものは、ちょうどいいブレストになるなあと思いました。

何かをしたことをきっかけに、新しいアイディアが芋づる式に出てくるかもしれません。迷いも多いですが、私もいろいろ手を動かしてみようとおもいます。


投稿者名 うぇびん 投稿日時 2019年01月07日 | Permalink

WordPressのブロックエディタ「Gutenberg」に対して私たち制作者が考えなくてはならないこと

WordPress5.0がリリースされ、噂のブロックエディタ「Gutenberg」が正式実装されました。

現在私は、同じ構成で構築された、いくつかのWordPressサイトの運用のお仕事をしています。 そのサイトがGutenbergの導入でどのような影響を受けるかの検証と、それだけではなく、今後CMSを扱う立場としてGutenbergとどのように関わっていくかを、この週末に、ざっくりですが検討していました。

Gutenbergさんとどう付き合うか

まず、投稿タイプなどを追加していない、WordPress5.0の基本の状態でGutenbergをひととおり試しました。

私は、10年前からブロックエディタを搭載していたことで知られる、a-blog cmsを長年使用しています。また、スマートなブロックエディタを実装しているブログサービス「g.o.a.t」を一年ほど利用していました。

その経験を含めての感想としては、
「思ったより怖くない」
「これは『ビジュアルエディタの次世代としては』かなり良いのではないか」
です。

基本的に、ブログ記事などでは、HTMLの要素は見出し・本文・リンク・強調・各種サービスの埋め込みくらいしか使いません。それらについては軽快に書けますし、以前のビジュアルエディタとの操作の差も意外と少ないです。 驚いたのが「既存のビジュアルエディタ」がブロックのひとつとして用意されていることです。重くなりそうですが、どうしてもあのエディタでないと、というクライアントへの説得要素にもなるでしょう。



ウェビングスタジオとしては、新規案件の緩いコンテンツなど、利用しやすいところでは積極的に受け入れていきたいし、カスタマイズを学習していきたいと考えています。

長年WordPressを使い込んで、多数のプラグインやPHP拡張を活用してきた人ほど、Gutenbergは厄介な存在でしょう。 WordPressはオープンで自由なCMSです。一切使わない選択肢も用意されていますから、個々の制作者の自由でいいと思います。

使いたくない場合

一方、コンテンツ・マネージメント・システムとしてWordPressを使う場合、「投稿タイプによって適しているエディタが異なる」という問題が生じます。

例えば私の件の運用サイトの場合は、以下の3つの投稿タイプを持っています。

  • post・・・ブログ記事
  • page・・・がっつりマークアップした渾身のメインコンテンツ
  • works・・・カスタムフィールド職人らしいフィールドのみのコンテンツ

worksでは、「Advanced Custom Fields Pro」のリピートフィールドで、こんな感じの簡易なブロックエディタを作成しています。簡易な方が操作しやすく、更新の効率が良くなるということは往々にしてあります。



この場合、pageとworksでGutenbergを使うことはできません。

このように、第一に制作者が考えなければならないのは、現在運用しているサイトの各投稿タイプで、Gutenbergにしても問題ない箇所と、使ってはいけない箇所を明確にしておくことです。

では、特定の投稿タイプだけ無効にすることはできるのでしょうか。管理画面にもそういった項目は見当たりません。困っていたら、WordPressをはじめとするいろいろなCMSに詳しい安部さんがTwitterで教えてくれました。

これです。ドンピシャです。 高橋文樹さんが、Gutenbergがベータ版の頃から各種回避策を書いてくださっていたようです。

Before Gutenberg アーカイブ - Capital P

pageとworksでブロックエディタを無効にすることで、これまでのWordPressと変わりない環境にすることができました。

function WS_remove_block_editor( $user_block_editor, $post ) {
    if (
        ( $post->post_type === 'page' )
        ||( $post->post_type === 'works' )
    ) {
        $use_block_editor = false;
    } else {
        $use_block_editor = true;
    }
    return $use_block_editor;
}
add_filter( 'use_block_editor_for_post', 'WS_remove_block_editor', 10, 2 );

プラグインとの衝突問題

次に考えなければならないのは、プラグインです。

一通りコンテンツを確認したところで、カスタムフィールドを管理している「Advanced Custom Fields PRO」の編集画面に入ったら、ページが真っ白になりました。 フォームプラグイン「MW WP Form」も編集画面だけ真っ白になっています。

プラグインは問題がないと思っていただけに慌てましたが、これについても高橋文樹さんがすでに原因を書いていました。 “エディターのない投稿タイプは動かない” そうです。

Before Gutenberg - カスタムフィールド職人の命運やいかに? - Capital P

つまりプラグインの投稿タイプでも無効にしなければならないわけで、最終的に以下のようなコードになりました。

function WS_remove_block_editor( $user_block_editor, $post ) {
    if (
        ( $post->post_type === 'acf-field-group' )
        ||( $post->post_type === 'mw-wp-form' )
        ||( $post->post_type === 'page' )
        ||( $post->post_type === 'works' )
    ) {
        $use_block_editor = false;
    } else {
        $use_block_editor = true;
    }
    return $use_block_editor;
}
add_filter( 'use_block_editor_for_post', 'WS_remove_block_editor', 10, 2 );

あまりスマートじゃなくなってきました…postだけ許可する、ホワイトリスト方式にした方がいいのかも。

この不具合については、頻繁に更新されているプラグインであれば早い段階で解決されると期待していますが、しばらく混乱は続くのでしょう。 これを機に、プラグイン制作者に問い合わせる前に、まず検索する習慣を身に付けたいものです。

既出かもしれませんがQiitaに寄稿しました。

WordPress5.0でプラグインの新規追加画面・編集画面が真っ白になった場合の対処 - Qiita

発展途上?なUI

ざっと使ってまず気になったのが、「ブロックを追加・挿入するボタン」の表示がわかりにくいことです。

最後に追加するならEnterキーを押せばボタンが出るのですが、挿入の場合は、前のブロックにマウスを置くと出る枠線の「上の線」にカーソルを置かないとボタンが出てこないのです。これがかなりシビアな操作になっています。 それ以前に、感覚的には一般に「下に追加する」と感じるので、一つ前のブロックの下線にボタンが出るべきじゃないですかね…



ボタンブロックについても、色の選択があるのですが、よりにもよって背景色だけでなく文字色まで自由に選択できるUIになっています。

サイトを明るくしようとした更新担当者さんが、ボタンの色をピンクとかライムにする未来が見えます。

これがインラインスタイルで入るのか、クラスで入るのかまだ確認できていないですが、とにかく色は個別に選ばせたくないですし、外観についても丸と四角、塗りつぶしとボーダーはそれぞれどのような役割で使うのか決めておかないと、わけのわからないことになります。


また、WCAN 2018/10でたにぐちさんも指摘されていましたが、パーマリンク設定の場所もわかりにくいです。WCANに参加していなければ見つけられませんでした。更新担当者にパーマリンクをいじらせてはいけない、という禁止系インターフェース…と考えられなくもないですが。

たにぐちさんがさらに指摘されていた「なぜかテキストブロックの文字の寄せ方向だけ、クラスではなくインラインスタイルになっている」件は、私はあまり気にしていません。文字色などとは異なり、文字の寄せ方向はテーマやCSSが変わっても、同じであることが多いからです。しかし、UIのブレであることは確かですし、インラインスタイルは優先度が高いので、上書きしようとするとimportantまみれになる問題があるのですが…

少なくともこれまでと相当感覚が違うので、リモートで運用をしている場合は、更新担当者にどのように操作説明をするか考える必要があります。 a-blog cmsユーザーの多くがやっていたことですが、往訪できない場合はブロック一種類ずつに対して、操作している動画を撮って見ていただくのが確実と思います。

特定のブロックを使わない自由はあるのか

ボタンのところでも触れましたが、Gutenbergの「機能が多すぎる」ことも私の中で課題になっています。 多数のブロックがありますが、すべて対応していられないとか、コンテンツの性格上、使ってほしくないケースもあります。

私がa-blog cmsを気に入っているのは、コンテンツ(ブログ)ごとに、使用できるブロック(ユニット)を管理者が指定できることです。 もう少し情報を調べれば既に出ているのかもしれませんが、特定のブロックを使わない自由を公式に設けてほしいものです。

Gutenbergさんは悪くない、悪くないんだ

繰り返しますが、私はGutenbergが気に入っていて積極的に使いたいです。

ただ、日頃「すべての人が自由に気軽に使えるCMS」を謳っていながら、「ユーザーが、GUIを通して機能を選択(無効ではない。選択)できない状態でリリースした」強引さに若干呆れています。

今後各国のWordPressコミュニティは、一定のウェブ制作の知識を持たない人(いわゆる個人ブロガーなど)へのサポートを切り捨てるか、これまでのようにGUIで管理できるプラグインの開発やブログ記事などの情報を充実させるかの、大きな選択を迫られるのでしょう。

個人へのサポートを既にやめている私としては、前者が幸せじゃね…?と思ってしまいつつ、制作会社・企画会社との協業媒体としてのWordPressに、Gutenbergをどう活用していけるか、前向きに考えていきたいと思います。


投稿者名 うぇびん(管) 投稿日時 2018年12月09日 | Permalink

CMSでの「事例コンテンツ」の5つの構築パターン


先月の「WCAN 2018/10」で、講師の谷口さんが、WordPress 5.0のGutenbergに対する懸念と同時に、小規模のコーポレートサイトはこれまでのWordPress一択ではなく、ASP型のシンプルなCMSへ移行していく選択肢もあるというお話をされていました。

コーポレートサイトの軽量化が進む中でも、CMSで構築すべきコンテンツはいくつかあります。そのひとつが「ユーザー事例」「導入事例」などの、事例コンテンツです。

事例コンテンツは、クライアントの業種、業態などで適したパターンが異なるので構築の最適解がありません。だいたいはすでに決まっているワイヤーに添って構築することが多いですが、私が中間の制作会社さんに「このパターンはこういうリスクがありますが大丈夫ですか」と提案したり、逆に意見を求められることもあります。

だいたい、5パターンに分けられると思うので、今後のために特徴と構築手法をまとめてみます。

ワイヤーがかなり縦に長いので、少し読みづらいですがご容赦ください。画像はクリックで拡大できます。

リッチテキスト型


冒頭にお客様の画像と名前が入り、その後はリッチテキストの自由文となります。
最も軽量なパターンで、特別なフィールドもお客様名くらいですから、JimdoなどのASP型も含め、どのCMSでも実装可能です。

このパターンの欠点は、データの再利用性が低いこと、リッチテキストであるためウェブ担当者のセンスに左右されることです。固定ページとほぼ同じですね。


データベース型


すべての項目をカスタムフィールドでがっちり構築し、事例の情報を細かいデータとして開示します。

大手企業さんで数回経験しました。すべての情報の再利用性を考えていることや、大きな社内で投稿ルールを統一するのが難しいからではないかと思います。

上記の通りデータの再利用性が高い、つまりAPI連携、リニューアルにめっぽう強いことが長所として挙げられます。一方で例外が許されなかったり、この事例だけ思い切り推したい、ということができないのが欠点です。このため、中間のテキストをリッチテキストの自由文にして、HTMLを書けるようにしておくという「逃げ」を考えたりします。

工数も多くなりますし、CMS本体への負荷も高めです。そういう意味でも大企業向けなように思います。


ギャラリー型


画像とキャプションがグループになった「繰り返しフィールド」を作り、カルーセルとして表示します。繰り返しフィールドについてはまとめで後述します。

jQueryが普及した頃から現在まで人気があり、コンパクトで、クライアントのOKも出やすそうなパターンですが、私はこのパターンにあまり良さを感じません。

このパターンは、最初に画像が集中しているため、画像と文章を対比して見ることができません。文中に「キッチンのタイルのあしらいは…」と書かれていて気になっても、ページの最初まで戻って、カルーセルをめくらなければならないのです。

また、スマートフォンの普及で画面が狭くなり、かつ訪問者の滞在時間が少なくなったため、2枚目以降を見てもらいにくいです。縦長の素材が多いとますます見づらくなってしまうのも難点です。文章は少ないけど良い写真がたくさんある、というなら採用しても良いかと思います。


リピートフィールド型


前項のギャラリー型の変形です。画像、キャプション、見出し、本文がセットになった繰り返しフィールドを重ねてページを作成します。見出しやキャプションは必ずしも必要ありません。

縦長の画像にも対応できたり、画像と文章を対比できるなど、ユーザビリティに利点があります。更新担当者にも説明しやすいパターンですが、同じパーツの繰り返しなので、そうとう文章に力を入れなければ単調になってしまいます。 また、途中に任意のコンテンツを割り込ませることができません。

画像に力が入っているならギャラリー型、文章に力が入っているならリピートフィールド型がいいのかなと考えています。


ユニット型


本文中のすべてのパーツを「ユニット」として自由に並べていくパターンです。

このブログへ何度か来られた方はすでにご存知かと思いますが、a-blog cmsが最も得意としているパターンです。concrete5も実質このパターンになります。WordPressのGutenbergやMovable Typeのブロックエディタも…近い、とは言えます。

例外対応ができる、段組ができる、事例専用のユニットを追加できるなど、なんでもありですが、a-blog cmsのエバンジェリストとして敢えて言うと「データの再利用性が低い」「手厚い導入説明が必須」という問題があります。このため、急ぎ案件やまとめてインポートをしたい場合には向きません。

また、これはリッチテキストエディタと同質の問題でもありますが、投稿ルールを決めておかないと、各ページがカオス化しがちです。


まとめ


以上、事例コンテンツのパターンをまとめてみました。いつものように突っ込みを待つことにします。

繰り返しフィールドは、「リピートフィールド」「フィールドグループ」などと呼ばれ、a-blog cmsはコアでこの機能を持っています。WordPressでは「Advanced Custom Fields」プラグインのPROライセンス、Movable Typeでは「FreeLayoutCustomField」で可能です。

個人的にはデータベース型はけっこう好きだったりしますが、サイトのレイアウトがデータに大きく縛られてしまうため、やはり繰り返しフィールドと単体フィールドの併用が良いのかなと思います。

すべてのパターンに言えることですが、事例を「インタビュー」としていた場合は「インタビューに応じてくれる寛容なお客様が、今後どのくらいいるのか」について検討しなければなりません(私はこれを「希望的観測問題」と呼んでいます)。なので、インタビューと通常事例でカテゴリー分けをして、通常事例はギャラリー型などにすることが考えられます。

なんにせよ、なぜ事例コンテンツを作りたいのか、事例を通して訪問者(将来の顧客、もしくは掲載された顧客)に対してどのようなユーザー体験を与えたいのか、この二点を明確にしてから進めたいものです。


投稿者名 うぇびん(管) 投稿日時 2018年11月10日 | Permalink

CMSの構築を考慮したコーディングとかクラスの命名規則の話


先日、CSSフレームワークについて記事を書いてから、今後のコーディング設計について具体的に考えています。

【Webdesign】Atomic Designの思想で、文系でもわかるCSSフレームワークを作りたい | ウェビンブログ

というより、再利用性のある業務用テーマの制作をいくつか依頼されており、いずれにしても着手しなければならないのです。

私の主業務が、CMS(それも特定のブランドによらない)を組み込んだサイトの制作であることを前提に、自分はどう設計していったらよいか、考えていることを書いておきます。


投稿者名 うぇびん 投稿日時 2017年07月08日 | Permalink