WordPressのデータベースプレフィックスを変更してセキュリティを強化する方法

WordPressサイトをセットアップする際に最初に行うことの1つは、データベースのプレフィックスをデフォルトのwp_からユニークなものに変更することです。これは多くのウェブサイト所有者が見落としがちな簡単なセキュリティ対策ですが、サイトの保護に大きな違いをもたらす可能性があります。

ほとんどのWordPressサイトは同じデフォルトのデータベース構造を使用しているため、ハッカーにとって格好の標的となりやすいです。データベースプレフィックスをカスタマイズすることで、自動化された攻撃の成功をより困難にし、サイトに重要なセキュリティレイヤーを追加できます。

既存のWordPressサイトを保護する場合でも、将来のプロジェクトのためにこのベストプラクティスを学びたい場合でも、データベースプレフィックスを安全に変更する複数の方法を紹介します。

このガイドでは、使いやすいプラグインを使用する方法と手動の方法の両方について説明しますので、ご自身の状況に最適なアプローチを選択できます。

WordPressのデータベースプレフィックスを変更する方法

要約: WordPressデータベースプレフィックスの変更は、多くの自動化された攻撃からサイトを保護できる、シンプルでありながら効果的なセキュリティ対策です。サイトを完全にハッキング不可能にするわけではありませんが、実装に費用がかからない重要なセキュリティレイヤーを追加します。

Solid Securityプラグインを使用する方法は初心者にとって最も安全なアプローチですが、データベースの操作に慣れている場合は、phpMyAdminを手動で操作する方法でより多くの制御が得られます。バックアップを作成し、すべてが正しく機能することを確認するために時間をかけてください。

下のクイックリンクを使用して、記事内を移動できます。

WordPressデータベースプレフィックスを変更する理由

WordPressデータベースプレフィックスは、小さな技術的な詳細のように思えるかもしれませんが、ウェブサイトのセキュリティ設定において重要な役割を果たします。すべてのWordPressインストールは、このプレフィックスを使用してデータベース内のサイトデータを整理します。

デフォルトでは、WordPressはすべてのデータベーステーブルのプレフィックスとしてwp_を使用します。これは、投稿がwp_postsというテーブルに保存され、ユーザーがwp_usersに保存されるなどのことを意味します。

問題は、ハッカーがこのデフォルト構造を知っていることです。

主要なセキュリティ企業からのセキュリティレポートによると、多くの自動攻撃はデフォルトのwp_プレフィックスを特に標的とするように設計されています。ハッカーがデータベーステーブル名を簡単に推測できると、攻撃が成功する可能性がはるかに高くなります。

データベースプレフィックスを変更する主なメリットは次のとおりです。

  • 隠蔽によるセキュリティを追加します: それ自体が完全なセキュリティソリューションではありませんが、カスタムプレフィックスはレイヤードセキュリティ戦略の重要な部分です。これにより、デフォルト設定に依存する低労力で自動化された攻撃にとって、サイトははるかに困難な標的となります。
  • SQLインジェクション攻撃からの保護: 多くの自動化されたSQLインジェクション攻撃は、デフォルトの wp_ プレフィックスを標的とするようにプログラムされています。これを変更することで、これらの一般的な自動ボットからサイトを不可視にし、より簡単な標的に移動するように強制します。
  • ターゲットスキャンを削減: 脆弱なWordPressサイトをスキャンするボットは、カスタマイズされた設定に一致しないデフォルトのデータベースパターンを探すことがよくあります。
  • 安心を提供: データベース構造がユニークであることを知ることで、サイトのセキュリティに対する自信がさらに深まります。

新しいWordPressのインストール時には、常にデータベースのプレフィックスを変更しています。なぜなら、これは非常に簡単な手順でありながら、多くの一般的な攻撃方法を防ぐことができるからです。

重要: データベースプレフィックスの変更は高度な操作です。このチュートリアルで推奨されていることを行う前に、必ずWordPressデータベースをバックアップしてください。

1つの間違いでサイトにアクセスできなくなる可能性があり、バックアップが唯一のセーフティネットです。毎日のバックアップを保持するために、Duplicatorのようなプラグインを使用することをお勧めします。


方法1:Solid Securityプラグインを使用する(初心者向け)

WordPressデータベースプレフィックスを変更する最も簡単な方法は、さまざまな脅威からウェブサイトを保護するセキュリティプラグインである無料のSolid Securityプラグインを使用することです。

このアプローチを初心者におすすめするのは、プラグインが必要なすべてのデータベーステーブルと設定ファイルを自動的に更新してくれるからです。コードに触れたり、データベースを直接操作したりする必要はありません。

この人気のセキュリティプラグインの詳細については、詳細なSolid Securityレビューをご覧ください。

ステップ 1: Solid Security プラグインのインストールと設定

