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

先週、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」を試しました。それはまた次の記事で書きます。

今朝、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フレームワークは、実際にウェブ制作で頻繁に使用されるモジュールやコンポーネントの集合体であるからです。

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

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

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

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

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

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

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

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

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

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

追記

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

①単位

【em】
親要素のfont-sizeを基準にした相対値。要素のfont-sizeが16px相当だったら1em→16pxとなります。.5emなら16pxの50%の8pxです。font-sizeで可変したいmarginやpadding、あとはletter-spacingもemで指定されることが多いです(サルワカさんおすすめの指定方法)

— TAK (@tak_dcxi) August 6, 2019

テーマの継承＝親子テーマの概念がある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ブロックを使用した場合、条件に合致していないコードも処理されます。なので、このような書き方をすると、実質２ページ分の読み込みが発生して処理が遅くなります。

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のコメントなどいただけると、とてもうれしいです。

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

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

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

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

変更ではなく削除

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

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

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

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

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

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

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

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

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

削除するとどうなるのか

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

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

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

まとめ

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

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

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

すでに解決していただきましたが、旧バージョンの管理画面テーマを使用している人が検索するかもしれませんので、ログとして残しておきます。

私が制作したbaserCMSのテーマ「ratio_3_2」に、バージョン4.2から選択できるようになった新しい管理画面テーマを適用すると、SNSアイコンが出なくなってしまいました。

先月リリースされたbaserCMS4.2について、不具合のお知らせです。
ベータ版として同梱されている管理画面テーマ「admin-third」を有効にすると、ratio_3_2のFontAwesomeのアイコンがリンク切れになる不具合を確認しています。（続く） #baserCMS pic.twitter.com/oL9Y1ItiQp

— うぇびんさん (@webbingstudio) 2019年7月15日

調べたところ、以下の原因が判明しました。

• baseCMSはログイン中、ヘッダに常時ツールバーが表示される
• ツールバーでは、FontAwesomeの5系が使用されている
• FontAwesomeは、4系と5系を同時に使用すると、4系のアイコンが正常に表示できなくなる（クラス名が重複しているため）。

ratio_3_2だけでなく、FontAwesomeの4系が使用されているテーマはすべてこの不具合が発生する可能性がある、ということで、FontAwesomeをツールバーに使用しないように修正していただきました。ありがとうございます。

2019年7月20日時点では、まだ公式サイトのダウンロードファイルは更新されていません。気になる方は、baserCMSの公式リポジトリから、最新バージョンをダウンロードしてください。

https://github.com/baserproject/basercms

テーマだけ差し替えたいという場合は、 /app/webroot/theme/admin-third/ 以下を差し替えればOKです。

まだベータ版ですが、baserCMSの新しい管理画面用テーマは、デザインやカラーリングのバランスが取れていて、旧テーマよりもかなり使いやすいと思います。日常的にbaserを使用している方は試してみてください。