Beiträge von b3317133

Evtl. hilft Dir dieser Ansatz mit einer Zeile CSS und einer Zeile Javascript, dort auch als Plugin verpackt verfügbar.

Wenn das Problem nur mit dem neuen Gutenberg Editor auftritt, wende Dich am besten wie hier beschrieben an die hauptberuflichen Entwickler, die lesen hier im Forum nicht mit.

Schritt 1: Alten Zustand wiederherstellen.

Es gibt diverse Wege, das zu reparieren bzw. rückgängig zu machen.

Wir machen das normalerweise direkt in der Datenbank im [FONT=Courier New]siteurl[/FONT] und [FONT=Courier New]home[/FONT] Feld, wenn die über das Hosting z.B. über phpMyAdmin zugänglich ist.

Schritt 2: Gesamten Website auf neue Domain umstellen.

Um WordPress gesamt auf .com umzustellen, suche mal nach "WordPress Umzug" oder dem Pluginnamen "Better Search Replace" hier im Forum, das wird oft gefragt und beantwortet. Wichtig in Deinem Fall ist, dass die .com Domain vor der Umstellung auch auf das WordPress Verzeichnis zeigt.

1. Erstelle eine Seite "Blog" ohne weiteren Inhalt.
2. Bei Einstellungen > Lesen > Deine Startseite zeigt sollte bereits Eine statische Seite angewählt sein, mit Deiner aktuellen Startseite bei Homepage:
3. Stelle zusätzlich dazu die o.g. Seite "Blog" bei Beitragsseite: ein.
4. Setze einen Haken bei bei Einstellungen > Diskussion > Standardeinstellungen für Beiträge > Besuchern erlauben, neue Beiträge zu kommentieren
5. Erstelle in WordPress ein paar Beiträge
6. Rufe die o.g. Seite "Blog" im Frontend auf

Wenn das dann alles funktioniert, kann man sich um die Beschränkung der Länge der Beiträge usw. auf der Übersichtsseite "Blog" kümmern. Hierfür eignet sich wahrscheinlich dieses Plugin Advanced Excerpt (von mir ungetestet) ganz gut. Die Länge in der Regel nach Wortanzahl, da die Zeilenanzahl je nach Browserbreite völlig unterschiedlich ist.

Für das Ergänzen simpler Anforderungen gibt es die Filter überall in WordPress.

Evtl. kannst Du den Code ab hier als Basis verwenden, mit direkt Deiner Taxonomie als [FONT=Courier New]$taxonomies[/FONT] und Wegfall der Zeilen 57-69 ...

Man könnte über den [FONT=Courier New]wp_link_query[/FONT] Filter und [FONT=Courier New]get_terms()[/FONT] i.v.m. [FONT=Courier New]name__like[/FONT] entspr. gewünschte Ergebnisse hinzufügen.

Ist der Custom Post Type recipe "public"?

Falls ja, sollten die veröffentlichten Beiträge des Custom Post Types in der Linkliste erscheinen.

Funktioniert das was Du vorhast im Classic Editor mit dem Classic Editor Plugin?

Falls nein, kannst Du die Ergebnisse über den wp_link_query_args oder wp_link_query Filter um Deine gewünschten Ergebnisse erweitern.

Wir hatten auch schon den Fall, dass u.a. [FONT=Courier New]wp-includes/load.php[/FONT] durch einen Trojaner infiziert war, der Zugriff auf diese Datei dann (durch autom. Scanner) vom Hosting Provider generell über die Dateirechte gesperrt wurde, und der entspr. Eigentümer des Websites das bei eigenen Reparaturversuchen beim "Überschreiben" nicht bemerkt hat.

Daher immer die Verzeichnisse und Core-Dateien erst löschen oder verschieben, dann sieht man u.a. auch solche Effekte und man erwischt nebenbei auch gern "versteckte" sonstige Dateien, die gar nicht zum WordPress Core gehören...

Ok, aber wie gesagt, der o.g. Link existiert für WordPress nicht wirklich, die entspr. WordPress Seite ist als statische Startseite eingestellt, daher wird dorthin weitergeleitet.

Der Link leitet hier direkt auf die Startseite weiter.

Evtl. ist bei der Kollegin wodurch auch immer generell der Zugriff auf die Seite gesperrt? Nicht durch WordPress, sondern durch ihren Internetzugang...

Vermutliche Ursachen könnten sein: Eines der letzten Updates wurde unvollständig installiert und Du hast jetzt eine Mischung aus zwei WordPress Versionen. Oder es liegt ggf. ein Hack vor, der nicht sauber arbeitet.

