スライドトグル

特定の箇所をクリックした際に、指定した要素の表示/非表示をスライド効果で切り替えるトグル機能です。(Ver. 1.2.1より)初期状態は非表示状態です。

通常は隠しておき、クリックした時に表示されるようなものに使用できます。

デモ

詳細を表示する

詳細のテキストです。詳細のテキストです。詳細のテキストです。詳細のテキストです。

デフォルト設定

この機能の設定は、/js/config.jsの以下の箇所にあります。設定を変更する場合は、適用しているテーマ内にJavaScriptファイルを別途作成してください。詳しくは「組み込みJSについて:設定を編集する」を参照してください。

toggleHeadClassSuffix  : 'toggle-head',
toggleBodyClassSuffix  : 'toggle-body',


toggleHeadClassSuffix 表示/非表示を切り替えるときにクリックする要素のclass名の接尾辞(後ろにつく文字列)を指定します。
toggleBodyClassSuffix 表示/非表示が切り替わる要素のclass名の接尾辞(後ろにつく文字列)を指定します。

設定のカスタマイズ

config.jsのデフォルトの設定からカスタマイズする場合、JSファイルに下記のように記述します。

ACMS.Ready(function(){
  ACMS.Config.toggleHeadClassSuffix = 'js-sample-toggle-head';
  ACMS.Config.toggleBodyClassSuffix = 'js-sample-toggle-body';
});

HTMLの編集

例)toggleHeadClassSuffixで「toggle-head」、toggleBodyClassSuffixで「toggle-body」と指定した場合

<p class="toggle-head">詳細を表示する</p>
<p class="toggle-body">詳細のテキストです。詳細のテキストです。詳細のテキストです。詳細のテキストです。</p>

表示/非表示を切り替えるときにクリックする要素は、アンカーリンク()ではなくても動作します。

フォームのセキュリティ対応

フォームのセキュリティ設定周りについて学びましょう。

フォームは、一般ユーザーが送信できる箇所になり、セキュリティをしっかりと考えないといけない箇所になります。 標準的なセキュリティ対策は標準でされていますが、フォーム設定などによってもよりセキュリティを高めれますので、設定する意味や設定内容をここで学びましょう。

入力チェック

できる限り、テンプレートで指定したバリデーションは、「フォーム設定(管理画面でのフォーム詳細画面)」でもするようにしましょう。
ここの設定をおこたると、少しHTMLの知識のある人なら、開発者ツールでHTMLを変更し、バリデーションを突破されてしまう為になります。

テンプレートでのバリデーション設定

テンプレートでのバリデーション設定は以下のコードのようにHTMLによって設定できます。 ただし単なるHTMLコードなので、ブラウザの開発者ツールなどを利用すると、簡単にバリデーションの記述を削除して突破されてしまいます。

<input type="text" name="name" value="{name}" data-validator="name" />
<input type="hidden" name="field[]" value="name" />
<input type="hidden" name="name:v#required" value="" id="name-v-required" />
<div data-validator-label="name-v-required" class="validator-result-{name:v#required}">
  <p class="error-text">
    <span class="acms-admin-icon acms-admin-icon-attention"></span>名前は必須入力です。
  </p>
</div>

フォーム設定でのバリデーション設定

フォーム設定でバリデーション設定すると、サーバーサイドでのチェックになるので、攻撃者はこのバリデーションを突破できなくなります。



メールアドレスのテンプレート指定

メールアドレスの「テンプレート指定」は出来るだけ無効化させましょう。 バリデーションと同じようにテンプレートでの指定は、攻撃者がブラウザの開発者ツールなどで、自由に変更できてしまいます。 必要のない項目は「テンプレート指定を無効」にチェックをつけて無効化させましょう。

To, From, AdminTo, AdminFrom に「テンプレート指定を無効」にチェックを付けた場合は、必ず管理画面でメールアドレスを設定しましょう。設定しないと宛先と差出人の情報が空となり、メール送信で失敗します。

おすすめ設定

以下は、おすすめの設定内容になります。

一般メール設定

お問い合わせ者に自動返信するメールの設定になります。 お問い合わせ者に送信先メールアドレスさえフォームで入力してもらえればいいので、「To」以外はテンプレートで指定できないようにします。



項目 テンプレート指定
To 有効
From 固定値 無効 ✅
Cc 空 or 固定値 無効 ✅
Bcc 空 or 固定値 無効 ✅
Reply-To 空 or 固定値 無効 ✅

一般メール設定の設定例

一般メール設定の設定例


管理者宛メール設定

管理者宛メールは、送信先が決まっているので「AdminTo」をテンプレートで指定できなくします。