まず、無料のSolid Securityプラグインをインストールしてアクティブ化する必要があります。詳細については、WordPressプラグインのインストール方法に関するステップバイステップガイドを参照してください。

有効化後、セットアップウィザードを使用してプラグインを設定する必要があります。開始するには、WordPress ダッシュボードで Security » Setup に移動してください。

ウィザードは、ウェブサイトの基本的な設定を案内します。

ウェブサイトの種類を選択したり、サイトのスキャンを実行したりするよう求められます。

ウェブサイトの種類を選択

ウィザードの各ページを注意深く読むようにしてください。ほとんどのウェブサイトではデフォルト設定で問題ありません。

私の経験では、オンボーディングウィザードは10分未満で完了するはずです。ウィザードを終了すると、基本的なセキュリティ機能が有効になります。

ステップ 2: データベースプレフィックスの変更

プラグインの設定が完了したら、データベースプレフィックスを変更できます。WordPress ダッシュボードから、Security » Tools に移動してください。

この画面には、「データベーステーブルプレフィックスの変更」というラベルのツールが表示されます。

データベースプレフィックスをセキュアに変更する

「実行」ボタンをクリックするだけで続行できます。

プラグインはランダムなプレフィックスを自動的に選択します。次に、サイトをメンテナンスモードにし、すべてのWordPressテーブルのプレフィックスを変更し、wp-config.phpファイルを更新してから、サイトをメンテナンスモードから解除します。

これらはすべて非常に迅速に行われ、各テーブルの名前が変更されるプロセスを監視できます。

ステップ3:サイトが機能していることを確認する

これで完了です。プラグインがすべての難しい作業を行ってくれました。最終確認として、すべてがスムーズに実行されていることを確認することは常に良い考えです。

ウェブサイトのホームページにアクセスして、正しく読み込まれることを確認してください。その後、WordPress管理画面からログアウトし、再度ログインしてみてください。両方の操作がうまくいけば、新しいデータベースプレフィックスは機能しています。🎉


方法2:phpMyAdmin を使用した手動での方法

データベースプレフィックスを手動で変更したい場合や、プラグインを使用したくない場合は、phpMyAdminを介して自分で実行できます。この方法では完全な制御が可能ですが、より技術的な手順が必要であり、エラーのリスクが高くなります。

開始する前に、WordPressサイトをメンテナンスモードにすることをお勧めします(方法1のプラグインはこれを自動的に行います)。そうしないと、ウェブサイトの訪問者にとって悪いユーザーエクスペリエンスを引き起こす可能性があります。

ほとんどのユーザー、特に初心者の方には、プラグインを使用する方法を強くお勧めします。

上級ユーザー向けの注意: 一部のプラグインは、設定を特別な形式(シリアライズデータと呼ばれる)で保存します。直接SQLクエリを実行すると、このデータが破損する可能性があります。これが、これらのエラーを防ぐためのセーフガードが含まれているプラグインメソッドを強く推奨するもう1つの重要な理由です。

ステップ1:wp-config.php でテーブルプレフィックスを変更する

まず、FTPを使用してウェブサイトに接続するか、WordPressホスティングアカウントのファイルマネージャーアプリを使用する必要があります。

次に、WordPress のルートディレクトリにある wp-config.php ファイルを開く必要があります。ここで、テーブルプレフィックスの行を wp_ から wp_a123456_ のような別のものに変更できます。

そのため、行は次のようになります。

$table_prefix  = 'wp_a123456_';

注意: テーブルのプレフィックスは、数字、文字、およびアンダースコアのみを使用して変更できます。

ステップ2:すべてのデータベーステーブル名を変更する

次に、phpMyAdmin ツールを使用してデータベースに接続する必要があります。

ホストが cPanel ダッシュボードを使用している場合、そこで phpMyAdmin を簡単に見つけることができます。

cPanelでphpMyAdminを選択する

デフォルトの WordPress テーブルは 12 個あるため、手動で変更するのは面倒です。

その代わりに、上部にある「SQL」タブをクリックする必要があります。

phpMyAdminでのSQLクエリ

次に、次のSQLクエリを入力できます。

RENAME table `wp_commentmeta` TO `wp_a123456_commentmeta`;
RENAME table `wp_comments` TO `wp_a123456_comments`;
RENAME table `wp_links` TO `wp_a123456_links`;
RENAME table `wp_options` TO `wp_a123456_options`;
RENAME table `wp_postmeta` TO `wp_a123456_postmeta`;
RENAME table `wp_posts` TO `wp_a123456_posts`;
RENAME table `wp_terms` TO `wp_a123456_terms`;
RENAME table `wp_termmeta` TO `wp_a123456_termmeta`;
RENAME table `wp_term_relationships` TO `wp_a123456_term_relationships`;
RENAME table `wp_term_taxonomy` TO `wp_a123456_term_taxonomy`;
RENAME table `wp_usermeta` TO `wp_a123456_usermeta`;
RENAME table `wp_users` TO `wp_a123456_users`;

