カスタム投稿タイプのデフォルトウィジェットブロック一式が詰まったWordPressプラグイン「Custom Post Type Widget Blocks」をリリースしました

カスタム投稿タイプで活用できるデフォルトウィジェットブロック 7 点が詰まった WordPressプラグイン「Custom Post Type Widget Blocks」を作りました。

WordPressプラグイン「Custom Post Type Widget Blocks」は、以前つくったウィジェット版の WordPressプラグイン「Custom Post Type Widgets」のブロックエディタ版です。

WordPress 5.0 から標準エディタがブロックエディタになりました。それに伴い、ウィジェットはブロックエディタに統合されていくことを見越して、ブロックの作り方をちょこちょこ学びつつ作ってみました。

機能は、Custom Post Type や Taxonomy で絞り込みができる以外は、標準のウィジェットブロックとほぼ同じです。
ある程度安定した状態になれば、将来的に機能を追加して拡張していこうかと思います。

是非ブロックエディタで活用してみてくださいね。

WordPressテーマ「Foresight」がレビューを経て wordpress.org 公式ディレクトリに掲載されました

WordPressテーマ「Foresight」が wordpress.org 公式ディレクトリに掲載されました。

WordPressテーマ「Foresight」は、公式ディレクトリ登録を目指していたので、テーマ開発に取り組んで目標の一つを達成できて一段落つきました。これからもテーマの改良を続けてブロックエディタの活用を充実させたり、いろいろ研究開発を行っていきたいですね。

ということで、公式ディレクトリ登録を行う上で欠かせないテーマレビューはどのようなものか。2ヶ月ほどやり取りしていたレビューの所感を綴ってみたと思います。

WordPressテーマ「Foresight」の詳細や作ったときの感想は、以下を見てください。

テーマレビュー経緯

テーマの登録申請を2019年11月25日にしました。
その時のテーマレビュー待ち200余り。
とりあえず気ままに待つことに。

待つこと3ヶ月ほど。
2020年2月13日にレビューアさんが付いてくれました。
途中新型コロナウイルスの大流行で滞りなくレビューが進むのが心配していましたが、普通にレビューが進んでいきました。こういうときにコミュニティが機能しているありがたさが実感できますね。

最初のレビューは、作ったWordPressテーマが、Theme CheckTheme Handbook のガイドラインに準拠しているかを主に診てくれます。

そして、修正をしながら進めていくとさらにソースコートを隅々まで詳細にレビュー (complete review) してくれます。

指摘されて改善したところ (パート1)

  • ディレクトリ構成が少し特殊な形なので、構成やファイル名を見直した。
  • JavaScript ファイルは minified しか入れていなかったので、レビューできるように生のソースも追加で入れた。最初 webpack でバンドルしていたけど、出力される生のソースも特殊な出力なのでレビューできるかどうか分からなかった。ということで普通の結合 (concat) に変えた。
  • オプションのデータの持たせ方を変えた。取り回しが効きやすいようにいつも複数の options に分けて入れているけど、公式テーマだと theme_mod (一つの配列) に入れるようにすることが大切。参考: Customizer Objects#Settings
  • タブキーでのフォーカス移動などキーボード操作できるようアクセスビリティをしっかり診てくれた。特にドロップダウンメニューが展開するグローバルメニューの部分。普段キーボード操作をあまり意識していなかったのでこういうところも大切だなぁと改めて気づいた。
  • テンプレート階層を少し触っているのでそのことを聞かれた。理由を説明するとすんなり受け入れてくれた。そんなに厳格さはなく、柔軟に対応してくれるようだ。

やり取りと修正を2回ほど繰り返し、ひとまず承認された。

次にダブルチェック的な最終テーマレビューへ進む。
少しベテランな感じ?のレビューワーさんが付いてくれました。
更に細かい部分まで診てくれる。特にセキュリティ面でエスケープやサニタイジングのところ。

