Wie man das Theme auf dem neuesten Stand hält und andere tolle Tipps von Guido Michele

[Gabe]

Wie man das Theme auf dem neuesten Stand hält und andere tolle Tipps von unserem Shopify Partner und Entwickler Guido Michele

Im folgenden Thread unterhalte ich mich mit einem unserer Top-Experten und Shopify Partner, Guido Michele, u. a. über wie man das Theme gesund und instand halten kann. 

Ein paar tolle Tipps bzgl. was alles beim Bearbeiten und Aktualisieren des Themes zu beachten ist, von einem unserer Top-Experten und API-Programmierer - Guido Michele!

In diesem Artikel besprechen wir u. a. die folgenden Themen mit Guido:

• Guido’s Bio und wie er Shopify Programmierer wurde.
• Die schönsten Eigenschaften der Plattform.
• Ein paar Limitationen der Plattform.
• Was man beim Updating des Theme beachten muss.
• Wie es mit komplexeren Code-Anpassungen aussieht.
• Was man bei Apps beachten muss, die den Code verändern können.
• Beispiele des Simple Page Template.
• Und ein Schlusswort zu was Guido über Metafelder denkt.

Eine kurze Bio

Der Guido beantwortet schon lange technische Fragen in unserer deutschen und englischen Community seit 2020 und ist auch sehr aktiv in unserer privaten DACH Facebook Gruppe. Er ist für ​​seine Hilfsbereitschaft bekannt und war immer für unsere Händler erreichbar, v.a. während der schwierigen Zeit der Pandemie, als viele von “Bricks & Mortar” zu “Online” pivotierten und nicht wussten was sie erwartete.

Für mich ist Guido auch der Inbegriff des “Digital Nomad”, da er mal aus Deutschland arbeitet, mal aus Spanien, Lanzarote, und viele andere der tollen EU Destinations. Er ist einer, der sich in der “Digital Economy” so richtig auskennt und die Vorteile der neuen Disruptive Technologies ausnutzt, um unseren Merchants am besten unter die Arme zu greifen. Er weiss Online-Verbindungen zwischen Menschen, Unternehmen, Geräten, Daten und Prozessen zu verknüpfen und effektiv auszubeuten und er legt viel Wert darauf, sich ständig in seiner Craft weiterzuentwickeln.

Guido, erzähl uns doch wo du herkommst und wie du zu einem der meistgesuchten Shopify Entwickler wurdest? Wie bist du zu Shopify gekommen?

Durch Zufall. Immer schon von Computern fasziniert, mit 14 verkaufte ich meine ersten selbst entwickelten Programme, ich erinnere mich an ein Programm, welches die Ausgabe der Error Codes, wie z.B. ERROR 78, damals üblich, durch Textausgabe ersetzte, die den Fehler kurz erklärte (mehr zu effektive Tooltips hier), aber auch mein erstes Game, ein Pac-Man Clone. Es gab damals kein Internet, die Programme waren in Computerzeitschriften abgedruckt und man musste den Code selbst abtippen. Bezahlt wurde man pro veröffentlichter Seite. Da habe ich dann nach meinem Abi nicht lange überlegt und mich für den Studiengang Softwaretechnik eingeschrieben. 

Wie war es damals, "Software Engineering” zu studieren?

Der Informatik-Studiengang war damals noch ganz trockene Materie, hauptsächlich Datenverarbeitung mit DOS Maske. Turbo Pascal, Assembler, C  und Basic. Trockene Materie, ich war mehr an Games interessiert, das gab es damals nur in den USA. Alle hatten Montags in der Fachhochschule immer rote übernächtigte Augen, meine jedoch nicht vom Wochenende vorm Monitor, sondern von zu viel Party und Spass mit meinen Freunden. Trotz Talent konnte ich mir nicht vorstellen, dass dies nun für den “Rest meines Lebens” so sein sollte. Ich arbeitete auch neben meinem Studium Stylist-Assistenz für die Max, und kam so zur Mode.

Ah, du hattest auch andere Interessen als nur das Coding? 

