Category Archives: ネット・PC

WordPressにLightbox風プラグインを導入する

「Lightbox」をご存知だろうか? 画像をクリックすると「うにょーん」、「びよーん」と画像が飛び出してくるアレである。 言葉では、説明が難しいので、ともかく下の画像をクリックして欲しい。 ※焦りは禁物!ページが表示されていてもLightboxに必要なライブラリの読み込みが完了したとは限らない。画面の一番下にツールバーが表示されたタイミングならOK。 「あっ、見たことある。」と思われたのではないだろうか? 「Lightbox」は、本来、特定のツールを指す固有名詞なのだが、一般的にはこのような機能を「Lightbox」と言う。 現在は、本家の「Lightbox」の他、Lightbox風の機能を実現するライブラリが多数登場しているが、Lightbox風のクローンを含めて、単に「Lightbox」と呼ばれることが多い。 Lightbox風の機能は、JavaScriptライブラリ「JQuery」、「MooTools」、「Prototype」などのライブラリを利用して作られている。 これらのライブラリは、見た目にも、アクセサビリティ上も優れた機能をウェブページで実現する、所謂、AJAXに対応したライブラリだ。 「JQuery」、「MooTools」、「Prototype」などを利用して、Lightbox風の機能を実現するライブラリは、本家の「Lightbox」および「Lightbox2」の他、「Slimbox」、「Slimbox2」、「ThickBox」、「ColorBox」など多数存在している。 更に、WordPress用に、これらがプラグイン化して配布されているので、WordPressへの導入は難しくない。 様々な開発者がプラグイン化しているので、(相違はバージョンが違う程度で)同一のライブラリをベースにしたものが多数存在する。 私は、このブログに、Lightbox風の機能を導入したく、作業を進めていた。 有効化、無効化も簡単なプラグインとして導入するつもりだったため、導入は、直ぐに終わると思っていたが、この判断は甘く、実際は、かなり苦労した。 Lightbox風の機能を実現するプラグインの多くが、動作環境に神経質で、導入しても動かないケースが非常に多い。 特に「zenback」とは相性が良くないようだ。「zenback」を外すと、あっさり動いたものもあった。 加えて、私の画像の挿入の仕方が悪いのだが、既存の画像には、Lightbox風の機能が適応されない問題にも直面することになる。 結局、既存の画像にもLightbox風の機能を適応するためにプラグインを自作するはめになった。 以下、私が試したLightbox風の機能を実現するプラグインを紹介する。 同じような名称のものが混在しているので注意して欲しい。 ・Easy FancyBox 「Easy FancyBox 1.3.4.8」は、「jQuery」ベースの「FancyBox」をプラグイン化したもので、画像だけでなく、Flash、PDF、iFrame、YouTubeもサポートしている。 最初、設定項目がないと勘違いしたが、管理画面の「設定」 -> 「メディア」の中にあった。 流れるように飛び出してくる動きが特徴的だが、このブログでは、個別記事のページでフリーズしたようになり、閉じられない現象が発生した、詳しくは後の述べるが、「zenback」と競合しているのではないかと思われる。 ただし、「zenback」を外す気もなく、面倒なので検証はしていない。 ・WP Facebox Gallery(Facebox Gallery) 「jQuery」ベースの「WP Facebox Gallery 1.0.4」は、なかなか動作が軽快だ。 設定項目は無いが、自動的に動作に必要な属性を画像のリンクに追加してくれる。 細かい設定をしたい人には不向きだが、インストールして直ぐ使える利便性がある。 私のブログでも、特に難なく動作した。 ・FancyBox for WordPress 「FancyBox for WordPress 2.7.5」も「jQuery」ベースの「FancyBox」をプラグイン化したものなので、動作が流れるようで綺麗だ。 基本的には、「FancyBox」系のインターフェースだが、タイトルの表示方法が面白い。 設定項目が充実しており、他のプラグインとのコンフリクトを抑制する動作モードまで備えるのだが、画像リンクへの属性の自動追加が上手く機能していないように思われる。 手作業で属性を追加した場合でも、個別記事のページでは動作しなかった。 「zenback」が動いている個別記事での不具合となると、やはり、「zenback」のせいを疑ってしまう。 追記:設定画面の「Other」->「Load JavaScript in Footer」を有効にする事で、「zenback」が動作している個別記事でも、バージョン2.7.5は問題なく動作する事が分かった。 ・FancyBox Gallery 「FancyBox Gallery 0.3.2」も「jQuery」ベースの「FancyBox」が元のようなので、何か問題は出来るだろうと予想はしていたが、動作しなかった。 あるはずの設定画面が見当たらない。設定オプションには、開発上の「To Do」にも入っているので、無くて正解なのかもしれない。 属性の自動追加機能が備わっていないのか、属性も追加されない。 ・Fancyboxify 「Fancyboxify 1.1」も「FancyBox」がベースのようだ。 これまでの結果を見ても「jQuery」ベースの「FancyBox」系のプラグインは、運良く動作した場合でも、このブログとは、どうも相性が良くないようだが、やはり、個別記事のページでフリーズしたようになり、閉じられない現象が発生した。 「FancyBox」系は、「zenback」と相性が悪いのかもしれない。 これも設定画面が見当たらないが、属性の自動追加機能が備わっている。 ・Flexible Lightbox 「Flexible Lightbox 1.0.4」は、まず、属性の自動追加が上手く働いておらず、手作業で追加しても動作しなかった。 設定項目が表示されないと思ったら、画像リンクを追加する際に個別に設定する仕様になっている。 「ThickBox」ベースの「WP Thickbox Integration」も、同一の開発者によるプラグイン。 ・jQuery Colorbox 「jQuery Colorbox 3.8.3」は、「jQuery」ベースの「ColorBox」をプラグイン化したものだ。 これは、有効化しただけで、あっけなく動作した。 動作は軽快で、見た目も悪くない。 デフォルトのテーマのバックグラウンドは、単調なものではなく面白い。 多言語化されているが、日本語には未対応。 ・jQuery Lightbox 「jQuery Lightbox 0.16」は、すっきりしたデザインで表示され、バックグラウンドにもリンク表示する。開く際に、最後に、もわっとスクロールする動作が特徴的。 画像の上をオーバーマウスすると、ファイル名やボタンが表示される。 管理画面には、必要最低限の設定項目を備えるが、属性の自動追加機能を備えていない点が残念。 自作したプラグインで属性の自動追加機能を補って、暫く利用していた。 ちなみに「jQuery lightBox plugin」は、これとは別物。 ・Lightbox 2 「Lightbox 2 v.2.9.2」は、「Lightbox 2」をプラグイン化したもの。 人気のあるプラグインだが、残念ながら、このブログでは動作しなかった。 ・Lightbox Plus 「Lightbox Plus … 続きを読む →

