Die neue Website geht an den Start!


Heute ist es nun endlich soweit: Unsere neue Website ist online. Sie verfügt jetzt – ähnlich einem Blog bzw. Weblog – über ein News-Archiv, über abonnierbare Feeds und über diverse Möglichkeiten zum „Sharing”. Inhalte können so einfacher auf Social-Media-Plattformen wie z.B. Facebook „geteilt” werden. An den Inhalten hat sich natürlich bis auf das neu implementierte News-System nicht allzu viel geändert – die Geschichte oder das Leitbild von HBZ Branse können wir ja kaum wegen einer neuen Homepage umschreiben… ;-) Neu sind aber die Branchen-News und die Mitteilungen aus dem Hause EUROBAUSTOFF, die sogenannte Sitemap und die Suche.

Neue Website der HBZ Branse GmbH

An dieser Stelle möchten wir uns noch mal für die jahrelange gute Zusammenarbeit mit CMidesign bedanken. Inhaber Christian Mähl kreierte damals das Layout der bisherigen Homepage, auf welchem auch die neue Website basiert. Durch die jahrelange Nutzung ist dieses Design ja fast schon Bestandteil des „Corporate Design” und somit der „Corporate Identity” geworden. Das Design wurde lediglich mit einem 3-Spalten-Layout etwas aufgefrischt.

In Kürze ist die Website auch mit Mobilgeräten wie Smartphones und Pads in einer angepaßten Version abrufbar.

Wir wünschen Ihnen jedenfalls viel Spaß beim Surfen. Etwaiges Feedback können Sie uns gern zukommen lassen – z.B. über das Kontaktformular oder auch über Facebook. Und falls Sie irgendwo einen Fehler bemerken, würden wir uns freuen, wenn Sie uns diesen mitteilen würden. Vielen Dank!

Nur noch Bekloppte…


Kuhl! ;-)

Habe gerade gesehen, daß ich auf Linkedin ein Job-Angebot von Apple bekommen habe – für den deutschsprachigen Support im CallCenter in Cork… (Tja, so ist das eben, wenn man überall präsent ist – “Social” Media sei dank…)

O-Ton: “Greetings from Apple’s European headquarters in Cork, Ireland…”

Mit Reisekostenerstattung, Übernahme der Krankenversicherung, Apple-Produkt-Rabatt usw…

Ich fühle mich geehrt… :-)

Aber wenn ihr so viel Ahnung von IT und TK habt, dann richtet eine webbasierte Timetable für Mitarbeiter-Verfügbarkeitszeiten ein – und macht in meiner aktiven Phase ‘ne Rufweiterleitung in der Zeit HIERHER. Was soll ich in Irland? Bin ich Ir(r)e?

Und Mauzi muß 4 Wochen in Quarantäne oder was? Seid Ihr bekloppt?

So viel Kohle habt Ihr gar nicht, um mir das Verlassen meiner Heimat schmackhaft zu machen… Da müßten schon die Russen kommen und sich aufführen wie 45 ff…

Beknackte Kosmopoliten… Jeder sollte da leben und arbeiten, wo er hingehört.

PS: Und wenn ich als Deutscher zu doof bin, um mit ausländischen Produkten umzugehen, dann setze ich mich entweder auf den Hosenboden und lerne – oder ich lasse es bleiben und kaufe deutsche Produkte. Aber ich rufe bestimmt keinen deutschsprachigen Support im Ausland an… Mir reicht schon der Russen-Akzent-Support von 1&1 – hier in Deutschland!

Daß SIEMENS keine Handys mehr herstellt, ist nicht zuletzt dem Käuferverhalten geschuldet.  Aber da ja alle (damals) Nokia, Motorola (und heute) Samsung, Apple & Co brauch(t)en – seht zu, wie Ihr mit der Scheiße klarkommt…

Und bei Problemen GEHT zu Deutschen und bezahlt deutsche Preise.
Gewöhnt Euch daran – oder überdenkt Euer Konsumverhalten!

Tausend Dank für die Session!


