普段はmacを使っています。お名前.COMなどでドメインを取得した後、
ちゃんとwhois代行ができているか確認するようにしています。

実は、先日まで.コムがすごい安くて買ってみました。

新規登録時にwhois情報の代理をチェックしておくと、以降ずっと無料です。




取得した後に、whois代理になっているかを確認したところエラーになってしまいました。

macのターミナル
$ whois xn--eckwd4c7c5976acvb2w6i.xn--tckwe
whois: xn--tckwe.whois-servers.net: nodename nor servname provided, or not known

日本語ドメイン.コム　＝＞　xn--eckwd4c7c5976acvb2w6i.xn--tckwe
（このドメインは例です。取得したドメインではありません！）

日本語ドメイン.comとかだと、punycode変換したxn--eckwd4c7c5976acvb2w6i.comで問題なく調べられます。
punycode変換ツールは、日本語JPドメイン名のPunycode変換・逆変換を使っています。

「.コム」の登録情報をmacでwhoisを使って調べる方法

「.コム」は、punycodeの.xn--tckweを利用するのが正解です。

whoisコマンドには、-h引数でホスト名が指定できます。
-h引数で「.コム」のwhoisサーバーを指定することで検索できるようになります。

$ whois -h whois.nic.xn--tckwe  xn--eckwd4c7c5976acvb2w6i.xn--tckwe

トップレベルドメインは、こちらで検索できます。
IANA.ORG Root Zone Database
見つけた「.コム」のwhoisサーバー情報です。

「.コム」と同じように、「.みんな」、「.グーグル」などもmacでwhois検索できるようになります。



「.コム」の登録情報をmacでwhoisを使って調べる方法以外にも、直接レンタルサーバーにsshログインすることで確認できたりします。

sshログインできるレンタルサーバーのうち、３つ（エックスサーバー、さくらインターネット、ロリポップ）の挙動を確認してみました。

エックスサーバーはそのまま検索できる！

エックスサーバーにsshログインして「.コム」のwhois検索ができるか確認してみました。
エックスサーバーは引数指定しなくても対応済みです。

$ whois xn--eckwd4c7c5976acvb2w6i.xn--tckwe
[Querying whois.internic.net]
[whois.internic.net]

Whois Server Version 2.0
・
・

さくらインターネット（スタンダード）は、引数で指定が必要です。

% whois xn--eckwd4c7c5976acvb2w6i.xn--tckwe
whois: xn--tckwe.whois-servers.net: hostname nor servname provided, or not known

ロリポップ(スタンダード)は、whoisコマンドがありません。

$ whois xn--eckwd4c7c5976acvb2w6i.xn--tckwe
-bash: whois: command not found

「.コム」の登録情報をmacでwhoisを使って調べる方法のまとめ

今回ご紹介した、
「.コム」、「.みんな」、「.グーグル」などのwhois登録情報を確認できる方法は、
新たにトップレベルの日本語ドメインが追加されても応用できる方法です。

少しの手間、IANA DBで対応するwhoisサーバーを探すして、whois -h で指定するだけです。


今回使ったmacは、2016/9時点で最新のmacOS Sierra 10.12を使っています。
pingやnslookupの名前解決は可能です。でもwhoisで検索できませんでした。
ping xxx.xn--tckwe
dig(nslookup) xxx.xn--tckwe
whois xxx.xn--tckwe
macでもデフォルトで対応してくれると嬉しいですね！


新たにレンタルサーバーを契約しようかご検討中なら、エックスサーバーがおすすめですよ

お名前COMっていうとドメインですよね、この記事はお名前COMの共用サーバーからエックスサーバーに引っ越する際のポイントをまとめています。


お名前COMの共用サーバーからエックスサーバーに引っ越し作業を実施しました。

数多いサイトを引っ越ししました。
この中でワードプレスのマルチサイトがあったのですが、とってもハマったので備忘録を兼ねて残しています。

ドメインの管理できる数は無制限とかですが、データベースの数は有限です。
エックスサーバー（X10）の場合、５０個がデータベースの上限です。

なので・・・

データベースを利用するワードプレスで、ドメインとデータベースは以下のように
ドメインに対して１データベースを割り当てるようにしています。
example1.com ＝＞ データベース１
example.com ＝＞データベース２
sub1.example.com ＝＞データベース２
sub2.example.com ＝＞データベース２
example2.com ＝＞データベース３

お名前COM、さくらサーバー、ロリポップ、エックスサーバーなどには、ワードプレスを簡単にインストールできるツールが備わっています。

データベースとドメインが１対１の場合、簡単インストール系がとても簡単です。
データベースとドメインが１対Nの場合、簡単インストール系は使えなかったりします。


エックスサーバーは、手動インストールする必要がありました。

1つのデータベースで複数のワードプレスサイトを管理する仕組み

ワードプレスのwp-config.phpに「 WordPress データベーステーブルの接頭辞」設定があります。
通常デフォルトは、下記のようにwp_になっています。
$table_prefix = 'wp_';


１つのデータベースで複数のワードプレスサイトを運営する場合、このwp_を別々の名前で指定することで対応可能です。

example.com ＝＞ $table_prefix='wp_';
sub1.example.com ＝＞ $table_prefix='wp1_';
sub2.example.com ＝＞ $table_prefix='wp2_';

$table_prefixは、以下のようにテーブル名として利用されます。

• wp_commentmeta
  
• wp_comments
  
• wp_links
  
• wp_options
  
• wp_postmeta
  
• wp_posts
  
• wp_termmeta
  
• wp_terms
  
• wp_term_relationships
  
• wp_term_taxonomy
  
• wp_usermeta
  
• wp_users
  

wp_の部分を変えることで、１つのデータベースで複数のサイトが管理できるようになっています。

ワードプレスって便利ですよね！

お名前COMからエックスサーバーへ引っ越しする際のハマりやすい３つのポイント

ワードプレスとデータベースが１対１のサイトを引っ越す際は、
ワードプレスのエクスポート機能、インポート機能を使いました。


手順は、ざっくりと以下の通りです。

1. コンテンツやメディアを１つにまとめたxmlファイルをエクスポート
   
2. ワードプレスの設定や導入しているプラグインをメモっておく
   
3. ＝＝引っ越し開始 ＝＝
   
4. エックスサーバーのサーバーパネル＞ドメイン設定から引っ越しするサイトを追加する
   
5. お名前COMのドメインNaviでdnsを他社でns1.xserver.jp・・・ns5.xserver.jpに変更する
   
6. エックスサーバーのサーバーパネル＞自動インストールからワードプレスをインストールする
   
7. サイトにアクセスできたら、２でメモったテーマ、プラグイン、設定などをインストール・設定する
   
