2011年11月24日木曜日

Wordbookerでサムネイルを非表示に[Wordpress]

WordpressのプラグインWordbookerは、投稿した記事をfacebookと連動できるという素晴らしいプラグインです。

Wordpressの案件で利用したのですが、投稿するとfacebookのウォールには関係ない画像が載ってしまいました。
よくある「ページトップへ」って画像が必ずサムネイルになってしまうという状況だったのですが、これではカッコ悪いです。
サムネイルを非表示にしようということになりました。

Wordbookerはまだ設定画面が全部英語なので何かよく分からないけど、何だかサムネイルをオフにする設定がないようなので、プラグインのコードをちょっといじって無理やり非表示にしました。

Wordbookerプラグインのwordbooker.phpの中の


    $post_data = array(
        'media' => $images,
        'post_link' => $post_link,
        'post_link_share' => $post_link_share,
        'post_title' => $post_title,
        'post_excerpt' => $post_content,
        'post_attribute' => $post_attribute,
       # 'post_full_text' => $post->post_content,
        'post_id'=>$post->ID,
        'post_date'=>$post->post_date
        );


の箇所と


    $wordbooker_fb_post = array(
        'name' => $post_data['post_title'],
        'link' => $post_data['post_link'],
        'message'=> $post_data['post_attribute'],
        'description' => $post_data['post_excerpt'],
        'media' => json_encode($images)
    );


の箇所の 赤字にしてある部分'media'を '_media'にする等して別の名前にします。
これで画像が出なくなりました。

その代わり、画像を出したくても出せないのが難点ですね。
まぁこの案件ではテキスト情報の更新しかしないのでこれでOKなのです。
ちなみにWordbookerのバージョンは2.0.8でした。

2011年11月20日日曜日

[CakePHP2.0]複数サブドメインでモデルを共有する

サイトの設計上、管理画面と公開画面をサブドメインで分けることになりました。
とは言え、Vendorやモデルは共有したので、ちょっとCakePHPの設定をいじらないといけません。

ControllerとViewだけを切り分けて、他のファイルを共通化するというのが一番いいのかな?
フォルダ構成はこんな感じになりました。


root
├cake
│├app
│└cake
├www.example.com(公開用)
│└public_html
└admin.example.com(管理用)
 └public_html


各public_htmlフォルダのindex.phpで、「ROOT」と「APP_DIR」と「CAKE_CORE_INCLUDE_PATH」の定数を設定します。
今回の場合は以下のようになりました。


if (!defined('ROOT')) {
    define('ROOT', dirname(dirname(dirname(__FILE__))).DS.'cake');
}
if (!defined('APP_DIR')) {
    define('APP_DIR', 'app');
}
if (!defined('CAKE_CORE_INCLUDE_PATH')) {
    define('CAKE_CORE_INCLUDE_PATH', dirname(dirname(dirname(__FILE__))).DS.'cake'.DS.'cake'.DS.'lib');
}


そして、ファイル管理をしやすくする為に root/cake/appのControllerとViewをフォルダで区切ります


app
├Controller
│├admin
│└www
└View
 ├admin
 └www


フォルダを区切るだけでは認識されないので、 app/Config/bootstrap.php に以下のコードを追記します。


App::build(array(
    'Controller' => array (
         ROOT.DS.APP_DIR.DS.'Controller'.DS.'admin'.DS,
         ROOT.DS.APP_DIR.DS.'Controller'.DS.'www'.DS
     ),
     'View' => array (
         ROOT.DS.APP_DIR.DS.'View'.DS.'admin'.DS,
         ROOT.DS.APP_DIR.DS.'View'.DS.'www'.DS
     )
));


これで、Modelを共有して複数のサブドメインから1つのCakePHPを参照することができます。

問題点は、フォルダで区切るから、同じ名前のコントローラー名をつけることができてしまうってことかな。
adminとwwwにPagesController.phpを作ってしまうとどちらか(多分adminの方)を読み込んで、片方は読まれません。
なので、この方法でやる場合はcontrollerの重複に気を付けないといけない感じです。

あと、app/routes.phpで調整してドメインごとにトップページのコントローラーを変える等の調整が必要です。
例えば、AdminPagesController.php をadmin.example.comのルートに設定する場合、


$host = explode('.', $_SERVER['HTTP_HOST']);
switch ($host[0]) {
    case 'admin':
        Router::connect('/', array('controller' => 'admin_pages', 'action' => 'display', 'home'));
        break;
    default:
        Router::connect('/', array('controller' => 'pages', 'action' => 'display', 'home'));
        break;
}


こんな感じでいいんじゃないかな。
ルーティングしてしまえばURLは何とでもなるし、adminフォルダならファイル名の接頭語にadminを付けるとかして工夫した方が安全ですね。

2011年11月17日木曜日

[CakePHP2.0]モデルのprefixが複数あるテーブルを扱う時

ちょっとCakePHPのプログラムを書いてます。

smartyばっかりだったのでなかなかフレームワークには馴染めませんでしたが、慣れてしまうとsmartyより便利ですね。
コードの量が減った気がします。

さてさて、CakePHPではデータベースのprefixを指定して管理することができます。

prefixと言うと、日本語なら「接頭語」って感じですかね・・例えば、cake_items、cake_prices、cake_details・・・という感じで、頭に必ずついてる「cake_」がprefixになります。
この共通の接頭語を app/Config/database.php のDB設定欄 prefixの値で設定することで、prefixを省略してContrllerの名前を付けたりできるわけです。


public $default = array(
 'datasource' => 'Database/Mysql',
 'persistent' => false,
 'host' => 'localhost',
 'login' => 'login_id',
 'password' => 'login_pass',
 'database' => 'sample',
 'prefix' => 'cake_',
 'encoding' => 'utf8',
);


1つのデータベースでWordpressやCakePHPや何だかんだと複数のアプリを管理している場合に便利ですね。

ところが今回のデータベースは、CakePHP上で扱うデータベースだけど接頭語の種類が複数あるというタイプでした。
例えば、マスターテーブル、アプリ用テーブル、設定用テーブルと種類分けされていて、それぞれに接頭語があるという感じです。
例えば、mst_items、app_histories、st_applications・・といった感じですね。

この場合、prefixを指定せずに、modelの中で使用するテーブル名を設定してもいいと思います。


/**
 * app_historiesテーブル
 */
class History extends AppModel {
    public $name = 'History';
    public $useTable = 'app_histories';
}


でも、今回は、大半がアプリ用テーブルだったので、prefixには 'app_' を設定しています。
この場合、マスターテーブル等のモデルをどうするかと言うと、


/**
 * mst_itemsテーブル
 */
public MstItem extends AppModel {
    public $name = 'MstItem';
    public $tablePrefix = '';
}


として、$tabelPrefix を空白に設定してやるとOKです。
マスターテーブルと分かるように、あえてMstItemという名前にしてますが、Itemとして管理したい場合は、$tablePrefixをmst_にすればいいんじゃないかな。これはやってません。


public Item extends AppModel {
    public $name = 'Item';
    public $tablePrefix = 'mst_';
}


結構柔軟に何でも扱えますね。
バージョン1.2の頃に使ったことがあったけど、バージョン2系になってからは初のCakePHPです。
findAllとか動かなくなってるんですね。
今現在(2011/11/18)まだ2系のリファレンス本は出てないような感じなので、しばらくはネット中心で情報を集めていくしかなさそうです。

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が更新されなくなったような・・
最近使ってないから知らないけど、バージョンアップでアドオンが使えなくなるのはちょっと残念な話です。