1. ドメインのDNS設定
   DNSの設定はいつでもできますが、反映されるのに時間がかかるので、先にやっておくと良いと思います。
   任意のドメインを取得し、DNS設定をCoreserverに向けます。
   value-domainであれば、「DNS設定」の欄を以下のようにします。

   a @ xxx.xxx.xxx.xxx

   ipアドレスは借りているサーバーに合わせて読み替えてください。@はwwwなどのサブドメインなしを示します。これで、example.comへ接続する場合、value-domainのDNSサーバーがレンタルサーバーのipアドレスを示すことができ、アクセス可能になります。

2. ドメインウェブの設定
   DNSで振り分けられたアクセスをレンタルサーバーで処理するための設定です。ここからはCoresreverの管理画面で行います。「ドメインウェブ」のsub1から続く欄の左側にexample.comと入力し、「ドメイン設定」ボタンを押します。このとき、先のDNS設定が正しいかどうかチェックされますが、設定から数分では反映されないことが多いので、間違いなければ「すべてのドメインでAレコードのチェックを行わない(強制設定) 」にチェックを入れてボタンを押します。
   設定すると、example.comというディレクトリがpublic_html下に作成されます。
   このexample.comというディレクトリに置いたファイルがexample.comにアクセスすることで表示されます。
3. データベースの設定
   Wordpressで使用するMySQLのデータベースを作ります。同じくCoreserverの管理画面から、「データベース」で2つ目以降の空欄にデータベース名(exampleなど)、パスワードを適宜設定し、文字コードはUNICODEとし、後でわかりやすくするために、備考欄に「example.com、wordpress用」などとしておきます。
4. sshのアクセス設定
   sshというコマンドラインでアクセスするため、「ホスト情報登録」メニューからssh登録ボタンを押します。Coreserverではセキュリティ対策のため、登録したホスト以外からはssh接続できないようになっています。
5. ssh接続
   RLoginなどのターミナルソフトでログインします。
   （詳細省略）
6. wordpressダウンロード
   ログイン直後は、ユーザーのホームディレクトリにカレントディレクトリがあるので、example.comに移動します。

   cd public_html
   cd example.com
   

   wgetでダウンロードします。ダウンロード先はwordpressのホームページのzipファイルのアドレスをコピーします。httpsの接続でホスト名の問題が出ることがあるので、–no-check-certificateオプションを付けます。

    wget https://jp.wordpress.org/wordpress-4.7.2-ja.zip --no-check-certificate
   

7. 圧縮展開
   zipファイルを展開します。

   unzip wordpress-4.7.2-ja.zip

   lsコマンドなどで確認しますが、wordpressディレクトリが作成され、必要なファイルが展開されます。

あとはブラウザからhttp://example.com/wordpress/にアクセスし、データベースなどの設定をウィザードに従って入力するだけで、設定は終わりです。

ローカルでzipファイルを展開してアップロードしても同じことができますが、細かいファイルがたくさんあるので、こちらのほうが、確実に処理できます。

結論から書くと、PHPのバージョンを5.4から5.6に変更していたことと、それに対応していないプラグインがあったことが原因です。ログインができないだけで、ページは一応表示できます。

環境は以下の通りです。

Coreserver(CORE-A)
Wordpress 4.5.3 （4.4.4でも同様）

CoreserverはドメインごとにPHPのバーションがコントロールパネルで変更できるので、一旦はログイン可能なバージョンに変更します。今回は5.5と5.6でログインできませんでした。また、5.4と7.0ではログインできました。

必要なバージョンアップを行い、一度バージョンを変えて試してみます。それでもログイン画面が表示されない場合は、プラグインを全てOFFにすると、おそらくログインできるはずです。

あとは、プラグインの変更や更新をした後、PHPのバージョンを戻してみて試します。

今回原因となったプラグインは、ZenCacheでした。プラグインの名称が変わり（Comet Cache）、ZenCacheそのものは更新が停止しています。

表示したいディレクトリに「.user.ini」を設置します。

display_errors = On
error_reporting = E_ALL & ~E_NOTICE

error_reportingの値は適宜変更して下さい。設置したディレクトリとその下層ディレクトリで有効です。
coreserverのPHPはここ数年で変更がありましたので、過去の対応とは異なることがあります。これからも変化があるかもしれませんので、できれば公式の情報をあたることをオススメします。

コースによって異なるところをピックアップしました。容量、値段は見事にお互いを補完するラインナップです。初期費用も異なりますが、現在、Coreserverは初期費用無料です。
他にも後発のValue-Serverは、PHPがモジュール版でセーフモードとともに通常モードでも利用できること、PHPをキャッシュし、高速表示できることやデータベースのバージョンが新しいといった点で有利です。

サーバーのハードウェア仕様もValue-Serverの方が強力ですが、ひとつのサーバーに詰め込まれるアカウントとの兼ね合いになりますので、使ってみないとわからない部分でもあります。

無料

共用サーバなので、仕方の無いことですが、改善を考えるとサーバーの移転が望ましいところです。幸い、CORESERVERは無料お試し期間を利用することで、比較的簡単にサーバー間の移動ができます。

参考にしたサイトは「CORESERVERのサーバー移動（作業手順メモ） | 普通のサラリーマンのiPhone日記」です。

