Onboarding - webEdition Core-Entwickler

Du hast Interesse am webEdition Code mitzuwirken? Wir freuen uns.

Entwicklungs-Themengebiete

Wir unterscheiden grundsätzlich diese Bereiche bei der Entwicklung:

Texte
Für die in webEdition dargestellten Texte und Labels gibt es einen Editor für Übersetzungen im Backend.
Backend
Hier wird verwendet: PHP, SQL,JS, (S)CSS
Frontend
Hier wird verwendet: PHP, JS, (S)CSS
Layout
Hier dreht es sich in erster Linie um (S)CSS (sass)
Tags
Die webEdition eigenen Tags sind in PHP geschrieben

Arbeitsumgebung

Um an webEdition arbeiten zu können, bedarf es einer entsprechenden Arbeitsumgebung. Nachfolgend findet ihr die bei uns eingesetzten Tools und/oder Empfehlungen, teilweise mit weiterführender Erläuterung.

Versionsprotokoll Mercurial (hg)

Wir setzen Mercurial (hg) als Versionsprotokoll ein. Wer es noch nicht kennt - die Kommandos funktionieren wie bei svn.
Ein großer Vorteil ist hier, dass auch Checkins gemacht werden können, wenn der Server mal nicht erreichbar ist.

Wir haben derzeit drei Branches:

Old (aktuell 8.1.x)
Default (9.1.x) für Bug-Fixes
Devel (9.2.0)

Wie daran vielleicht bereits erkennbar ist, wir nutzen bewusst Branches derzeit bis auf die genannten nicht. Branches werden, wenn benötigt, nur lokal eingesetzt.
Feature Taggings (Tags) verwenden wir nur für Versionen.
Ein Push sollte zuvor getestet sein (phan). Natürlich ist hierfür ein Schreibzugriff erforderlich.

IDE / Entwicklungsumgebung

Für eine sinnvoll durchführbare Core-Entwicklung braucht es natürlich eine Entwicklungsumgebung wie netbeans, phpstorm, ...
Empfehlen können wir netbeans - hier können auch für Neueinsteiger Tipps gegeben werden.

"Spiel"-Server / Webspace

Ob lokal oder remote. Eine webEdition Installation mit einer Beispiel-Website - Templates und Seiten, ... ist natürlich ebenfalls essentiell. Damit man direkt testen kann.
Idealerweise mit direkter Upload-Möglichkeit über SSH oder (S)FTP.

Jabber-Client

Das hat nicht unmittelbar etwas mit der Core-Entwicklung zu tun. Wir nutzen Jabber als direkte Kommunikations-Möglichkeit zwischen den Entwicklern. Dies ist viel effizienter und auch schöner als Email, wenn man sich schnell mal austauschen will.
Es bedarf also einen Client, wie zum Beispiel Pidgin.

Wir haben hier eine Allgemeine Gruppe (Raum) angelegt, in der die Entwickler sich tummeln:
webedition@conference.jabber.ccc.de

Wer Wert auf Verschlüsselung legt, kann sich pidgin-encryption, OTR anschauen.

Wenn Ihr die ersten Schritte gegangen und webEdition Core-Entwickler seid, werdet ihr natürlich auch eine Einladung zum Gruppenbeitritt bekommen.

PHP

Ist nicht zwingend lokal erforderlich, wenn man Zugang zum Server/Webspace hat. Was ja sehr wahrscheinlich der Fall sein wird.
Als Debugger Tool nutzen wir: Phan

Wie wir PHP nutzen ...
Wir schreiben Klassen, nutzen keine includes mehr. Die Stellen die noch includes nutzen, werden ausgebaut werden.
Wir haben strict typed properties (string ist string und es darf etsprechend kein int drinstecken).
Wir nutzen Klassen für die Datenhaltung und vermeiden Arrays.

Auch hier ist Phan sehr hilfreich bei der Ermittlung wo eine Umstellung noch erforderlich ist bzw. bei der Ermittlung von Fehlern.

Für die webEdition Tags ist es ein guter Start, sich diese nachfolgenden Tags anzuschauen:

we_tag_path – hier kommt ein String zurück
we_tag_ifClient – als Vertreter eines if-Tags, liefert ein bool Wert zurück
we_tag_ifNotDeleted – Im Normalfall sind die Not-Tags leere Konstrukte, es wird hier lediglich der If-Tag negiert

Eine essentielle Klasse ist die we_database_base, um die Datenbank anzusprechen und etwas abzurufen.

Beim Betrachten dieser Tag-Klassen dürfte deutlich werden, wie einheitlich, sauber und übersichtlich der Code jeweils aufgebaut ist.

SQL

Wir arbeiten im strict-mode.
Dies dient der Code-Sicherheit (Stichwort: SQL-Injections) und es werden damit schon frühzeitig Entwicklungs-Fehler aufgedeckt.
Auch möchten wir Tabellen-Constraints zunehmend einsetzen. Das ist derzeit jedoch leider nur bedingt möglich, da die Hoster teilweise keine aktuellen Datenbankversionen zur Verfügung stellen.

JavaScript

Wir setzen aus Gründen der Nachhaltigkeit kaum Frameworks ein.
Lediglich: jquery, jqueryui
Jedoch sollte in erster Linie Vanilla JavaScript eingesetzt werden.
Für JavaScript reicht theoretisch auch einfach der implementierte Browser-Debugger
Als Debugger-Tool empfehlen wir ESLint.

Wir möchten mit Version 9.2 den strict-mode einführen und inline JS vermeiden.
Künftig werden wir versuchen eine Kapselung von JS-Modulen zu entwicklen.

Wir verwenden data-Attributes, bspw. in der we_cmd sehr stark, um inline JS zu vermeiden.

CSS

Hier kommt kein spezielles Framework zum Einsatz. Das soll derzeit und wenn möglich auch künftig so bleiben - im Sinne der Nachhaltigkeit.
Für CSS reicht der implementierter Browser-Debugger.
Verbindungs-Werkzeug: sass

Schön und gut.
Aber wie fange ich nun also an?

Setze dir eine entsprechende Entwicklungsumgebung auf.
Das bedeutet konkret - du brauchst wenigstens Mercurial (hg) und Jabber.

Du kannst Auschecken und Spielen.
Solange kein Push gemacht wird, passiert nichts. - Und für einen solchen brauchst du eh Schreibrechte.

Wenn du soweit bist und willst loslegen, dann melde dich bei uns: committee@webedition.org

Wir ermöglichen dir einen leichten Einstieg und geben dir entsprechende Aufgaben für den Einstieg - ganz auf dich zugeschnitten und in Absprache mit dir.

Willkommen an Board!