指摘されて改善したところ (パート2)

  • エスケープやサニタイジングを結構見落としているところがあった。のでチェックしてくれるの助かる。
  • コピーライトやクレジットの表記の見直し
  • readme.txt ドキュメントの見直し
  • ライセンス上使っていい CDN や画像などサードパーティリソースの見直し。スクリーンショットを変えた。
  • 標準コアにあるカスタマイザの機能を一部削除していたのでその調整をした。
  • javascript のグローバル変数の扱い。プリフィックスをつけるか、または即時関数にしてローカルオブジェクトにする。
  • デザイン的にボタンやメニューを画面に fixed すると。ログイン状態でページを見る場合、adminバー (ツールバー) に重なるところがある。位置をずらして重なりを回避するの厄介だった。バーの高さは通常PCで32pxでタブレットやスマホビューで46pxに変わる。adminバーはスクロールしても上部に固定されているが、スマホビューでは挙動が変わり、固定がなくなる。その高さと挙動に合わせて fixed している position を CSSやjavascriptで調整。

やり取りを繰り返し、2020年4月26日にレビューが終了した。
即日 wordpress.org にあるテーマページが公開されて、7,472点あるディレクトリ掲載テーマ (2020年4月28日現在) の一員に加わりました。
晴れて Theme Developer になりましたとさ。

WordPressテーマを公式ディレクトリ登録してみてよかったこと、感じたこと

  • WordPressエコシステムの土台に乗って世界中で幅広い人に使われるように、レビュー済みで一定の品質基準を確保した WordPressテーマができた。
  • いままでテーマの公式ディレクトリにはあまり縁がなかったけど。独自機能を実装したテーマと公式ディレクトリに掲載される準拠さをもったテーマとの技術的な比較基準をもつことができた。
  • 公式ディレクトリに登録されているテーマの完成度が上がっている。これからも上がっていく感。よく言及されるスクリーンショット映え感ではなく技術実装面で。以前はブログ用途とかスキン的な感じのテーマが多かったりソースコードを見るとグチャグチャな感じも見受けられたけど。ブロックエディタとの兼ね合いなのか技術的にそれなりのレベル、また幅広くトータルなレベルが求められている感じがする。今後テーマを一人で作り切るのはスキル的に求められるものが多くなりそうで大変そう。チームでテーマを開発するとかに進むのかなぁ。
  • 機能面の充実より、用途の提案とか、コンセプト面の充実がテーマに求められそう。そのほうが活用の広がりが生まれる。
  • 今回テーマを作ったり、WordPressテーマスタータキット「WP Theme Boilerplate」を開発したりしてきて。WordPressテーマの開発は、スクラッチから作ったり、フレームワークから作ったり。公式テーマや無料有料テーマのありあわせものでサクッと立ち上げたり、カスタマイズしたり。多様なアプローチが取れるようになってきていると思う。その都度ふさわしいやり方を選んでプロジェクトが進められそう。プロジェクトマネジメント面の発展とかにつながる。

可能性が広がっているなぁと感じる今日このごろです。

さくらのレンタルサーバでSSH接続して環境を整える (AWS CLIをインストールするまで)

SSH接続ができるレンタルサーバーも増えてきました。
さくらのレンタルサーバもそのひとつ。
今回 AWS CLI を使いたいため、さくらのレンタルサーバ (スタンダードプラン) にSSH接続して、AWS CLIをインストールしてみました。

ターミナルでさくらのレンタルサーバにSSH接続。

さくらのレンタルサーバのサーバー環境は、

  • FreeBSD
  • 標準のシェルが csh
  • 標準のテキストエディタ vi
  • Python が 2.7.x

という環境です。

さくらのレンタルサーバは、git や WP-CLI もすでにインストール済みで結構使える。

まずは、環境を整える

  • 標準のシェルを bash
  • 標準のテキストエディタ vim

に変更。

ログインシェルを bash に変更する

chsh コマンドでログインシェルを bash に変更する

chsh -s /usr/local/bin/bash

設定ファイルを作る。

touch ~/.bash_profile
touch ~/.bashrc

.bash_profile の中身を書く。

vi ~/.bash_profile
if [ -f $HOME/.bashrc ]; then
    source $HOME/.bashrc
fi

PATH=$PATH:$HOME/bin:$HOME/usr/local/bin:$HOME/.local/bin
export PATH

一度ログアウトして再ログインする。
ログインシェルが bash に切り替わる。

標準のテキストエディタを vim に切り替える

which vim

すると、vim はすでにインストール済みなので。

