CMSの管理画面で変更したクラス名を資料化する

9月23日に書いた記事「CMSの管理画面でクラス名を変更できるようにしたことを後悔している」の続きです。

この記事を読んだプログラマの友人に
モジュールに設定したクラス名一覧を資料化すればいいのではないですか?
と聞かれました。

当初はこれについても書くつもりでしたが、結論から言うと諸々の問題で難しいのと、ますます記事が長くなるので追記しなかったのでした。

この件について改めて書いてみたいと思います。

モジュールID一覧を作ったことはある

一時期、管理画面で表示されている「モジュールID一覧」のHTMLをPDFに書き出し、資料として納品時にお渡ししていたことがありました。

a-blog cmsは、CMS内の設定(IDがnewsのカテゴリーのエントリーを5件呼び出す)に名前をつけて「モジュールID」として使い回すことができます。DrupalのViewsも同様だったと思います。
これもクラス名と同様、管理画面でしか参照できないものです。なので友人の指摘の通り、資料化しようと考えたのです。

ですが、これには以下のような問題がありました。

予算がつかない

これはウェブ制作全体の問題ですが、「サイトマップ」「マニュアル」以外の資料には、あまり価値を見いだされません。企画を重視していない案件では「カスタマージャーニーマップ」さえ予算がつくのが難しいでしょう。それ以前に私は受注制作がメインなので、予算に関われる案件はまずありません。

もしこちらから「モジュールID一覧もお送りしますね」と言っても、たぶん「いやー、いらないですよ!」と返事が来ます。
なので、できるだけシステム化して、こちらの見積内に組み込むことになります。よほど効率化しないとタダ働きになります。

やっぱり使われない

そうやって頑張って作成しても、サイトの改修自体がないことが多いです。私自身も完全納品だと、その後は声がかからないので使うことはありません。前回の記事のように、常時改修をお手伝いさせてもらっている案件もまれにありますが、全体の一割くらいです。
もしかすると、多くの納品先が、このような資料を必要としていたのかもしれません。しかし何も言われないのでわからないのです。あー、SNSでつながっている方、その後必要だったかこっそり教えて下さい…

サーバーと同期されない

オフラインの資料にしてしまうと、管理画面の内容を更新したときに資料も更新しなければなりません。資料と最新の状態が食い違うのはまずいです。 これは友人も指摘していました。むしろ資料作成を重視するプログラマさんやSIerさんは、こっちを気にすると思います。

管理画面の情報を常に閲覧できればいいのでは

そこで「管理画面に、モジュール関連の必要な情報だけを一覧できるテンプレートを作ればいいのでは?」と考えました。
テーマ内に含むようにできれば、毎回資料を作成する手数もなくなります。

a-blog cmsなら簡単にできるかもしれないと、管理画面にざっと書いてみたテンプレートがこれです。

<!-- BEGIN_MODULE Admin_Module_Index -->
<!-- BEGIN module:loop -->
mid: {mid}<br>
モジュールID: {identifier}<br>
<!-- BEGIN status#open -->
<span class="acms-admin-label acms-admin-label-info admin-status-label acms-admin-text-nowrap"><!--T-->有効<!--/T--></span><!-- END status#open --><!-- BEGIN status#close -->
<span class="acms-admin-label acms-admin-label-danger admin-status-label acms-admin-text-nowrap"><!--T-->無効<!--/T--></span><!-- END status#close -->
<br>
	<!-- BEGIN_MODULE\ Admin_Module_Edit ctx="bid/%{BID}/mid/\{mid\}" -->
	説明: \{description\}<br>
	追加クラス: \{module_exclass\}<br>
	追加属性: \{module_exattr\}<br>
	<!-- END_MODULE\ Admin_Module_Edit -->
<hr>
<!-- END module:loop -->
<!-- END_MODULE Admin_Module_Index -->

Admin_Module_Indexモジュールは、モジュールIDの最低限の情報を一覧表示するモジュールです。
ループ内でエスケープされているAdmin_Module_Editモジュールは、指定したモジュールIDの詳細情報を出力し、GET送信すれば編集可能にするモジュールです。
いずれも管理画面専用です。

  • mid
  • 識別名
  • 有効/無効
  • 説明文
  • 追加クラス(モジュールのカスタムフィールド)
  • 追加属性(モジュールのカスタムフィールド)

