カテゴリー: WordPress

WordPress(ワードプレス)に関する話題です。WordPressに関する情報、カスタマイズ、プラグイン、テーマ、などなど。

WordPress 5.0 にアップデートしてみました

ナッシュビルからこんにちは。WordPress 5.0がリリースされました。USロケールがまずリリースされています。このブログは日本語版ですが、ダッシュボードからUS版でアップデートできるのでしてみました。

このブログではひとまず特に問題はなさそうですが、まずはローカルやテスト環境でアップデートしてから、本番環境をアップデートしてください。

日本語の言語ファイルのアップデートはまだのようです。

2016年12月のWordBench Tokyoにて、プラグイン情報のLTをしてきました

先月、年末に開催されたWordBench Tokyoの12月の会で、ライトニングトークに登壇しました。ネタはプラグインの紹介で、「2016年にお世話になったプラグインと年末年始に試したいプラグイン」です。

「地味だけど改めてお世話になったプラグイン」は以前から知っている、または使ってるけど、仕事の中で今年改めてお世話になったプグインです。その中から、日本のコミュニティではあまり聞かない地味〜なプラグインを紹介しました。「2017年に向けて試したいプグイン」は、まだローカルで試した程度ですが、比較的信頼のおける情報源からだったので紹介しました。

2016年、地味だけど改めてお世話になったプラグイン(と、その作者たち)

Public Post Preview

Public Post Preview
Public Post Preview

Public Post Previewは、サイトに未登録のユーザーでも投稿のプレビュー確認を可能にしてくれるプラグインです。投稿毎に一時利用のURLを作成することで実現しています。いわゆる「このURLを知ってる人のみアクセスできるリンク共有」です。 Continue reading

WordCamp Kansai 2016 に登壇しました #wck2016

WordCamp Kansaiの1日目に「大学におけるWordPressサイトのインハウス開発」というセッションで登壇しました。

セッション概要とスライドは下記。

大学のウェブサイトをインハウスで開発、運営しており、一部にWordPressを採用しています。これまでの開発経験の中から、主に機能追加の要望に対して「できなくはない」ケースや、「シングルサイトかマルチサイトかの選択」においての意思決定についてお話します。日々の更新業務を遂行しつつ、インハウス開発を行うヒントになればと思います。

「こういう話を共有したい」と自分から応募していながら、技術の話ではなく、正解もない話を、どのようにセッションとして纏めるか難しく、かなり悩みました。伝えたかったことがきちんと伝えられたか…終わっても不安だったりします。

スタッフの方によると、参加してくださった方は14名だったそう。皆さんの環境でも参考になりうる、何かしらのヒントを得た方がいらっしゃったら幸いです。ありがとうございました。

余談

WordCampの登壇は今回が3回目です。過去のスライドはSlideShareにアップしてましたが、今回を機に全てSpeaker Deckにアップし直しました

WordPress 4.6から管理画面はネイティブフォント

WordPress 4.6から管理画面に指定されていたフォントがOpen Sansからネイティブ・フォントに変更されます。下記の記事を参考に、変更内容を調べてみました。

Open Sansからネイティブへ

3.8で管理画面のUIが一新された時からOpen Sansが指定されるようになりました。

body {
    font-family: "Open Sans", sans-serif;
}

しかし、幾つか問題点もあり、その1つがGoogle Fontsからフォントをロードせざるをえないことです。

<link rel="stylesheet" id="open-sans-css" href="https://fonts.googleapis.com/css?family=Open+Sans%3A300italic%2C400italic%2C600italic%2C300%2C400%2C600&amp;subset=latin%2Clatin-ext&amp;ver=5bf5a1af710ddc76d9b7fe8a90fede2c" type="text/css" media="all">

そこで、解決策として4.6からネイティブフォントが採用されることになりました。

body {
    font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen-Sans, Ubuntu, Cantarell, "Helvetica Neue", sans-serif;
}

ネイティブフォントの採用により:

  • より速いロード時間(特にオフライン時)
  • サードパーティー依存の解消
  • より”ネイティブ感”(ウェブとネイティブアプリの境界がなくなってきている)

が期待されます。

日本語の環境で確認してみました

Mac OS (El Capitan) で、 左から下記の組み合わせです。

  • 4.5.3 / Chrome
  • 4.6 beta 2 / Chrome
  • 4.6 beta 2 / Safari

Wordpress 4.5.xと4.6 beta 2のダッシュボード比較

ダッシュボード

Wordpress 4.5.xと4.6 beta 2の投稿一覧比較

投稿一覧

どうでしょうか?El CapitanなのでSan Franciscoになっていると思います。日本語では違いをあまり感じないですね。むしろ英語の方がウェイトが若干違うような。Matt Miklicさんの記事で、彼がOpen Sans とシステムフォントの表示比較のページを作っているので、それも参考に。

一番気になるのはWindowsの方ですね。Segoe UIらしいですが、どうなんでしょう…キャプチャとれなかったので、とれる方はぜひシェアしてください。

Jetpack等のプラグインのWP-CLIコマンドと、WP-CLI開発に関するWordCamp動画

この記事はWP-CLI Advent Calendar 2014 – Adventarの23日目の記事です。1日遅れてしまい、スミマセン…

1つの記事にするほどでもないので(汗)、今回は2つを1つにしました。

  • プラグインに含まれているコミュニティ・コマンド
  • A Journey To The Center Of WP-CLI

プラグインに含まれているコミュニティ・コマンド

