Dumme Frage: Wie sorge ich dafür das er die .htaccess verwendet? Schließlich greife ich per php-Prozess dann auf den Unterordner zu und nicht mehr von außen über den Webserver. Und imho lößt php die htaccess-Dateien nicht aus.Zitat:
Zitat von xtra
Druckbare Version
Dumme Frage: Wie sorge ich dafür das er die .htaccess verwendet? Schließlich greife ich per php-Prozess dann auf den Unterordner zu und nicht mehr von außen über den Webserver. Und imho lößt php die htaccess-Dateien nicht aus.Zitat:
Zitat von xtra
So ich habe mal v2.9.1 gepackt. Änderungen gibt es keine, da ich immer noch keine Idee habe, wie ich aus php die htaccess schreiben und gleich testen kann :(.
Achso, ich habe auf sf.net jetzt svn eingerichtet. Damit sehe ich dann selber, wo ich mal was verändert habe ;).
aus diesem Grunde musst du taic und die htaccess in ein subdir packen.Zitat:
Zitat von SunBlack
Alternativ kannst du auch versuchen auf ein file im subdir einen "new Request()" zu fahren, welche dir dann irgendwo ein flag setzt.
Die dritte Moeglichkeit ist dann noch, da alles per ajax ablaufen zu lassen, womit es dann auf den client ankommt die Antwort deines php files im subdir an den taic weiterzureichen.
Viele Wege koennen zum Ziel fyhren.
Such es dir aus und sei kreativ. :)
Gruss
Chris
Ich will halt dabei bleiben, dass es nur eine eiznige Datei ist. Von daher will ich diese Variante nicht unbedingt,Zitat:
Zitat von xtra
Da müsste die .htaccess auf em Server liegen bleiben. Und Reste mag ich nicht ;).Zitat:
Zitat von xtra
Ja werde ich wohl probieren müssen. Ich wollte den Weg nur vermeiden, da es mehr als 1-2 Zeilen sind (alles in einer einzigen Datei zu haben wird irgendwann unübersichtlich [vor allem wenn der Code eh mal refactored werden müsste]).Zitat:
Zitat von xtra
Ansonsten: Ich könnte ggf. mal einen Check einbauen, ob die config-Dateien wirklich mit <? anfangen, also kein BOM davor kommt. Der BOM-Fehler kommt scheinbar doch gelegentlich mal vor.
Besteht interesse den Speicherplatz vom Server zu überprüfen? Bin durch Zufall über die PHP-Funktion disk_free_space gestolpert.
Wenn ja: Es gibt ja keine offizielle Empfehlung. Wie würdet ihr es einteilen (ok, Warnung, Fehler)?
Ansonsten: Wer ins SVN geschaut hat, wird gesehen haben, dass es kleinere Fixes wieder gab. Nächstes Release kommt trotzdem erst bei 2.9.2 (ich will v2 etc. vermeiden)
Ok, das mit disk_free_space hat sich wohl erledigt. Er liefert mir 357.2 GiB / 732.3 GiB bei einem 1&1-Hostingpaket zurück, bei dem wir nur 5GB haben. Er scheint also wirklich die disc zu nehmen und nicht wie erhofft den Account (falls jemand für letzteres eine Funktion kennt, nur her damit).
So neue Version (2.9.2).
Changlog:
- Added detection of BOM in config files
- Fixed: Disabled max_execution_time=0 was interpreted as too less time
- Fixed some small bugs
Downloadlink siehe ersten Post dieses Threads.
Aktualisierung auf 2.9.3 ist erfolgt. Änderungen gab es ansonsten keine.
danke für dein tolles Tool, aber ich habe eine Frage.
Ich habe das System mit deinem Tool gecheckt und es sagt mit, dass meine dcaconfig, meine localconfig und meine langconfig beschädigt sind.
Wenn ich die Originale hochlade gibt es keine Fehler, wenn ich aber in die Originale den von mir benötigten code in diese Dateien einkopiere sagt es wieder beschädigt.
Heißt in dem Fall beschädigt einfach dass die Datei nicht mehr im ursprünglichen Zustand ist oder dass in der Datei falsche Anweisungen stehen?
danke für eine kurze Rückmeldung
Joachim
Das bedeutet eine abweichende Prüfsumme der betreffenden Datei. Was ja nicht weiter verwunderlich ist, wenn da Deine benötigten Änderungen drin sind.
Könnte man sicher eleganter formulieren, braucht Dich aber nicht zu beunruhigen.
oder wie man bei uns im Allgäu sagt
Muchas Gracias
Ah hier gabs ne Antwort - tut mir leid, habe ich nicht mitbekommen.
Also wenn dort eine Warnung ist, heißt das einfach nur, dass sie verändert wurde. Ist für mich z.B. bei Upgrades interessant um zu wissen, welche Dateien ich ggf. sichern muss. Wenn ich Zeit habe, werde ich mal am Tool auch wieder ein paar Verbesserungen einfliegen lassen. Momentan ist es nur mit der Zeit leider... :(
Nichtsdestotrotz: v2.9.4 hochgeladen.
So 2.9.5 hochgeladen.
Changelog:
- Charset war nicht utf-8, so wie eigentlich gedacht (Konflikt Dateicharset vs. angegebenen Charset)
- Kleinere HTML-fehler (HTML-Code ist wieder w3c-konform)
Danke fürs Update SunBlack.
PS: Du zahlst ne Runde, du hast 333 Beiträge geschrieben :)
Ein 8er Kasten Bits kann ich ja ausgeben ;).Zitat:
Zitat von schman
Btw: Eingangspost enthält jetzt auch die neuen Links.
So v2.10.0 ist raus. Änderungen gab es sonst keine. Dafür habe ich den Updater ein bisschen refactored, wes wegen der Code jetzt etwas lesbarer ist (war vorher grausam - ich weiß ;) ). Funktionell gabs dabei keine Änderung.
So v2.10.1 steht bereit.
Wenn ich demnächst Lust und Laune habe, gibt es ein Update für den Updater, bei dem man bestimmte Ordner auschließen kann (Zwecks svn).
Ich kann im FF6/Win die Sprache nicht wechseln mit der Version 2.10.0
Grund ist ein hardgecodetes doppelt escaptes & in der buildBaseUrl-Methode.
Meine Empfehlung wäre htmlspecialchars, abhängig vom konkreten Ausgabe-Ort der URL, zu nutzen und lediglich eine XML-unescapte URL in der buildBaseUrl-Methode zu erzeugen.
Es wäre außerdem hilfreich, wenn man irgendwo ein bisschen Dummy-Code hat um die CoSC via htaccess zu schützen, sonst könnte man ganz leicht den Server lahm legen, wenn man vergisst die cosc.php beim Live-Gang zu entfernen. Oder irgendwas anderes um das zu verhindern.
Danke für den Hinweis. Der Fehler fällt leider nur an der Stelle auf, da an allen anderen Stellen JavaScript die arbeit übernimmt. Ohne JS hätte ich gesehen, dass der Fehler in allen Links war -.-. Danke für die Meldung - ist gefixt als v2 (habs aber nur für die version gefixt und nicht für v2.9.5 und v2.10.0, da die kaum noch runtergeladen werden)Zitat:
Zitat von backbone
Wie meinst du das? Den Server legt man mit diesem Tool normalerweise nicht lahm - außer jemand macht einen DoS-Angriff auf dieses Tool, da es ja rechenaufwändiger ist. Ansonsten: oben gibt es ein define für TL_ROOT. Da kannst du auch einfach einen anderen Pfad angeben, den er durchscannen soll. Du kannst theoretisch das Tool also auch in einen .htaccess-geschützten Ordner legen. Ich muss aber zugeben, ich habe es nie mit einem anderem Pfad probiert ;).Zitat:
Zitat von backbone
Ich meinte eine DoS-Attacke. Wenn man die cosc.php nicht entfernt, wird das System extermst anfällig dafür.
Ja ok, aber wie willst du das verhindern? Die Möglichkeit das Tool zu verschieben gibt es ja, und dann diesen Ordner mit einer .htaccess/.htpasswd zu schützen. Falls du eine gute Idee hast, die ich vom Skript aus machen kann, gerne...
So 2.10.2 hochgeladen. Der Updater hat auch ein update erhalten, um system/tmp und system/scripts nicht mitzutesten (auch wenn dadurch die .htaccess nicht mehr überprüft wird :( - da muss ich wohl doch langsam erweiterte regeln für den Updater einführen)
Hallo,
ich habe ebenfalls den COSC für 2.10.2 hochgeladen.
Bei der Analyse erscheint er aber als "Contao System Check for version 2.10.1" und meldet entsprechende Abweichungen.
Was ist da schief gegangen?
Gruß Alex
Danke für den Hinweis. Was da schief gelaufen ist, weiß ich nicht so genau, denn im SVN liegt die korrekte Version.
Allerdings habe ich festgestellt, dass ein anderer gravierender Bug im Updater drin ist, wes wegen er den ganzen system-Ordner in v2.10.2 nicht mit prüft. Von daher habe ich cosc als auch den aktuellen Updater sicherheitshalber von sourceforge gelöscht, bis ich zu einem fix komme.
Dann viel Erfolg. :)
Ich hatte den Link direkt im ersten Posting zum Download verwendet.
Gruß Alex
Das war für den Fehler irrelevant - ist ja nur eine Verlinkung auf sourceforge ;).
Ich habe den Fix jetzt aber eingespielt.
- coscUpdater v1.2.1: Enthält den Fix, damit er den system-Ordner nicht mehr vergisst
- cosc v2.10.2v2: Mit dem neuen Updater erstellt ;).
So 2.10.3 ist hochgeladen.