2011年11月6日日曜日

window.nameで止まる?[javascript]

基本Chromeで見てるので、IEはいつも後回しなんだけど、しょっちゅうIEで何か不具合があります・・

ポップアップでWindowを開くページがありました。
複数のリンクがあるけど、同じリンク先がいくつか現れる可能性もあります。

Windowをポップアップした状態で、また同じポップアップリンクを押してしまった場合、もうWindowは開かないという処理が必要です。

こんな時はwindowのnameプロパティを使って制御するわけですが、IEで見ると何故かwindow.nameを参照したところで止まってしまいます。


var win; // グローバル変数でWindowオブジェクトを管理

$('#elm').click(function() {
    var win_name = $('input[name="xx"]').val();
    if (win && win.name == win_name) {
        return false;
    }
    win = window.open('xx.html', win_name);
});


まぁザックリとこんな感じです。
これはChromeとかFirefoxでは動くけどIE9で見てたらif文のところで止まる場合があります。

止まる「場合がある」というのは、止まらない場合もあるということです。

window.openしたWindowを閉じてから、また別のリンクを開こうとした際に止まるようです。

1回目ポップアップを開いた時は、グローバル変数のwinは空なので、if文を抜けてwindow.openします。
そして、そのWindowを閉じてからもう一回ポップアップを開く時、winにはWindowオブジェクトが格納されているのですが、プロパティを参照できない状態という感じなんだと思います。

なので、Windowが閉じたかどうかをチェックしないといけなかったわけです。


var win; // グローバル変数でWindowオブジェクトを管理

$('#elm').click(function() {
    var win_name = $('input[name="xx"]').val();
    if (win && !win.closed && win.name == win_name) {
        return false;
    }
    win = window.open('xx.html', win_name);
});


こうして、window.closedプロパティを見れば無事思った動作になりました。
分かりにくかったのは、winにWindowオブジェクトが入ってるけど、もうWindowのプロパティがないという状態だったということですね。
多分Chromeとかだと、windowを閉じた時点でwin自体がnullになってるんでしょうか?
そこまでチェックはしてないけど、とりあえず解決できました。

2011年11月4日金曜日

ChromeでPOSTしたページのソース

以前に書いた記事で、Chromeを使っててPOSTした後のページのソースが見れないということを言ってたと思うのですが、「要素の検証」で見れました。

右クリックして「要素の検証」を開いて、「Resources」タブを選択すると見れました。
そればかりか、「Network」タブを開けばFirefoxのエクステンション「HttpLiveHeaders」と同じ情報も見れます。

Chromeかなり凄いです。
これがあればFireBug不要ですね。

あとはFireMobileSimulatorみたいなのがあればいいんですけど、3キャリアの絵文字まで表示できるのはまだ無さそうです。

Firefoxも更新を頻繁にするようになってからFireMobileSimulatorが更新されなくなったような・・
最近使ってないから知らないけど、バージョンアップでアドオンが使えなくなるのはちょっと残念な話です。

2011年10月29日土曜日

エックスサーバーのcronでphp5が動かない?

エックスサーバーを使ってcronを使おうとした時のこと。
最初は自分の開発環境と同じように書いてみました。
0分、30分、50分にcron.phpを実行するという感じです。cron.phpはphp5とします。

分:0,30,50
時:*
日:*
月:*
曜日:*
コマンド:php /home/ユーザーID/ドメイン/public_html/cron.php

当然というか予想通りと言うか・・動きません。
この手の設定は調べながらやった方が確実です。

そこで、ザックリと調べて得た答えが


/usr/bin/php5 /home/ユーザー名/ドメイン/public_html/cron.php


という書き方。
コマンドのphpはフルパスで指定するのは当然なのかな?開発環境ではパスを通してたので・・
エックスサーバーでphp5は使えるけど、cronの時はphp5を指定しないとphp4として動くとか何とかって話でした。

なるほど・・と思い早速修正。
それでも動かない・・・

途方にくれながら管理画面をカチカチと見ていて、サーバー管理画面トップの「サーバー情報」に入ると、「コマンドパス一覧」という項目があったので見てみることに。
それで解決しました。

php5 というコマンドはもう無くなっていて、php4、php、php5.2、php5.3という4パターンあることが判明。
phpコマンドを実行するとphp5.1で走るようです。
今回は5.3で実行することにしました。


/usr/bin/php5.3 /home/ユーザー名/ドメイン/public_html/cron.php


これでちゃんと動きました。
試用期間中は確認メールが届かないようなので、処理がちゃんと走ったかどうかは実行結果を見に行かないといけません。

2011年10月26日水曜日

ネットショップで商品を売れるようにしてって・・

楽天にショップを出してるけど商品がほとんど売れない・・そんな会社は多いと思います。

商品名やキャッチコピー、紹介文の最適化で改善される例もあると思います。
広告を打ってみたら変わる場合もあると思います。

でも、やっぱり売れないものは売れないですね。

「楽天じゃダメだから自社ショップを立ち上げたい」という人も中にはいます。
これが一番ダメな選択だと思います。
楽天でダメなら自社ショップはもっと厳しいです。

楽天で検索する人は、GoogleやYahooで検索する人よりも「買う気」のある人です。
楽天の検索結果に商品が載るということは、売れる可能性はGoogleなんかに引っかかるよりも高くなるはずです。

自社ショップになってしまうと、当然楽天の検索には載りませんし、検索サイトからのアクセスが中心になると思います。
でも、検索サイトってのは、「買う」よりも「調べる」という要素が強いので、売れる可能性は下がりますね。


今回は売れるようにしてくれと言われたけど、そんなことが簡単にできるなら自分で何か売ってます。
でも、商品を見もしないで「売れないものは売れないし諦めろ」とは言えないので、とりあえず調査をするわけです。