WP-CLIのコミュニティ・コマンドを追加するには、コミュニティ・パッケージをインストールして追加する方法と、プラグインを有効化することによって追加する方法の2通りがあって、両方ともすでに今回のAdvent Calendarで取り上げられています。

既存のプラグインの場合、すでにWP-CLIコマンドに対応しているプラグインがあり、WP-CLIのGitHubページで確認できます。

List of community commands · wp-cli/wp-cli Wiki

Advanced Custom FieldsやBackWPup、Jetpack、WP Super Cache、W3 Total Cacheなど、すでに対応しているポピュラーなプラグインが幾つかあります。WP Migrate DB Pro のように、有料版でのみ対応している場合もあります。

JetpackのWP-CLI

その中から、JetpackのWP-CLIコマンドを見てみました。wp jetpack helpで確認すると下記コマンドがあることが分かります。

  • wp jetpack disconnect [blog|[user <user_id>]]

  • wp jetpack module [list|activate|deactivate|toggle [<module_name>]]

  • wp jetpack status

statusはこんな感じ。

$ wp jetpack status
Success: 現在 Jetpack は WordPress.com アカウントに連携済みです
Jetpack バージョンは 3.3 です
WordPress.com blog_id は 1076823 です

残念ながら、サブ・サブコマンド([~]の中)がバグで使えなくなっています。周知のバグでfixする予定ではあるみたい。

$ wp jetpack module list
<span style="line-height: 1.6471;">Warning: The `wp jetpack module` command has an invalid synopsis part: [list|activate|deactivate|toggle
</span><span style="line-height: 1.6471;">Warning: The `wp jetpack module` command has an invalid synopsis part: [&lt;module_name&gt;]]
</span><span style="line-height: 1.6471;">Error: Too many positional arguments: list

A Journey To The Center Of WP-CLI

WordCamp.tvに、現在リポジトリをメインテインしているDaniel BachhuberさんのWCNY2014の時のセッション動画を見つけたので紹介。

Daniel Bachhuber: A Journey To The Center Of WP-CLI | WordPress.tv

内容は、DanielさんがWP-CLIを使い、プルリクを送るようになったきっかけから、ユニットテストなどを用いたWP-CLIそのものの開発について語っています。

WP-CLIとCronの合わせ技でテーマの有効を予約設定する

この記事はWP-CLI Advent Calendar 2014の16日目の記事です。

WP-CLIのwp theme activateをCronと組み合わせて、テーマの有効を予約設定してみました。

Cron設定の仕方

Cronの設定については下記などを参照。

Cronを設定するには2通りの方法があるということを、実は今回知りました。crontab -eでCrontab画面を立ち上げて指定する方法と、/etc/crontab を直接編集する方法です。今回はcrontab -e方法だとうまくいかなかった(※)ので、vi /etc/crontabで直接編集しました。

※たぶんコマンドが間違えてたとかそういうのだと思われ。とはいえ、/etc/crontabを直接編集する方が分かりやすいと思いました。

例えば、12月16日13時45分に設定をするには下記の様に記述。user-nameには実行するユーザー名が入ります。

45 13 16 12 * user-name 何かの処理

なお、これだと実際は毎年12月16日13時45分に処理を行うという設定なので、1回だけであれば実行された後に手動で削除する必要があります。

VCCWを使ったローカル環境で試してみる

まずはローカルのVCCWで試してみました。VCCWは現在の日付・時刻をdateで確認するとUS時間でした。なぜだろう…en_US設定だからかな。ともかく、今回はテストなのでその時間に合わせてCronを設定。下記は12月15日17時14分にTwenty Fifteenを有効化する設定です。

47 17 15 12 * vagrant /usr/local/bin/wp --path=/var//var/www theme activate twentyfifteen

なお、vagrantユーザーでは/etc/crontabの編集はできなかったで、suする必要があります。実行するユーザー名はvagrantでも問題なかったです。

本番環境で試してみる

ローカルでうまくいったので、実際に本番環境、つまりこのブログ、で試してみました。

“`0 2 16 12 * /usr/local/bin/wp –path=/path/to/wordpress theme activate wilson

1 2 16 12 * root /usr/local/bin/wp –path=/path/to/wordpress nginx flush“`

これも問題なく有効化。2行目はNginx Cache ControllerのWP-CLIコマンドで、Wilsonというテーマをactivateした1分後にNginxのキャッシュをフラッシュしています。

/usr/local/bin/wpはWP-CLIの場所。/path/to/wordpressはWordPressのインストール場所。環境/サーバーによって違うので、正しく設定する。ここが一番注意するところかもしれません。僕も何回か間違えて設定し直しました。また、path=〜パラメータは wpの直後に記述する必要がありました。下記のように記述するとうまくいきません。

0 2 16 12 * /usr/local/bin/wp theme activate wilson --path=/path/to/wordpress

12月16日に試したこと

テストがうまくいったので、12月16日(つまりAdvent Calendar16日目…)にこういう設定をしておきました。

0 8 16 12 * root /usr/local/bin/wp --path=/path/to/wordpress theme activate highwind
0 13 16 12 * root /usr/local/bin/wp --path=/path/to/wordpress theme activate wilson
0 19 16 12 * root /usr/local/bin/wp --path=/path/to/wordpress theme activate twentyfifteen
1 8,13,19 16 12 * root /usr/local/bin/wp --path=/path/to/wordpress nginx flush

8時にHighwindを、13時にはWilsonを、そして19時にはTwenty Fifteenが有効化されるように設定し、さらにそれぞれその1分後にはキャッシュをフラッシュ。

それぞれの時間に職場からアクセスしてチェックしてみたのですが、うまくいっていたようです。

