メンテナンスページは確かに昔ほど人気がありませんが、今でも存在しています。 最新のサイトでは、多くの代替手段を利用してダウンタイムを最小限に抑えることができます。 これは、エラーが発生した場合、または別のタスクがダウンタイムを引き起こしている場合に、メンテナンスページを使用する必要がなくなったことを意味します。
このチュートリアルでは、使用できるメンテナンスページのいくつかの代替方法について説明します。 その前に、そもそもそれらを使用することが理にかなっている場合について話しましょう。
ウェブサイトのメンテナンスページの紹介
あなたはおそらくあなたがオンラインでいる間にたくさんのメンテナンスページに出くわしたでしょう。 通常は次のようになります。
メンテナンス ページは、現在問題が発生していることを示す単なるプレースホルダーです。 サイトのWeb 訪問しようとしています。 場合によっては、この問題を解決するのにしばらくまたは数分かかることがあります。
メンテナンス ページの目的は基本的に、 訪問者 修正しようとしているエラーに遭遇します。 機能やデザインを変更するときにも使用する人もいます。 サイトのWeb、このタイプの使用はもはや一般的ではありません。
実際には、全体のメンテナンス ページを有効にすることができます。 サイトのWeb または特定のページのみ。 アプローチは、遭遇する問題によって異なります。 次に、メンテナンス ページを使用するのが適切な場合を見てみましょう。
WordPressブログのメンテナンスページの使用を決定する方法
ウェブサイトのメンテナンスページは非常に便利ですが、いくつかの理由で少し人気がなくなっています。 例えば:
- メンテナンスページをアクティブにすると、基本的にWebサイトのダウンタイムに相当します。
- ダウンタイムを回避できるメンテナンスページの代替手段があります。
- メンテナンスページを使用すると、ユーザーを怖がらせることができます。
全体として、Webサイトのデザインや機能を変更するときに、メンテナンスページを使用する必要はありません。 そのような場合は、ウェブサイトのダウンタイムを伴わないより良い代替案があります。これについては後で説明します。
ほぼ間違いなく、メンテナンス ページの使用が常に役立つ状況は XNUMX つだけです (サイトの主な機能に影響を与えるエラーの場合)。 これらの場合、怖がらせて追い払う危険を冒す方がよいでしょう。 訪問者 破損した Web サイトを表示するのではなく、メンテナンス ページを表示します。 そんな時のために、スタイリッシュなメンテナンスページを作成できるツールが豊富に用意されており、多くのテーマにはメンテナンステンプレートが標準で含まれています。
メンテナンスページへの2の代替
ウェブサイトのメンテナンスページを使用する時間と場所があります。 ただし、ほとんどの場合、ダウンタイムを発生させることなくトリックを実行するいくつかの優れた代替手段もあります。 それが何であるかについて話しましょう。
1。 中間Webサイト(テスト)を使用して、必要な変更を行います
率直に言って、テストWebサイトは、使用を開始すると、開発および設計作業へのアプローチ方法が変わります。 要するに、ステージングサイトは、一般の人がアクセスできないWebサイトのライブコピーです。
ほとんどの場合、転送するWebサイトに変更を加えることができるのは、あなたまたはあなたのWebサイトで作業している他の人だけです。 満足したら、それらをライブで「公開」して、サイトの既存のバージョンを作業中の新しいバージョンに置き換えることができます。
設計を変更したり、Webサイトに機能を追加したりする場合は、メンテナンスページをアクティブにするよりも、中間コピーを使用する方がはるかに優れています。 サイトのライブバージョンで作業していないため、新しいバージョンに置き換えるまでサイトを実行し続けることができます。
WordPress Webサイトの設定に関しては、どのアプローチを採用するかに応じてXNUMXつのオプションがあります。
- 次のようなツールを使用して、ローカル開発環境をセットアップします。 MAMP ou WAMP あなたのコンピュータにあなたのウェブサイトのコピーをセットアップしてください。
- 次のようなツールを使用します。 フライホイールによるローカル トランジットウェブサイトをすばやくセットアップし、複数のウェブサイトを簡単に管理できます。
- ホストの転送サイトの機能を利用します(提供されている場合)。
ほとんどの場合、サイトのステージング コピーをセットアップする最も簡単な方法は、Web ホストの組み込み機能を使用してセットアップすることです。 問題は、すべてのプロバイダーがこの機能を提供しているわけではないことです。特に、宿泊施設 基本共有。
この著者は フライホイールのステージング機能(英語)開発作業用。 ただし、マイレージは異なる場合があります。 オフラインのステージングWebサイトをセットアップする場合は、最初のXNUMXつのアプローチを使用できます。
このような場合、次のようなバックアップツールを使用して、ライブWebサイトのローカルコピーを設定できます。 UpdraftPlus。 その後、必要な変更を加え、準備ができたら同じ方法でライブコピーを置き換えることができます。 もちろん、これらのアプローチには作業が含まれます。 ただし、改善を行っている間、サイトは少なくともアクセス可能なままになります。
2。 必要に応じて、以前のバージョンのWebサイトに戻る
多くの記事に共通するテーマは、常にWebサイトのバックアップを作成することです。 私たちが大規模なバックアップの「中毒者」であるというわけではありません。 ただし、この単純なアクションは「お尻」をさまざまな方法で保存できるため、ほとんど無責任です。 ne それをしないでください。
たとえば、ユーザーがアクセスできないためにWebサイトが大幅に破損したとします。 WordPressを更新しましたが、プラグインのXNUMXつなどと重大な競合が発生しています。 この状況では、次のXNUMXつのオプションがあります。
- メンテナンスモードをアクティブにせずに手動で問題を解決し、遅いトラフィック数を予想します。
- 問題を修正している間、メンテナンス ページをオンにしてください。 訪問者 あなたがその問題に取り組んでいることを知ってください。
- Webサイトを最近のバックアップに戻し、通常どおり作業を続けます。
バックアップがごく最近のものである限り、オプション番号XNUMXがはるかに簡単です。 理想的には、Webサイトのバックアップを毎日作成しますが、これは小規模なプロジェクトには実用的ではありません(ただし、 VaultPress)。 少なくとも毎週のバックアップをお勧めします。
一部のプラグインを使用すると、Webサイトのバックアップを自動化し、これらのファイルをオフサイトに保存できます。これも同様に重要です。 また、サイトを手動でバックアップすることもあります。 ただし、正直に言うと、自動化の方がはるかに簡単です。
さらに便利なエクスペリエンスが必要な場合は、一部のWebホストが顧客に自動バックアップを提供します。 転送サイトと同様に、多くのプロバイダーはこのタイプの機能を基本的な共有プランに含めていません。
この作成者は、次の機能を含むいくつかのWebホストバックアップ復元機能を試しました。 A2ホスティング と フライホイール 、そして両方で良い経験をしました。 当然、自動バックアップとサイト復元機能を提供するWebホストは他にもたくさんあります。 それらのXNUMXつを選択する前に、他の調査を行うことを躊躇しないでください!
まとめ
メンテナンスページを使用することが理にかなっている状況はまだあります。 たとえば、サイトの主要な機能に影響を与えたり、問題が発生したりするエラーが発生する可能性があります。 このような場合、修正を実行している間、サイトのメンテナンスページを有効にすることができます。
ただし、次のようなメンテナンスページの使用に役立つ他のツールもあります。
- 中間Webサイトを使用して、必要な変更を加えます。
- エラーがある場合は、Webサイトを最新のバックアップに移動します。
メンテナンスページはまだ良い習慣ですか? 以下のコメントセクションで私たちとあなたの意見を共有してください!
今朝の午前0,30時から午前2時45分まで、非常に大規模で忙しいWebサイトでインタビューを行いました。 メンテナンスを開始した後、最初にバックアップを実行し、次にタスク、インストールなどを開始しました。 データベースのランキングを変更し、プラグインをインストールします。 残念ながら、プラグインをインストールできませんでした。そのため、メンテナンスモードを終了し、すぐに再試行します。 問題が予想されるので、おそらくWebの1:1のコピーを作成して作業します。 方法を見つけたら、ライブWebで手順を繰り返します-メンテナンスページを使用します。
なぜメンテナンスページやウェブコピーなのですか? これには実際的な考慮事項があります。 WebはContao(WPではなく)で動作し、マルチドメインインストールです。 圧縮されたデータベースのサイズは約330MBです。 Webには、合計99 GBの数万のファイルが含まれています。SSHアクセスとマルチドメイン容量のサブドメインを使用して(サーバー上で)1:1コピーを構成してから、Contaoを再構成してデータベースをコピーします。データの数時間かかります。 Composer、Symfony、Symlinksのおかげで、Contao 4を起動して実行するのが難しいため、XAMPPではローカルで実行できないことがあります。 また、uUファイルをダウンロードするだけでも数日かかります。
この長い準備を考慮すると、小さな変更を加えるだけでよい場合、メンテナンスの問題は簡単です。 もちろん、メンテナンスページ付きのメンテナンスを夜間に移動するようにしています。 ただし、小さな変更がメンテナンスなしで行われることもあると考えられることもあります。 そして、あなたはすでにウェブを削除しました。 数週間前のクラッシュのように、日曜日の2-11からオフラインになりました。
私の意見:メンテナンスへのメンテナンスページはでなければなりません。 ウェブが大きすぎる場合、代替手段はありません。 ただし、重要なシステム変更は1:1のコピーで行う必要があります。すべて合格したら、手順を書き留めて、メンテナンスページと一緒にライブWebで繰り返します。 データベースと重要なWebファイルのバックアップは常に必須です。 私は常にメンテナンスモードをアクティブにした後にこれを行うので、訪問者がWeb(訪問者カウンター、フォーム送信など)を変更できないことを確信できます。