サイト公開時

目次

テスト環境を本番サーバーへ反映させるには

Webサイト制作における流れとして、テストサーバーにてサイト構築を行い、構築が完了してから本番サーバーへ移転、公開となる場合があります。テストサーバーの内容を本番サーバーへ移設させる方法、手順を説明します。

本番サイトにa-blog cmsをインストールする

本番サイトでa-blog cmsをインストールします。テストサイトのa-blog cmsと同じバージョンのa-blog cmsをインストールしてください。このあと、データベースのインポートを実施して全てのデータを入れ直しますので、インストール時のテーマ選択は何でも構いません。本番サイトには、正式なライセンスファイルを設置してください。

本番サーバーへファイルを移動する

次のフォルダ、ファイルをテストサーバーからダウンロードし、本番サーバーへアップロードします。

archives、archives_rev、media、themes/使用テーマフォルダ、extention(Ver.2.7.x以下では 「php/ACMS/User以下」)、private/config.system.yaml 、その他カスタマイズしているファイルはアップロードしてください。

データベースのデータをテストサーバーから本番サーバーへ移動

データベースの移動方法には2通りの方法があります

方法1:管理ページのバックアップからバックアップ・リストアを行なう



テストサイトの管理ページ > バックアップ ページ にアクセスします。

バックアップ機能を使用すると、テストサーバー側のデータベース(テーブル構造からレコードまで)をバックアップできます。このとき、「アクセスログとキャッシュ以外のテーブルをzip形式でダウンロードします。」という注釈が画面内にもある通り、全てのデータではなく必要なデータのみをバックアップします。

IDの数値や値は変更されませんが、例外としてPlugin_Schedule を使用している場合は、phpMyAdminでカレンダーの年と月にある"0"のデータを年なら"0000"、月なら"00"に変更する必要があります。

データ量が大きい場合、基本設定のままでは動かない場合があります。そのときは、PHPのmax_execution_timeやmemory_limitの設定値を変更するなど、調整が必要になります。

本番サーバーで行う作業について

つぎは本番サーバーの作業となります。テストサーバーでダウンロードしたzipファイルを本番サーバーの/private/backup_database/にアップロードします。



本番サイトにアクセスし、管理ページ > バックアップ > リストアにアクセスします。 /private/backup_database/にzipファイルを設置すると「バックアップファイル」の項目にセレクトメニューが現れます。先ほど設置したzipファイル名を選択し、「リストア」ボタンをクリックしてリストアします。

リストアが完了するとテーマ設定が切り替わりサイトが表示されますが、この時点ではまだライセンス違反になっています。

方法2:phpMyAdminなどでデータベースを移動させる



テストサーバーのphpMyAdminにアクセスし、テストサイトで利用しているDBのエクスポートを実行します。ダウンロードしたエクスポートファイルを、本番サーバーのphpMyAdminへインポートを実行します。この時、既に入っているa-blog cmsのデータベースは削除、接頭辞を別にして残しておく、DBを別に作るなどいくつか方法があります。DB名や接頭辞(suffix)を変更した場合は必要に応じてconfig.server.phpを変更してください。

完了するとテーマ設定が切り替わりサイトが表示されますが、この時点ではまだライセンス違反になっています。

ドメイン名設定を変更する