wp-config.php ファイルを編集する際に選択したデータベースプレフィックスに変更することを忘れないでください。

重要: このクエリは、12個のコアWordPressテーブルのみを名前変更します。多くのプラグインは、デフォルトのwp_プレフィックスを使用する独自のデータベーステーブルを作成します。

これらのテーブルを特定し(テーブル名にプラグインの名前が含まれていることが多い)、上記のSQLクエリに各テーブルのRENAME行を追加する必要があります。

この手順を忘れると、プラグインが機能しなくなります。

たとえば、wp_yoast_indexable という名前のテーブルが表示された場合、SQL クエリに次の行を追加する必要があります。

RENAME table `wp_yoast_indexable TO wp_a123456_yoast_indexable`;
ステップ3:Options テーブルを更新する

次に、options テーブルを検索して、古い wp_ プレフィックスをまだ使用しているフィールドを探す必要があります。最も重要なエントリは wp_user_roles で、これはユーザー権限を制御します。これが更新されないと、ユーザーは正しくログインできなくなります。

関連するすべてのエントリを自動的に更新するには、次の SQL クエリを使用できます。wp_a123456_ を新しいプレフィックスに置き換えることを忘れないでください。

UPDATE `wp_a123456_options` SET `option_name` = REPLACE(`option_name`, 'wp_', 'wp_a123456_') WHERE `option_name` LIKE 'wp_%';

このクエリは、option_name列でwp_で始まるすべてのエントリを検索し、その部分を新しいプレフィックスに置き換えます。

ステップ4:UserMetaテーブルの更新

同様に、ユーザーの権限と設定を格納するusermetaテーブルを更新する必要があります。wp_capabilitieswp_user_levelのようなキーを更新する必要があります。

meta_key 列のすべての古いプレフィックスを検索して置換するには、次のクエリを実行します。クエリで新しいプレフィックスを使用していることを確認してください。

UPDATE `wp_a123456_usermeta` SET `meta_key` = REPLACE(`meta_key`, 'wp_', 'wp_a123456_') WHERE `meta_key` LIKE 'wp_%';

これにより、すべてのユーザーが正しい権限と設定を維持できます。

これでサイトをテストする準備が整いました。上記の手順に従っていれば、すべて正常に動作するはずです。ただし、トラブルシューティングのヘルプが必要な場合は、続けてお読みください。


データベースプレフィックスの変更に関する問題のトラブルシューティング

手順を注意深く実行しても、WordPressデータベースプレフィックスを変更した後に問題が発生することがあります。ここでは、最も一般的な問題とその解決方法を説明します。

ログインの問題

プレフィックスを変更した後に WordPress 管理画面にログインできない場合は、通常、一部のデータベースエントリが正しく更新されていないことが原因です。これは、options または usermeta テーブルのエントリの更新を忘れた場合に、手動メソッドで最も一般的に発生します。

これを修正するには、phpMyAdmin に戻ります。

具体的には、options テーブルで wp_user_roles という名前のエントリ(古いプレフィックスを使用)を確認し、新しいプレフィックス(例:wp_a123456_user_roles)に名前が変更されていることを確認してください。

また、usermetaテーブルでmeta_keyエントリ(例:wp_capabilities)を検索し、それらが正しく更新されていることを確認してください。

データベース接続エラー

WordPressのサイトで「データベース接続確立エラー」というメッセージが表示されることがあります。これは通常、wp-config.phpファイルとデータベーステーブル名に不一致があることを意味します。

wp-config.phpファイル内のプレフィックスが、アンダースコアを含むデータベーステーブルのプレフィックスと正確に一致していることを確認してください。

WordPressインストール画面の表示

これは恐ろしいですが修正可能な問題です。これはほとんどの場合、wp-config.php ファイルが新しいプレフィックスで更新されたものの、データベーステーブルの名前が正常に変更されなかったことを意味します。

WordPressが設定ファイル内のプレフィックスに一致するテーブルを見つけられない場合、インストールが必要だと判断します。

これを修正するには、wp-config.phpファイルを編集して、プレフィックスを元のものに戻す必要があります。

  1. FTPクライアントまたはホスティングプロバイダーのファイルマネージャーを使用して、ウェブサイトに接続します。
  2. サイトのメインフォルダにある wp-config.php ファイルを見つけます。
  3. テーブルプレフィックスを指定する行を見つけます。そこには、新しい(そして間違った)プレフィックスが表示されています: $table_prefix = 'wp_a1b2c3_'
  4. 元のプレフィックス(通常は wp_)に戻します: $table_prefix = 'wp_'
  5. ファイルを保存し、サーバーに再度アップロードします。

