Beiträge von b3317133

Link zur Datei? Screenshot der Datei in der Mediathek?

Werden irgendwelche "Access Manager" oder "Download Manager" o.ä. Plugins verwendet?

Zitat von Master-Sezer

... kannst du ja die Seite besuchen ..

Link?

Zitat von MaBik

die Frage, ob das Problem des LogIn's eher es "etwas kleineres" und korrigierbares ist,

Kann man "von aussen" und ohne Einblick in .htaccess usw. nicht beurteilen.

Zitat von MaBik

Was sollte man beachten, wenn man am Live-System ein Restore fährt?

Man sollte mit ggf. unerwarteten Situationen umgehen können.

Zitat von MaBik

sollte man beim Hoster das Verzeichnis zuvor komplett per Hand löschen?

Würde in dem Fall die bestehenden Dateien erstmal (ausser per FTP alles in einen neuen Unterordner verschieben) nicht anfassen bzw. löschen, evtl. braucht man daraus noch was.. Gleiches gilt für die Datenbank, beim Duplicator Backup Einspielen eine neue nutzen (und die alte erstmal unverändert behalten).

Würde (da offenbar keine Erfahrung mit Duplicator Pro Restore vorhanden ist) als erstes mal das hier machen:

Zitat von b3317133

Kontaktiere doch mal den Hostinganbieter und frage nach, ob es ggf. dort Backups der Dateien/Datenbank gibt, die man einspielen könnte.

Ergänzend: Kannst Du Dich hierüber anmelden? Das scheint keinen Redirect zu verursachen.

https://owango.ch/wp-login.php

Generell sollte man alle Cache- und Optimierungs-Plugins deaktivieren, bis so ein Problem behoben ist. Das geht z.B. auch durch Umbenennen des entspr. Plugin-Ordners per FTP.

Evtl. "funktioniert" das Frontend der .ch Seite derzeit nur (noch), weil es alte Cache-Daten gibt? Kann man schwer beurteilen.

Die .at Seite ist mit einem Plugin auf Wartungsmodus gesetzt.

Die .de Seite zeigt auf ein leeres Hosting und hat zudem per https ein ungültiges Zertifikat.

Scheint also einiges schiefgegangen zu sein.

Was genau bedeutet ".htaccess auch schon geprüft", was steht denn drin? Mehr zur WordPress .htaccess hier.

Kontaktiere doch mal den Hostinganbieter und frage nach, ob es ggf. dort Backups der Dateien/Datenbank gibt, die man einspielen könnte.

Poste doch mal einen Screenshot, wie genau das aussieht. Evtl. scheitert es bisher an der Begriffsdefinition.

Das "Dashboard" ist z.B. nur eine Seite des ganzen Admin-Bereichs. Werden die Kommentare direkt auf dem Dashboard angezeigt? Oder auch noch anderswo?

Die entspr. "Capabilities" für WordPress Rollen wären [FONT=Courier New]moderate_comments[/FONT] oder auch [FONT=Courier New]edit_comment[/FONT].

Könnte an Einstellungen der diversen von Dir genutzten Plugins liegen, offenbar wird nach einer kurzen Testregistrierung mindestens "LoginPress" und "WPForo" verwendet.

Zum zweiten Plugin gäbe es bei einer Google-Suche nach WPForo Adminbar direkt einige Links zu dem Problem in das entspr. Support-Forum.

Tipp Am Rande: Der Logout/Ausgang Link enthält nach wie vor eine statische veraltete Nonce, siehe dazu auch anderer Thread...

@SirEctor Metaboxen bzw. Custom Fields jeweils pro Block klingt relativ komplex.

@doni32 Im WordPress-/Gutenberg Konzept gibt es eine solche Funktion nicht als Standard, evtl. mal bei den Gutenberg-Entwicklern vorschlagen.

Es gibt wohl ein paar Plugins für "Block Visibility" o.ä., aber nach Blick in jeweiligen Plugin-Quellcode verstecken sich da diverse mögliche Probleme z.B. ungeeignet für Cache-Plugins usw.

Soll das Kontaktformular im Inhaltsbereich der Seite erscheinen oder da wo bisher der Sidebar war?

Einfach nur generell den Sidebaraufruf auszukommentieren, kann problematische Folgen haben, v.a. was die "responsive" Darstellung angeht usw., da ggf. für die Gesamtdarstellung dann HTML-Elemente bzw. CSS-Klassen fehlen, die den Sidebar definiert bzw. angeordnet haben.

Viele Themes haben auch ein "Full Width" Template o.ä. für Seiten, daran kann man sich ggf. orientieren.

