{GELÖST} parse_css_file=on verursacht SQL Error (subsilver2)

[Testusmania99]

Hallo!

Ich ärgere mich nun seit gestern mit einem merkwürdigen Phänomen herum.
Und zwar muss ich jetzt nun in meinem eigenen, auf SubSilver2 basiertem, Style "parse_css_file" von standard off zu on wechseln, damit ich auch die Pfadvariabeln benutzen kann. (für englische und deutsche buttons z.b.)
Soweit eigentlich kein Problem oder? Naja, schon.

Denn wenn ich den Status auf On (oder 1) setze, die theme/theme.cfg hochlade, gibt es nach einem aktualisieren meines Forums einen kompletten Ausfall mit SQL Fehler.
Der Fehler sieht so aus, dass das komplette Forum "verschwunden" ist und man ausschließlich diesen SQL Fehler sehen kann:

Allgemeiner Fehler
SQL ERROR [ mysqli ]

Incorrect string value: '\xF6rte z...' for column 'theme_data' at row 1 [1366]

SQL

UPDATE phpbb_styles_theme SET theme_data[....] ellenlanger Text mit CSS angaben
[...]
BACKTRACE

FILE: includes/db/mysqli.php
LINE: 163
CALL: dbal->sql_error()

FILE: includes/session.php
LINE: 1726
CALL: dbal_mysqli->sql_query()

FILE: adm/index.php
LINE: 27
CALL: user->setup()

Hierfür richtete ich mich im Groben und Ganzen nach einem anderen Subsilver2 basiertem Style, um den entsprechenden Code für den ProSilver-Hovereffekt der Buttons (antworten, neues thema etc. pp.) herauszukopieren, und nach diesem englisch sprachigen Thread ebenfalls nach Hilfestellung gesucht:
http://www.phpbb.com/community/viewtopic.php?p=7114025

Klar habe ich versucht meinen Style zu deinstallieren, prosilver dann als standard und aktiv gesetzt und anschließend wieder meinen eigenen Style mit "parse_css_file = on" installiert und auf aktiv gesetzt. Genau derselbe Fehler trat dann erneut auf.

Also, irgendwo muss doch noch ein Fehler sein oder?
Ich meine, offensichtlich sieht es so aus, als dass das CSS aus der Datenbank nun gelesen werden soll, es aber irgendwie nicht dazu kommt - weswegen auch immer.

Muss ich vielleicht noch irgendwo anders etwas machen oder das CSS in die Datenbank irgendwie integrieren?
Ich wäre für jeden noch so kleinen Tipp sehr dankbar.
Vielen Dank!

Lg, Testusmania99

[Pyramide]

Es scheint so, als hättest du in der CSS-Datei nicht-ASCII-Zeichen verwendet und die Datei dann nicht als UTF-8 gespeichert (\xF6 ist ein kleines ö in ISO-8859-1 & co). Wenn du die Datei als UTF-8 ohne BOM speicherst, sollte es funktionieren. Siehe auch KB:utf8bom

[Testusmania99]

Ok, ich habe selbst meine Fehler gefunden. Es stand irgendwo im Internet geschrieben, dass, wenn genau mein SQL Fehler auftritt, ein fehlerhaftes CSS dafür verantwortlich ist.
Somit habe ich bis eben verzweifelt nach den "Fehlern" gesucht und, Ihr glaubt es echt nicht, ich habe alle Fehler gefunden.
Und ich habe wieder mal dazu gelernt, was auch nirgends geschrieben steht:
-> KEINE Umlaute in der CSS Datei für Kommentare (z.B. /* äöü */)
Dadurch entsteht genau mein SQL Fehler!
-> UND Bildpfade (images/...) MÜSSEN immer mit "./" beginnen, da diese sonst nicht geladen werden.

Puuuhhh, das war 'ne Arbeit bis eben. Aber es ist alles gelöst und mein Problem hat sich somit in Luft aufgelöst.

EINE FRAGE hätte ich aber noch: Gibt es Geschwindigkeitsvorteile, wenn man auch das Template in der Datenbank ablegt?
Vielen Dank!

Lg, Testusmania99

EDIT:
Hallo Pyramide. Du warst ja eine Minute schneller als ich.
Ja, genau das war es auch. Warum eigentlich darf man keine Umlaute verwenden? In der CSS Datei kann man ja auch das Charset mit angeben, welches aber offensichtlich gar keine Bedeutung hat.

