Telefon als Pflichtfeld in Magento – the ultimate solution

Es sind die kleinen Dinge, die nerven. Und davon hat Magento reichlich.

Man sollte meinen, dass es bei einem derart hochgezüchteten Shopsystem mit einem Klick getan ist, ein Feld im Checkout nicht zum Pflichtfeld zu machen. Im konkreten Fall die Telefonnummer, die aus unerfindlichen Gründen in so ziemlich jedem Shopsystem ein Pflichtfeld ist.

Der erste Blogpost dazu gibt Hoffnung. Aber so einfach ist es nicht. Also halt so gar nicht. Diese Änderung in der Datenbank ist mehr oder weniger nutzlos.
In den Templates wird nämlich gar nicht erst darauf geprüft, welches Feld ein Pflichtfeld ist. Man muss also an allen möglichen Stellen händisch alles entfernen, was auf ein Pflichtfeld hindeutet. Und neben den hier genannten Templatedateien kommt, zumindest in 1.6, auch noch /template/persistent/checkout/onepage/billing.phtml dazu.
Außerdem muss man noch die Mage_Customer_Model_Address_Abstract anpassen, auch hier folgt man am besten der Anleitung hier.

Fertig. Fertig!? Guter Witz, Rechnung ohne Magento gemacht!
Wenn man sich auf der Suche nach dem Fehler weiter durch den Magento-Core hackt trifft man früher oder später auf /app/code/core/Mage/Eav/Model/Attribute/Data/Text.php. Und hier liefert $attribute->getIsRequired() weiterhin treudoof true zurück, als ob man die Datenbankänderung nie gemacht hätte. Ein Blick in selbige führt aber zu der Erkenntnis, dass dort alles stimmt. Alle Caches leeren bringt exakt gar nichts. Erst das ausführen des folgenden Codeschnipsels:

$telephone = Mage::getModel('eav/entity_attribute')
           ->loadByCode('customer_address', 'telephone')
           ->setIsRequired(false)
           ->save();

überzeugt Magento endlich davon, dass die Telefonnummer im Checkout kein Pflichtfeld mehr ist. Herzlicher Dank auch an die Magento-Entwickler, man verbrät doch immer mal wieder gern ne Stunde für so einen Scheiß!

Kostenlose Payment-Icons für den europäischen Markt

Wir haben den Checkout-Prozess in unseren Shops überarbeitet und dazu auch neue Icons für die einzelnen Zahlungsarten entworfen. Diese sind stark abgestimmt auf den deutschen und europäischen Markt und die hier gebräuchlichen Zahlarten. Da ich der Meinung bin, dass diese auch für andere Shopbetreiber nützlich sein könnten biete ich hier das komplette Set zum Download an.

Update v16

Diesen Monat feiert mein kleines Iconset tatsächlich schon seinen fünften Geburtstag. Statt Torte gibt es drei neue Icons, heißt doch Amazon payments neuerdings Amazon pay und ein paar Sachen von der Wunschliste habe ich dann auch gleich noch mit abgearbeitet.
Kostenlose PNG-Icons für Kreditkarten und Zahlarten (v16) (zip, 12,1MB)

Enthaltene Icons:
Amazon pay
Stripe
Ratenkauf

Update v15

Da ist mir doch tatsächlich das neue MasterCard-Logo durchgerutscht. Das betrifft gleichzeitig auch Maestro und Cirrus und eigentlich auch MasterPass. Für letzteren ist aber außer einem bemitleidenswerten Bildchen, das MasterCard höchstpersönlich auf flickr veröffentlicht hat, kein brauchbares Grundmaterial zu finden und so ist erstmal bis auf weiteres das alte MasterPass-Icon enthalten.

Aufgefallen ist mir das neue MasterCard-Logo durch ein Schreiben unseres Aquirers. Denn VISA und MasterCard tun jetzt endlich was gegen den Kreditkartenmissbrauch. Auf der letzten Checkout-Seite muss jetzt das Herkunftsland, die Anschrift und die Telefonnummer des Händlers stehen. Endlich mal eine wirksame Maßnahme. Nicht.

Enthaltene Icons:
MasterCard
Maestro
Cirrus

Update v14

Es hatte sich so einiges angesammelt im E-Mail-Postfach und in den Kommentaren. Und daher kommen hier gleich 33 neue Icons. Oft geäußerte Wünsche sind ebenso dabei wie eher selteneres. Zu ersterem zählt sicherlich das Icon für paydirekt und die beiden PayPal-Icons für PayPal Express und PayPal Plus. Beides sind reine Fantasieprodukte, da PayPal keinen Bedarf dafür sieht. Die Shopbetreiber aber sehr wohl.

Unterstützung kam unter anderem wieder von José, der mich darauf aufmerksam machte, dass VISA ein neues Logo hat. Jetzt ist es ja so, dass sich das neue, das nur noch den blauen VISA-Schriftzug mit der gelben Ecke im V hat, irgendwie flächendeckend durchgesetzt hat. Da ist es natürlich ne völlig geniale Idee erneut ein geändertes Logo einzuführen. Die gelbe Ecke fällt weg, dafür hat der Schriftzug jetzt einen Farbverlauf. Und wenn das noch nicht genug Verwirrung wäre sieht das neue VISA-Electron-Logo dem ganz alten VISA-Logo deutlich ähnlicher als dem neuen. Daher gibt es im Set auch ein alternatives Electron-Logo, das besser in die neue Bildsprache passt. Und auch eine Variante ohne Farbverlauf, für alle, denen Farbverläuf zu 90er sind.

Apropos neues Logo: Die UPS-Nachnahme zeigt jetzt das neue, flache UPS-Logo und apropos Nachname: Christin hat mich darauf hingewiesen, dass es ja gar kein Icon für Deutsche Post Nachnahme gibt. Das ist hier auch enthalten.

Und dann haben wir noch fünf neue Texticons, einfach schwarze Schrift mittig.

Enthaltene Icons:
Nachnahme UPS
Nachnahme UPS (alternativ)
PayPal Express
PayPal PLUS
Bancontact
Bancontact/Mister Cash
Belfius
Mollie
Bankomat
Sodexo
Accor Services
Unionpay
Unionpay (alternativ)
VISA
VISA (alternativ)
V-Pay
Visa Electron
VISA Electron (alternativ)
Billpay (alternativ)
Swisscom Easypay
Swisscom Natel® Pay
Swisscom Natel® Pay (alternativ)
Nachnahme Post Deutschland
Nachname Post Deutschland (alternativ)
Nachnahme Post Schweiz
Nachnahme Post Schweiz (alternativ)
Nachname Post Österreich (alternativ)
Texticon schwarz „Überweisung“
Texticon schwarz „Rechnung“
Texticon schwarz „Lastschrift“
Texticon schwarz „Nachnahme“

Update v13

Ich hab mich dann mal nochmal mit dem Thema Rechnungs-Icon auseinandergesetzt und bin dabei etwas über das Ziel hinausgeschossen. Das Update enthält neben den von Alex beigesteuerten Text-Icons für „Rechnung“ und „auf Rechnung“ ein alternatives Mastercard-Icon, ein optimiertes PostPay-Icon und, ähm, 136 weitere Icons für Rechnung.

Obwohl ich kein Freund von Skeuomorphismus bin habe ich doch mal ein Rechnungskuvert auf’s Icon gebaut. Das ganze gibt es mit und ohne Banner „Rechnung inliegend“, mit deutscher, österreichischer und schweizer Briefmarke, einer weiteren Edition mit der deutschen Briefmarke zur Fußball-Weltmeisterschaft inkl. Sonderstempel und mit passenden Anschriften auf den Kuverts. Und da hat es dann angefangen, das hinausschießen über das Ziel. Es gibt für jedes Land sowohl eine weibliche als auch eine männliche Empfängeranschrift und in Deutschland gibt es das auch noch für jedes Bundesland. Macht am Ende 136 Icons. Und wenn dann doch nicht das passende dabei sein sollte – das PSD enthält jetzt auch dieses Rechnungsicon.
Ob das aber so bleibt weiß ich noch nicht, die Datei ist dadurch immerhin auf 11,2MB angewachsen.

Für die Schweiz außerdem noch dabei: Ein Icon für Twint, das Marco beigesteuert hat. Allen Zulieferern an dieser Stelle vielen Dank.

Enthaltene Icons:
Rechnung (136 Varianten)
Texticon „Rechnung“
Texticon „auf Rechnung“
Mastercard (alternativ)
PostPay
TWINT

Update v12

Da ich heute eine Stunde mehr Zeit hatte habe ich mal die offenen Requests soweit abgearbeitet. Herausgekommen sind zwei Versionen für yapital und zwei für micropayment.

Enthaltene Icons:
micropayment
micropayment (alternativ)
yapital
yapital (alternativ)

Update v11

Kleiner Rundumschlag zu Ostern: Barzahlen in zwei Varianten, ServiRed in zwei Varianten, MasterPay in zwei Varianten (Danke an José für den Hinweis und das eine davon), ebenfalls von José das neue Diners-Club-Logo und das neue dpd-Logo mit Nachnahme-Ecke in zwei Varianten.

Enthaltene Icons:
Diners Club
Nachnahme DPD
Nachnahme DPD (alternativ)
ServiRed
ServiRed (alternativ)
Barzahlen
Barzahlen (alternativ)
Masterpass
Masterpass (alternativ)

Update v10

PayPal hat ein neues Logo. Neue Schriftart, leicht geänderte Farben und ineinanderfließende P’s.

Enthaltene Icons:
PayPal
PayPal (alternativ)
PayPal (alternativ 2)

Update v9

Ein kleines Update mit allem, was sich hier so in den letzten Monaten an Wünschen und Anregungen angesammelt hat:
Von José habe ich wieder einige Icons für Zahlungsarten aus den Nachbarländern erhalten: iDeal (Niederlande), Carte Blanche (Frankreich), Manor MyOne (Schweiz) und Paysafecard (ebenfalls Schweiz inkl. einer Variante von mir). Darüber hinaus wurden Wünsche laut nach Bitcoin (drei Varianten), Nachnahme durch die österreichische Post und Barzahlung bei Abholung, die sich auch alle in diesem Update wiederfinden. Das letztgenannte Icon ist auch in der PSD enthalten, damit man es sich nach eigenen Wünschen umfärben kann.

Enthaltene Icons:
Paysafecard
Paysafecard (alternativ)
Nachnahme Post Österreich
Bitcoin
Bitcoin (alternativ)
Bitcoin (alternativ 2)
Carte Blanche
Barzahlung bei Abholung
Manor MyOne

Update v8

2014 wirft seine Schatten voraus und mit ihm SEPA, die Single Euro Payments Area. Aus diesem Grund gibt es hier kurz vor dem Jahreswechsel ein passendes SPEA-Logo.

Enthaltenes Icon:
SEPA

Update v7

Von José habe ich ein PostFinance-Icon bekommen. Dazu habe ich noch zwei alternativen erstellt und außerdem gibt’s noch das schon länger gewünschte VR-Pay-Icon.

Enthaltene Icons:
PostFinance
PostFinance (alternativ)
PostFinance (alternativ 2)
VR-Pay

Update v6

Großes Kino von Sofortüberweisung. Es scheint echt zu viel verlangt zu sein, vorher zu prüfen, ob das neue Logo irgendwelche bestehenden Copyrights verletzt. Deshalb gibt es schon wieder ein neues. Einmal, nur einmal mit Profis arbeiten…

Enthaltenes Icon:
Sofortüberweisung

Update v5

Klarna hat ebenfalls sein Logo überarbeitet.

Enthaltene Icons:
Klarna
Klarna (alternativ)
Klarna (Rechnung)
Klarna (Ratenkauf)

Update v4

Sofortüberweisung hat ein neues Logo, das ab sofort im Icon-Set enthalten ist.

Enthaltenes Icon:
Sofortüberweisung

Update v3


Ich hab mal die Vorschläge aus den Kommentaren aufgegriffen und das Set etwas ergänzt.

Enthaltene Icons:
UPS Nachnahme
UPS Nachnahme (alternativ)
amazon payments

