Toro_Unit

フリーランスのフロントエンドエンジニア、WordPress エンジニアです

カテゴリー: WordPress

  • ふつうのレンタルサーバーでも、VCCWとWordmoveを使って快適にローカル環境で開発しようぜ！

    ,

    昨日VCCWにプルリクエストを投げたらマージされ、コントリビューターになりましたToro_Unitです。1行だけですけどね！！！

    そのプルリクエストがWordmove周りのものだったのですが、プルリク投げたら宮内さんにブログを書けと言われたので書きます。

    What’s Wordmove

    そもそも、Wordmoveってなんぞやって話ですよね。僕もVCCWが対応したとかでそのとき初めて名前を聞きました。

    https://github.com/welaika/wordmove

    WordmoveはRuby製のWordPress用デプロイツールです。サーバー間でWordPressの環境をまるっと同期できます。プラグインとかテーマとか、データベースとか。本体も同期できますし、部分的にいろいろやれたりもします。言語ファイルだけとかも。

    データベースの同期だと、画像のリンクがフルパスになっていて同期先で上手く表示できないとかいう問題が発生しがちなのですが、そこら辺も上手い事やってくれます。

    要は、WordPressをサーバーやドメイン引っ越しとか、テスト環境から本番に公開するときなんかに、データベースをいろいろ書き換えたりとかしますよね。そこらへんも含めてコマンド一つでやってくれるものすごーい便利なツールです。

    また、本番環境からテスト環境へデータを持ってくる等もできるので、運用中のサイトのメンテナンスなどからでも取り入れる事ができます。

    VCCWでのWordmoveの使い方は、こちらの記事を参照してください。

    WordMoveを使ってVagrant内のWordPressと本番環境を同期する！ | Firegoby

    なんか、便利そうですよね。触ってみたくなりませんか？

    さくらのレンタルサーバーでWordmoveする

    先ほど紹介した宮内さんのブログだとAWSの話なのですが、これをさくらのレンタルサーバーでやります。

    Movefileはこんな感じです。

    local:
  vhost: "http://wordpress.local"
  wordpress_path: "/var/www/vhosts/i-09798573b46965351"

  database:
    name: "wordpress"
    user: "wordpress"
    password: "wordpress"
    host: "localhost"

staging:
  vhost: "http://example.com"
  wordpress_path: "/home/sakurauser/www/example.com"

  database:
    name: "database_name"
    user: "database_user"
    password: "database_pass"
    host: "database_host"
    charset: "utf8"

  exclude:
    - ".git/"
    - ".gitignore"
    - ".sass-cache/"
    - "bin/"
    - "node_modules/"
    - "tmp/*"
    - "Gemfile*"
    - "Movefile"
    - "wp-config.php"
    - "wp-content/*.sql"

  ssh:
    host: "sakurauser.sakura.ne.jp"
    user: "sakurauser"
    password: "pass"
    port: 22
    rsync_options: "--verbose"

     

    さくらのレンタルサーバーだと、データベースのdumpの文字コードがshift-jisになってしまうので、detabaseの項目に文字コードの指定を入れます。”utf-8″か”binary”にしておけば問題なく動きます。

    参考：WordPress – wordmoveのMovefileのエラーを解決してみた – Qiita

    $ vagrant ssh
$ cd /vagrant
$ wordmove pull --all

    上記のコマンドを実行すればサーバーからローカルへデータを同期できます。ただし、一番最初に実行するときはサーバーの公開鍵のチェックなどで上手くいかなかったので、vagrant sshでログインした後に対象のサーバーにsshで入る必要があります。

    $ ssh [email protected]

    これで、公開鍵を登録しますかとかうんたらかんたら聞かれるので、yesとしておけば大丈夫です。

    Movefileの設定等でなんとかなりそうな気はするんですけどね・・・。だれか教えてください。

    hetemlでWordmoveする

    hetemlの場合はsshは問題ないのですが、ファイルの同期をするrsyncが動かないので、FTPで行います。

    local:
  vhost: "http://example.local"
  wordpress_path: "/var/www/vhosts/i-09798573b46965351"
  database:
    name: "wordpress"
    user: "wordpress"
    password: "wordpress"
    host: "localhost"

