Einfache PHP-Shoplösung gesucht
Pierre
- php
Hallo
Ich hoffe ich verstosse hier nicht gegen die Forumsregeln, wenn ich nach einer PHP-Shoplösung frage. In meinem Webprojekt möchte ich eine einfache Shoplösung integrieren. Zahlungswesen brauchts net, einfach einen Warenkorb und wenn sich die Besucher anmelden können und später wieder erkannt werden wär das auch ganz toll. Und ne einfache Adminumgebung für den Shopbetreiber mit Bildupload und freier Definition der Kategorien.
Das Wichtigste ist aber, dass ich den Shop meinem Layout anpassen, bzw. darin integrieren kann.
Das aktuelle Layout ist css-basiert und schaut so aus:
http://http://www.per-net.ch/garage/weber/angebot/index.html
Kennt jemand ne gute Lösung, die ich für mein Projekt anpassen kann?
Besten Dank für Eure Tipps.
Pierre
Hello Pierre,
da bisher keine andere Antwort kommt und Du eigentlich auch schon ganz gute Ansätze gezeigt hast, lass uns doch so ein Ding hier mal planen und dann nach und nach auch programmieren. Dutzende von Folgegenarationen an Forumsbesuchern werden es uns danken...
Also, wie fangen wir an?
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
Hallo Pierre,
da bisher keine andere Antwort kommt und Du eigentlich auch schon ganz gute Ansätze gezeigt hast, lass uns doch so ein Ding hier mal planen und dann nach und nach auch programmieren. Dutzende von Folgegenarationen an Forumsbesuchern werden es uns danken...
Also, wie fangen wir an?
Wir fangen mit einer Vorüberlegung an, um uns einen groben Überblick zu verschaffen:
Was ist ein Online-shop (O-Shop)?
Ein O-Shop ist ein Web mit fast ausschließlich kommerziell Charakter.
Ein solches Web muß der breitestmöglichen Masse an Browsern / Clients
gerecht werden, um breitestmöglichen Anklang zu finden.
Anforderungen an Techniken
Die daraus erwachsenden Anforderungen an die einzusentzenden
Techniken sind eheblich und tragen maßgeblich zum Erfolg des
Webs bei.
- Einsatz von HTML nach Standard des W3C
- Einsatz von CSS nach Standard des W3C
- Bezugnahme auf Fehler verschiedener Browser
(vgl.: CSS hack, Boxmodel, Bug)
- Einsatz von PHP als serverseitige Technik
Anforderungen an die Gestaltung
Die Gestaltung ist der bedeutenste Teil des O-Shops. Er ist das
Interface über dem alle Transaktionen im Hinblick auf das Zusammen-
spiel von Client <-> Server, aber auch Kunde <-> Verkäufer ablaufen.
Je einfacher und intuitiver es gestaltet ist, desto weniger Mühe
wird ein User beim aufsuchen von Produkten im O-Shop haben und desto
eher wird er kaufen.
Bei der Umsetzung eines Layouts sind die eigenen Erfahrungen mit Web
erheblich. Daher ist es nicht schlecht google mit allen Suchbegriffen
der Form AAlräucherein bis Zylinderstifte zu durchsuchen, um diese
Erfahrungen nochmals aufzufrischen.
Präsentation der Produkte
Alle Produkte sind den User so zu präsentieren, daß er einen grobum-
fassenden Eindruck des Produktes erhält. Dieser Eindruck darf für den
durchschnittsgebildeten User keine Fragen offenlassen und klärt ihn
gleichfalls über alle gesetzlich vorgeschriebenen Angaben auf.
Darüber hinaus werden dem User bei Interesse detailreichere Einblik-
ke in Wort und Bild gewährt.
Diese Möglichkeit der Darbietung hält sich an "Weniger ist mehr",
der User hat also auf den ersten Blick nur die Informationen, die er
braucht und wird nicht mit Details erschlagen; daraus erwechst
gleichfalls der Vorteil, das man nur die Informationen serviert, die
die wirklich benötigt werden (Traffic).
Rechtlicher Aspekt
vgl.: Impressum, Fernabsatzgesetz, Rech O-Shop
Ab hier finge dann alles programmiertechnische an. Ich bitte um Korrektur und Ergenzung. Einen Punkt der Kosten- und Zeitminimierung gäbe es da noch: Man gehe zu den großen Hostern und bediene sich einer ihrer Fertigsysteme im bereich von 9.99 bis 49.95 monatilich.
Gruß aus Berlin!
eddi
Hello eddi,
wollte hier nur vermelden, dass ich es gesehen habe und mir morgen mal reinziehen werde. Heute habe ich keine Lust mehr auf qualitative Arbeit ;-))
Ich sauf jetzt einen und schwanzel noch ein Wenig durchs Web.
Nebenbei muss ich noch einen Briefentwurf fertig stellen; das ist Quality genug für heute.
Sollte ich's verpennen, tritt mich nochmal (per mail).
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
Hello,
Ich sauf jetzt einen und schwanzel noch ein Wenig durchs Web.
*schluck* das sollte "schawenzel" heißen, was soviel wie "Surfen" bedeutet
Es ist ja schließlich noch vor 22:00
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
Hello,
Noch ein wesentliches Anliegen ist mir die die strikte Trennung von Berechnungsmodulen und Ausgabeinheit. Es wird also keine Scripte mit Spaghetticode geben dürfen, in dem Ausgaben und Berechnungen gemischt werden.
Es gibt im wesentlichen die Funktionbereiche in der Section "Main":
Einen wichtigen Punkt sollten wir noch klären:
Da es ein "einfacher" Shop werden soll, müssen wir vielleicht eine koplexe Arbeit abliefern und das Ding nicht auf einem DBMS aufsetzen, sondern auf einem Flatfile-System.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
Moin,
Noch ein wesentliches Anliegen ist mir die die strikte Trennung von Berechnungsmodulen und Ausgabeinheit. Es wird also keine Scripte mit Spaghetticode geben dürfen, in dem Ausgaben und Berechnungen gemischt werden.
*lach* hab mal keine Sorge ;)
Es gibt im wesentlichen die Funktionbereiche in der Section "Main":
- Benutzeridentifikation
- "normale" Anzeigeberechnung
- Dialogberechnung
- Funktionalitätsberechnung (Buttons)
HTML-Ausgabe
- Anzeige-Template
Gerne auch OOP :)
Einen wichtigen Punkt sollten wir noch klären:
Da es ein "einfacher" Shop werden soll, müssen wir vielleicht eine koplexe Arbeit abliefern und das Ding nicht auf einem DBMS aufsetzen, sondern auf einem Flatfile-System.
Ich denke wir wissen, wie "einfach" ein Shop ist; ob es Flatfiles (an sich) Sein müssen, weiß ich nicht, vielleicht sollten wir uns auch mal an XML orientieren. Also geklärt.
Was würdes Du unter https://forum.selfhtml.org/?t=100415&m=616080 für PHP (-Module) benötigen? Welche Module Apaches sind Dir zu viel / würdest Du zusätzlich nehmen?
Gruß aus Berlin!
eddi
Hallo Pierre,
Ergänzung:
Desweiteren ist SSL für eine Verschlüsselte Übertragung von sensiblen Daten nötig.
Gruß aus Berlin!
eddi
Hallo Pierre,
also fangen wir mal an den technischen Teil dieses Projekts (Arbeitsname: Self-O-Shop) zu definieren und zu unterteilen. Setzen wir uns mal als Grundlage einen eigens für den O-Shop angemieteten (V)Server, dessen einziger Zweck es ist, ein einziges (, natürlich überaus vielbesuchtes) Web zu beherbergen.
Wir wollen einen Online-Shop (O-Shop) erstellen, der Produkte an Interessenten offeriert, eine einfache Produktverwaltung ermöglicht und eine Bestellabwicklung ermöglicht; und alles auf der Basis von PHP. Da PHP alleine diese Aufgaben schwerlich beweltigen kann, werden wir auch einen Web-Server benötigen. Dieser wird auf den allermeisten Maschinen, die als VServer / (Root)Server neben Mail-Server und SSHD bereits vorinstalliert und aller Vernunft nach mit einem GNU/Linux interagieren. Wie bereits in den Vorüberlegungen (& ff.) dargelegt, werden wir hier so einige Register ziehen, die das Forum an Kategorien zu bieten hat.
Damit nicht in einem heillosem Durcheinander jedes Thema in einem Arm des Thread besprochen wird, halte ich es für sinnvoll eine Vorabtrennung folgender Themen vorzunehmen:
Web-SERVER (apache)
PHP
HTML/XHTML
CSS
JavaScript
RECHT
(Ich beginne mal den Server etwas zu beleuchten ;)
Gruß aus Berlin!
eddi
Hallo Pierre,
nehmen wir mal den weitverbreitesten Web-Server, den apachen, zur Basis unseres O-Shops. Günstig ist es immer den Server so schmal wie möglich zu halten und nach Möglichkeiten auch selbst zu kompilieren. Warum steht hier.
Den apachen gibt es derzeit in zwei grundlegenden Versionen: 2.0.52 und 1.3.33. Der wesentliche Unterschied zwischen den beiden besteht in der frei wählbaren Handhabungen von Threads vs. Kindprozessen in der Version 2.x zu einem Prefroken in Prozessen in Version 1.x.
Da wir ja einen überaus populären O-Shop mit genialen Produkten haben werden, werden wir PHP als Modul einbinden. In der Ausgabe von ./configue --help der PHP-Sourcen heißt es dazu:
--with-apxs2[=FILE] EXPERIMENTAL: Build shared Apache 2.0 module. FILE is the optional pathname to the Apache apxs tool; defaults to apxs.
Persönlich arbeite ich seit einem halben Jahr mit PHP 5.0.x und apache 2.0.x und konnte noch keine Probleme feststellen. Aber solang es noch als experimentell bezeichnet wird, sollten wir lieber die Hände davon lassen. Daher gehe ich mal vom apachen 1.3.x aus.
Der apache bringt insgesamt 43 Module mit, die wir nie im Leben brauchen werden. Ein Modul brauchen wir neben PHP noch zusätzlich mod_ssl. Aber schauen wir uns mal an, welche module der apache ohne weitere Angaben mitbringt:
http_core.c
mod_env.c
mod_log_config.c
mod_mime.c
mod_negotiation.c
mod_status.c
mod_include.c
mod_autoindex.c
mod_dir.c
mod_cgi.c
mod_asis.c
mod_imap.c
mod_actions.c
mod_userdir.c
mod_alias.c
mod_access.c
mod_auth.c
mod_setenvif.c
Neben PHP halte ich folgende Module für ausreichend:
http_core.c
Um core kommen wir nun mal nicht herum ;)
mod_access.c
Man sollte sich die Möglichkeit offen lassen IP-Adressen
auszusperren, wenn von ihnen Gefahren (DoS) ausgehen.
mod_auth.c
Ein Web, insbesondere ein O-Shop ist immer eine Baustell,
die natürlich auch abgesperrt werden will ;)
mod_dir.c
Da wir mit PHP arbeiten, wollen wir natürlich auch Da-
tein, wie "index.php" als Verzeichnis haben.
mod_expires.c
Dieses Modul werden wir einsetzen, um statische Inhalte
nur einmalig servieren zu müssen.
mod_headers.c
Dieses Modul werden wir einsetzen, um statische Inhalte
nur einmalig servieren zu müssen.
mod_log_config.c
(Nicht wirklich benötigt, aber interessant ;)
mod_mime.c
Wird benötigt für Content Negatiation.
mod_negotiation.c
Das macht den Inhalt felxibler nach den Browsereinstel-
lungen des Accept.
mod_rewrite.c
Dieses Modul bevorzuge ich gegenüber mod_alias.
mod_so.c
Versorgt den Server mit der Fähigkeit Module zu akzep-
tieren. (Genaugenommen aber auch entbehrlich.)
mod_ssl.c
Sorgt für Verschlüsselung sensibler Daten.
Ob man diese Statisch einkompiliert oder nicht, ist Geschmackssache, persönlich baue ich essentielle Module immer statisch ein.
Gruß aus Berlin!
eddi
Hallo Pierre,
laut dem Konfigurationsvorschlag in der Datei "httpd.conf.default", die sich im Verzeichnis "conf" des kompilierten apachen standardisiert befindet, wird für den lieben IE natürlich wieder eine Extrawurst von Nöten sein. Der Server mekerte mich gerade an:
$ ./httpd -f /self-o-shop/conf/httpd.conf.default -D SSL
Syntax error on line 1186 of /sv/self-o-shop/conf/httpd.conf.default:
Invalid command 'SetEnvIf', perhaps mis-spelled or defined by a module not included in the server configuration
In Zeile 1186 heist es dazu:
SetEnvIf User-Agent ".*MSIE.*" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0
Gibt es andere Möglichkeiten mit den bestehenden Modulen auszukommen?
Es bleibt uns vorerst einmal nichts anderes übrig, als unseren Indianer noch ein Modul unter den Arm zu klemmen, sodaß ich ihn wie folgt kompiliert habe:
$ ./configure \ --prefix=/self-o-shop \ --disable-module=actions \ --disable-module=alias \ --disable-module=asis \ --disable-module=autoindex \ --disable-module=cgi \ --disable-module=env \ --disable-module=imap \ --disable-module=include \ --disable-module=status \ --disable-module=userdir \ --enable-module=expires \ --enable-module=headers \ --enable-module=rewrite \ --enable-module=so \ --enable-module=ssl
$ make
$ make certificate TYPE=...
$ make install
(Zu Fragen zum installieren von mod_ssl ist die Datei "INSTALL" als Beschreibung ausreichend.)
Nun schwirrt der httpd ohne Murren ab und liefert das Manual (wahlweise auch verschlüsselt mit einem selbstsigniertem Zertifikat). Somit kann man sich nun PHP zuwenden.
Gruß aus Berlin!
eddi
Bei den Konfigurationen beschränke ich mich auf die wesentlichen Teile, die nur das Projekt PHP-O-Shop direkt betreffen
LoadModule php5_module libexec/libphp5.so
DirectoryIndex index
<Files ~ "^.ht">
Order allow,deny
Deny from all
Satisfy All
</Files>
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory "/self-o-shop/htdocs">
AllowOverride All
Options All +MultiViews
Order allow,deny
Allow from all
RewriteEngine on
RewriteRule shop$ http://%{HTTP_HOST}/shop/ [R]
<Files "shop">
ForceType application/x-httpd-php
</Files>
</Directory>
<Directory "/self-o-shop/admin">
AllowOverride All
DirectoryIndex index.php
Options All
php_value post_max_size 1M
php_value upload_max_filesize 1M
</Directory>
php_flag allow_call_time_pass_reference 0
php_flag magic_quotes_gpc 0
php_flag register_argc_argv 0
php_flag register_long_arrays 0
php_value arg_separator.input "&"
php_value default_charset "iso-8859-1"
php_value include_path ".:/self-o-shop/php/include"
php_value post_max_size 102400
php_value upload_max_filesize 10
php_value user_agent "Self-O-Shop"
php_value variables_order "GPC"
NameVirtualHost 192.168.0.9
<VirtualHost self-o-shop>
DocumentRoot /self-o-shop/htdocs
<Directory "/self-o-shop/htdocs/img">
ExpiresActive On
ExpiresDefault A2419200
Header append Cache-Control "public"
</Directory>
<Directory "/self-o-shop/htdocs/add">
ExpiresActive On
ExpiresDefault A2419200
Header append Cache-Control "public"
</Directory>
</VirtualHost>
<VirtualHost admin>
DocumentRoot /self-o-shop/admin
</VirtualHost>
Des weiteren kehre ich mit dem eisernen Besen durch die mime.types und entferne alles, was nicht hundertprozentig gebraucht wird. Dmit ich PHP-Unteerstüzung erhalte, trage ich noch folgendes ein:
application/x-httpd-php php
Gruß aus Berlin!
eddi
Prompt was vergessen:
[...]
PHP
[...]
php_flag zlib.output_compression 1
php_value zlib.output_compression_level 9
Gruß aus Berlin!
eddi
Hallo Pierre,
da der O-Shop als serverseitige Technik PHP verwenden soll, liegt hierauf natürlich der besondere Augenmerk. PHP bringt in der Version 5.0.3 von Hause aus satte 80 Erweiterungen mit. Man könnte spötteln, daß es für so ziemlich jede jemanls erdacht Datenbank auch eigens dafür eine Erweiterung mitbringt. Aber da es ein einfacher O-Shop sein soll werden wir darauf verzichten müssen.
PHP bringt ohne weitere Auswahl folgende Erweiterungen gleich mit:
ctype
DOM
iconv
libXML
PCNTL
POSIX
Session
SimpleXML
SPL
SQLite
Tokenizer
XML
Das Modul libphp5.so des apachen erreicht in dieser Grundeinstellung und mit den Standardeinstellung "CFLAGS_CLEAN = -g -O2" für den Compiler satte 9,5 MB. Persönlich setze ich auf diesem Rechner (von dem ich gerade schreibe), der auch mein vorwiegender Arbeitsplatz ist, meine eingenen Flags
$ CFLAGS="-O3 -march=athlon -fomit-frame-pointer" make
Ohne an den Erweiterungen herumgebastelt zu haben, ist das PHP-Modul auf 2,3 MB zusammengeschrumpft. Näheres zu diesem kleinen Nettigkeiten findet sich für gewöhnlich unter http://gcc.gnu.org/; leider beobachte ich seit einigen Tagen, das der Server nicht mehr zu erreichen ist :( also müssen wir uns mit "man gcc" bescheiden.
Aber zurück zu den Erweiterungen: Auch wenn es naheliegend klingt Sessions zu verwenden, würde ich auf alle(!) Erweiterungen verzichten wollen. Aber hierbei ist sehr wichtig zu wissen, was man alles mit PHP machen möchte und wie man was machen möchte. Die meisten werden zu den bereist erwähnten passenden Datenbankerweiterungen greifen wollen. Manche, werden vielleicht mit XML als Datenspeicher arbeiten wollen. Wieder andere werden PHP nicht nur als Modul des apachen nutzen wollen, sondern auch als Command Line Interface und völlig andere Erweiterungen benötigen.
Selbst setze ich auf die Fähigkeit der Modularisierung PHPs, um nur das zu laden, was man wirklich gebraucht wird. Da wir einen O-Shop haben wollen, der mit der imensen Nachfrage nach den genialen Produkten, auf die die Welt nur gewartete hat, zurecht kommen muß, halte ich zur Sicherung der Bandbreite zlib für unumgänglich.
Sollten weitere Erweiterungen benötigt werden, bitte ich kurz um Einspruch.
Gruß aus Berlin!
eddi
Hallo Pierre,
$ CFLAGS="-O3 -march=athlon -fomit-frame-pointer" make
Korrektur:
$ CFLAGS="-O3 -march=athlon -fomit-frame-pointer" ./configure
Sollten weitere Erweiterungen benötigt werden, bitte ich kurz um Einspruch.
Keine? Gut (Notfalls lassen diese sich nachträglich als Modul noch einbinden).
CFLAGS="-O3 -march=athlon -fomit-frame-pointer" ./configure --prefix=/self-o-shop/php --with-zlib --with-apxs=/self-o-shop/bin/apxs --disable-all --disable-cli --disable-cgi
$ make
$ make install
somit hat der apache ein 1,4 MB großes Modul, mit dem er nun arbeiten soll. Als nächstes sollte bedacht werden, wie das Projekt in Verzeichnisse angelegt wird.
Gruß aus Berlin!
eddi
Hallo Pierre,
nun läuft der apache mit PHP.
Verschiedene Aufgaben des Server verlangen verschiedene Konfigurationen, so nimmt der ständige Bezug von notwendigen Bildern der einzelnen Produkte über die Browser dem O-Shop die Bandbreite. Sie sind statisch und unterliegen, einmal serviert, keiner Änderung seites des Betreibers. Mit PHP generierte Dokumente dagegen werden sich jedes mal verändern.
Für unser Web wurde bereis per Configure Command das oberste Verzeichnis "self-o-shop" angelegt und ich würde nun wie folgt
/self-o-shop
|
|-[... andere Verzeichnisse ...]
|
|-admin 1. Administrationsweb
|
|-php
| |
| -include 2. Includeverzeichnis | | |
-templ 3. Verzeichnis für HTML-Schablonen
|
|-waren 4. Datenverzeichnis der Waren
|
-htdocs | |-add 5. Verzeichnis für additionelles | |-bestellung 6. (Selbstredend) | |-img 7. Bilderverzeichnis | |-info 8. Verzeichnis für statisches | |-index.html [Datei] | |-robots.txt [Datei] |
-shop [Datei]
1. Administration
Von hier aus wird der O-Shop administriert. Scripte zur einpflege
von Produktdaten, statistischer Auswertungen und Bestellungsver-
waltung werden von diesem Web gesteuert.
2. Include verzeichnis
Hier werden alle Klassen und Funktionen eingelagert, die von PHP
dynamisch hinzugeladen werden. Somit werden sie auserhalb des Webs
gehalten, was für die Sicherheit wichtig ist; insbesondere beim
Arbeiten mit Passwörtern.
3. Templates
Aus diesem Verzeichnis bezieht PHP seine HTML-Konstrukte zur Gene-
rierung von Dokumenten.
4. Datenverzeichnis der Waren
Dieses Verzeichnis wird das Herzstück werden. Alle Informationen
über Produkte werden in dieses Verzeichnis eingelagert werden.
5. Verzeichnis für additionelles
Separate JavaScripte und Stylesheets und Layoutbilder werden hier
bereit gehalten.
6. Bestellung
Scripte zur Bestellabwicklung aber auch den Warenkob und das Er-
fassen der User betreffend finden hier platz.
7. Bilder
Aus diesem Verzeichnis werden die Produktbilder serviert.
8. Statisches
Dokumente wie "Wir über uns", "AGB" oder "Impressum", die keiner-
lei Dynamik benötigen, werden hier eingelagert.
Damit können wir nun den Server konfigurieren.
Gruß aus Berlin!
eddi
Hallo Pierre,
sammeln wir doch einmal, was wir alles brauchen und im include_path ablegen:
E-Mail-Adresserkennung
########## email_pruef.inc #################################
function email_pruef($a)
{
Zerlegen der Adresse in USER @ HOST als Kleinschreibung
$a=explode('@',strtolower($a));
gibt es genau ein Zeichen @
if(count($a)==2)
{
# Zerlegen des HOST in Subdomains und Anhaengen des USER $a[0]
$b=explode('.',$a[1]);
# HOST hat [SUB.]DOMAI.TLD
if(($c=count($b))>1)
{
$b[]=$a[0];
$c++;
# Durchlaufen und abpruefen aller Zeichen
for($i=0;$i<$c;$i++)
{
# auf Zeichenkettenlaenge pruefen
$a=strlen($b[$i]);
# Zeichenkette ist mindestens 2 Zeichen lang und wird durchlaufen
if($a>1)
for($j=0;$j<$a;$j++)
{
# Speichern des ASCII-Wert des Zeichens $b[$i]{$j}
$d=ord($b[$i]{$j});
# [0-9a-z]
if(($d>47 && $d<58) || ($d>97 && $d<123));
# Zeichen ist das erste Zeichen von $b[$i]
elseif($j==0) return FALSE;
# +[ -_ ]
elseif($d==45 || $d==95);
# Zeichenkette ist USER +[ . ]
elseif($i==(count($b)-1) && $d==46);
else return FALSE;
}
else return FALSE;
}
}
else return FALSE;
}
else return FALSE;
return TRUE;
}
Gruß aus Berlin!
eddi