Loop: Manche Postings nicht zeigen - trotzdem korrekte Anzahl Postings erreichen?

Ich komme aus dem grübeln und vor allem dem staunen nicht heraus:

Ich grübele:
- ich möchte gerne (und zwar sowohl im index.php als auch im Search, Archiv,...) bestimmte Postings nicht im Standard-Anzeigebereich anzeigen.
- Da sagt man sich: Ist ja einfach! Einfach im Loop ein "if" einbauen und schon werden die nicht gezeigt.

Stimmt auch - und es wird in der Dokumentation und auch in vielen Postings hier im Forum genau so beschrieben und als Lösung für viele Probleme empfohlen.

Und nun staune ich:
- Denn offenbar ist kaum jemandem aufgefallen, dass durch so ein "if" die Gesamtanzahl der Postings auf einer Seite reduziert wirde!
- Ist also eingestellt, dass 10 Postings gezeigt werden soll und man filtert über die if-Bedingung 3 Postings heraus, dann werden nur noch 7 Postings gezeigt.
- Sollte die if-Bedingung 22 Postings in Folge betreffen, so sind zwei leere Seiten vorhanden die erstmal vom Besucher überblättert werden müssen...

Das will ich natürlich nicht ;)

Nun habe ich schon gelesen, dass man mit get_posts auch Kategorien ausschließen kann - das hilft mir allerdings nicht, weil die auszuschließenen Postings in mehreren Kategorien vorkommen können. Das sind zwar alles Unterkategorien einer Hauptkategorie, aber diese Hauptkategorie auszuschließen hilft ja nicht.

Die Frage ist also klar:
- Wie kann ich innerhalb des Loops bestimmte Postings herausfiltern und dennoch die korrekte Anzahl von Postings auf einer Seite erreichen?
- Natürlich so, dass ein "<-- vorher / weiter -->" blättern durch die Seiten weiterhin möglich ist?

Geht das überhaupt?

Hey, vielen Dank!

Frage:
- Geht das auch temporär? Also wenn ich z.B. 2 Loops im Index oder Archiv habe dann möchte ich einmal mit der einen und dann mit einer anderen Bedingung filtern. Kann ich also so ein Plugin je nach Loop an/abmelden?

Die Alternative ist, den Loop selbst mit einem SQL zu füllen. Da bin ich auch schon am probieren und das klappt soweit ganz gut - im Index.

Wenn ich so etwas für archiv.php oder die Suche machen wollte frage ich mich allerdings wie ich an die FROM und WHERE Klausel heran komme um diese dann zu tweaken... Damit wären wir wieder bei dem vorgeschlagenen Plugin - nur auch hier brauche ich verschiedene Loops und somit verschiedene Where/From-Klauseln....

Hm - mal abgesehen davon, dass man das auch für die FROM und ggf. die ORDER Klausel tun müsste...

...läuft der Aufbau des Statements nicht bevor man überhaupt an der Stelle im Quellcode ist an dem der Loop läuft?
Sprich: Kann ich im archive.php oder index.php etc. überhaupt noch eine globale Variable setzen die sich auf dieses Plugin auswirken würde?

Weil: WENN das ginge, dann müsste es doch auch andersherum funktionieren!
Also quasi ein Plugin für FROM, WHERE, ORDER oder was weiß ich nicht alles bauen das nichts anderes tut, als diese Stücke in Klammern zu setzen und an eine eigene globale Variable zu übergeben.
Im Template selbst könnte man dann auf seine eigenen Variablen zugreifen um etwas zu tun wie:

"select " . $mySelect .", blabla from " . $myFrom . ", noch eine Tabelle where " . $myWhere .... etc.

oder gibt es solche globalen Zugriffe für die Select-Stückchen bereits?

Zitat von jottlieb

The Loop « WordPress Codex
Hier zufällig was passendendes dabei? Das hab ich beim rüberfliegen was mit Continue gesehen...

Du meinst das hier:

<?php if (in_category('3')) continue; ?>

das besagt nur, dass die While-Schleife weiterlaufen soll wenn der Loop auf einen Artikel in cat=3 stößt (anstatt den Inhalt der Schleife abzuarbeiten wird also sofort zum nächsten Eintrag gesprungen)

Das hilft leider nicht (den Codex-Artikel habe ich schon vor Tagen durch :))

Hintergrund: WordPress arbeitet intern ja auch mit der LIMIT-Klausel um eben so-und-soviel Datensätze zu cachen um diese dann dem Loop zur Verfügung zu stellen. Was immer Du also IM Loop herausfilterst führt dazu, dass weniger Artikel auf der Seite gezeigt werden.

Einzige Lösung ist daher, dass schon das SQL-Statement die Daten herausfiltert bevor man in den Loop kommt.
Für einfache Fälle geht das auch mit Bordmitteln (z.B. um eine Kategorie auszuschließen oder nur ein paar bestimmte Kat. zu lesen)