Damals passten ich und Coding nicht zusammen. Ich wechselte auf ein Ingenieurstudium im Bereich Textil mit Schwerpunkt Design. Ich hatte Glück, ‘97 stand mein eigenes Label, ‘99 ging es los mit Wholesale. 

Vier Agenturen machten den Vertrieb, und mich zog es dann nach Paris. Ich sah nur eins: erfolgreich, bis zum Burnout, und kein Weg aus dem Ganzen, sprich, kein Offramp. Dann ging alles ganz schnell. Eines meiner Designs wurde von Madonna auf ihrer World Tour verwendet, und die Sales gingen dann prompt durch die Decke. Ich sah dann meine Offramp Opportunity, und nahm mir einen Anwalt, um auszusteigen. Finanziell könnte ich es mir erlauben, ein Jahr nichts zu machen, außer mich um mich zu kümmern. Dann rief mich ein ehemaliger Kunde an, nach dem üblichen, mach doch wieder Mode, klagte er mir sein Leid mit einem Problem in seinem Webshop, Magento. Jetzt müsste er wieder 1 Monat warten, bis was passiert und mindestens 500€ blechen. 

Und dann hast du dein erstes “Blut geschmeckt”?

Seit diesem Job arbeite ich als Developer, fast keine Freizeit und ich habe viel Freude an der Arbeit. Zuerst auf der Magento und der WooCommerce Platform. Dann hörte ich von Shopify, wo Plugins “Apps” heißen, also alleine die Shopify Nomenklatur war faszinierend. Code als Liquid, sprich, Shopify's Programmiersprache - ein flüssiges System, dass sich reibungslos ohne Konflikte integrieren lässt. Ich habe mich direkt in Liquid verliebt.

Was sind deine Lieblingseigenschaften der Plattform und warum?

Shopify entwickelt sich stetig weiter. Das heutige Backend hat so viel mehr Funktionen und Einstellungsmöglichkeiten als wann ich damals zuerst anfing. Es war ein langer, spannender Weg von ohne Sections, zu Sections Everywhere und Store 2.0.

Meine Devise gilt: wenn etwas nicht geht, dann nutzt es nichts, ein totes Pferd zu reiten. Wie oft habe ich von meinen Kunden gehört “das wäre toll, aber das geht ja nicht''. Sicher gibt es Grenzen, auch in Hinsicht auf den Nutzen und die UX. 

Von anderen Plattformen kommend, ist das herausragende für mich mit Shopify, dass alle Bereiche so eng miteinander vernetzt sind. Es ist, im Gegensatz zu anderen Plattformen, ein verknüpftes Ökosystem an Backend und Frontend. Man installiert nicht eine App, um Konflikte mit drei anderen Apps zu bekommen. Alle Systeme reden und funktionieren nahtlos miteinander und das stetige Weiterentwickeln der Plattform ist einfach.

Was sind die größten Limits der Plattform und wie können sie am besten verbessert werden?

Das größte Limit der Plattform ist meiner Meinung nach die Beschränkung auf maximal 100 Varianten. Hat ein Produkt 3 Optionen, oder gibt es ein Produkt in vielen Größen und Farben, ist man schnell über den 100-Limit hinaus. Meinen Kunden aus den Bereichen Schmuck, Schuhen, Bekleidung, Handyzubehör usw. könnte ich mit Code und Kombination von Produkten helfen, dies kommt aber immer mit Nachteilen für SEO, Google, usw. Die Beschränkung auf 100 hat mal Sinn gemacht, Server waren nicht so leistungsstark, und Speicherplatz war teurer. Ich denke, viele wären sogar bereit, etwas mehr zu bezahlen für mehr Varianten. Einen “Premium Plan”, ohne Shopify+.

Shopify's Marketing Strategie ist, erstelle deinen Shop in 2 Wochen gratis, integriere Shopify Payments und fang an zu verkaufen. Das ist toll und einer der großen Selling Points, aber nicht immer der Realität entsprechend. Dem Shopbetreiber werden auch teilweise Programmierungen und Coding Tweaks für das eigene Live-Theme angeboten, die nicht so einfach umsetzbar sind, oder manchmal Legacy, sprich, veraltet. Viele Dinge werden auch als Wissen vorausgesetzt und überspringt und das kann zu Frust beim Klienten führen.