実際に仕事で使える?

サイドバーやウィジェットの設定はテーマを変更するとそのテーマに合わせて設定し直す必要があるので、いきなり新しいテーマを予約設定するのは現実的ではないかもしれません。良いデベロッパーならば、ステージングですべてテストしている上に、ファイルとDB(もしくはそれらの差分)を簡単にデプロイできるようにしているでしょうから、実際にはそのデプロイをスクリプトにしてCron設定しますよね。

WordPressのありとあらゆる設定がWP-CLIから変更できるようになると…

WP-CLIの(特に初めての人向け)紹介でよく目にするwp theme activateですが、「1行のコマンドで新しいテーマを有効化できて便利ですよ〜」と解説しても、日常的に黒い画面を使っていない人であれば「テーマの有効化なんて管理画面からできるし、GUIで楽」ってなるかと思うんです。でも、CLIでWordPressの設定変更ができるようになることのミソは「1行で便利〜」ではなく、コマンドという文字列(スクリプト)に書き出せることです。スクリプトにさえできれば活用の幅が広がります。

たとえば、今回のようにCronと組み合わせることで、いろいろな「予約」ができるようになります。WP-CLIを使わない場合、デフォルトでできるのは投稿の予約ぐらいです。ローカル開発用にWordPressを立ち上げる時に毎回行っている設定などはスクリプトとして保存しておき、必要な時に実行すると、あとはパソコンがすべて処理してくれます。たとえばMemo: wp-cli commands for the theme reviewers. | Days in Thailand

そんなワクワク感がいいなと思ってます。

VersionPress:ファイルもDBもWordPressサイト全体をバージョン管理するプラグイン

WordPressサイト全体をGitなどのバージョン管理下におく場合、いっそのことメディアファイルとDBも併せてバージョン管理したい、と思ってしまいます。そんな要望に応えてくれそうなプラグインが先日WP Tavernでピックアップされていたので紹介。

VersionPressのサイトには開発中のキャプチャが。リビジョンのIDとコメント、"Undo" リンクに注目。

VersionPressのサイトには開発中のキャプチャが。リビジョンのIDとコメント、”Undo” リンクに注目。

チェコのデベロッパー2人が現在開発中&クラウドファンディングで資金集め中のVersionPressというプラグインです。Version Pressはインストールして有効化するだけで、後は自動的にサイト上の全ての変更をバージョン管理してくれます。全ての変更、というのは投稿や固定ページの公開、変更、削除はもちろん、設定変更など全てです。バージョン管理されているので特定のリビジョンまでロールバックしたり、リビジョンを指定しての削除もできます。更に差分だけローカル、ステージング、プロダクション間で同期もしてくれるとか…

バージョン管理に使われるのはGitです。WP Tavernのポッドキャストに開発者の1人がゲスト出演しているのですが、その中ではDBの差分を出力してGitで管理する、と言っていました。また開発者ブログの方には、初期のリリースではリモートサーバーにGitがインストール済みであることが動作条件になるが、多くのホスティングサービスはGitをサポートしていない為、できる限り早い段階でPHP版のGitを実装すると書いています

まだ開発が発表されたばかりなので、ライセンスはどうなるのか?(後日100%GPLを発表)、調達した資金は具体的に何に使われるのか?仕様は?販売形態は?など多くの疑問が飛び交っていますが、期待通りの出来に仕上がっていればとても注目されるプラグインになりそうです。

先日の登壇後にコンテンツのデプロイメントに関する質問を受けました。コードのみではなく、DBを含むコンテンツも併せた包括的なバージョン管理+デプロイメントができないだろうか?デザイナーでも扱える仕組みで何かないだろうか?ー日本でも需要がありそうですね。

リリースは2014年の後半を予定しているそうです。気になる方は定期チェックしておいては?

「WordPressサイト制作におけるデプロイメントを考える」フォローアップ #wckansai

先の投稿でも書いたとおり、6月7〜8日開催されたWordCamp Kansai 2014に参加し、公募枠で登壇してきました。

セッションを聞いてくださった皆様、ありがとうございました。

セッションのタイトルは「WordPressサイト制作におけるデプロイメントを考える〜Gitとデプロイメントサービスの活用〜」です。概要はというと、WordCamp Kansaiのサイトからの引用になりますが:

現在WordPressサイトの構築や更新には、FTPもしくはSFTPソフトを利用したデプロイメントが主流です。サイト全体の引っ越しであれば、あるいはrsyncやscpといったコマンドを使う場合もあるでしょう。しかし手動で行う作業や、不慣れなコマンドを使うことにより、ミスしたり、時間が掛かったりしませんか?

一方で、最近は開発にGitを用いたVCを実践している、あるいは検討、勉強しているという方も少しずつ増えてきている反面、実務でわざわざ使う利点をイマイチ見いだせていない…という方もいるはず。

そこでGitとデプロイツール(サービス)を組み合わせたテーマ、プラグイン、サイト全体の、より効率的かつスピーディーなデプロイとその自動化を提案します。また、WordPressサイトにこのワークフローを導入する際の注意点も考えます。

まだまだ、個人と職場両方の場で模索しながらこのワークフローを試しています。実績に基づく「これをやっておけばよい」という正解をシェアできるものではありませんが、同様に模索している方や興味ある方と現在のノウハウをシェアしあい、インスパイアしあえるきっかけになればと思います。

副題に「デプロイメントサービス」とありますが、ツールも紹介しています。アウトラインはこんな感じ。

  • What is Deploy/Deployment?
  • Today’s Agenda
  • Where should I git init?
  • Code Deployment
  • Contents Deployment
  • More Advanced Deployment Tools
  • Towards a Full Stuck WordPress Development Tools
  • Managed WordPress Hosting
  • Message

