移転しました。
2013年2月〜
http://kanonji.info/blog/

2008年11月〜2013年1月
http://d.hatena.ne.jp/kanonji/

はてなダイアリーに移転してたけど、そっからさらにWordPressでのブログに移転しました。
 
201302061607
スポンサーサイト
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
別窓 | スポンサー広告
----------
Firefoxで独自プロトコル(スキーマ)を定義する方法 が書かれてるエントリへのリンク
ちょっとうっかりアンインストールしてしまい、独自プロトコルの設定が消えてしまった。
インストーラーからのインストールをしなくても使用できるZIP配布のあるツールだったので、最新版をダウンロードしてみたが独自プロトコルの設定方法が分からなかった。
「about:config」あたりで設定できるものだと思っていたが、どうやら違うようだ。

独自プロトコル(スキーマ)とは例えば「callto://」といったもの。
「callto://」の場合は、「callto://」から始まるリンクをクリックすることで、電話ツールが起動しそのまま電話をかけることが出来る。
設定によりSkypeだったりMSNメッセンジャーだったりが起動することになる。

さてその方法は以下のエントリが参考になる。
そして意外だったが、設定をちょこちょこっと変えればOKというものではなく、割とめんどくさいものの様だ。

Firefoxで独自プロトコルを定義する方法

「about:config」ではプロトコルの追加は出来ないが、設定済みのプロトコルを無効にしたりすることは出来るようだ。
以下URL先を参考にどんな設定が可能かだけを書いてみた。
「true/false」は推奨する設定とかじゃなくテキトウなので、設定する場合は自分で適切な値を調べて欲しい。

Mozilla-gumi Forum [One Topic All View / user.js での設定が完成 / Page: 0]

// Firefox で全てのスキームを処理することを許可する
user_pref("network.protocol-handler.expose-all", false);

// Firefox で各スキームを処理することを個別に許可する(expose-allを上書き)
user_pref("network.protocol-handler.expose.<プロトコル名>", true);

// Firefox で処理できない全てのスキームをOSで定義されているアプリケーションに渡すことを許可する。
user_pref("network.protocol-handler.external-default", false);

// Firefox で処理できないスキーム "スキーム名" をOSで定義されているアプリケーションに渡すことを許可する。(external-default を上書き)
user_pref("network.protocol-handler.external.<プロトコル名>", false);

// 全てのスキームを外部のアプリケーションで処理する際に警告を表示する
user_pref("network.protocol-handler.warn-external-default", true);

// 各スキームを外部のアプリケーションで処理する際に警告を表示する
user_pref("network.protocol-handler.warn-external.<プロトコル名>", true);

当然のことながら、
user_pref("network.protocol-handler.external.hogehoge", true);
とかやっても「hogehoge://」で起動すべきアプリケーションが分からないのでうまくはいかなかった。
スポンサーサイト
別窓 | ブラウザの拡張 | コメント:0 | トラックバック:0
200707311222
WordPressME2.2インストールメモ
WordPressME2.2インストールメモ

WordPressMEは日本ユーザ向けにカスタマイズしたMultilingual Edition。
マルチリンガルと書いてはいるが、今のところ実質日本語バージョンのようだ。

本家WordPress配布元
WordPress ? Blog Tool and Weblog Platform

WordPressME配布元
WordPress Japan

大きく分けて2.0系と2.2系の2本立てとなっており、2.2系のほうは文字コードがUTF-8のみの対応となっている。
2.0系はEUC-JPに対応しているので、EUC-JPで無ければ困る場合は2.0系を使うことになる。
基本的に文字コードなど、日本向けローカライズ以外はオリジナルとほとんど同じの様子。

○EUC-JPの環境で無理やりUTF-8な2.2系を動かす。

インストールしたサーバは、PHPもMySQLもEUC-JP向けの設定になっていたが、どうせなら新しいほうを入れたかったので無理やり2.0系をインストールした。
当然文字コードが違うため、日本語をPOSTした場合うまくいかない。
.htaccessとmbstring関数で無理やり回避してみた。

---.htaccess---
php_value mbstring.internal_encoding UTF-8
//WordPressME2.2はUTF-8で動いているので、内部エンコードをUTF-8にする。WordPressのwp-config.phpで「mb_internal_encoding('UTF-8');」されているがどうせならまとめとく。

php_value mbstring.http_input UTF-8
// 「auto」は、「ASCII,JIS,UTF-8,EUC-JP,SJIS」に展開されるはずだがなぜかどのinputもASCIIとして認識してしまう。
//これが問題なので、決めうちでUTF-8に設定する。
//mbstring.http_inputはマニュアルで「PHP_INI_ALL」と書いてあるが、「スクリプトではhttp_inputの設定は変更できません。」とも書いてある。
//実際、mb_http_input()は設定をする機能は無いので、.htaccessかphp.iniで設定するほか無い。

