はじめに

　UpdraftPlus Premiumを購入して移行処理をしようとする寸前，WPvividの情報を知った。ぼくの集合住宅ではベランダに面するアルミサッシ一式が更新中で，いま我が家はその工事の中にあって，早起きを強いられ，埃も舞うところで，このページを入力している。この工事のなかでの検索が功を奏したのである。眠い。

　Perplexityさんの評価を次に。

————————————————

総合評価
• All-in-One WP MigrationやUpdraftPlusなどの有力プラグインと並ぶ、またはそれ以上の使いやすさと機能性があると評価されています。
• 特に「All-in-One WP Migration」が有料サブスクリプション制になった後の無料の代替プラグインとして注目度が高いです。
• 日本語対応やリンク切れ対策など、実際の移行作業でも安心して使えるとの声が多いです。
まとめ
WPvividは、無料で容量制限がなく、ワンクリック移行や外部ストレージ連携など多機能で使いやすいWordPress移行プラグインとして、非常に高い評価を得ています。初心者から上級者まで幅広くおすすめできるアプリです。

————————————————

　Perplexityにお尋ねした「WPvividはなぜ無料なのでしょうか？」

————————————————

WPvividは「無料で容量制限なし」という魅力的な基本機能を提供することでユーザーを獲得し、より高度な機能を有料で提供することで収益化を図るフリーミアムモデルreemiumを採用しているため、無料で使えるのです。

————————————————

　弱小も弱小のちいさなぼくのようなユーザーには無料提供ということだなあ。UpdraftPlusもbackWPupも消えざるを得ないねえ。と今は思うけど，やってみないとわからない。

1. 無料版UpdraftPlusの凍結

　午後4時から自動的にGoogle Driveにバックアップが始まるので，無効化 deactivateをまずは実施した。

2. WPvividの使い方

　使い方については，たくさんのサイトがあるが，少なくとも上位のサイトの情報はほぼ役に立たなかった。Perplexityさんに聞くのが正解であった。

　Perplexityさんに。「WordPressのプラグインWPvividで大容量の独自ドメインサイトを，さくらレンタルサーバーからエックスサーバーに移行するには，どの機能を使うのが妥当でしょうか？」

———　引用〜

推奨機能と理由：
• 自動移行機能（Auto-Migration）
• WPvividの「自動移行」タブから、移行先（エックスサーバー）のWordPressで移行キーを発行し、移行元（さくらレンタルサーバー）でそのキーを使ってデータを転送する方法が最もシンプルで確実です。
• この方法はサイト全体（データベース＋ファイル）を丸ごと移行でき、容量制限もありません。
• サーバー間で直接データをやり取りするため、手動でのファイルアップロードやダウンロードの手間が省けます。
大容量サイト対応のポイント
• 容量制限なし
• WPvividは無料版でも移行データの容量制限がありません。All-in-One WP Migrationなど他のプラグインでは無料版に1GBなどの制限がありますが、WPvividなら大容量サイトも問題なく移行できます。
• 分割移行も可能
• 万一、1回での転送が難しい場合は、WPvividの「分割移行」機能を利用して、バックアップファイルを複数に分割して移行することもできます。
基本的な移行手順（自動移行機能）
1. 移行先（エックスサーバー）でWordPressを新規インストールし、WPvividプラグインを有効化
2. WPvividの「自動移行」タブで移行キーを発行
3. 移行元（さくらレンタルサーバー）のWPvividで「自動移行」を選択し、発行したキーを入力して移行を開始
4. 移行完了後、必要に応じてドメインやSSL設定を調整
補足事項：
• バックアップデータは「データベース＋ファイル（WordPressファイル）」で取得し、移行先でリストア（復元）する流れが一般的です。
• 大容量サイトの場合、アップロードや復元時にタイムアウトやエラーが出ることがあるため、その場合は「分割移行」や「手動でのバックアップファイル転送」も検討できます。
まとめ：
WPvividの「自動移行」機能を使い、容量制限なしで「データベース＋ファイル」をまるごと転送・復元する方法が、さくらレンタルサーバーからエックスサーバーへの大容量WordPressサイト移行に最も適しています。

引用〜おわり　———

　さらに，Perplexityさんに。「この自動移行の前に，settingsで何らかの変更は必要ありませんか？」

———　引用〜

WPvividの自動移行を行う前に、特別な設定変更は基本的に必要ありません。WPvividの自動移行機能は、ほとんどの場合、初期設定のままでそのまま利用できます。
ただし、以下の点には注意してください。
• 移行先のWordPress一般設定（URL）
移行先でWordPressを新規インストールした場合、「設定 > 一般設定」でサイトURL（http → https など）が正しいか確認し、必要に応じて修正してください。
• パーマリンク設定の再保存
移行後、パーマリンク設定を一度「変更を保存」して再生成してください。これによりリンク切れや表示不具合を防げます。
• ユーザー情報の確認
移行後、WordPressのユーザー情報は移行元のものに上書きされます。必要に応じて管理画面からユーザーの追加や削除を行ってください。
• 大容量サイトの場合
特に大容量サイトでは、バックアップ・復元の際にタイムアウトやエラーが出る場合もあるため、WPvividの分割バックアップ機能を使うことも検討してください。
まとめ
WPvividの自動移行前に特別な「settings」変更は不要ですが、移行後にURLやパーマリンク、ユーザー設定などを確認・調整することが推奨されます

引用〜おわり　———

3. XServerとさくらでの準備

3.1 ウェブ領域・設定の初期化

　UpdraftPlusやphpMySQLによるデータベース操作で失敗した独自ドメインサイトの初期化をする必要がある。

　この過程で，ぼくが拘り続けた疑問をPerplexityにぶつけてみた。「さくらで使用してきた独自ドメインをエックスサーバーに移行して，urlのSSL化をしたい。現在のエックスサーバーの「サイト設定状況」は「NS相違」である。さくらで運用してきたWordPressサイトをエックスサーバーに移行する際，httpsサイトからhttpsサイトへの移行が便宜性が高いと考えています。「エックスサーバーのネームサーバーへの変更」ではなく，「他者サーバーでのWeb認証」を実施した場合，WPvividでの「自動移行機能」を実施する上で問題がありますか？」

———　引用〜

結論：


「他者サーバーでのWeb認証」でSSL証明書が無事に発行できていれば、WPvividの自動移行機能に問題はありません。ただし、DNS設定次第ではWeb認証ができず、SSL化が移行後になる場合があるため、その場合は一時的にhttpでの移行となります。

引用〜おわり　———

　賢いなあ。エックスサーバーでは，httpのままで，問題がないということだね？

　エックスサーバーのサーバーパネルで，motochan.infoの初期化を実行したい。三択があるが，

ウェブ領域・設定の初期化

• サイトデータやサイトに関する各種設定の初期化を行います。
• メール等サイト以外の設定はそのまま活用し、サイトの内容のみ再構築したい場合に最適な機能です。

　

これを実行した。確認画面で，

対象ドメイン	motochan.info
処理方法	ウェブ領域・設定の初期化
処理内容	「/home/xxxxxxx/motochan.info/public_html/」以下の領域の初期化 ※サブドメインが設定されている場合、そのウェブ領域は削除されます。

適切だと思うので，実行した。

3.2 さくらでのWordPressユーザー名とパスワードの変更

　エックスサーバーで「WordPress簡単インストール」を実行する際に，ユーザー名とパスワードも入力する必要があるが，あまりにセキュリティ上，問題があるのを感じて（ずっと気になっていた），変更することにした。

　Perplexityさんにお尋ねした。

———　引用〜

新規ユーザーを作成してから旧ユーザーを削除する方法
• 「ユーザー」＞「新規追加」から新しいユーザーを作成し、権限を「管理者」に設定します。
• 新しいユーザーでログインし直してから、旧ユーザーを削除します。
• 削除時に「すべてのコンテンツを新ユーザーに割り当てる」を選択し、投稿やページを引き継ぎます。
• これが最も一般的で安全な方法です。

引用〜おわり　———

　この通り実行したが，かなり怖い。「すべてのコンテンツを以下のユーザーのものにする」を選択して，「削除」ボタンをクリック。フリーズではないが結構時間がかかって，「Bad gateway」のメッセージがきた。ログアウトして，新たなユーザー名とパスワードで新規ログインできた。ウェブ上でユーザー名は露出しているのでユーザー名をわざわざ変える必要性はなかったのである。パスワードの変更だけでよかった。

　なお，さくらのWordPressは自動で，ver. 6.8にアップデートされていた。いま，このバージョンでこの投稿を編集しているが，ブロックエディターのメニューが「/」を入力すると，その場に出てくるようになった。便利ではある。

3.3 XServerで「WordPress簡単インストール」

　XServerのサーバーパネルに入ってメニュー表示して，「WordPress簡単インストール」を選択して，さくらで新たに変更したユーザー名とパスワード（メールアドレスも）を登録した。

　この設定ののち，独自ドメイン motochan.info にWordPressがみえ，「さくらからの移行」というぼくのメモも見える。ここにこのワードプレスへのリンクがあって，アクセスできる。ログインするには，この設定ページにみえる「ログインボタン」をクリックして，さくらで新規に作成したユーザー名とパスワードを入力してダッシュボードに入ることができた。

　ここで新たに，WPvivid Backup Plugin，をインストールして有効化した。

　エックスサーバーからいま（Apr. 22, 2025），
「WordPress簡単インストール」「WordPress簡単移行」機能がWordPress最新版（6.8）に対応

という連絡があった。確かに，ぼくがインストールした時点ですでにこのバージョンであった。ぼくが選んだWordPressのテーマはLightning（子テーマも）のデータベースの修復のメッセージがあり，実行した。なお，デフォルトでのインストールプラグインは，CloudSecure WP Security のみであったが，有効化はされていないものの，Askimet Anti-spam, Hellow Dolly, Type Square Webfonts for エックスサーバー，がインストールされている。

4. WPvividを使って

4.1 ローカルにバックアップ

　「自動移行」にリスクがあるという情報をみた記憶があるので，まずはローカルにバックアップをと考て，Perplexityに尋ねた。「WPvividでローカルにバックアップを取る際の注意点を教えてください。」

———　引用〜

バックアップ対象と保存先の選択：
• バックアップ対象を明確に選ぶ
「データベース＋ファイル（WordPressファイル）」を選択すると、サイト全体（記事、設定、画像、テーマ、プラグインなどすべて）をバックアップできます。必要に応じて「データベースのみ」や「ファイルのみ」も選択可能です。
• 保存先を「ローカル」に設定
「ローカル」とは、WordPressが動作しているサーバー上（wp-content/wpvividbackupsフォルダ）にバックアップを保存することを指します。ご自身のパソコンに直接保存する場合は、作成後にダウンロード操作が必要です。
ダウンロードと管理：
• バックアップファイルのダウンロード
サーバー上に保存されたバックアップファイルは、WPvividの管理画面から「ダウンロード」ボタンで自分のパソコンに保存できます。
• バックアップファイルの命名規則
ファイル名にはドメイン名や作成日時、「wpvivid」などが含まれます。複数管理する場合は、どのサイト・日時のバックアップか分かるように整理しましょう。
• バックアップファイルの管理と保管
サーバー上やパソコン内でバックアップファイルが増えすぎると、ストレージ容量を圧迫します。不要なバックアップは適宜削除し、必要なものだけを安全な場所に保管してください。
復元・移行時の注意：
• 復元時はログイン情報が上書きされる
バックアップを復元すると、移行元のユーザー情報（ユーザー名・パスワード）が上書きされます。復元後は正しいログイン情報でアクセスできるか確認しましょう。
• ローカル環境（Local等）では一部機能が使えない場合がある
自動移行機能などはローカル環境では正常に動作しないことがあるため、手動でのバックアップ・リストアを選択してください。
その他：
• バックアップの定期的な確認
バックアップが正しく作成・保存されているか、定期的にダウンロード・復元テストを行いましょう。
• クラウドストレージの活用も検討
ローカル保存だけでなく、Google DriveやDropboxなどのクラウドストレージにもバックアップを保存しておくと、万が一の際にも安心です。
まとめ：
WPvividでローカルにバックアップを取る際は、バックアップ対象と保存先を正しく選択し、ファイルの管理・ダウンロード・保管を徹底してください。また、復元時のユーザー情報上書きや、ローカル環境での制限にも注意が必要です。

引用〜おわり　———

　気になることが出てきた。Perplexityに聞いた。「WPvividで自動移行機能を使って，さくらのWordPressサイトをエックスサーバーに移行する際，wp-content/wpvividbackupsのファイルも移行するのですか。」

———　引用〜

まとめ：
• 自動移行機能では、wp-content/wpvividbackupsフォルダの中身を個別に移行する必要はありません。
• サイト本体のデータのみが自動で転送・復元されます。
もし過去のバックアップファイルも新サーバーで管理したい場合は、手動でダウンロード・アップロードする必要がありますが、通常のサイト移行には不要です。

引用〜おわり　———

　やあ，安心だ。

　Perplexityに聞いた。「WPvividでローカルにバックアップを取る手順を教えてください。」

———　引用〜

2. WPvividの管理画面を開く • 左側メニューから「WPvivid Backup」をクリックします。
3. バックアップの設定を選択
   • 「バックアップ＆復元」または「バックアップ」タブを開きます。
   • バックアップ対象（「データベース＋ファイル（WordPressファイル）」など）を選びます。
   • 「バックアップをローカルに保存する」にチェックが入っていることを確認します。
4. バックアップの実行
   • 「バックアップ」ボタンをクリックします。
   • バックアップ処理が始まるので、完了まで待ちます。
5. バックアップファイルの確認とダウンロード
   • バックアップが完了すると、画面下部にバックアップリストが表示されます。
   • 必要に応じて「ダウンロード」ボタンをクリックし、バックアップファイルを自分のパソコンに保存します。
6. 補足
   • バックアップファイルはサーバー内の「wp-content/wpvividbackups」フォルダに保存されます。
   • 容量が大きい場合、バックアップファイルが複数分割されることがあります。
   • 定期的な自動バックアップは「スケジュール」タブで設定できます。
   この手順でWPvividを使い、WordPressサイトのローカルバックアップが簡単に行えます。

———　引用〜

4.2 “1 backup task(s) have been failed. Please switch to Log page to send us the debug information.”

　いやー，がっかり。図1のようにローカルへのバックアップが失敗した。何故，単純なバックアップで失敗したのか。UpdraftPlusによるバックアップの場合は問題なかった。