staging:
  vhost: "http://example.com"
  wordpress_path: "/web/example.com"

  database:
    name: "database_name"
    user: "database_user"
    password: "database_pass"
    host: "database_host"

  exclude:
    - ".git/"
    - ".gitignore"
    - ".sass-cache/"
    - "bin/"
    - "node_modules/"
    - "tmp/*"
    - "Gemfile*"
    - "Movefile"
    - "wp-config.php"
    - "wp-content/*.sql"
    - ".htaccess"


  ftp:
    user: "ftp_user"
    password: "ftp_pass"
    host: "example.com"
    passive: true

    wordpress_pathが実際のフルパスではなく、FTPでログインしたときのwordpressの場所になります。

    こちらの場合は、sshを使わないので公開鍵云々などの必要はありません。すんなり動きます。ただ、やりとりするファイルが多いと接続が切れたりする事があるようです。node_modules等はexcludeに指定しておくと良いかと思います。

    個人的にはまったとこ

    いくらpullしてもデータベースが反映されないなぁってやってたら、テーブルのプレフィックスを直してませんでした。ローカルでも本番環境でもこれは合わせておかないといけないようです。

    まとめ

    最近WordPressのCLIツールもどんどん発達してますが、使いこなすと革命レベルで作業がやりやすくなります。レボリューションです。

    WordmoveとWP-CLIはほんとにすごい。セットアップせずに使えるVCCWほんとすごい。

  • WordBench長野でお話しさせていただきました。#wbNagano

    ブログを書くまでが勉強会という事で。

    先週の土曜日にKnower(s)さんでWordBench Nagano Vol.4を開催しました。

    気がつけば満席で大盛況でございました。ご来場ありがとうございます。正直40分しゃべるってのはなかなか疲れました。懇親会では疲れ果てて非常にぐだぐだだったので次回は誰かに懇親会はお任せしようという決意をした所存であります。

    当日話した事

    先日の予告通りこのブログのリニューアルをどんな感じでやったかという話をざっくりとしました。テスト環境作るなら、VCCWがいいよって話と、Theme Unit Testをちゃんとやると良いよっていう話ですかね。

    かなり駆け足＆練習不足のためのグダグダなどもあったので、わかりやすく話せた自信は正直薄いので、いろいろググってください。宮内さんのブログとかに情報たくさんあるので、読んで頂ければと思います。

    http://www.slideshare.net/Toro_Unit/w-42198388

    今後について

    とりあえず、今年度中に何かしら勉強会やれたらなぁと思います。個人的にはCSSとかJSの話もしたいというのもあったり、WordBenchもある程度定期的にやりたいなとは思ってたりします。

    勉強会などのお誘い等は可能な限り参加させていただきますので、よろしくです。

     

  • wp_headからコメントのフィードへのリンクを消す。[追記あり]

    クライアントワークとかでコメントを使う機会って少ないですし、自分の中二病的ポエムサイトにコメントがついたりすると死にたくなりますよね。

    そんなわけでコメント欄をテーマに設置しないことが多いんですけど、それだけだとコメントフィードへのリンクがwp_headに出力されてしまいます。

    <link rel="alternate" type="application/rss+xml" title="ほげほげ のコメントのフィード" href="http://example.com/blog/hoge-hoge/feed/">

    みたいなやつ。

    なんだか気持ち悪いので取ってしまいましょう。

    ページ・投稿ごとに、ディスカッションの設定のチェックをすべて外す。

    discussion

    これにチェックが入っていないページであれば、コメントフィードは出力されません。

    投稿のデフォルト設定の「コメントの許可」、「他のブログからの通知を受け付ける」のチェックを外す。

    defaultsetting

    こいつらにチェックが入ってると、新しい投稿を作るたびにディスカッションのチェックを外さなければいけないので、チェックを外しましょう。

    でも忘れるよね･･･ということで、functions.phpにコピペできるコード。

    add_action(“init”,function(){
    update_option( “default_ping_status”, true );
    update_option( “default_comment_status”, true );
    });

    PHP5.3以上じゃないと動かないですけど、イマドキ5.4未満とかあり得ないと思うので別にいいかなと。

    追記：まがりんさんからツッコミ入ったので、修正。

    add_action("init",function(){
    add_filter("comments_open", "__return_false");
    add_filter("pings_open", "__return_false");
});

    こっちの方がベターですね。

  • VCCWで作ったvagrantfileをgitでちゃんと管理する。

    ,

    VCCWといえば、宮内さんが作った、Vagrantで超簡単にWordPress環境を作るやつですが、これを、git cloneして、Vagrantfile.sampleをリネームすれば、vagrant環境が立ち上がります。

    で、これで作ったVagrantfileをgit管理したい訳ですが、そもそもリポジトリはGithubに存在していて、宮内さんのコミットログが山のように入っています。これにコミットしてもいろいろ面倒ですし、バージョンを上げようと言うときに困ったり。そんなときの対処法です。

    VCCWとVagrantfileの場所を変更する。

    実は、Vagrantfile.sampleと別の場所にVagrantfileを作れます。

    https://github.com/miya0001/vccw/blob/master/Vagrantfile.sample#L42

    ここのパスがデフォルトではvccwのディレクトリになっていますが、ここを

    WP_CHEF_COOKBOOKS_PATH = "~/vccw"

    にすると、MacやLinuxであれば、ホームディレクトリの直下にあるvccwを参照します。コメントに書いてありますね。見落としてました。。。

    こうすることで、いちいちvccwをクローンしてこなくても良くなりますし、複数の仮想マシンを立てるときもvccwをいちいちcloneしてくる必要がないです。

    また、
    + Vagrantfile
    + vccw
    + Vagrantfile.sample
    + cookbooks
    + site-cookbooks
    みたいな構成にする時は、

    WP_CHEF_COOKBOOKS_PATH = File.join(File.dirname(__FILE__), "vccw")

    としてやれば良いです。

    僕は、この構成にして、vccwのディレクトリは、gitサブモジュールとして登録してます。プロジェクトによってはこっちの方がベターかもしれません。(windowsの人が混じってるときとかですかね。)

    ちゃんと、コメントは読むもんですね。

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

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

    3.9でのテストと、バグフィックスがメインになっています。

    WordPress › Custom Post Type Permalinks « WordPress Plugins

    Github: torounit/custom-post-type-permalinks

    バグレポート、Pull Request、お酒、コーヒーメーカー、フードプロセッサー、ミキサーなどなど、お待ちしてます。

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

    ,

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

    WordPress › Custom Post Type Permalinks « WordPress Plugins

    機能面での修正は、PHP5.4対応とか、WordPress3.8でテストしたとかその程度です。
    コードを全面的に見直して、がっつりリファクタリングを行っております。去年の夏から取り組んではいたのですがだいぶかかってしまいました。

    今まで一つのファイル・クラスで行っていたものを複数の小さなモジュールに分離しています。
    ここのモジュールは基本的に独立しているのでアドオン形式の機能追加なども可能です。

    あとソースコードも読みやすくなったはずです。（たぶん。）そんなわけでじゃんじゃんプルリクエストをいただければありがたいです。

    レポジトリはこちら。
    torounit/custom-post-type-permalinks

    パッチ・プルリクエスト・issue・フィードバック等よろしくお願いします。m(_ _)m

  • ぼくのかんがえたさいきょうの editor-style #wpacja2013

    WordPress Advent Calendar 2013、3日目を担当させていただきます。@Toro_Unitです。

    今回はWordPressで活用されているようで活用されていないような気がする、editor-style.cssをがっつり掘り下げてみようかと思います。

    そもそもeditor-styleとは

    WordPressの投稿画面のビジュアルエディタ(ビジュアルリッチエディターとも言いますね)に適用するCSSのことです。

    テーマのfunctions.phpに

    add_editor_style();

    と記述すると、テーマ内のeditor-style.cssというファイルが、読み込まれるようになります。

    また、引数にファイル名を指定することが可能で、その場合、

    add_editor_style("css/editor.css");

    とすると、テーマディレクトリのcss/editor.cssが適用されます。また、

    add_editor_style("css/Normalize.css");
