Nicolas hätte seine wahre Freude…


… wenn – ja wenn…. er sich seinen Nachnamen hätte schützen lassen! Denn dann könnte er sich zur Ruhe setzen und sich entspannt zurücklehnen – und ganz bequem von den Lizenzgebühren leben!

Denn: Kaum jemand wird so oft als vermeintlich Schuldiger benannt wie der Star aus “The Rock – Fels der Entscheidung”… Richtig – die Rede ist von Mr. N. Cage. Verantwortlich für die Schuldzuweisung ist sein Name, der [keedsch] gesprochen wird.

Warum auch immer – aber neben Caroline Müller alias C.C.Catch, gesprochen [ketsch], muß der gute Nick immer herhalten, wenn es bei irgendwelchen CMS- oder Shop-Systemen zu Anzeigeproblemen kommt…

Üblicher Verdächtiger in solchen Fällen ist nämlich der Cache – gesprochen [käsch].

Soweit der Epilog.

Nun ist es so, daß wir mal wieder einen Shopware-Shop am Wickel haben – den ersten der 5er Generation. Obwohl es am responsiven Design noch etwas zu fummeln gibt, will man ja irgendwie außer Strichen, Punkten und Hintergründen doch etwas sehen. Also wurde der veranwortliche “Shop System Articles and Products Manager” (SSAaPM), wie es wohl auf Neu-Deutsch heißen würde (in Anlehnung an “Content Manager”, “Content Manager Assistant” and… – sorry – … und “Social Media Community Manager”), gebeten, 3-4, bis max. 12 Mio Artikel einzuspielen… ;-)

So weit, so gut. Auftrag erledigt? Jo! Füße hoch? Nö! Es folgte nämlich noch der kleinlaute Kommentar, daß man an den Kategorien etwas verändert hätte. Und nun shoppt der Shop nicht mehr! Irgendwas (!!!) wäre wohl zerschossen…

Eingeloggt, nix zu sehen…. Aaaaah  – ein Anzeigeproblem….  *lol* Cache *noch-loller* gelöscht – nichts! Denn der war es ausnahmsweise mal nicht! Und die Startseite lädt trotzdem nicht… Obwohl: Falsch! Sie lädt und lädt und lädt… – wie man’s nimmt!

Nun ja – heute gibt es dann wohl wieder keinen Sex. Frauchen muß mit der Mohrrübe zufrieden sein… Denn die Nacht wird wieder einmal lang. Oder eher zu kurz? Morgen hilft jedenfalls nur exzessiver Coffein-Mißbrauch… Und ein Streichholz zum Aufhalten des einen wachen Auges… Ma gugge…

Shop-Frontend aufgerufen, gewartet, geguckt, zwischendurch rasiert und Frauchen die Rübe weggenommen, den Job erledigt, zurückgekommen, weiter gewartet, Kaffee gekocht, länger gewartet, Frauchen die Rübe wieder weggenommen, nochmal den Rübendienst erledigt, zurückgekommen – [Dreimal raten!] – gewartet… Shopware lädt den Header samt Grafik und Main-Navigation – und rööööööööödelt… Keine Einkaufswelt, kein Main-Content, kein Footer… Keine Seitennavigation! Nichts!

Main-Navigation getestet. Außer Home (wo es ja “rödelt”)  3 Kategorien: 2 davon ok, 1 nok. Beim Aufruf besagter Kategorie endlich eine Fehlermeldung:

Screenshot :: Shop: Fatal Error

In besagter Klasse “CheapestPriceService” findet man an der Stelle nur eine Methode, in deren Verlauf eine Preisgruppen-ID ermittelt werden soll:

Screenshot :: Shop: Preisgruppe Funktion

Ohne jetzt großartig irgendwelche Debugger oder Konsolen und deren Meldungen zu bemühen, erinnerte ich mich dunkel, daß ich letztens eine Preisgruppe “Kostenlos” für Gratis-Katalog-Versand angelegt hatte.. Danach funzte aber noch alles, trotz entleerten Caches – gesprochen übrigens [käschs] bis [käsches], mit ganz kurzem, fast nach [i] klingendem [e], also am besten irgendwas in Richtung [käschis] !!!

Aber wo könnte man etwas an den Preisgruppen drehen und schrauben? Was hat der “SSAaPM” getan? Grund-Konfig geändert? Unter Einstellungen > Grundeinstellungen > Artikel > Preisgruppen ??? Nö – alles clean! Aber was – in Dreiteufelsnamen – hat der “SSAaPM” da veranstaltet? Hiiiiiiiilfe!

Dann die Erleuchtung:
Aha – an den Artikeln selbst wurde rumgeschraubt!

Der Witz ist, daß es bei den Artikeln keine Default-Preisgruppe gibt. Trotzdem wurde bei einem einzigen der Artikel der Haken “Preisgruppe aktiv” gesetzt – und dann sofort gespeichert, ohne auch eine Preisgruppe zu hinterlegen!

Setzt man den Haken “Preisgruppe aktiv”, erwartet Shopware natürlich auch eine. Ist aber keine angegeben (in Ermangelung von “Default”), läuft die Suche nach der Preisgruppe natürlich ins Leere, was null zurückgibt. Und was bei null (als non-object) -> getId() rauskommt, kann sich wohl jeder denken: Ein kleiner, niedlicher FATAL ERROR !!!
Screenshot :: Shop Preisgruppe

Übersetzt: Nutze eine Preisgruppe – und zwar die Gruppe “Undefined”. Und von dieser (nicht definierten) Gruppe ziehe die ID aus der Datenbanktabelle… Das kann ja wohl nur in die Hose gehen.. Von NICHTS kann man wohl nur sehr schlecht eine ID ziehen – schon allein weil die Zeile mit dieser ominösen ID gar nicht existiert! Logisch – oder?.

Ergo: Haken raus…  (Übrigens: Haken lassen + irgendeine Preisgruppe auswählen funzt natürlich auch…) Fehler behoben !!! (Die fehlerhafte Kategorie funzt, weil alle ihre Artikel ohne Fehler abgefragt werden können. Und die Startseite funzt, weil die eingebundene Einkaufswelt mit den Artikeln der strittigen Kategorie auch keine Probs mehr hat… Also alles wieder i.O. !!!)

Schnell zum Frauchen, die Mohrrübe aufgegessen und den “Job” noch mal erledigt. Vorsichtshalber. Die Nacht wird ja doch länger als erwartet… Und ein wenig schlafen will selbst ich… Irgenwann mal… ;-)

Wenn es jetzt ohne Zwischenfälle weitergeht und mir nicht wieder ein Oberschlaumeier erzählt, ich solle doch mal den  [keedsch] leeren, kann der Shop vielleicht ja auch bald endlich Cash (gesprochen [käsch]) generieren…

OT = Oller Trödel?


Also für OffTopic steht OT heute ausnahmsweise mal nicht… Heute war nämlich mal wieder Katastrophenalarm: Der Met & Gothic Shop wollte nicht so, wie der Kunde wollte. Und der Betreiber wollte das sooo garantiert auch nicht.

Das Worst-Case- bzw. “Wurst-Käse-Szenario”: Ein ausländischer Kunde trieb sich unter der englischen Oberfläche im Shop rum und packte seinen Warenkorb voll. Dann ging es ans Checkout – und paff – eine weiße Seite…

Fix geschaut, was wo wie warum inkludiert wird – dabei schon error_reporting(E_ALL) im Kopf – und zu meiner Überraschung stellte ich fest, daß in der application_top.php des betagten XT-Commerce-Shops bereits die Zeilen

// set the level of error reporting
error_reporting(E_ALL & ~E_NOTICE);
//  error_reporting(E_ALL);

vorzufinden waren. Äh – ja macht man denn so was im produktiven Einsatz? Und noch “äher” – warum meckert mich nix an?

Der “Noch”-[aber nicht mehr lange]-Hoster GONEO.DE war schuld. Ebenso wie bei Strato tut sich mit bloßem error_reporting erst mal gar nichts. Nun ja – ein Massenhoster, der mal fix auf der Blacklist landet… Und der scheinbar so einen guten Ruf hat, daß Facbook den Versand von PNs verweigert, wenn im Text der String “goneo.de” auftaucht. Wird wohl als gefährlich eingestuft…. ;-)

