エントリー編集機能の改善 - Ver. 3.1.0 リリース情報


この記事では、2023年09月14日にリリースされた「Ver. 3.1.0」の「エントリー編集機能」の新機能・改善点について紹介しています。

大きい変更として、WYSIWYGエディタが「CKEditor」から「Trumbowyg」に変更されました。またバージョン管理を使いやすいように仕様変更し、プロフェッショナル版以上でエントリーの排他制御機能(編集ロック)が追加されました。

新機能・改善点一覧

  • CMS-6379 wysiwygエディタを「CKEditor」から「Trumbowyg」に変更
  • CMS-6126 エントリーの排他制御機能(編集ロック機能)を追加(プロフェッショナルライセンス以上)
  • CMS-6308 バージョン管理機能で、バージョンを上書き出来るように改善
  • CMS-6136 バージョン管理でバージョンの公開予約機能を追加

CMS-6379 wysiwygエディタを「CKEditor」から「Trumbowyg」に変更

WYSIWYGエディタが「CKEditor」から「Trumbowyg」に変更されました。UIが変わってしまい申し訳ございませんが、機能としてはほぼ同じことが出来るようになっておりますのでご安心ください。

Trumbowyg 公式ページ


新しいWYSIWYGエディタ

新しいWYSIWYGエディタ


通常テキストユニットのプルダウンメニューで「WYSIWYG」を選択すると、入力フィールドが「Trumbowyg」に切り替わりますが、今までと同様カスタムフィールドなどのカスタマイズした入力欄にもWYSIWYGを適応できるようになっております。

任意の入力フィールドを「Trumbowyg」にする

HTMLの書き方

以下のようにクラスに「js-wysiwyg」を設定すると、設定された「textarea」が「Trumbowyg」による編集欄になります。

<textarea name="textarea" class="js-wysiwyg"></textarea>

* デフォルトでは、互換性を保つため今まで指定していた「js-ckeditor」でも発火するようになっています。詳しくは以下設定をご覧ください。

設定方法

config.js で設定を変更することができます。

wysiwygMark: 'textarea.js-wysiwyg,textarea.js-ckeditor,textarea.js-emoditor', // 発火するクラス名を指定します
wysiwygConfig:
{
  lang: 'ja', // 言語を指定します
  // resetCss: true, // 「true」で、trumbowygのリセットCSSを適応します
  autogrow: true, //「true」で、編集欄の高さを入力内容によって自動で大きくします
  tagsToRemove: ['script'], // sciriptタグを入力できないようにします
  btns: [ // エディタのボタン設定
    ['viewHTML'], // HTMLを表示します
    ['undo', 'redo'], // 一つ戻る、一つ進む
    ['formatting'], // 段落、見出しなどのフォーマット
    ['fontsize'], // フォントサイズ
    ['lineheight'], // ラインハイト
    ['strong', 'em', 'del'], // <strong>, <em>, <del> タグ
    // ['superscript', 'subscript'], // 上付き文字、下付き文字
    ['foreColor', 'backColor'], // 文字色、背景色
    ['link'], // リンク挿入
    ['justifyLeft', 'justifyCenter', 'justifyRight'], // 左寄せ、中央寄せ、右寄せ
    ['unorderedList', 'orderedList'], // リスト、番号リスト
    ['horizontalRule'], // 水平方向の罫線
    ['table', 'tableCellBackgroundColor', 'tableBorderColor'], // テーブル、テーブルのセルカラー、テーブルのボーダーカラー
    ['removeformat'], // スタイルを削除
    ['fullscreen'], // フルスクリーン
  ],
  tagClasses: {
    // table: 'class-name', // テーブルのクラス名
  },
},

設定を変更する時は「js/config.js」を直接上書きすのではなく、各テンプレートで以下のように変更ください。

<script>
ACMS.Ready(function() {
    ACMS.Config.autogrow  = false;
});
</script>

参考 - 組み込みJSの設定を変更する

CMS-6126 エントリーの排他制御機能(編集ロック機能)を追加(プロフェッショナルライセンス以上)

プロフェッショナル版以上で、エントリーにロックがかけれるようになりました。これにより意図しないエントリーの上書きでのデータ消失のリスクが減ります。

動作の流れ

エントリーを編集していて、保存ボタンを押すまでは、編集中のエントリーにロックが自動でかかります

ロック中は、以下のスクリーンショットのように、エントリー一覧からロックがかかっていることが分かるようになっています。 自分がロックしている場合と、他のユーザーがロックしている場合で、違うアイコンが表示されるようになっています。


他のユーザーがロックしている場合の表示

他のユーザーがロックしている場合の表示


自分がロックしている場合の表示

自分がロックしている場合の表示


