Einbinden von StyleSheets (CSS-Dateien)
Eingetragen von erich (52)am 01.11.2006 - 09:02 Uhr in
Angeregt durch den Beitrag CSS durch Code in node einbinden möchte ich eine weitere Möglichkeit aufzeigen, wie man die Stylesheets in mehrere Dateien aufspalten kann. Wenn man dann einzelne nodes gezielt anders gestalten will, kann man dieses ja über ihre id-Attribute erreichen.
Auf unserer preetzlug.de-Seite benutzen wir als theme ein modifiziertes bluemarine und haben es preetzlug genannt; die CSS-Dateien zur Gestaltung der Seiten liegen also im Verzeichnis themes/preetzlug.
Der (logische) Seitenaufbau wird in der themes/preetzlug/page.tpl.php-Templet-Datei beschrieben. Dort finden wir im <head>-Element die Zeile
<?php print $styles ?>
Über diese Anweisung werden sowohl die /misc/drupal.css- als auch die /themes/preetzlug/style.css-Datei eingebunden. Die erste enthält erste Vereinbarungen für die Seitengestaltung und durch die zweite wird das Aussehen des bluemarine-Theme maßgeblich bestimmt.
Bisher wurde die style.css-Datei unseren Gestaltungswünschen entsprechend modifiziert und erweitert. Dieses führte nicht gerade zu einer guten Dokumentation und Übersichtlichkeit, deshalb soll die ursprüngliche Datei erhalten bleiben und die neuen
Stilinformationen sollen in gesonderten Dateien gespeichert werden; in der ursprünglichen Datei sollen die Regeln, die im Widerspruch zu neuen stehen können, aus Gründen der Dokumentation nur auskommentiert werden.
Um dieses Ziel zu erreichen, wollen wir die schon erwähnte Anweisung
<?php print $styles ?>
in der page.tmp.php-Datei erweitern.
Wir ersetzen sie durch die folgenden
<?php
global $styles;
$styles .= '<style type="text/css" media="all">@import "/'
. path_to_theme() . '/style.css";</style>';
$styles .= '<style type="text/css" media="all">@import "/'
. path_to_theme() . '/eigene.css";</style>';
$styles .= '<style type="text/css" media="all">@import "/'
. path_to_theme() . '/runde-ecken.css";</style>';
print $styles
?>Hierdurch werden die drei CSS-Dateien importiert; wir können uns dazu die Wirkung im Quellcode, der zum Browser geschickt wird, ansehen. Warum die style.css-Datei nochmal explizit aufgeführt sein muss, ist mir nicht klar.
Die Funktion path_to_them() scheint unter drupal-4.7.2 und drupal-4.7.4 einmal einen relativen und einmal einen absoluten Pfad zu generieren. Ich hatte jedenfalls Schwierigkeiten bei der 1-1 Übertragung.
- Anmelden oder Registrieren um Kommentare zu schreiben
Zum importieren
am 01.11.2006 - 11:19 Uhr
Zum importieren benutzerdefinierter CSS-Styles existieren in Drupal auch sehr komfortable Funktionen [1][2][3][4], die man sowohl in einem Modul, als auch in der template.php eines Themes aufrufen kann.
[1] http://api.drupal.org/api/4.7/function/theme
<?phptheme('add_style', drupal_get_path('module', 'mymodule').'/mymodule.css');
?>
[2] http://api.drupal.org/api/4.7/function/theme_add_style
<?phptheme_add_style(drupal_get_path('module', 'mymodule')).'/mymodule.css');
?>
[3] http://api.drupal.org/api/4.7/function/drupal_set_html_head
<?phpdrupal_set_html_head('<link rel="stylesheet" type="text/css" media="all" href="'.base_path().drupal_get_path('theme', 'base').'/css/layout.css" />');
?>
und für Drupal5.0
[4] http://api.drupal.org/api/HEAD/function/drupal_add_css
<?phpdrupal_add_css(drupal_get_path('module', 'mymodule')), 'module', all')
?>
--
sanduhrs - drupalcenter
--------------------------------
http://erdfisch.de
was heißt hier komfortabel?
am 01.11.2006 - 14:24 Uhr
Einerseits interessant aber andererseits: was heißt hier komfortabel?
Wenn ich verstanden habe, was die Variable
$stylesbedeutet, dann muss ich sie nur für jedes zusätzliche Stylesheet um'<style type="text/css" media="all">@import "/pad/zum/stylesheet.css";</style>'verlängern; das wird mit den drupal-eigenen Funktionen weder kürzer noch schneller in der Ausführung.Etwas anderes ist es, wenn ich keine Berechtigung habe, die page.tpl.php-Datei zu ändern.
Vielleicht stellt sanduhrs dar, ob und wie das mit den drupal-eigenen Funktionen geht.
erich
Guter Thread...
am 02.11.2006 - 02:11 Uhr
Servus, Erich.
Nun bin ich ja kein PHP Wizzard, aber ich meine, dass globale Variablen innerhalb der Session global sind. Dann würde dein Ansatz aber bei jedem Aufruf von Page.tpl.php die selben Einträge immer wieder an die Variable anfügen - oder ist dem nicht so? Zum testen fehlt mir leider jetzt die Energie...
Wie auch immer, die Drupal APIs haben schon noch ein paar Vorteile. Zum Beispiel muss ich den Pfad zum CSS gar nicht kennen, und wenn nun jemand dein Theme nach 'theme/foo' kopiert, muss er jedenfalls die page.tpl.php umackern, mit den geeigneten Drupal APIs wäre das überhaupt kein Thema.
Und grundsätzlich sollte man in einem System, das versucht, Objekt-orientiert zu agieren, die Systemvariablen nicht einfach "weil es möglich ist" schreibend benutzen. Das löchert zumindest die Idee, und irgendwann knallt es irgendwo und dann wird die Problemeingrenzung schon etwas mühsam, reden wir erst nicht von "online Support" wie hier.
Also selbst wenn die Lösung für dich funktioniert, als Lehrbuch-Eintrag würde ich das nicht empfehlen...
Norbert
Re: Guter Thread...
am 02.11.2006 - 08:27 Uhr
Und grundsätzlich sollte man in einem System, das versucht, Objekt-orientiert zu agieren, die Systemvariablen nicht einfach "weil es möglich ist" schreibend benutzen. Das löchert zumindest die Idee, und irgendwann knallt es irgendwo und dann wird die Problemeingrenzung schon etwas mühsam, reden wir erst nicht von "online Support" wie hier.
Norbert
Moin Norbert
Ich stimme Dir zu, dass man grundsätzlich keine globalen Variablen verändern sollte, um die Integrität des Systems nicht zu gefährden.
Im dargestellten Fall entsteht bei mir jedoch kein iterativer Effekt.
Die eigentliche Schwierigkeit sehe ich eher darin, wie finde ich das geeignete API, und wenn ich es dann habe, wie sind die Parameter zu verstehen; als relativer Neuling steht man da doch wie der Ochs vorm Berge.
Erich
Die Leiche im Keller
am 02.11.2006 - 12:56 Uhr
Servus, Erich.
Wahrscheinlich sollte man sich das Engagament in Drupal gründlich überlegen, bevor man viel Zeit (und die braucht's sicher) aufwendet. Wenn man das Gefühl hat, mit Drupal einen Glücksgriff getan zu haben, dann ist es wie mit jedem anderen Werkzeug auch: die Details zu kennen und die richtige Anwendung zu finden macht den Unterschied. Oder anders gesagt: nicht jeder, der ein Stemmeisen im Baumarkt kauft, wird deshalb zum Michelangelo.
Drupal ist ein Websiten-Baukasten, der neben einer Unmenge fertiger Funktionen vor allem ein sehr gut dokumentiertes und stringentes API bietet. Das sind also die "Keyfeatures", und wenn man genau die umgeht, macht man sein Werkzeug langfristig kaputt. So ähnlich wie wenn man einen Schraubenzieher zum Stemmen verwenden würde.
Wenn man sich für ein komplexes Werkzeug entscheidet, sollte das bei dem Aufwand, den man investieren muss, eine zumindest "mittelfristige" Entscheidung (so die nächsten drei bis fünf Jahre) sein. Wenn man dann in der üblichen Verzweiflung über fehlenden Durchblick Dinge "mal schnell so her biegt", besteht zumindest immanent die Gefahr, dass sich das in einer relativ weit entfernten Zukunft plötzlich rächt und man zu dem Zeitpunkt dann (teuer) bezahlt, was man zu Beginn der Lernkurve als Abkürzung betrachtet hat.
Vielleicht kommt die erste Site nicht ganz so rasch in die Gänge, wie man sich das wünschen würde, aber auf Dauer ist das bedächtige "Antasten" und Lernen der rentablere Weg. "So mal schnell" geht nach meiner 15 Wochen Erfahrung mit Drupal gar nichts, denn ein wenig später kommt man dann drauf, dass man sich mit Abkürzungen selbst im Weg steht.
Das macht Drupal sicher zur eher "harten Kost" am Anfang. Das sollte aber aus den erwähnten Gründen nicht dazu führen, Abkürzungen zu stricken, wenn man sich nicht aller Konsequenzen bewusst ist.
Resumeé: Lieber drei Stunden durch die Doku surfen, als in einer halben Stunde eine Abkürzung suchen und bauen, nach der man in wenigen Monaten dann einen halben Tag suchen muss.
Norbert
Vielleicht lebt die Leiche noch!
am 02.11.2006 - 13:47 Uhr
Hallo Norbert,
Drupal ist in der Entwicklung, wenn auch die Kinderschuhe abgelegt sein mögen; schon naht Drupal 5! Die bessere Einsicht ist immer das Resultat überholter Aspekte.
Ich erwarte, das Drupal mich darin unterstützt, Inhalt und Darstellung klar trennen zu können. Dazu gehört für mich beispielsweise, dass jeder node mit einem id-Attribut generiert wird, damit ich daran seine Darstellung über eine CSS-Datei festlegen kann; auch gehört dazu, dass mir auf der Administrationsebene die Möglichkeit angeboten wird, verschiedene CSS-Dateien einzubinden. Für beides will ich nicht erst die Programmtexte studieren und über ein API verändern müssen.
Grüß Dich
Erich
Nehmen Sie Linux? Ja, klar doch!