投稿者: Toro_Unit

  • ぼくのかんがえたさいきょうの 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さんです!クリスマスまで張り切って参りましょう!

  • ComposerをOSにインストールして、いつでもどこでもさくっとComposerできるようにする

    Composer 便利ですね。Rubyのbundleみたいな。初めて名前を聞いたときは、ComposerってHTMLエディタかよって思った人もたぶん多いはず。

    ただ、毎回毎回

    curl -s https://getcomposer.org/installer | php	
    

    とか、

     php composer.phar update          
    

    ってやるのがかったるいなぁって思ってました。

    composer update  
    

    とはならんのかと。

    http://getcomposer.org/doc/00-intro.md#globally-on-osx-via-homebrew-
    ComposerをOSにインストールする方法が書いてありました。ドキュメントって読むもんですね。

    homebrewでインストール

    $ brew tap josegonzalez/homebrew-php
    

    でリポジトリを追加して、

    $ brew install josegonzalez/php/composer
    

    したらインストール完了!と思っていたのですが、

    composer: Missing PHP53, PHP54 or PHP55 from homebrew-php. Please install one of them before continuing

    と怒られました。

    Note: If you receive an error saying PHP53 or higher is missing use this command to install php brew install php53-intl

    と公式にもあるので、これを追加。ただしPHP5.4にしたいので、

    $ brew install php54-intl
    

    を実行。すると、

    Error: No available formula for zlib
    Please tap it and then try again: brew tap homebrew/dupes
    Searching taps…

    だそうなので、

    brew tap homebrew/dupes
    

    してから、改めて実行。これを実行すると、homebrewからphp5.4も一緒にインストールされるので結構時間がかかります。
    また、PHPのバージョンがApacheとターミナルとで違うと面倒くさいので、/etc/apache2/httpd.confで、LoadModule php5_moduleの行を

    LoadModule php5_module /usr/local/opt/php54/libexec/apache2/libphp5.so
    

    に書き換え、Apacheを再起動します。php.iniの場所も変わるのでタイムゾーンやらの設定をしてあげましょう。

    そして、

    $ brew install josegonzalez/php/composer
    

    を実行すると、ようやく無事にインストールできました。意外に結構かかりました。

    Windowsの場合

    http://getcomposer.org/doc/00-intro.md#installation-windows
    書いてあります。Composer-Setup.exeを落としてインストールを実行するだけでいいみたいですね。

    楽そうですね。

    これでようやく、bundle気分で、composerが使えそうです。

  • 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から出力されて、2重に呼ばれてしまいます。

    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のデフォルトの表示件数を1件にしてみたりそんなことする必要はありません!!!!

    開発の経緯

    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/年/月/日”になります。この仕様はこのバージョンでの修正では無いですが、パーマリンク生成のロジック変更のため、アクセスできていたものができなくなる場合があります。

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

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

  • CoffeeScriptで、ライフゲームしてみた。

    50行で作る、HTML5+JavaScriptで『ラングトンのアリ』の簡単プログラミング! – あのねノート。を読んで、無性にライフゲームが書きたくなったので、やりました。

    さすがにJavaScriptで書くのは何番煎じどころの話じゃないので、CoffeeScriptのClassで書いてみました。

    [gist]https://gist.github.com/torounit/6613937[/gist]

    jQueryと、これをコンパイルしたjsを読み込んで、HTMLに適当にCanvasを書いてあげれば動くはずです。
    CoffeeScriptでjQueryプラグインを書く参考になったりするかもしれません。

    Canvas使うと、さくさくと動くものが作れて、楽しいですね。

    こんな感じで動きます。

    セル・オートマトン等はルールも難しくないので、案外さくっと作れるわりに、出来上がると案外楽しいので、遊びついでにやってみるってのもいいもんですね。

  • 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 日本語版の編集やってみようと決心したり、いろいろ、考えさせられることも多かったです。また、その辺のアウトプットは別にやっていきたいと思います。

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

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

  • add_action, add_filterで無名関数が使えます。

    最近は PHP 5.3 がいろんなレンタルサーバーでもメジャーになってきて、PHP 5.2 は若干レガシーかな。みたいな雰囲気ですね。

    そんなPHP 5.3ですが、無名関数が使えます。

    [php]
    $foo = function( $bar ) {
    echo $bar;
    };
    $foo("ほげ"); //ほげ
    [/php]

    こんな感じで、書けるようになりました。JavaScriptみたいに書けますね!

    前から、create_functionという関数はあったんですが、こんな感じで文字列で渡さないとなので、とても読み書きがしづらいんですよね。匿名関数というやつです。
    [php]
    $foo = create_function( "$bar", "echo $bar;" );
    $foo("ほげ"); //ほげ
    [/php]

    そんなわけで、add_action, add_filter もこんな風に書けます。

    [php]
    add_filter( "hoge", function( $param ){
    $param = $param + "ほげ";
    return $param;
    } );

    add_action( "hoge", function( $piyo, $fuga ){
    echo $piyo + $fuga;
    }, 10, 2 );
    [/php]

    時と場合を選ぶとは思うんですけど、アクションフック・フィルターフックは無名関数を使って書いた方が、関数名の衝突等も発生しないのでいい場合も多いかもしれません。また、チームのメンバーがJavaScript得意って場合もこっちの方が読み易いかも知れません。

    とりあえず、オーバーライドや、remove_action, remove_filer が想定される場合は避けましょう。

  • 記事を保存したときにAdvanced Custom Fieldsで設定したフィールドの値を取得する。

    Advanced Custom Fields に最近お世話になりっぱなしです。カスタムフィールドが手軽に扱えるし、ユーザーにもかなり優しいUIを作り易いし。

    そんな訳でACFを使ってちょっとした機能を作るときのTipsです。

    よく、記事の公開、公開中の記事の公開時には、publish_postというアクションフックが実行されます。しかし、この段階では、カスタムフィールドの値はデータベースに保存されていません。

    なので、$_POSTで送信されてきた値をとってきます。

    [php]
    add_action("publish_post","my_publish_post");

    function my_publish_post( $post_id ) {

    $acf_field = get_field_object( "hoge" );
    $acf_field_key = $acf_field["key"];

    if( isset( $_POST["fields"][$acf_key] ) {
    $field_value = $_POST["fields"][$acf_key];

    //ここに処理。
    }

    }
    [/php]

    hogeというキーで設定したフィールドの値はこんな感じで取得できます。

    これに、WordPressで記事の公開期間を簡単コントロール!カスタムフィールドに開始・終了日時を指定するだけでOKのクラス | Pimp My Site

    を組み合わせて、

    [php]
    class PM_Schedule_Post_ACF extends PM_Schedule_Post {

    protected function get_meta( $key ) {
    $val = ”;
    $acf_field = get_field_object( $key );
    $acf_key = $acf_field["key"];

    if ( isset( $_POST["fields"][$acf_key] ) ) {
    $field = htmlspecialchars( $_POST["fields"][$acf_key], ENT_QUOTES );
    }
    else {
    $val = parent::get_meta ( $key );
    }

    return $val;

    }

    }

    add_action( ‘after_setup_theme’, function() {
    new PM_Schedule_Post_ACF( "pubstart", "pubend", "公開終了" );
    });
    [/php]

    みたいな感じで使ってます。実際に使っているのはもう少しガリガリいじっているのでまたそれは後日アップします。

    管理画面のUIをACFで統一できるので、かなり使い勝手の良い管理画面を作れると思います!

  • Adobe製オープンソースのエディタ、「Brackets」がすごかった。

    Adobe製オープンソースのエディタ、「Brackets」がすごかった。

    アドビ、オープンソースのHTMLエディタ「Brackets」を公開。まだまだ開発中 - Publickey
    など、開発が続いていた、Adobe製エディタです。

    また、Creative Cloudに入っている Adobe Edge Codeの元になっているようです。FedoraとRHELみたいな関係と思えばいいんですかね。

    Brackets

    https://github.com/adobe/brackets

    Adobe Edge Codeを触ってみたついでにこっちも触ってみたのですが、なかなかすごかったので紹介。

    ライブプレビュー & ライブ編集

    エディタの右上の「雷マーク」をくりっくすると、
    livepreview

    という表示がでて、ローカルサーバーが立ち上がり、ライブプレビューが動作します。

    「DreamWeaverのプレビュー部分がブラウザにならないかな・・・」とか
    「開発者ツールで編集したCSSそのまま保存できないかな・・・」

    というマークアップエンジニアの願いが遂に現実のものに!

    また、CSSを編集していると、
    livepreview2

    みたいな感じで、現在編集している要素がハイライトされます。

    拡張機能

    また、拡張機能もたくさん用意されているようです。
    https://github.com/adobe/brackets/wiki/Brackets-Extensions

    また、基本的には、Macの場合であれば、 「ファイル → 拡張機能のインストール」から、GithubレポジトリのURL(ブラウザでアクセスできるURL)をコピペするだけでインストールできます。

    extention

    GUIも日本語化されているし、jsonやらテキストファイルで設定を書くようなことも無いので、デザイナーさんでも取っ付き易そうですね。

    ただ、OSのnode.jsを使うようなプラグインもあるので、その場合はコンソールを叩いたりする必要はあるみたいです。

    HTML/CSS/Javascriptで作られているので、拡張機能の作成のハードルも低そうです。

    また、色やグラデーション、img要素にカーソルを合わせれば、その色やら画像が表示されたりなど、Adobeならではの気遣いみたいなものを感じます。

    また、JSLintが標準で入っていたり、jQueryの入力保管が最初から入っていたり、当然のごとく、Emmet/Zen-Codingもプラグインありますし、LessをコンパイルするプラグインもあったりでフロントエンドならSublimeより良い選択肢かも知れません。

    DreamWeaverの使いやすい入力保管も受け継いでいてHTMLも書きやすいです。

    かつてDwをテキストエディタとしてのみ使い、現在はSublime Text 2でコードを書いている僕のような人間にとって、Brackets / Adobe Edge Code は良い選択肢かも知れないですね。

  • WordPressのマルチサイト案件で、子テーマを使って効率よくカスタマイズする。

    この間、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もちゃんと対応できておりません(汗)
    またカスタム投稿との棲み分けとかも考えないといけない部分があります。

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