WordPress の重要性: 開発者の視点

開発者はプラットフォームが気に入らないにもかかわらず、WordPress などの CMS を使用することになることがますます増えています。

熟練した開発者は、特にコーディングが得意な開発者の場合、カスタム ソリューションの使用を好むことがよくあります。 カスタム ソリューションを使用すると、非常にうまく機能する非常に洗練されたアプリケーションを作成できます。 ただし、開発者は、プラットフォームが非常に嫌いであっても、WordPress のような CMS を使用することになります。

この記事は、これらの開発者を対象としており、WordPress (WP) を使用する際に遭遇する多くの課題に対処しています。 これらの問題が何であるかを説明し、提案もします。世界で最も愛されている CMS である WordPress の主要な重要性のいくつかを考慮に入れるのに本当に役立つ WP ツールキットを提供する Plesk の助け。

開発者が WordPress を使用する理由

間違いなく、WordPress は市場で最も人気のある CMS であり、それには十分な理由があります。 このセクションでは、実際に独自のコードを記述できる経験豊富な開発者の間でも CMS が非常に人気がある理由について説明します。

まず、WordPress は非常に簡単にインストールできます。 必要なのは、標準の LAMP/LEMP 環境 (Linux、Apache/Nginx、PHP、DBMS としての MySQL/MariaDB) だけです。 持っている場合は、WordPress のインストールを開始できます。

WP CMSには、フロントエンドのルックアンドフィールをカスタマイズするテーマや機能を追加するプラグインなど、幅広いアドオンが付属しているため、カスタマイズは簡単です. 独自のテーマを作成することも可能で、経験豊富な開発者は独自のプラグインを作成することもできますが、このプロセスはより複雑です.

おそらく、WordPress が人気を博している最大の理由は、もちろん、技術に詳しくないユーザーでもアクセスできるという事実です。 インストールされた WP は、コーディングの経験やソフトウェアの理解を必要とせずにうまく動作するため、初心者ユーザーは仕事の直後に Web サイトを公開し、WordPress インスタンスをセットアップできます。

WordPressの問題は正確には何ですか？

さて、世界で最も人気のある CMS には、考慮すべき問題がたくさんあります。 WordPressの問題について大騒ぎするつもりはありませんが、以下は率直な議論であり、この信じられないほど人気のあるCMSの背後にある開発チームが次の点を肯定的な批評として受け取ることを願っています. WordPress が開発者にとってイライラする理由は次のとおりです。

幅広い能力を発揮しますが、決して優秀ではありません

WordPress の始まりは単純でした。 WP は、ブログを書いて公開したい人のためのプラットフォームとして生まれました。 CMS は何年にもわたって完全に変化し、今ではその謙虚な始まりとはまったく異なります。 一部の人々は、サイト全体を管理するための基本的なシステムとして、オンライン ショップのプラットフォームとして、さらには静的サイトを生成する方法としても使用しています (クレイジーですが、これは何年にもわたって見てきました)。

これは CMS の適応性を強調するものであり、私たちもその意見に同意しますが、非常に柔軟であることに伴う問題は、単一の役割で優れた能力を発揮することが難しくなることです。 これを実現する XNUMX つの方法は、プラグインのレンズを通して見ることです: 利用可能な何千もの WordPress プラグインは、人々が WordPress を強制的にそうではないものにしたり、もっと悪いことをさせたり、できないことをさせようとしている様子を示しています。そうです、痛いです。 これが、私たちが WordPress を使用し、それを頻繁かつ喜んで使用する場合、絶対に必要でないプラグインをロードしない理由です。 その時点で、私たちはそれらを自分で作ることを好みます。

明らかに、WordPress はこの「自作」のアプローチのために作られています。明らかに柔軟性には多くの利点があります。 しかし、特定のタスクに重点を置いていないと、CMS は明確なソリューションを提供するのに苦労します。 すべての人にとってすべてになろうとするこの焦点は、大きな問題を引き起こしています。 ただし、指摘しなければならないことがあります。WordPress は、ブログ、複雑でない Web サイト、および e コマース サイトを構築するためのプラットフォームとして引き続き機能します。

ハックとクラック: WordPress は開かれたドアになる可能性があります

つまり、WordPress は 24 時間体制でハッキングされており、これは開発者の世界から聞いた最大の不満です。 それを否定することはできません。CMS はセキュリティ ホールでいっぱいであり、終わることはありません。 短いブランケットのようなものです。片面を調整すると、もう片面が現れます。 ハッキングの数の一部は、WordPress の人気によるものですが、WordPress がオープンソースであることが原因でもあります。

誰でも CMS のオープンソース コードを表示できるため、ハッカーはコードの弱点を見つけることができます。 オープンソース コードが悪いアプローチであると言っているわけではありませんが、WordPress CMS のオープンソースの性質が、終わりのないセキュリティ問題の一因になっていると考えています。