　この失敗によってWPvividからの情報の前にわかったことがある。Google Driveなどの外部ストレージへのバックアップの場合，基本的に制限がない。CommanderOneなどのようなFTPクライアントの場合，サーバーのどこかのディレトリーにかなり重いファイルをアップロードすることは可能である。実質，ぼくのような個人ユーザーが扱うファイルのアップロードに対してサーバーからの制限がない。

　WPvividに用意されている最も簡単なバックアップができなかったのはなぜか。前述のように，「バックアップファイルはサーバー内の「wp-content/wpvividbackups」フォルダに保存されます。」。このディレクトリはWordPressの枠内である。

　ということは，php.iniで，max_execution_timeやmax_file_sizeを超えているからである。エックスサーバーで実行したように，さくらでも，php.iniを編集する必要がある。

　で，エラーのあと，WPvividのサポーターに質問することができる。返事が来るかどうかではあるが。ぼくの質問を次に。

———　引用〜

方法1。 サイトに SMTP を設定している場合、メールアドレスを入力し、下のボタンをクリックして、エラー発生時の関連情報 (ウェブサイト情報とエラーログ) を送信してください。何が起きたかの解明に役立ちます。問題が解決したら、お客様のメールアドレス宛にお知らせします。
WPvivid サポートメール: メールアドレス:

（ぼくからの）質問：
メッセージは次のようです。
1 backup task(s) have been failed. Please switch to Log page to send us the debug information.
進行状況ではすぐに13%と表示されて，その後も変わりませんでした。正確ではありませんが，40分ほど何度もトライしていたようです。特に，”Task, backup_db is not responding.” がよく出ていました。データベースは解凍すると3.04GBほどあります。php.iniを変更したいとは考えています。サーバーで見ますと全部で30GBほど占めていたように思います。
さくらからXServerへのサイト移行を考えていて，営為努力しているのですが。無料版UpdraftPlusの復元容量の制限を知らずにほぼ1ヶ月無駄にしてきました。昨日，UpdraftPlus Premiumを購入寸前に，WPvividの存在を知り，差し当たり，ローカルバックアップを始めたところでした。ご指導くださいませ。バッグを送信する，ボタンをクリックする。

引用〜おわり　———

“motochan.info send succeeded” とリアクションがあった。

　エラー情報のファイルもダウンロードした。

———　引用〜

wpvivid_debug.zip

内容：
[2025-04-22 18:50:19][error]Backup the file ends with an error 再開の試行が多すぎます。

引用〜おわり　———

　wpvivid_server_info.json もSeaMonkeyで閲覧し，テキストをコピーした。かなりのボリュームなのであるが，断片を次に

———　引用〜

略　”multisite”:”disable”,”web_server”:”Apache”,”php_version”:”8.3.8″,”mysql_version”:”5.7.40″,”wp_debug”:false,”language”:”ja”,”upload_max_filesize”:”1024M”,”max_execution_time”:”300″,”max_input_vars”:”65535″,

略　”memory_current”:”8MB”,”memory_peak”:”8.38MB”,”memory_limit”:”10240M”,”post_max_size”:”10240M”,”allow_url_fopen”:”1″,”safe_mode”:false,”pcre.backtrack_limit”:”1000000″,

引用〜おわり　———

　ここに記されている問題ならば，php.iniの編集で可能だろう。

4.3 想定される対策は

　まだ不確かである。4.2のエラーでのサポート情報は次のものであった。

Advanced Settings of Backup & Migration Free

How-to: Transfer Your Site with Backup & Migration Free

Troubleshooting Issues on Backup & Migration Free

　結局，次のような手順で回避できるのではないか。

1　WPvividの「バックアップ & 復元」のタブの下方にある，ヒント: ディレクトリ内のすべてのアップロードまたは受信したバックアップをスキャンするには、以下のボタンをクリックしてください /home/motochan/www/info2020/wp/wp-content/wpvividbackups，にはスキャンしても何も出てこない。
2　CommanderOneで，さくらのWordPressのドメインに入って「wp-content/wpvividbackups」フォルダ内のファイルの存否を確認し，あれば削除する。

3　さくらのphp.iniを編集してエックスサーバーと同様な変更をする。

4　データベースを含めて，200MB単位の分割をする。

a. 「wp-content/wpvividbackups」の確認

　図2にはエラーログ情報が見える。この種の情報は，今後の作業には影響がないものと考える。エラーが発生してバックアップ関連のファイルは自動的に削除されている。手作業でこの種のログ情報を削除すると問題が生じると考えられた。

以上，2025年4月22日。

b. さくらのphp.iniを編集

　途中。

c. 200MB単位の分割

　Perplexityさんに聞いた「WordPressのプラグインWPvividを使ってバックアップを取る際に，例えばファイル分割を200MB単位のファイル分割を実施するには？」

———　引用〜

WPvividでバックアップファイルを200MB単位で分割するには、以下の手順で設定できます。
1. WordPress管理画面で「WPvivid Backup」を開く
2. 「設定」タブをクリック
3. 「高度な設定」タブを選択
4. 「あるサイズごとにファイルを圧縮」欄に「200」と入力
この数値が分割されるファイルサイズ（MB単位）になります。
5. 画面下部の「変更を保存」ボタンをクリックして設定を保存
この設定により、バックアップファイルは200MBごとに分割されて保存されます。
大容量サイトやサーバーのアップロード制限が厳しい場合に特に有効です。

引用〜おわり　———

緊急書き込み中断

　さくらから，このWordPressのサイトのデータベース容量が制限を超えているので，コンテンツの削減を図りなさい。もし今後も増大させるようなら，連絡なしで，サイト中止にすることもって。

　で，連絡したら，優しいお返事があった。とにかく，ここへの書き込みは中止する。今後はネットへのアップをやめて，エックスサーバーへの移行が成功するまで，Microsoft Wordで書き溜めてゆく。エックスサーバーへの移行を二つの独自ドメインにして，その後，それぞれの役割を分けて考えて，いずれかのサイトにコンテンツが残るようにしたい。

以上，2025年4月23日。

　

　

　

　

はじめに

　やっとここまできた。このページでこのテーマは終了したいものである。エックスサーバーの本契約 Mar. 11, 2025 をしてもう一ヵ月，窓前では，白梅の開花をみていまやソメイヨシノの葉桜も終わりに近い。最大二日ぐらいで移行が完了すると考えていた。まあ学びの期間であった。このページでは移行過程をスクリーンショットを並べて示したいと思っている。ただ，現在，さくらレンタルサーバーにアップロードしているがこの移行プロセスの追加更新はXServerからのアップロードに引き継がれるはずである。

　残された移行プロセスは次のよう。

1　XServerで，さくらから移行した独自ドメインmotochan.infoにWordPress（テーマ: Lightning）をインストールする。

2　無料版Plug-inのUpdraftPlusをインストールする。

3　XServerの無料SSL secure sockets layer を実行する。WordPressからログアウト。

4　このWordPressにブラウザーで開く。https://motochan.infoなのか，https://motochan.info/public_htmlなのか確かめる。アクセスできるかではあるが。さくらurlは，https://motochan.info/wp でのアクセスが必要なので。もちろん，この段階ではネームサーバーの変更はしてはならない。

5　CommanderOneでwp-config.phpを参照しSearch-Replace DBアプリが求めるデータベース関係のパラメータを取得する。

6　以上まで問題なければ，XServerのサポートに確認をした方がいいだろう。問題があれば，もちろんXServerのサポートにヘルプ依頼だな。

7　さくらから毎日バックアップをとっているGoogle DriveにXServerのUpdraftPlusから復元する。これが出来ない仕様ならば，いちど，Google Driveからバックアップを macにダウンロードする必要があるかもしれない。

8　Search-Replace DBアプリのフォルダ名を変えて，CommanderOneを使って，wp-config.phpがある階層に，Search-Replace DBアプリフォルダをコピーする。

9　Search-Replace DBを使って一連の作業を実行し成功すれば，Search-Replace DBアプリフォルダを削除する。

10　XServerの「動作確認URL」機能を使って表示チェック。

11　ブラウザーでドメイン名を入力してアクセス。表示に問題がなければいいのだが。

12　ドメインのネームサーバーを変更。

1. XServerで独自ドメインmotochan.infoにWordPress（テーマ: Lightning）をインストール

1.1 XServer提供の簡単インストール

エックスサーバーのユーザーに提供されている，サーバーパネルより「WordPress簡単インストール」を実施する。データベースなど一切，オプションを設定しない。テーマはぼくがさくらで現在選択しているLightningを選択する。

WordPress簡単インストール設定例からぼくの場合を。

サーバーID: ぼくのエックスサーバーでの名前（xsample　）

ドメイン名：motochan.info

インストールディレクトリー：/home/xsample/motochan.info/public_html/

サイトurl: http://motochan.info/wp

以上。

簡単インストール前の設定で，「子テーマをインストールする」のオプションがあって，Perplexityに質問した。その回答が次。

————————————————

LightningはWordPressのテーマであり、子テーマではありません。しかし、Lightningテーマには親テーマとして利用できる設計があり、それを基にカスタマイズするための子テーマ（lightning-child）を作成・使用することが推奨されています。
子テーマの役割とLightningの場合
• Lightningテーマ: 親テーマとして機能し、デザインや機能が豊富に用意されています。
• Lightning子テーマ: Lightningをベースにカスタマイズを行うために作成されるもの。親テーマのアップデートによる影響を受けず、安全にカスタマイズが可能です。
子テーマの使用方法
1. Lightningの子テーマを公式サイトや提供元からダウンロードします.
2. WordPress管理画面で「外観」→「テーマ」→「新規追加」から子テーマをアップロードし、有効化します.
3. 子テーマ内のstyle.cssやfunctions.phpを編集して、デザインや機能をカスタマイズします.
したがって、Lightning自体は親テーマですが、カスタマイズする際には子テーマを利用することが一般的です。

————————————————

　さくらからの移行ではバックアップを利用するので，テーマ選択は意味がない可能性が大である。

1.2 motochan.info/wpへのインストール

　https://motochan.info/wpはさくらで現在公開中のWebサイトのurlである。図1と図2はWordPress簡単インストールの入力画面の上部と下部である。ぼくのこのWebページの地の文で明記しているサイト名を一応伏せている。

　図3は実行結果を示している。さくらからエックスサーバーに移行した独自ドメイン motochan.infoにノータッチのWordPressをインストールしたはずであるが，http://motochan.info/wp をクリックすると，現在公開中のさくらのサーバーのサイトに繋がってしまうのである。http://motochan.info/wp としているが，https://motochan.info/wp につながるのである。さくらのダッシュボードにもログインできる。

　　ぼくはエックスサーバーにWordPressをインストールしたら，エックスサーバーの独自ドメインをSSL化できるのではと考えたが図4（データベースの軽減のために削除）の表記に見えるように，無理だった。

　それで，WordPress簡単インストールに用意されている削除機能を使って，図5（データベース負荷を減らすべく削除）のように，XServerのWordPressを削除した。

　図5の重要情報を次に。

サイトurl: http://xxxx.info/wp

管理画面url: http://xxxx.info/wp/wp-admin/

削除対象ディレクトリ：/home/xxx/xxxx.info/public_html/wp

　そして，サブディレクトリーなしの場合を作成し機能しないので削除し，サブディレクトリー wp2の作成したのである。機能しないと考えたのは誤りで，ネット上に公開されるのには時間がかかるようだ。忘れてしまった。2025年4月13日の午後6頃前にアップロードしたから，すでに7時間が経過するが,http://motochan.info/wp2をブラウザーで入力すると，「Not Found　The requested URL was not found on this server.」となる。このthis serverはさくらのサーバーのようだ。

以上，2025年4月14日深夜。

1.3 サポートに質問

　回答は二日ほど後になるので，明日月曜日に見てもらうように今，メモ書きしてみよう。

————————————————

まずは，「経緯」をご説明し，お尋ねしたいことを「質問」として後に示します。

経緯：

　サクラレンタルサーバーからエックスサーバーへの移転すべく，ほぼ一ヵ月前にエックスサーバーのスタンダード版に3年契約をしました。お任せや簡単移行には対応せず，手作業での移行のために，学んでいます。で，UpdraftPlusを利用したサイト移転（引っ越し）方法　https://highfivecreate.com/blog/tips/6097.html#i-2が最も適切と考えています。

　さくらのサーバーでのWordPressのUpdraftPlusを使ってGoogle Drive (100GB)にバックアップを毎日（三日分）実施しています。これをエックスサーバーにインポートします。ただ，その前にエックスサーバーでWordPressをインストールし，UpdraftPlusをインストールする必要があります。

質問1：

　WordPress簡単インストールを使って，さくらから独自ドメイン motochan.infoにインストールしました。urlは，https://motochan.info/wp2 になります。ファイルマネージャーでみますとインストールされています。

ブラウザーでは「Not Found　The requested URL was not found on this server.」となります。このthis serverはサクラレンタルサーバーと考えられます。

　ブラウザーでWordPressを開いてUpdraftPlusをインストールできますでしょうか。

質問2：

　エックスサーバーの「動作確認URL」で可能なのでしょうか。

質問3：

　さくらからXServerへの移行は，同じurlを望んでいます。https://motochan.info/wp 。しかし，WordPress簡単インストールを使って，https://motochan.info/wp を作成しますと，サクラレンタルサーバーに繋がってしまい，インストールしたエックスサーバーに入ることができず，https://motochan.info/wp2 と敢えてサブディレクトリーを変えて，インストールしました。これでは，さくらのものとurlが異なりますので，ぼくの希望とは多少ずれることになります。（後掲のごとく致し方ないかと思います）

質問4：

　エックスサーバーのワードプレスにUpdraftPlusにインストールができたとして，さらに，Google Driveのバックアップをインポートして復元することができたとして，その後，Search and Replace DBを使って，さくらのurlなどを置換することになりますが，このパネルでの

Replace 「移行前のurl」 with 「移行後のurl」

の部分で，「移行前のurl」=「移行後のurl」となって，実行ができないのではないか（できないでしょうね）と危惧しています。

質問5：

　このように考えますと，移行前と移行後では，urlを変えざる得ず，

「移行前のurl」：　https://motochan.info/wp ←サクラレンタルサーバー

「移行後のurl」：　https://motochan.info/wp2 ←エックスサーバー

とするしかないのか，と思われます。サブディレクトリーが異なれば，別のurlと考えることができれば問題ないかと？

質問6：