Posted in WordPress, ネット・PC, 自作アプリ | Tagged , , , , , , , | 3 Comments

WordPressの管理者が重宝するプラグイン

今回は、「WordPress」の管理上、便利なプラグインをまとめて紹介する。 ・WordPress Database Backup(WP-DB-Backup) 「WordPress Database Backup 2.2.3」は、データベースのバックアップを可能とするプラグインで、不測の事態の際の復旧に役立つツールだ。 同様のプラグインは、多数存在するが、比較をしていないので「WordPress Database Backup」が優れているかは分からない。 ともかく、いずれかをインストールしておくと便利だ。 「WordPress Database Backup 2.2.3」の操作と設定は、管理画面の「ツール」->「バックアップ」から行う。 「WordPress」本体が利用するテーブルの他、プラグインが利用するテーブルも選択してバックアップ出来る。 スケジュール機能を利用すれば、定期的にバックアップしてファイルをメールで受け取ることも可能。 一応、インストールはしているが、正直、使っていないので、私は、不測の事態の際に泣くタイプだ。 ・Akismet 「Akismet 2.5.3」は、「WordPress」に標準でインストールされているプラグインで、コメントスパムやピンバックスパムの排除するために欠かせないプラグイン。 「Akismet API キー」が必要で、「Akismet」のサイトから取得する必要があるが、個人ブログなら無料で取得できる。 取得方法が、よく変更されること、個人ブログ用の無料「API キー」の取得方法が分かりにくいことから、ここからの「API キー」の取得はお勧めしない。 「wordpress.com」で発行される「API キー」でも代用できるので、こちらから取得すると良いだろう。 「API キー」は、「wordpress.com」でユーザー登録を行った後、送られてくるメールに記載されている。 このブログは、コメントシステムとして「DISQUS」を利用しているので、「WordPress」のプラグインとしては「Akismet」を利用していない。 「DISQUS」を利用している場合は、「DISQUS」側で「Akismet」の設定が可能となっている。 ・Revision Control 「WordPress」は作成中の記事を保存すると、記事を別のリビジョン(別の文書)として保存する。 また、自動保存の機能があるため、場合によっては、沢山のリビジョンが残ってしまう。 見かけ上は1つの記事だが、実際には10以上の記事が保存されていることも十分にあり得る。 記事の更新履歴が残り、再利用も可能なため、便利な面もあるが、データベースを圧迫する懸念がある。 また、このブログのようにパーマリンクをデフォルトに設定すると、URLは、記事のID(数字)ベースのものになるが、実は、全てのリビジョンが記事のIDを個別に持っている。 URLが連番にならないのは、リビジョンが記事のIDを消費するからだ。 そこで役立つのが、リビジョンの保存機能自体を無効にしたり、制限を加えることが出来るプラグイン「Revision Control 2.0.1」である。 また、記事の作成画面から、リビジョンを個別に削除する機能も付加される。 ・Better Delete Revision 「Better Delete Revision 1.2」は、リビジョンを一括で削除してくれる便利なプラグイン。 「Revision Control」などを導入して、リビジョンの保存機能を無効にしたものの、その時点で、既に沢山のリビジョンが保存されている場合は、これで一括削除すれば良い。 もちろん、「Better Delete Revision 1.2」だけでリビジョン管理を行って良い。 ・Broken Link Checker 「Broken Link Checker 1.2.4」は、記事内のリンク切れを調べてくれるプラグインである。 記事内で外部や内部記事へのリンクを挿入することも少なくないが、リンク切れをチェックするのは困難であるため、このプラグインは重宝する。 「WordPress」の管理画面上の「ツール」->「リンク切れをチェック」から簡単にリンク切れをチェックできる他、「設定」->「Broken Link Checker」では、定期的にリンク切れをチェックし、メールで通知させる設定ができる。 ・Redirection 「Redirection 2.2.3」は、特定のURLでのアクセスを別のURLへリダイレクトする機能を提供するプラグイン。 つまり、リンク切れの救済などに役立ちそうだが、今のところ必要性はないので利用していない。 パーマリンクの設定を変更したり、タイトルを変更してリンク切れを起こした場合は、このプラグインで、新しいURLへ転送(301リダイレクト)することができる。 リダイレクトだけでなく、「404」を返すなど、その他の処理も可能。 設定は、「WordPress」の管理画面上の「ツール」->「リディレクション」から行い、正規表現を用いることも可能。 ・Change Permalink Helper 「Change Permalink Helper 0.1」は、リクエストされたURLが見つからない場合、パーマリンクをチェックし、自動的に新しいURLに転送(301リダイレクト)してくれるらしい。 パーマリンクを変更した際は、非常に重宝しそうな気がするが、今のところ、このプラグインを使用していないので、自動処理がどこまで信頼出来るものなのかは不明。 転送先の判断には、URLの「スラッグ」を用いるらしいので、例えば、このブログのような「投稿 ID」を用いたパーマリンクから、別の形式のパーマリンクに変更する場合は、 /%year%/%monthnum%/%post_id% と言った風に「投稿 ID」を含むものにすれば、無難に処理してくれるのかもしれない。 投稿の「スラッグ」を使うという意味であれば、入力していないので絶望的だ。 ・Link to Post 「Link to Post 1.0.2」は、自ブログ内の記事、ページ、カテゴリ、タグへのリンクの挿入を手助けするプラグインだ。 記事に、自ブログ内の別の記事へのリンクを挿入することが多いなら、ぜひ、インストールしておきたい。 インストールすると、記事作成の際に使用する「ビジュアルエディタ」にリンクを作成するためのアイコンが追加される。 記事、ページ、カテゴリ、タグへのリンクが簡単に選択できる様になっている。 ・TinyMCE Advanced 「TinyMCE Advanced 3.3.9」は、記事作成の際に使用するビジュアルエディタの機能を強化するプラグインで、記事作りに拘るなら不可欠なツールだ。 「TinyMCE Advanced 3.3.9」は、バージョンアップが止まっている感があり、同様のプラグインに「CKEditor For … 続きを読む →

Posted in WordPress, ネット・PC | Tagged , , , , , , , , , | Leave a comment

WordPressを携帯電話対応サイトにする

