• この間、WordPressのマルチサイトモードで、8サイトくらいあるサイトを作りました。

    一つのサイトですが、更新コンテンツがとにかく大量にあっりました。
    そのコンテンツがカスタムフィールドばりばり使ったり、デザインがいろいろ違っていたり、求められる機能がいろいろ違ったりしていて、カスタム投稿やタクソノミーでは、開発しづらいし運用も大変だろうな・・・・ということで、マルチサイトで子テーマを6つくらい作りました。そのときのやったこと、やれば良かったことなどなど。

    そもそも子テーマとは

    子テーマ – WordPress Codex 日本語版

    要は、あるテーマを元にしてそのテーマを一部だけ改変したようなテーマを作成できる機能です。ただ、読み込み順は子テーマ→親テーマとなるので、子テーマに足りないものを親テーマから保管する機能と言ったほうが正確かも知れません。
    継承って言い方をしていますが、プログラミングにおけるクラスの継承とは全く別物なので注意が必要です。

    なので、get_header()とかを子テーマで、書いた場合、子テーマ内のheader.phpを探しにいって、なかった場合、親テーマのheader.phpが呼ばれます。
    また、子テーマにarchive.php、親テーマにcategory.phpがある場合は、カテゴリーページにアクセスしたら親テーマのcategory.phpが呼ばれるようです。まぁ、そうじゃないと、index.phpを作ったら全部のテンプレートを上書きってことになってしまいますもんね。

    子テーマの作成

    子テーマとしてテーマを作成するためには、style.cssの最初のテーマ用コメントに Template: 親テーマのディレクトリ名とするだけです。また、子テーマの場合、index.phpが無くても大丈夫です。
    [css]
    /*
    Theme Name: 子テーマ
    Template: parent
    */
    [/css]

    また、子テーマの子テーマ、孫テーマみたいなのは作成できません。1世代までです。

    子テーマ、親テーマで値が変わる関数や、定数

    正直全部は説明できませんが、とりあえず、

    • bloginfo(“stylesheet_directory’”)/bloginfo(“template_directory’”)
    • get_stylesheet_directory()/get_template_directory()
    • get_stylesheet_directory_uri()/get_template_directory_uri()
    • STYLESHEETPATH/TEMPLATEPATH

    の値は変わります。
    stylesheet・・・シリーズは子テーマ、templateシリーズは親テーマの情報を返します。
    なので、テーマ内で使う画像やCSS等、共通のリソースは親テーマに突っ込んでおく&なるべくtemplateシリーズでの記述ををお勧めします。

    また、is_child_theme()という関数もあるようです。

    functions.php

    functions.phpだけは存在すれば読み込まれない、という挙動ではなく、子テーマのfunctions.php→親テーマのfunctions.phpの順で両方読み込まれます。カスタム投稿・タクソノミーの設定は、子テーマのfunctions.phpに記述するといいかもしれません。

    また、

    子テーマのfunctions.php で同名の関数があれば、子テーマの関数が使用されます。

    という記述が日本語版Codexにありますが、これは、ちょっと言葉足らずで、そのまま同名の関数を書くと、「Cannot redeclare」のエラーを吐いてしまいます。なので、親テーマに再定義可能な関数を作る場合は

    [php]
    if ( ! function_exists( ‘parent_function’ ) ) {
    function parent_function() {
    // 処理内容
    }
    }
    [/php]

    としてあげる必要があります。英語版のCodexにはここら辺のこともちゃんと書いてあります。Child Themes « WordPress Codex

    また、テーマで使う変数も保護しないと上書きされてしまうのでここら辺は注意が必要です。変数の上書きはエラーにならないので、定数にしておく等の工夫が必要です。

    テーマの構造の設計における注意

    ちゃんと使いこなせば、いろいろ便利な機能ですが、ちゃんと設計しないと、「別々にテーマを作った方が、楽だった」になんてことになりかねない機能でもあります。
    なので、いくつか注意事項、というより現時点で僕が気を使っているルールです。

    親テーマを実際に使用するテーマにしない

    一番最初にマルチサイト+子テーマでサイトを作ったときに、親テーマを親サイト(ルートサイト)に設定していたために、死ぬほど苦労した結果、子テーマをやめた。なんて失敗もありました。

    親サイトはトップページなど、再利用性が低いものが入ることが多いですし、front-page.phpや、home.phpなど、テンプレートの読み込み順の優先度が高いものを使うことも多いです。これを子テーマ側でいちいち作成するのはとても面倒。無駄。これだけは絶対やってはいけないです。

    また、親テーマを実際に利用していると、「このサイトではカテゴリーも月別アーカイブも全部一緒でいいのに・・・・」みたいなことが発生し易いです。
    なので、親テーマに置くのは、ほんとに共通で使い回す部分だけ&テンプレートの読み込み順が低いもの例えば、

    1. header.php/footer.php等のモジュール系
    2. archive.php
    3. index.php
    4. テーマ内で使い回したい関数、ヘルパー等のライブラリ

    等に留めましょう。

    親テーマのfunctions.phpの肥大化を避ける

    別に子テーマを使ったりしなくてもという話でもあるんですが、マルチサイトは基本的に大きな案件にならないと使わないとは思いますが、そうなってくると、どんどん全部で使い回すようなカスタマイズが、functions.phpに蓄積していきます。

    ただ、管理画面のカスタマイズなど、テーマとの関連性が薄いもの、すべてのサイトで活用するものはfunctions.phpではなく、プラグインにして極力テーマの見通しを良くしましょう。カスタム投稿タイプ等は冗長になりがちなので、プラグインで関数を作るなりクラスを作り、それをテーマで使い回す等が便利だと思います。

    その他やっておいた方が、いいかもと思うこと。

    body_classにサイト名を出力


    をプラグインとかfunctions.phpに書いておくと、site-hogeみたいなクラスを吐くので便利かもしれません。特にテーマを識別する手段が無いので。。

    blog_idに依存しない

    特にテーマを別環境で作っているときは気をつけたいのですが、現在のサイトを識別する手段が、グローバル変数の$blog_idくらいしか無かったと思います。ただ、テーマにIDを直書きするのはメンテナンス性を欠くので、get_id_from_blogname( “hoge” )とかで、パスで指定する方が設定とテーマの分離ができて良いのかなと思います。

    前回の記事でもそんなとき使えるものを書きました。

    https://torounit.com/blog/2013/04/25/1514/

    WordPressのマルチサイト機能3.0からMUと統合されたまだまだ新しい機能です。対応していないプラグインもあります。僕のリリースしているCustom Post Type Permalinksもちゃんと対応できておりません(汗)
    またカスタム投稿との棲み分けとかも考えないといけない部分があります。

    ただ、ちゃんと使いこなせれば、更新コンテンツが多い、ユーザーが多い案件等でもかなり使い易い構築ができるんじゃないかな・・・と思っています。

  • 最近マルチサイト案件が多かったりするのですが、各ブログを横断してリンクをつないだりみたいなことをたくさんやりました。
    扱うサイトも多く、ブログを削除して作り直して・・・みたいなことが結構あったのですが、そのときに当然blog_idもかわってしまいます。(まぁそりゃそうだよね)

    で、マルチサイトの肝になるところといえば、switch_to_blog でブログを切り替えてあーだこーだすることだとは思うのですが、これが、

    [php]
    switch_to_blog(1);
    [/php]

    みたいな感じで、変更先のブログのIDを指定せねばならないのです。これがちょっと使い勝手が悪いし、テーマを見たときにどこのブログに変わったのか、よくわかりません。

    という訳でソースを眺めていたら、get_id_from_blogname( $slug )といういかにもな関数がありました。

    example.com/hoge/ もしくは hoge.example.com

    という子サイトがあった場合、
    [php]
    get_id_from_blogname( "hoge" );
    [/php]
    とすると、blog_idを教えてくれるので、

    [php]
    switch_to_blog( get_id_from_blogname( "hoge" ) );
    [/php]

    といった感じで、サイトパスで切り替えることができます。こっちの方が解り易いですね。テーマだけ別環境で開発といった場合でもちょっとは反映作業などもスムーズになるのではないでしょうか。

    まぁ、案件も終盤になった頃に見つけたのですがね・・・・

    マルチサイトは発展途上なイメージですが、ちゃんと使うと結構いろいろなことができそう!

  • Custom Post Type Permalinksの最新版をリリースしました。

    変更内容は以下の通りです。

    • has_archiveがtrueのときだけアーカイブを設定するようにしました。
    • 個別記事のパーマリンク生成部分に大幅な変更を行いました。
    • 3.6でテストしてます。
    • リライトルールの再生成部分を変更して、パーマリンク設定を2回保存したりすることのないように
    • wp_get_archivesのURLをslugを指定したときも正常に動作するようにしました
    • 開発用レポジトリを Github (https://github.com/Toro-Unit/custom-post-type-permalinks)にうつしました
    • メディア周りのパーマリンクの不具合の解消

    has_archiveがfalseのときはアーカイブのためのパーマリンクを生成しないようにしました。おかしくなったときは、has_archiveをtrueにしてみてください。

    wp_loadedでカスタム投稿タイプをすべて取得して行っていたパーマリンク追加をregistered_post_type後に行うようにしました。WordPressの通常の挙動に近いので不具合等も減ったはず・・・・

    git-svnでトラブル多発でバグもあると思いますので、なにかあれば@Toro_Unitまでご連絡ください。

    寄付も受付中です。ビールとかビールとか大好きです。欲しいものリスト

  • 「別にテーブルレイアウトでもいいんじゃないの?」

    こんな問題提起をされまして、ちょっと僕なりの見解というか技術との向き合い方みたいなものをまとめてみようかなと思います。
    まぁ、高品質なものをアウトプットしていきたいのはそりゃそーなんですけど、それって具体的にどういうことかとかちょっと突っ込んで考えてみようと思います。

    僕なりの品質の高いWEBサイトの定義

    僕の思う高品質なサイトの要件は

    • 良いデザインであること。(視覚的・感覚的に情報にアクセスしやすい)
    • 高速であること。
    • 運用(更新・メンテナンス)がしやすい。

    の3点です。
    WEBサイトの目的はユーザーに対する情報発信のはずなので、解りやすいデザイン・情報設計、直観的なUIは本当に大切ですし、遅いサイトにイライラするのは僕らは身を以て知っています。

    WEBサイトはやはり活用してナンボ、更新してナンボです。最新の情報がすぐに発信できるというのはWEBの特性の一つですし、近年、ソーシャルメディアの発達によって、それが更に重要な要素になっていると思っています。
    そのためには、サイト管理者が容易に更新できるようにすることも大切です。そのためにCMSなどがあったりですが、ちょっとした変更などにもスムーズに対応できるようなメンテナンス性も大切です。

    WEBサイトだって保守されるもの

    静的サイトでのページ・バナーの追加だとか、ナビゲーションの増加とか、意外にHTML+CSSレベルで発生するメンテナンス作業も多いですよね。
    HTML/CSSって手を抜いても、ものすごい丁寧に作られていても、ブラウザで見ている限りあまり実感として感じられない部分ではあります。

    「このバナー急いで外して!」みたいなことがあったときに、「これ外したらデザイン崩れたけど、どうしよう・・・・。とりあえずCSSで上書きするか。」となって、更に訳が分からないCSS完成していた。なんて経験ありませんか?そしてそれに時間を奪われて仕事がろくに進まないなんてことありませんでしたか?

    一度汚せば最後、どんどん読みづらくなって僕らから

    • ほかの案件が進められたはずの時間
    • あったはずのモチベーション
    • レッドブル代

    といったものをどんどん奪っていきます。

    テーブルレイアウトはなぜだめのかの問いの答えの1つにもなるはずです。

    そして、HTMLもCSSも巨大化している

    近年のWEBデザインの発展により、HTMLやらCSSも当然巨大化してきました。HTMLにはどんどんdivやらspanが増えて、更にそれに対してCSSが当たり。近年ではCSS SpriteだのBase64encodeだの画像周りやら、Media Queriesでのマルチでバイス対応なんてものまで。

    正直普通のCSSの使いづらさったらないので、Sass+CompassやLessなどのCSSプリプロセッサを活用して、読み易く、分かりやすく書き易い方法でスタイルシートを制作するのもすっかりメジャーになった感じです。Chromeの開発者ツールもSassに対応してくれるようになりました。

    自分自身としてはCSSプリプロセッサを使わないでCSSを書くとかもう考えられないです。

    WEBデザインもかわってきている

    昔は紙のデザインの再現が求められていたWEBデザインですが、アニメーションや、パララックスなどを活用したWEBならではの表現が生まれています。こういった表現は今後もどんどん研究が進み、そのうちSVGやcanvasが普通のサイトでも珍しいものじゃなくなるのかもしれないし、そうでもないかも知れない。

    また、スマートフォン・タブレット向けサイトみたいな新たな分野も登場し、IPhoneのインターフェースと違和感のないWEBサイトのフレームワークもたくさんあります。この分野の発展も更に続くんでしょうね。

    まとめ

    ここ数年のWEBのフロントエンド周りの状況の変化は本当に激しいです。無効にするのが常識だったJavaScriptが今では有効が当たり前だったり、スマートフォン・タブレットで今までFlashの領域だった部分をHTML5+CSS3+JavaScriptがやるようになってみたり。CSSがデザイン再現言語からUI作成言語になっていたり。フロントエンドエンジニアという肩書きができていたり、ワークフローの大きな見直しなんて話題もよくあります。

    ユーザーとしての僕らはスマートフォンを使いこなし、GmailやGoogleカレンダーを使って仕事をしたり、Retinaディスプレイに感動し、HTML5のブラウザへのドラッグandドロップを普通に使い、TwitterやFacebook等でAjaxでのリアルタイム通信を当たり前のように使っています。

    自分自身がWEBのユーザーとしてどんどん新しいものを受け入れ、慣れ、当然のように感じ、使えないと不便さえ感じている、そんな状況の中、やはりWEBに関わる人間として、僕自身新しいものを当たり前のように使い、サイトだったりサービスだったりアプリケーションだったりを提供していけるWEBクリエイターでありたいです。

  • 最近、メインブラウザをFirefoxからchromeに変えたせいか、はたまたパソコンを見ている時間が多いせいかわかりませんが、ブログを書くときの文字が小さくて困ります。

    ビジュアルエディタはadd_editor_style()とかでカスタマイズできるんですが、テキストエディタはそうもいかない・・・・・

    でも僕としては、HTMLタグを使う方が楽なんですよね。

    というわけで、functions.phpでごにょごにょします。

    [php]
    function change_textarea_style() {
    ?>
    <style type="text/css">
    #wp-content-editor-container textarea.wp-editor-area {
    font-size: 14px;
    font-family: Consolas, "ヒラギノ角ゴ Pro W3","ヒラギノ角ゴ Pro","Hiragino Kaku Gothic Pro W3","Hiragino Kaku Gothic Pro", "メイリオ", Meiryo, Osaka, sans-serif;
    }
    </style>
    <?php
    }
    add_action( "admin_head", "change_textarea_style" );
    [/php]

    font-familyとかは、自分が使いやすいものを入れておけばなんでもいいです。別に、ガツガツHTMLは書かないのであれば等幅フォントにこだわる必要ないですし。

    自分色に染め上げれば、記事を書く意欲も自然と湧いてきますよね。あ、ディスプレイが小さいんじゃ・・・・とかは言ってはいけません(笑

  • Nivo Sliderといえば、もう定番のコンテンツスライダーのjQueryプラグインですよね。エフェクトもたくさんあるし、使い方も簡単ですし。

    そのエフェクトなんですけど、

    「左の矢印と右の矢印で動きを変えたい!!!!!!」

    って思ったことないですか?戻るボタンで左にスライドとか、次へボタンで右にとか。まぁ、別に僕も人から言われて「確かに!」って思ったんですけど。。。。。。

    そんなの機能としてあるでしょ!とか呑気に思っていたら、どうやらそんなものはないようなので、JQueryをガリガリ書く羽目になったわけで。そのコードをさらしたいと思います。

    [js]
    $(window).load(function() {
    var $slider = $(‘#slider’);
    $slider.nivoSlider({
    effect: "sliceUpRight",
    afterChange: function(){
    $slider.find("img").attr("data-transition","sliceUpLeft");
    }
    });

    $(".nivo-prevNav").on( "click", function(){
    $slider.find("img").attr("data-transition","sliceUpRight");
    });
    $(".nivo-nextNav").on( "click", function(){
    $slider.find("img").attr("data-transition","sliceUpLeft");
    });
    });
    [/js]

    Nivo Slider 3.2で動作を確認しています。
    Nivo Sliderはスライドする要素にdata-transitionを設定しておくと、そこに設定されているエフェクトでその要素にスライドします。その値を書き換えているだけという、なんとも単純な作りです。

    普段何気なく使っているプラグインもソースを眺めてみると、意外にあんなこともこんなこともできるんだ!って発見がありますよねぇ~。

  • Custom Post Type Permalinksをアップデートしました。

    • %post_id%を含んだパーマリンクで、添付ファイルのリンクが404になる

    という不具合を修正しました。

    その他、細かいバグフィックスを行いました。

    http://wordpress.org/extend/plugins/custom-post-type-permalinks/

    また、いつも通り、何かありましたら、@Toro_Unitまでリプライください。m(_ _)m

  • 最近カスタム投稿タイプやら、マルチサイトでのブログ一覧をいじくることがそこそこあったのですが、ちょっと注意したいことがあったのでまとめ。

    query_postsとは

    query_posts() 関数はメインの WordPress ループだけを変更するためのものです。新たなループを作るためのものではありません。メインループの他にループが必要な場合は、get_posts() を使ってください。メインループの他で query_posts() を使用すると、メインループが不正な状態になり期待する結果が得られません。

    query_posts() 関数はページのメインクエリを上書きし、置き換えます。他の目的で使用しないでください。

    query_posts() 関数は新しい WP_Query オブジェクトを作成し、グローバル wp_query 変数に割り当てます。get_posts() 関数は、グローバルエリアをまったく上書きすることなく新しい WP_Query オブジェクトを作成します。

    Codex に記載されています。 pre_get_posts を使うとこんな問題を起こさずにカスタマイズ出来ます。

    テンプレートタグ/query posts – WordPress Codex 日本語版

    まぁ、おおざっぱにいえば、WordPressのそのページで使われているループを強制的に上書きしてしまう機能です。通常はURLを解釈して、それを元に記事を探してくるのですが、それを完全に無視します。

    "トップページとかでお知らせのタイトルを5件だけ表示する"みたいなときに使うことが多いと思いますが、カスタムページテンプレートで何かの記事一覧を出したり、なんて使い方をすることもたまにあったり。

    1ページ目と内容が変わらない。

    よくあるトラブルその1ですね。URLには"paged/2"とか書いてあるのですが、query_postsで再設定してしまっているので、うまくいきません。

    解決としては、query_postsに「今何ページ目?」という情報を与えてあげればよいので、

    query_posts(array( "paged" => get_query_var('paged'), "foo" => "bar" ));

    だとかしてあげればOKです。

    ページが見つかりませんでしたと表示される。

    今回の現象です。なぜか404になってしまいます。
    上記の設定ができているのに、うまくいかないということがありました。

    WordPressのテンプレート選択は、URLを解釈して読み込まれるわけですが、アーカイブページでは、最後のページが"/page/10"などの場合、"/page/11"だとかはNot Found扱いになり、404.phpが読み込まれます。これはカテゴリーでもカスタム投稿アーカイブでも同様です。

    なので、query_postsをarchive.phpなどに書いていたとしても、archive.phpが読み込まれる前にページが存在しないという判定になります。

    たとえば投稿が100件あって、WordPressの設定では1ページ当たりの表示件数を10件としている場合に、query_postsで5件しか表示しないようにしていると、11ページ目が存在するかしないかの判定は、WordPressの設定を使うので、すべての投稿が表示されていないのに、Not Foundとなってしまいます。

    解決法1

    archive.phpとかarchive-post_type.phpとかcategory.phpだとかで、メインのループを上書きしない。

    テンプレートがちゃんと提供されているので、それをちゃんと素直に使いましょう。ということです。

    解決法2

    ただしそういうわけにもいかないときもあるとは思いますし、カスタム投稿タイプごとに表示件数もデザインも変えたい!ということはあるかと思います。

    そんなときは、pre_get_posts を使いましょう。

    管理画面から、投稿件数を投稿タイプとかタクソノミーとかで弄れるプラグイン作っているので、そちらもどうぞ。

    まとめ

    URL から得られたクエリを変更することはトラブルの元になります。条件分岐タグ のようなページの判定を組み合わせることで、URL を一切変えることなく投稿 の見せ方をカスタマイズすることができます。

    とCodexにも記載されております。pre_get_posts で安全に使いましょう。

  • タッチパッドが有効だと、たまにキーボードを打つときに触ってしまい、ポインターがわけわからん場所に飛んでとっても不愉快なんですよね。

    しかしWindows8をクリーンインストールしたりで、ドライバーがどこかに行ってしまったわけで。そしたらタッチパッドが無効にできなくて散々な目に。

    そしたら、Synapticsのドライバーを入れれば良いとかいう情報があったので、入れてみました。

    Drivers | Synaptics

    ポインティングデバイスのプロパティのほかに、タッチパッドのプロパティという、機能しないプロパティが出てきたりはしますが、とりあえず手動で無効にできました。困っている人は一度試してみてください。

  • いまさらですが、あけましておめでとうございます。HTML5KARUTAに参加させていただいたり、引っ越しがあったりでブログがろくに書けませんでした。今年もよろしくお願いします。

    そして、今回の内容ですが、元ネタは Google Calendar API から日本の祝日データを取得 | memo.dogmap.jpです。

    function get_holidays_this_month($month){
    
        $holidays_url = sprintf(
                'http://www.google.com/calendar/feeds/%s/public/full-noattendees?start-min=%s&amp;amp;start-max=%s&amp;amp;max-results=%d&amp;amp;alt=json' ,
                '[email protected]' ,
                '2013-'.$month.'-01' ,  // 取得開始日
                '2013-'.$month.'-31' ,  // 取得終了日
                31            // 最大取得数
                );
        if ( $results = file_get_contents($holidays_url) ) {
                $results = json_decode($results, true);
                $holidays = array();
                foreach ($results['feed']['entry'] as $val ) {
                        $date  = $val['gd$when'][0]['startTime'];
                        $week = date('w',strtotime($date));
                        $title = $val['title']['$t'];
                        $holidays[$date] = $title;
    
                        if( $week == 0) {
                            $nextday = date('Y-m-d',strtotime('+1 day', strtotime($date)));
                            $holidays[$nextday] = '振替休日';
                        }
    
                        $before_yesterday = date('Y-m-d',strtotime('-2 day', strtotime($date)));
    
                        if(isset($holidays[$before_yesterday])){
                            $yesterday = date('Y-m-d',strtotime('-1 day', strtotime($date)));
                            $holidays[$yesterday] = '国民の休日';
                        }
    
                }
                ksort($holidays);
        }
        return $holidays;
    }

    とりあえず1か月分の祝日を取得します。ついでに振替休日やら、国民の休日にも対応してみました。国民の休日なんてめったにあるもんじゃないんですけど、2015年にまたあるようなので、とりあえず実装してみました。イベントスケジュールとかを作るときに結構便利です。

    追記:http://memo.dogmap.jp/2013/01/25/re-google-calendar-japanese-holidays/

    確かに・・・・

  • カスタム投稿タイプとNivo-Sliderで更新しやすいスライドエリアを作る。【Advent Calendar in 信州松本(だけじゃなくてもいいよ)】

    Advent Calendar in 信州松本(だけじゃなくてもいいよ)ということで、
    昨日のthinkAmiさんの機能のGoogleDriveAPIでHTMLファイルを作成し、GoogleドライブでWebサイト公開してアルクマを追いかける – メモ的な思考的なに引き続き、19日目を担当させてもらいます。Toro_Unitです。

    Google App Engineって楽しそうですね。プログラマさんの記事を読むと夢がほんとに広がります。

    そんなわけで、「何か作りたい!」という衝動に駆られたのですが、WordPressのカスタム投稿についてのプラグインを作ってたりするので、せっかくだからWordPressのカスタム投稿タイプでちょっと変わったことをやってみました。

    WP Custom Slider:https://github.com/Toro-Unit/wp-custom-slider

    デモサイト:https://torounit.com/wpcustomslider/

    WordPressのカスタム投稿タイプ&投稿サムネイルとNivo-Sliderでコンテンツスライダーを作ってみました。

    カスタム投稿タイプ部分

    [php]
    register_post_type(‘hoge’,array(
    ‘public’ => false,
    ‘show_ui’ => true,
    ‘show_in_menu’ => true,
    ‘query_var’ => false,
    ‘capability_type’ => ‘post’,
    ‘has_archive’ => false,
    ‘supports’ => array( ‘title’, ‘editor’, ‘thumbnail’ )
    );
    [/php]

    register_post_typeのpublicをfalseにすることで、URLでアクセスできないカスタム投稿タイプを作ることができます。
    また、supports値で、使う要素を制御できます。タイトルや本文入力欄も消すことだってできます。

    詳しくはCodexを!: 関数リファレンス/register post type – WordPress Codex 日本語版

    データの取得

    これだけだと「一体何に使うんじゃい!」って感じなのですが、このデータを
    [php]
    get_posts(‘post_type=hoge&posts_per_page=-1’);
    [/php]

    みたいな形で取得することができます。
    あとは、foreachに突っ込んでやりたい放題です。

    キャプションの部分は本文入力欄を使っています。setup_postdataに取ってきた記事データを突っ込むとthe_content等のテンプレートタグが使えるんですが、今回は本文が取れれば十分だったので、

    [php]
    $content = apply_filters(‘the_content’,$post->content);
    [/php]

    みたいなやり方で、本文をもってきています。ここまでで、大体完成。

    仕上げ

    そして、Nivo-Sliderを突っ込むだけなんですが、横幅が親要素の横幅まで拡大されてしまうので、置く場所によってはサイズがおかしくなる場合があったりしますので、

    [php]
    function fix_slide_size($size) {
    return array( 960, 400 );//横幅,高さ
    }
    add_filter("wp_custom_slider_size", "fix_slide_size");
    [/php]

    みたいにフィルターフックを使って大きさをカスタマイズできるようにしています。

    [php]
    public function set_image_size() {
    global $content_width;

    if($content_width) {
    $width = $content_width;
    }else {
    $width = 960;
    }
    $size = apply_filters("wp_custom_slider_size",array( $width, 350 ));
    add_image_size("slide", $size[0], $size[1], true);
    }
    [/php]

    ただ、apply_filtersがadd_filterよりも先に実行されると困るので、’after_setup_theme’というアクションフックに登録することで、テーマの読み込みが終わった後にプラグインが機能するようにしたりします。

    使い方

    いろいろ書きましたが、使い方としては、/wp-content/pluginsにプラグインを解凍・有効化して、

    テーマの中で、表示したい場所に
    [php]
    <?php wp_custom_slider();?>
    [/php]

    と書くだけです。サイズのカスタマイズや管理画面でのメニューなどの変更は、functions.phpにフィルターフックをちょこちょこ書いてあげれば、大丈夫。

    そんなわけで出来上がったのが、こちらのデモサイトです。
    Githubにも公開しています。https://github.com/Toro-Unit/wp-custom-slider

    カスタム投稿タイプでこんなこともできます!カスタムフィールドも合わせて使うと画像のリンクのURLなどが設定できたり夢が広がります。

    APIもかなり整備されているのでプラグイン制作も意外に簡単にできてしまうのでトライしてみてください。

    次は・・・

    明日は、4_1さんです。
    Advent Calendar in 信州松本(だけじゃなくてもいいよ)にお声かけいただきありがとうございました。m(_ _)m
    あと一週間、がんばっていきましょう!

  • Custom Post Type Permalinks 0.8.7.1 をリリースしました。

    Custom Post Type Permalinksをアップデートしました。

    アップデート内容はこんな感じです。

    • バグフィックス
    • 管理画面周りの変更
    • Pointer APIの使用
    • コメントや、個別記事でのページング等の不具合も解消したつもりです。
    • 申し訳程度にフィルターフックを実装。今のところ、デフォルトのパーマリンク設定を変えるくらいしか使い道はないです。
    • マルチサイトでも一応動作します。

    with_frontにはまだ対応していません。カスタム投稿タイプ登録時にスラッグを”foo/bar”等にすれば、下の改装でカスタム投稿タイプ活用できるとは思います。
    https環境とか、nginx環境とかでのテストはまるでできていないので、ちょっとどうしましょうという感じではありますが。

    そんなわけで、例によっていつものごとく@Toro_Unitまでフィードバックいただければ幸いです。

    よろしくお願いします。m(_ _)m