ここまで一画面で表示できればかなり便利になると思ったのですが…
残念ながらAdmin_Module_Editに属性値でIDを渡すことができないようで、説明文やクラスは表示できませんでした。何か間違えているのかもしれませんが。

となると、PHPを書いて、データベースへの直接のアクセスが必要になります。さすがにそこまでする必要があるかは微妙です。

リッチCMSに備えないといけない

かつては汎用CMSとは、本格的なエンタープライズCMSではなく、ごくごくシンプルなものでした。
ですが利用者が多いWordPressであっても、納品後にもコーディングに関与できる「リッチCMS」の採用が当たり前になっています。

制作側もこれまでのように作るだけで終わらせず、納品から半年後、一年後の改修で無駄な工数を食わないよう、対策を講じなければならなりません。
消化不良ですがこの話題はまたいつか。


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

#10年間を振り返る

突然「#10年間を振り返る」というハッシュタグが盛り上がっているのですが。

成功自慢か不幸自慢かネタ以外は流れていくだけの場で書く内容ではないでしょうよ。

という正論で殴りつつ、ブログに書きます。


10年前の写真。POKEN覚えてる?


10年間を振り返る

いろいろなコミュニティと関わりましたが、全体にはa-blog cmsとともに歩んだ10年間だった気がします。人生にも影響するとは思わなかったな…

2009年 34歳 CSS Nite LP6参加
2010年 35歳 a-blog cms Traning Campではじめて愛知県へ行く
2011年 36歳 CSS Nite in Sapporoの実行委員になる
2012年 37歳 Facebookページ本の執筆に参加
2013年 38歳 愛知県へ移住
2015年 40歳 baserCMSテーマコンテストでグランプリを受賞
2016年 41歳 北海道へ帰郷、a-blog cmsエバンジェリストになる
2018年 43歳 CSSフレームワーク「echo.css」を公開
2019年 44歳 ふたたび愛知県へ移住

私生活の10年間

ひとくちに「10年間」と言っても、公私では内容が異なります。上の10年間で、2014年と2017年が空いていますが、私生活ではいろいろあった年でした。

2014年はこれまで溜まってきた自分のダメな部分が出た年で、体調を崩したうえに、仕事でもコーディングでスランプに陥って、毎晩Ingressをしていた記憶しかありません。
いっぽう2017年は、私生活を良くしていこうと考え始めた年で、友人にヨガを習ったり、うさぎを飼いはじめたり、ゲーム用の自作PCを作ったりと、ほんわかした記憶が多いです。

今年は6月に、長年闘病をしていた母が他界しました。とても寂しいですが、これもまた節目でもあります。

私生活は、本人と近しい人以外にはどうでもいいことですし、面白くも興味深くもありません。ですが本人には、いいことも悪いことも、その後の表につながっていくのだろうと思います。

この先の課題

こうして10年間にやったことを書き出してみると、ここ数年は10年前の目標だった「a-blog cmsの案件増加」と「年収の安定」を達成できているものの、新しいスキルをあまり勉強できていません。
来月からまた愛知県民です。落ち着いたら次の10年間につながるようなことにまた挑戦していきたいです。


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

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

一周して親子テーマ構築からシングルテーマ構築に戻ってきた話

テーマの継承=親子テーマの概念があるa-blog cmsでは、複数のブログで構成されたウェブサイトを製作する場合、子ブログのテーマはルートブログの子テーマとします。

フォルダ構造をざっと書くと以下のとおりです。子ブログ「ニュース」の親ブログには「sample」というテーマが指定されています。
a-blog cmsは「テーマ名@親テーマ名」でテーマの親子関係ができますから、ニュース用のテーマは「news@sample」とすればよいわけです。

            sample ┬ テンプレート
                         ├ テンプレート
                         ├ テンプレート
                          ・・・

news@sample ┬ テンプレート
                         ├ テンプレート
                         ├ テンプレート
                          ・・・

ですが最近、他の人が製作した親子テーマを使わない「シングルテーマ構築」を見る機会があり、試してみたところ、開発者によっては、親子テーマよりもメリットが大きいかもしれないと感じました。

