[GELÖST] Firefox zeigt Login und Backend ohne Styles an

NaN · 22. Dezember 2011 14:01

Das charset=none kommt durch eine serverseitige Einstellung AddDefaultCharset zustande, die vom php Script nicht überschrieben wird. Wenn AddDefaultCharset verwendet wird, dann sollte dort ein gültiger Wert stehen und nicht einfach none. Die Apache Voreinstellung ist AddDefaultCharset Off. D.h. es wird kein Charset hinzugefügt, wenn keines anegeben wird. Ist diese Einstellung einfach nur auf AddDefaultCharset On gesetzt, würde als charset iso-8859-1 ausgegeben werden. Jeder andere Wert wird als zu verwendende Standardzeichenkodierung aufgefasst. Ergo ist der Server mit AddDefaultCharset none einfach falsch konfiguriert.

piratos · 22. Dezember 2011 14:12

AddDefaultCharset wirkt nur auf text/plain oder text/html nicht auf text/css , das ist dein Fehler im Ansatz und deswegen ist es ein Programmierfehler.

uniqu3 · 22. Dezember 2011 14:26

piratos schrieb:

Ein FF kann abbrechen wenn die CSS nicht korrekt ist:
body.body-login {
background: #fff
}
da fehlt das ;
also so:
body.body-login {
background: #fff;
}

?? seit wann muss man letzte css deklaration/erklärung schließen? Wäre das wie Du meinst ein Fehler dann wären die ganzen kompressions tools die man so findet auch falsch konfiguriert, oder lehrt und W3C auch falsch http://www.w3.org/TR/CSS2/syndata.html#x19 ?

piratos · 22. Dezember 2011 14:33

Das Thema ist ja schon durch, aber ältere FF Versionen haben da tatsächlich einen Abpfiff daraus gemacht.

Das der FF (sogar der aktuellste 9 er) CSS etwas anders verarbeitet sieht man ja hier an der Headergeschichte - alle anderen Browser haben das geschluckt nur eben der FF nicht.

NaN · 22. Dezember 2011 14:35

AddDefaultCharset wirkt nur auf text/plain oder text/html nicht auf text/css , das ist dein Fehler im Ansatz und deswegen ist es ein Programmierfehler.

Oha.
Asche auf mein Haupt ... ops
Falsche Directive.

Ich bin trotzdem der Meinung, dass es eine Fehleinstellung des Servers ist.
Vielleicht liegt's nicht direkt am AddCharset. Vielleicht auch einfach nur an falscher mod_mime Einstellung. Aber von alleine kommt das charset=none da nicht hin. Bei anderen Servern kommt als Antwort einfach nur text/css ohne Charset. Und die Server, bei denen es funktioniert, löschen mit Sicherheit keine Charsets aus dem Header raus.

Edit: was nichts daran ändert, dass man, wenn man das Problem mit ein paar Zeichen umgehen kann, es ruhig als "Fehler" melden kann. Nur einen echten Programmierfehler stelle ich mir anders vor.

$x = 1;
$y = 2;
if($x + $y == 5) {
...
}

Das wäre für mich ein echter Fehler wink

piratos · 22. Dezember 2011 15:11

Nun dein echter Programmierfehler ist schon mal keiner, der funktioniert nämlich:
<?php
$x = 1;
$y = 2;
if($x + $y == 5) {
echo 'Hallo';
}
else
echo 'Ätsch';
?>

wie man hier sehen kann.

Wer einen header mit PHP schickt sollte bei texten immer daran denken welche text Type schicke ich und in welcher Codierung - da gibt es dann auch keinen Platz mehr für Spekulationen.

Das der FF bis heute sich da in einigen Bereichen anders verhält als andere Browser das ist ausreichend bekannt.
Also sollte man als Programmierer das berücksichtigen und sich nicht darauf verlassen, das der eigene Lieblingsbrowser solche Dinge korrigiert.

NaN · 22. Dezember 2011 15:28