ウェブサイトは正しく表示されるはずです。この問題は、プラグインがデータベーステーブルの名前を変更するのを妨げる、厳格なファイル権限を持つホスティング環境で発生することがあります。

ソリューションとサポートリソース

それでも問題が解決しない場合は、以下の手順を試してみてください。

まず、バックアップを復元し、より慎重にプロセスをやり直してください。だからこそ、開始前にバックアップを作成することが非常に重要です。

次に、手動で実行した場合は、代わりにSolid Securityプラグインの方法に切り替えることを検討してください。手動で実行する際に簡単に見落としがちな多くのエッジケースを自動的に処理します。

最後に、問題が解決しない場合は、ウェブホスティングのサポートチームに連絡してください。多くの場合、データベース関連の問題を特定するのに役立ち、プレフィックスの変更プロセスを支援できる場合があります。

WordPressデータベースプレフィックスの変更に関するFAQ

データベースのプレフィックスを変更するのは怖いと感じるかもしれませんが、特にWordPress初心者の方にとってはそうです。

これらは、このプロセスについて最もよく聞かれる質問と、自信を持つのに役立つ明確な回答です。

WordPressのデフォルトのデータベースプレフィックスは何ですか?

デフォルトのWordPressデータベースプレフィックスはwp_で、wp_posts、wp_users、wp_optionsなどのすべてのデータベーステーブルに使用されます。このプレフィックスは、手動で変更されない限り、すべてのWordPressインストールで同じです。

WordPressのデータベースプレフィックスを変更すると、ウェブサイトが壊れる可能性はありますか?

はい、WordPressのデータベースプレフィックスの変更は、正しく行われないとウェブサイトを壊す可能性があります。そのため、開始前に完全なバックアップを作成し、すべてのデータベース参照が正しく更新されるように、手順を慎重に実行することが不可欠です。

データベースプレフィックスを変更した後、ログインできなくなった場合はどうすればよいですか?

プレフィックスを変更した後にログインできなくなった場合は、通常、一部のデータベースエントリが正しく更新されなかったことを意味します。バックアップを復元してプロセスを再度試すか、Solid Securityプラグインの方法を使用してください。このプラグインはこれらの更新を自動的に処理します。

WordPressセキュリティ強化のための追加リソース

この記事でWordPressデータベースプレフィックスの変更方法を学べたことを願っています。これは、WordPressサイトを保護するための一歩にすぎません。サイトをさらに安全にし、さまざまな種類の攻撃からより良く保護するために、他にも多くの手順を実行できます。

ここに私が設定を推奨する追加のセキュリティ対策をいくつか示します。

この記事が気に入ったら、WordPressのビデオチュートリアルについては、YouTubeチャンネルを購読してください。 TwitterFacebookでもフォローできます。

開示:当社のコンテンツは読者によってサポートされています。これは、当社のリンクの一部をクリックすると、当社が手数料を得る可能性があることを意味します。WPBeginnerがどのように資金提供されているか、それがなぜ重要か、そしてどのように私たちをサポートできるかについては、こちらをご覧ください。当社の編集プロセスはこちらです。

究極のWordPressツールキット

無料のツールキットにアクセスしましょう - すべてのプロフェッショナルが持つべきWordPress関連の製品とリソースのコレクションです!

読者とのインタラクション