本番サイトのメンテナンスメニュー( URL:http://現在の公開URL/setupフォルダを変更後の任意名/index.php )へアクセスし、ドメイン名の修正を行います



「全ブログのドメインを書き換えをする」のチェックボックスは基本的にチェックを入れてください。 ファイルの移動・データベースのコピー・ドメインの修正を実施し、移設作業は完了です。

注意点

本番公開前に、本番サイトの管理ページ>チェックリストへアクセスし、テスト環境のままの設定が本番サイトで使用されていないかを確認してください。

公開前にチェックリストで確認しよう

公開前にチェックしよう

苦労してWebサイトを作成したにもかかわらず、公開前のチェックを怠ると、表示速度が遅かったり、フォームのメールを誤った送信先へ設定していたという問題を見落としてしまう可能性があります。Webサイト公開前は、特に以下のような項目に気をつけましょう。

  • config.server.phpのDEBGUG_MODEがOFFになっているか
  • 正規のライセンスがあたっているか
  • キャッシュがONになっているか
  • フォームが設置してある場合、送信先のメールアドレスは適切か
  • 開発中に使ったテストエントリーが残ってないか

チェックリストを使ってチェックしよう

各種設定が一覧できる「チェックリスト」は、 管理ページ > チェックリスト から確認できます。



キャッシュの設定やメール設定などブログ毎に設定ができますが、その分チェックが大変です。チェックリストを使えば、サイト全体の公開前のチェックがしやすくなります。


コンフィグ検索

チェックリストの最後にコンフィグ検索というものがあります。



入力欄にキーワードをいれ検索すると、コンフィグ設定をDBから検索できます。 これにより、テスト用のコンフィグやテスト用のメールアドレスなどを管理画面から簡単にみつけられます。 また、検索結果からモジュールの設定画面に移動できるので、すぐに変更できます。
Webサイトを公開する際はチェックリストを使って公開時のミスを減らしましょう。

サイト公開時にチェックしておきたいポイント

管理ページの「チェックリスト」を確認する


a-blog cmsのインストール・構築ができたら、いよいよ公開です。
公開の前に、各種設定の見直しを行いましょう。

a-blog cmsの管理ページでは、設置されているライセンス、バージョン、サーバの情報や、現在の動作モード、キャッシュの状態、フォームの設定など、公開時にチェックしておきたい情報を表示しています。
公開前にはこのチェックリストを確認してみてください。


ライセンスは正規のものが入っていますか?


ライセンスがトライアル版のままになっていませんか? a-blog cms のサイトにログインしてサイト登録と購入を行い、公開するサイトの license.php をダウンロードしましょう。
この作業が行われていない場合には、管理者ボックス内のログインした時に表示されているボタン(ログアウトボタン)の横に / トライアル版 有効期限 : 2018-12-31 23:59:59 のような表示(60日の試用期間までの有効期限)がされています。
トライアル版のライセンスのまま有効期限が切れてしまうと、タイトル部分にTESTと表示がされ、情報の追加更新ができなくなります。


デバッグモードはOFFにしましたか?


インストール時はデバックモードはONになっています。公開時には、デバッグモードをOFFにするために config.server.php の define('DEBUG_MODE', 1); を 0 にしましょう。
デバッグモードがONになっている場合は「全ブログのキャッシュ機能がOFF」「HTMLソース内のコメントを表示する」という状態になります。
制作時には、行った変更を即時反映するためキャッシュ機能を使用しませんが、公開時にはキャッシュ機能を有効にすることでログインしていない時の表示速度が体感できるくらい違ってきます。


config.server.php 内の記述


// 本番運用時にDEBUG_MODEを 0 に設定して下さい
define('DEBUG_MODE', 1);

キャッシュ機能はONにしましたか?


上記のデバッグモードでも触れていますが、キャッシュ機能はブログごとにON/OFFが設定できます。必要に応じてOFFにすることもありますが、基本的には公開時にはONとしておくことでサーバの不可軽減、速度向上につながりますので、ONとすることをお勧めします。
変更する場合には、チェックリストページから各ブログごとの編集画面へ移動できます。



メールアドレスの設定は正しいですか?


チェックリストでは、フォームの一般宛・管理者宛の各メールの各宛先を一覧できます。この一覧で、テスト用に設定しているメールアドレスが残っていないか確認してください。
変更する場合には、チェックリストページから各ブログごとの編集画面へ移動できます。

テストデータは残っていませんか?

サーバ上のテスト・制作途中ファイルや、テンプレート、エントリ、ユーザにテストのデータが残っていないかも確認しましょう。


テンプレート上に制作環境のホストやパスが書き込まれていませんか?


テンプレート上に制作環境のURLが直接書かれている事もあるかもしれません。ローカルファイル上でファイルの一括検索等の機能を利用してチェックしておきましょう。

試作やバックアップのHTML・CSS・フォルダをサーバーから削除しましたか?

制作中はテスト的にテーマディレクトリ内にテスト用のファイルやディレクトリが作られることが多いかと思います。公開時には消しておきましょう。

制作用ユーザやテストエントリが残っていませんか?

制作用ユーザで作成したテストエントリがそのままになっていませんか? 必要のないエントリは削除し、公開後にも必要なエントリはエントリ管理ページからエントリのユーザーを変更しましょう。
また、必要のない制作用ユーザはエントリの所有者を変更した上で削除しましょう。

必要に応じて設定をするとよい項目

出力ソースのクリーンアップオプションは有効ですか?


a-blog cmsの 管理ページ > コンフィグ > 出力設定 に、余分な空白の削除 という設定 と HTMLコメントの削除 という設定があります。これにチェックをつける事によって、表示されなかったモジュールの空白等をツメたり、サイトのメンテナンスのために書かれているHTMLのコメントをテンプレートに書いてあっても出力しないということができます。


wwwの有無は確認していますか?


サイト登録時には www.example.com で登録しましたか? それとも example.com ですか? a-blog cms のサイトで登録したものでない方についてリダイレクトの設定を .htaccess にしておきましょう。

www.example.comで運用する場合

RewriteCond %{HTTP_HOST} ^example.com?
RewriteRule ^(.*) http://www.example.com/$1 [R=301,L]

example.comで運用する場合

RewriteCond %{HTTP_HOST} ^www.example.com?
RewriteRule ^(.*) http://example.com/$1 [R=301,L]

公開前に、最後の作業

チェックリストの確認、テストデータの整理などが終わったらいよいよ公開ですが、最後にこの作業をしておきましょう。

画像のアップロード・削除はできますか?

テストサーバで制作をされていた場合には、archives の画像ファイルなどを公開サーバアップロードします。その際にはパーミッションの変更を忘れずに行ってください。(ディレクトリは777、ファイルは666)パーミッションの設定チェックのために、画像を添付したエントリーを1つ書いてテストを必ずするようにしましょう。

制作環境のURLが含まれるようなキャッシュが残ってないですか?

制作用ドメインから公開用ドメインに変更して公開する際には、キャッシュファイルを削除しましょう。キャッシュが残ったまま公開してしまうと、ドメインの変更前の情報が表示されてしまう可能性があります。

セットアップ(メンテナンスプログラム)が動かない場合

セットアップ(メンテナンスプログラム)画面

セットアップ(メンテナンスプログラム)画面


php.iniをドキュメントルートに設置するタイプのレンタルサーバーの場合、a-blog cmsでアップデート時などセットアップ(メンテナンスプログラム)を動かそうとすると画面が真っ白になって動かない場合があります。

原因

セットアップ(メンテナンスプログラム)のディレクトリの中に、php.ini がない為、ioncube loaderがインストールされず、プログラムが動かない事が原因になります。

対策

ドキュメントルートにある php.ini ファイルをセットアップ(メンテナンスプログラム)のディレクトリの中にコピーしてください。これで、メンテナンスプログラムが動作すると思います。

さくらのレンタルサーバーで常時SSL/TLSを設定する


さくらのレンタルサーバーでは以下の特殊な事情により、SSL/TLSの常時化に一工夫必要になります。

仕様

  • httpsのアクセスであっても、%{SERVER_PORT} に 443ではなく80が設定される。
  • httpsのアクセスであっても、%{SERVER_HTTPS} は空。
  • $_ENV['HTTPS'] に httpsのアクセスの場合は"on"が設定されるが、リライトされたものは、空になってしまう。
  • httpsのアクセスの場合、%{HTTP:X-Sakura-Forwarded-For} に クライアントのIPアドレスが設定される。

a-blog cmsでの常時SSL/TLS対応

以上の仕様により、通常の方法では常時SSL/TLSが対応できません。(リダイレクトループが発生してしまう)

そこで以下の対応を行います。

.htaccessを修正

htaccessに以下のリダイレクト処理を追記します。


## 追加
RewriteCond %{ENV:HTTPS} !^on$
RewriteCond %{HTTP:X-Sakura-Forwarded-For} ^$
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R,L]

