表示部分がないヘッドレスCMS「microCMS」でサイトを作ってみた

2019-09-30追記
デモサイトの公開を終了しました。
microCMSで「画像のリサイズ」が可能になりました。また、boolean(チェックボック)フィールドが追加されました。



ASP型のヘッドレスCMS「microCMS」のベータテストが始まっています。
通常は月額8,500円が必要ですが、試用期間は無償で使い放題ということで、事前予約をしていました。

https://microcms.io/

ヘッドレスCMS」については後述しますが、これまでのCMSと概念が異なるため、使いどころが難しいです。実際にサイトを構築してみるしかないだろうと、コンセプトから考えてきっちり作ったので、体験レポートをします。

サンプルサイト


「動画投稿サイトから人気が出たブレイク直前の男性アーティスト」という、どこかで聞いたような人物のオフィシャルサイトです。
試用期間が終了する、2019年9月30日まで限定公開します。

(公開は終了しました)

Tsuyoshi.さん、かっこいい写真をありがとうございます。またジンギスカン食べましょう :D


基本的に静的サイトですが、以下の3箇所で、JavaScriptでmicroCMSに投稿したデータを表示しています。

  • Home>What's New
  • Home>Discography最新
  • Discography

ヘッドレスCMSとは



話を戻して、ヘッドレスCMSについてざっと説明します。

これまでの主要なCMSは、管理画面=投稿部分と、テンプレートエンジン=表示部分で構成されていますが、ヘッドレスCMSは表示部分を持っていません。そのかわりAPIが提供されていて、各ユーザーがAPIから取得したデータを加工して利用します。

利点は、ユーザー側が好きなスクリプト言語を使用でき、かつウェブサイトに限らず、スマートフォンアプリ・デジタルサイネージと、様々なプラットフォームに使えるというところです。

一方で欠点は、ノンプログラマには利用できないところです。また、アーカイブを考えなければならないブログやコーポレートサイトでの利用では、便利さを感じにくいでしょう。

管理画面の印象



APIのセット=サイトやプロジェクト名を新規作成すると「スキーマ」を作るように言われます。「フィールド」のことらしいです。入力例がないので何のことなのかしばらく悩みました。
上の画像はDiscographyのスキーマの一部です。



フィールドタイプは、現状、5種類しかありません。「ラジオボタン」「セレクトボックス」「チェックボックス」がないのは、かなりきついです。正式版までに実装されると願いたいものです。NewsやDiscographyのカテゴリーラベルは文字列の直打ちにしました。

booleanフィールドが追加され、チェックボックスでの選択が可能になりました。

日時は、タイムスタンプ=公開日時のことはありません。タイムスタンプはデフォルトで提供されます。公開日時を変更可能にしたい場合は、フィールドを作る必要があると思います。



スキーマを作ったらすぐ入力を始められます。画像フィールドに編集アイコンがありますが、画像のサイズを変えることはできません。また、現時点ではアップロード時のリサイズ生成ルールもありません。ここでは公開サイズに編集してからアップロードしています。

APIリクエスト時にクエリを送ることで、画像をリサイズできるようになりました。

開発の方からTwitterで教えていただいたのですが、画像サイズについては早めに対応を考えているとのことです。開発ロードマップは、管理画面で見ることができます。

コンテンツの表示

入力はすぐできたので、静的サイトを作って、いよいよAPIの取得・表示部分に取り掛かりました。

サンプルサイトのスキーマは複雑なので、「タイトル・日付・画像・テキスト」を持ったスキーマ「post」を表示するサンプルをGistで公開しておきます。
かなり雑なスクリプトですが…

APIを見て気付いたのが、API側でできることが、指定したフィールドの取得・表示件数・非公開記事を表示するかの選択くらいしかないことでした。

つまり、以下のようなことは自分でスクリプトを書いて実装しなければならないということです。

  • 並べ替え
  • フィールドの内容による絞り込み
  • ページネーションの生成

私はJavaScriptを専門にできるほどのスキルはまだありません。なので、Gistの内容を実装するまででも2時間くらいかかりました。テンプレートエンジンを知っていればもっとスムーズだったかもしれませんが。

microCMSのトップページの導入ケースに「デザイナー」がいるので誤解しがちですが、少なくともデザイナー向けのCMSではないです(そう書いてもいません)。

使えそうな状況

私はコーポレートサイトの制作が多いので推測レベルですが、以下のようなコンテンツに向いていそうです。

  • 静的サイトのごく一部にしか使用しない
  • データを表示したい対象が、サイト、アプリ、デジタルサイネージなど多数ある
  • データ構造がシンプル
  • ページネーション、検索、アーカイブなどの必要性が薄い

