#basercms

　前回、お問合せフォームのボタンラベル変更に対応したのですが、「個人情報保護方針をスクロールして最後まで読むまで確認ボタンを押せないように修正してほしい」と再修正指示を受けました。スクロール量によって submit ボタンの有効／無効の切り替えをするのは、JavaScript の function 追加で対応できそうだったのですが、ちょっと手こずったのでカスタマイズ手順を共有します。

この記事は、baserCMSアドベントカレンダー2019の8日目、12月8日の記事です。

先の週末、1月27日から28日にかけて一泊二日でbaserCMSの開発合宿に参加してきた。場所はいいかねPaletteという、田川市にある廃校（旧猪位金小学校）を利活用した施設で行われた。メンバーは開発メンバーの他にサポーターズの方や、メンバーのお子さんを含めて20名強。今回は管理画面の改善を目的とした内容で臨んだ。

それに至るまでの話を数回にわけて綴ろうと思う。

前回の合宿

CMSの改善にあたっては、バグフィックスだったり新機能追加だったりAPIの整備だったりセキュリティの向上だったり、色々とやりたいこと・対応することは山積みだが、管理画面の改善についてはざっくり言ってしまうとGUIの刷新が望まれていた。

管理画面の改善プロジェクトがはじまったのは実はずっと前で、2016年9月に行われた開発合宿でもそれが目的だった。当時の合宿前日までに部分的に改善方針とカンプは完成していて、合宿の中である程度形になったのだが、合宿終了後に各メンバーの多忙で開発ブランチが置いてけぼりになり、ブラッシュアップができぬまま放置されてしまった。

プロジェクトの再起動

整理をすると、改善案は次のように計画していた。

バックエンドシステムに関わる機能は基本的に現状維持

導線（ナビゲーション）を主に改善する

グラフィカルな面を今風に刷新する

バックエンドはそのままなので、メインのタスクはフロントエンドに依る。悲しいかな当時のメンバーはフロントエンドが得意な人間が多くなく、タスクボリュームとモチベーションの維持に悩まされる。

改めてプロジェクトを再起動させたのは昨年2017年の4月。我らが@Garyutenさんが、フロントエンドエンジニアを2名誘ってくれて、とりあえずコツコツ始めようよということで、計画的にやることになった。

フロントエンドの開発計画

まずは技術的にどう対応していくかを検討する。そもそも作られた時代的にフロントエンドの開発環境というものがなかったので、そこから整備をする必要があった。昨今のフロントエンド開発手法が安定しないので下手に環境を導入すると新しい開発者が参入できないという懸念が挙がったが、どちらにしても参入者が少ないかったので思い切って整備を始めた。ダイジョブ、古くなったら整備し直せばいいだけだ。

タスクランナーはgulp

CSSはSASSに

JavaScriptはTypeScriptに

jQueryで処理している機能はVue.jsに

タスクランナーはgulp

導入しやすかった以外の理由はない。

CSSはSASSに

おおよそSASSを導入しない理由なんてないのだけど、主に次の2つが理由だ。

CSSファイルから記述されているID・クラスが想像できない状態だったので整理したい

GUIのパーツがそれぞれがなるべく依存せず・干渉せず、独立して成立するようにコンポーネント単位で管理したい

コンポーネントとして管理するのは後に控えてる計画にも通じる。

JavaScriptはTypeScriptに

この件と次の件は開発メンバーのエンジニア間で大いに論争になったが、一応決着はついたつもりでいる。

JavaScriptは便利で気軽な言語な反面、本当にきちんと設計しないといけない。思わぬところに簡単なエラーや不具合を産んでしまったり、セキュリティの責任を持つこともある。その「きちんと」をある程度補ってくれるのが型システムだったりするので、コンパイラに安全性の一部を任せるべきだという結論。

もちろん他にもリンターやテストコードなど、機械検出で安全にできるものは積極的に導入したい。

jQueryで処理している機能はVue.jsに

開発者がライブラリを扱えるか扱えないか置いといて、DOMを直接操作するか、Viewライブラリを導入するかの二択である。要素操作設計を自分でするか、ライブラリに委ねるか、と言い換えてもいい。やっぱりここでも「本当にきちんと設計できるか」どうかの問題があり、より多くの知見がつまったViewライブラリを選択するべきだろうという結論だ。

開発再開

挙げた4つのうち、まずはgulpとSASSを導入する。これはすぐに済んだ。gulpは設定ファイルを書くだけ。SASSも最初はCSSファイルの拡張子を.scssにリネームすればいいだけだ。あとはクラスをひとつひとつ丁寧に見ていって整理する計画をたてていく。

TypeScript化とVue.js化も同時に行いたかったが、どこをどうコンポーネントにしていくか、どういう単位になるかをクラスの整理で見極めていく必要があったので後回しとなった。また、GUI刷新にあたってCSSの調整はマストだがJavaScript部分は機能的にまったくどっちでもよかったので、コンポーネントごとに部分的に変換をしていくようにした。

