2019-07-06追記
文中で「a-blog cmsのIFブロックは、エントリーの基本情報の日付は条件分岐で判定できますが、カスタムフィールドの値を校正オプションで変換したあとの日付はできないようなのです。」と書いていましたが、できます。死にたい。訂正してお詫び申し上げます。
いずれにしても、SetRenderedで変数化しておいた方が、サイト内の複数箇所で利用しやすいことは代わりありません。

曜日が丸囲み漢字になっている

画像のようなカンプを受け取りました。曜日が「丸囲み漢字」になっています。

丸囲み漢字はユニコードで表示できないことはありませんが、CMSで扱うのは困難です。かといって、画像を書き出してimg要素にしたり、CSSの:after疑似要素で丸を重ねたりすると工数が増えます。
カッコ囲みに変更させてもらおうかと思ったのですが、全体のデザインとのバランスを考えるとデザイナーさんの希望を叶えたいところでした。

実装した経緯を記事にしておきます。
お急ぎの方は「解決方法」からどうぞ。
WordPressでの解決方法もあります。こちらへどうぞ。

※文章の都合上「日付型カスタムフィールド」と書いていますが、普通の文字列です。a-blog cmsは、Y-m-d形式であれば日付フォーマットを適用できる仕様です。

マークアップ

望ましいと考えられるマークアップは以下です。
この記号は「日本語表記の略語」ですから、abbr要素でマークアップして、title属性に国際表記を付与します。lang属性も入れようかと思いましたが、文書自体が日本語だと宣言しているのでやめました。

<p>
<abbr title="Monday">&#12938;</abbr><br>
<abbr title="Tuesday">&#12939;</abbr><br>
<abbr title="Wednesday">&#12940;</abbr><br>
<abbr title="Thursday">&#12941;</abbr><br>
<abbr title="Friday">&#12942;</abbr><br>
<abbr title="Saturday">&#12943;</abbr><br>
<abbr title="Sunday">&#12944;</abbr>
</p>

上記のコードを表示すると以下のようになります。

㊊
㊋
㊌
㊍
㊎
㊏
㊐

a-blog cmsの「共通設定」を試してみる