Genau. Ich hatte ja auch nix weiter vor… ;-)
Genau SO habe ich mir den heutigen Abend vorgestellt !!!
Die nächsten Termine sind ja erst fürs nächste Jahr geplant… :-(

Ein weiteres Wurst-Käse-Szenario *  wurde wahr: Man rackt und schuftet in der Scheiße eines Landgerichts **  – oder wie das heißt – und dann passiert etwas von allein, was sonst nicht mal im Eiter des Geschlechts *** passieren sollte oder dürfte: Von ganz allein geht was kaputt !!! Diese millionenfach von Stümpern und Stümperinnen weltweit mißbrauchte Ausrede gibt es als traurige Wahrheit wohl doch in freier Wildbahn…

Die Chronologie des Schreckens:
Gestern – im Laufe des Tages: Blick auf den neuen Metshop – und auf den BMOA-Shop. Beides als Shopware-Shops auf 1&1 aufgesetzt – beidet löppt.

Dann: Nachts durchgemacht für ein anderes Projekt – Projekt X. Tagsüber geknüppelt. Heute abend hier Versionsabgleich in Sachen Projekt X. Internetzprobs. (Grrrrrrrmblfx !!!!!) Reboot der Fritte; ein Rechner ok, der andere nok. Trotz /flushdns, LAN-Verbindungsreparatur etc. Das übliche Gedöns… Als wenn mich gerade das BKA am Wickel hätte, nur weil ich die böse SAGA liken wollte… ;-)

Alles wie zähflüssiger Schleim mit einem Elefanten auf der Leitung. Windoof halt.

Also Neustart.

Google (oder Firefox…) nervt mal wieder mit ungültigen Zertifikaten… Ich öffne einen neuen FF-Tab mit der “klasssischen” Übersicht über die meistbesuchten Seiten der letzten Zeit – klicke auf den BMOA-Shop… – und es haut mich fast vom Sitz!

Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.

Wenn ich Murks in die .htaccess kritzle, ist das ja normal… Aber so? Ohne mein Zutun?

Durch wessen Zutun denn dann ???

Ich auf den Server, Modifikationsdatum beäugt… Alles roger. Seit meiner letzten Aktion hat niemand drin rumgepfuscht…. Puuuuuuuuuuuuuuuuuuuuh…

Mal davon ausgehend, daß das so auch stimmt (jemand, der einen ganzen Server unter seine Kontrolle bringt, kann auch das Systemdatum ändern… Und der nächste Dateizugriff bekommt dann eben ohne großen Aufwand einen gefälschten Zeitstempel… – insofern muß man nicht mal wissen, ob es Wege gibt, “nur einfach mal so” die mtime zu manipulieren… Oder sich Gedanken darüber machen…. Die letzte Attacke, die ich mal irgendwo sah, war jedenfalls schööööööööön am Datei-Datum erkennbar… Schönes Brute Force per FTP – und dann Feindscript rein in die Datei… Wie auf dem Präsentierteller: Alles Projektdateien von 2009 – und ein paar ganz böööööööööööööse gemoddete  Dateien von 2014… Uppps…… ;-)

Aber ob das immer so leicht herauszufinden ist? Ich mache mir darüber mal lieber keine Gedanken…

Die Chronologie des Erkenntnis:
Ich gab mich jedenfalls zufrieden und schob die Schuld flugs auf 1&1: Irgendeine Einstellung, die gestern noch funzte, funzt heute eben nicht mehr – weil die Jungs von “Summe = 2″ mal wieder irgendwas – vielleicht sogar auch nur temporär -  “verschlimmbessert” haben… Wäre schließlich nicht das erste Mal – und gerade im Zusammenhang mit Shopware und den leidigen mod_rewrite- und GZip/deflate-Probs wäre das denkbar…)

Nachdem ich dann also Zeile für Zeile die .htaccess getestet habe, stellte sich raus, daß der folgende Eintrag gestern noch funktionierte – und heute eben einfach nicht mehr:

<ifModule mod_deflate.c>
<filesMatch ……………………………
php_value output_handler ob_gzhandler
……………………………
</filesMatch>
</ifModule>

Seitdem der elende rote Störenfried :-) mittels # auskommentiert wurde, erhalten Besucher jedenfalls KEINEN 500er mehr…

Einfach mal testen, ob diese Einstellung bei Euch existiert – falls 1&1-gehostete Seiten unvermittelt bzw. unverhofft wie von Geisterhand rumbocken… Zumindest vorübergehend kann man ja wohl eher auf die Komprimierung seiner Seite als auf deren Erreichbarkeit verzichten…

PS:
Es soll ja Leute geben, die nicht auf linguistische Spitzfindigkeiten stehen… Von daher:

*     – “WorstCase Scenario”
**    – “im Schweiße seines Angesichts”
***  – “im Eifer des Gefechts”

;-)

Mir rettet aber ein solch schwachmatöser Nonsens aka Verbal-Output den Tag – wenn ich ich schon nicht schlafen darf, weil ich mal wieder nach derartigem Quatsch suchen muß… Gut – einerseits ist man ja froh, daß nichts Schlimme(re)s passiert ist… Andererseits ist es aber auch extrem “unspannend”, wenn man dann SOLCHE Dinge wie  “1&1 hat am Server geschraubt…” ermittelt…

*Gähn*

Gute Nacht!