Außerdem gibt es jetzt ein neues Set mit Logistikdienstleistern.

Update v2

Kaum einen Tag alt gibt es schon das erste Update, in diesem sind enthalten:

Enthaltene Icons:
Billpay
Billsafe
klarna
paymorrow
Nachnahme GLS
Nachnahme GLS (alternativ)
Nachnahme Hermes (siehe auch den Kommentar von Martin)
sage pay
Skrill

Außerdem enthält die Datei jetzt generische Icons mit Text für Überweisung, Vorkasseskonto oder beliebige andere Zahlungsarten. Da nicht jeder was mit Kuckucksuhren-Grün oder rein deutschsprachigen Icons anfangen kann ist im Zip eine PSD-Datei, mit deren Hilfe man sich die benötigten Icons schnell selber machen kann. Als Schrift kommt Aller bzw. Aller Display zum Einsatz. Wer mehr zu dieser Schrift wissen will wird bei Gerrit fündig.

Release

Format:
PNG, 512px
Enthaltene Icons:
American Express
CartaSI
Carte Bleue
Carte Bleue (altes Logo)
Cirrus
clickandbuy
Diners Club
Direct Debit
Discover
EC
eps netpay
girocard
giropay
JCB
Maestro
Mastercard
Moneybookers
Nachnahme DHL
Nachnahme DPD
Paypal
postepay
sofortüberweisung.de
Solo
Switch
Überweisung
V Pay
VISA Electron
VISA
Western Union
wirecard

Weiterentwicklung

Ich glaube, dass diese Icons für viele Shopbetreiber hilfreich sind. Mir ist aber auch klar, dass es zahlreiche Zahlungsarten gibt, die noch nicht berücksichtigt sind. Gerne füge ich weitere Logos hinzu. Dazu einfach einen Kommentar hinterlassen oder mich über das Kontaktformular kontaktieren.

Lizenz

Die Icons sind kostenlos für private und kommerzielle Nutzung und stehen unter der CC BY Lizenz.
Das Copyright der einzelnen Logos liegt bei den jeweiligen Gesellschaften.

Download

Kostenlose PNG-Icons für Kreditkarten und Zahlarten (v16) (zip, 12,1MB)

Baseball-Bundesliga.de

Es war ruhig hier die letzten Wochen. Die Baseballsaison 2012 wirft ihren Schatten voraus und in ihrem Windschatten kommt eine neue Website mit. Und diese Website war in den letzten Wochen mein liebstes Betätigungsfeld. Meistens jedenfalls.

Grundlage

Die Seite basiert auf WordPress. Was anderes darf man von mir derzeit auch nicht wirklich erwarten. Aufgrund des strammen Zeitplans (ein Monat, ein Entwickler, der zu allem Überfluss auch noch einem Beruf nachgeht) wurde ein fertiges Template als Grundlage herangezogen, das durch den grandiosen Christian Swoboda für die eigentliche Aufgabenstellung umgestaltet wurde.

Ausschlaggebend für die Wahl des Mediaflux-Templates war nicht nur die grundsätzliche optische Ausrichtung, sondern auch die Tatsache, dass es mehr oder weniger moderne WordPress-Features wie Menüs von Haus aus unterstützt. Der Quelltext ist aber leider nicht besonders hübsch und vor allem das CSS ist dermaßen überspezifiziert, da kann man mitunter schon mal zu viel bekommen.

Besonderheiten

Es gibt für WordPress ja Plugins für jeden (un)möglichen Anwendungsfall. Es gibt aber nichts für eine Ligaverwaltung. Aus diesem Grund ist der komplette spielbetriebsrelevante Teil selbst geschrieben. Für Spielpläne und Tabellen werden Schnittstellen verwendet, die ich bereits vor einigen Jahren in die Spielbetriebssoftware des DBV integriert habe und die für die neue Website entsprechend erweitert wurden. Gleiches gilt für Daten, die aus der Spielerpasssoftware opaso kommen. Auch hier wurden die Schnittstellen zum Teil beträchtlich erweitert und stehen in Kürze vermutlich auch allen Landesverbänden zur Verfügung.

Zum ersten Mal in einem meiner Projekte kommt auf dieser Seite leaflet zum Einsatz, nicht nur optisch das bessere Google Maps.

Eine besondere Herausforderung war die Anbindung des Livescoring und der daraus resultierenden Statistiken, bietet doch GameChanger keine API an. Ein Teil der Daten steht zwar als JSON zur Verfügung, manchmal hilft dann aber nur ein beherzter Griff zu PHP Simple HTML DOM Parser, um an die gewünschten Informationen zu kommen.
Ob und wie performant diese Lösung ist wird sich am 30. April zeigen, wenn die Saison mit dem Nightgame Mainz Athletics gegen die Buchinder Legionäre beginnt. Und ich werde am Mikro sitzen, also macht’s nicht gleich kaputt.

Geschwindigkeit

Performance ist natürlich ein gutes Stichwort.
Neben Caching- und Expire-Einstellungen, die man im Detail in meiner Artikelserie „xtcModified on steroids nachlesen kann, ist hier die Plugin-Schatulle von WordPress reich gefüllt:
Als Cache-Plugin kommt, wegen guter Erfahrungen bei Mister Baseball, WP Super Cache zum Einsatz.
Um Minimierung und Verknüpfung von Javascript- und CSS-Dateien kümmert sich Better WordPress Minify, das überragende Konfigurationsmöglichkeiten bietet, mir deren Hilfe man einstellen kann, was wie und wo minimiert wird.
Diese Maßnahmen bringen die Seite auf respektable 92 von 100 möglichen Page-Speed-Punkten.
Darüber hinaus werden die Informationen, die aus den APIs bezogen werden, mit Hilfe der Transients API von WordPress gechached.

Und jetzt: Play Ball!

Startseite


Clubs


Clubinfo


Roster


Liveticker

Hinten anstellen – xtcModified on steroids

Man kennt das aus dem Supermarkt: An der Kasse mal eben vordrängeln, um dann den Betrieb komplett aufzuhalten, weil man 14,83 Euro passend abgezählt in aller Seelenruhe aus dem Geldbeutel kramt. Gerne noch gepaart mit: „Ich hou mei Brilln daham vergessn, guggn sa amol, sinn des fünf odder zwaa Zent?”. Gibt’s bei der Geschwindigkeitsoptimierung im Web auch. Heißt da aber nicht Oma Meier sondern Javascript.

Javascript später parsen

Parsen Sie Javascript später, um die Blockierung der Seitendarstellung zu reduzieren.

Weil Javascript Inhalt und DOM der Seite verändern kann warten die Browser, sobald sie auf einen Script-Tag stoßen, bis das Javascript geladen, geparsed und gerendert ist, bevor sie mit dem eigentlichen Rendering der Seite fortfahren. Durch das Mischen von Javascript- und CSS-Tags kann das Laden noch einmal zusätzlich verlangsamt werden, Page Speed listet das unter ‘Reihenfolge der Formate und Skripts optimieren’. Eine Grafik, wie diese Verzögerung eben durch das Stoppen des eigentlichen Rendervorgangs aussehen kann, findet sich bei Google.

Heute geht es also darum, die Reihenfolge von CSS und Javascript im Hinblick auf Ladezeiten zu optimieren. Dabei gilt die Faustregel, CSS gleich zu Beginn und Javascript ganz am Ende zu laden. Allerdings muss man beachten, dass es Fälle gibt, bei denen man von dieser Regel abweichen muss, weil man Javascript-Funktionen schon vorher benötigt. Hat man beispielsweise einen SSL-Proxy und muss Cross-Domain-Tracking mittels Google Analytics implementieren, benötigt man das Analytics-Javascript vorher und kann es eben nicht ganz ans Ende verfrachten.
Auch die eigentliche Reihenfolge der Scripte ist wichtig, erfordern manche Funktionen bestimmte Bibliotheken, z.B. jQuery, muss dieses natürlich vorher geladen werden. Und vertauscht man die Reihenfolge bei CSS-Dateien könnte es aufgrund der Kaskade zu unerwarteten Darstellungsfehlern kommen.

Im Sourcecode von xtcModified finden sich Hinweise, dass man dieses Thema auch schon mal angegangen ist, aufgrund von Fehlern bei jQuery wurde das aber wieder rückgängig gemacht. Aktuell konnten ich bei Tests im Demoshop keine derartigen Probleme feststellen. In xtcModified findet sich außerdem noch sehr viel Javascript-Code, der nicht über eine externe Datei geladen wird. Hier aufzuräumen und den Code, der zum Teil noch aus dem originalen xt:Commerce stammt, gegen moderne, auf jQuery basierende Funktionen zu tauschen, würde eine eigene Serie gut füllen.

Daher beschränke ich mich hier mal auf das naheliegendste: In includes/header.php alles von Zeile 75 bis Zeile 278 in die Zwischenablage kopieren und dann löschen, ebenso Zeile 279 löschen. In includes/application_bottom.php die Zeilen 42 bis 46 markieren:

//BOF - DokuMan - 2010-02-25 - Enhance page loading time by putting CSS on TOP of page and JavaScript on BOTTOM of page
//BOF - web28 - 2010-07-14 -  change to TOP of page again because jquery view problems
//require('templates/'.CURRENT_TEMPLATE.'/javascript/general.js.php');
//EOF - web28 - 2010-07-14 -  change to TOP of page again because jquery view problems
//EOF - DokuMan - 2010-02-25 - Enhance page loading time by putting CSS on TOP of page and JavaScript on BOTTOM of page

und durch

?>

ersetzen. Anschließend den Inhalt der Zwischenablage einfügen.

Betrachtet man die reinen Zahlen könnte man meinen, diese Änderung bringt uns primär ein gutes Gefühl.

YSlow mit Javascript am Seitenende

Page Speed mit Javascript am Seitenende

Der eigentliche Erfolg ist hier aber eher offensichtlich, wenn man sich das Rendering ansieht. Mit Javascript im oberen Bereich der Seite wird der Browser sehr früh blockiert und beginnt erst nach ca 2,5 Sekunden mit dem Rendern. Hingegen beginnt dieser Prozess nach der Änderung gut eine Sekunde früher.

Weitere Artikel der Serie

  1. Höher, schneller, weiter
  2. Verfallsdatum überschritten
  3. Druck machen – xtcModified on steroids

Disclaimer: Ich bin nach wie vor der Meinung, dass viele der Einstellungen in der Serverkonfiguration besser aufgehoben sind als in der .htaccess-Datei, da aber sicherlich viele das ganze auch auf Shared Hosting umsetzen möchten werden alle Änderungen, die auch über die .htaccess durchgeführt werden können, im Rahmen dieser Artikelreihe dort vorgenommen.

Druck machen – xtcModified on steroids

Diesmal wollen wir im Rahmen der Artikelserie zur Geschwindigkeitsoptimierung mal ein bisschen Druck ausüben, denn die Steigerung von 36 auf 60 Punkten ist bestenfalls ein Teilerfolg.

Komprimierung aktivieren

Die Komprimierung der folgenden Ressourcen mit gzip könnte ihre Übertragungsgröße um 90.0 KiB verringern (Reduzierung um 70%).

70% der zu übertragenden, komprimmierungsfähigen Daten könnte man sich also sparen, wenn man diese vor der Auslieferung zippt. Das Entpacken findet dann beim Empfänger durch den Browser transparent statt. Jeder moderne Browser kann damit umgehen. Will man es auf die Goldwaage legen könnte man argumentieren, dass der Browser durch den erforderlichen Entpackvorgang länger braucht, um die Seite zu rendern. Aber das Nadelöhr ist nach wie vor ganz klar die Bandbreite der Leitung zum Empfänger, während die Prozessoren in moderner (Desktop-)Hardware gerade mal müde lächeln, wenn sie komprimierte Daten vorgesetzt bekommen.
Für die meisten eher unbedeutend ist in Zeiten von Traffic-Flatrates auch für Server die Einsparung beim Datenvolumen. Aber spätestens beim Thema CDN, wo nach wir vor nach Traffic abgerechnet wird, wird es plötzlich wieder interessant.