分析によると、WordPress サイトはインターネットの XNUMX 分の XNUMX 以上を占めています。 WordPress チームはこれを認識しており、CMS が安全であることを確認するためにできる限りのことをしようとしていますが、今日の開発サイクルは非常に高速であるため、複雑なアプリケーションを完全に保護することは困難な場合があります. また、セキュリティの取り組みが失敗すると、何百万もの Web サイトが危険にさらされる可能性があります。

もちろん、明らかな「WordPress インスタンスを更新する」以外に、WordPress のセキュリティ上の課題に対する明確な解決策はありません。 それでも、WordPress のリリース サイクルには、独特で際限のない問題が伴います。

多くの人が、WordPress のセキュリティを管理するのは簡単だと言いますが、それは大部分が正しいのですが、問題は、WordPress が安全であることを確認するために、なぜサイト所有者が To Do リストを作成する必要があるのか​​ということです。 このセキュリティが WordPress のすぐに使える部分ではないのはなぜですか?

• 誰かが実行可能ファイルを WordPress にアップロードするのは簡単であり、このオプションはデフォルトで制限されるべきです。 少し賢い人が悪意のあるコードを含むファイルを PHP スクリプトにアップロードするだけで、サイトが危険にさらされます。
• 現在、オプションはファイル システムで構成できます。 代わりに、WordPress はこれを取り除き、ファイル システムが「読み取り専用」であると想定する必要があります。 WordPress のコアはこれを行いますが、プラグインはこの動作パターンに従いません。 実稼働中に構成ファイルを変更するプラグインに遭遇した場合は、使用を中止してください。 これはファイル システムが書き込み可能であることを示しており、その結果、悪意のある変更を簡単に行うことができます。 解決策の XNUMX つは、システムのルートから wp-config.php ファイルを削除することです (WordPress はとにかく動作します)。ただし、これはセキュリティを完全に保証するものではなく、無意識の開発者によって書かれた多くのプラグインの正しい機能を妨げるものです。 .
• デフォルトでは、WordPress はユーザーが好きなだけログイン試行を行うことを許可しています。 これにより、ハッカーがログインに成功するまでランダムなパスワードを試行し続けるブルート フォース攻撃への扉が開かれます。 WordPress CMS は、インストール時に無制限のログイン試行を無効にする必要があります。

これは完全なリストではなく、いくつかのポイントにすぎません。 明らかに、大規模なソフトウェア ソリューション、特にオープンソース ソリューションは、攻撃に対して完全に無敵というわけにはいきません。 しかし、重要な点は、深刻な開発者が WordPress を使用することに消極的であるということです。 熟練した開発者は、未知の将来の脆弱性を心配することなく、ニーズをエレガントに満たし、厳密に保護できるまったく新しいアプリケーションを構築することを好みます。

または、PLESK 設定を最大限に活用し、WordPress に「非推奨」、さらに悪いことに「無料」、さらに悪いことに不適切に作成されたプラグイン (それについて判断するには、その分野での経験が必要です) を読み込まないようにすることで、まだ可能です。 WordPress を安全性の面でも優れたプラットフォームにします。 しかし、それはもはや「日曜大工」の管理ではなく、専門家の手が必要です。

問題の原因としてのプラグイン

優れた開発者は、最初に行き詰まったときにプラグインに頼ることはありません。 代わりに、優れた開発者はシンプルで洗練されたソリューションを構築しようとします。 それどころか、インターネットでプラグインを検索して常にプラグインに依存したり、コミュニティによって提案されたプラグインに依存したりすることは、非常に間違った考え方です。

最終的に、プラグインを使用すると、WordPress に特定の機能を簡単に追加できます。これにより、WP で利用できる幅広いプラグインが CMS の強みになりますが、リスクも伴います. プラグインは物事をより簡単かつ迅速にすることができますが、プラグインは多くのセキュリティ リスクをもたらすと同時に、使用できる WP のバージョンを選択するように強制し、同時に WordPress インスタンスを信じられないほど膨張させます.オンラインでのプレゼンスを苛立たせたり、危機に陥らせたりすることで、サイトを開く速度、したがってアクセシビリティ、およびその結果として検索エンジンでの正しいインデックス付けを測定します。

プラグインとセキュリティ

まず、プラグインが作成するセキュリティの問題を見てみましょう。 あるレポートでは、WordPress の既知のセキュリティ問題の半数以上がプラグインに起因していると示唆しています。 開発者は、プラグイン メーカーが従う良い慣行に従う必要がありますが、これはあまり良くないかもしれません。 したがって、開発者はプラグインを使用する前に徹底的にテストする必要があります。 この審査プロセスにより、プラグインで節約した時間をある程度取り除くことができます。 その時点で、サイトに追加するために必要な機能をゼロから開発することを検討することもできます。