Jedenfalls half ein kleines Update der .htaccess:

php_value error_reporting 2047
php_flag display_errors on
php_flag display_startup_errors on
php_flag register_globals on


Ich habe zwar keinen blassen Dunst, was die 2047 da zu suchen hat – aber mit diesen Werten spuckt sogar Goneo-Webspace Fehlermeldungen aus… ;-)

php_value register_globals 1
php_value error_reporting “E_ALL”

brachte nämlich nichts… Von daher hätte ich auch 1296483131 da eingetragen – mir wurscht. Hauptsache, error_reporting reportet auch Errors… :-)

Vorher hatte ich schon etwas mit var_dump() und exit() in der vermeintlich verbuggten (weil weißen…)  checkout_payment.php rumgespielt und mir $_SESSION, $order, $order_total_modules usw. anzeigen lassen – wenn es denn ging. Dabei stellte ich dann fest, daß innerhalb von zwei-drei Zeilen das Script die Konstante DIR_WS_CLASSES “vergißt”… Die Datei order.php wurde noch inkludiert – zwei Zeilen später war der Pfad vergessen – order_total.php war für den englischen Englischländer nicht erreichbar – und der Einkaufsbummel endete abrupt.

Eben freute ich mich noch, daß ich den Fehler schon mal etwas “eingegrenzt” hätte – doch bei einem Blick in diese Dateien kam ich mir vor, als wenn ein Schwein ins Uhrwerk glotzt… Mann !!! Ich habe dieses Jahr doch noch was vor! Wie lange soll ich denn da suchen? Hier wird dieses inkludiert, dort jenes – und das inkludiert dann dort hinten wieder eine andere Datei usw. usf. Grrrr !!!!

Nun gut – Grrrrrummelneo hatte ja ein Einsehen und ließ sich zum error_reporting() überreden….  Und man höre und staune: Ich war auf den richtigen Weg! Ein erneuter Aufruf der Seite offenbarte folgende Fehlermeldung:

Parse error: syntax error, unexpected T_STRING in /home/met-honigwein-shop-de/htdocs/lang/english/modules/order_total/ot_paypal_fee.php on line 18
(Am Ende von Zeile 17 fehlte das das Semikolon……..)

Natürlich war das noch nicht alles. Einen Upload und einen Testaufruf später zeigte sich die “redundante” Tücke des engl. PayPal-Moduls – EIN Fehler allein wäre ja langweilig. Also lieber gleich doppelt… Hält wohl besser ( die Online-Shopper vom Kaufen ab… ;-) )

Parse error: syntax error, unexpected T_STRING in /home/met-honigwein-shop-de/htdocs/lang/english/modules/order_total/ot_paypal_second_fee.php on line 18
(Am Ende von Zeile 17 fehlte ebenfalls das Semikolon……….)

Wenn so was natürlich im OT-Pfad liegt, ist es kein Wunder, wenn das Script beim Aufruf der order_total.php aussteigt und den Dienst verweigert….

Fazit: Falls noch jemand einen alten XTC-Shop nutzt und das Problem kennt, daß das Checkout eines Käufers mit ausländischer Adresse unter der englischen Oberfläche den Dienst verweigert….  – einfach mal die PayPal-Dateien unter /lang/english/modules/order_total prüfen…

Chronologie eines Dramas


Was bisher geschah:

Unsere liebliche Dicklichkeit – also ich – im Freudentaumel: Der erste “umgemodelte” und persönlichen Bedürfnissen angepaßte Online-Shop aus dem Hause Shopware fristet unter meinen Fittichen seit X Stunden und Y Minuten sein Dasein im Netz – wobei X kleiner als wenig ist und Y nicht weiter ins Gewicht fällt. Ein ganz frischer Frischling, sozusagen…

Es wurde natürlich alles getestet; alles “funzte” – nur ein paar Seiten und/oder Übersetzungen für die unter uns weilenden Englischländer und sonstige ausländisch sprechende Klientel sind noch von Nöten. Solcher Pillepalle-Krimskrams wird natürlich noch nachgerüstet. So zumindest der Plan.

Ich also stolz wie Oskar… Leicht fassungslos auf die Frühstückseier starrend, die aus Kostengründen gespiegelt anstatt gestreichelt wurden  (Kunststück – wurde doch die potentielle Streichlerin auch aus Kostengründen eingespart), trötet doch tatsächlich um
09:25 Uhr morgens – also mitten in der “Nacht” (zumindest für Nachteulen-Nerds und diejenigen, die es werden wollen…) – das Handy-Dingens… Eine frisch gesimste Simse, die mir die zwölf soeben zum “Abendbrot” inhalierten Frühstückseier förmlich wieder aus dem Mund fallen ließen (ich wollte nämlich gerade nach durchmachter bzw. -wachter Nacht ins Bettchen):

“Moin! Der BMOA-Shop funktioniert nicht richtig. Versuch mal, verschiedene Artikel in den Warenkorb zu packen!”

Na ich dachte ja, ich spinne! Es ging doch alles! Mir sprangen bis dato vor Stolz über ein funzendes Etwas  gerade eben fast noch die Knöppe vom Hemd – wegen der stolz geschwellten (Scheiß Deutsch – eigentlich “geschwollenen”) Brust… Un’ nu? (Viel besserer Deutsch.)

Also ließ ich die Eier Eier sein – und stürzte mich auf den Shop. Die Datenbank(anfragen) war(en) so buggy, daß nicht einmal der (natürlich in der DB hinterlegte) Wartungsmodus griff. GEIL !!!  Unterm Strich ging nix mehr richtig – und der Rest falsch oder gar nicht.

Ich war leicht verwirrt – und hatte Quadrilliarden von Fragezeichen in den Augen: Äh – wollte ich nicht gerade – trotz der offensichtlichen Mängel (welches Shopsystem hat die nicht…) – ein Fan von Shopware werden? War ich nicht trotz aller Unzulänglichkeiten geneigt, das System für gut bis oberaffentittengeil zu befinden? Innerhalb von 2 Monaten nach dem Erstkontakt kritzelte ich godlike in den Templates rum – oder, wenn das nicht reichte – erstellte ich Plugins… (Ok, zwar nur “Alpha”-Versionen – aber immerhin!) Zumindest sind schon mal 2 von 3 Plugins live im Einsatz…

Aber was zum Teufel war los? Ich bin zwar keine Lady – aber bin ich denn trotzdem schon gaga? Denn normalerweise lege ich meine Hand für Sachen, die ich mache, ins Feuer. Bei Eigenproduktionen/-kreationen sowieso – und bei fremden Sachen, in  die ich mich nach und nach eingearbeitet habe, zumindest nach bestem Wissen und Gewissen….! Und bei Shopware hatte ich eigentlich ein gutes Gefühl. Leider wird zwar bei Version 4 immer noch nicht das Versandkosten-Splitting genutzt; und auch die Länder-Zonen entpuppen sich als purer Blödsinn, solange ich sie bei den Versandkosten nicht nutzen kann…  Manche Variablen oder SQL-Queries überfordern beim Erstkontakt auch etwas.

Aber unterm Strich eigentlich Spaß – solange dieser eben nicht getrübt wird. Und wenn dat janze Zeugs nich funzt, dann ist das nicht nur “extrem unlustig” – nein; dann ist der eben erwähnte Spaß auch nicht nur getrübt – sondern pechschwarz verdunkelt !!!

Und der Spaß blieb vollends auf der Strecke, nachdem sich der Inhalt der SMS bewahrheitete: Mehr als einen Artikel in den Warenkorb zu legen funktionierte nicht mehr. Und selbst bei einem war es Glückssache. Shopware hing… und hing… und hing.

Der Warenkorb öffnete sich nicht !!!

Ich also in heller Aufgregung. Verständlich… – mein jüngstes Baby war krank und drohte am plötzlichen Kindstod zu sterben… Anstatt deshalb zum Psychoschwätzer zu rennen und für teures Geld einen One-Man-Quickie auf der legendären Couch hinzulegen, stürmte ich natürlich an einen meiner Rechner, um lieber selbst teures Geld zu verdienen – oder es zumindest wert zu sein… Ich mußte also unbedingt ins Netz – und bzw. um dem Grauen (auf Kosten meines Namens….) einen Riegel vor(zu)schieben…. Gut gedacht – aber der Wartungsmodus funzte ja nicht gleich… Also Operation am offenen Herzen – live, vor aller Augen. Aber egal! Hauptsache, der Fehler ist bald keiner mehr.

Ich machte also ALLES, was ich die letzten Tage impelemtiert habe, Schritt für Schritt rückgänig – vom datenschutzkonformen Social Media-Plugin “ITC-SMP” v3.0 Alpha a la Me-&-MySelf über Google Analytics und Quantcast… Ich deaktivierte neue Kategorien, neue Blogs, neue Artikel.

Nach jedem Schritt:

• raus aus dem Artikel-hinzufügen-Modus bzw.
• raus dem Warenkorb
• Cache über das Shopware-Backend leeren oder
• Cache mittels PuTTY über SSH leeren
• Cookies löschen

Wow! Das Debugging mutiert zur Klickorgie! Die ekelhafte Meldung “Ups! Ein Fehler…” habe ich dabei wohl 89 Mio mal gesehen….

Wenn man prozeduralen Code schreibt, sind error_reporting ( E_ALL ), var_dump ( ) und print_r ( ) natürlich die Hilfsmittel erster Klasse und auch erster Wahl – erst recht, wenn sie mit X-debug oder <pre>bla…blubb…foo…bar…</pre> aufgepimpt wurden.

Ein solches “Pimping” ist ja schön und gut – und vor allem ja auch gut und schön ;-)   ; und auch wenn man selbst vorrangig OOP betreibt, bleiben die genannten Funktionen im Rahmen EIGENER Programmierung  die erste Wahl. Schließlich kann man natürlich Methoden implementieren, die ein Error-Logging erlauben oder mit Exceptions hantieren und “try-en”, diese zu “catchen”, um sie live auszuwerten.

Spannend wird es eben nur, wenn man sich per se als “De-facto-doch-lieber-prozedural-Progger” zu erkennen gibt  bzw. sich als ein solcher outet – und auf fremde OOP triift !!! Fremder Code ist zwar immer etwas mehr als nur gewöhnungsbedürftig – aber wenn man auf die Schnelle keine Ausgaben erzeugen kann, wird es richtig nervig! Denn den Core verändern? Mit var_dump ( ) und die ( ) ??? Ist das wirklich eine Alternative?

Toll – nutzt aber manchmal nur nichts oder zumindest nicht viel, wenn noch ein PostDispatcher zulangt… Fehlermeldungen werden vom gerenderten Code überlagert. Voher “die( )-en”? Nun ja; wenn man dann Glück hat, wird man wenigstens im erzeugten HTML-Quelltext fündig. Kommt allerdings noch ein Redirect mittels Header(“Location:….”) o.ä. dazwischen, sieht es eher MAU aus. Aber so viel nur mal zu den theoretischen Vorbetrachtungen.

Also ging das Rumgeeier los – passend zu Ostern… Weil ja echo $bla, print_r ( $blubb ) und var_dump ( $foobar ) samt folgendem exit ( ”jo” ) oder die ( “nö” )  wegen der fremden OOP und der ganzen Pre- und PostDispatcherei so mal aben auf die Schnelle ausfielen, mußte also Firebug/FirePHP ran. Aber diese Konsole sollte man wohl nur auf Monitoren mit mind. 186 Zoll Bilddiagonale nutzen. Ach wat – Splitscreen bzw. 2 Monitore. Minimum! Sonst wird es nämlich ziemlich müßig, sich da durchzukämpfen – zumal der Output mehr als gewöhnungsbedürftig ist. Was liebe ich da doch das beruhigende Orange von X-debug-reporteten Fehlern in Kombination mit entspanntem <pre>…</pre>…  Natürlich sind Fehler immer Schiete – aber bei den letztgenannten wird man wenigstens nicht aus der gewohnten Ruhe gebracht… Ommmm…… Und: Ouza…….. Auch Fätt-Boys kennen Bad Boys… ;-)

Screenshot :: Firebug/FirePHPFirePHP, FireBug – toll !!! Genau DIESES kryptische Zeug brauchte ich… Was nutzt es mir denn, wenn “SQLSTATE[42000]aussagt:Syntax error or access violation: 1064 You have an error in your SQL syntax“… Gerade die eben benutzte SQL-Query wäre nämlich extrem aufschlußreich… Und zwar SEHR !!! Ansonsten ist nämlich ein entspannter Nachmittag einfach mal so “WEG”… Oder 2, oder 3… Oder 7 – oder 12!

Mal eben echo $sql bzw. $query und  var_dump ( $result ) anzeigen zu lassen, ist aber nicht ohne Weiteres drin. Ergo: Der Arsch ist erst mal dick….

Screenshot :: Firebug/FirePHPOOP-Horror pur: Ich – und das Sammelsurium aus Zend, Smarty, Doctrine usw. !!!

Nachdem ich dann also schritttweise alles rückgängig gemacht habe…. änderte sich NICHTS . GUT (oder eher das Gegenteil) – ich war es nicht, der Schiete verzapft hat – aber WER oder WAS war es denn bitteschön dann? Schließlich muß es für einen Fehler auch immer eine URSACHE geben…

Nach gefühlten 7 Mrd. Testaufrufen und mind. halb so vielen Quelltext-Beäugungen, warum $sql_select .= ‘, (‘.$calculation.’) as calculation_value_’ . $dispatchID; nun auf einmal einen Syntax-Fehler erzeugen soll, obwohl an der betreffenden Datei NIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIEEEEEEE etwas geändert wurde, kam ich auf den Trichter, daß die Wurzel allen Übels die Versandkostenberechnung war, die scheinbar keine Lust merhr hatte, weiter funktionieren zu wollen. Schließlich gab es schon mal Probleme, als ich mit zusätzlichen Attributen bzw. Freitextfeldern a la boleean (Checkbox) Ticketversand rumexperimentierte. Aus einem gespeicherten

MAX(a.topseller) as has_topseller, MAX(at.attr3) as has_comment, MAX(b.esdarticle) as has_esd, MAX(at.attr4=”true”) as Ticketversand

wurde nämlich beim nächsten Aufruf

