Hyper Estraier で WordPress をクロール

Hyper Estraier で WordPress をクロールしようとしたところ
redirected: 301 されてしまいインデックスされない 🙁

$ estwaver crawl -revcont casket
2014-05-15T03:40:17Z    INFO    DB-EVENT: status: name=casket/_index dnum=0 wnum=0 fsiz=9259055 crnum=0 csiz=0 dknum=0
2014-05-15T03:40:17Z    INFO    crawling started (revcont)
2014-05-15T03:40:17Z    INFO    fetching: 0: https://www.yonageya.com/
2014-05-15T03:40:17Z    INFO    seeding: 1.000: https://www.yonageya.com/
2014-05-15T03:40:17Z    INFO    [1]: fetching: 0: https://www.yonageya.com/
2014-05-15T03:40:18Z    INFO    [2]: fetching: 1: https://www.yonageya.com/blog/
2014-05-15T03:40:18Z    INFO    [2]: redirected: 301: https://www.yonageya.com/blog/
2014-05-15T03:40:18Z    INFO    waiting for threads: 0
2014-05-15T03:40:18Z    INFO    crawling finished
2014-05-15T03:40:18Z    INFO    DB-EVENT: flushing index words: name=casket/_index dnum=1 wnum=1 fsiz=9262217 crnum=670 csiz=45533 dknum=0
2014-05-15T03:40:18Z    INFO    DB-EVENT: flushing auxiliary keywords: name=casket/_index dnum=1 wnum=639 fsiz=9262217 crnum=31 csiz=2182 dknum=0
2014-05-15T03:40:18Z    INFO    DB-EVENT: closing: name=casket/_index dnum=1 wnum=639 fsiz=9274906 crnum=0 csiz=0 dknum=0
2014-05-15T03:40:18Z    INFO    finished successfully

301 部分だけ抜き出すと

[2]: redirected: 301: https://www.yonageya.com/blog/

ネットで調べたところ同じ状況の方がいらっしゃいました。

ヒントにさせていただき、調べてみたところ wp-includes/canonical.php に辿り着きました。

        /**
         * Filter the canonical redirect URL.
         *
         * Returning false to this filter will cancel the redirect.
         *
         * @since 2.3.0
         *
         * @param string $redirect_url  The redirect URL.
         * @param string $requested_url The requested URL.
         */
        $redirect_url = apply_filters( 'redirect_canonical', $redirect_url, $requested_url );

        if ( !$redirect_url || $redirect_url == $requested_url ) // yes, again -- in case the filter aborted the request
                return false;

        if ( $do_redirect ) {
                // protect against chained redirects
                if ( !redirect_canonical($redirect_url, false) ) {
                        wp_redirect($redirect_url, 301);
                        exit();
                } else {
                        // Debug
                        // die("1: $redirect_url<br />2: " . redirect_canonical( $redirect_url, false ) );
                        return false;
                }
        } else {
                return $redirect_url;
        }

$redirect_url と $requested_url を比較して同じだったらリダイレクトしないようですが、
実際に $redirect_url と $requested_url を調べてみたところ、

$redirect_url: https://www.yonageya.com/blog/
$requested_url: https://www.yonageya.com:80/blog/

とウチのブログの場合、$requested_url にポート番号がくっついていました ❗

ポート番号をくっつけているのは、同じ wp-includes/canonical.php の以下です。

        if ( !$requested_url ) {
                // build the URL in the address bar
                $requested_url  = is_ssl() ? 'https://' : 'http://';
                $requested_url .= $_SERVER['HTTP_HOST'];
                $requested_url .= $_SERVER['REQUEST_URI'];
        }

ウチのブログの場合 $_SERVER[‘HTTP_HOST’] にポート番号がくっついていました。

そして、同じ状況の方と同じように $requested_url .= ‘www.yonageya.com’ とすると解決する事も確認しました。

それで、どうやって解決するか対応方法に悩みましたが、functions.php に以下を追加して対応しました。

function my_redirect_canonical($redirect_url, $requested_url) {
        if (preg_match('/^HyperEstraier/', $_SERVER['HTTP_USER_AGENT'])) {
                return false;
        }
}
add_filter('redirect_canonical', 'my_redirect_canonical');

強引ですが :mrgreen:

WordPress IE9 対応

IE9 で WordPress の記事が投稿できないというお問い合わせをいただきました。

テストしてみたところ最新の 3.0.5 でもビジュアルエディタから投稿が出来ませんでした:cry:

ただ、IE9 を “互換表示” にすると投稿できる事がわかりました:mrgreen:

