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!

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…

BMOA @ Twitter

Barther Metal Open Air
Ab jetzt gibt es alle Neuigkeiten zum Barther Metal Open Air auf über Twitter!

Social Media gibt es sogar in Barth und Umgebung ;-) !!! (Zumindest, wenn es nach uns geht.) Wir haben uns jedenfalls dazu entschlossen, neben der Verbreitung über Facebook die BMOA-News auch über Twitter zu teilen. Um so größer ist die Reichweite. Außerdem können wir so auch mal nach der einen oder anderen Band schnökern, die es auf Twitter massenhaft zu finden gibt.

Also: Ab jetzt halten wir die BMOA-Fans in aller Welt auch mittels Twitter auf dem Laufenden. Mal sehen, was in Zukunft dort alles so gezwitschert wird… ;-)

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!

BMOA-Shop


Neuerdings gehört ja neben dem Met & Gothic Shop auch der BMOA-Shop zu unseren Kunden… An dieser Stelle sei einfach nur mal angemerkt, daß der auf Shopware basierende Online-Shop gute Fortschritte macht. Die Tickets und T-Shirts für das 17. Barther Metal Open Air können bereits dort geordert werden!