.bashrc の中身を書く。

vi ~/.bashrc
alias vi='vim'

vim の設定を変える。ここはお好みで。

  • カーソルキーでカーソル移動ができるように (カーソルキーでABCDと入力になるのを避けるため、vi互換モードを off に。通常のカーソル移動は「h,j,k,l」)
  • バックスペースキー (Macだとdeleteキー) で文字を削除できるように

以上の設定は、.vimrc を作って。

touch ~/.vimrc
vi ~/.vimrc

以下を設定。

set nocompatible
set backspace=indent,eol,start

一度ログアウトして再ログインする。
以上、環境を整えた。

Pythonのパッケージ管理システム pip をインストール

AWS CLI は、pip経由でインストールするため。
まずは pip をユーザー権限でインストールします。

Pythonの設定ファイル .pydistutils.cfg を作って設定。

touch ~/.pydistutils.cfg
vi ~/.pydistutils.cfg
[install]
user=1

インストール先は、ユーザーディレクトリになるため
以下のPATHを .bash_profile に設定してあらかじめ PATH を通しておく。(この記事ではすでに通し済みです)

$HOME/.local/bin

インストールの準備が整ったところで、pip をインストール

easy_install pip

インストールが完了したところで。

pip -V

バージョンが表示されていたら無事完了。
以下が表示されるなら。PATHが通っていないかも。

pip: Command not found.
source ~/.bash_profile

で、bashの設定を再読み込みして再度確認。

以下でユーザーディレクトリにインストールされたことが確認できる。

which pip

/home/<user>/.local/bin/pip

AWS CLIをインストール

AWS CLIを pip 経由でユーザーディレクトリ先にインストール。

pip install awscli --upgrade --user

インストールが完了したところで確認。

aws --version

aws-cli/1.17.2 Python/2.7.16 FreeBSD/11.2-RELEASE-p14 botocore/1.14.2

インストール先も確認。

which aws

/home/<user>/.local/bin/aws

これで、さくらのレンタルサーバで AWS CLI が使えるようになった。

WordPressプラグイン「Custom Post Type Widgets」のウィジェット「最近の投稿」でアイキャッチ画像を表示する

WordPressプラグイン「Custom Post Type Widgets」バージョン 1.2.0 からフィルタフックやアクションフックを追加したり、タグ名を見直して改善しました。フィルタフックやアクションフックを使って機能を追加したり、カスタマイズできる余地が広がりました。

今回、アクションフックを使ってウィジェット「最近の投稿」でアイキャッチ画像を表示するサンプルを紹介したいと思います。

アクションフックは、
それぞれの投稿リストの前に追加できる custom_post_type_widgets/recent_posts/widget/prepend を使います。

サンプルコードは以下の通りになります。

function cptw_hooks_setup() {
  add_action( 'custom_post_type_widgets/recent_posts/widget/prepend', 'cptw_recent_posts_prepend', 10, 4 );
}
add_action( 'after_setup_theme', 'cptw_hooks_setup' );

function cptw_recent_posts_prepend( $widget_id, $posttype, $instance, $recent_post ) {
  if ( has_post_thumbnail( $recent_post ) ) {
    echo get_the_post_thumbnail( $recent_post );
  }
}

こんな感じでアイキャッチ画像の表示ができます。

あとはスタイルシートでレイアウトを整えて完了。アイキャッチ画像を付けたいというときに試してみてください。

リソース

ブロックエディタにフル対応したWordPressテーマを作ってみた所感

ブロックエディタにフル対応したビジネス向けウェブサイト用のWordPressテーマ「Foresight」をつくりました

もともと去年2018年11月頃から、WordPressのブロックエディタ (Gutenberg) に対応した WordPressテーマ開発に取り組み始めましたが。いつの間にか方針転換をして WordPressスターターテーマ「WP Theme Boilerplate」を開発していました。テーマ開発は先延ばしになってしまいました。

今回ようやくWordPressテーマ「Foresight (フォーサイト)」がお披露目できてホッとしているところです。

タイミンク的に、ブロックエディタが WordPressに実装されてほぼ1年が経った頃で、その間ブロックエディタにも色々使いやすく改良が加えられて充実しつつあり、良かったんじゃないかと思います。

