私の5つの最悪のWordPress開発の間違い
公開: 2022-03-11または、私が以前にタンクに入れたすべてのサーバーへ：私が犯した5つの最悪のWordPressの間違いでの恐怖の振り返り
開発者として、私たちはキャリアのさまざまな時点でさまざまな種類の間違いを犯します。 特にWordPressの開発では、WordPressコードベースに精通するにつれて、さまざまな種類の間違いを犯します。
数年前、マット・マレンウェッグが、ほとんどの人が自分の過ちを繰り返し、賢い人は自分の過ちから学び、私たちの中で最も賢い人は他の人の過ちから学ぶという趣旨の宣言を聞いた。 私はむしろこれが好きで、当然の結果を追加します。誰もが間違いを犯し、謙虚な人々がそれらの間違いをプライベートで共有し、私たちの中で最も大胆な人がそれらを書き留めてブログに公開します！
しかし、後で熟考する時間はあります。 あなたは列車事故について聞きたいのでこの記事を読んでいます、そして私はエンジニアです。 それ以上の前文なしで、私がWordPress開発者として犯した最も恥ずかしい5つの間違いを恐れて振り返ってください。
ハッキングされたバージョンのWordPressCoreを更新したとき
私は、非常にあいまいなCraigsListコーディングのギグを行うことから、実際に実際の代理店で働くことへと卒業したばかりでした。 到着しました！ ソファ以外の場所、パジャマ以外の場所で作業することに緊張しました。 しかし、それでも、私は一般的にWordPress Doing ItWrongからWordPressRightを知っていました。そして、決して「コアをハッキング」しないなど、WordPressのベストプラクティスを自慢することは心地よく自己主張していることに気づきました。
このエージェンシーでの私の最初のWordPress開発タスクは、停滞したプロジェクトを再開することでした。これは、当時の私のスキルセットにとってはかなり複雑なプロジェクトでした。 これには、WordPressの登録とログインフローの多くのカスタマイズが含まれていました。 以前の開発者は、コアのwp-loginファイルを編集するだけで大きな進歩を遂げたと言われています。
これは持続不可能であることがわかっていたので、私の最初の仕事は、バックアップ/復元プラグインをインストールし、WordPressコアを新しくダウンロードしたバージョンに置き換えることでした。 このプロジェクトでは、まだそれほど印象的なものは何も実行されておらず、フィルターを介して既存の機能セットを模倣できると確信していました。
私の新しい雇用主が熱狂していたので、その時点で私が持っていたかもしれないし持っていなかったかもしれないコーディング能力が何であれ、すぐに無関係になりました。 彼女は「コアをハッキングする」ことの重要性を理解していなかったし、私はそれを消化できる方法で説明するほど成熟していなかった。 彼女の眉を一時的に冷やした唯一のことは、私がインストールしたバックアップ/復元プラグインを介して元に戻すことができると彼女に保証したときでした。
これがどこに向かっているのか推測できますか？
そのプラグインは、運命がそれを持っているように、 wp-contentフォルダーのみをバックアップしました。 それらのコアファイルにWordPressのハッキングがあったとしても、それは永遠に失われました。 私はまだ彼女に戻ってきた私のメールを覚えています（彼女はこの時点で私をホームオフィスに追放してからずっと経っていました）：
みんな、私はバックアップを行うことができません。
私は本当にフィルターとアクションを介して彼女の希望する機能セットを完成させる準備ができていましたが、彼女はそれを聞きませんでした。 彼女はその場で私を解雇し、私を訴えると脅し、2週間の非常に大変な仕事に対して私にお金を払うことはありませんでした。 私はとても屈辱的でした。
この経験から私が学んだことはたくさんあります（今では明らかです）。 バックアップは、リハーサルと確認が完了するまでバックアップではないという一般的な教訓は、良い教訓です。 しかし、私にもっとこだわったのは、WordPress、特にWordPressコアでバックアップを正確に行う方法についての特定のレッスンです。
堅牢なバックアップ/復元システムを備えたWP-Engineのような管理された環境を本当に大切にすることを学びました。 多くのブティックホストには、バックアップを実行するためのさまざまなコマンドラインツールやその他の開発者向けの機能がありますが、WP-Engineが私のお気に入りです。 非常に大規模なネットワークがない限り、非常に高速です。 UIはシンプルです。 UI、期間があります。WordPressの使用方法を知っている人なら誰でもこれを使用できます。 つまり、おそらくはるかに高速なCLIアプローチや、Pleskに埋め込まれているあいまいなものとは対照的に、クライアントはこれを使用して理解し、監視して、使用していることを確認できます。 私は大ファンです。
プラットフォーム全体を兄弟ディレクトリにドラッグした時間
私はまだプロの職場にかなり慣れておらず、常にWindowsの人でした。 しかし、私の新しい仕事はMacショップで、それについてのすべてをすぐに愛するようになりました。 まあ、ほとんどすべて。 「マジックマウス」に困っているようでした。 Bluetooth接続が失われる傾向があり、再接続すると偶発的で恐ろしいドラッグアンドドロップアクションが発生することがありました。 それ以上に、私は新しい細かい運動技能に不器用でした。
最近では、WordPressの開発フローには、FTPを介した本番環境へのデプロイが含まれていました。 平日は、コードの記述、チャット、電子メールへの返信に費やすのは珍しくありませんでした。通常、Cyberduckをデスクトップで本番環境に公開し、新しいMagicMouseを介して行き来しました。 おやおや、それは悪い音だ！ しかし、それはそうだった。
ある日、プラットフォーム全体がなくなってしまいました。 私たちのシステム管理者は、それが何らかのDDoSか、一般的に彼のレベルの何かであるとすぐに推測しました。 私たち開発者に関しては、私たちは彼の本能を信頼し、彼がすぐにそれを理解すると思いました。
時間が経ちました。 その日が来て、去りました。 まだダウンしています。
翌朝までに状況は回復し、CTOは私に会議室に彼女に加わるように優しく頼みました。 システム管理者が問題を特定しました。 彼はFTPログを取得し、私のユーザーがプラットフォーム全体を兄弟ディレクトリに移動したことを確認しました。 つまり、 wp-contentはwp-includes下にネストされていました。
私は頭がおかしくなったが、CTOはそれについて素晴らしかった。 彼女は私が一般的に親切で説明責任のある従業員であることがわかりましたが、彼女は私に単なる苦痛を超えて、これが二度と起こらないようにする方法を考え出すように挑戦しました。 私は2つの本当に役立つものを見つけました。
1つ目は、Cyberduckがリモートからリモートへのファイル移動をまったく許可しないようにするCLIコマンドを見つけることでした。 これは良い安全対策であり、すぐに会社の方針として採用しました。
2つ目は、Gitを介したデプロイに強い関心を持ったことです。 最終的に、私はWordPressプラグインを作成して、Bitbucketのバージョン管理を通常のwp-admin更新フローに組み込むことにしました。 それ以来、本番環境へのFTPアクセスさえも持つ理由はほとんどありませんでした。 このプラグインは、私のお気に入りのプロの業績の1つです。 もちろん、Gitとの親和性は、今日の開発者にとっての前提条件です。
add_filter()を介してすべてのフロントエンドコンテンツを削除した時間
この時点で、WordPressの練習でかなり賢くなったと本当に思っていました。 リクエストは、特定のカテゴリの投稿に「バッジ」を追加することでした。 何らかの理由で、このようなテンプレートファイルにさらに別の条件を追加するのは初心者だけだということを念頭に置いていたので、誇りを持って次のフィルターを実装しました。
add_filter( 'the_content', 'myprefix_add_a_badge' ); function myprefix_add_a_badge( $content ) { global $post; if( ! has_category( 'sponsored', $post ) ) { return false; } $out = $content . myprefix_get_badge(); return $out; }これに何か問題がありますか？ ステージングですばやくテストして、必要な投稿にバッジが適用されていることを確認しました。 それから私はそれを配備し、その日のために仕事を辞めました。 ご想像のとおり、宇宙は爆発しました。
具体的には、バッジのない投稿がコンテンツなしでフロントエンドにレンダリングされていました。 理由がわかりますか？ 問題は、ガード状態で$contentを返す代わりに、 falseを返すことでした。 しかし、実際にはここには多くの間違いの層があります。
投稿がバッジを受け取ったことだけをテストすることに満足したのはなぜですか？ 他の投稿が無傷のままであることもテストしなかったのはなぜですか？ なぜ私はその日の遅い時間に本番環境にデプロイしたのですか？ 品質管理が完全に私が少しクリックしてページを更新することで構成されていたのはなぜですか？
これらすべての質問に対する答えは、成熟度として要約できます。 視覚的な回帰テストや単体テストなどに投資するようになる前に、この種の間違いを犯すことにうんざりするのに少し時間がかかるだけです。 この特定の間違いは、何百もの中で、最終的にラクダの背中を壊し、phpUnitとxDebugに非常に投資するようになったストローでした。 次に、これらのツールは、テスト可能なコードの記述について教えてくれました。これにより、テスト自体よりも多くのバグが防止された可能性があります。
無限ループ内でゼロ除算した時間
クライアントのリクエストは、日付が「2011年11月10日」ではなく「XYZ前」になるようにWordPressブログ投稿の署名記事を再フォーマットすることでした。 これを実現する方法は正確にはわかりませんでしたが、人気が高まっているように見える日付形式であることに気づきました。実際、Google博士からスニペットがすぐに提供されました。 それは私の地元で働いた！ それはたくさんの数学、特にたくさんの除算を持っていました。 なぜそれが機能するのか正確にはわかりませんでした。ネストされたループ、剰余、丸めなどがたくさんありました。 しかし、それはグーグル上にあり、それはうまくいったようで、私はそれを本番環境にデプロイするのに十分満足していました。
約30分後、システム管理者から不親切なSkypeを入手しました。 生産が落ちた。 水中で死んだ。 彼は私に最近ゼロ除算をしているのかと尋ねましたが、彼が何を指しているのかわかりませんでした。 これが何が起こったのかです。
信じられないかもしれませんが、サンプルサイズが十分に大きい場合、私が見つけた読み取り不可能な「ローカルで動作する」スニペットは、異常な動作をする可能性がありました。 日、時間、分のいくつかの不幸な組み合わせが提供されると、ルーブゴールドバーグループは時々数値をゼロで除算しようとしました。 高校の数学から思い出してください：
通常の算術では、0を掛けると（≠0と仮定して）aを与える数がないため、式には意味がありません。したがって、ゼロによる除算は定義されていません。 -ウィキペディア
では、これはコンピューターにとって何を意味するのでしょうか。 通常はログにエラーメッセージが表示されますが、私の場合はさらに悪化しました。数学エラーがループロジックに干渉し、ネストされたループが完了せずに実行され、無限ループが発生して死の白い画面が表示されました。 そしてそれはさらに悪化します！ ループの各反復がゼロ除算のエラーを書き込んでいたため、エラーログは素晴らしい比率に成長し、ファイルシステムを妨害し始めました。 これは、ばかげた自傷行為ではありますが、DDoS攻撃の影響を及ぼしました。
この間違いの悪い点は、トラフィックの多いサイトをダウンさせたことです。 この間違いの良いところは、仕事へのアプローチが劇的に変わったことです。 何よりも、理解せずに実行しようとする意欲に恥ずかしい思いをしました。 私は、必要に応じてスニペットの作成者にフォローアップする場合でも、すべての行を理解するために可能な限りの努力をせずに、スニペットを二度と貼り付けないことを誓いました。
それ以上に、初心者の開発者にはあまり読みにくいコードを二度と出荷しないことを誓いました。 私はWordPressのコーディング標準、テキストエディターの拡張機能、インラインコメントとドックブロック、さらにはタブとスペース、さらには古典的な通過儀礼に夢中になりました。 要するに、私はコードを書くのがいかに簡単であるかよりも、コードを読むのがいかに簡単であるかをもっと気にすることに決めました。 理解せずに貼り付けることに対するこの反抗により、私はサードパーティの依存関係を管理することに深い専門家の関心を抱くようになりました。このトピックは、その後の10年間でさまざまな執筆とスピーチの機会を刺激しました。
ああ、そしてこの間違いについて本当に面白いことは？ WordPressコアには、そのためのワンライナーソリューションがあります。
誰もがそれにうんざりするまで、プロジェクトのスパイラルを制御不能にした時間
私は本当に魅力的なプロジェクトを上陸させました。 私はテクニカルリードとWordPress開発エンジニアになる予定でしたが、Amazon AWS Lambda開発者と、JavaScriptレポートの深い専門家がいました。 複数の人から報告を受けたのはこれが初めてで、これまで取り組んだ中で最も複雑なプロジェクトでした。 それをWordPressプロジェクトと呼ぶことさえ、問題を非常に控えめに言っていましたが、WordPressはすべてをまとめる接着剤だったので、私が技術リーダーとして行動することは理にかなっています。
私の主な役割は通常、厳密に技術者であり、ミニマリズムに親しみがあるため、JiraやBasecampなどのタスク管理用の実際のプラットフォームを実装することは思いもよらなかったからです。 プロジェクトの最初のイテレーションでは、物事はかなり順調に進みました。 独自のコンポーネントで作業し、クライアントの仕様書を製品ロードマップと呼び、物事を結合する必要があるときにSlackを介して相互にpingを実行することができました。
問題は、クライアントに進捗状況を示し、フィードバックを実装し始めたときに始まりました。 3人のチームとして始まったものは、すぐに新しい規模になったことを感じました。誰がどのフィードバックの責任者であるか、そのフィードバックを実装するステータスは何か、実際には誰が誰と話しているのかさえ不明でした。 。 Gmailの制限であるスレッドあたりの返信数が100を数回超えました。
物事は不快になり始めました。 クライアントは、プロジェクトの方向性をコントロールできなくなったように感じたと思います。同様に重要なのは、プロジェクトのステータスが見えなくなったように感じたことです。 私のAmazon開発者は、ある日、「Trelloを使うべきかどうか疑問に思います」と述べました。
ええと、私は思った。 3人のチームにはそのようなプラットフォームが必要ですか？ 繰り返しになりますが、私の通常の傾向は、より少ないツール、より少ないオーバーヘッド、より少ない複雑さを好むことです。 しかし、プロジェクトはすでに私たち全員を土に引きずり込んでいたので、それを試すことの害は何でしたか？
私はすべての電子メール、すべての仕様ドキュメント、すべての異なるコメントスレッドをくまなく調べ、それらすべてをTrelloボードにマッピングしました。 すぐに、プロジェクトは、はるかに少ない精神的なオーバーヘッドで通信できたため、デジタル墓から復活しました。 メールの受信トレイやほとんど廃止された仕様書でテキストを検索する代わりに、素敵なボード、リスト、カードを用意しました。 機能のステータスを確認したり、フィードバックを組み込んだり、新しいタスクを実行したりするのは簡単でした。 だんだんと目が見えなくなってしまったような気がして、気づかなかったので、いきなりまた見えてきました。
確かに、コードはそれ自体を記述していませんでした。それでも非常にやりがいのあるプロジェクトであり、技術的なスキルをすべて活用する必要がありました。 しかし、それは一種のポイントです。プロジェクトを理解するためのインフラストラクチャがついにできたので、技術的なスキルを自由に適用できるようになりました。
そのプロジェクトはクライアントの満足のいくように完了したと言って嬉しいです。 今日、私はTrelloまたはJiraが2人以上のチームの事実上の要件であると考えています。
前進し、他人の過ちから学ぶ
軍隊にいる間に教えられた最も賢いことの1つは、次のとおりです。 大丈夫ではないのは、船長が中尉の過ちを犯したり、中尉が私的な過ちを犯したりすることです。」
言い換えれば、あなたの現在の責任のレベルにとって当然のことである一般的な間違いを犯しても大丈夫です。 さらに重要なのは、それらからどのように成長するかです。
私たち開発者は、他の人が私たちと一緒にいることを願って、間違いを犯したときに他の人に思いやりを持って学ぶことを願っています。 私は間違いを犯したときも好奇心と説明責任を果たし続け、それを乗り越えて革新を続けていきたいと思っています。 私は常にWordPressの専門家の刺激的なコミュニティに囲まれていることを望んでいます。彼らの過ちから学び、自分自身を作ることを避けることができます。 そして何よりも、私がここで共有したWordPressの間違いのように、他の人が私の経験から学ぶことができることを願っています。