Beiträge von Ammaletu

Einzelbeiträge werden in den meisten Themes über die single.php angezeigt. Wenn Du den Kasten da einbaust, sieht man ihn aber auf jeder Einzelseite. Müsstest Du also schauen, dass es den Besucher nicht nervt, also nicht zu auffällig oder zu groß machen (hab's mir jetzt nicht angeschaut).

Das musst Du näher erklären, fürchte ich. Was willst Du übersetzen und welche "Übersetzungstools von WordPress" meinst Du?

Da würde ich einen Test vorschlagen, ob der Beitrag in der Kategorie ist oder nicht. So á la:

if (in_category(183)) {
  // category 183
} else if (in_category(184)) {
  // category 184
} else {
  // other category
}

Das ist jetzt mal nur improvisiert, ich hoffe, ich habe die Funktion richtig rausgefischt. Das wäre der Aufruf innerhalb des Loops oder auf einer Singleseite. Ansonsten müsstest Du den gewünschten Beitrag als zweites Argument mitgeben.

Finde zuerst mal raus, ob die betroffenen Elemente fest in einer Theme-Datei stehen (z.B. header.php) oder als Widgets umgesetzt sind. Und überlege dann, auf welchen Seiten sie stehen sollen und wie man das mit den WP-eigenen Conditional Tags ausdrücken könnte.

Ich vermute, da wirst Du in die Plugins schon reinschauen müssen. Sollte sich aber leicht finden lassen wenn Du mal nach "wp_head" suchst.

Die Inhalte verlierst Du dabei auf keinen Fall. Du müsstest eigentlich nur die Dateien der aktuellen deutschen Version über die jetzige Installation drüberkopieren, denke ich, und dann in der wp-config-Datei den Sprachkey einfügen:

// Hier kannst du einstellen welche Sprachdatei benutzt werden soll.
// Wenn du nichts einträgst wird Englisch genommen.
define ('WPLANG', 'de_DE');

Im Prinzip müsste es sogar reichen, die Sprachdatei nach wp-content/languages/ zu kopieren und diesen Key in der wp-config zu setzen. Soweit ich weiß, sind einige wenige Stellen aber auch in Core-Dateien übersetzt, die dann ggf. noch Englisch wären.

Du arbeitest vermutlich noch am Design, aber ich merke schon mal an, dass es im Moment nicht valide ist. Das führt vermutlich auch dazu, dass ich die Sidebar im FF 3.5 (Win XP) unter den Inhalten sehe statt daneben.

Ich habe gerade mal in den WP-Quelltext geschaut, um Unterschiede zwischen der normalen Ausgabe des Datums und der Ausgabe im Feed zu finden. So auf Anhieb sehe ich da hauptsächlich, dass bei der Feed-Ausgabe ein anderes Datum benutzt wird. Jeder Kommentar hat zwei Daten gespeichert in der Tabelle wp_comments: comment_date und comment_date_gmt. Vielleicht kannst Du ja noch mal einen Testkommentar anlegen und per phpMyAdmin oder so in die DB schauen, ob im comment_date_gmt etwa 0 drinsteht. Das würde das dann nämlich erklären.

Falls es das nicht ist, schaue ich mal genauer, wie die Daten verarbeitet werden. Falls doch, müsste man schauen, wieso der falsche Datumswert gespeichert wird. Du könntest eventuell auch mal schauen, ob sich was ändert, wenn Du den Kommentar im WP-Backend neu abspeicherst?

Ein generelles WP-Problem ist es jedenfalls eher nicht. In meinem Testblog tritt es z.B. nicht auf.

Für alle anderen, die Erklärung steht hier:
http://www.one-theme.com/support/using-…ls-problem.html

Offenbar legt das Plugin Tabellen an, welche Dir möglicherweise bei einem Umzug verloren gegangen sind?! Der Name der Tabellen steht wohl in einer WP-Option drin. Wenn die gelöscht wird, legt das Plugin die Tabellen neu an.

Was Du also suchen musst sind nicht die WPPT-Tabellen (die fehlen ja scheinbar?), sondern den Eintrag in der wp_options-Tabelle, der mit "wppt_" beginnt. Falls die Tabelle sehr viele Optionen enthält, musst Du ggf. auf weitere Seiten blättern (je nachdem womit Du auf die Datenbank zugreifst natürlich auch).

Also ich würde Dir erstmal raten, das nicht mit dem Feed-Reader zu testen sondern mit dem Feed selber. Dieser ist ja nichts weiter als eine XML-Datei, und das Datum steht da jeweils gut lesbar drin. Der letzte Eintrag im Feed ist vom Freitag, und alle Kommentare dort haben das korrekte Datum. Wenn überhaupt kann das auch nur ein Ausgabeproblem sein, da der Feed ja an sich nur die x neuesten Kommentare enthält. Wenn das also überhaupt ein WP-Problem ist, dann nur bei der Ausgabe des Datums, nicht beim internen Handling.

Solange wir das Problem aber nicht sehen können, ist es etwas schwer, etwas dazu zu sagen. Ähm, ich hoffe, Du hast nichts dagegen, aber ich habe jetzt einfach mal einen Testkommentar veröffentlicht (kannst Du sofort wieder löschen). Und ja, das Datum taucht tatsächlich so im Feed auf:

<pubDate>Thu, 01 Jan 1970 01:00:00 +0000</pubDate>

Tja, also... Ich fürchte, man müsste mal in den Quelltext schauern, in die Klasse oder Datei, die das zusammenbaut. Vielleicht sieht man dann schon, woran es liegt. Muss ich aber mal schauen, ob ich da heute noch Zeit zu habe.

Die Systemzeit an sich scheint jedenfalls zu stimmen und auch in der DB muss es eigentlich richtig stehen, denn auf der Webseite wird ja das korrkte Datum des Kommentars ausgegeben.

35 MB sollten wirklich dicke reichen für WordPress. Du kannst ja mal das "Memory Usage"-Plugin installieren und schauen, ob WP im Normalbetrieb schon an der Speichergrenze kratzt. Ob das Posten über externe Programme mehr Speicher als der normale WP-Aufruf benötigt, weiß ich nicht, käme mir aber komisch vor. Ausnahme wäre vielleicht höchstens, wenn Du in den Beiträgen riesige Bilder mitschickst. Hast Du denn bei Deinen Versuchen Bilder drangehangen?

Hat sich das Problem zwischenzeitlich erledigt? Im Moment enthält der Feed ja die korrekten Daten.

is_home ist true auf der Blog-Startseite, welche die aktuellesten Posts anzeigt. Für eine statische Startseite gibt es is_front_page(). Siehe: http://codex.wordpress.org/Conditional_Tags

Wenn die ganze Sidebar weg soll, müsstest Du die sidebar.php des Themes bearbeiten. Wenn nur einzelne Elemente weg sollen, wäre es am besten, wenn Du ein widgetfähiges Theme benutzt, dann kannst Du das im Backend unter Design > Widgets einstellen.

Die Frage ist doch, was soll Dein Code tun und wann soll er aufgerufen werden?

Zitat

Hat einer von euch noch eine Lösung für mich?

Der nächste sinnvolle Schritt wäre es IMHO, im Error-Log nachzuschauen, was der eigentliche Fehler ist. Error 500 ist nur ein Sammelbegriff für alle möglichen Fehler. Ohne eine genaue Fehlermeldung, wie sie normalerweise in einem Logfile landen sollte, kann man nur raten, und das führt selten wirklich zum Ziel.

Zitat

"Streambox" per "Copy 'n paste" - Ja hab es so eingefügt aber wieso wird es in internet explorer richtig gezeigt?

Weil der IE viele Sachen lascher handhabt als der Firefox und andere Browser. Deshalb sollte man auch auf einem standardkonformen Browser entwickeln und dann hinterher schauen ob es im IE geht (und bei Bedarf Fixes speziell für den IE einbauen). Andersrum ist witzlos. ;-)