まだ日が浅いので… なんとも言えませんが

なんとなく引っかかる検索キーワード増えた！？

詳しくは言えませんが Google Analytics の検索からの流入が明らかに上がりました。

もともと WordPressだったときと URLは完全一致＋ページ数増量 ということもあるかもしれません。

sitemap.xmlを XML-Sitemaps.com というサイトで作っているということもあるかも・・・

コーポレートサイトなのでページ数は滅多に増えません。

ブログはサブドメインで運用しているのでそちらはWordPressにお任せ・・・

昨日 エックスサーバーのSSLを申し込んで本日設定完了したようなので、今後 https化していく予定です。

また、ご報告します！

[adsense]

弊社のコーポレートサイトをリニューアルいたしました！！ 株式会社ジーティーアイ http://gti.jp

正確に言うと・・・リニューアルしていたんですが、DNS切替を行い公開しちゃいました・・・ってところですね。

今回、国産オープンソースのCMS「baserCMS」にてサイト構築しました！

コーポレートサイトにちょうどいい！っていう響きが良く、一度試してみたかったので自社サイトで実績化（笑）

実はもうちょっといろいろ手を入れたかったところもありますが、おいおい育てていきます。

今後ともどうぞよろしくお願いいたします。

—追伸— baserCMSって頭文字が小文字だったのね。 いろんなところで　BaserCMS　って書いた気がする・・・ 失礼いたしました。

BaserCMSで弊社サイトリニューアル時、困ったことが・・・

BaserCMSでは .htaccessにてゴニョゴニョしてリクエストパラメータを処理した結果を表示してくれているのですが そもそもこのサイト上にあった「サンプルコード」も移設しており（ちょっと変なところに置いちゃったなぁという反省はあります・・・） このサンプルコードのディレクトリ名を入れてもCMSのパラメータとして処理されちゃうため 「４０４　Not Found」ってなっちゃっていたんです。

でも・・・特定ディレクトリを除外する設定を.htaccessには記述してあったんですよ・・・。

うーん。困った～。 で、「RewriteCond効かない」でGoogle検索。

すると、全く同じ検索で同様の回答を得た方の記事を発見！

kennyjのブログ(仮): RewriteCondが効かずに困った.

助かりました。

解決しました。

baserCMS勉強会@福岡 Vol.10に行ってきた。

改めて理解

業務でbaserCMSは導入しているけど、僕のやっていることはデザインをスライスしてマークアップするまで。あとのbaserへの組み込みはシステムの方にお任せしているスタイルの制作形態だから、僕ががっつりとテンプレートファイルをいじるとかはない。

それでもちょっとしたところを修正させてもらったり、ディレクトリ構造を理解したりする必要があってぼんやりとbaserCMSの構造を見ていた。

というわけで、今回一から構築するのを見れてだいぶ理解が深まった。「たぶんこういうことしてるんだろうなー」という予想をしながらだったものが「あーやっぱりそうなのかー」とか「え、そういうことだったの」となったのは嬉しい。

いわゆるWordPressと同じ

こう言ってしまうのもアレなんだけど、組み込みの難しさというか敷居はいい意味でも悪い意味でもWordPressと同じだと思う。

WordPressでの構築経験があると、すごくわかりやすい構造。細かい設定や、コアのアーキテクチャは全然違うんだけど、特定のディレクトリにテンプレートファイルを作ればOK。

テンプレートエンジンを使っているわけではなく、WPと同じPHPファイルを直接テンプレートとして扱うスタイルは、WordPressユーザーにはすごく親しみやすいけど、デザイナーにとってはやっぱ敷居が高そうだなーと思った。

まあ、今の時代WP構築できないWebデザイナーなんて淘汰されていくだけだからこのくらいのタグやプログラミングの基礎(ifやforeach)覚えろよ、って考え方もあるんだけど、どうせならもっと簡単であってほしいもの。もっと簡単であれば、導入するユーザーも増えると思う。きっと。

ブログはWP、コーポレートサイトはbaserで。

あと思うのは、ブログが書きたいのならWPでいいと思う。そのくらい似てる。baserはCMSとしてWPにも負けないくらい流行ってくれたら嬉しいんだけど、ブログとしてのWPには対抗しちゃいけない気がする。コーポレートサイトを無理やりWPで構築しようとしているユーザーを取り込めればいい。

なんか1から10までWPと同じ土俵で比べがちなんだけど（実際僕もそういう目でどうしても見てしまう）、「ブログだけならWP。コーポレートサイトならbaser。」というもっともっとわかりやすい布教ができたらなあと思う。

WPが既にコーポレートサイトをも喰ってしまっている事実があるので難しいんだけどね。

固定ページ

固定ページが何か、画期的な機能か更新性か管理性か、そういうのができれば、WPでは絶対できない何かがあれば、すごい強みになるんだけどなぁと思う。

妄想はそこそこに