Welche SSL Umleitung funktioniert wie genau nicht?

Der o.g. Codeblock kann übrigens nicht funktionieren, es fehlen die // Zeichen in https:// in der RewriteRule Zeile.

Wenn man in einer WordPress Installation einmal Einstellungen > Permalinks mit einer anderen Einstellung als "Einfach" speichert, wird der nötige .htaccess Eintrag automatisch erstellt. Manuell etwas aus einer anderen Installation zu kopieren, kann schiefgehen. Mehr zu .htaccess hier.

Wenn man eigene Codeblöcke in die .htaccess einfügt, sollte man davor und danach jeweils einen einfachen Identifier setzen, dann findet sich WordPress und ggf. auch andere Software besser zurecht, Beispiel:

# BEGIN RedirectSSL
..codeblock..
# END RedirectSSL

Die sitemap.xml Datei ist mit http statt mit https in Deiner manuell erstellten Datei robots.txt verlinkt, behebe das.

Wo ist ansonsten eine Fehlermeldung? Mit WordPress haben die genannten Probleme alle nichts zu tun, evtl. wäre es besser, sich an ein Google Search Console oder explizites SEO Forum zu wenden.

Deaktiviere alle Cache- und Minify- und Analyse- und Optimierungs-Plugins, um ggf. hierdurch verursachte Fehler auszuschliessen.

Ansonsten gilt das gleiche wie hier beschrieben.

Das debug.log weist nebenbei auf fehlerhafte/doppelte Konfigurationseinstellungen in wp-config.php hin, wende Dich an die Person die den Website eingerichtet bzw. die Modifikationen von wp-config.php vorgenommen hat und lasse das beheben.

Deaktiviere der Reihe nach einzeln alle Plugins, bis Du den Fehler genauer zuordnen kannst. Schau auch in das PHP Error Log auf dem Server.

Aus Deinen Meldungen hier geht nicht hervor, wann/wo genau welcher Fehler auftritt.

Falls die Fehler beim Bearbeiten einer Seite auftreten, versuche es alternativ auch mal mit dem Plugin Classic Editor.

Der Screenshot zeigt das Anlegen einer "Seite" mit dem neuen Gutenberg Editor.

Einen Blogbeitrag würde man im Menü "Beiträge" anlegen.

Falls Du ggf. einen anderen Seiteneditor gewohnt bist, versuche es mit dem Plugin Classic Editor.

Die alten Domains müssen "da bleiben", sprich erhalten bleiben. WordPress selbst braucht man dort dann nicht. Die 301 erzeugt man z.B. entweder mit einem generellen Redirect über das Hosting oder mit einer .htaccess Datei, die eine Liste von alten Links auf die neue Domain und ggf. Unterseite weiterleitet.

Prüfe die Dateien über die "Live-URL" Funktion. In Deiner Liste steht zumeist zuletzt gecrawlt vor über 2 Wochen (20.11.2019 u.ä.). Und einen Link herrenhaarschnitt gibt es auf der Seite gar nicht (mehr?).

Welche Datei in welcher Reihenfolge von WordPress gesucht/genutzt wird, kann man in der Template Hierarchy sehen.

Tipp am Rande: Ein WordPress-Theme ganz ohne get_header() zu nutzen, führt mit sehr hoher Wahrscheinlichkeit zu grossen Folgeproblemen, da die entspr. "Action" dann nicht aufgerufen wird. Man kann bei Bedarf über einen Parameter auch eigene header-Dateien aus einem (Child-)Theme nutzen.

Ist bei CF7 reCAPTCHA (v3) konfiguriert? Es werden bei CF7 keine sonstigen captcha Plugins benötigt. Zu viele captcha Köche verderben den Brei...

Verwendest Du wirklich das Classic Editor Plugin und alleine den Classic Editor oder nur einen "Classic Block" im Gutenberg Editor?

Wenn Du Dich nicht an ein Update "traust" (was bei wenig Erfahrung und/oder ohne Backup-/Restore Konzept erstmal verständlich ist) und auch keinen Kontakt zum Theme Verkäufer bzw. Support aufnehmen willst, wäre ein Posting in der Jobbörse hier im Forum eine Möglichkeit, ggf. passende Angebote zu bekommen.

Beschreibe dort im Detail Dein Problem und den aktuellen Stand, dann bekommst Du evtl. passendere Angebote als ohne Angaben.

Es wurde im Thread mehrfach darauf hingewiesen, mit einzeln abgeschalteten Plugins zu testen, das ist offenbar leider nicht passiert, sonst wäre das Problem bereits seit einer Woche gelöst. :oops: