Code ist Poesie

Syntax Error – wenn das Redirection-Plugin mit dem Hoster kollidiert

Manchmal liegt die Fehlerquelle doch nicht bei einem selbst…

Ein kurzer Bericht aus dem Maschinenraum: Auf einer von mir betreuten Website läuft verlässlich das populäre Plugin Redirection von John Godley für alle möglichen Weiterleitungen. Von Zeit zu Zeit erfordert dieses Plugin ein Update seiner Datenbank – was grundsätzlich bei anderen Websites mit einem Klick gelöst war.

Nicht so bei dieser Website – das Datenbank-Uptdate scheiterte mit einem Verweis auf einen Syntax Error. Zunächst vermutete ich einen Konflikt mit Plugins oder dem Theme, doch auch bei vollständig deaktivierten Plugins und mit aktiven Standardtheme tauchte der Fehler auf.

Also warf ich mal einen genaueren Blick in das Error-Log:

Plugin: 4.9.2
WordPress: 5.5.3 (single)
PHP: 7.4.13
Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0
JavaScript: https://meine-website.de/wp-content/plugins/redirection/redirection.js?ver=4.9.2-b1c9e2f6a1c3f8b6cc251a44757c6863
REST API: https://meine-website.de/wp-json/
Query: ?page=redirection.php

Action: https://meine-website.de/wp-json/redirection/v1/plugin/database/ POST
Code: 403 Forbidden

Error: JSON.parse: unexpected character at line 1 column 1 of the JSON data (SyntaxError)
Raw: <!DOCTYPE html>
<html>
    <head>
        <meta charset="utf-8">
        <style type="text/css">
            html, body, #partner, iframe {
                height:100%;
                width:100%;
                margin:0;
                padding:0;
                border:0;
                outline:0;
                font-size:100%;
                vertical-align:baseline;
                background:transparent;
            }
            body {
                overflow:hidden;
            }
        </style>
        <meta content="NOW" name="expires">
        <meta content="index, follow, all" name="GOOGLEBOT">
        <meta content="index, follow, all" name="robots">
        <!-- Following Meta-Tag fixes scaling-issues on mobile devices -->
        <meta content="width=device-width; initial-scale=1.0; maximum-scale=1.0; user-scalable=0;" name="viewport">
    </head>
    <body>
        <div id="partner"></div>
        <script type="text/javascript">
            document.write(
                    '<script type="text/javascript" language="JavaScript"'
                            + 'src="//sedoparking.com/frmpark/'
                            + window.location.host + '/'
                            + 'IONOSParkingDE'
                            + '/park.js">'
                    + '<\/script>'
            );
        </script>
    </body>
</html>

Okay, was ist denn das? sedoparking, IONOSParkingDE? 🤔

Ein ziemlich eindeutiger Hinweis auf den Hosting-Anbieter IONOS von 1&1. Schnell wurde klar, dass der Fehler offenbar mit einer Funktion von IONOS zusammenhängt, auf leeren Domains („Domain-Parking“) Platzhalter-Seiten mit Werbung zu schalten. Igitt. Aber meine Domain war doch gar nicht geparkt!

Immerhin: Über den Direktlink mein.ionos.de/domain-parking kann ich die Werbe-Funktion ausschalten. Problem gelöst? Pustekuchen, denn der Syntax-Error war immer noch da, nur der Error-Log war jetzt anders und verwies auf die alternative Platzhalter-Website mit der h1 „Zugriff nicht erlaubt“. Warum war dieses Modul überhaupt aktiv? Kann man das nicht abstellen? Das habe ich auch den Support-Chat von IONOS gefragt, die etwas ernüchternde Antwort: „ Ich habe die Rückmeldung von der Fachabteilung erhalten, dass wir den Platzhalter im Webhosting nicht deaktivieren.“ Die einzig mögliche Lösung sei, die Website auf das Server-Angebot von IONOS umzuziehen, dort sei die generelle Deaktivierung der Platzhalter möglich. Wow, das ist mal ein Unique Selling Point. Ziemlich übergriffig, in meinen Augen.

(For the record: Der IONOS-Tarif, auf dem die Website läuft, heißt übrigens „1&1 Managed WP Starter“).

Die Lösung

Guter Rat war teuer. Vielleicht ein anderes Plugin versuchen? Aber dann müsste ich meine zahlreichen Redirections neu importieren und testen. Da fiel mir ein Link beim Update-Nag-Hinweis des Plugins auf: „Manual Upgrade“.

Screenshot: Update-Hinweis des Plugins „Redirection“

Und ein Klick hierauf offenbarte mir die SQL-Befehle, die in der Datenbank vorzunehmen waren.

Screenshot: Die SQL-Befehle für das manuelle Update der Redirection-Datenbank