8. １でダウンロードしたXMLファイルをワードプレスのインポート機能で取り込む
   

ワードプレスとデータベースが１対Nのサイトを引っ越す際、とってもハマりました。


基本的な流れとしては、お名前COM側 MySQLのエクスポート、ワードプレスサイトのフォルダをtarでまとめて転送する、あとはエックスサーバー側に適用するといった流れです。


データベース(MySQL)の引っ越しは、特にハマるポイントはなかったです。

手順としては、お名前COMにadminerをインストールしてデータベースをエクスポート、
エックスサーバー側でデータベースを作って、ユーザーを追加設定し、
phpmyadminを使ってインポートしています。

ポイント１ まさかのサブドメインの文字数制限

お名前COMでは特に意識したことがなかったんですが、
エックスサーバーのサブドメインには文字数制限があります。
制限は、30文字です。

サブドメインは30文字までに心がけましょう！

サポートにお願いしてなんとかなったりしないかなぁと思って問い合わせてみたんですが、
例外なしで、３０文字まででしたorz。

ちなみにオーバーしたサイトはそのままでは引っ越しできません。つまりサブドメイン名の変更になります。・・・

ポイント２ 403 Forbidden、さらに真っ白なトップページ

わかるととっても簡単でしたが、難問でした・・
お名前COMでtar cvf サイト.tar.gz ./サイトでまとめたファイルを
エックスサーバーで展開しました。

パーミッションが変なんです！

どこで変になったのか、ちょっと不明なんです（※１）が、
ファイル、ディレクトリともにgroup/othersの読み込みパーミッションがなくなっていました。
なので、以下コマンドでサッっと設定しなおしたらアクセスできるようになりました。

ディレクトリのパーミッションを一括設定

find . -type d -exec chmod 755 {} +

ファイルのパーミッションを一括設定

find . -type f -exec chmod 644 {} +

どちらのコマンドもとっても便利ですよ^^。これの意味を調べてわかればきっと立派なLinuxerですね

（※１）卵が先か、鶏が先かの問題になりますが、同じドメインで引っ越しする場合、エックスサーバー側で事前準備がしにくかったりします。
ドメインを設定しないとフォルダが作られないとかありますからね

そこで、あらかじめフォルダを作って、事前準備万端で引っ越し作業をしました。
エックスサーバーのサーバーパネルからドメインを追加した後に準備したwordpressのフォルダをmvしたりする作業をしています。

準備していたタイミングでは特にパーミッションの問題はなかったはずですが、アクセスできるようになったタミングではパーミッションがおかしかったです。

ポイント３ お名前COMのウェブ設定＞かんたんブログインストールしたワードプレスの引っ越し

かんたんプログラムインストールしたワードプレスサイトは、
サイト/wp/などwpフォルダがひつようだったり、
4.2.2-ja-jetpackなどが適用されていますよね。


wpフォルダのまま以降したい方は、このポイントは当てはまりません。

ここではwpフォルダからの脱却、jetpack未使用のサイトに引っ越しする方に最適です。

データベースの引っ越しができている状態の場合、コンテンツやワードプレスの設定はデータベースに含まれています。

これ以外に最低限必要なのは、ワードプレスの本体、適用していたテーマ、アップロードした画像ファイルなどです。


ポイント３としては、wpフォルダからの脱却に伴い、データベースを編集が必要です。
wpフォルダがない状態で、wpフォルダにアクセスするため表示されないサイトになります。

エックスサーバーのphpmyadminで、
wp_optionsテーブルのsiteurl、home項目にwpがある場合、
wpをなくすように設定してください。

ポイント４ エックスサーバーに簡単引っ越し！サブドメインの設定手順

名前COMのサブドメインは、~/sub1.example.comのような構成で作られます。
エックスサーバーのサブドメインは、~/example.com/public_html/sub1/のような構成になります。

比較ではあまり語られない部分で、結構ちがったりしますね・・

サブドメインの設定手順は以下の通りです。

1. サーバーパネルからサブドメインを追加する
   
2. sshでエックスサーバーのsub1フォルダにアクセスします。
   

   % cd ~/example.com/public_html/sub1

   
   
   
3. ワードプレスの最新版をダウンロード&展開
   

   % curl -O https://ja.wordpress.org/latest-ja.tar.gz

   
   
   wordpress latest-ja.tar.gzをwordpressディレクトリを除いて展開する方法
   これとっても便利です。忘れないように覚えておくと使いどころ満載です。
   

   % tar --strip-components 1 -xvf latest-ja.tar.gz

   
   
   --strip-components 1で、latest-ja.tar.gzにふくまれているwordpress/の部分を除去して展開してくれます。
   
   
4. ワードプレスの設定
   

   % cp wp-config-sample.php wp-config.php
   % vi wp-config.php

   
   
   データベースの設定、テーブルプレフィックスを適切に設定してくださいね。
   
   あなたの環境に従って最低限修正・見直しが必要な項目は以下５つです。
   DB_NAME、DB_USER、DB_PASSWORD、DB_HOST、$table_prefix = 'wp_';
   
   

   % vi .htaccess 

   
   最低限ワードプレスのデフォルト設定をしておきましょう！
   .htaccessに以下のような記載がなかったら追加してくださいね。
   # BEGIN WordPress
   
   RewriteEngine On
   RewriteBase /
   RewriteRule ^index\.php$ - [L]
   RewriteCond %{REQUEST_FILENAME} !-f
   RewriteCond %{REQUEST_FILENAME} !-d
   RewriteRule . /index.php [L]
   
   
   # END WordPress
   
   
   
   

   ポイント５ tarでシンボリックリンクも含めちゃう お名前COMのウェブ設定＞かんたんブログインストールしたワードプレスの引っ越し

   
   お名前COMはSunOS系なので、標準コマンドがgnuでなかったりします。
   そのため、tarコマンドなどはgzファイルに対応していないです。
   
   それでも、シンボリックリンクを展開した状態でまとめるオプションhは有効です。
   

   % tar cvfh files/xx.tar ./example.com

   
   
   とhを指定することでシンボリックリンクを展開してtarファイルにすることができます。
   
   tar.gzにするためには、以下コマンドを打ち込みます。
   

   % gzip files/xx.tar 

   
   
   これでfilesフォルダにxx.tar.gzが作成されます。
   
   このファイルの中には幾つか不要なファイル、お名前COM特有の設定情報が含まれます。
   エックスサーバーで展開後、さくっと削除してください。
   
   不要ファイル・フォルダは以下です。
   kantan-cgi(ディレクトリごと削除)
   .php
   
   
   
   
   

   まとめ

   
   同じドメインのまま、お名前COMからエックスサーバーに引っ越しした際、はまった５つのポイントをできるだけわかりやすいよう説明しました。
   
   エックスサーバーでドメインを追加して、お名前comのドメインナビで他社を指定した際、すぐに反映されるパターンと、３時間くらい反映までに時間がかかるパターンがありました。
   
   引っ越しする際は、普段アクセスが少ない時間帯に引っ越しするのが良さそうです。
   
   お名前COMの共用サーバーでドメイン削除してないよね？！って疑問に思っている方もいるかもしれません。
   この状態でもエックスサーバーには引っ越しできています。
   あとあと問題があるかもしれませんが、削除してしまうと、実体ファイルも削除されてしまうので、過去の設定が見えなくなったりします。
   利便性をとってこのような手順にしています。
   
   
   技術的なポイントとしては、tarの--strip-componentsが結構使えるとおもっています。
   
   
   
   お名前COMのドメインとフォルダの関係は結構好きです。
   ドメイン、サブドメインがlsで一覧できるのがとってもよかったです。
   
   ロリポップのフォルダ構成はちょっと苦手です。
   初期ドメインの下に配置される感じです。
   
   エックスサーバーは、ドメイン毎にフォルダが設定されるのでドメイン視点ではシンプルです。
   
   自由度が高いのは、さくらサーバーです。自分で任意のフォルダ指定できちゃうので、ほんと奔放ですよ^^
   
   
   
   
   
   
   これからレンタルするなら、このサーバーひとつで満足できるはずです。
   性能・速度・サポートに満足しているからおすすめできます！
   
   
   
   月額900円(税抜)から、高速・多機能・高安定レンタルサーバー『エックスサーバー』
   
   
   
   
   
   
   
   

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

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


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

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


ワードプレス　＝＞　別サーバーのワードプレスだから問題ないでしょ？

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

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


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

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


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



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



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

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


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









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

ドメイン名を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>
↑↑↑↑↑↑　レスポンスボディ

簡単に説明すると、リクエスト、レスポンス、レスポンスボディの３つの情報がわかります。
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が１つしか使えなくても、ワードプレスは１つのMySQLに複数インストールできちゃいます。
マルチドメイン50個まで対応しているので、最大50個のサイトも作れますよ。

ライトプラン　詳細はこちら

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

データベースっていいですよね！
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では対応していないんです・・・

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

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


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


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

１データベース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でどハマりした件 修正方法のまとめ

ここまでの修正方法をまとめると３つの方法がありました。

1. １）sqlite3をやめて、MySQL＋FULLTEXTを活用する

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

2. ２）pdo_sqlite3を自前で用意する

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

3. ３）PDO＝＞new SQLite3()に変更する

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

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

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

最後に

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

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

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



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

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

最終的に移行できたので、その顛末をご報告しておきます。

1. １）sqlite3をやめて、MySQL＋FULLTEXTを活用する

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

   
   
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. ３）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^)／

ご存知の方も多いと思います。sqlite3には全文検索（フルテキスト検索）が備わっています。

とは言っても、テーブルを生成する際に呪文を唱えておく必要があるので、今あるテーブルをそのまま全文検索の対象にするのはできません。
CREATE VIRTUAL TABLE tbl USING fts3(content TEXT);

元テーブルをselectして、新しいVIRTUAL FT3/FT4テーブルを作ってインサートするだけでコピーできるので、悲観することはないです。INSERTはとっても速いですしね！

フルテキストにはバージョンがあったりします

先ほどの呪文を唱える際、USING fts3と記載しています。

fts3がバージョンを意味しています。

FTS1,2は非推奨、現在使ってはいけないレベルの代物です。
FTS3とFTS4が現在使えるバージョンで、SQLiteのマニュアルではFTS4を推奨しています。

FTS3とFTS4の違いは、マニュアルによると「FTS3 and FTS4 are nearly identical.」、ほぼ一緒らしいです。
FTS4は、 SQLite version 3.7.4 から利用可能になっています。
フルテキストクエリのパフォーマンスが向上し、追加オプションにも対応しているので、FTS4を利用するようにしておいた方が安心です。
FTS4の唯一のデメリットは、追加情報によってディスク容量が増える可能性があるところです。

この辺りは、事前の評価で許容範囲かどうかの確認ポイントですね！

そして、最新はFTS5です。

SQLite 3.9.0から使えるようになっています。コンパイル時の指定はOFFになっています。
手順を踏んでコンパイルする必要があります。

ここではせっかくなので、FTS3,FTS4,FTS5の３パターンで謎を究明してみます。

全文検索の謎

sqlite3の全文検索を使い始めてみると一致する単語なのに見つからないってことがよくあります。
くせがあるというんでしょうか、よっぽどLIKE '%単語%'の方が確実です。

でも、全文検索（フルテキスト検索）は、チョー高速です。使ってみるとわかると思います。
速度に関してはストレスフリーです。

なので、全文検索のくせをつかもうと調査しました。

SQLite3の全文検索は、sqlite3.dllやsqlite3.lib(so)などをコンパイルする際に指定する”コンパイルオプション”で挙動が変わります。

ですので、ご自身の環境を知っておくことも重要です。



調査に使ったテーブル

CREATE VIRTUAL TABLE tbl USING fts3(content1,content2,content3)

後日加筆します。

自宅のウィンドウズ10、Core i7、メモリ16GB、SSD搭載のPCは、とっても高性能です。だから24時間連続稼働させてMT4などのFX自動売買ソフト、GRC、コンパスなどの検索順位チェックツール、フォローマティックXY等々のソフトを動かすこともできちゃいますね。

当然出勤して、自宅にいない時にも、パソコンが稼いでくれる環境です。

ただ、とっても心配なことがあり、不安もあります。

普通のパソコンで２４時間連続稼働するリスク

自宅のパソコンはかなり高性能、ハイスペックです。HTTPDのサービスも提供できちゃいます。
でも、産業用PCではなく、普通のパソコンです。
そして、自宅だからこそ、不安になることがあります。

一番の不安は、住宅火災＝＞パソコンからの発火することです

パソコン発火事件

数世代前の自作したパソコンの話です、CPUが発火しました。


その時は、在宅でリビングでくつろいでいました。


「何かくさい」




異臭の原因を探したらPCでした。



すぐに電源ケーブルを引っこ抜いて、火災には至りませんでした。（自宅にいるタイミングで、本当に良かったとしみじみ思います）



当時はマザーボードにCPU FANを監視するようなものもなく、CPUクーラーのファンが止まって熱でやられた感じだったと記憶しています。






今時のマザーボードは、FANの動作を監視できます、ただ、事実として

パソコンは「勝手に燃える可能性を秘めている」ことを体感
しました

PCの発火対策は？

定期的に掃除する、燃え移る可能性のあるホコリを除去するのが目的です。
初夏からだんだん暑くなってくるのでエアコンも欠かせません。