php_value mbstring.http_output UTF-8
//当然出力はUTF-8
---.htaccess---

その他php.iniでは以下が設定されている。
mbstring.encoding_translationとmbstring.http_inputの関わりがよく分からない。
mbstring.encoding_translationが曲者なのかもしれない。

---php.ini---
mbstring.encoding_translation On
mbstring.language Japanese
---php.ini---

参考
PHP: マルチバイト文字列関数 (mbstring) - Manual

○HTMLを含む投稿をするとどうも変な動きをする

WordPressのコントロールパネルはかなりきれいにまとまっていて、完成度の高さの表れだと思う。
しかし、投稿機能の動きがどうもおかしい。

WordPressには2種類の投稿エディタが用意されている。
いわゆるワードプロセッサの様に、太字などの簡単な装飾をHTMLやCSSを書くことなく指定できるビジュアルエディタと、
そういった機能の無い単なる入力フォームのコードエディタだ。
ビジュアルエディタも内部的には装飾用のタグかCSSを挿入しているはずだが、これがユーザが記述したHTMLやCSSをおかしくしてしまう。
コードエディタを使ってHTMLタグを含んだ投稿を書いている時、ビジュアルエディタに切り替えるとそこでコードを書き換えられてしまう。
また、投稿画面を開いたときデフォルトはビジュアルエディタの方で表示するため、既存のエントリを編集する場合それがHTMLタグを含んだエントリだったとしても、最初はビジュアルエディタで開いてしまう。
ビジュアルエディタからコードエディタに切り替えた時にコードをおかしくする前の内容で表示してくれればいいが、どうもそうはなっていない様子。
回避策としては、ビジュアルエディタはWordPressのユーザ単位で使用しない設定が可能。

また、ビジュアルエディタ・コードエディタの両方とも、エディタ上の改行をbrタグに置き換え、空白行があればpタグを挿入するようになっている。
便利といえば便利だが、これもHTMLやCSSを書きたい場合トラブルになる。
tableタグやobjectタグなどネストすること前提のタグの場合当然改行を含めて記述するが、この改行がbrに置き換わってしまいおかしくなってしまう。
WordPressのソースコードをざっと見ると、どうやら改行前後がHTMLタグの場合は置き換えないようにしている気もするが、これが不完なのかも知れない。

回避策としては、WordPressのソースコードを一部書き換え、brタグpタグの挿入機能をコメントアウトした。
書き換えるファイルは「wp-includes/default-filters.php」

修正前:
add_filter('the_content', 'wpautop');
add_filter('the_excerpt', 'wpautop');

修正後:
//add_filter('the_content', 'wpautop');
//add_filter('the_excerpt', 'wpautop');

○WordPressの出力するFeedはGoogleウェブマスターツールにてサイトマップとして登録できない。

Google ウェブマスター ツール - ウェブマスター ツール
ちゃんとしたsitemap.xmlを用意するのがめんどうだったのでとりあえず、RSSなどのFeedを登録しようとしたが拒否されてしまった。
これはFeedに記述されるサイトのURLが問題の様子。

例えば以下のURLでWordPressを運用しているとする。
http://example.com/wordpress/

その場合Feedに記述されるURLは以下のようになる。
http://example.com/wordpress

違いは最後の「/」が抜けている点。
これはRSS2.0の場合だが、AtomなどそのほかのFeedでも同様に最後の「/」が抜けている。

Googleウェブマスターツールでは、同じドメイン下でも階層が違えば別途認証を必要とする。
どうやらhttp://example.com/wordpress/のFeedではなく、http://example.com/のFeedだと認識し受け付けないようだ。
これはhttp://example.com/wordpress/とhttp://example.com/の両方を同じGoogleアカウントのGoogleウェブマスターツールで管理していても、拒否してくる。
WordPressのコントロールパネルでの設定で最後の「/」を入力してみたが、POSTすると最後の「/」は消されていた。
WordPress内では最後の「/」を付けずに運用されているようだ。

回避策としてはサイトマップ生成用のプラグインを導入する。
Google Sitemap Generator for WordPress v2 Final

インストールは簡単で日本語を含め多くの言語に対応している。
コントロールパネル内の設定画面も日本語で表示できるようになっているが、WordPressME2.2では多少修正が必要。
言語ファイルとしてsitemap-ja_JP.UTF-8.moとsitemap-ja_JP.UTF-8.poが用意されているが、WordPressME2.2ではwp-config.phpで「define ('WPLANG', 'ja');」と設定されている。
ファイル名を以下のように変更することで、コントロールパネル内で日本語にて表示されるようになる。

修正前:
sitemap-ja_JP.UTF-8.mo
sitemap-ja_JP.UTF-8.po

修正後:
sitemap-ja.mo
sitemap-ja.po
別窓 | 未分類 | コメント:2 | トラックバック:1
200707051540
| プログラマのチラシの裏 |
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。