Content-Dump 0.7 - Präfix-Nutzung, Filterfunktion, Hierachie-Kontrolle

[nhaack]

Hallo zusammen,

Zeit für ein weiteres Update des Content_dump Plug-ins . Diese Version stand ganz im Zeichen der Automatisierung und Flexibilität. Es hat sich wieder einiges unter der Haube getan und so sind vier weitere Parameter hinzugekommen.

-  Plug-in: http://dev.cmsmadesimple.org/project/files/564
-  Bugtracker: http://dev.cmsmadesimple.org/bug/list/564
-  Wiki-Help: http://wiki.cmsmadesimple.org/index.php/User_Handbook/Admin_Panel/Tags/content_dump

Nach spezifischen Block-Inhalten filtern.

Mit Hilfe des Parameters filter="text" kann in boolscher Logik der Inhalt der data-Felder nach bestimmten Wörtern/Texten durchsucht werden. filter="world" z.B. gibt nur Einträge in denen das Wort "world" in den Blöcken des Dumps vorkommt zurück. filter="-hello" nimmt z.B. alle Ergebnisse die "hello" enthalten aus dem Dump heraus. Nicht Case-Sensitiv.

Code: Select all

 {content_dump filter="world -hello"} 

ACHTUNG: Dieses Feature ist nur für mutige, da der DB table prefix_content_props um einen Index erweitert werden muss. Wenn du nicht genau weißt, was das bedeutet und welche Folgen dies hat, dann nutze dieses Feature lieber nicht. 

Die Änderung wird wie folgt vorgenommen:

Code: Select all

 ALTER prefix_content_props ADD FULLTEXT (content)

Mit dieser Funktion können z.B. Tag-basierte Inhalte für adaptive-Sites ausgewählt werden. Ein Beispiel: Jemand hat angegeben, er/sie mag Hunde lieber als Katzen, also befinden sich im Dump nur Artikel in denen das Wort Hund vorkommt.

Oder es können z.B. Seiten-Weite Beiträge zum Thema "Kochen" in einem RSS Feed oder dynamischen Themen-Index-Seiten gebündelt werden.

Es werden aktuell lediglich Content-Blöcke durchsucht (alle mit "block_name" und "extensions" genannten) - Title, Alias und Menu-Title werden im Moment nicht durchsucht - die Suche ist nicht auf einen einzelnen Blocknamen begrenzbar.

Handling von Alias-Prefix

Es besteht die Möglichkeit einen oder mehrere Alias-Prefixe zum filtern zu verwenden. Mit dem Parameter prefix="prefix1,prefix2" können diese bequem übergeben werden.

Code: Select all

 {content_dump prefix="privat_,setup_"} 

Mit dem Parameter prefix_mode kann bestimmt werden, wie die prefixe behandelt werden sollen. normal = keine Beachtung; force = nur Seiten mit passendem Alias-Prefix anzeigen; hide = Seiten mit passendem Alias-Prefix ausblenden.

Code: Select all

 {content_dump prefix_mode="force"} 

prefix_mode und prefix sollten gemeinsam verwendet werden.

Mit Hilfe des Prefix-Handlings können z.B. in Verbindung mit Custom-Content für registrierte Besucher zusätzliche Blog-Einträge angezeigt werden (für nicht-registrierte Besucher einfach per {content_dump prefix="geheim" prefix_mode="hide"} ausblenden. Registrierte Besuchen sehen mit {content_dump} alle Einträge.

Hierarchie-Begrenzungen

Mit dem depth-Parameter können dem Plug-in zwei Werte zur Eingrenzung der Hierarchie-Ebenen übergeben werden (z.B. depth="-1,2"). Es handelt sich hier um zwei Integer-Werte durch Komma getrennt.

Der Erste Wert gibt die Start-Ebene an. -1 = Start-Ebene ist automatisch Ebene von Content_Dump Start_id; 0 sowie 1 = Content_dump beginnt mit der ersten Ebene (Start-ID sticht Depth - mit Depth kann die Auswahl nicht vergrößert werden); n = Anzahl der Start-Ebene.

Der zweite Wert gibt die Anzahl der zusätzlichen Ebenen an. 0 = Nur Startebene wird von Content-Dump beachtet; n = Anzahl der zusätzlichen Ebenen (relative Tiefe)

z.B:

Code: Select all

Ab absolut erster Ebene - Drei Ebenen Gesamttiefe:
{content_dump depth="0,2"}

Ab Content-Dump erster Ebene - nur eine Ebene :
{content_dump depth="-1,0"}

Ab absolut zweiter Ebene - Drei weitere Ebenen:
{content_dump depth="2,3"}

Dieses Feature ist besonders Praktisch wenn zur Identifizierung keine dedizierten Content-Blöcke zur Verfügung stehen (oder immer das gleiche Template verwendet werden soll). Das genaue Fenster in der Hierarchie kann hiermit bestimmt werden. Dabei kann dieser Tag die bisher bestehende Auswahl nicht erweitern (start_id liegt z.B. auf Level 2, per Parameter depth soll aber auch Level 1 geprüft werden.).

Sonstiges

Ansonsten hat sich an der Daten-Struktur nichts geändert, das Plug-in sollte also gefahrlos (bzgl. eurer Smarty-Logik) Upgrade-Fähig sein. Ich freue mich auf euer Feedback und eure Anregungen - bitte gefundene Bugs melden

Beste Grüße
Nils

[cyberman]

Wieder eine klasse Arbeit - danke für diese "Schweizer Messer".

Das Problem bei solchen Multi-Funktionswerkzeugen ist halt nur, dass die wenigsten darauf kommen, was man damit alles anstellen kann ...

[nhaack]

Danke für die Blumen

wobei du schon recht hast, es wird nicht von vielen verwendet, dabei lassen sich ein paar kleine schnelle Leckereien mit dem Plug-In realisieren. Deshalb bin ich ja auch oft mit umfangreichen Erläuterungen zur Stelle (wenn jemand es gebrauchen kann) und habe die Wiki-Page zum Plug-in mit Wissen vollgestopft.

Wobei ich muss sagen, als Entwickler ist eine kleine Benutzergruppe gar nicht so verkehrt. Der Austauch ist u.U. intensiver und die Verantwortung nicht ganz so hoch. Nicht das ich schlampigen Code abliefern will aber bei einem Plug-in das auf 15.000 Sites zum Einsatz kommt ist der Druck als Freizeitentwickler dann doch etwas höher.

Auch richtet sich das Plug-in eher an fortgeschrittene CMSMS User die den Automatisierungs-Grad ihrer Site erhöhen wollen und so etwas spezielles suchen - zudem ist der Funktionsumfang dem CGFeedmaker und CGSimple Bundle nicht unähnlich. Ich denke Content-Dump ist also trotz der Flexibilität eher ein spezielles Nischen-Plug-in.

Naja, mal gucken was die nächsten Versionen von Content_Dump bringen. Einen Zugriff auf Modul-Inhalte wird es allerdings definitiv nicht geben. Der Schwerpunkt bleibt die Erstellung von Sammlungen aus Site-Content für die Site.

Ein Ausblick auf die Roadmap:

0.7.1 - Korrektur des Filterverhaltens (Jahresende 2008)
Im Moment zu strickt, es werden nur passende Inhalte übergeben. Enthält z.B. eine "Extension" kein passendes Keyword wird sie nicht übergeben. In 0.7.1 werden alle Blöcke ausgegeben wenn nur ein Block dem Filter entspricht. Auch werden einige Code-Stellen nochmal sauberer geschrieben und besser kommentiert. Die Hilfe werde ich auf ein Minimum reduizieren und noch stärker in das Wiki auslagern (das Plug-in bringt mit der Doku und kommentaren wuchtige ~50kb auf die Waage).

0.8 - Paginierung II (Februar 2008)
Diese Version wird einen Zugriff auf paginierte Inhalte eines einzelnen Blocks erlauben. In diesem Release wird sich die Datenstruktur u.U. ändern, da die einzelnen paginierten Teilblöcke als Array übergeben werden sollen und nicht als einfacher Text.

0.9 - Generator & Beta Phase (März/April 2009)
Ich würde gerne noch einen Generator mit Live-View einbinden, mit dem der Tag-Aufruf über eine Maske entspannt generiert werden kann. Dies dürfte vielen das Handling gerade für Komplexe Abfragen erleichtern. In der Beta-Phase sollen dann letzte Bugs ausgemerzt werden. Es gibt dann auch quasi einen Feature-Freeze.

1.0 Production Stable (Mai/Juni 2009)
Dies wird das endgültige Release sein, dass dann uneingeschränkt für den produktiv Einsatz freigegeben ist. Im Grunde kann das Plug-in auch jetzt schon im Produktiv-Einsatz genutzt werden. Es werden keine Daten durch das Plug-in verändert. Die Weiterentwicklung wird sich dann überwiegen auf Performance und Kompatibilität mit Core Aktualisierungen beschränken.

Es bleibt also weiter spannend. Wer Fragen zum Plug-in hat... oder Teilbereiche automatiseren möchte nur noch nicht weiß   was man da wie machen kann...immer Fragen

Beste Grüße
Nils

[cyberman]

Es bleibt also weiter spannend.

Noch spannender gehts ja kaum  ...

[Amendra]

Hallo Nils,
ich habe grade erst gesehen, daß du die neue Version schon seit einigen Tagen fertig hattest Glückwunsch, da ist wieder viel Arbeit drin!
Momentan habe ich Urlaub, aber ab Januar werde ich dein feines Tool ordentlich testen, vor allem den Level-Bereich.

Liebe Grüsse und schöne Feiertage!
Amendra

[Amendra]

Hallo Nils,
auch wenn es mittlerweile schon kräftig in den März hineingeht, habe ich dein Plugin und mein Versprechen zum Testen nicht vergessen.

Hier ein erstes Feedback:
Die Paginierung funktionert in der Fassung, in der ich sie benutze, gut. Ich habe ein ähnliches Template verwendet wie das, das du in der Hilfedatei bereitgestellt hast:

Code: Select all

<p class="paginierung">Seiten: 
{section name="i" start=1 loop=$pager_info->max+1 step=1} 
{if $smarty.section.i.index == 1}
<a href="{$page_alias}.html">1</a> 
{else} 
<a href="{$page_alias}.html?showpage={$smarty.section.i.index}">{$smarty.section.i.index}</a>
{/if}
{/section}
</p>

Die Seite 1 habe ich der Suchmaschinen wegen ausgeklammert, damit keine doppelten Inhalte indiziert werden. Jetzt wäre mein Anliegen, aus den Links richtige "SEO-freundliche" URLS zu machen. Das ginge z.B. mit

Code: Select all

{$page_alias}-seite-{$smarty.section.i.index}.html

Danach müßte die .htaccess nur noch diese Zeichenkette aufdröseln und in

Code: Select all

index.php?page=$page_alias&showpage={$smarty.section.i.index}

umschreiben. Genau da hakt es aber leider bei mir. Ich habe zwar mal ein ähnliches Ding mit mod_rewrite gebaut, aber diesmal bekomme ich es nicht hin. Hättest du da eine nutzbare Lösung, die ich in die .htaccess einbauen könnte? *lieb schau* Das wäre wunderbar!

Zu der heiß begehrten Suchenfunktion gibt es eine Menge an Testergebnissen zu berichten - in einem Extraposting

[Amendra]

Ein Extraposting, welches auf dem Fuße folgt

Teil 2 unserer Testserie - die Suchen-Funktion
Das war ja eines meiner Hauptanliegen, mit dem ich dich damals angesprochen habe. Nochmals herzlichen Dank dafür, daß du das mit implementiert hast, auch von Seiten meiner Freundinnen!

Mit ihnen habe ich diese neue Suchen-Funktion intensiv getestet. Wir pflegen in einem gemeinsamen Projekt derzeit 187 Seiten, deren Seiten alphabetisch abgelegt und dazu in diversen Kategorien eingeordnet sind. Diese werden an einer ganz anderen Stelle im Projekt zu ausgiebigen Listen zusammengestellt, immer den Inhalten eines bestimmten Feldes nach geordnet (welches nicht das content_en-Feld ist).

Dabei fiel uns auf, daß sich die Suchenfunktion anders verhält, als wir das erwartet haben

Ein Suchbegriff, der aus zwei verschiedenen Worten besteht, ist ein "sowohl als auch" anstatt ein "nur dieser feststehende Begriff aus diesen Worten und sonst nichts". Zudem findet er auch Teilmengen, was nicht beabsichtigt war. Geben wir etwa den Suchbegriff "Wasser" ein, findet er auch "Süßwasser", "Brackwasser" oder "Salzwasser". Er soll aber nur und ausschließlich den Begriff "Wasser" finden.

Ordnungskategorien haben wir Unmengen, dazu ziemlich exotische Suchbegriffe, von denen ich hier mal als Beispiel einige aufliste. Sozusagen eine Art Härtetest In der Kategorie "Erscheinungsform" finden sich diese feststehenden Suchbegriffe:

Code: Select all

- Gestaltwandler
- humanoid/ohne Angabe
- humanoid/veränderlich
- humanoid/winzig
- humanoid/sehr klein
- humanoid < 10 cm
- humanoid < 30 cm
- humanoid/klein
- humanoid < 50 cm
- humanoid < 1 m
- humanoid < 1,50 m
- humanoid/menschengroß
- humanoid < Mensch
- nicht humanoid 

Da ist schnell klar, wo das Problem liegt: Nach welchem Begriff, der nur ein einziges Mal vorkommt, soll man suchen lassen? Zumal es offenbar auch noch eine Begrenzung gibt: Wenn der Suchbegriff aus weniger als 2 oder 3 Zeichen besteht, wird gar nichts gefunden (vielleicht, weil gar nicht erst gesucht?). Bestimmt eine sinnvolle Sicherheitsabfrage, aber hier leider nicht die Lösung. Wir können nicht nach "10" oder "10 cm" suchen, nicht nach "1,50 m", nicht nach "cm" - sehr schade, das.

Bei "sehr klein" mußten wir uns mit "klein +sehr" behelfen. Der Suchbegriff "sehr +klein" gab hingegen alle Datensätze aus, in denen das Wort "sehr" UND das Wort "klein" vorkam, also auch alle Daten aus der Kategorie "humanoid/klein". Von der Verwendung eher arg gewöhnungsbedürftig, weil man vom analogen Standpunkt aus nach "sehr klein" als festem Suchbegriff suchen würde. Was also fehlt, ist die Funktionalität von "Suchbegriff als Ganzes auswerten". Wie bei Google, wenn die Anführungszeichen mit im Suchbegriff verwendet werden. Das wäre überaus hilfreich und eine tolle Erweiterung. Dann klappt's auch mit den Humanoiden

Dann fiel noch auf:
Standardmäßig sucht das Script immer im Feld content_en, was in diesem Fall nicht gewünscht ist und möglicherweise unnötig Rechenleistung kostet. Die Kategorien mit den auszuwertenden Suchbegriffen stehen in unserem Falle alle in Extrafeldern. Und es werden auch nur die Inhalte der Extrafelder benötigt, nicht der content_en-Inhalt.

Darüberhinaus kann man eine Suche und eine Abfrage von Extrafeldern nicht kombinieren. Die Aufgabe war bei uns: Suche nach einem bestimmten Suchbegriff (bestehend aus mehreren Worten, die genau so und nicht anders sein sollen, also auch keine Teilmengen) im Extrafeld "Kategorien" und hole für die gefundenen Datensätze die Inhalte aus den (Extra-)Feldern "Kategorien", "Klassifizierung" und "Kurzbeschreibung". Baue daraus dann eine Liste.

Das klappte in der Praxis auf Anhieb leider so gar nicht. Man kann entweder (in einem Feld via block_name="NameDesFeldes") suchen oder nur Inhalte zusammenstellen. Ich mußte einen Umweg wählen, um an die gewünschten Inhalte ranzukommen: Erst in einem ersten Durchlauf alle Datensätze sammeln, die den gewünschten Suchbegriff enthielten und dann einen zweiten content_dump starten, in dem die ermittelte content_id als $this_only-Parameter übergeben wurde. Erst dann erhielt ich die Inhalte, die ich brauchen konnte für meine Ausgabeschleife. Die sieht jetzt so aus:

Code: Select all

{content_dump block_name=$suchfeld filter=$suchwort start_id="82" exclude="82" depth="-1,2" prefix="buchstabe_" prefix_mode="hide" first_sort="title" html="strip"}
<ul class="kreaturenliste">
{foreach from=$dump item=dump}
	{content_dump extensions="klassifizierung,kurzbeschreibung" this_only=$dump->content->id html="strip"}
	{foreach from=$dump item=dump}
	<li><span class="klassifizierung">
	{$dump->extensions->klassifizierung->data}</span> 
	<b>{cms_selflink page=$dump->content->alias text=$dump->content->title}</b>
	{if $dump->extensions->kurzbeschreibung->data != ''}
	<span class="klein"> {$dump->extensions->kurzbeschreibung->data}</span>
	{/if}
	</li>
	{/foreach}
{/foreach}
</ul>

$suchfeld und $suchbegriff werden dabei von der aufrufenden Seite als smarty-Variablen gesetzt, bevor der eigentliche Aufruf startet, der seinerseits in dem global-content-block liegt.

Der Effekt: Er läuft die 187 Datensätze beinahe doppelt durch - es kommen in dieser Variante 277 Datenbankabfragen zustande. Zum Glück auf unserem Liveserver recht schnell (bei mir zuhause auf einer XP-Maschine mit XAMPP ziemlich langsam), aber ich frage mich, ob diese Vorgehensweise erstrebenswert ist? Wir generieren damit doch eine arge Datenbanklast, richtig?

Und noch eine Idee zum Schluß (und dann ist auch Schluß für heute): Wäre es möglich, die Abfrage so zu erweitern, daß auch der Menü-Title mit übergeben wird? Falls man mal auf diesen zurückgreifen wollte und nicht auf den Title der Seite. Das wäre eine klasse Erweiterung

Okay, also nochmals vielen lieben Dank für deine Mühe und dein enormes Engagement. Ich hoffe, wir konnten dir damit einen Gefallen tun. Wie gesagt, die "Whole Word only"-Funktion in der Suche wäre noch dringend erforderlich, um dein wunderbares Werk abzurunden (und unsere absonderlichen Wesen ans Tageslicht zu befördern, die derzeit noch in den Weiten der Datenbank verschollen bleiben) und einen Rat zur .htaccess würde ich noch erbitten.

Herzlichen Dank und liebe Grüsse
Amendra

[nhaack]

Hi Amendra,

astreines Feedback. Vielen Dank. Werde heute abend mal etwas genauer reingucken. Die SEF URLs sollten kein Problem sein. Ich muss mal in meine .htaccess Snippet Box gucken.

Bzgl. der anderen Punkte brauche ich etwas länger . Doch zunächst kann ich einmal sagen, das "Whole Word" sicherlich denkbar ist. Muss mir mal die Operatoren nochmal genau angucken.

Unter drei Zeichen wird eine Suche allerdings wohl nciht funktionieren. Dies liegt einfach daran, wie mySQL ein Filtering vornimmt. Vielleicht gibt es hierzu noch alternativen. Vielleicht kann man hier über den Alias filtern?

Performance seitig lasse ich mir die Angelegenheit ebenfalls ncohmal durch den Kopf gehen. ich habe da schon eine Idee die mit wesentlich weniger Queries auskommen sollte.

Welche Version hast du getestet? 0.7.1 oder die aktuelle 0.8?

Beste Grüße
Nils

[nhaack]

Hi Amendra,

habe mir dein Feedback einmal in Ruhe angesehen. Nochmals vielen dank für das umfangreiche Feedback. Dafür will ich mich bei meiner Antwort auch nicht lumpen lassen.

REWRITE PAGINATION
===================
Habe mal ein wenig rumprobiert aber noch kein zufrieden stellendes Ergebnis gefunden. Ich würde aber auf völlig hierarchische URLs setzen. Ich denke dies bereitet am wenigsten Probleme und macht die Site sehr übersichtlich (ich plädiere jedenfalls immer dafür )

Also z.B. so:

http://www.example.com/category/subcategory/article/1/
http://www.example.com/category/subcategory/article/2/

für den Fall von identischen Seiten (wie z.B.) kannst du ja mit dem Tag arbeiten oder einen Redirect setzen.

http://www.example.com/category/subcategory/article/
http://www.example.com/category/subcategory/article/1/

Mein Ansatz ist hier:

Code: Select all

###################################
# Rewrite for all pages
###################################
RewriteCond %{REQUEST_URI} ^.+/([0..9]*)/$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^.+/([^/]*)/([^/]*)/$ index.php?page=$1&showpage=$2 [QSA,L]

Die URL wird nur umgeschrieben, wenn sie auf eine Zahl + "/" endet, dann werden die letzten beiden Hierarchischen Elemente genommen und wie dargestellt geändert. Also "xyz/abc/article/2/"wird zu "index.php?page=article&showpage=2". Kann es allerdings im Moment nicht testen. Achtung, du musst als Dateiendung "/" in der config.php eintragen damit du die URL schön hierarchisch von CMSMS erstellen lassen kannst.


VERWENDUNG FILTERING
========================
## Auswahl der Blöcke
Ich glaube du hast noch mit 0.7.1 getestet. In der 0.8 Version lässt sich über "block_name" der Block zum Filtern auswählen (und nur dieser Block wird gefiltert). Wenn du content_en benötigst, kannst du diesen ja unter dem "Parameter extensions" aufführen. Damit dürfte sich auch die Suchzeit wesentlich reduzieren.

## Operatoren / Suchverhalten
Bzgl. des Suchverhaltens ist leider kein anderes Verhalten im Moment möglich, welches andere Operatoren als AND, OR und NOT kennt. Wie eine Gruppierung aussieht weiß ich nicht. Funktionieren vielleicht Klammern? Es ist wohl möglich, andere Suchmodi für einen Full-Text index zu verwenden (im Moment steht aber ein anderes Projekt an). A propos Performance - hast du einen Full-Text Index in der DB angelegt?

Man könnte die Suchart wohl auf "IN NATURAL LANGUAGE MODE" ändern, wenn ich die mysql Doku richtig verstehe. Damit dürfte ein Suchverhalten wie gewüschnt möglich sein. Den Modus per Parameter zu steuern dürfte auch nicht so schwer sein.

Eine entscheidene Grenze hat die reguläre FULL-TEXT search allerdings, ein Suchwort muss mindestens drei Zeichen lang sein ("10 cm" müsste dann aber gehen - "10" wird weiterhin nicht gehen). Vielleicht kann man dies aber in den mySQL Server Einstellungen ändern.


MEHRFACH FILTER ÜBER MEHRERE SPALTEN
=======================================

Das mit der mehrspaltigen Filterung ist da noch wesentlich aufwändiger vermute ich. Es ist geplant Content-Dump nochmal grundlegend zu überarbeiten um ADODB zu verwenden damit auch Postgres DB funktionieren. Im gleichen Atemzug werde ich auch einige Funktionen kapseln. Eine mehrspalten Suche müsste möglich sein.

Der Umweg über mehrere Durchläufe ist per se nicht falsch. Der Umweg über das verschachtelte Content-Dump frisst zweifelsohne aber selbst auf großen Servern bei entsprechender Datenmenge viel Leistung.

Die Dumps müssen also nacheinander ausgeführt werden. Du könntest vielleicht alle IDs des Ergebnisses in einem Capture speichern, und die Sammlung als Ganzes nochmal filtern in dem du als Capture eine Komma getrennte Liste an IDs übergibts). Das sit jetzt Freihand und nicht getestet.

