スロット攻略 プロジェクトドキュメント

Appearance

サーバー停止・PHP バージョンアップ手順 ​

初回本番移行時は PHP バージョンアップが必要なため、作業中はサイトを一時停止します。このドキュメントでは ConoHa WING でのサイト停止・PHP バージョン変更・サイト再開の手順と、移行作業全体の懸念点をまとめます。

作業の全体フロー ​

[1] バックアップ取得
[2] サイト停止（.maintenance ファイル設置）
[3] PHP バージョンアップ（ConoHa WING コントロールパネル）
[4] コード・デプロイ（core_YYYYMMDD_HHMMSS をアップロード）
[5] PHP-DI キャッシュ削除
[6] 管理画面アクセス（AdminDatabaseInstaller によるテーブル作成など）
[7] 動作確認
[8] サイト再開（.maintenance ファイル削除）

1. バックアップ取得（必須） ​

作業前に必ず実施してください。 問題発生時のロールバック手段が限られます。

DB バックアップ ​

ConoHa WING の「データベース」→「バックアップ」から手動バックアップを取得するか、SSH 経由で mysqldump を実行します。

bash
# SSH 接続後
mysqldump -u [DBユーザー] -p [DB名] > ~/backup_$(date +%Y%m%d_%H%M%S).sql

ファイルバックアップ ​

デプロイ対象の myCustom ディレクトリを圧縮して保持しておくと安心です。

bash
# SSH 接続後
cd ~/public_html/[ドメイン]/wp-content/themes/cocoon-child-master/
tar -czf ~/backup_myCustom_$(date +%Y%m%d_%H%M%S).tar.gz myCustom/

2. サイト停止（.maintenance ファイル設置） ​

WordPress ルートディレクトリに .maintenance ファイルを置くと、WordPress 組み込みのメンテナンス画面（503 ステータス）が表示されます。

手順 ​

bash
# SSH 接続
ssh "${DEPLOY_USER}@${DEPLOY_HOST}" -p "${DEPLOY_PORT}" -i "${DEPLOY_SSH_KEY}"

# WordPress ルートへ移動（例）
cd ~/public_html/[ドメイン]/

# .maintenance ファイルを作成（$upgrading にタイムスタンプを設定）
echo '<?php $upgrading = time();' > .maintenance

ポイント: WordPress は .maintenance ファイル内の $upgrading 変数を参照してメンテナンスモードを判定します（空ファイルでは有効になりません）。$upgrading が「現在時刻からおおよそ 10 分以内」の場合のみメンテナンス中とみなされ、それを過ぎると .maintenance が残っていても通常ページが表示される点に注意してください。$upgrading に現在のタイムスタンプを設定することで HTTP 503 が返され、クローラーに「一時的な停止」を伝えられるため SEO への影響を最小化できます。

作業が 10 分を超える可能性がある場合は、適宜 echo で .maintenance を再生成して $upgrading を更新する運用を行うか、あるいは Web サーバー側の 503 メンテナンスページ（例: .htaccess での 503 応答設定）で強制的にアクセスを止める方法も併用してください。特に数時間以上の長時間停止は検索順位に影響する可能性があるため、停止時間をできるだけ短くするか、停止時間帯を事前に告知するなど運用面での配慮も検討してください。

重要: .maintenance による WordPress メンテナンスモード中は、フロントだけでなく wp-admin へのアクセスも 503 で停止します。そのため、停止中に「管理画面アクセスで Installer を自動実行してテーブル作成する」手順は実行できません。本番移行で停止中に DB 変更を終える場合は、各テーブル手順に記載の手動 CREATE TABLE SQL を使用してください。管理画面アクセスによる自動作成は、.maintenance を置いていないローカル・ステージング・通常稼働中の環境、またはサイト再開後の確認用として扱います。

停止確認 ​

ブラウザでサイトにアクセスし、「メンテナンス中です」というWordPress標準のメンテナンスページが表示されることを確認します。

3. PHP バージョンアップ（ConoHa WING） ​

コントロールパネルからの変更手順 ​

  1. ConoHa コントロールパネル にログイン
  2. WING → サイト設定 → 応用設定タブのPHP設定 を開く
  3. 対象ドメインの PHP バージョンを選択して変更
  4. 保存・適用

変更後の確認 ​

bash
# SSH 接続後、phpinfo や php -v で確認
php -v

注意: ConoHa WING では SSH 時の PHP と Web 用の PHP が異なる場合があります。コントロールパネルで変更した PHP バージョンが実際に反映されているか、WordPress 管理画面（ダッシュボード → 「サイトヘルス」→「情報」）でも確認してください。

4. コード・デプロイとテーマ反映 ​

PHP バージョン変更後、本番向けにビルド済みの core_YYYYMMDD_HHMMSS とテーマファイルを反映します。

デプロイ（ローカル開発マシンで実行） ​