パッと浮かんだのが、スマホゲームアプリの開発会社です。公式とアプリの両方にお知らせを出しつつ、多数のゲーム用のアカウントを作る感じです。APIは30本まで作れるので、単純に30タイトルまでいけるということになります。
ゲームアプリを作るくらいの人たちであれば、ゲーム内にお知らせを組み込んだ方が楽なのかもしれないですが。

今回、アーティストのサイトを作ったのは、アーティストのサイトは、最初はSNS中心で小さく始めて、売れるに従って規模が大きくなっていくケースが見られるからです。

microCMSのライバル

身も蓋もない話になってしまいそうですが、ASP型CMS「MovableType.net」でもData APIが使えます。
使用したいサイトが1個だけであれば、こちらの方がコスパが良かったりします。

https://movabletype.net/support/setting/data-api.html

ただし、MovableType.netはあくまで、ウェブコンテンツの管理が主であり、API利用に特化するなら必要ない機能も多いです。microCMSのようにサクッと立ち上げることは難しいでしょう。そのあたりで差別化ができそうです。

私の業務内容からすると、microCMSはまだまだ縁が薄そうなのが残念です。でも、スキーマや表示部分を自分を組み立てていくのはとても楽しかったです。APIや管理画面の機能が改良されていけば、これまでになかったCMSとなるだろうと期待しています。


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

a-blog cmsに組み込まれているJavaScriptライブラリを体験できるテーマを配布します

ハンズオンをすると漏れなくピカブイにまみれることができます


先週、8月31日は「CMSMix Sapporo Vol.13・a-blog cmsの回」を開催しました。