Checkout-Anpassungen und Zugang zum checkout.liquid sind auch ein oft gewünschtes Thema. Ich stehe dem eher skeptisch gegenüber, wenn man sieht, was auf so mancher Startseite der Shops alles los ist, möchte man dies im Checkout vermeiden. Aber das das Ganze zum neuen Checkout mit Scalability und Extensibility sich jetzt bewegt, ist eine spannende Sache. Viele Klienten wollen Apps viel lieber über eine neue Checkout-Extension einbinden, nur hat man in der Extension nicht immer Zugriff auf alle verfügbaren Optionen, wie z. B. diverse Shipping Features. Man möchte beispielsweise unterschiedliche Lieferdaten im Versandschritt oder in der Bestätigung anzeigen, abhängig von der vom Kunden gewählten Shipping Option. Das wird derzeit nicht von der Checkout Extensibility API bereitgestellt und man muss über dem checkout.liquid an diese Information stattdessen kommen.

Shopify Functions ist gerade angekommen!

Wie oft möchte man als Shopinhaber den eigenen Kunden eine bessere Checkout Experience anbieten, wie z. B. die Zahlungsmethoden und/oder die Versandtarife in einer bestimmten senkrechten Reihenfolge anzeigen je nach einer gewissen Logik, wie Herkunftsland des User?

Solche Epic Wants unserer Händler sind unter den meist gefragten Features, die bis jetzt nur den Besitzer von Plus Shops vorbehalten waren, wo man komplexe Programmierung und Logik im checkout.liquid implementieren konnte. Auch der Zugang zum checkout.liquid naht für Plus Shops dem Ende mit dem Beginn des neuen Shopify Functions und des Checkout UI Extensions. Siehe auch unsere Blog Artikel hier:

• Shopify Functions: The New Way to Extend and Customize ...
• Build Custom Commerce Experiences with Shopify Functions

Ein Thema, das du oft in den Foren angesprochen hast, ist das Updating der Themes. Was muss man da beachten, v. a. wenn man Code Änderungen im Theme bereits durchgeführt hat?

Best Practices vergessen?

Ich übernehme ja auch oft Kunden, die sich ihre Shops z.B. von einer anderen Agentur erstellt haben lassen. Was man da an schlechter Arbeit sieht, ist oft enttäuschend und gruselig. Da wird beispielsweise 'inkl MwSt, zzgl Versand' in das Produkt Liquid ge-hardcoded, als gäbe es keine Local Files. 

Code Änderungen im Original-File des Templates/Section werden auch oft vorgenommen, ohne eine Kopie des Original-Codes zu erstellen oder als Backup zu speichern. Anstatt im Live Theme den Code zu ändern erstellt man zuerst eine Testumgebung wo man im Sand rumbuddeln und basteln kann. Code Änderungen werden auch nicht als solche mit “Comments” ausreichend gekennzeichnet. Der CSS wird dabei oft direkt im Original CSS überschrieben und der Original Code ist somit ohne Backup für immer und ewig pfusch. 

In dem Moment, wenn ein Theme dupliziert wird, verliert das Duplikat ja alle History, und die files werden zu Originalen, was die Wichtigkeit des Backups betont. Hier muss man dann eine frische Theme-Kopie in die Library laden als Original Code. 

Custom Code und die Updates

Wird nun ein Theme aktualisiert, wird jeglicher Custom Code überschrieben. Der Hinweis in der Theme-Bibliothek, “Ein Update steht zur Verfügung, Änderungen werden in das Update übernommen” wird hier auch oft falsch verstanden. Es werden nur die Änderungen übernommen, die am Theme im Theme Editor gemacht wurden und nicht die, die im Code gemacht wurden. Also nur Schriften, Farben, Sections, Texte, Bilder etc. Und Achtung, wir reden hier von einem Update und nicht von einem Theme-Wechsel!

Aufgepasst, der neue CSS-Code Editor ist jetzt da!