今の所これだけです。不安はぬぐえません。


ところで自宅のパソコンの中掃除したことあります？


蓋を開けて、びっくりするほどホコリが溜まっています。


吸気ファンから吸い込んだホコリがケース下、マザーボードなどに付着しています。



割とさっぱりした性格なので、いつも掃除機で掃除しちゃってます。



ノートPCも定期的に掃除するとFANが生き返ります。
ただ、保証対象外になることが多いです、蓋を開けるとファン付近にたっぷりホコリが溜まっていたりします。

吸気ファン、排気ファン、CPUクーラーのファン、いずれも可動部があり、消耗品です。
チップセット、メモリは意外と発熱しますね。
Windows7,7Pro,8.1,8.1Pro,10,10Proなどは、クライアントOSという位置付けです。
１日８時間の利用用途を想定しています。
＝＞１週間に１回は再起動しておくと気持ち的に安心です。

自宅サーバは意外とコストが掛かっています

厳密な計算は気が滅入るのでしていませんが、電気代が一番コスト高です。

ベーシックなノートPC 45W
少し高性能なノートPC 65W
ゲーミングノートPC 130W
デスクトップPCは、180W、350W、600W、750Wなど様々あります。

月の電気代は、ワット数と利用時間で変動しますよね。ここでは、２４時間、１ヶ月稼働した場合の電気代をワット数別に求めています。W×時間x0.027の計算式で求めることができます。

1ヶ月の電気代	ワット数
874.8円程度	45W
1,263.6円程度	65W
1,944.0円程度	100W
2,916.0円程度	150W
3,888.0円程度	200W
5,832.0円程度	300W
7,776.0円程度	400W
9,720.0円程度	500W
11,664.0円程度	600W
13,608.0円程度	700W
15,552.0円程度	800W
17,496.0円程度	900W

この計算は常にCPUがぶんまわっているような環境での想定です。実際には、CPUがアイドルになっている時間の方が多いかと思います。500WのPCで、平均すると100W前後に落ち着くのではないでしょうか。

デスクトップPCの場合、ディスプレイの消費電力も増えることになります。

24時間連続稼働のパソコンの電気代は、875円以上かかることがわかったかと思います。

電気代以外にも、不定期でSSD、HDD、ファンなどの消耗品の交換費用が発生する可能性も忘れてはいけませんね。

24時間連続稼働パソコンの悩みはコレで解決！？

パソコンで24時間連続稼働は、住宅火災を引き起こす不安を感じてしまいます。最近のWindows7以降、スリープから勝手に復帰して、スリープしない起動状態を維持してしまうこともあるので、意図せず連続稼働になってしまうこともあります。

この不安を解消するには、まずはスリープではなく、シャットダウンすることで意図せず連続稼働になってしまうことを防ぐことができます。

連続稼働させる場合、信頼性の高いサーバー用途のパーツで構成するのも一つの手です。ただ、データセンターなどは、夏でも寒いくらいに冷えています。温度管理に気を使う必要があるのは変わりません。

24時間監視できたらいいんですが、実際のところ人がいないタイミングもあるので、不安はぬぐえません。

根本的に不安を解消するには、連続稼働させるPC(発熱物質)を自宅に置かないことです。（と最近気づきました）

ウェブサイトを公開する目的で24時間連続稼働させている

レンタルサーバーに環境を移すことで不安は解消できます。
nginx＋PHP/Perl、MySQLの標準的な環境なら対応するレンタルサーバーは数多くあります。

共用レンタルサーバーのデメリット
・管理者権限がない。管理者権限が必要なものは一切入れることはできません。
・mod_rewriteは大抵利用できる(Wordpressを動かすために必須だから）、共用サーバーの場合、利用できないApacheのモジュールがあることに注意が必要。
・PHP/Perlのバージョンに注意が必要。deprecatedになっているPHPが標準というレンタルサーバもある。PHP7に対応したレンタルサーバーを選ぶのが確実。
・MySQLのバージョンは古い。FULL TEXT検索に対応していないMySQLを使っているレンタルサーバーが多い。
・MySQLのデータベースサイズにも注意が必要。大規模なデータベースを想定していません。500MB以上のデータベースは作れないこともあります。
・SQLite3のバージョンは古い。FTS3、FTS4、FTS5に対応していないバージョンの場合が多い。

共用タイプのレンタルサーバーのおすすめは高速でデメリットが少ないエックスサーバーです。

私も愛用しています。たくさんサイト立ち上げていますが遅いって感じたことはありません。（あくまで個人の感覚です）

ストレージ用途

Windowsのファイル共有、macのファイル共有、少し高機能なNAS、2TB、3TBのディスクは割安で購入できるのでストレージ用途としてパソコンを使っている場合、ハードディスクが発火するとか聞いたことありませんが、CPUを内蔵したパソコンやNASは、信頼性の高いものをチョイスしておきたいですよね。

光回線をご利用ならストレージもGoogle Drive、iCloud Drive、OneDriveなどメインに使うOSを軸にクラウドストレージにすることで安く済むことがあります。また、共用サーバーの中にはWebDAVを使えるところもあるので、自分専用のプライベートクラウドもできちゃいます。

難点は、一気にダウンロードする、アップロードするような操作に時間がかかります。ネットワークだとどうしても遅いです。
ただ、２４時間いつでもアクセスできる、外出時にもアクセスできる、ハードウェア故障の心配がないというメリットがあります。

セキュリティがしっかりしているビジネス向けのクラウドストレージ
クラウド型高速オンラインストレージ XDRIVE 1TB月額630円〜
大塚商会 どこでもキャビネット
50GB 月額3000円〜

24時間ずっと動かしたいWindowsプログラム

常時稼働させたいWindowsプログラムやアプリがあるとどうしても立ち上げっぱなしにしておく必要があります。

ウィンドウズで24時間連続稼働するならVPSがあります。
Windowsがプリンストールされたレンタルサーバーを契約できます。
つまり自宅サーバーの代わりにウィンドウズのソフトを24時間連続稼働させることができます。それがVPSです。以下で簡単な比較をしています。コストで考えると短期なら断然VPS、長期なら信頼性の高いPCの方が安く済むかと思われます。

型落ちCPUでお値打ちPCなら5万円ぐらいで調達できます。性能・コスパNo1のXserver for Windowsを比較した表を作成しています。これから導き出せる損益分岐点は1年間の利用ならXserver for Windowsの方が費用安いことがわかります。2年、3年と利用する場合自己所有の方が有利です。メンテナンス費用（ファンやストレージの劣化による交換費用）や光熱費の高騰などは考慮していません。

• 【Xserver for WIndows】12ヶ月 50,160円(月額4,180円)はXserver for WIndowsの4GBプラン（vCPU4コア、メモリ4GB、SSD100GB）を12ヶ月契約した費用です。
  
• 【型落ちPC】電気代21,024円は型落ちPCの消費電力を100Wと仮定、100Wの電気代は1時間約2.4円、24時間連続運転を1年間した場合の電気代です。
  
• ライセンス料等【Xserver for WIndows】年間11,880円(990円/月)は、リモートデスクトップ SALの費用です。
  
• Xserver for Windowsはキャンペーンが開催されたりします。このタイミングで契約できるとさらに費用を抑制できます。
  

１秒でわかるVPS！

仮想プライベートサーバーの略がVPS、利用イメージはVirtualPCという感じです。
インターネット上で24時間つけっぱなしにできるWindowsパソコンを1台レンタルするという感じです。

Microsoft Azureよりいいの？VPSは月額基準で安心です。Microsoft Azureは従量課金のため使いっぱなしは怖いです。

VPSで向かない用途

専用のボードだったり、外部機器が必要な場合、VPSでは使えません。
自宅サーバーの用途、例えば地デジ録画サーバーとかの場合は、地デジを見るために別途チューナー（USB/専用ボード）が必要なので向きません。

Windows10PCをレンタルする感じなの？

レンタルするのは、Windows7, Windows8、Windows10ではなく、Windows Serverです。

以下にWindows（Windows Server)が利用できるVPSの2コアSSDの最安プラン一覧をまとめています。