シングルテーマ構築とは

手法としては、特に凝ったものではなく、かなり昔からあったものです。私自身、Movable Typeで試したことがあります。

テンプレート内にインクルードを書き、ファイル名の一部に「ブログ名」もしくは「ブログID」を引数として渡します。
a-blog cmsで、詳細ページ用テンプレートの場合こうなります。

@include("/_entry/entry_blog_%{BID}.html")

コードネームを取得する変数「%{BCD}」を使って、より直感的なファイル名にしても良いと思いますが、a-blog cmsはルートブログではコードネームがない(NULL)ので「entry_blog_.html」というファイル名になってもよいのかは考える必要があります。

フォルダ構造は以下のようになります。画面ごとに「_top」「_index」「_entry」のフォルダがあり、現在訪問しているブログのIDをキーとして、表示するテンプレートを切り替えます。



シングルテーマ構築のメリット

やったことがない人から見ると複雑そうに感じますが、大規模なウェブサイトほどメリットがあります。

修正漏れが出にくい

親子テーマで構築したときに問題となるのが、子テーマの修正漏れです。親テーマと子テーマはテキストエディタや統合開発環境でファイル一覧を見た場合、かなり離れた場所に表示されます。このため、複数人で開発したり、数ヶ月語に改修をしたときに見落としが出やすくなります。

ファイルを探しやすい

テンプレートが画面ごとにひとつのフォルダに入っており、かつ一意のファイル名になっているので、ファイル名を検索して修正する作業がスムーズです。 親子テーマの場合、「index.html」を探そうとすると、テーマの総数分だけファイルがヒットすることになります。 カテゴリー単位でディレクトリを作っていると、ますます大変なことになります。

他の条件分岐を併用できる

親子テーマの場合、振り分けるのはあくまでブログ単位であって「ルートカテゴリーがitemsのエントリー」などのカテゴリー単位の振り分けは併用できません。
a-blog cmsの場合、「コンフィグセット」機能が追加されたので、カテゴリーごとにテーマを変えることもできるようにはなったのですが、テーマだけではなく同様にコンフィグに含まれている編集設定なども変わってしまうので、あまり現実的ではありません。

シングルテーマ構築のデメリット

説明が必要

CMS構築にそれほど詳しくない人には、事前説明が必要になります。最低でも、ブログIDとコンテンツの対照表がないと、ブログIDの調べ方がわからない人にはどうしてよいかわからないでしょう。

ルールはやはり子テーマ(a-blog cmsの場合)

スマートフォンではテンプレートを差し替える、などの「ルール」機能を利用する場合は、子テーマでなければなりません。

ELSE分岐が面倒(a-blog cmsの場合)

インクルード時にファイル名が一致していなければならないため、「ではない」を条件とした分岐が難しいです。

えっ?IFブロックを使って、こうすればよいのでは…と思うかもしれませんが、

<!-- BEGIN_IF [%{BID}/eq/2] -->
@include("/_entry/entry_blog_%{BID}.html")
<!-- ELSE -->
@include("/_entry/entry_blog_not2.html")
<!-- END_IF -->

a-blog cmsはIFブロックを使用した場合、条件に合致していないコードも処理されます。なので、このような書き方をすると、実質2ページ分の読み込みが発生して処理が遅くなります。

ELSE分岐はこのように、条件に合致しないテンプレートに、さらにインクルードを書くことになります。

_entry.html

@include("/_entry/entry_blog_%{BID}.html")

entry_blog_2.html 以外のブログIDのテンプレート

@include("/_entry/entry_not_blog_2.html")

なお、自作のグローバル変数を作成する知識があれば、 %{IS_NEWS} のような特殊な条件でtrueを返すグローバル変数を作ったり、特定のカスタムフィールドの値をテンプレートファイル名に使ったりできるので、大幅に有用性が上がります。
その場合はa-blog cmsのアップデートやサーバー移転の際に、オリジナルのグローバル変数を定義している /extension/acms/Hook.php を上書きしないよう、資料を書いて共有しておく必要があります。

まとめ:これでいいのか…?

