Skip to content

Latest commit

 

History

History
468 lines (388 loc) · 21.1 KB

camp-2024.md

File metadata and controls

468 lines (388 loc) · 21.1 KB

Contao Camp 2024

Info:

Das Camp fand in Essen am 20. und 21.04.2024 im Unperfekthaus statt. Wir hatten etwa 50 Teilnehmer.

https://2024.camp.contao.org

Gruppenbild 2024

Sessions:

Es folgt eine Auflistung der Sessions und deren Themen. Die Namen geben den „Moderator“ der Session wieder, d. h. derjenige der entweder die Session vorgeschlagen oder sich bereit erklärt hat, zu dem Thema was zu sagen/machen.

Samstag, 20.04.2024

Plan 1

Twig [Jerome Wein]

  • wie PHP in Twig migrieren
  • Twig Filter anlegen, wo und wie
  • eigene Twig Templates anlegen
  • Twig Ordnerstruktur
  • benötigte Blöcke herausfinden (GitHub/vendor)
  • Bugfixing & Debug-Mode
  • Idee für Referenz oder Verlinkung bei Generierung von neuem Template, als Link zu GitHub oder vielleicht sogar mit so einer Art Preview-Mode
  • Phpstorm ai PHP zu Twig

Barrierefreiheit (FE) [Joachim Nickel]

Versionsverwaltung [Jan Friebe]

  • Wie gehe ich besten mit meiner Code-Versionierung um, damit ich später auch noch etwas wiederfinde?
  • siehe Präsentationsfolien github-repo oder hier

Barrierefreiheitsstärkungsgesetz [Benedict Massolle, Joachim Nickel]

Updates [Alex Wuttke]

Modernes CSS – jetzt nutzen ohne Seiteneffekte zu produzieren [Janosch Oltmanns]

Diese gewünschte Session war eine Wiederholung des Vortrags von der Contao Konferenz 2023. Die Folien sind bereits auf der Konferenz-Website verfügbar.

Inhaltlich wurden die folgenden Punkte berücksichtigt:

  • Modernes CSS (was ist das eigentlich)
  • Graceful Degradation
  • Progressive Enhancement
  • Graded Browser Support
  • Interop
  • Anwendungsbeispiele