とは言えお客様に「互換表示にして投稿してください。」と言って対応していただく訳にもいかず、

なんとかサーバ側で対応できないか調べたところ、以下の meta タグで対応できる事がわかりました。

これをダッシュボードにログインした時のヘッダに出したいので、

wp-admin/admin-header.php

に以下を追加して対応しました。

<?php if (preg_match('/MSIEs9.0/', $_SERVER['HTTP_USER_AGENT'])) { ?>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<?php } ?>

filter をフックしてできるのかもしれませんが。。。:cool:

WordPress MU と /server-status

WPMU を利用しているサイトに munin をセットアップしたところ /server-status へのアクセスができなくてはまりました。

http://example.com/server-status へアクセスすると WPMU トップページへmod_rewrite によってリダイレクトされてしまいます 😥

色々なサイトに記載されている設定を試してみましたが思うように行かず mod_rewrite 以外の方法で何とかしようか…と悩んでいたところHF164.comさんの記事を読んで解決できました 🙂

# for server-status
RewriteCond %{REQUEST_URI} =/server-status
RewriteRule ^.*$ server-status [L]

hf164さんありがとうございます、助かりました 🙂

WordPress に GoogleAnalytics コードを挿入するプラグイン

前回に続き
また勉強と実務を兼ねて WordPress に GoogleAnalytics 用のコードを
挿入するプラグインを作ってみました 🙂

CMS として WordPress を使ってサイトを作成しているので、開発中はテスト用の
コード、リリース後は本番用のコードと切り替える必要があります。

また、リリース後も開発環境はテスト用コードを使い続けるので切り替えを
簡単にできるようにしたかったのです 🙂

管理画面で PC 用のウェブプロパティID、ktai_style 用のウェブプロパティID を
セットして、ktai_style のテンプレートで ks_wp_head(), ks_wp_footer() を
有効化すればOK

すでに同じようなプラグインはありますが自分で作ってみました 😎
このサイトでテスト中です… :mrgreen:

年末年始の目標を達成できました!

年末に目標を立てました。(しょぼい目標ですが)

  1. 荷物を片付ける
  2. 仕事ができる環境を作る
  3. WordPressのプラグインを作る
  • 荷物を片付ける
  • 年末に引越しをしたので全てのダンボールから荷物を出して、快適に(?)暮らせるようになる事を目標としました。
    全てのダンボールを開けて片付けなくても生活をスタートする事もできたのですが、最初にやらないとずーっとやらないと思ったのでガンバリました 😛

  • 仕事ができる環境を作る
  • これは当たり前の事で目標にするまでもないのですが、色々と大変でした 🙁
    事情があって引越しをしてすぐに仕事部屋が使えなかったので別の部屋にPCを置いて使う時だけPCをルータに接続して、それ以外はノートPCで乗り切りました :mrgreen:
    今は仕事部屋で仕事ができる状態になって快適です 😛

  • WordPressのプラグインを作る
  • 以前から作ってみたかったのですがなかなか着手できなかったので、年末年始時間があるので作ってみました。

    作成したプラグインはコメントスパムを検知して自動的に「承認待ち」か「spam」にするモノです。
    「承認待ち」にするか「spam」にするかはプラグインインストール後管理メニューから選択できるようにしました。
    spam判定は単純に英数字記号のみのコメントはspam扱いにします 😎

    少しだけ自分でテストは行ったのですが、本物のspamコメントをちゃんと検知できるかこのブログでテストをしてみます。
    akismetを停止して作成したプラグインをインストールしました :mrgreen:

    とこんな記事を投稿したら英数字記号以外のspamコメントが増えるかもしれませんね… 😥

とりあえず小さいながらも目標を達成できて2010年は良いスタートとなりました。
今年もがんばります 🙂

WordPress 予約投稿

WordPress の予約投稿が上手くいきませんでしたが、解決できました 🙂

ただし cron と wget が使える事が前提条件となります。

例えば blog の URL が http://example.com/myblog/ だった場合、
example.com 上で、cron から wget で以下のように wp-cron.php に
アクセスすると上手くいくようです。

* * * * * wget http://localhost/myblog/wp-cron.php 
--header="Host: example.com"

私は WordPress MU で全てのブログで予約投稿ができるように
以下のようなスクリプトを作成して cron から実行しています。
(WordPress MU 2.8.4a で実際に使っています)

#!/bin/sh
MYSQL=/usr/bin/mysql
OUT=/tmp/wp-cron.out
paths=`$MYSQL --user=DBユーザ名 --password=DBパスワード -D DB名 
-e "SELECT path FROM wp_blogs" -N -s`
 
