広告

この広告は30日以上更新がないブログに表示されております。
新規記事の投稿を行うことで、非表示にすることが可能です。
posted by fanblog

Wordpress Post/Page/Category/TagのURL一覧は結局自作しました

ワードプレスのサイトを引っ越しする、思い立ったのはいいんですが、面倒ですよね・・

特にマルチサイトとか立てたちゃっているサイトだと本当、面倒です。


引っ越し自体はたくさん参考になるサイトが見つかるので、ぜひググってください。

ワードプレス自体の引っ越しに関してはいろいろ情報はあります。
でも、
しっかり移行できたのか、
ちゃんとアクセスできるのか、
本当に正しく引っ越しできたのか?
といった移行の正しさを確認する方法が少なかったです。


ワードプレス => 別サーバーのワードプレスだから問題ないでしょ?

って思っていいんですかね・・・

石橋を叩いて渡る性格だと、なんか不安です・・・


がっちりテストケースを組んでやるほど余力もないので、チョー簡単に確認する手段を検討しました。

その方法とは、URLが移行前と、移行後が一致するかです。


同じワードプレス、MySQLを使って、引っ越ししているわけなので、基本記事が表示されるはずです。
データベースごとごっそり移行した場合、あまり神経質になる必要はないかと思います。



ワードプレスの基本機能にある、エクスポート、インポートを使う場合には、ワードプレス自体の設定も絡んでくるので確認したい項目ですね!



ワードプレスのプラグインでいいのがあったらと探したんですが、網羅されているURL一覧プラグインは見つかりませんでした。

もし、知っている方いたら、こっそりコメントいただけると嬉しかったりします^^
(コメントは承認制にしているので、すぐには反映されませんm(_ _)m )


プラグインを探して確認してみて、希望に合うものが見つからなかったので疲れたました。
そこで、探す時間がもったいなかったので、サクッと手抜きphpを作ることにしました。









Wordpress Post/Page/Category/TagのURL一覧のソースを公開・・・

ロリポップ htaccessでwww統一設定はしちゃダメ!ワードプレス4.5

ドメイン名をwwwありか、wwwなしで統一したいことがありますよね

今回はロリポップ(スタンダード)を使ってハマったお話です。
ちなみに、これはロリポップに限った話ではなく、ワードプレス全般の話です。

最初に正解を書いておきます。

ワードプレス wwwありなしの統一設定の正解はこれ!


ワードプレスを使ったサイトでは、.htaccessではなく、
wp-adminで設定>一般 WordPress アドレス (URL)にwwwを指定する

サイトアドレス (URL)も合わせて修正してください。

こんな簡単なことなんです、でも忘れたりしていると30分ぐらいハマります・・・

よくありがちな間違い


価格が安かったお名前COMで独自ドメインを取得して、
ロリポップで利用する設定をしました。

ここでは、例として、example.comというドメイン名にしています。


今回はワードプレスを使ったサイトにしようと「簡単インストール」で
さくさく!っと最新ワードプレス4.5.3をインストールしました。

インストール時に指定したドメインは、wwwなしの、example.comです。

「wwwあり」、www.example.comに統一するために、sshでログインして、.htaccessファイルを編集します。
BEGIN WordPressの前に以下のような感じで、
wwwが付いてなかったら、wwwをつけてリダイレクトするっていう設定を行います。
==========.htaccess ======

Options +FollowSymLinks
RewriteEngine on
RewriteCond %{HTTP_HOST} ^(example\.com)(:80)? [NC]
RewriteRule ^(.*)$ http://www.example.com/$1 [R=301,L]



# BEGIN WordPress

RewriteEngine On
RewriteBase /
・・・
==========.htaccess ======


で、これでアクセスすると
chrome
www.example.com ページは機能していません
www.example.com でリダイレクトが繰り返し行われました。

アクセスできない状況に陥ります。


でも、これってネットでhtacess www統一などのキーワードで探すと見つかる一般的な設定です



よくありがちなhtaccessの間違い www統一設定をデバッグする


RewriteLog フルパス
RewriteLogLevel 99
などで、mod_rewriteの挙動をログファイルに出力することができます。
この設定は、htaccessに指定します。

でも、一般的なレンタルサーバー、ここではロリポップでは指定できない項目になります。
(サーバー側のエラーになります)


「リダイレクトが繰り返し行われました。」とかのエラーが発生している場合は、
少なくともhtaccessに指定した内容を理解できていることになります。

