civicrm 1.5b, drupal 743, php5: formatierung laeuft aus dem container
Eingetragen von Anonymous (0)am 01.09.2006 - 16:00 Uhr in
hallo!
seit kurzer zeit beschaeftige ich intensiv mich mit Drupal. ich finde das system angenehmer zu handhaben als viele andere CRM- und portal-loesungen. eigentlich bin ich persoenlich aus administratorensicht kein freund von PHP, habe also wenig kenntnisse ueber die programmierung in dieser sprache.
ein Drupal-theme habe ich mir bereits erstellt. natuerlich habe ich schon einige module installiert und getestet.
nun zum unangenehmen teil:
wird ein neuer kontakt mit civicrm/contact/add?ct=Individual&reset=1#notes erstellt, geraet die seite aus den fugen:
das [html]fieldset Name und Begrüßung ist breiter als die als der mit 600px breite uebergeordnete div-container dies zulaesst/zulassen sollte. eine verkleinerung der font-size fuer die input-tags brachte nur maessige verbesserung. dann habe ich mir mit folgender kruecke im CSS beholfen:
div#name {
width: 580px;
overflow: auto;
}das resultat ist ein vertikaler scrollbalken fuer das fieldset, den ich im praxiseinsatz als huerde empfinde, da man zum nachnamen scrollen muss. (das gleiche gilt im uebrigen auch fuer die tabs in der verwaltung der kontakte.)
gibt es noch andere ansaetze?
eine aehnliche huerde habe ich im div-tag "id_location_1_show", das fuer die darstellung des primaeren standortes zustaendig ist. dort wird das fieldset in der passenden breite angezeigt, allerdings werden dort alle links, die das "... verstecken" ermoeglichen, ausserhalb der umgebenden div-container angezeigt und verdecken dadurch die rechts davon befindliche navigation oder verlassen die seite ganz.
das oben gesagte gilt analog fuer alle div-tags "id_location_...".
hat jemand aehnliche beobachtungen gemacht oder kann mir mit der laterne eine richtung zeigen?
vielen dank im voraus
ag
- Anmelden oder Registrieren um Kommentare zu schreiben
Kein Drupal Problem
am 01.09.2006 - 20:52 Uhr
Was du hier schilderst ist kein Drupal Problem, sondern 'nur' ein Problem des Themes und des CSS welches du benutzt. Du kannst davon ausgehen, dass solange irgendein HTML Element bei "overflow:auto" horizontale Scrollbalken anzeigt, seine Breite nicht für den Inhalt ausreichend ist.
Drupal ist übrigens kein CRM-System. CivicCRM ist ein Modul von CivicSpace - http://civicspacelabs.com/ - die eine andere Distribution von Drupal anbieten.
md - drupalcenter
-----------------
www.mdwp.de
vg
md - DrupalCenter.de
mdwp* Drupal Consulting & Services
die meisten webseiten werden
am 01.09.2006 - 22:37 Uhr
die meisten webseiten werden von mir auf eine breite von 800px konzipiert, da ich einige, vor allen dingen aeltere mitmenschen, kennengelernt habe. damit bleibt bei etwas navigation neben dem hauptcontainer gerade mal ca. 600px platz. willst Du mit dem was Du schreibst zum ausdruck bringen, dass ich bei einsatz solcher module bei meinem konzept gegen die wand laufe?
richtig, Drupal ist kein CRM, CiviCRM bietet CRM-funktionalitaet. da waren die finger etwas schneller...
mal etwas nachgepiekt:
CiviCRM habe ich von drupal.org als modul fuer Drupal heruntergeladen und ich stelle auch nicht in frage, dass es ein wesentlicher bestandteil von CiviSpace ist; warum schreibst Du nicht, es sei a u c h ein modul von CiviSpace?
gibt es unliebsamkeiten||vorbehalte bei CiviCRM?
das ist warscheinlich etwas off topic?
ag
CivicSpace
am 01.09.2006 - 22:54 Uhr
warum schreibst Du nicht, es sei a u c h ein modul von CiviSpace?
gibt es unliebsamkeiten||vorbehalte bei CiviCRM?
CivicCRM ist ein Drupal Modul von CivicSpace.
Und, es gibt keinerlei Unliebsamkeiten/Vorbehalte gegenüber Civicspace!
Die machen seit Jahren eine herrausragende Arbeit.
Ob du mit Modulen welcher Herkunft auch immer, mit 800px Breite gegen die Wand fährst, kann man nicht so einfach beantworten.
Hat dein Layout 2 oder 3 Spalten. Manchmal kann man für 800px auch mit einem horizontalen Scrollbalken leben. Willst du das nicht,
musst du halt irgendwie mit dem spärlichen Platz auskommen.
Das ist ein Problem, dass nichts mit Drupal oder welchem CMS auch immer zu tun hat. Es ist ein Problem jeder Website, für das man immer
eine 'optimale' Lösung finden muss.
md - drupalcenter
-----------------
www.mdwp.de
vg
md - DrupalCenter.de
mdwp* Drupal Consulting & Services
module und "schmale" seite
am 01.09.2006 - 23:31 Uhr
danke fuer die erhellung bezueglich CiviCRM!
die sache mit den modulen stellt sich deshalb als herausforderung dar, da diese meist nicht fuer ein bestimmtes webdesign programmiert sind und trotzdem miteinander verheiratet werden muessen. und damit hat dies schon etwas mit Drupal zu tun. wer ursache fuer das problem ist, ist mir egal; warscheinlich bin ich das, weil ich mir diese aufgabe gestellt habe.
in einem anderen beitrag wird behauptet, dass die breiten der textfeldlaengen per CSS definiert/ueberschrieben werden koennen. und keiner hat widersprochen. meine erfahrungen mit der style.css zeigen, dass dies nicht geht. denn wenn das gehen sollte, muesste es auch mit tabellen funktionieren - und mein problem waere geloest.
was ist Eure meinung dazu?
grund meiner unsicherheit ist erstens, dass ich bei eigenen webdesigns selbst die breite der elemente programmiere und nicht mit vorhandenen definitionen leben muss. und zweitens, dass ich seit geraumer zeit erfolglos damit kaempfe, den list-style im navigationsblock zu aendern/entfernen, was in anderen bloecken problemlos moeglich ist.
ga
CSS
am 01.09.2006 - 23:43 Uhr
da diese meist nicht fuer ein bestimmtes webdesign programmiert sind und trotzdem miteinander verheiratet werden muessen
Stell es dir mal umgekehrt vor: Module wären auf ein bestimmtes Design ausgerichtet. Und dann?
Drupal und die meisten Module liefern id's und/oder class-names (auch mehrere) für die generierten HTML Elemente.
Und diese kann man dann über CSS beliebig beeinflussen.
Auch Feldlängen von HTML Input-Elementen.
Welches Theme benutzt du denn?
md - drupalcenter
-----------------
www.mdwp.de
vg
md - DrupalCenter.de
mdwp* Drupal Consulting & Services
css
am 02.09.2006 - 00:15 Uhr
meine von Dir zitierte aussage war eher als bestaetigung und als meine arbeitsgrundlage verstanden, ich stimme Dir daher zu.
ich benutze ein selbst erzeugtes style.css. damit ich mich beim kennenlernen von Drupal nicht mit eigenem design-ideen verfranze, habe ich mir eine design-idee (nicht die programmierung) einer funktionierenden Drupal-seite fuer meine lokale testinstallation als vorlage genommen. das grund-design mit der anordnung des contents und der navigation habe ich mir bei drupal.mdwp.de abgeschaut. kennst Du den programmierer zufaellig? ;)
das heisst, ich habe folgende struktur:
<div1><div2></div2>
<div_rechte_seite>
</div_rechte_seite>
<div_content>
</div_content>
<div_foot>
</div_foot>
</div1>
dass die module ids/classes vorgeben, ist bekannt.
in meiner style.css stehen unter anderem erfolgreiche dinge wie:
div.block-blog li{list-style-type: none;
}
div.block-forum li{
list-style-type: none;
}
input {
font-size: 84%;
}
und auch nicht erfolgreiche dinge wie:
div.block-sitemenu ul.menu li{padding-left: 5px;
list-style-type: none;
}
div.block-user ul.menu li{
list-style-type: none;
}
input#edit-search-block-form {
width: 10px;
}
wobei nicht erfolgreich heisst, dass meine programmierung beim Konqueror erfolgreicher als beim Firefox ist; tests mit dem IE kommen erst spaeter.
ga
List-style-type
am 02.09.2006 - 12:22 Uhr
Hm, es wundert mich schon, dass der Konqueror etwas korrekt darstellt, der Firefox aber nicht.
Ich weiß jetzt natürlich nicht, was bei deinem CSS-Code deine Erwartung ist und was der FF daraus macht. Vielleicht ist das ja auch durchaus richtig.
Hat ja auch damit zu tun, wie dir Browser mit fehlerhaften Angaben im Code umgehen. Gnädig oder gnadenlos.
In deinem Code ist ja z.B. nicht ganz richtig, dass du list-style-type auf li Elemente anwendest.
Eigentlich ist das ein Attribut von ol und ul.
Schön, dass dir drupal.mwp.de so gut gefallen hat, dass du es als Vorlage genommen hast. Vielleicht sind da auch Fehler drin, ich kenne den Programmierer zufällig ;-)
md - drupalcenter
-----------------
www.mdwp.de
vg
md - DrupalCenter.de
mdwp* Drupal Consulting & Services
W3C und ergebnis
am 02.09.2006 - 14:20 Uhr
mich hat auch gewundert, dass der Konqueror etwas anders darstellt als der Firefox, zumal ich XHTML 1.0 strict verwende.
ich habe mal einen kommentierten screenshot gemacht, in dem die list-styles blau markiert sind. man kann im block menu und im block darunter erkennen, dass sich dort list-styles befinden. dagegen im untersten block Neueste Blockeinträge befinden sich keine punkte vor den einzelnen eintraegen und sind auch nicht ausgepixelt. in den bloecken darunter, die man nicht sehen kann, befinden sich auch keine discs vor den eintraegen.
das auspixeln habe ich mir uebrigens erlaubt, da ich die seite bereits im privaten einsatz habe und mein hirn etwas auslagere.
Dein einwand, list-styles nicht auf ul anzuwenden, kann ich verstehen, allerdings wurden bei mir mit einfuehrung von Drupal, was das ergebnis betrifft, die vorgaben des W3C etwas auf den kopf gestellt; das heisst, anders waere es meines erachtens richtig, funktioniert falsch aber besser.
[Nachtrag]
wie ich schon geschrieben habe, habe ich das design als vorlage genommen, nicht die programmierung zum design; also kein code kopiert oder abgeschrieben. das ergebnis koennte Deinem code vielleicht aehneln.
das design finde ich gelungen.
ga
Screenshot
am 02.09.2006 - 17:49 Uhr
Leider ist dein Screenshot nicht erreichbar.
wie ich schon geschrieben habe, habe ich das design als vorlage genommen
Das würde ich gerne mal sehen. Ich hoffe du hast nicht zuviel als 'Vorlage' genommen. Bei dem Layout handelt es sich um einen Teil meines Corporate Design.
md - drupalcenter
-----------------
www.mdwp.de
vg
md - DrupalCenter.de
mdwp* Drupal Consulting & Services
keine bedenken: corporate
am 03.09.2006 - 12:31 Uhr
beim screenshot handelt es sich um eine PNG-datei und die sollte erreichbar sein, sagen mir meine eigenen browser-tests.
zum corporate design ein wirklich freundlich gemeintes wort:
ich gehoere zu den leuten, die sich nicht die pein erlauben moechten/koennen (ego-geschichte), ein design in die netzwelt zu setzen, das so schon jemand anderes benutzt. aber in dem beitrag css habe ich eigentlich extra schon alles gesagt, wie zum beispiel lokale testinstallation oder grund-design etc.
ich habe ueberlegt, ob ich noch etwas weiteres drueber schreibe, aber bin zum entschluss gekommen, dass man wenn ein allgemeineren thread im off-topic dazu aufmachen koennte.
hoffentlich verstehst Du was ich meine ;)
wie gesagt, mein download-link funktioniert fuer mich; probier es doch nocheinmal aus und gib mir bescheid.
[nachtrag]
wie aeussert sich diese nichterreichbarkeit?
ga
Formatierung läuft aus dem container
am 03.09.2006 - 13:28 Uhr
Die Nichterreichbarkeit äusserte sich gestern darin, dass beim Aufruf einfach nichts geschah.
Jetzt gehts.
Also, dein Hauptproblem scheinen ja die Eingabemasken zu sein. Dies ist ein grundsätzliches Problem von vielen rDupal Themes bei 800x600 und festen Spaltenbreiten.
Ich mach mir dann immer ein extra Admin-Theme für 1024 oder größer. Eine andere Lösung gibts wohl nicht. Deine anderen Probleme scheinen sehr speziell zu sein und lassen sich per Ferndiagnose kaum lösen.
Grundsätzlich gilt: sehr genau auf die richtigen Selektoren, besonders sehr spezielle wie,
#sidebar-right .block .content ul li (nur ein Beispiel), zu achten.
Wenn du solche Selektoren überschreibst, musst du die auch genauso wieder angeben.
Dies gilt insbesondere für das Überschreiben aller in der 'misc/drupal.css' vorkommenden Selektoren.
Die haben mich auch schon zum Wahnsinn getrieben. Aber eigentlich lassen sich so alle Probleme lösen.
Off-Topic: ich wollte dir nicht zu nahe treten.
md - drupalcenter
-----------------
www.mdwp.de
vg
md - DrupalCenter.de
mdwp* Drupal Consulting & Services
beruhigt
am 03.09.2006 - 14:15 Uhr
dann scheinst Du den von mir beschriebene vorgang auch schon beobachtet zu haben. das beruhigt mich.
wahrscheinlich habe ich eventuellen content-administratoren unterstellt, dass sie aufloesungen kleiner 1024x768px benutzen. aber das sollte in der praxis ja wohl nicht der fall sein...
ich persoenlich finde bei primaerer nutzung von Drupal als blogmaschine schmalere themes angenehmer beim lesen von eintraegen; aber das nur am rande.
zum thema selektoren:
gerne ueberschreibe ich keine vom system vorgegebenen css-dateien. das haette ich gerne alles im style.css erledigt. beim event-calendar musste ich aber schon die modules/event/event.css anpassen, damit sie zu einem bestimmten design passen, da diese zum beispiel nach der style.css eingebunden wird. vielleicht ist dies aber nicht so schlimm, wenn man eine Drupal-seite fuer einen bestimmten zweck mit einem bestimmten design erstellt.
in jedem fall hast Du jetzt mindestens einen, der an dieser stelle mitfuehlen kann... ;)
ot:
das gesprochene wort waere weicher angekommen, als es bei geschriebenem manchmal scheint. aus eigenen erfahrungen kann ich Dir berichten, dass es sowas und sowas gibt... (jetzt waere es wirklich zeit fuer einen anderen thread)
nur soviel: es ist schwer die sichtweise eines anderen zu erahnen und: habe auch im ehemaligen beruf ohne kenntnis irgendwelcher genauen ...texte -ist manchmal eine schwaeche- mit verstand erfolgreich andere und mich vor den von Dir wage angetexteten fallen bewahrt.
;)
ga
Überschreiben
am 03.09.2006 - 14:27 Uhr
Hab mich wieder nicht deutlich ausgedrückt.
Mit 'Überschreiben' ist nicht gemeint, dass du die original Drupal.css oder eine CSS-Datei eines Moduls bearbeitest. Sondern, dass du den selben Selektor in deiner style.css neu definierts.
Das ist auch von Drupal.org empfohlene Praxis:
Beispiel:
In der drupal.css (die wird von allen Themes benutzt!) steht folgender Code:
ul.primary li a {background-color: #ddd;
border-color: #bbb;
border-width: 1px;
border-style: solid solid none solid;
height: auto;
margin-right: 0.5em;
padding: 0 1em;
text-decoration: none;
}
Möchtest du jetzt die Hintergrundfarbe eines Primary Links 'überschreiben', machste du folgendes in der style.css deines Themes:
ul.primary li a {
background-color: #333;
}
vg
md - DrupalCenter.de
mdwp* Drupal Consulting & Services
re: ueberschreiben
am 03.09.2006 - 14:34 Uhr
das ist mir schon klar. bei mir wird die modules/event.css nach der themes/.../style.css eingebunden. die style-definitionen fuer den kalender stehen in der event.css und da kann ich in meine style.css schreiben was ich will.
uebel das... ;)
ag
event.css
am 03.09.2006 - 14:52 Uhr
Dann läuft da irgendwas falsch. Die style.css sollte immer die letzte CSS-Datei sein, die eingebunden wird. Ich mein auch schon Sites mit dem Kalender und dem event Modul gesehen zu haben, bei denen das funktioniert. Den Archiv Kalender neu zu stylen funktioniert auf jeden Fall immer.
md - drupalcenter
-----------------
www.mdwp.de
vg
md - DrupalCenter.de
mdwp* Drupal Consulting & Services
einbindung css
am 03.09.2006 - 15:02 Uhr
eingebunden wird das im template bei mir mit
<head><title><?php print $head_title ?></title>
<meta http-equiv="Content-Style-Type" content="text/css" />
<?php print $head ?>
<?php print $styles ?>
</head>
und da habe ich wenig spielraum. das heisst, ich muesste die php-dateien direkt patchen.
mir geht es in erster linie um den event-kalender. den archiv-kalender benutze ich vielleicht spaeter mal.
oder habe ich da etwas missverstanden?
ag
Event Modul
am 03.09.2006 - 15:40 Uhr
Vielleicht schaust du mal auf der Projektseite des Event Moduls, ob das schon jemand als Fehler gemeldet hat und ob's dafür ein Patch gibt. Denn, wie gesagt, normal ist das nicht.
Schau mal hier: http://drupalcon.org/calendar
Und guck dir dann mal den Quellcode an. Dort ist das style.css - wie immer - das Letzte, das eingebunden wird.
md - drupalcenter
-----------------
www.mdwp.de
vg
md - DrupalCenter.de
mdwp* Drupal Consulting & Services
thread, $styles
am 03.09.2006 - 15:57 Uhr
irgendwie passen die letzten beitraege nicht mehr zum urspruenglichen, glaube ich. ab dem header Überschreiben koennte man einen neuen aufmachen. naja.
ob die einbindung am event-modul liegt? ist die variable in print $styles nicht in der includes/theme.inc (v.4.7.3) zeile 332 definiert?
ag