Beiträge von Ammaletu

Also die Version mit dem Loop, den Du nach zwei Posts quasi abbrichst, ist schon ganz gut. Als Verbesserung schlage ich vor: Nur die ersten beiden Posts aus der DB auslesen. Dafür den Loop so modifizieren (ganz oben, auf jeden Fall vor if have_posts):

$posts = query_posts($query_string . '&showposts=2');

Soll der Link dann auf den vorletzten Beitrag zeigen oder auf eine Seite, die alle Beiträge ab dem vorletzten enthält? Für ersteres kannst Du im Loop ganz einfach the_permalink() nutzen, das baut Dir einen korrekten Link auf den Post, egal wie Deine Permalinkstruktur aussieht.

Zu Problem Nummer zwei (Am Ende eines Jahresarchivs auf den Beginn des vorherigen Jahres verlinken): Naja, Du verlinkst halt einfach auf das entsprechende vorherige Jahresarchiv. Ähm, mal kurz im Codex gesucht... Das sollte so aussehen:

$year = get_the_time('Y');
get_year_link($year - 1);

Die Jahresarchive kannst Du bei Bedarf auch andersherum sortieren. Normalerweise würden ja die neuesten Beiträge oben stehen (also absteigend sortiert). Wenn Du es gerne aufsteigend hättest kannst Du auch hier die Query modifizieren:

if (is_year()) {
  $posts = query_posts($query_string . '&order=asc');
}

Das würde jetzt nur die Jahresarchive umdrehen, so einfach oben in die archive.php schreiben (nicht archive*s*.php, die macht was anderes, falls Dein Theme die überhaupt hat).

Sicher, Du kannst im Code natürlich auch auf den Parent des Parents testen. Wenn die Seite keinen weiteren Parent hat, müsste sie ihre eigene ID als Parent-ID zurückliefern, soweit ich weiß (aber teste mal, ist ein Weilchen her dass ich das gesehen hatte im Code).

Das wird natürlich wirklich unhandlich, wenn Du die Seiten noch weiter schachteln willst. Für drei Ebenen kann man das vermutlich gerade noch machen...

Mir fällt dazu nur eine Sache ein: Wenn Du Akismet nicht installiert hast, siehst Du alle als Spam markierte Kommentare nicht in der Kommentarverwaltung. Die sind trotzdem in der DB, aber es gibt die entsprechende Sektion unter "Kommentare" einfach nicht. Plugins wie Spam Karma bringen ihre eigene Verwaltung mit, aber die ist dann nicht unter "Kommentare" zu finden, soweit ich weiß.

Falls es das nicht, könntest Du uns ja mal die WordPress-Version verraten. Vielleicht fällt dann noch jemandem was ein. Ich wüsste aber nicht so richtig, wie ein Kommentar, was auch immer mit ihm sein mag, die Benachrichtigungen für andere Kommentare blockieren könnte!? Hast Du mal ins Fehlerlog Deines Servers geschaut (falls PHP-Fehler geloggt werden bei Dir)? Vielleicht steht da ja auch was Hilfreiches drin.

Ich kenne das Plugin nicht, aber bist Du sicher, dass Dein Server die nötigen Voraussetzungen erfüllt? Das "Zend" in der geposteten URL sowie der Name der fehlenden Funktion lassen mich vermuten, dass hier PHP-Features verwendet werden, die nicht direkt Standard sind. Deine PHP-Installation ist also vielleicht zu alt dafür oder Dir fehlt ein bestimmtes Modul. Die Doku des Plugins enthält hoffentlich nähere Infos dazu.

Also für das PDF-File bräuchtest Du ein iFrame, dann sollte das in den meisten Browsern gehen. Ich halte das allerdings eher nicht für sinnvoll, denn dann ist das PDF da auch eingesperrt und der Nutzer muss ggf. horizontal scrollen. In einem neuen Fenster öffnen finde ich da in aller Regel benutzerfreundlicher.

Was WordPress und bbPress betrifft: Du kannst das Forum natürlich ebenfalls in einem iFrame aufrufen, von einer statischen Seite mit einem Seiten-Template aus zum Beispiel. Schöner ist sicher, beide Seiten richtig zu integrieren, auch wegen Logins etc. Das sollte ja eigentlich gehen, ich habe da aber leider keine Erfahrungswerte anzubieten. Hast Du mit der Forumssuche hier nichts Brauchbares gefunden?