自分ではない他のユーザーが、編集中(ロック中)のエントリーの編集画面を開くと、以下のようなスクリーンショットが表示され、ロックしているユーザーや編集日時がわかるようになっています。


ロック中に表示されるアラート

ロック中に表示されるアラート


アラートを閉じれば、この状態でもエントリーの編集は可能になっておりますが、保存をすると以下スクリーンショットのエラーが出て保存できないようになっています。ではなぜ編集できるようになっているかというと、違うバージョンでの保存はロックがかかっていても保存はできるためになります。


ロック中のエントリーを保存した時のアラート

ロック中のエントリーを保存した時のアラート


エントリーの編集中に編集をやめページを離脱した場合はロックが残ってしまいます。このような時は、再度エントリー編集ページを開いて保存をするか、以下スクリーンショットにあるようにエントリー一覧から、ロックアイコンをクリックするこで、ロックを解除することが出来ます。


ロックの解除

ロックの解除


コンフィグ設定

管理ページ > コンフィグ > 機能設定に「エントリー同時編集ロック」のコンフィグがあります。

  • 同時編集ロック機能:チェックをつけると機能が有効になり、外すと機能が無効になります。
  • アラートのみ:チェックをつけると、ロックされている事のアラートは表示されますが、アラートを無視して保存できるようになります
  • ロック有効期限:ロックの有効期限を設定します。この期間を過ぎたロックは自動的に解除されます。

エントリー同時編集ロックのコンフィグ

エントリー同時編集ロックのコンフィグ


CMS-6308 バージョン管理機能で、バージョンを上書き出来るように改善

いままでのバージョン管理では一度作成されたバージョンを変更することはできなかったのですが、Ver. 3.1 では、バージョンを上書きできるようになりました。

改善の経緯

バージョン管理機能は、承認機能と密接に関わっている機能になります。多段階の承認で、最初の承認がされた後に、バージョンを上書きできてしまうと、承認後の変更になるので、承認の意味がなくなってしまうという考えで、バージョンの上書きはできないようになっておりました。

ただ承認機能ができてからしばらくの期間を経て、記事公開まで何度も承認・修正を繰り返すことが多く、この仕様だと運用が大変になるという結論となりました。 今回バージョンを上書き出来るようになり、多段階認証で承認後でも記事の編集が出来るようになりましたが、承認画面でコメントを残してやり取りができ、最終的には最後の承認を通らないと記事は公開されないので、承認機能としての役割は十分果たしていると思います。

また承認機能を利用されない方が一般的だと思います。バージョンを上書きできることで、あらかじめ更新予定の記事をバージョンで作成しておくこともより便利になったと思います。

バージョン保存ボタン

Ver. 3.1 では、バージョンを表示中「このバージョンを保存」と「新規バージョンとして保存」の2つになりシンプルでわかりやすくなりました。


今までのバージョン保存

今までのバージョン保存


新しくなったバージョン保存

新しくなったバージョン保存



CMS-6136 バージョン管理でバージョンの公開予約機能を追加

いままでの機能だと、新規記事を公開予約することは出来たのですが、記事更新を公開予約する機能はありませんでした。*1
なので更新内容をバージョンとして作成していても、切り替えるには手動でバージョンを切り替える必要がありました。

そこで、Ver. 3.1 ではバージョンの公開予約機能を追加し、記事の更新でも時間を指定してバージョンが切り替わる仕組みを用意しました。

*1 正確には、エントリーコードが同じエントリーを2つ用意して、公開日時と掲載期間を切り替え日時に合わせれば可能でしたが、公開予約のたびにエントリーを増やさないといけませんでした

公開済みのエントリーで、更新内容を公開予約する手順

1. バージョンを切り替えたい日時を「公開日時」に設定します


公開日時を設定

公開日時を設定


2. 公開日時に設定と編集ができたら「新規バージョン」として保存します


新規バージョンとして保存

新規バージョンとして保存


3. さらに編集したい場合は「このバージョンを」を選択して保存します(何度もOK)


このバージョンを保存

このバージョンを保存


4. 編集が完了したら編集したバージョンの確認をします


バージョン管理ボタンを押して、バージョン一覧を表示

バージョン管理ボタンを押して、バージョン一覧を表示


バージョン一覧から編集したバージョンの確認ボタンを押す

バージョン一覧から編集したバージョンの確認ボタンを押す


5. 「このバージョンを公開予約」ボタンを押して公開予約する


公開予約の実行

公開予約の実行


以上、エントリー更新の公開予約手順でした。予定している時間になると、自動的にバージョンが切り替わり記事の更新が完了します。

また公開予約が完了すると、ダッシュボードの「公開/掲載終了予定の記事」にエントリーが出現します。キャッシュもバージョン切り替え時に自動的にクリアするので、キャッシュの時間設定は気にしなくても問題ありません。