WordPressテーマ「Foresight」の特徴

WordPressテーマ「Foresight (フォーサイト)」の特徴は、

  • ビジネス向けウェブサイトまたはランディングページなど1ページもののウェブページが作れるように
  • 新しいエディタであるブロックエディタをフルに活用できるように

設計したテーマです。

ビジネス向けはもちろん、ランディングページはじめ、ブランディングやマーケティングで活用することを考慮して、デフォルトレイアウトに幅広なレイアウトを採用して作ってみました。ブログ・メディア向けテーマにするとサイドバーが必須になることが大半でブロックエディタの全幅・幅広なレイアウトが活かせないところもあったり。といっても必要な方にはオプション設定やテンプレートの選択でできるように作っています。

WordPressテーマ「Foresight」の公式ディレクトリへの登録は、これから登録申請する予定です。ので管理画面経由からのインストールはまだできません。しばしお待ちを。早々に試したい方は GitHub からダウンロードできますので、是非試してみてください。

ブロックエディタにフル対応したWordPressテーマを作ってみた所感

テーマのコンセプト的なことは、とりあえずテーマのプロダクトページを用意しましたので、そちらに譲ります。またテーマの技術的なことは、GitHub のレポジトリをご覧ください。この記事では、ブロックエディタにフル対応したWordPressテーマを作ってみたときに感じたことを綴ってみたいと思います。

なぜ作ったの?

4つあります。

まずは、テーマを作るのに先立って WordPressテーマスターターキット「WP Theme Boilerplate」を作ったので、これをベースに公式ディレクトリに登録されるテーマとして実績を作ることを目指しました。

2つ目がブロックエディタにフル対応したテーマを設計するというテーマ開発の動機ができた。

WordPressの関わりは、テーマ開発がはじまりで (オープンソースで公開しているのはプラグインだけで。いくつかリリースして使われているのでプラグインの人かと思われている感がありそうですが)。当時テーマを作って公式ディレクトリに登録しようと思ったが、気合を入れすぎて機能を作ったけど、プラグインテリトリなど全く知らないこともあり、登録を断念したまま時が過ぎていきました。一時テーマ販売もしたこともありますが、どちらかというとマーケティングやメディア運営が軸に活動しているところもあり、テーマ開発は、作ったテーマの改良を続けているだけでした。新たにテーマを開発する動機がありませんでしたが。

去年末に WordPress 5.0 からブロックエディタが導入されました。開発したテーマは前エディタであるクラシックエディタに対応したものがほとんどで。今回ブロックエディタに対応したWordPressテーマを作ろうという動機が少しずつ出てきたので、手を動かし始めました。ベースにある感覚は、Gutenbergを開発段階から触っていて、完成度が高まるとコンテンツ作りに集中できるなぁという感覚でした。

ツイッターでもちょこっと所感をツイートしていた。

3つ目がブロックエディタへ移行してなにかか生まれる契機になりそう、特にビジネス面で。

ウェブサイト運営の現場も変わりつつありそうなのも動機の一つになりました。

公式ディレクトリを見てみると、ブロックエディタに対応したテーマがまだまだ少ないのが現状です。今はまだブロックエディタへの移行期の途中ですね。無料有料のWordPressテーマもクラシックエディタの部分を引きずっているところがあります。(現実的には継続してアップデートを繰り返してもブロックエディタへの移行も難しいですから。特に機能部分の移行や破棄はやりづらいですね。テーマ開発者にとって辛いことですが。コツコツ頑張りましょう。ボクも以前作ったテーマで苦労している最中です〜。)

実際のウェブサイト運営の現場でも今までの業務の仕方で特に支障がないためブロックエディタに変える必要性があまり見いだせないところでしょう。クラシックエディタから使い込んでいるWordPressサイトでは、ブロックエディタへの移行もなかなか進んでいかないのも現状かと思います。

テーマの設計面やウェブサイト運営の現場など広く見渡しても一筋縄でいかず、解決策を探るべく模索がまだまだ続いていくかと思います。

その中で、特にビジネス面でなにかか生まれてくることに期待しています。その期待を見据えつつ、ビジネス向けWordPressテーマとして作ってみたところがあります。

4つ目がウェブサイト設計の知見を一層深めること。

