Import-Funktion: Wird der Bug mit dem falschen Timestamp bereinigt?

  • Hallo zusammen,

    ich bin willens, mein bisher bei twoday.net geführtes Blog mit ca. 1700 Beiträgen und gut 6000 Kommentaren auf eigene (WordPress-)Beine zu stellen. Diverse Ex- und Import-Versuche sind schon mal recht positiv verlaufen, aber eine Sache ist besonders lästig: WordPress übernimmt Beiträge und Kommentare, die zwischen 0:00 und 1:00 Uhr oder zwischen 12:00 und 13:00 Uhr abgeschickt wurden (und das sind nicht eben wenige), mit dem (idiotischen) Unix-Urknall-Datum 1. Jan 1970, 1:00 Uhr. Hier hilft nur eine manuelle Anpassung, die äußerst zeitraubend ist. Toll wäre es natürlich, wenn die vor der Tür stehende neue WordPress-Version 2.7 auch in dieser Hinsicht fortschrittlicher wäre. Besteht da Hoffnung bzw. auf welchem Weg müßte man dieses Problem an wen zwecks Abstellung kommunizieren?

    Dank & Gruß,
    Ralph

    • Anzeige

    Hallo!

    Wenn du gerade an deiner Website arbeitest oder dein aktuelles Hosting überdenkst: Wir betreiben mit NetzLiving eine Hosting-Plattform, die speziell auf Performance, Sicherheit und einfache Verwaltung ausgelegt ist.

    • ✔️ Schnelle Ladezeiten (optimiert für WordPress & Co.)
    • ✔️ Deutsche Server & DSGVO-konform
    • ✔️ Persönlicher Support (kein 0815-Ticket-System)

    Mehr erfahren

  • Da es mehrere Arten gibt, wie man ex-/importieren kann, wäre eine Angabe hilfreich, wie du das machst. (PhpMyAdmin als SQL oder WP XML Export oder ...)

    Ich bitte um Verzeihung für das Versäumnis! Bei twoday.net exportiere ich im MT-Format und importiere diese (noch durch diverse Suchen & Ersetzen-Läufe optimierte) Textdatei in WP 2.6.2 über "Verwalten" -> "Import" -> "Movable Type und TypePad". Das klappt ja prinzipiell auch.

    Ich habe freilich in diversen anderen Blogs mit den Erfahrungsberichten Umzugswilliger immer wieder Hinweise darauf gefunden, daß WP beim Datei-Import die korrekt vorliegenden Uhrzeiten ignoriert, sofern diese in der Mittags- oder Mitternachtsstunde liegen. Bei mir das Gleiche. Deshalb dachte ich, dieser Bug wäre längst bekannt!

    Natürllich hat man den Ärger nur einmal zu bewältigen, aber wenn man halt sehr viel zu importieren hat, ist das manuelle Anpassen eine ebenso lästige wie hirnlose und an sich unnötige Tätigkeit...

    Dank & Gruß,
    Ralph

  • Moveable Type Import Datei - Datumswerte werden laut Spezifikation so angegeben:

    Code
    AUTHOR: Foo Bar
    TITLE: A dummy title
    DATE: [B]01/31/2002 03:31:05 PM[/B]
    CATEGORY: News

    darauf wendet WordPress beim Import die regulare PHP Funktion:

    Code
    $date = trim( substr($line, strlen("DATE:")) );
    $date = [B]strtotime[/B]($date);

    an und baut daraus den Zeitstempel für den Eintrag im Blog.
    Wenn etwas mit dem Datumswert in der MT Datei nicht stimmt, liefert die strtotime() Funktion den 1.1.1970 1:00 Uhr (Start of Unix Epoc)
    Dies kann auch passieren, wenn die Jahreszahl nur 2 stellig ist, siehe PHP Manual.
    Ohne einen Ausschnitt aus der MT Datei mit einem später falsch konvertiertem Datum kann man nicht sagen, was schief läuft, denn der Import Code im WP sieht erstmal formal korrekt zur Spezifikation von MT aus: mtimport - Movable Type Import Format

  • ...Ohne einen Ausschnitt aus der MT Datei mit einem später falsch konvertiertem Datum kann man nicht sagen, was schief läuft, denn der Import Code im WP sieht erstmal formal korrekt zur Spezifikation von MT aus: mtimport - Movable Type Import Format


    Vielen Dank für die ausführlichen Erklärungen, ich will mal ein konkretes Beispiel liefern. Das hier ist ein zu migrierender Beitrag:

    zonebattler's homezone: Tiere der Großstadt ( 2. Sep. 2007, 0:10 Uhr )

    und so kommt er -seines korrekten Datums verlustig gegangen- in WP an:

    zonebattler’s homezone» Blogarchiv » Tiere der Großstadt ( 1. Jan. 1970, 01:00 Uhr )


    In der MT-Import-Datei -um die es hier ja geht- stand und steht folgendes:

    Sieht doch korrekt und absolut spezifikationsgemäß aus, oder? Und trotzdem haut es nicht hin und bei vielen anderen Beiträgen und Kommentaren auch nicht. Allen gemein ist ein Timestamp zwischen 0:00 und 1:00 Uhr bzw. 12:00 und 13:00 Uhr...

    Schon recht eigenartig, oder? Ich könnte noch Dutzende weitere Beispiele liefern, die Sache ist systematisch und reproduzierbar!

    Vielen Dank für die analytische Mühe und eine gute Nacht,
    Ralph

  • Also ich hab mal einen kleinen Test gemacht. Folgender PHP Code wurde ausgeführt:

    Code
    $date = strtotime(trim(' 09/02/2007 00:10:00 AM'));
        var_dump($date);echo "<br/>";
        $date = date('Y-m-d H:i:s', $date);
        var_dump($date);echo "<br/>";
        $date_gmt = get_gmt_from_date($date);
        var_dump($date_gmt);echo "<br/>";

    und das Ergebnis ist folgendes (egal ob Leerzeichen zwischen Zeit und AM oder nicht, auch Kleinschreibung ändert nix):

    Code
    bool(false) 
    string(19) "1970-01-01 01:00:00" 
    string(19) "1969-12-31 23:00:00"

    Also das Ganze nochmal wiederholt, aber diesmal AM weggelassen:

    Code
    $date = strtotime(trim(' 09/02/2007 00:10:00 '));
        var_dump($date);echo "<br/>";
        $date = date('Y-m-d H:i:s', $date);
        var_dump($date);echo "<br/>";
        $date_gmt = get_gmt_from_date($date);
        var_dump($date_gmt);echo "<br/>";

    und jetzt ist das Ergebnis:

    Code
    int(1188684600) 
    string(19) "2007-09-02 00:10:00" 
    string(19) "2007-09-01 22:10:00"

    Ok, die PHP strtotime() Funktion spinnt also also mit AM/PM Angaben. Es gab dazu einen Bug Eintrag bei PHP, der eigentlich 2005 gelöst worden sein sollte: PHP Bugs: #34771: strtotime() fails with 1-12am/pm

    Allerdings sieht das nicht danach aus oder der ist wiedergekehrt in PHP. Wenn man sich die Bugliste von PHP zum Thema strtotime() ansieht, dann merkt man schnell, das an dieser Funktion immer wieder was nicht geht und das auch noch OS abhängig ist: PHP Bugs: Search

    Evtl. könnte man das in WP umgehen. Allerdings ist das dann im WP Trac zu melden, doch ich fürchte, das kann dauern.
    Und um es nochmal klar festzustellen, es ist kein WordPress Problem sondern ein PHP Bug.

  • Evtl. könnte man das in WP umgehen. Allerdings ist das dann im WP Trac zu melden, doch ich fürchte, das kann dauern.
    Und um es nochmal klar festzustellen, es ist kein WordPress Problem sondern ein PHP Bug.

    Danke erneut für das Verfolgen des Phänomens! Bitte um Verzeihung, wenn ich den Fehler fälschlicherweise WP untergeschoben habe: Aus Sicht des Anwenders ist es halt schwer zu sagen, wo da was im Getriebe hakt...

    Wie geht man da nun pragmatischerhalber am besten vor? Nützt es was, per Suchen & Ersetzen die AM/PM Angaben in der Importdatei vor dem Einlesen zu eliminieren?

    Erneut ein dickes Dankeschön,
    Ralph

  • Die pragmatische Lösung sieht so aus:

    1. Suche die Datei /wp-admin/import/mt.php
    2. in einem Texteditor öffnen.

    Nun nach folgender Stelle suchen (bei WP 2.6.2 ab Zeile 362):

    Code
    } else if ( 0 === strpos($line, "DATE:") ) {
                    [COLOR=Red]$date = trim( substr($line, strlen("DATE:")) );
                    [/COLOR][COLOR=Red]$date = strtotime($date);
    [/COLOR]                $date = date('Y-m-d H:i:s', $date);
                    $date_gmt = get_gmt_from_date($date);

    und durch folgenden Code ersetzen:

    Code
    } else if ( 0 === strpos($line, "DATE:") ) {
                    [COLOR=DarkGreen]preg_match("/^DATE:\s*(\d+\/\d+\/\d+\s*\d+:\d+:\d+)\s(AM|PM|)*/", $line, $hits);
                    $date = strtotime($hits[1]);
                    if($hits[2] == 'PM') $date += 43200; //add 12 hours[/COLOR]
                    $date = date('Y-m-d H:i:s', $date);
                    $date_gmt = get_gmt_from_date($date);

    Nun sollten alle Datumswerte korrekt importiert werden.
    (Zur Sicherheit kannst du ja vorher eine Kopie der Originaldatei machen.)
    erfolgreich getestet mit WP 2.6.2.

  • Die pragmatische Lösung sieht so aus:
    ...
    Nun sollten alle Datumswerte korrekt importiert werden.
    (Zur Sicherheit kannst du ja vorher eine Kopie der Originaldatei machen.)
    erfolgreich getestet mit WP 2.6.2.

    Herzlichen Dank, wenn das klappt, spart es mir immens viel Arbeit!

    Dann reduzieren sich meine Importprobleme auf das manuelle Anpassen der ganzen internen Verlinkungen auf eigene Artikel. Auch das wird Monate brauchen, aber da kann mir nun wirklich niemand helfen... ;-)

    Merci und nochmals ganz herzlichen Dank für die Unterstützung,
    Ralph

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!