WP Total Hacksをアップデートしました。
ゆりこさんにご指摘いただいた内容で以下の項目については今後検討させて下さい。
みよしさんが開発したContactForm7に、Google Ajax API上のjQueryとDatePickerを使って、日付入力用のカレンダーを付ける方法です。
まずはじめに、今回はオレオレ仕様なので、あらかじめ以下のことを理解しておいてください。
以下のソースをプラグイン化した後、ContactForm 7 で、日付を入力したいテキストボックスに、datepicker というクラス属性をつけて下さい。
やってることをかいつまんで説明すると以下のとおり。
今回の私の目的では管理画面は関係無いので、管理画面側では上述の処理はしていません。
このへんの処理に関する解説は以下のページで。
オレオレ仕様なのでプラグイン化してません。
カレンダーを表示する際に以下のようなオプションも追加しています。
WordPressでは公開状態を「パスワード保護」とか「非公開」にすることで、コンテンツに認証をかけることが可能です。
でも、これらの方法では投稿したコンテンツ全体に認証が必要です。
一方で、記事を途中まで見せて、続きはログインしてねみたいな認証をかけるには以下のようなショートコードを使用するとオッケー。
以下のソースをプラグインとしてインストールするか functions.php にコピペして下さい。
以下のような感じで認証をかけたい部分を [auth]〜[/auth] で囲むと、その部分のみログインユーザーのみが閲覧可能なコンテンツになります。
掌の上で少し落ちついて書生の顔を見たのがいわゆる人間というものの見始であろう。 [auth]この時妙なものだと思った感じが今でも残っている。 第一毛をもって装飾されべきはずの顔がつるつるしてまるで薬缶だ。[/auth] その後猫にもだいぶ逢ったがこんな片輪には一度も出会わした事がない。
主な需要はエロサイトかな。笑
今回の記事は前回の記事の続きです。
事の発端は、WP Total Hacksの最終行に改行があるぞと指摘を受けたとこからでした。
しかし、実際には改行を入れた覚えはないし実際にvim上でもtracでも改行はないし、いままでに不具合の指摘を受けたこともありませんでした。
でもGUIベースのテキストエディターで開くと最終行に改行が入ってるではないですかっ！
で、よくよく調べたら以下のような事実が判明。
しかし、これだとひとつ問題が。
PHPは、<?php ?> の外側は何でも出力してしまうので、viでphpスクリプトを書く時は手を打たなきゃイカン。
でも、それってPOSIXの定義に反しててちょっと不思議。
以上が前回の記事です。
PHPのパーサーは、閉じタグの直後の改行を自動的に削除する仕様になっています。
したがって、
<?php // some action ?> [EOF]
みたいなファイルをrequireしても全く問題はありません。
あと、以下のようなphpの出力結果は、
<?php echo '<div>'; ?> foo <?php echo '</div>'; ?>
こんな風に改行が抜け落ちます。
<div>foo </div>
vim で PHP ファイルを編集する時に、前回の記事で紹介したような設定やコマンドを実行することは不要です。
あと、終了タグを書いちゃいけないという記述のブログ記事がたくさんありますが、「終了タグの後に余分な文字列を書かない」と「終了タグを書かない」は、どっちも書かないように気をつけるという意味でおなじようなものなので、終了タグを書いちゃダメというのは言いすぎかなと。（マニュアルでも書かないほうが無難と表現しています。）
vim 等により勝手に入っちゃう改行は無視されるわけですから！
実際、WordPressコアに含まれるファイルの多くが、?>（改行）で終わっています。
最終行の終了タグ直後の改行が嫌われる根本的な原因は、GUIベースのテキストエディターが、改行をトリガーにして新しい行があるかのように表示するからではないかと思います。
でも、これはしょうがいない。改行入れた時に新しい行ができなかったらいつできんねん！？ってことですから。
一方で、gccのようにファイルの最後が改行じゃないとエラーを吐くシステムもあります。
なぜ gcc はファイルの最後に改行がないと警告を出すのか？ – Schi Heil と叫ぶために
gccも行の最後は必ず改行であるべしという定義を守ってるんですね。
まずは理解すべき点。
「テキストファイルの行末は必ず改行が入っているべき」と定義されています。
私は普段 vim でプラグインを開発しているので、閉じタグの直後に改行が入っています。
なので、テキストエディターで開くと「あほかっ！」と頭に血が上ることもあるかと思いますが、phpのパーサーはもとよりtrac、subverionなどのツール類でもEOF直前の改行は無視しており、これが正しい姿なので、暖かく見守ってあげて下さい。（笑）
とはいっても、余計な心配をかけないように、終了タグ自体を順次消していったほうがいいですね。
変な誤解を与えないようにという意味でphpの終了タグは消したほうがいいかなと思った次第です。
ちなみに、このように閉じタグ直後の改行は無視されるという結果オーライな事実が判明しましたが、私自身入れてはダメと思いながら知らないうちに入っていたというのが事の発端なので、私の不勉強が諸悪の根源です。
すいませんすいません。
今日、Yuriko.netの管理人さんでKtai Styleの開発者のゆりこさんからコメントやTwitterでTotal Hacksについて不具合をいくつかご指摘いただきました。
1行ずつ追っかけていただいたらしく、グサっと刺さる部分もありましたが（笑）本当にありがたい事です。
指摘していただいた内容については勉強不足も大いにあって、もう本当にごめんなさいで、今週中にはアップデートします。
ゆりこさんから指摘いただいた不具合の中で衝撃的だったのがこれ。
なぬ？
いままで不具合の報告もなかったので疑問に思って調べてみました。
実はここまでで、いちどゆりこさんには「改行ないっすよ」と回答したんですが。ふたたび「あるよ」と。
なんですと？
一瞬、頭がフリーズしかけたんですが、ふっと思い立ってテキストエディターで開いてみると、あるではないですか改行が！
あちゃーっ、改行コードがCRなんだね、そうなんだねと思って調べたらそうでもなさそう。
うーーーーん。
結論から言うと正確なソースが見つからなくて詳しいことははっきりしないのですが、以下のような感じみたいです。
twitterでこの件に関してゴチャゴチャ言っていると天の声が飛んできました。
もしくは、以下のような方法もありですね。
結果オーライ（？）でこれらの方法で問題は解消するのですが、個人的には以下のような疑問を感じます。
というわけで、詳しい人、どなたか解説して下さい。
世界でトップシェアのオープンソースCMS ”WordPress” のイベント、WordCamp Kobe 2011 に行ってきました。
前日の夜に開催されたヤットさん主催の WebAttend 2011 から、WordCamp Kobe 2011 まで、以前から会いたかったいろんな人に会えて、大興奮の2日間でした。
以前の記事でも告知させて頂きましたが、開発者向けセッションで講師として登壇させて頂きました。
予想外に大勢の人に聞いていただいて本当に感謝です。
女性が過半数以上だったデザイナー向けセッションに比べると、女性が少なかったのが気になりますが（笑）
しかし、来場いただいたみなさんは御存知の通り、機材のトラブルでアドリブでセッションをすることになってしまいました。
そんなわけで伝わりにくかったと思いますが、ここで使用する予定だったスライドを掲載させて頂きます。
ほかの講師と比べると手抜きな感じが否めませんが。（笑）
個人的にはセッションを見るよりも、以前からtwitter上で交流のあるプラグイン開発者のみなさんやWordPress日本化プロジェクトのみなさんと、いろいろとお話ができたので、もうそれだけで大満足でした。
あと、名刺交換の際にTotal Hacksの宮内さんですか？とか言っていただいた方が数人いらっしゃって、それだけでハグしたいぐらい嬉しかったです。（笑）
いいかげんな人間だとバレてしまいましたが、WordCampでお会いしたみなさん、こんごともよろしくお願いいたします。
（できれば仕事下さい。なるべく小さいやつで。笑）
直前の告知ですが、9/11に神戸芸術工科大学で行われるWordCamp Kobe 2011でしゃべらせていただきます。
タイトルは「WordPressとWP Total Hacksで制作するクライアント向けサイト」です。
内容はといいますと、私が開発したWP Total Hacksプラグインの機能のご紹介をしながら、クライアント向けサイトを請負で制作する際の、ポイントとかノウハウを惜しげも無く公開しちゃおうと思っています。（たいしたものではありませんが。^^）
請負でWordPressサイトを構築している皆様に、役立つ情報をご提供しますので、ぜひ聞いてあげて下さい。
あと、私は現在、和歌山県の串本町に住んでおりますので、セッションの最後の5分ほどを使って台風12号の被災地の現状と、ご協力のお願いもさせてください。
大勢の前で話すのは苦手な上に大勢の方が参加するようなので、めっちゃプレッシャーですが、頑張ります！
oEmbed Gistをアップデートしました。
http://firegoby.theta.ne.jp/wp/oembed-gist
今回のアップデートでは、JavaScriptが無効のユーザーに対して<noscript>を出力するよう修正しました。
この修正に対してパッチを送付いただいた、Alex Kingさんにお礼を申し上げます。
なんかこのAlex KingさんはWordPress界では有名な人らしく。
みたいなリアクションがあったので、
と、きいたら教えてくれました。
まがりんとゆりこさんを足して２で割ったような感じ？
たしかにすごそう…w
WordPressの投稿フォーマットを使用すると、投稿毎に異なったスタイルを適用することができるので、超便利です。
しかし、この便利な投稿フォーマットはデフォルトでは固定ページで使用できません。
代わりに固定ページではページテンプレートというのが使用できますが、テンプレートファイルを作ったりCSSを書いたりするのが面倒だったので、固定ページで投稿フォーマットを有効にしてみました。
以下は、テーマファイルのfunctions.phpに記述して下さい。
管理画面側で投稿フォーマットを有効にするには以下の1行をfunctions.phpに記述するだけでオッケーです。
add_post_type_support('page', 'post-formats');
たったこれだけで以下のように投稿フォーマット選択用のメタボックスが追加されました。
固定ページの一覧画面でも以下のような感じで投稿フォーマットが表示されます。
密かにステップ１の作業だけでclass属性が出力されることを期待したのですが、残念ながらこの部分はsingleページかどうかの条件分岐の中に入っていたので、フィルターフックでclass属性を追加する必要があります。
以下のソースをテーマのfunctions.phpにコピペして下さい。
add_filter("body_class", "my_body_class");
function my_body_class($classes) {
if (is_page()) {
global $post;
$fmt = 'page-format-'.get_post_format($post->ID);
$classes[] = $fmt;
}
return $classes;
}
ここまでの作業が完了したら、固定ページ上で任意の投稿フォーマットを選択して、実際のページ上のbody要素にpage-format-asideなどのclass属性が追加されたことを確認して下さい。
あとは、CSSをゴニョゴニョするだけです。
試してないのですが、以下のように.htaccessで制御する記事を海外のブログで見つけたので、メモがわりに書いておきます。
この方法を使用するとプラグインを使わなくてもアップロードファイルにパスワード保護をかけられるので、SNS系のシステムなどを構築するのに便利かもしれません。
方法はとてもシンプルで、以下のソースを.htaccessに記述するだけです。
試してないのであしからず。