携帯電話でウェブを参照するユーザーは、けして少なくない。 「WordPress」は、プラグインの導入によって、簡単に携帯電話向けに簡略化されたテーマでの表示が可能になるので、ぜひ、携帯電話に対応させたいところだ。 しかし、一口に携帯電話と言っても様々な種類があり、標準搭載されているブラウザの機能も様々である。 場合によっては別のブラウザを追加インストールしている可能性もある。 携帯電話の場合もPCと同様にその環境は複雑であり、一括りに考えることは出来ない。 ゲーム機などの携帯端末まで考慮すると更に複雑になる。 PCサイトの参照を目的としたフルブラウザで参照しているユーザーに対して、携帯電話向けの簡略されたテーマで表示することが、果たして親切なのか?それともパフォーマンスに優れた携帯電話向けのテーマで表示することが親切なのか? 色々と考え始めるキリがないが、幸いそこまで高度な設定が可能なプラグインを私は知らないので、もう少し、シンプルに考える。 とは言え、かなり複雑である。 基本的には、搭載されている、もしくは使用している可能性があるブラウザによって分類する必要がある。 以下、主な携帯端末のブラウザを分類した。 NTTドコモ iモード iモードブラウザ au Ezweb PCサイトビューアー ソフトバンク Yahoo!ケータイ PCサイトブラウザ ウィルコム Opera NetFront Opera(フルブラウザ) NetFront(フルブラウザ) イー・モバイル NetFornt NetFront(フルブラウザ) Apple Mobile Safari(AppleWebKit系、iPhone、iPad、iPodに搭載) Windows Mobile IE系 NetFront Android AppleWebKit系 BlackBerry ブラウザ不明 Palm OS AppleWebKit系 Symbian OS(ノキアなど) UIQ搭載ブラウザ S60搭載ブラウザ(AppleWebKit系) 任天堂 DS(Opera系?) ソニー PSP その他 Opera Mini 携帯電話への対応は、プラグインで簡単に実現出来るが、一番の問題は、実際に、どの端末で携帯電話用テーマを使って表示されるかの確認である。 ユーザーエージェントを偽装できる「FireFox」のアドオン「User Agent Switcher」や「Google Chrome」のエクステンション「User-Agent Switcher for Chrome」を用いれば、レイアウトの確認までは無理としても、携帯用テーマで表示されるか否かの確認は出来る。 使用する前に、「Options」で、ユーザーエージェントを設置する必要があるが、携帯端末のユーザーエージェントは、「ユーザーエージェント – Wikipedia」「userAgent一覧-ユーザーエージェント一覧」で確認出来る。 追記 携帯電話のブラウザをシュミレーションするFireFox用プラグイン「FireMobileSimulator」が「FireFox4」対応となった。 対応機種は限られるが、こちらの方が実際に近い画面を確認できる。端末の情報さえ得られれば、自身で機種を追加することも可能。 以下、「WordPress」を携帯電話対応にするためのプラグインを紹介する。 ・WPtouch 1.9.25 「WPtouch」は、「WordPress」に標準でインストールされているプラグインで、iPhone、iPod touch、Android、Blackberry Storm、Blackberry Torch、Palm Preやその他タッチタイプパネルの携帯端末を自動的に判別し、専用のテーマでの表示を行う。 Blackberryがリストにあるが、全てのモデルが対象ではない。 ユーザーエージェントを偽装したテストの結果では、対応リストにはないものの、iPadにも対応している様に思われる。 あくまで特定の携帯端末が対象で、日本のものを含めて、一般的な携帯電話には対応していないので、後で述べる「Ktai Style」と併用すると良い。 標準のテーマは、iPhoneアプリを意識したデザインで、見た目も悪くない。 日本語にも対応しており、「Regionalization Settings」を「Japanese」に変更すれば、日本語テーマでの表示になる。 コメントシステムの「DISQUS」にも対応している。 基本的に有効化するだけで使えるが、メールアドレスを公開したくないなら設定で「Enable Email Menu Item (Uses default WordPress admin e-mail)」のチェックを外して置くこと。 設定の「Adsense」に「Adsense ID」を設定できる。 ※「Adsense ID」は、「Adsense」の管理画面右上に表示される「pub」で始まるコード。 「Google Analytics」でアクセス解析を行う場合は、PC用のテーマとは別に、対応が必要。 「Stats & Custom Code」で、「Google Analytics」のトラッキングコードを設定出来るが、携帯電話用のトラッキングコードが設定出来る訳ではない。 ・WordPress Mobile Pack 1.2.4 「WordPress Mobile Pack」は、殆どの携帯端末での表示に対応している。 … 続きを読む →

Posted in WordPress, ネット・PC | Tagged , , , , , , , , , , , | 1 Comment

WordPressにアクセス解析を組み込む