Komprimierung? Bringt der Shop doch schon mit!

php bietet von Haus aus die Möglichkeit, Daten komprimiert auszuliefern und in xtcModified ist die Option im Admin unter ‘Erweiterte Konfiguration’ – ‘Gzip Kompression’ auch schnell gefunden und aktiviert. Nur: Das gelbe Ausrufezeichen in Page Speed verschwindet nicht, die Note von YSlow für die Komprimierung wird nur marginal besser.

Der Grund ist einfach: Die shopeigene Komprimierung wird wie gesagt vom php-Parser zur Verfügung gestellt. Nur Dateien, die diesen vor Auslieferung passieren, werden komprimiert. Und genau das gilt nicht für CSS und Javascript. Aber gerade hier findet sich ein enormes Einsparpotential.

mod_deflate kümmert sich um alles

Auch hier kommt uns wieder ein Apache-Modul zu Hilfe: mod_defalte (seit Apache 2, davor hieß es mod_gzip und wer noch einen Apache 1 im Einsatz hat sollte seinen Serveradmin mal fragen, ob er nicht lieber mit etwas Geld verdienen möchte, womit er sich auch auskennt). Und auch hier lohnt ein Blick in die .htaccess des HTML5Boilerplate. Zuvor schalten wir aber die shopeigene Komprimierung wieder aus, sie wird nicht benötigt.

<IfModule mod_deflate.c>
 
# Force deflate for mangled headers developer.yahoo.com/blogs/ydn/posts/2010/12/pushing-beyond-gzipping/
<IfModule mod_setenvif.c>
  <IfModule mod_headers.c>
    SetEnvIfNoCase ^(Accept-EncodXng|X-cept-Encoding|X{15}|~{15}|-{15})$ ^((gzip|deflate)s*,?s*)+|[X~-]{4,13}$ HAVE_Accept-Encoding
    RequestHeader append Accept-Encoding "gzip,deflate" env=HAVE_Accept-Encoding
  </IfModule>
</IfModule>
 
# HTML, TXT, CSS, JavaScript, JSON, XML, HTC:
<IfModule filter_module>
  FilterDeclare   COMPRESS
  FilterProvider  COMPRESS  DEFLATE resp=Content-Type $text/html
  FilterProvider  COMPRESS  DEFLATE resp=Content-Type $text/css
  FilterProvider  COMPRESS  DEFLATE resp=Content-Type $text/plain
  FilterProvider  COMPRESS  DEFLATE resp=Content-Type $text/xml
  FilterProvider  COMPRESS  DEFLATE resp=Content-Type $text/x-component
  FilterProvider  COMPRESS  DEFLATE resp=Content-Type $application/javascript
  FilterProvider  COMPRESS  DEFLATE resp=Content-Type $application/json
  FilterProvider  COMPRESS  DEFLATE resp=Content-Type $application/xml
  FilterProvider  COMPRESS  DEFLATE resp=Content-Type $application/xhtml+xml
  FilterProvider  COMPRESS  DEFLATE resp=Content-Type $application/rss+xml
  FilterProvider  COMPRESS  DEFLATE resp=Content-Type $application/atom+xml
  FilterProvider  COMPRESS  DEFLATE resp=Content-Type $application/vnd.ms-fontobject
  FilterProvider  COMPRESS  DEFLATE resp=Content-Type $image/svg+xml
  FilterProvider  COMPRESS  DEFLATE resp=Content-Type $application/x-font-ttf
  FilterProvider  COMPRESS  DEFLATE resp=Content-Type $font/opentype
  FilterChain     COMPRESS
  FilterProtocol  COMPRESS  DEFLATE change=yes;byteranges=no
</IfModule>
 
<IfModule !mod_filter.c>
  # Legacy versions of Apache
  AddOutputFilterByType DEFLATE text/html text/plain text/css application/json
  AddOutputFilterByType DEFLATE application/javascript
  AddOutputFilterByType DEFLATE text/xml application/xml text/x-component
  AddOutputFilterByType DEFLATE application/xhtml+xml application/rss+xml application/atom+xml
  AddOutputFilterByType DEFLATE image/svg+xml application/vnd.ms-fontobject application/x-font-ttf font/opentype
</IfModule>
</IfModule>

Zunächst kümmert man sich um Clients, die aufgrund von Proxies oder anderer Einflüsse kaputte Header schicken und standardmäßig nicht mit komprimierten Inhalten versorgt werden würden. Gemäß einem Blogpost im Yahoo! Developer Network sind das ca. 15% der Besucher, also eine nicht zu unterschätzende Anzahl.

Anschließend werden mit Hilfe von mod_filter, das wesentlich flexibler ist als das früher benutzte AddOutputFilterByType, Inhalte in Abhängigkeit ihres MIME-Type (den wir ja schon im zweiten Teil gerade gezogen haben) komprimiert. Bei Bildern beispielsweise wäre das nur verschwendete Rechenleistung. Der letzte Block ist für Server, die ohne mod_filter laufen, indem die ‘alte’ mod_deflate-Syntax zum Einsatz kommt.

Wer jetzt neu lädt wird sich wundern, dass sich nach wie vor nichts tut, unsere Javascript- und CSS-Daten noch immer bemängelt werden. Nachdem wir aber bereits im vorherigen Teil die Expire-Zeiten hoch gesetzt haben fragt der Browser gar nicht mehr beim Server nach, sondern holt die Datei aus seinem Cache und die ist natürlich unkomprimiert.
Um realistische Ergebnisse aus Page Speed zu bekommen müssen wir also den Browsercache umgehen, entweder indem wir ihn leeren oder indem wir mit gedrückter Hochstelltaste auf das ‘Neu laden’-Icon klicken – zumindest in Firefox und Chrome führt das zum gewünschten Ergebnis. Das ist aber auch nur deshalb praktikabel, weil sich unser Shop noch im Testbetrieb befindet. Wie man das Problem im Livebetrieb umgeht haben wir ja schon behandelt.

YSlow jetzt mit der Gesamtnote A

YSlow jetzt mit der Gesamtnote A

Auch bei Page Speed die 75%-Marke überschritten

Auch bei Page Speed die 75%-Marke überschritten

