Home > WordPress

WordPress Archive

WordPressでカテゴリーが表示されないのでレンタルサーバを引っ越した

昨年の5月くらいから、当時借りていたさくらインターネット(スタンダードコース)が非常に重く、当時はまだWordPressは入れておらずtDiaryを使っていましたが、ブログを更新しようとしても劇重だったり500とか503エラーが頻発するので閉口していました。

負荷観測鯖一覧 < なんとなく負荷観測の実験中 | さくらのレンタルサーバ非公式FAQでも、441番のサーバなのですが、まわりのサーバより負荷が高いです。ちなみに、この負荷観測は私が借りているスペースで行っていますが、現在私のコンテンツはこの負荷観測用CGI以外はすべて引き払っているので、私が負荷をかけているせいでサーバ全体の負荷が高いわけではないと思います。しかし、これを見ていると441番は負荷が高い方とはいえ、スタンダードコースで同程度に負荷が高いサーバは他にもぽつぽつあるので、さくら側としてはこの程度の負荷は許容範囲内なんだなと思いました。

2008年5月にさくらのサポートに問い合わせたときは、「お客様のコンテンツを拝見いたしましたところ、503 Service Temporarily Unavailable のエラーが検出されておりました。」とか、「本サービスでは月間や一日あたりのリソース(サーバ資源)使用量がそれほど大きくなくとも、瞬発的な大量の同時接続などサーバに対して著しい負荷を掛けていると判断した場合、一時的に制限を施させていただくことがございます。」(私のサーバがこの制限の対象になっているかどうかについては言及なし)など、 こっちからも確認できるようなことやレンタルサーバに関する一般論しか返事には書いてなくて、失望しました。しかし、2005年4月末からずっとさくらで借りていて、コンテンツの引越しも面倒くさかったので、ずるずると使っており、2009年5月の契約更新時にも翌1年分のお金を払ってしまいました。

しかし、2009年7月ごろになって、ブログ更新欲が湧いてきて、快適に更新できる環境を整えたくなり、さくらに再度問い合わせたら、データベースに負荷がかかっているので私のコンテンツには制限をかけているという返事をもらい(やっと、私の借りているものに対して管理側がなにをやっているか教えてもらえた!)WP Super Cacheを入れたりして、その後制限は外してもらえたのかと聞いたら外したとの返事でしたが、サーバの重さはあまり解決されませんでした。

そこでいろいろ調べて、さくらの契約期間がまだ10ヶ月くらい残っていてもったいないですが、サーバが重いのにイライラするよりはと、海外サーバのhostmonsterに乗り換えました。

hostmonsterにしたのは、各種レンタルサーバサイトで割と評価が高かったのと、WordPress公式サイトでもおすすめhostingとして紹介されているbluehostというところがありますが、そことhostmonsterは運営会社は同じで事実上同じサービスを提供していると言われており、hostmonsterの方が少し安かったからです。

hostmonsterは、これを書いている2009年9月7日現在、期間限定で月3.95ドルになっています(たぶん2年以上の契約が条件なんじゃないかと思います)。私が借りた8月上旬は、この時々やってくるという安売り期間ではなかったのですが、TOP 10 Web Hostingからのリンクでhostmonsterのトップページに行くことで(hostmonsterではなく、MonsterHostと表記してあります)、通常1年契約なら月5.95ドルのところ4.95ドルになりました。2~3年契約だともっと安いですが、いきなり複数年契約も怖いので1年契約にして、59.4ドルをカードで払いました。入会金はありません。

乗り換えを決めた理由は、500エラーや503エラーが頻発することのほかに、私は以前このブログのカテゴリを40個ほど作り、さらにそれを階層化していたのですが、いつごろからか、そのカテゴリーが一切表示されなくなったからということもありました。WordPressのフォーラムでも相談したのですが、カテゴリを階層化していることがサーバに負荷をかけているらしいということが分かったので、さくらでもカテゴリを階層化せずに表示すると、カテゴリーの順序がぐちゃぐちゃになるので見づらいですが一応表示されたりもしました。

hostmonsterに移って、最初は階層化されたカテゴリがちゃんと表示されたので喜んだのですが、昨日あたりからまたカテゴリが表示されなくなってしまい、また記事が1つもないので表示されてないのも含めると40以上あるカテゴリは、いくらなんでも作りすぎだろうと自分でも思い、階層化をやめて12個のカテゴリにまとめました。過去ログのほとんどについてカテゴリを変更したので疲れました…。その後何度かこのサイトを表示させていますが、カテゴリは表示されたりされなかったりという感じです。WordPressはカテゴリを階層化する機能を用意していますが、階層化はサーバリソースによほど余裕のある状態でないとまともに動かないものなのかなと思いました。