このうち、「Contents Deployment」と「Managed WordPress Hosting」は時間が足りなく飛ばしましたが、Slideshareにアップしたスライド(下記)に入っています。

伝えたかったこと

ツールやサービスなど難しいことを駆け足で話しましたが、もっとも伝えたかったことは3つの「Message」です。

  1. 何はともあれGit。
  2. よりストレスフリーなデプロイメントを目指してデプロイメントのツールやサービスを使ってみよう(車輪の再発明はしない)。
  3. Full Stack方向を意識しつつ、情報のアンテナを張り、手を動かしてみる。

特に3つめなのですが:

20140607_wpkansai-slide_ver6-Final-128

紹介したデプロイメントツールとサービスも、手を動かして使ってみないと理解しづらいと思いますし、実戦投入できるかどうか?するのであればどんなプロジェクトでできそうなのか?判断が付けづらいかと思います。しかし、WordBench Osakaを始め、関西のコミュニティではGitや翻訳など、手を動かして何かproductiveなことをしよう!と挑戦されている印象があります。Gitで一歩、いや、数歩進み始めた方が「次の挑戦に検討してみる題材の1つになれるのでは?」とは今回応募した理由の1つです。皆さんどうでしょうか?

スライドのフォローアップ

登壇後に頂いた質問では、飛ばしたContents Deploymentに関わる内容もありましたので、そのあたりを中心に下記に補足しておきます。

Contents Deployment

コンテンツ、つまりDBと/uploads/ディレクトリをローカル、ステージング、プロダクションのサーバー間で簡単にデプロイする方法ですが、選択肢はほとんどありません。更に、サーバー間で同期する方法も多くはありません。

真っ先に考えられるのはrsyncやmysqldump等のコマンドを使ったスクリプトを作成し、サーバーに置いておき、手動またはCronを使って自動で実行する手法です。URLの置換にはシリアライズされた値にも対応する必要がありますが、WordPressのDBのURL置換用のスクリプトが既に存在するのでそれらを使うと簡単です。もう既に何かしらの自動処理を独自で行ってらっしゃる方はおそらくこの方法ですよね?

WP-CLIがインストールされていれば、WP-CLIのwp dbwp search-replaceを使うのも手でしょう。wp search-replaceはシリアライズされた値にも対応しています。

より簡単に、であればプラグインの出番です。しかしこれも選択所はほとんどなく、WP Migrate DB Proと、RAMPという2つの有料プラグインぐらいしかありません。

WP Migrate DB Proはローカル、ステージング、プロダクション、それぞれのサーバーに構築したWordPress全てにインストールし、ボタン1つでDBを指定のサーバーへ、URLを適切に置換した上でアップしてくれます。Developer以上のライセンスであれば、メディアファイル(/uploads/にアップした画像など)も差分だけ転送してくれるアドオンや、WP-CLIに対応するアドオン(現在beta)も用意されています。公式サイトにはキャプチャ動画がアップされているので興味のある方は見てみてください。

RAMPは、ステージングサーバーのコンテンツをプロダクションサーバーへ差分デプロイする為のプラグインです。使用している人は少ないのか、あまり情報はありません。

Notes

注意点、もしくは要検討するべき点を3つスライドの中で挙げましたが、他にもあります。

WordPressのメンテナンスモード

デプロイ中にサイトへアクセスすると、もちろん、うまく表示されません。デプロイ内容にもよるとは思います。ですので、デプロイ中の処理も考えなければいけません。個人ブログやアクセスが少ない時間があり、差分が発生するファイルも少なければ、アクセスが少ない時間を狙いデプロイする方法がありますね。しかし、サイト全体をGitの管理下に置いているサイトや、アクセス数が多いサイトではWordPressのメンテナンスモードを使いましょう。ベストプラクティスとして知っておいて損はしない機能でもあります。詳しくは下記のサイトを参照してください。

Managed WordPress Hosting

スライドの中では海外の Managed WordPress Hostingサービスしか紹介していませんが、日本のホスティングサービスでも同様のステージング+デプロイ機能を備えているサービスがあることを後で知りました。

WordCamp Kansaiのスポンサーでもあるアイティーエー株式会社さんが運営しているWordPress専用レンタルサーバーでは、「2つの環境をセットで用意」と「2つの環境の同期」の2つ機能を実装してらっしゃるそうです。気になる方は試してみてはどうでしょうか?

VersionPress(2014-06-22 22:46追記)

コードをGitでバージョン管理するのであれば、コンテンツ(メディアファイル+DB)も何とか併せてバージョン管理できないもんだろうか?とやはり皆考えるようで、先日VersionPressというプラグインの開発が発表されていましたので記事にしておきました

WordCamp Kansai 2014でWordPressのデプロイメントについて話します #wckansai

当日朝の投稿になりましたが、今日開催されるWordCamp Kansai 2014に公募枠で登壇します。タイトルは「WordPressサイト制作におけるデプロイメントを考える」で、12時15分からです。(UST中継もされるのかな?)

20140607_wpkansai-slide_ver5.001

FTP/SFTPクライアントソフトや、Dreamweaver、Codaといった開発ツールのファイルアップロード機能などを使いデプロイしている方が多いと思いますが、Gitでファイルをバージョン管理するのであれば、Gitを活かしたデプロイ方法に挑戦してみてはどうでしょう、という話です。

