Beiträge von b3317133

@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:

Link zu so einer geschützten Seite?

Hast Du Dich zum Testen von WordPress abgemeldet?

Dann erzeuge den Fehler neu und poste dann die neusten Einträge aus dem Server Error-Log oder einfach mal generell die letzten Einträge.

Weiterhin deaktiviere diesen Query Monitor und alle sonstigen Monitoring- und Optimierungs- und Cache-Plugins, um Einflüsse auszuschliessen.

Schau beim Erzeugen des Fehlers mal in die Konsole des Browsers und in das Netzwerk-Tab in das Antwort-Feld beim entspr. Ajax-Aufruf wenn da was fehlschlägt oder lange dauert, was steht dort?

Weiterhin deaktiviere temporär alle sonstigen Plugins, eines nach dem anderen, und schau, ob das die Fehler beeinflusst.

Und beschreibe kurz, was genau Du seit "vor einiger Zeit" gemacht hast, bevor das Problem auftrat. PHP-Version verändert, Updates von WP, Plugins, Theme?

Welche WordPress-Version, PHP-Version, Theme & Version, Plugins & Versionen wird verwendet? Ist alles auf dem neusten Stand?

Was sagt der Support von Storefront Pro Premium zu der Fehlermeldung? Den Support hat man in der Regel mitgekauft.

Die vergleichsweise lange Dauer von 120 Sekunden dürften übrigens einfach dadurch entstehen, dass auf dem Server direkt ein Fehler passiert und das lokale Script dann bis in den Timeout auf eine sinnvolle Antwort wartet, die es nie bekommt.

PS. Wenn Du nicht mit der Installation arbeiten kannst, wende Dich am besten an die Person, die den Website eingerichtet hat, die weiss am besten, was wie verwendet wird und wie eingerichtet wurde.

Der 404-Fehler in der ersten Meldung ist lt. Autor der API normal und bedeutet, dass es keine Updates gibt.

Der PHP-Fehler deutet auf ein Problem mit dem Storefront Plugin hin. Mehr dazu findest Du ggf. im Server Error Log, wie man das bei Strato findet siehe z.B. hier.

Die Installation ist derzeit für das Unterverzeichnis /wordpress eingerichtet, Vorgehen:

1. Einstellungen > Allgemein > dort in den beiden Feldern den Teil [FONT=Courier New]/wordpress[/FONT] entfernen, so dass nur noch die Domain ohne / am Ende dortsteht > Speichern > dann wirst Du vermutlich autom. abgemeldet.
2. Strato Umleitung auf das Verzeichnis legen
3. Anmelden mit [FONT=Courier New]example.com/wp-admin/[/FONT] also ohne das Unterverzeichnis
4. Plugin "Better Search Replace" installieren und damit ersetzen [FONT=Courier New]example.com/wordpress[/FONT] durch [FONT=Courier New]example.com[/FONT] (jeweils ohne / am Ende).

Die hier verwendete Beispieldomain example.com durch Deine Domain ersetzen...

Das zweite Problem ist also auch gelöst, der Login der Installation, zu der der o.g. cuttly Link führt, funktioniert wie er soll, wenn man ihn korrekt benutzt.

Das dritte - wiederum neue - Problem ist jetzt also eine weitere Installation mit der Subdomain "devgroh" offenbar installiert in einem Unterordner der Hauptinstallation.

Die "Redirects" dort liegen daran, dass in dieser dritten Installation die Permalinks auf "Einfach" gestellt sind und die .htaccess im übergeordneten Ordner dazu nicht passt aber vom Server berücksichtigt wird (bei .htaccess geht der Server sozusagen durch die ganze Ordnerstruktur und beachtet alles).

Man könnte als Lösungsansatz die .htaccess im übergeordneten Ordner kurz umbenennen, sich dann in die "devgroh" einloggen, und die Permalinks auf "Beitragsname" o.ä. umstellen.

Das Originalthema des Threads war eine inzw. gelöste Fehlermeldung, mit dem jetzt dazugekommenen Wirrwar aus Installationen und Unterordnern hat das nichts mehr zu tun. Erstelle am besten eigene Themen für neue Probleme.

Ganz am Rande: Vielleicht wäre auch ein Posting in der Jobbörse mit exakter Beschreibung, was eigentlich das Ziel der ganzen Änderungen ist, ein denkbarer Ansatz, mit geforderter Erklärung, was genau das Problem war, um daraus zu lernen, statt von einem Problem irgendwie ins nächste zu schlittern.

Kennst Du schon die Dokumentation auf der Hersteller Seite des Plugins?