MAX(a.topseller) as has_topseller, MAX(at.attr3) as has_comment, MAX(b.esdarticle) as has_esd, MAX(at.attr4=

!!!!

Ob das nun ein simpler Ausgabefehler aufgrund fehlender HTML-Entities war  – oder ob das in der DB passierte – das wissen nur die Götter.  Obwohl mehr für Datenbank spricht (sonst hätte es bei der Berechnung keinen Fehler gegeben) – Datenmüll habe ich nicht gefunden. Möglicherweise aber auch deshalb, weil ich erfolgreich auf einfache Gansefüße alias Hochkommata umstellte:

MAX(a.topseller) as has_topseller, MAX(at.attr3) as has_comment, MAX(b.esdarticle) as has_esd, MAX(at.attr4=’true’) as Ticketversand

Das funzte !!!

Da das aber für Mischversand (Merchandising-Artikel UND Tickets) oder reinen Merchandising-Artikel-Versand nicht richtig funzte, setzte ich unter Einstellungen > Grundeinstellungen > Storefront > Versandkosten-Modul wieder den Standard

MAX(a.topseller) as has_topseller, MAX(at.attr3) as has_comment, MAX(b.esdarticle) as has_esd

Jedenfalls stellte ich dann um 14:15 Uhr fest, daß das gemeldete Problem  EINEINDEUTIG (… wie mein Mathe-Lehrer aus der 8. Klasse, Karl Wellner, gesagt hätte…) auf die hinterlegten Versandkostenregeln zurückzuführen sind. Deaktivierte ich sie oder konfigurierte ich sie lt. Shopware-Doku mit einer eigenen Berechnung gemäß

MIN((SELECT 3 FROM s_articles_categories WHERE articleID=a.id AND categoryID = 7))

, war die Welt in Ordnung…

Einziges Problemchen dabei war, daß es bei manchen Artikeln (Tickets) eben BILLIGER statt teurer werden sollte. Also mußte es

MIN((SELECT 3 FROM s_articles_categories WHERE articleID=a.id AND categoryID != 7))

lauten. Soweit, so gut. Und jetzt wird es “lustig”: Als der erste Artikel im englischen Sprachshop aufgenommen wurde, funktionierten die Versandkosten nicht mehr!  Schnell war als Übeltöter……äh, ich meine natürlich “-täter”…. – wen wunderts – die Versandkostenbrechnung ausgemacht. Denn: Funktioniert etwas nicht, liegt es meist an eben dem, was nicht funktioniert. Also schuf ich nach dem großen “Kopfklatsch” flugs Abhilfe:

MIN((SELECT 3 FROM s_articles_categories WHERE articleID=a.id AND categoryID != 7 AND categoryID != 9))

Und das funktionierte !!! Da bin ich mir 10.000 % sicher, weil ich es ausgiebig getestet habe!

Der Brüller ist, daß es nicht mehr ging, als ich mehr Artikel ins Englische “rüberholte”. Also zum MItmeißeln: wenn ich nicht ganz senil bin, funzte obige Berechnung, solange

im deutschen Shop
• ein Ticket in der Kategorie “Tickets”,
• ein oder mehrere T-Shirts unter “T-Shirts”,
• ein oder mehrer T-Shirts unter “Girlie-Shirts” und

im englischen Shop
• ein Ticket in der Kategorie “Tickets”

hinterlegt waren.

Nachdem ich im deutschen Shop
• die Kategorie “CDs” angelegt und mit 3 Scheiben befüllt hatte,
• in beiden Shops eine Blog-Kategorie “News” einrichtete,
• Google Analytics und Quantcast implementierte
• ein eigenes DATENSCHUTZKONFORMES* SocialMedia-Plugin (Nachfolger unserer nicht mehr weiterentwickelten 2-Klick-Beta) installierte und
• samtliche Artikel des deutschen Shops in den englischen rüberzog – da wurde das Problem bemerkt!

Da Shopware in manchen Templates ein Problem damit hat, wenn Javascripte syntaktisch richtig eingebunden werden, konnte das Problem überall liegen. Erst nachdem ich die eigene Versandkostenberechnung aushebelte bzw. shoptechnisch aka finanzmathematisch unzulässig auf  “… articleID=a.id AND categoryID != 7 AND categoryID != 9…” verzichtete, ging wieder alles. Leider kam ich erst darauf, als ich alles andere rückgängig gemacht habe. Kann ja niemand ahnen, daß die VK schon beim Hinzufügen zum Warenkorb eine Rolle spielen !!!

Diese Berechnung funzte wohl nur so lange, wie ein einziger Artikel in der einzigen englischen Kategorie zu finden war. Ob es die dazugekommenen T-Shirts waren – oder was auch immer… – das Problem waren die VK. Das wußte ich nun. Doch wie das Problem lösen?

Ob das jetzt glaubhaft klingt oder nicht: Ich sagte mir gedanklich so in schönstem bayerisch “Dis stinkt mi an!” – und da kam mir die Idee…. Es gab doch noch so was wie DISTINCT !!! Ob das àuch des Rätsels Löung sein könnte?

Ich machte die Probe aufs Exempel – und wurde belohnt! Mein Problem war keins mehr…

MIN((SELECT DISTINCT 3 FROM s_articles_categories WHERE articleID=a.id AND (categoryID != 7 AND categoryID != 8 AND categoryID != 9 AND categoryID != 13))) FUNZTE !!!

“Nicht-Ticket-Artikel” und Mischversand aus Tickets und anderen Artikeln sind nämlich in diesem Fall (Versand innerhalb Deuschlands) 3 Euro teurer als “Nur Tickets”… Daß mein logisches Empfinden ein wenig mit MIN bzw. MAX kollidiert bzw. hadert und ich gern mal einen kompletten SQL-Query-Output und einen VAR_DUMP des Output-Arrays hätte, sei mal dahingestellt. Natürlich ließe sich das machen – ich wohne ja auch nicht hinter dem Berg – aber eben mit erheblichem Aufwand. Und am Core rumzufummeln ist trotz einer existenten SIK immer hot. Es braucht nur mal zu klingeln – und schon vergißt man irgendwas. Erst recht witzig, weil Shopware-Dateien eine so tolle “Nicht-UTF-8-Codierung” aufweisen… Also am besten Pfoten weg. Eigene Sheets, Templates oder sogar Plugins – das ist was anderes. Soll heißen: Den Kern fasse ich nur an, wenn es gar nicht anders geht. Aber ich hatte ja noch mal Glück… ;-)

16:59 Uhr: Barth – die Frisur sitzt.
17:00 Uhr: Internet – der Shop funzt.

* Zum Thema Datenschutzkonformität:
• Facebook und Konsorten vs. Datenschutz
• Ahnungslose Anwälte verbreiten unabsichtlich Unsinn?
• 2-Klick-Lösung als Beta 2
• Ein Gespenst geht um in Europa…
• Wenn man sich schon mal freut…

Ticket- und Merchandising-Shop


Sooooooooooooooooo… Wir haben unseren ersten, auf Shopware basierenden Online-Shop so ziemlich fertig… ;-)

Logo BMOAAn der englischen Version wird allerdings noch etwas gefeilt. Es fehlen noch ein paar Seiten und ein paar Übersetzungen… Aber egal – der Kartenvorverkauf für das mittlerweile 17. BMOA 2015 ist angelaufen!

E-Mail-Versand über Website funktioniert nicht mehr…


Ein XTC-Shop (oder eine andere Website) versendet plötzlich (scheinbar) keine E-Mails mehr… Man selbst ist sich jedoch keiner Schuld bewußt… Woran kann es also liegen?

Das Problem muß nicht unbedingt auf einer falschen Konfiguration oder einem Hack beruhen… Handelt es sich evtl. um Billig-Webspace bei einem Massenhoster? Dann ist es wahrscheinlich, daß es sich um eine ganz andere Ursache handelt…

Es wird im Video gezeigt, was man neben Konfiguration und Scriptcode noch prüfen sollte – am besten sogar zuerst!

Für den Fall, daß sich das Ergebnis dieser Prüfung mit den Befürchtungen deckt, wird auch grob erklärt, was zu tun ist bzw. was das Beste wäre, um einem Wiederholungsfall vorzubeugen… Und das wäre aus SEO-Gründen ohnehin ratsam…

Weiterführende Links:
http://www.zdnet.de/39160890/dns-blacklisting-e-mail-verbot-fuer-unschuldige/
http://www.returnpath.de/blog-press/leitfaden-zu-e-mail-blacklists-alles-was-sie-uber-die-schwarzen-listen-wissen-mussen/

Übrigens: Den Shop kann man nur empfehlen! Leckeren Met und vieles mehr gibt es bei http://metladen.de bzw. http://met-honigwein-shop.de !!!

.

DAU-Alarm!


Ursprünglich wollte ich den Beitrag ja mit www.doof.de betiteln – bis ich feststellte, daß die Axel Springer AG sich diese Domain gekrallt hat… Ob das in einem Anflug von Selbstkritik wegen der vom Springer-Verlag verzapften BLÖD-Zeitung passiert ist – darüber spekuliere ich hier lieber nicht. ;o) ;o) ;o)

Aber lassen wir die BILD-Zeitung, ihrer Verantwortlichen und deren Leserschaft heute mal in Ruhe. Daher habe ich vorsichtshalber einen anderen Titel gewählt, der in etwa das Gleiche aussagt wie ”Achtung – Vollpfosten im Netz”.

Bevor man uns jetzt Arroganz unterstellt: Natürlich haben auch wir die Weisheit nicht mit Löffeln gefressen. Das Leben ist ein endloser Lernprozess – vieles, was wir damals nicht wußten, wissen wir jetzt; und ein Teil von dem, was wir heute nicht oder nicht richtig wissen, wissen wir vielleicht später mal irgendwann – und vielleicht sogar richtig. Wer weiß…