Google Analytics調べでは、このブログが700PV/日程度、tDiaryを使っている旧ブログが100PV/日もいかないくらいで、この2つのブログが転送量のほとんどを占めています。全体の転送量は、サーバを移転した8月初旬~8月末で7.07Gです。この程度の負荷でストレスなく使うにはいくらくらいのサーバを使えばいいんでしょうね?

hostmonsterに対しては良い点もありますが不満点もあって、1年後更新するかどうかは分かりませんが、またデータベース等も含めて引越しするのめんどくさいなぁ…とも思っています。

良い点は、管理画面にcPanelというソフトを使っていて、これが分かりやすいことです。アメリカのサーバ会社なので管理画面も英語なのですが、アイコンがついているなどで、日本のレンタルサーバ会社が手打ちHTMLで作ったようなデザイン性のかけらもない管理画面に比べてよっぽど見やすいです。

また、相変わらずページを開くのに時間がかかりますが500とか503エラーは出なくなりました。みなさんにお見せしているこのブログの公開ページは相変わらず遅いですが、WordPressの管理画面の方はそれよりも早く開くので、WordPressのプラグインあるいはテーマに問題があるのかなとも思います。

悪い点としては、WordPressの日本語版は運用できなかったことがあります。管理画面からWordPressの自動インストールができますが、インストールできるのは当然英語版で、ちゃんと動くようになったあと、日本語化しようとしてwp-config.phpをダウンロードして「define (‘WPLANG’, ‘ja’);」と書き換えたら、そこしか書き換えてないのに「Fatal error: Allowed memory size of xxxxxxxx bytes exhausted」というエラーメッセージが出ました。それ以前に公式サイトからダウンロードした日本語版をFTPでインストールしようとしたときも同様のエラーが出ました。フォーラムで書いてあるように、このサーバではPHP.ini ファイルを編集できるので、デフォルトでmemory_limit = 32M となっていたところ、数値を徐々に増やして256Mくらいにまでしてみましたが変わらず。仕方がないので英語版のまま運用しています。

さらに、WordPress本体の自動アップグレードができません。これも「Fatal error: Allowed memory size of xxxxxxxx bytes exhausted」というエラーメッセージが出たと思います。なので面倒ですがFTPでダウンロード&アップロードしています。なお、プラグインの自動アップグレードはできます。

また、デフォルトではシェルログインができません。シェルログインしようとすると何か書類をFAXか何かで送れという表示が出てすぐ消えますが、あまりにもすぐ消えてしまうのでどこに何を送るのかメモもできません(Poderosa使用の場合)。

これは良くも悪くもない点ですが、hostmonsterを使う際には、FTPソフトにFFFTPを使うとファイルがうまく転送されない場合があるとあちこちのサイトで読みました。お勧めはFileZillaだそうで、FileZillaに乗り換えましたが特に問題もなく使えていますしFileZilla自体も使いやすいソフトです。さくらを引き払うとき、最後にファイルを消すときにFFFTPからだとうまくファイル削除ができず、普段滅多に使わないコマンドラインを調べまくってファイルを消去しましたが、FileZillaならできたのかもしれません。

というわけで、hostmonster、最高だとうたう個人サイトも多いですが、決して万能とはいえないと思います。とりあえず契約期限の来年8月までは、よっぽどひどいことがない限り使い続けると思いますが、その後乗り換えるかどうか考え中です。その割には検索すると絶賛するサイトがたくさん見つかりますが、自分のリンクを踏んだ人が契約したら65ドルもらえるという高額なアフィリエイトプログラムを提供しているので、アフィリ目当ての人が多いと思われます。

まとめ

  • WordPressの階層型カテゴリはサーバに負荷をかけるので避けた方が無難
  • さくらのレンタルサーバには当たり外れがある。ハズレを引いたらどうしようもない
  • 絶賛されているレンタルサーバはアフィリエイト目的を疑え
  • 月7G程度の転送量で快適に使えるレンタルサーバがあれば教えてください(月1000円/10ドル以下程度が希望ですが相場があればそれも知りたい)