VPSでWindowsはライセンスの関係、最小スペックが高いためです。Windows以外でも大丈夫なら安価に借りることができるLinux系のVPSがあります。
Linux系のVPSはこちら「格安（千円未満）のSSDプランがあるVPS一覧とプラン【さくらVPS・ConoHa VPS・mixhost VPS】比較」の記事にまとめています。

wordpressは、とっても簡単に設置できて、プラグインも豊富だから見栄え豊かで、キレイなサイトが誰でも作れてしまう強い味方です。

こんな高機能なプログラムが無料で使えるのでとっても幸せです。


PHPが動けば、無料レンタルサーバー、有料レンタルサーバーどちらでもワードプレスは使えます。
ただ、MySQL（データベース）がない場合、sqliteというファイル型のデータベースを使うように設定変更する必要があるので、できればMySQLが使えるレンタルサーバーを選ぶのが得策です。

誰でも使えるように高機能なので、ワードプレスで記事を書いたり、テーマ、アップデート、設定を変えたりするには、「ログイン」する仕組みです。

ワードプレスを使うデメリットのひとつとして、
ログインするためのパス、管理画面のパスなどがバレていることです。
これは、みんなが使っているので、管理側のURLなどの推測が知れ渡っています。

例えば、ドメイン名/wp-login.phpというのはワードプレスを使ったサイトでは共通です。


推測可能なユーザー名、例えば古いワードプレスのデフォルトだったadminとか、簡単パスワードを設定してしまうと乗っ取られてしまう可能性が高まります。

ユーザー名、パスワードともに自由に設定できる仕組みが備わっています。
できる限りパスワードは難しくしておきましょう。
また、ユーザー名はデフォルトではそのまま記事投稿者として表示されます。

ユーザー一覧からニックネームの修正ができるので、ログインするユーザー名等は異なる名称にしておきましょう！

wordpress wp-login.phpのガード方法

「ドメイン名/wp-login.phpというのはワードプレスを使ったサイトでは共通」だから、規則が決まっています、だから攻撃されやすいです。

「All In One WP Security & Firewall」、「Login LockDown」など、ワードプレスのセキュリティを向上する定番プラグインで対処することもできます。


ただ、ワードプレス本体、テーマ、も同じですが、プラグインも常に最新を保つようにしましょう。
大抵のアップデートには、不具合のFix、セキュリティホールの対応などが含まれます。

プラグインは、結局新たな機能を持ったプログラムをサイトで動かすことになります。
そのため、総合的なスピードが落ちたりするリスクもあります。

googleの2段階認証でログインで保護する

「Google Authenticator」、２年前が最終更新日のプラグインを使う方法です。
信頼のあるGoogleの2段階認証を無料で使える方法なので、プラグイン自体は古くても問題ありません。

SEOで有名な鈴木さんが解説してくれる「Google AuthenticatorプラグインでWordPressブログを2段階認証に設定する方法」が信頼できます。
https://www.suzukikenichi.com/blog/how-to-set-2-step-verification-for-wordpress/

wp-login.phpをパスワードで保護する

プラグインに頼らないで、アタックされる入り口のwp-loginをパスワードで保護しちゃいましょう。
設定は、２つ必要です。

１）保護するユーザ名、パスワードを作る

パスワードファイルは、webアクセスされない場所に作りましょう。

ロリポップの場合、web/フォルダがhttpアクセスの対象なので、webフォルダにログインしている状態なら一つ上のフォルダに作る、というような感じです。
htpasswd -c ../htpass user1
New password:
Re-type new password:
Adding password for user user1


上で作ったファイルを見る場合は、catというコマンドが使えます。
cat ../htpass
user1:$apr1$tJdfeg1t$r5j.mWqaJQIvKu7LAwgR7.

ユーザーを削除したい場合、-Dオプションを指定します。
htpasswd -D ../htpass user1

２）wp-login.phpを.htaccessで保護

wordpressをインストールしたフォルダにある.htaccessに以下を追加します。

# END WordPress
<Files wp-login.php>
AuthType basic
AuthName "(A)"
AuthUserFile (B)
Require valid-user
</Files>

(A)はブラウザによっては、メッセージとして表示されます。


(B)は１）で作成したパスワードファイルをフルパスで指定します


wp-login.phpまたは/wp-adminにアクセスするとダイアログが表示されます。Chromeは、AuthNameは表示されません。


