Beiträge von Melewo

    3.8 ist aktuell, nicht 3.7.1 und der Fehler liegt weder in den Sprachdateien noch an WP. Im Quelltext Deiner Seite wird alles ausgegeben, ist somit vorhanden und wird nur nicht sichtbar angezeigt. Schaue in den Quelltext Deiner Seite und Du findest:

    HTML
    Dieser Beitrag wurde am <...><...>8. Januar 2014<...><...><...> von <...><...>Marcos López<...><...> in <...>Ego<...> veröffentlicht. Schlagworte: <...

    Warum das nicht angezeigt wird, kann ich Dir nicht sagen. Ich habe zum Beispiel rel="category tag" in der wp-includes/category-template.php in rel="tag" geändert, weil rel="category tag" vom Validator bemängelt wurde. Auch in 3.8 ist es noch enthalten, doch das ist nur ein Schönheitsfehler und daran kann es nicht liegen. Vielleicht etwas mit CSS und hidden oder so.

    Wenn Du in Deiner style.css nach

    Code
    .single-author .entry-meta .by-author {
        display: none;
    }

    suchst und aus none inline machst, dann wird auch alles richtig angezeigt. Bei mir steht zwar auch display: none und wird dennoch angezeigt, da es aber richtig angezeigt wird, habe ich mir noch keine weiteren Gedanken dazu gemacht.


    .single-author .entry-meta .by-author {
    display: inline;
    }

    Der Unterschied zwischen Localhost und Web beginnt doch eigentlich damit, dass Du unter Localhost WP in einem Ordner zu liegen hast. Im Browser rufst Du dann auf:

    "http://localhost/wordpress/"

    Bei Strato hast Du ein Paket mit mehreren Domains, von denen Du aber gleich eine per Strato-Formular auf /wordpress zeigen lässt. Und die richtest Du so ein und rufst die auch genauso ein, wie hier beschrieben:

    http://www.strato-faq.de/artikel.html?id=2412

    Wobei diese Beschreibung nur das ist, was Du bei Strato zu erledigen hast. Da Dein Blog aber von Localhost kommt und localhost/wordpress enthält, musst Du auch das noch befolgen,

    http://faq.wpde.org/wordpress-url-aendern/

    schließlich ist ja localhost nicht mehr gültig und /wordpress ist nicht mehr /wordpress sondern nur noch /, da ja /wordpress zum Root- bzw. Startverzeichnis wurde, nach Benutzung des Formulars bei Strato.


    Und schreibe alle Verzeichnis- und Dateinamen klein, Du hast nicht Windows vor Dir, wo Groß- und Kleinschreibung keine Rolle spielt.

    So wird das nichts mit dem Verständnis. Es ist ein Verzeichnis /WordPress_01 zu sehen und ein großgeschriebens EIS ohne wp. Wenn die Domain nicht auf /WordPress_01 verweist, dann musst Du die auch unter example.com/WordPress_01/ aufrufen. Falls die Domain aber auf /WordPress_01 verweist, dann hat dieses Verzeichnis nichts in der htaccess verloren. Mit verweisen meine ich damit keine Weiterleitung, sondern eine Einrichtung als Startverzeichnis für diese Domain.

    Und Groß- und Kleinschreibung hätte ich vermieden, weil dadurch Tippfehler begünstigt werden.

    Code
    Fehler bei der Anfrage:
    INSERT INTO `wp_comments` (`comment_ID`,`comment_post_ID`,`comment_author`,`comment_author_email`,`comment_author_url`,`comment_author_IP`,
                      VALUES  (        '19',            '420',                    'xxxxxxxxxx@gmx.de',                  '',   '95.118.114.139',

    Auf was für Reaktionen wartest Du?
    Ich hätte es nicht gesehen, wenn es Nevery nicht aufgefallen wäre, so viel ist gewiss.

    Kaputt ist kaputt, es sei denn, Du hast beim Einfügen von xxx einmal '', gelöscht, was passieren kann. Was nicht passieren kann, dass ein Flüchtigkeitsfehler (falls es sich um einen handelt), der zu Fehlinterpretationen verleitet, nicht berichtigt wird. Auch kein Wort von einer Kontrolle erfolgt, wo dieser Fehler ansonsten entstanden sein könnte, also ob der nur im Dump auftritt.

    Doch doch, ich habe noch zugriff auf den alten satz. Die daten sind noch da.
    Und ich komme auch über Confixx an die SQL daten - nur kann ich sie nicht einzeln exportieren
    es sind 40 Datensätze.

    Dann ist es doch ganz einfach, Du brauchst doch nur unter Struktur die Tabellen beim ersten Rutsch anhäkeln, die zusammen 2 MB nicht überschreiten (was bei Größe steht) und exportieren und beim zweiten Rutsch die restlichen Tabellen anhäkeln und exportieren. Beide Dateien anschließen in die neue DB importieren und gut ist es, ohne etwas teilen zu müssen.

    Die Schriftart hat wenig mit dem Editor zu tun. Du kannst nur Schriftarten bzw. Fonts verwenden, die auf den jeweiligen Endgeräten mehrheitlich vorhanden sind oder Webfonts benutzen. Webfonts kannst Du dann entweder nach dem Download innerhalb Deines Webspaces speichern, womit Du vermutlich überfordert sein dürftest, weil diese dann auch eingebunden werden müssen, oder wie üblich über eine API von Google laden.

    Wenn Du nur Standardschriften verwenden möchtest, genügen Anpassungen in der style.css vom Theme, wenn Du einen anderen Webfont verwenden möchtest, solltest Du das im Unterforum Jobbörse ausschreiben und einen Entwickler beauftragen.

    Ein Blick in den Quelltext verrät Dir, dass Du zur Zeit "http://fonts.googleapis.com/css?family=Sorts+Mill+Goudy" benutzt. Innerhalb vom Content benutzt Du dann wieder

    Code
    <span style="font-family: Times New Roman;">


    doch dann solltest Du dafür in der style.css einen anderen Font wählen, was Du allein hinbekommen solltest, wenn Du Dich damit ein wenig beschäftigst.

    Gelesen hatte ich es, durchgezählt nicht, so kann es wirklich nichts werden.

    Doch noch einmal zum Kopieren und zum Teilen. Ich meine, in der alten DB ist ja eine Übersicht enthalten, wie groß jede Tabelle ist. Und wenn kein Zugriff mehr auf die alte DB besteht, dann halt unter Localhost und Xampp, wo Du gleich ein paar Trockenübungen machen könntest.
    Teilen brauchst Du nur dann, wenn eine Tabelle 2 MB übersteigt und das doch wohl auch nur bei einigen Hostern. Und welche Tabelle das ist, siehst Du ja, vermutlich _posts, eventuell auch _comments. Die anderen kannst Du in einem Stück hochladen.

    Das ist nun der Mist, wenn man etwas nicht richtig testen kann. Jedenfalls, wenn Du jetzt ein benutzerdefiniertes Feld mit dem Namen 'Ort-und-Termin' anlegst, dann sollte es funktionieren. Innerhalb einer Function musste $post; global gemacht werden, ob hier auch, bin ich mir nicht sicher, weil ich gerade nicht verstehe, warum $mp_content_area; am Anfang global gemacht wurde. Teste das erst einmal so.

    Die sieht so aus (hatte ich das schon gepostet?):[COLOR=#000000][COLOR=#0000BB]


    [/COLOR][/COLOR]


    Nein, hattest Du noch nicht, soweit war ich ja auch einmal eine Seite zuvor mit [COLOR=#000000][COLOR=#DD0000]'Ort-und-Termin'[/COLOR][/COLOR], doch es geht halt in der functions.php nur für Content und nicht für <header>...</header> und das muss dann halt doch in der content-header.php eingefügt werden. Ich schreibe noch einmal um.

    Zwischenstand und Quelltext?
    Jetzt wird der Rest nicht mehr ausgegeben?

    HTML
    <header class="entry-header">
    
    
    <h2 class="entry-meta" style="font-size:12px">
    </header>

    Und der Code von der Datei sollte nach der Ergänzung etwa so aussehen. Testen kann ich den nicht abschließend. Doch da die Rubrik ja bereits innerhalb <header> mit Icon angezeigt wurde, wäre wohl dann alles gut gewesen. Was jetzt ist, ich weiß es nicht, der Theme-Entwickler wird sich ja etwas dabei gedacht haben, H2 innerhalb von <header> zur Verfügung zu stellen.


    Die zusätzlichen und geänderten Zeilen sind rot markiert.

    Wollte mir gerade einen Überblick über Delphi verschaffen, da erfolgt ein Verweis auf Pascal und wenn Du damit gut klar gekommen bist, dann lernst Du PHP recht schnell, erst bei OOP wird es dann wieder etwas anders. In PHP und bei WP musst Du halt mehr auf die Sicherheit achten, dafür um die Speicherverwaltung weniger. Problem ist lediglich, dass WP gefühlte 1.000 eigene Funktionen besitzt.

    Die Core-Dateien von WP sollte man eigentlich nicht anfassen, da die sich ja mit den Updates ändern und überschrieben werden. Du brauchst Dich somit nur aufs Theme zu konzentrieren. Doch CSS ist auch nicht mehr das was es war und da solltest Du dann, wenn schon, denn schon, Dich gleichzeitig noch mit den Möglichkeiten von CSS3 und responsiven Webdesign auseinandersetzen.

    Ich meine, egal wie und womit, irgendwie wird sich ja dieser Hinweis zur Ausstellung in H2 einfügen lassen, sonst wäre ja der Tag nicht enthalten. Es würde nur dumm aussehen, wenn H2 mit diesem Hinweis zur Ausstellung auf der Startseite genauso groß als Untertitel ausgegeben werden würde, wie in der Beitragsseite, wodurch nichts mehr richtig stimmen würde.
    Doch wenn der in H2 auf den Artikelseiten mit H2 19 bis 24px und auf der Startseite oder Kategorie-Seite mit H2 11-14px ausgegeben würde, dann wäre doch alles im Lot. Und mehr als das letzte Codelisting als kleine Änderung ist doch eigentlich nicht erforderlich, nach meinen augenblicklichen Vorstellungen.