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

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

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

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

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

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

変更ではなく削除

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

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

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

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

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

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

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


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


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

削除するとどうなるのか

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

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

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

まとめ

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

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

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


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

Atomic Designの思想でCSSフレームワークを作るのは難しいので代替案を考える


一昨日、「FLOCSSがわかりにくい」「Atomic Designの思想でフレームワークを作ってみたい」という記事を書いたところ、とてもたくさんの感想をいただきました。

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

大半がフロントエンドエンジニアからの突っ込みです。著名な方々にもたくさん意見をいただいただのでまとめました。ありがとうございます。

「Atomic Designの思想で、文系でもわかるCSSフレームワークを作りたい」に識者たちの鋭すぎる突っ込みが入る - Togetterまとめ

Atomic DesignがCSS設計に適していない理由

ピクセルグリッドの高津戸さんによると、そもそもAtomic DesignはCSSやJSの設計とは全く関係ないそうですが、よく考えてみると、たしかに厳密な階層構造を持っているAtomic Designの設計は、デザインレベルからの意思統一が可能な環境でなければ破綻してしまいます。

私はデザインを外部に発注することが多いですし、CMSベースで構築すると、どうしてもマークアップやクラスの命名に手を出せない箇所が出てきます(※)。

そんなこんなで、Atomic Designを採用することは諦めて、既存のCSS設計を、専門のマークアップエンジニアではなくても理解しやすくする方向で考え直すことにしました。


投稿者名 うぇびん 投稿日時 2017年06月16日 | Permalink

UQ WiMAXが遅いのをなんとかしようとした話

2015-07-06 追記:
UQ WiMAXの通信制限の説明が不十分であることについて、集団訴訟が行われます。私自身は通信速度は改善しており、制限の説明は事前に受けていたため参加しませんが、困っている方の参考になれば幸いです。


出先で仕事をすることが多くなってきたので、完全ノマドを妄想して、「UQ WiMAX」を契約してみました。

正確には、ビックカメラの「BIC WiMAX SERVICE」で、端末はWi-Fi WALKER WiMAX 2+ NAD11です。

二週間使ってみたものの、残念ながら期待していたクォリティにはほど遠いです…違約金という名の授業料を払って、解約することになりそうです。


私の利用状況や、速度向上のために試してみたことなどを記事にまとめます。
WiMAXを検討している人のお役に立てば幸いです。


投稿者名 うぇびん 投稿日時 2014年07月14日 | Permalink