Beiträge von b3317133

    7. Wenn Du mit Deine letzten Beiträge dann im Menü auf Home klickst kommt die Startseite mit dem Pfad wie eine normale verlinkte Seite.

    Code
    http://wiesbachschule.de/home/


    Stelle testweise in Einstellungen > Lesen > Eine statische Seite > eine andere Seite als Home ein.

    8. Stelle "Einfach" ein und speichere und dann wieder "Beitragsname" und speichere, das refresht dann auch die internen sog. Rewrite Rules.

    Entferne in .htaccess alles vor/oberhalb dieser Zeile, das sind Reste des inaktiven Cache Plugins.

    Code
    # BEGIN WordPress


    Direkt ursächlich für den "Redirect der Startseite auf sich selbst" Effekt sollten diese Zeilen allerdings nicht sein. Wurde das W3 Total Cache Plugin komplett deaktiviert über die Plugins Liste?

    3. Deaktiviere temporär alle Plugins, ändert das etwas?

    4. Was steht in der Datei .htaccess? Einsehbar per FTP oder auch so über das Yoast SEO Plugin.

    5. Die Unterseiten funktionieren derzeit, was ist bei Einstellungen > Lesen eingestellt? Ggf. Screenshot? Existiert die dort eingestellte Startseite? Ist diese Seite "publiziert" oder ggf. Entwurf?

    Ergänzung:
    Die Startseite funktioniert wenn sie per Seiten-ID oder über die REST API aufgerufen wird, also ist sie eigentlich korrekt vorhanden.

    Code
    http://wiesbachschule.de/?page_id=276
    http://wiesbachschule.de/wp-json/wp/v2/pages/276


    Bleibt im Grunde nur ein Problem in .htaccess o.ä. das die Hauptseite betrifft.

    6. Versuche auch Einstellungen > Permalinks > Button unten ohne Änderungen speichern (2x), das erzeugt die .htaccess neu, falls dort noch Cache Reste sind.

    Weder im Beitrag #4 noch in der dort verlinkten Anleitung wird eine dauerhafte Nutzung der älteren Version empfohlen.

    Die Überschrift dort "Tutorial for moving away from PHP Everywhere 3.0" bedeutet, dass es sich um eine Anleitung handelt, wie man zu einem anderen Plugin wechselt.

    Dafür benötigt man temporär die ältere Version 2.0.3, um wieder an die bereits eingegebenen Daten zu kommen.

    Zitat

    So, the first step is to restore it, in order to be able to easily copy the PHP code you already have.


    Die weiteren Schritte sind die Installation eines anderen Plugins und das Übertragen der Daten dorthin.

    Dass am Ende einer solchen Migration das vorher genutzte Plugin nicht mehr weitergenutzt wird, sollte eigentlich selbsterklärend sein.

    Das ganze nennt man (wie in Beitrag #4 als solches bezeichnet und in Beitrag #6 nochmals erklärt) in der IT-Welt "Offboarding".

    Die Linux Virtual Machine Datei ist im Ordner vm, ein Entpacken der Virtual Machine ist nicht vorgesehen. Der Zugriff auf die Dateien darin erfolgt wie bereits beschrieben.

    Wie von @Kurt Singer bereits angemerkt, ist InstantWP relativ alt (letztes Update 15. Februar 2018) und funktioniert daher ggf. nicht mit aktuellen Windows Versionen.

    Es gibt nur einen der o.g. Einträge.

    Du siehst noch drei Einträge mit [FONT=Courier New]<script type='text/javascript'>[/FONT] (mit einfachen Hochkommata) die durch das Theme ausgelöst werden und noch einen vom WordPress Core.

    Dein Theme meldet an WordPress derzeit nur html5 Support für das Suchfeld, nicht für scripts allgemein.

    Code
    neve/inc/core/front_end.php:48
    add_theme_support( 'html5', array( 'search-form' ) );


    Dort müsste z.B. sowas stehen, dann würde WordPress das [FONT=Courier New]type[/FONT] Attribut im Script Tag weglassen:

    Code
    add_theme_support( 'html5', array( 'search-form', 'script' ) );


    Wende Dich an den Theme Hersteller, evtl. kann der Dir erklären, warum das Theme bei html5 die Scripts explizit nicht mit deklariert.

    Alternativ ist evtl. TYPO3 für Dein Vorhaben besser geeignet.

    Das einzige derzeit sichtbare [FONT=Courier New]<script type="text/javascript">[/FONT] auf der angegebenen Seite kommt aus dem WordPress Core selbst:

    Code
    <script type="text/javascript">
    window._wpemojiSettings = {"baseUrl":"https:\/\/s.w.org\/images\/core\/...


    Dieses Script ist bzgl. DSGVO ein Problem, da es je nach Browser ohne Zustimmung Daten von externen Servern einbindet. Viele nutzen ein Plugin wie Disable Emojis, um dieses für wohl 99,9% der Besucher unnötige Script aus den Seiten zu werfen.

    Ist das bei Euch und "Aktuelle Version: 5.9" nicht der Fall?


    Das ist in jeder WordPress 5.9 Installation der Fall.

    Wieder mal zeigt sich, dass man bei Updates in einen neuen Zweig erstmal 1-2 Wochen abwarten und die aktuellen WordPress Tickets beobachten und/oder solche Updates zunächst auf einer Staging Installation komplett durchprüfen sollte, bevor man das Update im live Server einspielt.

    Wenn

    • ab und an mal WordPress Datenbank nicht gefunden erscheint
    • ab und an mal install.php erscheint
    • mal custom css verschwindet
    • und ein paar Stunden später wieder kommt
    • das Problem bei allen dort gehosteten Websites auftrat


    deutet das darauf hin, dass Dein WordPress von der Datenbank unterschiedlichen Stände des Inhalts zu sehen bekommt und zwar

    • gar keine DB
    • leere DB
    • Stand Zeitpunkt X
    • Stand Zeitpunkt Y
    • Stand Zeitpunkt Z
    • ...


    Das deutet darauf hin, das entweder Dein Hosting akut am Datenbankserver gearbeitet hat und dort irgendwas neu aufsetzt und/oder falsche Stände/Backups einspielt oder dass es mehrere (eigentlich) gespiegelte Datenbanken gibt, die durch DNS oder anderweitig kaputtes Loadbalancing und/oder eine fehlerhafte Spiegelung diese unterschiedlichen Stände ergeben.

    Es ist/war anhand der Beschreibung ein Problem beim Hosting. Auf einen Hack deutet die Beschreibung nicht hin.

    Wenn das Problem ab "gestern Nachmittag nicht mehr vorgekommen ist", scheint das Hosting das Problem gefunden und behoben zu haben.