タグ検索：a-blogcms

昨年末になりますが、弊社で利用しているa-blog cmsの最新バージョン2.11がリリースされました。
弊社でもすでに利用していますが、今回のバージョンアップでも沢山の新機能がありますので、ご利用いただくお客様には多くのメリットを感じていただけるのではと思っています。また、新しいライセンス体系が設定されましたので、運用に合わせた導入方法の選択肢が広がりました。

・a-blog cms Ver. 2.11リリース
https://developer.a-blogcms.jp/blog/changelog/release211.html

詳細はオフィシャルサイトの情報をご覧いただくとして、個人的に嬉しいのはこの辺り。

・セキュリティの強化（ログイン操作ミスによるロック機能、二段階認証など）
・パフォーマンスの改善（モジュールのキャッシュ機能、lazy-load系など）
・新しいリッチエディターユニットの導入（PaperEditor）
・PDFのプレビュー機能
・エントリーの一括変更機能（既存エントリーを一括で修正可能になる）

えっと、新機能のほとんどですね。
でも、本当に素晴らしい機能が追加されたので、これから益々より良いサイト作りができると思います。特にセキュリティやパフォーマンスの向上は、現場で求められていますし、PaperEditorはユニットベースのa-blog cmsの自由度を高めてくれるものになると思います。

あとは、メンテナンスポリシーの明確化というのも嬉しい情報です。今後利用バージョンのリリース日から、バグ修正は2年間、セキュリティ修正は5年間となりました。このあたりも明確化されることで、お客様にもご理解いただきやすくなると思います。弊社のお客様でも、いまだに10年ほど前のバージョンをご利用中のお客様もみえます。この場合、バグだけでなくセキュリティに関しても対応できておりませんので、ぜひこの機会にバージョンアップをご検討いただけると幸いです。

ぜひ、自社サイトにお悩みをお持ちの皆様、
新しくなったa-blog cms ver2.11で、サイトをより良くしてみませんか？

最近仕事で利用していた外付けHDDがクラッシュし、データが書き込めなくなるという事がありました。
今回は幸いデータは読み込めたので、バックアップを取りフォーマットして再利用しています。容量が3TBと大きく作業に2日間程かかりましたが、今回は無事復旧できてホッとしたところです。

しかしディスクが完全にクラッシュしてしまった場合は、データが取り出せない場合が多々あります。前回壊れたディスクは復旧できず諦める事になりました。また、どうしても必要なデータの場合は業者に頼むことになりますが、復旧出来たとしても費用は高額で結局は諦めることがほとんどだと思います。

長年PCを使った仕事をしていると、数年に一度の頻度でこの様な事態に遭遇します。今まではその都度ディスクを買い替えて対応してきた訳ですが、今回は社内環境を見直し、XSERVERが提供しているクラウド型高速オンラインストレージ「XDRIVE」を導入する事にしました。

このXDRIVEですが、使ってみると高速でブラウザでの操作も分かりやすく快適です。ビジネスのプランなら、ひとり 9,072円（税8%込）／年で月で割ると756円とかなりリーズナブルです。考え方にもよりますが、大体2年に1度位はスタッフ誰かの外付ディスクが壊れるので、XDRIVEが2年で18000円位のコストと比較すると、外付けHDが壊れるリスク・データの保守・壊れた際の復旧作業の時間などを踏まえ、かなりお得ではないでしょうか。

またクラウドだという事や、共有設定・外部への公開設定もできるので、結果的にXDRIVEを導入する事でDropboxをやめる事ができました。これは本来の用途的にDropboxとXDRIVEは異なるのですが、弊社の場合はDropboxが社内の共有クラウドディスク化していましたので、XDRIVEで十分代用できたという感じです。

ということで、Dropboxは有償のPlusプランをスタッフ人数分使っていたのですが、全て無料プランにダウングレードしました。Dropboxは紹介などによって無料プランでもある程度ディスク容量を確保できるので、弊社の場合は数GBあればクライアント・外部とのデータのやりとりにも困ることは無く、結果的に固定費のコストダウンにつながりました。

色々と便利なサービスは多いので、つい始めてしまうと見直す機会を逃しがちですが、最近のサービスは固定費用がかかるクラウドサービスが多いため、始めてばかりいるといつの間にか固定費が膨らむという事になります。今回は必要なものを見極め、不要なものは見直す良い機会となり、導入して良かったです。

現在XDRIVEの他に古いサーバも見直し中です。特にサーバは最新のものに置き換える事で、同じコストでも高性能化する事がほとんどです。この様な固定サービスは、定期的に見直しながら良いものがあれば取り入れるという取り組みが大切だと思います。

弊社はWebサイト制作やデザイン制作が主な業務ですが、この様なPC周辺のご相談も対応可能ですので、何かにお困りの際はぜひお気軽にご相談ください。

・XDRIVE
https://www.xdrive.ne.jp/

・XDRIVEをご契約の際にぜひご利用ください（弊社お取り次ぎ）
https://www.xdrive.ne.jp/agency_via/?cd=XAFSLX&type=server

Webサイトの評価基準って色々あると思いますが、ひとつの指標としてGoogle ChromeのAuditでのチェックがあります。
Auditには「Performance」「Accesibility」「Best Practices」「SEO」「Progressive Web App」の5つの項目がありますが、通常のWebサイトでは「Progressive Web App」を除いた4つの項目での評価を参考にしています。

このブログでも他のエントリーで書いていますが、速度アップのためのチューニングやWebアクセシビリティ向上への取り組みなど、Webサイトの根っ子の改善がWebサイト自体の価値を高める大切な要素になっていると思います。Webサイトというものは、世界中の情報が手軽に得られるというアクセシブルものなので、この考え方はとてもシンプルでわかりやすいものだと思います。

このサイトもこの4つの項目を意識して調整をしていますが、全ての項目をパーフェクトにすることは難しいです。ただ「Accesibility」などは、無計画に作っても満足な結果になる事は無いので、しっかり意識した上で、何にどこまで対応するのかを検討することが一番大切なのかもしれません。そしてこの改善を積み重ねていく事が最も重要なんだと思います。

現在の弊社サイトの状態です。まだまだ改善の余地はありそうです。

今回はa-blog cmsの「クライアントキャッシュ有効時間」の話です。
こちらも先日の「a-blog cmsの日」で教えてもらったのですが、a-blog cmsでブラウザのキャッシュの有効期限を設定し、サーバへのアクセス負荷を減らすというものです。

公式な説明によると…

という事です。
ブラウザのキャッシュなので、一旦キャッシュすると指定した秒数が経つまでブラウザのキャッシュを利用します。そのため更新してもすぐに画面に反映されないので、運用に合わせて秒数を設定するという感じです。

設定はコンフィグの機能設定にある「クライアントのキャッシュ有効時間」に秒数を設定するだけなので簡単です。

クライアントのキャッシュ有効時間を設定する

a-blog cmsの特徴として、ログイン・非ログインに関わらず同じURLでページにアクセスしますので、キャッシュが効いているとページの変化が反映されない場合があります。また、公開したエントリーが即座に反映されない場合もあります。このキャッシュ機能を使う場合は、サイト管理者側が理解をしていないとダメな気がしますから、運用側でしっかり把握しておく必要があると思います。

ただ、キャッシュのメリットは大きいので、少しでもサイトのパフォーマンスを上げたい方にぴったりの機能だとお思います。ちなみにページの更新状態にシビアな条件がなければ「120秒位で運用すると良い」というお話でしたが、仮に120秒が厳しい場合に15〜30秒程度で設定しても効果があるという事でした。

現状このサイトは120秒で運用していますが、サイト管理者が理解していれば、120秒程度のキャッシュのデメリットは感じられません。こちらはオススメ機能のひとつですので、ぜひ一度試してみてください。

先日参加したa-blog cmsの日（a-blog cmsの勉強会）でコンテンツセキュリティポリシー(CSP)の話がありました。
とても参考になるものでしたのでブログに残しておこうと思います。

コンテンツセキュリティポリシーを簡単に説明すると、設定されたドメイン環境以外のデータは無視することで、未知なる脅威からサイトを守るというものです。改ざんにあった際にも、コンテンツセキュリティポリシーを設定しておく事で、外部ファイルが実行できず被害を最小限に食い止めることが可能かもしれません。

a-blog cmsでは、「private/config.system.yaml」に設定をすることで実装可能ということでした。

//デフォルトはoff
content_security_policy : off # default-src 'self'; script-src 'self' | off

例えば、サイトのドメインのみデータの実行が可能にするためには下記の様に設定します。

//すべてのコンテンツをサイト自身のドメイン (サブドメインを除く) から取得
content_security_policy : default-src 'self'

この場合、他サイトのデータは実行されなくなりますので、別のサーバに置かれているjsや画像などは全て無視されます。

読み込み先にドメインを設定すれば、サイトのドメインに加え指定されたドメインの画像やjsなども実行することが可能になります。

//コンテンツをサイト自身のドメインと設定されたドメイン（sample-hp.com）から取得
content_security_policy : default-src 'self' *.sample-hp.com

例ではサイトのドメインに加え、外部ドメイン（*.sample-hp.com）のデータが読み込める様になりました。

また、SSLを指定することで暗号化した通信のみを許可する事も出来るようです。

//コンテンツをサイト自身のドメインと設定されたドメイン（www.sample-hp.com）からSSLでのみ取得
content_security_policy : default-src 'self' https://www.sample-hp.com

細かい設定は要件に合わせて追加していく様で、「script-src」「style-src」「img-src」などで、読み込むファイルの種類ごとに指定をすることも出来ます。

ただし、今どきのサイトの多くがSNSや地図APIなど外部サイトの機能に依存しているので、すべて設定するのは結構大変かもしれません。また、jsのインライン記述には基本的には対応しておらず、どうしてもインラインで書かなくてはならない場合は、ハッシュをつけるなどで対応する様です。

実際の作業としては、まずサイトのドメインだけを許可し、あとはソースやコンソールなどで表示される情報を確認しながら、読み込み可能なドメインを追加していく感じになると思います。
細かく複数のファイルを読み込むものも多いので、それなりの工数はかかりそうな気がしますが、これでリスクを減らせて安心できるなら、頑張って実装するのも良いかもしれません。