公開/掲載終了予定の記事

公開/掲載終了予定の記事


エントリーの編集機能の改善紹介については以上になります。他 Ver. 3.1.0 の新機能・改善も多くありますので、ぜひご覧ください。

日々使いやすいシステムとなるよう改善を勤めておりますので、皆様からの貴重なフィードバック、お待ちしております。
今後とも a-blog cms のことをどうぞよろしくお願いいたします。

監査ログ機能 - Ver. 3.1.0 リリース情報


この記事では、2023年09月14日にリリースされた「Ver. 3.1.0」の「監査ログ」機能について紹介しています。

CMSで操作された内容や、CMSで発生したエラーがログとして残り管理画面から確認できるようになりました。 操作した人や、URL、HTTPヘッダーや、送信内容などログ毎に細かく情報が取れますので、何か問題が起きた時の調査に役立ちます。

* 操作ログはプロフェッショナルライセンス以上になりますが、何かしらエラーが起きた場合のログは、スタンダード版でも確認できるようになっております。

ログ確認画面

管理者でルートブログの管理ページにアクセスすると、右側メニューに「監査ログ」があります。クリックすると監査ログページにアクセスできます。

監査ログ画面では、ログの一覧が確認でき、ユーザーや期間、ログレベルで絞り込みが行えるようになっています。


監査ログ画面

監査ログ画面


詳細な情報を確認したい場合は、確認したいログの「詳細」ボタンを押すことで確認できます。 この画面では様々な情報が確認でき、右上の「クリップボードにコピー」ボタンを押すことで「JSONデータ」としてコピーすることができます。サポートを受ける際にも非常に有効な手段ですので、ぜひご利用ください。


ログの詳細情報

ログの詳細情報


ログレベル

ログのレベルは全部で以下のものがあります。「INFO(情報)」については、プロフェッショナルライセンス以上でのみ記録されるようになります。ユーザーの操作履歴を残したい場合は、プロフェッショナルライセンス以上をご検討ください。



ログレベル 説明 スタンダード プロ以上
DEBUG(デバッグ) デバッグ情報
INFO(情報) エラーではない正常の操作を記憶します
NOTICE(注意) 特にプログラムを修正する必要はないが、不正操作・不正アクセス(CSRFチェック、アカウントロック時)など
WARNING(警告) 潜在的な問題。不具合や環境に問題がある可能性があるエラーなど
ERROR(エラー) データが壊れているなど、不具合や環境に問題がある可能性があるエラー。処理が継続できない場合など
CRITICAL(重大) 一部機能が使用不能・表示不能になったなどの、ある程度影響範囲が大きいエラーが起きた場合など
ALERT(警報) データベースに接続できないなど、サイトが表示できない状態で緊急で対応が必要な場合など
EMERGENCY(緊急) サイトが表示できない状態。基本的には使用していません。

通知機能とファイルへの保存

エラーが発生した際、問題にすぐに気がつけるように監査ログ機能には通知機能がついており、設定したログレベル以上のログが発生すると、メールで通知してくれます。 また、データベースにログは保存しているのですが、ファイルにも書き出すことが出来るようになっております。

設定方法

a-blog cms設置ディレクトリにある「.envファイル」で設定を行います。

# エラー通知
ALERT_EMAIL_FROM=info@example.com # エラー通知メールの送信元
ALERT_EMAIL_TO= # エラー通知メールの送信先。空の場合「UID」が一番小さい管理者アカウントのメールアドレスに送信します。
ALERT_EMAIL_BCC= # カンマ区切りで指定
ALERT_REPORTING_LEVEL=WARNING # エラー通知をする最低ログレベルを設定します。(DEBUG|INFO|NOTICE|WARNING|ERROR|CRITICAL|ALERT)

# ロガー
LOGGER_ROTATING_MAX_FILES=60 # ログローテーションの日数を設定します。
LOGGER_MODE=development # (development|production) productionに設定すると、ライセンス切れやデバッグモード時なども、ログとして残します


設定項目 説明 デフォルト値
ALERT_EMAIL_FROM エラー通知メールの送信元 info@example.com
ALERT_EMAIL_TO エラー通知メールの送信先。空の場合「UID」が一番小さい管理者アカウントのメールアドレスに送信します
ALERT_EMAIL_BCC エラー通知メールのBCC
ALERT_REPORTING_LEVEL エラー通知をする最低ログレベルを設定します WARNING
LOGGER_ROTATING_MAX_FILES ログローテーションの日数を設定します 60
LOGGER_MODE productionに設定すると、ライセンス切れやデバッグモード時なども、ログとして残します development