Natürlich gibt es auch die neue .htaccess mit dem aktuellen Status zum Dowload.

Weitere Artikel der Serie

  1. Höher, schneller, weiter
  2. Verfallsdatum überschritten

Disclaimer: Ich bin nach wie vor der Meinung, dass viele der Einstellungen in der Serverkonfiguration besser aufgehoben sind als in der .htaccess-Datei, da aber sicherlich viele das ganze auch auf Shared Hosting umsetzen möchten werden alle Änderungen, die auch über die .htaccess durchgeführt werden können, im Rahmen dieser Artikelreihe dort vorgenommen.

Verfallsdatum überschritten – xtcModified on steroids

36 von 100 möglichen Punkten erreicht ein frisch installierter xtcModified auf einem 1&1 Virtual Server. Diesen Wert gilt es jetzt im Rahmen dieser Artikelserie zu optimieren.

Browser-Caching nutzen

Ganz oben auf der Liste von Page Speed steht das fehlende Browser Caching.

Die Aktualität der folgenden Cache-fähigen Ressourcen ist nur von kurzer Dauer. Legen Sie fest, dass folgende Ressourcen künftig mindestens einmal pro Woche ablaufen:

Und darunter kommt so ziemlich jedes Bild, das Stylesheet und die Javascript-Dateien, die alle kein Ablaufdatum haben. Dieses würde festlegen, wie lange der Browser oder auch ein Proxyserver die Datei als aktuell betrachtet. Mit der aktuellen Konfiguration fordert er jede Datei bei jedem Aufruf erneut an, denn kein Ablaufdatum bedeutet, dass die Datei aus Browsersicht sofort veraltet ist.

Ein solches Verhalten ist sinnvoll und wünschenswert bei Inhalten, die bei jeder Anforderung die aktuellen Gegebenheiten reflektieren müssen, so führt beispielsweise das hinzufügen eines Artikels zum Warenkorb zu einer Änderung und das HTML für den Warenkorb darf dann eben nicht aus dem Cache geholt werden. Bilder, Stylesheets und Scripts ändern sich aber in der Regel nicht mit jedem Klick. Es ist also völlig unnötig, diese Dateien jedes Mal erneut anzufordern bzw. auch nur beim Server anzufragen, ob sich was geändert hat.

mod_expires for the rescue

Zwar gibt es in der .htaccess-Datei, die mit xtcModified mitkommt, einen Eintrag, um bestimmte Formate mit einem Ablaufdatum von einem Monat zu versehen (der aber standardmäßig nicht aktiv ist), ich bevorzuge hier aber die feiner aufgranulierte Lösung aus dem HTML5Boilerplate:

<IfModule mod_expires.c>
  ExpiresActive on
 
# Perhaps better to whitelist expires rules? Perhaps.
  ExpiresDefault                          "access plus 1 month"
 
# cache.appcache needs re-requests in FF 3.6 (thanks Remy ~Introducing HTML5)
  ExpiresByType text/cache-manifest       "access plus 0 seconds"
 
# Your document html 
  ExpiresByType text/html                 "access plus 0 seconds"
 
# Data
  ExpiresByType text/xml                  "access plus 0 seconds"
  ExpiresByType application/xml           "access plus 0 seconds"
  ExpiresByType application/json          "access plus 0 seconds"
 
# Feed
  ExpiresByType application/rss+xml       "access plus 1 hour"
  ExpiresByType application/atom+xml      "access plus 1 hour"
 
# Favicon (cannot be renamed)
  ExpiresByType image/x-icon              "access plus 1 week" 
 
# Media: images, video, audio
  ExpiresByType image/gif                 "access plus 1 month"
  ExpiresByType image/png                 "access plus 1 month"
  ExpiresByType image/jpg                 "access plus 1 month"
  ExpiresByType image/jpeg                "access plus 1 month"
  ExpiresByType video/ogg                 "access plus 1 month"
  ExpiresByType audio/ogg                 "access plus 1 month"
  ExpiresByType video/mp4                 "access plus 1 month"
  ExpiresByType video/webm                "access plus 1 month"
 
# HTC files  (css3pie)
  ExpiresByType text/x-component          "access plus 1 month"
 
# Webfonts
  ExpiresByType font/truetype             "access plus 1 month"
  ExpiresByType font/opentype             "access plus 1 month"
  ExpiresByType application/x-font-woff   "access plus 1 month"
  ExpiresByType image/svg+xml             "access plus 1 month"
  ExpiresByType application/vnd.ms-fontobject "access plus 1 month"
 
# CSS and JavaScript
  ExpiresByType text/css                  "access plus 1 year"
  ExpiresByType application/javascript    "access plus 1 year"
 
  <IfModule mod_headers.c>
    Header append Cache-Control "public"
  </IfModule>
 
</IfModule>

Das ganze in If-Bedingungen zu verpacken verhindert effektiv Internal Server Errors (500), wenn das Modul nicht installiert ist. Klar, dass das ganze dann auch nichts bringt, aber ein Shop, der Inhalte ohne die Optimierung ausliefert ist immer noch besser als ein Shop, der nur eine Fehlermeldung zurückgibt.
Wenn aber mod_expires aktiv ist geschieht folgendes: Der generelle Wert für das Ablaufdatum wird auf einen Monat gesetzt und das ganze dann für Inhalte, die nicht gecached werden sollen, wieder zurückgesetzt. Anschließend werden die Werte für einzelnen Formate basierend auf dem MIME-Type gesetzt. Man könnte alles weglassen, was dem generellen Wert entspricht, aber ich lasse das hier mal mit aufgeführt, vielleicht will man den ein oder anderen Ablaufzeitraum doch anpassen, bei X-Skating sind es beispielsweise 10 Jahre für Bilder. Auf die dabei auftretenden Probleme gehe ich später noch ein.
Cache-Control “public” sorgt dann noch dafür, dass diese Inhalte auch von Proxies gecached werden können, auch wenn man sich vorher per HTTP authentifizieren musste (was für xtcModified aber nicht zutrifft).