Git前提の話なので、対象は主にWordPressサイトの開発においてGitを使っている方になりますが、Gitはかじったけれどあまり有効活用を見出せてない方(例えば、1人で開発してるので、とか…)にも有用な内容だと思います。

WordCampのサイトにも書いてありますが、僕自身もGitは昨年、今回紹介するデプロイは2〜3ヶ月前に実践し始めたばかりです。しかしシェアすることで皆さんと一緒に学べると考え公募に応募しました。(ブログに書けよという突っ込み置いておき…)

また、関西のWordPress勉強会はGitのワークショップや翻訳デーを開催し、手を動かすことを比較的多くやってらっしゃる印象です。今回の話は特に、手を動かすことで消化できる内容だと思うので、継続して手を動かしていくネタになれば、とも思っています。

WordCampはこれまでスタッフや実行委員長として多く関わってきましたが、登壇するのは初めてなので、もう既にめっちゃ緊張しています。ですが、出身地の大阪での登壇は楽しみでもあります。

さくらのレンタルサーバからConoHaのWordPressテンプレートへ引っ越してみた

このブログをさくらのレンタルサーバからConoHaへ引っ越ししてみました。

ConoHaはGMOのVPSサービスですが、WordPressサイトの構築・運営視点でみると最近提供が開始されたWordPressをすぐ使えるテンプレートが魅力的。このテンプレートを使うと、VPSでありながらAWSのAMIのように比較的簡単にWordPress環境を構築できる。加えて、テンプレートをチューニングしたのはデジタルキューブさんということで、これは快適そうです。

支払いもAWSと違い固定の月払い。初期費用もなく、3000円分のクーポン券も先日もらった。物は試しにと、ひとまずwaviaei.comをConoHaに引っ越ししてみました。
Continue reading

WCSF2013から

WordCamp San Francisco 2013からのメモ。

State of the Word 2013

This is just a data from wordpress.com. 50,000 blogs that were created, let’s say seven days a go, only about 4% of that is going to be active today. So we are having 96% attrition rate of people that are starting blog. We think this is actually higher for WordPress.org users, because there is additional steps, and things around plugins and themes. … 4% is riduculously low. We can improve that a lot.

State of the Word 2013: Q&A

WordPress has always made mistakes. Continuous.

Jetpackプラグインの隠し機能(イースターエッグ)

WordPressプラグインのJetpackに隠し機能を見つけました。いわゆるイースター・エッグです。

Jetpackが有効化されていると一般設定の一番下に「雪」という項目が増えています。

20131208_jetpack-easter

オンにするとサイトに雪が降ります。マウスを左右に動かすと、雪も左右に動きます。

20131208_jetpack-easter3

はい。ただそれだけです。

時期限定でサイトに雪を降らすというのはWordPress.comで2007年に追加された機能です。それをJetpackに追加したものと思います。

雪なんか降らなくていい

「そんな隠し機能なんかいらんわ!」と言う方はJetpacks Melt Snowというプラグインがあるので活用してくださいw

プラグインといっても、中身はたったの2行。下記をfunctions.phpにコピペしても雪機能を無効にできるはず(未検証)。

add_filter( 'jetpack_is_holiday_snow_season', 'jetpacks_melt_snow' );
function jetpacks_melt_snow() {
    return false;
}

おしまい。

WordFes Nagoya 2013で事例発表をしてきました。

先週の土曜日、8月31日に開催されたWordFes Nagoya 2013の活用事例発表会セッションにて登壇してきました。当日の発表者は4名で、僕はその3番目に「大学のウェブサイトをインハウスで構築・運営しています。その中でWordPressをを使っています。ノウハウを3つ紹介します。」というやたら長いタイトルで話してきました。

僕がウェブマスターとして、インハウスで携わっているのがテンプル大学ジャパンキャンパスのウェブサイトで、現在その中の4つのセクションでWordPressを使っています。その経験から3つの事柄を「ノウハウ」として紹介させてもらいました。

紹介したノウハウは次の3つです。

  • スターターテーマの選択
  • イベント機能をプラグインで実装
  • カスタム投稿タイプの名称

WordPressを採用した4つのセクションと、その利用概要。

WordPressを採用した4つのセクションと、その利用概要。

びったりな言葉が見つからず「ノウハウ」としましたが、もしかしたらお勧めプラグインやティップス、コードスニペットの紹介を期待させてしまったかもしれません。また、「みなさんスターターテーマはご存じですか」との問いかけに(少なくともその場では)ポジティブな反応が得られなかったので、初心者の方が多く、内容が難しすぎたのかもしれません。

ともかく、内容はどちらかというと制作工程の中での「設計」の部分に当たります。頭の片隅程度に置いておき、今後、役に立つ時があれば幸いです。

Ustream動画の録画がここに公開されています(3番目に登壇)が、最後の「カスタム投稿タイプの名称」は時間が足りなくなり省略したので、内容をここに少し書いておきます。

Continue reading

WP-CLIをVagrant環境で使う

先日に引き続き、もう1つWP-CLIネタ。今回はWP-CLIをVagrantと組み合わせて使う方法です。

方法と言っても、インストールと設定はMAMP環境下よりも簡単。Vagrantを使ってセットアップしたWordPressが問題なく動く環境に、公式サイトに書いてある通りにインストールします。

$ curl https://raw.github.com/wp-cli/wp-cli.github.com/master/installer.sh | bash

そして.bash_profileにPATHを通すだけです。

# WP-CLI directory
export PATH=/home/vagrant/.wp-cli/bin:$PATH