札幌での勉強会の参加は、今週末の「CSS Nite in Sapporo, vol.23『北海道限定!ブランディング』」で、当分お休みになります。二年以上に渡ってCMS Mixを共同運営していた、西山さん、白根さん、ありがとうございます。俺流のザンギは最高です (๑´ڡ`๑)

さて、Vol.13のテーマは、a-blog cmsの「組み込みJS」について、ハンズオン形式で紹介しました。
a-blog cmsには、インストール時点で制作を補助するJavaScriptライブラリが、多数読み込まれています。これらは簡単なclassやdata属性の付与で起動することができます。

ハンズオンで使用したバージョンから一部修正した学習用テーマを、GitHubで公開します。

https://github.com/webbingstudio/acms_builtin_js_handson

インストール直後のa-blog cmsにこのテーマを反映するだけで、画面の指示に従って以下のライブラリを体験できます。

  • 指定した管理画面URLをポップアップで表示
  • スムーズスクロール
  • コンテンツの折りたたみ
  • 動画のポップアップ
  • 最低限のタグのみ使用できるリッチテキストエディタ
  • カスタムフィールドの文字数をカウントする
  • 表を簡単に入力できるカスタムフィールドを作る
  • 組み込みJSの設定を変更する

組み込みJSの立ち位置

勉強会で「この組み込みJSを使うということは、うぇびんさんは、CMSのサイトを作るときにJSも書くんですか?」と聞かれました。制作会社とフリーランスの温度差を感じる質問でした。

CMSを扱う制作会社の場合、コーディング担当とCMS構築担当という切り分けになることが多いですが、私のようなフリーランスの制作者は「ワンストップでやってほしい」と、しばしば希望されます。やはりその方が手戻りが少ないからで、コーディングが完了したデータをいただいて作業するのは、大企業さんの案件くらいです。

問題は、ウェブサイトにはJavaScriptの演出が欠かせないというところです。ライブラリを探して組み込んで、デザインを合わせる工数だけでもばかになりません。私はある程度JavaScriptを書くことができますが、デザイン+HTML+CSS+WordPressというスキルセットの制作者はいつも大変です。

そういう、JavaScriptを通常業務としていない人でも、ある程度の演出を気軽に使用できるのは、a-blog cmsの強みではないかと思います。また、a-blog cmsは公式テーマでサイト構造だけ作ってからデザインを考える手法を勧めているので、イメージしている演出を組み込みJSでさくっと組んでしまうこともできます。XDみたいな感じですね。

逆に、コーディングが先にあって、かつJavaScriptのスキルが高い人だと、必要のないライブラリが多数読み込まれてしまうa-blog cmsの仕様は不便に感じるかもしれません。

ハンズオン素材を作る目的

勉強会では、時間が許す限りハンズオン素材を制作しています。また、素材は配布可能にしたいと考えています。
これは勉強会を楽しく進めるのに必要なのはもちろんなのですが、少なからずいる、勉強会に物理的・時間的な理由で来られない人にアプローチしたいからです。

というか、そういう潜在的な参加予備軍の方がはるかに多いはずです。「勉強会に行くと参加者とつながりができたり、そのCMSを使わざるを得なくなるのでめんどくさい」という、現実的な理由があるのも察しています。
そういう人たちにも気軽に使ってもらって、「a-blog cms便利だな!!」となってもらえるとうれしいです。他のCMSのユーザーの人も偵察にお使いくださいw

勉強会の後半ではヘッドレスCMS「microCMS」を試しました。それはまた次の記事で書きます。


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

CSSプロパティはどこまで覚えればいいのか


今朝、Twitterを見ていたら「未経験からの入社でも、このくらいはCSSのプロパティや値を覚えていてほしい」というツイートが流れてきました。

一連のプロパティの紹介はとても勉強になるもので、うなずきながら読んでいましたが、途中、どうにも同意できなくて突っ込みを入れたものがあります。

  • flex-flow、justify-content、align-itemsの全ての値
  • animationのfill-mode
  • :nth-of-type疑似要素

これらのプロパティは中級者以上が、存在を知っている程度で充分であり、覚えるものではないと考えています。

覚えなくて良いと考える理由

私がこれまでお取引をした制作会社の「平均よりちょっと上」のレベルをイメージしています。

flexbox関連

flexbox 自体は、マークアップエンジニアとして就職するなら必修です。が、入社レベルでは以下の3パターンを実装するためのスニペットを知っていればいいです。このパターン以外の値の使用頻度が、極端に低いためです。

  • すべての要素を改行せず並べる+すべての要素の高さを揃える(レイアウト)
  • すべての要素を改行せず並べる+すべての要素を縦中央に揃える(ページネーション等)
  • 幅がオーバーした場合改行する+すべての要素の高さを揃える(グリッドレイアウト等)

なお、スマホでは横並びを解除(flex-direction: column)も意外と出番が多いです。

justify-contentの space-around, space-evenly は、一般のウェブデザインのパターンではあまり見られません。私は一度も実装したことがありません。デザインお任せのときに使ってみたいですが。
使用頻度が低いプロパティの挙動を研究するのは、頻度が高いスキルを問題なくこなせるようになってからでもいいです。むしろ読みやすいコードを書いてほしいです。

animation関連

「アートディレクターがゴリゴリに作ったカンプをCSSで動かすことになり、コーディングができる社員が初級者しかいない」という状況ならまだ理解はできるのですが、animationの fill-mode を初級者に説明させるのは酷というものです。使うとしてもbothでだいたいなんとかなります。
まずは transition から書かせて、CSSアニメーションの基礎を知ってからの方が理解しやすいと思います。transitionは必修です。

:nth-of-type

このプロパティを知らなかったというツイートをけっこう見ました。そのくらい使用頻度が低いプロパティです。
詳しくはMDNのリファレンスを見ていただきたいですが、以下のようなHTMLに任意のスタイルを反映させる際に役立ちます。

  • 自由にクラスを付与できない
  • 繰り返される
  • 他の要素が兄弟階層に混ざる可能性がある

WordPressのGutenbergなどの、CMSのブロックエディタで生成されたHTMLを整形する際に役立つ可能性があります。
ですが「使用頻度が低い」と書いたとおり、:nth-of-typeを知らなくても解決できるようなHTMLが提供されていることがほとんどで、私も一度しか使ったことがありません。また、JavaScriptを追加できるならDOMを解析して連番クラスを付与する手もあります。
考えられるのは、官公庁などのいにしえのHTMLを、一切触らずにCSSを追加しなければならないような状況でしょうか…

プロパティはどこまで覚えればいいのか

人それぞれと思いますが…私は
Bootstrapに書いてあるCSSが、覚えておきたいプロパティと値である」
と考えています。

BootstrapなどのCSSフレームワークは、実際にウェブ制作で頻繁に使用されるモジュールやコンポーネントの集合体であるからです。

開発者ツールで遊ぼう、フレームワークを読もう

ここ数年、年に2回、初心者向け講座の講師をしていました。「会社に入ったばかりの初心者に、最低限のHTML・CSS・JavaScriptを三日間で教える」というなかなかハードな講座です。

https://www.deos.co.jp/koza/detail/tf010

カリキュラムの作成にも一部参加したのですが、困ったのがCSSでした。一日では教えきれないほど必修のプロパティが多いのです。
最終的に「テキストにはいろいろ値が書かれているけれど、これとこれ以外は、今は覚えなくて良いです」と、現場で使用されているプロパティを推しまくる進め方になりました。

それだけでは、当然勉強不足です。なので、以下の三点を補足しました。

  • Chromeの「開発者ツール」を早い段階で触らせ、各プロパティに様々な値が存在していることも教える
  • 有名どころのCSSフレームワークを見てほしいと説明する
  • 時間の関係で教えられないプロパティは、名称と簡単な役割をメモさせておき、検索するように言う

CSSに限らず、学習には以下の三点が必要なのだと思っています。

  • 習得の優先順位を判別すること(これは勤め先の環境でも変わるでしょう)
  • 既存ツール、素材を活用すること
  • アンテナを張り、気になった用語を検索して調べること

長々と書きましたが、私はコーディングが大嫌いです!予算に余裕さえあれば、コーディングが得意な友人たちに外注してCMSだけを触っていたいくらいです。

だからこそ、すべての人が高いレベルのCSSの知識を持っていなくてもいいのではないかな…と感じます。

追記

元ツイは一旦削除されましたが、ツイ主のTAKさんが、知っておくと良いプロパティと値について、再度まとめてくださいました。
こちらからTwitterへ移動して、一連のスレッドを読めます。


投稿者名 うぇびん 投稿日時 2019年08月07日 | 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

「さくらのVPS」から「さくらのレンタルサーバー」へドメインを移動するときは、一旦すべての設定を削除しなければならない

「さくらのレンタルサーバー」のドメイン管理の独特の仕様でハマったので記事にしておきます。

「さくらのVPS」を解約し、ドメインとCMSを「さくらのレンタルサーバー」へ移転したいという依頼でした。

移転当日、いつものように、さくらインターネットの「ドメインメニュー」でDNSを変更して、レンタルサーバー側のコントロールパネルにドメインを登録しようとしましたが、できません。

「さくらのレンタルサーバー」は、以前の所有者のコントロールパネルや移転前のサーバーにつながっていると追加できないというのは以前から知っています。ですが、今回の場合はすでに新しいサーバーへつなぐよう変更しているのに、追加できません。

変更ではなく削除

困って、さくらのサポートへ相談したところ、以下のようなお返事がありました。

さくらのレンタルサーバにドメインの追加設定を行います場合
現在のゾーン情報が削除されている必要がございます。

会員メニュー画面上 "契約情報" → "契約ドメインの確認" →画面右下 [ドメインメニュー] → 該当ドメインの [ゾーン編集]
画面左 [削除] にて現在のゾーン情報を削除ください。

削除後、新しい設定は作成せずにさくらのレンタルサーバの
コントロールパネルからドメインの追加設定を行ってください。

つまり「さくらのレンタルサーバー」に独自ドメインを使用する場合は、同じアカウントが取得したサーバーであろうと、どのような設定であろうと、二回目以降は、一旦設定を削除しなければならない、ということらしいです。

さくらインターネットで取得した独自ドメインが追加できません

これまでずいぶん、さくらのサービスを使ってきたと思ったのですが、VPSからレンタルサーバーへ移転するケースははじめてだったということに、今更気づきました。
お名前.comやムームードメインと同様に、先にDNSの設定をしても良いのだと思いこんでいたのでした。


さくらインターネットのドメインメニュー画面


※画像のユーザーID、ドメインの設定、履歴はでたらめです

削除するとどうなるのか

なるほどそういうことか、ではドメインの設定を削除すればいいですね、ポチ
と削除したところで、この仕様の本当に恐ろしい部分に気づきました。

今回のドメインは、メールはさくらのレンタルサーバーではなく、GsuiteのGmailサーバーを利用していたのです。
削除した時点で、Gmailサーバーへつないでいた設定も全部切断されてしまいました。

お客様には、メールには影響がないとお伝えしていたので大失敗です。平謝りで設定をし直しました。
事前に設定を控えておいたのが不幸中の幸いでしたが、一時間ほどメールの送受信ができなくなってしまいました…

まとめ

結論からいうと、「さくらのレンタルサーバー」への移転の注意点は、以下の通りということになります。

  • さくらのVPSなどの他サーバーに接続していたさくらのドメインを使用する場合は、一旦設定を削除しなければならない
  • その際にGmailなどの、外部サービスへの接続もすべて切断されてしまう

この業界で15年仕事をしていて、こんな記事を書いていて大丈夫だろうか…と凹んでいます。
いつもと同じ感覚で作業すればいいや、というのが事故の元になることが、改めてよくわかりました…


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