Wie gesagt – wir wissen ja auch nicht alles. Allerdings kannten wir bisher eigentlich immer unsere Grenzen. Einen Online-Shop zu programmieren oder ohne fachmännische Hilfe zu betreiben, wäre uns nie eingefallen, wenn unser Know-How nur aus 1 Zeile PHP-Code bestünde oder ähnlich umfangreich wäre.

»Ah – Erkenntnis!  Erleuchtung! Es gibt ja Internetz! Dann spiele ich jetzt “Online-Shop”… Mein Nachbar kann Frontpage und installiert mir bestimmt einen Shop…« So oder ähnlich scheinen manche Leute ins Netz gelangt zu sein. Die haben alles Mögliche – vom Sockenschuß über der berühmten Knall bis hin zum totalen Sprung in der Schüssel – aber eben null Hintergrund, keine Ahnung – und erst recht keinen Plan, was irgendwelche grundlegenden Abläufe im Netz betrifft. (Leider. Denn andere müssen unter dieser Dummheit leiden – z.B., weil ihnen deswegen eine STRAFANZEIGE ins Haus flattert…)

Großkotzig, oder? Mag sein. Vielleicht ein bißchen.  Aber wenn wir irgendwelche Zusammenhänge nicht kennen oder nicht deuten können, dann sind wir wenigstens so intelligent und FRAGEN bzw. RECHERCHIEREN, wenn uns etwas spanisch vorkommt. Doch worum geht es genau?

Man stelle sich einmal vor, es gäbe keine HTML-Formulare. Man wäre gezwungen, sämtliche Sachen per GET zu übergeben, so daß man entsprechende URIs um einen QueryString erweitert, indem man Parameter bzw. Wertepaare anhängt. So kann ich dann aus einer 1 eine 5 nachen, aus einer Pfanne einen Topf – oder eben 232 andere Töpfe.

Dann noch schnell ein &mode=add  vorn oder hinten ran – und schon landet meine neue Küchenausstattung im Warenkorb. Natürlich geht das. Und vor allem schnell und unkompliziert. Wozu also die doch existenten Formulare, geschweige denn POST nutzen? Per Adreßzeile ist alles ja “viiiiiiiiiiiel schönerer”.

Also pflastert man die “Shop-Seite” mit Links auf kryptische URLs zu. Meier, Müller, Schulze, Lehmann, Hinz und sogar der jetzt an dieser Stelle von allen Lesern erwartete Kunz können sich nun endlich 3 Zwergkaninchen oder einen Wolf klicken. Ebenso der Stino-Surfer und Otto-Normalverbraucher. Jippieh – Click-Attack!

Aus Gründen der Emazipation haben  sich Conny Crawler, Susanne Spider und Ricarda Robot aber nun gesagt: “Das wollen und können wir auch!” In Ermangelung von Fingerchen wird zwar nicht auf irgendwelchen nicht vorhandenen Mausbuttons rumgefingert – man spart sich das Klicken – aber man folgt trotzdem den Links…

Was passiert? Wie auf einer Tupperware-Party folgt Ricarda Robot ganz bereitwillig der Einladung “Add-a-Plastikschüssel”, wobei sie also virtuell auf dem zur Partymeile gehörenden Pfad  /index.php?modul=shop&mode=add&category=kitchen&article=tupper box&items=3 lustwandelt.

Doch wie war das noch gleich? Wenn man - sei es nun durch Klicken, Folgen oder “Lustwandeln” – irgendwie auf die Seite /index…box&items=3 kommt, schmeißt der gute Geist des Online-Shops aus reiner Nettigkeit 3 Plaste-Schüsseln in den virtuellen Einkaufswagen – den Warenkorb.

Da die Betreiberin des Shops, eine gewisse Frau Vera Olldau, die auch gern mit abgekürztem Vornamen als V.Olldau in Erscheinung tritt, keine Kosten und Mühen gescheut hat, um ein hochqualitatives und ultimatives Nonplusultra-Shopsystem aufzusetzen, gibt es darin natürlich neckische Tools wie die Echtzeitanzeige von aktuell befüllten Warenkörben usw. - gleich neben dem implementierten Wetter-Ticker für Timbuktu.

Verständlicherweise hat bei einer derartigen Homeshopping-Party unsere über alles geschätzte Frau V.Olldau Dollar- bzw. Euro-Zeichen in den Äuglein. Die werden allerdings feucht (also nicht Frau V.Olldau oder die Währungssymbole – nein, die Augen…), weil auch nach Stunden keine persönlichen Daten eingegeben, keine Bestellungen ausgelöst und keinerlei Zahlungsverpflichtungen eingegangen wurden.

Kruzitürkn! Gottverdammich! Himmelarsch und Zwirn! “Die haben mich verpökert” denkt Frau V.Olldau wütend. Aber der Progger hat als zusätzliches Feature die Anzeige der IP-Adresse eingebaut… Hah! Das schreit nach Rache!

Also hin zur Polizei. “Böse Menschen”, so Frau V.Olldau, “haben meinen Online-Shop abgenutzt und meine kleinen Bits und Bytes gequält! Nur zum Spaß. Ich hatte deswegen ganz viel Fick!” Der Polizist guckt verdutzt. “Was hatten Sie?” will er wissen. “Na hier diesen – wie heißt das – ach ja, Träff-Fick. Das ist doch Computersabotage, oder?”

Der Polizist ist auch so ein Kandidat, der eine zufällig vor der Ingenieurshochschule herumliegende Leiche heimlich vor die Post legt, damit er den Bericht mit allen darin enthaltenen Wörtern auch allein schreiben kann.

Server-Logs? Bäh! Kennt man dort in dem Dorf nicht. Dort gibt es nur den Sheriff, die Post, die Hochschule und die Hütte von V.Olldau nebst Online-Shop.

Also springt unser Sheriff auf, rennt zur Wand, nimmt den Trichter ans Ohr und kurbelt. “Bitte mal die Staatsanwaltschaft, Fräulein…” Ein Fall von Coumputerterrorismus wird nach ganz oben gemeldet…

Minuten später: Der Richter wird vom Staatsanwalt aus dem Bett geklingelt! “Chef – wir haben eine IP von Computer-Saboteuren! Cyber-Kriminelle der übelsten Sorte! Terroristen!” Der Richter unterschreibt ein Formular, nachdem er ein paar Angaben eingetragen hat – und schickt seinen Kurier zur Staatsanwaltschaft zurück. Dieser reitet flugs bei Nacht und Nebel los…

Es werden alle Hebel in Bewegung gesetzt. Die Christel von der Post (!), die die Telefonleitungen zusammenstöpselt, wird verhört. Schlußendlich gibt sie die Daten heraus. Ricarda Robot hatte am 30.02.2012 um 24:69 Uhr die IP-Adresse 123.456.789.000 !!!

Wie gesagt – Logdateien auf Servern sind in den dortigen Breitengraden noch gänzlich unbekannt. Schade! Ricarda Robot benutzt nämlich keinen ordinären Stino-Browser – sie hinterläßt daher auch verräterische Spuren im Log. Sogar einen Hinweis auf eine Info-Seite ihrer Homepage. Warum also einfach, wenn man auch den Richter aus’m Bett klingeln und nachts einen Boten auf einem Pferd durch die Gegend hetzen kann…

Wäre man in der Gegend, in der Frau V.Olldau lebt, auch schon so weit wie anderswo, hätte ein Blick in die Logdatei gereicht. Dann zwei Zeilen in die robots.txt einfügen - und fertig!

Ein vernünftiges Shop-System wäre auch noch eine Möglichkeit.

Wir werden uns wohl aber damit abfinden müssen, daß sich am Technologie-Standort Deutschland jede Menge Vollpfosten im Netz tummeln. Und daß in diesem Fall überhaupt erst Daten zu irgendwelchen IPs ermittelt wurden, zeugt auch nicht unbedingt von der Qualifikation unserer Cyber-Cops…

Also: Vorsicht im Netz - es ist DAU-Alarm! Und bloß nicht irgendwelchen Links folgen – es kann ja sein, daß der Betreiber einer Seite gar nicht will, daß man einer verlinkten Seite folgt… Logisch? Klar doch. Deutschland 2013!

Ein echtes Opfer einer solchen Geschichte: SEOkicks… Die ganze Story hier: http://www.seokicks.de/news/201301/strafanzeige-gegen-seokicks-gefullte-warenkorbe-nicht-bestellt/#comments