次の手順のうち、./bin/deploy-all.sh は ローカルの myCustom リポジトリルート（開発用マシン上のターミナル）で実行します。SSH で本番サーバーに接続したシェル上では実行しません。config/local.env 等のデプロイ設定に基づき、ビルド成果物がサーバーへ転送されます。

  1. （前提） リモートの DEPLOY_REMOTE_PATH（通常は .../wp-content/themes/cocoon-child-master/myCustom/）に connector.php が既に存在することを確認してください。./bin/deploy-all.sh の末尾で実行される ./bin/activate.sh は、リモート上の myCustom/connector.php 内の define( 'VERSION', ... ) を sed で書き換えるため、初回導入などで当該ファイルが無いとアクティブ化に失敗します。未配置の場合は、先にステージングからコピーするか、手元の connector.php をアップロードしてから手順 2 に進んでください（手順 2 完了後、VERSION は activate により最新の core_YYYYMMDD_HHMMSS に合わせて更新されます）。
  2. ./bin/deploy-all.sh を実行する（ビルド・本番へのアップロード・アクティブ化まで一括）。個別に進める場合は 本番環境デプロイ の ./bin/build.sh / ./bin/deploy.sh / ./bin/activate.sh を参照。connector.php を後から丸ごと上書きした場合は、VERSION を再度揃える必要があるため ./bin/activate.sh <YYYYMMDD_HHMMSS> を再実行してください。
  3. 子テーマルート（cocoon-child-master/ 直下。myCustom フォルダと同階層）の functions.php を、ステージングで確認済みの内容で上書き反映する（手動コピー、rsync、または運用に合わせた方法）。カスタム本体は myCustom/connector.php を子テーマの functions.php から読み込む構成のため、myCustom/functions.php を探さないよう注意してください。

補足: デプロイ後に PHP-DI キャッシュ削除・管理画面アクセス（Installer 実行）・動作確認などが続く場合は、作業の全体フロー の [5]〜[7] および各手順書に従ってください。手動の CREATE TABLE が必要な緊急時のみ、各手順書の SQL を参照してください。

5. サイト再開（.maintenance ファイル削除） ​

全作業・動作確認が完了したらメンテナンスモードを解除します。

bash
# SSH 接続後
cd ~/public_html/[ドメイン]/
rm .maintenance

ブラウザでサイトにアクセスして正常表示を確認してください。

懸念点・注意事項 ​

PHP バージョン互換性 ​

PHP のメジャーバージョンアップ（例: 7.4 → 8.x）では後方互換性が大きく変わる場合があります。

確認項目内容
非推奨/削除された機能動的プロパティの廃止、内部関数の引数・戻り値の型チェックの厳格化など
型宣言の厳格化PHP 8.x では型エラーが以前より多く発生する
エラーハンドリングWarning が TypeError などの例外に昇格するケースがある
文字列の数値比較0 == "foo" が PHP 8 から false になった

対策: ローカル環境やステージング環境で同バージョンの PHP に切り替えてテストを実行してから本番適用してください。

bash
# PHPStan を新バージョン向けに再実行（エラーがないか確認）
composer analyse

依存ライブラリの互換性 ​

本プロジェクトが使用するライブラリの PHP 要件を確認してください。

ライブラリ確認方法
Twigcore_src/composer.lock の twig/twig エントリの php 要件を確認（または composer show twig/twig | grep php を実行）
PHP-DIcore_src/composer.lock の php-di/php-di エントリの php 要件を確認（または composer show php-di/php-di | grep php を実行）
PhpSpreadsheetcore_src/composer.lock の phpoffice/phpspreadsheet エントリの php 要件を確認（または composer show phpoffice/phpspreadsheet | grep php を実行）

注意: core_src/vendor/ は .gitignore 対象のため、GitHub 上では確認できません。core_src/composer.lock はリポジトリに含まれるため、こちらで PHP 要件を確認してください。

要件を満たさないバージョンに上げる場合は core_src/ で composer update が必要です。 composer.lock も更新されるため、必ず動作確認後にコミットしてください。

WordPress・プラグイン・テーマの互換性 ​

確認項目確認方法
WordPress coreWordPress 公式の PHP 要件ページで確認
Cocoon テーマCocoon の動作環境・更新履歴を確認
各プラグイン管理画面「プラグイン」または各プラグインのリポジトリで PHP 要件を確認

特に Cocoon は PHP 8.x での動作実績を公式サイト・フォーラムで事前に確認しておくことを推奨します。

PHP-DI コンパイルキャッシュの削除（必須） ​

PHP バージョン変更後はコンパイル済みキャッシュが古い PHP バージョン向けになっているため、必ず削除してください。削除しないとサイトが正常に動作しない場合があります。

bash
# SSH 接続後
rm -f ~/public_html/[ドメイン]/wp-content/cache/php-di/CompiledContainer.php

詳細は 本番環境への接続方法 を参照してください。

SEO・ユーザー体験への影響 ​

  • .maintenance ファイルによる停止は HTTP 503 を返すため、クローラーへの影響は最小限です
  • ただし停止時間が長くなると検索インデックスや順位に影響する可能性があります
  • 作業は一気に通して実施し、**停止時間を最小限（目安: 30分以内）**に抑えることを推奨します
  • 可能であれば深夜〜早朝など、アクセスが少ない時間帯に実施してください

ロールバック計画 ​

問題が発生した場合の対応を事前に確認しておいてください。

問題対応
PHP バージョンアップ後にエラーが多発ConoHa コントロールパネルで PHP バージョンを元に戻す
コードデプロイ後に不具合connector.php の VERSION を旧バージョンに戻す（ロールバック手順 を参照）
DB 変更後に不具合バックアップから DB をリストア（事前バックアップ必須）

.maintenance ファイルはロールバック完了まで残しておくと、ユーザーへの影響を抑えられます。

作業前チェックリスト ​

□ DB バックアップ取得済み
□ ファイルバックアップ取得済み
□ ローカル／ステージングで新 PHP バージョンでのテスト済み
□ 依存ライブラリの PHP 要件確認済み
□ WordPress・プラグイン・Cocoon の互換性確認済み
□ ロールバック手順を確認・メモ済み
□ 作業時間帯（深夜〜早朝推奨）を計画済み
□ リモート myCustom に connector.php が配置済み（deploy-all 末尾の activate の前提）

関連ドキュメント ​