メリットのところで書いたとおり、シングルテーマ構築は、私的には便利でした。途中、ディレクターさんが急ぎの文言変更でテーマを編集しましたが、フォルダ階層を登ったり降りたりしなくて良いので、作業しやすかったようです。

この構築手法は、a-blog cmsの公式テーマの管理画面のカスタムフィールドでは昔から使われています。ですが、公開側のテンプレートについては、ドキュメントでもこのような手法は解説していないので、オレオレカオステーマになってしまわないか、このまま採用し続けて良いものかという迷いがかなりあります。うぇびんたんいつも迷ってますね。

このへん、他の製作者さんの見解を知りたいので、SNSのコメントなどいただけると、とてもうれしいです。


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

a-blog cmsの一時的なテンプレート差し替えについて考える


地味なTIPSなのですが。
a-blog cmsのインクルードは、themesからのパスで記述すると、他のテーマのファイルを参照することができます。

冒頭の図のように、theme_a から theme_b にある file_b.html を参照する場合は以下のとおりです。

@include("/themes/theme_b/file_b.html")

これを利用すると、テーマの関係を無視することができます。

と書いた時点で、CMSの構築に慣れている人は悪い予感しかないと思います。実際、これの多用はおすすめできません。なんのために「テーマ」という概念があるのかわからなくなります。

ですが、これを活用できる状況もあります。

  • 期間限定で、特定のページを大幅に差し替えたい
  • サイト公開後の一定期間だけ、ティザーサイトを公開したい

などで、一時的に退避する本来のページも、別URLで閲覧できるようにしたい場合 です。

実際の手順とともに解説します。

※本来のページを移動する必要がない、かつ、一部のユーザーだけ見られれば良い場合は後述します

テーマ間インクルードの使用例

まず、ティザーサイト用の子テーマを作成し、本来のページと同じファイル名で差し替え後のページを作成します。
ここではわかりやすくするために親テーマ名を公式の site2019 、トップページを _top.html にします。
本来のページは top_02.html に退避させます。

teaser@site2019
  ├ _top.html
  └ top_02.html

一般的な親子テーマの継承を考えると、この構成にした時点で、親テーマの _top.html はティザーサイト用のテーマに上書きされ、参照できなくなります。
このため、退避した top_02.html には親テーマと同じコードを書かなければなりません。

もしもティザーサイトを公開中に top_02.html だけを編集して、それを忘れたままテーマをもとに戻すと、トップページに巻き戻りが発生してしまいます。

ここで、テーマを超えたインクルードを使います。

top_02.html のファイルを空にして、冒頭の、他のテーマを参照するインクルードを書きます。

@include("/themes/site2018/_top.html")

これで、ティザーサイト用のテーマ側で、親テーマのトップページを編集することはなくなるので、期間が終了したらテーマをもとに戻すだけで済み、安全な撤収ができます。

一時的な差し替えへの様々な対処

ウェブ制作に最適化されたa-blog cmsは、一時的なページ差し替えには、テーマ間インクルードの他に様々な対処法が用意されています。

参照テンプレートを変更するURLコンテキストを使う

退避前のページが非公開で良い場合、改修後のページをチェックしてほしい場合に使えます。URLの末尾に /tpl/(テンプレートファイル名) を追加すると、指定したテンプレートに同じデータを反映したページを見ることができます。

条件分岐を使う

ログインしているときだけ退避前のページを表示したいときに使えます。ただし、更新担当者は常時ログインしているので、この方法だと難色を示されるかもしれません。

ルールを使う

cookieや端末で動的にテーマを差し替えたい場合に使えます。期間も設定できるので自動終了できますが、管理画面から設定するので、a-blog cmsの構築に慣れていないとルールが適用されていることに気づきにくいです。しっかり情報共有をしなければなりません。

以上、いろいろな手段が考えられるのですが、ファイル1点くらいの入れ替えであれば、テーマ間インクルードが一番共有もしやすいように思います。ファイルを見たら、一行しか書いていないので、親テーマをそのまま読み込んでいることがすぐわかります。

いつもの手法や、開発元が推薦している手法にこだわらず、現在のプロジェクトの状況でもっとも良い方法を選定したいものです。


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