add_editor_style("css/editor.css");

    みたいなことももちろんできます。

    Before

    before

    まぁ、普通のWordPressの画面ですね。

    After

    after

    ちょっと使いやすくなった気がしませんか？

    テーマで使うCSSとeditor-styleを統合する

    テーマで使うCSSからeditor-styleにCSSをコピペするのは、正直かったるいですね。それに同じスタイルが2重管理になってしまったりで非常にメンテナンスしづらくなってしまいます。これどうにかしたいですね。

    ここで、ビジュアルエディタのbody要素に注目すると、

    <body id="tinymce" class="mceContentBody content post-type-post post-status-auto-draft post-format-standard wp-editor" dir="ltr"></body>

    みたいな感じになっています。
    “post-type-post post-status-auto-draft post-format-standard”は投稿の状態によってクラスが変わりますが、

    • mceContentBody
    • content
    • wp-editor

    の3つは、基本的には、ずっと適用されています。

    なので、
    テーマの方のthe_content()、the_excerpt()を、

    <div class="content">
<?php the_content();?>
</div>

    のような形で作っておくと、あとは、CSSを

    .content h2 {
}

.content h3 {
}

.content  ol {
}

.content  .alignleft {
}

    のような感じで.contentの子要素として作成すれば、テーマ側でもビジュアルエディターでも全く同じスタイルシートを使い回すことができます。

    また、テキストエリアの余白など、ビジュアルエディターでのみ適用したいスタイルがあると思いますが、そのときは、

    #tinymce {
	padding: 20px;
}

    としておくと、ビジュアルエディターでのみ使うスタイルが作れます。

    ビジュアルエディターのbodyのクラスについて

    先ほどスルーした、投稿の状態によって変わることがあるクラスがありますが、これを使うとかなり投稿画面を柔軟にカスタマイズすることができます。

    post-type-hoge
    現在の投稿タイプによって、post-type-post、post-type-pageなどのクラスが当たります。
    post-format-huga
    現在の投稿フォーマットによって、post-format-link, post-format-galleryに変わります。このクラスはJavaScriptで動的に変更されます。TwentyThirteenの投稿フォーマットを変更すると、背景色が変わったり画像が出たりしますが、このクラスを使っています。
    post-status-puyo
    現在の投稿のステータスによって、post-status-future（予約投稿）、post-status-auto-draft（自動保存・新規投稿時）、post-status-publish（公開されている）、post-status-draft（下書き）の4つのどれかが選択されます。

    クライアントワークでWordPressを使うと、やっぱりHTMLとかよくわからないって人が更新することも多いわけですが、ちょっとした設計を最初に考えるだけで使いやすさはかなりアップします。また、コンテンツエリアのCSSをちゃんと作っておくと、余計なclassやインラインスタイルを当てずにすむので、リニューアル時もコンテンツにはほとんど手を入れずにすみます。

    CMSだと、「コンテンツエリアのデザインで凝ったことができない」とよく言われがちですが、WordPressは案外できることが多いですよ。

    明日の投稿はnyagihimeさんです！クリスマスまで張り切って参りましょう！

  • WordPressのテーマ作成で気をつけてほしいこととか・アンチパターンとか。

    WordPressのテーマ作成で、ありがちなアンチパターンです。

    • テンプレート内にロジックは書かない
    • query_postsは使わない。
    • wp_head(),wp_footer()はちゃんと書く
    • .alignleft, .alignright等のCSSは定義する
    • JavaScriptは、wp_enqueue_scriptを使って読み込む
    • 更新のあまりないページでも静的にせず、固定ページに入れる

    テンプレート内にロジックは書かない

    関数はここから引用。
    http://www.2ndgate.jp/archives/614

    before

    <ul>