Na gut, dann musste ich hier wohl selbst Hand anlegen. Im IONOS-Backend komme ich über diesen Link zur Verwaltung meiner Datenbanken: mein.ionos.de/mysql-overview. Und dort kann ich über phpMyAdmin die Datenbank direkt editieren, also: Datenbank ausgewählt, ein Backup heruntergeladen, und dann einfach im Reiter „SQL“ die obenstehenden Befehle eingefügt und mit „OK“ bestätigt. Das verlief reibungslos, und dann konnte ich das Update der Datenbank im WordPress-Dashboard mit einem Klick auf „Complete Upgrade“ abschließen.

Auch wenn die Lösung letztendlich ziemlich einfach war, so ist sie doch denkbar ungeeignet für WordPress-Anwender, die nicht manuell ihre Datenbank editieren möchten oder können. Der IONOS-Support war hier nicht wirklich hilfreich: Eine Antwort auf meine Frage, warum das Platzhalter-Modul denn aktiv ist, wenn die Domain gar nicht geparkt ist, bekam ich keine Antwort. An den Error-Logs zeigte sich der Support nicht interessiert. 🤷


Die Illustration oben beruht auf Arbeiten von Elina Cecilia Giglio auf Blush.design. Zu den Lizenzhinweisen.

8 Kommentare zu “Syntax Error – wenn das Redirection-Plugin mit dem Hoster kollidiert

  1. Bei Ionos kann ich den Twitter-Support nur empfehlen. @ionos_hilft ist technisch kompetent, kann direkt auf Konten und Technik zugreifen und benötigt nur selten Unterstützung von der Fachabteilung. 95% meiner Probleme konnten sie direkt lösen. Einen Versuch wäre es wert, da mal zu fragen.

    • Hallo Torsten,

      danke für den Input! Ich fand den Support via Chat auch nicht schlecht und ich vermute, auf Twitter hätten sie mir vielleicht dasselbe mitgeteilt: Dass der Platzhalter nicht deaktiviert werden kann. Es kann aber durchaus sein, dass ich nicht die richtige Frage gestellt habe, wie dein folgender Kommentar auch zeigt… 🤷

  2. In der Sache denke ich, dass die entscheidende Frage ist, warum da ein 403 Forbidden kommt, wenn du versuchst den REST API Endpoint /wp-json/redirection/v1/plugin/database/ via POST aufzurufen.

    Hast du (oder der Hoster) da vielleicht eine Sicherheitslösung am Start? Irgendwas in der htaccess oder in einem Plugin, dass die API-Endpunkte absichert?

    • Auf der Website läuft Wordfence, aber ich habe es auch komplett ohne probiert: Alle Plugins deaktiviert, Standard-Theme, Basic-htaccess. Mir ist nur aufgefallen, dass der Error-Log jeweils auf diese Ionos-Platzhalterseiten verwies. Mir fehlt leider das Verständnis, um hier tiefer einzusteigen, aber ich war froh, jetzt diesen Workaround gefunden zu haben.

  3. Hab gerade dasselbe Problem mit Managed WordPress und IONOS, allerdings ohne das o.g. Plugin, und zwar seitdem ich die WP-Loginseite mit htaccess schützen will. Dann kommt die Passwort-Aufforderung bereits unerwünscht beim normalen Startseitenbesuch. Die Fehlermeldung weist wie hier bei dir oben auf ein ähnliches Problem mit „Parking“ hin. Bisher blockt der Support. Bei zwei anderen WordPress-Seiten (nicht „managed“) hat das mit htaccess fehlerfrei funktioniert. So komme ich nicht weiter. :-/ Unbekannterweise liebe Grüße in die alte Heimatstadt.

    • Hallo T.! Ja, nervig sowas! Ich hoffe, du findest da schnell eine Lösung! Viele Grüße!

      • Danke für den Hinweis auf den Chat! Der IONOS-Mitarbeiter hat sich sehr viel Zeit genommen. Auch wenn der rätselhafte Punkt mit dem „IONOSParkingDE“ trotz aller Mühe nicht aufgeklärt werden konnte, habe ich zufällig selbst einen Workaround entdeckt. Für den Fall, dass andere Google-Suchende hier landen: Bei mir lag es offenbar mit auch am WordPress-Theme „Koji“ in Kombination mit Was-auch-immer.

        Nachdem im Customizer unter „Seitennummerierung“ umgestellt wurde von „Mehr laden durch Scrollen“ hin zu „Links zur vorherigen und nächsten Seite“ entfällt das Popup-Fenster. Und auch die Passwort-Abfrage ist nicht mehr auf der Startseite, sondern erst im Loginbereich. Ursache aber unklar. Aufgefallen war mir das, weil bis zum Aufrufen des Pop-ups nicht alle erwarteten Inhalte auf der Startseite luden.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert