Beiträge von threadi

Dafür braucht man nicht zwingend PHP. Wichtig ist lediglich, dass ein bestimmter Content-type gesetzt wird. Das geht auch z.B. über htaccess, Servereinstellungen oder mit jeder anderen Webprogrammiersprache. Ich würde htaccess vorziehen, wenn das restliche Web aus bisher statischen Seiten besteht.

Ich verwende dafür

html { overflow-y: scroll; }

Das Problem betrifft ohnehin nur einige Browser die nicht von Microsoft stammen. Daher kann man das ruhig so schreiben statt height zu missbrauchen.

Der HTML-Code selbst ist schonmal sehr fehlerhaft.

Du verwendest z.B. <center>, welches man eigentlich gar nicht mehr nutzen sollte (Zentrierung wird per CSS erreicht) und noch dazu steht es an einer Stelle an der es nicht hingehört (zwischen <ul> und <li> darf nichts anderes stehen).

Außerdem gibt es das Element <list> nicht beim XHTML 1.0-Standard, welchen dein Doctype angibt.

Mach erstmal den HTML-Code valide bevor Du sich weiter um die Darstellung kümmerst.

Mal sehen wie lange er tot ist ..

Du beziehst dich auf E-Mails die sowohl HTML als auch Text enthalten. Das E-Mail-Programm des Empfängers entscheidet dann je nach Einstellung, ob das HTML-Format der E-Mail angezeigt wird oder nicht.

Um E-Mails die sowohl HTML als auch Text verschicken zu erzeugen, musst Du dich mal das E-Mail-Format genauer anschauen. Mit HTML hat das nämlich rein gar nichts zu tun. Die E-Mail muss nämlich in verschiedene Bereiche getrennt werden, Teile des Multiparts:
- den Bereich mit dem Content-type text/html der HTML-Code und somit die HTML-Ansicht der E-Mail enthält
- den Bereich mit dem Content-type text/plain der keinen HTML-Code und somit die rein textliche Ansicht der E-Mail enthält

Ein Beispiel dafür habe ich gerade für Dich unter
http://www.dominik-boecker.de/email/beispiel.html
gefunden. Weitere findest Du wenn Du mal nach multipart suchst.

Selbst kannst Du natürlich solche E-Mails auch verschicken. Wenn Du die E-Mail auf dem Server zusammenbaust, musst Du vor der Übergabe dieser E-Mail an den MTA den Inhalt der E-Mail genau so trennen wie es für Multipart-E-Mails vorgesehen ist.

Noch ein paar Infos:
http://www.wilsonweb.com/wmt5/html-email-multi.htm

Nein, änder das auch in

submit.submit();

So wird das Formular korrekt abgeschickt.

Die richtige URL lautet:
http://rabidwolverine.ra.funpic.de/index.html

Und dort sehe ich einen grauenhaften HTML-Code dem auch ein Doctype fehlt.
http://validator.w3.org/check?verbose=…de%2Findex.html

Kein Wunder, dass die Browser machen was sie wollen.

Das hier

<meta charset="utf-8" />

ist auch keine korrekte Angabe eines Zeichensatzes. Zudem liefert dein Webserver im Header (hat nichts mit dem HTML-Code zu tun!) den

Content-Type: text/html; charset=ISO-8859-1

zurück, weshalb Du entweder alle Zeichen in ISO-8859-1 kodieren müsstest oder deinen Webserver entsprechend umstellen müsstest, dass er utf-8 oder gar nichts als Zeichensatz zurückliefert. Die Browser richten sich immer primär nach der Angabe im Header, nicht nach der Angabe im HTML-Code.

Außerdem bitte die Tipps von MrMurphy beachten. Ich würde auch dringend empfehlen das Tabellengrundgerüst sowie die Verwendung von Bildern statt richtigen Texten zu überdenken. Diese besondere Schriftart kann man, wenn man die Rechte dafür hat, auch in die Webseite einbetten.

Wieviele Datensätze sind da drinne? Welche MySQL-Version? Schonmal "Messen" im phpmyadmin probiert? (dort vergleiche ich sowas gerne)

Ein Produktkonfigurator ist immer eine Individuallösung, denn Produkte die sowas ermöglichen sind immer unterschiedlich. Selbst bei Schuhen kann man nicht alles so sehr vereinheitlichen, dass man diese in einem Konfigurator zusammenstellen kann, ganz zu schweigen von den Produktionskosten. Aber möglich ist es alle mal - nur weil es eben Individual ist, muss man zunächst alle Details definieren. Nur dann kann man auch einen Preis dafür schätzen. Wie gesagt: nicht alle Produkte sind gleich.

Und auch die Bezahlung von einem so zusammengestellten Produkt kann sehr unterschiedlich sein. Es stehen Dutzende Zahlweisen zur Verfügung. Manche erleichtern den Kauf den Kunden, andere wiederum dem Verkäufer, einige auch beiden. PayPal, soforueberweisung.de, Kreditkartenzahlung .. alles ist möglich - alles kostet aber auch je nachdem, welches System die Grundlage für die Webseite ist, auch mehr oder weniger Geld.

Da der Konfigurator quasi eine Individuallösung wäre, müsste man auch die Zahlungen und die Verwaltung des ganzen individuell programmieren. Nach meiner Erfahrung geht sowas selten unter einem 4stelligen Betrag. Monatliche Kosten für Hosting, Domain, Support .. kommen noch dazu.

Mein Tipp: such dir einige Agenturen raus die dir sowas zusammenstellen könnten und fordere von denen auf Basis eines detaillierten (!) Lastenheftes ein Angebot an.

Änder

var submit = document.getElementById("actionSubmit");

in

var submit = document.getElementById("actionForm");

Hintergrund: submit() wirkt nur bei Formularen, nicht bei Formularfeldern.

JOINs haben den Nachteil, dass sie innerhalb der Datenbank-Engine mehr Abfragen erzeugen. Führe mal ein Explain und Miss die Zeit für ein Statement mit JOIN aus und mach das selbe nochmal mit WHERE. Ich habe die Erfahrung gemacht, dass man auf JOIN besser verzichten sollte. Die Geschwindigkeit, gerade bei großen Datenbanken, kann dadurch noch gesteigert werden. Die Übersichtlichkeit kann man dagegen mit einer ordentlichen Einrückung und Zeilenumbrüchen einfach erreichen.

Code kopieren, hier einfügen, und am Besten mit [ CODE ] und [/ CODE ] umgeben (ohne die Leerzeichen dazwischen).

Und wo ist das Formular? Zeig bitte den problematischen HTML-Code, nicht nur einen Ausschnitt.

Du kannst den Quellcode auch hier posten, falls man dann noch etwas ohne Bilder erkennt.

Tabellenverknüpfung mit MySQL läuft über die Angabe von den anzusprechenden Tabellen im FROM und deren Verbindung zueinander im WHERE. Beispiel:

SELECT * FROM bilder, user WHERE bilder.userid = user.userid

Näheres:
http://dev.mysql.com/doc/refman/5.1/de/select.html
http://www.schattenbaum.net/php/mstart.php
http://alice-grafixx.de/PHP-MYSQL-Tuto…ERE-Klausel-151
...

Ich sehe da nur eine weiße Seite. Im Quelltext sehe ich einen grauenhaften HTML-Code ohne Doctype und <head>-Bereich. Wundert mich nicht, dass es da Probleme gibt. Korrigiere die HTML-Fehler, dann lebt es sich auch besser.

Zeig doch mal einen Link zur Seite damit man den Quellcode sehen kann. Ohne den wird es nur rummraten.

Es würde auch genügen die index.html als DirectoryIndex zu definieren. Siehe Manual:
http://httpd.apache.org/docs/2.0/mod/mod_dir.html

CSS-Regeln werden in der Reihenfolge abgearbeitet in der sie in der CSS-Datei stehen. Die Reihenfolge der Klassen im HTML-Code spielt keine Rolle. Und das interpretiert nicht Plone sondern dein Browser, daher ist der Firebug durchaus hilfreich.

Relevant ist der HTML-Code der in deinem Browser ankommt. Nicht der Quellcode der als Grundlage für die Generierung genutzt wird. Also zeig den Link zur betreffenden Seite oder den HTML-Code den Du in deinem Browser siehst. Ansonsten kann man nur raten was "navTreeCurrentItem" nun für eine Bedeutung hat.