1つだけつまずいたのは、インストールが終了し、WP-CLI files have been successfully installed.と表示されるにもかかわらず、きちんとインストールされなかったこと。表示されたコメントに下記が含まれていたので、gitをインストールして解決しました。

sh: git: コマンドが見つかりません

WP-CLI本体のインストールが終われば、次はwpコマンドでWordPressをダウンロードし、wp-config.phpの設定と、インストールを行うだけです。例えば下記のように進めていきます。(ディレクトリやDB情報、url等は適当に置き換えてください)

$ mkdir /vagrant/wp
$ cd /vagrant/wp
$ wp core download --local=jp
$ wp core config --dbname=vagrantwp --dbuser=root --dbpass=root
$ wp db create
$ wp core install --url=192.168.33.10/wp/ --title="WP-CLI on Vagrant test" --admin_name=admin [email protected] --admin_password=admin

これで、http://192.168.33.10/wp/にWordPressがインストール&セットアップされる。http://192.168.33.10/wp/へアクセスし、問題なくインストールがされていれば完了です。

ss_2013-08-23 0.19.33

Varying Vagrant Vagrantsを使う

ちなみに、VagrantでWordPressに最適な環境だけさくっと作ってしまいたいのであれば、Varying Vagrant Vagrantsを使うのが手っ取り早いかもしれません。MAMP/XAMPを使ったWordPress開発環境をリプレイスする目的で作られており、Ubuntuをベースに、WordPressを動かすためのphp、mysql、nginxの他、NodeJS、grunt-cli、WP-CLI、git、subversion等の便利なパッケージも既に組み込まれています。サーバーの設定は、米国の10up社が一般的な高トラフィックのWordPressサイト用にセットアップする設定に合わせているそうです。

※10up社はWordPress.comのVIPパートナーで、コアコミッターも何人か所属している会社です

Varying Vagrant Vagrantsのインストール

Githubのページのここに書かれている手順を沿っていけば問題ないはず。大まかには、git cloneして、vagrant upして、hostsファイルに1行追加して終わりです。

http://local.wordpress.dev/には最新の安定版が、http://local.wordpress-trunk.dev/には最新のtrunk版がインストールされています。更にhttp://build.wordpress-develop.dev/には最新のtrunk版とGruntを組み合わせたセットアップがされているなど、結構高度な仕様となってます。

詳しくは関連記事Wikiを参照。

2013-09-14追記:
より詳しくはをかもとさんが書かれた記事を参考にしてください!
Varying Vagrant Vagrants で WP 開発環境を手に入れる | dogmap.jp

WP-CLIをMAMP環境で使う

WP-CLIはコマンドラインからWordPressをコントロール(インストールしたり、アップデートしたり、設定を変更したり、など)するためのツールです。Taiさん(@tekapo)が分かりやすい記事を2つ書かれているので、まずはそちらを参照してくだい。

MAMP環境で使おうとするとエラーがでるのと、WP-CLIの方もバージョンアップされているので、その辺りを書いておきます。先日開催されたWordCamp San FranciscoでもWP-CLIのセッションがあったので、それも参考にしています。
Continue reading

WordPressのカスタム投稿タイプに専用の権限を設定してユーザーにアサインする

カスタム投稿タイプを設定すると、そのcapability_typeはデフォルトではpostになります。なので、例えば特定のユーザが属しているroleから、edit_postのcapabilityを削除すると、そのユーザーは投稿もカスタム投稿タイプも編集できなくなります。もう1つ、デフォルトで設定できるcabapility_typeにpageがあるのですが、こちらも固定ページのcapabilityを削除すると同様の結果になります。

そこで、カスタム投稿タイプにその投稿タイプ専用のcapabilityを設定すれば、他からは独立した権限設定が可能になります。

まずregister_post_type()の$argsにcapability_typeとmap_meta_capを追加。

function register_custom_post_types() {

    // set up the arguments
    $speakers_args = array(
        'labels' => array( ~省略~ ),
        'public' => true,
        'supports' => array( 'title', 'editor', 'thumbnail' ),
        'has_archive' => true,
        'rewrite' => array( 'slug' => 'speaker' ),
        // add capability for Speaker
        'capability_type' => array( 'speaker', 'speakers'),
        'map_meta_cap'=> true
    );
    // register this post type
    register_post_type( 'speakers', $speakers_args );

}
add_action( 'init', 'register_custom_post_types' );

これでcapabilityの設定が追加されることになるが、このままではどこのRoleにもアサインされていない状態なので、administratorにアサインする。

function tujicas_roles_set() {

    global $wp_roles;
    $role = get_role( 'administrator' );
    if ( $role ) {
        $role->add_cap( 'edit_speaker' );
        $role->add_cap( 'read_speaker' );
        $role->add_cap( 'delete_speaker' );
        $role->add_cap( 'delete_speakers');
        $role->add_cap( 'edit_speakers' );
        $role->add_cap( 'edit_others_speakers' );
        $role->add_cap( 'delete_others_speakers' );
        $role->add_cap( 'publish_speakers' );
        $role->add_cap( 'edit_published_speakers' );
        $role->add_cap( 'delete_published_speakers' );
        $role->add_cap( 'delete_private_speakers' );
        $role->add_cap( 'edit_private_speakers' );
        $role->add_cap( 'read_private_speakers' );
    }
}
add_action( 'init', 'tujicas_roles_set' );

$role->add_capに指定する項目は必要に応じて。各roleへのcapabilityの細かな設定は、上記のコードに追記してもよいですが、僕はMembersプラグインを入れて管理してます。