PPS: Dieser eben bemängelte “Quatsch” ist mir aber trotzdem 100mal lieber, als wenn ich mich mit Angriffen von nervenden Script-Kiddies oder gar gefährlichen Profis auseinandersetzen müßte… Dann bleib’ ich eher doch lieber sogar noch ‘ne weitere Nacht wach… ;-)

In Anbetracht dessen kommt dann tatsächlich doch noch – selbst um diese Uhrzeit, für mich immerhin irgendwas von 48 Uhr aufwärts… – so was wie Freude auf, daß ich das Problem eingrenzen konnte…

PPPS:  Trotz allem:
Viereckiger Kopf.
Sprachstörungen…
Magelhafte Feinmotorik….
Der rote Bulle hilft seit gestern nicht mehr – verursacht höchstens Durchfall.
Coffeinum hilft seit vorhin nur noch, wenn man vier “große” zermahlt und sich zusammen mit Glukose im Verhältnis 1:1 ‘ne Line zieht. Oder eben C. kauen – ohne Flüssigkeit.
Altöl zu trinken mag vielleicht auch noch gehen… Oder Bier und Kaffee im Wechsel  im Verhältnis 1:1….
Blutdruck: Jedenfalls normale 180 : 140…
Zucker: 6,5… ;-)
Jetzt eine meiner verordneten Ramipril – und ich erkranke an spontaner Hyper-Narkolepsie – das einzige, was mich noch wach- und vom Umfallen abhält, ist mein Blutdruck!…
Obwohl – im Moment wäre Umfallen auch vollkommen ok… :-)

Gute Na… ;-)

Wenn was ist – weckt mich!
Bzw. VERSUCHT ES! :-)
Insofern: Bis zur Reinkarnation! ;-)  ;-) ;-) ;-) ;-)
AMEN!

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!

Facebook-Apps – Part 3


Jetzt wird es aber wirklich so richtig albern: Eine neue unendliche Geschichte nimmt scheinbar ihren Lauf…

Seit gefühlten 100 Jahren funzen unsere Facebook-”Apps” – es sei denn, sie funktionieren gerade einmal nicht… – z.B. wegen solcher Geschichten

Hm – der “Bug” wurde fix gefixt… ;-)
Soweit, so gut…

Sollte man meinen!

Denn nun – gerade in einer Phase, in der ich temporär dem App-Entwicklungs-Wahn* verfallen bin – haperte es auf einmal beim Erstellen neuer “Apps” fürs Fratzenbuch. Nach dem Zusenden einer Ausweiskopie, die mich von robotigen Bots abgrenzt und mich als lebendige humanoide Zellkultur ausweist und outen soll, erwartete ich dummerweise so etwas wie eine Antwort.

Nach vier Stunden “plingte” und “ploppte” es in meinem Nachrichten-Bereich. Mir keiner Schuld bewußt beäugte ich voller Vorfreude die “Antwort” – und es verschlug mir fast die Sprache:

Screenshot FB-App

Textbausteine waren gestern. Heutzutage nutzt man wohl das Tool “Phrasengenerator v1.0 beta” der “Basta! IT Solutions Inc.”

Endgültig? Geschlossen?

Man macht sich die Sache bei FB ja so richtig einfach. Ein Art Verwarnung, ein Hinweis, eine temporäre Sperrung der App oder dergleichen wären wohl wesentlich sinnvoller und hilfreicher gewesen. Vor allem würde mich bösen Menschen mal interessieren, gegen welchen Punkt der Richtlinien ich verstoßen habe bzw. welche “SCHÄDEN” ich verursacht haben soll! Lächerlich!

Natürlich habe ich erst einmal recherchiert – schließlich wäre ich gern eine passende Antwort in Richtung FB-”Support” losgeworden. Allerdings solllte ich dann aber auch im Recht bzw. unschuldig sein…

Nun ja… *schäm*

Vielleicht habe ich wirklich einen Punkt in den Richtlinien überlesen (wie z.B. Punkt 4.8 ‘Entwickle keine App, deren Hauptzweck es ist, Nutzer von Facebook wegzuleiten.’)  In schönstem säuselnden Amerikanesisch wird einem erklärt, was man nicht darf.

Aha! Allerdings ist mir das wirklich neu. Gab es diese Bestimmung auch schon, als wir unsere “Apps” entwickelt haben? In einer Ära vor Äonen, als es lediglich darum ging, SEITENREITER  bzw. TABS zu erstellen? Weder habe ich einen Review angefordert, noch einen Vertrieb dieser “Apps” beabsichtigt. Sie sollten lediglich die Navigation um einen Homepage-, Blog-, RSS-Button u.ä. erweitern.

Na ja, vielleicht fehlt ja auch noch die Datenschutzrichtlinie für die Applikation (lt. Policy nötig, in der App-Verwaltung aber kein Pflichtfeld), die mir das Besuchen einer Homepage, eines Blogs, eines Shops oder das Aufrufen eines Feeds ermöglicht.

