マイペースクリエイターとクリエイターはWordPressとWordくらいちがいます。WordPressを中心としたWeb系の覚え書き。
このサイトの存在意義・コンセプト等については「このサイトについて」のページをご一読くだされば幸いです。
だいたいが自分用の覚え書きだったり学習記録だったりします。
読者ターゲットは、Web制作の勉強を始めて間もない人とか、独学でやっててイマイチ自信の持ててない人とかです。でも一番の読者は自分です。
今後は先輩Web屋さんにも役立ててもらえるような記事を書けたらいいなって思います。
この記事はWordPress Advent Calendar 2016の20日目として書いています。
19日目のdenari01さんからのリレーです。
コアコミッターの皆さん、翻訳チームの皆さんいつもありがとうございます。
さて、WordPress4.7の新機能といえば、なんといっても長らく「やるやる詐欺」とも言われていた(?)WP REST API のコアへの実装でしょうか。
しかし、クライアントワークでひたすらブログやコーポレートサイトを作り続けている我ら下層ウェブ制作者にとっては、新関数get_theme_file_uriの登場こそ、待望されていたのではないでしょうか！
get_theme_file_uriについては、Make WordPress Coreのこのスレッドにて紹介されています。
wp_enqueue_script( 'my-script', get_theme_file_uri( 'js/my-script.js' ) );
The above code enqueues the URL of thejs/my-script.jsfile from the child theme if it exists, falling back to the URL of the file in the parent theme. Now your parent theme can enable each of its enqueued assets to easily be overridden by a child theme. And of course, if no child theme is in use then the function simply uses the parent theme URL, just likeget_template_part().
この部分に、胸踊りました。
上記（例）のコードでは、js/my-script.jsファイルがまず子テーマに存在するかどうかチェックし、なければ親テーマの同名ファイルを探しにいってくれるというのです！
WordPressでクライアントワークを長らくやっている人なら、こういうようなサイトの作り方をしたことがあるんじゃないでしょうか？
こういう場合って、デザインはほぼ親テーマのベース流用でOKだけど、細かい部分で調整が加わるからまったくそのままは使えない、ということが多いです。
WordPressの子テーマの場合、これまでテンプレートファイルはオーバーライド機能が備わっていましたが、それ以外のパーツについてはオーバーライドされませんでした。
つまり、index.phpやheader.phpなどのPHPファイルについては、親テーマと変えたい部分のファイルのみ同名で用意しておけば、子テーマ側に存在するファイルはそっちが読み込まれ、ないものは親テーマのものが使われていました。
しかし、画像やCSS, JavaScriptなどのパーツファイルはそうはいきませんでした。
テーマ内でパーツのuriを出力するにはget_template_directory_uriを使うと思うんですが、これを子テーマ側で使った場合、親テーマのパスを返されて「おい！」と思ったことのある方も一定数いらっしゃることでしょう。
今でもこの記事にそこそこアクセスがあるので、みんな一度は通る道のようです。
上記事の【2012.02.04追記】にも書いたように、子テーマ内のファイルを参照するには get_stylesheet_directory_uriを使うことになります。
事前に、パーツごとに親テーマのものを参照するか子テーマ側で新たに用意するか検討して、コード側でget_template_directory_uriを使うのか、get_stylesheet_directory_uriを使うのか選択する必要がありました。
これの設計が結構めんどくさい！
ところが、get_theme_file_uriを使えばもう悩まなくてよいのです。
悩むことなくget_theme_file_uriを使っておけば、後からオーバーライドしたいパーツが変わっても大丈夫。
子テーマに入れるか、入れないかだけで勝手に対応してくれる。
いやぁ、楽になります。
ただ、ひとつだけいいたい。
「ちょっと遅いよ！」
レスポンシブが主流になるまえのあの頃にこの関数があればよかった。。。
get_template_directory_uriも現状非推奨になったわけじゃないので、そのまま使っていても問題ありません。
運用中のサイトで慌てて書き換える必要は今のところありませんが、新しくテーマを作る際はget_theme_file_uriを使うのが良いと思います。子テーマ関係なくてもget_template_directory_uriの代わりに使えます。
※子テーマでも明示的に親テーマのパスを出したいときに使えるget_parent_theme_file_uriというのも増えました。
詳しくは前述のリンク先をご確認ください！
明日は、昨年も12/21をゲットされたねこみみ隊長(@nekomimiTaicho)です。
（なぜ21日なのかは昨年の記事を読んで納得しました）
お楽しみに！
このブログを2010年10月に立ち上げてもうすぐまる6年。小学生ならもう卒業です。
さて、私といえば「サボテンの人」とか「サボテンダーの人」って認識してくださる方が多いのですが、「実はあれサボテンじゃないんですよ」っていう説明も最近面倒になったので、サボテンとして受け入れております。
口頭で説明するのもちょっと長いですし、そんな長語りを聞かされるほどそんな興味ないと思うので、せめてブログに書いておくことにしました。
いちおうWordFesの振り返り記事です。
今回、はるばる宮崎から @miiitaka さんに飛行機で名古屋にお越しいただき、「WordPress+JSON-LDで構造化するこれからのマークアップ」というセッションを担当いただきました。
一応WordCamp Kansai 2016の同名セッションの再演なのですが、今回は45分とセッション時間も長くなり、よりブラッシュアップしていただきました。
私はスタッフ活動の合間に、サポーターブースの横のモニターでセッション中継を見ていました。
以前から構造化マークアップについて注目はしつつも、なかなかまだ業務上で要件に含まれるような案件がなく、このブログでささやかにdata-vocabulary.orgによるパンくずと、microformats.orgによるhentryについては入れてあるような感じです。
ただ、パンくずも今はGoogleでschema.orgの方が推されているようですし、全体的にちょっと古い感が出てきているのは否めません。
そんなところへ、@miiitakaさんがセッションで「構造化データをHTMLの属性に記述していくと煩雑になる。テーマと分離したい」というような趣旨のことをおっしゃっていて、
「それ！それだよ！」
と、非常に非常に共感したわけです。
テーマにはできるだけ手を入れたくないですもんねー。
そこで「JSON-LD」です。
超平たく言うと、HTMLにdata-***属性とかitem-***属性を1つ1つつけていくのではなく、1ヶ所に集めて書いちゃうという、おまとめ方式の記述のことです。
検索で数年前の情報が上位に出ているのをアップデートしたい企画第3弾（くらい）です。
wp_count_posts関数を使ってください。
以上。
Codexに「この関数は指定した投稿タイプの各投稿ステータスの投稿数を取得できます。」とありますので、たとえば「公開済み」の投稿についての総数を知りたい場合、
<?php $count_posts = wp_count_posts(); $published_posts = $count_posts->publish; echo '全記事数は'. $published_posts .'件です。'; ?>
とすればよいです。
投稿タイプ別の投稿数も取れます。
ただ、引数に配列は受け付けてくれないようなので、複数の投稿タイプの記事数を合算したい場合は
<?php $count_posts = wp_count_posts( 'post' ); $count_pages = wp_count_posts( 'page' ); $published_posts = $count_posts->publish; $published_pages = $count_posts->publish; $allposts = $published_posts + $published_pages; echo '全記事数は'. $allposts .'件です。'; ?>
て感じで別々に取って足し算すればいいと思います。
2009年くらいに書かれたブログ記事が元ネタだと思われる、以下のようなデータベースに直接問い合わせるようなコードは負荷もかかりますので、単純に全記事数を取れればいいだけだったり、コードの意味が分からない場合は使わないようにしましょう。
<?php $numposts = $wpdb->get_var("SELECT count(*) FROM $wpdb->posts WHERE post_status = 'publish' AND post_type IN ('post', 'page')"); if (0 < $numposts) $numposts = number_format($numposts); echo '全記事数は'. $numposts .'件です。'; ?>
データベースに問い合わせないといけない複雑な条件のときだけにしときましょう。
「WordPress日本語フォーラムについての話を」ということで、WordCamp Kansai 2016のスピーカーとしてお声掛けをいただき、2年ぶりに参加してきました！
orgのプロフィールページにスピーカーのバッジが付きました！
以前もWordPress日本語フォーラムに関するブログ記事は何度か書いていますが、それを焼き直し、最新の数字を加えた内容です。
フォーラム基本情報、フォーラムを使う前に調べること、いざ回答するときの配慮など、基本的には「初めてフォーラムで質問する」方向けの内容になっています。
WordPressで商品紹介サイトを構築して、1つの投稿（カスタム投稿でも可）が1つの商品紹介ページになる、というような設計になることってよくありますよね？
で、「お客さんや営業マン用に、各商品ごとに印刷用ページを生成したい」っていわれることもあったりしますよね？
WordPressで印刷用ページを生成するためのプラグインってあるんですが、どうしても簡易的なものなので、クライアントさんの思うような印刷用ページになるとは限りません。
そこで今回は、プラグインではなく自力で各投稿ごとの印刷用ページを自動生成する機能をできるだけ簡単な方法で実装してみたいと思います。
この記事は『フリーランスAdvent Calendar 2015』の14日目として書いています。まいぺーすたんことKさんこと野村です。
13日目担当のyoshipanさんからのたすきをつなぎます。
今回のフリーランスAdvent Calendarはいくつか質問が用意されていて、答えたいものを記事に取り入れることになっていますが、ちょうどよいテーマがあったので、今回はその中の「5年前、5年後のじぶんはどう思いますか？」というテーマで書きたいと思います。
2ヶ月くらい前に『WordPress4.1以降でカスタムフィールドを使い、投稿ごとにタイトルタグを自由に編集する方法（フィルターフック使用）」という記事を書いて、さらにこれをプラグイン化したものもリリースしたんですが、つい今週WordPress4.4がリリースされたら、あっさりフックが変わってしまったので、早速修正することになりました。
この記事は『パン Advent Calendar 2015』の8日目として書いています。まいぺーすたんことKさんこと野村です。
今年は技術系以外のAdvent Calendarにも参加したいと思っていたのと、今年なぜか野村家（というか旦那殿）に空前のパンブームが到来したということもあって、この「パン」にエントリーしてみました。
といっても我が家にはホームベーカリーもありませんし、自分でこねてパンを焼くといったハイソサエティーな趣味もありません。
ただひとつパンについて書けることがあるとしたら、それは今年「トースターパン」を買ったということです。
買ったのはこれと同じものです。私が買ったのはAmazonではないですし、もうちょっとだけ高かった気がしますが。。。
↓
両面エンボス鉄製 トースターパン 34600
（※Amazonへのリンクです）
WordPress Advent Calendar 2015 4日目を担当します、まいぺーすたんことKさんこと野村です。
3日目のあやかさんからのたすきをつなぎます。
さてもう6年くらいWordPressを使っていますが、いまさら初めて自作プラグインを公式ディレクトリに申請しました。
ほんとにいまさらです。むしろなぜ今までやっていなかったのか。
6年もWordPressのクライアントワークをやっていると、その都度functions.phpに書いていた機能ってけっこうあるわけです。そのうち簡単そうなものだけピックアップしてプラグイン化することはそれほど難しいことではないはずだったのですが…。
翔泳社さんより、2015/02/27発売しました。2年経ちますのでもう賞味期限切れだとは思いますが、一応実績として...