Der vorliegende Fall läßt uns zum ersten Mal freiwillig darüber nachdenken, ob nicht sinnvoll wäre, Online-Shop-Betreibern eine Pflichtschulung “Server-Grundwissen in 3 Tagen” aufzubürden und sie nur geprüfte Shop-Systeme verwenden zu lassen…

Windows L8 – der User weint…


Microsoft hat es wahrgemacht – das höchstwahrscheinlich zu Unrecht verschriene Windows 8 wird seit heute zu den angedrohten, horrenden Preisen angeboten. Bis gestern (also bis 31.01.2013, 24:00 Uhr) lief ja eine Aktion, in deren Rahmen man ein Upgrade auf Windows 8 Pro für sage und schreibe nur 29,99 Euro beziehen konnte.

Im Freundes- und Bekanntenkreis haben etliche Leutchen dieses Angebot genutzt. Und erste Tests haben ergeben, daß Win8 flüssig und vor allem stabil läuft. Allerdings ist es ein wenig gewöhnungsbedürftig.

Seit heute ist also nun im MS-Download-Shop zu lesen, daß die während der o.g. Aktion angekündigten Preise ab jetzt Realität sind: Ein Windows-8-Upgrade kostet 119,99 €; und ein Windows-8-Pro-Upgrade schlägt sogar mit  279,99 € zu Buche. (Witzig ist übrigens der Zusatz UVP im microsoft-eigenen Online-Shop.) Ob sich der Redmonder “Winzigweich”-Konzern mit dieser Preispolitik einen Gefallen tut, bleibt abzuwarten bzw. ist eher zu bezweifeln.  Wegen knapp 30 Euro hätte sich wohl kaum ein Raubkopierer Gedanken gemacht – beim fast zehnfachen Preis für ein OS, das ohne Zusatztools nicht einmal DVDs abspielen kann, sieht das schon etwas anders aus – was auch nachvollziehbar ist.  

Die Alternative: Linux! Diverse Linux-Varianten gibt es nach wie vor umsonst. Würden nicht sämtliche “Hausfrauen” und unbedarften (zukünftigen) PC-”Besitzer” stillhalten   (echte PC-”User”, die mit der Materie vertraut sind, würden es wohl nicht tun), wenn sie beim Kauf neuer Rechner das neue MS-Win-OS aufs Auge gedrückt bekommen, wäre wohl bei den exorbitanten Preisen der Verkauf von Win8 heute für alle Zeit beendet.

Aber leider ist es nach wie vor so, daß jemand, der gerade mal so mit Windows umgehen kann (also Rechner ein- und ausschalten), mit Linux vollkommen überfordert ist – es sei denn, er startet als Mausschubser eine “Klickibunti”-Oberfläche eines Live-Systems von einer bootbaren DVD. Installation und Updates (trotz GUI) ohne Fehler sowie root-Zugriff per Konsole sind für Nicht-Profis nach wie vor ziemlich unmöglich. Denn wenn man z.B. nicht weiß, was man wie warum wo (z.B. in der /etc/apt/sources.list) zu editieren hat, ist es u.U. mit Updates Essig. Noch schlimmer ist, wenn beim kleinsten neuen Pups alte Pakete aus sämtlichen Repositories verschwinden und neue Pakete nicht kompatibel sind, so daß eine komplette Neuinstallation notwendig wird, nur weil man aufgrund irgendwelcher Abhängigkeiten auf nicht mehr aufzutreibende Pakete updaten müßte.

Das wirklich gute Debian 5, Codename “Lenny”, ist kaum noch irgendwo zu finden; das 4er “Etch” ebenso nicht – und kompatible Pakete dafür erst recht nicht. Man wäre also gezwungen, etwas  komplett neues zu installieren – es sei denn, man hätte die kompletten [sic!] 39 CDs von Lenny…  Solange Linux so anwenderunfreundlich ist, könnte Microsoft wahrscheinlich sogar 500,- Euro für ein Betriebssystem verlangen, davon dann 3 Exemplare verkaufen und mit 500 Raubkopien in jedem Kleckerdorf kämpfen… 

Na dann…

Nichts als heiße Luft…


Nachdem wegen angeblicher Fehler im Online-Shop der HBZ Branse GmbH viel heiße Luft durch einen BSD-User abgelassen wurde und wir  hier und hier darauf eingingen, lief viel Wasser den Berg hinunter – immerhin haben wir die haltlosen Vorwürfe über ein Vierteljahr unkommentiert gelassen.

Wir erinnern uns kurz: Die “Startseite” http://shop.hbz-branse.de/shop erzeugte einen Fehler 404. Der Gag dabei: Das ist nicht die Startseite! Und es existiert auch keine Umleitung, die diesen Aufruf erzeugt! Für uns war klar: Der Fehler sitzt vor dem Monitor in Schicht 8 des siebenschichtigen OSI-Modells. Immerhin war der BSDler stolz auf seine “speziellen Einstellungen”. Nun war es aber an uns, herauszufinden, was mit “normalen Einstellungen” (bzw. bei “normaler Nutzung”) passiert. Was geschieht also, wenn man den Browser bestimmungsgemäß verwendet und nicht einfach irgendwelche Phantasie-URLs zu nicht existenten Seiten eingibt?

Erstens hätten wir zum Testen mit besagter BSD-Edition ein 64Bit-System gebraucht. Davon gibt es bei uns zwar etliche – als Fätt-Boys haben wir schließlich 2 DiMuX(e) im Einsatz. Doch die sind logischerweise tabu. “Never touch a running system” vs. Live-Stick… Nö – beim besten Willen nicht. Nicht wegen derartigen Unsinns… Privat steht beim Kollegen Klein auch etwas 64bittiges herum – er hat aber auch noch etwas anderes zu tun; und das nicht zu knapp. Private Kisten oder Rechner mit anderer Bestimmung a la DiMuX sind ohnehin irgendwie tabu. Außerdem: Bei EiTiCo bin ich der Web-Onkel – aber meine 64er Test-Kiste war leider gerade “out of order”. Seit über 3 Monaten lag das Ding in auseinandergeschraubten Einzelteilen irgendwo hier und dort verteilt umher, weil es nicht so wollte, wie es sollte. Endlich habe ich auch in einer ruhigen Minute die Fehlerquelle gefunden: Eine meiner heißgeliebten M-Audio Delta 1010LT war verstorben. Rien ne va plus – nichts geht mehr! Ok, kurz getrauert; alles zusammengefriemelt, dann fix den originalen, “popeligen” Realtek-HD-Sound@NVIDIA aktiviert – und dat Ding löppt allwedder…

Zweitens: Ich hatte die Ruhe weg! Denn SERVERSEITIG heißt SERVERSEITIG! Und kraft meiner Wassersuppe habe ich im Vollbesitz meiner geistigen Fähigkeiten SERVERSEITIGE UMLEITUNGEN per .htaccess erstellt. Also konnte der besagte Fehler gar nicht auftreten – es sei denn, der Feuerfuchs der betreffenden BSD-Edition macht, was er will und kreiert nach Belieben URLs, die er dann aufruft. Doch dann wäre er komplett Schrott und nicht nutzbar; das würde dieses System komplett disqualifizieren. Daher war dieser Teil der Kritik (SSL-Kritik ist berechtigt! Liegt aber nicht in meiner Hand!) von Anfang an einfach nur in die Kategorie BLÖDSINN einzuordnen.

Drittens: Die einzige Möglichkeit, die (neben mutwilliger URL-Falscheingabe seitens des testenden “anonymen BSD-Users” (kurz: “ABU”)) zu einem Auftreten des Fehlers führen könnte, wäre ein von mir irgendwo eingebauter, falscher Link, der keine Umleitung auslöst und direkt auf den falschen URL zeigt. Doch ich bat ja den ABU, mir mitzuteilen, wo er den URL her hätte (um diesen etwaigen Fehler dann auszumerzen). Bislang ist diesbezüglich nichts erfolgt. Also bleibt mir nur die Annahme, daß er diese Adresse höchst-selbst und eigenhändig eingetippselt hat.