wp-login.phpまたは/wp-adminにアクセスするとダイアログが表示されます。Safariは、AuthNameが表示されます。privateで設定しました。
(ちなみに日本語(UTF-8)で設定しましたが、見事文字化けしました）

この方法のメリット

一般的な保護の方法を見ると、/wp-admin/を保護する方式が多いですが、ここのフォルダには一般ユーザーもアクセスしないといけないファイル（admin-ajax.php）が存在します。
この方法であれば、直接wp-login.phpのみを保護するので、簡単で済みます。

この方法のデメリット

• /wp-admin/フォルダ下に、独自のテキストファイルとかある場合、ガードできません

wp-login.phpをパスワードで保護する 固定IPでガード

先ほどのガード方法は、htpasswdを使ったガードでした。
もし、あなたが固定IPを所有しているなら、固定IPでガードした方が簡単で安全です。

# END WordPress
<Files wp-login.php>
order deny,allow
deny from all
allow from IPアドレス(999.999.999.999)
</Files>

プロバイダ、モバイル回線、いづれも通常は、固定IPではなく、プライベートIPと呼ばれるものです。
この方法は、動的に変化しない静的なIPでやる方が安全です。

プライベートIPの場合、場所によってIPが変わったり、日付によってIPアドレスが変わったりします。
そのため、突然ログインできなくなる不確定要素を背負うことになります。
（プライベートIPでも日々.htaccessファイルを見直すことで運用は可能です）


プロバイダーによっては、固定IPオプションがあります。
固定IPが安い＝＞http://asahi-net.jp/service/option/fixedip/

また、MyIPというサービスを使うと固定IPアドレスが提供されないプロバイダやネットワーク環境からでも、グローバル固定IPアドレス（静的IPアドレス）が利用できます。



モバイルルーターや使わなくなったドコモ回線が使えるスマホをお持ちなら固定IPのSIMがあります。

あとがき

wordpressは、PHPという言語で書かれたプログラムです。
プログラムって、不具合を全部なくすって本当に難しいことなんです。

wordpressもこのソフトウェアの呪縛から逃れられないので、定期的にアップデートを確認して、最新版が出ていたらアップデートする運用を心がけたいですね！

是非とも運用する前に、
WordPress公式のドキュメント WordPress の安全性を高める一読されることをオススメします。
http://wpdocs.osdn.jp/WordPress_%E3%81%AE%E5%AE%89%E5%85%A8%E6%80%A7%E3%82%92%E9%AB%98%E3%82%81%E3%82%8B

ロリポップ！スタンダードプランで簡単インストールでワードプレスを設置してみました。
簡単インストールは約9秒で終わりました。（新規にデータベースを作成するパターンです）

インストールされたWordPressのバージョンは、4.4.2です。

PHPは5.6（モジュール版）です。


デフォルトでインストールされているワードプレスのプラグインは、

• Akismet
• Hello Dolly
• Ptengine - Real time web analytics and Heatmap
• SiteGuard WP Plugin
• WP Multibyte Patch

でした。全て非アクティブ状態で、手動で有効化する必要があります。


デフォルトで有効なテーマは、Twenty Sixteen、Version: 1.1です。

デフォルトで登録されている記事は、Hello world!、サンプルページの２つだけです。


Google PageSpeedInsightsの評価を確認しながら、改善していきます。
＝＞ https://developers.google.com/speed/pagespeed/insights/?url=

モバイルと、パソコン２つの評価が確認できます。モバイルファーストの視点で、モバイルの評価のみ記載します。（モバイル70/100、パソコン84/100でモバイルの方が評価悪いです）

多くの方が利用している共用レンタルサーバーなので、重い時もあれば、軽い時もあります。契約した時点で選ばれるサーバーで当たり、ハズレもあるかもしれません。
本来であれば、時間をずらしながら、定期的にサンプルを収集し、多くのデータを集めて分析しないとブレます。今回掲載している内容は、時間要素、試行回数要素、ともに少ないです。なので、参考速度としてみてください。

また、モジュール版PHPとCGI版PHPの違いは、単一アクセスしている限り、ほぼ同じようなスピード、評価の傾向です。今回の評価では、モジュール版PHPだからすごい！という結果は出ていません、ただモジュール版PHPはCPUの専有率が低いのが大きな特徴です。複数のワードプレスをインストールして運用する、同時にアクセスするユーザーが多い場合にメリットがあります。

結論　ロリポップ！スタンダードのモジュール版は何もしなくても速いよ!

先に結論です。ロリポップ！スタンダード＋ワードプレスを使った評価をしてみました。
mod_deflateはデフォルトで有効、プラグインなしのデフォルト状態でも１秒程度(chrome)で表示ができます。


PageSpeedInsightsの指摘事項を改善する施策を行いましたが、速度はほとんど改善しません。お勧めできるプラグインを厳選していますので、安定した運用に貢献できると思っています。


３秒や、５秒かかるサーバーもあったりする中で、触っている中では常に１秒前後のロリポップ！スタンダードは優秀なレンタルサーバーの部類です。
ワンコインで100個のマルチドメイン、30個のデータベース、モジュール版PHPならロリポップ！スタンダードプランは検討の価値はあります。特徴スペックからは、
複数のワードプレスサイトを１つのレンタルサーバーで動かしたい方にオススメできます。

国内最大級の個人向けレンタルサーバー『ロリポップ！レンタルサーバー』は、

月額100円（税抜）〜で容量最大400GB！しかも安いだけじゃなく
大人気WordPressの簡単インストール/ウェブメーラーなど
機能も満載！共有/独自SSLもバッチリ対応でセキュリティ対策も万全！

もちろん、オンラインマニュアルやライブチャットなど、

充実したサポートで初心者の方でも安心です。

無料のお試し期間が10日間ありますので、

まずはお気軽にご利用してみてくださいね！


▼ロリポップ！レンタルサーバーはこちら

1秒という速度に満足できない方は、PageSpeedInsightsで調べた中では、XServerが安定して速かったです。
価格はロリポップ！スタンダードより高いです。

モバイル（初期）

簡単インストール（WordPress)直後の結果は、「７２点」でした。

指摘された事項を徹底列挙です！修正事項１件、修正考慮事項５件ありました。

