Beiträge von Ammaletu

Der Themewechsel sollte keine Auswirkungen haben, mit dem Standard-Theme müsste eigentlich jede Seite funktionieren. Wenn Du Plugins deaktivierst, kann es allerdings zu PHP-Fehlern kommen, wenn das Theme nicht gut programmiert ist.

Besser ist es eigentlich, sowas an einer lokalen Testversion auszuprobieren. XAMPP ist schnell aufgesetzt und einen Dump der DB vom Server einzuspielen sollte auch kein großes Problem sein. Dann hast Du eine WP-Instanz, an der Du das Problem in aller Ruhe einkreisen kannst. Und bei zukünftigen Updates kann man da auch erstmal in Ruhe testen, ob alles funktioniert.

Zitat

Schön und gut... nur leider bin ich was das programmieren angeht eher mehr als unerfahren

Na dann ist ja gut, dass dafür nichts zu programmieren ist. ;-)

Nein ernsthaft: Du musst Dir lediglich überlegen, in welchen HTML-Tags der Text stehen soll. Das Bild lädst Du normal in den Uploads-Ordner hoch. Mit einem Link zu Deiner Seite kann ich Dir das auch schnell aufschreiben.

Also bei den falschen Suchergebnissen hat Google offenbar die Seite als ISO-8859-1 interpretiert, aber mir erschließt sich auch nicht, wieso. Sowohl in der Seite als auch im HTTP-Header steht ja korrekt UTF-8 drin. Kann es sein, dass es früher mal falsch im HTTP-Header stand? Oder hast Du die Meta-Angabe erst kürzlich geändert? Ansonsten würde ich den Google-Spider noch mal drüber schicken und etwas warten, ob Google das dann auf die Reihe kriegt. In der Zwischenzeit kannst Du noch das fehlende schließende div ergänzen (HTML-Validator). ;-)

Wenn Du sowieso keine Widgets nutzt, schreib das doch einfach in die sidebar.php Deines Themes an die gewünschte Stelle. :-)

Hallo!

Es gibt Bonuspunkte für das unaufgefordete Posten eines Links zu der Problemseite, aber Abzug in der B-Note dafür, dass Du nicht geschrieben hast, in welchem Browser das auftritt. ;-)

Ok, habe ich also mal etwas durchgetestet. Im IE7 sieht alles normal aus, im FF2 dagegen verschiebt sich die Sidebar über den Inhaltsbereich. Die Ursache ist offenbar das Suchfeld, welches ebenfalls nach rechts geflotatet ist. Schreibe mal das hier vor das Öffnen des container-divs:

<div class="clear"></div>

Zitat

Habe nichts gefunden.

Dann bleibt Dir immer noch die radikale Lösung: Umschalten auf Standard-Theme. Wenn die Ausgabe dann noch da ist, liegt es nicht am Theme. Ausschalten aller Plugins: Wenn die Ausgabe dann noch da ist, ist es ein WordPress-Fehler. *g* Damit solltest Du sehr schön sehen können, ob es am Theme oder an einem Plugin liegt, und ggf. auch an welchem Plugin.

Zitat

Wenn ich in der Post-Template.php jedoch etwas ändere...dann macht sich das auch in der Ausgabe bemerkbar ...also vllt. könnte man die post-template.php irgendwie modifizieren?

Klar, wenn Du in Coredateien von WP was änderst, macht sich das bemerkbar. Wer hätte es gedacht. ;-) Das ist allerdings keine gute Idee, da solche Änderungen nur bis zum nächsten Update halten oder die WP-Upgrades um einiges erschweren. Deshalb Änderungen immer als Plugin ablegen oder in die functions.php des Themes schreiben. Und hast Du jetzt wirklich in der post-template.php die Ursache für die Ausgabe gefunden?!

Zitat

Das Problem habe nicht nur ich ...auch andere Seiten hatten es bereits ...also kann es nicht speziell mit meiner Seite zusammenhängen ...

Link zu anderen Beispielen? Denn wenn es in diesem Forum schon jemand gehabt hätte, hättest Du den entsprechenden Thread per Forensuche ja sicher gefunden und dann gleich dort gepostet, oder?

Zitat

- ich dachte das PRoblem wäre bekannt.

Wenn das Problem bekannt wäre, hätte Dir mittlerweile jemand die Lösung geschrieben. Bei bekannten Probleme geht das eigentlich immer sehr schnell hier. Für mich klingt das ehrlich gesagt wirklich nach einem Problem mit einem veralteten/schlechten Theme oder Plugin, deshalb die Nachfragen.