Wahrscheinlich muß erst ein Fenster aufpoppen, in dem das User-Foto neben dem App-Icon zu sehen ist. Darunter steht dann solche Sülze wie

Jetzt surfen

Durch das Anklicken von „Jetzt surfen“ erhält diese App

Deine allgemeinen Informationen.

Indem Du fortfährst, stimmst Du den Datenschutzrichtlinien von EiTiCo zu.

Diese App darf nicht in Deinem Namen posten.
Nicht gepostete Beiträge kann niemand sehen.

[ Blockieren ]     [ Problem melden ]

Auch wenn es Dein Nutzererlebnis ungemein schmälern wirdt – aber
nun kannst Du Facebook verlassen und die gewünschte Seite aufrufen.

Damit Dir das nicht ungewollt passiert und wir Dich in Zukunft vor Dir selbst
schützen wollen, bauen wir an dieser Stelle demnächst ein Captcha ein!

[ Letzte Chance: Blockieren ]     [ Letzte Chance: Problem melden ]

 [ Allerletzte Chance: Wirklich nicht? ]

Sorry – aber “idiotisch” ist wirklich alles, was mir dazu einfällt. Man kann es manchmal wirklich übertreiben!

Und das Allerbeste: Scheinbar habe ich jetzt zu allem Überfluß auch noch eine Like-Sperre bekommen – sprich: Mit dem Drücken des “Gefällt-mir”-Buttons ist es (erst einmal?) Essig. Irgendwie haben die mich gar nicht lieb… :-)


* Zum Thema Entwicklungswahn – siehe oben:

Screenshot


Der Rundumschlag: Frisches Aussehen für die App-Icons… Jedoch: Ist das legendäre “f” etwa eine Urheber- oder Markenrechtsverletzung? Wenn ja, dann können sich wohl Millionen Anbieter kostenloser Icon-Sets warm anziehen…

PS: Gut gemachte Icon-Sets gibt es z.B. hier oder hier


Das große Fressen…


… ist ja ein berühmter Film. Ok – etwas Hunger hätte ich theoretisch ja auch – gefräßig, wie ich üblicherweise nun mal bin. Praktisch ist mir der Appetit allerdings irgendwie vergangen, denn mir ist eher nach dem “großen Heulen” zumute. Da hat man mal wieder eine neue Site in den Händen, will sie hier und da (bei wichtigen,  SEO-relevanten – und auch bei einigen, eher unwichtigen) Tool- und Projekt-Seiten testen oder/und eintragen…. Ist ja eigentlich auch egal – REICHWEITE ist das, was zählt… (Irgendwann befassen wir uns in dem Zusammenhang auch bestimmt mal mit dem Sichtbarkeitsindex bei Sistrix).

Ist ja alles gut und schön – allerdings müßten die Tools auch funzen! Sogar die Billig-Tools!

Die Loser des Monats:
__________________
Der Meta-Doctor ist tot und hat den angebotenen MetaCheck gleich mit in den Hades gerissen. Jegliche Tests enden nur noch mit einem “404 Not Found” – allerdings nicht einfach so trivial, wie man annehmen mag… Nein! Erst nach einer CLIENT-SEITIGEN Weiterleitung auf die nicht existente Seite! Das Projekt Webutation.net verabschiedet sich beim Test eines URLs permanent ins Nirvana – und Webseitenbewertung.com ist auch keinen Deut besser: Seit Tagen hängt sich die Seite bei der Analyse eines Webprojekts mind. ebenso schön dauerhaft auf… Ergo: Nix geht. Toll!

Aber es gibt auch einen Lichtblick am Horizont: OneProSEO – unserer Meinung nach knallharfte Konkurrenz zu WooRank !!!

Facebook-Apps – Part 2


Natürlich trifft das App-Problem auch auf alle anderen FB-Seiten zu, die wir so unter unseren Fittichen haben – angefangen bei den eigenen Projekten Fätt-Boys, EiTiCo, DiSePo, TRISEPO… bis hin zur Barther Freilichtbühne

Screenshot Redirection-Erkennung

Das Social-Media-Netzwerk Facebook bemängelt bei Apps neuerdings serverseitige Umleitungen.

Da wir das Problem bekanntlich bereits identifiziert haben, steht einem Bugfix in den nächsten Tagen nicht im Wege. Bei der HBZ Branse GmbH war es ja auch in ein paar Minuten erledigt…

PS: Wir haben keine Ahnung, wie lange das schon so buggy war… So wie im PS zum Artikel “Bugfix” bereits angemerkt: Man darf uns auch gern bezüglich solcher Sachen kontaktieren!