WordPress、Web Design、Photography、その他もろもろ
WordPress（ワードプレス）に関する話題です。WordPressに関する情報、カスタマイズ、プラグイン、テーマ、などなど。
WordPressプラグインのJetpackに隠し機能を見つけました。いわゆるイースター・エッグです。
Jetpackが有効化されていると一般設定の一番下に「雪」という項目が増えています。
オンにするとサイトに雪が降ります。マウスを左右に動かすと、雪も左右に動きます。
はい。ただそれだけです。
時期限定でサイトに雪を降らすというのは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;
}
おしまい。
先週の土曜日、8月31日に開催されたWordFes Nagoya 2013の活用事例発表会セッションにて登壇してきました。当日の発表者は4名で、僕はその3番目に「大学のウェブサイトをインハウスで構築・運営しています。その中でWordPressをを使っています。ノウハウを3つ紹介します。」というやたら長いタイトルで話してきました。
僕がウェブマスターとして、インハウスで携わっているのがテンプル大学ジャパンキャンパスのウェブサイトで、現在その中の4つのセクションでWordPressを使っています。その経験から3つの事柄を「ノウハウ」として紹介させてもらいました。
紹介したノウハウは次の3つです。
WordPressを採用した4つのセクションと、その利用概要。
びったりな言葉が見つからず「ノウハウ」としましたが、もしかしたらお勧めプラグインやティップス、コードスニペットの紹介を期待させてしまったかもしれません。また、「みなさんスターターテーマはご存じですか」との問いかけに（少なくともその場では）ポジティブな反応が得られなかったので、初心者の方が多く、内容が難しすぎたのかもしれません。
ともかく、内容はどちらかというと制作工程の中での「設計」の部分に当たります。頭の片隅程度に置いておき、今後、役に立つ時があれば幸いです。
Ustream動画の録画がここに公開されています（3番目に登壇）が、最後の「カスタム投稿タイプの名称」は時間が足りなくなり省略したので、内容をここに少し書いておきます。
先日に引き続き、もう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/へアクセスし、問題なくインストールがされていれば完了です。
ちなみに、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パートナーで、コアコミッターも何人か所属している会社です
Githubのページのここに書かれている手順を沿っていけば問題ないはず。大まかには、git cloneして、vagrant upして、hostsファイルに1行追加して終わりです。
http://local.wordpress.dev/には最新の安定版が、http://local.wordpress-trunk.dev/には最新のtrunk版がインストールされています。更にhttp://build.wordpress-develop.dev/には最新のtrunk版とGruntを組み合わせたセットアップがされているなど、結構高度な仕様となってます。
2013-09-14追記：
より詳しくはをかもとさんが書かれた記事を参考にしてください！
Varying Vagrant Vagrants で WP 開発環境を手に入れる | dogmap.jp
WP-CLIはコマンドラインからWordPressをコントロール（インストールしたり、アップデートしたり、設定を変更したり、など）するためのツールです。Taiさん（@tekapo）が分かりやすい記事を2つ書かれているので、まずはそちらを参照してくだい。
MAMP環境で使おうとするとエラーがでるのと、WP-CLIの方もバージョンアップされているので、その辺りを書いておきます。先日開催されたWordCamp San FranciscoでもWP-CLIのセッションがあったので、それも参考にしています。
Continue reading
WordPress-Skeltonをローカルで試そうと思ったんだけど、何故かうまくいかない。そこでローカルにクリーンインストールしたWordPressに部分的に実装してみた。WordPress-Skeltonの仕組み全てを会社のWordPress環境には適用できないので、便利そうな部分のみ使ってみたテストの備忘録。
Continue reading
カスタム投稿タイプを設定すると、その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 MeetupにてWordPress 3.6について（英語で）話してきました。今回のアップデートはマーク・ジェクィース（Mark Jaquith）3.6の開発前に提案していた通り、コンテンツ編集機能の強化にフォーカスされています。
WordPressの利用目的に関係無く、コンテンツの編集は必ず使う機能なので、デベロッパーにとっても、ユーザー/ブロガーにとっても興味深いアップデートではないでしょうか。
今回のアップデートは主に7つに絞ることができますが、このうち4つがコンテンツ編集関連です*。4つとも新しい機能ではなく、既存の機能をより使いやすくしたアップデートです。Betaで使ってみましたが、この中でPost Lockingが最も即効性高く便利さを感じられる機能だと思いました。
*但し、Editorial Flowは3.6からは外れました。
2013-05-30追記：投稿フォーマットUIの変更は、3.6のコアからは取り出し、まずはプラグインという形で開発が進められいくことに。ちょうどMP6のような進め方です。
テーマを作成する方は、投稿フォーマットUIの変更に伴い、theme_support()の書き方や、the_post_format_imgae()やthe_remaining_content()等の新しいテンプレートタグも導入されているので要確認。投稿フォーマット使ってないよ、と言う方も一度チェックしておくといいかも。この辺のことは今のところwptuts+の記事が一番詳しいです。
新しいデフォルトテーマのTwentyTwelveは、デザインが個人的に好みでないのですが、:beforeと:afterがガンガン使われていたり、calcやhyphensが使われていたり、background-colorがrgbだったり、レティナ対応してたりと、CSSのコードの方をむしろじっくり読みたい感じです。
少し前になりますが、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なんでしょうか。ビジョンとしては興味深いことを話してました。（正しいのか？/進むべき道なのか？というのはまた別の話）
他にディスカッションされていたトピックは大体こんな感じ（ほぼ時系列）。
動画はDradcastのサイトにもありますが、こちらにも貼り付けておきます。10年後のWordPress～、は42:20あたり。全体的におもしろかったので、興味のある方は是非。
http://youtu.be/jkWiygLIkQI
WordPress Codex日本語版のテーマの作成ページの訳を、最新版に更新しました。最後に最新版に更新されたのはNaoさんによる2010年6月なので、約3年ぶりです。
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' );
}
include()もget_template_part()も、一見同じこと（ファイルをインクルード）をしているので、動けばどちらでも良いと思われるかもしれません。ですが、get_template_part() は、SSLの判定や、ファイルが存在しない場合の処理など、裏側で幾つか重要な処理を追加で行っています。加えて、$name引数を使って、親テーマ化も視野に入れた柔軟なカスタマイズが可能なコーディングも最近では当たり前のようにあります。デフォルトテーマもそう。
詳しくは下記参照。
そういえば、最終更新が3.0リリース直後でしたが、3.0から実装されたget_template_part()タグや、マルチサイト機能実装に伴うユーザー権限周りの変更など、3.0からの変更点もCodex日本語版には反映されてませんでした。たぶん、英語版もまだ更新されてなかったからでしょう。
と言うわけで、3.0以降の変更にようやく対応。同様に、3.0頃から翻訳の更新が滞っているページもたくさんあるので、WordPressに貢献してみたい方は是非！
人気あるけど更新が滞っているのとか、どうですか？
今日（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一覧を1ページで表示する場合、ページ内リンク付きのQuestionsリストをページ上部に、各QuestionsとそのAnswerをその下に表示するやり方がありますよね。ちょうど下図のキャプチャのような感じです。
ページ上部にQuestionsのリスト。その下にQ+Aの一覧。
（仕事で携わっているサイトのページから）
WordPressで構築したサイトにおいてFAQを機能として実装するとなると、カスタム投稿タイプを使うやり方がまず考えられます。タイトル欄にQuestionを、本文欄にそのAnswerを入力。そうすると、カスタム投稿タイプのアーカイブ表示を利用するだけでQuestions + Answerの一覧部分を表示することができます。
ではページの冒頭に表示する、ページ内リンク付きQuestionリストはどのように表示すればよいか？
やり方は幾つかありますが、今回はWP_Query()、rewind_posts()、query_posts()、pre_get_postsを使い、下記の3つの値で表示パフォーマンスを比較してみました。
WordPressコアの貢献者で、Automattic社のKonstantin KovsheninさんがWordCamp Norway 2013で登壇された「より良いテーマ開発のための7つのティップス」が良かったので紹介。テーマを作る時に心がけておきたいベストプラクティス的なものです。
get_template_partはトモダチだ get_template_partはincludeやrequireとはちょっと違うユニークなプロセスでファイルをインクルードする。wp_enqueue_scriptとwp_enqueue_styleを使うこと。query_posts使うべからず WP_Query、pre_get_posts、そしてquery_posts。どれも2つ目のクエリーを走らせるのは同じだけど、query_postsだけ特殊で実行する。query_postsはメインクエリーを変更するのではなく、丸ごとそっくり差し替えるんだ。だからきちんと理解できてないととんでもないことになる。僕の経験からいって、サブクエリーを作りたければWP_Query、メインクエリーを変更したければpre_get_postsもしくはrequestフィルターを使うと良い。勢いで訳したので、原文確認をオススメです。登壇内容が本人により分かりやすくまとめられているので、是非原文を読んでください。スライドと動画もアップされてます。
7 Tips for Better WordPress Theme Development – Konstantin Kovshenin