10. Juni 2018

TYPO3 Static File Cache – Mehr speed…

in Extension, Performance, TYPO3
TYPO3 Static File Cache Backend Module

TYPO3 Static File Cache Backend Module

Langsam aber sicher entwickelt sich der Static File Cache weiter, sodass ich euch mal wieder ein Update geben will. Nachdem die Geschichte mit fl_staticfilecache 2006 begonnen hat, wurde dieser in einem Fork als nc_staticfilecache weiterentwickelt (Podcast von früher). Ende 2016 habe ich die Version dann übernommen. Die Extension wurde darmals auf Github/Packagist/Composer migriert, sodass die neuste Version unter „lochmueller/staticfilecache“ zu finden ist. Bei der Version hat sich in den letzten 1-2 Jahren einiges getan, sodass ich euch einmal auf den aktuellen Stand bringen will. PS: Ein passender Teet zum Thema 😉

Was ist der TYPO3 Static File Cache?

Der TYPO3 Static File Cache ist ein Cache, welcher mit einem geschickten Regelwerk auf Basis von PHP und htaccess ausgestattet ist, dass Seiten, welche im Cache liegen RICHTIG FIX werden. Da reden wir nicht von Faktor 2 oder 3, sondern eher so vom Faktor ~200 (gemessen mit Apache Benchmark). Der Grund der Performance-Steigerung ist, dass das Regelwerk der statischen Dateien und der htaccess Datei dafür sorgt, dass weder PHP noch die Datenbank gebraucht wird. Gerade das „nicht starten“ des PHP Interpreter – und das damit verbundene direkte Ausliefern der Datei – führt zu diesem Schub! Neben dieser Hauptfunktion gibt es zudem ein Backend-Modul, in dem zu sehen ist, welche Seiten im Static File Cache sind. Sollte eine Seite nicht aufgenommen werden können, gibt es zudem Informationen warum dies der Fall war. Dies ist ein guter Einstieg für die Optimierung einer Seite, um z.B. falsche Konfigurationen und schlecht entwickelte Plugins zu finden.

Was hat sich in den letzten 2 Jahren getan?

Mit der Migration zu github.com habe ich stark an der Code-Qualität gearbeitet. Phpcs, phpmd, StyleCI, Scrutinizer und Travis sorgen dafür, dass der Code nicht nur PSR-2 kompatibel ist, sondern auch, dass Fehler vermieden werden und dies auch so bleibt. In dem Zuge wurde die PHP Version auf 7.x angepasst und die Extension läuft unter TYPO3 8.x und 9.x (Wer noch TYPO3 7.x hat, bitte dennoch staticfilecache [in einer älteren Version] anstatt nc_staticfilecache benutzen). Das Backend-Modul wurde umstrukturiert, aufgeräumt und näher an ein TYPO3 Look&Feel gebracht. Zudem ist das Backend-Modul sauber in deutsch und englisch übersetzt.

Großer Neuerung in der TYPO3 Static File Cache Extension ist der „Boost-Mode“. Ist der Modus aktiviert, werden die statischen Cache-Dateien nicht mehr aktiv durch das Caching-Framework entfernt, sondern stattdessen wird eine Queue aufgebaut, welche im Hintergrund von einem Scheduler-Task abgearbeitet wird. Großer Vorteil dieser Lösung: Der Benutzer hat IMMER eine statische Datei. Einziger Nachteil ist, dass Anpassungen an der Webseite ein wenig zeitverzögert erscheinen.

Zu guter letzte wurde die Dokumentation in den letzten 2 Jahren weiter optimiert, sodass die Einrichtung gut funktioniert. Bei Rückfragen gibt es direkt die passenden Antworten in der Doku.

Wie geht es weiter?

Im Moment bin ich auf der Suche nach mehr Feedback aus der Community. Ich habe die Extension kurz auf dem TYPO3Camp vorgestellt und habe bereits von 2-3 Usern Feedback bekommen. Dies ist mir aber noch nicht genug? 😉 Neben inhaltlichen Feedback sind auch immer gerne weitere Entwickler gesehen (oder auch finanziell ;)), weil ich glaube man kann mit der Extension noch einiges machen.

