既存の WordPress Web サイトに関連するプロジェクトを受け入れる前に、いくつかの重要な質問を自問してください。
あなたはまだこの記事を読んでいますが、少なくとも 1 回は「いいえ」または「わかりません」と答えたにもかかわらず、あなたは十分に絶望しているか、ネットワーキング/マーケティングやフォローを期待しているなどの他の理由があるのではないかと思います。 -up プロジェクトに参加すると、すでに問題を引き起こし始めている従来の WordPress Web サイトを扱うことに同意したことになります。
常識と細心の注意を払うことで、リスクやトラブルを減らすことができます。最も重要なことは、変更を加える前に必ずすべてのデータをバックアップしてください!
ページビルダーを使用して既存のレガシー Web サイトを変更する必要がある場合に行うこと:
次へ:
バックアップを作成してください! UpdraftPlus は、購入したプラグインを含む WordPress Web サイトのクローンを開発およびステージング システムに作成するためにバックアップを使用できるため、優れたツールです。
バックアップ ファイルをローカル コンピューターにダウンロードします!
開発インスタンスをセットアップしてください!共有ホスティングでの 1 クリック インストールから始めることも、ローカル開発には wp_cli_docker などの Docker ベースのテンプレートを使用することもできます。
元のコンテンツをローカル コピーに復元/移行します。 UpdraftPlus はすべての絶対 URL を調整し、ターゲット インスタンス上でメディア ライブラリが動作するようにします。
メイン管理者ユーザーをリセットし (wp-admin で、またはデータベース Docker コンテナー内の mySQL cli を使用して)、メール アドレスを変更します。
他のユーザーをすべて削除してください!
すべての個人データと顧客データを削除してください!
サイトのタイトルとブックマークアイコンを変更します。私のローカル開発セットアップのタイトルは通常「ローカル」で始まり、アイコンが実稼働環境のアイコンと混同されることはありません。
ローカル開発インスタンスの WordPress とそのプラグインを更新します。
すべてが引き続き動作することを確認してください。
完全バックアップを作成してダウンロードする前に、クライアント実稼働サイトのどの部分も更新しないでください。また、スクリーンショットを撮ってアーカイブの例を保存する前に更新しないでください。何かが壊れた場合は、最後の動作状態を知る必要があります!
本番サイトに変更を加えているときに、クライアントに「工事中」または「メンテナンスモード」のどちらの通知を希望するかを尋ねます。 Elementor には組み込み機能がありますが、WordPress にはまだ組み込まれていないため、サードパーティのプラグインに依存する必要があります。私は Under Construction を試してみましたが、実稼働環境では致命的ではないはずの PHP 非推奨メッセージにより、ローカルホスト インスタンスが「死の白い画面」で壊れましたが、それでも危険を冒したくありませんでした。 Team Streber のブログのヒントのおかげで、WebFactory Ltd によるメンテナンスを利用しました。PRO 機能の料金を支払わなくても、少なくとも短いダウンタイムであれば十分だと思われます。
既存のコードをcustom.css、custom.js、example-child/functions.phpなどのプロジェクトファイルにコピーし、コミットします。
実際の Web 開発を続行する前に、パフォーマンス、キャッシュ、およびセキュリティのプラグインをローカルで無効にします。これらは開発中に役に立ちませんが、その最適化が邪魔をしたり、ページスタイルが古くなり、メモリとエネルギーを浪費したりする可能性があります。
顧客にテスト用のプレビューを表示したい場合は、パブリック ステージング インスタンスをセットアップし、ローカルホストから新しいバックアップを転送し (顧客データやオプションのプラグインは既に含まれていません)、パスワード保護を設定します。適切な人だけがステージにアクセスできるようにするためです!
ステージングを行わない場合は、実稼働サーバーにドラフト ページを追加して、進行状況を表示し、作業内容をローカルホストから実稼働環境に選択的にコピーできることを確認できます。
次に、指定された設定で作業する最適な方法、変更を保持する方法、何も壊したり忘れたりすることなく、変更を別のページまたはインスタンスに安全に転送する方法を見つけようとします。
私はフロントエンドに重点を置く Web 開発者として、可能な限りグローバル CSS を使用するようにしています。これがノーコード ページ ビルダーの意図と矛盾していることは承知していますが、コーディング全般でも同様です。これは、コードを制御し続けることと、既存のコードとソフトウェアを完全に捨てないことの間の現実的な妥協策であることがわかりました。
グローバル カスタム CSS は、次のメジャー アップデート後に機能しなくなる可能性がある要素固有のカスタム CSS やプラグイン固有の設定と比較して、目立つため、見つけやすいです。
Web サイトの複雑さと、そのテクノロジーに関する私たちの経験によっては、目に見える成果が得られずに、従来のセットアップを理解するのに少なくとも 30 分、または 1 日を費やした可能性があります。コーディングを開始する前に、割り当てを確認し、簡単に始められるサブタスク、理想的には一目で明らかな変更を引き起こすものを見つける必要があります。
これにより、最初の 1 時間または 1 日の仕事を達成感を持って終えることができます。
仕事を進めるときは、常に注意しなければなりません。
ご覧のとおり、私は WordPress について投稿し続けています。私は従来の WordPress Web サイトを使用するクライアントを引き続き受け入れており、コードを最初から書き直すことはありません。私のヒントや暴言が誰かにとって役立つことを願っています。この種の投稿を公開することは、知識を保存し、次回 Google でエラー メッセージを検索するときに見つけられるもう 1 つの方法です。
以上が従来の WordPress Web 開発ワークフローの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。