wp-tmkm-amazonプラグインに乗り換え

以前は、Amazonの商品の画像を使ったりアフィリエイトリンクを貼ったりするのに、Amazon Reloaded for WordPressを使っていました。しかし、Amazonのアフィリエイト用 API変更に伴い、古いAmazon系プラグインが全部使えなくなってしまうようです。

詳しくは、Amazon Product Advertising API への対応(PHP版) – もやし日記にありますが、8月15日以降のAmazonのAPIを利用するプラグインは、利用者個々に取得したSecret Access Keyが必要になるとのこと。

Amazon Reloaded for WordPressの公式サイトのコメント欄を見ると、この変更に対応して欲しいという要望を出している人はいて、作者は「そのうち対応するよ」的なことを言っていますが、2009年8月3日時点でプラグインのアップデートはありません。

というわけで、プログラミングのできない私は、新しいAPIに対応したプラグインを探してみました。

そこで見つけたのが、wp-tmkm-amazonプラグイン配布>> OpenMediaLaboratoryです。wp-tmkm-amazonというプラグイン(これ自体は2008年以降更新されていません)にもともとの作者でない人が改良を加えて今回のAPI変更に対応したもののようです。wp-tmkm-amazonの改造自体はあちこちのサイトでいろいろな人が行っていますが、上でリンクしたサイトのものが最終的に最も使いやすい形になっているようです。

このプラグインは、普通にインストールして、管理画面でアソシエイトIDに加えてAccess Key IDとSecret Access Keyを入力します。この2つはAmazon Web Servicesで取得できます。amazon.comに登録したことがある人は、そのメールアドレスとパスワードでAmazon Web Servicesにログインできます。

過去に、Amazon Reloaded for WordPressを入れたとき、メリットとして以下のように書きました

このプラグインを入れると、エントリを投稿する画面にAmazon検索ボックスが出てきて、検索結果をクリックすると画像のみ、またはタイトルのみのリンクをつけたものをHTML化してテキストボックスに入力してくれます。プラグインによっては、独自のタグをテキストボックスに投稿するものもありますが、そういうのを使うとそのプラグインをずっと入れ続けなければいけないので、将来プラグインを使うのをやめたとき、あるいはプラグイン作者が WordPress本体のアップデートに追随するのをやめて使えなくなったときなどに不安が残ります。

しかし、amazon側で今回のような変更があった場合は、これは逆に無力だなぁと思いました…。wp-tmkm-amazonプラグインを使っていれば、独自の[tmkm-amazon]タグでASINを囲んであるものを、プラグインを変更すれば新しいAPI対応に完全に置き換えることができるのです。

というわけで、今回アクセスの多いページ中心に、HTMLを[tmkm-amazon]タグに置き換える作業を行いましたが、正直いって面倒でした。

そのほか、HTMLじか書きに比べてこういう独自タグ方式のメリットとしては、Amazon APIを使ったHTMLはやたらめったら長くなるので、それに比べてテキスト入力画面がすっきりすることがあります。一方デメリットは、左に画像、右に説明といった定形的なリンクしか作れないので、テキストにamazonリンクを貼ろうとしてもできないことがあります。私は本文中に書いた本のタイトルをamazonにリンクさせたりしていたので、これができないのはちょっと不便でした。amazonリンクを書き換えたページでは、そういったリンクは全部削除してしまいました。あとは、Amazon Reloaded for WordPressで貼っていたような、大きな画像には対応していないのも寂しいです。

それから、wp-tmkm-amazonプラグインは投稿画面からamazonを検索することができます。そして検索結果には「amazonで詳細を見る」という文言でamazonへのリンクがついているのですが、このリンクURL内に「3104com-22」という文字が入っています。おそらくアフィリエイトIDですね。これを自分のアフィリエイトリンクにできれば上記の「テキストにamazonリンクを貼る」という使い方もできると思います。というか、他人のアフィリエイトと気づかずにリンクを張る人がいるんじゃないかと思います。URLは長くて読みづらいですし。

また注文ですが、このアフィリエイトIDが、wp-tmkm-amazonプラグインを元々作った人のものなのか、今回の改造をした人のものなのかわからないですが、検索結果からジャンプするときにアフィリエイトIDがつくという説明を見つけられませんでした。一言断りがあればいいのになと思います。プラグインを作った人が利益を得るのを否定するわけではありませんが、利用者に知らせた上でそうしたほうがいいと思います。