　移行作業をする際は，サクラレンタルサーバーからのバックアップはGoogle Driveに入っているので，ネームサーバーをエックスサーバーの方に移行しても問題ないというか，その方が上記の問題をクリアできるのではと思ったりしています。

　以上，だらだらと書かせていただきましたが，是非，お助けいただければと存じます。

2025年4月14日深夜

————————————————

　この質問のあと，追伸をしている。

————————————————

追伸

シャワーをかかっている時に考えたことをご連絡します。

エックスサーバーで，さくらで使用中のドメイン（url: https://motochan.info/wp）と同じものを，エックスサーバーで作成して，ネームサーバーをさわって，エックスサーバーの同名のurlを優先させれば，SSLも設定できるし，

エックスサーバーのWordPressでUpdraftPlusもインストールできるし，Search and Replace DBも使う必要がない，ということではありませんか？

ご指導ください。

2025年4月14日，3時40分AM。

————————————————

1.4 ファイルマネージャーで

　図6は，サーバーパネルのトップメニューの上端のメニューの「ファイルマネージャー」を起動させて/home/motochan.info/wp2 を覗いたものである。図6の左ペーンでみると，motochan.infoの一段下位ディレクトリーに，public_htmlがあり，その下位にwp/, wp2/が見える。wp/は一旦作成して，1.1 XServer提供の簡単インストール，で用意されている機能で削除したものである。ファイルマネージャーではwp/フォルダは削除できない。

　CommanderOneでこのフォルダを削除できるであろうが触らない方がいいように思う。サポートから先ほどお返事を得て，wp2/を削除し，wp/に再度，WordPressをインストールするつもりである。

2. サポートから回答 2025年4月14日

　「1.3 サポートに質問」の回答があった。

平素は当サービスをご利用いただき誠にありがとうございます。
エックスサーバーサポート xx と申します。

XServerアカウントID　:　xx
お問合せ番号 　　　　:　xx

お忙しい中、ご返信をいただきましてありがとうございます。

それぞれのご質問について、ご案内をいたします。

まず、ご質問1～3について、
ネームサーバー変更前（ドメインが現在のサーバーを参照している状態）で
エックスサーバー側のWordPressを同一ドメインで操作されたい場合、
お客様のご利用端末の「hostsファイル」を編集いただくことで、
お客様の端末でのみ、ドメインのWEBサイトがエックスサーバーを
参照するよう設定いただくことが可能です。

詳細は以下のページをご参考ください。

————————————————————
▼マニュアル：WordPressなどのプログラムを使ったサイトの動作を確認する方法
https://www.xserver.ne.jp/manual/man_domain_checkproxy.php#link-previous-c
————————————————————

なお、WordPressのWEBサイトについては
動作確認URLでの確認ができません。

※　動作確認URLは、単純なHTMLのWEBサイトなど、
　　静的コンテンツのみ対応しております。

恐れ入りますが、エックスサーバー側へ同一ドメインでWordPressを
インストールいただき、hostsファイルを編集いただく形で
WEBサイトをご確認くださいますようお願い申し上げます。

上述のご対応にて、質問4～5についてもご解決いただけるかと存じますので、
ご確認くださいますと幸いでございます。

質問6、ならびに、2通目のメールでご連絡いただいた
ネームサーバーのご変更については、
hostsファイルを編集いただき、同一ドメインのWEBサイトについて
エックスサーバー上での構築・動作検証完了後に、
ご対応いただければと存じます。

他社サーバーからエックスサーバーへのサーバーの移転手順については
以下のページで一連の流れをご案内しておりますので、
こちらについても併せてご参考くださいますと幸いでございます。

————————————————————
▼サーバー移転手順
https://www.xserver.ne.jp/order/order_transfer_server.php
————————————————————

何かご不明な点がございましたら、お気軽にお問い合わせください。

何卒、よろしくお願い申し上げます。

3. 回答を踏まえて

上記回答のなかの次のアドバイスを実行してみよう。

————————————————

恐れ入りますが、エックスサーバー側へ同一ドメインでWordPressを
インストールいただき、hostsファイルを編集いただく形で
WEBサイトをご確認くださいますようお願い申し上げます。

————————————————

3.1 改めてさくらのWordPressサイトをXServerに

　とにかく，簡単に実行できるところから。wp/2を削除して，改めて，wp/を作成した。さくらのWordPressの情報と一致させた。サイト名，ユーザー名，パスワードなど。プラグイン CloudSecure WP Securityをデフォルトで選択したままにした。移行完了までのリスクを考慮したためである。UpdraftPlusを利用してのbackupファイルのアップロードと復元に問題がでるかもしれない。その場合は一時，deactivateすれば良いだろう。簡単インストールが４回目ゆえだろう，データベース名は，サーバーID名.wp4となっている。それに，エックスサーバーのお仕着せでWPは日本語版6.7だ。英語版の方が直接的で快適であったが仕方がない。さくらからのドメイン移行のなか，移行プロセスをエックスサーバーに頼っているから仕方がない。

　ファイルマネージャーでみると，wp2/は残っているが空っぽだ。wp/に新たにWordPress関連ファイル群が入っている。今日の日付のファイルは，地のディレクトリーでは，.htaccess (権限644)，wp-config.php (権限600)だけ，wp-content/では，plugins, themes, upgrade (三つとも権限755)である。

3.2 hostsファイル編集後にwebサイト確認

　この機能の役割を知るために。意味なしと思いつつ試行してみたい。

3.2.a hostsファイルの一時的変更

　図7〜9に，macOS用ファイルをファインダーで操作した過程を示している。

　/etc/hostsのファイルを操作したプロセスを示す。操作にログインパスワードが必要である。

3.2.b このmacのみでWordPressの操作が可能

　この macのブラウザーで，http://motochan.info/wp，と入力すると，図10のようにテーマLightningが表示される。http://motochan.info/wp/wp-adminを実行すると，さくらのWordPressで使用しているぼくが設定したユーザー名とパスワードで，図11のようにダッシュボードにログインできる。データベース更新，WordPressやテーマの最新バージョンも取得して更新できる。

　懸案のプラグインUpdraftPlusもダウンロード，インストールができるのである。インストールして有効化activateした。もちろんバックアップはしていない。図10〜12をデータベース負荷削減のため削除。図10にテーマLightningのトップ画面，図11にはhttp://xxxx.info/wp/wp-admin/での管理画面，図12にはUpdraftPlusのインストール画面。

・UpdraftPlus で謳われている移行情報：

　この無料版の UpdraftPlus を使用すると、WordPress サイトを別の Web ホスト、サーバー、またはドメインに簡単に移行できます。

移行するには、データベース、プラグイン、テーマなどをソースサイトからダウンロードし、移行先サイトにアップロードするだけです。

　移行時には、組み込みの検索置換エンジンが古い文字列を識別し、新しい場所を反映するように置換します。UpdraftPlus は、時間を節約し、手作業による移行に伴うリンク切れやファイル紛失のリスクを軽減します。

・実際には：

　UpdraftPlusのメニューを見ると，この移行情報が明記されず，有料版購入を誘っている。$70 (x 150=10,500円)/年である。移行１回で良いので年間契約は不要である。

4. UpdraftPlusによるドメイン移行

　どうもできそうだ。UpdraftPlusでWordPressサイトをバックアップ＆リストアする方法 には無料版での移行法の概略が記されていた。リモートストレージ例はDropBoxだったがぼくはGoogle Driveだ。

　XServerの動作確認URLでの，http://motochan.info/wp のWordPress日本語版に無料版UpdraftPlusをインストールして，このサイトにGoogle Driveにあるさくらレンタルサーバーのhttps://motochan.info/wpのApr. 14（昨日夕）のバックアップファイルをアップロードする作業を実施した。その手順を述べる。

4.1 無料版UpdraftPlusでリモートストレージGoogle Driveのバックアップファイル群をスキャニング

　UpdraftPlusの設定タブの画面を五分割して並べる。図13〜17。

　図18はGoogle Driveフォルダー　My Drive > UpdraftPlus，の圧縮ファイル群の一部である。トータル38filesで，uploads 1-34 zip，themes.zip，plugins.zip，others.zip，db.gzである。
　データベースファイルのみ-gz圧縮ファイルである。すでに述べたようにこれだけでも解凍するとテキストだけなのに3GBもある。

　リモートストレージstorageのうち，図14に見えるように，Google Driveを選択した。バックアップに含めるファイルはすべてである。その目的達成のために１カ所追加したので，図17に見える「変更を保存」ボタンをタップした。それに反応して現れたのが図19のメッセージである。次に図14の「Googleでログイン」ボタンをタップして現れたのが図20である。

　UpdraftPlusがGoogle Driveにsign inする過程を図21〜23に示す。ここまではGoogle Driveでの認証過程（スキャニング）である。

4.2 Google Driveのバックアップファイルをhttp://motochan.info/wp にアップロード

　図23のメッセージにあるように，http://motochan.info/wpのUpdraftPlusでの作業になる。UpdraftPlusはGoogle Driveのバックアップファイル群を把握したのである。

　Google Driveからhttp://motochan.info/wpのUpdraftPlusでの作業が続く。UpdraftPlus > バックアップ/復元のパネル（図24, 25）の下部（図25）を見ると，「既存のバックアップ（0）」の行の次に，「他のタスク」として，三つのリンクが設定されている。その最後の「リモートストレージを再スキャン Rescan remote storage」を選択する。

　図26は期待したものなので問題ない。図27ではサイトへのアップロードに使用するバックアップ日を選ぶものである。ぼくの目的ではもちろん複数日を選択する意味はない。図27最下部の「すべてを選択」をすると全5日分が選ばれる。なお，Sep. 26, 2024のテーマがなぜ，リストされているのか，わからない。

　で，図27のAug. 14, 2025の行右端の「復元」ボタンをクリックすることになる。この行には他と同様，データベース〜その他の枠が見えるが，ここで選択はできない。単にメニュー表示に過ぎないのである。図28では復元するコンポーネントが表示されており，図29ではぼくが全部をチェックしたところである。

　まあ，当然ながら全部のコンポーネントを選択するのであるが，結果的にはすべてをアップロードした段階でエラーが出て，達成できなかった。エラーの原因は時間切れのようなので，分割してアップロードをすべきと考えている。図30はアップロードの過程の一場面で，図31はアップロード終了後のエラー表示である。

　

　図32の表示から抜け出すためにはキャンセルするしかない。

　updraft_send_command: error: error (Internal Server Error)

　図33の表示では，赤い「削除」ボタンしかないだろう。図34では，UpdraftPlusによるhttp://motochan.info/wpへの復元結果を削除するのであるが，「リモートストレージからも削除」のチェックを外さないといけない。図35ではその選択を外して，「削除」を実行することになる。

　図36には，削除結果が示されている。これでさっぱり。

4.3 エラーの原因は

　今日，午後5時頃に，ワードプレスから二通のメールが同時に届きました。
一通目　———————————————
2025/04/14 18:24:09 に xxxx がログインしました。

【ログイン情報】

・日時：2025/04/14 18:24:09

・ユーザー名：xxxx

・IPアドレス：xxxxxxxxxxxxxxxxxxxxxxxx

・リファラー：xxxxxxxxxxxx

・ユーザーエージェント：Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) xxxxxxxxxxxxxxxxxxxxxxxx

—
CloudSecure WP Security
————————————————

二通目————————————————
2025/04/15 00:42:16 にサーバーエラーが発生しました。

【サーバーエラー情報】

・エラータイプ：E_ERROR

・エラーメッセージ：Maximum execution time of 240 seconds exceeded

・エラー箇所：xxxxxxx updraftplus.php:5282

—
CloudSecure WP Security
————————————————

4.3.a CloudSecure WP Securityをinactiveに

　もちろん，セキュリティの観点から種々削除しているが幾つか気づくことがあった。一通目のログイン時間であるが，hostsを編集して，「動作確認URL」機能を使ってmacでログインした時間であるが，Apple M2チップなのに，Intelとなっている。両方のメールに，CloudSecure WP Security，の認証があり，これはエックスサーバーで簡単WordPressインストールにデフォルトで入っていたものであり，これは，inactivateした方がいいだろう。

追記：　2025年4月16日：　上記の二通のエラーメッセージを見ると，「CloudSecure WP Security」の役割が侵入をリジェクトすることではなく，挙動を報告することではないかと想像した。

4.3.b 実行制限時間を延長

・エラー箇所：xxxxxxx updraftplus.php:5282

　Perplexityによれば，主にサーバー容量不足やプラグインの破損、ストレージの問題などが原因で発生することが多いです。まずはサーバーやストレージの空き容量を確認し、プラグインの再インストールや不要ファイルの削除を試してください。それでも解決しない場合は、UpdraftPlusのログファイルを確認し、エラー内容を特定してください，とあるが，この指摘はいずれも当たらないと思う。

・エラータイプ：E_ERROR

　Perplexityによれば，UpdraftPlusの「E_ERROR」は、プラグインや環境の不整合による「致命的エラー」です。エラーメッセージをもとに、バージョンアップや再インストール、リカバリーモードの活用などで対処してください。

・エラーメッセージ：Maximum execution time of 240 seconds exceeded

　Perplexityによれば，UpdraftPlusプラグインの処理（バックアップや復元など）に240秒（4分）以上かかり、PHPの実行時間制限を超えたために処理が強制終了されたことを示すエラーです。
　• PHPの実行時間制限（max_execution_time）
サーバーのPHP設定では、1つのスクリプトが実行できる最大時間（例：240秒）が決められています。これを超えると、セキュリティやサーバー負荷防止のため、処理が自動的に中断されます。

Perplexityにお聞きしたら次のようだ。wp-config.phpファイルで，

————————————————
php
//さまざまな設定や定数が並んでいる部分の下に

define(‘WP_MAX_EXECUTION_TIME’, 300);//最大実行時間を300秒に設定

/* That’s all, stop editing! Happy publishing. */

コメント　/* That’s all, stop editing! Happy publishing. */　より上にdefine(‘WP_MAX_EXECUTION_TIME’, 300);　を追加することで、WordPressの設定として正しく認識されます。追加後はファイルを保存し、サーバーにアップロードしてください。

————————————————

4.3.c コンポーネントを分けてアップロード

　・エラーメッセージ：Maximum execution time of 240 seconds exceeded

このメッセージをどう考えたら良いのか。240/60=4分間だ。実際には20分ほど動いていた。

　テーマとプラグインとその他，データベース，アップロード

という三分割でどうだろうか。とにかく，アップロードが34個の圧縮ファイルからなっているので最も重い。クリアするかだな。34個のファイルを適当に分割できれば一番いいのだけど？