142 CommentsLeave a Reply

  1. ガイドをありがとうございます。WordPressを使い始める前は、ユーザーがもちろん「admin」で、プレフィックスが「wp_」というデフォルトのインストールを使用していました。後になって、セキュリティの観点からそれは良くないこと、そしてカスタムプレフィックスを持つ方がはるかに良いことを知りました。すでに稼働しているウェブサイトの設定を変更することには少し抵抗があり、知識も十分ではありませんでした。このガイドに従って、小さなサイトでプレフィックスを変更してみたところ、本当にうまくいきました。そのため、セキュリティを少しでも向上させるために、他のウェブサイトでも同じことをするつもりです。素晴らしいです。

    • あなたの励ましと、どのようにうまくいったかについての経験の共有に感謝します。新しい WordPress サイトで変更することにしました。確立されたサイトではまだ変更する勇気がありません。私もこのガイドに従って、小さなウェブサイトで試して、それが機能するかどうかを確認します。

  2. クエリを「wp\_%」に調整する必要があります。これにより、アンダースコア文字がエスケープされます。SQLでは「1文字」の値を持つため、そうでなければ、多くの方が私の助言に従って、名前に「wp」が含まれるものはすべて取得してしまうでしょう!また、最初の「%」文字も不要です。これは、先頭に何も付かない「wp」で始まる名前を探しているためです。オプションテーブル内の内部出現箇所については、プレフィックスを変更するために組み込みのphpMyAdmin機能を使用する可能性がある方にとっては、非常に良いアドバイスです。これはメインテーブル名のみを変更し、テーブルフィールド内は検索しません。

    • Thank you for your feedback, we will look into this code again, as this was for a search only and not a replace it was set up to have a broader search to be safe :)

      管理者

  3. これはWordPressのセキュリティにとって目から鱗でした。
    シンプルさゆえにデータベースのプレフィックスを変更する必要性を感じたことはなく、そのままにしておくことが危険だとは知りませんでした。
    ほとんどの初心者はデータベースのプレフィックスをそのままにして、変更しないのではないかと思います。
    新しいWordPressサイトをインストールする際には、必ずこのことを念頭に置きます。

    • はい、私も含め、多くの初心者ブロガーは、その意味を知らなかったため、変更せずにそのままにしています。新しいWordPressのインストール時に変更するのが最も簡単で最良の方法ですが、確立されたブログでは困難です。

    • その通りです、Moinuddinさん。多くの初心者(私も含めて)はこのステップを見落としがちです。「デフォルト」というプレフィックスは、誤った安心感を与えがちです。それを変更することで、自動化されたスクリプトを使用する攻撃者にとって、追加のハードルとなります。これは大きな違いを生むことができる簡単なセキュリティ対策です。

  4. こんにちは。WordPressテーブルのプレフィックスを変更することは非常に重要です。なぜなら、このプレフィックスはデフォルトであり、ほとんどの人が変更しないため、ハッカーによるテストの対象になりやすくなるからです。したがって、それを変更することは理にかなっており、すべての友人に推奨しています。WordPressのインストール中にプレフィックスを変更するのがはるかに良いです。しかし、インストール後でもテーブルプレフィックスを変更することは可能です。

  5. こんにちは。
    WordPressのウェブサイトのデータベースプレフィックスを更新するために、この記事を参照しています。
    OptionsテーブルとUsermetaテーブルの更新について混乱しています。それぞれのSQLクエリを実行したところ、transient_wp_cloudflare、dismissed_wp_pointers、tlwp_feedback_data、wpseo_socialなどの行も結果に含まれていました。
    そのため、wp_が中間や末尾にあるような行も更新する必要があるのでしょうか、それともwp_page_for_privacy_policyのように先頭にwp_プレフィックスがある行だけを更新すればよいのでしょうか。
    プレフィックスとは、先頭にあるものを意味することは理解していますが、この混乱を解消したいと思っています。

    • いいえ、それらのテーブルはプラグインやその他のツールがそれらの特定のタイトルを探しているため、そのままにしておく必要があります。

      管理者

  6. あるプラグイン開発者が、データベースプレフィックスなしではWordPressブログは存在しないと言っていました。これは非常に混乱しています。なぜなら、私は5年間アクティブなWordPressブログを持っていましたが、データベースプレフィックスがありませんでした。では、データベースプレフィックスなしでWordPressサイトを持つことは可能なのでしょうか?

    • WordPress には、ユーザーが変更する必要なくデフォルトでデータベースプレフィックスがありますが、これはプレフィックスをカスタマイズする方法です。

      管理者

  7. こんにちは、データベースファイルを確認するために別のチュートリアルに従っていましたが、私のファイルは「wphy_users」のような名前になっていることに気づきました…これは、ここで説明されていることの拡張であり、前にアンダースコアがないだけでしょうか?

    返信をお待ちしています!

  8. こんにちは、しばらく前にテーブルプレフィックス名を変更しました。古い名前とメインフォルダ(データベースだと思います)にも古い名前が付いた新しいマップがいくつか追加されていることがわかりました。今、私のフォルダはすでに標準の「wp」プレフィックス名とは異なる名前を持っていることがわかりました。そのため、変更はそもそも必要ありませんでした。今できることは、テーブルの半分が1つの特定の名前を持ち、残りの半分が別の名前を持っているということです。すべてが正常に機能しているので、もう変更したくありませんが、唯一の質問は次のとおりです。テーブルに異なる名前が付いていることは問題ですか?すべて同じ名前である必要がありますか、それとも関係ありませんか?

    • 追加のテーブルはプラグインによって作成された可能性があります。すべてのコンテンツで同じプレフィックスを使用することをお勧めします。

      管理者

  9. マルチドメインホスティングを利用しています。WPをインストールする際、テーブルプレフィックス(デフォルトでwp_と書かれています)に何を入力すればよいですか?

    できるだけ早く提案してください…

    • サイトのデータベースプレフィックスを変更する場合、プレフィックスを何にするかを選択します。

      管理者

  10. データベースプレフィックスを変更した後、WordPress管理ダッシュボードにアクセスすると「申し訳ありませんが、このページにアクセスする権限がありません」というエラーが表示されます。

  11. こんにちは、WordPressのマルチサイトを使用しています。ホームサイトのデータベースプレフィックスとメディア添付ファイルのフォルダを、ホームサイトを含むすべてのサブサイトで使用したいと考えています。何かアイデアはありますか?

    • ホームサイトのメディアライブラリに画像をアップロードし、サブサイトに画像を埋め込むことで、そのようなことが可能です。

      管理者

      • それは知っていますが、フィーチャー画像はそれをサポートしていないので、サイト全体のメディアデータベースプレフィックスをすべてのサイトで使用したいです。

  12. 試してみましたが、ログインできなくなりました。おそらくセキュリティプラグインを使用しているためです。

    すべてのプラグインを無効にして削除し、コアWPのみのインストールを残してから変更した場合、usermetaまたはoptionsテーブルの変更をすべて変更する必要がなくなるでしょうか?つまり、テーブルの変更を壊さずに安全に行うための最も安全な方法でしょうか?

    その後、プラグインを再インストールします。

  13. この記事によると、WordPressのテーブルプレフィックスを変更しても、サイトのセキュリティを強化する効果は全くありません。
    テーブルプレフィックスを変更したとしても、ハッカーはこのコードを実行することでテーブルプレフィックスを見つけることができます。
    SELECT DISTINCT SUBSTRING(`TABLE_NAME` FROM 1 FOR ( LENGTH(`TABLE_NAME`)-8 ) )
    2
    FROM information_schema.TABLES WHERE
    3
    `TABLE_NAME` LIKE ‘%postmeta’;

    • Mishelさん、こんにちは。

      私たちはそれに同意しません。何かを曖昧にするセキュリティ対策はすべて、経験豊富なハッカーによって解明される可能性があります。これらの手順は、全体的なセキュリティを破りにくくするための難易度レイヤーを追加するだけです。テーブルプレフィックスの変更には間違いなく欠点はありません。自動化された明白なハッキング試行をブロックできるのであれば、それだけの価値は十分にあります。

      管理者

  14. wp_optionsとwp_usermetaの両方のクエリは、wpが含まれるデータを返しますが、それらもリネームすべきでしょうか?
    例:wpseo_title, _yoast_wpseo_

  15. 私は非常に愚かな間違いを犯しました。wp-configファイルで、$table-prefix変数を末尾のアンダースコアなしで割り当てていました。たとえば、「wp_12345」のようになっていますが、「wp_12345_」であるべきです。

  16. これでファイルが破損し、ローカルサイトでもライブサイトでもファイルにアクセスできなくなりました。幸いなことに、これはすべて学習用とテストサイトなので、何がうまくいかなかったのでしょうか?

  17. うまくいきました、本当にありがとうございます!ただし、プレフィックスを変更した後、バックエンドで次の警告が表示されます。2回試しましたが、

    Warning: Cannot modify header information – headers already sent by (output started at /myurl/wp-config.php:1) in /myurl/wp-includes/option.php on line 837

    警告: ヘッダー情報を変更できません – ヘッダーは既に送信されています (出力は /myurl/wp-config.php:1 で開始されました) /myurl/wp-includes/option.php の 838 行目

    手伝ってもらえますか?

    • こんにちは、Joschさん

      このエラーは、wp-config.php ファイルの末尾に空白または余分な行があることが原因で発生する可能性があります。それを削除すると問題が解決する場合があります。

      管理者

  18. こんにちは、記事をありがとうございます。それについて質問があります。WordPressにインストールされているプラグインがある場合、上記で説明された方法は同じですか?それとも、このステップを完了するために他の何かが必要ですか?
    WordPressサイトに20以上のプラグインがインストールされているため、その点についてご案内いただけると幸いです。
    ご協力ありがとうございます。

  19. 将来的にプラグインなどをアップデートする際に問題は発生しませんか?

    これのためにiThemes Securityの組み込み高度機能を使用しようとしましたが、エラーが発生しました:「無効な形式」エラーにより、リクエストが予期したとおりに完了しませんでした。返されたデータの形式を認識できませんでした。これは、プラグイン/テーマの競合またはサーバー構成の問題が原因である可能性があります。

    なので、手動で実行する勇気もありません…

  20. こんにちはチーム

    共有していただきありがとうございます。

    最後のステップを除き、すべてのステップは順調に進みました:UserMeta Table。

    MySqlではプレフィックスを変更できません。

    それが私が受け取るエラーメッセージです:

    #1054 – 「where句」に不明な列「wp_new_usermeta.umeta_id」があります

    何かアドバイスをいただけますか?

    ありがとうございます。

    Joe

    • インストール時にデータベースのプレフィックスを入力するように求められるオプションがあります。したがって、好きなプレフィックスを入力できます!!

  21. 新しいプレフィックスを作成する際に、まだ「wp_」を含める必要がありますか?ハッキングの可能性を減らすために、英数字の文字列を使用することはできますか?

    ありがとう、

    トム

  22. 良い記事です。OptionsテーブルとUserMetaテーブルのクエリは、あまり詳しくない人を混乱させると思います。どのようにかはわかりませんが、それらの手順についてもう少し詳しく説明していただけると助かります。

    ガイドに従って、データベーステーブルのプレフィックスを正常に変更しました!

  23. This does not add really any kind of security.
    If I can inject SQL, I can query against information_schema.tables and get info about tables, whatever fancy prefix you put in front of names ;)

    • 本当にその通りです。優れた.htaccessはSQLインジェクションもブロックします。それに加えて、私のWordPressのインストールでは、データベース接続よりもはるかに前に収集された特定の情報に基づいてそれらの認証情報を割り当てることにより、ごく一部のユーザーにのみ完全なデータベースアクセスを提供します。それ以外のすべてのユーザーは非常に基本的なアクセスしか得られません。

      wpzlogin.phpを非表示にし、cpanelでwp-adminへのアクセスをさらにパスワード保護することで、ほとんどのハッキング試行を阻止しました。wpログインページにアクセスするにはログインが必要です。

  24. こんにちは、素晴らしい記事です!テーブルプレフィックスの置換を簡略化することを考えていました。

    Phpmyadminでデータベースを選択すると、テーブルのリストが表示されます。
    1. すべて選択のチェックボックスを有効にする

    2. ドロップダウンで「選択した項目と置き換える」を選択します。

    記事で述べられているように、オプションから既存のプレフィックス「wp_」を入力します。

    4.記事で述べられているように、新しいプレフィックスをオプション「wp_a123456_」に入力します。

    5. 送信をクリック

    これは、プラグインのテーブルを含むすべてのテーブルのテーブルプレフィックスを変更するのに役立ちます。

    サイトのハッキング解除に関するサポートが必要な場合は、これらの記事を確認できます

    • ということで… @SHIVI

      テーブルのプレフィックスを変更するには、設定ファイルに入り、プレフィックスを変更してから、手順1〜5に進むだけで、テーブルのプレフィックスはどこでも(プラグインなど)変更されます。
      それで終わりですか?

    • オプションテーブルとusermetaテーブルのプレフィックスは、手動で更新する必要があります。

  25. すべてのテーブルに対してSQLを実行する必要がありますか?つまり、15個のテーブルがあります。それとも、説明されている2つのテーブルを変更するだけで問題が解決しますか?

  26. 皆さん、こんにちは。

    これらの指示をありがとう。大文字の問題を解決するのに役立ちました。

    初心者として、テーブル名を手動で変更する方法についてのガイダンスがあればよかったと思います。その方がもっと安心できたでしょう。

    また、私のような初心者にとっては、OptionsテーブルとUsermetaテーブルの変更方法に関する指示があれば役立ったでしょう。

    再度感謝します。あなたなしではできませんでした!

  27. 指示をありがとうございます。プレフィックスから大文字を削除する必要があり、これにより、まさに変更が必要なレコードが表示されました!

    ヒント:phpMyAdminを使用すると、下部にあるすべてのレコードを確認し、「テーブルプレフィックスを置き換える」を選択できます。これにより、「から」と「へ」の値を持つ標準の置換ボックスが表示されます。
    特にデータベースが大きい場合、手順1でのタイピングを大幅に節約できます。

  28. 皆さん、こんにちは。

    これらの変更を行ったところ、現在のユーザーとしてサインインできず、WordPressを再インストールするように求められました…

    イゴール

  29. 私のSQL DBにはテーブルプレフィックスがないため、WordPressのWpconfig.phpで$table_prefix = '';がないと時々エラーが発生します。
    テーブルプレフィックスを追加する方法
    設定ファイルに追加して、すべてのテーブルを同じプレフィックスに変更しようとすると
    WPにログインすると「アクセス権がありません」というエラーが表示されます。

  30. プレフィックスの名前を変更するためのSQLを更新してください。WordPressは現在「wp_termmeta」テーブルを追加しています。これは以下のSQLに含まれています。

    RENAME table `wp_commentmeta` TO `wp_yoursitename_commentmeta`;
    RENAME table `wp_comments` TO `wp_yoursitename_comments`;
    RENAME table `wp_links` TO `wp_yoursitename_links`;
    RENAME table `wp_options` TO `wp_yoursitename_options`;
    RENAME table `wp_postmeta` TO `wp_yoursitename_postmeta`;
    RENAME table `wp_posts` TO `wp_yoursitename_posts`;
    RENAME table `wp_termmeta` TO `wp_yoursitename_termmeta`;
    RENAME table `wp_terms` TO `wp_yoursitename_terms`;
    RENAME table `wp_term_relationships` TO `wp_yoursitename_term_relationships`;
    RENAME table `wp_term_taxonomy` TO `wp_yoursitename_term_taxonomy`;
    RENAME table `wp_usermeta` TO `wp_yoursitename_usermeta`;
    RENAME table `wp_users` TO `wp_yoursitename_users`;

  31. データベースのテーブル名を変更すると、ギャラリーのすべての画像が消えてしまいます。その理由がわかりません。この問題を解決するために誰か助けてくれませんか?

    • この問題は、データベース内のシリアライズされたデータ文字列(ギャラリー画像に使用)を正しく更新しない場合に発生します。これを行う良い方法は、プラグインWP Migrate DBを使用することです。Lynda.comに優れたチュートリアルがあります(ただし、ターゲットデータベースのプレフィックスはソースデータベースと同じにしてください)。
      私はこれを苦労して学びました。最初からやり直そうとしたところ、バックアップも faulty であることがわかりました。幸いなことに、私のウェブホストには、移行を再開するために使用できる古いバックアップがありました。WP Migrate DBがそのトリックをやってくれました。

  32. _usermetaまたは_optionsテーブルに更新が必要なフィールドが見つかりません。それらが特定のテーブルを参照していない限り、更新する必要はありません。テーブルプレフィックスであり、変数プレフィックスではありません。

    • 実際、訂正します。デフォルトのWordPressインストールに含まれるものがいくつかあります。

      prefix_options
      prefix_user_roles

      prefix_usermeta
      prefix_capabilities
      prefix_user_level
      prefix_dashboard_quick_press_last_post_id
      prefix_user-settings
      prefix_user-settings-time

      他のフィールドを更新する際は注意が必要です。プラグインは、定義されたプレフィックスまたは`wp_`をプレフィックスとして使用する場合があります。常にバックアップを取り、開発環境またはステージング環境でテストしてください。

  33. こんにちは、
    質問があります。すべてのプレフィックスをwp_somethingから別の名前に変更したと仮定します。これらの変更はデータベースの既存のフィールドのみに行われます。しかし、WordPressのPHPファイル内のコードはそのまま残るのではないでしょうか???したがって、次回新しいユーザー登録やその他の登録を行う場合、PHPファイル内のメインコードは変更されないため、エンティティは再びwp_somethingとして保存されるのでしょうか…???

    ありがとうございます…

  34. UPDATE `wp_a123456_options` SET `option_name`=REPLACE(`option_name`,’wp_’,’wp_a123456_’) WHERE `option_name` LIKE ‘%wp_%’;

    UPDATE `wp_a123456_usermeta` SET `meta_key`=REPLACE(`meta_key`,'wp_','wp_a123456_') WHERE `meta_key` LIKE '%wp_%';

    変更を行いましたが、その後再度以下のクエリを実行すると、プレフィックスが変更されていないと表示されます。
    SELECT * FROM `wp_a123456_options` WHERE `option_name` LIKE ‘%wp_%’

  35. この投稿とコメントへの返信には、非常に重要な要素が欠けています。テーブルはwp_で始まる必要がありますか?

    wordpress.orgでの別の議論で、実際には必要ないことが示されていました。モデレーターがこの質問に答えてくれていれば助かったのですが。

    また、dismissed_wp_pointersに関する質問には明確に回答されませんでした。私は自分のものを変更しました。

  36. 皆さん、こんにちは。

    これらの手順を実行しましたが、サイトのバックエンドまたはフロントエンドを表示しようとすると、次のエラーが表示されます。

    エラー: wp-config.php の $table_prefix には、数字、文字、およびアンダースコアのみを含めることができます。

    テーブルプレフィックスは小文字のアルファベットとアンダースコアのみであると確信しています。

    何かアイデアはありますか?サイトはローカルホストにあります。

    Cheers.

  37. 本当にありがとう!古いデータベースを復元しようとしましたが、うまくいきませんでした。その後、新しいデータベースプレフィックスが古いものと異なることに気づきました。あなたが推奨したすべてを行い、うまくいきました!

  38. 上記の手順を実装した後、「このページにアクセスするには権限が不足しています」というエラーが発生します。これを解決するにはどうすればよいですか?????

  39. 素晴らしいヒントをありがとうございます。
    質問があります。
    post_meta テーブルで使用されている “wp_….” も変更する必要がありますか?

コメントを残す

コメントを残していただきありがとうございます。すべてのコメントは、当社のコメントポリシーに従ってモデレーションされますので、ご了承ください。メールアドレスは公開されません。名前フィールドにキーワードを使用しないでください。個人的で有意義な会話をしましょう。