ホーム > タグ > WordPress
WordPress
XREAのレンタル共用サーバーに設置したWordPressでメディアの一括削除ができない
- 2009-07-03 (金)
- 技術
WordPressのバージョンは2.7.1です。
いつも書いてる通りXREAのサーバーはあまり触りたくないのですが、依頼なので仕方ありません。
XREAでWordPressを動かす場合、モジュール版PHPではパーミッションの関連上ファイル操作に難があり、普通に設置しただけではWordPressから画像などをアップロードすることが出来ません。（PHPのセーフモードがらみの問題で、仕様ですね）
そこで、管理画面は（もしくはアップロード用スクリプトのみを）CGI版PHPで動かす設定を.htaccessで施すことによってその問題を回避する方法があります。
まぁココまでは”XREA WordPress”などで検索すれば幾らでも出てくる情報なんですが、その設定をやった上で、今回新たに「メディアライブラリの一覧で、個々のファイルの左にあるチェックボックスを複数チェックして、一括して削除しようとしたときに、サーバーからの応答が無くなる」という問題が発生しました。
応答がなくても、実際によく調べてみると、ファイルの削除もデータベースの操作も完了してるっぽかったので正確には「削除できてる」んですが、削除ボタン（実際には適用ボタンですか）を押してから、ブラウザが延々といわゆる「読み込み中」のまま、という状態です。
HTTPヘッダも何も返ってこない状態。
該当部分のソースを読んでみたり色々テストしていくと、削除処理をした後のリダイレクト処理部分で”wp_redirect”という関数が呼ばれており、どうもその関数が上手く動いてない様子でした。
ちなみにモジュール版なら”wp_redirect”関数自体は普通に動作します。
一括削除処理だけモジュール版で動作するようにしようかと一瞬思いましたが、そのwp_redirect関数を含むファイルって、upload.phpなんですよね。
つまりupload.phpに表示・追加・削除の機能が一つにまとめられてるので、htaccessのfilesディレクティブで切り替える方法が使えません。
とりあえず今回はwp_redirectを呼んでる行をコメントアウトして、
<html>
<header>
<title>wordpress redirect</title>
<meta http-equiv=”Refresh” content=”0; URL=$location”>
</header>
<body>
しばらくお待ち下さい。
</body>
</html>
という内容を返すようにしました。
文字化けるかもしれないのでもっとちゃんとしたソースを返すようにした方がいいです。
他にもwp_redirect関数を呼び出してる部分があったのですが、それらはちゃんと動いてるようでした（ホントかな）のでそのままです。
一応調査の中で、
header(’Location: http://example.com/’);
などと一行だけ書いたスクリプトをCGI版で動かしてみたりしましたが普通に動きました。
まぁ、これが動かなかったら大問題になりますけど。
原因は複合的なんでしょうね。
いつも書いてる通りXREAのサーバーはあまり触りたくないのですが、依頼なので仕方ありません。
XREAでWordPressを動かす場合、モジュール版PHPではパーミッションの関連上ファイル操作に難があり、普通に設置しただけではWordPressから画像などをアップロードすることが出来ません。（PHPのセーフモードがらみの問題で、仕様ですね）
そこで、管理画面は（もしくはアップロード用スクリプトのみを）CGI版PHPで動かす設定を.htaccessで施すことによってその問題を回避する方法があります。
まぁココまでは”XREA WordPress”などで検索すれば幾らでも出てくる情報なんですが、その設定をやった上で、今回新たに「メディアライブラリの一覧で、個々のファイルの左にあるチェックボックスを複数チェックして、一括して削除しようとしたときに、サーバーからの応答が無くなる」という問題が発生しました。
応答がなくても、実際によく調べてみると、ファイルの削除もデータベースの操作も完了してるっぽかったので正確には「削除できてる」んですが、削除ボタン（実際には適用ボタンですか）を押してから、ブラウザが延々といわゆる「読み込み中」のまま、という状態です。
HTTPヘッダも何も返ってこない状態。
該当部分のソースを読んでみたり色々テストしていくと、削除処理をした後のリダイレクト処理部分で”wp_redirect”という関数が呼ばれており、どうもその関数が上手く動いてない様子でした。
ちなみにモジュール版なら”wp_redirect”関数自体は普通に動作します。
一括削除処理だけモジュール版で動作するようにしようかと一瞬思いましたが、そのwp_redirect関数を含むファイルって、upload.phpなんですよね。
つまりupload.phpに表示・追加・削除の機能が一つにまとめられてるので、htaccessのfilesディレクティブで切り替える方法が使えません。
とりあえず今回はwp_redirectを呼んでる行をコメントアウトして、
<html>
<header>
<title>wordpress redirect</title>
<meta http-equiv=”Refresh” content=”0; URL=$location”>
</header>
<body>
しばらくお待ち下さい。
</body>
</html>
という内容を返すようにしました。
文字化けるかもしれないのでもっとちゃんとしたソースを返すようにした方がいいです。
他にもwp_redirect関数を呼び出してる部分があったのですが、それらはちゃんと動いてるようでした（ホントかな）のでそのままです。
一応調査の中で、
header(’Location: http://example.com/’);
などと一行だけ書いたスクリプトをCGI版で動かしてみたりしましたが普通に動きました。
まぁ、これが動かなかったら大問題になりますけど。
原因は複合的なんでしょうね。
wp_get_attachment_imageでalt属性を出力できるようにした
- 2009-01-06 (火)
- 技術
Wordpressには、wp_get_attachment_imageとwp_get_attachment_image_srcという関数（テンプレートタグ）があります。
これらの関数は、引数にブログに登録された画像ファイルのIDと表示サイズを渡し、その情報を取得することができます。
wp_get_attachment_image_srcは、戻り値として画像のURLと縦横のサイズを配列にしたものを返します。
wp_get_attachment_imageは、その関数内部でwp_get_attachment_image_srcを利用し、戻り値として画像を表示するためのHTMLタグを文字列として返します。
これらの関数は記事の枠組みにとらわれず、画像を表示し管理したい場合に役に立つのですが、SEO的に必須とも言えるようなimgタグのalt属性に対応していません。
Wordpressの管理画面では画像ファイルに”キャプション”と”説明”というalt属性として使えそうな項目を関連付けられるのにも関わらず、それらがあまり生かされていないのは勿体無いと言う外ありません。
そこで、今回は管理画面で言うところの画像の”キャプション”を”alt属性”として出力できるようなプラグインを作成してみました。
名前は、wp_get_attachment_image_complete。センスのかけらもないネーミングですね。
プラグインファイルはここからダウンロードできます。
使い方
ダウンロードして解凍し、Wordpressのプラグインフォルダに入れて、管理画面から有効にします。
そうするとテンプレートでwp_get_attachment_image_completeとwp_get_attachment_image_src_completeの2つのテンプレートタグが利用可能になります。
元々のテンプレートタグと互換性を持たせてあるので、そのまま置き換えるだけ（同じ使い方）で問題ないハズです。
wp_get_attachment_image_completeは特に何もしなくてもalt属性を出力します。
wp_get_attachment_image_src_completeは、戻り値の配列の4番目と5番目、つまり$imgに格納したとして$img[3]と$img[4]がそれぞれ”キャプション”と”説明”に対応します。
あとがき、言い訳
本当は、wp_get_attachment_imageから呼び出されるwp_get_attachment_metadataにフックをかけるのがスマートだと思うのですが、そうした場合に何故かpost idがプラグインの関数側で取得できないという問題が起き、それを解決するためにwp-includes内の関数に手を加える以外の方法を思いつかなかったので、違う関数名で定義することにしました。
バージョンアップが頻繁なWordpressですから、wp-includes内の関数に手を加えたのを忘れて新しいバージョンを上書きすると面倒なことになりますからね。
もしかしたら、同じ機能を持つもっと良いプラグインが他に実在するかもしれません。
ただ、ちょっと調べた感じでは無さそうだったので作ってみました。
というかそもそも、元のwp_get_attachment_image自体があまり利用されてない気がする・・・
このブログでも使ってないしw
あと、元のソースをベースになるべく時間をかけずに改造したので汚くなってます。
1から自分で書けば、まるで清廉なポエムを読んでるような気分になるくらい美しいソースになるんですが。ウソです。ドキドキです。
ライセンスはWordpressのソースを流用してるので一応GNU GPLってことにしておきます。コピーレフトコピーレフト。
post idがプラグインの関数側で取得できない問題について
今回公開したプラグインはこの問題を避けているので関係ないのですが、気になったので記録しておきます。
といっても、きちんと調べて説明するのが面倒なので箇条書き風です。
func_get_args関数には魔物が潜んでるのかもしれない。
wp_get_attachment_metadata関数内部
return apply_filters( ‘wp_get_attachment_metadata’, $data, $post->ID );
ここでは$dataに画像の基本的な情報(src,width,height)とEXIFデータが格納されてて、$post->IDには画像のID(Wordpressは記事も画像データも同じテーブルに入ってるため、$image->IDとかじゃなくて$post->IDになる)が入ってる。画像のキャプションと説明はpostテーブルに入ってるためそれらを取得するには$post->ID超重要。
apply_filters関数内部
$args = func_get_args();
何故かprint_r($args)で$post->IDで渡されたものが出てこない。
しかし$args[2]と直接指定すると見える。
最終的にcall_user_func_arrayでプラグインの関数が呼び出される訳ですが、
プラグインの関数内ではもう完全に$post->IDで渡されたはずのデータが見れなくなってる。
沖縄で何が起きているのか
- 2008-08-06 (水)
- 日記
近くのMT信者にちょっとイラッとしたので、Google TrendsでMTの没落っぷりを見て独りほくそ笑んでおりました。
いやな性格です。
ついでにWordpressの隆盛っぷりも見て悦に入っていました。
MTは日本以外の国での検索数が非常に少なく、たまたま見たカナダのデータでは検索数が少なすぎてグラフが表示されないような状態でした。
一方Wordpressの検索数では日本はトップ10にさえ入っていませんが、その11位以下の日本でさえWordpressの検索数の方がMTの検索数を軽く超えています。
つまり、MTに最大限有利に計算しても10倍以上は検索数の差があるということです。
もちろんカナダのグラフも普通に表示されました。
MTにとっては最後の頼みの綱である日本でさえ検索数でWordpressに圧倒的に負けている状況は、没落しているとしか言いようがありません。
ちなみにMT没落の原因としてMT3発表時のライセンス問題がよく挙げられますが、僕はそれだけではないと思います。
MT4になってから仕事上いくつかの案件で使ったことがあるのですが、あんな重くてバグが多く運用に気を使うソフトウェアは、代替が豊富にある今となっては、タダであっても使う気がしません。
要はソフトウェアそのものの出来によって没落した部分もあると思います。
とまぁ、そんな没落ソフトのことはどうでもいいのですが、
気になるのは、日本国内では、Movable TypeとWordpressの検索数でどちらも沖縄が東京を抜いて1位だという点です。
沖縄で何が起きているのでしょうか。
その真相について非常に興味があるところです。
wp.Vicuna（Warship）に変えてみた
- 2008-05-30 (金)
- 技術
とりあえず、wp.VicunaというWordPressのテーマを入れてみました。
wp.Vicunaはテーマ単体としてはシンプルなXHTMLで出力されるようになっていて、スキンという名のcss（と装飾用の画像）を切り替えて色んなデザインを楽しめるようになっています。
Warshipというスキンが気に入ったのでそれを入れてみました。
入れてみた結果、見た目はほぼ完璧だったのですが、色々と機能的な問題が発生したので、その内容と解決方法を書いておきたいと思います。
これは最初、使ってるプラグインやwp.Vicunaとの相性問題かと思って色々調べたんですが（使ってるプラグインのソースほとんど読んでしまいましたorz）、もっとかなり単純な原因だったようです。
WP-SWFObjectやiG:Syntax Hiliterで記事に何かを埋め込んだ場合、埋め込んだものはdivタグで囲まれます。
そして、brBrbrは記事全体を1つのpタグで囲みます。
このpタグの中にdivタグが存在するということは、wp.Vicunaが使ってる「XHTML 1.0 Strict」では許されていません。
で、「XHTML 1.0 Strict」でpタグの中にdivタグがあった場合、ブラウザ（FireFox2,IE6,IE7で確認）は、何とpタグの中のdivの開始タグの直前にpの終了タグを移動してしまうようです。
つまり、divタグ以降がpタグの外に出るわけで、WP-SWFObjectやiG:Syntax Hiliterで埋め込まれたdivタグ以降が、マージン指定などされたpタグの外に出てしまい、ずれるということが起こっていたようです。
最初、プラグインで使われてるJavaScriptが悪さしてるのかと散々ソースを読みましたが、原因が分かって何か拍子抜けです。
で、この問題を回避する方法ですが、要はpタグでdivタグを囲まないようにすれば良いだけなので、僕の場合は、brBrbr.phpで最終的に記事をpタグで囲んでる部分をclass指定ありのdivタグで囲んで、そのdivタグにpタグのスタイル指定と同じ指定をcssでしました。
これで、問題はなくなったようです。
WP Captcha-Freeが使えてたころのテーマのcomment.phpとwp.Vicunaのcomment.phpを見比べてみると、wp.Vicunaのほうにdo_actionという関数の呼び出しが足りないことに気付きました。
とりあえず、wp.Vicunaのcomment.phpのコメント記入欄部分のformの終了タグの直前に
を追加することで、とりあえずWP Captcha-Freeがコメント投稿時に読み込まれるようになりました。
しかしこれだけだと正常に動作しませんでした。
よくソースを見てみると、WP Captcha-Freeが期待しているformタグのidとwp.Vicunaのformタグのidが違ったので、wp.Vicunaで吐き出されるXHTMLに合わせてcaptcha-free.phpのgetElementById('commentform')をgetElementById('commentsForm')へ置換しました。
しかし今度は何故かコメントの投稿ボタンを押すと、記事の検索処理が動いてしまいます。
これもよくソースを見ると、WP Captcha-Freeが期待しているコメント投稿ボタンのidとwp.Vicunaのコメント投稿ボタンのidが違ったので、wp.Vicunaに合わせてcaptcha-free.phpのgetElementById('submit')をgetElementById('comment-post')へ置換しました。
これでようやく正常に動作するようになりました。
とりあえず今のところは、上記以外の問題は発見してません。
あとは、wp.Vicunaが中途半端に日本語化されてるので（といっても作者は日本人みたいだから、理由があって敢えて英語を使ってるんでしょうけど）、独自に日本語化してみました。
wp-content/themes/wp.vicuna/languages/ja_UTF.poが言語ファイルのソースなってるので、それを心行くまで編集して、後はwp-content/themes/wp.vicuna/languagesディレクトリで、
# msgfmt --output-file=ja_UTF.mo ja_UTF.po
とコマンドを打てばコンパイルできます。
ということで、まともに使えるようになるまで一苦労ありましたが、wp.Vicuna、なかなか良いです。というかWordPress2.5.1なかなか良いです。
wp.Vicunaはテーマ単体としてはシンプルなXHTMLで出力されるようになっていて、スキンという名のcss（と装飾用の画像）を切り替えて色んなデザインを楽しめるようになっています。
Warshipというスキンが気に入ったのでそれを入れてみました。
入れてみた結果、見た目はほぼ完璧だったのですが、色々と機能的な問題が発生したので、その内容と解決方法を書いておきたいと思います。
問題1:記事にWP-SWFObjectやiG:Syntax Hiliterを使ってFlashやコードを埋め込んだときに、埋め込んだもの以降の文章が左にずれる。
これは最初、使ってるプラグインやwp.Vicunaとの相性問題かと思って色々調べたんですが（使ってるプラグインのソースほとんど読んでしまいましたorz）、もっとかなり単純な原因だったようです。
WP-SWFObjectやiG:Syntax Hiliterで記事に何かを埋め込んだ場合、埋め込んだものはdivタグで囲まれます。
そして、brBrbrは記事全体を1つのpタグで囲みます。
このpタグの中にdivタグが存在するということは、wp.Vicunaが使ってる「XHTML 1.0 Strict」では許されていません。
で、「XHTML 1.0 Strict」でpタグの中にdivタグがあった場合、ブラウザ（FireFox2,IE6,IE7で確認）は、何とpタグの中のdivの開始タグの直前にpの終了タグを移動してしまうようです。
つまり、divタグ以降がpタグの外に出るわけで、WP-SWFObjectやiG:Syntax Hiliterで埋め込まれたdivタグ以降が、マージン指定などされたpタグの外に出てしまい、ずれるということが起こっていたようです。
最初、プラグインで使われてるJavaScriptが悪さしてるのかと散々ソースを読みましたが、原因が分かって何か拍子抜けです。
で、この問題を回避する方法ですが、要はpタグでdivタグを囲まないようにすれば良いだけなので、僕の場合は、brBrbr.phpで最終的に記事をpタグで囲んでる部分をclass指定ありのdivタグで囲んで、そのdivタグにpタグのスタイル指定と同じ指定をcssでしました。
これで、問題はなくなったようです。
問題2:この前導入したWP Captcha-Freeが動作しない。
WP Captcha-Freeが使えてたころのテーマのcomment.phpとwp.Vicunaのcomment.phpを見比べてみると、wp.Vicunaのほうにdo_actionという関数の呼び出しが足りないことに気付きました。
とりあえず、wp.Vicunaのcomment.phpのコメント記入欄部分のformの終了タグの直前に
PHP:
- <?php do_action('comment_form', $post->ID); ?>
を追加することで、とりあえずWP Captcha-Freeがコメント投稿時に読み込まれるようになりました。
しかしこれだけだと正常に動作しませんでした。
よくソースを見てみると、WP Captcha-Freeが期待しているformタグのidとwp.Vicunaのformタグのidが違ったので、wp.Vicunaで吐き出されるXHTMLに合わせてcaptcha-free.phpのgetElementById('commentform')をgetElementById('commentsForm')へ置換しました。
しかし今度は何故かコメントの投稿ボタンを押すと、記事の検索処理が動いてしまいます。
これもよくソースを見ると、WP Captcha-Freeが期待しているコメント投稿ボタンのidとwp.Vicunaのコメント投稿ボタンのidが違ったので、wp.Vicunaに合わせてcaptcha-free.phpのgetElementById('submit')をgetElementById('comment-post')へ置換しました。
これでようやく正常に動作するようになりました。
とりあえず今のところは、上記以外の問題は発見してません。
あとは、wp.Vicunaが中途半端に日本語化されてるので（といっても作者は日本人みたいだから、理由があって敢えて英語を使ってるんでしょうけど）、独自に日本語化してみました。
wp-content/themes/wp.vicuna/languages/ja_UTF.poが言語ファイルのソースなってるので、それを心行くまで編集して、後はwp-content/themes/wp.vicuna/languagesディレクトリで、
# msgfmt --output-file=ja_UTF.mo ja_UTF.po
とコマンドを打てばコンパイルできます。
ということで、まともに使えるようになるまで一苦労ありましたが、wp.Vicuna、なかなか良いです。というかWordPress2.5.1なかなか良いです。
AS3でパーティクル
- 2008-05-25 (日)
- 技術
今はMacで入力してるからそんな問題は無いのですが、IMEで入力するとパーティクルがパーティ来ると変換されてしまいます。パーティなんてこ洒落たものには行きません。
タイトルの件ですが、どっかのブログでAS3でパーティクルっていう記事に触発されて、似たようなもんを作ってみました。
最近AS3に今更ですがハマっています。
ついでに、WordPressにWP-SWFObjectというプラグインを追加してFlashを表示できるようにしました。
本当はマウスカーソルと各粒子の距離の2乗に反比例する反発力を働かせたかったのですが、アルゴリズムがいまいちのため、ちょっと変な反発力が働くようになっています。
タイトルの件ですが、どっかのブログでAS3でパーティクルっていう記事に触発されて、似たようなもんを作ってみました。
最近AS3に今更ですがハマっています。
ついでに、WordPressにWP-SWFObjectというプラグインを追加してFlashを表示できるようにしました。
This movie requires Flash Player 9
※クリックで粒子の見た目を切り替えれます。また、マウスカーソルと粒子の間に反発力が働くようにしています。本当はマウスカーソルと各粒子の距離の2乗に反比例する反発力を働かせたかったのですが、アルゴリズムがいまいちのため、ちょっと変な反発力が働くようになっています。
WordPressのアップデートをしてみた
- 2008-05-23 (金)
- 技術
今までこのブログはWordPress ME 2.2を使ってきたのですが、そろそろ新しいバージョン出てるんじゃね？と思い調べてみたら、なんとMEは終焉を迎え、MEなしに統一されたという衝撃の事実。
まぁ、衝撃というのは嘘ですが。（MEと無印の違いなんて知らなかったしw）
で、最新のWordPress2.5.1はセキュリティ関係の修正も含むということで早速アップデートしてみることに。
本来なら、一度古いファイルをすべて消してから新しいファイルを配置するらしいですが、ものぐさなのでいきなり上書きしてみましたw
するとやっぱりいきなり上書きしたのが悪かったのか、管理画面が中途半端に日本語化された状態になってしまいました。
言語ファイルが旧バージョンとコンフリクトしてるんだろうなと思い、wp-content/languagesを見てみると以下の8つのファイルがありました。
ja_EUC.mo
ja_EUC.po
ja_SJIS.mo
ja_SJIS.po
ja_UTF.mo
ja_UTF.po
ja.mo
ja.po
で、ファイルの日付を見てみると、ja.moとja.poが今日の日付で後は古かったので、とりあえず古いファイルを適当にリネームして、ja.moとja.poをja_UTF.mo、ja_UTF.poにリネームしたら管理画面が完全に日本語化されました。
めでたしめでたし。
ついでに、コメントスパム除けの為に、Captchaを付けてみることに。
WP Captcha-Freeというのがあったのでそれを入れてみました。
きちんと動くかどうか。。。
まぁ、衝撃というのは嘘ですが。（MEと無印の違いなんて知らなかったしw）
で、最新のWordPress2.5.1はセキュリティ関係の修正も含むということで早速アップデートしてみることに。
本来なら、一度古いファイルをすべて消してから新しいファイルを配置するらしいですが、ものぐさなのでいきなり上書きしてみましたw
するとやっぱりいきなり上書きしたのが悪かったのか、管理画面が中途半端に日本語化された状態になってしまいました。
言語ファイルが旧バージョンとコンフリクトしてるんだろうなと思い、wp-content/languagesを見てみると以下の8つのファイルがありました。
ja_EUC.mo
ja_EUC.po
ja_SJIS.mo
ja_SJIS.po
ja_UTF.mo
ja_UTF.po
ja.mo
ja.po
で、ファイルの日付を見てみると、ja.moとja.poが今日の日付で後は古かったので、とりあえず古いファイルを適当にリネームして、ja.moとja.poをja_UTF.mo、ja_UTF.poにリネームしたら管理画面が完全に日本語化されました。
めでたしめでたし。
ついでに、コメントスパム除けの為に、Captchaを付けてみることに。
WP Captcha-Freeというのがあったのでそれを入れてみました。
きちんと動くかどうか。。。
コメントスパムがヒドイ
- 2008-05-22 (木)
- 技術
最近急にこのブログの特定のエントリに国外からと思わしきコメントスパムが大量に付くようになりました。
大量といっても1日200ぐらいだから大したことないですけどね。
wordpressのスパムフィルタ機能が働いて全く表には出ないので問題ないのですが、
なんか精神衛生上よろしくないので、何とかしたいところです。
にししても、1時間に数回ずつ24時間スパまれてるので、自動化されてるんでしょうね。
大量といっても1日200ぐらいだから大したことないですけどね。
wordpressのスパムフィルタ機能が働いて全く表には出ないので問題ないのですが、
なんか精神衛生上よろしくないので、何とかしたいところです。
にししても、1時間に数回ずつ24時間スパまれてるので、自動化されてるんでしょうね。
brBrbr.phpを入れてみた
- 2008-04-17 (木)
- 技術
wordpressでは本文の連続した改行が反映されないので、何か解決する方法はないかとググってみたら、やはり多くの人が同じ問題（まぁ問題というか、標準に準拠したソースを出力するためには仕方のない事だと思います）に悩んでたようで、プラグインという形でこの問題を解決するものが出てました。
brBrbr.php
何と呼んだら良いんでしょうね。コレ。ぶらぶらぶら？
ということでコイツを入れてみて今最初のエントリを書いてみてるところです。
うまくいくかどうか。
↓改行1
↓改行2
↓改行3
↓改行4
↓改行5
どうかな？
ちなみにこのプラグインはビジュアルエディタとの相性が良くないため、編集時にはビジュアルエディタは切っておいた方がいいようです。
brBrbr.php
何と呼んだら良いんでしょうね。コレ。ぶらぶらぶら？
ということでコイツを入れてみて今最初のエントリを書いてみてるところです。
うまくいくかどうか。
↓改行1
↓改行2
↓改行3
↓改行4
↓改行5
どうかな？
ちなみにこのプラグインはビジュアルエディタとの相性が良くないため、編集時にはビジュアルエディタは切っておいた方がいいようです。
iG:Syntax Hiliter 日本語版を入れてみた
- 2008-01-29 (火)
- 技術
いまさらながらiG:Syntax Hiliter 日本語版というものがあると知ったのでそのテスト。
コードは無意味です。
にしてもコード晒すのはなんか恥ずかしいね。
早くCode Craft読み上げて、守備的コーディングとやらを実践せねば。
JavaScript:
- function showData(data,str){
- $('ans').innerHTML = "";
- var ul = document.createElement('ul');
- if(!data || data == -1){$('ans').innerHTML = '見つかりませんでした。';return;}
- if(data["Error"]){$('ans').innerHTML = 'エラーが発生しました。';return;}
- if(data["ResultSet"]["totalResultsAvailable"] <1){$('ans').innerHTML = '見つかりませんでした。';return;}
- var itemFormat = new Template(
- '<li><a href="#{Url}" target="_blank">#{Title}</a><br />#{Summary}#{datetime}</li>'
- );
- var formatted = '';
- var reg = new RegExp(str.replace(" ","|"),'i');
- var rows = data["ResultSet"]["Result"];
- for (var i=0, item; item = rows[i]; i++) {
- item.Title = item.Title.gsub(reg, '<strong>#{0}</strong>');
- item.Summary = item.Summary.gsub(reg, '<strong>#{0}</strong>');
- formatted += itemFormat.evaluate(item);
- }
- $('ans').innerHTML = '<ul>' + formatted + '</ul>';
- }
コードは無意味です。
にしてもコード晒すのはなんか恥ずかしいね。
早くCode Craft読み上げて、守備的コーディングとやらを実践せねば。
POP BLUEのバグ修正
- 2007-07-27 (金)
- 技術
この前のエントリ(WordPressのテーマ POP BLUEを日本語化してみた）で書いたとおり、現在このサイトはPOP BLUEというwordpress用のテーマを使っていますが、右カラムの最近のエントリに最新のエントリが表示されていなかったので修正してみました。
修正部分は・・・
修正部分は・・・
この場で続きを見る » もしくは 別ウインドウで続きを見る
トップページ > タグ > WordPress
- 検索
- フィード
- メタ