WP バージョンの制限

「バージョン制約」として知られるプラグインは、実行できる WP CMS のバージョンを制限できます。 現在、WordPress はリリース サイクルに非常に積極的であるため、定期的に新しい更新をリリースしており、実際、プラットフォームが特定の月にいくつかの小さなバージョンまたはパッチをリリースすることがよくあります。 WP チームは常に攻撃ベクトルを修正しているため、これは理解できます。 しかし、これらの更新にはすべて問題があります。WP の更新によってプラグインが破損し、サイトが機能しなくなったり、クラッシュしたりする可能性があります。

もちろん、CMS を最新の状態に保つ必要がありますが、プラグインによって課されるバージョンの制約により、この作業が困難になる可能性があります。 一部のプラグイン開発者は常にプラグインのテストと更新を行っていますが、この小さな「世界」は プレミアムプラグイン 大多数を代表するものではありません。 これらのプレミアム プラグイン以外では、WP のバージョン アップグレードが文字通りサイトを破壊する可能性があるという現実的なリスクがあります。

プラグインの肥大化

ほとんどの開発者は、余分なコードを使用しない無駄のないプロジェクトを構築することが重要であることを知っていると仮定しましょう。 現在、一部のプラグインはこの原則に準拠していますが、多くのプラグインはユーザーが抱える可能性のあるすべての問題を解決しようとするため、非常に肥大化しています。 開発者は、プラグインが XNUMX つの問題を解決する一方で、自分のサイトに関係のない他の XNUMX の問題の解決策を提供していることに気付くことがよくあります。 （テーマと「ビルダー」は言うまでもありません）。

プラグインは WordPress ワークフローを中断します

最後に、多くのプラグインが作成するもう XNUMX つの一般的な問題は、プラグインが WordPress でのユーザー エクスペリエンスを妨げる可能性があるという事実です。これは残念ながら効果に依存します。 肥大化プラグイン WordPressの。 たとえば、プラグインは、投稿の作成方法とサイト全体への配布方法を完全に変えることができます。

これにより、WP 開発者が非常によく直面する問題が発生します。彼らは、単にプラグインを使用するのではなく、プラグインを「回避」する必要があると感じています。 必然的に、プラグインはプロセスの問題を解決しているように見えるため、開発者はプラグインをバイパスするこのプロセスを実行します (これは必然的に存在しません)。

Webアーキテクチャは進化しました

WordPress がしばらく前から存在していることはすでに述べました。 Web サイトが構築されたとき、開発者は、Web サイトでは常に単一のサーバーと単一のファイル システムが使用されると考えていました。ただし、開発者は複数のノードを利用する、いわゆるマイクロサーバー アーキテクチャを使用することが増えています。このような作業方法は、よりスケーラブルで柔軟であるためです。しかし、複雑なアーキテクチャで WordPress を使用すると、WP CMS の更新がほぼ FTP に依存するなど、問題が発生する可能性があります。

現代の開発者は明らかに、FTP 経由でコードを更新することは時代遅れにすぎないと考えるでしょう。 開発者は通常、特定のワークフローを使用して、コードが動作するようになる前に潜在的な問題を阻止できるようにします。 これは、開発がローカルで行われ、コードがバージョン管理され、そのコードも自動的にテストされることを意味します。これらはすべて、継続的な統合プロセスを通じて行われます。 したがって、短いループを実行する環境に新しいコードをロードするだけで、問題が発生する可能性が高くなります。

パッチの問題よりも大きな問題は、XNUMX つのノードで XNUMX つのファイル システムを使用しているという単純な仮定です。 Web サーバーのマルチノード クラスターは、ハードウェア障害とパフォーマンスの両方を改善します。このため、このアプローチがますます採用されています。 ただし、WP にはハードルがあります。FTP 経由でテーマまたはプラグインの更新をインストールすると、一度に XNUMX つのファイル システムしか更新できないということです。 そのため、マルチノード クラスタでは、すべてのノードに対してこの更新を行う必要があります。

開発者はこの問題を回避できますが、簡単には解決できない問題が残ります。 さらに、このプロセスではファイルシステムが書き込み可能である必要があり、WordPress の心臓部であるデータベースに重大なセキュリティ上の懸念が生じます。

孤立したデータとデータ構造全般

まず、WordPress のデータ構造は単純です。 ただし、WP データベースに冗長なテーブルがあることがすぐに明らかになります。 たとえば、なぜメタデータを「wp_posts」と「wp_postmeta」という XNUMX つのテーブルに分ける必要があるのでしょうか。 すべてのデータを XNUMX つのテーブルに含めたほうがよいのではないでしょうか? 同じことが、メタデータ用に XNUMX 番目の関連付けられたテーブルを持つコメント テーブルにも当てはまります。