書き換えたい場合は、wp-tmkm-amazon.phpの77~78行目で

			$tmkm_amazon_options = array(
				'associatesid' => '3104com-22',

となっていますので、そこを書き換えればできるようです。

WP Super CacheとKtai Styleを併用

もう1年以上前から管理画面やブログ本体を開くときに503エラーが頻発し、自分のサイトが重い重いとぐちりながら、コンテンツの引越しも面倒くさいのでレンタルサーバはずっとさくらインターネットで運用しています。

今回、あまりにも503エラーが頻発しているので、直近24時間のサーバのエラーログが欲しいと申し入れ、エラーログをもらいました。(SAKURA Internet // サポート – オンラインマニュアル – よくある質問(さくらウェブ) : よくある質問と回答一覧 の一番下に「CGIで起こっている問題解消のために、サーバに残ったエラーログをお渡しすることができます。」という記述があります)

そのときにこんなことを言われてしまいました。

また、確認いたしましたところお客さまにて設置されたCGIやPHPにより
データベースサーバに負荷が発生しておりましたため、過負荷やアクセス数等に
関する制限が設けられておりました。

恐れ入りますが、お客さまにて原因となるプログラムを特定していただき
負荷の改善を図ってくださいますでしょうか。

私が設置しているCGIでデータベースにアクセスするのはWordPressだけなので、WordPressが原因だとしか思えないのですが、さくらのスタンダードプラン(月額500円)では平均一日1000PV程度のWordPressのサイトは捌ききれないのかなぁ、月額1000円くらいのところに移転するしかないのかなぁと思っていましたが、負荷を軽くするためにWP Super Cacheを試してみて、これでもダメならサーバ移転を考えることにします。

もともと携帯閲覧のためにKtai Styleを入れているので、これと共存するためにはちょっと手間がかかります。

Ktai Styleのページの注意書きと、WP Super CacheとKtai Styleを併用する方法 – IDEA*IDEAを見てやってみたところ、うまく共存できたようです。

まずWP Super Cacheをダウンロードしてwp-cache-config.php ファイルを作り、それを wp-content/ 直下に置いて、管理画面から新規インストールでWP Super Cacheを入れました。

その後、IDEA*IDEAで言及されている、.htaccessに挿入すべきコードのところですが、管理画面でWP Super Cacheの設定をする際に、「.htaccessを以下のように書き換えますよ」という注意書きが出て、IDEA*IDEAに出ている「挿入すべきコード」(日本の携帯電話のユーザーエージェントに対応するもの)というのもあらかじめその書き換える.htaccessに含まれているようだったので、変更なしでそのまま書き換えるというボタンを押しました(2009年7月現在)。

チェックのため、Ktai Style (携帯対応プラグイン)にあるように、

5. ログアウト状態、かつ、クッキーを削除した状態の PC で閲覧して、リロードしたとき、XHTML ソースの末尾に 「Cached page served by WP-Cache」もしくは「Cached page generated by WP-Super-Cach」の表示があることを確認する (WP-Cache もしくは WP Super Cache の動作確認)
6. 携帯電話で同じページを閲覧して、携帯向け表示になっていることを確認します。PC 表示だったり文字化けしていたら失敗です (PC 向けブラウザーでユーザーエージェント偽装しての確認だとうまくいかないことがあります)。
7. 再度 PC で同じページを見て、携帯向け表示になってないことを確認します (携帯ページがキャッシュされてないかの確認)。

というのもやってみましたが、うまくいったようです。

WordPress 2.8.1にアップグレード& wp.Vicuna Ext の不具合が直った

WordPress 2.8.1が出たので、自動アップグレード機能を使ってアップグレードしました。

WordPress 2.8は、自動アップグレードを行うとサーバー上のファイルが削除されることがあるという不具合がアナウンスされていたため、面倒なので手動でもアップグレードは行わず、2.8.1を待っていたのでした。

現在使っているWordPressのテーマはwp.Vicuna Extというものですが、このテーマにしてからずっと起こっていて、もう諦めていた不具合がありました。それは、管理画面でアクセス解析を見られるWordPress.com Statsというプラグインの結果がどうにもおかしいということです。

以下は昨年12月にキャプチャした、そのアクセス解析の画面の一部ですが、「人気のページと投稿」(アクセス数の多いページ)の結果が最新の投稿から常に5番目のものに著しく偏っていて、このサイトに来る検索ワードやリファラーと照らし合わせて、とても正しい結果を反映しているとは思えなかったのでした。

Global Dashboard › — WordPress

このアクセス解析の偏りは、wp.Vicuna Extのときのみの現象でした。テーマを変えて、ログアウトして(ログインしていると管理者のアクセスとしてアクセス解析に記録されなくなるので)、エントリをいくつかクリックして試してみた結果それがわかりました。

そこで、wp.Vicuna Extの掲示板にも書き込んだのですが、レスもなく、このテーマを変えたくなかったし、詳しく解析する力もないのであきらめていたのですが、WordPress本体を2.8.1に変えてから正しく記録されている模様です。2.8.1にアップグレードしてこれが個人的には一番うれしい変化でした。

カテゴリが一時期消えて、その後復活した

昨日の昼過ぎにこのブログを見たら、カテゴリがまるごとなくなっていました。右側のサイドバーに、「最近の投稿」の下、「カテゴリー」というのがありますが、ここに、「カテゴリーなし」と表示され、いま20以上あるカテゴリが1つもなくなっていたのです。ブログの個別の投稿を見ても、カテゴリを表示するところが「未分類」となっていました。

管理画面に入ってカテゴリを見ると、空っぽになっています。投稿→カテゴリー のところも空白、ブログの投稿画面の下に表示される、チェックボックスを入れて選択するカテゴリーのところにも何も表示されません。

データベースが壊れたのかなと思い、MySQLの「**_terms」というのを見ましたが、ちゃんとあるようでした。それでも不安なので、データベースのバックアップを取っておこうと思い、Backing Up Your Databaseに従ってバックアップしようとしても、エラーが出てできません。以下のようなエラーです。2月6日20時現在でも同じエラーが出ます。

Proxy Error
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request POST /phpmyadmin/export.php.
Reason: Document contains no data

最近入れたカテゴリの順序を入れ替えるプラグイン、MyCategoryOrderのせいかなと思い、MyCategoryOrderのウィジェットと標準のカテゴリーのウィジェットを入れ替えてみたり、RGBlog.net » Blog Archive » 覚書:突然カテゴリー表示が消えた!を参照してサイドバーのPHPを書き換えてみたりもしましたが、私の場合は関係ないようでした。

仕方がないのでそのまま出かけて、夜帰ってきたら、カテゴリが復活しています。結局、何もしていないのにカテゴリが消え、また何もしていないのにカテゴリが復活したのでした。

不安なのでデータベースのバックアップを取ってみようとしても、上記のエラーのためとれません。とりあえず、WP-DB-Backupを使ってバックアップしてみましたが、以前書いたように、WP-DB-Backupでは保存されるデータが異常に少ないうえに、テキストエディタで開いてみるとWordPress関連掲示板の投稿とか、このブログの内容とは関係ない文章が保存されていて、ちゃんと保存されているのか心配です。

My Category Orderでカテゴリを並べ替える

このブログではたくさんのカテゴリを階層分けまでして使っていますが、このカテゴリが作った順でもなく、URLのアルファベット順でもなく、なんだかよく分からない順番で並んでいて、WordPressのデフォルトでは並べ方を自分で決められないのが不満でした。そこで、プラグインのMy Category Orderを使って並べ替えることに。

以前一度このプラグインを入れて、うまくいかなかったのでしばらく停止していたのですが、カテゴリを並べ替えるプラグイン[WP] – ミblog : レビューや日常などを参考にしてテンプレートを書き換えることなどで今回はうまくいったのでメモしておきます。Vicunaテーマを使っている人はこの書き換えが必要になるみたいです。

まず、WordPress公式内にあるMy Category Orderのインストール方法どおり、ダウンロードしてプラグインフォルダに入れて、プラグインメニューで有効化します。そして、管理画面で「投稿」→「My Category Order」でドラッグ&ドロップで(これが楽ですばらしい!)カテゴリの並べ替えをし、保存します。その後、「外観」→「ウィジェット」で、今まで使っていた「カテゴリー」ではなく新しくできた「My Category Order」のウィジェットを入れます。

それからカテゴリを並べ替えるプラグイン[WP] – ミblog : レビューや日常などの通り、Vicunaテーマを使っている人はテンプレートのうちsidebar.phpを開いて以下をコメントアウトし、

<?php wp_list_cats('sort_column=name&optioncount=0&hierarchical=1'); ?>

以下を書き足します。

<?php wp_list_categories('orderby=order&style=list&hide_empty=1&title_li=');?>

なお、カテゴリを並べ替えるプラグイン[WP] – ミblog : レビューや日常などには、「wp-includesにあるtaxonomy.phpを上書きする」とも書いてありますが、このプラグインの2009年1月29日時点での最新バージョンでは、taxonomy.phpというファイルは中に入っていないし、上書きも必要ありません。

ウィジェットのMy Category Order。

ウィジェットのMy Category Order。カテゴリを階層分けしている人は「Show Hierarchy」をにチェックを入れます

これだけやっても、私の場合うまくいきませんでした。なぜかもともと分けていた階層が全部なくなってしまい、指定したカテゴリの順番も反映されずぐちゃぐちゃに並んでいたのです。

しかし、My Category Orderのウィジェットを開いて「Show Hierarchy」にチェックを入れたら並び順も含めてうまくいきました。

そのほか、私は「Show Post Counts」にもチェックを入れて投稿数を表示しています。

関連記事表示プラグインで1ユーザーあたりPVが上がり、直帰率がぐんと下がった

WordPressなどのブログツールやブログサービスによっては、1つのエントリのあとにそれに関連する他のエントリを自動的に表示する機能があります。WordPressでこの機能を実現するプラグインはいくつかあるようですが、日本人が日本語対応で作っているプラグインのほうがいいかなと思い、WordPress Related Post for Japaneseを入れてみることにしました。このエントリを単独で表示すると、下部に「このブログ内の関連するかもしれない投稿」というのがありますが、これがそうです。

このプラグインを入れてからまだ4日分のアクセス解析しか取れていないんですが、1ユーザーあたりのPVと直帰率にすごい変化が出たのでお知らせします。

1ユーザーあたりのPV

1ユーザーあたりのPV。プラグイン導入前は平均1.6PV程度だったのですが、導入後は2.6~2.7PV程度に増えました。クリックで拡大します

直帰率

直帰率。これまで70%以上が普通だったのに、一気に35%以下と半分以下になりました。クリックで拡大します

まあ、企業サイトではないので、PV増加にそれほど必死にならなくてもいいんですが、それでもプラグイン1つでここまではっきりとアクセス解析に差が出るのは面白いです。それに、どうせ見に来てくれたならいろいろ読んで行ってくれるほうが私も嬉しいし。

Vicunaではてなスターが落ちる件の対処法

私が現在使っているwp.Vicuna Ext.というテーマでは、はてなスターの設置は簡単にできるのですが、スターだけがなぜか下の方にずれて表示されるのがみっともないなあと思っていました。ずれていたときの画像は、WordPressのテーマをwp.Vicuna Extに変更の最後の方にキャプチャしたものがあります。このほかスターが多くて「☆14☆」のように表示される場合でも、数字はあるべき位置にあるのに、☆だけが下に落ちていました。

はてなスターというのはjavascriptで表示しているんでしょうか? よくわからないのですが、普通にページのソースを見ても表示されないので、CSSで上下に動かす方法も分からず、「みっともないなー、なんとかならんのかなー」と思っていたところでした。

しかし、maRkのMyOwn – はてなスターとmt.Vicunaで紹介されていたCSSをまるごとコピペしたところ、ちゃんと真ん中に☆が来るようになりました。感謝。こちらで使われているのはMovableTypeのVicunaのようですが、WordPressのVicunaでも同じみたいです。

.hatena-star-star {
      vertical-align: middle;
      margin-top:0 !important;
}
.hatena-star-comment-container a,
.hatena-star-star-container a{
      background-image: none !important;
      padding-left: 0px !important;
}

ついでに、はてなスターのボタン画像を変更するを参照して、コメントと☆追加のアイコンをデフォルトの水色のものからグレーのものに取り替え、周りと色調を揃えてみました。

RSSリーダごとの購読者数が分かるプラグイン「FeedLogger」

WordPressでRSSフィード購読者数を計測するプラグイン FeedLoggerというのを入れてみました。

リンク先にもあるように、今までRSSリーダごとの購読者数を知りたい場合は、FeedBurnerというサービスにRSS配信を預けてしまうということがよく行われていたのですが、「FeedBurnerを使うとYahoo!のブログ検索に引っかからなくなり、SEO上マイナス」という話があります(これについても諸説あり、回避する方法もあるとかいろいろな話がありますが、省略します)。

まあSEOはともかくとしても、自分のブログで配信できるものを、わざわざ外部サービスに預ける気はしないけど、RSSリーダごとの購読者数が分かるものなら知りたいよなーとはちょっと思ってました。そこでFeedLoggerを入れてみました。

インストールは特に変わったこともなくfeedloggerフォルダをプラグインフォルダに入れただけです。「wp-content/plugins/feedlogger/data フォルダに書き込み権限を与えてください。」とのことですが、デフォルトで755になっていて、そのままでいけました(さくらインターネットの場合)。

そのまま数時間待つと、ダッシュボードにRSSリーダごとの購読者数が表示されます。私のところはこんな感じ。

FeedLoggerによるRSSリーダーごとの購読者数

FeedLoggerによるRSSリーダーごとの購読者数

上記ではLivedoor Readerが一番人気ですが、私が個人的に使っているのはこれの英語版FastLadderです。今のところ広告とかオススメとかいった余計な情報が出てこないのがよいです。

wp.Vicuna Extのスタイルシート改造をやり直す

あけましておめでとうございます。本年もどうぞよろしくお願いします。

さて、以前、Vicuna ext.のスタイルシートは、注釈がしっかりついているのでいじりやすそうだと書きましたが、間違っていました。いくつものスタイルシートが複数のフォルダに渡ってあり、階層が深いところにあったりするため、WordPressにあるテーマ編集機能(スタイルシートやテーマのPHPファイルををブラウザからいじれる機能)が使えないため、むしろ編集はやりづらいかも、と昨年末に少しいじってみて思いました。

そのときいじりかけのまま放置してしまったので、改めてどういう構造になっているのかCSSを既存のものに一旦戻して、改造をやり直しつつしっかり見ていくことにしました。

まず、たくさんあるスタイルシートをどういう順番で読み込んでいるかということですが、

http://blog.yuco.net/wp-content/themes/wp.vicuna.ext/style.php

にあるように、

@import url(style-smartCanvas/1-element.css);
@import url(style-smartCanvas/2-class.css);
@import url(style-smartCanvas/3-context.css);
@import url(style-smartCanvas/4-layout.css);
@import url(style-smartCanvas/module/mod_subSkin/1-subSkin.css);
@import url(style-smartCanvas/module/mod_subSkin/2-singleUtilities.css);

@import url(style-smartCanvas/module/mod_gNavi/mod_gNavi.css);

@import url(http://blog.yuco.net/wp-content/plugins/vicuna-adaptors/css/icon.css);

という順番のようです。これら既存のスタイルシートには手を加えず、自作のスタイルシートファイルを追加して上書きする方向で行きたいと思います。

現在ベースに使っているLeavesというテーマを使うには、WordPress テーマ vicuna – スキンのLeavesからダウンロードして展開すると「module」というフォルダができます。これを、

wp-content/themes/wp.vicuna.ext/style-smartCanvas/

以下の「module」というディレクトリにコピーすると使えるようになります。

これで、ベースとなるスタイルシートができたので、自作スタイルシートの置き場所を考えます。

スタイルシートの読み込み順を決定しているstyle.phpの最後の行に

@import url(style.css);

を追加して、CSSファイルはもともと存在していたけれども中身がなくて、使われていなかったstyle.cssファイル内に独自の内容を書いて上書きしていくことにします。ここならブラウザからの編集もできますし。

wp-content/themes/wp.vicuna.ext/style-smartCanvas/module/mod_subSkin

内にある、

1-subSkin.css
2-singleUtilities.css

という2つのCSSファイルのうち、おもに1-subSkin.cssを見て、バックグラウンド画像を指定したり、個別エントリ表示時にタイトルの最初の一文字の色を変更しているのでその色指定を変更(このエントリなら「wp.Vicuna Extのスタイルシートを変更」の最初の「w」の字です)、フッターの文字色変更などをして、style.cssに変更して上書きしていっています。

タイトルやバックグラウンドの画像を保存するためには、既存のディレクトリを使わず、wp.vicuna.ext直下に新しいディレクトリを作ってそこに保存しました。

このようにして、本体がバージョンアップして内容が変更になっても自分が独自に改造した分だけは切り分けられるようにしています。

Home > WordPress

Search
最近買ったもの
Banners

この日記のはてなブックマーク数
フィードメーター - blog.yuco.net

Return to page top