In den nächsten Wochen werde ich mich um die Kompatibilität für TYPO3 9.x kümmern und den Code entsprechend anpassen. Zudem werde ich weitere Tests schreiben, sodass die Qualität des Codes besser überwacht wird bzw. neue Entwicklung keine Angst haben müssen etwas zu ändern.

Ich freue mich auf euer Feedback…

Wer weitere Infos brauche. Bei GitHub ist alles zu finden…

56 Reaktionen zu “TYPO3 Static File Cache – Mehr speed…”

Kommentare abonnieren (RSS) oder TrackBack URL

Hallo Tim,

da möchte ich ersteinmal mit einem gaaaaanz herzlichen „DANKE!“ feedbacken.

Trotztdem aber eine Frage: Ich habe nur die neuesten Insatalltionen im Composermode laufen, alle anderen (ca. 80%) sind zwar auf Versionen 7 und 8 geupdatet, können aber nicht an Deiner genialen Extension teilhaben. Zumindest habe ich das nicht auf die „traditionelle Art“ hinbekommen, auch wenn Du in github schreibst „or you could also copy-paste the extension manually“. Die Extension lässt sich iunstallieren, aber das war’s auch schon. Zuckt nicht. Nirgends.

Ich vermute ja noch Probleme bei der korrekten Einbindung in die .htaccess – hättest Du da mal ein aktuelles Muster? Oder funktioniert die Ext. wirklich nur und ausschließlich im composer-mode?

Dank & Gruß
Uwe

Uwe am 10. Juni 2018 um 19:43

Hmm… generell sollte die Extension als „Kopie“ ohne composer normal laufen. Deine htaccess-Vermutung macht Sinn. Werden den die Cache-Dateien erzeugt bzw. siehst du Meldungen in dem Backend Modul? Grüße, Tim

Tim Lochmüller am 10. Juni 2018 um 21:29

Moin Tim,

ich bin manchmal einfach nur ein Honk.
Deine Extension läuft auch als „manuelle Kopie“.
Mein Fehler war, dass ich noch als Admin im BE eingeloggt war (und als solcher das Caching unterbunden hatte). Tätääää….
Also alles gut und nochmal vielen Dank!

Uwe

Uwe am 10. Juni 2018 um 21:55

Moin erstmal und vielen Dank!
Ich habe gerade mal zu Testzwecken staticfilecache in eine DDEV-Installation integriert. Beim ersten Aufruf bin ich genau dann in den Fehler gelaufen, den Du vor ein paar Minuten gefixed hast: https://github.com/lochmueller/staticfilecache/commit/deaf878d79807d834199e08b837544f05cd590d9

Einen besseren Service gibt es nicht! Die Dateierstellung funktioniert wunderbar, schaue mir dann heute noch die Scheduler-Tasks an.

Stephan am 11. Juni 2018 um 11:20

Hey Stephan. Danke für das Feedback. Der Fehler ist in Version 5.4.1 nun korrigiert…

Tim Lochmüller am 11. Juni 2018 um 13:03

Aus welchem Grund veröffentlichst du die Extension nicht im TER? Wer dort nach staticfilecache sucht, findet nur die obsoleten Versionen (nc_ / fl_).

Peter Kraume am 12. Juni 2018 um 00:52

Vielen Dank für diese nützliche Extension. Eine Anregung hätte ich: es ist in manchen Szenarien vielleicht sinnvoll, nur ausgewählte Seiten in den static file cache aufzunehmen.

Sacha Vorbeck am 12. Juni 2018 um 07:02

@Peter: Ich habe mal die Jungs von Netcreators nach dem Schlüssel „staticfilecache“ gefragt.