Homesite kenne ich nicht, ich selber nutze UltraEdit (kostenpflichtig, aber wirklich nicht zu schlagen als Allround-Editor). Da würde man die Datei öffnen, dann Datei > Konvertieren > ASCII nach Unicode/UTF-8-Bearbeitung und dann Datei > Speichern unter > UTF-8 ohne BOM. In anderen Editoren müsste das ja ähnlich funktionieren. Einfach mal einen Umlaut zur Kontrolle raussuchen, die Datei (wenn nötig) konvertieren und dann als "UTF-8 ohne BOM" speichern.

Am einfachsten müsste es im Prinzip aber sein, die Umlaute einfach durch Entities zu ersetzen. Sind ja in aller Regel nur sieben Stück:
ä => ä
Ä => Ä
ö => ö
Ö => Ö
ü => ü
Ü => Ü
ß => ß

Wie sich das verhält, wenn die Texte aus der deutschen Sprachdatei kommen, bin ich mir im Moment übrigens nicht sicher. In dem Fall stimmt die Codierung hoffentlich immer, da die Texte dann ja per PHP eingefügt werden.

Das Plugin versucht offenbar mit file_exists() zu prüfen, ob Du PHP 5 benutzt. Auf Deinem System ist es aber nicht erlaubt, auf Dateien außerhalb bestimmter Pfade zuzugreifen, das schlägt also fehl. Entweder dem Plugin-Autor fällt ein cleverer Weg ein, PHP 4 und PHP 5 zu unterscheiden, oder Du änderst einfach die entsprechende Zeile des Plugins (aber dann bei Updates des Plugins aufpassen, deswegen ist das nicht so ideal).

Die Einstellung in WordPress muss zu Deiner Datenbank passen. Das kannst Du nicht nach Belieben umstellen, sonst werden natürlich die Beiträge falsch ausgelesen und ggf. auch falsch gespeichert (neue Beiträge). Mit UTF-8 fährst Du da immer am besten.

Wenn Du UTF-8 verwendest, muss natürlich auch das Theme UTF-8 unterstützen, das heißt alle PHP-Dateien des Themes, in denen fest irgendwelche Texte für die Sidebar etc. stehen, müssen auch als UTF-8-Datei (ohne BOM) gespeichert werden. Das könntest Du mit einem guten Texteditor einfach selber konvertieren oder Du fragst mal beim Theme-Autor nach. Oder Du ersetzt die Umlaute einfach durch HTML-Entities.

Was der DB-Fehler soll, kann ich Dir auch nicht so genau sagen, aber irgendwie denke ich, wäre das eine Frage für Deinen Hoster. Es sieht so aus, als könnte er innerhalb der DB ein temporäres File nicht beschreiben.

Davon abgesehen solltest Du Dich mal darum kümmern, dass Deine Errorlogging-Einstellungen verbessert werden. Fehler wie dieser sollten eigentlich in ein Logfile geschrieben werden und nicht für jeden sichtbar auf der Seite ausgegeben werden. ;-)

Das sieht mir so aus, als wäre es im Theme falsch geschachtelt. Müsste sich in der comments.php des Themes eigentlich beheben lassen. Mal sehen...

Hm, liegt am Theme. Such mal diese Zeile, ganz am Ende der comments.php:

<?php endif; // If registration required and not logged in ?>

Und verschiebe sie weiter nach oben (Zeile 57 bis 60), so dass es so aussieht:

</div>
  <?php endif; // If registration required and not logged in ?>
  <!--comments area-->
  <?php if ($comments) : ?>

Achtung, ich habe es nicht getestet. Ggf. das Original aufheben, falls ich mich mit der Schachtelung der Klammern doch vertan habe. ;-)

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:

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.

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:

$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. ;-)

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. ;-)

Hallo!

Diese beiden Zeilen generieren die Navigation:

<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:

<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>

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?!

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:

<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. :-/

Bist Du sicher, dass es diese Info im Adminpanel gibt? Ich sehe in meiner 2.3.er-Installation nur den Autor, und der sollte beim Editieren eigentlich nicht geändert werden. Oder ist das in 2.5 jetzt anders?!

Verwendest Du Widgets für die Sidebar? Falls nicht steht das vielleicht einfach so in der sidebar.php Deines Themes drin, dass die Blogroll nicht auf Archivseiten angezeigt wird. Einfach mal da reinschauen.

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