Doch DANN ist alles ok – wie erwartet. Nicht existente Seiten liefern nun einmal einen 404er; das soll so, muß so und ist auch richtig so. Das weiß eigentlich sogar der ABU. Die serverseitigen Umleitungen funktionieren alle perfekt – wie erwartet. Und nun kann ich auch reinen Gewissens sagen, ich hätte es mit BSD getestet:

Sowohl alle Verlinkungen auf der Homepage als auch die Direkteingabe von  http://shop.hbz-branse.de/, http://www.hbz-shop.de/ oder http://www.hbz-branse-shop.de/ führen erwartungsgemäß zur richtigen Seite. Lediglich ein Flash-Element wird vom “Gnash”-Player unter BSD nicht verarbeitet. Aber Flash ist ohnehin (spätestens seit HTML5 und Apple-Smartphones) out und stirbt demnächst sowieso.

Aber von einem 404er ist weit und breit nichts zu sehen – der tritt erst auf, wenn ich Phantasie-URLs wie /shop oder /wurstbrot eingebe. Doch so was mache ich nicht - ich bin schließlich kein ABU!

Wie gesagt: Falls ich den (übrigens logischerweise natürlich auch in anderen Browsern einen Fehler 404 erzeugenden) URL irgendwo so, wie es kritisiert wurde (http://shop.hbz-branse.de/shop), fälschlicherweise verlinkt haben sollte, ist mir das echt entgangen. Gefunden habe ich jedenfalls nichts. Doch so lange sich der ABU in Schweigen hüllt, muß ich eben annehmen, daß er seine hyperaktiven Fingerchen bei der Adreßeingabe nicht im Griff hatte. Doch mit Verlaub – das ist dann einzig und allein SEIN Problem und interessiert mich nicht die Bohne.

Nach wie vor bin ich aber gern bereit, das (angebliche) Problem hier im Blog zu diskutieren oder ggf. zu reproduzieren. So lange man mir aber nicht den geheimen und gut versteckten Link auf die angebliche Startseite zeigt, bleibe ich um so standhafter bei meiner Meinung, daß alles so ist, wie es sein soll.

Offizielles Fazit: Der kritisierte Fehler existierte nie und ist nur heiße Luft - mehr nicht! Und alles, was zu der Annahme dieses Fehlers führte, basierte auf falschem Umgang mit dem Rechner – so leid es mir auch für das Ego des BSD-Nerds tut.

Update: Ich habe gerade festgestellt, daß neben dem, was im Blog niedergeschreiben steht, noch eine weitergehende Diskussion stattfand und mir doch vom ABU mitgeteilt wurde, in welcher Situation der Fehler auftritt – das war mir in Anbetracht der verstrichenen Zeit tatsächlich entfallen. Wenn ich ihn richtig verstanden habe, tritt der 404er auf, wenn man in der Navigationsleiste der Homepage auf Shop klickt. Daher habe ich sämtliche Verlinkungen nochmals getestet – und zwar für alle als Video sichtbar und nachvollziehbar.

Freude hält nicht ewig an…


Ich dachte bislang immer, daß ich der weltgrößte Nörgler sei… Da habe ich mich aber wohl geirrt. Es gibt Menschen, die zu Hause hinter dem Rechner sitzen und den ganzen Tag Protokolle bzw. Logdateien lesen, ob wieder Chinesen auf dem Rechner waren. Also Firewall bis zum Anschlag! Angst vor Javascript und Cookies runden das dann ab – Amazon und Google könnten sonst herausbekommen, daß sie nichts herausbekommen sollen. Au weia! Spaß und Komfort im Netz sind schädlich – die ganze Welt will einem nur an den Kragen. Und wenn ich mir heute online einen Dildo bestelle, fühle ich mich ja total ausspioniert, wenn der Online-Sex-Shop mitbekommt, daß ich Sex-Spielzeug kaufe. Wenn die mir dann nächstes Mal personalisierte Werbung für passende Batterien schicken, gleicht das dem Weltuntergang: Der gläserne Bürger ist dann Realität! Wenn ich aber alles ausschalte und mir dann bei Amazon ein Buch hole, werden die niemals auf die Idee kommen, daß ich lese. Wie auch…

Sicher – es muß für alles Grenzen geben. Es steht mir aber auch frei, einen Rechner mit sensiblen Daten nicht ins Netz zu stellen. Es ist einzig und allein mein Verschulden, wenn irgendwas ins Netz gelangt, was da nicht hingehört. Denn ich bin der, der die Daten auf den Rechner packt.

Vielen ist mittlerweile egal, was von Ihnen im Netzt kursiert; diese Typen schreien nur nach Datenschutz, weil es eine Modeerscheinung ist. Und 10 Minuten später posten sie bei Facebook Fotos ihrer Kinder. Andere sind da schon etwas vorsichtiger und handeln bedachter. Doch bei der dritten Gruppe kann man es nur Paranoia nennen. Erst recht, wenn man als Mitglied dieser Gruppe alles verweigert: Windows, WordPress, Typo3 usw. Es ist alles schlecht, selbst kann man alles viel besser – sitzt aber, anstatt Karriere zu machen,  zu Hause hinter dem Rechner und fängt 24/7 kleine Chinesen, die durchs WAN huschen…

Eigentlich ist es nicht meine Art, hinter dem Rücken von anderen zu lästern – zumindest nicht, wenn ich sie kenne. Aber heute wurde ich echt sauer, als ich das Gesichtsbuch aufklappte. Daher muß ich mal Luft ablassen – und lasse mich ausnahmsweise mal auf dasselbe Niveau herab und lästere hier. Mit einem Unterschied: Ich schicke dem Kollegen Zugangsdaten zum Blog – dann kann er sich dazu äußern. Ich bitte sogar darum.

Worum geht es? Nach langem Hin und Her hat der Online-Shop von HBZ Branse die Trusted-Shop-Zertifizierung geschafft. Dazu muß man wissen, daß der Shop eine Entwicklung von OSG Neue Medien ist; daß der Betreiber E/D/E heißt und dieser Shop nur gemietet wurde. Als “Administrator” hat man eigentlich nur die Möglichkeit, den Shop wie ein CMS zu nutzen. Es existieren Schnittstellen, um Artikel von E/D/E zu importieren; theoretisch hat die Software von OSG auch eine Vorzertifizierung von Trusted Shops. Theoretisch. Es war trotzdem viel Arbeit, sich durch teilweise widersprüchliche und konfuse Anleitungen und Fehlerprotokolle zu wuseln – aber wozu gibt es EiTiCo? Wir beraten HBZ ja nicht umsonst.

Ergo: Die Zertifizierung hat geklappt, wobei für uns von vornherein SSL auf der Tagesordnung stand. Kommt wahrscheinlich auch noch – das ist man seinen Kunden schon irgendwie schuldig. Es fehlt eigentlich nur noch der Auftrag vom Chef. Trotzdem ist SSL keine Voraussetzung für eine TS-Zertifizierung. Punkt. Darum – und um nichts anderes – ging es. Niemand hat behauptet, daß schon ein SSL-Zertifikat existieren würde. Allerdings ist besagter Facebook-Beitrags-Autor wild dabei gewesen, alles anhand des fehlenden SSL-Zertifikats zu zerpflücken.

Jedenfalls mußte ich beim Stöbern auf Facebook das folgende erblicken (nach den Bildern und etwaigen Texten folgt meine jeweilige Stellungnahme):

404? HBZ? Da war ich etwas erstaunt. Doch dann erst noch der Text dazu – mir fehlten die Worte, was eigentlich nur höchst selten vorkommt:

Die Startseite. {Name des Verfassers} – Ansicht. Natürlich mit speziellen Einstellungen. Und garantiert windowsfrei! Und das mit bestandenem Gütesiegel. Die angebotenen Produkte konnte ich mir mit meinen Einstellungen leider nicht ansehen.

Also sah ich mir das Bild genauer an; mein Blut geriet langsam in Wallung; und ich verstieg mich zu folgendem Kommentar (wie gesagt – wir kennen uns):

1) Es wäre schon nett, wenn Du mich über so etwas informieren würdest. Ich zerpflücke Seiten, an denen Du irgend einen Anteil hast, auch nicht in aller Öffentlichkeit.