その結果、データベース全体に余分なデータが残ります。 はい、WP には、孤立したデータの影響を軽減するのに役立ついくつかの機能が含まれていますが、数千行の行数を操作する必要がある場合、関数は失敗します。 基本的に、WordPress の機能はサーバーのタイムアウトを引き起こし、メモリ リークを引き起こし、単純に効果的ではありません。

もちろん、SQL クエリを直接記述して、孤立したデータを単純に削減することもできます。 ただし、正しい SQL クエリを作成するには、テーブルがどのように接続されているかを完全に理解する必要があります。 WordPress データベースのデータ分離の度合いは、単純に不必要であることがわかります。

改善のために Plesk Toolkit for WordPress が行うこと

Plesk の WordPress Toolkit を使用すると、単一のコントロール パネルから、WordPress インスタンスを簡単にセットアップおよびカスタマイズできます。 Webサイトにインストールされている限り、使用できます。 WordPress Toolkit が WP の処理に役立ついくつかの領域を次に示します。

セキュリティ管理

ツールキットを使用すると、最も明白なセキュリティ ホールを自動的に閉じることができます。 たとえば、XML を RPC ping に切り替えたり、「wp-content」フォルダーが安全であることを確認したりできます。 ツールキットは、サイトのセキュリティ ステータスを表示し、セキュリティを向上させるための推奨事項である「危険」または「警告」で問題にフラグを立てます。

WP インスタンスの更新

Toolkit 3.x 以降のアドオン機能として利用できる Smart Updates 機能を使用すると、サイトを破壊するリスクなしに、運用サイトの実行を維持しながら同時に更新することができます。 このツールは、更新によって発生する可能性のある問題をチェックし、何らかのリスクがあるかどうかを通知します。

クローニング

WordPress サイトのコピーを作成する理由はたくさんあります。 たとえば、ライブに移行する前に変更をテストできるステージング サイトがあるとします。 準備ができたら、サイトのコンテンツをコピーします。

または、公開サイトがあり、そのコピーを作成して、一般ユーザーがアクセスできないようにする場合があります。 もう XNUMX つの例は、WordPress インストールのモデル コピーを持っていて、それをテーマやプラグインを含めて自動的に複製したいプロの開発者です。

また、いくつかの変更でサイトの外観がどのように変わるかを示すなど、さまざまな理由でサイトのコピーをいくつか作成したいというクライアントもいます。

理由が何であれ、WordPress Toolkit の複製ツールを使用すると、サイト ファイル、サイト データベース、すべての WP CMS 設定など、すべてを簡単にコピーできます。

シンクロニッツァーネ

さまざまな理由から、XNUMX つの WordPress Web サイトが一致していることを確認したい場合があります。 WP Toolkit を使用すると、WP データベースとすべての WP ファイルの両方を自動的に同期できます。

サイトのステージング コピーがあり、パブリック コピーが別の場所で実行されている場合、ステージング サイトで行った変更を WP ライブ サイトにコピーする必要があるため、サイトを同期することができます。

同様に、本番サイトからステージング インスタンスに一部のデータをコピーして、ステージング バージョンに加えられた変更がライブ データとうまく連携するかどうかを確認することができます。 または、ステージング サイトに加えた変更によってデータベース テーブルが変更された場合、ツールキットでは必要に応じてこれらの変更をデータベースに同期することしかできません。

WP Toolkit の同期機能のもう XNUMX つの使用例は、開発者がステージング サイトを WordPress の製品版に更新し、その変更をライブ サイトにミラーリングしたい場合です。

WP CMS 全体、またはその一部のみを同期するオプションがあります。 したがって、WP のファイル、そのデータベース、またはその両方をミラーリングできます。 データベース全体を同期するか、テーブルのみを同期するか、ソースにはあるが宛先には存在しないテーブルを同期するかを選択できるという点で、さらに細分性が提供されます。 個々のテーブルをミラーリングすることもできます。

WP でのバグハンティング

Plesk WordPress Toolkit では、デバッグ モードを有効にすることで、開発者が Web サイト ソースのエラーを自動的に検出して修正することもできます。

結論。

以上のことから、協力する開発者やあなたをフォローできる代理店を選択するだけでなく、何よりも WordPress でサイトをホストするホスティングを選択することが非常に重要になることは明らかです. これらのことからでも、プロのホスティングにダークサイトがあるかどうかが何を意味するかを理解しています.

WordPress は扱いが簡単な「オブジェクト」ではありません。 確かに、あなたは自由に感じ、開発者を必要としない、または代理店に縛られていないと思います。自分でできることは素晴らしいことだと思いますが、実際には、真実はそうではないと言い、今日のセキュリティは重要なテーマです.第三者に対する義務と責任のおかげで、もはや二次的ではなく一次的です。