4.3.d WordPressとテーマのバージョンの統一

　図37のように，さくらのWordPressは英語版v.6.7.2である。エックスサーバーの簡単WordPressインストールは日本語版だけに対応している。バージョンが同じでも英語版と日本語版の違いは影響ないだろうか。

　ぼくのこのサイトは基本的に英語で発信する意気込みであったが読者はどうするのかという問題もあった。結果としては操作だけ英語で公開は日本語という形になっている。Pluginsは英語版の方が圧倒的に豊富なのだからと思ってはみても，実際は日本人が使っているもので十分である。

　図37には，reinstall 6.7.2-ja が見える。日本語化してしまった方がいいだろう？

　テーマはさくらでは，Lightningも最新 15.29.6である。UpdraftPlusも最新で1.25.3。

　エックスサーバーの方も改めて確認する必要がある。昨日にアップデートした時には，v.6.7.2-jaであった。hostsの書き換えを昨日実施して，ブラウザーでhttp://motochan.info/wpにアクセスできたが，今朝はできなかった。hostsファイルを開いたままにして，ブラウザートップのurl窓でhttp://motochan.info/wp を入力すると起動できた。

　図38,39はhttp://motochan.info/wp の画面で，図38はUpdraftPlusのバージョン1.25.3，図39ではWordPressのバージョンが6.7.2であり，v.6.7.2-jaへの再インストールのオプションが見える。WordPressのバージョンは，さくらもエックスサーバーも同じではないのか。英語表記と日本語表記の違いがあるが。エックスサーバーのWordPressには日本語パッチが付属しているのではと思う。

　UpdraftPlusのバックアップと復元はシステムに影響を与えないので，エックスサーバーでは日本語表記になる可能性は高いと思う。

　CommanderOneでwp-config.phpも覗いた方がいいだろう。

以上，2025年4月15, 16日。

5. 課題の整理

　結局？　一つまたは複数のバックアップファイルのアップロードの際に，4分間を超えてしまったということのようだ。

　Perplexityにお尋ねした。

5.1 UpdraftPlusの復元の際は負荷が大きい

Perplexityの回答：

　UpdraftPlusで「バックアップ時には時間制限（max_execution_time）をクリアできているのに、復元時には時間制限をクリアできない」現象が起こる理由は、バックアップ処理と復元処理の仕組みやサーバー負荷の違いにあります。

　復元処理の一括性：　復元時は、特にデータベースのリストアや大きなファイルの展開など、一度に多くの処理を行うため、PHPの実行時間制限（例：240秒）を超えやすいです。

　対策：
• PHPのmax_execution_timeを延長する（例：300秒や600秒に設定）。
• バックアップファイルの分割サイズを小さくすることで、復元時の1回あたりの処理量を減らす。

5.2 UpdraftPlusバックアップファイルの分割サイズを小さくするというのは？

　Perplexityの記述をみて想像したことがある。max_execution_timeは，30分間ほどのバックアップや復元の工程では何回かに分けられている。バックアップファイルは現在，38個であるが，この38個の一つ一つに関わって，max_execution_timeが評価されているようである。

　Google Driveのバックアップファイルの記録をこれからその視点で参照してみた。ファイル名は例えば，backup_2025-04-15-1636_YamatoGeographer_8976f0ebea43-uploads3とある。

　バックアップされたファイルは上ほど新しいものになっている。backup_2025-04-15-1636_YamatoGeographerを冠するファイル群は，下から，-db.gz（gzip），-others.zip，………。ファイルそれぞれの右端に見える「⋮ (more actions)」をタップし，File information > Detailsで，Activityパネルを開くと，you uploaded an itemとして時刻が見える。

表：　Google Driveの配列通り新しいファイルは上方に配置されているが，そのうち-dbから-uploads3までを並べる。

compressed file name	file size (MB)	uploaded time
-uploads3.zip	394.1	4:38PM
-uploads2.zip	397.5	4:37PM
-uploads.zip	402.8	4:37PM
-themes.zip	7	4:36PM
-plugins.zip	51.4	4:36PM
-others.zip	2.2	4:54PM
-db.gz	826.6	4:58PM

　この表から見ると，UpdraftPlusによるバックアップは午後4時36分に始まって（ファイル名に含まれる），-plugins.zip，-themes.zip, -uploads.zip，-uploads2.zip，-uploads3.zip，・・・・，と続いてゆく。-uploads??.zipについては，1分前後でコピーが終了しているようである。-uploads??.zipについてはファイルの分割が成功しているようだ。

　-uploads??.zipが制限時間を超えているとぼくは思っていたが誤りのようである。-uploads??.zip以外でも，-db.gz以外はファイルサイズは小さい。

　結局，-db.gzが問題だ。-db.gzのアップロード完了時間は4:58PMと，全圧縮ファイルのうちで最も遅い時間になっている。にもかかわらず，最も下方に配置されているのである。これは何を意味するのか。おそらく，dbはバックアップ作業の開始から始まってもっとも遅く終了したことを意味している。WordPressのファイル構造からそういう手順が必要なのだろう。

　繰り返すが，-db.gzが問題である。UpdraftPlusによって，php通信の240秒=4分以内が実現していたのであるが，さて，uploadではどういう工夫がなされているのか？

　Perplexityによれば，

————————————————

　UpdraftPlusがバックアップ作成過程でデータベースをどのような時間配分で圧縮しているかについて、公式ドキュメントや一般的な解説では「具体的な時間配分（例：何分ごとに分割処理する等）」は公開されていません。

　UpdraftPlusはスケジュールに従い、データベース全体を一度にエクスポート・圧縮して保存します。
• データベースバックアップは1ファイル単位で圧縮され、ファイルバックアップのような分割処理や細かな時間配分はありません。

————————————————

とある。理解できない。ぼくのdbファイルは解凍すると3GBにも達する。そしてバックアップに時間もかかっている。

5.3 FTPで実行？

Perplexityに，

UpdraftPlusで作成されたファイルサイズの大きなデータベースのバックアップファイルをWordPressにアップロードするための手続きを教えてください。

としたら，次のような回答が。

————————————————

補足：アップロードがうまくいかない場合
• FTPでのアップロード
WordPress管理画面経由でアップロードできない場合は、FTPクライアント（FileZillaなど）でwp-content/updraftフォルダに直接バックアップファイルをアップロードしてください。その後、UpdraftPlusの「既存のバックアップを再スキャン」機能を使うと、アップロードしたファイルが認識されます。

————————————————

Perplexityは取材サイトは次のようだ：

a. UpdraftPlusを使ったWordPressの自動バックアップと復元方法 の，https://olein-design.com/blog/all-about-updraftplus#co-index-35

b. WordPressで3GBファイルも怖くない！大容量ファイルアップロード完全攻略ガイド

　b-web情報には，これまでの疑問を解消してくれる正攻法が記されている。簡潔に書かれているので結構ではあるが，php言語に無知なぼくの地平では，a-web情報がわかりやすい。

　なお，a-web情報は，有料版へ誘導する意図が感じられる。サイト移行は有料版としているが，実際は無料版でできる。

　では，今後の手順を記したい。

0　ぼくのmacの残容量は300GBある。Google Driveのバックアップファイルは最大60GBなので，ダウンロードに問題はない。

1　Google Driveのmy Drive > UpdraftPlusフォルダーごとダウンロードはできないだろうから，38ファイルを個々に選択してダウンロードしよう。

2　CommandOneで，独自ドメイン motochan.info/wpのwp-content/updraftフォルダーにmacのデスクトップから38個のファイルを少しずつアップロードしようと思う。

ここまでは問題なく進むと思われる。

Perplexityでは，「その後、UpdraftPlusの「既存のバックアップを再スキャン」機能を使うと、アップロードしたファイルが認識されます。」となる。

この手法は，本ページの「4. ドメイン移行　第１回」を実行すれば良いのだが。

　ただ，ドメイン motochan.info/wp 内での作業なので，全バックアップファイルのアップロード，復元，という作業は進むかもしれないが，phpのバリアで進めない場合，b-web情報を実行せざるを得ないかもしれない。

6. FTP援用してのドメイン移行

6.1 Google Driveからmacへ

　ぼくのmacの残容量は300GBある。Google Driveのバックアップファイルは最大60GBなので，ダウンロードに問題はない。直接，ダウンロードフォルダにダウンロードされる。図40は38ファイルを-db.gz，-others.zip, -plugins.zip, -theme.zip, -uploads.zip〜-uploads34.zipの順でダウンロードしている様子を示している。

6.2 CommandOneでupload

　CommanderOneでのFTP新規サイトとしてXServerを登録する必要があった。新規接続のパネルで。

名称：Xserver，タイプ：FTP，サーバー（FTPサーバー，ホスト名）：svxxxx.xserver.jp，ログイン（ユーザー，アカウント名）：xxxxxxx，パスワード（サーバーパスワードと同じ）：xxxxxxxxxx，同時接続の数制限：5，モード：受け身，リモートパス：空欄。

　CommandOneで，独自ドメイン motochan.info/wpのwp-content/updraftフォルダーにmacのデスクトップから38個のファイルを1ファイルずつアップロードした。パッドでのファイル選択が結構難しく，2年ぶりぐらいか，ブルーツゥースのマウスを接続して，マウスでの選択に替えて，ファイル選択が楽になった。

　図41には，macのDownload/ からupdraft/ へ38圧縮ファイルをupload寸前のCommanderOneなどのウィンドウを示している。XServer > motochan.info > public_html > wp > wp-content > updraft，というパスができている。WordPress関係のファイルは wp/ に入っている。updraft/ フォルダーは無料プラグイン UpdraftPlus をインストールした段階で作成されたものである。

　図42には，macのDownload/ からupdraft/ へdb圧縮ファイルのupload開始前を示している。EBはone billion gigabytesであり，このXServerの容量と関係があるのだろう。エックスサーバーのスタンダードでは600GBが与えられている。

　図43では最も重い-db.gz圧縮ファイルをコピーしている様子である。残り < 1分，とあるが，事実，このファイルは1分以内にアップロードできたのである。

　図44には，macのDownload/ からupdraft/ へdb圧縮ファイルがすべてuploadされた結果を示している。対照したが名称とサイズは一致している。Google Driveからmacのダウンロードフォルダーにダウンロードした際には多少サイズが増える傾向があったが，macからサーバーへはサイズの違いが生じなかった。記憶媒体が同質の可能性がある。

　このようにFTPでサーバーに全バックアップファイルをアップロードしてみて，ぼくに幾つかの想定が生まれた。

　すでに実行してエラーが出てこの実行で得られた関係ファイルを指示に従って削除したのであるが，この updraft/ フォルダーに入っていたのではないだろうか。その意味では，UpdraftPlusがアップロードする手間を省いたことになる。「図36　削除結果」のメッセージからもそう理解される。リモートストレージ Google Drive からupdraft/ フォルダーへのコピーでは結局，「エラーメッセージ：Maximum execution time of 240 seconds exceeded」が生じなかったのではないだろうか。

　つまり，ぼくがCommaderOneで実行したことは，エラー回避に繋がらないのではないかということである。

6.3 UpdraftPlusによるバックアップのhttp://motochan.info/wpへ復元

　上記のぼくの想定からすると，FTP援用作業はエラー回避に意味がないということになるが，とにかく，標記の作業を進めてみないとb-web情報を実行する必要性があるかどうかわからない。なお，Perplexityによれば，「UpdraftPlusでバックアップから復元する場合、phpMyAdminでデータベースをインポートする必要はありません。」とある。

　Perplexityに尋ねて，ぼくのこの現状での手順を確認した。図45ではUpdraftPlusのメニューの移行/複製，を選択する。そして，前回のGoogle Drive選択状態がそのままなので，この選択状態をGoogle Driveのボタンをクリックして，選択を解除した。図46は，UpdraftPlus > 設定 > UpdraftPlus Backup/Restore で，バックアップ/復元 タブの，既存のバックアップの，
他のタスク:の，三つのリンクのうち，2番目の「新規バックアップ一式のためにローカルフォルダーを再スキャン」を選択した。図47では，この再スキャンが実行されて，ぼくがCommanderOneでアップロードしたバックアップが認知され，図46ではバックアップ数9なのだが，図47では10になっている。既存のバックアップの数が9から10になって，最上段に，Apr.16, 2025 16:29が出現しているのである。そして，この行の，「復元」ボタンをクリックした。

　そして図48のように，全コンポーネントを選択した。

　図49は異なるphpバージョン間の復元に関わる警告である。

　図49の左下隅のキャンセルボタンをクリックした。そしてPerplxityさんにお尋ねした。

————————————————
WordPressのPHPバージョンを確認する主な方法は以下の3つです。

1. WordPress管理画面から確認する方法

   1. WordPressの管理画面にログインします。
   2. 左メニューから「ツール」→「サイトヘルス」を選択。
   3. 「サイトヘルス」画面で「情報」タブを開き、さらに「サーバー」セクションを探します。
   4. そこに「PHPバージョン」が表示されています。

————————————————

　移行元のさくらでは，8.3.8 (Supports 64bit values)で，エックスサーバーは8.2.22である。サーバー会社の方針なのでphpを自分の思いでアップデートはできないと思う。Perplexityに尋ねた。

————————————————

下位バージョンへの移行は原則可能
PHP 8.3と8.2は互換性が高く、WordPressやUpdraftPlus自体もPHP 8.2以上を公式にサポートしています。バックアップファイル（データベースやメディア、テーマ、プラグイン等）はPHPバージョンに依存せず、WordPressの構造データとして保存されるため、PHP 8.3→8.2の移行自体でデータが壊れることはありません。

————————————————

　前述のように，復元をキャンセルしたのであるが，前ページに戻っている状態だったので，再度，復元を選択した。この時刻が19:15である。図50は開始後1分ぐらいの時だ。認証は☑️，データベース復元中。この時は快調だ。

　図51は19:20頃。つまり，4分越えで，データベースの処理が中断されたようだ。認証，データペース，には☑️。プラグイン，テーマ，アップロード，その他，クリーニング，には❌。完了には☑️。

　図51ではデータベースの処理は済んだように見えるが，ログファイルを見るとそうではない。Perplexityにお尋ねすると❌はできていないということ。

　Perplexityにお尋ねした。「バックアップの復元が完了しない場合の対処法は」。この回答はぼくの状況には対応しないようだ。

　対処法を別途尋ねた回答で，次が当たっていると思われる。