Außerdem sorgen die vielen Bugs des IE manchmal auch dafür, dass etwas richtig angezeigt wird, obwohl es eigentlich kaputt ist.

Zitat

Ammaletu -- falsch geschachtelt ?

Ja, es wird ein div-Tag geschlossen, welches nicht geschlossen werden sollte. Soweit ich das sehe, hast Du ganz rechts zwei Text-Widgets. Oben sind zwei Videos drin, unten die Streambox, richtig? Das obere Widget enthält ein schließendes div, obwohl gar kein öffnendes div drinsteht. Das bringt die ganze Sidebar durcheinander. Wäre das Theme an sich valide, hätte der Validator Dir jetzt zwei, drei Fehler angezeigt und man wüsste sofort, wo der Fehler liegt. Bei 93 größtenteil völlig unnötigen Fehlern im Theme muss man sich das einzeln aus dem Quelltext raussuchen.

Ok, also nochmal: Wenn Du aufrufst /unterordner/datei-die-existiert, sollte das auch mit der jetzigen Konstruktion schon gehen. Genauso für /unterordner/noch-ein-ordner-der-existiert oder direkt /unterordner. Was nicht geht ist /unterordner/datei-die-existiert/url-parameter, wo dann der URL-Parameter ähnlich wie die Permalinks von WordPress ausgewertet wird, z.B. über eine weitere .htaccess. Aus Sicht von Apache ist das dann keine existierende Datei und der Aufruf geht an WordPress weiter, wo er im 404 mündet (und ich nehme mal an, dass eine 404-Fehler von WordPress das ist, was Du ursprünglich beschrieben hast).

Oben vorgeschlagene Lösung sorgt dafür, dass die WP-Rewrite-Regel nicht angewendet wird, wenn der Aufruf in das zu schützende Unterverzeichnis führt. Das würde WP überschreiben, wenn Du die Permalink-Einstellungen neu abspeicherst, was man ja aber normalerweise nicht so oft macht. Mit etwas mehr Kenntnis der .htaccess-Regeln kann man das auch sicher so schreiben, dass man es in der .htacces außerhalb des WP-Blocks angeben kann,dann lässt WP das auch in Ruhe.

Und was ich vermutlich gleich hätte fragen sollen: Du versuchst jetzt aber nicht, einen Teil von WP damit zu schützen, also z.B. eine Kategorie oder so, oder? Es geht um externe Dateien, die mit WP nichts zu tun haben und nur zufällig in einem Unterordner innerhalb von WP liegen?

Die Tabelle wp_wppt_preset ist keine Standard-WP-Tabelle. Finde doch erstmal raus, zu welchem Plugin die gehört. Passt "wppt" als Abkürzung zu einem Deiner Plugins oder zu Deinem Theme? Ansonsten poste doch bitte mal eine Liste aller Plugins, die Du verwendest.

Hat sich zwischenzeitlich erledigt? Ich sehe keinen Fehler.