[Pyramide]

-> UND Bildpfade (images/...) MÜSSEN immer mit "./" beginnen, da diese sonst nicht geladen werden.

Dafür gibt es die {T_THEME_PATH}, die sich dann automatisch anpasst, damit es auch noch funktioniert, wenn man eine Datei in einem Unterordner aufruft. Siehe z.B. die colors.css von prosilver.

Warum eigentlich darf man keine Umlaute verwenden?

Darf man doch, allerdings muss die Datei immer als UTF-8 ohne BOM gespeichert werden. Da in deiner Fehlermeldung \xF6 bemängelt wurde, war deine offenbar mit einem 8bit Zeichensatz wie ISO-8859-1/15 oder windows-1252 gespeichert.

In der CSS Datei kann man ja auch das Charset mit angeben, welches aber offensichtlich gar keine Bedeutung hat.

Wenn du @charset meinst, dann gilt diese Angabe nur für den Browser. phpBB verwendet aber intern ausnahmslos UTF-8, also müssen auch alle Dateien in diesem Zeichensatz gespeichert werden.

[Testusmania99]

Hallo und vielen Dank für diese weitreichenden Informationen!

Es ist sehr aufschlussreich zu lesen, dass ich mein Dreamweaver hierfür falsch eigenstellt haben muss. Denn auch die CSS Dokumente werden standardgemäß mit win-iso neu erstellt. Somit waren tatsächlich keine Umlaute möglich. Ich habe eben alles richtig eingestellt und meine sämtlichen CSS Dateien richtig formatiert.
Ein Fehler, der mir hätte nicht passieren dürfen.
Wieder also eine Notiz mehr, die ich hinter mein Öhrchen schreiben muss!

{T_THEME_PATH} etc., habe ich eigentlich meistens ausser Acht gelassen, da es ja vorher nicht überall funktionierte. In CSS schon, ja, jedoch nicht in einigen Templatedateien von mir. Jetzt mit der Umstellung auf die Datenbank, werde ich mich noch darum bemühen, alle Pfade (./images) mit {T_THEME_PATH} zu berichtigen und etliche andere Möglichkeiten mit "T_IMAGESET_LANG_PATH" erweitern. *freu*
Vielen Dank auch für diesen Hinweis!

Alles in Einem, ist durch Deine Antwort ein sehr hilfreicher Thread für mich geworden. Und ich dachte, ich wüsste schon soo viel, dass mir so etwas hätte nie passieren dürfen.
Ich bedanke mich jedenfalls sehr herzlich für Deine Geduld mit mir und wünsche Dir noch einen angenehmen Sonntag!

Lg, Testusmania99

[Crizzo]

Dafür gibt es die {T_THEME_PATH}, die sich dann automatisch anpasst, damit es auch noch funktioniert, wenn man eine Datei in einem Unterordner aufruft. Siehe z.B. die colors.css von prosilver.

Das könnte man auch einfach so umgehen, dass man statt {T_THEME_PATH} einfach absolut verlinkt und nicht relativ zum Dokument, oder nicht?

[Pyramide]

Eine absolute URL hat man ja nur dann, wenn man das Theme ausschließlich für ein einziges Forum entwickelt. Wobei es selbst dann nicht mehr funktioniert, wenn man das ganze lokal testet oder irgendwann mal das Forum umzieht. Wenn möglich, sollte man also immer relative URLs verwenden.

[Crizzo]

Eine absolute URL hat man ja nur dann, wenn man das Theme ausschließlich für ein einziges Forum entwickelt. Wobei es selbst dann nicht mehr funktioniert, wenn man das ganze lokal testet oder irgendwann mal das Forum umzieht. Wenn möglich, sollte man also immer relative URLs verwenden.

Da hab ich mich wohl falsch ausgedrückt. Aber ich meinte nicht, dass immer http://www.meinedomain.de dazu kommt, sondern einfach sowas geschrieben wird:

Code: Alles auswählen

.bla {
background-image: url(/styles/prosilver/imageset/forum_unread.gif);
}

Damit geht der Browser immer auf den Ursprung der Domain. Also hier "meinedomain.de" und sucht dann von dort ausgehend nach dem Ordner "styles" und so weiter.

Nützt natürlich nix, wenn man den gleichen Style mal in meindomain.de und meineanderedomain.de/forum/ nutzt.