このトピックはあまり詳細に文書化されておらず、ググっても2~3年前の記事しかでてきません。ということで、メモ程度に記事にしてみました。

WordPress 3.6について話してきた

先週末、WordPress MeetupにてWordPress 3.6について(英語で)話してきました。今回のアップデートはマーク・ジェクィース(Mark Jaquith)3.6の開発前に提案していた通り、コンテンツ編集機能の強化にフォーカスされています。

20130519_wmt.007

WordPressの利用目的に関係無く、コンテンツの編集は必ず使う機能なので、デベロッパーにとっても、ユーザー/ブロガーにとっても興味深いアップデートではないでしょうか。

20130519_wmt.008

今回のアップデートは主に7つに絞ることができますが、このうち4つがコンテンツ編集関連です*。4つとも新しい機能ではなく、既存の機能をより使いやすくしたアップデートです。Betaで使ってみましたが、この中でPost Lockingが最も即効性高く便利さを感じられる機能だと思いました。
*但し、Editorial Flowは3.6からは外れました。

2013-05-30追記:投稿フォーマットUIの変更は、3.6のコアからは取り出し、まずはプラグインという形で開発が進められいくことに。ちょうどMP6のような進め方です。

20130519_wmt.012

テーマを作成する方は、投稿フォーマットUIの変更に伴い、theme_support()の書き方や、the_post_format_imgae()the_remaining_content()等の新しいテンプレートタグも導入されているので要確認。投稿フォーマット使ってないよ、と言う方も一度チェックしておくといいかも。この辺のことは今のところwptuts+の記事が一番詳しいです。

20130519_wmt.016

新しいデフォルトテーマのTwentyTwelveは、デザインが個人的に好みでないのですが、:before:afterがガンガン使われていたり、calchyphensが使われていたり、background-colorがrgbだったり、レティナ対応してたりと、CSSのコードの方をむしろじっくり読みたい感じです。

WordPressはWeb Operating System

少し前になりますが、The DradCastのエピソード007にマット・マレンウェッグが出演してました(Episode 007: WordPress OS)。その中で「10年後にWordPressはどうなっているだろうか?そもそも存在するだろうか?」という質問に対してディスカッションがあり、この中でマットがこういう興味深いことを言ってます。

When you think about it, we’re kind of building a web operating system. We are building something that other people can build of.

よく考えてみれば、僕たちはウェブ・オペレーティング・システム(OS)を構築してるみたいなもんだよ。他の人たちが何かを作る際の土台になれる物を作っているんだ。

WordPressがアプリエンジンとして使われ始めているのは去年前半の話題でしたね。行きつく先はウェブOSなんでしょうか。ビジョンとしては興味深いことを話してました。(正しいのか?/進むべき道なのか?というのはまた別の話)

