Welche Entwickler außer xtra und leo.unglaub lesen eigentlich die Änderungen im SVN mit und testen (mehr oder weniger) regelmäßig die neuesten Builds?
Druckbare Version
Welche Entwickler außer xtra und leo.unglaub lesen eigentlich die Änderungen im SVN mit und testen (mehr oder weniger) regelmäßig die neuesten Builds?
Ich schaue ungefähr einmal in der Woche da rein, testen tue ich allerdings nicht so regelmäßig.
Carolina,
Mit "mitlesen" meine ich auch hauptsächlich, die einzelnen Revisionen anzuschauen und die Änderungen auf eventuelle Fehler zu prüfen. Ein Test nach jedem Commit wäre doch recht zeitaufwändig :)
Ich schaue oftmals rein, manchmal aus zeitvertreib, aber als wirklich konstantes testen dients nicht. Dazu fehlt mir die Zeit.
Stellenweise mal zum ausprobieren, aber mehr nicht.
"Nightly build" ist für mich ein Synonym für "verschiedene Änderungen" :) Gibt es da einen gebräuchlicheren Ausdruck?
Hi,
Wie im Eingangspost schon angefyhrt, ich checke den trunk regelmaessig aus und diffe durch wobei ich alles durchsehe.
Betreffend der "nightly builds". Nightly ist i.d.R. ein automatischer commit/build eines files.
Was du machst ist eigentlich ein regulaerer commit mit "various minor fixes" ohne zugehoerige Tickets und genauere Beschreibung.
Wenn ich etwas derartiges commite, dann schreibe ich meist obigen Satz oder aber "committing current workspace" oder so was in der Art, jedoch nur, wenn ich "zu faul" zu einem check bin, was ich alles geaendert habe.
Allgemein gesehen bist du jedoch vollkommen frei damit, wie du deine commits benennst, also ist auch nightly build vollkommen in Ordnung, und irgendwo auf dem Erdenball ist ja auch immer Nacht, von daher wen interessiert schon der Name der draufsteht, solange der Inhalt passt. ;)
Gruss
Chris
PS: Ich denke es werden auch noch einige den svn mitlesen, die nicht hier im Board sind. Was meint denn deine Serverstatistik?
Ich verfolge fast täglich die Änderungen im SVN und lade i. d. R. mehrmals die Woche die aktuelle Revision herunter. Ausführliche Tests führe ich zwar nicht durch, aber installiere (je nach Änderungen in der Revision) auch mal einen Nightly auf einer Live-*/Test-Seite und lokal und probiere einige Änderungen durch bzw. ob meine Installation(en) noch laufen (also inklusive 3rd-Party-Erweiterungen).
* Ja, sollte man nicht, aber ich schau mir den geänderten Code immer vorher an …
Gut, dann weiß ich ja erstmal, wen ich bei Rückfragen kontaktieren kann :)
Wir kommen jetzt so langsam in den Bereich des finalen Release, daher sind Tests nicht verkehrt. Viele Erweiterungen sind schon angepasst und der trunk ist bis auf das letzte offene Ticket (Contextmenü statt zusätzlichem Edit-Button) Feature-complete. Ich werde diese Woche noch https://contao.org umstellen, damit auch die Übersetzer ihre Arbeit abschließen können. Dann kann die 2.8 gegen Ende Februar kommen.
Und ich kann es nicht oft genug sagen: Vielen Dank für eure Hilfe!
Kriegen wir den __autoload hook evtl. auch noch rein? :)Zitat:
Zitat von leo
Gerne geschehen, ich mein, wir profitieren doch auch in hoechstem Masse davon.Zitat:
Zitat von leo
Gruss
Chris
Ich fürchte nicht, da hier noch überhaupt keine Einigung in irgendeine Richtung stattgefunden hat. Ich möchte noch prüfen, ob man nicht eine "if function_exists('spl_autoload')"-Version erstellen kann. Daneben möchte ich auch prüfen, wie sich ein Verzicht auf den Autoloader auf die Performance auswirkt (die Dateien würden dann explizit über eine eigene Funktion eingebunden). Die Array-Lösung scheint mir überdimensioniert, denn wenn der Speicherort einer Datei sowieso klar ist, kann man sie ja auch direkt einbinden. Es geht also hauptsächlich um Modul-Dateien und Plugins, die ebenfalls den Autoloader nutzen.Zitat:
Zitat von xtra
Falls Du für eine Erweiterung kurzfristig eine Lösung benötigst, baue ich Dir gerne noch einen exklusiven Hook ein (Anfrage bitte im Ticket). Grundlegende Änderungen möchte ich aber zuerst ausführlich testen.
Hallo,
ich schaue über das Ticketsystem gelegentlich auch mal die Änderungen rein, denn dadurch sieht man wie du ein Problem gefixt hast, während man vorher nur alle Ändeurngen gesehen hat und somit nicht wusste, welche Änderung welchen Bug behoben hat. Von daher sage ich auch mal danke für das SVN :). Zum testen mit dem SVN-Build kam ich bisher nicht (außer einem Commit kurz nach der Einführung), da mit momentan für TL die Zeit leider fehlt.
Unter Windows hatte ich mal eine Performancemessung gemacht. Dabei war __autoload eindeutig ein deutlich langsamer als die direkte Einbindung. Von daher mache ich es bei meinen Projekten inzwischen immer so, dass alles direkt eingebunden wird, wo man weiß, dass man sie von Anfang an braucht - den Rest kann man per __autoload machen, da selbstgeschrieben Methoden aufwändiger sind und nur wenig bis keine Performancevorteile bringen.Zitat:
Zitat von leo
Hallöchen,
lese grad erstaunt man könne bereits das SVN ausschecken.
Hab ich noch garnicht mitbekommen.
Gibts da ein besonderen Link oder den ich im Projektarchiv sehe?
Sonst Hinweise dazu?
Mit SVN kenn ich mich an sich aus.
Infos gibt es hier: https://contao.org/typolight-entwick...tml#repository
Hatte es auch eher per Zufall erfahren ;).
Gern geschehen, auch wenn die Hilfe zur Zeit begrenzt ist ;).Zitat:
Zitat von leo
Danke, werd ich gleich mal versuchen.Zitat:
Zitat von FloB
Nachtrag: ach geht das schön schnell.... :D
Ich hab eine Testversion auf dem Server, die ich immer wöchentlich auf den aktuellsten Stand bringe. Allerdings nutze ich sie zumeist für meine eigene Modulentwicklung und nutze von daher zwar den Core aber kaum eine Erweiterung.
Bei den Tickets habe ich gerade erst angefangen einen Überblick zu gewinnen.
MFG JPP
Ich zieh mir gelegentlich neue Dateien auf eine Testinstallation, um bei der Entwicklung von Erweiterungen auch immer die Weiterentwicklung des TL-Core im Auge zu behalten. Vor allem bzgl. der Frameworknutzung und der Kompatibilitätsprüfung.
Gruß
ChrMue
Aufgrund dieses Threads habe ich erstmals in das Projektarchiv hineingesehen. Es ist ja toll, wie schnell man dort die Änderungen herausfinden kann. Ich schaue jetzt sicherlich auch öfter mal vorbei.
Für mein Ticket #1472 habe ich aber noch eine Bemerkung im Ticket eingetragen:
http://https://contao.org/issues/show/1472
Wie kann man ein reOpen machen?
Bei der Lösung fehlt nämlich noch eine Kleinigkeit.
EDIT: Es ist wohl noch zu früh! Hat sich erledigt - Leo hat bereits reagiert, ich hatte nur noch keine Mail bekommen. Sorry für die Aufregung
Hallo Leo,
um auf deine Frage zurück zukommen, ich werde in Zukunft öfters mal auschecken, jedoch nur wenn es meine Module betreffen könnte.
Mehr Zeit hab ich leider nicht.
Sollte ansonsten ein wichtiges Feature / Bugfix bei sein, wo viel Tester nötig sind, dann sicherlich auch.
Ich musste gerade noch mal eine Änderung an der Funktion "getAllEvents()" vornehmen, die ja bekanntlich den größten Teil der Eventlogik steuert und daher durchaus als "heikle Funktion" bezeichnet werden kann :)
Könntet ihr bitte - sofern ihr irgendwo die Kalender-Erweiterung nutzt - die Änderungen in der r149 ausführlich testen und mir eine Rückmeldung geben, wenn etwas nicht funktioniert?
Am Wochenende werde ich die noch offenen Tickets bearbeiten, so dass die 2.8.2 möglichst Anfang nächster Woche erscheinen kann. Voraussichtlich ab Samstag Nachmitag/Abend kann (und sollte) getestet werden.
wow, wird dann ja ein stressiges WE... :cool:
Diese Thread hat mich auf die Idee gebracht: Ich hab mir jetzt ein E-Mail Abo für die Änderungen angelegt, und lese somit zumindest mit welche Dateien sich mit welcher Commit-Message geändert haben :cool:
Teste auch grad.
cool Sache das mit dem white theme von Mediabox ( http://https://contao.org/issues/1651 ) und dem Tipp für den "counterText".
Wobei ich mir grad überlege, aber das ist sicher Ansichtssache / Geschmackssache, ich werde mir den Hintergrund weiterhin scharz färben lassen und nur die Box selber in weiss.
Da ja die eigenen CSS nach dem der Mediabox geladen werden, habe ich dazu einfach definiert:
Schön isses :DCode:#mbOverlay {
background-color: #000;
}
Sehr schön, die Mediabox ...
Ansonsten schaut das für mich - soweit der Testtag und die lange Ticketliste das jetzt hergab - sehr gut und stabil aus.
Carolina.
Bestätige ebenfalls keine Probleme mit den Changes!
werd ich frühestens heute Abend testen können, meine trunk Installation läuft nur dort :)
Kann weder einen Absturz des Fx 3.6.3 / Mac OS X 10.5.x bestätigen, noch dass nichts in den Cache geschrieben wird. Bei mir füllt der sich prima :).
So, ich habe den Theme-Manager jetzt noch mal überarbeitet und unter anderem die verschiedenen Tickets dazu geschlossen. In der Revision 364 ist der Importprozess jetzt zweigeteilt: Im ersten Schritt werden eventuell fehlende Datenbankfelder geprüft und nach fehlenden eigenen Layoutbereichen geschaut. Der Benutzer kann so eventuell fehlende Extensions oder Layoutbereiche vor dem zweiten Schritt (dem eigentlichen Import) anlegen.
Wie ihr wisst ist der 4. Juli spätester Termin für das finalen Release (Contao 2.9.0). Bitte testet daher die nächsten beiden Tage ausführlich die letzte Version im trunk (zur Zeit r480), damit wir die 2.9 am Freitag oder Samstag freigeben können.
Vielen Dank für eure Unterstützung.
Schon dabei (ergibt sich automatisch beim Schreiben/"Screenshot-Erstellen") :)
Gibt es Bereiche die besonders ausführlich getestet werden sollen?
Nein. Gut wäre es, wenn nicht alle Tests mit der Music Academy laufen, sondern ein paar Live-Seiten kopiert und in einer separaten Installation getestet würden. Wichtig sind auch die Änderungen am SMH, die ich bereits sowohl für die 2.9.0 als auch für die 2.8.4 auf Deinem (Ninas) Testaccount getestet habe. Aber gerade da weiß man ja nie, welche unvorhersehbaren Konfigurationen in der Praxis verwendet werden.
Hallo Leo, ich muss eh gerade eine Seite (welche noch auf 2.6 bassiert) updaten.
jetzt die Frage wäre es dir lieber wenn ich die Seite quasi nachbaue (ich denke so findet man eher Fehler) oder wenn ich diese nur importiere?
Leider kann ich den SMH nicht testen, da unser Server dieser nicht benötigt.
Importieren sollte eigentlich reichen (nachbauen ist u.U. ziemlich viel Arbeit).
Das habe ich gerade auch bemerkt das es verdammt viel Arbeit ist wenn ich es nachbaue :)
Ich habe auch mal den neusten SVN-Build auf einem System installiert. Das System verwendet auch eine kommerzielle Lizenz, und ich kann dazu bisher sagen dass wir keine Probleme haben und das automatische entfernen der Copyright-Hinweise mit meinem Modul immer noch funktioniert. Ausserdem kann ich noch berichten dass auch die Encryption-Routinen funktionieren, ich muss auf dem System nämlich Kreditkarten-Daten speichern :eek::eek:
Ich habe gerade ein Problem mit dem Frontend-Cache behoben, also an einer etwas heikleren Stelle im System operiert. Mit dem neuen Code ist es auch möglich, die Startseite (leere Domain) in Abhängigkeit von der Browsersprachen zu cachen. Dabei wird jedoch für jede mögliche Sprachkombination eine eigene Cache-Seite angelegt:
1. Besucher mit Browsersprache "de" -> Cache-Seite "empty.de"
2. Besucher mit Browsersprache "de, en" -> Cache-Seite "empty.de.en"
3. Besucher mit Browsersprache "en, de" -> Cache-Seite "empty.en.de"
4. Besucher mit Browsersprache "fr, it, en" -> Cache-Seite "empty.fr.it.en"
Für eine Webseite wie contao.org bedeutet das, dass die Startseite mindestens einmal pro Sprache gecached wird. Ich kann noch nicht abschätzen, ob das besser oder schlechter ist, als die Startseite gar nicht zu cachen, wie es momentan der Fall ist. Einen Test ist es aber auf jeden Fall wert.
Die 2.9.1 sollte dann relativ zügig nachdem ihr die Änderungen getestet habt erscheinen.
Ich konnte der Änderung bezüglich bisher kein Problem feststellen.
Was mir aber eben aufgefallen ist: Ich habe beim Startpunkt von MusicAcademy 60Sekunden Cache eingestellt. Das Interessante ist das er bei courses.html ein Datei in system/tmp/ ablegt, aber bei services.html und z.B. navigation.html erfolgt das nicht, obwohl kein extra Cacheverhalten eingestellt ist. By Design or Bug?
Btw: Hattest du das Cookie-Teil2-Problem noch im Bugtracker registriert? (Also meine Reaktion nach der Implementierung?)
Was ist mit Page-Alias 'empty.lng1.lng2…'? Da könnte es doch Kollisionen geben, oder? Hab bisher nur den Code angesehn, komm grad nicht dazu Tests zu fahren.
Also bei mir ist da per default "0 (nicht cachen)" eingestellt. Kann mich nicht erinnern das selber eingestellt zu haben.Zitat:
Zitat von SunBlack
Da gibts den kleinen Unterschied:Zitat:
Zitat von FloB
Cache Eintrag von / : empty.en.de
Cache Eintrag einer Seite mit "empty.en.de" als Alias: empty.en.de.html
Hast Recht. Habe ich vorhin übersehen :).Zitat:
Zitat von BugBuster
Andere Frage: Wäre es möglich den Cache-Header auch zu senden, wenn das Dokument zum erstenmal aufgerufen wird (also wenn er schon auf Disk geschrieben wird)?
So, nach knapp 5 Stunden wurden 32 Dateien für die Startseite von contao.org angelegt.
Das ist durchaus vertretbar für den Gewinn, die Startseite cachen zu können, die ja in der Regel am häufigsten aufgerufen wird.Code:empty.de.en.
empty.fr
empty.fr.en
empty.pl.en
empty.cs.en
empty.es
empty.pl
empty.ru
empty.de.en.es
empty.sv.en
empty.de.en
empty.zh.en
empty.pt.en
empty.en.fr.ja.de.es.it.nl.sv.nb
empty.ru.en
empty.ru.
empty.de.ch
empty.lt
empty.da
empty.en.de
empty.zh.
empty.sv
empty.en.cs
empty.en
empty.de.fr.en
empty.nl.en
empty.en.de.fr.it
empty.es.en
empty.pt
empty.en.es
empty.
empty.de
Wird denn auch kontrolliert, ob das "valide" Sprachen sind ?
Weil du ja nur im Environment auf die $_SERVER['HTTP_ACCEPT_LANGUAGE'] zugreifst. Ich kann meinen Browser ja irgendwas vorgeben, womit das System dann gleich eine neue gecachte Seite erstellt.
So kann ich nicht nur den Server unnoetig beschaeftigen, weil ich mittels gefakter HTTP_ACCEPT_LANGUAGEs immer mehr den Server zuknallen kann, sondern kann auch gezielt Prozesse lahmlegen, weil ich ueberlange Dateinamen dadurch provozieren kann.
Ich habs noch nicht ausprobiert die HTTP_ACCEPT_LANGUAGE abzuaendern, aber theoretisch koennte man auch Dateien erzeugen, die andere ueberschreiben.
Kaeme auf einen Versuch an ;-)
OK, gerade im Code nachgelesen. Dateien ueberschreiben wird nicht klappen, da du die erlaubten Sprachen mittels substr auf 2 Zeichen reduzierst.
Aber damit liesse sich sehr schnell ein Server dicht machen. EInfach alle Kombinationen durchgehen ;-)
Du solltest evt. nur Sprachen cachen, die das System auch unterstuetzt, ansonsten eben eine empty.default erzeugen. (guter Tip von leo-unglaub)
Theorien sind immer gut, aber es zählt letztendlich nur, ob es in der Praxis funktioniert oder nicht. Und genau da merkt man, dass ihr die Idee nicht getestet habt :)Zitat:
Zitat von lindesbs
Habe ich mir auch schon angeschaut. Geht leider nur bedingt. Zwar prüft Contao Anfangs welche Sprache er für die Module nehmen kann, aber innerhalb der Module nicht. Wenn im backend-Modul nur "de" und "en" vertreten sind, kannst du ja trotzdem einen Startpunkt mit "fr" haben. Contao nimmt dann aus den Sprachpaketen den englischen oder deutschen Teil, aus der DB dann aber z.B. das für französisch. Von daher ist die Einschränkung nicht so leicht möglich, da dann in irgendeiner Datei stehen müsste, welche Sprachen genutzt werden.Zitat:
Zitat von lindesbs
Kühne Behauptung.Zitat:
Zitat von leo
Ich habs getestet. Für jede Sprachkombi wird eine neue Cache Datei angelegt der Startseite, obwohl (bei mir) der Inhalt der Cache Seite völlig identisch ist.
Darum gehts hier denke ich.
Vielleicht habe ich den Sinn ja noch nicht vollends verstanden.
(Startseite cachen schon, nur nicht warum es nicht reicht sich auf die erste Sprache zu beschränken bzw. auf die ausgelieferte durch fallback)
;) Wenn wir testen sollen, was sehr gut ist, dann müssen wir schon verstehen was. ;)
Zitat:
Zitat von leo
Leo, eine Bitte, sei mit solchen Aussagen vorsichtig...
Wenn Du moechtest, kann ich Dir deinen Server lahmlegen. Xtra wird Dir gleich per eMail das ProofOfConcept zuschicken. NATUERLICH mit einer aktuellen Version aus dem SVN getestet.
Wenn Du mal genau liest, was ich geschrieben habe, wirst Du feststellen, dass sich meine Aussage auf die "empty.default" bezieht und auf nichts anders (extra deswegen noch mal zitiert). Das andere Problem besteht zweifelsohne und mir fällt dazu auch keine Lösung ein. Also werden wir damit leben müssen, dass wir die leere Domain nicht cachen können.
War etwas missverstaendlich, da der Erste Teilsatz dominierte (check ob unterstytzte Sprache) gegenyber der kleinen Klammer worin das mit der empty.default stand.Zitat:
Zitat von leo
Das ist geklaert und nun beruhigen wir uns wieder. :)
Mail ist raus. IMO ist dies ein genereller Schwachpunkt in Environment (siehe hierzu auch vorgeschlagenen Fix in der Mail).Zitat:
Zitat von leo
Die Frage die ich mir hier stelle ist jedoch, wozu brauchen wir alle kombinationen?
Ein File pro pageroot sollte doch reichen (schliesslich klebt hier der Sprachcode).
Ausnahme hiervon ist doch lediglich der fallback, welcher alle moeglichen Sprachen haben kann.
Ich muss zugeben, ich hab mich mit dem zugrundeliegenden Problem des caches in diesem Sinne noch nicht wirklich beschaeftigt, lediglich die Idee gehabt das cachen in der vorliegenden Version zu exploiten. Fyr genaueres fehlt mir leider momentan die Zeit.
Gruss
Chris
Nunja, das mögliche Angriffsproblem könnte man schon ein bisschen dadurch einschränken, dass für die httpAcceptLanguage nur Sprachen erlaubt sind, die /[a-z]{2}/ entsprechen. Wenn man aktuell als akzeptierte Sprache irgendeinen anderen Wert liefert, dürften einige SQL-Befehle defekt sein (kann man aber durch die Beschränkung auf 2 Zeichen nicht wirklich ausnutzen). Allerdings gibt es immernoch zuviele möglichkeiten.
Gibt es eigentlich noch Stellen wo das die Sprache wichtig ist? Wenn es nur für die Modulsprache und die Webseitensprache ist, könnte man beim Hinzufügen eines Webseitenstartpunktes in den Cache alle erlaubten Sprachen schreiben. Dann ein array_intersect drüberlaufen lassen und schon sind es nur noch einige Dateien die erzeugt werden können.
Zitat:
Zitat von leo
Nu ja, ich habe genau gelesen, ich kenne dein System und den Code.
tl_page laesst sich durchsuchen, so laesst sich auch herausfinden, welche Seitensprachen unterstuetzt werden. Es gibt mit SIcherheit auch noch andere Stellen, wo man Sprachen definiert, hab ich gerade nicht parat (Sorry)
Aber zur Not, muss eben kontrolliert werden, ob die angeforderte Sprache in deinen eigens definierten Languages ist (TL_ROOT/system/config/languages.php) Damit laesst sich das schon deutlich reduzieren......
Jop, das habe ich mich auch gefragt. Kannst du das bitte erläutern, Leo?Zitat:
Zitat von xtra
Der Cache funktioniert so: Beim "starten" des CMS wird eine Prüfsumme der URL gebildet. Diese Prüfsumme sucht er dann in system/tmp/ und überprüft, ob er die noch verwenden darf. Wenn ja wird der Inhalt zurückgegeben und ansonsten der normale Code ausgeführt. Das ganze passiert, bevor irgendeine DB-Verbindung gestartet wird.Zitat:
Zitat von FloB
Bei der Startseite passiert nun folgendes: Das System wird hochgefahren und der Host, in Kombination mit der Sprache, in der DB nachgeschlagen und eine passende pageRoot gesucht (siehe Änderung rev 518). Wenn etwas passendes gefunden wurde, wird die entsprechende Seite genommen (oder der Fallback).
Problem an der Stelle mit cachen ist, dass der Cache keine Ahnung von der Sprache hat. Wenn dein Browser "en,de;0.9" als akzeptierte Sprache liefert, zieht er englische Webseiten vor, gefolgt von deutschen. Wenn es nun nur eine deutsche gibt, dann versucht Contao erst eine englische Seite für den aktuellen Host zu finden, findet dabei nichts, und anschließend nach einer deutschen, die er findet. Die zurückgelieferte Seite hängt somit immer von httpAcceptLanguages ab - und dabei sogar noch von der Reihenfolge (abgesehen davon das Leo da eine Annahme macht an die sich zwar jeder Browser hält, aber nicht ganz korrekt ist [bei en;0.9,de würde Contao nen Fehler machen]).
Und da der Cache keine Ahnung von den erlaubten Sprachen im System hat, muss httpAcceptLanguages im Cachedateinamen enthalten sein, damit er dem Browser nicht ausversehen die deutsche Seite aufliefert, wenn er eigentlich die deutsche zeigen sollte.
Btw: Der geänderte Code in #518 erlaubt es übrigens den MySQL-Server ziemlich leicht mit SQL-Anfragen zu bombardieren. Da wäre eine Abfrage in der Richtung :
besser, da es maximal zwei Abfragen wären, statt viele, denn bei 10 akzeptierenden Browsersprachen, wobei keine einen Treffer erzeugt, wären alleine da jetzt schon 22 Abfragen von Nöten. Mit einem angepassten SQL-Code wären nur zwei nötig: alle in Frage kommenden pageRoots, wobei PHP dann den besten ermitteln muss (abhängig von der Anzahl der zurückgeleiferten Pageroots und nicht von den Browsersprachen), und evtl. die Fallback-Seite (könnte man auch noch zur ersten packen, wenn man bissl mehr in die PHP-Logik steckt).PHP-Code:SELECT id FROM tl_page WHERE type='root' AND (dns=? OR dns=? OR dns='') AND language IN ('', ?, ?, ?, ...) AND (dns<>'' and language<>'')
Gut beschrieben, kleine Anmerkungen:
Da ich mehrmals staunte musste ich in den Quelltext schauen wie du das meinst.Zitat:
Zitat von SunBlack
Im Dateinamen nicht direkt, die Prüfsumme wird aus URL + httpAcceptLanguages gebildet.
Cache Dateiname: 1ba8fcef37a6fd774662e3b5bcec471b (hier suche ich immer das de-en)
In der erste Zeile wird die auch nochmal eingetragen.
IP maskiert ;)Code:<?php $expire = 1280433357; /* http://256.256.256.256/typolight-trunk/empty.de.en */ ?>
Hier meinste bestimmt die englische Seite.Zitat:
Zitat von SunBlack
Und warum geht man nicht so vor, dass pro Sprache eine Cache-Datei angelegt werden kann, beim Aufruf je Sprache auf eine im Cache liegende Datei geprüft wird und wenn nichts gefunden wurde danach die DB abgefragt wird?
Edit: OK, ich sehe darin schon ein Problem: Wenn die erste Sprache existiert, aber nicht im Cache abgelegt ist, die zweite aber schon, bekommt der Besucher die falsche Sprache serviert. Kann man das irgendwie umgehen?
Edit 2: Kann man nicht einfach eine Maximalzahl (z. B. 3 oder 5) für alternative Sprachen angeben, um den DDoS-Vektor zu versperren? Also max. möglicher Dateiname z. B. 'empty.de.en.fr'. Mehr alternative Sprachen halte ich für äußerst selten, sollte dabei mal eine falsche Sprache ausgegeben werden, halte ich das für vernachlässigbar.
Ja, sorry. Ich war zu faul alles wieder auszuschreiben und da die, die hier mitschreiben, den Code zum Teil kennen, dahcte ich mir das sie sich denken können was mit httpAcceptLanguages gemeint ist ;).Zitat:
Zitat von BugBuster
Jop, wobei um ehrlich zu sein gefällt mir diese Variante nicht. Da ich ein eigenes Templatesystem geschrieben haben (achja, die If-Abfragen müsste ich auch mal fertig implementieren^^) und dort auch einen Cache habe, habe ich mich mal damit beschäftigt, wie man erkennt ob er den Cache noch verwenden darf oder nicht. Meine erste Variante war auch die Zeit in den Cache zu schreiben. Aber bei mir hat filemtime unter Unix und Windows problemlos funktioniert. Contao hätte sogar einen Performancevorteil davon, wenn statt include ein readfile dastehen würde, da das parsen wegfällt.Zitat:
Zitat von BugBuster
Jo, hast Recht. Bin sowieso erstaunt das ich vorhin noch einen halbwegs zusammenhängenden Text hinbekommen habe (hat jemand Lust für mich morgen die Klausur in theoretische Informatik zu schreiben [geht ja nur um reduction von NPC-Problemen und so ;) ])Zitat:
Zitat von BugBuster
Wenn Du das System so gut kennst, solltest Du auch wissen, dass der Vorteil des Cache ist, dass eben keine DB-Verbindung aufgebaut wird. Und somit kann man auch nicht die tl_page durchsuchen. Deswegen sage ich: Theorien sind nett, aber bevor wir hier ernsthaft diskutieren können, solltet ihr eure Ideen zumindest mal implementiert und getestet haben.Zitat:
Zitat von lindesbs
Das ist mir klar.Zitat:
Zitat von SunBlack
Auch dies ist unstrittig jedoch IMO unnoetig, da der Cache vorher einsetzen koennte, siehe unten.Zitat:
Zitat von SunBlack
Ebenfalls klar, deine Befyrchtung der "Annahme" teile ich btw.Zitat:
Zitat von SunBlack
Generell sollte Environment die languages filtern und nach ihrer Gewichtung sortieren.
Dies ist nichtmal so aufwendig.
Der Cache MUSS keine Ahnung von den Seiten im System haben. Wozu auch?Zitat:
Zitat von SunBlack
Er muss lediglich checken ob eine(!) Seite existiert, welche in den akzeptierten Sprachen enthalten ist, zur Domain passt und obendrein einen leeren alias besitzt.
Diese Informationen koennen wir komplett ohne Datenbank erhalten.
Hierbei muss er lediglich die akzeptierten Sprachen durchlaufen (welche wie oben beschrieben nach Gewichtung sortiert sein myssten).
Hat er hierbei einen "[domainname].empty.[langcode]" Hit, muss er diesen ausliefern.
Hierbei ist es vollkommen egal was es war, ob fallback oder richtiger match. Ein vorheriger Aufruf hat naemlich bereits entschieden, dass wer unter dieser Domain mit Sprache XY vorbeikommt diese Seite erhalten soll.
Domainname bezieht sich hierbei auf die im Pageroot hinterlegte Domain (Womit Mehrfachinstallationen abgedeckt waeren).
Einzig verbleibende Faelle sind nun noch:
- der Fall, wo keine Sprachen vom Browser angefragt werden (HTTP 1.0 etc.). Hierzu koennten wir, in genau jenem Falle, eine "www.example.com.empty.nolang" o.ae. im cache ablegen.
- der Fall, wo keine vom Browser gesendeten Sprachen im System bekannt sind und somit der Fallback generiert werden muss. Dieser wird anschliessend auch ohne Cache generiert aber mit dem vom Browser praeferierten Sprachcode im Cache abgelegt (z.B. "www.example.com.empty.cz"), beinhaltet de facto aber eine Kopie der Startseite. Bei jedem subsequenten Aufruf wird die Seite mit entsprechendem LangCode ausgeliefert.
Der Einfachheit halber haben wir nun:
IMO ist es doch so (Mal aus Sicht des Browsers gesehen):Code:de,en => www.example.com.empty.de
en,de => www.example.com.empty.en
de => www.example.com.empty.de
en => www.example.com.empty.en
fr => www.example.com.empty.fr (im System nicht abgelegt, also fallback)
'' => www.example.com.empty.nolang (Browser sagt nicht was er will, also fallback)
'cz,ru' => (Browser sagt nur unbekannte Sprachen, also fallback) www.example.com.empty.cz
Generell kann eine Seite immer nur eine Sprache haben.
Ebenfalls hat eine Seite auch nur einen URI bzw. alias.
Der Sinn und Zweck nun alle Browsersprachen in das hash zu ybernehmen hat sich mir nicht erschlossen. IMO erzeugt das nur massig duplicate cache content. Da koennte man auch (ybertrieben gesagt) auch das Cookie ins Hash einfliessen lassen.
Klaert mich auf, wo sind meine Denkfehler?
€dith: Argument von Flob oben macht Sinn, kann jedoch umgangen werden... muss mal ne Referenzimplementierung zusammenschmeissen.
Full ACK.Zitat:
Zitat von SunBlack
Grysse Chris
PS: warum nicht gleich eine allgemeine Cache Klasse bauen, welche strikt Hashes entgegen nimmt, vergleicht und bei matches den Wert returned und ansonsten false.
Dann koennten auch Extensions Teile von sich cachen (ich habe in einigen immer einen eigenen kleinene Cache Mechanismus einbauen myssen um Request-Ergebnisse zu puffern).
@FloB: Den Vorschlag wollte ich vorhin auch schon machen, bis mir der Fehler daran auffiel (so wie dir per Edit ;) ).
Einzige Möglichkeit das zu umgehen ist der zusätzliche Cache, den ich in #59 ansprach. Problem daran: Man muss wissen, wo die erlaubten Sprachen gecacht sind, was Erweiterungen einschränken könnte (auch wenn es unwahrscheinlich ist)
Nur würde eine solche Abfrage nicht die Reihenfolge der Sprachen und somit ihre Wertigkeit berücksichtigen. Das ließe sich natürlich mit FIND_IN_SET() korrigieren, aber das entspricht nicht dem SQL92-Standard und kann daher nicht verwendet werden.Zitat:
Zitat von SunBlack
Und deswegen noch mal die Bitte: Implementiert eure Ideen zuerst und stellt sie dann hier zur Diskussion.
Könnte man das nicht nachträglich in PHP erledigen? Dies + ein SQL-Query ist sicherlich auch performanter als mehrere SQL-Queries in einer Schleife.Zitat:
Zitat von leo
Nein, keine Implementierung zur Hand. Wohl leider auch nicht die nächsten Tage. Aber als Anschubidee für Andere …? ;)
Bitte alles aus meinem Absatz beachten. Da stand etwas von:Zitat:
Zitat von leo
Sprich php muss dann letztendlich aus der zurückgegebenen Liste den besten ermitteln. Ich hatte da gestern ne Implementierung angefangen, aber ich fand das Lernen für die Klausur doch wichtiger ;)Zitat:
Zitat von SunBlack
Hab gerade die r524 committed, die eine Kompromisslösung darstellt und einige andere Anregungen aus diesem Thread implementiert.
1. Die Suche nach der passenden Root-Seite simuliert nun FIND_IN_SET() und kommt dafür mit einer einzigen DB-Abfrage aus.
2. Die Funktion httpAcceptLanguage() prüft die Tags anhand einer Regexp und filtert leere Tags heraus.
3. Leere Requests werden nicht mehr in Abhängigkeit der Browsersprache sondern der Seitensprache gecacht. Stimmt die erste Browsersprache mit einer Seite überein, kann diese aus dem Cache geladen werden. Das funktioniert aber nur für die primäre Browsersprache und auch nur bei einem echten Treffer - also nicht bei Fallback-Seiten. Ist aber immer noch besser als gar nichts :)
:) Ich habe eben nur kurz drübergeschaut: Die MySQL-Rückgabe kannst du eigentlich beschränken, also dns eingrenzen etc. Der SQL-Befehl wird dadurch zwar länger, aber dafür braucht PHP danach weniger Records durchsuchen (MySQL wird mit Filtern effizienter sein).Zitat:
Zitat von leo
Allerdings sehe ich ein Problem bei der Implementierung:
Ist das Ergebnis folgender Funktion beabsichtigt:
Bei eienr Domain wie meinwww.de (bzw. www.meinwww.de ) ;)PHP-Code:str_replace('www.', '', $objRootPage->dns);
Ist das $strTag != '' nicht unnötig? pregmatch dürfte den Fall doch auch herausfiltern, wenn ich mich nicht irre.Zitat:
Zitat von leo
Ist ein guter Kompromiss :). In vielen Fällen dürfte der Cache da greifen und wenn nicht, gibt es auch keine Probleme, die durch den neuen Cache verursacht hätten werden können.Zitat:
Zitat von leo
Ich habe eine Implementation, auch gegengetestet. Und der Geschwindigkeitsverlust ist vernachlaessigbar.Zitat:
Zitat von leo
Getestet habe ich mit dem ApacheBench, der mir neutrale Daten liefern kann.
Und selbst eine DB Abfrage mittels SELECT DISTINCT(language) verschelchtert mir mein Ergebnis nicht nennenswert.
Bei 200 Anfragen, mit 10 parallel gestarteten Requests, ist beim Original eine Auslieferungszeit von 67ms. Wenn ich meine DBAbfrage nutze liegt diese bei 75ms.
Ja gut, mag einer sagen, 10% mehr. Aber dem Browser ist es egal, ob es nun nach 67ms da ist oder erst nach 75ms. Da er dann erst anfaengt und den Header auswertet, um JavaScript nachzuladen usw. Da faellt dieser kleine Versatz nicht mehr auf.
Alles getestet mit der MusicAcademy.
Ich werd heute abend einen Bericht mit den Beispielen hochladen. Sitze gerad ein Paris am Flughafen....
Keine Ahnung was Du damit meinst. Am besten implementierst Du Deine Idee und lädst den Code anschließend hoch. Das dürfte für alle am anschaulichsten sein :)Zitat:
Zitat von SunBlack
Das stimmt, da sollten wir lieber preg_replace() verwenden.Zitat:
Zitat von SunBlack
Ich habe eben mal rumgespielt. In Anbetracht dessen das es meistens nur sehr wenige pageroots gibt, lohnt sich ein unübersichtliger SQL-Befehl da nicht wirklich.Zitat:
Zitat von leo
Was ich am aber Code evtl. noch ändern würde: Statt über die Browser-Sprachen zu iterieren würde ich nur über die PageRoots iterieren und dabei schauen welches am besten passt (per array_flip geht da nen schneller Zugriff auf die Sprachpriorität)
Ok, eimmal sage ich es noch: Bitte implementieren und Code posten :)Zitat:
Zitat von SunBlack