Nun dein echter Programmierfehler ist schon mal keiner, der funktioniert nämlich:

Ähm... wenn man ihn entsprechend abändert, ja roll
Dann funktioniert aber auch nur ein Teil des Codes.
1+2=5 ist völlig unsinnig.
Die Bedingung würde nie eintreffen.
Also Pogrammierfehler.

Außerdem hat der header ohne charset ja auch funktioniert.
Nur nicht immer. Und das liegt nicht am Browser oder PHP Script, sondern am Server.

Wer einen header mit PHP schickt sollte bei texten immer daran denken welche text Type schicke ich und in welcher Codierung - da gibt es dann auch keinen Platz mehr für Spekulationen.

Dann machst Du bei PCMS aber genau den gleichen echten Programmierfehler wink

piratos · 22. Dezember 2011 15:49

Dein Script ist nur in deinem Kopf ein Fehler und dann auch nur ein Logikfehler, wenn du ein Ergebnis von 5 sicher erwartest, was aber nie der Fall sein wird. smile

NaN schrieb:

Dann machst Du bei PCMS aber genau den gleichen echten Programmierfehler

Das ist mir bei der Geschichte auch aufgefallen - im Adminbereich wird tatsächlich eine style.php eingesetzt , die ich soeben komplett entfernt habe - da kommt eine statische CSS als Link rein.

NaN · 22. Dezember 2011 15:51

charset=none ist keine gültige Angabe.
Der Fehler liegt dort, wo diese Angabe gesetzt wird und nicht dort, wo sie nicht gesetzt wird. Ein Server, der von Haus aus charset=none ausgibt, ist falsch konfiguriert.

piratos · 22. Dezember 2011 16:04

Also da drehen wir uns im Kreise wie Kleinkinder die im Kreis tanzen - über das Thema gibt es ein paar Millionen Fundstellen im Netz - betroffen sind diverse Titel gewesen - die haben das alle für sich korrigiert und gut ist.

Wenn man das nicht mit eine paar Anschläge beseitigen will kommt das also immer mal wieder hoch - bei mir nun nicht mehr.

NaN · 22. Dezember 2011 16:11

Dass man das ändern sollte, darüber sind wir uns doch alle einig wink
Aber das geschieht nicht, weil es ein Fehler ist, sondern weil man damit etwaige Fehleinstellungen Dritter bereits im Vorfeld korrigieren kann. Wer das macht, der leistet saubere Arbeit. Wer nicht, dem würde ich nicht unbedingt einen Fehler in seinem Script ankreiden, wohl aber ein unelegantes Verhalten seines Scriptes.

Edit: ich hab's mal vorsichtig als Feature-Request gemeldet.

NaN · 22. Dezember 2011 17:27

Übrigens kann man das charset auch via .htaccess setzen ohne die php-Dateien zu ändern:

Hier klicken, um den Code zum Kopieren zu markieren

php_value default_charset utf-8

Ich hoffe nur, dass die Devs nicht auf die Idee kommen, das als Lösung zu antworten, anstelle die beiden php-Dateien um das korrekte charset (wie es z.B. in der config.php angegeben ist) zu erweitern.

piratos · 22. Dezember 2011 17:42

Wenn ich das richtig sehe wirkt das auch nicht auf text/css - wäre also keine Lösung.

NaN · 22. Dezember 2011 17:52

Funktioniert bei mir (lokal) problemlos mit allen Content-Types.

mike-r · 22. Dezember 2011 19:12

piratos schrieb:

Das Thema ist ja schon durch, aber ältere FF Versionen haben da tatsächlich einen Abpfiff daraus gemacht.

Welche Versionen sollen das sein?
Ist mir noch nie untergekommen und einen Bug dazu kann ich auch nicht finden.

piratos · 22. Dezember 2011 19:20

Da googelst du mal mit firefox style.php no css und schaust dir mal ein paar von den 21 Mio. Treffern an.

