wordpress

タグ別:

会話を書きやすくするショートコード [dialog] を追加

丁稚さんです。
こつこつ自作中でこのサイトでも使っている WordPress テーマ skel

基底クラスをつくって「ショートコードがぱぱっとできあがる」ようにしたのに気をよくして、
ちょっと量産しているのですよ。

ということで、会話文(ダイアログ)を書きやすくするショートコードを作ってみました。
(こりはリポジトリ中の一部なのでこのままコピペしたりしても動きません)

たとえば、Markdown の定義リストに合わせて、こんなふうに書くと…

[dialog]
丁稚さん
:    ほら! めんどくさい会話形式の表示がこんなにかんたんに!

ダル子
:     ということは、わたしの登場頻度が高くなるというわけだわね…

丁稚さん
:    そう…なるのかな?
[/dialog]

こうなる!

[dialog] 丁稚さん
: ほら! めんどくさい会話形式の表示がこんなにかんたんに!

ダル子
: ということは、わたしの登場頻度が高くなるというわけだわね…

丁稚さん
: そう…なるのかな?
[/dialog]

これわべんり!
…かな?

「定義リストはダイアローグに使ったらいけないんですぅ~」とかいうHTML5原理主義者の指摘は却下です…。

もうひとつショートコードつくったらリファクタリングして、本来の作業に着手しよう。

WordPressで手軽に「ジョンソンボックス」を書くためのショートコードをつくってみた

ジョンソン・丁稚さんです。

[johnson title=”かんたんに説明すると”] WordPressでジョンソンボックスを手軽に書けるようにした
: `[johnson title=”見出し”]…[/ johnson]` ですぐ書けるよ

[`skel`](/tech/2017/0223/79) テーマで使えるよ
: まあ、ほかの人にすぐ使ってもらえるレベルに達してないんですが
[/johnson]

「ジョンソンボックス」ってこういう ↑ 箇条書きにチェックボックスをつけて視覚的にアピールする、広告クリエイティブのことです。
結論ファーストでブログのエントリ書いたり、ランディングページつくるときにべんり。

先日紹介して、このサイト上で開発しながら使ってる「skel」テーマに投入してみました。

使い方は上述のとおりなんですが、

[johnson title="見出し"]
箇条書き1
箇条書き内容1
箇条書き2
箇条書き内容2
[/johnson]

のようにすると、

[johnson title=”見出し”]
箇条書き1

箇条書き内容1

箇条書き2

箇条書き内容2
[/johnson]

になります。

HTML直書きだとまだめんどくさいですね。Markdownと組み合わせると、

[johnson title="見出し"]
箇条書き1
:    箇条書き内容1

箇条書き2
:    箇条書き内容2
[/johnson]

で、

[johnson title=”見出し”] 箇条書き1
: 箇条書き内容1

箇条書き2
: 箇条書き内容2
[/johnson]

になるのでなかなかラクです。

テーマにいくつもショートコードを入れ込むのがめんどくさいので、ショートコード実装のための基底もどきっぽいクラスを書きました。

なので [ johnson] ショートコードの実装は短くすみました。こんな感じ:

ぜんぜん「がいこつ」じゃなくなってくなあ、このテーマ…。
でも、ミラドール本体サイトをつくるのにちょっと機能増やさないといけないからなあ…。

wpautopフィルターがかかる前にショートコードを実行させるもっそい汚いやり方

なんだかWordPressとPHPのことばっかり書いてるなあ…ホントはPHP書けないのに…という丁稚さんです。

例によってWordPressのこと。

WordPressはデフォルトで「本文に <p><br> をよしなに追加する」という機能があります(仮に wpautop と呼ぶ)。

ちょっとショートコードやプラグインを書いたことのある人にとって、これは鬼門です。なぜかというと「投稿者が入力したとおりのテキストではなく、wpautop が加工したテキストを相手にしなくてはならない」からです。

図にするとこういう感じで、

本文(the_content)に対して、priorityつまり優先順位が 10wpautopが実行されてから 11 のショートコード群が呼ばれます。

具体的にはどうなるか。たとえば [markdown]...ほげほげ...[/markdown] とかいって「囲った内容をMarkdown化するショートコード」を書くと、ほげほげの部分に勝手に <p><br> が入ってきてしまいます。Markdownはいわゆる「HTMLブロック要素」内のマークアップを無視する使用なので、うまく動かなくなります。

