ブログ

  • WordPressが表示されなくなった場合の対処法

    先日、いつもどおり、メールを確認しているとgoogleからメールが。。

    http://webmaster.chielog.com/: Googlebot can't access your site
    Over the last 24 hours, Googlebot encountered 15 errors 
    while attempting to connect to your site. 
    Your site's overall connection failure rate is 88.2%.
    You can see more details about these errors in Webmaster Tools.

    意訳すると、「グーグルの検索用ボットが、あなたのサイトにアクセスできません」という内容です。

    早速、当該ブログにアクセスしてみると、たしかに、表示されない。現象としては、サーバーが落ちている感じにみ見える。

    そこで、サーバーの障害情報を確認してみると、サーバー自体は落ちていない。
    http://mainte.coreserver.jp/

    となると、WordPressのファイルに不具合が生じたのかも。そこで、ファイルマネージャーにて、当該ファイル群を確認するも問題なさそう。

    以前、WordPressが表示されなくなったときは、ファイルを全部入れ替えたら表示されたことがあったのですが、最近は、ファイルを弄っていないし、WordPressの更新処理もしていない。

    そこで、ネットで調べてみると、データベースに不具合が生じている可能性があることが判明。

    CORESERVERでは、MySQLが使えるのですが、そのMySQLに不具合が生じているとのことです。

    具体的には、データベースにオーバーヘッドなるものが発生していて、パフォーマンスが低下しているらしい。なお、オーバーヘッドとは、データベース領域内のゴミのようなものの意。

    そこで、早速、phpMyAdminにて、MySQLにログインして確認してみると、たしかに、いくつかのテーブルにオーバーヘッドが生じています。

    コメント用のテーブルに、オーバーヘッドが多いので、どうやら、コメントスパムが、大量に投稿されるようになったのが原因の一つと推定できます。

    これを解消することにより、ブログが表示されるようになるとのこと。

    オーバーヘッドの解消の方法は、

    テーブル一覧画面の下部にある「オーバーヘッドのあるテーブルを確認してください」リンクをクリックして、テーブルを選択。
    次に、「チェックしたものを:」のセレクトボックスから、「テーブルを最適化する」をクリック。

    これで、オーバーヘッドが解消されます。

    改めて、ブログを確認してみると、きちんと表示されるようになりました。

    以上です。

  • 【XREA】WordPressをSSHでインストールする方法【CORESERVER】

    XREA/CORESERVERにWordPressをSSHでインストールする方法の覚え書きです。

    【1.準備】

    今回は、SSHを使うため、何はともあれ、サーバー管理画面の「ホスト情報登録」から、「SSH登録」をしておきます。

    サーバー管理画面にいるついでに、「データベース」も作成しておきます。アカウントに続く任意の名称をつけ、「作成」をクリック。なお、今回は、文字コードはUNICODEを選択しておきます。

    なお、既に作成しているデータベースを利用するなら、新規データベースの作成は不要です。

    とりあえず、ここまでで、

    1.ホスト情報登録
    2.データベース作成

    の2つを済ませておきます。

    現在、管理画面を開いているので、ファイルマネージャーも開いておくと便利かもしれません。

    【2.WordPressファイルの取得】

    ここまで、終了したら、WordPressの日本語版のサイトに行き、ダウンロードするzipファイルを確認します。

    http://ja.wordpress.org/

    WordPressダウンロード

    今回のファイルはこれです。 http://ja.wordpress.org/wordpress-3.5-ja.zip

    ここまでの作業で、SSHに対して、ホスト情報が反映される頃なので、SSHクライアントを立ち上げます。ここでは、「TeraTerm」を使用します。

    「TeraTerm」にユーザーアカウントとFTPパスワードを入力してログインします。なお、この際、パスワードをCTR+Vで貼り付けしても反映されないので、マウス操作で貼り付けをします。

    さて、ログインできたら、WordPressをインストールするディレクトリまで移動(および、ディレクトリ作成)をします。

    cd public_html 
    mkdir example.com 
    cd example.com

    ここでは、example.com をWordPressをインストールするディレクトリとしています。

    さて、このexample.com 内に先ほど確認したWordPressのzipファイルをwgetコマンドにより取得します。

    wget http://ja.wordpress.org/wordpress-3.5-ja.zip

    上記コマンドで、zipファイルを取得できます。

    次に当該zipファイルを解凍します。

    unzip wordpress-3.5-ja.zip

    上記コマンドで、瞬時に必要なファイル・ディレクトリが揃います。FTPクライアントでアップロードする手間が省けるのが最大の魅力です。

    ドメイン直下にwordpressディレクトができているので、ここに移動し、ファイルを一覧表示します。

    cd wordpress 
    la

    すると20程のファイル・ディレクトリが存在するのがわかります。

    【3.設定ファイルの編集】

    インストールに必要なファイルは、wp-config-sample.php です。 ただ、このまま使うのではなく、名前をリネーム(変更)して利用します。変更名は、wp-config.php です。

    cp wp-config-sample.php wp-config.php

    上記コマンドにより、wp-config.php ファイルを作成します。

    次に、必要な設定をwp-config.phpに書きこみます。

    ここでは、vi により、ファイルを編集します。なお、ファイルマネージャーを利用したり、PHP用のエディタで編集することもできます。

    vi wp-config.php

    viでファイルを開くと、編集する部分が丁寧に説明されているので、それに従って書き込んでいきます。

    設定する箇所は、MySQL情報、テーブル接頭辞、秘密鍵、などです。

    まず、自分の情報に書き換えるため、不要な箇所を「x」または、「dd」で削除します。

    次に、「i」で入力モードにし、必要な情報を書き込んでいきます。

    最後に、エスケープで編集モードに戻り、「:w」で上書き、「 :q」 で終了します。

    設定ファイルの編集はここまでです。

    【4.インストール】

    以上まで完了したら、次に、作成したドメインのインストールページにアクセスして、インストールを完了させます。

    http://example.com/wordpress/wp-admin/install.php

    ここまで上手くできているなら、「ようこそ」ページが表示されます。

    WordPressようこそ

    ここで、ブログタイトルやパスワード、メールアドレスなど必要な情報を入力して、下段の「インストール」をクリックします。

    これで、インストールが完了します。おそらく、WordPressの管理画面である「ダッシュボード」に遷移しているはずです。

    【5.トップページURLの変更】

    ただ、このままだと、ブログのトップページのURLが、

    http://example.com/wordpress/

    となっているので、これを

    http://example.com/

    がトップページになるように変更します。

    まず、WordPressの「設定」→「一般」と進み一般設定画面において、

    「サイトアドレス(URL)」を、http://example.com に変更します。この際、最後のスラッシュは不要です。

    変更したら、「変更を保存」をクリック

    なお、「WordPress アドレス (URL)」は、そのままでOKです。

    次に、サーバーにある、wordpressのディレクトリ内のファイルをコピー、編集します。

    まず、wordpressディレクトリ内に移動し、index.phpを一段上のドメイン直下にコピーします。

    cp index.php ../index.php

    index.php をコピーできたのを確認して、ドメイン直下の当該ファイルを変更します。

    vi index.php

    require(‘./wp-blog-header.php’);

    の行を次のように変更します。

    require('./wordpress/wp-blog-header.php');

    以上で基本的な設定は終了です。

    【6.パーマリンクの設定】

    ついでに、パーマリンクの設定もしておきましょう。

    ここでは、

    /%category%/%postname%

    として、カテゴリーに、記事名を足したものにします。

    もし、最後を、.htmlにしたければ、下のようにします。

    /%category%/%postname%.html

    ここで、XREA/CORESERVERでは、.htaccessの書きこみ権限はないので、作成するように促されます。

    そこで、

    vi .htaccess

    として、表示されたmod_rewrite ルールを書き込み保存します。

    これでパーマリンクの設定も終了です。

    以上、お疲れ様でした。

  • 【XREA】CRONが動かない時の対策【CORESERVER】

    XREA・CORESERVERでのクローンの設置の仕方は下記ページで解説しました。

    http://webmaster.chielog.com/php/39.html

    当該ページの作業をすれば、ほぼ上手くいくのですが、稀にCRONが作動しない場合があります。

    そのようなCRONが動かない場合に次のようなエラーメールが届くことがあります。

    Cron Daemon 
    
    Status: 404 Not Found 
    Content-type: text/html
    No input file specified.

    クローンの設定およびパス、そしてコードのスペル等すべて正しいのに、このようなメールが送られてきたなら、原因の一つにshファイルの改行の不具合が考えられます。

    クローンの設定で使う、shファイルの改行は、LFであることが必要のようです。これが、CRLF等になっていると不具合が生じ上記エラーメールが送信されることになります。

    そこで、対策ですが、一度、shファイルを削除して、新規にshファイルを作成します。その際に、ローカルのWindowsでshファイルを作成しアップロードするのではなく、管理画面のファイルマネージャーで、ファイルを作成し、クローン設定画面のサンプルコードをコピーアンドペーストします。

    あるいは、SSHログインしてサーバー上で、コマンドを発行してshファイルを作成してみるのも良いかもしれません。

    いずれにしても、CRONの不具合で、自分が上記エラーメールを受けたときは、shファイルを一度削除して新規に作り直すことで、CRONが動くようになりました。

    一応、参考として覚書しておきます。

  • 【標準モード】CSSにおける幅(width)の解釈の違いと対策【後方互換モード】

    現在開発中のWEBサイトにおいて、CSSのwidthの解釈がieとfirefox他で異なっていたのを修正したことの覚書です。

    (前提)

    標準モードにおけるwidthの解釈

    width = 内容物の幅のみ ※padding、borderを含まず

    後方互換モードにおけるwidthの解釈

    width = 内容物の幅+パディング + 線 ※padding、borderを含む

    つまり、結果として、標準モードは幅が広く、後方互換モードは幅が狭くなる見た目になります。

    (対策)

    今回の自分のケースでは、

    DOCTYPE宣言にトランジショナルでURI無し

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

    を使用していたため、ieで後方互換モードとなり幅の表示が異なってしまってました。

    そこで、

    DOCTYPE宣言をトランジショナルでURI有りに変更しました。

    <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" 
    "http://www.w3.org/TR/html4/loose.dtd">

    すると、ieでも標準モードが適用されることになり、firefox他のブラウザ同様の幅の表示がされるようになりました。

    結論として、標準モードになるDOCTYPE宣言をし、CSSも標準モードに準拠するようにして、幅は、線・パディング・内容物の足し算で常に計算すると幅の見た目を各ブラウザで統一できそうです。

    ちなみに、DOCTYPE宣言をstrictにするのも一つの選択肢なのですが、色々、第三者のタグを挿入するケース(アクセス解析や広告タグなど)も考えると、トランディショナルで妥協するのも現実的かなと思います。

  • HTMLの入れ子の一覧確認シート

    先日、開発中のWEBサイトのバリデーション・チェックをしたところ、「dl要素には、divを入れられない」という指摘を受けました。

    あまり使わないタグだったのでミスも致し方ないとも思ったのですが、ふと他のタグについてもHTMLの入れ子構造が適切に記述できているか不安になりました。

    そこで、HTMLの入れ子の一覧ができるサイトを検索で探したのですが、適当なのが意外と見つからず一苦労。

    最終的に見つけたのが、W3Cのチート・シートです。英語のページなのですが、実質、タグの一覧なので、見るのは比較的容易です。

    XHTML 1.0 Strict Cheat Sheet
    http://www.w3.org/2010/04/xhtml10-strict.html

    XHTML Basic 1.1 Cheat Sheet
    http://www.w3.org/2007/07/xhtml-basic-ref.html

    上がXHTML 1.0で、下がXHTML 1.1です。

    簡単に説明しておくと、表の左がタグの「要素」(Element)の列です。表の中央は、取り得る属性(Attributes)の列です。そして、表の右が、取り得る入れ子要素(Content model)です。

    つまり、左の要素は、右の入れ子要素をとることができるという訳です。

    なお、左の要素は色分けされており、水色はインライン要素、紫および灰色はブロック要素となっているようです。(紫と灰色の違いがイマイチわからなかったので分かった方は、コメントで指摘してくれると嬉しいです。)

    また、右の入れ子要素についても、色分けされており、水色はインライン要素、紫はブロック要素となっています。

    この入れ子のチートシートを見て確認するとHTMLのマークアップのミスが確実に減らせます。

    ちなみに、HTMLのバリデーション・チェックも、W3Cのサイトでできます。http://validator.w3.org/

    CSSのバリデーション・チェックも同様に、W3Cのサイトでできます。
    http://jigsaw.w3.org/css-validator/

    CSSの方は、日本語に対応しているので使いやすいです。

    結論として、HTMLのマークアップ時には、入れ子のチートシートをみて確認し、所々で、バリデーション・チェックをするのが効果的といえそうです。