今回は、「WordPress」にアクセス解析を組み込む方法についてまとめてみた。 「WordPress」では、外部のアクセス解析を利用することは勿論の事、様々なアクセス解析がプラグインという形で提供されているのでアクセス解析に関しては困ることはないだろう。 ここでは、「Google Analytics」、「StatPress」系、「WordPress.com Stats」について解説する。 ・Google Analytics ご存知の通り、「Google Analytics」は、Googleが提供するアクセス解析だが、WordPressにも比較的容易に組み込める。 テーマが「Weaver」なら、「外観」->「Weaver Admin」->「Advanced Options」の「<HEAD> Section」にアクセス解析用のコードを追加しても良いし、テンプレート「ヘッダー(header.php)」の「</head>」の前に直接書きこんでも良い。 テーマのバージョンアップでの上書きを避けたいなら、プラグインを利用する方法もある。 私は「Google Analytics for WordPress 4.0.11」を使っているが、真面目に比較して選んだわけではないので、正直、これが優れているかは分からない。 プラグインを利用するメリットは、単にアクセス解析用コードを挿入する以上の機能が利用出来ることにある。 「Google Analytics for WordPress 4.0.11」でも、様々な機能が提供されているようだが、全体は把握してない。 とりあえず、「Track outbound clicks & downloads」という機能を有効にして、外部リンクへのアクセスをイベントとして記録してる。 これを普通にやろうとすると、全てのリンクタグを修正する必要があるので、チェック1つで出来るのはとても便利だ。 「Google Analytics」の欠点は、「WordPress」の管理画面上で、アクセス解析データを参照できない事だが、それを解決するプラグインも沢山存在するので、必要ならばインストールするとよい。 ・StatPress系 「StatPress」と、その派生の「StatPress Reloaded」や「NewStatPress」は、リアルタイムでアクセス解析してくれる優れたプラグンである。 ただし、私は、元祖の「StatPress」は使ったことがない。 「StatPress Reloaded」は、「StatPress」の改良版としてリリースされているが、暫く更新がストップしているので、「StatPress」と比較して、実際のところ、どちらが優れているかは不明だ。 リリースが古いこともあって「StatPress Reloaded 2.7.1」は、ユーザーエージェントの解析に難があり、正しい結果を表示しない。 「NewStatPress 0.1.2」はリリース自体が新しいので、まだまだユーザー自体が少ないが、「StatPress Reloaded 2.7.1」の欠点は、大幅に改善されている。 「StatPress」系は、アクセス記録を、WordPress同様に自サーバーのデータベースに格納するため、データが肥大化した場合は、データを管理画面から削除する必要がある。 「StatPress」系の特徴は、視覚的にも優れていることだ。 ブラウザ、国、リファラなどの情報を見やすく表示してくれる。 「Details」の画面では、表だけでなく、円グラフや地図などを使った表示となるため非常に分かりやすい。 「Spy」では、訪問者毎の詳細を確認できる。 難点は、日本語の一部が化けることだが、視認性を悪くする程ではない。 ※上の画面は、すべて「NewStatPress 0.1.2」のもの。 人気ページやアクセス数を表示するためのウィジェットも備えているので、カウンターを表示したい人には便利だ。 「StatPress」系のプラグインは、共存させることが出来ない。 少なくともインストールは出来るが、有効化出来るのは、いずれか1つのみだ。 私は「StatPress Reloaded 2.7.1」から「NewStatPress 0.1.2」乗り換えたが、まず「StatPress Reloaded 2.7.1」を無効化し、「NewStatPress 0.1.2」を有効化した後に「StatPress Reloaded 2.7.1」を削除した。 アクセス記録は「StatPress Reloaded 2.7.1」から正しく引き継がれたように見える。 管理画面から「NewStatPressUpdate」を実行したが、一応、無事に終了はしたもののエラーが出た。 単純なアップデートではないので、エラーは仕方がないかもしれない。 同系統とは言え、全く別のプラグインなので、データベーステーブルにも相違があるのだろう。 とは言え、一応、正常に動作しているように見えるので、このまま使うことにした。 バグなのか、私の環境に問題があるのか分からないが、「NewStatPress 0.1.2」では、管理画面でフィードへのアクセス数が表示されない。 ただし、「NewStatPressUpdate」を実行すると、フィードへのアクセス数が反映され、そのタイミングでビジターから除外され、その分、ビジターが減る。 「StatPress Reloaded 2.7.1」、「NewStatPress 0.1.2」の解析結果は、Google Analytics」と比較して、ビジター、ページビューなどは、かなり大きな数値になり、閾値や解析方法が異なるように思われる。 とは言え、スパイダーやフィードへのアクセスは別項目で表示され、管理者(登録者)のアクセスも除外でき、ノイズは抑えられている。 ・追記 ※「NewStatPress 0.1.2」における「NewStatPressUpdate」実行時のエラーについては、後日、「MySQLAdmin」にてデータ格納するテーブルを削除した後、プラグイン自体を再インストールしたが、現象は変わらず。 過去の履歴データを失っただけの徒労だった。 フィードが反映されない点に関してだが、データベーステーブルに関して、本家の「StatPress」との互換性を重視したため、若干、設計が異なる「NewStatPress」には、即時に反映されない項目があるのだろうと思う。 フィードを反映するためには、定期的に「NewStatPressUpdate」を実行するしかないようだ。 「StatPress」系としては、「StatPress Visitors」というプラグインも登場している。 詳細表示できる項目は多いが、逆に、見難いと感じたので使っていない。 一部のデータの反映には「NewStatPress」と同様のアップデート操作が必要で、2項目あり、「NewStatPress」よりも煩雑。 ・WordPress.com Stats 「WordPress.com Stats 1.8.1」は、日本語での画面表示にも対応したアクセス解析プラグインである。 人気ページやカウンターを表示するウィジェットを追加してくれる「WordPress.com Stats Helper 0.5.5.3」も一緒にインストールしておくと便利だ。 「WordPress.com Stats 1.8.1」は、アクセス記録を、自サイトのデータベースに格納するのではなく、「wordpress.com」のデータベースに格納する。 そのため、データベースを圧迫せず、データベース絡みのパフォーマンス低下が起こらない利点がある。 ただし、このプラグインを利用するためには、API Keyが必要となるので「wordpress.com」で、ユーザー登録を行う必要がある。 API Keyは、ユーザー登録完了後に、送られてくるメールに記載されている。 また、「wordpress.com」にログインした状態で、「WordPress.com … 続きを読む →

Posted in WordPress, ネット・PC | Tagged , , , , , | 2 Comments

IE9、Firefox4の登場で、高速ブラウザが揃い踏み

