私は最近、前の開発者がwp-adminディレクトリを変更したプロジェクトに取り組む必要がありました。Wordpressは常に更新されているので、私には悪い考えのように思えます。私はWordpressの変更に関する専門知識のレベルではありませんか?
5 に答える
オープンソースであるため、WordPressのようなソフトウェアはいつでも変更および拡張されるのが一般的だと思います。
変更するか変更しないかは、トレードオフの選択です。新しい機能はモジュールとしてカプセル化できます。これにより、機能が必要以上に統合されなくなる可能性があります。ただし、変更を完全に統合すると、新しいバージョンがリリースされたときにソフトウェアを簡単に更新できない場合があります。
ソフトウェアを直接変更するには、誰かがソフトウェアに精通している必要がありますが、これは必ずしも悪い考えではありません。
ちなみに、WordPressを変更することはほとんど必要だと思います。特に、適切なアーキテクチャを使用したり、実際に安全にしたい場合はそうです(わかりました、それはジャブでした、私を訴えます)。
これは、内部の事実上のフォークを維持する責任があることを意味するという点でのみ、悪い考えです... WordPress が更新をリリースするたびに、変更を新しい「実際の」 「ワードプレス。(3 方向差分とは、古いバージョンのフォークと標準の古いバージョンの間で差分を作成してパッチ セットを作成し、そのパッチ セットを新しいバージョンに適用することを意味します。) また、VCS を使用して自分自身を維持する必要があります。正気。
KISS の原則に従い、アプリケーション コードをいじらないことには何の問題もありません。
同じことを同じように効率的に行うプラグインを作成できる場合は、それを行う必要があるため、独自のフォークを維持する必要はありません。
ただし、アプリケーションコードをハッキングするだけで、WordPress が (効率性、セキュリティなど) 苦手なことがたくさんあります (多くの作業を必要とせず、必要のないコードを無効にするだけで) 改善できます。WordPress は、もともとソフトウェアやデータベースの設計に関する知識がほとんどない人々によって書かれた、汚れたレガシー スパゲッティ コードであり、リクエストごとにデータベースにクエリを実行して、それ自体siteurlが何であるかを確認するなど、途方もなく愚かなことをたくさん行います。 2 行のコードを変更するのに 5 分かかることは何も悪いことではありません。
私は Technorati ランキングの上位 20 位にランクされたブログでテクニカル リードとして働き、WordPress を単一のサーバー上でスケールし、次にクラスター (管理者アクセスとパブリック アクセス用に別のサーバーを使用) にスケールするために多くの作業を行いました。HTTP アクセラレータとして機能する上流のリバース プロキシ (Varnish または Squid) と、PEAR::Cache_Lite を使用したファイル システム キャッシングへのフェイルオーバーを備えた memcached にプラグインされる内部オブジェクト/ページ フラグメント キャッシュ システムがありました。多くの不要な SQL と処理を無効にするために、正気でキャッシュに適した HTTP ヘッダーを送信するなどのことを行うために、WordPress を変更する必要がありました。
MySQL のメモリのみの NDB クラスター ストレージ エンジンを使用して実行するように WP を変更しました。これは、多くのクエリでインデックスを指定することを意味していました (ただし、最終的には代わりに複製クラスターを選択しました)。管理者アクセスとパブリック アクセス用に別々のサーバーで実行するように変更する際に、パブリック側のバージョンをロックダウンして、読み取りのみを許可する大幅に削減された MySQL 権限で実行しました (3 番目の MySQL ユーザーはコメント権限を取得しました)。
深刻なコメント スパムの問題 (つまり、1 時間あたり 10,000 件) がある場合は、プラグイン以外のことをする必要があります。WordPress がそのコアを初期化するだけで、並行性のないスタンドアロン P4 では 0.5 秒のようなものであり、WP はコード ヘアボールであるため、最初にコアを初期化せずに何もする方法がないため、スパムはあなたを DOS します。
「WP-Cron」は脳死状態であり、これらの機能を実行するために実際の crontab にアクセスできる場合は無効にする必要があります。難しいことではありません。
要するに、あなたが変更を加えたいと思うかもしれない理由を永遠に列挙し続けることができます.
これを通じて、これらの変更を最小限に抑え、できるだけ明確に文書化することが、保守性の理由から当然の目標であり、意味がある場合は多くをプラグインとして実装しました。
WordPress の古いバージョン (1.0 や 2.0 の初期でさえも) では、WordPress 自体を変更することには目を向けませんでした。
ただし、WordPress のアーキテクチャは成熟しています。サイドバーを手動でコーディングする必要がなくなりました。代わりに、ウィジェットを使用するようにテーマを移植して、ウィジェットを作成することができます (なんて天の恵みでしょう!)。何かが表示される方法が気に入らない - テーマを変更するだけ! WordPress が何かを処理する方法が好きではありませんか? プラグインを作成します。WordPress の最新のモジュラー コンポーネント (ウィジェット、プラグイン、テーマ) では処理できない WordPress コード自体を変更する理由が思いつきません。
私は、WordPress のようなオープン ソース アプリの「内部」に常に潜入するタイプの人間です。ただし、最近では、コアの WordPress コードを変更する正当な理由はありません。
あるブログとフォーラムの組み合わせで、ユーザーが 1 つのフォームに入力して WordPress と phpBB の両方に同時にサインアップできるように、サインアップ手順をハックしました。プラグインを使ってそれを行うもっと良い方法があると確信していますが、それには予期しない利点が 1 つあります。それは、スパムボットを本当に混乱させることです。毎日数件の登録がありますが、フォーラムの活動期間中に約 2 件のスパム投稿がありました。
もちろん、私がお勧めするものではありません-どちらのソフトウェアもアップグレードできなくなります。
特に WordPress のように更新されるプロジェクトでは、可能な限りコア コードを変更しないよう強く主張する傾向があります。WordPress がプラグインなどで必要なことを実行できない場合は、Drupal のようなより拡張可能で汎用的なシステムを使用する方がよいでしょう。ブログ指向の CMS を別のものにハッキングする価値はないかもしれません。