LOGGER_MODEはデフォルトだと「development」になっています。この状態だと、ライセンスに問題があった場合などログが残らず通知もしてくれないので、本番環境では必ず「production」に設定しましょう。

開発者向け

専用モジュールやHookなどを使用して、PHPをカスタマイズしている方もいると思います。 そんな方には、以下の方法を使うことで自分のプログラムにログを追加できるようになります。

基本的な使い方

  • 保存したいログレベルのメソッドを呼び出す
  • 第1引数: メッセージ文字列
  • 第2引数: 保存したい情報(連想配列)
AcmsLogger::[ログレベル](string $message, array $info);

// 例
AcmsLogger::info('xxxを作成しました', [
  'hoge' => 'abc',
  'hoge2' => 200,
]);

use して使う場合

use Acms\Services\Facades\Logger;

Logger::info('xxxx');

コード例

メッセージだけ指定

\ AcmsLogger::critical('重大な問題により動作を停止しました');

例外をログとして残す

「Common::exceptionArray()」を第2引数に指定すると、例外の詳細な情報を渡してくれます。

try {
...
} catch ( \Exception $e ) {
    \AcmsLogger::warning($e->getMessage(), \Common::exceptionArray($e));
}

このログは通常のログと同じように表示や通知などに利用できますので、PHPでカスタマイズを行っている方はぜひお試しください。

監査ログ機能の紹介については以上になります。他 Ver. 3.1.0 の新機能・改善も多くありますので、ぜひご覧ください。

日々使いやすいシステムとなるよう改善を勤めておりますので、皆様からの貴重なフィードバック、お待ちしております。
今後とも a-blog cms のことをどうぞよろしくお願いいたします。

キャッシュ機能の改善 & Webhook機能の改善 - Ver. 3.1.0 リリース情報


この記事では、2023年09月14日にリリースされた「Ver. 3.1.0」の「キャッシュ機能」「Webhook機能」の改善点について紹介しています。

新機能・改善点一覧

  • CMS-6480 キャッシュドライバーにデータベースを追加しデフォルトドライバーをデータベースに変更
  • CMS-6448 webhook に「ユーザー」タイプを追加

CMS-6480 キャッシュドライバーにデータベースを追加しデフォルトドライバーをデータベースに変更

「Ver. 3.0.0」で、キャッシュ機能が大幅にアップデートされ、複数のキャッシュドライバーから、環境に合わせて好きなキャッシュ方法を選択できるようになりました。

Ver. 3.0 にあったキャッシュドライバー

  • file: ファイル キャッシュドライバー
  • php: PHPファイル キャッシュドライバー
  • memory: メモリー キャッシュドライバー
  • apcu: APCuキャッシュドライバー
  • redis: Redis キャッシュドライバー

「Ver. 3.1.0」では、上記のドライバーに加え、「データベース」キャッシュドライバーを追加いたしました。このドライバーを選択すると、キャッシュをデータベースに保存するようになります。

追加意図

レンタルサーバー環境だと「APCu」や「Redis」のキャッシュドライバーが利用できない事が多く、デフォルトでもある「file」キャッシュドライバーを利用されている方も多いと思います。 ただディスクアクセスが遅い環境だと、キャッシュのパフォーマンスがあまり出ないため、今回メモリ上に乗るためアクセス速度が基本的には速い「データベース」を追加いたしました。

またもう1つの理由として、データベースキャッシュを利用することにより、複数台構成のときに、同じキャッシュを利用できる為になります。いままでは複数台構成でキャッシュを統一するには「Redis」を利用するしかなかったのですが、少し導入ハードルが高く設定しずらい状況でした。

各キャッシュのデフォルト値

今回「Ver. 3.1」で各キャッシュのキャッシュドライバーのデフォルト値を変更しています。基本的にはこのままで問題ありませんが、よりキャッシュのパフォーマンスをあげたい場合は、「Redis」や「APCu」をご検討ください。

変更前の Ver. 3.0 の設定値

テンプレートキャッシュ: file
フィールドキャッシュ: file
モジュールキャッシュ: file
一時キャッシュ: memory
コンフィグキャッシュ: file
ページキャッシュ: file

変更後の Ver. 3.1 の設定値

テンプレートキャッシュ: file
フィールドキャッシュ: database
モジュールキャッシュ: database
一時キャッシュ: memory
コンフィグキャッシュ: database
ページキャッシュ: database

キャッシュドライバーのマニュアルを見る

CMS-6448 webhook に「ユーザー」タイプを追加

今回、Webhookのタイプに「ユーザー」タイプを追加しました。これにより、会員サイトなどで新規会員登録された時や更新、退会時にフックをすることが出来るようになりました。


イベントの種類



イベント 説明
ユーザー作成 管理画面でユーザーを作成した時、発火します。
会員登録 管理画面で管理者がユーザー追加した時ではなく、会員登録機能で表から会員登録した場合に発火します。
ユーザー更新 ユーザー情報更新時に発火します。管理画面、会員機能による更新は関係ありません。
ユーザー削除 管理画面でユーザーを削除した時、発火します。
ユーザー退会 会員機能で、ユーザーが退会処理をした時、発火します。
ユーザーログイン 権限関係なく、ログイン・サインインしたとき、発火します。

ログとしてチャットツールに通知したり、外部のサービス(例えばCRMなど)とデータ連携したり、いろいろ出来る幅が広がると思います。ぜひご活用ください。

Webhookのマニュアルを見る

「キャッシュ機能」「Webhook機能」の改善紹介については以上になります。他 Ver. 3.1.0 の新機能・改善も多くありますので、ぜひご覧ください。

日々使いやすいシステムとなるよう改善を勤めておりますので、皆様からの貴重なフィードバック、お待ちしております。
今後とも a-blog cms のことをどうぞよろしくお願いいたします。

テンプレート機能の改善 - Ver. 3.1.0 リリース情報


この記事では、2023年09月14日にリリースされた「Ver. 3.1.0」の「テンプレート機能」の新機能・改善点について紹介しています。

新機能・改善点一覧

  • CMS-6462 インクルード文で使えるグローバル変数を追加できるHook(addGlobalVarsInIncludePath)を追加
  • CMS-6471 インクルード文に使用できるグローバル変数に「%{CATEGORY_LEVEL}」を追加

CMS-6462 インクルード文で使えるグローバル変数を追加できるHook(addGlobalVarsInIncludePath)を追加

「Ver. 3.0」よりテンプレートキャッシュ機能が追加され、テンプレートキャッシュが利用できるようになりました。 ただテンプレートキャッシュ有効時(デフォルト有効)の制限として、インクルード文内で利用できる「グローバル変数」に制限がありました。

テンプレートキャッシュのマニュアル

インクルード文にグローバル変数を含める例

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

このインクルード文で使用できるグローバル変数は固定になっており、他のグローバル変数や、カスタムグローバル変数をインクルードで利用できず、不便な場合が多々ありました。 そこで、Ver. 3.1 では、インクルード文で利用できるグローバル変数を追加できる仕組みを用意しました。(カスタムグローバル変数もOKです)

インクルード文で使えるグローバル変数の追加方法

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

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

public function addGlobalVarsInIncludePath(&$globalVarNames)
{
    $globalVarNames = ['SESSION_USER_AUTH', 'HOGE']; // 例)インクルード文に %{SESSION_USER_AUTH} と %{HOGE} を使えるようにする
}

上記の例のように、配列の形でグローバル変数名を指定します。すでにあるグローバル変数は、Hook.php で追加したカスタムグローバル変数でも大丈夫です。

注意事項

上記の方法で、インクルード文に使用できるグローバル変数を追加することができますが、注意する点があります。 グローバル変数の値ごとにテンプレートキャッシュを生成するので、ページ毎に値が違うような値の種類が多いグローバル変数を設定してしまうと、大量のテンプレートキャッシュが生成されることになり、キャッシュの意味がなくなってしまう可能性があります。ここで追加するグローバル変数は、とりうる値の数が少ないグローバル変数にしてください。

CMS-6471 インクルード文に使用できるグローバル変数に「%{CATEGORY_LEVEL}」を追加

「Ver. 3.1」でインクルード文に使用できるグローバル変数を拡張できるようになりましたが、「%{CATEGORY_LEVEL}」はデフォルトで使用できるようにいたしました。

デフォルトで使用できるグローバル変数

%{ECD}
%{BCD}
%{PBCD}
%{RBCD}
%{CCD}
%{PCCD}
%{RCCD}
%{ALIAS_CODE}
%{IS_ADMIN}
%{MODULE_NAME}
%{MODULE_ID}
%{ADMIN_PATH}
%{ADMIN_PATH_MID}
%{CATEGORY_LEVEL} // Ver. 3.1 で追加

テンプレート機能の紹介については以上になります。他 Ver. 3.1.0 の新機能・改善も多くありますので、ぜひご覧ください。

日々使いやすいシステムとなるよう改善を勤めておりますので、皆様からの貴重なフィードバック、お待ちしております。
今後とも a-blog cms のことをどうぞよろしくお願いいたします。

管理機能の改善 - Ver. 3.1.0 リリース情報


この記事では、2023年09月14日にリリースされた「Ver. 3.1.0」の管理機能の新機能・改善点について紹介しています。

開発・運用で便利になる変更が多くさせております。Ver. 3.1 の管理機能の変更点について学びましょう。