サーバーの権限や設定を確認：　ファイルの書き込み権限（パーミッション）が適切か、PHPの実行時間やメモリ制限が十分か確認し、必要に応じてサーバー設定を調整してください。

　メンテナンス情報のなかに，

————————————————

0000.373 () Database successfully unpacked
0000.373 () データベースを復元しています…
(大きいサイトは時間がかかります – タイムアウトが起こった (ホスティング会社があなたのリソースを制限しているときに起こる) 場合、 phpMyAdmin など別の方法で復元したほうがいいでしょう。

————————————————

とある。かなりサイズが大きいことを認識しているということである。

以上，2025年4月18日。日が明けたところ。

6.4 サーバー設定の調整を学ぶ

　Google DriveからWordPressにアップロードする方式では，「エラーメッセージ：Maximum execution time of 240 seconds exceeded」が出て，図50に見られるような認証画面までには至らなかった。FTPを通じてWordPressのサイト内にバックアップファイル（38個）を配置したことは功を奏したのである。

　とはいえ，残念ながら，WordPressはデータベースファイルの取り込みに失敗した。となると，phpファイルを編集せざるを得ない。

　なお，6.3の試行では失敗したが，Perplexityによれば，上書きされるので，失敗自体は問題がないとのことである。

　Perplexityに質問した「サーバー設定の変更には，php.iniと.htaccessとwp-config.phpのすべてを変更する必要がありますか？」。

————————————————

サーバー設定の変更において、php.ini、.htaccess、wp-config.phpのすべてを同時に変更する必要があるわけではありません。どのファイルを編集するかは、変更したい内容によって異なります。

各ファイルの役割が紹介されている。

　Perplexityに質問した：「UpdraftPlusによるバックアップからのサイト復元にだけにmax_execution_timeなどの増大をするには，php.ini以外の変更で可能なのでしょうか？」

————————————————

php.ini以外でUpdraftPlusによるバックアップからのサイト復元時だけmax_execution_timeなどの値を一時的に増やす方法は、以下の2つが現実的です。

1. .htaccessファイルでの設定
   Apacheサーバー環境の場合、.htaccessファイルに以下のような記述を追加することで、max_execution_timeなどPHPの実行環境設定を上書きできます

2. wp-config.phpでの設定
   wp-config.phpに@ini_set()関数を使って直接設定値を上書きする方法もあります

注意点
• これらの方法はサーバー側の制限（上限値）によっては反映されない場合があります。
• サーバーによっては.htaccessやwp-config.phpでの上書きを許可していない場合もあるため、反映されない場合はサーバー管理画面やphp.iniでの設定が必要です。

————————————————

　さらに，Perplexityに質問した。「サーバーによっては.htaccessやwp-config.phpでの上書きを許可していない場合があるとのことですが，サーバー管理画面やphp.iniでの設定は一ユーザーとして可能なのでしょうか。」

————————————————

　一般的なレンタルサーバー（エックスサーバー、さくらのレンタルサーバなど）では、一ユーザーとしてサーバー管理画面やphp.iniでの設定変更が可能な範囲が用意されています。
　サーバー管理画面・php.iniでの設定について：
• 多くのレンタルサーバーでは、ユーザーごとにphp.iniの設定変更ができる専用画面が提供されています。
例：エックスサーバーの「サーバーパネル」や、さくらのレンタルサーバの「サーバコントロールパネル」など。
• php.iniの直接編集や、管理画面からの設定変更で、memory_limit、max_execution_time、upload_max_filesizeなど主要なPHP設定を変更できます。
• 一部の項目はサーバー管理者権限が必要で、ユーザー側で変更できない場合もあります。

————————————————

　a-web情報を参照し，2件をピックアップする。

2-1. PHP設定の変更

PHPの設定ファイル（通常はphp.ini）で以下のパラメータを大容量ファイルに対応できるよう変更します。
例として、3GBに対応させる設定は下記のようになります：

; php.ini の設定例
upload_max_filesize = 3G
post_max_size = 3G
memory_limit = 4G
max_execution_time = 0    ; 制限なし（または十分大きな値に設定）
max_input_time = 0        ; 制限なし

※ 注意
・upload_max_filesize は1ファイル当たりの上限です。
・post_max_size はフォーム全体（アップロード含む）の最大サイズ。
・実際に設定を変更後、Webサーバーの再起動が必要となる場合があるので、再起動も忘れずに行いましょう。

5. コマンドラインでの確認方法 🖥️

サーバー設定を変更した後、変更が反映されているかを確認するために、簡単なPHPスクリプトを用意しましょう。

————————————————

<?php
// phpinfo.php
phpinfo();
?>
————————————————

このスクリプトをサーバーに配置してWebブラウザからアクセスすることで、upload_max_filesize や post_max_size などの値が希望通りになっているか確認できます，とある。

6.5 php.iniの設定

　結局，php.iniの編集に限定して作業を進めることにする。図52はXServerのサーバーパネルにログインしたところである。その左ペーンのPHPの「php.ini」設定を選択した。その結果が図53である。新規のWordPressをインストールしているドメインはmotochan.infoで，各種設定の「直接編集」を選択すると，図54でphp.iniの編集画面が現れる。

　ここで，max_execution_time = 180 を，300にした。Google DriveからWordPressにアップロードする方式では，「エラーメッセージ：Maximum execution time of 240 seconds exceeded」が出たのであるが，エックスサーバーの初期値は180（3分間）であった。理由はわからない。300（5分間）が功を奏するかわからない。ゼロにすると無制限になるが，これはセキュリティの観点からするとリスクが高い。

　図53にmemory_limit = 1Gとなっており，これは変更できないようである。post_max_size = 1Gを4Gに，upload_max_filesize = 1Gを4Gに増やした。この段階で有効になるかはわからなかった。編集後，「設定する」ボタンをクリックした。

　図55では「PHP ver 切替」を見ている。PHP 8.2.22（推奨）となっている。PHP 8.3.10の選択も可能である。さくらが採用しているバージョンである。高いバージョンから低いバージョンに移行することについては問題が無いようであり，エックスサーバーについては，PHP 8.2.22（推奨）から変更しないこととしよう。

　php.iniの変更が生きているのか，システムに反映されているのか，知りたいところである。php.iniを触った場合，これを反映させるために，WordPressの再起動が推奨されている。再起動した。

　反映されたのかどうかを知るのは，phpinfo.phpを作成して，XServer/motochan.info/public_html/wpにコピペする必要がある。

　phpinfo.phpのファイルには，

<?php

// phpinfo.php

phpinfo();

?>

を書き込んだphpファイルを作成する必要がある。エディター Visual Studio Code で作成する必要がある。macのテキストエディットやCoEditorでは作成できない。ファイル名をphpinfo.phpとする。ぼくの環境では32バイトになる。図56，57に見えるphpinfo.phpは未完のものであった。

　さて，phpinfo.phpを使って，php.iniの改変が実現しているかどうか，見ることになる。一般にはブラウザのアドレスバーに
http://あなたのドメイン/phpinfo.php

と入力すればアクセスできるとあるが，そうではない。パスでは次のようである。でも，404 File not foundとなる。

http://motochan.info/public_html/wp/phpinfo.php

　正しくは，http://motochan.info/wp/phpinfo.php であった。

　図58〜60がぼくの関心の部分の上，中，下である。幸いなるかな，図54のphp.ini設定編集結果が完全に反映されているのである。

　これで一応，懸案は片付いた。

　ちょっと休憩。

6.6 三度目の正直だったが

　図61で見られるように，php.iniによるphp環境の改変後も図50と同じ結果になった。ファイルサイズや実行時間を延長しても効果がなかった。PostとUploadのファイルサイズについては，規定値の1Gを4Gに変えた。データベースファイルは解凍前は　865.8MB < 1G，解凍後は3.02 G。実施過程からすると解凍後のファイルサイズは関係がない可能性が高い。

　どうもActivity logに違いが出ていない。execution timeの問題では無いかもしれないが，この可能性が高いと思う。つまり300秒では足りないと。900秒に増やしてみたいと思っている。

　さて，データベースの復元だけを図62のように選択した。なお，このWebページの上の方では日本語表示になっているが，第２回目の中途半端な復元の影響でさくらのWordPressが反映している。
　図63には第３回目のデータベースのみの復元の実行結果がみえる。ただ，必要と思われるcleaningに失敗しているようだ。databaseに☑️が入っていても不完全と考えられるのである。図61と図63の右手のactivity logは同じ場所で「中断」しているようだ。

　また，このページから管理画面に戻ろうとするが，図64のように，「現在メンテナンスのため，しばらくの間ご利用いただけません。」としてこの画面から回避できない。図61の際には少し待って，WordPressの管理画面に入ることができたのだが。

　そこでWordPressを（http://motochan.info/wp/）再起動した。図62にあたるメニュではデータベース以外を選択して実行した。調子よく済んで，図65のように，Restore successfully，が出た。

Return to UpdraftPlus configuration ボタンをクリックして管理画面に戻った。ウィジェットエリアをみたら図66のような表示。

　このエックスサーバーでの最新のブログを見ると，図67のように，図が表示されていない。画像のリンクに問題がある。さらにブログの設定したはずのcategoriesが消えている。

　Databaseの正常なインストールを実施する必要がある。いま，考え得るのは，execution timeを1500秒（25分）にしてみることか。

　Perplexityにお尋ねしてみた。「UpdraftPlusでWordPressを復元した際にblogのcategories情報が欠落した原因は，データベースの移行に問題があったと考えて良いのでしょうか？」

————————————————

　WordPressのカテゴリー情報は、データベース内のwp_termsやwp_term_taxonomyテーブルなどに保存されています。UpdraftPlusは、バックアップ・復元時にこのデータベース全体を扱いますが、何らかの理由でデータベースの復元が不完全だった場合、カテゴリー情報が欠落することがあります。

　よくある原因：
• データベースバックアップファイルが破損している、または一部しか復元されていない
• 復元時にエラー（例：Duplicate entryエラーやタイムアウト）が発生し、全データが正しくインポートされなかった
• 移行先のWordPressやプラグインのバージョン違いによる互換性問題
• データベースの一部テーブルだけが上書き・復元された
推奨される確認・対処：
• UpdraftPlusの復元ログやエラーメッセージを確認し、データベース復元に失敗やエラーがなかったかを調べる。
• 必要に応じて、データベースを一度クリア（初期化）してから再度バックアップを復元する。
• バックアップファイルが完全かどうか、サイズや中身を確認する。
• カテゴリー情報が含まれるテーブルがバックアップファイル内に存在しているか確認する。

————————————————

　ぼくの能力からすると，「データベースを一度クリア（初期化）してから再度バックアップを復元」か。Perplexityさんに質問：「データベースを一度クリア（初期化）してから再度バックアップを復元する方法を教えてください。」

————————————————

2. phpMyAdminでデータベースを手動で初期化する

   1. phpMyAdminにログイン
   2. 対象のWordPressデータベースを選択
   3. テーブル一覧で「すべて選択」し、「削除（Drop）」を選ぶ
   4. 確認画面で「はい」を押して削除
      → これでデータベースが空になります
   5. （必要に応じて）新規インストールやバックアップからの復元を実施

————————————————

Perplexityに質問：「エックスサーバーで， phpMyAdminにログイン，するには？」

————————————————

7. phpMyAdminでデータベースを削除そしてインストール

　図68はXServerのサーバーパネルにログインし，データベース > MySQL（マイ エスキューエル My Structure Query Language）設定を開いたところである。taniha.wp4に 「WordPress利用中」が表示されている。「アクセス権所有ユーザー」名は，taniha_wp4である。容量は，3031.3/5000 MB。3031.3MBは，ぼくのデータベースの容量に対応している。これとは別に，エックスサーバーのデータベース容量の最大はどうも5GBのようである。今後のぼくのWordPressのコンテンツの積み上げには限界があるようである。

　WordPressを複数運営するのもまずいので，コンテンツを他のウェブサイトに移動する必要性もあると感じる。固定ページの文は全部リンクだけにして，コンテンツそのものは他のウェブサイトに収納するのが適当かもしれない。他のウェブサイトというのは，motochan.siteになるだろう。Seamonkey + CommanderOneで作成メンテしてゆくかどうか。セキュリティの問題があるので，適当なWordPressの無料テーマを探すのもいいかも知れない。まだわからない。ユーザー名はtaniha_wp4であるが図69のパスワードがわからない。

　

　Perplexityさんによれば，「WordPressサイトの場合、「wp-config.php」ファイル内にMySQLユーザー名とパスワードが記載されています。」とあり，閲覧し，図70のように，データベース phpMyAdmin に入った。図71のように「データベース」タブを選んで，表の「taniha_wp4」をタップした。

。

　その結果が図72である。このリストの最下部には，「すべてをチェック」ボタンがある。それを実施した結果の一部が図73である。

　図74には，「外部キーのチェックを有効にする」のオプションがある。Perplexityに尋ねた「phpMyAdminでログインして，WordPressの不要なデータベースを選んで削除する際に，外部キーのチェックを有効，を選択した場合と，しない場合でどういう違いがあるのですか。」
————————————————

詳細：
• 有効の場合（チェックあり）
外部キー制約が働きます。たとえば、削除しようとしたテーブルが他のテーブルの外部キーとして参照されている場合、削除操作はエラーとなり実行できません。これは、データの整合性（リレーションの一貫性）を保つためです。
• 無効の場合（チェックなし）
外部キー制約を一時的に無効化し、削除を強制的に実行できます。参照関係があっても削除が成功しますが、参照元のテーブルに「存在しないデータを参照する」状態が発生し、データベースの整合性が損なわれるリスクがあります。

まとめ：
• 安全に整合性を保ちたい場合は「外部キーのチェックを有効」にしたまま削除してください。
• どうしても削除したい場合や、参照関係を気にしない場合のみ「無効」にして削除しますが、データベースの一貫性が崩れる可能性があるため注意が必要です。
一般的には、外部キーのチェックは有効のまま操作することが推奨されます。
————————————————
　で，図75のように，「外部キーのチェックを有効にする」のオプションにチェックを入れて，「はい」を実行した。

　その結果が図76である。図77では，taniha_wp4を選択した。オレンジ色に変わった。

　図78ではインポートタブを選択している。ここにphpタイムアウトの注意書きがあるので，図79ではmax_execution_time = 1000 (sec)にした。

　phpinfo.phpで確かめたら，図80のように反映されていた。それで，図78のインポートタブに戻って，「ファイルを選択」を実行した。macへのリンクしか現れず，macのdownloadsフォルダーにキープしていたバックアップファイルの-db.gzを図81のように選択した。

　図82のように，「インポートは正常に終了しました。」図82からログアウトした。これは必須だ。

　さて，http://motochan.info/wpのWordPressをまずはログアウトしたが，なぜか，これまで使えた動作確認urlが使えなくなった。それでサーバーパネルにアクセスして，ドメイン>動作確認URL>，そして，motochan.infoをドロップメニューで選択した。図83（19:36）では，反映待ちになっている。図84のように，2時間弱の後にあたる21:20頃には認証されたようだが，WordPressは対応しない。この方式ではWordPressには対応しないことが明記されている。hostsファイルの変更は生きている。この設定は問題が生じる可能性があるので図83の設定状況をOFFにした方がいいだろう。

以上，2025年4月20日。

補：動作確認urlの問題

　 Perplexityに尋ねた。「エックスサーバーで，データベースを更新したら，動作確認URL機能を使ってWordPressサイト http://sample.info/wp にアクセスできなくなった。対処法を教えてください。」

————————————————

1. phpMyAdminで「siteurl」と「home」を動作確認URLに変更

   1. エックスサーバーのサーバーパネルからphpMyAdminにログイン
   2. 対象のWordPressデータベースを選択
   3. wp_optionsテーブルを開く
   4. 「option_name」が「siteurl」と「home」の2つのレコードを探す
   5. それぞれ「option_value」を動作確認URL（例：http://●●●.xsrv.jp/wp など）に書き換える
   6. 変更を保存
      ※作業後は、独自ドメインへの切り替え時に再度元のURLに戻すのを忘れないでください。

————————————————

　エックスサーバーでは，wp_optionsにあたるものは，wpecdff9optionsであった。図85に見える。当初見つけることができず，図86のようにoptionsで検索した。

　図87のように，wpecdff9optionsを開いて，siteurlとhomeを見つけた。option valueは，移行元の https://motochan.info/wp/ であった。エックスサーバーではネームサーバーの確定が終わるまで，SSL化はできないが，移行後の環境に影響を受けていないのである。当然といえば当然である。ではMySQLの編集前までは，動作確認URLが機能したのであろうか。図88は編集過程を示している。’

　図89も編集過程で，図90は確定した結果，site名がhttp://motochan.info/wp/ になっている。このあと，図90の左上隅にみえるログアウトアイコンをクリックして，ログアウトする必要がある。

　エックスサーバーからもログアウトした。この過程を経ても，ブラウザーでエックスサーバー http://motochan.info/wp/に入ることができない。そこで，Google Chrome（図91）やFirefox（図93）などをセキュリティの設定を工夫したが全く見ることができなかったのである。ただ，Google Chromeでは，図92のような化けたサイトを見ることもあったのである。

補：諦めつつ

　以上の無駄な抵抗を踏まえて，今後の方針を考えてみたい。

0　UpdraftPlusの無料版と有料版の違いが何なのかを調べる。有料版がぼくの環境に資するものと考えた場合，独自ドメイmotochan.infoの初期化をした上で，簡単WordPressインストールをして，エックスサーバーの方へ有料版をインストールしてみよう，となるか。

1　今はもう，エックスサーバーのWordPressが見えない状態なので，初期化するしかない。

2　php.iniも破壊されているのであれば，UpdraftPlusの作業のための環境設定を再度，整える必要がある。

3　無料版または有料版のUpdraftPlusで，プラグイン+テーマ，データベース＋その他，データベース，で三分割して復元をすることになるな。

4　動作確認URLで確かめることになるが・・・・。

以上，19:32，2025年4月20日。

8. 無料版UpdraftPlusはサイト移行ができるか

8.1 UpdraftPlusに騙されていた時の思い

　Perplexityさんに質問「無料版UpdraftPlusではサイト移行ができないのですか？」

————————————————

　最新の情報によると、無料版UpdraftPlusでもサイト移行（別URLへのリストア）が可能になっています。かつては「無料版ではバックアップ元と同一URLでのみ復元可能」という制限がありましたが、現在は移行元サイトでバックアップを作成し、移行先サイトでそのバックアップを復元することで、異なるURL・ドメインへのサイト移行が無料版でも実行できます。
　ただし、データベース内のURL（siteurlやhomeなど）を新しいURLに合わせて手動で置換する作業が必要な場合があります。この作業を自動で安全に行いたい場合や、マルチサイト、より複雑な移行には有料版（Premium）が推奨されます。
　まとめ
• 無料版UpdraftPlusでも手順を踏めばサイト移行は可能です。
• URLの置換作業など一部手動対応が必要な場合があります。
• より簡単・安全に移行したい場合や追加機能が必要な場合は有料版を検討してください。

————————————————

　有料版UpdraftPlus（UpdraftPlus Premium）の料金は、1年目が70ドル（142.66*$70=9986円）で、2年目以降は42ドルです。このプランは「Personal」プランで、2サイトまで利用できます。

　Perplexityに尋ねた「有料版UpdraftPlus（UpdraftPlus Premium）が2サイトまで利用できるということであれば，サイト移行に利用する場合は，有料版UpdraftPlusを1本購入すれば良いのでしょうか？」

————————————————

UpdraftPlus Premiumのライセンスは「インストールできるWordPressサイト数」で管理されており、Personalプランなら2サイトまでインストール・有効化できます。
• サイト移行時は、移行元と移行先の両方に有料版UpdraftPlusをインストールして有効化する必要があります。
• 1本のライセンスで2サイト分まで対応できるので、移行元・移行先それぞれ1サイトずつであれば追加購入は不要です。

————————————————

　Perplexityに尋ねた「有料版UpdraftPlusを使って一つのサイトを移行して後，無効化して，別のサイトの移行のために有効化して使えますか。」

————————————————

注意点：
• 同時に有効化できるサイト数が上限なので、移行元・移行先の両方で同時に使う場合は、ライセンス数分必要です。
• 作業が終わったサイトで「無効化」や「ライセンス解除」を忘れると、ライセンス枠が解放されません。
• ライセンスの管理や解除方法はUpdraftPlusの公式サイトや管理画面から行えます。
まとめ：
有料版UpdraftPlusは、作業後に無効化・ライセンス解除すれば、別のサイトの移行にも再利用できます。
ただし、「同時利用サイト数」制限を超えないようご注意ください。

————————————————

　これなら，さくらからエックスサーバーのmotochan.infoに移行して，別途，エックスサーバーのmotochan.siteに移行することが可能なので，残りの人生の時間確保には意味があると思う。

無料版でもできるということである。移行のための主コンテンツはバックアップされ移行される。ただシステム的な情報は移行されないので，urlが異なれば，すでに述べてきたように，Search-Replace DBを使う必要がある。

　Perplexityに尋ねた「Search-Replace DBの使い方は」内容省略。

————————————————

まとめ：
Search-Replace-DBは、WordPressのデータベース内文字列を安全かつ一括で置換できる強力なツールです。
使用後の削除とバックアップの徹底を忘れずに行ってください。

————————————————

　以上でほぼ理解した。無料版でもサイト移行は可能である。ファイル容量に制限があるわけでは無い。

8.2 騙していたんだねえ

　Perplexityに質問「無料版UpdraftPlusでサイト移行する際，バックアップファイルの容量にはアップロードと復元についても制限がないと考えて問題ないですか。」　まとめだけを次に。

————————————————
• バックアップ（エクスポート）自体には容量制限がない場合が多いが、
• 復元（インポート）には512MBの容量制限があるため、512MBを超えるバックアップファイルは無料版では復元できません。
したがって、「無料版UpdraftPlusでサイト移行する際、容量制限はない」とは言えず、特に復元時に512MBの制限があることに注意が必要です。

————————————————

　この件をずっと危惧していた。エックスサーバーのサポートの方へさきほど書いたメール内容を次に。

————————————————

　日曜日にお返事がいただけて感謝です。ざっと読ませていただきました。これらに対する対処はなんとか，ぼくは可能です。

Perplexityに聞いて，
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
• バックアップ（エクスポート）自体には容量制限がない場合が多いが、
• 復元（インポート）には512MBの容量制限があるため、512MBを超えるバックアップファイルは無料版では復元できません。
したがって、「無料版UpdraftPlusでサイト移行する際、容量制限はない」とは言えず、特に復元時に512MBの制限があることに注意が必要です。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

ということがわかりました。無料版UpdraftPlusには，復元時に容量制限があるのではないかと，ずっと考えていました。ぼくのサイトは圧縮ファイルで30GBほどあり，データベースも解凍時には3GBを少し超えます。解凍前は900MB弱ですが。

　それで，UpdraftPlus Premium版を購入することにしました。移行元のさくらと移行先のエックスサーバーにインストールして年$70ですが，仕方がないと考えています。移行はぼくの人生でこれっきりでしょうでしょうし。

データベース5GBの制限を知りましたので，さくらからの移行対象のWordPressをmotochan.info/wpとmotochan.site/wp に移行して，それぞれでコンテンツのテーマをゆるく2分して使用したいと考えました。重いものはWordPressに含めず，つまり，外部リンクを設定しないで，ぼくのmacのローカルサイトとサーバーの間をSeamonkey + CommanderOneで繋ごうと考えました。

お忙しい中，長々と書きましたが，ぼくの書いている内容に理解不足などがあれば，ご指摘いただければと存じます。

2025年4月20日　23：03

————————————————

　バックアップは必要だ。それゆえ，無料版UpdraftPlusは使える。なんかトラブルがあって復元が必要になれば，有料版を購入するという形しかない。１年分は否応なく使わないとと思うので，あらたな問題が生じた際に有料版を購入すれば良いと考える。

　ところがである。

　Perplexityに聞いた「エックスサーバーのレンタルサーバー内でのバックアップサービスはありますか？」

————————————————

エックスサーバーのレンタルサーバーには自動バックアップサービスが標準で提供されています。
この自動バックアップ機能は、全プランで無料で利用可能です。
主な特徴
• サーバー領域（Web・メールデータ）とMySQLデータベースの両方が対象
• 1日1回自動でバックアップ
• 過去14日分のデータを保持
• サーバーパネルからバックアップデータの取得や復元が可能
• バックアップデータはパソコンにダウンロードして保存することも可能
• 万一のデータ消失時には、バックアップデータから簡単に復元できる仕組み
注意点
• バックアップは自動で取得されますが、完全なデータ保全を保証するものではありません。
重要なデータはご自身でも定期的にバックアップすることが推奨されています。
• 一部古いサーバーでは保持期間が7日間の場合がありますが、順次14日間に拡大中です。
• サーバーパネルからバックアップデータの取得申請や復元操作ができます。
まとめ
エックスサーバーでは、Web・メール・データベースを含む自動バックアップサービスが標準機能として提供されており、管理画面から簡単にデータ取得や復元が可能です。

————————————————

　もうUpdraftPlusは不要だ。このエックスサーバーのバックアップサービスだけで良い。移行が終われば，凍結だな。

　次のページで有料版UpdraftPlusを使って移行だなあ。

以上，2025年4月20日。

　と思っていたけど，WPvividという無料の高級アプリを発見。さくらからエックスサーバーレンタルサーバーへの乗り換え 10: migrating WordPress site from Sakura to XServer 5 using free WPvivid

以上，2025年4月21日。

はじめに

　このシリーズのほとんどはパスワードプロテクトしてきた。サーバーに関わる当方の情報を掲載せざるを得なかったためである（隠してしまうとぼくが利用する際に不便という理由）。さくらのドメインのエックスサーバーへの移行なども終わったので，WordPressコンテンツの移行完結をここで示したいと希望している。窓外のぼくの梅には若葉が繁り，ソメイヨシノの大木は満開で，花吹雪も見える。

　エックスサーバーのぼくの誕生日までのキャンペーンは終了し，新たなキャンペーが始まっている。ぼくが3年契約したキャンペーン中での移行を目指したが未だ実現していない。お任せ（3万3千円）無料サービスに期待したが，サブディレクトリ（https://motochan.info/wp）に配置されているWordPressの移行は対象外だという。負傷したことなどもあって昨日，簡単移行を実行したがエラーで進めなかった。とすると，自ら進めなければならない。これがこの投稿の核心である。

1. 簡単移行の試み

　エックスサーバーのサーバーパネルにログインして，左ペーントップの「全メニュー表示」を選択すると，図1が表示される。赤い下線を施した「WordPress簡単移行」を選択する。

　移行済みWordPress一覧が表示されるが，もちろん，ぼくには無い。「＋WordPressを移行」ボタンをクリック。

　図2には作業結果を表示している。

　移行元urlには，さくらによって，サブディレクトリの /wp が付加されている。移行先ullには，サブディレクトリを入力しないことになっている。実は，/public_htmlフォルダーにインストールされる。

　次に，図2の右下隅の「移行する」ボタンをクリックした結果は，エラー（移行元WordPressのダッシュボードへのログインに失敗している可能性があります。）であった。WordPressに受け入れられなかった。思えば当然のことであった。日頃，WordPressにコンテンツをアップロードする場合，自ら設定したユーザー名とパスワードを使っているのだから，それらを入力する必要があったのである。すぐにクリアして，右下隅の「移行する」ボタンをクリックした。

　その3分後には，スライダーで40%の表示が出るが，その2分後には，図3のように，エラー「移行元WordPressからのバックアップの取得に失敗しました。」が出た。このエラーメッセージのすぐ下に，「もう一度お試し」とあり，まあ，実行したが根本的な問題がありそうで諦めた。手作業での移行が必要なのだろう。

　赤い「確認しました」のボタンをクリックすると図4のファイル削除のアドバイスが。掃除を自動的にしてくれるようだ。もちろん，「削除する」ボタンをクリック。

　簡単移行，は諦めた。

2. エックスサーバーが公開している移行手続

2.1 エックスサーバー公式

　ホーム > マニュアル > WordPressの移転について が，エックスサーバーの「孤独の移行手続き」に関わる，いわば公式ページであろう。目次を次に。

• WordPressの移転について
• 1. 移転元でバックアップが必要なデータの準備

  1. WordPressサイトファイルのバックアップ
  2. データベースのバックアップ

• 2. エックスサーバーへの移転作業

  1. 1. ドメイン設定の追加（独自ドメインで運用する場合）
  2. 2. データベースの作成
  3. 3. wp-configファイルの書き換え
  4. 4. データベースのインポート
  5. 5. サイトデータのアップロード
  6. 6. ネームサーバーの変更、およびサイトの動作確認

　この内容を見ると，官僚的というか制度優先というか，なんとも臭い。流れはこのようだと理解するだけだ。

2.2 WordPressブログの引っ越し（サーバー移行）手順を解説！

　https://www.xserver.ne.jp/blog/wordpress-migration/　これはエックスサーバーT部長のブログの位置付けである。

1. WordPressの引っ越し（サーバー移行）手順6ステップ

   • 1．事前準備
   • 2．新サーバー会社の契約
   • 3．新サーバーへドメイン追加
   • 4．データの移行
   • 5．データ移行後の作業
   • 6．旧サーバー会社の解約

2. サイトがうまく表示されない！よくあるトラブル2つ

   • 1．サイトが表示されたり表示されなかったりする
   • 2．正しいサイトアドレスなのに想定されたページが表示されない

3. まとめ

　

　この手順に沿って検討したいと思う。ただ，理解に苦しむ時には，次の該当部分を覗いてみる。

DesignAmus ～デザインアムズ～作

【サーバー移転・前編】さくらインターネットからエックスサーバーへの移転手順

【サーバー移転・後編】エックスサーバーにFTPソフトで手動データ移行～手順解説～

【ドメイン移管・無料特典利用】さくらインターネットからエックスサーバーへのドメイン移管手順

3. 改めてサーバー移行の選択肢

　ネット検索してサーバー移行には三種の機会が提供されていることを知った。以下に簡潔に。

3.1 All-in-One-WP Migration

　これを使えば夢のように簡単に移行できる。https://ja.servmask.com/products/unlimited-extension だけ見ても分かりにくいかもしれない。まず1年間分$99を購入して年間ライセンス5.75ドル/月(年払い）ということらしい。使用料$5.75/月という情報がネット上にあるが誤りである。これはWordPressのプラグインで高機能なのであるがこの種の需要は多くはないだろうと素人ゆえか想像している。

　極めて軽いWordPressを運営している方は，この無料版を使えるかもしれないが，その方面の利用者からの評価は極めて低い。

　このアプリを使うとデータベースも自動で書き換えられる。移動元でこのアプリをインストールしてコンテンツのバックアップをとって，移動先でもこのアプリをインストールしてコンテンツを復元するだけだ。WordPressの引越しを超簡単にできる「All-in-One WP Migration」の使い方 に記述されている。

　ぼくの目的からするとこのアプリは高額だ。1度使うだけで$100はちょっと痛い。エックスサーバーのお任せ移行（サブディレクトリー非対応）が33,000円と謳われていることからすると，リーズナブルか。

3.2 UpdraftPlus

　T部長やDesignAmusさんの記述を見ていて，なんとも納得が行かない。たとえば，せっかく圧縮されたバックアップファイルをなんで解凍するのか，などと驚いた。泥臭い。

　で，ネット検索して，，UpdraftPlus で WordPress サイトを超簡単に移行する方法 by こうすけ，に出会った。この方法で実施しようと思う。データベースの書き換えの内容については，T部長やDesignAmusさんの記事が参考になるだろうと考えている。

4. UpdraftPlusを利用して移行

　前述の主に UpdraftPlus で WordPress サイトを超簡単に移行する方法 by こうすけ，に基づいて実行したい。

4.0 大まかな移行手順

　リンクとともに掲載する。当方の記述はぼくの環境での実行過程を示している。ぼくのこれからの記述に疑問を持った際に利用してほしい。

WordPress サイトの具体的な移行手順

手順1. 【移行元】UpdraftPlus をインストール

手順2. 【移行元】WordPress サイトのデータのバックアップ

手順3. データベースファイルを一部加工

手順4. 移行先のサイトを WordPress で構築

手順5. 【移行先】UpdraftPlus をインストール

手順6. 【移行先】バックアップデータをもとにサイトを復元

最後に

4.1 database (db)ファイルの一部加工

　ぼくはUpdraftPlus（Updraft Backup Plus）無料版を使って毎日午後4時半からほぼ午後5時まで，レンタルGoogleDrive（100GB）に自動でバックアップをとっている。最新の三日分がキープされている。

　午後4時30分ないし午後5時移行作業は，午後1時半または午後5時過ぎから実行することになるだろう。ウェブコンテンツを作成しつつ実行するので時間がかかる。

4.1.1 実行前の準備

　後に述べるが結果的には，a. エディター Visual Studio Code，b. -gzファイルへの圧縮アプリ，はこのプロセスでは不要であった。しかし使用してみて，優れたツールであって今後？使えそうには思っている。

a. エディター Visual Studio Code取得

　こうすけさん推薦のこのエディターは，Windows，Linux, macに対応している。macOS への Visual Studio Code のインストール方法 を参考にmacにインストールし，日本語化した。マックのドックに表示した。

b. -gzファイルへの圧縮アプリ取得

　Visual Studio Codeによる編集済みのdatabaseファイルを元の-gzファイルに戻す必要がある。こうすけさんは7-Zipを推薦しているが，macユーザーからすると使いにくいソフトなので，Perplexityにお尋ねした。圧縮技術GZIPで圧縮されたファイルにファイル拡張子-gzが付加される。初心者にお勧めが次。

————————————————
　Keka
• 特徴: Macで利用しやすい圧縮・解凍ソフト。多くの形式に対応しており、簡単な操作でファイルを圧縮できます。
• 対応形式: ZIP、7z、TAR、GZIPなど。
• 入手方法: 公式サイトまたはMac App Storeから無料でダウンロード可能。

————————————————

　Perplexityお勧めだが1000円でしかもダウンロード，インストールした筈だがmac内でみつからない。Perplexityはその際には再度実行せよとあったが，クルクル回ったままだ。

https://www.keka.io/ja/ 作成者のサイトにアクセスしてダウンロードできた。KekaExternalHelper-v1.2.0.zipというファイルがダウンロードフォルダに入った。mac付属のStuffIt Expanderを使ってアプリケーションフォルダに解凍した。KekaExternalHelper.appが見える。ドックに運んだ。使用の際はファイルをこのアイコンにドラッグ&ドロップすれば良いはずだ。1000円は請求されない。寄付は任意になっている。ユーザーの書き込みに，Ketaとあったりして，Kekaって覚えにくーい。ケ(ン)カ?

c. Search-Replace DB取得

　UpdraftPlusを利用したサイト移転（引っ越し）方法 by 祐太郎紹介のツールであり，次の図にはこのサイトに掲載されているダウンロード法が示されている。2025年4月10日現在，v4.1.4になってはいる。なお，GitHub（ギットハブ）にサインインした上でダウンロードする必要がある。

　GitHubのサイトに示された情報で，参考になる部分を次にコピペしている。

Search-Replace-DB

https://github.com/interconnectit/Search-Replace-DB

Readme：
Search Replace DB – v4.1.4
This script was made to aid the process of migrating PHP and MySQL based websites. Works with most common CMSes.

Usage：
Do backups.
Migrate all your website files.
Upload the script folder to your web root or higher.
Browse to the script folder URL in your web browser.
Fill in the fields as needed.
Choose the Do a safe test run button to do a dry run without searching/replacing.

Installation：
To install the script, please place the files inside your sites public folder and head to yoursiteURL/Search-Replace-DB

CLI script：
To invoke the script, navigate in your shell to the directory to where you installed Search Replace DB.

Type php srdb.cli.php to run the program. Type php srdb.cli.php –help for usage information: 以下省略。

PerplexityにCLI scriptを尋ねた。
————————————————
WordPressにおけるCLIスクリプトの例: WP-CLI
WP-CLIはWordPress専用のCLIツールであり、以下のような操作が可能です。
主な機能
• WordPress本体やプラグインのインストール・アップデート・有効化.
• データベース操作（検索・置換、インポート・エクスポート）.
• サイト設定や投稿管理.
————————————————

4.1.2 データベース操作の練習

a. dbダウンロードと解凍

　昨日（Apr. 7, 2025）のバックアップファイル群のデータベースファイルは次のものだ。
backup_2025-04-07-1632_YamatoGeographer_4efdb673ff8b-db.gz　825.7MB

　dbファイルだけは拡張子が，-zipではなく，-gzである。Google Driveでこのファイルを選んで右クリックしてダウンロードを始めた際は1.5MBとあったが，2分後ダウンロードが完了した結果は865.8MBだった。そして，StuffIt Expanderで解凍したら，3.02GBである。重ーいい。想像を絶している。全体的に重いサイトであることがエックスサーバーで用意された簡単設定が役に立たなかった訳なのだろう。

b. Visual Studio Codeを使ってみた

　Visual Studio Code （略してVS Code）はマイクロソフトが提供しているシェアウエアである。これを立ち上げて前述のdbファイルを開こうとすると図5のように，「ファイルは非常に大きいため，テキストエディターに表示されません（2.81GB）」とメッセージされる。このメッセージの直下に，それでも開くと，制限の構成，の二択が出ている。

　「制限の構成」を選択すると，図6のように，
メッセージ：　Workbench: Editor Large File Confirmation
エディターで開く際に確認を求める前に、ファイルの最小サイズを MB 単位で制御します。この設定はすべてのエディターの種類と環境に適用されるとは限らない場合があることに、ご注意ください。1024MB =1GB
　それで，1024×3 = 3072MBに変更し，意味わからんけど「バックアップと同期の設定」ボタンをクリック。

　図7に見えるサインインのボタンをクリック。

　図8のように，「サインイン済み」になっている。

　

　図9のように，画面の左上の◻︎が並ぶアイコン（数字の1が見える）をクリックした。三つの拡張機能が表示される。そこで，GitHub Copilot Chatの「拡張機能の再起動」をクリックした。

　その結果，図10の右ペーンのように，Ask Copilotの表示が復活した。さらに，図10の左下の設定欄で，VimとGitLens-Git sup….の二つをインストールせよのようなお誘いがある。意味がわからないのでPerplexityに質問した。「インストールするべきか？
• 必要性を確認:　
• Vim: Vim風の操作が不要であればインストールしなくても問題ありません。
• GitLens: Gitを使用している場合は便利ですが、必須ではありません。」とありスキップした。

　遠回りをしたが，最初から，「フォルダを開く」をクリックすれば良かったのである。

　図12の中央のペーンにはdbファイルのテキスト群が見えている。図11の「フォルダーを開く」をクリックすると，マックのファインダーに入って，改めて，dbファイルを選択した。dbファイルは構造的にフォルダーなのだろう。
　さらに，図12の右下隅の「強制的に機能を有効化」をクリックした。今後は今までのステップは省略されるのであろうと推測する。

　図13のように，ファイルを再度開け，とのことで，改めて，「フォルダーを開く」をクリックする。

　図14のように，左右のペーンの幅を狭めて，テキスト本文が全部見えるよう。

　この本文の最上部の注記は次のようだ。行頭の#は省略されている。

————————————————

WordPress MySQL database backup

Created by UpdraftPlus version 1.25.3 (https://updraftplus.com)

WordPress Version: 6.7.2, running on PHP 8.3.8 (Apache), MySQL 5.7.40-log

Backup of: https://motochan.info/wp

Home URL: https://motochan.info/wp

Content URL: https://motochan.info/wp/wp-content

Uploads URL: https://motochan.info/wp/wp-content/uploads

Table prefix: wpedcff9

Filtered table prefix: wpedcff9

ABSPATH: /home/motochan/www/info2020/wp/

UpdraftPlus plugin slug: updraftplus/updraftplus.php

Site info: multisite=0

Site info: sql_mode=NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

Site info: end

————————————————

　このうち，次の四行に注目する。

Backup of: https://motochan.info/wp

Home URL: https://motochan.info/wp

Content URL: https://motochan.info/wp/wp-content

Uploads URL: https://motochan.info/wp/wp-content/uploads

　この表記からすると，さくらのWordPressのurlは，https://motochan.info/wp である。こうすけさんのウェブでは，旧サーバーでのhttps://upd.worldで検索して，新サーバーでのhttp://localhost:7000に置換すると言っているが，当方ではさくらのサブディレクトリーの/wpも加える必要性がある。そしてエックスサーバーの方では，http://motochan.info/public_html にすることになると思うが。エックスサーバーのサポートにメールで尋ねる必要がある。

　図15左ペーンで，motochan.info/wp で検索した様子が示されている。左ペーンではヒットした行が並んでいる。

　図16では，左ペーンのペーン幅を拡大している。

　図17では検索結果の2行に⇨をつけている。上の⇨の行では文章が見える。つまりWebページの地の文が見えているのである。dbファイルはコンテンツのテキストをすべて網羅しているらしい。下の⇨の，15:50の行，言い換えると第1436行だけ選んでコピペするとめちゃくちゃ長い（CotEditorで「高度な文字カウント」を実行するとUnicodeスカラで263,120字だ）。核部分を見ると，’https://motochan.info/wp/2020/05/29/355-revision-v1/’,などとなっている。

　確かに，https://motochan.info/wp/ を，http://motochan.info/public_html/
と置換することになるのだろう。エックスサーバーの方はコンテンツがないので，https化を実行できない。コンテンツを移行したあとで，SSL化することになるので，エックスサーバーの方は，http://，が適切だと思われるのである。

以上，2025年4月9日。

c. シリアライズされたデータは変換されない

　UpdraftPlusを利用したサイト移転（引っ越し）方法 by 池田祐太郎には，上掲のUpdraftPlus で WordPress サイトを超簡単に移行する方法 by こうすけ，を評価しつつ，大きな問題点を挙げている。

————————————————

「データベースファイルを一部加工」の箇所はDB内のURL文字列を移行元から移行先へと変換するプロセスですが、 wp_options や wp_postmeta テーブル内にはシリアライズされたデータが保存されている場合があり、シリアライズされたデータがDB内にあると完全にURLの変換ができずに旧サイトのURLが残ってしまう可能性があります。

WordPress 公式にもこのように記載があります。

URL を変更するためにデータベース全体の検索と置換を行うと、いくつかのテーマやウィジェットには URL の長さを示す値を保存しているものがあるため、データのシリアライゼーションに問題が生じる可能性があります。これが変更されると、壊れてしまいます。WordPress の移行 | WordPress.org 日本語

よって、この方法で進めた場合はシリアライズされた部分は置換されないため、ウィジェットやプラグインで不具合が発生したり、投稿や固定ページ等で設定されたページ内リンクが移行元URLのまま、といったような問題が発生してしまう可能性があります。

————————————————

　「シリアライズされたデータ」とは何か，Perplexityにお尋ねすると，

————————————————

WordPressにおける用途：
WordPressでは、主にカスタムオプションや設定データを効率よく保存するためにシリアライズを利用します。これにより、複数のデータを1つのデータベースレコードにまとめることが可能となります。

URL変更時の問題：
• WordPressを別の環境に移行する際、シリアライズデータ内のURLなども更新が必要です。データ内に含まれる文字列の長さ（s:10 のように文字列長を定義）が正しくない場合、アンシリアライズに失敗することがあります。
• 解決法: シリアライズデータを考慮したURL置換ツールを使用（例: Search and Replace for WordPress Databases）。

————————————————

などとあって，前項4.1.2.bの図17のように，ぼくのサイトでも多用されていて，こうすけさんのようにurlの置換をテキストベースで実施する方法は不適切であることがわかる。

4.2 Research-Replace DBのパラメータ取得

4.2.1 Search-Replace DBの導入

　祐太郎さんの記述（2021-2022年）に基づくと，こうすけさんの「移行前にdbのテキスト置換」は不適切で，移行先でまずはUpdraftPlusを使って全データをインポートして，さらに，4.1.1.c で取得したSearch-Replace DBを使って，一括置換を実施する必要がある。こうすけさんは移行前で，祐太郎さんは移行後である。

　ホーム > ツール >【WordPress】DBの置換には「Search Replace DB」を使おう 2018年4月 by 車椅子コーダーさんの情報もあった。使用法が丁寧に解説されている。

　Search Replace DBの使い方！データベース内のドメインを一括置換する方法 2025年1月 by しゅんのすけさん，にもある。これが最新だ。

　祐太郎さんによれば，アップロード後、アップした先のURLを直打ちしブラウザでアクセスしてみると、一括置換ツールのスクリプト画面が表示されます，とある。

4.2.2 一括置換ツールのスクリプト画面

　

　図18の内容はもちろん，移行先のサーバーの情報である。未だWordPressの移行作業に入っていないので，何をしていいのかまだ把握できていない。

　祐太郎さんによれば，

————————————————
　必要な情報を入力し接続成功後、一括置換を実施

まずは正しくデータベースにアクセスできるか確認しましょう。Database Details より以下の情報を入力します。それぞれに対応する wp-config.php の箇所です。

• database name: WordPress のためのデータベース名
• username: MySQL データベースのユーザー名
• pass: MySQL データベースのパスワード
• host: MySQL のホスト名
• port: MySQL のホスト名にポートが設定されている場合はポート番号を入力（任意）

単純に wp-config.php にかかれている内容を入力すれば問題有りません。入力できたら「Test connection」をクリックし接続テストします。

接続成功後、「replace」に移行元の古いURLを、「with」に移行先の新しいURLを入力します。ドメイン名のメールアドレスを利用している場合があるため、httpプロトコルから入力すると安全です。

例

with: https://new.highfivecreate.com

replace: https://old.highfivecreate.com

————————————————

　「単純に wp-config.php にかかれている内容を入力すれば問題有りません。」とあるので，UpdraftPlusでファイル群をインポートの後に，wp-config.php を参照すれば良いということになるが，

現在のさくらのワードプレスのwp-config.phpを閲覧してみよう。

　

4.2.3 さくらのwp-config.php

　FTP client: Commander One < さくらからエックスサーバーレンタルサーバーへの乗り換え4 に示したサーバーへのアクセスでさくらのwp-config.phpを参照している。

　Research-Replace DBのパラメータは前述のように，

• database name: WordPress のためのデータベース名
• username: MySQL データベースのユーザー名
• password: MySQL データベースのパスワード
• host: MySQL のホスト名
• port: MySQL のホスト名にポートが設定されている場合はポート番号を入力（任意）

であるが，

• database name: アカウント_wp2020
• username: アカウント
• pass: ぼくが設定したWordPressにログインするパスワード
• host: さくらの設定値.アカウント.sakura.ne.jp
• port: httpの場合は21, httpsの場合は22

となるが，ポート番号が任意という意味がわからない。おそらく，ポート番号の入力が任意の意味であろうが，Research-Replace DBのパネルでは，portにあたる空欄はあって，入力が任意とは記されていない。

　Research-Replace DBのパネルへのMySQL databaseの空欄に入れるパラメータはさくらのものではなく，エックスサーバーのものである。

4.2.4 XServerのwp-config.phpとさくらXServerのurl

　XServerのwp-config.phpの情報が明確ではない。とにかく，XServerの移行対象ドメインにWordPressをインストールして，CommanderOneでwp-config.phpを参照する必要がある。

　Research-Replace DBのパネルには，search/replace欄があって，

replace欄には，http://motochan.info/wpが，

with欄には，http://motochan.info/public_htmlが，

入るものと想像しているが，エックスサーバーのサポートに尋ねる必要がある。

4.3 Research-Replace DBの使い方の確認

　どうも実行経験がないので，このアプリの使用法がわからない。このサイトに出かけて調べる必要性を感じる。

WordPress Search Replace DB の使い方 更新日：2022年03月13日

作成日：2021年4月26日 by 不明。ご自分の備忘録的なサイトで凄く丁寧にノウハウが示されているので，差し当たり，これで移行準備は完了とすることに。

以上，2025年4月13日。

おわりに

実際の移行プロセスは次のページへ：

さくらからエックスサーバーレンタルサーバーへの乗り換え 9: WordPress移行4　migrating WordPress site from Sakura to XServer 4

　

　

　

はじめに

　awesome Adobe applications to sharewares で示したように，Adobe Photoshopから離れて，GIMPを使用したい。

　GIMP使用当初はPhotoshopに比べてステップ数が多いと感じたのであるが慣れてきて，かつてGIMP使用を断念した時よりはよほど肩が軽くなった。Photoshopから拒絶されたので致し方ない。

1. ダウンロード

　https://www.gimp.org/downloads/ に，GIMP, Current Stable Version

The current stable release of GIMP is 3.0.2 (2025-03-23), のダウンロードサイトがある。Donationを以前したことがある。使えるようになったら改めてしたいと思う。

　ver. 2.1を削除してこのver. 3.0をインストールしたのであるが，ツールボックス表示のタイミングがうるさくなくなったという印象を持つが，戸惑うことがあり，Perplexityにお世話になった。

2. 最近は何をしていたのか

　Adobe Photoshopで最近何をしてきたのかを考える。今後，必要に応じて追加してゆく。

2.1 スクリーンショットや写真からWeb用コンテンツを作成

　現在の最頻度の作業は，macやWindowsでの作業をスクリーンショットで貯めて，それらを軽くしてWebページへ掲載してきた。フィールドなどで撮影した写真も同様の利用をする。iPhoneで撮影した写真は，mac写真アプリに並べてコメントを付し，jpgで出力してそれらをスクリーンショットとほぼ同様の作業をしてきた。

　スクリーンショットはフィールド写真と比べるとかなり軽量で多少処理過程に違いはある。総じてPhotoshopでの作業は次のようであった。

1 　必要な部分を切り取る場合がある。

2　写真の場合はスライダーを使って彩度を高くする。

3　ランドスケープの場合は，解像度300dpi，縦1200dpi，横1600dpi。

　 ポートレート　の場合は，解像度300dpi，縦1600dpi，横1200dpi。

4　容量を軽くする。Web用だとスクリーンショットの場合最大100 kbyteほど，写真だと500kbytesほどにしてきた。

　さて，Perplexityでの質問文を考えてみる。

　スクリーンショット：　GIMPでの作業過程を教えてください。スクリーンショットの一部を切り取って，その形がランドスケープの場合は，解像度300dpi，横1600dpiに揃えたい。そしてファイル容量100kbytesほどのjpgで出力したい。

　写真：　GIMPでの作業過程を教えてください。iPhoneで撮影した写真の彩度を高めて，その形がランドスケープの場合は，解像度300dpi，横1600dpiに揃えたい。そしてファイル容量500kbytesほどのjpgで出力したい。

3. スクリーンショットをWebページ掲載画像ファイルjpgに変換する手順

　では，スクリーンショットの場合を聞いてみた。回答は簡潔でそのままでは実行できない。以下に。

作業手順

3.1　スクリーンショットの切り抜き

　1.1 GIMPで，メニューのファイル > 開く/インポート。

　1.2 設定したパスでのファイルを選択，ダブルタップ。

　ファイルを直接，作業画面にドラッグ&ドロップするのが簡単ではあるが（一般的にはこれが迅速），図1のようにパス指定すると，その後は，パスを覚えてくれている。図1の右手にはファインダーでのスクリーンショットフォルダ内が見えており，対応している。日を跨ぐと，更新日時欄の表示には時刻が表示されない。名前欄の幅が小さいので，スクリーンショットの長いファイル名が表示されることはない。

　目的のファイルをダブルクリックすると選択できる。ファイルを選択したあとに右下隅の「開く」ボタンをタップしてもよい。
　次に，Keep the image’s color profileパネルが表示される。この下端には「維持」と「Convert」ボタンがあり，「維持」ボタンをタップすることになる。ただ，このパネルは，「次回から確認しない」に☑️を入れて良いだろう。ぼくの能力では，このパネルを生かすことはできない。

　図2の作業枠は，画像サイズがこれを超えると，枠域は自動で拡大される。Photoshopには無い融通性だ。

3.2　矩形選択ツールで必要な範囲を選び，切り抜く

　他のツールを使っていない場合は，自動的に矩形選択ツールが使え，選択範囲でクリックすれば，切り抜くことができる。直前のファイル作業で他のツールを使っている場合は，次のような手続きが必要である。

2.1 メニューのツール > 選択ツール > 矩形選択ツール
　2.2 画像 > 選択範囲で切り抜き

3.3　画像の拡大・縮小

　メニューの画像 > 画像の拡大縮小

　　図4で解像度（水平と垂直は連動）を300dpiに幅（高さも連動）を1600pxに設定。確定後、「OK」ボタンはないので，「拡大・縮小」ボタンをタップ。

3.4　エキスポート

　4.1 メニューのファイル > 名前を付けてエキスポート

　図6に示したように，「名前を付けて保存」ではなく，「名前を付けてエクスポート」である。　

　4.2 保存先をダウンロードフォルダにしてJPEGでエキスポート過程に

　JPEG形式で保存しないと容量などの点からウェブコンテンツにならない。図7の下段にはファイル形式の設定メニューが見えるが，「🔽ファイル形式の選択」欄はもともと閉じている。これを開いたのが図7である。このウィンドウのほぼ中央ぐらいに，JPEGが見えるので，それを選択するのである。図7ではupload用フォルダーが選択されているが，GIMPは記憶してくれないので都度このパス指定が必要になり時間を取られるので，左端のフォルダー表示で，Downloadsは簡単に選択できるのでここにエキスポートしたい。

　4.3 ファイル容量を100kB程度に

　図7の画面の次に図8の画面が現れる。左上隅には，品質調整のスライダーがある。スライダー上の左方部をタップすると品質が低下する。この図8では，147.4kBが見えるが，後背の画像をみつつ，67.2kBにして，エキスポートした。

　エキスポートした画像を見たが全く問題なかった。

　なお，一つの画像に関わる作業が終われば，

メニューのファイル > ビューを閉じる

を選ぶ。保存するかどうか聞いてくるが，すでにエキスポートしているので，保存しない，を選択する。保存にするとGIMP固有のファイルとなり，引き続き作業が可能になる。

線を描く

　図6には，注意喚起のために，赤線を入れている。この入力法を次に。

メニューのツール > ツールボックス，

とするとツールボックスが出る。その鉛筆を選んで色も指定する。

鉛筆の太さの変更は次のようにする。

メニューのウィンドウ > ドッキング可能なダイアログ > ツールオプション

を開いて，サイズ，を調整する。

以上，2025年4月5日。

テキストボックスの選択解除

　なぜか，複数のテキストを作成したあと，その一つのテキストボックスが解除されない。メーンメニューの選択 >「 選択の解除」，は灰色になってしまっている。

　Perplexityに質問してその回答の一つを実行して成功した。

————————————————

2. フローティング選択範囲の確認と解消 • フローティングレイヤーがある場合は、以下の手順で処理します:

   1. レイヤーダイアログを開きます（「ウィンドウ」→「ドッキング可能なダイアログ」→「レイヤー」）。
   2. フローティングレイヤーが表示されている場合は、右クリックして「新しいレイヤーに変換」を選択します。
   3. これによりフローティングレイヤーが通常のレイヤーに変換され、「選択を解除」が使用可能になります

————————————————

　この回答の通りには実行できない。

2.1の [ レイヤーダイアログを開きます（「ウィンドウ」→「ドッキング可能なダイアログ」→「レイヤー」）。] を実行した。図9の図で三つのテキストのうち，「/wp………」のテキストボックスが選択状態になっている。右上に出現しているツールボックスでも，「/wp………」が選ばれている。それで，最下部の「スクリーン」を選択した。

　図10の図中の「/wp………」のテキストボックスの選択が外れている。右端のツールボックスでは，見えにくいが「スクリーン」が選ばれている。幸なるかな。

以上，2025年4月6日。

はじめに

　さきほど，macOS Sequoia 15.4，にアップデートした。大失敗だ。この作業ののち，サブスクリプション制度前のAdobe Photoshop，Illustrator，Dreamweaverなどが使えなくなった。ずっとAdobe Applicalication Managerが，お待ちください，として，水車が回っている。Creative Cloudはクリアするのだが。

　このmacだけではなく，macOS Sierra 10.12.6のそれも，同様だ。互換性がない，ということらしい。しかし，古いバージョンのアプリも使えない状況になった。古いバージョンを使わせない魂胆である。アップルもアドビもトランプと同じだ。独占資本である。メンバーシップの有効期限が切れたということらしい。

代替アプリは

　いま，気づいたのだが，MacBook Air（macOS Sequoia 15.4）のIllustratorは何と，立ち上がっている。Photoshopはだめだ。Dreamweaverもだめだ。

　一番使っているのはPhotoshopだ。これはWEBというかWordPressコンテンツ作成のために毎日使っている。これはGimpで代替可能だろう。

　Illustratorはこれまで作成してきたファイルがあるのでこれを使うには必須のものだ。今なぜか，使えている？が，ペーパー作成の際にはアカデミック月単位の契約をするしかないだろう。

　Dreamweaverは一昨日に，学生への授業コンテンツの提供を中心とするドメインコンテンツの古いさくらサイトからエックスサーバーへの移行のために，固めて使ったが（幸いなるかな），基本的には，Cyberduck + SeaMonkey，で問題ない。

おわりに

　Photoshop代替のGimpについて，次のページに記す。

以上，2025年4月3日。