3/15に「Internet Explorer 9」、3/22に「Firefox 4」がリリースされ、主要ブラウザは、全て描画が高速なタイプになった。 ※IE9 日本語版のリリースは、地震を配慮して延期されている。 描画の速さでは「Google Chrome 10」が、一歩先をゆく感じだったが、「IE9」と「Firefox4」がリリースされたことで、シェア争いも激化しそうだ。 では一体、どのブラウザが高速化ということに興味があるかもしれないが、ベンチマークの結果は、他でも公開されているので、そちらを見て欲しい。 そもそも、使うツールによってベンチマークの結果は異なるし、実際の使用に近い負荷テストがされているとは限らない。 以下、主要なブラウザ用ベンチマークを紹介しておく。 Kraken JavaScript Benchmark SunSpider JavaScript Benchmark V8 Benchmark Suite Revisions Peacekeeper 個人的にも、管理下のサイトの表示を確認するために「IE 9」、「Firefox 4」、「Google Chrome 10」、「Safari 5 Win版」、「Opera 11」をインストールして使っているが、パフォーマンスという意味では「IE9」、「Firefox4」、「Google Chrome10」の差は大きくないと思っている。 「Google Chrome」と同じ、レンダリングエンジン「AppleWebKit」を採用している「Safari5」も、パーフォーマンス面では、「Google Chrome」に劣るものの、かなり速い。 「Opera11」に対しても、かなり速い印象を持ってはいるが、「Safari5」同様に、サイトの表示を確認する目的以外に使用しないので、体感的に、どの程度かと言われると判断が難しい。 パフォーマンスという意味では、「IE9」、「Firefox4」、「Google Chrome10」のいずれを選んでも損はないだろう。(勿論、「Safari5」、「Opera11」という選択肢も間違いではない。) 「Firefox4」は、やや起動にもたつく感があるが、許容の範囲だ。 また、今回のバージョンアップで、標準の設定では「IE9」、「Firefox4」共に「Google Chrome」のようにシンプルなナビゲーションインターフェースを採用している。 液晶モニタが主流になってからは、かなり横長のアスペクト比の画面で作業をすることが多くなっているが、この場合、横には広く使えるが、縦が狭い。 しかし、アプリケーションの多くは、縦に見るタイプだ。 ブラウザに限らず、メニューで場所をとってしまうと、メインの表示領域や作業領域がその分狭くなってしまう。 そう言った事を考慮すると、シンプルなナビゲーションは、当然の流れという事になるが、容易にユーザーに受け入れられるかは疑問の余地がある。 実際、シンプルなナビゲーションを逸早く採用し、高速な表示で知られる「Google Chrome」は、急速にシェアを伸ばしたが、IEやFirefoxに迫る程のシェアは獲得してない。 私は、大きな液晶を持つモデルではあるが、ノートパソコンをメインに使っている。 そう言った環境では、「Google Chrome」は、サイトが見やすいと感じたのも事実だ。 とは言え、シンプルなナビゲーションは、1つ流れであるので、これを嫌うユーザーは、ナビゲーションのカスタマイズ性でブラウザを選ぶ事になると思う。 ・Internet Explorer 9 実は、現在も過去もIEが、私のメインブラウザである。 世界中の殆どのサイトは、まず第一にIEにおいての表示を考慮した設計なので、そう言った意味で一日の長があった。 IE9になって、ナビゲーションが大きく変わり、アドレスバー、タブ、アイコンが一列で表示されている。 検索バーは無くなり、アドレスバーがそれを兼ねている。 上に無駄なスペースがあるように見えるが、実際には、他のブラウザと比べても省スペースなデザインで、表示領域を広く取っている。 起動も速く、描画は高速で、パフォーマンス面では、「Firefox4」、「Google Chrome10」と遜色ない。 私のようにIEをメインに使っていた者にとっては、「IE9」は救世主になるだろう。 しかし、1つ残念なことに「Windows XP版」はリリースされない。「Windows Vista」、「Windows 7」ユーザーのみが、その恩恵を受ける事が出来る。 「ALT」キーを押すとメニューが表示されるので、メニューからナビゲーションをカスタマイズし、旧来のインターフェースに近づける事も可能。 ・Firefox 4 Firefoxもナビゲーションが大きく変わった。 アドレスバーの上にタブを配置し、「Google Chrome」に近いレイアウトになっている。(それ以上に「Opera11」に酷似しているが・・・。) 大きな違いは、検索バーがある事と、最上段にメニューにアクセスするアイコンを配している点だ。 「IE9」や「Google Chrome10」と比較すると、起動が遅い印象があるが、全体のパフォーマンスとしては遜色なく、高速である。 「IE9」、特に「Google Chrome10」の大きな違いは、ナビゲーションのカスタマイズ性の高さだ。 自由度が高く、様々なユーザーの要求に応えるられるナビゲーションを提供してくれるだろう。 個人的には「Firefox」を積極的に使う理由は、「Firebug」と言うアドオンのためだった。 機能は劣るが「Google Chrome」にも同等の「Firebug Lite for Google Chrome」がある事を最近知ったので、サブブラウザとして使っている「Google Chrome」に一本化しようと思っていたが、「Firefox4」は、考えを改めさせるに十分な機能を秘めている。 ・Google Chrome 10 「IE9」と「Firefox4」が登場する以前は、高速な描画のブラウザと言えば「Google Chrome」だった。 私の体感では、パフォーマンス面においては、今現在も「Google Chrome」に一日の長があるように感じる。 しかし、その差は特筆するようなレベルではない。 私は、「Google Chrome」をサブブラウザとして使っている。 特定の作業は、全て「Google Chrome」で行っているので、使用頻度も、そう低くはない。 正直、最初はインターフェースに戸惑ったが、慣れてしまえば全く問題はない。 インターフェースのカスタマイズ性は高くないが、ある程度、使いやすい環境は構築できる。 何よりも、他のブラウザと比べて少し、表示領域が広くなっただけで、随分と見やすく感じたものだった。 ツールバーもインストールしてるが、必要に応じて表示するタイプなので、無駄に表示領域を侵食することもない。 「テーマ」という形でスキンも提供されているが、私にとっては、背景は白地が一番なので使ってない。 ・Safari 5(Win版) Safariは、Windowsユーザーにとってはマイナーブラウザーであるかもしれないが、Macユーザーに支えられて、一定のシェアを確保している。 Windows版も提供されており、iPhoneやiPadにも、専用にチューンしたものが搭載されている。 描画も遅くなく、パフォーマンス面は悪くないし、使い勝手も、悪くないが、個人的にはあまり好きにはなれない。 何が、嫌なのか説明するのが難しいが、1つ言えるのは、タブの操作性が今1つで、空の新しいタブを開いたりする操作が面倒だ。 ナビゲーションは、アドレスバーとブックマークバー、タブの3列に見えるが、実際には、複数のタブを開いた場合のみ、タブが表示される。 ブックマークバーを非表示にすれば、他のブラウザと大差ないレイアウトだ。 … 続きを読む →

Posted in ネット・PC | Tagged , , , , , , | Leave a comment

IEのレンダリングモードをタグで明示的に指定する

