mokkosan

まず、NiftyのWordPress簡易インストーラーを利用されている場合、すでにWordPressがサーバーにインストールされている状態です。そのため、FileZillaを使ってローカルのWordPressサイトをアップロードする際には、いくつかの考慮事項があります。

Nifty固有の詳細な設定については、Niftyのサポートに確認するのが最も確実ですが、ここでは一般的なWordPressサイトの移行方法について説明します。

1. WordPressのインストール場所の確認

Niftyの簡易インストーラーでWordPressが「homepage」ディレクトリの下にインストールされているとのことですので、FileZillaでNiftyサーバーに接続した際、「homepage」ディレクトリ内にWordPressのコアファイル（wp-admin、wp-content、wp-includesなど）がすでに存在するか確認してみてください。

2. 一般的なアップロード方法

ローカルで開発したWordPressサイトを、すでにWordPressがインストールされているサーバーに移行する際、最も一般的な方法は以下のようになります。

• サーバーのWebルートディレクトリの確認: NiftyのサーバーでWebサイトが表示される「Webルートディレクトリ」がどこになっているかを確認します。簡易インストーラーで「homepage」の下にインストールされているのであれば、通常はその「homepage」ディレクトリがWebルート、またはその直下のサブディレクトリがWebルートになっている可能性が高いです。
• ファイルのアップロード:
  • 既存のWordPressの上書き: ローカルのWordPressサイトのファイル（wp-admin、wp-content、wp-includesディレクトリ、およびルートにあるPHPファイルなど）を、サーバー上の既存のWordPressインストール先に上書きアップロードします。ただし、wp-config.phpファイルはサーバー側のデータベース情報が含まれているため、ローカルのものをそのまま上書きしないように注意が必要です。サーバーのwp-config.phpの内容とローカルのデータベース情報を比較し、必要に応じてサーバー側のwp-config.phpを編集してローカルのデータベース情報に合わせるか、新しいデータベースを作成して情報を記述します。
  • 下位ディレクトリへの設置: もしサーバーの既存のWordPressを保持しつつ、ローカルのサイトを下位ディレクトリ（例: homepage/newsite/）に設置したい場合は、ローカルのWordPressファイルをその新しいディレクトリにアップロードします。この場合、WordPressアドレスとサイトアドレスの設定変更が必要になります。
• データベースの同期: ファイルをアップロードするだけではサイトは正しく動作しません。ローカルのWordPressサイトのデータベースを、サーバーのデータベースにインポートする必要があります。phpMyAdminを使って、ローカルのデータベースをエクスポートし、サーバーのデータベースにインポートする形になります。

以上、ざっと説明しましたが、実はFTPよりもプラグインを利用した移行がおすすめです。

FTPソフトを使って手動でファイルをアップロードし、データベースを同期する方法は、WordPressの知識がある程度必要で、ドメインの書き換え作業など手間がかかります。

現在では、ローカルで作成したWordPressサイトをサーバーに移行する際、またはその逆でサーバーのサイトをローカルに持ってくる際にも、FTPよりもプラグインを利用する方が主流です。プラグインを使えば、どこをどこにアップロードするのかといった複雑なことを考える必要がなくなり、ドメインの書き換え作業も自動的に行ってくれるため、非常に簡単で手軽にサイトの移行ができます。ファイルだけでなく、データベースもまとめて数クリックで完了するので、手間が大幅に省けます。

いくつかおすすめのプラグインがありますが、例えば「All-in-One WP Migration」や「Duplicator」といったプラグインは非常に人気があり、多くのユーザーが利用しています。私も個人的には「UpdraftPlus」をよく利用していますが、用途や好みによって使い分けても良いでしょう。

プラグインでの移行は、初心者の方にとって特にメリットが大きいので、ぜひ検討してみてください。具体的なプラグインの使い方については、それぞれのプラグインの公式サイトや解説記事が参考になりますよ。

Lightningのユーザです。うちはWeb屋さんではなくて、建設業ですが、LightningのおかけでWeb関係は内製化できています。小さな工事店なのでそんなに年商が大きなわけではないですが、ホームページが年間売り上げの半分は集めてくれます。（残りは口コミとリピーターさんです。）

さて、Danganページビルダーは使ったことないですが、登録フォーム以外は無料版のVK Pattern Libraryからコビペで全部代用できそうですね。ですから、登録フォームすら自分で作りたくないという場合は、Danganページビルダーのメーカーさんにサポート依頼したほうがいいでしょう。

ところで、作ったページで成果を出すためには、どうやって作るかよりも、どういう構成にしてどういう言葉を使うのかの方がずっと大事です。また、登録フォームに関して言えば、EFO(Entry Form Optimization・入力フォーム最適化)という言葉もあるくらい大切なものなので、ご自分で設定できるようにした方が、将来より幸せになれると思いますよ。