他にディスカッションされていたトピックは大体こんな感じ(ほぼ時系列)。

  • WordPress.orgにプレミアムプラグインが無い件
  • テーマの為に金を払うのと、プラグインの為の金を払うのはバリューが違う?
  • WordPress.orgサイトはどあるべきか
  • WordPress.orgに要望・アイデアを述べたい時にどうしたらよいか
  • (他のCMSと比較して)WordPressの強みの1つは後方互換
  • WordPress、10年後は?
  • WordPressを汎用ではなく、目的別に分けていくべきかどうか
  • プラグマティックに
  • モバイルアプリ
  • WordPress.comのReader。(フォロー機能。参考:「RSSの次」の可能性をWordPressが見せてくれたかもしれない – カイ士伝
  • 100% GPL
  • WordPressとビジネス
  • WordCamp San Diegoの2nd day – 将来のWordCampにはビジネストラックも?
  • 専門分野化したWordCamp?
  • マットが先日うっかり漏らしてしまった(?)今開発をしている高速化の技術。キャッシュを活用してもオーバーヘッドは発生するので、どうのこうの…(1:02:00あたり)
  • WordCamp SF

動画はDradcastのサイトにもありますが、こちらにも貼り付けておきます。10年後のWordPress~、は42:20あたり。全体的におもしろかったので、興味のある方は是非。

http://youtu.be/jkWiygLIkQI

WordPress Codex 日本語版の「テーマの作成」の訳を3年ぶりに最新版に更新しました

WordPress Codex日本語版テーマの作成ページの訳を、最新版に更新しました。最後に最新版に更新されたのはNaoさんによる2010年6月なので、約3年ぶりです。

情報量は約2倍

2010年6月と言うと、ちょうどWordPress 3.0がリリースされた頃。テーマ作成に関する全体的な流れに大きな変更はありませんが、細部に変更が多くありました。削除された箇所、更新もしくは言い回しに変更があった箇所はもちろんですが、何よりも追加分が多かったです。得にテーマテンプレートファイルのセクションがガッツリ追加されてます。更新前と比較して、ページの長さは2倍くらいかな。

もちろんコードも更新されてます。

テーマの作成からコードだけコピペして使ってた方もチェックしておいてください。変更されてます。たとえば、「WordPressの公式テンプレート階層チャートで命名規則をチェック | バニデザノート」という記事に書かれている、「テーマの作成」の「クエリベースのテンプレート」に書かれているという下記のコードですが…

if (is_category(9)) {
   include(TEMPLATEPATH . '/single2.php');
} else {
   include(TEMPLATEPATH . '/single1.php');
}

現在はこうなってます。

if ( is_category( '9' ) ) {
    get_template_part( 'single2' );
} else {
    get_template_part( 'single1' );
}

get_template_part()

include()get_template_part()も、一見同じこと(ファイルをインクルード)をしているので、動けばどちらでも良いと思われるかもしれません。ですが、get_template_part() は、SSLの判定や、ファイルが存在しない場合の処理など、裏側で幾つか重要な処理を追加で行っています。加えて、$name引数を使って、親テーマ化も視野に入れた柔軟なカスタマイズが可能なコーディングも最近では当たり前のようにあります。デフォルトテーマもそう。

詳しくは下記参照。

まだまだあります

そういえば、最終更新が3.0リリース直後でしたが、3.0から実装されたget_template_part()タグや、マルチサイト機能実装に伴うユーザー権限周りの変更など、3.0からの変更点もCodex日本語版には反映されてませんでした。たぶん、英語版もまだ更新されてなかったからでしょう。

と言うわけで、3.0以降の変更にようやく対応。同様に、3.0頃から翻訳の更新が滞っているページもたくさんあるので、WordPressに貢献してみたい方は是非!
人気あるけど更新が滞っているのとか、どうですか?

Posts 2 Posts プラグインを翻訳しました

今日(4月13日)行われた翻訳もくもく会@Co-Edoへ行ってきました。この会に参加したのはこれで2回目。

今回はPosts 2 Postsプラグインを翻訳しました。作者へも送るつもりですが、ひとまず.poと.moファイルはgithubにアップしてます作者へpull requestし、マージされました

あとは、3年近く更新されておらず(最終更新日:2010年7月31日)気になっていたCodexのテーマの作成ページの更新に手を付け始めました。こちらは英語の最新版が結構長文になっているのでもう少し時間がかかりそうです1ヶ月かかりましたが、更新完了

翻訳もくもく会?って方は直子さんの記事を参照してください。
翻訳もくもく会 @ Co-Edo(コエド)でいろいろ翻訳しました – ja.naoko.cc

カスタム投稿タイプのFAQページを作りながら、WP_Query、rewind_posts、query_posts、pre_get_postsの表示パフォーマンスを比較してみた

サイトのFAQ一覧を1ページで表示する場合、ページ内リンク付きのQuestionsリストをページ上部に、各QuestionsとそのAnswerをその下に表示するやり方がありますよね。ちょうど下図のキャプチャのような感じです。

ページ上部にQuestionsのリスト。その下にQ+Aの一覧。(仕事で携わっているサイトのページから)

ページ上部にQuestionsのリスト。その下にQ+Aの一覧。
仕事で携わっているサイトのページから

WordPressで構築したサイトにおいてFAQを機能として実装するとなると、カスタム投稿タイプを使うやり方がまず考えられます。タイトル欄にQuestionを、本文欄にそのAnswerを入力。そうすると、カスタム投稿タイプのアーカイブ表示を利用するだけでQuestions + Answerの一覧部分を表示することができます。

ではページの冒頭に表示する、ページ内リンク付きQuestionリストはどのように表示すればよいか?

やり方は幾つかありますが、今回はWP_Query()rewind_posts()query_posts()pre_get_postsを使い、下記の3つの値で表示パフォーマンスを比較してみました。

  • DBへの総クエリー数
  • DBへのクエリー所有時間の総和
  • 処理速度の総和

Continue reading

より良いWordPressテーマ開発のための7つのティップス

WordPressコアの貢献者で、Automattic社のKonstantin KovsheninさんがWordCamp Norway 2013で登壇された「より良いテーマ開発のための7つのティップス」が良かったので紹介。テーマを作る時に心がけておきたいベストプラクティス的なものです。

  1. get_template_partはトモダチだ 
    ― get_template_partincluderequireとはちょっと違うユニークなプロセスでファイルをインクルードする。
  2. スクリプトとスタイルはenqueueする 
    ― 必ずwp_enqueue_scriptwp_enqueue_styleを使うこと。
  3. Theme OptionよりもCustomizer 
    ― テーマのカスタマイズ設定はTheme OptionとCustomizerの両方もしくはどちらか1つ実装できるが、これからはCustomizerの方に集中しよう。Customizerの方がよりエンドユーザーにはより良いユーザーエクスペリエンスを提供できる。
  4. Editorスタイルを追加しよう 
    ― 公式レポジトリにある1600以上のテーマにeditor styleが含まれているのはわずか200。これじゃあリッチテキストエディターは使われないよね。実装は簡単だし、CSSもコピペすればOK。
  5. query_posts使うべからず 
    ― これば僕の一番のお気に入り。WP_Querypre_get_posts、そしてquery_posts。どれも2つ目のクエリーを走らせるのは同じだけど、query_postsだけ特殊で実行する。query_postsはメインクエリーを変更するのではなく、丸ごとそっくり差し替えるんだ。だからきちんと理解できてないととんでもないことになる。僕の経験からいって、サブクエリーを作りたければWP_Query、メインクエリーを変更したければpre_get_postsもしくはrequestフィルターを使うと良い。
  6. スクラッチから作り始めない 
    ― スクラッチから作るのはつらい。子テーマ、テーマフレームワーク、スターターテーマを使って効率的に開発しよう。車輪の再発明はしないように。コードの再利用は良いプログラミング慣行だよ。
  7. ツールをよく知っておこう。 
    ― 僕が開発時に使っているツール: Theme Check、Theme Unit Test、Log Deprecated Notices、Debug Bar + Debug Bar Extender + Debug Bar Console、Monster Widget、WordPress Beta Tester、Core Control。

勢いで訳したので、原文確認をオススメです。登壇内容が本人により分かりやすくまとめられているので、是非原文を読んでください。スライドと動画もアップされてます。

7 Tips for Better WordPress Theme Development – Konstantin Kovshenin