新機能・改善点一覧

  • CMS-6458 コンフィグセットに加えて、テーマセットと編集画面セットを追加 & グローバルオプションを追加
  • CMS-6123 ライセンス切れ時にもキャッシュが効くように改良 & デバッグモードとベンチマークモードをユーザー詳細ページでユーザーごとに設定できるように改修(管理者のみ)
  • CMS-6135 同一ブログ内でのカテゴリーコードの重複許可オプション(category_order_strict_mode)を追加(新規インストール時デフォルトON)
  • CMS-6130 メディア編集画面でファイル名を変更する機能を追加
  • CMS-6188 エイリアス機能を管理画面でも有効になるように改修
  • CMS-6194 登録ドメイン以外でもサイトが表示できるように仕様変更(ライセンスと違うドメインの場合はnoindexとなる)
  • CMS-6215 WordPressのXMLインポートで、サムネイル画像URLをインポートできるように改善
  • CMS-6131 メディアでアップロードしたファイルのリンクに拡張子を含めるように変更
  • CMS-6322 フォームの添付ファイルの削除されるまでの時間をオプション化 & 添付ファイルの即時削除をしないオプションを追加
  • CMS-6124 ショートカット機能の編集権限及び投稿者権限で「条件設定」と「カスタム設定」の項目を編集できるように改良
  • CMS-6482 ショートカット機能のコンフィグセット対応
  • CMS-6483 ショートカット機能で複数種類のID(モジュールID × ルールIDなど)の掛け合わせに対応

CMS-6458 コンフィグセットに加えて、テーマセットと編集画面セットを追加 & グローバルオプションを追加

大きな機能変更ではありませんが、サイト制作において大きく恩恵がある機能になります。コンフィグセット機能はいままでもあった機能ですが、コンフィグセットでコンフィグを統一してもコンテンツ毎にテーマや編集画面は変わることが多いため、コンフィグセットが利用しずらい状況でした。

またコンフィグセットでベースのコンフィグを統一して、テーマや編集画面はルール機能を使って、別のコンフィグを当てる方法がありましたが、ルール機能を使うとどのようなコンフィグが当たっているか分かりづらく設定が複雑になる傾向があります。

そこで、Ver. 3.1 ではコンフィグセットの設定内容を「コンフィグセット」「テーマセット」「編集画面セット」の3つに分割するようにしました。


コンフィグセット

コンフィグセット


テーマセット

テーマセット


編集画面セット

編集画面セット


作成したコンフィグセット、テーマセット、編集画面セットは、ブログ・カテゴリーにセットできるようになっております。

これにより、コンフィグセットは、サイト全体で共通のコンフィグセットを使用し、テーマだけブログ毎に別のテーマを当てるなどが簡単に出来るようになりました。 また編集画面もコンテンツ毎に変更することが多いので、編集画面もブログとカテゴリー毎に用意している編集画面セットを別々に設定でき便利になります。


ブログの設定画面

ブログの設定画面


カテゴリーの編集画面

カテゴリーの編集画面


コンフィグセットの継承機能

さらに便利な機能として各セットを子ブログ、子カテゴリーにも継承できるようになりました。

ブログ・カテゴリーの編集画面で「子ブログ(カテゴリー)にも継承する」チェックボックスにチェックをつけることで、チェックをつけたセットが子ブログ(カテゴリー)にも反映されます。

* 子ブログ(カテゴリー)ではセットが選択されていない必要があります。子ブログ(カテゴリー)でセットが選択されている場合は、そのセットが適応されます



具体的な例で見ていきましょう。

例えば、通常のサイトであれば、テーマ設定や編集画面はブログ、カテゴリー毎に変更する事は多いですが、基本的な設定であるキャッシュ設定や機能設定、アクセス設定などはサイト全体を通して、共通のコンフィグで問題ない場合は多くあります。

このような時、ルートブログでコンフィグセットを選択し、子ブログにも継承するようにする事で、サイト全体のコンフィグをコンフィグセット1つで管理することが出来るようになります。 BASIC認証の設定などブログ毎に設定するのが大変だったと思いますが、1つ設定すればいいので、開発・運用がぐっと楽になります。

CMS-6123 ライセンス切れ時にもキャッシュが効くように改良 & デバッグモードとベンチマークモードをユーザー詳細ページでユーザーごとに設定できるように改修(管理者のみ)

ライセンス切れ時にもキャッシュが効くように改良

いままではライセンスが正式ライセンスではない場合、キャッシュ機能が利用できない状態でしたが、Ver. 3.1 で正式ライランスが当たってない状況でも、キャッシュが利用できるようにいたしました。

変更意図

変更意図として、出来るだけ本番運用時と開発時の差分を少なくしたかっためです。開発環境では問題なかったのに、キャッシュの問題で本番環境でうまく動作しないなどの可能性があるため、出来るだけ開発環境と本番環境で同一の動作をするようにいたしました。