Jetzt kann man CSS Code direkt im Theme Editor ausprobieren ohne die Gefahr zu begehen, das Theme Code selber zu brechen oder das Theme aus den Updates auszuschließen. Möchtest du beispielsweise einen roten "Sale" Menüpunkt zu deiner Navigation hinzufügen oder das Padding um gewisse Abschnitte oder Blöcke ändern, dann einfach einen css Code zum Editor hinzufügen entweder auf Gesamt-Shop- oder auf Block-Ebene und schauen ob es klappt!

ODER

• Siehe einen Beispiel-Leitfaden wo das erfolgreich gemacht und der CSS Code auch erklärt wurde hier!

Wie sollte man also am besten vorgehen, Guido?

Custom liquid sections und 2.0 Blöcke machen einem es jetzt viel einfacher

Wenn möglich, immer die Code-Erweiterung im Theme Editor durchführen und nicht im Code, abgesehen davon, dass eigene Anpassungen des Theme Codes zu schlechteren Ladezeiten führen können. Seit Store 2.0 haben fast alle Themes custom liquid sections und Blöcke an Bord, die es einem viel leichter machen, das zu erreichen, was man braucht. Manchmal werden diese auch als Custom HTML/Liquid oder Advanced Content bzw. “Benutzerdefiniertes Liquid'' bezeichnet. Hat ein Theme diese Section nicht, so kann man diese einfach erzeugen.

Hier ein Minimalbeispiel:

<section>
{%- if section.settings.liquid != blank -%}
  <div class="liquid">
    {{- section.settings.liquid -}}
  </div>
{%- endif -%}
</section>

{% schema %}
{
  "name": "Custom Liquid",
  "class": "shopify-section--custom-liquid",
  "settings": [
    {
      "type": "liquid",
      "id": "liquid",
      "label": "Liquid"
    }
  ],
  "presets": [
    {
      "name": "Custom Liquid"
    }
  ]
}
{% endschema %}

In das Textfeld eines solchen Blocks/Section kann man HTML, CSS, und auch JavaScript einfügen, welches dann an der Position desselben ausgeführt wird. Für viele einfache, häufige Wünsche ist das völlig ausreichend. Der Vorteil ist, dass dieser Code dann auch bei einem Theme-Update kopiert wird und nicht verloren geht.

Ein Beispiel ist auch das Einbauen eines MP4 Video. Und die Payment Icons unterhalb des ATC Buttons. Ein Liquid Block unter dem ATC Button mit Content macht genau das und der Clou: auch noch nach einem Update:

  {%- if shop.enabled_payment_types.size > 0 -%}
          <div style=”display:flex”>
              {% for type in shop.enabled_payment_types %}
                {{ type | payment_type_svg_tag }}
              {% endfor %}
           </div>
        {%- endif -%}

Wäre das im Code selber verankert, wäre dies bei einem Update futsch.

Wie sieht es bei komplexeren oder anspruchsvolleren Code-Anpassungen aus? Reichen diese Sections?

Das geht natürlich nicht bei anspruchsvollen Programmierungen. Hier muss oft der Code selbst angepasst werden im Sinne der Best Coding Practices. Solche Anpassungen im Liquid File selbst sollten so gekennzeichnet und kommentiert werden, dass diese leicht wiederzufinden sind, und ihre Position erklärt wird. 

Hierzu eignet sich die {* comment *} Funktion von Liquid oder das HTML <!-- text --> Tag. Für den Chrome Browser gibt es Extensions, die nach einem bestimmten Suchwort im Theme-Code suchen (Shopify Theme File Search oder Shopify theme edit & liquid file search tool). Benutzt man z.B. immer im Kommentar das Wort "Custom Code'', werden bei Eingabe dieses Suchwortes alle Files markiert, die dieses Wort enthalten.

Wenn ich mein Theme nun upgedatet habe, Farben, Schrift/Fonts, Bilder, Sections etc. korrekt übernommen wurden, suche ich nach 'custom-code' und bekomme alle Files angezeigt die verändert wurden. Nun öffne ich 2 Fenster alt und neu und kopiere die markierten Bereiche an die gleiche Position im neuen Update. Man kann auch das www.diffchecker.com Tool verwenden, um die zwei Code-Versionen miteinander zu vergleichen.