地震の影響で日本語版は、リリースが延期になったが、「Internet Explorer 9」がリリースされた。 私も英語版をダンロードしているが、パフォーマンス面で大きな改善が見られる。 ウェブ標準準拠については、IE8で個人的に満足が行くレベルになっていたし、HTML5やCCS3へ新たに準拠しているが、これについては実際に恩恵に預かるのは、まだ先の事と考えている。 私が管理しているHPも当面はXHTMLで記述するつもりだ。 ともあれ、他の主要ブラウザと比較しても遜色のないレベルに仕上がっており、近年のIEとしては、評価に値するバージョンだ。 しかし、ウェブ作成者の立場で、1つ気に入らない点がある。 正確にはIE8から実装された機能だが、アドレスバーに「(後方)互換モード」への切り替えボタンが表示される点が気に入らない。 世の中には、様々なウェブサイトが存在する。 W3Cが勧告するウェブ標準に沿った記述がされているサイトもあれば、ウェブ標準からズレたサイトもある。 その為、多くのブラウザは、複数のレンダリングモードを持ち、ウェブ標準に従ったサイトも、そうでないサイトも、綺麗に表示されるように工夫されている。 実際、FireFoxなどにも、ウェブ標準に基づいた解釈する「標準モード」や「ほぼ標準モード」の他、「(後方)互換モード」というウェブ標準からズレたサイトを表示するレンダリングモードが実装されている。 通常は、HTML上の「DOCTYPE」の記述によって、ブラウザがレンダリングモードを自動的に判断してる。 勿論、IEも例外ではない。 しかし、IE8以降では、ユーザーが「互換モード」へ明示的に切り替えるためのボタンが付いている。 IEの場合、過去の経緯から「DOCTYPE」での判断だけでは、不順分なため、「もし、綺麗に表示されなかったら押して下さい。」的な、親切機能として付いているのだが、逆に、「DOCTYPE」による自動判断で正しいレンダリングモードが選択されるような記述を行なっているウェブ作成者にとっては、不愉快な機能だ。 書類が破れたように見えるアイコンで、見た目も良くない。 加えて、ユーザーが間違って押せば、予想外の結果を招く可能性もある。 そこで、IE8が登場してからは、このアイコンを消すためのだけに、ある「metaタグ」を追加してきたが、このブログには、追加していなかった。 IE8やIE9には、ブラウザモードとドキュメントモードという2つのモードがある。 ブラウザモードは、ブラウザの「振る舞い」を決め、ドキュメントモードは、所謂、レンダリングモードを指し、描画を決定している。 IE8やIE9を開いた状態で、「F12」キーを押すと、開発者ツールが表示されるが、ここで、ブラウザモードとドキュメントモードが切り替えられ、様々な描画条件での表示を確認する事ができる。 これはあくまで、開発者ツール上の機能で、一般向けではない。 ユーザーやサイト作成者が、ブラウザモードやドキュメントモードを明示的に指定する方法もあるが、正しく、HTMLを記述してさえいれば、通常は全く意識しなくて良い。 IE9では、4つのブラウザモードを実装してる。 IE9・・・IE9して振舞う。 IE9互換・・・「互換モード」ボタンを押したときに、このモードになる。IE7として振る舞うが、サーバーが受け取るユーザーエージェントから、本当はIE9であることも分かる。 IE8・・・IE8として振舞う。 IE7・・・IE7として振舞う。 具体的にブラウザモードを説明すると、ブラウザモードの切替で、IE9でも、IE7のように振舞わせる事ができる。 例えば、ブラウザモードをIE7に切り替えれば、サーバーが受け取るユーザーエージェントのバージョン情報もIE7になる。 しかし、ドキュメントモードは、別だ、ブラウザモードの切り替えだけでは、ドキュメントモードは変わらない。 ブラウザモードがIE7だが、ドキュメントモードはIE9標準という事もあり得る。 ただし、「互換モード」ボタンを押した時は、ブラウザモードだけでなく、ドキュメントモードも自動的に変更されるようになっているようだ。 ドキュメントモードは、描画、つまりサイトの見た目に影響する。 IE9に実装されているドキュメントモードは4つだ。 IE9標準・・・(標準モードの)IE9での描画になる。 IE8標準・・・(標準モードの)IE8での描画になる。 IE7標準・・・(標準モードの)IE7での描画になる。 Quirksモード(所謂、互換モード)・・・IE5での描画に近い。 ドキュメントモードは、HTML上の「DOCTYPE」の記述に従って自動選択されるので、「DOCTYPE」を正しく記述していれば意識する必要はない。 しかし、HTML側で明示的にドキュメントモードを指定する「meta」タグがIEでは用意されている。 細かな文法は割愛するが、下記のような「meta」タグだ。 <meta http-equiv=”X-UA-Compatible” content=”IE=8 ; IE=9″ /> 上記の例では、IE8で参照した場合は、ドキュメントモードは、IE8標準モード、IE9で参照した場合は、IE9の標準モードが選ばれ、「互換モード」ボタンが表示されなくなる。 追加しなくても良い、むしろ不要なタグだと思うが、IE8、IE9から「互換モード」ボタンを消したい場合は、最も手軽の方法だ。 このタグは、ドキュメントモードのみを変更し、ブラウザモードやサーバーが受け取るユーザーエージェントには影響を与えない。 少なくとも、IE8ではそうであったが、IE9では、少し違うようである。 ドキュメントモードは変化しないが、サーバーが受け取るユーザーエージェントは、ドキュメントモードに合わせて変化する。 私は、ドキュメントモードやユーザーエージェント、その他の振る舞いを確認できるページを作成してチェックした。 以下で、ブラウザーモード、ドキュメントモード、ユーザーエージェントなどを確認できるHTMLをダウンロード出来るようにしておく。 サイズ:2KB さて、ここまでは、横道。 本題は、このサイトから「互換モード」ボタンを消す事であるが、私がWordPressで使用しているテーマ「Weaver 2.0」の場合、HTML5を先取りしたのか「DOCTYPE」や「meta」タグの記述が少し変わっている。 もし、気になるなら、まずは、これを変更する。 現時点ではHTML5に関する知識がないので正しく判断できないが、おそらく、このテーマはHTML5で記述されている。 試した限りでは古いブラウザでも表示に問題はなく、必ずしも、この修正は必要ではない。 変更は、テンプレートの「ヘッダー(header.php)」に対して行う。 まず、 ?><!DOCTYPE html> <html <?php language_attributes(); ?>> <head> <meta charset=”<?php bloginfo( ‘charset’ ); ?>” /> という記述を <?php echo ‘<?xml version=”1.0″ encoding=”utf-8″?>’; ?> <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”> <html xmlns=”http://www.w3.org/1999/xhtml” <?php language_attributes(); ?> xml:lang=”ja”> <head> <meta http-equiv=”Content-Type” content=”text/html; charset=<?php bloginfo( ‘charset’ ); ?>” … 続きを読む →

Posted in WordPress, ネット・PC | Tagged , , , , | 4 Comments

海外向けの販売に便利なショッピングカート「Ecwid」