## 変更
# RewriteRule ((\.(html|htm|php|xml|txt|js|json|css|yaml|csv))|/)$ index.php [L] # 変更前
RewriteRule ((\.(html|htm|php|xml|txt|js|json|css|yaml|csv))|/)$ acms.php [L] #変更後

%{ENV:HTTPS} が "on" でなく、%{HTTP:X-Sakura-Forwarded-For} が 空の場合に、httpsからのアクセスでないと判定できるので、httpsにリダイレクトします。

acms.php の作成と編集

以下のコードをacms.phpファイルを作成し編集します。

<?php

if ( isset($_SERVER['HTTP_X_SAKURA_FORWARDED_FOR']) ) {
    $_SERVER['HTTPS'] = 'on';
    $_ENV['HTTPS'] = 'on';
}
require 'index.php';

これで、a-blog cmsの内部的にもhttpsのリクエストが判別できるようになります。

wwwありのドメインの場合

wwwありのドメインで運用する場合さらに注意が必要です。(wwwなしのドメインの場合は関係ありません。)

さくらのコントロールパネルのドメイン設定で「マルチドメインとして使用する(推奨)」に設定をしている場合問題がおきます。


マルチドメインとして使用する(推奨)

マルチドメインとして使用する(推奨)


この場合、httpsでwwwありでアクセスをすると、内部的に wwwなしとして扱われてしまいます。その結果、a-blog cmsは404 Not Foundを返してしまいます。

例: https://www.example.com でアクセスすると、以下のような値がwwwなしになってしまう。

  • $_SERVER[‘HTTP_HOST’] -> example.com

対応策

対応策として以下のように、さくらのコントロールパネルで設定してください。

  1. wwwなしのドメインの設定を「wwwを付与せずマルチドメインとして使用する(上級者向け)」に設定
  2. wwwありのドメインを追加し、「マルチドメインとして使用する(推奨)」に設定
  3. wwwなし、wwwありの設定とも「SNI SSLを利用する」にチェックをつける

wwwなし

wwwなし

wwwあり

wwwあり

これで、httpsのアクセスでも wwwありのリクエストとして a-blog cmsが認識できるようになります。