先日「Ver. 2.11.25からのテンプレートの仕様変更について」という記事を掲載しましたが、中にはallow_pathを記述しなくても読者以下の権限で正常に使用できるとご報告をいただきました。

弊社でもある条件下において該当の現象を確認しましたが、弊社としては変わらずconfig.system.yamlのallow_pathを記述してテンプレートを許可することを推奨します。この記事では、その件について詳しく説明します。

現象の詳細

config.system.yamlのallow_pathの項目からテンプレートを許可しなくてもポストインクルードおよび検索機能などのPOST_2GETを使用している機能にてtpl指定が利用可能な状態になっているケースが確認されています。
ただし、中には適切に記述をしないとPOST_2GETの機能を利用できないケースもありますので、弊社としては引き続きallow_pathを指定していただくことを推奨しています。

起こっている現象を詳しく説明すると、tplをテンプレート経由で記述していても、実際のプログラム側に送られているRequest URLではtpl指定がされている場合とそうでない場合があります。
tpl指定が指定されているとステータスコードは400エラーになり、tpl指定がなければ基本的にはステータスコードが200になり、正常に表示されます。

挙動がバラバラになってしまうことを防ぐため、統一するためにallow_pathの指定を推奨しております。

ステータスコードが200の条件

BIDとキーワード指定のみ

この時はRequest URLが http://example.com/include/entry/summary-custom.html/keyword/テスト/ となります。

子ブログのBIDを指定して検索したとき

この時はRequest URLが http://example.com/test/include/entry/summary-custom.html となります。

子ブログのBIDとキーワードを指定して検索したとき

この時はRequest URLが http://example.com/test/include/entry/summary-custom.html/keyword/テスト/ となります。

フィールド検索

この時はRequest URLが http://example.com/include/entry/summary-custom.html/field/station/あの駅/ となります。

ステータスコードが400の条件

400になる時、起こっている現象は2種類あります。

その１：REQUEST URLにtplを渡している

ブログのトップページでEIDを指定して検索したとき

この時はRequest URLが http://example.com/entry-2.html/tpl/include/entry/summary-custom.html となります。
tplがURLに入っているので、404エラーで表示されません。

その２：Request URLにtplを渡していないけど、パスが成立していない時

CIDを指定していて、「/〇〇（カテゴリーコード）/include/entry/summary-custom.html」というテンプレートがないとき

この時はRequest URLが http://example.com/〇〇（カテゴリーコード）/include/entry/summary-custom.html となります。

カテゴリーコードをURLに挟んでいるので、テンプレート（include/entry/summary-custom.html）をカテゴリーコードと同じ名前のディレクトリに設置する必要があります。
もし、テーマディレクトリ直下に該当のテンプレートが設置されていた場合は、 http://example.com/〇〇（カテゴリーコード）/include/entry/summary-custom.html に該当するテンプレートがなく、400エラーが発生します。

REQUEST URL の調べ方

開発者ツールから調べます。ここではGoogle Chromeを使用しています。

開発者ツールのNetworkタブをクリックしてください。

ポストインクルードを発火させると、一覧にポストインクルードで使用しているテンプレート名が表示されている（キーワード検索なら、指定したキーワードが表示される）のでクリックします。

Request URL を確認します。今回の例ではtplが使われておらず、カテゴリーコードも指定されていないので、読者以下の場合でも特にallow_pathでテンプレートを指定しなくても正常にポストインクルードが動作します。

まとめ

基本的には弊社としては allow_path を指定し、該当のテンプレートのみ許可することを推奨しています。

allow_pathの指定の仕方については、くわしくは「Ver. 2.11.25からのテンプレートの仕様変更について」の記事をご覧ください。

この記事では、現在開発中のVer.2.12のdevelopテーマとUTSUWAテーマで配布しているwebpackの開発環境について解説します。

概要

公式テーマで配布しているwebpackの開発環境についてシンタックスハイライターが読者以下の権限またはログアウト時に読み込まれないという現象が報告されました。この記事ではログアウト時にもシンタックスハイライターを有効化するいくつかの方法をご紹介します。
siteテーマ、beginnerテーマ、bootstrapテーマ、blogテーマを使用されている方には同じ現象は該当しないのでご安心ください。

webpackで行なっていること

以前からパフォーマンス速度の改善をする際に、組み込みJSで使用しているacms.jsの容量が問題となっておりました。このwebpackの開発環境を使うことにより、Webサイトのパフォーマンス速度を改善するため、最小限の組み込みJSを読み込むことができます。
具体的には、読者権限以下またはログアウト状態ではタッチモジュールを使ってacms.jsを読み込まないようにし、組み込みJSで使用している各プラグインをnpm経由でwebpackを使って読み込んで再現しています。

この記事で説明すること