• 修正が必要 「スクロールせずに見えるコンテンツのレンダリングをブロックしている JavaScript/CSS を排除する」
• 修正を考慮:圧縮を有効にする
• 修正を考慮:サーバーの応答時間を短縮する(0.42秒でした）
• 修正を考慮:ブラウザのキャッシュを活用する
• 修正を考慮:CSS を縮小する
• 修正を考慮:JavaScript を縮小する

合格しているのは、４個のルールで、リンク先ページのリダイレクトを使用しない、HTML を縮小する、画像を最適化する、表示可能コンテンツの優先順位を決定するです。

ロリポップ！のサーバーはデフォルトで、gzip圧縮が有効になっています（mod_deflate）
圧縮を有効にする指摘は、「twentysixteen/genericons/Genericons.svg を圧縮すると 51.6 KB（68%）削減できます。」１件です。html、css、javascriptなどはデフォルトで有効です、一部拡張子で漏れているものがあるようです。

テーマをStinger7に変更

Stinger7に変更直後の結果は、「７２点」でした。指摘事項もテーマが変わったことで変化しました。

• 修正が必要 「スクロールせずに見えるコンテンツのレンダリングをブロックしている JavaScript/CSS を排除する」
• 修正を考慮:サーバーの応答時間を短縮する(0.32秒でした）
• 修正を考慮:ブラウザのキャッシュを活用する
• 修正を考慮:CSS を縮小する
• 修正を考慮:JavaScript を縮小する
• 修正を考慮:HTML を縮小する

合格しているのは、４個のルールで、リンク先ページのリダイレクトを使用しない、圧縮を有効にする、画像を最適化する、表示可能コンテンツの優先順位を決定するです。


chromeの検証ツールでブラウザが表示するまでの時間を確認、比較したスナップショットです。
Documentの読み込みで386ms、表示に必要なコンテンツの読み込み完了に1.02秒の結果がわかります。

アクセスして、1秒で表示できる感じなので、これ以上手を加えなくても満足できる性能です^^

mod_expiresでブラウザのキャッシュを活用するが合格します

ロリポップ! のレンタルサーバーは、mod_expiresが使えます。
.htaccessに以下を追記するとすべてのファイルで１週間のキャッシュが効きます、２度目のコンテンツの読み込み完了は851msec（0.8秒）と高速です。

<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresDefault "access plus 1 weeks"
</IfModuel>

ブラウザのキャッシュを活用する指摘が合格します、ブラウザ上は、「304 Not Modified」となり、キャッシュされた情報で表示が高速になっていることが確認できます。
ただ、画像、css、HTML、javascriptすべて１週間キャッシュされてしまうと、画像の差し替え、スクリプトの修正などで見た人によっては1週間のタイムラグが生まれてしまいます。

こういった場合には、MIMEタイプを個別に指定する方法も使えます。
css/javascript/pngは1日、それ以外は1週間の設定例

<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresDefault "access plus 1 weeks"

 ExpiresByType text/css "access plus 1 days"
 ExpiresByType text/javascript "access plus 1 days"
 ExpiresByType image/png "access plus 1 days"
</IfModuel>

Exipresの期間を短めにすると、「ブラウザのキャッシュを活用する」は不合格になります。
はじめはよく分からないと思うので、運用が安定してから、設定することのがオススメです。

mod_expiresで使える構文＝＞https://httpd.apache.org/docs/2.2/ja/mod/mod_expires.html
拡張子とMIME typeの一覧がすっごい詳しく載っています。
＝＞http://www.iana.org/assignments/media-types/media-types.xhtml

Autoptimize 2.0.0 プラグインでCSS/JavaScript/HTMLを縮小！

Autoptimize 2.0.0 プラグインで指摘事項は減りました、結果は、「７３点」でした。
Autoptimizeによって、CSSとHTMLの縮小指摘が合格しました。

• 修正が必要 「スクロールせずに見えるコンテンツのレンダリングをブロックしている JavaScript/CSS を排除する」
• 修正を考慮:サーバーの応答時間を短縮する(0.27秒でした）
• 修正を考慮:ブラウザのキャッシュを活用する
• 修正を考慮:CSS を縮小する
• 修正を考慮:JavaScript を縮小する
• 修正を考慮:HTML を縮小する

合格しているのは、6個のルールで、リンク先ページのリダイレクトを使用しない、CSSを縮小する、HTMLを縮小する、圧縮を有効にする、画像を最適化する、表示可能コンテンツの優先順位を決定するです。

Autoptimizeの設定は、「Optimize HTML Code レ」、「Optimize JavaScript Code　レ」、「CSS Options　レ」にしています。
そのため、「修正を考慮:JavaScript を縮小する」も消える予定でしたが、Stinger7ではてなブックマークへのリンクで、外部スクリプトb.st-hatena.com/js/bookmark_button.jsを必要としています。
Autoptimizeプラグインが対象としているのは、内部にあるファイルです、hatena.comは外部のJavaScriptファイルなので、この指摘は一個人でどうにかできるものではないので、これ以上こだわりません。

ブラウザでの速度

chromeの検証ツールでiPhone6ブラウザが表示するまでの時間は、Autoptimizeで減るどころか、増えました。
Documentの読み込みで466ms、表示に必要なコンテンツの読み込み完了に1.09秒でした。

javascript/cssを正しく圧縮する

Wordpressのデフォルト状態では、スクリプトの後ろに?ver=x.x.xというようなバージョンパラメータが付加されてしまいます。
ロリポップ！デフォルトで設定されているmod_deflateがどのような設定になっているかはわかっていませんが、通常よく見かけるmod_deflateの設定例だとxxx.css?ver=とかxxx.js?ver=となっていると正しくCSSファイル、Javascriptファイルとして認識できずに圧縮できていなかったりします。

１年前の更新で、少し古い「Remove Query Strings From Static Resources 1.3」を適用します。
Autoptimize 2.0.0 プラグインは停止させています、テーマはStinger7です。
結果は、「７０点」でした。

• 修正が必要 「スクロールせずに見えるコンテンツのレンダリングをブロックしている JavaScript/CSS を排除する」
• 修正を考慮:サーバーの応答時間を短縮する(0.36秒でした）
• 修正を考慮:ブラウザのキャッシュを活用する
• 修正を考慮:CSS を縮小する
• 修正を考慮:JavaScript を縮小する
• 修正を考慮:HTML を縮小する

合格しているのは、4個のルールで、リンク先ページのリダイレクトを使用しない、圧縮を有効にする、画像を最適化する、表示可能コンテンツの優先順位を決定するです。

ブラウザでの速度

chromeの検証ツールでiPhone6ブラウザが表示するまでの時間は、
Documentの読み込みで398ms、表示に必要なコンテンツの読み込み完了に0.9秒(989ms)でした。

Remove Query Strings From Static Resourcesではなくても、直接functions.phpを編集することでも対応できます。テーマの更新で修正が必要などのデメリットはあります。

AutoptimizeとRemove Query Strings From Static Resourcesの同時利用

結果は、「７１点」でした。

• 修正が必要 「スクロールせずに見えるコンテンツのレンダリングをブロックしている JavaScript/CSS を排除する」
• 修正を考慮:サーバーの応答時間を短縮する(0.45秒でした）
• 修正を考慮:ブラウザのキャッシュを活用する
• 修正を考慮:CSS を縮小する
• 修正を考慮:JavaScript を縮小する
• 修正を考慮:HTML を縮小する

合格しているのは、6個のルールで、リンク先ページのリダイレクトを使用しない、CSSを縮小する、HTMLを縮小する、圧縮を有効にする、画像を最適化する、表示可能コンテンツの優先順位を決定するです。

ブラウザでの速度

chromeの検証ツールでiPhone6ブラウザが表示するまでの時間は、
Documentの読み込みで391ms、表示に必要なコンテンツの読み込み完了に1.01秒でした。

まとめ：ロリポップ! PageSpeedInsights徹底チェック

• サーバの応答は0.2秒から0.5秒の間です。
• アクセスから表示するまでの時間は1秒前後です(Chrome調べ）
• ロリポップ！デフォルトで圧縮が有効になっています
• ロリポップ！mod_expiresが使えます

デフォルトで圧縮が有効なので、「Remove Query Strings From Static Resources」プラグインを適用するだけで、css/javascriptが圧縮対象にできます。
「Autoptimize」プラグインを使うと、縮小系の指摘を合格に導けます。

あとがき

PageSpeedInsightsとChromeの検証ツールの両方で確認してきました。
実際にユーザーが使っている視点で見ると、ユーザー環境に近い、Chrome検証ツールのLoad時間の方を重視したくなります。

PageSpeedInsightsの速度が出なくても、Chrome検証ツールで確認すると1秒未満だったりします。

「スクロールせずに見えるコンテンツのレンダリングをブロックしている JavaScript/CSS を排除する」修正項目は全く対応していなくても１秒未満です。

デフォルトで十分速いと何もしなくてもいい！と感じる評価でした^^

ロリポップ！のスタンダードプラン、エンタープライズプランはsshでログインができます。

この記事では、スタンダードプランのsshで何ができるのか、出来ることをまとめています。

ロリポップ！スタンダード SSHで出来ること

ロリポップ！スタンダードプランで契約したサーバにSSHログインし、確認してみました。

bashのバージョンは、「GNU bash, version 4.1.2(1)-release (x86_64-redhat-linux-gnu)」、バージョンから察するにlinux redhatの64ビット版のサーバーのようです。
本来であれば、uname等の結果でわかる情報ですが、ロリポップ！のサーバーはかなり厳格にコマンドを選定しています。
また、通常たくさんのライブラリが見える/usr/lib /libなどアクセス権が適切に設定され、ほとんど一般ユーザーから見えなくなっています。

SSHログインでできることは、アップロードしたファイルの展開、ファイル移動、ファイル編集等のファイル操作、phpコマンドの動作確認、gitコマンド、subversionコマンド、sqlite3データベースのメンテナンスなどです。emacsやnanoといったエディタがデフォルトで利用可能です。
wgetコマンドも使えます。

コマンドは厳選されていますが、フォルダに対する操作はある程度自由が与えられています。
~/.sshフォルダを自分で作って、SSHパスワードなしログイン可能です。


できることより、出来ないことを見た方が分かりやすいかもしれません、

• gccコマンドを使ったコンパイルはできません
  
• unameコマンド、pingコマンドは使えません、見つかりませんでした
  

ロリポップ！のスタンダードプランで使えるSSHは、
普通にWEBサイト、PHPなサイト、rubyなサイトを構築する用途に最適です！

bashを使ったスクリプト、PHP/Ruby/Python/Perlを使ったスクリプトをクーロンで動かせます

SSHログインで使えるコマンド

• /usr/bin

  b2m dig emacs expr gem grep-changelog id mysql od pr python2.7 sabcmd sqlite3 svnadmin tac tty vim xsltproc
  clear dir emacs-23.1 find git groups install mysqldump paste printenv rcs-checkin scp ssh svndumpfilter tail unexpand wc yes
  comm dircolors emacsclient fmt git-receive-pack gunzip join nano perl printf readlink seq ssh-keygen svnlook tee uniq wget zip
  convert dirname env fold git-shell head less nkf perldoc ptx rsync sftp stat svnserve test unzip which
  csplit du etags.emacs ftp git-upload-archive htdigest make nl php python ruby sha1sum sum svnsync tr urlgrabber whoami
  diff ebrowse expand gctags git-upload-pack htpasswd md5sum nslookup php5 python2 ruby-1.9.3 split svn svnversion tsort vdir xargs

• /bin

  awk bash chmod csh date egrep false find grep gzip link ls mailx more nano pwd rm sed sleep stty tcsh traceroute uname vi zsh
  basename cat cp cut echo env fgrep gawk gunzip hostname ln mail mkdir mv nice readlink rmdir sh sort tar touch true unlink zcat

  
  

/usr/local/binにはphp/ruby/python/perlがあります。

ロリポップ!スタンダード SSHログイン有効からログインするまでの方法

ロリポップ!スタンダード SSHログインはデフォルトで無効です。
管理画面からSSHを有効にする手順を踏みます。（と言っても公式のマニュアルを見なくても、ボタンひとつで有効にできます）

sshのポート番号は、デフォルトではありませんでした、そのため、sshコマンドの引数を追加してポートを指定する必要があります。

スタンダードプラン ユーザー専用ページ、WEBツール＝＞SSHでSSHを有効にします。

SSHログインするSSHコマンド引数はコレです

ローカルPC(ここではMacという前提で説明しています。)
$ ssh -p ポート番号 アカウント@サーバー

パスワードが聞かれます。ユーザー専用ページに表示されているパスワードをコピペしてください。

これでロリポップ!スタンダード SSHログインできます。

ロリポップ!スタンダード SSHパスワードなしでログインする方法

ローカルPC(ここではMacという前提で説明しています。)でid_dsa.pubが存在するか確認します。
$ ls ~/.ssh/

id_dsa.pubがない場合は作ります。

$ ssh-keygen -t dsa
これで、~/.ssh/id_dsa.pubファイルが作られています。

サーバー名、アカウントが長いので省略名でログインする設定をします

ローカルPCでの作業です。
$ vi ~/.ssh/config
以下を追記します。

Host 省略名(半角で入力）
 HostName ロリポップ！ユーザー専用ページ SSHのサーバー
 User  ロリポップ！ユーザー専用ページ SSHのアカウント
 Port  接続ポート

ここでは、以下で設定した仮定で進めます。

Host lolipop
 HostName sshxxx.xxxx.jp
 User  xxx.jp-yyy
 Port   9999

id_dsa.pubをロリポップ!スタンダードサーバーに転送します。

ローカルPCのid_dsa.pubをロリポップ！スタンダードサーバーに仮転送します。
$ scp ~/.ssh/id_dsa_pub lolipop:~/.
(パスワードを入力します）

仮転送したid_dsa.pubを確定させます

ロリポップ!スタンダードサーバーにsshログインしてください。
(ローカルPC) $ ssh lolipop
(パスワード入力します）

(ロリポップ!）$ mkdir ~/.ssh
(ロリポップ!）$ chmod 700 ~/.ssh
(ロリポップ!）$ mv ~/id_dsa.pub ~/.ssh/authorized_keys
(ロリポップ!）$ chmod 600 ~/.ssh/authorized_keys

シェルは省略ワードなど使えますが、ここではフルで書いています。知っている方は!$とか使ってください。

この状態で、ローカルPC側で新たにterminal(Shell)を起動して、パスワードなしで入力できることを確認します。
$ ssh lolipop

設定ミスがなければ、パスワードなしでそのままロリポップ！にログインできます。