@Sacha: Was genau meinst du damit. Würdest du gerne den „default-Wert“ von der Checkbox „Ja, statisch Cachen“ in den Seiteneigenschaften konfigurieren, sodass du per default „nicht cachen“ einstellen kannst um dann selektiv 1-2 Seiten aktiv zu cachen?

Beste Grüße,
Tim

Tim Lochmüller am 12. Juni 2018 um 08:15

Ich finde die extension super. Aber in einem aktuellen Projekt bekomme ich die neue Version einfach nicht aktiv.

The page is not static chachable via TypoScriptFrontend
config.no_cache is true

Ich hab alle vorkommen von no_cache auf 0 gesetzt. Zusätzlich noch mal generell auf 0 gesetzt. Kann es sein, dass eigentlich was anderes gemeint ist?

Beste Grüße
Aurelius

Aurelis am 29. Juni 2018 um 13:36

Hey… am besten mal rein Debuggen. Oft es ist RealURL bzw. die cHash Berechnung, welche fehlschlägt und den Cache deaktiviert. Beste Grüße,
Tim

Tim Lochmüller am 30. Juni 2018 um 00:16

Ist schon einige Monate her, seitdem ich mich an der Extension versucht habe. Damals habe ich es nicht hinbekommen, es manuell in Nicht-Composer Installationen zum Laufen zu bekommen.
Eben nochmal ausprobiert, klappt ja völlig problemlos!
Ist wirklich eine tolle, man könnte sagen essentielle TYPO3-Extension. Jetzt muss ich noch herausfinden, warum das Backend so rumschneckt, dann macht TYPO3 auch wieder Spaß 😀

Marco am 16. Juli 2018 um 13:52

Hi,
ich habe auf meinem Webserver ein Typo3 Ver. 8 installiert. Wenn ich über „Erweiterungen hinzufügen“ den Static File Cache installieren will, warnt das System mich, dass der STatic File Cache nur bis zur Version 7.99.99 zugelassen ist.
Kann ich diese auch bei Ver. 8.7.15 installieren?

Danke und VG

Niels am 16. Juli 2018 um 21:14

Die aktuellste Version vom Static File Cache gibt es nicht im TER, sondern nur als Download via Github oder halt via composer. Beste Grüße,
Tim

Tim Lochmüller am 16. Juli 2018 um 21:22

Hi,
danke für den Tipp. Habe heute mir den ZIP Ordner bei GITHUB runtergeladen und versucht die Erweiterung hinzuzufügen. Leider bekomme ich immer die Fehlermeldung, dass dies nicht funktioniert.
Woran könnte das liegen?
VG

Niels am 22. Juli 2018 um 16:33

Ähh… wenn du das Problem beschreibst oder die Fehlermeldung postest, dann kann dir betimmt wer helfen 😉
Grüße,
Tim

Tim Lochmüller am 22. Juli 2018 um 19:08

Wo findet man denn das Backend Modul? Muss man das erst irgendwo aktivieren? Habe staticfilecache 6.0 installiert, aber es taucht kein Backend-Modul auf.

Martin am 24. Juli 2018 um 15:24

Das Module ist unter „Info -> StaticFileCache“ zu finden. Es ist kein eigenes Hauptmodul und gliedert sich unter „Info“ ein… Grüße, Tim

Tim Lochmüller am 24. Juli 2018 um 18:29

Ah, cool, danke für die schnelle Rückmeldung!

Steht das schon irgendwo in der Doku und ich habe es nur übersehen?

Martin am 24. Juli 2018 um 19:06

Hey Martin… ich muss zugeben, dass es schwer zu finden ist, da die Dokumentation nicht in einem Dokument gerendert wird. Aber hier wäre die Info: https://github.com/lochmueller/staticfilecache/blob/master/Documentation/Monitoring/Index.rst

Grüße,
Tim

Tim Lochmüller am 24. Juli 2018 um 21:56

Dort hatte ich sogar geschaut, aber nicht in „Monitoring“. Einfach übersehen… Danke dir!

Martin am 25. Juli 2018 um 06:37