Contao.Contact [Stefan Lindecke]

  • Dienst contao.contact vorgestellt und Intention am Beispiel lindesbs.contao.contact erklärt.
  • Bundle ist frei verfügbar
  • Einbindung der VCF und QRCode Generierung über weiteres Paket vorgesehen (https://github.com/lindesbs/MemberQRCode); dieses wird noch erweitert durch ContentElemenete/Module für die Einzel und Mehrfachgenerierung von VCF/QRCode

Matomo [Joachim Nickel]

  • Vortrag von Joachim in "Kurzdurchlauf"
  • "Fünfzig Prozent des Werbebudgets sind raus geworfenes Geld" (Henry Ford)
  • Wie ist Werbung messbar? Mit Zeitung, Radio, Fernseher - ist das nicht machbar... => Gießkannenprinzip.
  • Kanäle: Anzeigen/Ads, E-Mails/Newsletter, Webseite?
  • Kosten für: Inhalte, Anzeigenplätze
  • Verbindung zwischen Werbekosten zu Käufen per Analytics - wie gut ist Analytics?
  • Analytics ist so gut, wie man es konfiguriert - die Interaktionen müssen passend gemessen werden
  • Tracking-Links in normale E-Mails einbauen (kein Personenbezug einbauen)
  • Auswertung in Matomo per "Kombiniertes Reporting"
  • "Trüffel-Tipps":
    • Kampagnen-Parameter kürzen (z. B. yourls.org)
    • Kampagnen-Parameter mtm_* und utm_* werden entfernt - daher eigene Parameter verwenden (in Matomo konfigurierbar)
    • Datenverlust in Analytics beheben - Matomo kann Consent-Bannerfrei eingesetzt werden / Adblocker können umgangen werden (siehe Blockliste z. B. uBlock Origin)
    • Ladezeit beachten - erst nach vollständigem Laden, wird Matomo-Track befeuert
    • Tracking von Bildschirmauflösung und Browsererweiterungen abschalten, damit kein Fingerprinting erfolgt
  • Tipp: Matomo auf eigenem Server
  • Neues Reporting-Tool für Matomo-Daten in Vorbereitung

Starter-Kit [Stefan Fischer]

Inhalt der Session waren die Möglichkeiten für Agenturen/Freelancer, um Kundenprojekte möglichst schnell abzuschließen

Persönliche Vorgehensweise (Stefan):

  • Code & Extensions:
    • Standard Felder in RSCE anlegen und dann für die verschiedenen ContentElemente per include einbinden
    • Standard-Template-Parts die zu den Standard-Feldern gehören
    • Innerhalb des Templates haben wir ein Customer-Ordner, wo fest vorgefertigte Werte des Kunden bereitgestellt werden. Bsp.:
      • Standard-Werte für die Eingabefelder
      • vorgefertigte Farbwerte für die Klassen / SCSS-Variablen
    • eine extra DB / Extension um Kundenspezifische Einstellungen für:
      • Footer
      • Header
        • zu definieren - Bsp.:
          • Standard-Farbwerte
          • Standardwerte für Eingabefelder
          • Daten des Kunden die relevant für die Webseite sind
          • Festlegen, welche art von Header(Navi) oder Footer erscheinen soll. Bsp.: Compact, Expanded, Custom ...
  • Nutzung eines Install-Scripts / Copy-Scripts:
    • Install-Script
      • automatische Erstellung von:
        • Domain
        • DB+DBUser
        • SSH/FTP-Zugang
        • SSL
      • automatisches Speichern der Passwörter in einem Passwort-Manager (bsp. 1password) mittels Script
      • automatische Installation von Contao & den Extensions
      • Mittels:
        • SSH
        • 1password-CLI
        • FTP
        • PHP
        • Command-Pattern
        • Plesk-Api (XML)
        • Git-Commands
        • Contao-Manager
  • Copy-Script
    • Domain, DB, Zugang müssen manuell angelegt werden
    • mittels Bash
      • komplettes Contao-Projekt herunterladen
      • entzippen und einrichten
  • Diskussion und Feedback in der Runde
    • Vorschlag:
      • besser Composer verwenden und Projekt installieren statt komplettes Projekt herunterzuladen
      • statt Kundenordner mit Standardwerten:
        • Stylemanager-Extension verwenden
        • Standardwerte (bsp. Klassen) mittels Stylemanager festlegen
      • Fields & Template-Parts über anderen Ordner, statt unter Templates
      • Prüfung: kann man RSCE-Configs einfach über das Templates-Menü von Contao verwalten?
      • Verwaltung über Git, Packagist und Composer
        • könnte allerdings schwierig bei privaten Repos werden. Möglichkeit:
          • Zugriff über composer.json ermöglichen
          • Pakete in Contao-Manager per Zip hochladen
    • hat sich der Aufwand des Install-Scripts gelohnt?
      • Wie viele Kunden habt ihr?
    • Was machst du, wenn auf anderen / aktuellen Projekten Änderungen passieren?
      • Aktuell mittels Subscription werden die Code-Updates finanziert
      • Code-Update
        • müssen in allen Projekten der Code upgedated werden?
        • Alternativ: Überlegung, ob man Projekte unabhängig voneinander weiterentwicklet. Sprich Änderungen in einem Projekt nicht mittels Updates im anderen Projekt übernehmen
        • grundsätzliche Frage, wie kriegst du die Code-Updates rein, die auf der Original-Domain stattfinden & die du in deinem aktuellen Projekt brauchst.
    • alternative Möglichkeiten bsp.:
      • Extensions (einfache Updates möglich)
      • Themes (einfache Updates möglich). Möglichkeiten:
        • damals unter anderem von Aschemp entwickelt
        • extra vorgesehen, für die Nutzung von Darstellung / Themes
        • wird nur einmalig bei erst-installation verwendet
        • SQL-Datei, Templates, SCSS, JS, ... zu inkludieren

Versionsverwaltung Code/Deployment [Sascha Wustmann]

  • Viele verschiedene Möglichkeiten
  • Einfache Systemupdates über den Manager oder Trakked
  • Deployment vom lokalen Rechner mittel Phing, MagePHP, Deployer o.ä.
  • Integration von Tools in Deployment Systeme (Gitlab CI, Jenkins o.ä.)

Agenturtools [Ali Dursun]

  • Kommunikation / Datei-Share
    • Libre Workspace
    • Nextcloud
    • SeaFile
  • Projekte / Aufgaben
    • aWork
    • Redmine
    • Trello
    • Clickup
    • Moco
  • Zeiterfassung
    • Clockodo
  • Wiki / Doku
    • Xwiki
    • Wiki.js
    • Bookstack
    • Gitlab
  • Automatisierung
    • zapier
    • make
    • n8n.io
  • Fernwartung
    • Rustdesk
    • HoptoDesk
  • Monitoring
    • Uptime Kuma
    • Icinga
    • StatusCake
  • Backup
    • Monkey für Joomla / Wordpress

Core-Contributions [Leo Feyer]

  • Verschiedene Wege, das Monorepo in eine Managed-Edition einzubinden, um Änderungen im Browser testen zu können: Symlink über Composer oder direkte Entwicklung in vendor.
  • Eigenen Fork erstellen und als Remote hinzufügen.
  • Pull-Request auf github.com erstellen.
  • Installation bzw. Aktivierung von Yarn 4, um die Assets zu builden.

zod.js Schema-Verwaltung [Jan Friebe]

  • leider bestand hier kein Interesse und die Session ist nicht zustande gekommen.
  • Wen das Thema (TypeScript-first schema validation with static type inference) trotzdem interessiert, kann sich unter folgendem Link informationen einholen zod.js

Zusammenfassung [Janosch Oltmanns]

Sonntag, 21.04.2024

Plan 2

Einsatz von KI [Christian Röckl]

  • An welchen Stellen unseres Auftragsablaufes kann KI eingesetz werden?
  • Unterstützung bei Kommunikation wie E-Mails (Chrome-Erweiterung)
  • Zusammenfassung von Texten wie Vertäge
  • Texterstellung - Achtung: Texte checken!; z. B. Produktbeschreibung
  • Generierung von Sitemap als Grafik z. B. Octopus
  • Wireframe generieren z. B. Relume
  • Generierung von Bildern, erweitern von Bildern z. B. bei unpassenden Formaten, Icons (z. B. Indesign)
  • Generierung von JS Snippets
  • SEO z. B. Zusammenfassungen/Description, Alt-Texte von Bildern
  • Marketing
  • Überwachung von Websitesinhalten
  • Präsentationen z. B. mit Gamma.app, Video generieren
  • Harpa Ai
  • aus Screenshot bearbeitbare Seite machen Uizard
  • Chatbot - aktuell die Unterschiede in der Handhabung bei der Konfiguration

Tools:

Contao Events / Themen für Konferenz 2024 [Stefan Preiss, Markus Peltzer]

Angestoßen wurde die Session vom Event-Team und rund 15 Personen besuchten die Session

Im ersten Teil der Session wurde das Format Barcamp thematisiert.
Sowohl in der Contao Community als auch in anderen Communities sind die Besucherzahlen zu Camps rückläufig. Das mag noch an Auswirkungen der Pandemie liegen, es wurde auch diskutiert, dass das Format als solches nach 15 Jahren an Attraktivität verloren hat.

Zur Frage, ob das Format besser in der Woche oder am Wochenende stattfinden sollte, gab es unterschiedliche Meinungen:

  • für Einzelkämpfer besser am Wochenende
  • für Angestellte, die zu Veranstaltungen geschickt werden, ist es während der Woche besser

Vorteile des Formats Barcamp:

  • Möglichkeit, viel und in Kommunikation zu lernen
  • individueller Know-How Transfer möglich
  • geringerer Ticketpreis
  • Fokus auf Community/Netzwerken

Spezielle Nachteile des Formates Barcamp:

  • das Format lässt sich Chefs schwieriger vermitteln, da unklare Inhalte

Allgemeiner Nachteil der Veranstaltungen:

  • zusätzliche Belastung durch Hotel, Anfahrt etc durch Preissteigerungen

Ideen für das Camp:

  • denkbar wäre eine Terminierung Freitag/Samstag
  • Themenpunkte des letzten Camps auf Website(s) veröffentlichen
  • Mischformate (vorgegebene Themengruppen)
  • Kombination mit Colleges
  • Kombination mit anderen CMS
  • Banner der Veranstaltung auch in der Doku

Fragerunde, wie Besucher vom Camp erfahren haben:

  • Slack, explizite Ansprache
  • Idee, die nächste Veranstaltung im Anschluss zu verkünden (ist in Kiel/Camp 2024 passiert)
  • nicht anwesende Personen anschrieben

Alternative Formate zum Camp:

  • Mix-Events
  • Sommerfest mit Workshops
  • Fuckup-Night im Abendprogramm

Im zweiten Teil der Session wurde das Format Konferenz thematisiert.
Wie beim Camp auch gibt es rückläufige Besucherzahlen in allen Communities. Besprochen wurde die Zielgruppe und mit welchen Motivationen Besuchergruppen haben:

  • Lowpreis vs. Highpreis
    • Lowpreis/Einsteiger: weniger Vor-Ort für Angestellte, viel Online
    • Highpreis: Agenturen/Firmen schicken die "Head-Ofs" (mehr Budget)

Konsens herrschte bei der These, dass Online-Formate eine Konkurrenz wurden. Diese wurden durch Corona professionalisiert und bringen weniger Arbeitszeitausfall und weniger Kosten mit sich.

Weitere Ideen/Themen zur Konferenz:

  • bezahlte Anzeigen (CA-Budget nutzen)
  • Idee: in SoMe-active Nutzer als Influencer nutzen
  • Wie können Agenturen erreicht werden?
  • explizite Themenstränge beibehalten
  • Bedürfnisse/Wünsche abfragen
  • Speaker-Suche ist aufwändig/müßig
  • finanziell werden Speaker aus der Community benötigt
  • Meta-Themen: Mitarbeiterführung, Projektleitung
  • Security-Themen
  • Symfony Community

Weitere Topics

  • brauchen wir neue/weitere Online-Formate
  • offene Online-Stammtische

Blick in die Zukunft und über den Tellerrand hinaus [Benedict Massolle, Christian Röckl]

Nennenswerte Unterschiede von Contao zu anderen Redaktionssystemen, die im Arbeitsalltag oder im Gespräch mit Kunden auftauchen:

  • Andere CMS bieten eine API
  • Inhalte in Contao sind sehr verschachtelt (immer Seiten, Artikel, Inhaltselemente), andere CMS sind da flacher
  • Schulungsbedarf bei Contao
  • Das CMS muss zum Job passen: Je nach Anforderungsprofil des Jobs ist der Aufwand höher auch geringer. Auch die Verfügbarkeit von Erweiterungen spielt eine Rolle
  • Contao hat ein komplexes Rechtemanagement: Es lässt sich sehr viel sehr fein einstellen, man muss sich aber auch damit auseinandersetzen.
  • Weniger Features des CMS erlauben manchmal mehr Kontrolle. Gegen manche Contao-Features muss man regelrecht ankämpfen.

Es haben sich unterschiedliche Herangehensweisen herauskristallisiert: Alles über das Backend steuern vs. alles „im Template hardcodieren“. Je nach Arbeitsweise passt ein CMS, besser als das andere. Die eierlegende Wollmilchsau wird es eher nicht geben.

Andere CMS, die in der Contao Community je nach Anforderung auch verwendet werden:

Wie geht: Trakked [Bjarke Ammann]

  • Registrierung
  • Einbindung
  • Tracking von Seiten
  • Security-Hinweise

Finanzierung von Erweiterungen [Andreas Schemp]

  • es wurden verschiedene Wege für Refinanzierung erörtert
  • "early-adopter-programm" wie bei MetaModels, Contao-Bootstrap, Include-Erweiterung - also mit Programmierung in Vorleistung gehen und einen finanziellen Beitrag für sofortige Nutzung bekommen; Ingolf hat im Vorfeld zu "EAP" eine Umfrage bei Agenturen gemacht und das ist für viele eine gute Option für die Projektplanung; bei dem "EAP" sind die Erweiterung nach Finanzierung für alle frei verfügbar
  • klassisches Fundraising like Kickstarter - wenig Bereitschaft im DACH-Bereich für diese Variante der Finanzierung
  • Klassische Bezahlvariante - ggf. vorhandene Lizenzbedingungen beachten
  • eigene "Community" wie bei Isotope mit dem "Circle" - da reichen Einnahmen nur für Bugfixes/Support aber nicht für große Neuentwicklungen/Features
  • Variante mit freier Verfügbarkeit und zu bezahlenden Plugins
  • schwierig ist die Umstellung von bisherigen kostenlosen Varianten zu einer Bezahlvariante

Tools für Coding [Stefan Lindecke]

Finale Besprechung bezüglich Tools zum Entwickeln mit Docker, plain oder ddev (https://ddev.com/)

Contao ThemeManager [Daniele Sciannimanica]

  • Historie
  • Warum gibt es den ThemeManager und wie ist er entstanden
  • Bestandteile des ThemeManagers
  • Core Features wie Seo-Headlines & Hintergrundbilder
  • Arbeiten mit dem ThemeManager
  • Dokumentation
  • Wie installiere ich erwerbbare Themes
  • Fragen & Antworten

Contao Xliff [Christian Bargon, Ingolf Steinhardt]

  • Unterschiede zwischen Xliff 1 und 2
  • Vorstellung von "Contao2Xliff"
    • Duplizieren des Seitenbaums
    • Zielgruppe ist "normale Contao-User"
  • Vorstellung von "XLIFF-Ex-Import":
    • Konsolen-Tool
    • Steuerung über eine Konfigdatei
    • Automatisierung per Cronjob möglich
    • Debugmöglichkeiten bei z. B. bei unklaren Zuordnungen
    • Zielgruppe ist eher Admins, die automatisierte Export/Importe einrichten wollen oder MetaModels dabei haben
  • bei beiden muss man bei Erweiterungen gucken, was geht

"Matomo+" - Tracking bei Contao-Seite [Joachim Nickel]

Code-Quality [Florian Otto]

Ideen für Contao-Bundles [René Fehrmann]

Beschäftigt haben wir uns ganz im Allgemeinen mit 2 Ideen, die es so bisher nicht gibt. Hier mal stichwortartig etwas detaillierter:

  1. Sammlung erweiterter Inhaltselemente/Module
  • sollte out-of-the-box funktionieren (Bundle installieren, Elemente stehen funktionsfähig zur Verfügung)
  • Umsetzung als echte Inhaltselemente (keine RSCEs)
  • einige Ideen:
    • Module ToTop (ein Button, der sich automatisch einblendet und bei Klick auf der Seite nach oben springt)
    • Module ScrollPosition (ein einfacher Balken, der anzeigt, wie weit man sich auf der Seite bereits nach unten bewegt hat)
    • Element Responsive Gallery (einfach responsive Galerie mit einigen neuen Features, z.B. Spans über Spalten)
  1. ein Audit-Modul um Fehler/Probleme schnell/früh zu erkennen
  • regelmäßige Audit´s möglich (Command per Cron)
  • erweiterbar um neue eigene Prüfungen zu ergänzen
  • jede Prüfung möglichst mit eigenen Werten konfigurierbar
  • Konfiguration mittels eigener yml-Datei (für einfaches Kopieren in andere Installationen)
  • einige Ideen für entsprechende Prüfungen:
    • gibt es im System noch "(Kopie)"-Markierungen?
    • ist in der Startseite der Alias auf index gesetzt
    • wie groß werden die Log-Dateien insgesamt
    • ist ein Route-Prefix für das Backend konfiguriert
  • Bild 1: Konfiguration
  • Bild 2: Auswertung