Bei einem Update von einem Vintage zu 2.0 Theme hat sich die Struktur in vielen Files erheblich geändert, besonders im Produkt und Collection Liquid, da kann es durchaus schwierig werden. Und CSS sollte niemals überschrieben werden. Entweder man erstellt komplett ein eigenes custom.css File und nutzt dies für Änderungen von CSS Klassen, oder bei Themes wie z. B. Dawn, die das CSS aufgesplittet haben, fügt man am Ende ein Custom CSS hinzu.

Anpassungen im JavaScript sollten, wenn möglich, nicht im Script selbst geschehen, sondern möglichst nur im custom.js. Moderne Themes und Apps erstellen Custom Events bei wichtigen Ereignissen, die dann custom javascript code auslösen können, den man im custom.js gespeichert hat:

document.body.addEventListener('VARIANT_CHANGED', function(event) {...})

Und wie sieht es mit Apps aus, die das Liquid verändern und somit ein 2.0 Theme aus den Updates ausschließen können?

Die neuen oder erneuerten Apps vermeiden dies so gut es geht und werden über den Theme Editor installiert und deinstalliert.  b des Themes und ist nach einem Theme-Update verschwunden, sollte eine erneute Installation der App dies wieder korrigieren. Ein good practice ist das aber nicht und die App-Entwickler sollten bei Problemen immer kontaktiert werden, so dass diese die Code Probleme beheben, dass die App verursacht hat.

Wie schon oben erwähnt, bieten immer mehr Apps verschiedene Events und Methoden an, so dass man auch dort einiges anpassen kann. Als Beispiel erzeugt die App Slidecart ein Event, wenn ein Produkt in den Warenkorb gelegt wurde, wobei item_ID und die Anzahl der Produkte übergeben wird, die ich dann in einer Function benutzen kann:

window.SLIDECART_ADD_TO_CART = function({ id, quantity }) {console.log(“Produkt: “ + id + “Anzahl: “ + quantity) }

oder 

window.SLIDECART_OPEN() und window.SLIDECART_CLOSE()

(-> öffnet und schließt den Cart Drawer).

Man kann übrigens aus jedem Theme ein Online Store 2.0 Theme machen, auch wenn es für viele Themes keine Updates geben wird (Debut, Brooklyn usw.) Der Unterschied zwischen Vintage und 2.0 Theme liegt hauptsächlich im Template Folder. Der Filetyp hat sich hier geändert von .liquid (früher) zu .json (heute). Das heißt aber nicht, dass es den einen oder anderen Filetyp exklusiv nur für das jeweilige Theme gibt.

Habe ich ein Vintage Theme, so kann ich auch in diesem Theme ein Template File in .json erzeugen, und für dieses Template alle Vorzüge von 2.0 nutzen, wie zum Beispiel “sections everywhere”. 

Wie ist es mit dem Beispiel des Simple Page Templates?

Als erstes machen wir IMMER eine Kopie des Themes, in der wir uns austoben können.

Zunächst erzeugt man eine neue Section im “Section Folder”. Nach der neuen Nomenklatur würde man diese “main-page” nennen.

Die Section wird bereits mit dem {% schema %} erstellt. Über dieses fügen wir nun den Code des Template-Files “page.liquid” aus dem Template-Folder ein und speichern es.

Nun erzeugen wir im Template Folder ein neues Template mit dem Namen “page-json” im Format .json (der Zusatz im Namen dient nur zur besseren Unterscheidung später). 

In dieses JSON File müssen wir den Aufbau des Templates kopieren. Zunächst besteht dieses nur aus der eigentlichen Seite, diese haben wir main-page genannt:

{
  "sections": {
    "main": {
      "type": "main-page",
      "settings": {
      }
    }
  },
  "order": [
    "main"
  ]
}

Von nun an steht im Page Editor ein neues Page Template mit Namen “page-json” zur Verfügung, und dies weisen wir einer Seite zu.