a-blog cmsの「コンフィグ＞共通」設定には、曜日をどのように表示するかという設定があります。通常は「日〜土」の普通の漢字表記ですが、任意の文字列に変更可能です。
この文字列は、エントリー関連モジュールの {date#week} 変数で表示できます。

じゃあ下のように書けばいいよね、と思ったのですが…

<p>
<abbr title="{date#l}">{date#week}</abbr>
</p>

ここで問題が発生しました。
今回は、日付型カスタムフィールドで日程を表示している箇所があったのです。

{entry_sample_date}[date('l')] → Sundayなどの英語表記

{entry_sample_date}[date('week')] → PHPのdate関数にはないので何も表示されない

a-blog cmsの日付型カスタムフィールドの場合、使えるフォーマットは「PHPのdate関数と同じ種類」となっています。このため、先程のa-blog cms独自のフォーマット変換は適用されません。

改めて、プログラムでの処理を考えることになりました。

出し分け方を考える

プログラムでの処理の流れを考えるとこのようになります。

• エントリーの曜日を取得
• PHPのDateフォーマットの「N」に変換し、1〜7の数値を取得
• 数字を条件にabbrでマークアップした記号を出力

WordPressの例

WordPressであれば、get_post_time関数を利用することになるでしょうか。ifを使おうかと思いましたが、配列をそのまま呼び出した方がスマートですね。

<?php
    $week_mark = array(
        '<abbr title="Monday">&#12938;</abbr>',
        '<abbr title="Tuesday">&#12939;</abbr>',
        '<abbr title="Wednesday">&#12940;</abbr>',
        '<abbr title="Thursday">&#12941;</abbr>',
        '<abbr title="Friday">&#12942;</abbr>',
        '<abbr title="Saturday">&#12943;</abbr>',
        '<abbr title="Sunday">&#12944;</abbr>'
    );
    $week_number = get_post_time( 'N' ) + 1;

    // 番号に該当する曜日記号を出力
    echo $week_mark[$week_number];

?>

同様の処理をa-blog cmsのIFブロックで行おうとしたのですが…また、カスタムフィールドならではの問題が発生してしまいました。

<!-- BEGIN_IF [{date#N}/eq/1] -->
<abbr title="Monday">&#12938;</abbr>
<!-- ELSE_IF [{date#N}/eq/2] -->
<abbr title="Tuesday">&#12939;</abbr>
・・・

a-blog cmsのIFブロックは、エントリーの基本情報の日付は条件分岐で判定できますが、カスタムフィールドの値を校正オプションで変換したあとの日付はできないようなのです。

できます。失礼いたしました。

<!-- BEGIN_IF [{entry_sample_date}[date('N')]/eq/1] -->
<abbr title="Monday">&#12938;</abbr>
<!-- ELSE_IF [{entry_sample_date}[date('N')]/eq/2] -->
<abbr title="Tuesday">&#12939;</abbr>
・・・

さすがにちょっと悩みましたが、先月の合宿のハンズオンでやった、SetRenderedの利用が参考になりました。

カスタムユニットを動的化してみよう | 2019春合宿 | ハンズオン | a-blog cms developer
https://developer.a-blogcms.jp/hands-on/camp2019spring/entry-3132.html

解決方法

最終的に、以下のように構築して解決しました。これであれば日付でもカスタムフィールドでも対応できます。

1. 曜日用のテンプレートを作成する

「vars_week.html」というテンプレートをテーマ内に作成し、以下の通り記述します。それぞれの変数名は「label_week_(数字)」で、数字は月曜日から日曜日まで、1〜7とします。

<!-- BEGIN_SetRendered id="label_week_1" --><abbr title="Monday">&#12938;</abbr><!-- END_SetRendered -->
<!-- BEGIN_SetRendered id="label_week_2" --><abbr title="Tuesday">&#12939;</abbr><!-- END_SetRendered -->
<!-- BEGIN_SetRendered id="label_week_3" --><abbr title="Wednesday">&#12940;</abbr><!-- END_SetRendered -->
<!-- BEGIN_SetRendered id="label_week_4" --><abbr title="Thursday">&#12941;</abbr><!-- END_SetRendered -->
<!-- BEGIN_SetRendered id="label_week_5" --><abbr title="Friday">&#12942;</abbr><!-- END_SetRendered -->
<!-- BEGIN_SetRendered id="label_week_6" --><abbr title="Saturday">&#12943;</abbr><!-- END_SetRendered -->
<!-- BEGIN_SetRendered id="label_week_7" --><abbr title="Sunday">&#12944;</abbr><!-- END_SetRendered -->

2. テンプレートを読み込む

曜日を使用する可能性があるテンプレートの冒頭で、この変数群テンプレートを読み込みます。

@include("/vars_week.html")

3. 変数を呼び出す

通常のエントリーの日付であれば以下のように記述します。

<!-- GET_Rendered id="label_week_{date#N}" trim="1" -->

Y-m-d形式のカスタムフィールドで、フィールド名が「entry_sample_date」であれば以下のように記述します。

<!-- GET_Rendered id="label_week_{entry_sample_date}[date('N')]" trim="1" -->

補足：校正オプションの自作

今回はやりませんでしたが、a-blog cmsは校正オプションを自作できますから
「Y-m-d形式の文字列を渡すと、先述のWordPressの場合の処理を通して、丸囲み漢字を返す」
という校正オプションを作ってしまう手もあります。

ただし、拡張を自作する場合は将来のバージョンアップやサーバー移転の際に漏れが出ないよう注意が必要です。

まとめ

こうして、丸囲み曜日を文書的にもシステム的にも問題なく表示できるようになりました。今回はたまたま丸囲み曜日でしたが、「弥生」とか「神無月」のような日本の古い月表記、a-blog cmsがサポートしていない言語の曜日表記にも使えますね。

なお、今回の場合、解決までに30分程度だったので問題なかったですが、時間がかかりすぎるようならカッコ囲みにさせてもらうなどの相談をしたほうが良いと思います。どのくらいかかりそうか、詰まったときに解決のヒントになりそうな引き出しがどのくらいで出てくるかで、そのあたりのバランスを考えています。

a-blog cms Traning Campのハンズオンは、毎回参考になることが多いので助かってます。アーカイブがあるのでぜひ見てみてくださいね。

https://developer.a-blogcms.jp/hands-on/

WordPress5.0がリリースされ、噂のブロックエディタ「Gutenberg」が正式実装されました。

現在私は、同じ構成で構築された、いくつかのWordPressサイトの運用のお仕事をしています。 そのサイトがGutenbergの導入でどのような影響を受けるかの検証と、それだけではなく、今後CMSを扱う立場としてGutenbergとどのように関わっていくかを、この週末に、ざっくりですが検討していました。

Gutenbergさんとどう付き合うか

まず、投稿タイプなどを追加していない、WordPress5.0の基本の状態でGutenbergをひととおり試しました。

私は、10年前からブロックエディタを搭載していたことで知られる、a-blog cmsを長年使用しています。また、スマートなブロックエディタを実装しているブログサービス「g.o.a.t」を一年ほど利用していました。

その経験を含めての感想としては、
「思ったより怖くない」
「これは『ビジュアルエディタの次世代としては』かなり良いのではないか」
です。

基本的に、ブログ記事などでは、HTMLの要素は見出し・本文・リンク・強調・各種サービスの埋め込みくらいしか使いません。それらについては軽快に書けますし、以前のビジュアルエディタとの操作の差も意外と少ないです。 驚いたのが「既存のビジュアルエディタ」がブロックのひとつとして用意されていることです。重くなりそうですが、どうしてもあのエディタでないと、というクライアントへの説得要素にもなるでしょう。

ウェビングスタジオとしては、新規案件の緩いコンテンツなど、利用しやすいところでは積極的に受け入れていきたいし、カスタマイズを学習していきたいと考えています。

長年WordPressを使い込んで、多数のプラグインやPHP拡張を活用してきた人ほど、Gutenbergは厄介な存在でしょう。 WordPressはオープンで自由なCMSです。一切使わない選択肢も用意されていますから、個々の制作者の自由でいいと思います。

使いたくない場合

一方、コンテンツ・マネージメント・システムとしてWordPressを使う場合、「投稿タイプによって適しているエディタが異なる」という問題が生じます。

例えば私の件の運用サイトの場合は、以下の３つの投稿タイプを持っています。

• post・・・ブログ記事
• page・・・がっつりマークアップした渾身のメインコンテンツ
• works・・・カスタムフィールド職人らしいフィールドのみのコンテンツ

worksでは、「Advanced Custom Fields Pro」のリピートフィールドで、こんな感じの簡易なブロックエディタを作成しています。簡易な方が操作しやすく、更新の効率が良くなるということは往々にしてあります。

この場合、pageとworksでGutenbergを使うことはできません。

このように、第一に制作者が考えなければならないのは、現在運用しているサイトの各投稿タイプで、Gutenbergにしても問題ない箇所と、使ってはいけない箇所を明確にしておくことです。

では、特定の投稿タイプだけ無効にすることはできるのでしょうか。管理画面にもそういった項目は見当たりません。困っていたら、WordPressをはじめとするいろいろなCMSに詳しい安部さんがTwitterで教えてくれました。

これは違います？https://t.co/jZR2e7bLT6

— 海老庵? (@evian) 2018年12月8日

これです。ドンピシャです。 高橋文樹さんが、Gutenbergがベータ版の頃から各種回避策を書いてくださっていたようです。

Before Gutenberg アーカイブ - Capital P

pageとworksでブロックエディタを無効にすることで、これまでのWordPressと変わりない環境にすることができました。

function WS_remove_block_editor( $user_block_editor, $post ) {
    if (
        ( $post->post_type === 'page' )
        ||( $post->post_type === 'works' )
    ) {
        $use_block_editor = false;
    } else {
        $use_block_editor = true;
    }
    return $use_block_editor;
}
add_filter( 'use_block_editor_for_post', 'WS_remove_block_editor', 10, 2 );

プラグインとの衝突問題

次に考えなければならないのは、プラグインです。

一通りコンテンツを確認したところで、カスタムフィールドを管理している「Advanced Custom Fields PRO」の編集画面に入ったら、ページが真っ白になりました。 フォームプラグイン「MW WP Form」も編集画面だけ真っ白になっています。

プラグインは問題がないと思っていただけに慌てましたが、これについても高橋文樹さんがすでに原因を書いていました。 “エディターのない投稿タイプは動かない” そうです。

Before Gutenberg - カスタムフィールド職人の命運やいかに？ - Capital P

つまりプラグインの投稿タイプでも無効にしなければならないわけで、最終的に以下のようなコードになりました。

function WS_remove_block_editor( $user_block_editor, $post ) {
    if (
        ( $post->post_type === 'acf-field-group' )
        ||( $post->post_type === 'mw-wp-form' )
        ||( $post->post_type === 'page' )
        ||( $post->post_type === 'works' )
    ) {
        $use_block_editor = false;
    } else {
        $use_block_editor = true;
    }
    return $use_block_editor;
}
add_filter( 'use_block_editor_for_post', 'WS_remove_block_editor', 10, 2 );

あまりスマートじゃなくなってきました…postだけ許可する、ホワイトリスト方式にした方がいいのかも。

この不具合については、頻繁に更新されているプラグインであれば早い段階で解決されると期待していますが、しばらく混乱は続くのでしょう。 これを機に、プラグイン制作者に問い合わせる前に、まず検索する習慣を身に付けたいものです。

既出かもしれませんがQiitaに寄稿しました。

WordPress5.0でプラグインの新規追加画面・編集画面が真っ白になった場合の対処 - Qiita

発展途上？なUI

ざっと使ってまず気になったのが、「ブロックを追加・挿入するボタン」の表示がわかりにくいことです。

最後に追加するならEnterキーを押せばボタンが出るのですが、挿入の場合は、前のブロックにマウスを置くと出る枠線の「上の線」にカーソルを置かないとボタンが出てこないのです。これがかなりシビアな操作になっています。 それ以前に、感覚的には一般に「下に追加する」と感じるので、一つ前のブロックの下線にボタンが出るべきじゃないですかね…

ボタンブロックについても、色の選択があるのですが、よりにもよって背景色だけでなく文字色まで自由に選択できるUIになっています。

サイトを明るくしようとした更新担当者さんが、ボタンの色をピンクとかライムにする未来が見えます。

これがインラインスタイルで入るのか、クラスで入るのかまだ確認できていないですが、とにかく色は個別に選ばせたくないですし、外観についても丸と四角、塗りつぶしとボーダーはそれぞれどのような役割で使うのか決めておかないと、わけのわからないことになります。

また、WCAN 2018/10でたにぐちさんも指摘されていましたが、パーマリンク設定の場所もわかりにくいです。WCANに参加していなければ見つけられませんでした。更新担当者にパーマリンクをいじらせてはいけない、という禁止系インターフェース…と考えられなくもないですが。

たにぐちさんがさらに指摘されていた「なぜかテキストブロックの文字の寄せ方向だけ、クラスではなくインラインスタイルになっている」件は、私はあまり気にしていません。文字色などとは異なり、文字の寄せ方向はテーマやCSSが変わっても、同じであることが多いからです。しかし、UIのブレであることは確かですし、インラインスタイルは優先度が高いので、上書きしようとするとimportantまみれになる問題があるのですが…

少なくともこれまでと相当感覚が違うので、リモートで運用をしている場合は、更新担当者にどのように操作説明をするか考える必要があります。 a-blog cmsユーザーの多くがやっていたことですが、往訪できない場合はブロック一種類ずつに対して、操作している動画を撮って見ていただくのが確実と思います。

特定のブロックを使わない自由はあるのか

ボタンのところでも触れましたが、Gutenbergの「機能が多すぎる」ことも私の中で課題になっています。 多数のブロックがありますが、すべて対応していられないとか、コンテンツの性格上、使ってほしくないケースもあります。

私がa-blog cmsを気に入っているのは、コンテンツ（ブログ）ごとに、使用できるブロック（ユニット）を管理者が指定できることです。 もう少し情報を調べれば既に出ているのかもしれませんが、特定のブロックを使わない自由を公式に設けてほしいものです。

Gutenbergさんは悪くない、悪くないんだ

繰り返しますが、私はGutenbergが気に入っていて積極的に使いたいです。

ただ、日頃「すべての人が自由に気軽に使えるCMS」を謳っていながら、「ユーザーが、GUIを通して機能を選択（無効ではない。選択）できない状態でリリースした」強引さに若干呆れています。

今後各国のWordPressコミュニティは、一定のウェブ制作の知識を持たない人（いわゆる個人ブロガーなど）へのサポートを切り捨てるか、これまでのようにGUIで管理できるプラグインの開発やブログ記事などの情報を充実させるかの、大きな選択を迫られるのでしょう。

個人へのサポートを既にやめている私としては、前者が幸せじゃね…？と思ってしまいつつ、制作会社・企画会社との協業媒体としてのWordPressに、Gutenbergをどう活用していけるか、前向きに考えていきたいと思います。

a-blog cmsは、初期インストールが最大の難関となっています。ドキュメントが充実してきましたが、説明を見ただけで挫折する人も多いようです。
そんな中、開発元のアップルップル山本さんが「サーバー設定も含めた、すべてのインストールを自動化するプログラム」のリリースをはじめました。

Mac に a-blog cms を誰でもインストールできるようにするプログラムを書いてみた | kazumich.log

現在、以下のサーバー環境に対応したパッケージを配布しています。

• MAMP
• Windows XAMPP
• CPIレンタルサーバー ACE01
• さくらのレンタルサーバー
• ロリポップ & ヘテムル
• Zenlogic
• XSERVER
• 2.5.x -> 2.6 へのアップデート

留守中の姉の部屋で食べる「きのとや」のチーズタルトおいしいです ŧ‹"ŧ‹"(•ㅂ•)ŧ‹"ŧ‹"

シルバーウィークの間、札幌の実家に帰省中です。といってもほぼ毎日、仕事をしているわけですが…

久しぶりに、WordPressの案件が入りました。最近は新着情報など小さな組み込みが続いたので、まとまった案件はほぼ一年ぶりです。
いずれにしてもいちから作り直しになるので、テーマやプラグインを見直すことにしました。

baserCMS用のテーマ「logical_jp」を作ってから、もうずいぶんになります。

前回のコンテストで佳作となったこのテーマは、その後、私がbaserCMSのバージョンアップに対応する時間が取れなかったことから、開発元のみなさんに手を入れていただき、ありがたいことに今も人気テーマの一つとなっています。

logical_jp_baser | baserマーケット

作成した当時はまだbaserCMSの特徴を把握しきれておらず、トップページが魔改造になってしまい、カスタマイズできないという質問がフォーラムにも時折きているようです。正直すまんかった。

よくある質問については、こちらまとめたいと思います。

• はじめに
• テーマカラーの変更が反映されない・ロゴを差し替えたい・ロゴにリンクを貼りたい
• 本文に表を書くと必ずボーダーが入ってしまう
• トップページ右上のRSS新着を削除したい
• トップページ右上にHTMLを書きたい
• トップページ右側をウィジェットにしたい
• トップページの画像＋説明文の数を6個に増やしたい