Hallo, hat jemand 'ne Idee, wie man für die indexed_search in TYPO3 13 den Paginiator austauschen kann? Indexed_search verwendet wohl den TYPO3-eigenen Pagniator, der auch eine 'sliding-Variante' hat, die ich aber nicht konfigurieren kann. Problem ist u. a., dass bei sehr vielen Ergebnissen alle Seiten angezeigt werden, also nicht sowas wie >>>. Es gibt die Ext. numbered_pagination von Georg Ringer, mit der sowas funktionieren könnte. Leider kann ich der Doku nicht entnehmen, wie sich das auf die indxed_search übertragen lässt. Außerdem liefert die Suche in Version 13 nicht mehr die Anzahl der Treffer - warum auch immer (https://forge.typo3.org/issues/104861). Hat vielleicht dazu jemand einen hilfreichen Einfall? Vielen Dank für eure Hilfe

Um den gesamten Paginator auszutauschen müsstest Du den SearchController der indexed_search überschreiben (Patchen od. XClassen). Wie Du hier sehen kannst gibt es in der Klasse keine andere Möglichkeit den Paginator zu ändern: https://github.com/TYPO3-CMS/indexed_search/blob/9c49bdc7cdc2035e73ddf33efc5fffea31d57125/Classes/Controller/SearchController.php#L263 Man könnte auch versuchen das Partial für den Paginator zu überschreiben mit dem Partial aus der EXT:numbered_pagination. Das geht relativ simpel. Dazu musst Du nur die EXT:numbered_pagination installieren und in Deiner Sitepackage Extension folgende Konstanten implementieren: EXT:my_sitepackage/Configuration/TypoScript/constants.typoscript: ```yaml plugin.tx_indexedsearch { view { partialRootPath = EXT:numbered_pagination/Resources/Private/Partials/ } } ``` Bei beiden Lösungen stehst Du allerdings vor dem gleichen Problem, dass die EXT:numbered_pagination für die EXT:news geschrieben wurde und nicht für die EXT:indexed_search. Das wird also beides nicht so ohne weiteres funktionieren. Vielleicht ist es besser darüber nachzudenken eine andere Suche zu verwenden wie bsp. die EXT:ke_search. Die ist vielleicht besser geeignet, wenn Du so viele Suchergebnisse hast. Ich meine, dass man da auch die Suchergebnisse beschränken kann. Bin mir aber nicht ganz sicher. Ich persönlich finde jetzt 100 Suchergebnis-Seiten ein wenig viel. Aber ich kenne Deinen Use-Case auch nicht. Das Problem mit der Treffer-Anzahl lässt sich allerdings vorerst relativ leicht beheben. Dazu muust Du das Template Search.html überschreiben. Dies kannst Du auch in Deinem Sitepackage in den Konstanten tun: EXT:my_sitepackage/Configuration/TypoScript/constants.typoscript ```yaml plugin.tx_indexedsearch { view { templateRootPath = EXT:my_sitepackage/Resources/Private/Templates/ } } ``` Und dann musst nur das Template aus der EXT:indexed_search in Deine Ext:my_sitepackage kopieren. EXT:indexed_search/Resources/Private/Templates/Search/Search.html EXT:my_sitepackage/Resources/Private/Templates/Search/Search.html Und in dem Template musst Du dann die Zeile 34 austauschen: Original: ```html ``` Ersetzen mit: ```html ``` Ich würde es aber mal mit der ke_search versuchen an Deiner Stelle. 😉