まずいくつかある商品の一個を検索してみると・・他社でも扱ってる商品でした。
しかもかなりの大手から小さな会社まで色々な場所で扱っています。
楽天の他店舗にもありましたし、Amazonにもありました。
これが売れるとは思えないですね。

他の商品も調べてみたけど、どれも同じような感じです。
これはECサイト向きの商品ではないということだと結論を出しました。

ECサイトで物を売りたいなら「オリジナル」か「他社より安い」ことが条件になるんじゃないかと思います。
適当な卸店から仕入れてコンビニや薬局と同じように売っているのではダメです。


ECサイトで成功するのって本当に難しいと思います。
よほど商品力か価格競争力がない限りやるもんじゃないです。

2011年10月24日月曜日

サブカテゴリ(小カテゴリ)の一覧を取得[Wordpress]

サブカテゴリの一覧が必要になったので、ちょっと関数を作ってみました。
親カテゴリの情報をカテゴリスラッグから取得するので、get_category_by_slugを使ってます。

function get_subcategories($slug) {
    $cat = get_category_by_slug($slug);
    $lists = get_terms("category", "child_of={$cat->term_id}");
    foreach ($lists as $list) {
        $cats[] = array (
            'slug' => $list->slug,
            'slug_name' => $list->name,
            'description' => $list->description,
            'count' => $list->count
        );
 }
 return $cats;
}

カテゴリの取得順序はプラグインのMy Category Order辺りを利用して、get_termsの箇所を以下のようにすればOKだと思います。

$lists = get_terms("category", "child_of={$cat->term_id}&orderby=order&order=ASC");


get_terms関数を知るまでは、wp_list_categoriesを使って、正規表現で抜き出したコードを書いてました(^^;
でもそれだとdescriptionが取得できないんですよね。
もうちょっと関数知らないと思わぬ無駄な処理をしてしまうことになりそうです。

2011年10月22日土曜日

get_the_categoryで親と子の取得順序[Wordpress]

あるWebの規約で、必ず親カテゴリと小カテゴリに一個ずつチェックをつけて記事を投稿するというのがありました。

元々は小カテゴリは不要で、親カテゴリの記事の一覧を作るだけのページだけど、もし万が一親カテゴリの記事が100件とかに増えてしまった場合、小カテゴリで区切って表示させようという意図があります。
なので、今回のコーディングでは小カテゴリは完全に無視して、親カテゴリだけを扱って、もし小カテゴリで分ける必要が出てくれば再コーディングするということです。

まぁこんなページで親カテゴリ名を取得しようとした時のこと。

while ($query->have_posts()) {
    $query->the_post();
     // カテゴリ取得
    $cat = get_the_category();
    $cat = $cat[0];
}
return $cat->name;

こんなコードを書いてみると、親カテゴリ名を返す場合と、小カテゴリ名を返す場合がありました。
get_the_categoryって関数は、カテゴリの親子関係順に配列を返してくれるわけではないようです。

これでは困るので以下のように書き換え

// カテゴリ取得
$cat = get_the_category();
// 親カテゴリを取得
foreach ($cat as $val) {
    if ($val->category_parent == 0) {
        $cat_parent = $val;
        break;
    }
}
return $cat_parent->name;


もしこれを小カテゴリ対応するとしたら

// カテゴリ取得
$cat = get_the_category();
// 親カテゴリを取得
foreach ($cat as $val) {
    if ($val->category_parent == 0) {
        $cat_parent = $val;
    } else {
        $cat_sub = $val;
    }
}

みたいにすれば1つの親カテゴリ、1つの子カテゴリなら対応できますね。

複数カテゴリに対応するには変数を配列にする等していけば何とかなるんじゃないかな。
今回はそこまで求められてないのでどうでもいいけど。

2011年10月20日木曜日

正常に表示されてるのに404エラー[Wordpress]

あるサイトの仕上げにHTML Validationチェックをかけていた時のこと。

ちゃんと画面は表示されているのに、Validation ServiceにURLを送信すると404エラーになるページがありました。

どのページも共通してWordpressのヘッダーをrequireしていたので、原因はWordpressしかないと考えました。


require_once 'blog/wp-blog-header.php';

do_something..


こんな感じでwp-blog-header.phpをrequireしていたので、まずはwp-blog-header.phpのソースをチェック。


if ( !isset($wp_did_header) ) {
    $wp_did_header = true;
    require_once( dirname(__FILE__) . '/wp-load.php' );
    wp();
    require_once( ABSPATH . WPINC . '/template-loader.php' );
}


こんなのが書いてあります。

行数が少ないので、一個ずつコメントアウトして動作チェックしてみると、wp() 関数をコメントアウトしたら404エラーが出なくなりました。
そして、template-loader.phpを読まなくても問題ないので、ここで必要なのは wp-load.phpだけということになります。

なので、wp-blog-header.phpのrequireをやめて、wp-load.phpを読み込むように変更しました。


require_once 'blog/wp-load.php';

do_something...


こうすることで404エラーは出なくなり、validationも無事通すことができました。

結局wp()関数が何をしているのかは検証してないけど、Wordpressの機能だけ使えたら問題ないので必要ないでしょう。


これって、画面が正常に表示されているだけに気づきにくい問題です。
もしWordpressを組み込んだサイトを作って、wp-blog-header.phpをrequireしている人がいたら、一度W3CのHTML Validation ServiceにURLを送ってみるとか、Chromeの「要素の検証」で「Network」を開いてチェックしてみるとかしてみた方がいいですね。

ちなみに今回のWordpressのバージョンは3.2系だったと思います。