Code: Select all

{content_dump filter="xyz" block_name="block1"}
	{assign var=rounds value=$dump|@count} 
	
{capture name=filterselection}
	{section name="i" start=0 loop=$rounds-1 step=1}
		{$dump->content->id}{if $i != $rounds-1},{/if}
	{/section}
{/capture}

Als Ergebniss müsste man einen String in etwa wie folgt erhalten "34,23,765,654,32,9"

Code: Select all

{content_dump this_only=$filterselection filter="abc" block_name="block2"}
 {foreach from=$dump item=dump}
   {$dump->data->title}
 {/foreach}
 

Diesen kannst du ... mist... kanst du nicht! Das Plug-in kann für this_only keine Kette an ID's annehmen. Quasi ein "these_only" muss her. Müsste aber machbar sein. Dann kannst du mehrere IDs übergeben und diese explizit filtern lassen. (Ich lass das hier mal als Memo stehen - vielleicht geht das quasi als Patch recht schnell). Dann sind es nur noch zwei Content-Dump Durchläufe.


ALSO
================
Ich denke ein paar Änderungen können relativ kurzfristig umgesetzt werden. Allerdings arbeite ich zur Zeit an einem Site-Projekt, so dass ich diese Änderungen erst in einigen Wochen einbauen werde (es sei denn ich gerate in die gleiche Situation und muss es dringend ändern ). Freizeit ist ein knappes Gut - du verstehst?

Also wie gesagt, die Probleme "Humanoide Suche" und "Mehrfachfilterung" dürften wohl in jedem Fall in absehbarer Zeit gelöst werden. Für die "Blockwahl" müsste 0.8 eigentlich gehen. Bei der Paginierung musst du mal schauen ob du mit dem Ansatz Weiteres machen kannst. Vielleicht hat hier ja nochmal jemand einen Tipp (vielleicht mal einen neuen Beitrag hierfür starten).

Und das mit dem Menu-Text statt Title wird auf jeden Fall umgesetzt. Ist mir nie aufgefallen, dass der gefehlt hat

Beste Grüße
Nils