Da mod_expires auf Grundlage der MIME-Types arbeitet empfiehlt es sich, noch einen anderen Bereich aus der Datei von HTML5Boilerplate zu übernehmen, nämlich den Teil, wo die MIME-Types vereinheitlicht werden, gerade Javascript kommt je nach Serverkonfiguration mit den obskursten MIME-Types daher:

# JavaScript
#   Normalize to standard type (it's sniffed in IE anyways)
#   tools.ietf.org/html/rfc4329#section-7.2
AddType application/javascript         js
 
# Audio
AddType audio/ogg                      oga ogg
AddType audio/mp4                      m4a
 
# Video
AddType video/ogg                      ogv
AddType video/mp4                      mp4 m4v
AddType video/webm                     webm
 
# SVG
#   Required for svg webfonts on iPad
#   twitter.com/FontSquirrel/status/14855840545
AddType     image/svg+xml              svg svgz
AddEncoding gzip                       svgz
 
# Webfonts
AddType application/vnd.ms-fontobject  eot
AddType application/x-font-ttf         ttf ttc
AddType font/opentype                  otf
AddType application/x-font-woff        woff
 
# Assorted types
AddType image/x-icon                        ico
AddType image/webp                          webp
AddType text/cache-manifest                 appcache manifest
AddType text/x-component                    htc
AddType application/x-chrome-extension      crx
AddType application/x-opera-extension       oex
AddType application/x-xpinstall             xpi
AddType application/octet-stream            safariextz
AddType application/x-web-app-manifest+json webapp
AddType text/x-vcard                        vcf

Die einzige Änderung, die wir noch an den Expires vornehmen ist das Favicon, das wird ebenfalls auf einen Monat gesetzt. Die .htaccess, wie sie bis zu diesem Zeitpunkt aussieht, kann hier heruntergeladen werden.

Erneut durch YSlow und Page Speed überprüft ergibt sich schon ein wesentlich besseres Bild. YSlow pendelt sich jetzt bei 89 Punkten ein, noch deutlicher ist die Steigerung bei Page Speed, 60 von 100 möglichen Punkten stehen jetzt bereits zu Buche.

YSlow klettert von 80 auf 89 Punkte...


...Page Speed sogar von 36 auf 60

Auch schön zu sehen ist die extreme Reduktion an HTTP-Requests durch diese Maßnahme. So zeigt das Wasserfalldiagramm bei webpagetest.org ohne mod_expire auch bei der Anfragewiederholung noch alle Bilder etc. Der Server antwortet zwar mit 304 Not Modified, aber die Anfrage geht trotzdem raus und muss beantwortet werden. Sind Expire-Header gesetzt gehört das der Vergangenheit an.

Inhalte aktualisieren bei langen Expires

(Sehr) lange Expire-Zeiten bringen ein Problem mit sich: Da der Browser davon ausgeht, dass die CSS-Datei, die er gestern geladen hat, noch ein Jahr gültig ist, wird er erst gar nicht auf die Idee kommen, diese neu anzufordern. Daher kommt man um eine Versionierung nicht herum. HTML5Boilerplate empfiehlt das über Query-Paramter zu machen, statt stylesheet.css ruft man also beispielsweise stylesheet.css?20120112 auf. Damit man das nicht jedes Mal händisch aktualisieren muss sollte man die Zeilen 15 und 16 in templates/xtc5/css/general.css.php wie folgt ändern:

<link rel="stylesheet" href="<?php echo 'templates/'.CURRENT_TEMPLATE; ?>/stylesheet.css?<?php echo filemtime('templates/'.CURRENT_TEMPLATE.'/stylesheet.css') ?>" type="text/css" />
<link rel="stylesheet" href="<?php echo 'templates/'.CURRENT_TEMPLATE; ?>/css/thickbox.css?<?php echo filemtime('templates/'.CURRENT_TEMPLATE.'/css/thickbox.css') ?>" type="text/css" media="screen" />

Damit wird immer das Datum der letzten Modifikation als Unix-Zeitstempel angehangen. Das gleiche sollte man auch für das Javascript machen, aber da wir uns dem eh im Rahmen dieser Serie noch gesondert annehmen müssen verschieben wir das auf einen späteren Zeitpunkt.

Als letztes Problemkind bleiben die Bilder. Die Lösung dafür ist etwas aufwendiger und wird behandelt werden wenn wir auf das Thema Content Delivery Networks (CDN) zu sprechen kommen.

Weitere Artikel der Serie


Disclaimer: Ich bin nach wie vor der Meinung, dass viele der Einstellungen in der Serverkonfiguration besser aufgehoben sind als in der .htaccess-Datei, da aber sicherlich viele das ganze auch auf Shared Hosting umsetzen möchten werden alle Änderungen, die auch über die .htaccess durchgeführt werden können, im Rahmen dieser Artikelreihe dort vorgenommen.

Höher, schneller, weiter – xtcModified on steroids

So langsam erreicht die Erkenntnis, dass Websitegeschwindigkeit (auch) ein Rankingkriterium sein kann, auch die kleineren und ganz kleinen Shops.

Zeit, in einer Artikelserie mal zu zeigen, wie man aus einem der derzeit beliebtesten Open-Source-Systeme, nämlich aus xtcModified, das Maximum rauskitzeln kann.

Ausgangssituation

Shopsystem

Es beginnt mit einem xtcModified, wie er aus der Schachtel fällt. Zum Zeitpunkt dieser Artikelserie trägt er den schönen und leicht zu merkenden Namen 1.05 SP1b. In diesen wurden die Demoartikel importiert, allerdings mit individuellen Artikelnummern, damit es mehr als vier unterschiedliche Produkte sind. Außerdem wurden noch SEO-URLs aktiviert und vier Artikel auf die Startseite gestellt.

Hosting

Installiert ist der Shop auf einem 1&1 Virtual Server L, denn nur so hat man die maximale Kontrolle. Das sollte man im Hinterkopf behalten, wenn man die im Rahmen dieser Serie vorgestellten Tipps auf einem Shared Hosting umsetzen will, manche Sachen gehen dort einfach nicht.

Domain

