Beiträge von Ammaletu

    Wie schon gesagt, das Plugin nutzt nicht die für Widgets vorgesehenen Mechanismen. Ich habe dem Autor mal einen Kommentar hinterlassen. Widgets sollen sich nämlich eigentlich nahtlos in alle Themes einfügen, egal wie deren spezielles HTML nun gerade aussieht. Obiger Fix tut es aber auch, solange keine neue Plugin-Version erschienen ist. ;)

    Zitat

    Kann mir jemand sagen, was ich ändern muss, damit der Besucherzähler genau so aussieht wie die anderen Widget auf meiner Page ?

    Du müsstest dafür sorgen, dass das HTML des neuen Widgets mit dem der schon vorhandenen Widgets übereinstimmt. Im Moment besteht Deine Sidebar offenbar aus divs mit h3-Tags als Überschrift. Das neue Widget liegt aber in einem li mit einem h2-Tag als Überschrift.

    Wenn ich mich mühsam dran erinnere, wie die Widgets funktionieren, dann sollte das eigentlich ja nicht passieren. Würde das nicht das Theme setzen, wenn nicht der Standard verwendet werden soll?! Da gibt es Variablen für "before widget", "after widget", "before headline" und "after headline". Entweder Dein Theme baut an der Stelle also Mist oder das Plugin nutzt nicht die vorgesehenen Strukturen. Hast Du mal einen Link zu beidem, dann kann ich genauer schauen, woran es liegt.

    Ich würde Dir vorschlagen, die Seite erstmal ohne JavaScript in beiden Browsern zum Laufen zu kriegen, und dann zu schauen, welches JS eventuell das Problem verursacht. Ohne JS lädt der IE7 die Seite jedenfalls. Es fehlt dann das Flash, logisch, und es fehlt der Hintergrund im Hauptcontent-Bereich. Letzteres Problem sollte sich erstmal so klären lassen. Und dann bringt, denke ich, ein Script-Problem den IE7 dazu, das Laden der Seite abzubrechen.

    Ich habe die Seite mal im IE7 aufgerufen und bekomme da tatsächlich eine sehr nichtssagende Fehlermeldung des Browsers angezeigt. Schaltet man das JavaScript ab, ist die Seite aber da (wenn auch nicht zentriert und mit aus ihren Boxen laufenden Linktexten in der Sidebar). Also müsstest Du mal schauen, was genau das JavaScript da eventuell an Umleitungen oder ähnlichen Späßen einbaut. Versuch ggf. mal einzelne JS-Dateien auszukommentieren, bis Du die gefunden hast, die das Problem verursacht. Eventuell hilft es auch, noch andere Browser zu testen, ob die eine sinnvollere Fehlermeldung ausspucken (was sagen Opera oder Safari dazu?).

    Ok, ein paar Gedanken dazu. Probiere mal in_category() statt is_category(). Probiere ggf. mal die neue is_front()-Methode oder wie sie hieß. Im Codex findest Du mehr zu diesem Thema. Und natürlich: Nicht WP-Kerndateien ändern, lieber Deine eigenen Widgets im Theme erzeugen und ggf. die Standard-Widgets mit Deinen überschreiben.

    Zitat

    Gibt es auch eine Download-Version ohne einer ZIP-Datei?

    Ich glaube nicht (ok, klar, Du könntest es aus dem SVN auschecken, aber das ist hier wohl eher keine Alternative *g*), das würde auch nicht viel Sinn machen, da WP aus mehreren hundert Dateien besteht. Und ehrlich gesagt glaube ich auch nicht, dass Du mit WordPress sehr weit kommst, wenn Du am Entpacken des zip-Files schon scheiterst. Ist nicht böse gemeint, aber WP selbst auf dem Server zu installieren erfordert schon noch den ein oder anderen technischen Handgriff.

    Wenn Du es ganz simpel haben möchtest, könntest Du Dir ja WordPress.com » Get a Free Blog Here mal anschauen. Da hast Du weniger Möglichkeiten die Seite anzupassen, dafür ist auch alles schon fertig und wird von WP aktuell gehalten.

    Ansonsten gibt es alternative zip-Programme, bei mir läuft z.NB. TugZip recht gut:
    TUGZip[.de]

    Und ab Windows XP ist das doch eh in Windows integriert, so dass Du WinZip eigentlich gar nicht brauchst.

    Noch mal als kleiner Nachtrag dazu eine Sache, die mir eben gerade Kopfzerbrechen bereitet hat: Folgt auf eine Zahl direkt ein (schließendes) Anführungszeichen, ersetzt WordPress das nicht korrekt durch das typographische schließende Anführungszeichen (Englisch: & #8221;) sondern durch das Zollzeichen (& #8243;). Bei mir war es eben eine Überschrift, die auf "2008" endete. Auch das aktivierte "InTypo"-Plugin hat daran nichts geändert.

    Das Zollzeichen sieht irgendwie ähnlich aus, aber je nach Schriftart ist der Unterschied schon sichtbar, zumal in einer größeren Überschrift. Klar, an der Stelle kann WP ja nicht wirklich wissen, dass ich nicht die Einheit Zoll meine. Kommt mir irgendwie trotzdem blöd vor.

    Naja, jedenfalls habe ich das jetzt für mich erstmal dadurch behoben, dass ich in wp-includes/formatting.php in Zeile 23 und 24 die beiden Konvertierungen für Zoll/Sekunden und Fuß/Minuten rausgenommen habe. Das sieht bei mir jetzt so aus... Edit: Ich würde es posten, aber das Forum zerhaut mir das immer. :-/
    (WP 2.3.3)

    Falls jemand eine schönere Lösung kennt, immer her damit. ;)

    Also ich denke, der Fehler liegt hier noch woanders. Die Kommentare im Quelltext sind ein bisschen irreführend, denn man kann da sehr wohl zwischen Teaser und Volltext umschalten, jedenfalls wenn der Feed die Kurzform im Tag "description" enthält und die Volltext-Variante (incl. HTML) im Tag "content". Zumindest deute ich den oben zitierten Quelltext-Schnipsel mal so.

    Ich glaube, das Problem liegt eher darin, dass Frank das für RSS-Feeds angepasst hat (deswegen auch der Name des Plugins *g*). Und da steht der Volltext-Inhalt, bei mir zumindest, in einem Element namens "content:encoded". Das versucht er da auszulesen. In Deinem Atom-Feed heißt das Element dagegen nur "content" und wird deshalb vermutlich nicht gefunden. Soweit jedenfalls meine Vermutung. Aber ich frage Frank einfach mal. ;)

    Es ist diese Zeile hier, ca. Zeile 35/36:

    PHP
    <small class="commentmetadata"><a href="#comment-<?php comment_ID() ?>" title=""><?php comment_date('d F Y') ?> um <?php comment_time('H:i') ?> Uhr <?php edit_comment_link('edit','',''); ?></small>

    Die sollte so aussehen:

    PHP
    <small class="commentmetadata"><a href="#comment-<?php comment_ID() ?>" title=""><?php comment_date('d F Y') ?> um <?php comment_time('H:i') ?> Uhr</a> <?php edit_comment_link('edit','',''); ?></small>


    Falls das Theme veröffentlicht ist (also keine Eigenkreation), gib doch bitte auch dem Themeautor Bescheid, damit er den Fehler behebt.

    Ähm, also dieses Thema haben wir mehrmals im Monat. Da müsstest Du mit der Suchfunktion eigentlich schon weiterkommen. Aber ich fasse noch mal zusammen: In der Quelltext-Ansicht von WP siehst Du normalerweise weder <br> noch <p>, die werden von WP beim Speichern ergänzt. In der Anzeige auf der Webseite müssten sie im Quelltext trotzdem drin sein. Ob Du die Absätze auch in der normalen Webseiten-Ansicht siehst, hängt vom Stylesheet ab. Schau mal nach, was da für margin oder padding für Absätze definiert ist.

    Das wäre soweit der Normalfall. Bei Dir kann es natürlich auch noch an was anderem liegen, da hilft uns ggf. ein Link zur Seite weiter. ;)

    Das ist vermutlich ein einfach zu behebender Fehler im Theme. Geh mal in die comments.php Deines Themes und suche die Stelle, an der das Datum des Kommentars ausgegeben wird. Dieses Datum soll verlinkt sein mit dem Permalink des Kommentars, was es auch ist, aber der Link wird nicht wieder geschlossen. Vor das "<br />" am Ende der Zeile muss also noch ein "</a>".

    Zitat

    Mein Problem ist, dass das PlugIn zwar Überschriften darstellt (und wahlweise auch Description), aber eben NICHT den Volltext des Postings.

    Das heißt, Du hast die Doku des Plugins gelesen und wie angegeben hier die dritte Zeile auskommentiert und an der fünften den Kommentar entfernt?

    PHP
    // Edit here:
    // For import with pure text
    //$desc  = $item['description'];
    // For import with HTML
    $desc  = $item['content']['encoded'];

    Das ist zugegebenermaßen nicht optimal gelöst, dass man das Plugin manuell modifizieren muss. Das wäre als Option wesentlich besser aufgehoben.

    Tja, und dann muss der Ziel-Feed natürlich auch den Volltext enthalten, klar. Und damit sollte es eigentlich wie gewünscht funktionieren. Mehr kann ich dazu aber auch nicht sagen, da ich nicht die Zeit habe, das selber auszuprobieren. Wenn es wirklich nicht geht, ist es entweder mit Atom oder mit der neueren WP-Version nicht kompatibel. Gegebenenfalls freut sich dann der Plugin-Autor sicher über einen Hinweis auf seiner Seite.

    Falls die geänderte Adresse in ihrer alten Form in den Optionen steht,musst Du das dort auf jeden Fall anpassen. Direkt in der Datenbank, wenn Du Dich nicht einloggen kannst. Nimm ein Tool wie phpMyAdmin und such in der wp_options-Tabelle nach der URL.

    Wenn sich die Adresse des Blogs geändert hat, muss das in den WP-Optionen geändert werden. Da gibt es ein oder Optionen, welche die Blogadresse enthalten, und wenn das nicht mit der tatsächlichen URL übereinstimmt, fällt einem das "canonical URL"-Feature von WordPress auf die Füße. WP leitet ja alle Aufrufe über alternative URLs auf die eingetragene URL um.

    Falls Du in Deinen älteren Beiträgen eigene Beiträge mit der kompletten URL verlinkt hast, müsstest Du diese Links natürlich auch ändern, wenn der Blogaufruf generell dann wieder klappt.

    Wieso Dein Provider Deine Website so verschiebt, dass sich die Blog-Adresse ändert, wäre natürlich noch mal eine ganz andere Frage. Ich meine, war das Absicht? So sind dann ja alle Links auf den Blog kaputt, incl Google.

    Ein anderes sehr schönes Plugin dafür ist InTypo:
    http://dossier.dunker.de/intypo

    Ich kenne Typographical Improvements nicht, aber InTypo nutze ich schon länger und bin sehr zufrieden damit. Eigentlich denke ich auch immer noch, dass so ein Plugin der deutschen WP-Version beiliegen sollte, da es WP alleine ja nun mal nicht richtig hinkriegt. :-/