Hi Tim,

vielen Dank, Static File Cache funktioniert super auf Typo3 8.7.18. Jetzt möchte ich gerne Static File Cache in Kombination mit Redis verwenden, sodass der Cache in einer Redis Datenbank abgespeichert wird. Hast du eine Idee, wie man Static File Cache in Kombination mit Redis verwenden könnte?

Viele Grüße
Jacqueline

Jacqueline am 29. August 2018 um 11:31

Hallo Jacqueline, dies macht keinen Sinn bzw. ist konzeptionell nicht mögich. Wenn eine Datei im StaticFileCache liegt, ist diese schneller, als wenn du diese in den Redis legst. Bedenke, wenn etwas im Redis liegt, musst du zunächst PHP „starten“ und dann auch noch die Verbindung mit Redis aufbauen etc. Somit ist dies nicht möglich/nötig.
Beste Grüße,
Tim

Tim Lochmüller am 29. August 2018 um 11:46

Hallo Tim,
danke, aber wir sind trotzdem an Redis interessiert, da wir unsere Daten mit einer anderen Software aus Redis auslesen müssen (LoadBalancer).

Viele Grüße
Jacqueline

Jacqueline am 30. August 2018 um 12:39

Hallo Tim,
ich vermisse bei Staticfilecache die Möglichkeit einzelne statische Files anhand z.B. URL (Request)automatisiert zu löschen. Das macht bei den Seiten Sinn, wo eigener PlugIn platziert ist, der eigene Inhalte(mit Pagination) ausliefert. Die Filterkriterien sind Bestandteil der URL, sodass einzelne Ergebnisse durch URL eindeutig identifizierbar sind. Aktuell werden Sie auch durch staticfilecache gecacht. Aber ich kann Sie nicht einzeln säubern, wenn eine der Seiten durch eine Änderung (in ganz anderem Backend) betroffen ist.
Viele Grüße
Andreas Rack

Andreas am 31. August 2018 um 13:42

Hallo Andreas,
wenn eine Seite durch eine Änderung in einem „anderen Backend“ betroffen ist, so sollte ja dennoch das TYPO3 caching Framework aufgerufen werden (da ansonsten der Static File Cache, aber nicht der TYPO3 Cache gelöscht wird). In diesem Fall wird ja auch der StaticFileCache gelöscht. Wenn du dies „selektiver“ haben möchtest, dann würde ich empfehle CacheTags zu benutzen. Diese lassen sich sowohl über die Seite, als auch über das TSFE steuern. Die passenden Tags können über z.B. das Plugin ergänzt werden und dann kann der Cache auf Basis eines Tags gelöscht werden. Vorteil: Du erwischt immer alle nötigen Caches und nicht nur den vom SFC.
Bei Fragen kann ich gerne unterstützen….
Grüße,
Tim

Tim Lochmüller am 31. August 2018 um 14:35

Hallo Tim,

meine Arbeitsgruppe ist an der Speicherung in Redis interessiert. Wir wollen ein komplexeres System entwickeln, das einen Rapid Delivery Agent unterstützt.

Bist du in München auf dem Typo3Camp? Da könnten wir darüber diskutieren.

Viele Grüße
Jürgen

Jürgen Heym am 04. September 2018 um 09:33

Hallo Jürgen, bin ich leider nicht. Wie aber oben schon geschrieben, ist die Extension glaub ich der „falsche Ansatz“ dafür. Wenn es nur darum geht die vollständige Seite in den Redis zu schieben, dann würde ich einfach eine Mini-Extension schreiben und den Core-Hook benutzen um dies zu machen. Ich sehe noch nicht ganz den Use-Case innerhalb des SFC ein Redis zu füllen. Vermutlich ist es abhänig von einem dritten externen System… dies kann ich jedoch nicht überblicken. Beste Grüße,
Tim

Tim Lochmüller am 04. September 2018 um 13:01

Hallo zusammen,

leider komme ich nicht mehr ins Backend rein.