ほとんどは上記のサイトに従って行いました。ひとつ注意ですが、サーバー間でコピーを行った場合、PhpMyAdminもコピーされます。従って、Logフォルダのパスワードの設定も引き継がれますので、管理画面、データベースの「ページ入室の際はログ閲覧画面の認証パスワード」も旧サーバの設定がコピーされます。新しいサーバーの管理画面にあるパスワードは使えません。この設定は/public_html/log/.htpasswdに記述されていますので、気になる場合はこれを変更します。.htpasswdの生成には管理メニューのツールの使用が便利です。

データベースのコピーは一括でできませんので、一つ一つ設定する必要がありますが、30分ほどで移転が完了しました。

同じプランのサーバー間の移転はもちろん、サーバーのアップグレードや統合などにも使えます。

WordPressのプラグインであるGoogle XML Sitemapsでサイトマップファイルを作成するときも、新規にファイルを作ることができずにエラーが出ます。

エラーは「書き込みができませんでした」といった内容です。

There was a problem writing your sitemap file. Make sure the file exists and is writable. Learn more
There was a problem writing your zipped sitemap file. Make sure the file exists and is writable. Learn more

解決方法は、アクセス権を設定したからのファイルを作成することです。

通常必要なファイルはsitemap.xmlとsitemap.xml.gzです。
このファイルをwordpressフォルダ、またはインストールしたフォルダとは別フォルダにホームページを設定している場合はそのフォルダに作成します。内容は0バイトでOKです。パーミッションは666に設定します。

以上を行ったら、あらためてサイトマップを構築すれば完了です。再構築には、Google XML Sitemapsプラグイン設定ページから「サーバーまたはブログ上で何か変更をした場合は、手動でサイトマップを最構築するべきです。」のところで行ってください。

coreserverのPHPはセーフモードの制限があるので、こちらの「WordPressのダッシュボードの表示がおかしい」も参考にしてください。

解決方法としてはCGIを作ってワイルドカードで削除することができるということでしたので、それにならって削除することにしました。

CGIは以下の通りです。こちらの記事やこちらの掲示板を参考にしました。属性は755とし、/public_htmlに設置しました。

#!/usr/bin/perl

system("rm -rf /virtual/IDIDID/public_html/DDDDDD/FFFFFF");
print "Content-Type: text/html\n\n";
print "OK!!";
exit;

IDIDIDはアカウント名、DDDDDDはディレクトリ名、FFFFFFはファイル名です。例えば○○.jpgというファイルをすべて削除するル場合はFFFFFFは*.jpgになります。

とここまでは良かったのですが、実行するとエラーが表示されます。

Script Error

The script did not produce proper HTTP headers. Please see the error log to see the detail of the errors. Depending on the server configuration, you can also run thisscript under CGIWrap debugging. Usually, either rename or linkthe script temporarily to a file which ends with .cgidextension, or add a AddHandler cgi-script-debug .cgiline to your .htaccess file.

なにかのエラーが出ているようですが、内容はわかりません。こちらのサイトを参考に、.htaccessに以下を追加してエラーの内容を表示するようにしました。

<Files del.cgi>
AddHandler cgi-script-debug .cgi
</Files>

1行目のdel.cgiは今回作成した削除用のスクリプト名です。
これで、cgiを実行して、エラーがあれば画面下の方に表示されます。

Output of script follows:
=====================================================
Content-Type: text/html

OK!!

エラーがなければ一番下にこのような表示がでます。

今回はコピー＆ペーストしたスクリプトに全角スペースがあったことが原因でした。
訂正して実行した結果、文字化けしたファイルは無事に削除されました。

本題に入る前に、CoreserverのPHPについて説明します。Coreserverの PHP はセーフモードで動いているため、wordpressの自動更新などでうまくいかなくなることがあります。回避するために.htaccessをWordpressディレクトリに設置し、以下の一行を追加すると、CGIモードでWordpressを使うことができます。

AddHandler application/x-httpd-phpcgi .php

しかし、この設定がくせ者で、ダッシュボードのCSSが無効になってしまうようです。

このサイトやこのサイトを参考に.htaccessを以下のように設定しました。CGIモードで動かした方がよい4つのファイルのみをCGIモードで動かすようになっています。

# ファイルのアップロード
<files async-upload.php>
AddHandler application/x-httpd-phpcgi .php
</files>
# プラグインの新規インストール
<files plugin-install.php>
AddHandler application/x-httpd-phpcgi .php
</files>
# テーマの自動アップグレード
<files update.php>
AddHandler application/x-httpd-phpcgi .php
</files>
# コアアップグレード
<files update-core.php>
AddHandler application/x-httpd-phpcgi .php
</files>

これで、解決しました。

逆に、当初のように、 CGIモードでWordpress を運用し、ダッシュボードを表示するPHPのみをCGIモードから除外するという方法もあるようですが、CGIモードの方がパフォーマンスが落ちると言うことなので、まずは上記の設定で運用することにします。

ちなみに、さくらのレンタルサーバはPHPがCGIモードで動いているためこのような心配はありません。

ただし、さくらのレンタルサーバはスタンダード以上、ライトはPHPが使えないのでWordpressは動作不可です。ライトにPHPをインストールすることは可能です。（そのときのWordpressの動作は未確認）

通常は ignore_user_abort をfalseとし、例外的にtrueにしたい場合は、スクリプトの中で以下のように記述することででも可能です。デフォルトでは多くのレンタルサーバーではfalse(off)になっているようです。さくらインターネット、Coreserverではfalseでした。

ignore_user_abort(true);

このほうが、サーバーへの負荷は少なくなります。
ブラウザとの接続については出力しようとしたときに確認されるようなので、ignore_user_abortがfalseでも、ブラウザを閉じたと同時に処理が中断するわけではなさそうです。