Beim "Überschreiben" mit einer frischen Version, die Ordner [FONT=Courier New]wp-admin[/FONT] und [FONT=Courier New]wp-includes[/FONT] vorher komplett löschen und die [FONT=Courier New]wp-xxx.php[/FONT] Dateien im Hauptverzeichnis nicht vergessen, und alle [FONT=Courier New]index.php[/FONT] auch in [FONT=Courier New]wp-content[/FONT], da verstecken sich so einige Trojaner, und einen Blick in [FONT=Courier New]wp-config.php[/FONT] ob sich da irgendwelche extra Code-Zeilen befinden, gerne auch mal mit ein paar 100 Leerzeichen eingerückt, so dass sie "ausserhalb des Editor Fensters" bleiben.

Wie genau sieht diese Meldung aus? Wann / wo erscheint sie genau?

Falls sie immer bei allen Zugriffen auf die Seite erscheint, ist es evtl. auch eine Meldung Deines Hosting Providers. Manche Provider blenden sowas anstelle des Websites ein, wenn z.B. Rechnungen unbezahlt sind oder Symptome eines Hacks entdeckt wurden o.ä.

Frage doch mal nach den genauen Gründen, und lass Dir Deine Recherche-Zeit vergüten...

Das ist ein relativ altes WordPress.

Seit wann tritt der Fehler auf? Was genau wurde vorher gemacht? Wann konntest Du Dich das letzte Mal korrekt anmelden?

Funktioniert die normale Webseite oder erscheint dort auch eine leere Seite?

Ändert sich was, wenn Du die PHP-Version bei Strato auf so alt wie möglich stellst?

Was steht im Server Error Log in zeitlichem Zusammenhang zum Aufruf Deiner leeren Seite?

Die Error-Logs bei Strato stehen üblicherweise unter "Datenbanken & Webspace -> Statistik -> Logfiles (oben) -> Error-Logfile anzeigen (Button)". Exemplarisch hier ein Screenshot wie man da hinkommt.

Yoast SEO Premium wird mMn. nicht über Themeforest vertrieben, wende Dich am besten an deren Support, den hast Du normalerweise mitgekauft.

Auf der o.g. Unterseite befinden sich diverse Verweise zu http:// inkl. in den Yoast SEO Metadaten dort, das sollte man sich mal ansehen.

Die [FONT=Courier New].htaccess[/FONT] ist ok.

Zitat von meikel175

Wie bereits erwähnt oben - alle Plugins alles aktuell.

Hm, das ist seltsam, z.B. Yoast SEO Premium ist aktuell bei Version 11.3, bei Dir lt. Liste / Quellcode Version 11.0

Zitat von meikel175

Ja genau das gleiche Problem auch mit deaktivierten Plugins.

Wie verhält es sich mit deaktivierten Plugins und einem WordPress Standard Theme wie Twenty Nineteen oder Twenty Seventeen mit PHP 7.2.x und ohne PHP Boost? Wenn die Seite damit auch so langsam ist, sollte man wohl mal WordPress selbst unter die Lupe nehmen (ggf. ein Hack oder eine unvollständige Installation o.ä.) oder die ganze Installation mal per Duplicator o.ä. in ein anderes Paket auf eine Subdomain installieren und dort testen, so könnte man Strato-Problemen mit dem aktuellen Server/Paket auf die Spur kommen.

Ergänzend, eine zufällige https:// Unterseite z.B. [FONT=Courier New]/vostochno-evropeiskaya-ovcharka/rassestandard/[/FONT] enthält auch Verweise auf http:// - evtl. ist eine SSL-Umstellung nocht korrekt vorgenommen worden und das bremst die Sache aus? Erscheinen Verweise zu http:// in der Browser Konsole im Netzwerk Tab beim Laden des Backends? Und was steht in der [FONT=Courier New].htaccess [/FONT]Datei?

Sind alle Plugins auf dem aktuellen Stand?

Bei PowerWeb Basic dürften die genannten Änderungen via [FONT=Courier New]wp-config.php[/FONT] keine realen Auswirkungen haben.

Und noch eine Rückfrage: Mit allen Plugins deaktiviert ist die Seite also genauso langsam?

Dann wende Dich am besten an Deinen Hostingprovider oder nutze die o.g. Möglichkeit der Jobbörse, mit den aktuell bekannten Eckdaten kann man von "aussen" leider nicht sinnvoll weiterhelfen (ausser munter zu raten, was gern jemand anders machen darf, bin raus).

Das steht bereits weiter oben in diesem Thread, bitte alles genau lesen.

Ist bei Strato PHP Boost aktiv? Falls ja, was passiert, wenn Du das deaktivierst?

Deaktiviere alle unnötigen Plugins wie Smush Pro, WP Statistics, Duplicate Post, Easy Theme and Plugin Upgrades, ändert sich dann etwas?

Und wie änderst Du Memory Limit und PHP Time Limit? Hast Du bei Strato einen V-Server o.ä.? Welches Hosting-Paket genau?