npmに公開されていないライブラリは一部再現できないものがあり、その1つが今回上げているシンタックスハイライターで利用しているgoogle-code-prettifyのライブラリです。こちらは2013年ごろに開発がストップしており、npmではライブラリが公開されていないため、webpackで使用することが困難になります。
この記事では、webpack以外でgoogle-code-prettifyを使用する方法と、webpackで別のnpmパッケージを利用する方法をご紹介します。

webpack以外でシンタックスハイライターを使用する方法

• タッチモジュールを外す
• CDNで使用する

タッチモジュールを外す

この方法が一番簡単な方法です。developテーマとUTSUWAテーマでは読者以下の権限（ログアウトを含む）にて、acms.jsが読み込まれていないことが原因となっています。 /include/head/js.htmlを開き、該当するタッチモジュールを削除すれば、他のテーマと同様に使用することができます。

CDNで使用する

次に簡単な方法です。acms.jsを読み込みたくないけど、google-code-prettify（シンタックスハイライター）を使いたい場合におすすめです。Githubに記載されているCDNをhead要素内で読み込みましょう。

• googlearchive/code-prettify: GitHub

<script src="https://cdn.jsdelivr.net/gh/google/code-prettify@master/loader/run_prettify.js"></script>

webpackで別のnpmパッケージを利用する方法

この機会にwebpackを試したい方や、他のライブラリに挑戦したい方におすすめの方法です。a-blog cms 以外に基本的なJavaScriptの知識が必要となります。

今回は実際に highlight.js を使ってご紹介します。2021年11月現在、このデベロッパーサイトでも使っているシンタックスハイライターです。

• highlight.js

Ver.2.12β版で配布しているUTSUWAテーマをもとに解説します。

npmパッケージをインストールする

まずは、/themes/utsuwa/のディレクトリまで移動し、highlight.jsのnpmパッケージをインストールします。

$ npm install highlight.js --save

インストールしたら、次はインストールしたパッケージをwebpackから読み込みます。

インストールしたパッケージをwebpackから読み込む

/themes/utsuwa/src/js/index.jsをエディタで開きます。ファイルの8行目付近で、highlight.jsを読み込みます。

import hljs from 'highlight.js';

使用するスタイルを指定する

先程のhighlight.jsのサイトで、スタイルがいくつかプレビューできるので、好きなテーマを探してください。

そして、14行目付近にテーマ名と同じcssファイルを読み込みます。

今回は、agateというテーマを指定します。

import 'highlight.js/styles/agate.css';

発火する処理を書く

UTSUWAテーマでは、82行目付近にdomContentLoadedが既に書かれています。このdomContentLoadedの中に発火するための処理を書きます。

domContentLoaded(() => {

  document.querySelectorAll('pre code').forEach((el) => {
    hljs.highlightElement(el);
  });

// ... 省略 ... 
});

これで、ログアウト状態でもシンタックスハイライターが動くようになりました。ただ、ログイン状態の時にgoogle-code-prettifyとhighlight.jsが2つ動いてしまっているので、google-code-prettifyを無効化します。

google-code-prettifyを無効化する

UTSUWAテーマでは既に33行目付近に、acms.js に関するif文が記述されています。このif文のelseの中に、google-code-prettifyを無効化する記述をします。以下のように書きます。

if (window.ACMS === undefined) { // acms.jsが読み込まれていない時
// ... 省略 ....
} else { //acms.jsが読み込まれている時
  edit();
  ACMS.Ready(() => {
     ACMS.Config.googleCodePrettifyClass = 'prettyprinted';
  });
}

これで、ログインしている時もhighligh.jsが動くようになったはずです。一度お試しください。

まとめ

今回ご紹介したように、acms.jsを使う方法やCDN経由で従来のライブラリを使用する方法があり、webpackの開発環境は無理にお使いいただくものではありません。これからもa-blog cmsを使ったWeb制作で最低限必要な知識はa-blog cms、HTML、CSSのみです。
Web制作に関する技術が増え、技術選択に迷う時代ではありますが、弊社としては開発効率の向上やパフォーマンス改善を行なう際のベースとして、みなさまがより良いお仕事ができるように開発環境を提供できたらと考えております。

弊社としては時にはCMSの垣根を超えて、みなさまの制作に役立つものを提供したいと考えております。
フィードバックなどありましたら、お気軽にお問い合わせフォーム、TwitterやFacebookなどのSNSからお気軽にお知らせください。

今回のブログ記事では、今後リリース予定のVer.2.12で公式テーマに同梱されているWebpackの開発環境についてご紹介します。

まず始めに、Webpackを使わなくてもいい場合について

この記事でご紹介するWebpackの開発環境はa-blog cmsの実装に必要なものではなく、既存のJSを変更したい場合やWebpackからSass（SCSS）をコンパイルしたい場合に任意で使用するものです。
a-blog cms を使用する上で最低限必要な技術はa-blog cms、HTML、CSSだけです。あくまで開発環境を整えるということはよりよいサイト制作をするための手段の1つなので、今回ご紹介するWebpackを無理に使わなくても大丈夫です。