まじめな対策としてはいくつかあります。下のページさんなんか細かく書いてありますが。

  1. wpautop を無効にする
    → 無効でもいいんだけど。サイト全体に影響が出ますね^^;
  2. wpautop の優先順位を本来の 10 より下げる(12 とかにする)
    → ほかのショートコードの実行に影響が出るかもしれない
  3. 上掲サイトのような方法
    → 現状ではこれがいちばんよいのだけれど、正直見通しがよくない気がする
  4. 優先順位 9 に自分のショートコード用フィルタを登録し、自前パースする
    → ショートコードの結果に wpautop がかかるのが気に入らない

ということでいまひとつ決定打がない…。

しかたないので、こんなふうにしてみました。

  • 優先順位 9 で自分のショートコード要素が内包するテキストをぜんぶ base64 エンコードする(改行もなにもなくなる)
  • 自分のショートコードの処理が呼び出されたら、まず受け渡された内包テキストを base64 デコードする
  • あとはふつうにショートコードの実装をする

図にするとこうです。

むっちゃくちゃ汚い実装ですね ^^; でも、丁稚さんみたいに実力のないプログラマが他人のパーサを乗っ取ってなにかするとき、わりと重宝する手法です(前科がたくさんあるらしい…)。

ちなみに、一部のサンプルコードを載せておきます。

// base64 エンコードしちゃう部分
$shortcode_name = 'おまえのショートコード名';
add_filter(
    'the_content',
    function ( $content ) use ( $shortcode_name ) {
        $content =
            preg_replace_callback(
                '/(\['
                    . $shortcode_name
                    . '[^\]]{0,}\])([\s\S]*?)(\[\/'
                    . $shortcode_name
                    . '\])/',
                function ( $matches ) {
                    return(
                        $matches[1]
                        .  base64_encode( $matches[2] )
                        . $matches[3]
                    );
                },
                $content
            );
        return( $content );
    },
    9
);
// ショートコードの実態メソッド
function ( $attrs, $content = '' ) {
    $content = base64_decode( $content );
        :
        // 以下ふつうの処理
    return( $content );
}

preg_replace_callback を使ってすごいことになってますね。
単に正規表現でパースするだけならまだしも [\s\S]*? とか使ってるので…。
不特定第三者の入力を受け付けるショートコードだと RDoS 攻撃の対象になるかもしれません。
サイト運営者しか使わないショートコード向けならだいじょうぶでしょう。
本気で使うときは元コンテンツの md5 をキーにキャッシュ取ったほうがいいのかも。

まあ、どっちにしてもいちばん正しいアプローチは こんなことしなくてもすむようなパーサをちゃんと書く ですね…。

WordPress の JetPack Markdown をほかのテーマやプラグインなどのメソッドから使うよ

ソースを grep してしらべた…。「Singletonだぜウェーイ」としか書いてなくて何の役にも立たないコメントに悩まされつつ…。

$content = 'sutekina **em** something';
if (
    class_exists( 'Jetpack' ) 
    && Jetpack::is_module_active( 'markdown' )
) {
    jetpack_require_lib( 'markdown' );
    $content =
        WPCom_Markdown::get_instance()
            ->transform(
                $content,
                [
                    'id'      => false,
                    'unslash' => false,
                ]
            )
    ;
}

なお、wpautop というフィルタが実行される前に使わないと、全体に <br><p> が勝手に入るため使い物にならないもよう。

WordPressとMarkdownとシンタックスハイライトと私

画像はやる気のないダル子。

できるだけ手抜きしてブログ更新したい丁稚さんですよ。手抜き更新するには「HTMLなんか直に書いていられない」というのが正直なところ。そこで必要になるのがおなじみ簡略記法「Markdown」です。Markdownの詳細は他サイトにゆずる。

WordPressで、投稿画面にMarkdown形式テキストを書いたらブログを更新できる…それは過去5, 6年くらいの永遠の課題…。実現するためのプラグインは存在するのに、なかなか決定打がないんですよね。ポイントは以下のような感じ。

  1. WordPressの「ビジュアルリッチエディタ」と共存できるかどうか
  2. Markdownの便利な「亜流」に対応しているかどうか
  3. シンタックスハイライトはどうする?

で、まあ、2年ぶりくらいにまた調べてみました。

(さらに…)

