Beiträge von Ammaletu

  • Kann erstelltes Widget nicht mehr bearbeiten oder löschen

    Also ich habe mal in meine Datenbank geschaut. Du musst ggf. einstellen, dass Dir alle Daten der wp_options-Tabelle angezeigt werden und nicht nur die ersten 50 oder so (je nach Tool das Du dafür nutzt).

    In der Spalte "options_name" müsstest Du dann mal nach "widget_text" suchen. In "option_value" müsste dann etwas wie das hier stehen:

    Code
    a:1:{i:1;a:2:{s:5:"title";s:0:"";s:4:"text";s:0:"";}}



    Setze hier einfach mal den Teil nach "title" auf 0 und einen leeren String. Also z.B. aus "a:1:{i:1;a:2:{s:5:"title";s:10:"abcdefghij";s:4:"text";s:0:"";}}" das hier machen "a:1:{i:1;a:2:{s:5:"title";s:0:"";s:4:"text";s:0:"";}}". Das sollte es eigentlich tun.

  • Startseite mit einem Beitrag SUCHE Seite mit allen Ergebnissen

    Oh ja, das hatte ich tatsächlich nicht ganz verstanden. Deine Lösung ist soweit richtig, es geht aber noch einfacher. Einfach oben über dem [EDIT: if (have posts)] das hier einfügen:

    PHP
    $posts = query_posts($query_string . '&posts_per_page=20');

    Und da dann halt die entsprechende [COLOR=black]Zahl[/COLOR] eintragen. Da Du die Query ja in ihrem Inhalt nicht änderst, gibt es nicht wirklich einen Grund, eine neue Query zu bauen (was Du mit new WP_Query tun würdest).

    Was ich oben zum Ersetzen der Links geschrieben hatte, ist dann natürlich trotzdem nötig, damit weitere Ergebnisseiten korrekt verlinkt werden. ;)

  • Kommentare lesen ohne Anmeldung

    Das ist die Standard-Einstellung, dass jeder Kommentare lesen kann. Außer bei Passwort-geschützten Posts. Wenn das bei Dir im Moment nicht funktioniert, musst Du im Theme mal schauen, wieso. Weitere Infos, wenn Du uns was über Dein Theme verrätst. ;)

  • Startseite mit einem Beitrag SUCHE Seite mit allen Ergebnissen

    Hallo!

    Diese beiden Zeilen generieren die Navigation:

    PHP
    <div class="title"><?php posts_nav_link('','','OLDER POST') ?></div>
<div class="title"><?php posts_nav_link('','NEWER POST','') ?></div>



    Die kannst Du aus der search.php einfach entfernen, da machen sie ja keinen Sinn. Was Du stattdessen ggf. bräuchtest, wäre die Navigation für die weiteren Seiten. Wenn es mal mehr als die eingestellte Anzahl von Ergebnissen pro Seite sind, soll man ja zu Seite 2, 3 etc. navigieren können. Das sieht im Default-Theme so aus und gehört direkt unter das endwhile:

    PHP
    <div class="navigation">
   <div class="alignleft"><?php next_posts_link('&laquo; Vorherige Eintr&auml;ge') ?></div>
   <div class="alignright"><?php previous_posts_link('N&auml;chste Eintr&auml;ge &raquo;') ?></div>
  </div>

  • Anzeige des letzten Editors einer statischen Seite

    Ah ok. Also das gibt es in der Version 2.3.3 noch nicht, meines Wissens nach. Du müsstest einfach mal in die PHP-Datei schauen, welche diese Ausgabe generiert. Ok, ganz so einfach ist es nicht, weil WP innen drin so unübersichtlich ist, aber mit etwas Glück sollte die Stelle zu finden sein. Müsste eine Datei im wp-admin-Ordner sein, denke ich. edit-pages.php oder new-page.php vielleicht?!

  • Anlage fehlt??

    Was ist daran nicht zu verstehen? Steht "Anlage fehlt" im Backend über den Beiträgen (z.B. Beitragseditor) oder im Frontend (Webseite/Blog)? In ersterem Fall ist es eher ein WP-Problem, in letzterem wird es wohl an Deinem Theme liegen. Dann wäre die nächste Frage, wo genau es da steht: Nur in der Einzelansicht oder auch auf den Archivseiten, Suchergebnissen etc. So oder so wirst Du im Theme schauen müssen, woher das kommt. Wenn Du uns über das Theme nichts verraten möchtest, können wir Dir da nicht helfen.

    EDIT: Ok, mit Infos aus PN lässt sich folgendes sagen: Suche mal in den Themedateien hier nach:

    PHP
    <p class="attachment">



    An der Stelle müsste diese Ausgabe generiert werden. Das Theme erwartet da möglicherweise eine Anlage, um einen Link dazu zu generieren, und gibt das eben aus, wenn keine Anlage da ist. Keine Ahnung, wie genau das gedacht ist, aber da es Deine Seite ist, müsstest Du das mit einem Blick in den Quelltext ja nachvollziehen können, was da passiert. Wenn sich nichts finden lässt, könnte das natürlich auch von einem Plugin stammen. Da müsstest Du mal schauen, ob es ohne die Plugins auch passiert bzw. welches von ihnen sowas vielleicht in die Seite schreiben könnte.

    EDIT 2: Und um es noch erwähnt zu haben: So ein kommentarloses "schieb" nicht einmal zwei Stunden nachdem Du das ursprünglich gepostest hast, empfinde ich auch als ziemliche Frechheit. Das ist schon frech, wenn Du das nach zwei Tagen machst, und in aller Regel bringt das eh nichts. Entweder es fällt jemandem etwas dazu ein oder eben nicht. Daran kannst Du nur etwas ändern, wenn Du weitere Infos rausrückst. :-/

  • Post Slug - Titelform nach Update verschwunden

    Das lässt sich mit etwas Googlen leicht beantworten: :)

    "The Post (or Page) slug is now displayed as the Permalink under the Title field in writing or editing a Post or Page. If you are using the "Default" Peramlink Settings you will not see and can't edit the Permalink. Only if you are using a 'pretty Permalink' (e.g. Month and name) in Settings->Permalinks will the Permalink be available for edit. When creating a new Post or Page, the Permalink field won't show up until you complete the Title."
    WordPress › Support » WP 2.5 Post Slugs

    Allerdings gibt es da wohl auch noch einen schwer zu fassenden Bug was Seiten betrifft -- für statische Seiten kann der page slug auf einigen Servern erst nach dem Publizieren editiert werden. Hauptsächlich tritt das wohl mit PHP4 auf:
    #6529 (Cannot edit page-slug before publishing) - WordPress Trac - Trac

  • 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?! ;)