「AdminFrom」はお問い合わせ者のメールアドレスをテンプレートで設定することも多いと思いますが、おすすめとしては「AdminFrom」も固定にしてしまいます。 というのも、メールはCMSがあるサーバー、またはSMTPサーバーから送信されますので、Fromのメールアドレスドメインと送信サーバーが合わずFromの偽装にあたり迷惑メール扱いになる可能性が高いためになります。

ただ、このままでは管理者に届いたメールを返信しようと思っても、返信できないので「AdminReply-To」にお問い合わせ者のメールアドレスをテンプレートで指定するようにします。 これで、メーラーで返信する時、お問い合わせ者に返信できるようになります。



項目 テンプレート指定
AdminTo 固定値 無効 ✅
AdminFrom 固定値 無効 ✅
AdminCc 空 or 固定値 無効 ✅
AdminBcc 空 or 固定値 無効 ✅
AdminReply-To 有効

管理者宛メール設定の設定例

管理者宛メール設定の設定例


複数指定

特に理由がない限り複数指定できないようにチェックをつけましょう。
複数指定できてしまうと、フォームで大量のメールアドレスをカンマ続きで指定する事により、大量のメールを送信できてしまうことになります。



そもそも自動返信メールを送らない

問い合わせ受け付けメール(自動返信メール)を投稿者アドレスに送信しない設定にするのも方法の一つです。 この場合、そもそもメールが送信されないので、セキュリティを高めることができます。

ただしお問い合わせ者が正常にメールが送信されたか判断しずらいので、ここは、利便性とセキュリティを比べて判断するようにしましょう。

メール送信しないように設定する方法

フォーム設定で、メールアドレスを全て空にして、テンプレートからも指定できなくしましょう。これでメールは送信されなくなります。


メール送信しないように設定する方法

メール送信しないように設定する方法


reCAPTCHAの導入

標準機能ではありませんが、よりフォームのセキュリティを高めるために、ロボットか判断するGoogleの「reCAPTCHA」サービスと連携する方法がございます。
a-blog cms の拡張アプリとして用意されていますので、こちらもご検討ください。

https://github.com/appleple/acms-recaptcha

キャッシュ機能

a-blog cms では複数のキャッシュを使い、パフォーマンスを高めています。
ここでは使用されているキャッシュの種類とクリア方法を確認しましょう。

キャッシュの種類

ページ キャッシュ

CMSでレンダリングされたHTMLをキャッシュします。このキャッシュにより2回目のアクセスは、ほとんどのCMSの処理を飛ばすことができるので、 表示速度に大きく影響します。特に理由がなければ「有効」にしましょう。詳しくは「ページキャッシュについて」をご確認ください。

テンプレート キャッシュ

テンプレートをキャッシュします。テンプレートキャッシュがあることにより、テンプレートの組み立てを毎回することがなくなるので、 ページ表示速度が高速になります。テンプレート修正した時などはキャッシュをクリアする必要があるため注意事項がいくつかあります。 詳しくは「テンプレートキャッシュについて」をご確認ください。

コンフィグ キャッシュ

CMSのコンフィグ設定をキャッシュします。特にキャッシュについては意識する必要はなく、コンフィグを変更すると自動的にキャッシュはクリアされるようになります。

カスタムフィールド キャッシュ

コンテンツのカスタムフィールド情報をキャッシュします。特にキャッシュについては意識する必要はなく、コンテンツ更新時などに自動的にキャッシュはクリアされるようになります。

モジュール キャッシュ

モジュールの出力情報をキャッシュします。モジュールID化してキャッシュを設定した場合 や、Feed_ExListモジュールやJson_2Tplなどの外部アクセスが必要なモジュールでも利用されます。

一時的なキャッシュ

さまざまな情報をキャッシュします。例えばエントリーの情報や、プログラムの変数などをキャッシュしています。 特にキャッシュについて意識する必要はなく、コンテンツ更新時などに自動的にキャッシュはクリアされるようになります。

キャッシュのクリア方法

キャッシュのクリア方法について説明します。

ページキャッシュ以外のクリア方法

ページキャッシュ以外のキャッシュは 「ルートブログ」で「編集者以上」 のユーザーのみキャッシュのクリアが可能です。 ルートブログのダッシュボードで、クリアしたいキャッシュにチェックをつけて「キャッシュをクリア」ボタンを押してください。



ページキャッシュのクリア方法

ページキャッシュのクリアは「編集者以上」のユーザーが各ブログでキャッシュをクリアできるようになっております。
ダッシュボードで「ページキャッシュ」にチェックをつけて「キャッシュをクリア」ボタンを押してください。

各ブログでキャッシュクリアをすると、そのブログだけのキャッシュがクリアされるわけではなく、 各ブログのページキャッシュの設定によってクリア範囲が変わります。 詳しくは「ページキャッシュについて」をご確認ください。