このエラーは、クライアント側(自分のPC側)で判断された内容です。


ログファイルが使えない場合、有効なデバッグ方法の一つとして直接httpアクセスしてみる方法があります。
そのコマンドは、curlです。
-vオプションを指定すると詳細な挙動を確認できます。


% curl -v example.com
↓↓↓↓↓↓ リクエスト
* Rebuilt URL to: example.com/
* Trying 157.7.999.999...
* Connected to example.com(157.7.999.999) port 80 (#0)
> GET / HTTP/1.1
> Host: example.com
> User-Agent: curl/7.43.0
> Accept: */*
↑↑↑↑↑↑ リクエスト

↓↓↓↓↓↓ レスポンス
>
< HTTP/1.1 301 Moved Permanently
< Date: Thu, 21 Jul 2016 08:02:23 GMT
< Server: Apache
< Location: http://www.example.com/
< Content-Length: 240
< Content-Type: text/html; charset=iso-8859-1
<
↑↑↑↑↑↑ レスポンス

↓↓↓↓↓↓ レスポンスボディ
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://www.example.com/">here</a>.</p>
</body></html>
↑↑↑↑↑↑ レスポンスボディ

簡単に説明すると、リクエスト、レスポンス、レスポンスボディの3つの情報がわかります。
example.comにアクセス(リクエスト)、
その結果HTTP/1.1 301 Moved Permanently、301 リダイレクトで、移動先(location)はwww.example.comになります。
locationで移動してくれないブラウザのために、hereリンクのHTMLを出力してくれていることがわかります。

ここまでの動作は、予定通り、正しい流れですよね。


次に、リダイレクト先のwww.example.comで確認してみます。
% curl -v www.example.com
* Rebuilt URL to: www.example.com/
* Trying 157.7.999.999...
* Connected to www.example.com (157.7.999.999) port 80 (#0)
> GET / HTTP/1.1
> Host: www.example.com
> User-Agent: curl/7.43.0
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Date: Thu, 21 Jul 2016 08:03:22 GMT
< Server: Apache
< X-Powered-By: PHP/5.6.21
< Location: http://example.com/
< Content-Length: 0
< Content-Type: text/html; charset=UTF-8
<
* Connection #0 to host www.example.com left intact

www.example.comにアクセスすると、example.comに移動しましたっていう結果になります。

「リダイレクトが繰り返し行われました。」本当に起きています。
example.com => www.example.com =>example.com =>・・・・
という感じで繰り返されていることがわかりました。


まとめ


正解は、htaccessに指定してはいけなかったです。

ワードプレスサイトでは、
wp-adminで設定>一般 WordPress アドレス (URL)にwwwを指定する
が正解です。htaccessで指定する必要はありません。


今回使っているサーバーは、ロリポップスタンダードです。
月額500円でsshログインもできちゃうサーバーなので、bash使える方は簡単に設定できます。

月額500円より安いライトプランでもワードプレスが使えます。
MySQLが1つしか使えなくても、ワードプレスは1つのMySQLに複数インストールできちゃいます。
マルチドメイン50個まで対応しているので、最大50個のサイトも作れますよ。

ライトプランはsshが使えません、またphpが高速に動くモジュール版も使えません。
もうちょい速いの!って思ったらスタンダードが鉄板だと思います。












エックスサーバーのsqlite3でどハマりした件

データベースっていいですよね!
MySQLとか、SQLiteとか、レンタルサーバーで使いたい放題です。

そんな感じなので、サーバー移転とか、とっても安易に考えていました・・・


今回、お名前共用サーバーからエックスサーバーへ乗り換えようと思い立った理由は、
お名前共用サーバーの月額1000円、エックスサーバーの月額1000円、金額が同じだからです。

お名前共有サーバーを使っていて、すごい困った事っていうのは特にありませんでした。
ちょっと困ったなってことはいくつかあって
  1. お名前共有サーバーから外部へ接続(FTP/HTTP)する経路がブロックされていることがある
  2. 上の影響か、wordpressのアップデートを実行すると、とても遅く感じる
  3. PageSpeed Insightsでサーバーの応答速度の指摘事項を消す事ができなかった
  4. mod_deflate/mod_expiresが使えない

振り返ると結構あるもんですね

ま、いいんです、お名前COMで賢威も安く買えたので、満足しています。







今回エックスサーバーに変えたのは、php7が使える事、mod_pagespeedが使えたりすること、
あと、お友達に聞くと、みんな揃ってエックスサーバーがいいってオススメされたこともでかいです。


と、かる〜い気持ちで、X10を契約しました。
(お名前 共用サーバーは、しばらくお別れする予定です)


お名前共用サーバ vs エックスサーバー X10を軽く比較


ほぼデフォルトの.htaccessでエックスサーバーX10は、
「PageSpeed Insights サーバーの応答速度は合格」です。
これだけでも、結構満足度高いです。

ちなみに、お名前共用サーバーではあがいてあがいて、不合格のままでした。



gccも使えたので、コンパイルし放題かもしれません。


ただ、libcは2.5。gccは4.1.2と結構古めです。
今時のバイナリを持ってきても、libcが古いので動かない可能性大です。
コンパイルしましょうね!(make/configureはちゃんと動きました)



前置きが長くなってしまいました、ようやく本題に入ります。
現時点では解決できていません。

エックスサーバーのsqlite3でどハマりした件


エックスサーバーは、php7への取り組みがとても早かったので、スペック最新なんだね!
という印象でした。

だから、あまり細かいところまで確認しないで契約してしまったのがいけないんですけど・・

お名前.comの共用サーバーでは、pdo_sqliteのバージョンは、3.7系でした。

エックスサーバーでは、pdo_sqliteのバージョンは、3.3系でした。

そう、とっても古いバージョンなんです。

全文検索を前提に組んでしまったシステムがあり、VIRTUAL テーブルとFTSを使っています。
実はこれがネックになっていて、3.3系では弾かれエラーになりました。(ー ー;)

sqlite3.3.6では対応していないんです・・・

問い合わせしてみたら、1時間あまりで即応答もらえました。
(エックスサーバーのサポートいいね!)

sqlite3.3.6以外は使えないとの回答でした。ガッテム・・・


システムを組んでいるひとは、必要なモジュールのバージョンをしっかり確認しましょう
と、少し失敗してしまった私が言います(笑)


じゃ、どうするか・・・
エックスサーバーのX10は
50個のMySQLサーバーデータベースで、1つあたり500MBまでの容量が使えます。

1データベース500MBの制限はちょっと厳しい感じですが、データベースを複数個使ったシステムに変更しようと計画中です。

あまり手を加えたくないんですけどね・・・

もう一つの方法は、こちらの記事「sqlite3, pdo_sqlite モジュールの全文検索(FTS)対応コンパイル手順」に書いてある方法です。
FTSが有効なpdo_sqliteを自分で用意して、php.iniに適用する方法です。
この方法は、エックスサーバーのサポート外、自己責任となります。
ただ、既存ソースコードに手を加えなくていいっていうところが魅力です。

エックスサーバー SQLite3 は 3.8系だった


pdo_sqlite(PDO)SQLite Library:3.3.6
sqlite3(Native)SQLite3 module version:0.7-dev
SQLite Library:3.8.10.2

PDOとSQLite3のバージョンは一緒だと思っていたんですが、違いました!

ちなみにPHPは、php-7.0.7を使っています。

3.8系はFTS、全文検索がサポートされているので期待大です。

ただ・・・

PDOとSQLite3は別物です。似ているけど使い方が違います


この違い、差分を吸収できるクラスを知っているって方はコメントから教えていただけると幸いです。
PDOで使っていたソースを
new SQLite3差分クラス()的な呼び出しをすると
後はPDOとSQLite3の差分を吸収してくれて、ソースを修正する必要ないって感じが望みなんです。

  1. トランザクション PDO::beginTransaction() vs $sqlite3->exec("BEGIN ;");
  2. フェッチ PDOStatement::fetch() vs SQLite3Result::fetchArray()

    SQLite3はカーソルっていう概念がないんです><


  3. Exec PDOは行数を返します、SQLite3は成功、失敗だけです

まだまだ違いはたくさんあります。

そのまま修正するとソースコード修正箇所もうなぎのぼり!


と、ちょっと断念気味です。

エックスサーバーのsqlite3でどハマりした件 修正方法のまとめ


ここまでの修正方法をまとめると3つの方法がありました。
  1. 1)sqlite3をやめて、MySQL+FULLTEXTを活用する

    PDOを使っているので、ソースコードの修正は部分的です。でもqueryの方法が違うので、それなりの規模感を感じています。

  2. 2)pdo_sqlite3を自前で用意する

    エックスサーバーと同じようなLinuxのバージョン、gccなどを揃えて、pdo_sqlite3を作る必要があります。
    ソースコードの修正は一切不要です。
    コンパイル環境を用意したりするのが面倒ですね

  3. 3)PDO=>new SQLite3()に変更する

    エックスサーバーのpdo_sqliteのバージョンは古かったですが、SQLite3のバージョンは3.8系で新しかったです。
    PDOとSQLite3クラスは考え方が違うので、ソースコードの修正は広範囲になりそうです。



いずれにしても、いばらの道の予感がビリビリ来ています(笑)

コンパイル済みのpdo_sqlite3(FTS有効)があればベストなんですけどね・・





最後に


ここで書いているのは独自のPHPでシステムを組んでいる場合の話で、
ワードプレスを使い倒す分には、エックサーバーという選択は正しいと感じています。

速くて、PHPのバージョンも豊富だからオススメできます。

詳しくはこちらから↓↓↓↓↓



X10じゃ何もないかと思っていたんですが、ドメイン1つもらえました。
サーバ使っている限りはずっと更新料がかからないやつでした。
地味に嬉しいです(笑)






エックスサーバーのsqlite3でどハマりした件 修正方法のまとめの追記(7/14)


最終的に移行できたので、その顛末をご報告しておきます。
  1. 1)sqlite3をやめて、MySQL+FULLTEXTを活用する

    最後の手段として残しておきました。結局この方法は選びませんでした。


  2. 2)pdo_sqlite3を自前で用意する

    この方法は断念しました。以下に理由を説明します。

    まず、エックスサーバーはLinux x86_64です。だから適当なRPMからpdo_sqlite3を抜き出せばいけるんじゃ?
    RedHat EL 6 for x86_64のpdo_sqliteをダウンロードし、抽出、そしてエックスサーバーに適用してみました。
    =>エラーでロードできませんでした。PHP Warning: PHP Startup: Unable to load dynamic library
    pdo_sqlite.so: undefined symbol: __zend_calloc in Unknown on line 0

    別途環境を用意するのは面倒だったので、エックスサーバーにはgccがあるじゃないか!

    phpをコンパイルし、エックスサーバーでphpizeコマンドを作りました。
    phpizeコマンドでpdo_sqliteをコンパイルし、適用してみました。
    =>うまくいきません>< 
    調べてみるとphp.iniでフルパスextensionを指定しても、
    所定のフォルダ以外に置かれたものは適用できない旨の情報をみつけました。
    つまり、root(管理者)じゃなきゃ、無理って思い、この時点で諦めました。



  3. 3)PDO=>new SQLite3()に変更する

    結局この方法を採用しました。
    PDO(sqlite3)からnew SQLite3への変更箇所をまとめる以下6点でした。
    ごにょごにょやりながらメモっていたので抜けがあるかもしれません。ご了承ください。

    • 1.接続文字列のsqlite:=>””に変更する
    • 2.fetch(PDO::FETCH_ASSOC)=>fetchArray(SQLITE3_ASSOC)に変更する
    • 3.プリペアを使っていない closeCursor() =>finalize()
    • 4.プリペアを使っている closeCursor() =>close()
    • 5.beginTransaction() =>exec("BEGIN;")
    • 6.prepare execute(array) の流れ=>prepare bindParam(bindValue) execute(void)

      bindParamで文字列の結合を行った値を渡していたらうまく動かずかなり悩みました。
      渡した値は参照渡しが基本で、bindParamで設定した値が確定するタミングはexecute、ということで
      エラーになっていました。http://webmaster.chielog.com/php/133.htmlが参考になりました。
      bindParam(1,"xx".$xx."xx")を変数を使って、bindParam(1, $value1)とかに変更したら問題解決です。






今回のロジックではCRUD系が少なかったので楽でした。

CRUD系のロジックをPDOからnew SQLite3に変更するのはとても面倒な作業になりますね><

VPSとかだとルートにもなれるので簡単だったんですが、共用サーバーなので仕方ありませんね


ついでに、PHP5.5系からPHP7.0系に変更しましたが、こちらはすんなりと移行できました(^O^)/






最新記事
最新コメント
タグクラウド
カテゴリアーカイブ
×

この広告は30日以上新しい記事の更新がないブログに表示されております。