Nun gehen wir in den Theme-Editor und rufen die Seite welches das Template page-json benutzt auf, oder wählen einfach aus dem Dropdown im Theme Editor das page-json Template. Du siehst im Dropdown, dass Du nun die neue Möglichkeit hast, weitere Page Templates zu erstellen. Es stehen Dir in diesem Page Template und allen weitern Page Templates, die auf Basis dieses JSON Templates erzeugt werden, alle Sections zur Verfügung, die Du sonst nur auf der Startseite benutzen konntest. Analog geht dies auch mit allen anderen Liquid Templates.

Um zum Beispiel Landing Pages zu erzeugen, würde man im Theme Editor ein weiteres Page Template erzeugen auf Basis “page-json” und Namen z. B. “landing-page”.

Im Page Editor muss man dann dieses Template einer Seite zuordnen. Der Inhalt kann aber aus den Abschnitten kommen, die man im Theme Editor für dieses Template erstellt hat.

Wie sieht es mit Metafelder aus? Arbeitest du gerne mit Metafelder und was sind die Vorteile?

Die Einführung, oder besser gesagt die Unterstützung der Metafelder, denn Metafelder gibt es schon lange, ist ein großer Fortschritt für Shopify. Noch nicht 100% vollzogen, so fehlt zum Beispiel die Möglichkeit, die Metafelder mit den Produktdaten zusammen zu exportieren (ohne App). 

Auch gibt es hier und da ein paar Macken, so kann zum Beispiel das Metafeld als einzeiliger Text HTML und gestylten Rich Text ausweisen, oder ein .svg oder Code aufnehmen. Meiner Meinung nach wird das dadurch erheblich nützlicher als der mehrzeilige Metafeld-Typ. Das verursacht aber durch das kleine Textfeld keine vernünftige Vorschau, und im Theme Editor hat man damit manchmal Probleme, seinen Inhalt überhaupt in dem Textfeld darzustellen. 

Eine große Hürde beim Update von einem Legacy Theme auf ein neues 2.0 Theme ist, dass die alte Tag Filterung von den neuen 2.0 Themes nicht mehr unterstützt wird und nun durch die Storefront Filterung ersetzt wurde. Die Storefront Filterung bringt viele Vorteile, wie z.B. die Möglichkeit auf Varianten Ebene zu filtern, als auch das Filter out of the box zu Verfügung stehen (Produkttyp, Produktoptionen, Preis etc.). Auf den ersten Blick ist die Umstellung gerade für Shops, die mit vielen Tags Produkte gefiltert haben, eine Mammut Herausforderung. Man kann hier gut folgendermaßen vorgehen: 

1. In den Einstellungen erstellt man ein neues Produkt Metafield mit dem Namen des Filters welcher später im Shop als Oberbegriff über den Filtern erscheinen soll. In unserem Beispiel “Material”, mit Inhaltsart  “Einzeilger Text” - “Werteliste”. 
2. In der Produktübersicht filtert man die Produkte nach einem der tag, der früher als Filter gedient hat, in unserem Beispiel “Material_Silber” und öffnet das Ergebnis der gefilterten Produkte im Bulk Editor. 
3. Im Bulk Editor lasse ich mir die Zeile Metafeld Material, welches wir zuvor erstellt haben, anzeigen und fülle die Felder mit “Silber”. 

Schritt 2 und 3 wiederhole ich mit allen alten Tag Filtern, die den neuen Filter Material zugehören, in unserem Beispiel z.B. Gold, Kupfer, Platin etc.

Danach wird analog zu Schritt 1 die nächste Filtergruppe erstellt und analog zu 2 und 3 mit Inhalten gefüllt. Nach und nach werden so alle Tags durch Metafelder ersetzt. Die tags werden damit zum größten Teil überflüssig, man sollte diese aber mit Vorsicht löschen, da manche eventuell auch für das Erstellen von Automatik Kategorien dienen.  

Die Möglichkeit eines Im- und Export von Metafelder mit den Produktdaten als CSV würde diesen Prozess erheblich schneller und einfacher machen. 

So wie ich Shopify kenne, wird das bald möglich sein, Shopify schläft ja nicht, also watch this space!

Vielen Dank für das Interview, Guido!