カテゴリー: WordPress

  • http://www.slideshare.net/Toro_Unit/wordpress-54602891

    というわけで、10/31に WordCampTokyo 2015 にて、「WordPressで行う継続的インテグレーション 入門編 -プラグイン開発・保守地獄から学んだこと-」というセッションをしてきました。

    予想を大きく上回る人数のご参加、ありがとうございました。ちびりそうでした。

    プラグインを作っていて辛かった話さんざんしましたけど、公式プラグインに限った話でもないし、大事なのはその心意気とか考え方だとは思いますので、参考に出来るところがあれば幸いです。

    とりあえず、セッションで笑いが全然とれずに泣きそうだったので、またどこかでリベンジさせてください。

    あと二日酔いでめちゃくちゃしんどかったので、そこら辺も気をつけたいと思います。(3ヶ月ぶり2回目)

    コントリビューターデイはとりあえず好き勝手にいろいろ楽しくやらせていただきました。詳細は近日中に書きたいと思います。

    とりあえず、スタッフの皆様ありがとうございました。お疲れ様でした。相変わらず楽しい3日間でした。またかまってください。

     

  • WordCamp Tokyo 2015 で CI のことをおしゃべりします。

    今更ですが、今週末の10/31・11/1に開催される WordCamp Tokyo 2015 に登壇しまーす。

    「WordPressで行う継続的インテグレーション 入門編  -プラグイン開発・保守地獄から学んだこと-」というセッションをさせていただきます。入門編なので、プラグインを作っている/作って見たいって人向けの内容、特に今回はテスト周りを中心に話す予定です。CI三兄弟の末っ子としてがんばります。

    他には、gulpのハンズオンのお手伝いしたり、コントリビューターデイのお手伝いしたり、お酒飲んだり、お酒飲んだり、お酒飲んだりしています。

    スベったらハンズオンまでSAN値が持たないのでちゃんと笑って下さい。やさしくしてください。

    あと「何言ってるか全然わからんかったぞ!」って人とか、「テーマのビルド・デプロイ自動化について聞きたい」って人は、懇親会などにも居ますので捕まえて聞いください。お酒が入りすぎると分け解らんことを言うのでその前にどうぞ。

     よろしくお願いします。

  • Custom Post Type Permalinks とRS CSV Importer Media Add-On をそれぞれアップデートしました。

    Custom Post Type Permalinksの更新内容

    ほとんど何にもしてないです。

    • 4.3でのテスト。
    • 管理画面の設定画面のバグ修正。カイトさんからプルリクエスト貰ったやつです。

    Github: custom-post-type-permalinks

    RS CSV Importer Media Add-On

    テストコードを書いてテストを自動化しました。

    • 4.3でのテスト。
    • テストコードを追加。(Githubのみ)
    • 画像のパスがサーバーの内部パスの場合に対応しました。

    Github: rs-csv-importer-media-addon

    WordPress Importer のテストコードが以外に参考になりました。コアのテストと同じレポジトリにあってちょっとびっくりしましたけど。

     

    何かあればプルリクエストくださいー。

  • 【WordBench京都 9月号】「CI(継続的インテグレーション)」と「kintone×WordPressハンズオン」に参加してきました。

    本当は日曜日の朝に帰ってゆっくりしようとか思っていたんですが、折角関西に来たのに電車賃がもったいないなぁと思い直しまして。

    前日のWordBench大阪でしゃべってお酒も飲んだおかげで相変わらず死にかけてましたけど。。。orz

    太鼓の岡本さんCI三兄弟の兄貴と一緒にWordFesのときの酔っ払い放送を見てたと言われ、末っ子の私は結構なダメージでした。つらい。

    https://twitter.com/tkc49/status/643048809208016896

    https://twitter.com/tkc49/status/643048765880823809

    口タイポをホソヤさんが全力でさらされてました。口タイポであれだけ面白いとかずるいと思いました。

    感想とか

    CIのセッションをパクろう聞こうと思って参加したのですが、セッションで5回くらい WordCamp Kansaiのときのスライドが「具体的な方法はスライドを見ろ!」って感じで紹介されてました。ヤラレタ!

    やっぱりシステム開発とかをメインにしてる人はCIに対する情熱というか重みが凄い。とりあえず、決意を新たにテストコードを書きたいと思います。

    http://www.slideshare.net/inc2734/word-campkansai2015-ci

    http://www.slideshare.net/horike37/wordpress-50908456

    Kintoneのハンズオンは、単純にKintoneを触ったことも無かったので面白かったです。ドキュメントも読まずに突撃したので結構必死だった記憶しかないです。

    折角開発者アカウントも取ったのでいじって遊んでみようと思います。

     

    とりあえず、この土日のWordBench旅行、楽しかったです。また折を見て遊びに行きたいと思います。

  • というわけで、9月12日の第45回WordBench大阪でトークショーをしてきました。

    YATさんの陰謀により、45分×2というタイムテーブルになっていて、戦々恐々としていたんですが、結局120分くらい話してました。後半は時間感覚がかなり麻痺してました。いやはや。すみません。

    http://www.slideshare.net/Toro_Unit/wordpresscss

    当日のスライドはTypoやら、言い回しやら話の展開とかがいろいろバグってたり、当日しゃべりながら補足したところが沢山あったのでかなり加筆修正しました。200枚って凄い量ですね。参った参った。

    とりあえず、当日しゃべった内容はだいたいメロン本に書いてあるのでとりあえず、みんな読めば良いんじゃないかと思います。このフレーズ何度言ったか。。。

    日本CSS界のスーパースターからリプライが飛んできてびびりました。

    編集後記的ななにか

    CSSって文法はとにかくシンプルです。そしてそれなりに歴史も長いです。なので、ベストプラクティスは規模感、システムの機能、利用シーンなどで異なるとは思ってます。

    その上で、TPOにあったCSSを考えないとダメかなとは思います。インラインCSSだけで良い場合あるし、HTMLを増やすごとにCSSを書くというのも決して無しではありません。

    その上でやはりWordPressのテーマのCSSというのは、投稿やページが100件だろうが1万だろうが作成されることを念頭に置かねばならないですし、基本的にはWYSIWYGエディタで記事を増やすことが前提になってくるモノなのかなと思います。その場合、スケーラブルでメンテナンスしやすくWYSIWYGでも扱いやすいCSSというものを考えなければならないものなのかなと思います。

    全部の要素にclassを自動的に設定してくれるようなモノで有ればまた違った考え方もあると思いますし、REST APIでReact.jsとかであれば、JSでCSSも記述したりすることもあるので、また別物かと。

    いずれにしろ、とりあえずOOCSSの考え方はしっかりたたき込んでおいて損は無いと思います。

    スライドを200枚作った感想

    スライドって200枚作れるもんだなーとは思いましたが、こんなに枠を貰ってがっつり話すってこともそうそう無いのでとりあえず良い経験だったなーと思います。次は50枚くらいでやります。

    Decksetでスライド作りましたが、ホントに楽でした。とりあえずコンテンツ作成に集中出来るのが楽でした。リアルタイムでプレビューもできるのもかなり楽でした。

    50人の前で120分しゃべった感想

    めちゃくちゃ緊張しました。いやほんとに。

    関西人の前で、福島県生まれ群馬県育ち長野県在住がしゃべり倒すのは怖かったです。場の空気をつかむのがすっごい大変でした。若干スベったときはホントにどうしようってなりましたけど、なんとか無事小さい笑いも取りつつ、なんとかやりきりました。次はもっとちゃんと笑いを取りたい。

    あと、もう少し時間配分とか上手いことやれたら良かったなというのと、意外に人間しゃべれるものだなーとも。でも終わったあとは、へたり込むレベルで疲れました。

    なんだかんだで楽しかったです。

     

    とりあえず機会があればどんどんこういうのをやって慣れていきたいです。ほんと呼んでいただいてありがとうございました。あと焼き肉うまかった。

    次の日にWordBench京都も行ってきたのでその話も近々書きます。

  • 第45回 WordBench 大阪 「使いやすいWordPressテーマを作るために必要なCSSのつくりかた」でおしゃべりします。#wbosaka

    Doorkeeper: https://wbosaka.doorkeeper.jp/events/30996

    というわけで、9月12日のWordBench大阪でおしゃべりします。いつもはプラグインな人ですけど、今回はWordPressテーマのCSSの話を、本当にがっつりしゃべりますここまでがっつりやるつもりはなかった

    後半は、Web制作者のためのCSS設計の教科書 モダンWeb開発に欠かせない「修正しやすいCSS」の設計手法とか、谷 拓樹さんのスライド読んでおけばだいたいいんじゃないかなって内容だと思うので、良いなと思ったら読んでみると良いと思います。

     

    とりあえず、特番とか講義くらいの時間があるので、がんばってすらいどつくります。がんばります。

    おうえんしてください。

     

    次の日は

    【WordBench京都 9月号】「CI(継続的インテグレーション)」と「kintone×WordPressハンズオン」

    ってのもあるらしいです。

     

  • 恐らく日本一 flush_rewrite_rules に悩まされている男、Toro_Unit です。

    カスタム投稿タイプのパーマリンクがどーのこーのでよく出てくる、flush_rewirte_rules ですが。これをテーマとかに書くのはホントに勘弁してってお話です。

    Flushing the rewrite rules is an expensive operation, there are tutorials and examples that suggest executing it on the 'init' hook. This is bad practice.

    Rewrite API/add rewrite rule « WordPress Codex

    関数リファレンス/flush rewrite rules – WordPress Codex 日本語版

    毎回実行するのはバッドプラクティスとCodexにもしっかり書かれているので、絶対にやめましょう

    と言う前に、そもそも flush_rewrite_rules って地味に有名だけど、正直何の関数なのかサッパリ解ってない人多いとは思いますので、なんでこれがダメなのか、ちょっとしっかり解説しようと思います。

    長いので面倒な人は、一番下のまとめだけ読んでください。

    そもそも flush ってどういう意味なの?

    ポーカーのフラッシュとか顔を赤くするとか様々な意味がありますが、ここでの用法だと、水とかをどっと流すと言った意味合いです。

    プログラムの文脈だと、バッファとかキャッシュをクリアしたりすることを指すようです。

    要はトイレで水を流すようなイメージなんですかね。

     flush_rewrite_rules ってなんだろう?

    flush_rewrite_rules は WP_Rewite::flush_rules の ラッパーです。なのでこっちの話。

    WordPressでリライトルールは、rewrite_rules ってオプションにシリアライズされて保存されています。こいつを参照してWordPressはURLをパースしています。

    なんでわざわざそんな面倒な実装になっているかというと、リライトルールの生成というのが結構コストの高い処理なんです。ただパーマリンク構造なんて運用中にそうそう変更するものでも無いので、ページにアクセスするたびにそんなことやってられないよ!って話です。

    flush_rewrite_rules を実行すると、rewrite_rules 削除し、その後 WP_Rewrite::wp_rewirte_rules を叩いてリライトルールを生成するという流れになります。

    また、flush_rewrite_rules の引数が true もしくは空の場合、.htaccess なんかも再生成されます。

    じゃぁなぜ使っちゃだめなの?

    当然かなり重いと言うのもあるんですが、これをよくわからないタイミングで実行されるとリライトルールがバグったりします。ついでに僕が出してるプラグイン1号2号もバグります。

    カスタム投稿のパーマリンクまわりの不具合のほとんどは、flush_rewire_rules です。ほんと止めましょう。

    検証した結果、flush_rewire_rules 書いてたんかい!!!!みたいなのがあると結構辛い!!!

    代わりにどうしたら良いの?

    管理画面から設定→パーマリンク設定に入り、変更を保存すれば良いです。別に変更し無くても大丈夫です。このとき、デフォルト(http://example.org/?p=123)以外のパーマリンク構造になっていれば、flush_rewrite_rules が適切なタイミングで実行されます。

    とりあえず、カスタム投稿タイプ、カスタムタクソノミー、エンドポイントなどを追加、編集した際はこれやっておけば大丈夫です。

    flush_rewrite_rules を使うシチュエーション

    プラグインなどで register_post_type 等パーマリンク周りを取り扱う場合は、register_activation_hook や、register_deactivation_hook 等で登録しておくと良いかもです。

    まぁ設定画面でボタン押せば良いだけなので、やらなくても大きな問題では無いと思います。

    まとめ

    • flush_rewirte_rules をテーマとかプラグインにとりあえず書かない。毎回実行は厳禁。不用意なタイミングで実行するとバグる。
    • register_post_type とか、 register_taxonomy 等を書いたり、rewriteパラメーターを変更したりした場合は管理画面のパーマリンク設定に行って、「変更を保存」。
    • 日本語Codexにもページ作成したから読んで。ついでに翻訳しよう。
  • WordPress 4.3のコアコントリビューターになったりしました。

    ここ最近のものってばかりでもないですけど、いろんなコントリビュートしました。

    WordPress 4.3 のコアコントリビューターになりました

    今更ですが、WordPress 4.3のコアコントリビューターになりました。と言っても一行直しただけなんですけどね!!!

    チケット:#33254 (Access undefined $current_user in update_option_new_admin_email().) – WordPress Trac

    そのとき書いたブログ:WordPressのTracにチケットを投げたら採用されました。| Toro_Unit

    ちゃんとバッジも貰いました。今年の目標の一つだったのでめちゃくちゃ嬉しいです。4.4も頑張りたいです。

    WooCommerce Breadcrumb Permalinks のコントリビューターになりました

    WordCamp Kansai 2015の懇親会で、WooCommerceの中の人のパーマリンクのプラグインにプルリクエスト送るよ!みたいな話になったのですが、プルリクを投げてマージしてもらいました。プルリクエスト投げたら「ありがとう」って帰ってきてびびりました。

    今更ですけど、Smart Custom Fieldsのコントリビューターになりました

    もうかなりくらい前の話ですけど、プルリク投げつけまくってマージしてもらいました。自分の欲しい機能がどんどん付いていくのがおもしろかったです。

    思うこと

    ちょっとイラッとしたり、こうなったらいいのになーみたいなのがあったら、とりあえずコードを書いて送りつければ良いと思います。

    プルリクエストは貰う側も結構嬉しいものですし、自分のコードがダメなら単に拒否されるだけで別に世界が滅んだりとかしないです。

    遠方の人や海外の人とこうやってつながっていける感がとにかく楽しいです。実際にWordCampとかで会ったとき、とりあえず「プルリクありがとう!」って話が出来たりします。

    スペルミスの修正とかでも全然良いと思います。書いてる側は案外気づいてない。

    人のコードを読むのは勉強になることも多いし、みんな気軽にやってみればといいと思いました。

     

     

     

  • コードを書くのに疲れたので、何となく縁のなさそうなコードを読んでいたら、バグを見つけました。用意はしてあるけど使われてない関数だったっぽいです。

    調べたら特にチケットも切られてなかったので、パッチ作ってTracに突撃してきました。

    #33254 (Access undefined $current_user in update_option_new_admin_email().) – WordPress Trac

    そしたらなんか採用されたようです。

    VVVを使って宮内さんの言うとおりにやるのがとにかく簡単でした。VVVの起動にどえらい時間がかかるので飯でも食いながら待ってればいいと思いました。

    VVVを使ってWordPress本体のパッチを送る方法

    VVVが起動する時点でgruntは動くのでやらなくても良いですが、仮想マシン内で実行されるので、仮想マシンの外から作業をするなら、node_modulesを削除して作業する環境で

    $ npm install

    してあげないとビルドタスクがこけます。面倒なので仮想マシンの中で全部作業しました。

    あとちゃんとテストはしましょうね。テストだいじ。

    Tracへの突撃方法

    https://make.wordpress.org/core/reports/ へアクセスして Create a Ticket すればまぁ良いんです。難しいことは正直ほとんどないですが、注意点とか。

    類似のチケットがないかちゃんと調べる

    まぁ、どこでもある奴ですね。右上のSearchからGoogleのサイト内検索が出来るので調べる。関数やメソッド名で調べるのが一番手っ取り早いかも。

    知ってる人がどんな感じでチケット書いたのか読む

    とりあえず、Kiteさんとか宮内さんとかがコアにチケット投げてたのでそれを読んで参考に。

    英語が得意じゃなくてもパッチ投げれば意外に何とかなる

    コードレビューしてくれるコアチームの人とかは当然コード読めるので、この規模ならほぼコードで会話出来そうな感じでした。

    正直営業の人にプログラムの説明するよりは1000倍くらい楽だった気がします。

    提案が入ったようなチケットや、かなり議論が必要なものだとちょっと厳しい気はします。

    というざっくりな感じです。

     

    とりあえずこれで4.4が出るまでの間は、クレジットされたでー!って自慢しようかと思います。

    あと、wp-admin/includesの中とか自分に縁のなさそうなところを読んでみると、といろいろ勉強になること多いです。miscって雑多なって意味だってのを初めて知りました。

    確かにレガシーコードも多いけど、それはそれで勉強になること多いんでたまには、みんな読んでみると良いんじゃないですかね。そのついでにパッチを送ればいいなーとか思いました。

  • こないだ発見した問題ですが、WordPress4.2以降、特定のサーバー条件が揃うと、WordMoveデータベースをpushしてもデータベースがインポートされないという状況が発生しました。特にエラーなどは発生しませんでした。

    、WordPress4.2以降、DBの文字コードがutf8mb4に変更されました。ただし、これ全てのWordPressって訳では無くて、動作しているサーバーのMySQLが5.1系等の場合(正確には5.5.3未満)の場合はutf8mb4に対応してないので、utf8のままなんですよね。

    その場合、ローカルで作った環境がMySQL5.5.3以上の場合、データベースのインポートに失敗します。

    解決法

    ローカルのDBの文字コードを片っ端からutf8に戻せば解決します。面倒くさかったので、SQLダンプでエクスポートしてから utf8mb4 から utf8 に一括置換しました。SQLで一発で戻せる方法あれば誰か教えて下さい。WordPressのコアを見れば utf8 から utf8mb4 はやってるはずなのでわかりそうなものだけど。

    ちょっと・・・みたいなサーバーを扱うときはいろいろ要注意ですね。

  • Amimotoに移行しました。

    やろうやろうと思い続けて早一年。

    ようやく重い腰を上げてAMIMOTOを使いAmazon EC2に移行しました。

    この間のCIのハンズオンでデプロイ用のサーバーを立てていろいろ弄りまくっていたので、そこまでやったならついでにやってしまおうかと。

    とにかく速いですね。正直アクセスもそこまで無いのでHHVMであるコトのメリットはよくわかってませんけど、とりあえず速いです。

    VCCWを使って移行しましたが、ちょっとデータベースの移行が上手いこと行きませんでした。DBの容量が問題だったのかよくわかってないので、ここらへんをしっかり調査できたら、そのうち移行手順まとめたいと思ってます。

    とりあえず、サーバーのユーザー周りを弄ったりする必要はありますね。

    参考:ec2-user ユーザーで網元で作成したインスタンスに(S)FTPクライアントソフトで接続するには? | 超高速 WordPress AMI 網元

    これでおいらも網元機動隊!

  • マルチサイト専用のプラグインを作る機会があったのですが、そのときに手元でPHPUnitするときのメモです。

    とりあえず、wp-cliでプラグインのひな形を作ります。

    $wp scaffold plugin hoge

    このままphpunitを実行してもマルチサイトにならないので、以下のようなテストコードを書くと失敗します。

    class SampleMultisiteTest extends WP_UnitTestCase {
        public function test_is_multisite() {
            $this->assertTrue( is_multisite() );
        }
    }

    その場合、phpunit.xmlを以下のように改変します。

    <phpunit
        bootstrap="tests/bootstrap.php"
        backupGlobals="false"
        colors="true"
        convertErrorsToExceptions="true"
        convertNoticesToExceptions="true"
        convertWarningsToExceptions="true"
        >
        <php>
            <const name="WP_TESTS_MULTISITE" value="1" />
        </php>
        <testsuites>
            <testsuite>
                <directory prefix="test-" suffix=".php">./tests/</directory>
            </testsuite>
        </testsuites>
    </phpunit>

    WP_TEST_MULTISITEという値を渡してあげるとマルチサイトとしてテスト用のWordPressがインストールされて動作します。

    https://github.com/torounit/multisite-sample-plugin

    Travis CIだとtravis.yml弄るだけで大丈夫です。Travisすげー。

    追記

    宮内さん

    $ WP_MULTISITE=1 phpunit

    でいけるだろ、と指摘されました。そりゃそうだ。

    シングルサイトでもしっかりテストしなきゃ行けないときはコマンドラインで変数を渡して上げる方が良いですね。