[TYPO3-german] Re: backend seite nicht erreichbar oder wird umgeleitet
Deaktiviere doch mal die htaccess einfach mal umbennenen... dann weist du ob es daran liegt. Php 5.3 deutet auf typo3 4 hin... ganz dringend updaten! ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
[TYPO3-german] Re: DRK Musterseite mit Typo3 7.6 Probleme
Guck dir den pfad an, der ist falsch... also mal suchen wo und wie die Datei eingebunden ist, und entsprechend ändern.. :-) /homepages/2/d120002940/htdocs/CMS_neu/typo3_src-7.6.21/typo3conf/ext/drk_template_2016/Classes/ViewHelpers/ImageInterchangeViewHelper.php ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
[TYPO3-german] Re: Eigene Gallery Settings
Schreib mal was du genau machen möchtest, dann können wir dir besser helfen, da es in t3 immer mehrere wege gibt. Die sind je nach dem mal mehr mal weniger sinnvoll...:-) Nutzt du fluid templates? Am einfachsten ist es wohl das layout feld unter erscheinungsbild zu nutzen... google mal danach :-) ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
[TYPO3-german] Re: ckeditor .yaml: contentsCSS auf .css in fileadmin verweisen lassen
Wird deine yaml denn auch geladen? Das mit 1: steht auch so in der default ... mitgelieferten base.yaml... guck dir die mal an. Sprich sollte funktionieren, allerdings bin ich mir da gerade nicht sicher :-) Wenn das mit ../ funktioniert, warum lässt du es nicht so? https://typo3worx.eu/2017/02/configure-ckeditor-in-typo3/ ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Caching von Webserviceantworten
Hallo Fabian. > Aber wie mache ich es dann? Ich muss ja irgendwie aus der XML-Antwort meine > Objekte basteln, über die ich dann im Fluid Template iteriere und die > Tabellen zusammensetze. Das ist genau der Punkt. Du wirst also erst in einem „findAll()“ alle Objekte aus der Datenbank holen. Dann lässt Du Dir über den SOAP-Request alle XMLe geben. Jetzt kannst Du in einer geschachtelten Schleife über beide drüber iterieren und prüfen welche zu aktualisieren sind, welche neu zu erstellen und welche zu löschen. Das kostet Dich natürlich erstens ganz massiv RAM. Und zweitens musst Du das reine Synchronisations-Hilfsmittel „tstamp“ als Property Deines Models mappen – obwohl der tstamp überhaupt nichts mit Deiner Domäne zu tun hat. Der gehört da also schlicht nicht hin. Du bläst damit Deine Domäne also mit „Kram“ auf. Dann kommt alles mit Repository->add(), Repository->update() oder Repository->delete() in die Datenbank, und unter Umständen musst Du dann ein „persistAll()“ aufrufen damit ein anschließender Filter-Query auch wirklich die aktualisierten Daten aus der Datenbank bekommt. Ohne das persistAll() werden die Persistenzoperationen durchgeführt, *nachdem* die Action erfolgreich durchlaufen wurde. Ein „findByIrgendwas()“ innerhalb der Action wenn in den ersten Zeilen der Action neue Daten in die Datenbank gekommen sind wird diese neuen Daten sonst nicht finden. Wenn Du jetzt noch „updateoptimiert“ z.B. ein Plugin hast das nur die Daten von 2017 haben möchte, ein weiteres Plugin das nur die Daten einer bestimmten Kategorie aber dafür zeitunabhängig haben möchte und ein drittes Plugin das alle Daten sortiert nach Titel dafür mit Pagination anzeigen soll. Dann tust Du Dir schon schwer, wirklich sinnvoll auf Basis einer solchen Teilmenge zu ermitteln, welche deiner lokalen Daten gelöscht werden sollen oder welche neu sind. Das heißt Du musst für jede Plugin-Filter-Teilmenge sowohl den Extbase-Query als auch die SOAP-Anfrage so hin optimieren, dass sie die exakt identischen Werte liefern. Andernfalls legst Du Daten an die es schon gibt (wenn sie von Deinem Extbse-Query ausgefiltert wurden aber über SOAP kommen) oder löchst Daten die Du eigentlich noch brauchst (wenn der Extbase-Query zu lasch war und mehr Datenliefert als Du anzeigen möchtest). Sobald Du jetzt die Logik was eigentlich wirklich angezeigt werden soll noch den Redakteur überlässt. Denk wieder an News. Filter nach Kategorie, mehrere Kategorien AND- oder OR-Verknüpft, Kategoriefilter negiert, absteigend oder aufsteigend sortiert, beschränkt auf Datum. All diese Optionen kann der Redakteur im News-Plugin selbst wählen. Und jetzt bau das mal als SOAP-Anfrage nach, damit sie im Frontend zum Synchronisationszeitram zu 100% auf den vom Redakteur gewählte Extbase-Filter-Query passt. ⇨ Sync zur Laufzeit erzeugt einen wahnsinnigen Kraut-und-Rüben-Code, bläst Dein Model auf und kostet RAM im Web-Request. > Leider liefert der Webservice kein Änderungsdatum o.Ä. an dem ich entscheiden > könnte, ob aktualisieren, nicht aktualisieren oder löschen. Bleibt also > nichts Anderes übrig als lokal zu entscheiden mittels timestamp, oder? Wenn Dir der SOAP-Request keine Verändungsinformationen gibt, also weder eine Objekt-Version noch ein Änderungsdatum, dann kannst Du überhaupt nichts entscheiden. Dann musst Du wohl oder übel das Objekt speichern wenn Du es bekommst. > Da hast du natürlich recht. Ich werde also die getrennte Lösung per Scheduler > vorziehen. Ich würde wirklich genau einen einzigen Sync-Durchlauf per Scheduler machen der das komplette Model lokal aufbaut. Anschließend kannst Du in Deinem lokalen Model noch filtern und sortieren wie Du lustig bist. Kein Filter, keine Sortierung. Der Scheduler-Durchlauf muss auch überhaupt nicht mit Extbase arbeiten. Mindestens die Datenmanipulation kann – gerade wenn es möglicherweise viele Daten sind – auch einfach durch den DataHandler passieren. Beste Grüße, Stephan Schuler Web-Entwickler | netlogix Web Solutions Telefon: +49 (911) 539909 - 0 E-Mail: stephan.schu...@netlogix.de Web: websolutions.netlogix.de Neu: Wir sind Amazon Web Services Partner. Mehr erfahren: https://websolutions.netlogix.de/technologie/amazon-web-services-aws netlogix GmbH & Co. KG IT-Services | IT-Training | Web Solutions Neuwieder Straße 10 | 90411 Nürnberg Telefon: +49 (911) 539909 - 0 | Fax: +49 (911) 539909 - 99 E-Mail: i...@netlogix.de | Web: http://www.netlogix.de netlogix GmbH & Co. KG ist eingetragen am Amtsgericht Nürnberg (HRA 13338) Persönlich haftende Gesellschafterin: netlogix Verwaltungs GmbH (HRB 20634) Umsatzsteuer-Identifikationsnummer: DE 233472254 Geschäftsführer: Matthias Schmidt ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Caching von Webserviceantworten
Hallo, Es wäre schön, wenn ich Dich mit Namen ansprechen könnte. Ein sinnvoller Absender und eine Grußformel an Ende wäre dabei hilfreich. Hab mein Profil mal angepasst, aber keine Ahnung, ob und wann das auf das Forum durchschlägt. Ich würde das nach Möglichkeit entkoppeln und per Scheduler synchronisieren. Eine Synchronisation zur Laufzeit mit gleichzeitigem lokalem persistenten Model ist keine gute Idee, dann machst Du alles von Hand. Angefangen damit, dass Du Dir überlegen musst, welcher dieser Requests jetzt diese Daten aktualisieren muss und welche nicht. Sprich: Du musst Dir bei jedem Objekt das „last synced" merken um zu entscheiden, ob das zu synchronisieren ist oder nicht. Natürlich hat der Datensatz bereits das Attribut „tstamp" womit die letzte Modifikation in der Datenbank gemeint ist. Aber dieser tstamp gehört ja eigentlich nicht in deine Domäne. Das ist ein Hilfsmittel, ein Werkzeug. Ein eine Object-Property des Extbase Domain-Models würde ich den tstamp nicht mappen solange er nicht wirklich im Frontend für den Benutzer als „letzte Änderung: Vor 15 Minuten" o.ä. angezeigt werden soll. Wenn Du die Synchronisation in einen Scheduler packst ist klar: Jedes Mal wenn der läuft synchronisiert der. Aber wie mache ich es dann? Ich muss ja irgendwie aus der XML-Antwort meine Objekte basteln, über die ich dann im Fluid Template iteriere und die Tabellen zusammensetze. Die Aufteilung in den Teil der sich geändert hat und den Teil der sich nicht geändert hat kannst Du im Scheduler immer noch durchführen. Lass Dir eine Liste aller Objekte geben, evtl. mit reduziertem Datenumfang. Diejenigen die im SOAP-Request ein Änderungsdatum neuer als tstamp lokal haben sind lokal zu aktualisieren. Die die im SOAP-Request ein Änderungsdatum älter als tstamp haben kannst Du in Ruhe lassen. Die die lokal existieren aber nicht über den SOAP-Request kommen musst Du lokal löschen. Insbesondere die Entscheidung welches Objekt ggf. zu löschen ist kannst Du nur über Bande treffen wenn Du im Controller des Frontend-Requests synchronisierst. Leider liefert der Webservice kein Änderungsdatum o.Ä. an dem ich entscheiden könnte, ob aktualisieren, nicht aktualisieren oder löschen. Bleibt also nichts anderes übrig als lokal zu entscheiden mittels timestamp, oder? Weiterhin bringt Dir bei der Synchronisation im Frontend die Extbase-Persistenz eigentlich keinen relevanten Vorteil. Wenn Du stattdessen den Plugin eine Stunde lang als HTML-Snippet cachen kannst, genügt es, die Objekte oer SOAP zu holen, an Fluid zu übergeben und nach dem PHP-Request wieder zu vergessen. Der dritte, weit schlimmste Nachteil der Synchronisation im Controller ist, dass Du Deine Frontend-Laufzeit von fremden Servern abhängig machst. Wenn der SOAP-Server mal nen schlechten Tag hat und ein paar Sekunden für die Antwort braucht, oder gar nicht antwortet, weil irgendwas hängt, dann hängt auch Dein Frontend. Solange Du Deine Daten nicht in der Datenbank als geändert schreibst (sprich: die Nicht-Antwort des SOAP-Servers als leeres Result und damit Löschanweisung interpretierst) bedeutet das für Dein Frontend, dass mehrfache Anfragen im Frontend jeweils parallel auf die Idee kommen, für die Synchronisation zuständig zu sein, und alle hängen am hängenden SOAP-Server fest. Dein Webserver hat ja nicht unendlich viel Arbeitsspeicher und kann damit nicht unendlich viele PHP-Prozesse gleichzeitig bedienen. Wenn Du für das Betriebssystem 1GB RAM abziehst und jedem PHP-Prozess 64MB RAM spendierst kansnt Du Dir ausrechnen, wie viele parallele PHP-Prozesse Du Dir erlauben kannst ohne dass der Server swappen muss. Die Zahl liegt mit großer Wahrscheinlichkeit im unteren zweistelligen Bereich. Wenn die Seite mit der Tabelle jetzt etwas Load hat, vielleicht vom ein oder anderen Crawler gefunden wird, wenn Du jetzt auch noch ungeduldige Webseitenbesucher hast die nach 10 Sekunden Ladekringel gleich auf reload drücken, dann hast Du sehr schnell alle Deine PHP-Prozesse damit belegt, auf den nicht mehr reagierenden SOAP-Server zu warten. Ab diesem Zeitpunkt sind Frontend und Backend nicht mehr erreichbar. Da hast du natürlich recht. Ich werde also die getrennte Lösung per Scheduler vorziehen. Gruß, Fabian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
[TYPO3-german] Spaß mit Daten
Hallo Liste Ich habe in einer eigenen Extension eine Klasse namens Event, diese enthält die Eigenschaft "Date". Wenn ich ein Event im Backend anlege, und z.B. 14.08.2017 15:50 Uhr angebe habe ich folgendes Problem: Vorgabe beim Abspeichern: 2017-08-14 15:50:00 In der Datenbank: 2017-08-14 15:50:00 In der Listenansicht im Backend: 14-08-17 15:50 -> auf bearbeiten klicken In der Bearbeitungs-Ansicht als Titel des Event: 14-08-17 17:50 In der Bearbeitungs-Ansicht vorausgefüllt im Input: 15:50 14-08-2017 In der IRRE-Ansicht als Teile einer anderen Klasse: 14-08-17 17:50 In der IRRE-Ansicht als Teile einer anderen Klasse vorausgefüllt im Input: 15:50 14-08-2017 Als Fluid-Objekt im Frontend: DateTime prototype object (2017-08-14T17:50:00+02:00, 1502725800) Ich habe dazu diesen Bug gefunden: https://forge.typo3.org/issues/68651 Aber alle Lösungsvorschläge die dort genannt werden beseitigen zumindest die falschen Ansichten mit 17 Uhr im Backend nicht. Hat da jemand Anders vielleicht eine Lösung zu? Liebe Grüße, Sebastian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Caching von Webserviceantworten
Hallo! Es wäre schön, wenn ich Dich mit Namen ansprechen könnte. Ein sinnvoller Absender und eine Grußformel an Ende wäre dabei hilfreich. Ich würde das nach Möglichkeit entkoppeln und per Scheduler synchronisieren. Eine Synchronisation zur Laufzeit mit gleichzeitigem lokalem persistenten Model ist keine gute Idee, dann machst Du alles von Hand. Angefangen damit, dass Du Dir überlegen musst, welcher dieser Requests jetzt diese Daten aktualisieren muss und welche nicht. Sprich: Du musst Dir bei jedem Objekt das „last synced“ merken um zu entscheiden, ob das zu synchronisieren ist oder nicht. Natürlich hat der Datensatz bereits das Attribut „tstamp“ womit die letzte Modifikation in der Datenbank gemeint ist. Aber dieser tstamp gehört ja eigentlich nicht in deine Domäne. Das ist ein Hilfsmittel, ein Werkzeug. Ein eine Object-Property des Extbase Domain-Models würde ich den tstamp nicht mappen solange er nicht wirklich im Frontend für den Benutzer als „letzte Änderung: Vor 15 Minuten“ o.ä. angezeigt werden soll. Wenn Du die Synchronisation in einen Scheduler packst ist klar: Jedes Mal wenn der läuft synchronisiert der. Die Aufteilung in den Teil der sich geändert hat und den Teil der sich nicht geändert hat kannst Du im Scheduler immer noch durchführen. Lass Dir eine Liste aller Objekte geben, evtl. mit reduziertem Datenumfang. Diejenigen die im SOAP-Request ein Änderungsdatum neuer als tstamp lokal haben sind lokal zu aktualisieren. Die die im SOAP-Request ein Änderungsdatum älter als tstamp haben kannst Du in Ruhe lassen. Die die lokal existieren aber nicht über den SOAP-Request kommen musst Du lokal löschen. Insbesondere die Entscheidung welches Objekt ggf. zu löschen ist kannst Du nur über Bande treffen wenn Du im Controller des Frontend-Requests synchronisierst. Weiterhin bringt Dir bei der Synchronisation im Frontend die Extbase-Persistenz eigentlich keinen relevanten Vorteil. Wenn Du stattdessen den Plugin eine Stunde lang als HTML-Snippet cachen kannst, genügt es, die Objekte oer SOAP zu holen, an Fluid zu übergeben und nach dem PHP-Request wieder zu vergessen. Der dritte, weit schlimmste Nachteil der Synchronisation im Controller ist, dass Du Deine Frontend-Laufzeit von fremden Servern abhängig machst. Wenn der SOAP-Server mal nen schlechten Tag hat und ein paar Sekunden für die Antwort braucht, oder gar nicht antwortet, weil irgendwas hängt, dann hängt auch Dein Frontend. Solange Du Deine Daten nicht in der Datenbank als geändert schreibst (sprich: die Nicht-Antwort des SOAP-Servers als leeres Result und damit Löschanweisung interpretierst) bedeutet das für Dein Frontend, dass mehrfache Anfragen im Frontend jeweils parallel auf die Idee kommen, für die Synchronisation zuständig zu sein, und alle hängen am hängenden SOAP-Server fest. Dein Webserver hat ja nicht unendlich viel Arbeitsspeicher und kann damit nicht unendlich viele PHP-Prozesse gleichzeitig bedienen. Wenn Du für das Betriebssystem 1GB RAM abziehst und jedem PHP-Prozess 64MB RAM spendierst kansnt Du Dir ausrechnen, wie viele parallele PHP-Prozesse Du Dir erlauben kannst ohne dass der Server swappen muss. Die Zahl liegt mit großer Wahrscheinlichkeit im unteren zweistelligen Bereich. Wenn die Seite mit der Tabelle jetzt etwas Load hat, vielleicht vom ein oder anderen Crawler gefunden wird, wenn Du jetzt auch noch ungeduldige Webseitenbesucher hast die nach 10 Sekunden Ladekringel gleich auf reload drücken, dann hast Du sehr schnell alle Deine PHP-Prozesse damit belegt, auf den nicht mehr reagierenden SOAP-Server zu warten. Ab diesem Zeitpunkt sind Frontend und Backend nicht mehr erreichbar. Um Himmels Willen führ Kommunikation mit fremden Servern erstens mit dem geringstmöglichen Timeout durch und zweitens sofern nur irgend möglich asynchron. Beste Grüße, Stephan. Stephan Schuler Web-Entwickler | netlogix Web Solutions Telefon: +49 (911) 539909 - 0 E-Mail: stephan.schu...@netlogix.de Web: websolutions.netlogix.de Neu: Wir sind Amazon Web Services Partner. Mehr erfahren: https://websolutions.netlogix.de/technologie/amazon-web-services-aws netlogix GmbH & Co. KG IT-Services | IT-Training | Web Solutions Neuwieder Straße 10 | 90411 Nürnberg Telefon: +49 (911) 539909 - 0 | Fax: +49 (911) 539909 - 99 E-Mail: i...@netlogix.de | Web: http://www.netlogix.de netlogix GmbH & Co. KG ist eingetragen am Amtsgericht Nürnberg (HRA 13338) Persönlich haftende Gesellschafterin: netlogix Verwaltungs GmbH (HRB 20634) Umsatzsteuer-Identifikationsnummer: DE 233472254 Geschäftsführer: Matthias Schmidt ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
[TYPO3-german] DRK Musterseite mit Typo3 7.6 Probleme
Hallo zusammen, ich hoffe sehr, dass ich hier Hilfe finden werde, da ich mich derzeit sehr mit Typo3 rumärgere. Ich hab keine Erfahrung damit und komme dazu noch aus einer verwöhnten Wordpress / Joomla Welt :) Ich bin damit beauftragt worden für unseren DRK Ortsverein Typo3 7.6 aufzusetzen. Soweit so gut. Installation, Datenbank Import, Import der Musterseiten scheint soweit geklappt zu haben...hoffe ich. Hoster ist 1&1, PHP Version 5.6 oder 7.0, beides schon probiert. PHP.ini mit folgenden Werten liegt im Typo3 Verzeichnis: memory_limit >= 256M max_execution_time >= 240s max_input_vars >= 1500 compilation option disable-ipv6 must not be used Jetzt wirft mir Typo3 beim Aufruf der Seite folgende Meldung, meine anderen Seiten scheinen auch nicht wirklich vollständig zu sein: Uncaught TYPO3 Exception #1289386765: Could not analyse class: "Drk\DrkTemplate\ViewHelpers\ImageInterchangeViewHelper" maybe not loaded or no autoloader? PHP Warning: Declaration of Drk\DrkTemplate\ViewHelpers\ImageInterchangeViewHelper::render($src = NULL, $interchangeSettings = NULL, $treatIdAsReference = false, $image = NULL) should be compatible with TYPO3\CMS\Fluid\ViewHelpers\ImageViewHelper::render($src = NULL, $width = NULL, $height = NULL, $minWidth = NULL, $minHeight = NULL, $maxWidth = NULL, $maxHeight = NULL, $treatIdAsReference = false, $image = NULL, $crop = NULL, $absolute = false) in /homepages/2/d120002940/htdocs/CMS_neu/typo3_src-7.6.21/typo3conf/ext/drk_template_2016/Classes/ViewHelpers/ImageInterchangeViewHelper.php line 20 (More information) TYPO3\CMS\Extbase\Object\Container\Exception\UnknownObjectException thrown in file /homepages/2/d120002940/htdocs/CMS_neu/typo3_src-7.6.21/typo3/sysext/extbase/Classes/Object/Container/ClassInfoFactory.php in line 37. Die Hilfe Seite von Typo3 bringt mich kein Stück weiter. Hat jemand ne Idee? Wie gesagt: die Subseiten der DRK-Musterseiten scheinen von der Struktur her zu gehen, es fehlen allerdings Bilder und es sieht chaotisch aus. Grüße Frank ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
[TYPO3-german] Eigene Gallery Settings
Hallo Typo3 Freaks ;), ich bin noch neu in Typo3 und auch noch relativ unerfahren was Typoscript angeht. Ich habe in meinem aktuellen Projekt ein kleines Problem mit den Gallery Settings der Content Elements. Gäbe es einen weg eine eigene Einstellung zu erstellen die später auch Update sicher wäre? Aktuell trete ich auf der stelle und komm nicht so richtig weiter. Gruß Konzule ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
[TYPO3-german] Re: ckeditor .yaml: contentsCSS auf .css in fileadmin verweisen lassen
Danke Dir, gut zu wissen für die Anwendung in TypoScript. In der .yaml funktioniert das offenbar nicht. Oder ich stelle mich zu doof an. Hier der Code meinerr .yaml: #Das funktionierte: #contentsCss: "../fileadmin/t3/css/rte.css" #Präfix "1:" funktionert nicht: contentsCss: "1:t3/css/rte.css" ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
[TYPO3-german] Re: ckeditor: Auswahllisten Stil und Format haben keinen Eintrag zur Abwahl
Im alten RTE sah der Listeneintrag für das Entfernen eines Stils so aus: http://www.typo3-handbuch.net/?id=212 So hätte ich es mir gewünscht. Von selbst wäre ich nicht drauf gekommen - aber um einen Blockstil abzuwählen, muss man ihn wiederholt in der Liste anklicken. Der Listeneintrag funktioniert also wie ein An/Aus-Knopf. ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
[TYPO3-german] Re: backend seite nicht erreichbar oder wird umgeleitet
Quote: Webdesigner (typo3userberlin) wrote on Mon, 12 September 2016 16:36 Beitrag wurde gelöscht -- - Heute standen wir noch am Abgrund - morgen sind wir ein Stück weiter - ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
[TYPO3-german] Re: Horizontales Drobdown Menu -aber wie
Beitrag gelöscht -- - Heute standen wir noch am Abgrund - morgen sind wir ein Stück weiter - ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
[TYPO3-german] Re: Backend - weisse seite !
Quote: Webdesigner (typo3userberlin) wrote on Wed, 30 October 2013 15:20 Beitrag wurde gelöscht ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Caching von Webserviceantworten
Ok, mit so einer ausführlichen Atnwort hab ich nicht gerechnet. Danke! Quote: Stephan Schuler wrote on Fri, 11 August 2017 14:02 Eine Variante wäre, die Remote-Daten als lokale Domäne abzubilden und per Scheduler einen Import zu bauen. Wenn z.B. ein beliebiges JSON- oder XML-Format verwendet wird um Daten bereitzustellen die in TYPO3 als News angezeigt werden sollen bietet es sich ja an, alle paar Minuten die Daten remote abzufragen und in lokale News-Records zu überführen. Der Vorteil daran ist natürlich, dass man keinen gesonderten Renderingprozess für diese News konfigurieren muss, wenn es ohnehin schon anderweitige, lokale News gibt. Das ist der Weg, den ich so jetzt auch gegangen wäre. Vorab zum Verständnis grad nochmal was ich brauche: Ich möchte eine Extension bauen, die den Redakteuren ein Frontend Plugin zur Verfügung stellt, welches sie auf beliebigen Seiten einfügen können. Dieses Plugin soll letztendlich Daten eines Webservice (genauer handelt es sich dabei um Veranstaltungsdaten (Termin, Ort, etc.)) tabellarisch aufbereiten und anzeigen. Der Redakteuer hätte in der Plugin Konfiguration gewisse Einstellungsmöglichkeiten, was genau angezeigt werden soll (aus diesen Einstellungen wird die Request für den Webservice gebaut). Die angezeigten Daten müssen von Zeit zu Zeit aktualisiert werden (nehmen wir als Richtwert mal an das die Daten immer 1 Stunde lang gültig sind). Stellt sich für mich nur noch die Frage, ob ich die Aktualisierung der Remote-Daten per Scheduler oder im Controller durchführe. Ersteres scheint mir eigentlich der sauberere Weg zu sein, allerdings sehe ich beim Controller den Vorteil, dass nur Einträge aktualisiert werden, die auch abgefragt werden. Seiten mit dem Plugin, die nicht aufgerufen werden, müssen ja nicht aktuell sein. Nachteil wäre halt, dass es jede Stunde einen Nutzer trifft, der einige Sekunden warten muss, bis die Remote-Daten neu abgefragt wurden. Auch wenn man in eine lokale Suche die Remote-Daten integrieren möchte bietet sich dieser Schritt an. Wenn man erst einen Import von einer Remote-API in lokale Datensätze durchführt, kann im Folgeschritt z.B. ein Solr-Indexing-Task die Daten in den Solr schaufeln und sie sind im Frontend über die Suche verfügbar. Dabei sollte der Import natürlich über den TYPO3 DataHandler durchgeführt werden, weil das die zentrale Stelle ist, die sowohl eine für Redakteure nachvollziehbare History erzeugt also auch der API-Call, an den sich wiederum Record-Indexer wie eben Solr hängen um innerhalb von TYPO3 über Datenänderungen informiert zu werden. Auch was Caching innerhalb einer TYPO3-Seite betrifft (Cache-Tags im Caching-Framework) ist die Verwendung des DataHandler dringend angeranten. Eine Verfügbarkeit der Daten über eine Suche ist nicht nötig. Eine weitere Möglichkeit ist ein Runtime-Cache. Der API-Aufruf ist sicherlich in irgendeiner Form ein HTTP GET-Request. Das heißt hier gibt es eine URL aus der sich ein Cache-Identifier ableiten lässt sowie einen Response-Body der der Cache-Content sein kann. Hier rate ich dringend dazu, nicht irgendeine selbst erfundene Datenbankstruktur zu verwenden, sondern das Caching-Framework. Für die Speicherung der Daten gibt es unterschiedliche Backends, nämlich u.a. dateibasiert, datenbankbasiert, memcache oder redis. Je nach Bedarf und Verfügbarkeit. Dem Konsumenten des Caches gegenüber stellt man die Daten dan entweder über das Variable-Frontend zur Verfügung (z.B. wenn es sich um Array oder Objekte handelt) oder über das String-Frontend (wenn der Konsument den Text-Body bekommen soll). Wenn der Cache richtig konfiguriert ist, lässt er sich über die „Clear Cache"-Buttons im Backend rechts oben ganz einfach leeren, wodurch das auch von Redakteuren bedient werden kann. Oder auch ein „Clear all Caches" wie man es ja vermutlich im Rahmen jedes Code-Deployments anstößt (Stichwort CLI-API!) nimmt das Caching-Framework, man muss sich also nicht selbst darum kümmern. Ja, der Webservice wird über eine SOAP-Request angesprochen. Werde mir diese Möglichkeit mal genauer ansehen. In beiden Fällen ist natürlich kein Weg beschrieben, wie Inhaltsänderungen des Providers an TYPO3 kommuniziert werden können. Das heißt, dass Du Dir eine Cache-Lifetime ausdenken musst die im Zweifelsfall zu kurz oder zu lang ist. Eine Lifetime von wenigen Minuten könnte dafür sorgen, dass Du trotzdem an ein anbieterseitiges Request-Limit stößt. Eine Lifetime von mehreren Minuten dagegen sorgt immer für panische Anrufe von Redakteuren, warum die Inhaltsänderung nicht sofort auch in TYPO3 sichtbar ist. Hier sollte es im Idealfall Empfehlungen des API-Providers geben an die man sich halten kann. Dann lassen sich diese Empfehlungen dem Kunden kommunizieren und die panischen Redakteure können mit Fakten beruhigt werden. Wenn es sich um einen HTTP GET-Request handelt der seinerseits Cache-Header enthält,