この投稿は単なるお節介なので、煮るなり焼くなりお好きにどうぞ(^^;;

想像を逞しく考えるに、おそらく、普通にログインできた4月12日以降に、サーバのシステムがバージョンアップして、古いWordPressが動作範囲外になってしまったため、エラーが発生しているのではと思います。もしかしたら、今までご自身で、WordPressやプラグイン・テーマを、こまめに更新してきていなかったのではないかと想像します。

これは例えて言えば、オイル交換をずっとしていない車に乗っていて、しかも警告灯が点灯しているにもかかわらず、それを放置して乗り続けた挙句に、車が故障して動かなくなってしまった状態と言えるでしょう。

多少なりとも車をいじった経験があれば、詳しい人に聞きながら、なんとか応急処置くらいはできるでしょう。しかしながら、全く触ったこともないし、用語もわからんという人は、聞いただけでどうにかできるとは思えないですよね。さっさとプロの自動車工場までレッカーしてもらう方が早く対処できるはずです。

今回の件でいえば、ことりさんがあげたチェックリスト等は、ごく基本の診断方法です。それによって、問題がどこにあるのか切り分けて、原因を特定するために必要になります。それがチンプンカンプンということでしたら、取りうる道は三つしかありません。

1. 諦める。→新しいサイトを作って、中身を移動する。
2. 学ぶ。→1から学んで対処できるように頑張る。
3. 依頼する→餅は餅屋です。WordPressのプロに頼みましょう。

どの道を選ぶかは、あなた次第です。

ブラウザのキャッシュは削除してみましたか？また、いつも使っているブラウザとは違うもの、例えばChromeを常用にしているならFirefoxを使ってみるとか、で状況は変わりますか？なお、それはないとは思いますが、Swell側に原因がある場合、有償製品なので、このフォーラムでは取り扱うことができません。メーカーサポートに聞いてもらうことになります。

なるほど。では、まず届いたメールの指示通りにしてみるというのはどうでしょうか。

ログインするのにはIDとパスワードが必要なわけですが、お使いのパスワードが過去に流出したリストに含まれているものだったようで、そのままだと乗っ取られる可能性があるので、アカウントにプロテクトをかけたと書いてありますよね。で、ログイン画面で示してある数字を入力してログインし、パスワードをすぐに変更してください。と指示があります。これらは行いましたか？

これらを行わずにJetpackだけ止めてログインしたとすると、危険なパスワードのままプロテクトが解除されてしまって、その隙に何らかの攻撃があっておかしくなっている可能性もあるかと思います。（あくまでも可能性ですからそうなっていると指摘しているわけではありません。）

(6)ですが、wpフォルダの上の階層はどうなっていますか？

なお、netowlは私は使っていないので固有の事象に関しては分かりません。他の方のアドバイスも待ってみましょう。

「ログインしていない状態でwp-adminのフォルダやファイルにアクセスすると、wp-login.phpにリダイレクトされるものだと認識しております。」とお書きですが、この認識が間違っています。

Apacheのリダイレクトの場合、例えば、.htaccessなどに

Redirect 301 /a.php /b.php

と書くか、または、

RewriteEngine On
RewriteRule ^a.php$ b.php [R=301,L]

と書くことで実現できます。

この時Apacheは、ブラウザからa.phpが要求されたら、a.phpを開くことなく即座にb.phpを開きます。ですから、b.phpが閲覧制限されていたら、a.phpもまた閲覧制限が適用されます。

ところがwp-admin/index.phpは、そういう正規の意味でのリダイレクトが行われているわけではありません。WordPress の PHP コード（アプリケーションレベル）で実行されている擬似的なリダイレクトです。その動作は次のようになっています。

処理の流れ（ログインしていない場合に wp-admin/index.php にアクセスすると…）

1. ブラウザが https://example.com/wp-admin/index.php にアクセス
2. Apache は そのファイルを通常通り処理し、PHP が実行される
3. wp-admin/index.php → wp-admin/admin.php が読み込まれ、
4. admin.php 内で WordPress コア関数 auth_redirect() が呼ばれる
5. この関数が「ログインしていない」と判定すると、wp_redirect( wp_login_url() ); exit; というコードにより、PHP側で wp-login.php へリダイレクト
6. ブラウザが wp-login.php?redirect_to=... に飛ばされる

という流れです。

つまり、一旦index.phpは開かれるわけです。ということは、wp-login.phpにいくらIPアドレス制限をかけても、制限をかけてないindex.phpはアクセスし放題なわけです。もちろん、index.phpで処理された結果転送されたwp-login.phpは開かれないですよ。でも、index.phpは開かれた後なので、ログには制限されているはずのIPアドレスが残るのです。

FilesMatchディレクティブの動作はまず、ファイル名に対して指定したものと合うかどうかを比較し、ヒットした場合には、ディレクティブ内のルールを適用します。よく似たのに、Filesディレクテイブがあり、これもファイル名に対して比較がはたらきます。これはどちらも、ファイル名に対して比較がはたらきます。ですからファイルではないwp-admin（ディレクトリ名）にはマッチしません。つまり、ご指定のディレクティブだと、wp-admin/index.phpなどにはアクセスし放題です。

また、そもそもサーバの設定で.htaccessでFilesMatchディレクトリが許されているのかどうか確認する必要があります。Apacheの場合なら、AllowOverride Allでないと、.htaccessのFilesMatchディレクティブは無視されます。

AllowOverride Allという前提で、wp-admin以下のファイルにアクセスできないようにするには、wp-adminディレクトリ内にディレクティブ指定しないで単純に

Order deny,allow
Deny from all
Allow from 1.1.1.1
Allow from 1.1.1.2

とした上で、フロントエンドで動くプラグインやテーマのJavaScriptがアクセスする可能性の高いadmin-ajax.phpのみ制限を解除するように次の指定を続けます。

<Files admin-ajax.php>
    Order allow,deny
    Allow from all
    Satisfy any
</Files>

以上で、指定したIPアドレスのみがアクセスできるようになるでしょう。

なお、これでも改善しない場合、Sucuri がリモートのIPではなくてCDN経由のIPを拾っている可能性があります。Suc uriの動作は詳しくないので、他の人の答えに期待しましょう。

追加ですが、PHPに関していえば、8.0以下はすでにEnd of lifeを迎えており、セキュリティホールがあってもメンテナンスされない危険な状態です。（今日2025/03/23現在）また、8.1は2025年いっぱい、8.2は2026年いっぱいでEnd of lifeを迎えます。その辺りの事情も踏まえて、どのバージョンで運用するのかを決めましよう。