Bekomme diesen Fehler:

Oops, an error occurred!
Call to a member function getPackagePath() on null

Benutze unter anderem

OPcache und APCu

Heiko am 05. Oktober 2018 um 09:48

Hey Heiko, danke für die Info. Alles weitere besser im Bugtracker. Danke für das Anlegen des Tickets: https://github.com/lochmueller/staticfilecache/issues/98
Grüße,
Tim

Tim Lochmüller am 05. Oktober 2018 um 15:23

Hallo Tim,
vielen Dank für die Extension, hab die auf ner kleinen Seite (mit vielen News) die demnächst live gehen soll, installiert, läuft echt gut.
Mit der aktuellen Version von Github (Anfang Oktober, Version wird mit 6.1 angezeigt) bekomme ich unter Info die Meldung „static cache disabled on domain: testdomain.lan“. Bei der alten Version (6.0) vom Juli ist das nicht der Fall, hier wird der Cache problemlos geschrieben.
Liegt vermutlich am Eintrag tx_staticfilecache_cache in der Tabelle sys_domain. In dem getesteten Projekt gibt es allerdings keinen Domaineintrag…

Viele Grüße
helmet

helmet am 07. Oktober 2018 um 18:41

Hmm… gute Frage. Ich habe keine Instanzen ohne Domain Eintrag 😉 … habe mal die Rule angepasst, sodass diese ein wenig mehr „Fail-Safe“ ist: https://github.com/lochmueller/staticfilecache/commit/7712336e802af1e488606d0e1fea8048ba611949

Grüße,
Tim

Tim Lochmüller am 08. Oktober 2018 um 18:03

Klasse, nun funktioniert es auch ohne Domain-Record 🙂

helmet am 09. Oktober 2018 um 15:47

Hallo Tim, gibt es die Möglichkeit, einige Dateien auszuschließen, z.B. dynamisch generierte sitemap.xml oder feed.rss? Oder ist das keine gute Idee?
Beste Grüße
Torsten

Torsten am 06. Dezember 2018 um 09:27

Hallo Torsten, generell werden ja nur Seiten als statisch abgelegt. Wenn du deine feed.rss und sitemap.xml als Seite erzeugst, kannst du einfach in den Seiteneigenschaften den Static File Cache deaktivieren und/oder die Cache-Zeit entsprechend runter setzen.

Beste Grüße,
Tim

Tim Lochmüller am 06. Dezember 2018 um 14:16

Hallo Tim, das geht leider nicht, die Dateien werden direkt via URL erzeugt, z.B. so https://www.botex.de/sitemap.xml?tx_csseo_view=pages. Die URL sollte sich doch via htaccess von der Weiterleitung zum Cache ausschalten lassen, oder gibt es noch eine andere Möglichkeit?
Beste Grüße
Torsten

Torsten am 07. Dezember 2018 um 09:14

Die URL wird nie vom Cache erfasst, da Parameter an der URL hängen. Der StaticFileCache ist für dieses Usecase nicht gedacht.
Im SFC landen nur Dateien, welche durch ein Seitenrendering erzeugt werden, das Processing nicht via „die“ abgebrochen wird und auch keine Parameter gibt (es gibt noch weitere Regeln in der Extension).

Tim Lochmüller am 07. Dezember 2018 um 11:08

Das ist doch prima so.
Danke für die Info und die Erstellung der Extension.
Beste Grüße
Torsten

Torsten am 07. Dezember 2018 um 11:35

Hallo,

ich habe mir die Extension „staticfilecache“ in TYPO3 8.7 installiert und unter „typo3temp/tx_staticfilecache“ werden alle Seiten schön abgespeichert.

Mein Problem ist nun, wenn ich mir den Quelltext anschaue, wird nur für die Startseite der Timestamp am Ende des Dokumentes hinzugefügt.

Das heisst, dass nur die Startseite per .htaccess geladen wird, aber alle anderen Seiten leider nicht, obwohl sie von „staticfilecache“ richtig erzeugt werden.