ぜい肉をそぎ落としたWordPressテーマ「skel」を作っているのです

ケータイでブログ更新すると指が太くて困る丁稚さんですよ。

さて。前にTwitterでもつぶやきましたが、WordPressのテーマをこつこつ作っています。このサイトで利用しているもので、GitHub にも公開しています。その名も skel

skel は「がいこつのようにシンプルであまりゴテゴテしていない」をコンセプトに作りはじめました。

WordPress は生態系が確立されていてテーマが豊富ですけれど、力作ほどこんな欠点があります。

  • すでに装飾されまくっていて修正しづらい
  • 要らない機能を消すのが大変
  • CSSリセットの影響でCMSとして使いづらい
  • PHP, JavaScriptでグローバル汚染が起きている
  • CSSフレームワークとaltCSSを採用しており、修正にほかのツール連携が必要

ということで、今回はいろんなしがらみをばっさり断ち切ってゼロから作ってみました。

基本的な機能

  • レスポンシブ
    • 基本2カラム。サイドバーを左右どちらに置くか指定可能
  • テーマカスタマイザ
    • ヘッダー画像の変更
  • スクロールしてもついてくるパーツ
    • グローバルメニュー
    • 「ページの最初へ」戻るボタン
  • サイドバー(ウィジェットを置く領域)対応
    • 横幅いっぱいのヘッダ
    • 本文脇
    • 横幅いっぱいのフッタ
    • ヘッダ(左・中央・右)
    • フッタ(左・中央・右)
  • メニュー対応
    • サイトグローバルメニュー – 最上位統一メニュー
    • サイトグローバルメニュー(脇) – 最上位統一メニューの右寄せ要素
    • サイトグローバルメニュー(ドロップダウン)- メニューからのドロップダウン要素
  • Windows/OS X/Android/iPhone, Edge/Chrome/Safari でアンチエイリアスフォント表示されるよう設定

テーマ自身が提供するもの

  • SNSシェアボタン
    • Twitter, Facebook, はてなブックマーク, Google+, LINE
  • Googleサーチコンソール対応
  • Google Analytics対応
  • Google タグマネージャ対応
  • Canonical(標準のまま)
  • Twitterカード
  • Facebook OGP
  • ウィジェット
    • プロフィール
    • サイト内検索
    • タグ
  • ページャ
    • トップページ、各カテゴリ・アーカイブページ、検索結果ページ
  • アイコンフォント
    • FontAwesome
    • Google Material Icon
  • ウィジェット開発簡便化のための基礎クラス
  • 国際化対応
    • したがってテーマファイル中には一切日本語は入っていません
    • テキストドメイン skel を使用しています

と、こんな感じで。あとは推奨・同梱プラグインで機能を実現してね! というポリシーになっています。

もうちょっとマシになったら公式リポジトリのほうにも投下するかもしれません。気がついたことなどありましたらTwitterでお寄せくださいな。

ではではー。

WordPress/JetPackの依存パッケージ

キライだけど使っちゃう、くやしいっ! でも使っちゃうっ! な丁稚さんです。なにがキライなのかは言いません。

このサイトの運営にも使っているWordPress。あと、それの必須公式プラグインであるところのJetPack。ひさしぶりにセットアップしてみたら、なんだか依存パッケージ類が増えているような気がします。

パッケージというか正確には PHP の extension なんですが。

これまで安定して使ってきた秘伝のタレ環境だと特になにもなかったにもかかわらず、

  • AlpineLinux (/etc/alpine-release = 3.3.1)
  • PHP 5.6.30
  • WordPress 4.7.2

の現環境になってから、

  • php-ctype
  • php-dom

が必要になりました。パッケージ名はそれぞれご自分がご利用のLinuxディストリビューションに沿って読み替えてください。

前者はなにが起きたのかもう忘れたけれど、後者がないと JetPack Markdown 中で入れ子の HTML 要素が入ったときに落ちます。

…どちらも「えっ。なんでその程度の extension 入ってないの??」と言われそう。Docker の軽量イメージつくって運用してるので、ほんとに必要最小限しか入れていないのですよ~。

このあたり、おーとまちっくさんは必要環境類の情報を細かに明示してもらえるとありがたいですね。まあ、WordPress に限ったことじゃないか…。

ちなみに Markdown と php-dom の関係については以下のページを参考にさせていただきました o