Ach ja, Domains kauft man nicht, Domains hat man. Es stimmt, dass man die bei eigentlich jedem Hosting hinterherworfen bekommt. Trotzdem sollte man darauf achten, dass man eine größtmögliche Flexibilität bei der Konfiguration hat.
10 Subdomains, wie es 1&1 beispielsweise früher für einen Server angeboten hat, sind eine absolut sinnlose künstliche Limitation. Domaindiscount24 hat sich in den vergangenen Jahren als zuverlässiger Partner erwiesen was das Domainhosting angeht. Wer keinen eigenen Server hat sollte aber vorher mit seinem Hoster klären, ob dieser Fremddomains einrichten kann. Bei den meisten geht das kostenlos, bei manchen muss man eine geringe monatliche Gebühr einplanen.

Tools

Yahoos YSlow und Googles Page Speed sind sicherlich die beiden bekanntesten Browser-Plugins, die sich dem Thema Websitegeschwindigkeit widmen. Diese beiden werden uns im Rahmen der Serie begleiten, hin und wieder aber vom ein oder anderen Online-Tool ergänzt werden. Die Kritierien, die beide überprüfen, ähneln sich, die Ergebnisse könnten aber unterschiedlicher nicht sein.

Ausgangssituation YSlow

Während YSlow 80 Punkte vergibt und damit auf die amerikanische Schulnote ‘B’ kommt kann sich Page Speed bei unserem Testshop unter www.ladeze.it lediglich für 36 von 100 Punkten erwärmen, was zu einem roten Gesamtwert führt.

Ausgangssituation PageSpeed

Damit konfrontiert geht es jetzt an die Optimierung, denn auch beim ‘B’ von YSlow ist deutlich Optimierungspotential zu sehen, gibt es doch für den ein oder anderen Punkt eine glatte Sechs.

Wer sich die Wartezeit bis zum zweiten Teil etwas verkürzen will sollte in den Podacst von OnlineRader reinhören. Der bietet einen guten Überblick zum Thema.


Disclaimer: Ich bin nach wie vor der Meinung, dass viele der Einstellungen in der Serverkonfiguration besser aufgehoben sind als in der .htaccess-Datei, da aber sicherlich viele das ganze auch auf Shared Hosting umsetzen möchten werden alle Änderungen, die auch über die .htaccess durchgeführt werden können, im Rahmen dieser Artikelreihe dort vorgenommen.

Vertrauensbildende Maßnahmen

Vertrauen schaffen zwischen dem Händler und dem Kunden ist eine der Grundvoraussetzungen für erfolgreiche Geschäfte im Online-Handel. Ein mit SSL verschlüsselter Checkoutprozess war für uns daher schon immer eine Selbstverständlichkeit – nicht jeder Mitbewerber sieht das so. Darüber hinaus arbeiten wir seit Jahren erfolgreich mit Trusted Shops zusammen. Im vergangenen Jahr haben wir unser Engagement in diesem Bereich noch weiter ausgebaut und lassen unsere Webseiten täglich von McAfee Secure auf mögliche Schwachstellen prüfen – als erster und selbst zum Zeitpunkt dieses Posts ein Jahr später einziger Anbieter im Bereich Erzgebirge Volkskunst (Erzgebirge Palast) und Kuckucksuhren (Schwarzwald Palast).

In diesem Jahr gehen wir noch einen Schritt weiter. Unser Anbieter für SSL-Zertifikate, die PSW Group, hat uns in Zusammenarbeit mit Comodo ein Paket geschnürt, mit dem wir die Überprüfung auf Schwachstellen nicht nur auf alle unsere Shops ausweiten, sondern darüber hinaus auch noch alle Shops mit sogenannten Extended-Validation-Zertifikaten versehen können, die neben der schon vorhandenen Verschlüsselung auch klar und deutlich zum Ausdruck bringen, wer hinter der Website steckt und damit noch mehr Sicherheit für unsere Kunden bieten.
Damit übernehmen wir beim Thema sicheres Einkaufen nicht nur im Erzgebirge und im Schwarzwald die Vorreiterrolle, sondern jetzt auch im Bereich Nordic Cross Skating und lassen damit teilweise weit größere und umsatzstärkere Konkurrenzunternehmen hinter uns.

Krisenmanagement bei 1&1

In der Krise zeigt sich, was der Provider wirklich drauf hat. Krise bei 1&1 war gestern. Und das Krisenmanagement hat sich mit der Internetleitung einen Wettstreit darum geliefert, wer von beiden der größere Totalausfall ist.

Los ging es um kurz vor drei. Fünf von fünf Servern nicht erreichbar. Ein kurzer Check über die serielle Konsole ergab aber, dass es nicht an den Servern lag. Der Twitter-Account @1und1 brauchte dann geschlagene 20 Minuten, um das auch zu bemerken. Die, man sollte annehmen eigentlich genau für einen solchen Fall gedachte, Statusseite status.1und1.de hingegen verkündet auch heute morgen noch, dass alle Systeme funktionieren würden und dies seit dem 4. August so sei.

Ziemlich genau zwei Stunden später waren dann alle Server wieder erreichbar bis kurz vor 20 Uhr. Und hier kommt der Teil, der mich an dieser Geschichte wirklich aufregt. Fehler können immer mal auftreten, da kann man sich noch so gut absichern. Und ich gestehe jedem eine angemessene Zeit zu, dass er diese beheben kann. Wenn man aber um kurz nach fünf mit großen Halali auf Twitter verkündet, dass jetzt wieder alles gut sei, dann sollte man alles daran setzen, dass nicht genau der gleiche Fehler kurz darauf wieder auftritt:


Die Ursache ist bekannt. In anderen Worten:

Scheiße, genau das gleiche wie vorhin. Warum haben wir das nicht einfach vernünftig gefixt?

Und obwohl 1&1 weiß, woran es liegt, brauchen sie erneut über zwei Stunden, um das Problem aus der Welt zu schaffen!
Krisenmanagement und vor allem auch Krisenkommunikation sieht anders aus. Die angesprochene Statusseite hat sich auch beim zweiten Ausfall nicht aktualisiert und der Twitter-Account war eigentlich immer so viel zu spät dran, dass man sich auch den hätte sparen können.

Page 5 of 9« First...34567...Last »