テンプレートキャッシュについて

テンプレートキャッシュについて詳しくご紹介します。

テンプレートキャッシュを有効にする

「private/config.system.yaml」に以下の記述をすると機能が有効化されます。

template_cache: on

3系の「config.system.yaml」はデフォルトで、テンプレートキャッシュが有効になっています。よって2系からのアップデートの場合は、通常「config.system.yaml」を更新しないため、テンプレートキャッシュはオフの状態となっております。

また「DEBUG_MODE」時はテンプレートキャッシュが有効になりません。 テンプレートキャッシュを使いたい場合は「config.server.php」で「DEBUG_MODE」を「0」にしましょう。

define('DEBUG_MODE', 0);

テンプレートキャッシュが使える条件(制限事項)

テンプレートキャッシュを有効にすると、テンプレートの作り方に制限が設けられます。
具体的には、インクルード文の中に使用できるグローバル変数が限定されます。

<!-- 以下のようなインクルード文で使用するグローバル変数が限定されます。 -->

@include("/admin/entry/bcd/%{BCD}.html")

使用できるグローバル変数

  • %{ECD}
  • %{BCD}
  • %{PBCD}
  • %{RBCD}
  • %{CCD}
  • %{PCCD}
  • %{RCCD}
  • %{ALIAS_CODE}
  • %{IS_ADMIN}
  • %{MODULE_NAME}
  • %{MODULE_ID}
  • %{ADMIN_PATH}
  • %{ADMIN_PATH_MID}
  • %{CATEGORY_LEVEL}

以下のような 正規表現 で全文検索すると、インクルード文の中でグローバル変数を使っている箇所を検索できます。 (@include方式のみ)

