hasOwnPropertyがない

Internet Explorer 8でチェックしてたら、window.hasOwnProperty()のところでエラーが発生。あれ?

自分の無知が恥ずかしい。。。

MSDNドキュメントをチェックしてみると、なんかドキュメントがええかげん。.hasOwnPropertyの説明では確かにIE8はサポートされない、と書いてあるんだけど・・・javascriptのバージョン情報のところを見ると、hasOwnPropertyは’Y’になっとる。

だけど、Object.hasOwnProperty はエラーは起こらず。どゆこと?

結局、IE8の時だけ、下記のようにする。

// これってもしかして、常識なの???(^^;;;
var undefined;
if(window.hasOwnProperty === undefined)
{
  window.hasOwnProperty = function(property_name)
    {
       return Object.prototype.hasOwnProperty.call(window,property_name); 
    };
}

なんか、釈然としない。はやくIE8消えてくれ。つか、会社のPC、いいかげん、XPから7にバージョンアップさせてほしい・・・自分で金出すから。

雑記

「いいね」ボタンより、「だめだめ」ボタンが欲しい今日この頃です。

7月から別の部署で、違う人の下で仕事するようになってルーチンワークが続き、好き勝手できなくなったので(^^;;;、更新が途絶えてしまいました。

備忘録するネタはあるんですが、書くのに時間がかかりなかなか終わらない。もちっと暇になったら一気に更新しよう。

あ、iPad Air が発表されましたねー。僕は128GBのものに買い替えるつもり。どうせ1~2ヶ月は品薄で手に入らないんだし、来年頭ぐらいかな、買えるのは。

どんなプラットフォームでも、プログラムを書くって、言うと、ものすごく大層なことだと、誤解されていると思うことが多々ある。は???ってことに出くわす。

「データーベースとか使って、何でプログラム組んでるの? 言語なに?」
『んー、ほとんどPHPとかPerlとかスクリプトが中心かなー。』

とか言うと、半ば、見下される(笑) 別に見下されても悔しくも何ともないんだが。
たぶん、今なら
『 Java で Webシステムの構築とか、Access、SQLServerを使って業務系組んでます!』
とか恥ずかしい事を言うと、違った反応するのかもしれないw

プログラムのスキルってのは、使用しているプログラム言語やスクリプト、プラットフォームで決まるんじゃないんだよ。
どういう内容のプログラムを組んで、どういうアプローチでシステムを構築して、どういうコードを書いているかが、その人のスキルなんだよ。どういうフレームワークで仕事してるのか、どんな分担の仕事をしてるか、チームで組んだことはあるのか、ソースコード管理は?とか。コードのメンテ性を考慮してるか?とか。
C++やマシン語が書けても、簡単なWindowsのフォームベースのプログラムに何ヶ月も掛かってたんじゃ、意味ないんだよ。そんなのはスキルじゃないんだよ!

スーパーの特売日に、フェラーリやポルシェで買いに行くような、恥ずかしい真似はしたくない、のと同じように、データベース内のたかだかテーブル数個、一日数百レコードを更新するだけようなプログラムにこれ見よがしにJavaなんか使う必要あんの?

でも、実際は、あるんだよね(笑) ちゅーと半端にシステムをかじってる営業さんは、かっこいい横文字を使えば取引先に「どや顔」できるんだよね。。。そういう世界なんだよね。僕は営業ってできない。モノを売るってことの才覚はゼロ。だから、口には出さない。だから、ここで書く!(m_m)

閑話休題。

最近はjQuery + PHP にどっぷりはまってます。いや、僕的にはjQuery + Perl ( 時々C# )にしたいのだが・・・。
Wordpressのメディアの管理画面にようなモジュールが欲しくて、イチから組んでます。

最初はデータの保存にSQLiteを使用していたけど、SQLite関数を使わずPDOを使用してたので、どうせならMySQLでも切り替えて使えるように、データへのアクセスを抽象化したところから、ちょっと変な方向に・・・。

だいたい必要なものは組み込んだけど、後から後から、あれもこれもと、機能を組み込んでいくと、あっちゅーまにワケワカメなコードが・・・。

fileman02

エクスプローラ・フォルダの詳細表示ような画面が欲しくなって、リスト表示も。
後付け、後付けで機能を付け足すから、時間を無駄に食う。
fileman01

あとは、使い回せるように、モジュール化しないといけない。
自分でこういうコードを書いてて思うんですが、Wordpressって、ホントに良くできたシステムですよねぇ。

PHPの配列は9ソだ!

PHPの仕様に関して文句は別にないんだが・・・、あのPHPの配列だけは、どうにかならないものか・・・。

Perlだと、配列と連想配列は、配列なら、$array[0] 、連想配列なら、$hash{’00’}と、表記と共に明確に区別されているのでわかりやすいし、まぁ、間違えることは、少ない。

が、PHPのコードを書いてると、ホントにイライラする。ま、言語仕様を斜め読みしかしていない、あやふやな知識で書いているオイラが全面的に悪いんだけど。。。

データベースのとあるカラムからフェッチした、数字の文字列を、つい、うっかり、配列に入れて、foreachとかでぶん回していたら、あるはずのデータが未定義になる、という現象の解読に数時間費やしてしまった・・・。

$ar = array();

$ar[1] = 'ほげほげ';
$ar[23] = 'ほむほむ';

//$recordには、以下の値が入っていた。
//$record['date_begin_day'] = '01';

echo $ar[$record['date_begin_day']];

さて、僕は、当然 「ほげほげ」と出力されると信じて疑わなかった。
PHPで仕事している人は、たぶん、こう思うでしょう。

「おまえはアホか!もう一回、リファレンスを読めよ」

と。

echo $ar[intval($record['date_begin_day'])];
//intval関数を通さないといけなかった・・・。

perlなら配列の添字は数字に暗黙的に変換されるので何ら問題無い。

$ar[1] = 'ほげほげ';
$ar[23] = 'ほむほむ';

$record{'date_begin_day'} = '01';

print $ar[$record{'date_begin_day'}];

しかし、別の問題を引き起こすが・・・ま、一長一短ですかな・・・。

気を付けよう。。。

カスタム投稿タイプとパーマリンクと分割ページ

WordPressで、カスタム投稿タイプを作って、テーマを作り込んでいる途中、ちょっとはまった点があり、その備忘録です。

まぁ、既存のプラグインを導入すればいいわけですが、一つのテーマ内で全てを完結させたい、という方針で作ってる訳です、ハイ。
導入も簡単ですしね。プラグインをアレとコレと入れて、設定して・・・という手間はなるべく避けたいわけです。

さて、本題。

カスタム投稿タイプを作ってパーマリンクを投稿IDでアクセスさせようとしました。要するに・・・

ttp://hoge.com/information/123

っていう風に。これ自体はFAQなので、検索すると、下記コードが載ったブログ記事がいっぱいヒットします。

/* カスタム投稿タイプ information の例 */

add_action('init', 'myposttype_rewrite');
function myposttype_rewrite() {
    global $wp_rewrite;
    $queryarg = 'post_type=information&p=';
    $wp_rewrite->add_rewrite_tag('%information_id%', '([^/]+)', $queryarg);
    $wp_rewrite->add_permastruct('information', '/information/%information_id%', false);
}

add_filter('post_type_link', 'myposttype_permalink', 1, 3);
function myposttype_permalink($post_link, $id = 0, $leavename) {
    global $wp_rewrite;
    $post = &get_post($id);
    if ( is_wp_error( $post ) )
        return $post;
    $newlink = $wp_rewrite->get_extra_permastruct('information');
    $newlink = str_replace("%information_id%", $post->ID, $newlink);
    $newlink = home_url(user_trailingslashit($newlink));
    return $newlink;
}

だけど・・・これ現在のバージョン(3.5)では致命的な欠陥があります。

カスタム投稿タイプの投稿記事内に分割ページ(<!–nextpage–>>)を入れて、2ページ目、3ページ目・・・とアクセスできません。
要するに・・・

ttp://hoge.com/information/123/2

などのようにアクセスすると、投稿がありません、とかなってしまいます。つまり、上記コードを入れることで、Rewrite処理が上手く機能しなくなっているようです。試しに上記コードをコメントアウトすると、ちゃんと分割ページが機能します。カスタム投稿タイプのパーマリンクは、%postname%になっているはずですから、以下のようになるわけです。

ttp://hoge.com/information/投稿のタイトルのスラッグ/2

おそらく、パーマリンクを投稿IDにする、上記コードには何かが足りないのだと思います。Wordpressのフォーラムにも質問を投げて見たのですが結局アドバイス頂けなかったので、いろいろ試行錯誤しながら調べた結果、以下の一行を入れることで、無事分割ページが機能するようになりました。

/* ごめんなさい、浅学なんで、これで上手くいく理屈が分かりません。 */
$post_type = 'information'; //これはサンプル
add_rewrite_rule(&quot;{$post_type}/(.+?)/([0-9]+)$&quot;,'index.php?post_type='.$post_type.'&amp;p=$matches[1]&amp;page=$matches[2]','top');

つまり、分割ページのために、リライトルールを一個追加してしまえ、ってことです。

それと、ネットで検索して出てくる上記コードで、現在のWordpressのバージョンにおいて、フィルターフック名 ‘post_type_link’ でのコールバック関数の第二引数が間違っていると思います。

//上記コードでは、
function myposttype_permalink($post_link, $id = 0, $leavename){}

//となってますが、今のバージョンでは、
function myposttype_permalink($post_link,$post,$leavename){}

//という風に、バージョン3.1から、投稿IDではなく、WP_Postオブジェクト自体が渡されるように変更になっていると思われます。
// 参考URL http://adambrown.info/p/wp_hooks/hook/post_type_link

この点も踏まえて、修正したコードが、以下のようになります。

/* カスタム投稿タイプ information の例 の分割ページ対応修正版 */
add_action('init', 'myposttype_rewrite');
function myposttype_rewrite() {
    global $wp_rewrite;
    $queryarg = 'post_type=information&amp;p=';
    $wp_rewrite-&gt;add_rewrite_tag('%information_id%', '([^/]+)', $queryarg);
    $wp_rewrite-&gt;add_permastruct('information', '/information/%information_id%', false);

    add_rewrite_rule(&quot;information/(.+?)/([0-9]+)$&quot;,'index.php?post_type=information&amp;p=$matches[1]&amp;page=$matches[2]','top');
}

add_filter('post_type_link', 'myposttype_permalink', 1, 3);
function myposttype_permalink($post_link, $post, $leavename) {
    global $wp_rewrite;

    $newlink = $wp_rewrite-&gt;get_extra_permastruct('information');
    $newlink = str_replace(&quot;%information_id%&quot;, $post-&gt;ID, $newlink);
    $newlink = home_url(user_trailingslashit($newlink));
    return $newlink;
}

でも、この修正によって、別の不具合が出るかも・・・。まぁ、いいや。

パーマリンク関係のコードを変更したら、必ず、設定 => パーマリンクの空更新を忘れずに。

カスタム分類のrewrite

私的備忘録。

カスタム分類(Taxonomy)を登録する際、rewrite 引数をtrueにしたとき、has_archiveをtrueにしているにも関わらず、一覧が表示されないことがあった。あれこれ設定を調べてみても原因らしきものが分からなかった。

1日ほど、あれやこれや試した結果、どうやら、設定 => パーマリンク設定で、「変更を保存」を行わないとカスタム分類のrewriteが有効にならないことが判明。

もっと、厳密に調べてみると、wordpress api、flush_rewrite_rules関数をrewriteルールを変更した場合に最低一回コールしなければならない、らしい。

毎回コールする必要がないらしい?(実際のところ、面倒なのでソースを追ってないので理屈は分かりません) ので、設定・パーマリンク設定の変更を保存ボタンをクリックすることで、flush_rewrite_rules関数がコールされるのと同じことがされるみたい。

開発段階で、rewrite関係でおかしくなったら、パーマリンク設定で「変更を保存」で回避。

なんか、やっぱり本一冊買ってイチから勉強しなおした方が効率がいいかもしれない。。。