Hallo und vielen herzlichen Dank. Die Treffer-Anzahl anzeigen scheint mit deiner Änderung zu funtkionieren (und, wie dir bekannt sein dürfte, vielleicht ja in Kürze der Standard, s. https://forge.typo3.org/issues/104861). Das sliding window Paginator-Problem scheint es schon länger zu geben, vgl. https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/12.0/Feature-94625-IntroduceSlidingWindowPagination.html (mit dem Verweis auf Georg Ringer). Sehe ich es richtig, dass da was im Core ausgetauscht werden muss - eventuell mit Auswirkungen an ganz anderen Stellen? Was updates angeht, auch nicht gerade die beste Lösung. Erstaunlich, dass nach dem (wahrscheinlich nicht ganz unaufwendigen) Überarbeiten von Core-Extensions wesentliche Merkmale nicht mehr funktionieren und man auf 3rd-Party Extension zurückgreifen muss.

Der Sliding-Window Paginator wurde bisher nur bereitgestellt zur Verwendung in eigenen Extensions. In dem Feature wird beschrieben, wie man ihn in seine Extension einbinden kann. In der Ext:indexed_search gibt es bisher nicht die Möglichkeit ihn zu verwenden. Wenn man das trotzdem will, dann muss man den Controller derzeit noch selbst überschreiben. Hierbei würde ich empfehlen dies mit einem Patch zu tun und diesen dann auch hier bereitzustellen: https://forge.typo3.org/issues/105084 Da vorgesehen ist, dass das auch in der indexed_search möglich sein soll. Wie man in dem Bsp. mit der Treffer-Anzahl sehen kann, hat die Bereitstellung des Workarounds dazu geführt, dass ein Core-Entwickler die Änderung implementiert hat und der Fehler damit höchstwahrscheinlich schnell behoben wird. Danke geht raus an Garvin Hicking dafür. :-)

Danke für die Antwort. Der Forge-Beitrag stammt von mir. Leider sind meine Programmierkenntnisse nicht ausreichend, um das hinzubekommen. Was mich überrascht ist, dass ich auch nach längerem googeln wenig gefunden habe. Offensichtlich stört es viele nicht, dass elementare Funktionen verschwinden oder sie wenden sich gleich anderen Extensions oder anderen CMS zu. Für mich beduetet das, dass indexed_search in TYPO3 13 wohl unbrauchbar ist, sofern sich nicht ein fähiger Kopf findet, der dies - wie von dir empfohlen - noch nachsteuert.

Die EXT:indexed_search ist ja auch ein Urgestein in TYPO3. Gefühlt gibt es die Extension schon immer. Ein kurzer Blick ins Git-Repo zeigt, dass der erste Commit dazu von Kasper selbst am 16.11.2004 gemacht wurde und die Extension schon mind. seit TYPO3 3.7.0 mit dabei ist. Also eigentlich schon immer. Ich selbst arbeite mit TYPO3 seit der Version 4.3 und habe die EXT:indexed_search nur selten verwendet. Und dass nur wenige bemerkt haben, dass die Gesamt-Treffer-Anzahl im Suchergebnis fehlt, zeigt ja auch, dass anscheinend nicht viele andere die EXT:indexed_search verwenden. Meiner Meinung nach ist die EXT:indexed_search gut geeignet, wenn man nur wenige Content-Seiten hat. Wenn man allerdings viel dynamisch generierten Content auf seiner Seite hat, ist die Extension m.M.n. unbrauchbar. Was wohl auch daran liegen mag, dass man jede Seite einmal aufrufen muss, um diese zu indexieren. Oder man verwendet einen Crawler, der dieses tut. Aber so hat ja jede Erweiterung ihre Vor-/ und Nachteile. Und was der eine als Vorteil ansieht ist für den anderen ein Nachteil. Nimmt man beispielsweise die EXT:ke_search. Die indexiert die Suche über die Datenbank-Einträge und kann dies von Haus aus für Seiten, CE's und News (Und wahrscheinlich noch mehr). Hat man allerdings eine Eigenentwicklung, dann muss man selbst einen Indexer dafür schreiben. Das ist für viele Nicht-Programmierer sicherlich eine große Hürde. Ich hab heute mal einen kurzen Blick in die EXT:indexed_search geworfen und festgestellt, dass man die Paginierung nicht so ohne weiteres austauschen kann. Das liegt daran, dass der beschriebene QueryResultPaginator die Ergebnisse als QueryResult erwartet und die EXT:indexed_search das Ergebnis als Array liefert. Auf deutsch bedeutet das, dass man doch tiefer in die EXT:indexed_search eingreifen muss, als nur den Paginator auszutauschen damit das ganze funktioniert. 😉 Schaut man sich mal den von Dir beschriebenen Use-Case an mit über 100 Trefferseiten a 10 Treffer pro Seite, dann reden wir hier ja über mehr als 1000 Seiten die bei einer Suche gefunden werden. Das scheint ja zumindest keine kleine Vereinsseite zu sein oder so. Wie schon gesagt solltest Du da vielleicht überlegen eine andere Suche zu verwenden. Wenn Du aber trotzdem die EXT:indexed_search verwenden willst, dann wäre eine andere Option, einen Entwickler zu suchen, der das ganze für Dich einbaut und ggf. zum Core beiträgt. Bei Open-Source leistet halt jeder seinen Beitrag wie er kann. 😉 Ich persönlich finde, dass die Suche auch in TYPO3 13 noch das liefert wofür sie gedacht ist. In den Tests die ich die letzten Tage mit der Extension gemacht habe, hat sie genau das getan, was sie sollte. Und der Fehler mit der Gesamt-Treffer-Anzahl ist sicherlich in einigen Tagen behoben.

Ich denke, die indexed_search hat durchaus ihre Daseinsberechtigung, auch wenn ich die ke_search trotzdem sehr gerne nutze. Kommt halt auf's Projekt an. Aber bei der Anzahl der Seiten, um die es hier geht, würde ich sicher auch die ke_search bevorzugen, alleine wegen der Indexierung, die man locker über einen Scheduler-Task automatisieren kann. Das mit dem Indexer stimmt, aber ich habe es tatsächlich schon mal geschafft, einen eigenen Indexer zu schreiben für eine Event-Extension. Die Doku (und ChatGPT) waren da sehr hilfreich.

Seit gestern wird ab TYPO3 13.4 auch wieder die Gesamt-Treffer-Anzahl angezeigt. 🙂

V13 indexed_search - Paginator und Treffer

wini2

Die indexed_search ist sicher ein Urgestein - ebenso wie ich. Ich hab' TYPO3 auch schon lange im Einsatz (seit v. 3.5!), aber eben nur nebenberuflich. Damals fiel die Wahl auf TYPO3, nicht zuletzt wegen seiner durchdachten und redaktionell gut bedienbaren Art - erwähnt sei hier nur der Seitenbaum, der Ur-RTE (der vor dem htmlarea) und die vergleichsweise umfassende Dokumentation und dem guten Community-Suport (für die, die sich z.B. noch an typo3.net erinnern). Wordpress konnte damals überhaupt nicht mithalten, vielleicht auch, weil 'nur' ein Blog-System, Mambo/Joomla und ähnliche fand ich ebenfalls deutlich unterlegen.

Wenn ich mich recht erinnere, war auch die indexed_search ein wichtiges Auswahlkriterium für mich, damals ein echtes 'Killerfeature', noch dazu mit so tollen Umsetzungen, die Suche granular einzugrenzen () und per BE-Checkbox Seiten ganz auszuschließen. Die indexed_search mag technisch umständlich und langsam gewesen sein, meinen Anforderungen hat sie meistens genügt - und würde es auch weiter, wenn sie die Elementarkriterien erfüllen würde. Dass die Icons in der Ergenisliste weggefallen sind (https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/13.0/Breaking-102921-RemoveSeveralOutdatedIndexedSearchFeatures.html), ist verschmerzbar, wenn ich auch nicht verstehe, warum das veraltet sein soll. Der Paginator ist allerding übel, weil ich gerne nicht ungezählte Ergebnisse auf einer Seite habe, meist nur fünf bis zehn. Ich habe Seiten, bei denen mittelprächtig viele PDFs indexiert sind, was dazu führt, dass doch schon reichlich Ergebnisse zusammenkommen. Mit dem 'mobil-egal' Ansatz - winizige Buttons im Pagniator, geht das natürlich, Besucher/-innen einer Seite finden das aber allgemein nicht ganz so chic.

Ich hoffe, das Paginator-Problem wird irgendwie gelöst, vielleicht ja mir genialen t3sbootstrap-ext. von Helmut Hackbarth (bei der das ja schon für v12 besser gelöst ist), die ich gerne verwende, andernfalls muss ich, wie von euch vorgeschlagen, bedarfsweise ke_seach einsetzen (zumal ja ebenfalls in t3sbootstrap enthalten).

@Mogens Fiebrandt - Danke für den Hinweis, dann kann ich einen Punkt ja von der to-do-Liste streichen.

Christian Reifenscheid

Hallo zusammen,

ich hatte auch das Problem, dass ich nur eine definierte Anzahl Links zeigen möchte (TYPO3 13.4.18). Dafür habe ich lediglich das "Pagination.html"-Partial überschrieben.
Die Anzahl der Links steckte bei mir in {settings.page_links}.
Zusammen mit {searchParams.pointer} habe ich mir dann im Fluid eine Condition gebastelt.
Dies rendert die Link ab der vorherigen und solange bis meine Anzahl erreicht ist.

Sieht bei mir so aus:

<!-- rendering of the "previous" link -->
<f:variable name="previousPageNumber" value="{searchParams.pointer}" />
<f:variable name="lastPageNumber" value="{searchParams.pointer + settings.page_links - 1}" />

<f:for each="{pagination.allPageNumbers}" as="pageNumber" iteration="i">
    <f:if condition="{i.cycle} >= {previousPageNumber} && {i.cycle} <= {lastPageNumber}">
        <!-- original link rendering -->
     </f:if>
</f:for>

<!-- rendering of "next" link -->

Nicht die beste, aber in meinem Fall die einfachste und schnellste Lösung.
Vielleicht hilft es ja wem.

VG,
Christian

wini2

Besser spät...
ich habe es mittlerweile mit eigenem js gelöst. Habe noch keine Nachteile feststellen können.

//sliding paginator - nur für suchseite (einbindung via f:asset.script in Search.html)
  
 document.addEventListener("DOMContentLoaded", function () {
    const paginators = document.querySelectorAll(".sliding-paginator");

    if (!paginators.length) {
        console.log("Keine Paginatoren gefunden");
        return;
    }

    paginators.forEach((paginator) => {
        const pageItems = paginator.querySelectorAll(".page-item");
        const activePageItem = paginator.querySelector(".page-item.active");

        if (!activePageItem) {
            console.log("Keine aktive Seite gefunden");
            return;
        }

        const activePage = parseInt(activePageItem.textContent);
        const totalPages = Array.from(pageItems).filter(item => !isNaN(parseInt(item.textContent))).length;

        if (totalPages <= 5) {
            //console.log("Zu wenige Seiten für Ellipsen");
            return;
        }

        function createPageItem(pageNum, isCurrent) {
            const li = document.createElement("li");
            li.classList.add("tx-indexedsearch-browselist-next", "page-item");
            if (isCurrent) li.classList.add("active");

            const link = document.createElement("a");
            link.href = "#";
            link.classList.add("tx-indexedsearch-page-selector", "page-link");
            link.textContent = pageNum;
            link.setAttribute("data-prefix", "tx_indexedsearch");
            link.setAttribute("data-pointer", pageNum - 1);

            li.appendChild(link);
            return li;
        }

        function createEllipsis() {
            const li = document.createElement("li");
            li.classList.add("page-item", "ellipsis");
            li.innerHTML = "<span class='page-link'>...</span>";
            return li;
        }

        // Neues <ul> erstellen, um das HTML sauber zu halten
        const newUl = document.createElement("ul");
        newUl.className = paginator.querySelector("ul").className;

        // Vorherige und erste Seite Buttons hinzufügen
        const firstPageButton = paginator.querySelector(".page-item:first-child");
        const prevPageButton = paginator.querySelector(".page-item:nth-child(2)");

        if (firstPageButton) newUl.appendChild(firstPageButton.cloneNode(true));
        if (prevPageButton) newUl.appendChild(prevPageButton.cloneNode(true));

        // Erste Seite immer anzeigen
        newUl.appendChild(createPageItem(1, activePage === 1));

        // Ellipse vor dem aktuellen Bereich, wenn nötig
        if (activePage > 3) {
            newUl.appendChild(createEllipsis());
        }

        // Seiten um die aktuelle Seite herum anzeigen
        const startPage = Math.max(2, activePage - 1);
        const endPage = Math.min(totalPages - 1, activePage + 1);

        for (let i = startPage; i <= endPage; i++) {
            newUl.appendChild(createPageItem(i, i === activePage));
        }

        // Ellipse nach dem aktuellen Bereich, wenn nötig
        if (activePage < totalPages - 2) {
            newUl.appendChild(createEllipsis());
        }

        // Letzte Seite immer anzeigen
        newUl.appendChild(createPageItem(totalPages, activePage === totalPages));

        // 'Nächste Seite' und 'Letzte Seite' Buttons am Ende hinzufügen
        const nextPageButton = paginator.querySelector(".next-page");
        const lastPageButton = paginator.querySelector(".last-page");

        if (nextPageButton) newUl.appendChild(nextPageButton.cloneNode(true));
        if (lastPageButton) newUl.appendChild(lastPageButton.cloneNode(true));

        // Ersetze das alte <ul> mit dem neuen <ul>
        paginator.replaceChild(newUl, paginator.querySelector("ul"));

       //console.log("Neuer Paginator hinzugefügt:", newUl);
    });
});

Auch hier die Hoffnung, dass es jemand brauchen kann.

Eric Harrer

Ich habe das heute mit der Sliding Window Pagination des Cores (seit TYPO3 v12) und einer minimal invasiven XClass für die Indexed Search umgesetzt.

in ext_localconf.php:

use TYPO3\CMS\IndexedSearch\Controller\SearchController as CoreSearchController;
use VendorName\Sitepackage\Controller\IndexedSearch\SearchController as CustomSearchController;

/**
 * use XClass for search controller
 */
$GLOBALS['TYPO3_CONF_VARS']['SYS']['Objects'][CoreSearchController::class] = [
    'className' => CustomSearchController::class,
];

in Controller/IndexedSearch/SearchController.php:

<?php

namespace VendorName\Sitepackage\Controller\IndexedSearch;

use TYPO3\CMS\Core\Pagination\PaginationInterface;
use TYPO3\CMS\Core\Pagination\SlidingWindowPagination;
use TYPO3\CMS\IndexedSearch\Controller\SearchController as CoreSearchController;

final class SearchController extends CoreSearchController
{
    protected function getDisplayResults(
        array $searchData,
        array $searchWords,
        array|bool $resultData,
        int $freeIndexUid = -1
    ): array {
        // Execute the original Core implementation to preserve all existing logic
        $result = parent::getDisplayResults($searchData, $searchWords, $resultData, $freeIndexUid);

        // Replace only the pagination implementation while keeping the original paginator
        // built by indexed_search. This avoids duplicating logic and stays in sync with Core
        // behavior across TYPO3 updates.
        $pagination = $result['pagination'] ?? null;
        if ($pagination instanceof PaginationInterface) {
            $result['pagination'] = new SlidingWindowPagination(
                $pagination->getPaginator(),
                7 // maximum number of links
            );
        }

        return $result;
    }
}

Das funktioniert als Drop-In-Replacement direkt ohne Anpassungen im JavaScript-Code.

wini2

Eric Harrer

Vielen Dank für die Lösung.

Vielleicht schafft es die ja auch in den Core. Ich bin mir über die Verfahrensweise unsicher, aber es könnte dazu hilfreich sein, wenn du die auf https://forge.typo3.org/issues/105084#change-529282 posten könntest. Der Änderungswunsch steht da schon seit über einem Jahr auf Accepted, scheint aber nicht so wirklich jemanden zu kümmern.

Eric Harrer

wini2

Ich habe dafür eben einen Core-Patch vorbereitet, der ein PSR-14-Event in indexed_search einführt. Damit wäre ab v14 ein sauberer Weg vorhanden, die Pagination auszutauschen. Mal sehen, ob der Patch gemergt wird. 😉

https://review.typo3.org/c/Packages/TYPO3.CMS/+/92578

wini2

Super. Schön zu sehen, dass sich dank deiner kompetenten Unterstützung was tut.
Nochmals ganz herzlichen Dank für die Unterstützung.

Eric Harrer

wini2 gern geschehen.
Ein PSR-14-Event fühlt sich für diesen Anwendungsfall für mich deutlich stimmiger an als eine XCLASS.

Wie würdest du das im Patch diskutierte Thema grundsätzlich einschätzen?
Sind Integratoren aus deiner Sicht heute mit PSR-14-Events als Erweiterungsmechanismus im Core ausreichend vertraut?
Oder wäre ein Setting trotz der damit verbundenen Einschränkungen bei der Flexibilität (z. B. keine vollständig eigene Pagination) der bessere Weg?

wini2

Ich bin leider nicht [sonderlich] damit vertraut. Für mich ist es immer klasse, wenn die Doku vollständig und verständlich ist und ich die Konfiguration ohne großes Eingreifen in den php-Code hinbekomme. Vieles kann ich mir durch langjährige Erfahrung und googeln erklären. Der Frage von Guido Schmechel kann ich mich daher anschließen. Eine setting im TypoScript wäre für mich die einfachste Lösung - auch wenn indexed_search schon reichlich hat.

Eric Harrer

Ich kann den Wunsch nach einem Setting grundsätzlich nachvollziehen, sehe den Mehrwert hier aber nur bedingt. Für den Wechsel auf eine Sliding-Window-Pagination ist der Aufwand sehr gering, da lediglich ein kleines Copy-&-Paste-Snippet hinterlegt werden muss.

Das Beispiel im Changelog ist vollständig und so gestaltet, dass man das Event funktional nicht im Detail verstanden haben muss, um es einzusetzen. In der Praxis beschränkt sich der PHP-Anteil auf diesen einen Schritt; die weitere Anpassung erfolgt wie gewohnt im Fluid-Template.

Der Listener wird z. B. unter folgendem Pfad abgelegt:

EXT:sitepackage/Classes/EventListener/ModifySearchPaginationListener.php

Die Zahl 5 steht dabei für maximumNumberOfLinks und bestimmt, wie viele Seitennummern maximal in der Pagination angezeigt werden.

<?php

declare(strict_types=1);

namespace Vendor\Sitepackage\EventListener;

use TYPO3\CMS\Core\Attribute\AsEventListener;
use TYPO3\CMS\Core\Pagination\SlidingWindowPagination;
use TYPO3\CMS\IndexedSearch\Event\ModifySearchResultPaginationEvent;

#[AsEventListener(identifier: 'sitepackage/modify-search-pagination')]
final readonly class ModifySearchPaginationListener
{
    public function __invoke(ModifySearchResultPaginationEvent $event): void
    {
        $event->setPagination(
            new SlidingWindowPagination($event->getPaginator(), 5)
        );
    }
}

Das war es dann auch schon mit PHP: Datei anlegen, Beispiel-Code einfügen und Vendorname sowie Extension-Key anpassen.

Mal sehen was die weitere Diskussion im Patch hervorbringt. Vielleicht läuft es ja bei entsprechender Mehrheit tatsächlich auf ein Setting heraus oder eine Mischung aus beiden Ansätzen.

Eric Harrer

Kurzes Update von mir:

Vielen Dank für euer hilfreiches Feedback bisher.

Ich habe einen aufbauenden Folge-Patch erstellt, der ein neues Pagination-Setting für indexed_search einführt:

plugin.tx_indexedsearch.settings.pagination_type

Standard bleibt simple (kein Breaking Change).
Optional kann auf slidingWindow umgestellt werden.
Damit wird page_links wieder wirksam und begrenzt die angezeigten Ergebnisseiten wie erwartet.

In Kombination mit dem ersten Patch (PSR-14-Event) sind damit beide Anforderungen abgedeckt:

Für individuelle, weitreichende Anpassungen kann das Event genutzt werden.
Für den einfachen Wechsel auf Sliding-Window reicht ein Setting.

So werden beide Welten bedient.

wini2

Eric Harrer
Wow. Super - vielen Dank!

Der Screenshot ist augenscheinlich aus v14. Wird deine Lösung schon in 14.2 geben? Ich hab' nun schon einige Zeit gewartet, da kann ich es noch bis Ende März aushalten, um es testen.

Eric Harrer

wini2 Zum aktuellen Zeitpunkt kann man nicht sagen, wann und ob die Patches in den TYPO3 Core übernommen werden. Sie haben aber gute Aussicht auf Erfolg, da ich exakt dem Weg gefolgt bin, den die bisherigen Reviewer vorgeschlagen haben.

In beiden Fällen sind noch Reviews erforderlich und am Ende ein Core-Merger, der die Verantwortung für die Änderungen übernimmt und diese letztlich auch in den Core integriert.

Da am 31.03.2026 Feature Freeze für TYPO3 v14 geplant ist, wird seitens des Core Teams aktuell besonderer Wert auf [FEATURE]-Patches gelegt. Dementsprechend finden die beiden Patches hier voraussichtlich besondere Beachtung. Wir werden sehen, wie es weitergeht.

wini2

Eric Harrer
Danke für die Einschätzung. Bis Ende März ist ja noch ein Weilchen hin. Ich würde mich freuen, wenn es deine tolle Arbeit schafft.

Eric Harrer

wini2 beide Patches wurden nun gemergt 😉

wini2

Eric Harrer

Finde ich wirklich gut. Ich bin gespannt, ob ich aus Anhieb damit zurechtkomme - andernfalls weiß ich ja, wen ich nerven kann 😉. Vielen Dank für dein Engagement.

Steffen

wini2 @Eric Harrer Moin, danke euch beiden für die Arbeit – ich finde es top, so sollte es sein. Als Integrator – es sei denn man ist auch Dev – hat man in den meisten Fällen recht wenig Plan von PHP Code da man die Komplexität nicht überblickt.

Vielen Dank, ich freue mich schon auf TYPO3 v14,
Steffen

wini2

@Eric Harrer
Endlich bin ich dazu gekommen, die verbesserte Pagination bei indexed_search auszuprobieren, TPYO3 v14.2 mit Camino. Funktioniert (auf den ersten Blick) super. Auch die Sache mit den Konfigurationseinstellungen ist prima gelöst. Sehr einfach, aber auch sehr gut; keine umständlichen Conditions oder kryptische Angaben im TypoScript.

Ich wäre nicht ich, wenn ich nicht noch ein Haar in der Suppe gefunden hätte (das mir vielleicht selber ausgefallen ist). Hat mit dem sliding paginator nur bedingt zu tun. Seit einigen Versionen hoffe ich darauf, dass es {pagination.firstPageNumber - 1} bzw. {pagination.lastPageNumber - 1} mal ins fluid-Template - oder zumindest ins Manual schaffen. Wäre toll, wenn man das in den settings noch an-/ausknipsen könnte. Vielleicht ja in v15 ;-)

Nochmal: Ganz herzlichen Dank für deine tolle Arbeit (der natürlich auch allen anderen gilt, die dazu beigetragen haben).

Nächste Seite »

Unterstütze das Forum

Hilf mit, den Community Hub für TYPO3 werbefrei zu halten und die Betriebskosten zu decken. Werde Official Community Hub Supporter für nur 5 Euro im Monat (zzgl. USt) und erhalte ein exklusives Supporter-Badge. Jeder Beitrag zählt!

Jetzt Supporter werden

Impressum - Datenschutz - Kontakt - Netiquette - RSS