Dies wird wohl an der .htaccess Datei liegen.

Ist das Problem schon bekannt und wie müsste meine .htaccess aussehen, damit das auch bei den Unterseiten funktioniert?

Andre am 27. Dezember 2018 um 12:03

Hallo Andre,
das Problem ist nicht „bekannt“, es liegt vermutlich an deinem Webserver und/oder an der htaccess-Datei. Bitte prüfe ob du den aktuellen Stand benutzt: https://github.com/lochmueller/staticfilecache/blob/master/Documentation/Configuration/Htaccess.rst

ggf. einmal einzelne Regeln (Conditions) auskommentieren um zu prüfen, an welcher es liegt.

Beste Grüße,
Tim

Tim Lochmüller am 27. Dezember 2018 um 12:13

Hallo Tim,

danke für deine Antwort.

Müsste dann unterhalb von der „main“ in der .htaccess evtl. eine Condition fehlerhaft sein oder eher im Bereich „preparation“?

Aber den aktuellen Stand benutze ich bereits schon in der HTACCESS.

Andre am 27. Dezember 2018 um 12:30

Es geht um die Conditions hinter „### Begin: Static File Cache (main) ####“ & vor „# Rewrite the request to the static file.“.
Wenn du die conditions alle raus nimmst, dann leitet er immer weiter. Meine vermutung ist, dass bei dir die „# It only makes sense to do the other checks if a static file actually exists.“ Regel nicht passt. Tipp: Kommentier die Regel aus und leitet mit der RewriteRule auf eine Domain weiter, welche es nicht gibt. Dann siehst du die bestandteile in der URL und kannst sehen, welcher Part falsch ist.

Tim Lochmüller am 27. Dezember 2018 um 12:35

Vielen Dank für deinen Tipp, nun funktioniert es. Er hatte hinten immer index.phpindex.html stehen gehabt und unter so einen Namen werden die Dateien nun ja nicht gespeichert.

Andre am 27. Dezember 2018 um 13:06

Leider habe ich mich zu früh gefreut, den er hat mir immer nur die Startseite angezeigt.
Das Problem scheint zu sein, dass %{REQUEST_URI} als Wert immer nur „index.php“ ausgibt. 🙁

Andre am 27. Dezember 2018 um 14:03

Hallo Andre, dies bzgl. müstest du einmal deine Apache Konfiguration prüfen (lassen) oder eine andere Variable benutzen, wenn die sprechender URL in einer anderen Umgebungsvariable enthalten ist. Wenn du eine Lösung hast, dann kann ich gerne die Dokumentation ergänzen, sodass andere nicht in das gleiche Problem stolpern. Beste Grüße,
Tim

Tim Lochmüller am 27. Dezember 2018 um 23:10

Hallo Tim,

wie sieht es denn aus wenn auf der Seite ein Formular eingebunden ist? Gibt es hier einen Workaround?
Grüße,
Gabriel

Chabryl am 22. Februar 2019 um 16:08

Hallo Chabryl,

verstehe die Frage nicht ganz. Das Formular ist ja erst einmal cachbar (sollte so sein). Die Ziel-Action dann nicht. Dies bzgl. braucht man keinen Workarround (weil genau so will man es doch haben).

Wenn deine Formular-Action nicht cachbar ist, dann ist auch nicht zu empfehlen den Cache zu „erzwingen“.

Beste Grüße,
Tim

Tim Lochmüller am 22. Februar 2019 um 23:52

Moin Tim,
die Original-Extension wurde scheinbar aktualisiert: https://extensions.typo3.org/extension/staticfilecache/.
Hast du da schon reingeschaut?
Beste Grüße
Jan

Jan am 11. Juni 2019 um 16:08

Hey Jan… verstehe die Info nicht ganz. Kannst du mir mehr Details schicken. Seit ca. 1 Monat schiebe ich staticfilecache auch ins TER. Dennoch sollte composer der beste Weg bleiben, die Extension zu installieren.
Beste Grüße,
Tim