Noch mal zum Thema Tiefe der angezeigten Parameter: Ich habe gerade eben im Codex gelesen, dass der depth-Parameter an wp_list_categories erst mit Version 2.5 ergänzt wurde. Deswegen funktioniert das bei meiner 2.3.3 auch nicht. Und wie ich sehe nutzt Du ja auch noch 2.3.3. Sorry also für den nicht korrekten Hinweis, das hätte ich früher sehen können. Das kommt davon, wenn man die Doku nur überfliegt. Wenn Du auf 2.6 upgradest, sollte es wie gepostet funktionieren.

Zitat

Warum es bei mir zu Fehlern führte: ich habe ein Buzzword gesetzt, welches ein Apostroph ( ' ) enthielt. Bei PHP eigentlich reichlich blöd von mir...

Also das sehe ich eigentlich ganz anders: Falls es nicht ausdrücklich in der Dokumentation des Plugins erwähnt ist, ist das eher "reichlich blöd" vom Plugin-Autor. Don't trust user input, das ist doch eine der Programmier-Grundregeln. Mich würde das eher von der weiteren Verwendung des Plugins abschrecken ehrlich gesagt, aber Du solltest das auf jeden Fall dem Plugin-Autoren mal schreiben.

Also wenn es Dir nicht um die DB-Inhalte geht, sondern nur um Theme-Dateien, tut es eigentlich jeder gute Texteditor (zumindest kommt UltraEdit mit einer genialen "In Dateien suchen"-Funktion daher). Zur Not hat sicher auch Dein Betriebssystem eine Suchfunktion an Bord. Oder muss das Ergebnis in WordPress zur Verfügung stehen? Was genau willst Du denn machen?

Wenn man mal in den Quelltext Deiner Seite schaut, sieht man dort Folgendes:

<div class="post_content">
<link rel='stylesheet' type='text/css' href='/wp-content/plugins/buzzwords/css/prototip.css' />
        <script type='text/javascript' src='/wp-content/plugins/buzzwords/js/prototype.js'></script>
        <script type='text/javascript' src='/wp-content/plugins/buzzwords/js/prototip.js'></script><br />
</div>

Da sollte sicher der Beitragsinhalt stehen statt dessen. Ist "Buzzwords" zufällig ein Plugin, das Du kürzlich aktiviert hast? Falls ja, deaktiviere es mal. Ich nehme an, dass es einfach nicht korrekt funktioniert. Eventuell ist es ja nicht WP-2.6-kompatibel. Der CSS-Link hat an der Stelle jedenfalls nichts zu suchen, sowas gehört in den Header. Die Javascript-Dateien eigentlich auch.

Relativ verlinken kannst Du ganz einfach, wenn Du weißt, unter welcher Adresse die Zielseite veröffentlicht ist. Dann einfach Links wie "zielseite", "../zielseite" oder "parent/zielseite" eingeben.

Was spricht ansonsten gegen absolute Links? In den Postings solltest Du die Beiträge sowieso absolut verlinken, da nicht jeder Feed-Reader mit relativen Links etwas anfangen kann. Und wenn Du die DB mal lokal installieren willst zum Testen, kann man die Domain im DB-Dump sehr leicht ersetzen.

Wenn nicht irgendein SEO-Plugin Dir die Titel umschreibt, steht das in Deinem Theme drin. Schau dort mal in die header.php, dort kannst Du das auch ändern.

Zeilenumbruch sollte egal sein, aber ich denke, es müsste zwischen "IE" und die Versionsnummer ein Leerzeichen. Die Syntax wird hier beschrieben:
About Conditional Comments

Die geposteten Beispiele sehen ansonsten korrekt aus und funktionieren auf meiner eigenen Seiten auch so ähnlich. fredmansky, hast Du das aus der verlinkten Seite wieder entfernt? Ich sehe dort keine conditional comments im Header. Ich denke, live an der Seite lässt es sich am einfachsten sagen, wieso es ggf. nicht funktioniert.

Vielleicht erklärst Du für alle, die mit Begriffen wie "Loot" und "Wow Items Link" nichts anfangen können, erstmal worum es überhaupt geht. Dann sind Deine Chancen auf eine sinnvolle Antwort sicher höher.

Wenn das ganze auf einer irgendwie öffentlichen Schnittstelle/API basiert, wäre ein Link dazu ebenfalls hilfreich.

Also soweit ich weiß geht folgendes:

/?cat=1,3

Das bringt allerdings wahrscheinlich alle Beiträge in Kategorie 1 oder 3. Vermute ich jedenfalls, müsstest Du aber mal testen. Ob es auch eine Variante gibt, die Dir nur die Schnittmenge liefert, weiß ich nicht. Wenn Du das nur für eine spezielle Abfrage brauchst, kannst Du Dir ein Template dafür bauen und über eine statische Seite anzeigen lassen, denke ich. Für eine ganz allgemeine Lösung bräuchtest Du aber wahrscheinlich eine eingebaute Lösung. Eventuell müsstest Du da mal in den Quelltext von WordPress schauen, was da intern so passiert. Aber vielleicht geht es ja so auch schon.

Wenn das tatsächlich alles ist, was im Errorlog steht, weiß ich auch nicht so genau, woran es liegt. Da es mit dem Default-Theme funktioniert, wird es wohl an Deinem Theme liegen und nicht an einem Plugin. Stimmen die Rechte für Deine Theme-Dateien? Hast Du das Theme modifiziert oder kann man das irgendwo downloaden?

Ich denke, das liegt an folgendem: Die Funktion ini_get() ist bei Dir ausgeschaltet, aus Sicherheitsgründen. Keine Ahnung, ob das Sinn macht oder nötig ist, aber wenn es nicht Dein eigener Server ist, kannst Du das vermutlich nicht ändern. WordPress ruft die Funktion aber auf, was eine Fehlermeldung generiert. Auf einem gut eingerichteten System würde diese einfach ins Logfile geschrieben und dann würde WordPress vermutlich weiter machen. In Deinem Fall wird die Fehlermeldung aber am Bildschirm ausgegeben. Wenn dann kurz danach eine andere WordPress-Datei versucht, einen Header zu ändern, geht das nicht, weil durch die Fehlermeldung der Header schon abgeschickt und der Body der Antwort angefangen wurde.

Kurzum, Du könntest Deinen Provider mal fragen, warum ini_get() nicht verfügbar ist und ob sie das ändern können. Davon abgesehen wäre es hilfreich, Dich etwas mit PHP-Logging zu beschäftigen und das System so einzurichten, dass Log-Meldungen nicht am Bildschirm ausgegeben werden. Das sollte dieses Problem auch beheben, da ich nicht glaube, dass WordPress direkt von ini_get() abhängt. Das geht sicher auch ohne. Gegebenenfalls kann Dir das auch Dein Provider einrichten, frag einfach mal nach.

Wenn es Dein eigener Server ist, schau mal, dass Du das Log-Level höher stellst bzw. Debug-Ausgaben anstellst. Und wenn nicht wäre das eine Frage für den Support Deines Providers, denke ich. Vielleicht können die ja MySQL auch mal aktualisieren. Wie gesagt, bei meinem Provider läuft seit einiger Zeit die 5.0.51.

Geht es dabei um ein Widget, das bei WordPress standardmäßig dabei ist, oder stammt das aus einem Plugin? Die Standard-Widgets sollten solche Probleme ja eigentlich nicht verursachen, und die SQL-Abfrage sieht auch nicht problematisch aus. Andererseits haben manchmal auch einzelne Versionen von MySQL Bugs, die dann in der nächsten Version wieder behoben sind. Ich erinnere mich noch an den netten Bug, der dafür gesorgt hat, dass plötzlich die Beiträge in WordPress aufsteigend anstatt absteigend sortiert wurden. So gesehen könnte es an 5.0.45 liegen und vielleicht mit neueren Versionen schon behoben sein. Ich habe mal geschaut, mein Provider setzt 5.0.51 ein im Moment.

Wenn Du das Kalender-Widget nicht brauchst, ist es fürs erste vermutlich das beste, es einfach nicht einzusetzen. Du kannst es ja wieder probieren, wenn Dein Provider irgendwann MySQL mal aktualisiert. Ansonsten immer schön DB-Backups machen, für alle Fälle.

Ich habe mal nach der Fehlermeldung gegoogelt und finde da irgendwie unklare Bug-Reports. Mit welcher MySQL-Version arbeitest Du denn? Eventuell hilft Dir ein Upgrade auf ein neueres MySQL weiter.

Naja, der entsprechende Code ist weiter oben doch schon gepostet. Du kannst ihn ja auch gerne mal mit dem aus dem Default-Theme vergleichen. Wenn es dann immer noch nicht geht, macht Dein Theme irgendwas anderes noch. Es modifiziert vielleicht die aktuelle Query nicht korrekt oder so. Das kann Dir aber niemand sagen, ohne das Theme zu kennen. Ist es ein Theme, das online zu finden ist? In dem Fall könntest Du ja mal einen Link posten.