2) Wo hast Du den URL http://shop.hbz-branse.de/shop her? Der sollte eigentlich nirgends existieren, wenn da nicht gerade ein Fehler passiert ist.

3) Wenn Du hingegen eine manuelle Eingabe in die Adreßleiste gemacht hast: Was erwartest Du bitteschön, wenn Du eine nicht existente Seite aufrufst? Du hättest ebenso gut http://shop.hbz-branse.de/heiko-tut-gern-wichtig eingeben können – 404 bedeutet, daß die Seite nicht gefunden wurde. Und das finde ich nicht unlogisch, wenn die Seite nicht existiert. Das muß ich Dir doch wohl nicht sagen, oder? Ich denke, Du hast so viel Ahnung?

4) Wenn Du mit Deinen Einstellungen irgendwas nicht siehst, ist das bitte wessen Problem? Vielleicht solltest Du an Deinem Rechner mal die Einstellung “OFF” testen.

5) Wenn das jetzt ein wenig böse klingt: Selbst schuld. STARTSEITE ist nämlich dermaßen falsch, daß ich schon fast geneigt bin, das als Lüge zu bezeichnen. Ich nehme aber alles zurück, wenn Du mir zeigst, wo der Link zu http://shop.hbz-branse.de/shop ist. Ich habe auch nur einen Kopf. Also: Dann mal los – ich warte!

Dann stellte ich fest, daß es noch weiter ging – es existierte ein ganzes Album mit Screenshots:

Text zum Bild:

Ich kann mir nicht helfen. Findet so etwas keine Beachtung? Es is ja nur ein Zertifikat. Halten Sie davon was Sie wollen. Datenschutz sieht bei {Name des Verfassers} aber anders aus!

Antwort (mal davon abgesehen, daß dieser Vorwurf nicht so ganz unbegründet ist):

Ich kann Dir auch nicht helfen. SSL ist nicht Bestandteil oder Kriterium der Trusted-Shop-Zertifizierung.

Und weiter:

Text zum Bild:

Das Zertifikat sagt alles. Vertrauenswürdig? Ja, Ja, Administrator müßte man sein, und in der Administration arbeiten. Wenigstens ist das Zertifikat noch bis 2013 gültig. Natürlich für ne andere Domain. Man lese und Staune. Was liegt dort nahe? Wurde diese Seite schon manipuliert? Das alles nach 2 Tagen der Siegelerteilung?

Antwort (er vergleicht KEIN Zertifikat mit einem anderen Zertifikat…):

Ich glaube schon, daß das Zertifikat was sagt. Allerdings bezweifle ich, daß es DIR etwas sagt. Wie gesagt – SSL ist kein Bestandteil – wäre aber kein Problem, für SHOP.HBZ-BRANSE.DE ein Zertifikat zu installieren. Der CSR ist fertig, Anbieter ist auch schon ausgeguckt. Und die Zahlung ist jetzt schon sicher.

 Sicher? Ja: PayPal und Überweisung. Also keine Bankdaten… Doch weiter:

Text zum Bild:

Das Ding sollte schon etwas taugen, jedenfalls für nen Onlineshop.

Antwort:

Und? Wo ist hier wieder Dein Problem? Der Text ist Standard, ist geprüft und abmahnsicher. Klar, bei Dir wäre das alles besser… Du schaffst nach wie vor nicht, auf Deiner Seite Deine Adresse richtig zu schreiben. Langsam werde ich stinkig…

 So, und dann kam noch das Hauptbild des Beitrages: 

Mein Kommentar:

Jawohl – Zertifizierung geschafft. Aber vielleicht solltest Du mal darüber nachdenken, zwei Zertifikate zu machen. Für den Fall empfehle ich

1) Zertifizierter Lesen-Könner und
2) Zertifizierter URL-Eingeber.

Das würde Dir immens weiterhelfen. Bevor Du mitredest, solltest Du vielleicht mal nachlesen, worum es bei der Trusted-Shop-Zertifizierung geht. Du kennst sicher nur SSL-Zertifikate, oder? Mal davon abgesehen – wir waren schon erstaunt, daß TS kein SSL voraussetzt. Trotzdem ist das TS-Zertifikat gültig. Oder geht das über Deinen Horizont?

Sicher, das war nicht die feine englische Art. Aber: Einen Hinweis oder ein paar Fragen im Rahmen konstruktiver Kritik hätte ich durchaus begrüßt. Aber nicht so was!

Ich bin ja mal gespannt, ob er mich jetzt aus der Freundesliste schmeißt… Aber ganz ehrlich: Wer selbst kritisiert, sollte auch Kritik abkönnen. Deswegen werde ich ihn auf diesen Beitrag hinweisen. Mal sehen, ob er sich dazu äußert…

Freude bei HBZ: Zertifizierung geschafft!


Barth. Heute um 15:16 Uhr war es endlich soweit: Es grünte! Zwar nicht das berühmte und so oft besungene Grün und erst recht nicht draußen (da sieht es bei läppischen 11° Celsius ohnehin eher sehr nach ungemütlichem und nassem Herbst aus)… Selbst Spaniens Blüten haben reinweg gar nichts damit zu tun, wohl aber die Bits und Bytes in den Tiefen des weltweiten Netzes - genaugenommen die HBZ-Zertifikatsseite bei Trusted Shops. Die ist nämlich relativ neu und kündet seit 15:16 Uhr des heutigen Tages  in schönstem und prachtvollstem Grün davon, daß die HBZ Branse GmbH ab jetzt zertifizierter Zertifikatsinhaber sei! ;-)

Aber mal ernsthaft: Grund zur Freude war bzw ist, daß der HBZ Online-Shop seit vorhin das Trusted-Shops-Gütesiegel tragen darf; er ist ab jetzt also “offiziell vetrauenswürdig” bzw. von der anerkannten Zertifizierungsstelle Trusted Shops als vetrauenswürdig eingestuft worden.

Was bedeutet eine Zertifizierung durch Trusted Shops?

Trusted Shops wird von Verbraucherschützern und staatlichen Stellen ausdrücklich empfohlen, so z.B. durch die Stiftung Warentest oder das Bundesjustizministerium. Durch objektive Prüfkriterien wurde (und wird) sichergestellt, daß Sie als Kunde in unserem Online-Shop keine bösen Überraschungen erleben. Der HBZ-Online-Shop mußte mehr als 100 Qualitätskriterien erfüllen, um das Trusted-Shops-Gütesiegel zu erhalten. Diese Kriterien werden von unabhängigen Verbraucher- und Datenschützern fortlaufend weiterentwickelt und von Wirtschaftsjuristen und IT-Experten überprüft.

Die Qualitätskriterien von Trusted Shops basieren auf nationalen und europäischen Gesetzen, berücksichtigen aktuelle Urteile und Forderungen der Verbraucherschutzverbände. Teilweise gehen sie sogar darüber hinaus. Um zu gewährleisten, daß auch die zertifizierten Shops den jeweils aktuellen Kriterien entsprechen, gilt das Zertifikat jeweils 1 Jahr; danach erfolgt eine erneute Prüfung. So werden z.B. folgende Angaben und Abläufe überprüft:

• Anbieterkennzeichnung
• Datenschutz und Datensicherheit
• Produktbeschreibung, Vertriebs- und Marketingbeschränkungen
• Preistransparenz, Versandkosten und Zusatzkosten
• Lieferinformationen, Verfügbarkeit und Kundenservice
• Zahlungsarten, Zahlungszeitpunkt
• Widerrufs- oder Rückgaberecht und Kaufpreisrückerstattung
• Allgemeine Geschäftsbedingungen
• Vertragsschluß
• E-Mail-Bestätigung usw.

Unabhängig von der Zahlungsart können Sie sich für einen Zeitraum von bis zu 30 Tagen gegen Verlust Ihrer Zahlung im Fall der Nicht-Lieferung oder nach Rückgabe der Ware absichern – und zwar bis zu einem Betrag in Höhe von 2.500,- Euro. Die Kosten dieses Käuferschutzes trägt der HBZ-Online-Shop für Sie!

Nun sollte sich auch der größte Internet-Skeptiker bei uns im Online-Shop sicher fühlen…