Tim Lochmüller am 11. Juni 2019 um 16:28

Moin Tim,
das IST tatsächlich deine Extension, sorry! Da habe ich nicht richtig hingeschaut. Wenn allerdings das gesamte Projekt nicht via Composer installiert wurde und noch dazu in einem Shared-Hosting liegt bleibt mir nur die Möglichkeit über das TER. (Keine Frage, ich arbeite auch lieber in einer vernünftigen Staging Umgebung und mit dem Composer).
Beste Grüße aus Hamburg
Jan

Jan am 18. Juni 2019 um 17:48

PS. Lieben Dank für deine Extension! Works like a charm 🙂
Beste Grüße
Jan

Jan am 18. Juni 2019 um 17:50

Moin Tim,
eine Frage: ist die Extension nicht kompatibel mit 404-Fehlern? Ich werde entweder auf die Startseite weitergeleitet oder nach /.html und bekomme dann einen 403. Das ist aus SEO-Sicht natürlich beides nicht so gut.
Problem bekannt? Schon eine Lösung?
Liebe Grüße
Jan

Jan am 02. Juli 2019 um 12:16

Hey Jan, die Extension hat erst einmal nichts mit 404 Fehlern zu tun. D.h. Eine Seite die es nicht gibt, wird es auch im Cache nicht geben. Wenn es Seiten „nicht mehr“ gibt, dann leitet die Extension nicht weiter. Das 404 Handling muss separat gehandhabt werden. Grüße, Tim

Tim Lochmüller am 02. Juli 2019 um 13:01

Moin Tim,
das habe ich mir gedacht, dass das eigentlich so sein soll. Habe nun deine Extension auf drei verschiedenen Seiten laufen und auf allen habe ich oben beschriebenes Verhalten. Daher URLs die eigentlich einen 404-Fehler zeigen sollten leiten wie oben beschrieben weiter. Ich bin mir recht sicher, dass das mit der .htaccess zusammenhängt. Deaktiviere ich deine Extension zeigen diese URLs wie gehabt den Standard Typo3 404-Fehler.

Jan am 02. Juli 2019 um 13:18

Kannst du einmal prüfen, welche Regeln zu dem Verhalten führen. Wenn es an der htaccess liegt, dann müsste es egal sein ob die Extension installiert oder deaktiviert ist. Dann sind vermutlich regeln falsch. Bitte prüf dies einmal und mache gerne ein Ticket auf GitHub auf. Dann würde ich mir dies ebenfalls einmal anschauen. Grüße, Tim

Tim Lochmüller am 02. Juli 2019 um 14:00

Hallo Tim,

gibt es eigentlich eine Lösung zum Einsatz von staticfilecache UND indexed_search.
Ich habe auf der Website ein Suchfeld (Plugin) eingebunden, und es indexed_search setzt zum Indizieren TSFE no_cache = 1.
Dadurch werden keine Seiten gecached -.-
Quasi Frage 1 hier:
https://github.com/lochmueller/staticfilecache/blob/master/Documentation/Faq/Index.rst

Im Netz gibt es keine Lösung zum Einsatz beider Extensions parallel.

Hast du eine Idee?

Gruß
André

Andre am 30. September 2019 um 10:03

Hey André, indexed_search wird glaub ich nicht „no_cache = 1“ setzen, weil dann wäre auch nichts im Index?! Ich vermute, dass dere Fehler an einer anderen Stelle in deiner Konfiguration liegt. Generell gibt es keinen Konflikt zwischen indexed_search und staticfilecache. Habe selbst auch einige Seiten wo die Plugin koexistieren. Wenn es nur daran liegt, dass der Suchschlitz in der Seite ein USER_INT ist, dann würde ich das Formular einfach mit FLUID rendern (ohne das Plugin zu benutzen). Grüße, Tim

Tim Lochmüller am 30. September 2019 um 11:49

Kategorien

Archiv