NaN · 22. Dezember 2011 20:13

Das Problem ist übrigens bereits im SVN behoben worden smile

mike-r · 22. Dezember 2011 20:40

piratos schrieb:

Da googelst du mal mit firefox style.php no css und schaust dir mal ein paar von den 21 Mio. Treffern an.

Thema war:

uniqu3 schrieb:

?? seit wann muss man letzte css deklaration/erklärung schließen? Wäre das wie Du meinst ein Fehler dann wären die ganzen kompressions tools die man so findet auch falsch konfiguriert

Ich dachte Deine Antwort bezog sich darauf, schliesslich hast Du direkt auf diese Frage "geantwortet" (aber nicht schlüssig beantwortet).

Beitrag geändert von mike-r (22. Dezember 2011 20:41)

Klenkes · 22. Dezember 2011 21:46

NaN schrieb:

Das Problem ist übrigens bereits im SVN behoben worden

Haben wir hier einen Doppelagenten?
Wie biqu3m... ähh, räusper, bequem meinte ich. Da kann ich mir den Bugreport sparen wink

NaN · 22. Dezember 2011 22:01

Klenkes schrieb:

Haben wir hier einen Doppelagenten?

Nein, ich habe das Problem als Feature-Request gepostet wink
Und daraufhin wurde es behoben:
http://dev.cmsmadesimple.org/feature_request/view/7380
Bin überrascht, aber sehr erfreut wie schnell das ging big_smile

uniqu3 · 22. Dezember 2011 22:04

Klenkes schrieb:

Haben wir hier einen Doppelagenten?
Wie biqu3m... ähh, räusper, bequem meinte ich. Da kann ich mir den Bugreport sparen