for path in ${paths[0]}
do
wget http://localhost${path}wp-cron.php 
--header="Host: example.com" 
-O $OUT
rm -f $OUT
done

上記スクリプトに実行権(chmod +x)をつけて cron から実行しています。

* * * * * /usr/local/path/to/wpcron.sh

今のところ問題なさそうです 🙂

※ ❗ スクリプトに MySQL のパスワードなどが記述されているので注意してください
※ ❗ スクリプトは自分だけ、または管理者だけが読めるようにしましょう :mrgreen:

sendmail nocanonify

サーバのドメインをサブドメインに変更したらメールを受信してブログ記事を
投稿する処理がエラーになってしまう現象が発生 😥

開発用のサーバなので良かったのですが 😐

調べるのに結構時間がかかってしまったのでメモ。

調べてみたところ記事投稿用アドレスにサブドメインを付けると
sendmail がサブドメインを削除していて、メールアドレスの
validate でエラーになっている事がすぐに分かりました。

原因が分かったのですぐに解決できると思い軽い気持ちで、
Google で「sendmail アドレス書き換え」などで色々と調べてみましたが
答えに辿り着く事ができませんでした 😥

そこで基本に帰ってアドレステストモードしてみました。

# /usr/sbin/sendmail -bt -C/etc/mail/sendmail.cf
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> /parse foo@sub.example.com
Cracked address = $g
Parsing envelope recipient address
canonify           input: foo @ sub . example . com
Canonify2          input: foo < @ sub . example . com >
Canonify2        returns: foo < @ example . com . >
canonify         returns: foo < @ example . com . >
parse              input: foo < @ example . com . >
Parse0             input: foo < @ example . com . >
Parse0           returns: foo < @ example . com . >
ParseLocal         input: foo < @ example . com . >
ParseLocal       returns: foo < @ example . com . >
Parse1             input: foo < @ example . com . >
Recurse            input: moblog
canonify           input: moblog
Canonify2          input: moblog
Canonify2        returns: moblog
canonify         returns: moblog
parse              input: moblog
Parse0             input: moblog
Parse0           returns: moblog
ParseLocal         input: moblog
ParseLocal       returns: moblog
Parse1             input: moblog
Parse1           returns: $# local $: moblog
parse            returns: $# local $: moblog
Recurse          returns: $# local $: moblog
Parse1           returns: $# local $: moblog
parse            returns: $# local $: moblog
2                  input: moblog
2                returns: moblog
EnvToL             input: moblog
EnvToL           returns: moblog
final              input: moblog
final            returns: moblog
mailer local, user moblog
>

※ moblog というのはブログを投稿する為の alias です

canonify2 で sub が削除されている事がわかりました ❗

そこで今度は Google で「canonify」を検索したところ情報が出てきました。

RBBTODAY

sendmail.mc に nocanonify を追加して sendmail を再起動して解決できました :mrgreen:

FEATURE(nocanonify)dnl

基本に立ち返る事が基本 ❗

WordPress MU のライブラリを CLI から使う時の注意

このブログではないのですが、ktai_entry の inject.php を使って受信したメールから記事を投稿できるようにしました :mrgreen:
その時に気がついた事です。

inject.php から WordPress MU のファイルを沢山読み込むのですが、
その中に wpmu-settings.php ファイルがあります。

wpmu-setings.php の中に以下の記述があり、WordPress MU は CLI から利用する事を想定していないようです。

if( defined( "WP_INSTALLING" ) == false && constant( 'VHOST' ) == 'yes' && !is_
object( $current_blog ) ) {
// NOBLOGREDIRECT が define されていたら NOBLOGREDIRECT へリダイレクト
// NOBLOGREDIRECT が define されていないならサインアップへリダイレクト
die();
}

つまり CLI からアクセスすると wpmu-settings.php を読み込んだ時点で die() してしまいます。

CLI のときには上記処理へ行かないようにして回避しました。

if( defined( "WP_INSTALLING" ) == false && constant( 'VHOST' ) == 'yes' && !is_
object( $current_blog ) && isset($_SERVER['REQUEST_METHOD']) ) {
// NOBLOGREDIRECT が define されていたら NOBLOGREDIRECT へリダイレクト
// NOBLOGREDIRECT が define されていないならサインアップへリダイレクト
die();
}

使っている WordPress MU のバージョンは 2.7.0 です。

他にもいくつか気がついて手を加えた箇所があるので暇を見て書いく予定です 🙂