@include\(['"][^'"]*%\{[^\}]+\}

テンプレートキャッシュが有効時は、テンプレートを編集しても反映されません。
開発環境では「DEBUG_MODE」をオンにしてキャッシュされないようにして作業し、本番環境では「DEBUG_MODE」をオフにしてテンプレートキャッシュを有効にするのがいいでしょう。

本番環境反映時には、ダッシュボードからテンプレートキャッシュのクリアを忘れないようにしましょう。

インクルード文で使用できるグローバル変数の追加

Ver. 3.1.0 でインクルード文で利用できるグローバル変数を追加できる仕組みが追加されました。(カスタムグローバル変数も可)

Hook.php」を修正することにより、インクルード文で使えるグローバル変数を追加します。

extension/acms/Hook.php の「addGlobalVarsInIncludePath」メソッド

/**
 * テンプレートキャッシュ有効時に、
 * インクルードのパスで使用できるグローバル変数を設定
 *
 * ページ毎に値が違うようなグローバル変数を設定しないでください。
 * 値別にキャッシュが作成されるので、値の種類が多いとキャッシュの意味がなくなります。
 *
 * @param array $globalVarNames
 */
public function addGlobalVarsInIncludePath(&$globalVarNames)
{
    $globalVarNames = ['SESSION_USER_AUTH', 'HOGE']; // 例)インクルード文に %{SESSION_USER_AUTH} と %{HOGE} を使えるようにする
}

上記のコードのように、配列の形でグローバル変数名を指定します。すでにあるグローバル変数や「Hook.php」で追加したカスタムグローバル変数でも指定可能です。

ページキャッシュについて

ページキャッシュについて詳しく紹介します。

ページキャッシュを有効にする

ページキャッシュを有効にするためには、いくつか条件があります。

  • DEBUG_MODEがオフであること
  • コンフィグ or コンフィグセットで キャッシュ設定がONであること
  • ログアウトしている時
  • 読者ユーザーがログインしている時(要設定)

コンフィグでページキャッシュを有効化

管理ページ > コンフィグ > キャッシュ機能 ページの「ページキャッシュ」にチェックをつけることで有効になります。



読者ユーザーでログイン中でもページキャッシュを有効化

通常ログインしているときはページキャッシュは有効化されませんが、読者ユーザーの場合はログインしていてもページキャッシュを有効化することができます。
たとえば、会員制サイトなどでログインしていても表示内容がそこまで変わらない場合に有用です。

有効化する方法

管理ページ > コンフィグ > キャッシュ設定 ページの「読者ユーザーの場合」にチェックをつけることで有効になります。


読者ユーザーでもキャッシュを有効化

読者ユーザーでもキャッシュを有効化

この機能を有効化すると、ログインしていてもページキャッシュが効いてしまいます。ログインしているユーザー固有の情報(マイページなど)や、 ログイン状況によって表示・非表示を切り替える箇所は、キャッシュしないように、マイページはキャッシュ設定をオフにしたり、JavaScriptで制御する対応が必要です。

ログイン状態に応じて表示・非表示を切り替える「組み込みJS」が用意されています。 ログイン状態に応じて表示・非表示を制御する

ページキャッシュ設定

ページキャッシュは、サイトの構造やサイトの更新頻度、アクセス数などによって、キャッシュの戦略が変わってきます。

設定箇所

ページキャッシュの設定は、管理ページ > コンフィグ > キャッシュ機能 で行います。
コンフィグなので、ブログ毎の設定または、コンフィグセットでの設定となります。



設定項目

ページキャッシュ

チェックをつけることにより、ページキャッシュ機能が有効化されます。

POST時のキャッシュクリア

チェックをつけることにより、エントリー保存した時やコンフィグ変更、モジュール変更などの更新系の操作(POST)をした時に、ページキャッシュをクリアをするようになります。
ただしエントリー詳細ページのキャッシュは、ここの設定にかかわらず、エントリー更新時に該当エントリーのキャッシュをクリアします。

キャッシュ有効時間

キャッシュの有効時間を秒数で設定します。この有効時間はエントリー詳細ページ以外のキャッシュ有効時間となります。

エントリーキャッシュ有効時間

エントリー詳細ページのキャッシュ有効時間を秒数で設定します。

キャッシュクリアの対象ブログ

このブログでキャッシュがクリアされた時に、他のブログのキャッシュもクリア対象にするか設定を行います。

実行ブログのみ : キャッシュクリアが実行されたブログのみのキャッシュをクリアします。

実行ブログと下階層のブログ : キャッシュクリアが実行されたブログと、そのブログの下階層ブログのキャッシュをクリアします。

実行ブログと親階層のブログ : キャッシュクリアが実行されたブログと、そのブログの親階層ブログのキャッシュをクリアします。

全ブログ : すべてのブログのキャッシュをクリアします。

サイト構造をみて対象となるブログを設定しましょう。たとえば設定ブログの情報が、そのブログのみで使われているのであれば「実行ブログのみ」で大丈夫です。
他には、設定ブログの情報が「ルートブログ」で利用されているのであれば「実行ブログと親階層のブログ」を選択しましょう。

クライアントキャッシュ設定

ブラウザに保存するキャッシュ有効時間を秒数で指定します。キャッシュヒット時はサーバーへのアクセスがないので、非常に高速にページ表示ができます。

クライアントキャッシュは、CMS側でクリアできないキャッシュとなります。有効時間が過ぎるか、エンドユーザーがブラウザのキャッシュを削除するしかありません。
なので、クライアントキャッシュに長い有効期限を設定するのはやめましょう。数分程度が推奨です。

キャッシュ戦略

ページキャッシュは設定項目も多いため、キャッシュ設定例を2つほど紹介します。

更新頻度が低い場合のページキャッシュ設定例

1週間に一回など更新頻度が少ないサイトであれば、キャッシュ有効時間を伸ばしPOST時にキャッシュをクリアするようにします。 更新頻度が少ないので、POST時のキャッシュクリアも頻繁に発生せず、キャッシュの有効時間も長いので、キャッシュヒット率もあがります。

  • ページキャッシュ: 有効
  • POST時のキャッシュクリア: 有効
  • キャッシュ有効時間: 2592000秒(30日間)
  • エントリーキャッシュ有効時間: 2592000秒(30日間)
  • キャッシュクリアの対象ブログ: サイト構成に沿って適切に設定
  • クライアントキャッシュ設定: 120秒

更新頻度が高く、アクセス数の多い場合のページキャッシュ設定例

更新頻度が高く、アクセス数の多いサイトの場合、POST時のキャッシュクリアはしないようにします。 更新頻度が高いので、その都度キャッシュをクリアしてしまうと、キャッシュのヒット率が下がってしまうからです。

またキャッシュクリアをPOST時にしてしまうと、キャッシュが一気に消え、瞬間的にキャッシュヒット率が極端に下がり、サーバーの負荷も上がってしまいます。 そこでキャッシュの有効時間を短くし、キャッシュの有効時間でばらばらにキャッシュがクリアしていくようにしています。

ただしエントリーのキャッシュ時間は長くし、エントリー更新時のみキャッシュがクリアされるようにしています。
注意点はエントリー詳細ページにエントリー情報以外の情報があると、その情報が更新されないので、JavaScriptなどでひっぱってくるなどの対応が必要です。

  • ページキャッシュ: 有効
  • POST時のキャッシュクリア: 無効
  • キャッシュ有効時間: 300秒(5分間)
  • エントリーキャッシュ有効時間: 2592000秒(30日間)
  • キャッシュクリアの対象ブログ: サイト構成に沿って適切に設定
  • クライアントキャッシュ設定: 120秒