* 正式ライセンスでない場合「noindex」になるのは、引き続き同じ動作となります。

デバッグモードとベンチマークモードをユーザー詳細ページでユーザーごとに設定できるように改修(管理者のみ)

いままでサイトの調査をするときに、config.server.php を編集してデバッグモードやベンチマークモードに変更していました。ただこのやり方だと、全ユーザーに影響が出て、変更忘れなどあった場合に、影響が続いてしまいます。

そこでVer. 3.1では、管理ユーザーの場合のみ、ユーザー編集画面で、そのユーザー限定でデバッグモードとベンチマークモードになることが出来るオプションを用意しました。これにより、気軽にデバッグモードやベンチマークモードを試せるようになりました。


ユーザー編集画面でモード設定

ユーザー編集画面でモード設定


またこの機能変更に合わせて、config.server.phpの「DEBUG_MODE」はデフォルトオフ(0)に変更いたしました。DEBUG_MODEの変更忘れを防ぐためになります。

CMS-6135 同一ブログ内でのカテゴリーコードの重複許可オプション(category_order_strict_mode)を追加(新規インストール時デフォルトON)

いままで同一ブログ内でのカテゴリーコードは重複できない仕様でした。例えば以下のような構造は設定できませんでした。

news(全体のお知らせ)
products(製品情報)
┗ news(製品のお知らせ)
recruit(採用情報)
┗ news(採用情報のお知らせ)

ブログを分ければ、同じカテゴリーコードを利用できたのですが、この制限が理由でブログを分ける必要がなくなったので、よりカテゴリーが利用しやすくなったと思います。

重複許可のオプション設定

この設定は新規インストール時はデフォルトで有効になっていますが、アップデートの場合は無効になっております。というのも以前の仕様だと動作に不具合が起きる可能性があるためです。

設定箇所は「private/config.system.yaml」で行います。

category_order_strict_mode: on # on | off カテゴリー親子関係を厳密に指定したURLでないと404になるモード。onだと同ブログ内でも同じ階層でなければ同名のカテゴリーコードを設定可能

CMS-6130 メディア編集画面でファイル名を変更する機能を追加

いままでは、メディア機能でアップロードした画像やファイルのファイル名を後から変更することができませんでしたが、今回変更できるようになりました。メディアの編集画面で編集できます。


メディアの編集画面

メディアの編集画面


CMS-6131 メディアでアップロードしたファイルのリンクに拡張子を含めるように変更

メディア(ファイル)のパーマリンクURLの仕様を変更いたしました。URLの最後にファイルの拡張子が入るようになりました。これでURLからどのようなファイルか判定できるようになります。

今までのURL

https://example.com/media-download/xx/xxxxxxxxxx/

変更されたURL

https://example.com/media-download/xx/xxxxxxxxxx/PDF/

古い仕様のURLでも問題なくアクセスできます。互換性はありますので安心して利用ください

CMS-6188 エイリアス機能を管理画面でも有効になるように改修

少しマニアックな機能ですが、ドメイン拡張ライセンスを入れて、エイリアス機能で別のドメインを設定している場合があります。

例えば、example.comというサイトがあり、en.example.com や zh.example.com のようにエイリアスで多言語対応をしている場合です。 この時今までの仕様だと各ドメインで管理ページにアクセスはできず、管理ページは基本となる1つのドメインでしかアクセスできない状況でした。(リダイレクトされる)

この仕様により、勝手にドメインが変わるので、混乱の元になり、またドメインが変わるので、セッションが切れやすい状況になっていました。

この仕様をVer. 3.1 で変更し、今閲覧しているドメインのまま管理ページにアクセス出来るようになりました。

CMS-6194 登録ドメイン以外でもサイトが表示できるように仕様変更(ライセンスと違うドメインの場合はnoindexとなる)

いままでは、ブログで設定されたドメインまたは、拡張ライセンスで追加されたドメイン以外でサイトにアクセスするとサイトは表示できませんでした。このように制限が厳しい状態だと、サイト切り替え時など不便なことが多いので、ブログで設定されていないドメインでも a-blog cms が設置されているドキュメントルートへアクセスされるURLであれば、サイトは表示するように修正しました。

具体的な例でみると、例えばサイトリニューアルでDNSを変更してサイトを公開する場合、CMSのドメインを本番用ドメインにしたあとだと、各閲覧環境でhostsファイルを書き替えないとサイトが閲覧できない状況になっていたと思います。これが新しいサーバーの仮ドメインやIPアドレスでもサイトが閲覧できるようになったので、hostsファイルの変更が要らず共有しやすくなったと思います。(サーバー環境によってはhostsファイルを変更しないと見れない場合もあります)