個人的に、仙台在住のデザイナーさんが手がける、手作り手帳の海外向け販売をお手伝いしている。 非常に素晴らしい出来栄えの革の手帳である。 デザイン・ワイ 私は、海外でのマーティングを得意としているわけではないので、残念ながら沢山売れているわけではないのだが、「こんな少ないアクセスでよくも」と思えるほど、コンスタントに売れている。 そもそも、沢山受注しても、手作りなので、注文を処理出来ないのだが・・・。 驚いたことに、非常に高い確率でメール、お手紙、場合によっては、なんと、お礼の品という形でフィードバックが届く。 海外でも非常に高い評価を受けているようだ。 本来のブログのテーマからすれば、この手帳の事を書くべきだが、手帳の話は別の機会に書くことにする。 現在、海外向けの手帳の注文は、メールフォームで受け、折り返し、メールで支払先の「PayPal ID」を連絡する形で対応しているが、使い方が分かり難いという意見があったり、間違った金額を支払われたりすることもある。 また、コンスタントに注文も来るので、出来れば管理上の手作業を減らしたい。 そこで、ショッピングカートを導入しようと、昨年末から、様々なカートをテストしてきた。 その結果、1つのカートに絞ったのだが、それがロシア生まれのショッピングカート「Ecwid」である。 「開発元である「Creative Development LLC」は、「XCART」などのショッピングカートも手がけており、この分野に強い会社のようだ。 「Ecwid」は、サーバーにインストールするタイプではない。また、ホスティング型のサービスでもない。 「JavaScript」で記述されたコードを、自分のサイトに貼りつければ、そのページがショッピングカートになる。 サーバーではなく、ブラウザでの演算に依存する手法なので、理屈的には、「JavaScript」の使用に制限のないホームページ、サーバーなら、場所を選ばず、「Ecwid」を利用出来るのだ。 有料版と無料版が用意されており、無料版でも十分な機能を持っている。 管理機能や受注データの保存は、「Ecwid」サイトのコントロールパネル内で行っているので、ホームページさえあれば、特に追加投資無く、ショッピングサイトを構築する事が可能である。 「Ecwid」の利点としては、 自サイトへの導入が簡単でサーバーに依存しない。 サーバーやサイトの移転の際の作業が簡単。 多言語表示に対応。 たっぷりと画像や動画を使って商品ページの作成が可能。 ダウンロード製品の販売にも対応。 柔軟な配送設定が可能。 柔軟な決済が可能。 決済方法としてPayPal、GoogleCheckoutをサポート。 携帯電話用ページも作成出来る。 Facebookページに、カートを表示させる事が可能。 プラグインを利用してWordPessに表示させる事も可能。 などが上げられる。 しかし、「JavaScript」を利用しているため、スクリプトの読込みにやや時間がかかる印象がある。 また、ページ全体をSSLで暗号化出来ないため、フォームデータの送信に関しても不安があるが、最低限のセキュリティは施されている。 加えて、カートやメールはUTF-8でエンコードされているため、日本の携帯電話では、機種によっては、2バイト文字が文字化けする可能性があるが、海外の携帯電話では問題ない。 「Ecwid」が提供するショッピングカートは、シンプルなデザインで、様々なサイトにマッチする。 デザインが気に入らなければ、CSSでカスタマイズする事も可能だ。 買い物の仕方も、一般的なカートを踏襲したものであり、顧客が使い方に悩むことはないだろう。 技術的にはAjaxが使われており、ページを移動してもページの再読込みが発生しないので、買い物をする側としても楽だ。 携帯電話用のページも用意されているが、フルブラウザでの参照を前提としており、HTMLで記述されている。 画面が小さい携帯電話でも、無理なく表示できるように、横幅が狭く、画像も極力廃したデザインになっている。 ショッピングカートの表示言語は、コントロールパネルから設定出来る。同時に複数の言語が設定でき、顧客のPC環境に合わせて、自動的に表示言語が選択される。 英語の他、ブラジルポルトガル語、ブルガリア語、中国語、クロアチア語、チェコ語、デンマーク語、オランダ語、エストニア語、フランス語、ドイツ語、ギリシャ語、ヘブライ語、ハンガリー語、インドネシア語、ラトビア語、ポーランド語、ルーマニア語、ロシア語、セルビア語、スロベニア語、スペイン語、スウェーデン語、タイ語、ウェールズ語に対応してる。 現時点では日本語には対応していないが、後で述べる通り、将来、対応する可能性もある。 追記:Ecwid 7.0から、ショッピングカートについては日本語での表示に対応。ただし、管理画面のメニューは、日本語表示されない。 多言言語表示と言っても、あくまでショッピングカートの表示言語であり、コントロールパネルの表示言語は英語を基本としている。 しかしながら、テスト段階であるためかスマートなやり方とは言い難いものの、コントロールパネルの表示言語を切り替える事も可能だ。 現状、英語、ロシア語、フランス語、ドイツ語、イタリア語に対応している。 なお、コントロールパネルの言語の切り替え方法については、ナリッジベースの「Backend translations」に記述がある。 「Ecwid」では、ショッピングカート上のラベル(表示)をJavaScriptによって書き換える機能も提供している。また、エンコードがUTF-8であるため、日本語などの2バイト文字での置き換えも可能だ。 このラベルの置き換え機能を利用した、言語インターフェースが、JavaScriptの形でダウンロード出来るようになっている。 How to install other storefront translations? 現状、用意されているJavaScriptは、ノルウェー語、トルコ語、フィンランド語、リトアニア語、イタリア語のもので、画像として表示されるボタンの置き換え方法は、「How can I translate or change buttons?」でまとめられている。 ただし、この手法で言語の変更を行った場合は、コントロールパネルで設定した言語の自動切り替えが無効になる。 つまり、使用したJavaScriptに応じた1言語のみでの表示となり、様々な国に向けの販売には向かない。出来れば、言語の設定はコントロールパネル内で完結させるべきだろう。 また、これらのJavaScriptは、現行バージョン用に作成されたものではなく、置き換えも不完全で、翻訳されないラベルも発生する。 「Ecwid」では、ラベルを置き換えるJavaScriptを簡単に作成できる「Ecwid Translate Tool」を提供しているので、これを利用して翻訳や気に入らない表現の置き換えが可能だが、このJavaScriptの使用は、1言語で運営する場合に限り、有効と言える手段だ。加えて、現行バージョンでは、置き換えが不完全である。 前にも書いた通り、最も良い、言語の設定は、コントロールパネル上で設定することだが、必要とする言語に未対応の場合でも、その気になれば、「Ecwid」から提供されるのを待つ必要はない。 「Ecwid」は、翻訳に関してはボランティアを募集している。 翻訳のやり方は、「How to translate my Ecwid store to a new language?」にある。 また、コントロールパネルの翻訳に関してもボランティアを募集しているが、ラベルなどの情報は公開されていないようなので、興味があれば「Ecwid」にコンタクトしてみるのも良いだろう。 実は、私も、ショッピングカート部分だけではあるが、日本語訳を作成し、「Ecwid」に提出した。次期バージョンで採用される可能性もある。 ファイルは、「Japanese language files」で公開されており、その中の「ecwid-ja.js」を使えば、採用を待たなくとも、日本語化が可能だ。 ただし、間違いがあるかもしれないので、使用に関して何の保証もしない。 「buttons_ja.zip」には、日本語版のボタン、「notifications_ja.zip」には、コントロールパネルの「Mail」で設定するためのメール用メッセージが含まれている。 日本語化した場合でも、住所の入力方法までもが日本風に変わるわけではないので、日本国内向けの販売には不向きだ。 これは、仮にコントロールパネル上で日本語の選択が可能となった場合でも同じこと。あくまで、「Ecwid」における日本語版とは、海外から日本に対して販売を行う場合に便利な機能である。 日本人にとっては、コントロールパネルの日本語訳こそ、一番有益かもしれない。 日本語で管理出来れば、海外向けのショッピングサイトの運営が楽になる。

Posted in WordPress, ネット・PC | Tagged , , , , , , | 1 Comment

WordPressのテーマを「2010 Weaver」から「Weaver」に変更