Solltest Du damit mich meinen, ist mir deine Meinung wurst, mir aber auch klar warum um ich Diskussionen hier meide, FR wurde durch NaN eingetragen (http://dev.cmsmadesimple.org/feature_request/view/7380), was eigentlich richtige Vorgehensweise ist, und commit um 17:46 durchgeführt, Zeit Differenz kannst aber jetzt selbst kalkulieren.

mike-r · 22. Dezember 2011 22:23

uniqu3, is jetzt nicht Dein ernst, oder? Den Smilie haste gesehen?

owr_web · 23. Dezember 2011 23:05

is do ana lei a bissl angriaht?

ui und weils amoi schnell gangen is und .... ach lassen wir das, führt nur wieder zu unnötigen Diskussionen.

Ich bin auch positiv überrascht, dass eine Fehlermeldung von CG schnell und ohne viel Aufhebens und Trara ganz einfach über die Bühne gebracht wurde.

Klenkes · 23. Dezember 2011 00:12

uniqu3 schrieb:

Klenkes schrieb:
Haben wir hier einen Doppelagenten?
Wie biqu3m... ähh, räusper, bequem meinte ich. Da kann ich mir den Bugreport sparen
Solltest Du damit mich meinen, ist mir deine Meinung wurst, mir aber auch klar warum um ich Diskussionen hier meide, FR wurde durch NaN eingetragen (http://dev.cmsmadesimple.org/feature_request/view/7380), was eigentlich richtige Vorgehensweise ist, und commit um 17:46 durchgeführt, Zeit Differenz kannst aber jetzt selbst kalkulieren.

Oh Nein, das war nur ein blöder Scherz, und in keinster Weise ernst gemeint.
Ich bin ein Fan von Verschwörungstheorien und finde die Paranoia, die meist daraus entspringt, sehr amüsant. Und manchmal klingt es hier auch ein bissel so. Deshalb...

Ich gebe zu, man kann es falsch verstehen.
War aber echt nicht so gemeint.

piratos · 23. Dezember 2011 11:33

Nun mal keine künstliche Aufregung - es haben doch einige etwas davon:

1. einem wurde direkt geholfen
2. der andere (ich) musste feststellen, das er eine bereits vor über 2 Jahren gefixte Sache unabsichtlich wieder in die laufende Schiene kopiert hat
3. Die CMSMS DEV Org hat auch etwas gemacht

Ich kann nur sagen das CG sich auch bei mir öfters umschaut - so hat er sich bei mir die Smarty 3 Thematik genau angesehen. Ich finde - das ist völlig normal gut und richtig, das man sich mal umschaut.

Zu 2. aber noch ein kleiner Hinweis.
Der damalige Fix beinhaltete noch eine zweite Sache.

style.php? führt bei manchen Proxyservern dazu, das die CSS nicht durchgelassen wird, weil man eine statische Sache erwartet und auf das ? als Kennzeichnung für eine dynamische reagiert.

Ich hatte das damals auf style.php/blah= geändert und das Thema war damit ebenfalls erledigt.

Forum für CMS/made simple

#26 22. Dezember 2011 14:01

Re: [GELÖST] Firefox zeigt Login und Backend ohne Styles an

#27 22. Dezember 2011 14:12

Re: [GELÖST] Firefox zeigt Login und Backend ohne Styles an

#28 22. Dezember 2011 14:26

Re: [GELÖST] Firefox zeigt Login und Backend ohne Styles an

#29 22. Dezember 2011 14:33

Re: [GELÖST] Firefox zeigt Login und Backend ohne Styles an

#30 22. Dezember 2011 14:35

Re: [GELÖST] Firefox zeigt Login und Backend ohne Styles an

#31 22. Dezember 2011 15:11

Re: [GELÖST] Firefox zeigt Login und Backend ohne Styles an

#32 22. Dezember 2011 15:28

Re: [GELÖST] Firefox zeigt Login und Backend ohne Styles an

#33 22. Dezember 2011 15:49

Re: [GELÖST] Firefox zeigt Login und Backend ohne Styles an

#34 22. Dezember 2011 15:51

Re: [GELÖST] Firefox zeigt Login und Backend ohne Styles an

#35 22. Dezember 2011 16:04

Re: [GELÖST] Firefox zeigt Login und Backend ohne Styles an

#36 22. Dezember 2011 16:11

Re: [GELÖST] Firefox zeigt Login und Backend ohne Styles an

#37 22. Dezember 2011 17:27

Re: [GELÖST] Firefox zeigt Login und Backend ohne Styles an

#38 22. Dezember 2011 17:42

Re: [GELÖST] Firefox zeigt Login und Backend ohne Styles an

#39 22. Dezember 2011 17:52

Re: [GELÖST] Firefox zeigt Login und Backend ohne Styles an

#40 22. Dezember 2011 19:12

Re: [GELÖST] Firefox zeigt Login und Backend ohne Styles an

#41 22. Dezember 2011 19:20

Re: [GELÖST] Firefox zeigt Login und Backend ohne Styles an

#42 22. Dezember 2011 20:13

Re: [GELÖST] Firefox zeigt Login und Backend ohne Styles an

#43 22. Dezember 2011 20:40

Re: [GELÖST] Firefox zeigt Login und Backend ohne Styles an

#44 22. Dezember 2011 21:46

Re: [GELÖST] Firefox zeigt Login und Backend ohne Styles an

#45 22. Dezember 2011 22:01

Re: [GELÖST] Firefox zeigt Login und Backend ohne Styles an

#46 22. Dezember 2011 22:04

Re: [GELÖST] Firefox zeigt Login und Backend ohne Styles an

#47 22. Dezember 2011 22:23

Re: [GELÖST] Firefox zeigt Login und Backend ohne Styles an

#48 23. Dezember 2011 23:05

Re: [GELÖST] Firefox zeigt Login und Backend ohne Styles an

#49 23. Dezember 2011 00:12

Re: [GELÖST] Firefox zeigt Login und Backend ohne Styles an

#50 23. Dezember 2011 11:33

Re: [GELÖST] Firefox zeigt Login und Backend ohne Styles an

Fußzeile des Forums