Beiträge von Ammaletu

  • Kann erstelltes Widget nicht mehr bearbeiten oder löschen

    Wenn es wirklich an der Länge der Überschrift liegt, könntest Du Dich einfach direkt an der DB einloggen und es dort korrigieren. Falls Du Dir nicht sicher bist, was Du tust, zieh vorher auf jeden Fall ein DB-Backup. Die Widgets sind in der wp_options-Tabelle gespeichert. Sieht etwas kryptisch aus, aber Du müsstest es finden und kürzen können. Den Rest kannst Du dann ja aus WP heraus erledigen.

  • Anlage fehlt??

    Hast Du einen Link zur Seite? Oder welches Theme verwendest Du? Und geht es überhaupt um die Webseite oder steht das im Backend? Etwas mehr Infos musst Du uns schon geben. ;-)

  • RSS-Feed schneller aktualisieren

    Das Widget nutzt eine Standard-Funktionalität in WordPress für den Aufruf des RSS-Feeds, welche wiederum einen Cache benutzt. Ich glaube ehrlich gesagt nicht, dass sich das so ohne weiteres ändern lassen wird. So oder so sollte das Intervall auch nicht zu klein sein. Wenn Du das ohne Cache umsetzen würdest, würde der RSS-Feed ja bei jedem Aufruf der Seite neu gezogen, und zwar von Deinem Server. Das würde ziemlichen Traffic verursachen und die Seite sicher auch langsamer machen.

    Ob man die Cachezeit vielleicht auf eine halbe Stunde oder so runtersetzen kann, weiß vielleicht jemand, der sich damit besser auskennt, oder es lässt sich per Google rausfinden. Suche mal nach "wordpress magpie rss" oder so. Bin leider etwas in Eile heute Abend... :-/

  • Serverwechsel und update

    Ok, ein paar Sachen fallen mir dazu ein:

    - Memory Size: In der PHP-Installation kann man einstellen, wie viel Speicher ein PHP-Prozess verbrauchen darf. Deines steht scheinbar auf 8MB, was offensichtlich für WordPress nicht ausreicht. Bei mir lokal sind es 16MB und auf meinem Server offenbar sogar 50MB. Du kannst probieren, das mit einer Angabe wie memory_limit = 16MB; in Deiner php.ini zu beeinflussen, aber die Chancen stehen ganz gut, dass Dein Hoster sowas nicht erlaubt. In dem Fall müsstest Du Dich an den Hoster wenden.

    - Memory-Fehler haben, denke ich, nicht direkt etwas mit der Zeile zu tun, die da angezeigt wird. Das ist nur die Methode, die zufällig lief, als der verfügbare Speicher alle war, quasi der Tropfen, der das Fass zum Überlaufen brachte. An der Stelle kann man also nichts daran machen.

    - DB-Name: Da sollte es meiner Meinung nach reichen, ihn in der wp-config richtig einzutragen.

    Ansonsten weiß ich da erstmal auch nicht wirklich weiter. Es kann aber sein, dass das alles mit dem Speicher zu tun hat.

  • Umlaute nach Speichern zerschossen

    Ja sicher, da stimmt etwas mit den Kodierungs-Einstellungen nicht. Genauer kann ich es Dir ohne genauere Infos von Dir nicht sagen. Aber an folgenden Stellen kann etwas dazu stehen, und die jeweils verwendeten Kodierungen sollten übereinstimmen:
    - Encoding der DB (z.B. in phpMyAdmin überprüfen)
    - Encoding der DB-Connection (DB_CHARSET in der wp-config.php ?!)
    - Codierungsangabe in den WP-Optionen
    - Encoding der Themedateien (für alle direkt im Theme stehenden Texte, sollte nicht die Beitragstexte selbst betreffen, mit jedem guten Texteditor zu überprüfen)
    - Encoding-Angabe im Theme (sollte automatisch aus den Optionen generiert werden, aber könnte natürlich auch explizit und damit ggf. falsch im Theme stehen)

  • Serverwechsel und update

    Lese ich das richtig heraus, dass Du beim Umzug WordPress auch noch aktualisiert hast? Dann musst Du wahrscheinlich die upgrade.php ausführen. Näheres dazu findet sich in der detaillierten Update-Anleitung, die es auch auf dieser Seite irgendwo geben sollte.

    Davon abgesehen wäre wünschenswert zu wissen, von welcher Version aus Du aktualisiert hast. Da kann es ggf. danach zu Konflikten mit Plugins kommen, die unter der neuen Version nicht mehr funktionieren. Wenn es so gar nicht geht, lade erstmal die alte Version wieder rauf und schau, dass WordPress mit der alten Db auf dem neuen Server erstmal läuft. Das Update von WP würde ich dann in einem zweiten Schritt durchführen.

  • Darstellungs, Validierungs- und Umlautproblem

    Sieht im IE zugegebenermaßen anders aus als im Firefox, aber ausnahmsweise kann man sich streiten, ob es der IE richtig macht oder der Firefox. ;-)

    Das hier steht im Stylesheet (Zeile 683):

    Code
    #right-sidebar li li a {	background: url(images/bg_bullet_full_2.gif) left no-repeat;	padding-left: 12px;}



    Was Du vermutlich meinst, ist aber "left top" statt nur "left", denn der Defaultwert für die vertikale Platzierung scheint "center" zu sein. Probier es mal damit, dann sollten die Listenpunkte in beiden Browsern gleich aussehen.

  • Darstellungs, Validierungs- und Umlautproblem

    Wenn es irgendwie geht bleibe bei UTF-8 und konvertiere lieber das Forum. Auf lange Sicht erspart man sich viele Probleme, wenn man konsequent auf UTF-8 setzt. Mischformen kommen dagegen nicht ganz so gut. ;-)

    Wenn Du eines der beiden Projekte ändern willst, musst Du zum einen im Projekt die richtige Codierung einstellen. Zum anderen müssten die Daten in der Datenbank angepasst werden, bzw. je nach MySQL-Version müsste die Codierung der DB geändert werden. So oder so solltest Du immer ein komplettes Backup machen, bevor Du Dich daran probierst.

    Validierung vor der Problemlösung ist natürlich wünschenswert. Aber es muss auch nicht unbedingt sein. Nicht in jedem Fall haben Validierungsfehler etwas mit Deinem Problem zu tun.

    Die falschen Bytes sind tatsächlich in Zeile 278 enthalten. Wenn Du Dir das z.B. im Firefox in der Quelltext-Ansicht anschaust, sieht man im title-Attribut der Listenpunkte in dieser Zeile Zeichen, die nur als leeres Kästchen oder als Fragezeichen dargestellt werden.

    Code
    </li><li id="rss-89003311" class="widget widget_rss">... title='Wann: Sa 3. Mai 2008 20:00 bis 23:30� CEST  Wo: Chicago Status des Termins: bestätigt' ... </li>

    Das kommt aus der "Termine/Events"-Sektion. Wie auch immer Du die eingefügt hast, da stimmt die Codierung jedenfalls nicht. Sollte sich aber eigentlich beheben lassen.

    So und damit zu Deinem eigentlichen Problem: Kannst Du bitte genauer definieren, was "nicht vernünftig dargestellt" heißt?! ;-)

  • 2 Bilder untereinander, LF gesetzt, linksbündig gesetzt

    Also um erstmal das Desaster mit den hochgerutschten Kommentaren zu beseitigen, probiere mal Folgendes im Stylesheet einzufügen (ab Zeile 237 müsste es stehen):

    Code
    #inhalt .postmetadata {
  clear: both;

    Damit das zweite Bild nicht danebenrutscht sollte es reichen, das erste Bild nicht linksbündig zu markieren. Soll es ja in dem Fall auch nicht sein.

  • Probleme nach Upgrade zu 2.5

    So auf Anhieb würde ich vermuten, dass Deine Probleme weniger am Sprung auf 2.5 als vielmehr am (impliziten) Sprung auf 2.3 liegen. Da wurde doch die ganze Kategorienstruktur in der DB umgebaut.

    Folgende Fragen solltest Du beantworten:
    - Nutzt Du Plugins, die in die Darstellung auf der Seite eingreifen und vielleicht etwas mit Kategorien zu tun haben könnten? Plugins zum Sortieren der Kategorien etwa?!
    - Enthält Dein Theme irgendwo eigene SQL-Queries?

    Davon abgesehen: Welches Theme verwendest Du überhaupt?

  • Kommentarverweis aus Kategorie

    Zitat

    Die Frage ist nur, welchen Vorteil hätte dann eine zusätzliche single.php?

    Übersichtlichkeit. Wenn man verschiedene Dateien für verschiedene Ansichten benutzt (Index, Single, Page, Archiv etc.) und Gemeinsames auslagert (Sidebar, Header, Footer), weiß man normalerweise sofort, wo man etwas suchen muss, und die Dateien werden kleiner. Dafür kommt die ein oder andere Codezeile dann doppelt vor. Aber solange Dein Theme funktioniert und Du es nicht aus Interesse umbauen willst oder es Dir wirklich zu kompliziert aufgebaut ist, lohnen sich Modifikationen vermutlich nicht. Du weißt schon, "never touch a running system". ;-)

  • sharethis integration

    Meine Bemerkung zu JavaScript bezog sich auf die Tatsache, dass jeder Besucher Deiner Seite und damit natürlich auch Du selbst JavaScript im Browser deaktivieren kann. Und ohne wirst Du den Button nicht sehen können, glaube ich. war jetzt nur eine Möglichkeit, wieso es bei Dir nicht klappen könnte.

  • Rechte Spalte teilweise ausblenden

    Dir ist schon klar, dass Du die Breitenbegrenzung des iFrames loswerden musst, oder? Dazu hatte ich in meiner letzten Antwort ja schon was geschrieben. Andernfalls nützt Dir ja auch die ausgeblendete rechte Spalte nichts. Das Design, dass Du verwendest, ist nun mal mehr oder weniger fluide, da sollte es auch das iFrame sein.

    Ob sich die rechte Spalte einfach ausblenden lässt, kann ich Dir auf Anhieb nicht sagen. Mit einer entsprechenden overflow-Definition am iFrame geht das vielleicht sogar, aber so richtig gut würde das vermutlich nicht aussehen. Das grundlegende Vorgehen hatte ich Dir ja schon geschildert (Template erstellen, Variable definieren, diese in sidebar.php abfragen). Aber ich denke, Du fährst besser, wenn Du erstmal den Platz in der Content-Spalte ausnutzt. Wenn Du nicht gerade mit einer 800*600-Auflösung unterwegs bist, sollte die Tabelle da eigentlich schon hinpassen, wenn Du die festen 680 Pixel Weite loswirst.