ブロックエディタになったWordPressで、いままでのウェブページの作り方がガラリと変わります。

以前のクラシックエディタは、HTMLベースのテキスト入力 (テキストモード) あるいは見出しや太字などテキストの装飾をメインにしたビジュアル編集 (ビジュアルモード) でした。

これがブロックエディタになると、見出しや太字などテキストの装飾はもちろん、コンテンツ部分の構成やレイアウトもブロックを積み重ねるようにして作ることができます。HTMLやスタイルシートを扱わなければできなかったことが、HTMLを直接扱うことなく (ブロックエディタがその部分をうまく吸収してほとんど表に出ることなく、求められる技術スキルのハードルが下がり)、文章の作成や編集修正、レイアウト作りが誰でもできる形でウェブページが作れる。つまり、コンテンツ作りに集中できる環境がブロックエディタで実現しています。

ウェブサイトを運営する方にとっては、ホームページの開設や日々の運営していくコンテンツ作成の敷居が下がる分、ビジネスチャンスを掴みやすい環境になります。コンテンツの部分でもビジネスに発展していく機会が増えていってほしいですね。

これからのWordPressテーマ設計を考えてみる

反面、テーマ開発者はじめ、ホームページ制作やウェブサイト構築に携わっている方にとってウェブサイト構築やウェブデザインのあり方まで変わる可能性を秘めているところです。面白いところでもありますが、設計と実装面で相当の技術レベルが要求されつつあります。ウェブサイトを運営する方にとってハードルが下がるということは、設計実装面ではハードルが上がることを意味します。そこについていくことがなかなかつらい現状ですが...。

WordPressのテーマ設計面を診てみると、
ブロックエディタの導入による大きな変更は、テーマの機能として実装していた部分

  • ウェブサイト機能 (ウェブサイト全体設計の部分)
  • コンテンツ機能 (本来はプラグインテリトリに該当するかなぁ)

として機能を作り込んできたかと思います。

レイアウト機能やコンテンツを構成するコンポーネント、ウィジェット、ショートコード、ビジュアルエディタの機能拡張などを独自の設定画面を作ったり、カスタマイザに設定パネルを用意してWordPress管理画面に使いやすく実装してきました。

これからは4つのレイヤーで設計を考える

いままでWordPressのテーマ設計を考える場合、3つのレイヤーで考えるところが (テリトリにもつながるところですね)

  1. WordPress本体の機能 (標準機能)
  2. WordPressテーマの機能 (ウェブサイト機能とコンテンツ機能)
  3. WordPressプラグインの機能 (付加機能)

そこにブロックエディタが加わり、テーマの機能にあったコンテンツ機能に当たる部分がブロックエディタに移ることになると思います。以下のように。(コンテンツテリトリみたいになっていくのかなぁ)

  1. WordPress本体の機能 (標準機能)
  2. WordPressテーマの機能 (ウェブサイト機能)
  3. WordPressプラグインの機能 (付加機能)
  4. ブロックエディタの機能 (コンテンツ機能)

つまり、テーマあるいはプラグインのどちらに実装すればいいのか今まで曖昧で、はっきりしなかったコンテンツ機能の実装が、ブロックエディタの導入で明確になったことが大きいなぁと感じます。

ということで、いままでカスタマイザにあったコンテンツ機能がブロックエディタに移っていくように設計されることになるかと思います。 プラグインもコンテンツ機能を担っていたものの一部はブロックエディタ (またはカスタムブロックとして) に移りそう。特にウィジェット系はブロックエディタに統合される将来があるのかなぁとも思いますね。全体的にもブロックエディタ上に統合する形の方向にもなりそう。

またWordPressテーマ不要論もチラホラ見受けられます。が、WordPressテーマはウェブサイト全体設計として残ります。そのテーマで出来上がるウェブサイトを規定する上位の設計思想 (コンセプトの部分にあたるところ) として。WordPressテーマ「Foresight」もそんな感じで作ってみました。

WordPressは、全体を見るとなにか複雑になっているように見えますが。
設計面をこうして見ると、うまく分かれてWordPressが進化しているのが理解できますね。

ということを考えることが楽しい今日この頃です。

最近の投稿

カテゴリー

アーカイブ