<?php while(have_posts()):the_post();?>
<li>
<?php the_post_thumbnail();?>
<p>ファイルサイズ:
<?php
$attachment = get_post_thumbnail($post->ID);
$attachment_path = get_attached_file( $attachment );
$attachment_filesize = filesize($attachment_path);
$s = array('B', 'KB', 'MB', 'GB', 'TB', 'PB');
$e = floor(log($attachment_filesize)/log(1024));
echo sprintf( '%.1f '.$s[$e], ( $attachment_filesize/pow( 1024, floor($e) ) ) );
?></p>
</li>
<?php endwhile;?>
</ul>

     

    読みづらいし、HTMLの修正とかしづらい…

    after

    テーマ内に、functions.phpという名前のファイルを用意すると、テンプレートより先に、自動的に読み込まれます。

    functions.phpに以下のような関数を用意します。

    function byteConvert( $bytes ){
$s = array('B', 'KB', 'MB', 'GB', 'TB', 'PB');
$e = floor( log($bytes)/log(1024) );
return sprintf('%.1f '.$s[$e], ( $bytes/pow( 1024, floor($e) ) ) );
}

function my_post_thumbnail_filesize($post_id) {
$attachment = get_post_thumbnail($post_id);
$attachment_path = get_attached_file( $attachment );
echo byteConvert(filesize($attachment_path));
};

    テンプレート側はこんなかんじにします。

    <ul>