他の例だと、開発環境でローカル環境と社内サーバーでデータベースを共通化している場合などに、ドメインが別々になっていると思います。このような時もどちらかが見えなくなってしまうことなく、両環境でサイトを閲覧することができるようになります。

注意点としてサイトは閲覧できますが、ライセンスと違うドメインの場合はnoindexとなります

CMS-6215 WordPressのXMLインポートで、サムネイル画像URLをインポートできるように改善

以前からWordPressのエクスポートデータのインポート機能はあり、エントリーとして記事が作成できましたが、一覧でインポートした時サムネイル画像が表示できず、サムネイル画像は手動で登録するなど、実用面で問題がありました。

そこで今回、WordPressのメディアエクスポートデータからアイキャッチ画像URLをカスタムフォールドにインポートする機能を追加いたしました。

注意ポイント

注意点として、必ず投稿データのインポートを行った後、アイキャッチ画像URLのインポートを行うようにしてください。


WordPressデータのインポート画面

WordPressデータのインポート画面


CMS-6322 フォームの添付ファイルの削除されるまでの時間をオプション化 & 添付ファイルの即時削除をしないオプションを追加

フォーム機能で添付ファイルをする機能があります。こちらはフォーム入力でアップロードした後、フォーム送信が完了すると自動的にサーバーから削除するのですが、フォームを離脱してしまうと、ファイルがサーバーに残ってしまいます。そこでアップロードから30分たったファイルは自動的に削除するようになっていました。

今回この自動削除の機能をオプション化して値を設定できるようにしました。設定は「private/config.system.yaml」で行います。

form_attached_file_delete_immediately: on # on | off フォーム送信後(メール送信後)に即時に添付ファイルをサーバー上から削除するか設定します
form_attached_file_lifetime: 1800 # フォームの添付ファイルをサーバー上に残しておく秒数

特にこの設定はデフォルトで問題ありませんが、何か特別な処理をしたい場合などにご活用ください。

CMS-6124 ショートカット機能の編集権限及び投稿者権限で「条件設定」と「カスタム設定」の項目を編集できるように改良

Ver. 3.1 では、ショートカット機能で「編集者」権限及び「投稿者」権限にモジュールIDの編集権限を与えた場合でも「条件設定」や「カスタム設定」の設定項目を編集できるようになりました。

特に、「カスタム設定」の項目の編集ができるようになることで、「管理者」権限は与えたくないが、「編集者」権限や「投稿者」権限でも編集できるようにしたいデータについては、モジュールのカスタムフィールドとして制作するといった選択ができるようになりました。

Ver. 3.1 以降のバージョンで作成したモジュールIDのショートカットのみ「条件設定」と「カスタム設定」の設定項目を「編集者」権限や「投稿者」権限で編集できるようになります。
Ver. 3.1 未満のバージョンで作成したモジュールIDのショートカットは管理者のみ「条件設定」と「カスタム設定」の設定項目のみ編集できる仕様となりますので、ご注意ください。


管理画面 > ダッシュボードにあるショートカット一覧

管理画面 > ダッシュボードにあるショートカット一覧


CMS-6482 ショートカット機能のコンフィグセット対応

Ver. 3.1 からコンフィグセットに紐付けられたコンフィグのショートカットを作成できるようになりました。

Ver. 3.1 未満のバージョンではコンフィグセットのページからショートカットを追加した場合、「このブログの初期コンフィグ」へのショートカットとなる仕様でした。
しかし、コンフィグセットを利用している場合、ショートカットが利用できないことになってしまうため、Ver. 3.1 ではコンフィグセット紐付けられたコンフィグのショートカットも作成できるように改善いたしました。

これにより、コンフィグセットを利用しているサイトでもよく設定するコンフィグをショートカットに登録できるようになり、より便利にサイトを運用することができるようになったのではないでしょうか?

CMS-6483 ショートカット機能で複数種類のID(モジュールID × ルールIDなど)の掛け合わせに対応

Ver. 3.1 からはモジュールID、ルールID、コンフィグセットIDを掛け合わせた編集ページをショートカットに登録することができます。

具体的には以下のケースに対応可能です。

  • 特定のルール下でのモジュール編集ページ
  • 特定のルール下でのコンフィグ編集ページ

ルールをご利用のサイトの場合、運用者にってより更新しやすい管理画面を提供可能になりました。

管理機能改善の紹介については以上になります。他 Ver. 3.1.0 の新機能・改善も多くありますので、ぜひご覧ください。

日々使いやすいシステムとなるよう改善を勤めておりますので、皆様からの貴重なフィードバック、お待ちしております。
今後とも a-blog cms のことをどうぞよろしくお願いいたします。