Beiträge von Ammaletu

Hm, da wirst Du die Funktion wp_list_pages oder Teile davon überschreiben müssen. Kannst Du etwas genauer sagen, was Du mit dem Custom Field machen möchtest? Einfach hinter dem Seitentitel ausgeben?

Gut. Dann ist die Chance jetzt ziemlich groß, dass es an einem Plugin liegt, denke ich. Du kannst, bevor Du sie alle nach und nach abschaltest, auch mal in allen Plugindateien nach "get_attachment_link" suchen. Ich habe eben zufällig im Trac einen Eintrag gesehen, der diese veraltete Methode erwähnt. Wer weiß, vielleicht nutzt das ja eines Deiner Plugins noch.

Ich habe jetzt doch noch mal den Thread auf der wp-hackers rausgesucht:
[wp-hackers] Full size should mean full size

Als Begründung hat Matt angeführt, damit Usern helfen zu wollen, die Bilder von ihrer Digicam unkonvertiert hochladen (das meinte ich mit DAU *g*). Was IMHO nicht sehr clever ist, da die Bilder dann ja trotzdem 2 MB oder so groß sind und nur vom Browser kleiner dargestellt werden. Und wenn ich heute ein Theme mit 500px Breite nutze und morgen auf ein Theme mit 800px umsteige, steht in älteren Posts die Weite von 500px fest drin. Nicht wirklich durchdacht also...

Anyway, man kann seine eigene maximale Weite setzen, indem man in der functions.php seines Themes die Variable $content_width definiert (angeblich, ich habe es nicht probiert). So etwa z.B., einfach in die functions.php einfügen, außerhalb einer Funktion:

// set another maximum width for uploaded images
$content_width = 800;

Wenn man diesen Unfug nicht haben möchte, kann man da natürlich auch 5000 angeben oder so, dann sollten die Bilder bei Auswahl von "full size" auch immer mit der tatsächlichen Größe eingefügt werden.

Das Ticket, mit dem das umgesetzt wurde, ist übrigens hier zu finden:
#5777 (Constrain image size when adding to editor) - WordPress Trac - Trac

Also ich denke, das wäre mit JavaScript eine Sache weniger Minuten. Genauer gesagt mit der jQuery-Bibliothek. So könnte ich mir das vorstellen:

Du fügst nach den Feldern die Hinweise an die gewünschte Stelle ein und versiehst die div-Tags mit der Klasse "commentInfo".

Du definierst im JavaScript-File Deines Themes (wenn Du keines hast, lege es an und binde es in den Header des Themes ein, ggf. auch nur für Einzelansichten) eine jQuery-Methode, die beim Start der Seite ausgeführt wird:

/**
 * The following is jQuery functionality that will be executed as soon as the
 * DOM is ready (roughly equal to onload).
 */
jQuery(function($) {
  // hide comment info on page load
  $(".commentInfo").hide();
  // add event handler on comment form fields
  toggleCommentInfo();
});

Das versteckt schon mal beim Laden der Seite die Hinweise. Wer kein JavaScript aktiviert hat, sieht sie gleich.

Dann fehlen noch die Event Handler an den Formularfeldern. Hier gehe ich davon aus, dass das commentInfo-div mit im p-Tag steht. Ansonsten wäre das hier noch anzupassen.

function toggleCommentInfo() {
  $("#comment_form .text_input").click(function() { 
    $(this).parent("p").find(".commentInfo").show("slow");
  });
}

Das ist noch nicht sehr ausgefeilt, aber mit der jQuery-Doku kriegst Du das sicher auch selber beendet:
Main Page - jQuery JavaScript Library

Der Befehl müsste auch außerhalb des Loops funktionieren, Du kannst dann aber natürlich nicht einfach $id benutzen wie im Loop. Willst Du aber ja auch gar nicht, sondern Du willst ja ein Feld der Unterseite ausgeben. Dessen ID musst Du natürlich kennen.

Wie Du das in Deine Navigation integrierst, kann ich Dir jetzt so ohne Infos dazu schlecht sagen. Entweder suchst Du Dir selber die richtige Stelle heraus oder Du postest mal den Code der Navigation, dann kann ich ja mal schauen.

Deine Seiten werden als UTF-8 ausgeliefert, die Metaangabe fehlt aber und die Umlaute scheinen teilweise als ISO-8859-1 codiert zu sein.

Zuerst einmal solltest Du die Metaangabe ergänzen. Das hier bitte in der header.php Deines Themes am besten als erste Anweisung nach <head> einfügen:

<meta http-equiv="Content-Type" content="<?php bloginfo('html_type'); ?>; charset=<?php bloginfo('charset'); ?>" />

Das wird möglicherweise das Problem aber noch nicht lösen. Die zweite Frage wäre, ob Du im Backend auch UTF-8 als Codierung eingestellt hast (Einstellungen > Lesen > Zeichensatz für Seiten und Feeds) und was in Deiner wp-config.php für DB_CHARSET und DB_COLLATE steht (falls da etwas steht, es muss auch nicht).

Wenn das alles stimmt, müsste man im Theme mal schauen, wieso einige Dinge falsch herauskommen. Die Beitragstexte generell scheinen ja zu stimmen, während z.B. in der Linkliste und bei den Titeln statischer Seiten Fehler auftauchen. Wenn Du die entsprechenden Stellen weißt, kannst Du ja auch mal posten, welcher Code das ausgibt.

Ja, das ist eines von den ganz tollen, neuen Features von WP 2.5. Wieder mal angepasst an den DAU. :-/

Aber zum Glück kann man das umgehen -- ich kann Dir nur leider gerade nicht sagen wie. Es kann an mir liegen, aber ich finde einfach keine Informationen zu diesem Thema. Aber auf der WP-Hackers-Liste wurde das letztens erwähnt, dass man eine Konstante in seinem Theme setzen muss (glaube ich), welche die maximale Bilderweite enthält. Vielleicht weiß ja jemand anders hier weiter oder hat Zeit, im WP-Hackers-Archiv zu suchen?!

Wenn ich mich richtig erinnere, werden übrigens nicht die Bilder selber kleiner gemacht, sondern es wird nur im HTML des Postings eine kleinere Weite eingegeben (korrigiert mich falls ich mich irre). In dem Fall müsstest Du alle bisher erstellten Beiträge bearbeiten und die falsche Weite dort ersetzen. Und die Höhe auch, da diese ja sicher ebenfalls verkleinert wurde!?

Ich denke, dafür brauchst Du das Plugin gar nicht. Soweit ich weiß vereinfacht es ja auch nur den Zugriff auf die Custom-Fields ein wenig, aber man kann das auch mit WP-Bordmitteln ganz gut bewerkstelligen.

In meinem Theme greife ich auf die Felder z.B. so zu:

echo get_post_meta($id, 'mein-gewaehlter-feldname', true);

Die Variable $id ist dabei die ID des Postings, in Deinem Fall müsstest Du da die ID der Unterseite reinreichen. Dann halt den Feldnamen und true, wenn Du nur einen Wert erwartest (bei false kommt ein Array zurück).

Da wirst Du uns ein paar Infos zur Homepage geben müssen, vor allem, wie sie umgesetzt ist. Nutzt Du ein CMS und wenn ja welches? In den meisten CMS müsste man den RSS-Feed Deines Blogs eigentlich einbinden können, so wie das ja auch in WordPress mit dem RSS-Widget möglich ist.

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:
ä => &auml;
Ä => &Auml;
ö => &ouml;
Ö => &Ouml;
ü => &uuml;
Ü => &Uuml;
ß => &szlig;

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.