<?php while(have_posts()):the_post();?>
<li>
<?php the_post_thumbnail();?>
<p>ファイルサイズ: <?php my_post_thumbnail_filesize($post->ID);?></p>
</li>
<?php endwhile;?>
</ul>

    としておくと、HTML編集も楽だし、後々ファイルサイズの部分を変更することになっても、テンプレートは触らなくても大丈夫。

    WordPressに限ったことでもない気がしますが、テンプレート側には可能な限りロジックは書かないでおくと、HTMLの構造とかが把握しやすいです。

    query_postsは使わない

    これはテンプレート内で使っちゃいけません！ じゃぁなぜ使えるんだろう

    テンプレート上で表示する記事を変更するので、ページング周りがおかしくなったり(まだ記事があるはずなのにページが見つかりませんになったり、記事がないはずのページにアクセスできてしまったり。)します。 メインクエリーの代わりにWP_Queryでやっても同様の事態に見舞われます。なので、メインクエリーをpre_get_postsを使って変更してあげましょう。

    before

    [php title=”category-hoge.php”]
    <?php query_posts($query_string . ‘&posts_per_page=4’);?>

    <div class=”entries”>
    <?php while(have_posts()):the_post();?>
    <article>
    <h1><?php the_title();?></h1>
    <?php the_content();?>
    </article>
    <?php endwhile;?>
    </div>
    [/php]

    after

    [php title=”functions.php”]
    add_action( “pre_get_posts”, “my_pre_get_posts” );
    function my_pre_get_posts( $query ) {
    if ( is_admin() || ! $query->is_main_query() ) {
    return;
    }
    if ( $query->is_category( “hoge” ) ) {
    $query->set( ‘posts_per_page’, 4 );
    }
    }
    [/php]

    [php title=”category-hoge.php”]
    <div class=”entries”>
    <?php while(have_posts()):the_post();?>
    <article>
    <h1><?php the_title();?></h1>
    <?php the_content();?>
    </article>
    <?php endwhile;?>
    </div>
    [/php]

    あ、管理画面からここら辺がいじれるプラグイン作りました。各投稿タイプ・タクソノミーのアーカイブでの表示件数を変更する「Powerful Posts Per Page」をリリースしました。

    wp_head(),wp_footer() はちゃんと書く

    プラグインやWordPress本体が出力するmetaタグ、cssやJavaScriptはここで出力されます。入れないとプラグインが上手く動かなかったりします。

    .alignleft, .alignright等のCSSは定義する

    .alignleft, .alignright,.aligncenter,.wp-caption等WordPressのビジュアルエディタが出力するクラスがあります。WordPressのビジュアルエディタは、インラインスタイルでCSSを定義しないので、これをテーマ側のCSSでも定義してやらないと、管理画面では右寄せにしたはずの画像がそうなっていない等の不具合が発生します。

    また、WordPressには、editor-styleといってビジュアルエディタにCSSを適用できる機能があります。

    ビジュアルエディタの部分はiframeになっていて、そこのbodyタグは、
    [html]
    <body id=”tinymce” class=”mceContentBody content post-type-page wp-editor”>
    [/html]
    のような感じになっていますので、テーマの方でも、
    [php]
    <div class=”content”>
    <?php the_content();?>
    </div>
    [/php]
    としておくと、editor-styleをそのままテーマ側でも使ったりしやすいです。

    デフォルトテーマの editor-style.cssが参考になります。というかほとんどそのままコピペしてもいいくらいです。

    JavaScriptは、wp_enqueue_scriptを使って読み込む

    before

    [php title=”header.php”]
    <?php wp_head();?>
    <script src=”<?php bloginfo(“stylesheet_directory”);?>/js/jquery.js”></script>
    <script src=”<?php bloginfo(“stylesheet_directory”);?>/js/hoge.js”></script>
    [/php]
    等と、書いてしまうと、WordPressのプラグインなどで、jQuery等を使っている場合（例えば Contact Form 7とか）、wp_headから出力されて、２重に呼ばれてしまいます。

    after

    [php title=”header.php”]
    <?php
    wp_enqueue_script(‘jquery’);
    wp_enqueue_script(‘hoge’, get_stylesheet_directory_uri() . ‘/js/hoge.js’);
    wp_head();
    ?>
    [/php]
    などをwp_headより前、もしくはfunctions.php等で、書くと、wp_headからscriptタグが出力されます。

    また、wp_enqueue_scriptの第3引数に配列で、依存するライブラリを書いておくと、そのライブラリを先に呼んでから呼んでくれるようになります。
    [php]
    wp_enqueue_script(　’hoge’,　get_stylesheet_directory_uri() . ‘/js/hoge.js’,　array( ‘jquery’ ));
    [/php]

    WordPressに内蔵されているJavaScriptって結構たくさんあるようです。 backbone.jsとかunderscore.jsとかはよくお世話になりますね。
    Default Scripts Included and Registered by WordPress

    更新のあまりないページでも静的にせず、固定ページに

    phpのincludeとかで、ヘッダー、フッターなどを管理して静的サイトを作ることも多いですが、それをそのまま持ち込むと、ヘッダーを2重管理したり、js周りの読み込みの管理が煩雑になりがちです。

    page-hoge.php等のテンプレートで、各個別ページごとのテンプレートも作れるので、ちょっとがんばって突っ込んでおきたいです。
    CMSの管理に乗るので、Google XML Sitemaps等のプラグイン等の恩恵が受けやすくなります。

    WoedPress簡単だって言われておりますが、大まじめにやろうと思うと気をつけなきゃいけないコトは実は多いです。規模が大きくなるとプラグインも増えたり、WordPressの機能を使い倒す場面も多いのでテーマもちゃんと作っておくと不具合が出にくいです。

  • Powerful Posts Per Page 0.7.2 をリリースしました。

    先日リリースした、Powerful Posts Per Pageをアップデートしました。

    PPPPのスクリーンショット

    アップデート内容は、

    • カテゴリー・タグへの対応（してたつもりができていなかったものを修正）

    となります。

    WordPress › Powerful Posts Per Page « WordPress Plugins

    バグフィックスは @Toro_Unitまでお願いします。

  • 各投稿タイプ・タクソノミーのアーカイブでの表示件数を変更する「Powerful Posts Per Page」をリリースしました。

    各投稿タイプ・タクソノミーのアーカイブでの表示件数を変更する「Powerful Posts Per Page」をリリースしました。

    WordPressの管理画面からカスタム投稿タイプや、各タクソノミーごとの表示件数を変更できるプラグイン、Powerful Posts Per Pageをリリースしました！

    このプラグインができること

    WordPressの管理画面の 「設定->表示設定」から、カスタム投稿タイプやタクソノミーのアーカイブページの投稿数を指定できます。

    PPPPのスクリーンショット

    ここで指定された値は、ロード時に、pre_get_postsを使って、WordPressのループを変更します。

    もうcategory.phpやらarchive.phpにquery_postsを書いたり、WordPressのデフォルトの表示件数を１件にしてみたりそんなことする必要はありません！！！！

    開発の経緯

    query_postsを捨てよ、pre_get_postsを使おう【追記あり】【報告あり】 | notnil creation weblog等で、春先当たりからpre_get_postsが大きなブームになっていますよね。

    そんなこんなで、僕もすっかりpre_get_postsの虜になっている訳なんですが。

    ただ、この間のWord Camp Tokyo 2013のテクニカル座談会で、「pre_get_postsとかって初心者には難しくない？」という話があがったり、
    仕事で人にWordPressを教えたりすることがあったりするのですが、WordPressが専門ではない人だとか、デザイナーさんだとか、functions.phpよくわからん！って人にはめちゃくちゃ高いハードルな気がしてます。

    「でも、そんな人にもpre_get_postsを使ってほしいナー」とか、「管理画面からデフォルトの値は設定できるんだったら、他のも管理画面からやりたいよナー」

    と、思ったので作ってみました。教えてと言われてもちゃんと教えられる自信が無いので、プラグインにしました。pre_get_postsを簡単に使うにはいいと思ってます。細かいことはできませんが。

    そんなわけで、ちょっとでも便利そうだなと思ったら、使ってみてください。
    フィードバックは@Toro_Unitや、https://github.com/torounit/ppppやら、フォーラム等でいただければ幸いです。

    余談ですが、制作時間より、「略称をPPPPにしたいがために、Pから始まる単語を探しまくった時間」のほうが長かったです。どういうこっちゃ。

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

    記事がずっと下書き状態のままでした。。。
    先月末の話ですが、Custom Post Type Permalinks 0.9.3.3をリリースしました。

    WordPress › Custom Post Type Permalinks « WordPress Plugins

    カスタム投稿タイプのスラッグと、固定ページのスラッグがコンフリクトした場合の処理を追加しました。
    has_archive => trueのときは、カスタム投稿タイプのアーカイブを、falseであればアーカイブページが生成されないので、固定ページが表示されます。
    投稿タイプの著者アーカイブは “/投稿タイプスラッグ/author/著者名/”、dateアーカイブは、”/投稿タイプスラッグ/date/年/月/日”になります。この仕様はこのバージョンでの修正では無いですが、パーマリンク生成のロジック変更のため、アクセスできていたものができなくなる場合があります。

    また、デフォルトのパーマリンク設定に拡張子をつけた場合にカスタム投稿のパーマリンクがおかしくなるバグ等を修正しました。

    その他、細かい修正を行っています。よろしくお願いします。

  • WordCamp Tokyo 2013に行ってきました！ #wctokyo

    ブログを書くまでがWordCampです！というわけで、WordCamp Tokyo 2013に参加して参りました。相変わらず、凄い人の数でしたね。

    そんなわけで、WordPressカルタに参加させていただきました。幼少の頃、上毛かるたをやっていたグンマーな僕としては、負ける訳にはいかない！ということで、一応、優勝？いたしました。

    そんな訳で、WordPressカルタ

    2013-09-18 00.53.36

    と、

    2013-09-18 00.52.49

    スタッフTシャツいただきました！

    そして、嬉しいことに、「Custom Post Type Permalinks」の札があるではありませんか。

    2013-09-18 01.06.14

    こういうのってなかなか嬉しいですね。使ってもらっている実感とかが得られるというか。とりあえずプラグイン制作っていいもんだなと思いますよ。とりあえず話の種になるし、決して楽ではありませんが得るものも大きいなと個人的には感じています。

    とりあえず、開発がんばります。。。壇上でもしゃべりましたが、Pull Request、Patch、バグレポート、お酒待ってます！

    開発レポジトリ：https://github.com/Toro-Unit/custom-post-type-permalinks

    他にも、PHPカンファレンスのほうでも、ためになるセッションがあったり、WordPress Codex 日本語版の編集やってみようと決心したり、いろいろ、考えさせられることも多かったです。また、その辺のアウトプットは別にやっていきたいと思います。

    なかなか、人が多くて、ご挨拶できなかった方々も大勢いるので、東京や名古屋の勉強会にももう少し参加したいなと思いました。

    あ、あとダイエットします。今度はウソじゃないです。