mokkosan
フォーラムへの返信
-
フォーラム: インストール
返信が含まれるトピック: wordpress.orgのログイン方法についてもう少し、段階を追ってお聞かせください。
【1】「サーバー契約をして、リンクからwordpress.orgに自動で入れるようになっていたのですが、サーバーネーム変更の際に誤ってwordpress.comに繋げてしまいました。」
の部分が、ほとんどの人にとってわかりづらいのではないかと推測します。分解すると、
①サーバー契約をして → mixhostと契約して、サイトを立ち上げた。（そのサイトのドメインを仮にexample.jpと仮定しますね。）この状態で、example.jpのホームページは見れたのですね？
②リンクからwordpress.orgに自動で入れるようになっていた → おそらくここがほとんどの人には意味不明なんだと思います。
②Q1:リンクというのは、どこにあるリンクですか？mixhostのマイページ的なものにそういう機能があるのですか？また、そのリンクというのは、自分で設定したのですか？それとも自動でできたのですか？
②Q2:通常、何らかのリンクからご自分のサイトを開く場合、そのリンク先はexample.jpにするものです。何故、wordpress.orgにリンクをしたのですか？wordpress.orgは言ってみれば「WordPress利用者互助会コミュニティ」的なサイトなので、ここにログインしても、大抵の人はフォーラムに書き込みするくらいのことしかできません。もしかして、リンクから自動で入った先は、あなたのホームページの管理画面だったりしませんか？そうだとすると、それはwordpress.orgにリンクをしていたのではなくて、あなたのサイトのWordPressにリンクしていただけだと思いますが、違いますか？
③サーバーネーム変更の際に誤ってwordpress.comに繋げてしまいました→ここもよくわからないです。
③Q1:サーバーネーム変更というのは、どの画面で行ったのですか？あなたのサイトのWordPressの管理画面か、mixhostの何かの画面か、あるいはまた別のところでか、どこで名前を変えたのでしょうか？
③Q2:wordpress.comに繋げたということの意味を教えてください。サーバーネームをwordpress.comに変えたということではなくて、②のリンクのリンク先をwordpress.comに変えたという意味ですか？それとも、さらに別の何かですか？
【2】「wordpressのお問い合わせ」について、直前のレスでおっしゃっていますが、そのお問い合わせは、どこに対して行ったのですか？mixhostですか？wordpress.comですか？それとも別のところですか？
①保存データはwordpress.orgにある→これは100%あり得ないです。mixhostとwordpress.orgが連携してデータを保存するサービスなんてやってないです。mixhostに限らずwordpress.orgはそういうデータ預かりはしていないので、自分のサイトのデータをwordpress.orgにおいているという人はいません。もしかして教えてくれた人が言っているのは、mixhost内にあるバックアップデータのことを指しているのではないですか？
②URLは削除した欄しか残っていません→ URLというのは、インターネット上の住所みたいなもんですよね。これは、何かリストのようなものがあって、そこに登録されていたURLを削除してしまったので空欄になっているという意味でしょうか？だとしたら、その欄というのは、どこのどの画面のことを言っているのでしょう？ほとんどの人は、それが何を指し示しているのか想像がつかないと思います。
フォーラム: 使い方全般
返信が含まれるトピック: サブドメイン内固定ページが意図しないURLで閲覧できるなるほど、それも意図していないのに閲覧できるというわけですね。
ちなみに、サーバにFTPなりでアップロードしたファイルのディレクトリ構成ですが、サイトA・www.〇〇.jpの中身を置いたディレクトリと、サイトB・▲▲.〇〇.jpのWordPressを置いたディレクトリは、全く違うディレクトリなんですよね？
例えば、サイトAが /サーバのルート/www/html に https://www.〇〇.jp/ でアクセスできるトップページがおいてあるとした場合、サイトBは /サーバのルート/www/html2 とか、サイトAとは被らない形でWordPressが置いてあるのですよね？（ディレクトリ名は違うでしょうから読み替えてください）
フォーラム: 使い方全般
返信が含まれるトピック: サブドメイン内固定ページが意図しないURLで閲覧できるその挙動は、WordPressのせいではなく、Webサーバの設定のせいだと思います。
手元の端末からそのサイトの特定のページを開こうとした場合、手元の端末のブラウザが、直接サーバのWordPressとやりとりしているわけではありません。ブラウザがやりとりしている相手は、あくまでサーバで動くWebサーバのプロセスです。
(1)ブラウザが、「https://▲▲.〇〇.jp/recruit/をください」と要求→
(2)Webサーバが「▲▲.〇〇.jpへの要求があったらまずこのディレクトリを見ること。」と設定されているディレクトリを開く→
(3)そこにあるWordPressが「こんなんありまっせ」とWebサーバにHTMLでデータを返す→
(4)Webサーバはそのデータをブラウザに送る→
(5)ブラウザがHTMLをレンダリングしてあなたの目に映る
このうち今回の問題は(2)で、〇〇.jpを要求されたWebサーバが、▲▲.〇〇.jpにあるWordPressを開いていることです。これは、勝手には起こらないので、気がつかないうちにそういう設定になっている可能性があります。（そうなりうる設定はいくつか考えられます。）
なお、確認ですが、https://www.〇〇.jp/recruit/を開いた場合はどうなりますか？
- この返信は1年、 2ヶ月前にmokkosanが編集しました。
フォーラム: 使い方全般
返信が含まれるトピック: カスタマイズ読み込み中のまま今回の場合、ログインしないとアクセスできない場面についてのことなので、そこはスルーして問題ないです。
これが関係するのは、サイトの表示がおかしいとか、エラーが出てるとか、一般の閲覧者が見ることのできる場面での問題が発生したときのことです。
フォーラム: その他
返信が含まれるトピック: 問い合わせフォームの送信元、送信先の設定についてフォーラム: その他
返信が含まれるトピック: 問い合わせフォームの送信元、送信先の設定について追記です。
私がSPFレコードと言っているのは、エラーは出たままで解決しなくても送信できるけど、その状態だと、受け取り側のメールサーバで大抵Spamフラグ立てられるし、相手がgmailだったら受け取ってさえもらえないよね、という点の解消です。エラー表示は解消しないで運用するという方法です。
ですから、どうしてもエラー表示自体を消したいとなると、SPFは関係ないです。送信元をそのサイトのドメインのアドレスにする一択です。会社アドレスでの運用は諦めるか、もしくは、Yukinobu Asakawaさんのおっしゃるように、会社側のドメインのサイトにフォームを置くしかないですね。
フォーラム: その他
返信が含まれるトピック: 問い合わせフォームの送信元、送信先の設定についてまず、やりようはいくらでもあるので、どの方法が正しいとは言いません。正直、されようとしている設定は私だったら絶対しないなと思いますが、そういう運用をしなくてはならない事情もあるでしょうから、そこにはあえて踏み込みません。確かに多くの人にとってはおすすめの設定ではないだろうとは思います。
SPFレコードについて、誤解されている方がいますが、これは、「そのドメインが信頼できるドメインであることを認証」するものではありません。「発信したメールサーバが、そのドメインの公式なメールサーバであることをDNS上で告知するもの」です。なりすましを防ぐためのものです。IPアドレスで指定することが多いです。今回の場合のように、会社ドメインを運用しているサーバと違うサーバで発信された場合でも、そのサーバを正規のサーバとして扱うことができます。もちろん、同じサーバで発信する場合でも、SPFの設定は今の時代必要だと思った方がいいです。もしくはDKIM。細かい設定までは、ここのフォーラムの趣旨には合いませんから、それこそ、サーバの管理者と相談しないとダメなんじゃないですかね。そもそもメールサーバの運用方針だってそれぞれ違うし、外部サービスに丸投げのことだってあるだろうし、さらにDNSサーバの管理だってまた別かもしれないですし(^^;;
DNSサーバの設定は、「WordPressの設定間違えてメールがとどかない」というレベルを超えてもっと重い、それこそ全社的な問題をはらむことになるので、これ以上はそちらの管理者と相談してくださいとしか言えません。
あと、「[your-name] にはフォームでユーザーに問うたメールアドレスが代入されます。」と上で出ていますが、これは間違いです。正しくは、「[your-name] にはフォームでユーザーに問うた氏名が代入されます。」です。メールアドレスは[your-email]で代入されます。
今回の場合、発信者の名前に[your-name] を、メールアドレス自体にはサイト運営側の特定の会社アドレスを設定、ということなので、単純にこの会社アドレスをサイトのドメインに変えたら、その位置に[your-name] があってもエラー表示なく送信できると思います。
ちなみに、「サイトのドメインに属していないメールアドレスが送信元に設定されています」のエラーですが、このエラーは解決しなくても送信動作自体は行われたと思いますが、今のバージョンでは違ってます？
あともう一点。SPFがなんたらとかわからんからそんなのしたくないということであれば、WP Mail SMTPを入れて送信は全部会社のメールサーバに振るという方法もあります。その代わり、管理者宛のメール（例えば自動更新の通知とか）も全部そっち経由になりますが…
フォーラム: その他
返信が含まれるトピック: 問い合わせフォームの送信元、送信先の設定について言い換えてみます。
「送信元」…サーバから発信する時の「送信者」
「送信先」…サーバから発信して届けたい「宛先」
[your-name]…フォームを設置したサイト側から見て「入力してくれたお客さんの名前」
あなたの設定ですと、フォームから発信するメールの送信者の名前が毎回入力してくれたお客さん（お客さん相手のフォームなら）で、そのメールアドレスはいつもあなたの会社の特定のメールアドレスということですね。そして、サイトのドメインとあなたの会社のドメインは違うということですね。
実際に、サイトのドメインとは異なるアドレスで発信しようとしているので、「サイトのドメインとは異なるアドレスが入力されています」となるのは必然です。また、その設定で送信した場合、ほぼ間違いなくスパム扱いされるか、gmail相手だと着信すらさせてもらえません。今後、着信すらしなくなる相手は増えていくでしょう。それを回避するには、会社のドメインのDNSサーバで、サイトのドメインから発信したものは正しく会社のものだという宣言をさせることで回避できます。 SPFレコードの設定です。
ちなみに、フォームからの送信元を、特定の「会社ドメインのアドレス」ではなく、[your-email]とかにした場合、届かなくなる問題を回避するすべはありません。やってはダメです。
フォーラム: 使い方全般
返信が含まれるトピック: 管理画面にアクセスできないそれでは、そのドメインについて、こちらで検索してみてください。
.comなどの場合→ https://www.whois.com/whois/
.jpなどの場合→ https://whois.jprs.jp
検索結果から、 [Expires on]または[有効期限]が未来の日付になっているか？ [Status]または[状態]がactiveになっているか？ をまず確認してください。
どちらもOKの場合、ネームサーバ（DNSサーバ）の問題である可能性が高いです。検索結果の中に、[Name Server]の項目があります。そこには最低2つ以上のネームサーバが表示されているはずです。それらがちゃんと正しい答えを返していたらDNS_PROBE_FINISHED_NXDOMAINのエラーは起こり得ません。ですからその稼働状態を確認してください。
具体的には、いろいろな確認方法がありますが、こちらのサイトが簡単です。
→ https://www.cman.jp/network/support/nslookup.html
このサイトで、「ホスト名(FQDN)を指定してください」のところに、WordPressが稼働しているドメイン名（ホスティング業者のドメイン名じゃなくて、サイト自身のドメイン名です。）を入力。オプションはANYを選択します。「DNSサーバを指定する場合（任意）」のところに、上の検索結果の[Name Server]を入れてください。そして「dig実行」をします。ネームサーバは二つ以上あるはずなので、二つの場合は一つずつ2回、三つの場合は、一つずつ3回、それ以上の場合も一つずつあるだけDNSサーバを指定して調べることになります。これで、応答が遅かったり稼働していなかったりするネームサーバがあれば、それが犯人ですね。また、digを実行した結果の各答えが正しいかどうか、特に、ドメイン名の逆引きIPアドレスが正しいかどうかも確認が必要です。
- この返信は1年、 2ヶ月前にmokkosanが編集しました。
フォーラム: 使い方全般
返信が含まれるトピック: 管理画面にアクセスできない横からすみません。
DNS_PROBE_FINISHED_NXDOMAIN ということは、WordPressに辿り着く前にエラーになっているということなのですが、まれに、Google Chromeがおかしくなっててこのエラー吐くことがあるようです。
参考→https://support.google.com/chrome/thread/238509113/特定のドメインにアクセスできなくなる場合がある?hl=ja
一旦、FirefoxやSafariなどのChromeのエンジンを使ってないブラウザでアクセスして確かめてみてください。（EdgeやOperaはChromeと同じChromiumベースなのでひとまずやめといた方がいいかもです。）
それでもやっぱりダメな場合には、WordPress以前に、そのドメインが死んでいるか、そのドメインを担当しているネームサーバが死んでいる可能性が高いです。まずはドメインのレジストラに確認してみてください。
- この返信は1年、 2ヶ月前にmokkosanが編集しました。
フォーラム: 使い方全般
返信が含まれるトピック: データベースに接続出来ないもう一つ、ボタンをかけちがっているような感じを受けましたので、補足します。
「
Access denied for user ‘admin’@’localhost’ to database ‘pm’ のエラーが返ってきました。
XAMPPを利用しているため、ローカル環境です。
」
このようにお書きですが、user ‘admin’@’localhost’のlocalhostはローカル環境であるかどうかとは全く関係のないものなのです。すでに承知されていることでしたら、失礼の段お許しください。そうでないのなら、、この機会に理解されると幸せになれます。
同じサーバマシンに、WordPressというPHPで書かれたプログラム群とそのバックエンドとなるMySQLがインストールされている場合、WordPressがユーザadminでMySQLにアクセスすると、MySQL側から見ると、同じサーバのadminユーザさんからアクセスが来てると識別されるわけですが、その同じマシンだという意味がlocalhostということです。ですから、グローバルに置いた本番環境であっても、同じマシン内にMySQLを置くのであればlocalhostからのアクセスということになります。
フォーラム: 使い方全般
返信が含まれるトピック: データベースに接続出来ないボタンのかけ違いがあります。「ユーザ」というものについて、誤解されています。
データが格納されているMySQLのデータベース「pm」にアクセスする権限を持つユーザは、MySQLで定義されるユーザ（同じMySQLサーバにあるデータベース「mysql」に格納されています。）です。それに対して、pmデータベース内のwp_usersテーブルのユーザは、WordPress内部のユーザです。これらは同じ名前であっても別物です。
たとえば、〇〇県教育委員会に山田さんが勤めていて、県教委の人事データベースの閲覧権限があるとしましょう。〇〇県立〇〇高校に山田先生が勤めていたとして、同じ山田だから同じ人事データベースを見る権限があるかというと、そんなことはないですよね。MySQLユーザーのadminさんと、Wordpressユーザーのadminさんは、単なる同姓同名の別人です。
ちなみに、ではデータベースpmについてアクセスする権限を持っているMySQL上のユーザが誰かを調べるには、phpmyadminでデータベース名mysqlにあるdbテーブルを見てください。なお、dbテーブルでなさそうなら、グローバル権限でアクセスしていることになるので、その場合は同じデータベースmysqlのuserテーブルを見てください。
なお、老婆心ながら、ユーザー名がadminなんて、ハッキングしてください宣言してるようなものなので、練習時点から、そんなユーザー名を使う癖はつけない方がいいですよ。
フォーラム: 使い方全般
返信が含まれるトピック: WordPressのログイン画面ではじかれるこのトピックは、「WordPressのログイン画面ではじかれる」とのタイトルですが、この問題はもう解決したのですよね。それでしたらここは一旦解決済みにして、違う内容は新たにトピックを立てた方が、答えもつきやすいしみんなにとって幸せですよ。
- この返信は1年、 3ヶ月前にmokkosanが編集しました。
フォーラム: 使い方全般
返信が含まれるトピック: トップページが修正できないもう一度新たな固定ページを、テーブルではなく最初からブロックを使って作ったのちに、その作ったページをトップページに指定し直してみると、どうなりますか？
ところでサポートですが、Lightningの開発元のサイトで、パスポート購入してそちらのフォーラムでサポートを受けるという手もあります。
フォーラム: プラグイン
返信が含まれるトピック: Spectraプラグインについて老婆心ながら、困った状況が発生した場合、パニクるよりも一旦深呼吸して、落ち着いて対処なさると幸せになれます。
落ち着いて対処ということは、書いてあることをちゃんと読むということもその一つです。
たとえば、四つ前のfujiwarakanaeさんの投稿に、「2.0の最高バージョンの2.0.16をインストールしてみたら、なんと、編集画面が復活しました」とあって、その一つ前には、「固定ページの編集画面は何も変わりませんでした。」とおっしゃっていますが、そもそもその前の私のアドバイスは、「Spectraを最新バージョンにまずアップデートしてから、ドメイン/wp-admin/index.php?spectra_old_user=yesにアクセスしてね」と書いてます。なのにバージョンアップせずにアクセスしたでしょ？
また、アクセス後出てきたページでは、懇切丁寧に（英語ですが不得意ならDeepLなりに食わせたら一発でわかりますよね。）一部のページが古いバージョンのSpectraで作成されているから、デザインに影響しないようにするにはデータベース更新が必須でっせ。こちらデータベース更新リンクをクリックしてや。って書いてあります。書いてある通りにポチったら、あとはよしなにしてくれます。
きっとこれから先も、壁にぶつかられることがあるでしょう。そんな時は落ち着いて対処して、幸せになりましょう。
なお、古いバージョンを使い続けることは、セキュリティ的に大問題になることがあるので、基本的にはやめたほうがいいです。