Webpackを用意しているテーマでも、Ver.2.11以前と変わらずに以下のことはできます。

• テーマですでに用意されているJSは変更せず、新しいJSファイルを追加して読み込む
• テーマですでに用意されているスタイルをCSSファイルから変更する
• 新しいCSSファイルを読み込んでテーマですでに用意されているスタイルを上書きする

Webpackを使用する方法以外でもコンパイルするアプリなどのツールが存在しています。
今回の記事では詳しいツールについてご紹介しませんが、もしWebpack以外の方法でスタイルをSCSSファイルからCSSへコンパイルしたいという方がいらっしゃれば、ご自身が使いやすいものを別途調べていただけると幸いです。

Ver.2.12から同梱されているWebpackでできること

以下の作業のために開発環境を整えています。

• JSやCSSなどのファイルを1つにまとめる
• SCSSをCSSに変換する
• ソースコードを整形する
• ESLint（JavaScriptの構文チェッカーのこと）

Ver.2.12 β版の配布について

Ver.2.12は2021年11月現在、β版が用意されています。正式版のリリースまで、今しばらくお待ちください。

本記事で紹介するWebpackの環境がいち早く確認したい方は、β版用ablogcms.ioにてVer.2.12を体験できる環境を用意しておりますのでこちらから確認できます。 ablogcms.ioの環境を用意し、SFTPに接続すると各テーマファイルにWebpackの設定ファイルがあるので、こちらからご確認ください。

• β版用ablogcms.ioを試してみる

使い方

UTSUWAテーマを例にして、ご紹介します。

マシンにnode.jsが入っていない方はnpmコマンドが使えないため、事前に公式サイトからインストールしてください。
インストールするバージョンは、.node-versionに記載しているバージョンと同じバージョンをインストールしてください。

.node-versionの中身

例えば、以下のような記述が書かれています。

v14.16.0

この場合は、v14.16.0と書かれているのでNode.jsの14.16.0をインストールしましょう。

npm コマンドの使い方

1. themes/utsuwa に移動してnpm install をする（npm installコマンドを実施することによって、UTSUWAで使用している全てのパッケージをインストールします）
2. その後npm run start またはnpm run dev で開発を開始する（JSやCSSが1つにまとめたり、SCSSをCSSに自動で変換します）
3. リリースできるようになったら、npm run build でビルドする

npm installをすると、そのディレクトリにnode_modulesと言うフォルダが作成され、大量のファイルがダウンロードされます。これは普通のことなので、焦らなくても大丈夫です。 npm run dev とnpm run build は、後ほど説明します。

package.json

package.jsonにはUTSUWAで使用できるコマンドと使用しているパッケージがリストされています。

以下、把握した方が良さそうな項目を絞って一部の設定について紹介します。

package.jsonのconfig

• local ... 後述する npm run start のライブリロードで使用します。開発環境を表示しているドメインなどあれば記入してください。
• theme ... 使用しているテーマを記述します

package.jsonのscripts

基本的には、 npm run dev とnpm run build を使用すればOKです。
もしライブリロードが欲しいなら、npm run dev の代わりに npm run startを使いましょう。

Webpack の設定ファイル

以下はWebpackの処理を設定しているファイルです。Webpackの処理をカスタマイズしたい際は、以下のファイルを変更してください。
JSの結合や、SCSSからCSSのコンパイルする作業などの基本的な設定はすでにされているので、基本的なことをしたい場合は変更は特に必要ありません。

関連する不可視ファイル

開発環境を整えるために使用している不可視ファイルです。Macだと可視化するために特別な設定（Shift+⌘+.）が必要になります。
Webpackの開発環境を利用する際は、これらのファイルも忘れずに設置してください。

まとめ

今回ご紹介したWebpackの開発環境は無理にお使いいただくものではありません。これからもa-blog cmsを使ったWeb制作で最低限必要な知識はa-blog cms、HTML、CSSのみです。
そこにさらにJSの知識があればよりリッチな表現ができますし、今回のようなWebpackに関する知識があれば開発効率が上がったり、パフォーマンス改善を行なったりすることができます。つまり、これらの開発環境を整えるということはよりよいサイト制作をするための手段の1つにすぎません。

Web制作に関する技術が増え、技術選択に迷う時代ではありますが、弊社としては開発効率の向上やパフォーマンス改善を行なう際のベースとして、みなさまがより良いお仕事ができるようにWebpackの開発環境を提供できたらと考えております。

弊社としては時にはCMSの垣根を超えて、みなさまの制作に役立つものを提供したいと考えております。
フィードバックなどありましたら、お気軽にお問い合わせフォーム、TwitterやFacebookなどのSNSからお気軽にお知らせください。