Hintergrund: Ich habe mehrere Websites, die auf RPI4 mit Nginx und WordPress laufen. Ich möchte eine der Sites zur Entwicklung und zum Testen in mein lokales Netzwerk kopieren. Ich habe die Datenbank- und WordPress-Dateien kopiert und eine Konfigurationsdatei eingerichtet, um Port 8082 abzuhören und die Datenbank zu sichern. Die ursprüngliche Website ist sicher und verwendet ein https-Verbindungszertifikat, die lokale Kopie jedoch offenbar nicht.
Wenn ich über das Netzwerk 192.168.0.213:8082 auf die Website zugreife, wird die Startseite angezeigt, aber ich kann nicht auf die Anmeldeseite zugreifen, da jeder Link, den ich versuche, auf meine Live-Website umgeleitet wird. Also habe ich die Site-URL und die Homepage-URL über MySQL-Anweisungen aktualisiert und konnte auf die Anmeldeseite zugreifen. Alle anderen Links außer der Homepage funktionierten jetzt. Jetzt leitet mich die Homepage weiter zu:
192.168.0.213:8082/192.168.0.213:8082/
Dies ist eine Seite, die nicht existiert. Ich habe das Gefühl, wenn ich das herausfinden kann, bin ich dem, was ich will, sehr nahe. Da es Nginx ist, gibt es keine .htaccess-Datei, aber ich kann gerne alles ändern, was ich brauche, und Root-Zugriff haben, um alles zu tun. Ich kenne mich mit SQL, Befehlszeile usw. aus, habe das aber noch nie gemacht und stecke fest. Ich bin mir nicht sicher, was ich in der PHP-Datei ändern oder anpassen soll, damit sie sich nicht selbst hinzufügt.
Ich habe den hier gefundenen Fix ausprobiert und im Grunde das „http://“ hinzugefügt, das ich gemacht habe. Ich bin immer noch ein Neuling in diesem Bereich und frage mich, ob ich meinen Localhost nicht richtig verweise.
Ja, dies ist eine Blogseite namens „chadsmancave“ und alle Inhalte werden von chadsmancavebkp kopiert. Ich kann bestätigen, dass ich beide Versionen hoste, da Änderungen an der Datenbank nur in der lokalen Version widergespiegelt werden, nicht in der von mir veröffentlichten Version.
Hier sind einige Screenshots, ich hoffe, sie helfen:
我正在回答这个问题，但要接受 Chris Haas 的回答，因为他所说的解决了问题。
确实，我使用的是 Chrome，它保留了该重定向！不是 f5，否则任何东西都会通过它，直到我彻底清除整个浏览器数据。
一旦他说到浏览器和 Chrome，我就到我家的另一台机器上输入地址，结果为零。就在那时我知道我一直在用的浏览器做这一切都是原因！
谢谢你。谁知道我会在这上面浪费多少时间，甚至放弃。再加上开发人员在这方面浪费的 5-6 个小时的时间。 XD
我几乎每天都会移动网站。
首先，获取并安装已安装的官方 WP CLI。
接下来，从您要移动的站点，将
cd移至 WordPress 根目录并使用以下命令导出数据库：这将在该目录中创建一个 SQL 转储文件。将该文件移动到 WordPress 根目录中的新位置
cd并使用以下命令导入它（显然适当地替换了文件）：最后，仍然在新位置时运行搜索替换命令：
第一个 URL 是旧的，第二个 URL 是新的。确保准确，包括协议（HTTP 与 HTTP）、域（www.example.com 与 example.com）。 com）和端口。也不要在没有协议的情况下运行它，它可能会也可能不会达到您的预期。同样，不要使用尾部斜杠运行它（例如
https://example.com/），因为这会产生其他影响。下一个参数 (
--recurse-objects) 指示 CLI 反序列化对象并遍历它们，这是安全更新元和选项表所需的。下一个参数（
--all-tables）仅表示遍历包括插件的整个数据库。最后一个参数（
--dry-run）意味着不会进行任何更新。始终在打开它的情况下运行，直到确定没有任何拼写错误，然后在没有它的情况下运行命令。注意
此外，在执行、导入或更新之前始终先进行数据库备份，以防万一：
附加说明
search-replace 命令还有一个名为
--export的选项，您可以使用该选项并跳过初始转储。然而，我个人并不这样做，因为如果我从实时备份到开发服务器，我不想在实时服务器上产生任何额外的 CPU/IO，我希望这种负担稍后发生在开发服务器上在。我也可以有条件地使用它，但我只是喜欢有一个我在任何地方都使用的命令设置。还有一点
浏览器，特别是 Chrome，往往会记住重定向，至少暂时是这样。因此，在测试该举措是否确实有效时，我强烈建议始终在私密浏览窗口中进行测试。我无法告诉你我和其他开发人员因此损失了多少时间。一旦确定已更新，您就可以返回到普通浏览器。