Für Komplexere Dinge geht das so aber nicht. Da muss man schon sein eigenes SQL abschicken - oder, siehe oben, über eine Plugin-Lösung arbeiten.
Nur fehlt mir noch das Wissen darum, ob man - BEVOR das Plugin gerufen wird - in seinem Template etwas einstellen kann was dann die Aktion im Plugin beeinflusst. Also im Template sagen: "Achtung Plugin! Wenn Du gleich gerufen wirst - es geht hier um den Loop A und nicht um den Loop B!"

Inzwischen würde es mir allerdings schon genügen, wenn ich an die einzelnen SQL-Stückchen im Template herankäme. Wenn ich also im Grunde das Original-Statement selbst mit Variablen zusammensetzen könnte - nur dass ich vorher im Template selbst noch ein paar Erweiterungen (hier ein AND, dort ein JOIN...) mit einbaue....

Gibt es da nicht irgendwelche globals auf die man zugreifen könnte?

OK, ich komme vermutlich mit einem eigenen Loop doch weiter als vermutet. Bessere Tipps sind natürlich dennoch gerne gesehen.

Für alle anderen, die evtl. über eine Suche diesen Thread gefunden haben, hier eine kurze Info woran ich arbeite.

- Ich brauche mehrere Loops auf einer Seite. Sowohl im index.php als auch im archive.php und search.php
- Diese Loops sind keine Dinge die durch ein simples "nicht diese Kategorie" gelöst werden können da ich z.B. auf Tabellen von anderen PlugIns prüfen möchte. Es muss also mal ein zusätzlicher JOIN, manchmal eine zusätzliche Tabelle im FROM und die WHERE-Bedingung angepasst werden.

Mein Ansatz:
1.) den Loop selber aufbauen mit einer eigenen SQL-Abfrage. Das steht im Codex und geht ungefähr so:

$pagelimit=10;
        $page = (get_query_var('paged')) ? get_query_var('paged') : 1;
        $pagenum=($page-1)*$pagelimit;


         $pageposts = $wpdb->get_results("SELECT wposts.* FROM $wpdb->posts wposts, ....was_ihr_noch_so_braucht...
                WHERE ...Eure_Bedingungen...
                AND wposts.post_status = 'publish' AND wposts.post_date < NOW() 
                AND wposts.post_type = 'post'
            ORDER BY wposts.post_date DESC
            LIMIT ".$pagenum.", ".$pagelimit, OBJECT);

Einfach im Codex nach "get_results" oder "custom query" suchen.

2.) um nun zu sehen, welches SQL WordPress normalerweise absetzt (zum lernen und anpassen der eigenen Query) gibt eine globale Variabe "$request"
Zum anzeigen einfach mal folgendes einbauen:

global $s, $request;
        echo "<br/>".$request;

Für die Suche gibt es noch ein globales "$s" mit dem Suchbegriff
Für die Archivseiten gibt es haufenweise globale Variablen die einem sagen, welches Jahr/Monat/Tag/Autor/... geklickt wurde ($cat, $author, $m, $year, $monthnum, $day)

Damit kann man schon ganz schön eine eigene Query zusammensetzen.

Bleibt noch das Problem, dass man u.U. ja alle Postings aus einer gewählten Kategorie UND die Postings aus allen UNTERkategorien haben möchte.

3.) das geht mit der "IN"-Klausel von SQL. Testet mal die $request Ausgabe (s.oben) mit einer Kategorie-Seite - da seht ihr wie das benutzt wird.
Um an alle IDs der Unterkategorie zu kommen klappt folgendes:

$cat_children = $cat.', '.get_category_children($cat, '', ', '); /* für eine Liste aller children einer Kategorie (für SQL "IN"-clause) */
        $cat_children = substr($cat_children, 0, -2); 
        echo "<br/>category_parents: ".$cat_children;

Hm... das sollte das wichtigste gewesen sein. Sobald ich wieder etwas Zeit habe versuche ich das alles mal in mein Template einzubauen. Dann sehe ich ja was mir noch fehlt :D

...ach ja:
4.) Mit der Standardnavigation klappt das so alles nicht mehr. Die bezieht sich nämlich immer auf den standard-loop den ich ja gar nicht mehr verwende. Ist aber kein großes Problem da ich sowieso eine schönere Navigation (Seitenzahlen) haben wollte. Ich habe dafür also eine eigene Funktion geschrieben - bzw. eine vorhandene angepasst!
Sucht einfach nach einem "Pagenavi"-Plugin das Euch gefällt und erweitert es im Aufruf um einen Parameter um EUER SQL-Statement zu übergeben (anstatt dass die Funktion mit $request arbeitet soll sie mit eurem sql arbeiten).

OK - ich hoffe das hilft noch anderen...