Ein Paypal-Account, mehrere Shops, verschiedene Logos

Ein Paypal-Account, mehrere Shops, verschiedene Logos

Der Titel ist zugegebenermaßen etwas sperrig. Bei Elmastudio ist gestern ein Artikel erschienen, wie man die Paypal-Bezahlzeite etwas individualisieren kann.
Hat man jetzt mehrere Shops auf einem Paypal-Account laufen muss man sich aber nicht zwingend für das Logo der ‘Dachgesellschaft’ entscheiden, das der Kunde vermutlich gar nicht kennt und eher vorsichtig skeptisch reagiert. Denn man kann für das Paypal Standard Payment über entsprechende Parameter das gewünschte Logo mitgeben:

cpp_header_image
ist die max. 750×90 Pixel große Kopfgrafik
cpp_logo_image
ist das max. 190×60 Pixel große Logo

Bei cpp_logo_image muss man darauf achten, dass die übergebene URL maximal 127 Zeichen lang sein darf. Wer also bereits http://www.verein-zur-erhaltung-historischer-feuerwehrfahrzeuge-und-geraete.de/ 1 als Domain hat sollte sich bei Pfad und Bildnamen eher kurz halten.

Und so sieht das dann aus:




1 Wer meint, den Fehler gefunden zu haben, kann sich ja mal in den Kommentaren melden. Ich überleg mir was schönes.

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ß!

Konfigurierbare Produkte mit individuellen Preisen

Bei manchen Funktionalitäten, die in Magento eingebaut sind, fragt man sicht schon, ob man bei Varien mit dem, was man sich da zusammenklöppelt, auch einen Praxisbezug sieht oder ob man einfach irgendwas programmiert, egal ob es in der Praxis brauchbar ist oder nicht. Die Preisvergabe bei konfigurierbaren Produkten ist so ein Fall. Magento sieht von Haus aus vor, dass man einer Variante, etwa einer anderen Größe, einen festen oder prozentualen Aufpreis geben kann. Oder anders gesagt, die untenstehende Preismatrix funktioniert mit diesem System schon nicht mehr:

  11cm 15cm
natur 28,40 31,80
Goldrand 31,20 34,90
lasiert 34,60 40,70

Denn bei natur kostet die 15cm-Variante 3,40 Euro mehr, bei Goldrand aber schon 3,70 Euro und bei lasiert gar 6,10 Euro. Das lässt sich weder durch einen Fixpreis noch durch einen prozentualen Aufschlag abdecken und wenn man dann noch bedenkt, dass man das auch noch für die Ausführung (natur, Goldrand, lasiert) machen muss bricht das ganze System in sich zusammen.

Zum Glück gibt es eine Lösung, die eigentlich so naheliegend ist, dass man sich fragt, warum Magento das nicht einfach von Haus aus kann: Simple Configurable Products. Die Erweiterung sorgt dafür, dass einfach der direkt beim Produkt hinterlegte Preis benutzt wird. Und nicht irgendwelche komischen Berechnungen durchgeführt werden, die am Ende doch nicht zum gewünschten Ergebnis führen.

Einen kleinen Bug hat die Erweiterung aber: Zeigt man die gewählte Option im Warenkorb an, dann wird immer das Admin-Label für das Attribut verwendet, welches nicht mehrsprachig ist. Aber dafür gibt es Abhilfe. Die Datei, um die es geht, ist Checkout/Block/Cart/Item/Renderer.php. Dort findet sich in Zeile 81:

'label' => $attribute->getFrontendLabel(),

Das muss lediglich durch

'label' => $attribute->getStoreLabel(),

ersetzt werden und schon sind die Label auch in der jeweiligen Store-Sprache.

Umlaute im URL key von Magento

Umlaute ist ja eines meiner Lieblingsthemen. Und Magento stellt sich da direkt hinter Afterbuy in die ‘Können wir nicht’-Schlange. Naja, fast. So heißt es in meinem Lieblingsbuch auf Seite 162:

Die URL-Bezeichnung ist wichtig, wenn Sie als Shop-Besitzer die Anzeige in der Adressleiste eines Browsers beeinflussen möchten. Sollten Sie das Feld leer lassen, generiert Magento automatisch aus dem Produktnamen die URL-Bezeichnung. Da das System aus dem USA stammt, werden die Umlaute dabei nicht berücksichtigt, sondern falsch dargestellt: ä als a, ö als o etc.

Soweit richtig. Magento berücksichtigt in der URL-Bezeichnung (URL key) keine Umlaute. Warum man im Buch aber nicht direkt auf die Lösung verweist erschließt sich mir nicht. Denn wer mag schon bei vierstelligen Produktzahlen jeden URL key in Handarbeit erstellen?

Allerdings muss die im Magento-Wiki befindliche Lösung noch etwas erweitert werden, denn die Einträge in app/etc/local.xml, die im Wiki genannt werden, berücksichtigen weder ß noch die Großbuchstaben Ä, Ö und Ü (die Ersetzung erfolgt offensichtlich bevor der String in Kleinbuchstaben gewandelt wird).

Der fertige Block, der direkt vor </config> eingesetzt wird, muss also lauten:

<default>
  <url>
    <convert>
      <char0228><from>ä</from><to>ae</to></char0228>
      <char0246><from>ö</from><to>oe</to></char0246>
      <char0252><from>ü</from><to>ue</to></char0252>
      <char0223><from>ß</from><to>ss</to></char0223>
      <char0196><from>Ä</from><to>ae</to></char0196>
      <char0214><from>Ö</from><to>oe</to></char0214>
      <char0220><from>Ü</from><to>ue</to></char0220>
    </convert>
  </url>
</default>

Damit werden Umlaute im Produktnamen im URL key korrekt umgeschrieben. Die Einstellung greift nicht für Kategorien. Wer dafür eine Lösung hat, immer her damit, aber Kategorien legt man ja auch nicht so oft neu an wie Produkte bzw. nicht in der selben Anzahl.

Magento-Buch – nur für wen?

Ich lese gerade, äh nein, ich quäle mich durch ein Magento-Buch, namentlich Magento – Installation, Anwendung, Erweiterung und ich habe mich auf Podcast-Empfehlungen und die Amazon-Bewertungen verlassen. Genau. Selber schuld.

Nach einem Drittel ist mir absolut unklar, für welche Zielgruppe das Buch ist. Auf jeden Fall trifft das, was Falk Opitz in seiner Rezension schreibt, nicht zu:

Dieses Buch ist sowohl für Neueinsteiger, als auch erfahrene Entwickler sehr zu empfehlen.

Leider bekomme ich jedes Mal Ausschlag, wenn Sachen, die für einen erfahrenen Entwickler eine Selbstverständlichkeit sind, erklärt werden. Ich brauche keine Empfehlungen für Texteditoren oder FTP-Programme und ich brauche keine Erklärungen, was ein Cache ist oder ein RSS-Feed. Auf der anderen Seite dürfte den Neueinsteiger schon die lokale Installation überfordern, spätestens beim Editieren von irgendwelchen E-Mail-Templates dürfte aber jemand, der HTML für einen US-Amerikanischen Radiosender hält, das Buch aus der Hand fallen.

Und dann kommen die wirklich wichtigen Sachen schlicht zu kurz.
Stichwort Zahlungsmodule. Steht auch ganz markant auf dem Buchtitel. Dafür steht dann auf Seite 116:

4.4.5 Google API, Paypal-Konten, System & Erweitert – Einstellungen für Entwickler
Innerhalb des Magento-Administrationsbereichs gibt es noch weitaus mehr Möglichkeiten und Konfigurationseinstellungen, als in diesem Kapitel behandelt wurdenwerden. Die für dieses Buch nicht relevanten Bereichen haben wir daher an dieser Stelle kurz der Vollständigkeit halber erwähnt. Es handelt sich dabei um Bereiche, die vor allem für Entwickler bzw. Administratoren mit einem hohen Wissensstand interessant sein dürften.

Und auf Seite 130 noch einmal ein Schlag ins Gesicht:

Ein sehr populärer Vertreter einer im Internet etablierten Zahlungsmöglichkeit ist Paypal. Paypal wird, neben Payflow und Authorize.net, von Magento direkt unterstützt. Es würde aber den Umfang dieses Buches springen, gezielt auf die jeweiligen Payment-Provider einzugehen.

Oder, in meinen Worten:
Wenn Paypal Ihre einzige Zahlungsmöglichkeit ist, kaufen Sie sich doch bitte ein anderes Buch.

Stichwort Steuersätze. Also mir ist ja unklar was es bei Varien zu rauchen gab als das implementiert wurde. Aber nach dem 3,5 Seiten im Buch, die sich mit diesem Thema beschäftigen, hat man am Ende mehr Fragen als vorher. So wird das Thema eines weltweiten Versands (und der damit verbundenen Herausforderungen an die Steuerberechnung) mit keinem Wort erwähnt und es wird auch nicht erklärt, wie man sicherstellt, dass ein Schweizer keine Steuer berechnet bekommt, ein Franzose hingegen schon. Man klebt einfach ein paar Sachen zusammen, die zum Großteil aus rein textlicher Information bestehen und dann wird’s schon passen. Da werde ich mich wohl doch an diese Anleitung halten müssen.

Ich befürchte ja, das mit mir und dem Buch wird nichts mehr. Mal sehen, wie viele Seiten es noch überlebt, bevor es in eine Ecke fliegt. Dem Kollegen, der für die Shoppflege zuständig ist, brauche ich es aber auch nicht in die Hand zu drücken. Dem ist das zu technisch. Der mehr oder weniger generalistische Ansatz des Buches dürfte damit gleichzeitig sein größtes Problem sein…

Update

Bin dann doch schon auf Seite 305. Da werden gerade CSS-Änderungen am Frontend vorgenommen:

background:#fff; border:1px solid #999; border-top:none;

Und direkt danach kommt:

Was hat das zu bedeuten? background: #fff ist der weiße Hintergrund; border:1px solid #999 sagt dem Browser, dass er um den ganzen Inhaltsbereich einen grauen Rahmen ziehen soll.

Mach Sachen! Wie gesagt, eine Zielgruppe ist für dieses Buch nicht auszumachen.