先日、WordPress用のテーマ「Weaver」がリリースされた。 「2010 Weaver」の後継が「Weaver」という位置づけのようだが、2011年になったので、今更、「2010」でもないのだろう。 このブログでも、テーマに「2010 Weaver」を使っていたので、早速、「2010 Weaver 1.5.4」から「Weaver 1.7」に変更した。 と言っても、フッターのクレジットを除いては外観は変わっていない。 「2010 Weaver」も「Weaver」も、WordPress標準のテーマ「Twenty Ten」の流れをくむテーマであり、シンプルでカスタマイズし易い点が特徴だ。 「2010 Weaver」と「Weaver」では、サブテーマを選択できるシステムになっているが、どちらも「Twenty Ten」をサブテーマに持っている。 「Weaver」のテンプレート構成や中身は、「2010 Weaver」から多少、変更されていた。 そのため、カスタマイズに関して、多少、悩んだ点もあった。 「2010 Weaver」同様に専用の管理項目を持っており、管理画面の「外観 -> Weaver Admin」からアクセスする。 ここではサブテーマを選ぶことが出来る。 1つのテーマでありながら、予め24種類のサブテーマが用意されており、様々なデザインが楽しめる点も、このテーマの魅力だ。 このブログでは、シンプルな「Twenty Ten」をサブテーマに設定している。 「Main Options」では、PHPやCSSファイルを直接、変更することなく、デザインのカスタマイズが可能だ。 初心者でも簡単に、デザインのカスタマイズが楽しめ、直接、ファイルを編集する方法と違って、リスクも殆ど無い。 「Advaced Options」では、ヘッダーなど特定の領域にコードを追加できる。 CSSやJavaスクリプなども、直接ファイルを編集せずに簡単に組み込むことが可能だ。 以上のように「Weaver」は、初心者から上級者まで、使いやすい易いテーマである。 個人的にも「Weaver」は気に入っている。 このブログでは、過去記事においては、テーマが「2010 Weaver」の場合を例に、コードの挿入場所などを解説しているが、テーマが「Weaver」の場合も追記しておいた。

Posted in WordPress, ネット・PC | Tagged , , | Leave a comment

WordPressの中途半な404エラーを改善する

存在しないページがリクエストされた時に表示する、404エラーメッセージを用意しているサイトも多い。 「お探しのページが見つかりません。~」というヤツだ。 WordPressでも、404エラーメッセージは、用意されているのだが、その動作には少々難がある。 パーマリンクの設定でも、条件は変わってくるが、このブログに限って言えば、例えば、 http://www.near-mint.com/blog/?p=999 の様なアドレスの場合。 WordPressが処理できそうなアドレスだが、(少なくとも現時点では)存在しないページである。 この場合は、WordPressが用意した、404エラーメッセージが表示される。 対して http://www.near-mint.com/blog/404message の様に、WordPressで処理できなさそうなアドレスで、かつ存在しないページがリクエスされた場合は、WordPressが用意した404エラーメッセージは表示されない。 (別途、エラーメッセージを用意していないなら)単にブラウザのエラーメッセージとなる。 WordPressが用意した404エラーメッセージなのだから、WordPressが処理できるURLでなければ、表示されないというのは当然といえば、当然だが、統一感がないので、これを何とかしようと思う。 その前に、前者の場合は、404エラーメッセージが表示されてはいるが、本当にステータスコード「404」を返しているのかという疑問もあった。 ステータスコード「404」は、サーバーが返すコードで「ページが存在しない」という意味になる。 404エラーメッセージのページが表示されるか否かは別として、ステータスコード「404」を返し、サーバーが、明確に「ページが存在しない」事を伝えるのは重要である。 例えば、404エラーメッセージを表示しながら「リクエストが成功しました」の意味のステータスコード「200」を返しているなら、ブラウザはともかく、検索エンジンのエージェントなどは、ページが存在すると勘違いしてしまい、本当は存在しないページに対してクロールを繰り返すかも知れない。 挙句の果ての404エラーメッセージのページが、検索エンジンに登録されることになる。 ステータスコードを調べるには、「ステータスコードチェッカー」というサイトが便利なので紹介しておく。 存在しないURLを入力して、下の図ように「404」となっていれば、正しく、存在しないページとして通知されている。 WordPressが処理して404エラーメッセージを表示した場合も、正しく、ステータスコード「404」を返しているので問題ない。 今度は、WordPressの404エラーメッセージが表示されない後者の例にを解決するために「.htaccess」に ErrorDocument 404 /blog/index.php?error=404 という1行を追加し、404エラーメッセージの指定を行い、対応することにした。 これで、WordPressが処理できるURLについては、WordPressが処理して404エラーメッセージを返し、それ以外のURLについては、「.htaccess」に従う。 「.htaccess」は、WordPressのインストールディレクトリに存在する筈なので、それを編集すれば良い。 エラーメッセージの指定は、「index.php?error=404」としているが、WordPressが用意しているものを流用した。 パスの部分は、自分の環境に合わせて書き換えること。 ちなみに、404エラーメッセージは、テーマの「404.php」で生成しているので、これを自分のブログに合わせて書き換えると良い。 余談だが、ステータスコードを調べる際に、最初は、Telnetで80ポートを叩けば良いと思ったのだが、その時、初めて、「Windows Vista」ではTelnetコマンドが標準でインストールされていない事を知った。 コントロールパネルから、追加インストールする必要がある。

Posted in WordPress, ネット・PC | Tagged , | Leave a comment

WordPressで省略表示時の「Continue reading」を「続きを読む」に変更

WordPressでは、カテゴリ別、月、日付別、タグ別、検索結果等の画面は、記事が全文表示されるのではなく、省略表示になる。 「Continue reading」をクリックすると全文表示されるのだが、どうも「Continue reading」という表現は頂けない。 そこで「続きを見る」に置き換えることにした。 ちなみのこのブログのテーマは、「2010 Weaver 1.5.4」である。 まず、テーマのテンプレート「loop.php」の中に <?php the_content( __( 'Continue reading <span calss="meta-nav">&rarr;</span>', TTW_TRANS ) ); ?> と <?php ttw_the_content_featured( __( 'Continue reading <span calss="meta-nav">&rarr;</span>', TTW_TRANS ) ); ?> と言う記述があったので、「Continue reading」の部分を「続きを読む」に置き換えて見たが、結果は上手くいかない。 どうもIF文で分岐しているようなので、直前の関数が怪しい。 そこで、テーマのテンプレート「2010functions.php」を調べたところ、 function twentyten_continue_reading_link() { return ' <a href="'. get_permalink() . '">' . __( 'Continue reading <span>&rarr;</span>', TTW_TRANS ) . '</a>'; } と言う記述があったので、「Continue reading」を「続きを読む」に置き換えてみたところ、これで上手く行った。 「loop.php」での変更がどこで効いているのかは分からなかったが、とりあえず、変更した状態のままにしている。 ・補足 テーマ「Weaver 1.7」では、「テーマのための関数(functions.php)」の function weaver_continue_reading_link() { の部分のみを変更すれば良い。 管理画面の「外観 -> Weaver Admin -> Main Optiins」の「Continue reading Message」でも変更できるが、ここで変更すると、省略を表す文末の「…」が消えてしまう。 ・補足 現在、日本語表示の問題に関しては、*.po、*.moファイルを編集して対応している。 多言語化をサポートするテーマでは、この方法が最も適しており、テーマのアップデートの際も、(表示項目が変わるような変更がない限り、)*.po、*.moファイルをアップロードし直すだけで対応できる場合が多い。

Posted in WordPress, ネット・PC | Tagged | Leave a comment