Opencaching-Wiki - Benutzerbeiträge [de]

Entwicklungsumgebung einrichten

2026-04-29T08:58:57Z

Fraggle: + docker-Socket-Datei prüfen

Das Einrichten der Testumgebung erfolgt in mehreren Schritten, die im folgenden beschrieben sind. Falls es dabei zu unerwarteten Fehlermeldungen kommt, bitte die letzten Schritte noch einmal genau anschauen und gegebenenfalls wiederholen. Auch ein Blick ins Fehlerhandbuch hilft meistens, da bereits viele Fallstricke entdeckt und beschrieben wurden.

== 1. Das Betriebssystem vorbereiten, entweder Linux oder Windows ==
=== Windows 10 ===
==== Programme installieren ====
Unter Windows ist es standardmäßig nicht möglich, “einfach“ die Linux Distribution Ubuntu zu installieren. Dazu muss vorab erst das WSL2 aktiviert / installiert werden werden (Punkt 1). Im Anschluss ist eine Installation von Ubuntu (18.04 oder höher) möglich. Zudem muss DDEV installiert werden, in welchem dann die Entwicklungsumgebung laufen kann (Punkt 2).

# WSL2 unter Windows10 aktivieren und Ubuntu installieren:
## Aus dem Microsoft-Store: https://aka.ms/wslstorepage (verfügbar seit Nov. 2022)
## Manuell unter [https://learn.microsoft.com/de-de/windows/wsl/install#manual-installation-steps|Installieren von WSL]
# DDEV für Windows installieren: [https://docs.ddev.com/en/stable/#system-requirements-windows-wsl2|Install DDEV WSL2]

Danach kann Ubuntu gestartet werden (z.B. im “Such“-Menü nach Ubuntu suchen und anklicken). Beim erstmaligen Starten von Ubuntu müssen ein Benutzername und ein Passwort festgelegt werden.

Im Anschluss den Punkten folgen und ausführen, die im nächsten Schritt “Linux” beschrieben werden.

=== Linux ===
Der Linuxartikel wurde erstellt auf Lubuntu 22.04 und erweitert mit Debian 12

==== Programme installieren ====
Folgende Programme sind notwendig und müssen vorab installiert werden:
PHP (aktuell mindestens PHP8.2), diverse PHP-Erweiterungen, ddev, mariadb-client. Für die PHP-Erweiterungen ist eventuell ein zusätzliches PPA-Repository notwendig. Dessen Installation erfordert je nach Betriebssystem ein unterschiedliches Vorgehen.

<nowiki>Ubuntu:
sudo apt install software-properties-common
sudo add-apt-repository ppa:ondrej/php

Debian:
sudo apt install software-properties-common ca-certificates lsb-release apt-transport-https
curl -sSL https://packages.sury.org/php/README.txt | sudo bash -x</nowiki>

Die Pakete lassen sich mit folgenden Befehlen installieren (Versionsnummer kann abweichen).
<nowiki>sudo apt update
sudo apt install php8.2 php8.2-mbstring php8.2-curl php8.2-xml php8.2-mysql
sudo apt install mariadb-client</nowiki>

Die docker-Installation ist ebenfalls notwendig. Die Anweisungen sind hier zu finden:
[https://docs.docker.com/engine/install/ubuntu/|https://docs.docker.com/engine/install/ubuntu/]

Die ddev-Installation ist ebenfalls notwendig. Die Anweisungen sind hier zu finden:
[https://ddev.com/get-started/|https://ddev.com/get-started/]

Sollten beim Installieren der Pakete Fehlermeldungen auftreten, ist es empfehlenswert, die Pakete einzeln zu installieren und auftretende Fehler/Abhängigkeiten einzeln zu lösen.

==== Nutzer in docker-Gruppe aufnehmen ====
Der aktuelle Benutzer muss in die Gruppe “docker” aufgenommen werden, sonst kann es passieren, dass dieser keinen Zugriff auf die Dockercontainer bekommt.
<nowiki>sudo usermod -aG docker $(id -un)</nowiki>

Die Änderung wird aber erst nach einem Ab-/Anmelden des Nutzers wirksam. Überprüft werden kann dies danach mittels
<nowiki>id</nowiki>

Hier muss die “docker”-Gruppe aufgelistet sein. Beispiel:
<nowiki>uid=1000(user) gid=1000(user) groups=1000(user),4(adm),24(cdrom),..,128(docker)</nowiki>

==== Eigenschaften der Docker Socket-Datei prüfen ====
Den folgenden Befehl ausführen, um die Eigenschaften der Datei anzeigen zu lassen:
<nowiki>sudo ls -la /var/run/docker.sock</nowiki>

Die Datei muss dabei ‘docker’ zugewiesen sein:
<nowiki>rw-rw---- 1 root docker 0 Dec 21 19:16 /var/run/docker.sock</nowiki>

Ist dies nicht der Fall, muss die Zugehörigkeit geändert werden:
<nowiki>chgrp docker /var/run/docker.sock</nowiki>

== 2. Sourcecode von Git laden ==
=== Github ===
Zwar ist zum Herunterlden des Sourcecodes keine Account auf GitHub notwendig, aber zum Hochladen wird einer benötigt. Daher sollte zuerst einen Account auf https://github.com/ angelegt werden.

=== optional: SSH-Keys für Repositorys anlegen und in Github eintragen ===
siehe https://docs.github.com/en/free-pro-team@latest/github/authenticating-to-github/connecting-to-github-with-ssh 
oder: https://www.heise.de/tipps-tricks/SSH-Key-fuer-GitHub-Repositories-einrichten-4627459.html

=== Git lokal installieren ===
Windows: 
siehe: https://github.com/git-for-windows/git/releases 

Linux:
<nowiki>sudo apt install git</nowiki>

=== Sourcecode lokal herunterladen ===
Ein Terminal öffnen, folgende Kommandos ausführen und dabei Namen und Email-Adresse des Git-Accounts eintragen:
<nowiki>git config --local user.name "Your Name Here"
git config --local user.email "your_email@youremail.com"</nowiki>

Im Verzeichnis "home" einen Ordner "opencaching" (Name beliebig) anlegen. Dort folgenden Code ausführen. Dies legt einen Ordner mit dem Namen “oc-server3“ an, lädt den OC-Code aus deinem Github-Fork herunter und kopiert ihn in diesen Ordner.
<nowiki>git clone git@github.com:<DeinGithubBenutzername>/oc-server3</nowiki>

Im Anschluss in den Ordner “oc-server3“ wechseln und den folgenden Befehl ausführen, um bei einem Update den neuesten Sourcecode aus dem Opencaching.de-Repository erhalten zu können:
<nowiki>cd oc-server3
git remote add upstream git@github.com:OpencachingDeutschland/oc-server3</nowiki>

Mit folgendem Befehl gibt es eine Übersicht über die verknüpften Repositorys, die (abgesehen vom Nutzernamen ‘Slini11’) wie in der Grafik aussehen müssen:
<nowiki>git remote -v</nowiki>
[[Image:Testumgebung Git 01.png]]

Nun den Branch “development“ auschecken:
<nowiki>git checkout development</nowiki>

Und den Development-Branch auf aktuellen Stand bringen:
<nowiki>git pull --rebase upstream development </nowiki>

=== Weiterführende Informationen zu Git ===
Diese sind unter anderem im [[Entwicklung/Git|OC-Wiki]] zu finden

== 3. DDEV Entwicklungsumgebung initalisieren ==
=== Entwicklungsumgebung zum ersten Mal starten ===
Zuerst in den Projektordner “oc-server3“ navigieren und dort die Installation der Testumgebung starten.

==== Scripte einzeln und (auch nur einmal!) ausführen ====
* ddev anstarten. Im Laufe dieses Prozesses wird die hosts-Datei automatisch angepasst.
<nowiki>ddev start</nowiki>

* Starten der Initialisierung der Testumgebung und der Datenbank.
<nowiki>ddev init</nowiki>

* Die Entwicklungsumgebung steht nun über den Browser bereit unter:
https://opencaching.ddev.site
bzw.
https://try-opencaching.ddev.site

Das Passwort für den Benutzer ''root'' lautet ''developer''. Das Passwort der anderen Benutzer (Benutzernamen siehe Datenbank) lautet ''password''

* Ein Mailpit steht nun über den Browser bereit (zumindest für den Legacy-Teil, für OC4 ist es noch nicht bestätigt) unter:
https://opencaching.ddev.site:8026/

=== Entwicklungsumgebung ein weiteres Mal starten ===
Eine bereits per 'ddev init' initialisierte Testumgebung kann gestartet werden mit:
<nowiki>ddev start</nowiki>

Die Testumgebung kann neugestartet werden mit:
<nowiki>ddev restart</nowiki>

=== Entwicklungsumgebung stoppen ===
Die Testumgebung kann gestoppt werden mit:
<nowiki>ddev stop</nowiki>

=== Entwicklungsumgebung löschen ===
Die Testumgebung kann im Projektordner gelöscht werden mit:
<nowiki>ddev delete --omit-snapshot</nowiki>
Danach sind ein erneutes ''ddev start'' und ''ddev init'' notwendig.

=== von DDEV angelegte Objekte löschen und Projekte aus der globalen DDEV-Liste löschen ===
<nowiki>ddev clean --all</nowiki>
<nowiki>ddev stop --unlist opencaching</nowiki>

=== xdebug in der Entwicklungsumgebung starten ===
<nowiki>ddev xdebug</nowiki>
Ein ''ddev start'' oder ''ddev restart'' deaktiviert das xdebug wieder.

=== Weitere ddev-Optionen.. ===
''ddev'' ohne Parameter aufrufen gibt eine Liste weiterer Optionen aus.
<nowiki>ddev</nowiki>

== 4. Die Testdatenbank füllen ==
Während der Installation wird eine Testdatenbank importiert, die bereits eine kleine Menge an Caches und Nutzern beinhaltet. Ein manueller Import des Datenbankdumps ist somit (seit März 2021) nicht mehr notwendig.

Für den Fall, dass trotzdem Daten exportiert / importiert werden sollen, können folgende Abschnitte berücksichtigt werden:

=== Login auf der Test-Datenbank im ddev-Container ===
<nowiki>mysql -uroot -proot -hopencaching-db opencaching</nowiki>

=== Datenbank innerhalb des ddev-Containers exportieren ===
<nowiki>mysqldump -uroot -proot -hopencaching-db opencaching > file.sql</nowiki>

=== Datenbank außerhalb des ddev-Containers exportieren ===
<nowiki>mysqldump --complete-insert --user root -proot --host 0.0.0.0 opencaching > dump.sql</nowiki>

=== Datenbank im phpStorm exportieren ===
Auf der rechten Bildschirmseite den Databasedialog ausklappen
rechte Maustaste auf die zu exportierende Datenbank “opencaching” => “Export with ‘mysqldump’”

[[Image:Testumgebung DB 01.png]]

Im Exportmenü die Zeile “Statements” umstellen auf “Insert with columns” und eventuell den Ausgabepfad “Out Path” anpassen. Im Kommandofeld den Parameter “--routines“ ergänzen und dann “Run” drücken

[[Image:Testumgebung DB 02.png]]

=== Datenbank-Dump im phpStorm importieren ===
Auf der rechten Bildschirmseite den Databasedialog ausklappen
rechte Maustaste auf die Datenbank => “Restore with ‘mysql’”

[[Image:Testumgebung DB 03.png]]

Im Importmenü den Eingabepfad “Path to dump” anpassen, dann “Run” drücken

[[Image:Testumgebung DB 04.png]]

== 5. Die Entwicklungs-IDE vorbereiten ==
Gegebenenfalls sind an der Programmierumgebung Änderungen vorzunehmen, um zum Beispiel [[OC Coding Style|einheitlich formatierten Code]] zu schreiben.

=== Einrichtung des PHP Coding Styles am Beispiel von phpStorm ===
Unter Settings / Code Style / PHP rechts auf “Set from…” klicken und “PSR-12” auswählen. Die Einstellung mit “Apply” bestätigen.
(Weitere Informationen zum Coding Style sind [[OC Coding Style|hier im Wiki]] zu finden.)

[[Image:Testumgebung IDE 01.png|500px]]

=== Symfony Pfade am Beispiel phpStorm anpassen ===
[[Image:Testumgebung IDE 04.jpeg]]

=== Terminalanpassung am Beispiel phpStorm (für Windows-Nutzer) ===
[[Image:Testumgebung IDE 05.png]]

=== Datenbankanbindung in phpStorm aktivieren ===
Seit ddev als Umgebung genutzt wird, bietet sich das ddev-Plugin im phpStorm an. Es richtet z.B. den Zugang zur opencaching-Datenbank in der Testumgebung sowie weitere Einstellungen automatisch ein.
Hierzu im phpStorm im Menü Datei/Einstellungen.. zum Abschnitt ''Plugins'' navigieren, im Suchfeld ''ddev'' eintippen und das Plugin installieren.
[[Image:Testumgebung IDE 06.jpg]]

=== Synchronisieren/Wiederherstellen der Benutzereinstellungen mittels JetBrains-Server ===
Sofern man bei JetBrains einen Account hat, kann man mit diesem die Einstellungen der lokalen IDE synchronisieren und z.B. nach einer Neuinstallation von dort wiederherstellen.

Hierzu in der IDE rechts oben auf das Zahnrad klicken und “Settings Sync is off” auswählen.
[[Image:Testumgebung IDE 02.png]]

Im folgenden Fenster den Button “Enable Settings Sync” klicken und danach alle Einstellungen auswählen, die man sichern möchte. Ein Klick auf “Push Settings to Account” sichert die Einstellungen. Ein Klick auf “Get Settings from Account” stellt sie wieder her, sofern sie vorher dorthin gesichert wurden.
[[Image:Testumgebung IDE 03.png]]

== 6. Das Fehlerhandbuch lesen (gilt insbesondere für die Schritte #1-#4 :wink:) ==

Beireits bekannte Fehler werden im [[Entwicklungsumgebung/Fehlerhandbuch|Fehlerhandbuch]] beschrieben.

[[Kategorie:Entwicklung|Entwicklungsumgebung ]]

Entwicklungsumgebung einrichten

2026-04-29T08:57:51Z

Fraggle: docker + docker-Gruppe wieder ergänzt

Das Einrichten der Testumgebung erfolgt in mehreren Schritten, die im folgenden beschrieben sind. Falls es dabei zu unerwarteten Fehlermeldungen kommt, bitte die letzten Schritte noch einmal genau anschauen und gegebenenfalls wiederholen. Auch ein Blick ins Fehlerhandbuch hilft meistens, da bereits viele Fallstricke entdeckt und beschrieben wurden.

== 1. Das Betriebssystem vorbereiten, entweder Linux oder Windows ==
=== Windows 10 ===
==== Programme installieren ====
Unter Windows ist es standardmäßig nicht möglich, “einfach“ die Linux Distribution Ubuntu zu installieren. Dazu muss vorab erst das WSL2 aktiviert / installiert werden werden (Punkt 1). Im Anschluss ist eine Installation von Ubuntu (18.04 oder höher) möglich. Zudem muss DDEV installiert werden, in welchem dann die Entwicklungsumgebung laufen kann (Punkt 2).

# WSL2 unter Windows10 aktivieren und Ubuntu installieren:
## Aus dem Microsoft-Store: https://aka.ms/wslstorepage (verfügbar seit Nov. 2022)
## Manuell unter [https://learn.microsoft.com/de-de/windows/wsl/install#manual-installation-steps|Installieren von WSL]
# DDEV für Windows installieren: [https://docs.ddev.com/en/stable/#system-requirements-windows-wsl2|Install DDEV WSL2]

Danach kann Ubuntu gestartet werden (z.B. im “Such“-Menü nach Ubuntu suchen und anklicken). Beim erstmaligen Starten von Ubuntu müssen ein Benutzername und ein Passwort festgelegt werden.

Im Anschluss den Punkten folgen und ausführen, die im nächsten Schritt “Linux” beschrieben werden.

=== Linux ===
Der Linuxartikel wurde erstellt auf Lubuntu 22.04 und erweitert mit Debian 12

==== Programme installieren ====
Folgende Programme sind notwendig und müssen vorab installiert werden:
PHP (aktuell mindestens PHP8.2), diverse PHP-Erweiterungen, ddev, mariadb-client. Für die PHP-Erweiterungen ist eventuell ein zusätzliches PPA-Repository notwendig. Dessen Installation erfordert je nach Betriebssystem ein unterschiedliches Vorgehen.

<nowiki>Ubuntu:
sudo apt install software-properties-common
sudo add-apt-repository ppa:ondrej/php

Debian:
sudo apt install software-properties-common ca-certificates lsb-release apt-transport-https
curl -sSL https://packages.sury.org/php/README.txt | sudo bash -x</nowiki>

Die Pakete lassen sich mit folgenden Befehlen installieren (Versionsnummer kann abweichen).
<nowiki>sudo apt update
sudo apt install php8.2 php8.2-mbstring php8.2-curl php8.2-xml php8.2-mysql
sudo apt install mariadb-client</nowiki>

Die docker-Installation ist ebenfalls notwendig. Die Anweisungen sind hier zu finden:
[https://docs.docker.com/engine/install/ubuntu/|https://docs.docker.com/engine/install/ubuntu/]

Die ddev-Installation ist ebenfalls notwendig. Die Anweisungen sind hier zu finden:
[https://ddev.com/get-started/|https://ddev.com/get-started/]

Sollten beim Installieren der Pakete Fehlermeldungen auftreten, ist es empfehlenswert, die Pakete einzeln zu installieren und auftretende Fehler/Abhängigkeiten einzeln zu lösen.

==== Nutzer in docker-Gruppe aufnehmen ====
Der aktuelle Benutzer muss in die Gruppe “docker” aufgenommen werden, sonst kann es passieren, dass dieser keinen Zugriff auf die Dockercontainer bekommt.
<nowiki>sudo usermod -aG docker $(id -un)</nowiki>

Die Änderung wird aber erst nach einem Ab-/Anmelden des Nutzers wirksam. Überprüft werden kann dies danach mittels
<nowiki>id</nowiki>

Hier muss die “docker”-Gruppe aufgelistet sein. Beispiel:
<nowiki>uid=1000(user) gid=1000(user) groups=1000(user),4(adm),24(cdrom),..,128(docker)</nowiki>

== 2. Sourcecode von Git laden ==
=== Github ===
Zwar ist zum Herunterlden des Sourcecodes keine Account auf GitHub notwendig, aber zum Hochladen wird einer benötigt. Daher sollte zuerst einen Account auf https://github.com/ angelegt werden.

=== optional: SSH-Keys für Repositorys anlegen und in Github eintragen ===
siehe https://docs.github.com/en/free-pro-team@latest/github/authenticating-to-github/connecting-to-github-with-ssh 
oder: https://www.heise.de/tipps-tricks/SSH-Key-fuer-GitHub-Repositories-einrichten-4627459.html

=== Git lokal installieren ===
Windows: 
siehe: https://github.com/git-for-windows/git/releases 

Linux:
<nowiki>sudo apt install git</nowiki>

=== Sourcecode lokal herunterladen ===
Ein Terminal öffnen, folgende Kommandos ausführen und dabei Namen und Email-Adresse des Git-Accounts eintragen:
<nowiki>git config --local user.name "Your Name Here"
git config --local user.email "your_email@youremail.com"</nowiki>

Im Verzeichnis "home" einen Ordner "opencaching" (Name beliebig) anlegen. Dort folgenden Code ausführen. Dies legt einen Ordner mit dem Namen “oc-server3“ an, lädt den OC-Code aus deinem Github-Fork herunter und kopiert ihn in diesen Ordner.
<nowiki>git clone git@github.com:<DeinGithubBenutzername>/oc-server3</nowiki>

Im Anschluss in den Ordner “oc-server3“ wechseln und den folgenden Befehl ausführen, um bei einem Update den neuesten Sourcecode aus dem Opencaching.de-Repository erhalten zu können:
<nowiki>cd oc-server3
git remote add upstream git@github.com:OpencachingDeutschland/oc-server3</nowiki>

Mit folgendem Befehl gibt es eine Übersicht über die verknüpften Repositorys, die (abgesehen vom Nutzernamen ‘Slini11’) wie in der Grafik aussehen müssen:
<nowiki>git remote -v</nowiki>
[[Image:Testumgebung Git 01.png]]

Nun den Branch “development“ auschecken:
<nowiki>git checkout development</nowiki>

Und den Development-Branch auf aktuellen Stand bringen:
<nowiki>git pull --rebase upstream development </nowiki>

=== Weiterführende Informationen zu Git ===
Diese sind unter anderem im [[Entwicklung/Git|OC-Wiki]] zu finden

== 3. DDEV Entwicklungsumgebung initalisieren ==
=== Entwicklungsumgebung zum ersten Mal starten ===
Zuerst in den Projektordner “oc-server3“ navigieren und dort die Installation der Testumgebung starten.

==== Scripte einzeln und (auch nur einmal!) ausführen ====
* ddev anstarten. Im Laufe dieses Prozesses wird die hosts-Datei automatisch angepasst.
<nowiki>ddev start</nowiki>

* Starten der Initialisierung der Testumgebung und der Datenbank.
<nowiki>ddev init</nowiki>

* Die Entwicklungsumgebung steht nun über den Browser bereit unter:
https://opencaching.ddev.site
bzw.
https://try-opencaching.ddev.site

Das Passwort für den Benutzer ''root'' lautet ''developer''. Das Passwort der anderen Benutzer (Benutzernamen siehe Datenbank) lautet ''password''

* Ein Mailpit steht nun über den Browser bereit (zumindest für den Legacy-Teil, für OC4 ist es noch nicht bestätigt) unter:
https://opencaching.ddev.site:8026/

=== Entwicklungsumgebung ein weiteres Mal starten ===
Eine bereits per 'ddev init' initialisierte Testumgebung kann gestartet werden mit:
<nowiki>ddev start</nowiki>

Die Testumgebung kann neugestartet werden mit:
<nowiki>ddev restart</nowiki>

=== Entwicklungsumgebung stoppen ===
Die Testumgebung kann gestoppt werden mit:
<nowiki>ddev stop</nowiki>

=== Entwicklungsumgebung löschen ===
Die Testumgebung kann im Projektordner gelöscht werden mit:
<nowiki>ddev delete --omit-snapshot</nowiki>
Danach sind ein erneutes ''ddev start'' und ''ddev init'' notwendig.

=== von DDEV angelegte Objekte löschen und Projekte aus der globalen DDEV-Liste löschen ===
<nowiki>ddev clean --all</nowiki>
<nowiki>ddev stop --unlist opencaching</nowiki>

=== xdebug in der Entwicklungsumgebung starten ===
<nowiki>ddev xdebug</nowiki>
Ein ''ddev start'' oder ''ddev restart'' deaktiviert das xdebug wieder.

=== Weitere ddev-Optionen.. ===
''ddev'' ohne Parameter aufrufen gibt eine Liste weiterer Optionen aus.
<nowiki>ddev</nowiki>

== 4. Die Testdatenbank füllen ==
Während der Installation wird eine Testdatenbank importiert, die bereits eine kleine Menge an Caches und Nutzern beinhaltet. Ein manueller Import des Datenbankdumps ist somit (seit März 2021) nicht mehr notwendig.

Für den Fall, dass trotzdem Daten exportiert / importiert werden sollen, können folgende Abschnitte berücksichtigt werden:

=== Login auf der Test-Datenbank im ddev-Container ===
<nowiki>mysql -uroot -proot -hopencaching-db opencaching</nowiki>

=== Datenbank innerhalb des ddev-Containers exportieren ===
<nowiki>mysqldump -uroot -proot -hopencaching-db opencaching > file.sql</nowiki>

=== Datenbank außerhalb des ddev-Containers exportieren ===
<nowiki>mysqldump --complete-insert --user root -proot --host 0.0.0.0 opencaching > dump.sql</nowiki>

=== Datenbank im phpStorm exportieren ===
Auf der rechten Bildschirmseite den Databasedialog ausklappen
rechte Maustaste auf die zu exportierende Datenbank “opencaching” => “Export with ‘mysqldump’”

[[Image:Testumgebung DB 01.png]]

Im Exportmenü die Zeile “Statements” umstellen auf “Insert with columns” und eventuell den Ausgabepfad “Out Path” anpassen. Im Kommandofeld den Parameter “--routines“ ergänzen und dann “Run” drücken

[[Image:Testumgebung DB 02.png]]

=== Datenbank-Dump im phpStorm importieren ===
Auf der rechten Bildschirmseite den Databasedialog ausklappen
rechte Maustaste auf die Datenbank => “Restore with ‘mysql’”

[[Image:Testumgebung DB 03.png]]

Im Importmenü den Eingabepfad “Path to dump” anpassen, dann “Run” drücken

[[Image:Testumgebung DB 04.png]]

== 5. Die Entwicklungs-IDE vorbereiten ==
Gegebenenfalls sind an der Programmierumgebung Änderungen vorzunehmen, um zum Beispiel [[OC Coding Style|einheitlich formatierten Code]] zu schreiben.

=== Einrichtung des PHP Coding Styles am Beispiel von phpStorm ===
Unter Settings / Code Style / PHP rechts auf “Set from…” klicken und “PSR-12” auswählen. Die Einstellung mit “Apply” bestätigen.
(Weitere Informationen zum Coding Style sind [[OC Coding Style|hier im Wiki]] zu finden.)

[[Image:Testumgebung IDE 01.png|500px]]

=== Symfony Pfade am Beispiel phpStorm anpassen ===
[[Image:Testumgebung IDE 04.jpeg]]

=== Terminalanpassung am Beispiel phpStorm (für Windows-Nutzer) ===
[[Image:Testumgebung IDE 05.png]]

=== Datenbankanbindung in phpStorm aktivieren ===
Seit ddev als Umgebung genutzt wird, bietet sich das ddev-Plugin im phpStorm an. Es richtet z.B. den Zugang zur opencaching-Datenbank in der Testumgebung sowie weitere Einstellungen automatisch ein.
Hierzu im phpStorm im Menü Datei/Einstellungen.. zum Abschnitt ''Plugins'' navigieren, im Suchfeld ''ddev'' eintippen und das Plugin installieren.
[[Image:Testumgebung IDE 06.jpg]]

=== Synchronisieren/Wiederherstellen der Benutzereinstellungen mittels JetBrains-Server ===
Sofern man bei JetBrains einen Account hat, kann man mit diesem die Einstellungen der lokalen IDE synchronisieren und z.B. nach einer Neuinstallation von dort wiederherstellen.

Hierzu in der IDE rechts oben auf das Zahnrad klicken und “Settings Sync is off” auswählen.
[[Image:Testumgebung IDE 02.png]]

Im folgenden Fenster den Button “Enable Settings Sync” klicken und danach alle Einstellungen auswählen, die man sichern möchte. Ein Klick auf “Push Settings to Account” sichert die Einstellungen. Ein Klick auf “Get Settings from Account” stellt sie wieder her, sofern sie vorher dorthin gesichert wurden.
[[Image:Testumgebung IDE 03.png]]

== 6. Das Fehlerhandbuch lesen (gilt insbesondere für die Schritte #1-#4 :wink:) ==

Beireits bekannte Fehler werden im [[Entwicklungsumgebung/Fehlerhandbuch|Fehlerhandbuch]] beschrieben.

[[Kategorie:Entwicklung|Entwicklungsumgebung ]]

Entwicklungsumgebung einrichten

2026-04-29T08:49:34Z

Fraggle: ddev Installationslink

Das Einrichten der Testumgebung erfolgt in mehreren Schritten, die im folgenden beschrieben sind. Falls es dabei zu unerwarteten Fehlermeldungen kommt, bitte die letzten Schritte noch einmal genau anschauen und gegebenenfalls wiederholen. Auch ein Blick ins Fehlerhandbuch hilft meistens, da bereits viele Fallstricke entdeckt und beschrieben wurden.

== 1. Das Betriebssystem vorbereiten, entweder Linux oder Windows ==
=== Windows 10 ===
==== Programme installieren ====
Unter Windows ist es standardmäßig nicht möglich, “einfach“ die Linux Distribution Ubuntu zu installieren. Dazu muss vorab erst das WSL2 aktiviert / installiert werden werden (Punkt 1). Im Anschluss ist eine Installation von Ubuntu (18.04 oder höher) möglich. Zudem muss DDEV installiert werden, in welchem dann die Entwicklungsumgebung laufen kann (Punkt 2).

# WSL2 unter Windows10 aktivieren und Ubuntu installieren:
## Aus dem Microsoft-Store: https://aka.ms/wslstorepage (verfügbar seit Nov. 2022)
## Manuell unter [https://learn.microsoft.com/de-de/windows/wsl/install#manual-installation-steps|Installieren von WSL]
# DDEV für Windows installieren: [https://docs.ddev.com/en/stable/#system-requirements-windows-wsl2|Install DDEV WSL2]

Danach kann Ubuntu gestartet werden (z.B. im “Such“-Menü nach Ubuntu suchen und anklicken). Beim erstmaligen Starten von Ubuntu müssen ein Benutzername und ein Passwort festgelegt werden.

Im Anschluss den Punkten folgen und ausführen, die im nächsten Schritt “Linux” beschrieben werden.

=== Linux ===
Der Linuxartikel wurde erstellt auf Lubuntu 22.04 und erweitert mit Debian 12

==== Programme installieren ====
Folgende Programme sind notwendig und müssen vorab installiert werden:
PHP (aktuell mindestens PHP8.2), diverse PHP-Erweiterungen, ddev, mariadb-client. Für die PHP-Erweiterungen ist eventuell ein zusätzliches PPA-Repository notwendig. Dessen Installation erfordert je nach Betriebssystem ein unterschiedliches Vorgehen.

<nowiki>Ubuntu:
sudo apt install software-properties-common
sudo add-apt-repository ppa:ondrej/php

Debian:
sudo apt install software-properties-common ca-certificates lsb-release apt-transport-https
curl -sSL https://packages.sury.org/php/README.txt | sudo bash -x</nowiki>

Die Pakete lassen sich mit folgenden Befehlen installieren (Versionsnummer kann abweichen).
<nowiki>sudo apt update
sudo apt install php8.2 php8.2-mbstring php8.2-curl php8.2-xml php8.2-mysql
sudo apt install mariadb-client</nowiki>

Die ddev-Installation ist ebenfalls notwendig. Die Anweisungen sind hier zu finden:
[https://ddev.com/get-started/|https://ddev.com/get-started/]

Sollten beim Installieren der Pakete Fehlermeldungen auftreten, ist es empfehlenswert, die Pakete einzeln zu installieren und auftretende Fehler/Abhängigkeiten einzeln zu lösen.

== 2. Sourcecode von Git laden ==
=== Github ===
Zwar ist zum Herunterlden des Sourcecodes keine Account auf GitHub notwendig, aber zum Hochladen wird einer benötigt. Daher sollte zuerst einen Account auf https://github.com/ angelegt werden.

=== optional: SSH-Keys für Repositorys anlegen und in Github eintragen ===
siehe https://docs.github.com/en/free-pro-team@latest/github/authenticating-to-github/connecting-to-github-with-ssh 
oder: https://www.heise.de/tipps-tricks/SSH-Key-fuer-GitHub-Repositories-einrichten-4627459.html

=== Git lokal installieren ===
Windows: 
siehe: https://github.com/git-for-windows/git/releases 

Linux:
<nowiki>sudo apt install git</nowiki>

=== Sourcecode lokal herunterladen ===
Ein Terminal öffnen, folgende Kommandos ausführen und dabei Namen und Email-Adresse des Git-Accounts eintragen:
<nowiki>git config --local user.name "Your Name Here"
git config --local user.email "your_email@youremail.com"</nowiki>

Im Verzeichnis "home" einen Ordner "opencaching" (Name beliebig) anlegen. Dort folgenden Code ausführen. Dies legt einen Ordner mit dem Namen “oc-server3“ an, lädt den OC-Code aus deinem Github-Fork herunter und kopiert ihn in diesen Ordner.
<nowiki>git clone git@github.com:<DeinGithubBenutzername>/oc-server3</nowiki>

Im Anschluss in den Ordner “oc-server3“ wechseln und den folgenden Befehl ausführen, um bei einem Update den neuesten Sourcecode aus dem Opencaching.de-Repository erhalten zu können:
<nowiki>cd oc-server3
git remote add upstream git@github.com:OpencachingDeutschland/oc-server3</nowiki>

Mit folgendem Befehl gibt es eine Übersicht über die verknüpften Repositorys, die (abgesehen vom Nutzernamen ‘Slini11’) wie in der Grafik aussehen müssen:
<nowiki>git remote -v</nowiki>
[[Image:Testumgebung Git 01.png]]

Nun den Branch “development“ auschecken:
<nowiki>git checkout development</nowiki>

Und den Development-Branch auf aktuellen Stand bringen:
<nowiki>git pull --rebase upstream development </nowiki>

=== Weiterführende Informationen zu Git ===
Diese sind unter anderem im [[Entwicklung/Git|OC-Wiki]] zu finden

== 3. DDEV Entwicklungsumgebung initalisieren ==
=== Entwicklungsumgebung zum ersten Mal starten ===
Zuerst in den Projektordner “oc-server3“ navigieren und dort die Installation der Testumgebung starten.

==== Scripte einzeln und (auch nur einmal!) ausführen ====
* ddev anstarten. Im Laufe dieses Prozesses wird die hosts-Datei automatisch angepasst.
<nowiki>ddev start</nowiki>

* Starten der Initialisierung der Testumgebung und der Datenbank.
<nowiki>ddev init</nowiki>

* Die Entwicklungsumgebung steht nun über den Browser bereit unter:
https://opencaching.ddev.site
bzw.
https://try-opencaching.ddev.site

Das Passwort für den Benutzer ''root'' lautet ''developer''. Das Passwort der anderen Benutzer (Benutzernamen siehe Datenbank) lautet ''password''

* Ein Mailpit steht nun über den Browser bereit (zumindest für den Legacy-Teil, für OC4 ist es noch nicht bestätigt) unter:
https://opencaching.ddev.site:8026/

=== Entwicklungsumgebung ein weiteres Mal starten ===
Eine bereits per 'ddev init' initialisierte Testumgebung kann gestartet werden mit:
<nowiki>ddev start</nowiki>

Die Testumgebung kann neugestartet werden mit:
<nowiki>ddev restart</nowiki>

=== Entwicklungsumgebung stoppen ===
Die Testumgebung kann gestoppt werden mit:
<nowiki>ddev stop</nowiki>

=== Entwicklungsumgebung löschen ===
Die Testumgebung kann im Projektordner gelöscht werden mit:
<nowiki>ddev delete --omit-snapshot</nowiki>
Danach sind ein erneutes ''ddev start'' und ''ddev init'' notwendig.

=== von DDEV angelegte Objekte löschen und Projekte aus der globalen DDEV-Liste löschen ===
<nowiki>ddev clean --all</nowiki>
<nowiki>ddev stop --unlist opencaching</nowiki>

=== xdebug in der Entwicklungsumgebung starten ===
<nowiki>ddev xdebug</nowiki>
Ein ''ddev start'' oder ''ddev restart'' deaktiviert das xdebug wieder.

=== Weitere ddev-Optionen.. ===
''ddev'' ohne Parameter aufrufen gibt eine Liste weiterer Optionen aus.
<nowiki>ddev</nowiki>

== 4. Die Testdatenbank füllen ==
Während der Installation wird eine Testdatenbank importiert, die bereits eine kleine Menge an Caches und Nutzern beinhaltet. Ein manueller Import des Datenbankdumps ist somit (seit März 2021) nicht mehr notwendig.

Für den Fall, dass trotzdem Daten exportiert / importiert werden sollen, können folgende Abschnitte berücksichtigt werden:

=== Login auf der Test-Datenbank im ddev-Container ===
<nowiki>mysql -uroot -proot -hopencaching-db opencaching</nowiki>

=== Datenbank innerhalb des ddev-Containers exportieren ===
<nowiki>mysqldump -uroot -proot -hopencaching-db opencaching > file.sql</nowiki>

=== Datenbank außerhalb des ddev-Containers exportieren ===
<nowiki>mysqldump --complete-insert --user root -proot --host 0.0.0.0 opencaching > dump.sql</nowiki>

=== Datenbank im phpStorm exportieren ===
Auf der rechten Bildschirmseite den Databasedialog ausklappen
rechte Maustaste auf die zu exportierende Datenbank “opencaching” => “Export with ‘mysqldump’”

[[Image:Testumgebung DB 01.png]]

Im Exportmenü die Zeile “Statements” umstellen auf “Insert with columns” und eventuell den Ausgabepfad “Out Path” anpassen. Im Kommandofeld den Parameter “--routines“ ergänzen und dann “Run” drücken

[[Image:Testumgebung DB 02.png]]

=== Datenbank-Dump im phpStorm importieren ===
Auf der rechten Bildschirmseite den Databasedialog ausklappen
rechte Maustaste auf die Datenbank => “Restore with ‘mysql’”

[[Image:Testumgebung DB 03.png]]

Im Importmenü den Eingabepfad “Path to dump” anpassen, dann “Run” drücken

[[Image:Testumgebung DB 04.png]]

== 5. Die Entwicklungs-IDE vorbereiten ==
Gegebenenfalls sind an der Programmierumgebung Änderungen vorzunehmen, um zum Beispiel [[OC Coding Style|einheitlich formatierten Code]] zu schreiben.

=== Einrichtung des PHP Coding Styles am Beispiel von phpStorm ===
Unter Settings / Code Style / PHP rechts auf “Set from…” klicken und “PSR-12” auswählen. Die Einstellung mit “Apply” bestätigen.
(Weitere Informationen zum Coding Style sind [[OC Coding Style|hier im Wiki]] zu finden.)

[[Image:Testumgebung IDE 01.png|500px]]

=== Symfony Pfade am Beispiel phpStorm anpassen ===
[[Image:Testumgebung IDE 04.jpeg]]

=== Terminalanpassung am Beispiel phpStorm (für Windows-Nutzer) ===
[[Image:Testumgebung IDE 05.png]]

=== Datenbankanbindung in phpStorm aktivieren ===
Seit ddev als Umgebung genutzt wird, bietet sich das ddev-Plugin im phpStorm an. Es richtet z.B. den Zugang zur opencaching-Datenbank in der Testumgebung sowie weitere Einstellungen automatisch ein.
Hierzu im phpStorm im Menü Datei/Einstellungen.. zum Abschnitt ''Plugins'' navigieren, im Suchfeld ''ddev'' eintippen und das Plugin installieren.
[[Image:Testumgebung IDE 06.jpg]]

=== Synchronisieren/Wiederherstellen der Benutzereinstellungen mittels JetBrains-Server ===
Sofern man bei JetBrains einen Account hat, kann man mit diesem die Einstellungen der lokalen IDE synchronisieren und z.B. nach einer Neuinstallation von dort wiederherstellen.

Hierzu in der IDE rechts oben auf das Zahnrad klicken und “Settings Sync is off” auswählen.
[[Image:Testumgebung IDE 02.png]]

Im folgenden Fenster den Button “Enable Settings Sync” klicken und danach alle Einstellungen auswählen, die man sichern möchte. Ein Klick auf “Push Settings to Account” sichert die Einstellungen. Ein Klick auf “Get Settings from Account” stellt sie wieder her, sofern sie vorher dorthin gesichert wurden.
[[Image:Testumgebung IDE 03.png]]

== 6. Das Fehlerhandbuch lesen (gilt insbesondere für die Schritte #1-#4 :wink:) ==

Beireits bekannte Fehler werden im [[Entwicklungsumgebung/Fehlerhandbuch|Fehlerhandbuch]] beschrieben.

[[Kategorie:Entwicklung|Entwicklungsumgebung ]]

Entwicklungsumgebung einrichten

2026-04-09T18:52:17Z

Fraggle: ddev-Anweisungen erweitert

Das Einrichten der Testumgebung erfolgt in mehreren Schritten, die im folgenden beschrieben sind. Falls es dabei zu unerwarteten Fehlermeldungen kommt, bitte die letzten Schritte noch einmal genau anschauen und gegebenenfalls wiederholen. Auch ein Blick ins Fehlerhandbuch hilft meistens, da bereits viele Fallstricke entdeckt und beschrieben wurden.

== 1. Das Betriebssystem vorbereiten, entweder Linux oder Windows ==
=== Windows 10 ===
==== Programme installieren ====
Unter Windows ist es standardmäßig nicht möglich, “einfach“ die Linux Distribution Ubuntu zu installieren. Dazu muss vorab erst das WSL2 aktiviert / installiert werden werden (Punkt 1). Im Anschluss ist eine Installation von Ubuntu (18.04 oder höher) möglich. Zudem muss DDEV installiert werden, in welchem dann die Entwicklungsumgebung laufen kann (Punkt 2).

# WSL2 unter Windows10 aktivieren und Ubuntu installieren:
## Aus dem Microsoft-Store: https://aka.ms/wslstorepage (verfügbar seit Nov. 2022)
## Manuell unter [https://learn.microsoft.com/de-de/windows/wsl/install#manual-installation-steps|Installieren von WSL]
# DDEV für Windows installieren: [https://docs.ddev.com/en/stable/#system-requirements-windows-wsl2|Install DDEV WSL2]

Danach kann Ubuntu gestartet werden (z.B. im “Such“-Menü nach Ubuntu suchen und anklicken). Beim erstmaligen Starten von Ubuntu müssen ein Benutzername und ein Passwort festgelegt werden.

Im Anschluss den Punkten folgen und ausführen, die im nächsten Schritt “Linux” beschrieben werden.

=== Linux ===
Der Linuxartikel wurde erstellt auf Lubuntu 22.04 und erweitert mit Debian 12

==== Programme installieren ====
Folgende Programme sind notwendig und müssen vorab installiert werden:
PHP (aktuell mindestens PHP8.2), diverse PHP-Erweiterungen, ddev, mariadb-client. Für die PHP-Erweiterungen ist eventuell ein zusätzliches PPA-Repository notwendig. Dessen Installation erfordert je nach Betriebssystem ein unterschiedliches Vorgehen.

<nowiki>Ubuntu:
sudo apt install software-properties-common
sudo add-apt-repository ppa:ondrej/php

Debian:
sudo apt install software-properties-common ca-certificates lsb-release apt-transport-https
curl -sSL https://packages.sury.org/php/README.txt | sudo bash -x</nowiki>

Die Pakete lassen sich mit folgenden Befehlen installieren (Versionsnummer kann abweichen).
<nowiki>sudo apt update
sudo apt install php8.2 php8.2-mbstring php8.2-curl php8.2-xml php8.2-mysql
sudo apt install mariadb-client
sudo apt install ddev</nowiki>

Sollten beim Installieren der Pakete Fehlermeldungen auftreten, ist es empfehlenswert, die Pakete einzeln zu installieren und auftretende Fehler/Abhängigkeiten einzeln zu lösen.

== 2. Sourcecode von Git laden ==
=== Github ===
Zwar ist zum Herunterlden des Sourcecodes keine Account auf GitHub notwendig, aber zum Hochladen wird einer benötigt. Daher sollte zuerst einen Account auf https://github.com/ angelegt werden.

=== optional: SSH-Keys für Repositorys anlegen und in Github eintragen ===
siehe https://docs.github.com/en/free-pro-team@latest/github/authenticating-to-github/connecting-to-github-with-ssh 
oder: https://www.heise.de/tipps-tricks/SSH-Key-fuer-GitHub-Repositories-einrichten-4627459.html

=== Git lokal installieren ===
Windows: 
siehe: https://github.com/git-for-windows/git/releases 

Linux:
<nowiki>sudo apt install git</nowiki>

=== Sourcecode lokal herunterladen ===
Ein Terminal öffnen, folgende Kommandos ausführen und dabei Namen und Email-Adresse des Git-Accounts eintragen:
<nowiki>git config --local user.name "Your Name Here"
git config --local user.email "your_email@youremail.com"</nowiki>

Im Verzeichnis "home" einen Ordner "opencaching" (Name beliebig) anlegen. Dort folgenden Code ausführen. Dies legt einen Ordner mit dem Namen “oc-server3“ an, lädt den OC-Code aus deinem Github-Fork herunter und kopiert ihn in diesen Ordner.
<nowiki>git clone git@github.com:<DeinGithubBenutzername>/oc-server3</nowiki>

Im Anschluss in den Ordner “oc-server3“ wechseln und den folgenden Befehl ausführen, um bei einem Update den neuesten Sourcecode aus dem Opencaching.de-Repository erhalten zu können:
<nowiki>cd oc-server3
git remote add upstream git@github.com:OpencachingDeutschland/oc-server3</nowiki>

Mit folgendem Befehl gibt es eine Übersicht über die verknüpften Repositorys, die (abgesehen vom Nutzernamen ‘Slini11’) wie in der Grafik aussehen müssen:
<nowiki>git remote -v</nowiki>
[[Image:Testumgebung Git 01.png]]

Nun den Branch “development“ auschecken:
<nowiki>git checkout development</nowiki>

Und den Development-Branch auf aktuellen Stand bringen:
<nowiki>git pull --rebase upstream development </nowiki>

=== Weiterführende Informationen zu Git ===
Diese sind unter anderem im [[Entwicklung/Git|OC-Wiki]] zu finden

== 3. DDEV Entwicklungsumgebung initalisieren ==
=== Entwicklungsumgebung zum ersten Mal starten ===
Zuerst in den Projektordner “oc-server3“ navigieren und dort die Installation der Testumgebung starten.

==== Scripte einzeln und (auch nur einmal!) ausführen ====
* ddev anstarten. Im Laufe dieses Prozesses wird die hosts-Datei automatisch angepasst.
<nowiki>ddev start</nowiki>

* Starten der Initialisierung der Testumgebung und der Datenbank.
<nowiki>ddev init</nowiki>

* Die Entwicklungsumgebung steht nun über den Browser bereit unter:
https://opencaching.ddev.site
bzw.
https://try-opencaching.ddev.site

Das Passwort für den Benutzer ''root'' lautet ''developer''. Das Passwort der anderen Benutzer (Benutzernamen siehe Datenbank) lautet ''password''

* Ein Mailpit steht nun über den Browser bereit (zumindest für den Legacy-Teil, für OC4 ist es noch nicht bestätigt) unter:
https://opencaching.ddev.site:8026/

=== Entwicklungsumgebung ein weiteres Mal starten ===
Eine bereits per 'ddev init' initialisierte Testumgebung kann gestartet werden mit:
<nowiki>ddev start</nowiki>

Die Testumgebung kann neugestartet werden mit:
<nowiki>ddev restart</nowiki>

=== Entwicklungsumgebung stoppen ===
Die Testumgebung kann gestoppt werden mit:
<nowiki>ddev stop</nowiki>

=== Entwicklungsumgebung löschen ===
Die Testumgebung kann im Projektordner gelöscht werden mit:
<nowiki>ddev delete --omit-snapshot</nowiki>
Danach sind ein erneutes ''ddev start'' und ''ddev init'' notwendig.

=== von DDEV angelegte Objekte löschen und Projekte aus der globalen DDEV-Liste löschen ===
<nowiki>ddev clean --all</nowiki>
<nowiki>ddev stop --unlist opencaching</nowiki>

=== xdebug in der Entwicklungsumgebung starten ===
<nowiki>ddev xdebug</nowiki>
Ein ''ddev start'' oder ''ddev restart'' deaktiviert das xdebug wieder.

=== Weitere ddev-Optionen.. ===
''ddev'' ohne Parameter aufrufen gibt eine Liste weiterer Optionen aus.
<nowiki>ddev</nowiki>

== 4. Die Testdatenbank füllen ==
Während der Installation wird eine Testdatenbank importiert, die bereits eine kleine Menge an Caches und Nutzern beinhaltet. Ein manueller Import des Datenbankdumps ist somit (seit März 2021) nicht mehr notwendig.

Für den Fall, dass trotzdem Daten exportiert / importiert werden sollen, können folgende Abschnitte berücksichtigt werden:

=== Login auf der Test-Datenbank im ddev-Container ===
<nowiki>mysql -uroot -proot -hopencaching-db opencaching</nowiki>

=== Datenbank innerhalb des ddev-Containers exportieren ===
<nowiki>mysqldump -uroot -proot -hopencaching-db opencaching > file.sql</nowiki>

=== Datenbank außerhalb des ddev-Containers exportieren ===
<nowiki>mysqldump --complete-insert --user root -proot --host 0.0.0.0 opencaching > dump.sql</nowiki>

=== Datenbank im phpStorm exportieren ===
Auf der rechten Bildschirmseite den Databasedialog ausklappen
rechte Maustaste auf die zu exportierende Datenbank “opencaching” => “Export with ‘mysqldump’”

[[Image:Testumgebung DB 01.png]]

Im Exportmenü die Zeile “Statements” umstellen auf “Insert with columns” und eventuell den Ausgabepfad “Out Path” anpassen. Im Kommandofeld den Parameter “--routines“ ergänzen und dann “Run” drücken

[[Image:Testumgebung DB 02.png]]

=== Datenbank-Dump im phpStorm importieren ===
Auf der rechten Bildschirmseite den Databasedialog ausklappen
rechte Maustaste auf die Datenbank => “Restore with ‘mysql’”

[[Image:Testumgebung DB 03.png]]

Im Importmenü den Eingabepfad “Path to dump” anpassen, dann “Run” drücken

[[Image:Testumgebung DB 04.png]]

== 5. Die Entwicklungs-IDE vorbereiten ==
Gegebenenfalls sind an der Programmierumgebung Änderungen vorzunehmen, um zum Beispiel [[OC Coding Style|einheitlich formatierten Code]] zu schreiben.

=== Einrichtung des PHP Coding Styles am Beispiel von phpStorm ===
Unter Settings / Code Style / PHP rechts auf “Set from…” klicken und “PSR-12” auswählen. Die Einstellung mit “Apply” bestätigen.
(Weitere Informationen zum Coding Style sind [[OC Coding Style|hier im Wiki]] zu finden.)

[[Image:Testumgebung IDE 01.png|500px]]

=== Symfony Pfade am Beispiel phpStorm anpassen ===
[[Image:Testumgebung IDE 04.jpeg]]

=== Terminalanpassung am Beispiel phpStorm (für Windows-Nutzer) ===
[[Image:Testumgebung IDE 05.png]]

=== Datenbankanbindung in phpStorm aktivieren ===
Seit ddev als Umgebung genutzt wird, bietet sich das ddev-Plugin im phpStorm an. Es richtet z.B. den Zugang zur opencaching-Datenbank in der Testumgebung sowie weitere Einstellungen automatisch ein.
Hierzu im phpStorm im Menü Datei/Einstellungen.. zum Abschnitt ''Plugins'' navigieren, im Suchfeld ''ddev'' eintippen und das Plugin installieren.
[[Image:Testumgebung IDE 06.jpg]]

=== Synchronisieren/Wiederherstellen der Benutzereinstellungen mittels JetBrains-Server ===
Sofern man bei JetBrains einen Account hat, kann man mit diesem die Einstellungen der lokalen IDE synchronisieren und z.B. nach einer Neuinstallation von dort wiederherstellen.

Hierzu in der IDE rechts oben auf das Zahnrad klicken und “Settings Sync is off” auswählen.
[[Image:Testumgebung IDE 02.png]]

Im folgenden Fenster den Button “Enable Settings Sync” klicken und danach alle Einstellungen auswählen, die man sichern möchte. Ein Klick auf “Push Settings to Account” sichert die Einstellungen. Ein Klick auf “Get Settings from Account” stellt sie wieder her, sofern sie vorher dorthin gesichert wurden.
[[Image:Testumgebung IDE 03.png]]

== 6. Das Fehlerhandbuch lesen (gilt insbesondere für die Schritte #1-#4 :wink:) ==

Beireits bekannte Fehler werden im [[Entwicklungsumgebung/Fehlerhandbuch|Fehlerhandbuch]] beschrieben.

[[Kategorie:Entwicklung|Entwicklungsumgebung ]]

Entwicklungsumgebung/Fehlerhandbuch

2026-03-30T06:14:25Z

Fraggle: neu: webpack-encore Meldung

Während der Installation der Programme oder Einrichtung der Testumgebung kann es zu diversen Fehlern und Meldungen kommen. Im Folgenden sind bereits bekannte Meldungen aufgelistet, die bei einer schnellen Behebung helfen sollen.

== Fehlermeldungen während der Paketinstallation ==
==== Während der Installation der benötigten Pakete, kommt es zu einer Meldung, dass Abhängigkeiten mit dem ‘libdvd-pkg’ Paket nicht aufgelöst werden können ====

Eine Rekonfiguration des Pakets schafft Abhilfe:
<nowiki>sudo dpkg-reconfigure libdvd-pkg</nowiki>

== Fehlermeldungen in Zusammenhang mit der DDEV-Testumgebung ==
==== Fehler “ERROR: for opencaching-mariadb Cannot start service mariadb: driver failed programming external connectivity on endpoint opencaching-mariadb [..] Error starting userland proxy: listen tcp 0.0.0.0:3306: bind: address already in use” ====
Wenn beim 'ddev start' diese Fehlermeldung kommt, läuft im Hintergrund bereits ein anderer Webservice (z.B. mysql) auf Port 3306.

Prüfen kann man das mit:
netstat -tanp | grep :3306

Zum Beispiel ein mysql-Webserver kann gestoppt werden mit:
sudo mysqladmin -u root shutdown

==== [symfony/webpack-encore 4.x] Meldung “webpack-dev-server > rimraf@3.0.2: Rimraf versions prior to v4 are no longer supported” (.. und ähnliche) ====
Diese Meldungen haben keine funktionelle Einschränkung und können aktuell ignoriert werden. Abhilfe ist das Upgrade auf symfony/webpack-encore 5.x oder höher.

==== [Yarn 1.x] Meldung “[DEP0169] DeprecationWarning: `url.parse()` behavior is not standardized and prone to errors that have security implications. Use the WHATWG URL API instead. CVEs are not issued for `url.parse()` vulnerabilities.” ====
Diese Meldung hat keine funktionelle Einschränkung und kann aktuell ignoriert werden. Abhilfe ist das Upgrade auf Yarn 2.x oder höher.

Hintergrund: Seit nodejs Version 22 wird die Funktion url.parse() als veraltet markiert. Yarn 1.xx nutzt sie, wird wohl aber kein Update mehr erhalten. In Yarn 2+ ist das Problem behoben, allerdings ist ein Umstieg mit größeren Aufwänden verbunden und wird aktuell nicht forciert.

== Fehlermeldungen beim Zugriff auf die Datenbank ==
==== Fehlermeldung “ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)” ====
Es wurde vergessen, den Namen der Datenbank in der Kommandozeile zu übergeben.
mysql -uroot -proot -hopencaching-db opencaching

== Fehlermeldungen beim Zugriff auf die Testserverdomain(s) ==
==== Beim Anlegen/Editieren eines Listings funktioniert die Attributeauswahl nicht (betrifft Legacy-Testsystem) ====
Editiert man ein Listing, stehen nicht alle Attribute zur Verfügung bzw. es können nicht alle Attribute ausgewählt werden.

Abhilfe: (noch) keine Ahnung.

==== Ein neu angelegter Benutzer kann sich nicht einloggen und wird immer wieder ohne Meldung auf die Login-Seite geleitet (betrifft Legacy-Testsystem) ====
Die exakte Ursache ist nicht bekannt. Abhilfe kann geschaffen werden, wenn beim entsprechenden Nutzer in der Datenbank in der Tabelle ''user'' das Feld ''permanent_login_flag'' auf ''1'' gesetzt wird.

==== Es kann kein Logbild hochgeladen werden (betrifft Legacy-Testsystem) ====
Sobald man ein Logbild hochladen möchte, erscheint eine Fehlermeldung
<nowiki>Warning: move_uploaded_file(): Unable to move '/tmp/phpGmSzpi' to '/application/htdocs/config2/../images/uploads/700770A6-C101-11EA-BA77-0242AC120005.jpg' in /application/htdocs/lib2/logic/picture.class.php on line 856</nowiki>
Abhilfe: (noch) keine Ahnung. Die Bilder wurden aber trotzdem hochgeladen.

==== Es kann nicht auf die Domains opencaching.ddev.site oder try-opencaching.ddev.site zugegriffen werden. ====
Normalerweise sollte der Zugriff nach Installation der Testumgebung automatisch funktionieren. Sollte das nicht der Fall sein, kann mittels Anpassung der hosts-Datei ein Workaround geschaffen werden:
<nowiki>127.0.0.1 opencaching.ddev.site
127.0.0.1 try-opencaching.ddev.site</nowiki>

==== Abschalten von “NOTICE”-Meldungen. (betrifft Legacy-Testsystem) ====
Aufgrund diverser (Smarty- und PHP-)Updates werden vormals ignorierte Probleme nun mit einer “NOTICE”-Meldung kenntlich gemacht. Um die Meldungen zu unterdrücken, kann in das error_reporting Level geändert werden.

Beispiele für Fehlermeldungen:
<nowiki>Notice: Undefined index: error_password_not_ok in /app/htdocs/var/cache2/smarty/compiled/..
Notice: Trying to get property 'value' of non-object in /app/..</nowiki>

Abhilfe:
Bis Smarty 3.x: In der Datei /htdocs/vendor/smarty/smarty/libs/Smarty.class.php die Zeile mit $error_reporting ändern auf den nachfolgenden Code. Die Änderung ist nicht git-relevant und geht nach jedem “ddev init” verloren.
<nowiki>public $error_reporting = E_ALL & ~E_NOTICE;</nowiki>

Ab Smarty 3.x und 4.x: In der Datei /htdocs/lib2/common.inc.php die obere Zeile (PHP_DEBUG_ON) mit $error_reporting ändern auf den nachfolgenden Code. Die Änderung ist permanent und muss vor einem Commit rückgängig gemacht werden, da sie sonst im github Repository landet.
<nowiki>ini_set('error_reporting', E_ALL & ~E_NOTICE);</nowiki>

==== Vorgehen zum Anlegen eines weiteren Benutzers (betrifft Legacy-Testsystem) ====
Zuerst via https://opencaching.ddev.site/register.php einen neuen Nutzer registrieren. Zwar kommt dann die Meldung, dass der Aktivierungscode per Mail zugsandt wurde, dies passiert aber nie. Der Aktivierungscode muss aus der Test-Datenbank ausgelesen werden.
Der Code steht in Tabelle ''user'' im Feld ''activation_code''.

Mit https://opencaching.ddev.site/activation.php gelangt man zur Account-Aktivierungsseite. Hier die E-Mail-Adresse und den aus der Datenbank kopierten Aktivierungscode eingeben. Der Account ist nun aktiviert, aber falls der Login nicht funktioniert: siehe andere Fehlermeldung hier auf der Seite weiter unten.

Info: Eventuell wird in Zukunft der MailHog zum Laufen gebracht. Dann werden die vom Server verschickten Emails von diesem abgefangen und man kann die Informationen darin lesen.

== gelöste und veraltete Fehlermeldungen ==
==== [veraltet] Beim Anlegen des ''zweiten'' Cachelistings kommt eine Fehlermeldung (betrifft Legacy-Testsystem) ====
Bei einer ''leeren'' Datenbank funktioniert das Setzen und Hochzählen der OC-Codes nicht. Es muss einmal ein OC-Code von Hand gesetzt werden.

Hierzu auf dem Testserver ein Listing anlegen. Dann für diesen Cache in der Datenbank in der Tabelle ''caches'' das Feld ''wp_oc'' auf einen initialen Wert ändern, z.B. ''OC1234''.

==== [veraltet] Beim Erstellen/Speichern eines Cachelistings kommen mehrere Fehlermeldungen, u.a. "Warning: A non-numeric value encountered in /app/htdocs/newcache.php on line 1025" (betrifft Legacy-Testsystem) ====
[[Image:Fehlerhandbuch Domain 01.png|500px]]

Zuerst muss geschaut werden, ob eventuell der vorige Abschnitt ("Beim Anlegen des zweiten Cachelistings kommt eine Fehlermeldung") zutrifft. Wurden die dort beschriebenen Maßnahmen bereits umgesetzt, kommt es zwar trotzdem zur Fehlermeldung, das Listing wurde aber erfolgreich angelegt bzw. gespeichert. (Seite neu laden)

==== [gelöst] Beim Löschen von Logs kommt eine Fehlermeldung "This log entry has been created on another Opencaching website. The cache can only be edited there." ====
Auf dem Testserver werden die Logs laut Datenbank (Tabelle ''cache_logs'', Spalte ''nodes'') als ''node=5'' gespeichert, obwohl es laut Tabelle ''nodes'' diese Ziffer gar nicht gibt.

Um Logs wieder über die normale Loglöschenfunktion löschen zu können, gibt es mehrere Möglichkeiten:
# In der Datenbanktabelle 'cache_logs' den Eintrag in Spalte 'nodes' auf 4 ändern. (Dies entspricht der 'Local Development'-Umgebung (siehe Tabelle 'nodes')).
# In der Datei '/dev-ops/local.team-opencaching.de/templates/config2-settings.inc.tpl.php' den Eintrag '$opt['logic']['node']['id'] = 5;' ändern auf '$opt['logic']['node']['id'] = 4;' und das docker:init Script ausführen
# Der Pull [[https://github.com/OpencachingDeutschland/oc-server3/pull/830|Pull Request #830 changed node information from 5 to 4]] behebt das Problem.

==== [veraltet] Das Länderauswahlfeld rechts oben auf der Seite ist leer und funktioniert nicht. (betrifft Legacy-Testsystem) ====
Alle php-Dateien im Cacheverzeichnis htdocs/var/cache2 müssen gelöscht werden.

Das Vorgehen Unter Linux:
<nowiki>./psh.phar docker:stop
rm htdocs/var/cache2/*.inc.php
./psh.phar docker:start</nowiki>

==== [gelöst] Die Übersetzungen funktionieren nicht. Meist wird nur Englischer Text angezeigt. (betrifft Legacy-Testsystem) ====
Die vorhandenen Fremdsprachen werden auf dem Testsystem nicht korrekt dargestellt. Meistens wird nur der Englische Text oder ein Mischmasch aus Englisch und eingestellter Sprache angezeigt.

Abhilfe: im docker:start Skript wurde eine fehlende Komponente ergänzt, welche nun automatisch mitinstalliert wird. Dadurch werden die Sprachdateien korrekt erzeugt und die Übersetzungen funktionieren.

Siehe auch: [[https://opencaching.atlassian.net/browse/RED-1278|RED-1278: Die Übersetzungen funktionieren auf dem Testserver nicht]]
Dieser Fehler sollte somit nicht mehr auftauchen.

==== [veraltet] Docker Services neu initialisieren, z.B. bei "''W: GPG error: stable InRelease: The following signatures were invalid: EXPKEYSIG 23E7166788B63E1E Yarn Packaging <yarn@dan.cx>''" ====
Treten während eines docker:init neue, merkwürdige und nicht näher spezifizierbare Fehler auf, kann es helfen, die Dockercontainer neu zu initialisieren mittels:
docker-compose build --pull

==== [veraltet] Fehler "The stream or file "/application/htdocs/var/logs/dev/dev.log" could not be opened: failed to open stream: Permission denied" oder ähnlich (betrifft Legacy-Testsystem) ====
==== [veraltet] Oder: Fehler "Permission denied" beim Zugriff auf /htdocs/var/cache (betrifft Legacy-Testsystem) ====
==== [veraltet] Oder: Fehler 500 (ohne weitere Angaben, warum) (betrifft Legacy-Testsystem) ====
Hier scheint der Webserver keine Zugriffsberechtigung auf bestimmte Pfade/Dateien zu haben. Von einem Ändern der Zugriffsberechtigungen, z. B. mittels sudo chmod -R 777 ./var/log, sollte aus Sicherheitsgründen aber Abstand genommen werden.

Helfen kann, die Befehlsfolge
./psh.phar docker:ssh
./psh.phar docker:init
exit
ein weiteres Mal auszuführen.

Falls dies weiterhin keinen Erfolg bringt, können folgende Schritte zum Ändern der Zugriffsberechtigungen angewandt werden:
# Ermitteln der ID des Containers oc-server3_php-fpm mittels sudo docker ps.
# Öffnen einer Shell im Container: sudo docker exec -it 45b6e4994fac /bin/bash, wobei 45b6e4994fac die ID des Containers ist.
# In der Container-Shell chmod -R 777 /application/htdocs/var/logs/dev/ ausführen.
# Die Container-Shell regulär mittels exit verlassen.

==== [veraltet] Fehler "starting opencaching-webserver .. error" oder "Starting webserver ... error" ====
Vermutlich läuft im Hintergrund bereits ein anderer Webservice auf Port 80.

Prüfen kann man das mit:
netstat -tanp | grep :80

Zum Beispiel ein apache2-Webserver kann gestoppt werden mit:
sudo systemctl stop apache2

Damit der apache2 nach einem Rechnerneustart nicht erneut aktiviert wird, kann man ihn generell deaktivieren:
sudo systemctl disable apache2

Alternativ lässt sich auch eine [[https://docs.docker.com/compose/extends/|Override-Datei]] für die betroffenen Ports verwenden, was allerdings weitere Komplikationen mit sich führen kann (wie beispielsweise eine nicht funktionierende OKAPI). Aus diesem Grund sollte nach Möglichkeit das Stoppen der Standard-Services für Apache und einen Datenbank-Server vorgezogen werden.

==== [veraltet] Fehler "W: GPG error: https://dl.yarnpkg.com/debian stable InRelease: The following signatures were invalid: EXPKEYSIG" ====
Nach dem Ausführen von ./psh.phar docker:start kommt der Fehler. Hier ist das Zertifikat veraltet. Folgender Befehl löscht das Docker-Image.
docker-compose build --pull

Mit einen erneuten ./psh.phar docker:start läuft es wieder durch.

==== [veraltet] Host-Mismatch bei Aufruf der OKAPI mit Port-Override ====
Falls in einer Override-Datei Ports überschrieben werden (siehe oben), funktioniert die OKAPI möglicherweise nicht richtig - stattdessen erscheint ein Hinweis auf einen Port-Mismatch. Dies kann auf folgende Art und Weise behoben werden:
# Ermitteln der ID des Containers ''oc-server3_php-fpm'' mittels ''sudo docker ps''.
# Öffnen einer Shell im Container: ''sudo docker exec -it 45b6e4994fac /bin/bash'', wobei 45b6e4994fac die ID des Containers ist.
# Im Container einen Editor installieren, beispielsweise nano. Da der Container auf Ubuntu basiert, funktioniert dies mittels ''apt-get update && apt-get install nano''.
# Die passende Konfigurationsdatei mittels des Editors im Container öffnen, beispielsweise mittels ''nano /application/htdocs/config2/settings.inc.php.''
# Setzen von ''$dev_baseurl = 'http://docker.team-opencaching.de:2200';'' und anschließendes Speichern der Datei. Hierbei ist 2200 der Port, der statt Port 80 für den Webserver in der Override-Datei konfiguriert worden ist.

==== [veraltet] Meldung "DEPRECATED: The legacy builder is deprecated and will be removed in a future release. Install the buildx component to build images with [[https://docs.docker.com/go/buildx/|BuildKit]]" ====
Der Docker build Prozess wurde geändert. Die bisherige Methode wurde ab Dockerversion 23 als "deprecated" markiert und wird in einer zukünftigen Version entfernt. Siehe [[https://docs.docker.com/engine/deprecated/#legacy-builder-for-linux-images|Deprecated Engine Features]]

==== [veraltet] Meldung "ERROR: BuildKit is enabled but the buildx component is missing or broken." ====
Docker Buildkit/buildx soll verwendet werden (DOCKER_BUILDKIT=1), wurde aber nicht installiert.

Abhilfe: Buildkit/buildx Komponente installieren. Vorher müssen aber einige bereits installierte Pakete entfernt werden. Je nach OS gibt es unterschiedliche Anweisungen und Installationswege, siehe hier: [[https://docs.docker.com/engine/install/|Install Docker Engine]]

==== [veraltet] Während docker:init kommt es im Abschnitt (3/31) zu einer Meldung "> mysql -uroot -proot -hmariadb -e "DROP DATABASE IF EXISTS opencaching" ERROR 2005 (HY000): Unknown MySQL server host 'mariadb' (-3)." ====
Abhilfe: ''./psh.phar docker:init'' darf nicht außerhalb des Dockercontainers aufgerufen werden.

==== [veraltet] Während docker:init kommt es im Abschnitt (13/31) zu einer Meldung "PHP Fatal error: .. __toString() must not throw an exception .." ====
Die Ursache ist nicht bekannt. Hier hilft aktuell nur ein Workaround, in dem die Exception im Script auskommentiert wird.

Hierzu in der Datei ''../htdocs/vendor/symfony/symfony/src/Symfony/Component/DependencyInjection/Compiler/AutowirePass.php'' die Zeile 236 ''throw new AutoWiringFailedException'' auskommentieren. Die Datei ist allerdings erst nach dem Ausführens von docker:init vorhanden.

Siehe auch Ticket: [[https://opencaching.atlassian.net/browse/OCC-90|OCC-90: Exception error during docker:init]]

==== [veraltet] Während docker:start-clean: ''"\Doctrine\Common\Persistence\Mapping\Driver\MappingDriverChain()" not found'' ====
Dies ist ein Fehler in einem der ''doctrine/*'' Pakete (vermutlich ''doctrine/persistence'') in bestimmten Paketversionen. Hier hilft, die Datei ''/htdocs/vendor/doctrine/doctrine-bundle/Resources/config/orm.xml'' Zeile 32 zu editieren:
<parameter key="doctrine.orm.metadata.driver_chain.class">Doctrine\Common\Persistence\Mapping\Driver\MappingDriverChain</parameter>
zu
<parameter key="doctrine.orm.metadata.driver_chain.class">Doctrine\Persistence\Mapping\Driver\MappingDriverChain</parameter>

Allerdings muss dies zum richtigen Zeitpunkt passieren. Nachdem ''docker:start-clean'' aufgerufen wurde, kurz warten, bis die Pakete heruntergeladen wurden und noch bevor Abschnitt 13/32 anfängt, muss die Datei korrigiert und gespeichert worden sein.

==== [veraltet] Während docker:start-clean: ''"Browserslist: caniuse-lite is outdated."'' ====
Scheinbar wird die "browserslist" nicht automatisch aktualisiert. (Grund? k.A.)

Zum manuellen Update im Docker:ssh eingeben:
npx browserslist@latest --update-db
bzw.
npx update-browserslist-db@latest

==== [veraltet] z.B. bei Update auf Symfony 5.2 kommt während docker:start-clean der Fehler ''"mv: cannot stat '/root/.symfony/bin/symfony': No such file or directory Service 'webserver' failed to build: The command '/bin/sh -c mv /root/.symfony/bin/symfony /usr/local/bin/symfony' returned a non-zero code: 1"'' ====
In diesem Fall in der Datei ''docker/httpd/Dockerfile'' die fehlerverursachende Zeile
RUN mv /root/.symfony/bin/symfony /usr/local/bin/symfony
auskommentieren und docker:start-clean erneut laufen lassen.

[[Kategorie:Entwicklung|Fehlerhandbuch ]]

Entwicklungsumgebung/Fehlerhandbuch

2026-03-30T06:06:49Z

Fraggle: Umsortierung und neu: yarn-Meldung

Während der Installation der Programme oder Einrichtung der Testumgebung kann es zu diversen Fehlern und Meldungen kommen. Im Folgenden sind bereits bekannte Meldungen aufgelistet, die bei einer schnellen Behebung helfen sollen.

== Fehlermeldungen während der Paketinstallation ==
==== Während der Installation der benötigten Pakete, kommt es zu einer Meldung, dass Abhängigkeiten mit dem ‘libdvd-pkg’ Paket nicht aufgelöst werden können ====

Eine Rekonfiguration des Pakets schafft Abhilfe:
<nowiki>sudo dpkg-reconfigure libdvd-pkg</nowiki>

== Fehlermeldungen in Zusammenhang mit der DDEV-Testumgebung ==
==== Fehler “ERROR: for opencaching-mariadb Cannot start service mariadb: driver failed programming external connectivity on endpoint opencaching-mariadb [..] Error starting userland proxy: listen tcp 0.0.0.0:3306: bind: address already in use” ====
Wenn beim 'ddev start' diese Fehlermeldung kommt, läuft im Hintergrund bereits ein anderer Webservice (z.B. mysql) auf Port 3306.

Prüfen kann man das mit:
netstat -tanp | grep :3306

Zum Beispiel ein mysql-Webserver kann gestoppt werden mit:
sudo mysqladmin -u root shutdown

==== Yarn Fehlermeldung “[DEP0169] DeprecationWarning: `url.parse()` behavior is not standardized and prone to errors that have security implications. Use the WHATWG URL API instead. CVEs are not issued for `url.parse()` vulnerabilities.” ====
Diese Meldung hat keine funktionelle Einschränkung und kann aktuell ignoriert werden.

Hintergrund: Seit nodejs Version 22 wird die Funktion url.parse() als veraltet markiert. Yarn 1.xx nutzt sie, wird wohl aber kein Update mehr erhalten. In Yarn 2+ ist das Problem behoben, allerdings ist ein Umstieg mit größeren Aufwänden verbunden und wird aktuell nicht forciert.

== Fehlermeldungen beim Zugriff auf die Datenbank ==
==== Fehlermeldung “ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)” ====
Es wurde vergessen, den Namen der Datenbank in der Kommandozeile zu übergeben.
mysql -uroot -proot -hopencaching-db opencaching

== Fehlermeldungen beim Zugriff auf die Testserverdomain(s) ==
==== Beim Anlegen/Editieren eines Listings funktioniert die Attributeauswahl nicht (betrifft Legacy-Testsystem) ====
Editiert man ein Listing, stehen nicht alle Attribute zur Verfügung bzw. es können nicht alle Attribute ausgewählt werden.

Abhilfe: (noch) keine Ahnung.

==== Ein neu angelegter Benutzer kann sich nicht einloggen und wird immer wieder ohne Meldung auf die Login-Seite geleitet (betrifft Legacy-Testsystem) ====
Die exakte Ursache ist nicht bekannt. Abhilfe kann geschaffen werden, wenn beim entsprechenden Nutzer in der Datenbank in der Tabelle ''user'' das Feld ''permanent_login_flag'' auf ''1'' gesetzt wird.

==== Es kann kein Logbild hochgeladen werden (betrifft Legacy-Testsystem) ====
Sobald man ein Logbild hochladen möchte, erscheint eine Fehlermeldung
<nowiki>Warning: move_uploaded_file(): Unable to move '/tmp/phpGmSzpi' to '/application/htdocs/config2/../images/uploads/700770A6-C101-11EA-BA77-0242AC120005.jpg' in /application/htdocs/lib2/logic/picture.class.php on line 856</nowiki>
Abhilfe: (noch) keine Ahnung. Die Bilder wurden aber trotzdem hochgeladen.

==== Es kann nicht auf die Domains opencaching.ddev.site oder try-opencaching.ddev.site zugegriffen werden. ====
Normalerweise sollte der Zugriff nach Installation der Testumgebung automatisch funktionieren. Sollte das nicht der Fall sein, kann mittels Anpassung der hosts-Datei ein Workaround geschaffen werden:
<nowiki>127.0.0.1 opencaching.ddev.site
127.0.0.1 try-opencaching.ddev.site</nowiki>

==== Abschalten von “NOTICE”-Meldungen. (betrifft Legacy-Testsystem) ====
Aufgrund diverser (Smarty- und PHP-)Updates werden vormals ignorierte Probleme nun mit einer “NOTICE”-Meldung kenntlich gemacht. Um die Meldungen zu unterdrücken, kann in das error_reporting Level geändert werden.

Beispiele für Fehlermeldungen:
<nowiki>Notice: Undefined index: error_password_not_ok in /app/htdocs/var/cache2/smarty/compiled/..
Notice: Trying to get property 'value' of non-object in /app/..</nowiki>

Abhilfe:
Bis Smarty 3.x: In der Datei /htdocs/vendor/smarty/smarty/libs/Smarty.class.php die Zeile mit $error_reporting ändern auf den nachfolgenden Code. Die Änderung ist nicht git-relevant und geht nach jedem “ddev init” verloren.
<nowiki>public $error_reporting = E_ALL & ~E_NOTICE;</nowiki>

Ab Smarty 3.x und 4.x: In der Datei /htdocs/lib2/common.inc.php die obere Zeile (PHP_DEBUG_ON) mit $error_reporting ändern auf den nachfolgenden Code. Die Änderung ist permanent und muss vor einem Commit rückgängig gemacht werden, da sie sonst im github Repository landet.
<nowiki>ini_set('error_reporting', E_ALL & ~E_NOTICE);</nowiki>

==== Vorgehen zum Anlegen eines weiteren Benutzers (betrifft Legacy-Testsystem) ====
Zuerst via https://opencaching.ddev.site/register.php einen neuen Nutzer registrieren. Zwar kommt dann die Meldung, dass der Aktivierungscode per Mail zugsandt wurde, dies passiert aber nie. Der Aktivierungscode muss aus der Test-Datenbank ausgelesen werden.
Der Code steht in Tabelle ''user'' im Feld ''activation_code''.

Mit https://opencaching.ddev.site/activation.php gelangt man zur Account-Aktivierungsseite. Hier die E-Mail-Adresse und den aus der Datenbank kopierten Aktivierungscode eingeben. Der Account ist nun aktiviert, aber falls der Login nicht funktioniert: siehe andere Fehlermeldung hier auf der Seite weiter unten.

Info: Eventuell wird in Zukunft der MailHog zum Laufen gebracht. Dann werden die vom Server verschickten Emails von diesem abgefangen und man kann die Informationen darin lesen.

== gelöste und veraltete Fehlermeldungen ==
==== [veraltet] Beim Anlegen des ''zweiten'' Cachelistings kommt eine Fehlermeldung (betrifft Legacy-Testsystem) ====
Bei einer ''leeren'' Datenbank funktioniert das Setzen und Hochzählen der OC-Codes nicht. Es muss einmal ein OC-Code von Hand gesetzt werden.

Hierzu auf dem Testserver ein Listing anlegen. Dann für diesen Cache in der Datenbank in der Tabelle ''caches'' das Feld ''wp_oc'' auf einen initialen Wert ändern, z.B. ''OC1234''.

==== [veraltet] Beim Erstellen/Speichern eines Cachelistings kommen mehrere Fehlermeldungen, u.a. "Warning: A non-numeric value encountered in /app/htdocs/newcache.php on line 1025" (betrifft Legacy-Testsystem) ====
[[Image:Fehlerhandbuch Domain 01.png|500px]]

Zuerst muss geschaut werden, ob eventuell der vorige Abschnitt ("Beim Anlegen des zweiten Cachelistings kommt eine Fehlermeldung") zutrifft. Wurden die dort beschriebenen Maßnahmen bereits umgesetzt, kommt es zwar trotzdem zur Fehlermeldung, das Listing wurde aber erfolgreich angelegt bzw. gespeichert. (Seite neu laden)

==== [gelöst] Beim Löschen von Logs kommt eine Fehlermeldung "This log entry has been created on another Opencaching website. The cache can only be edited there." ====
Auf dem Testserver werden die Logs laut Datenbank (Tabelle ''cache_logs'', Spalte ''nodes'') als ''node=5'' gespeichert, obwohl es laut Tabelle ''nodes'' diese Ziffer gar nicht gibt.

Um Logs wieder über die normale Loglöschenfunktion löschen zu können, gibt es mehrere Möglichkeiten:
# In der Datenbanktabelle 'cache_logs' den Eintrag in Spalte 'nodes' auf 4 ändern. (Dies entspricht der 'Local Development'-Umgebung (siehe Tabelle 'nodes')).
# In der Datei '/dev-ops/local.team-opencaching.de/templates/config2-settings.inc.tpl.php' den Eintrag '$opt['logic']['node']['id'] = 5;' ändern auf '$opt['logic']['node']['id'] = 4;' und das docker:init Script ausführen
# Der Pull [[https://github.com/OpencachingDeutschland/oc-server3/pull/830|Pull Request #830 changed node information from 5 to 4]] behebt das Problem.

==== [veraltet] Das Länderauswahlfeld rechts oben auf der Seite ist leer und funktioniert nicht. (betrifft Legacy-Testsystem) ====
Alle php-Dateien im Cacheverzeichnis htdocs/var/cache2 müssen gelöscht werden.

Das Vorgehen Unter Linux:
<nowiki>./psh.phar docker:stop
rm htdocs/var/cache2/*.inc.php
./psh.phar docker:start</nowiki>

==== [gelöst] Die Übersetzungen funktionieren nicht. Meist wird nur Englischer Text angezeigt. (betrifft Legacy-Testsystem) ====
Die vorhandenen Fremdsprachen werden auf dem Testsystem nicht korrekt dargestellt. Meistens wird nur der Englische Text oder ein Mischmasch aus Englisch und eingestellter Sprache angezeigt.

Abhilfe: im docker:start Skript wurde eine fehlende Komponente ergänzt, welche nun automatisch mitinstalliert wird. Dadurch werden die Sprachdateien korrekt erzeugt und die Übersetzungen funktionieren.

Siehe auch: [[https://opencaching.atlassian.net/browse/RED-1278|RED-1278: Die Übersetzungen funktionieren auf dem Testserver nicht]]
Dieser Fehler sollte somit nicht mehr auftauchen.

==== [veraltet] Docker Services neu initialisieren, z.B. bei "''W: GPG error: stable InRelease: The following signatures were invalid: EXPKEYSIG 23E7166788B63E1E Yarn Packaging <yarn@dan.cx>''" ====
Treten während eines docker:init neue, merkwürdige und nicht näher spezifizierbare Fehler auf, kann es helfen, die Dockercontainer neu zu initialisieren mittels:
docker-compose build --pull

==== [veraltet] Fehler "The stream or file "/application/htdocs/var/logs/dev/dev.log" could not be opened: failed to open stream: Permission denied" oder ähnlich (betrifft Legacy-Testsystem) ====
==== [veraltet] Oder: Fehler "Permission denied" beim Zugriff auf /htdocs/var/cache (betrifft Legacy-Testsystem) ====
==== [veraltet] Oder: Fehler 500 (ohne weitere Angaben, warum) (betrifft Legacy-Testsystem) ====
Hier scheint der Webserver keine Zugriffsberechtigung auf bestimmte Pfade/Dateien zu haben. Von einem Ändern der Zugriffsberechtigungen, z. B. mittels sudo chmod -R 777 ./var/log, sollte aus Sicherheitsgründen aber Abstand genommen werden.

Helfen kann, die Befehlsfolge
./psh.phar docker:ssh
./psh.phar docker:init
exit
ein weiteres Mal auszuführen.

Falls dies weiterhin keinen Erfolg bringt, können folgende Schritte zum Ändern der Zugriffsberechtigungen angewandt werden:
# Ermitteln der ID des Containers oc-server3_php-fpm mittels sudo docker ps.
# Öffnen einer Shell im Container: sudo docker exec -it 45b6e4994fac /bin/bash, wobei 45b6e4994fac die ID des Containers ist.
# In der Container-Shell chmod -R 777 /application/htdocs/var/logs/dev/ ausführen.
# Die Container-Shell regulär mittels exit verlassen.

==== [veraltet] Fehler "starting opencaching-webserver .. error" oder "Starting webserver ... error" ====
Vermutlich läuft im Hintergrund bereits ein anderer Webservice auf Port 80.

Prüfen kann man das mit:
netstat -tanp | grep :80

Zum Beispiel ein apache2-Webserver kann gestoppt werden mit:
sudo systemctl stop apache2

Damit der apache2 nach einem Rechnerneustart nicht erneut aktiviert wird, kann man ihn generell deaktivieren:
sudo systemctl disable apache2

Alternativ lässt sich auch eine [[https://docs.docker.com/compose/extends/|Override-Datei]] für die betroffenen Ports verwenden, was allerdings weitere Komplikationen mit sich führen kann (wie beispielsweise eine nicht funktionierende OKAPI). Aus diesem Grund sollte nach Möglichkeit das Stoppen der Standard-Services für Apache und einen Datenbank-Server vorgezogen werden.

==== [veraltet] Fehler "W: GPG error: https://dl.yarnpkg.com/debian stable InRelease: The following signatures were invalid: EXPKEYSIG" ====
Nach dem Ausführen von ./psh.phar docker:start kommt der Fehler. Hier ist das Zertifikat veraltet. Folgender Befehl löscht das Docker-Image.
docker-compose build --pull

Mit einen erneuten ./psh.phar docker:start läuft es wieder durch.

==== [veraltet] Host-Mismatch bei Aufruf der OKAPI mit Port-Override ====
Falls in einer Override-Datei Ports überschrieben werden (siehe oben), funktioniert die OKAPI möglicherweise nicht richtig - stattdessen erscheint ein Hinweis auf einen Port-Mismatch. Dies kann auf folgende Art und Weise behoben werden:
# Ermitteln der ID des Containers ''oc-server3_php-fpm'' mittels ''sudo docker ps''.
# Öffnen einer Shell im Container: ''sudo docker exec -it 45b6e4994fac /bin/bash'', wobei 45b6e4994fac die ID des Containers ist.
# Im Container einen Editor installieren, beispielsweise nano. Da der Container auf Ubuntu basiert, funktioniert dies mittels ''apt-get update && apt-get install nano''.
# Die passende Konfigurationsdatei mittels des Editors im Container öffnen, beispielsweise mittels ''nano /application/htdocs/config2/settings.inc.php.''
# Setzen von ''$dev_baseurl = 'http://docker.team-opencaching.de:2200';'' und anschließendes Speichern der Datei. Hierbei ist 2200 der Port, der statt Port 80 für den Webserver in der Override-Datei konfiguriert worden ist.

==== [veraltet] Meldung "DEPRECATED: The legacy builder is deprecated and will be removed in a future release. Install the buildx component to build images with [[https://docs.docker.com/go/buildx/|BuildKit]]" ====
Der Docker build Prozess wurde geändert. Die bisherige Methode wurde ab Dockerversion 23 als "deprecated" markiert und wird in einer zukünftigen Version entfernt. Siehe [[https://docs.docker.com/engine/deprecated/#legacy-builder-for-linux-images|Deprecated Engine Features]]

==== [veraltet] Meldung "ERROR: BuildKit is enabled but the buildx component is missing or broken." ====
Docker Buildkit/buildx soll verwendet werden (DOCKER_BUILDKIT=1), wurde aber nicht installiert.

Abhilfe: Buildkit/buildx Komponente installieren. Vorher müssen aber einige bereits installierte Pakete entfernt werden. Je nach OS gibt es unterschiedliche Anweisungen und Installationswege, siehe hier: [[https://docs.docker.com/engine/install/|Install Docker Engine]]

==== [veraltet] Während docker:init kommt es im Abschnitt (3/31) zu einer Meldung "> mysql -uroot -proot -hmariadb -e "DROP DATABASE IF EXISTS opencaching" ERROR 2005 (HY000): Unknown MySQL server host 'mariadb' (-3)." ====
Abhilfe: ''./psh.phar docker:init'' darf nicht außerhalb des Dockercontainers aufgerufen werden.

==== [veraltet] Während docker:init kommt es im Abschnitt (13/31) zu einer Meldung "PHP Fatal error: .. __toString() must not throw an exception .." ====
Die Ursache ist nicht bekannt. Hier hilft aktuell nur ein Workaround, in dem die Exception im Script auskommentiert wird.

Hierzu in der Datei ''../htdocs/vendor/symfony/symfony/src/Symfony/Component/DependencyInjection/Compiler/AutowirePass.php'' die Zeile 236 ''throw new AutoWiringFailedException'' auskommentieren. Die Datei ist allerdings erst nach dem Ausführens von docker:init vorhanden.

Siehe auch Ticket: [[https://opencaching.atlassian.net/browse/OCC-90|OCC-90: Exception error during docker:init]]

==== [veraltet] Während docker:start-clean: ''"\Doctrine\Common\Persistence\Mapping\Driver\MappingDriverChain()" not found'' ====
Dies ist ein Fehler in einem der ''doctrine/*'' Pakete (vermutlich ''doctrine/persistence'') in bestimmten Paketversionen. Hier hilft, die Datei ''/htdocs/vendor/doctrine/doctrine-bundle/Resources/config/orm.xml'' Zeile 32 zu editieren:
<parameter key="doctrine.orm.metadata.driver_chain.class">Doctrine\Common\Persistence\Mapping\Driver\MappingDriverChain</parameter>
zu
<parameter key="doctrine.orm.metadata.driver_chain.class">Doctrine\Persistence\Mapping\Driver\MappingDriverChain</parameter>

Allerdings muss dies zum richtigen Zeitpunkt passieren. Nachdem ''docker:start-clean'' aufgerufen wurde, kurz warten, bis die Pakete heruntergeladen wurden und noch bevor Abschnitt 13/32 anfängt, muss die Datei korrigiert und gespeichert worden sein.

==== [veraltet] Während docker:start-clean: ''"Browserslist: caniuse-lite is outdated."'' ====
Scheinbar wird die "browserslist" nicht automatisch aktualisiert. (Grund? k.A.)

Zum manuellen Update im Docker:ssh eingeben:
npx browserslist@latest --update-db
bzw.
npx update-browserslist-db@latest

==== [veraltet] z.B. bei Update auf Symfony 5.2 kommt während docker:start-clean der Fehler ''"mv: cannot stat '/root/.symfony/bin/symfony': No such file or directory Service 'webserver' failed to build: The command '/bin/sh -c mv /root/.symfony/bin/symfony /usr/local/bin/symfony' returned a non-zero code: 1"'' ====
In diesem Fall in der Datei ''docker/httpd/Dockerfile'' die fehlerverursachende Zeile
RUN mv /root/.symfony/bin/symfony /usr/local/bin/symfony
auskommentieren und docker:start-clean erneut laufen lassen.

[[Kategorie:Entwicklung|Fehlerhandbuch ]]

Entwicklungsumgebung einrichten

2026-03-04T17:15:08Z

Fraggle: Ergänzung Mailpit

Das Einrichten der Testumgebung erfolgt in mehreren Schritten, die im folgenden beschrieben sind. Falls es dabei zu unerwarteten Fehlermeldungen kommt, bitte die letzten Schritte noch einmal genau anschauen und gegebenenfalls wiederholen. Auch ein Blick ins Fehlerhandbuch hilft meistens, da bereits viele Fallstricke entdeckt und beschrieben wurden.

== 1. Das Betriebssystem vorbereiten, entweder Linux oder Windows ==
=== Windows 10 ===
==== Programme installieren ====
Unter Windows ist es standardmäßig nicht möglich, “einfach“ die Linux Distribution Ubuntu zu installieren. Dazu muss vorab erst das WSL2 aktiviert / installiert werden werden (Punkt 1). Im Anschluss ist eine Installation von Ubuntu (18.04 oder höher) möglich. Zudem muss DDEV installiert werden, in welchem dann die Entwicklungsumgebung laufen kann (Punkt 2).

# WSL2 unter Windows10 aktivieren und Ubuntu installieren:
## Aus dem Microsoft-Store: https://aka.ms/wslstorepage (verfügbar seit Nov. 2022)
## Manuell unter [https://learn.microsoft.com/de-de/windows/wsl/install#manual-installation-steps|Installieren von WSL]
# DDEV für Windows installieren: [https://docs.ddev.com/en/stable/#system-requirements-windows-wsl2|Install DDEV WSL2]

Danach kann Ubuntu gestartet werden (z.B. im “Such“-Menü nach Ubuntu suchen und anklicken). Beim erstmaligen Starten von Ubuntu müssen ein Benutzername und ein Passwort festgelegt werden.

Im Anschluss den Punkten folgen und ausführen, die im nächsten Schritt “Linux” beschrieben werden.

=== Linux ===
Der Linuxartikel wurde erstellt auf Lubuntu 22.04 und erweitert mit Debian 12

==== Programme installieren ====
Folgende Programme sind notwendig und müssen vorab installiert werden:
PHP (aktuell mindestens PHP8.2), diverse PHP-Erweiterungen, ddev, mariadb-client. Für die PHP-Erweiterungen ist eventuell ein zusätzliches PPA-Repository notwendig. Dessen Installation erfordert je nach Betriebssystem ein unterschiedliches Vorgehen.

<nowiki>Ubuntu:
sudo apt install software-properties-common
sudo add-apt-repository ppa:ondrej/php

Debian:
sudo apt install software-properties-common ca-certificates lsb-release apt-transport-https
curl -sSL https://packages.sury.org/php/README.txt | sudo bash -x</nowiki>

Die Pakete lassen sich mit folgenden Befehlen installieren (Versionsnummer kann abweichen).
<nowiki>sudo apt update
sudo apt install php8.2 php8.2-mbstring php8.2-curl php8.2-xml php8.2-mysql
sudo apt install mariadb-client
sudo apt install ddev</nowiki>

Sollten beim Installieren der Pakete Fehlermeldungen auftreten, ist es empfehlenswert, die Pakete einzeln zu installieren und auftretende Fehler/Abhängigkeiten einzeln zu lösen.

== 2. Sourcecode von Git laden ==
=== Github ===
Zwar ist zum Herunterlden des Sourcecodes keine Account auf GitHub notwendig, aber zum Hochladen wird einer benötigt. Daher sollte zuerst einen Account auf https://github.com/ angelegt werden.

=== optional: SSH-Keys für Repositorys anlegen und in Github eintragen ===
siehe https://docs.github.com/en/free-pro-team@latest/github/authenticating-to-github/connecting-to-github-with-ssh 
oder: https://www.heise.de/tipps-tricks/SSH-Key-fuer-GitHub-Repositories-einrichten-4627459.html

=== Git lokal installieren ===
Windows: 
siehe: https://github.com/git-for-windows/git/releases 

Linux:
<nowiki>sudo apt install git</nowiki>

=== Sourcecode lokal herunterladen ===
Ein Terminal öffnen, folgende Kommandos ausführen und dabei Namen und Email-Adresse des Git-Accounts eintragen:
<nowiki>git config --local user.name "Your Name Here"
git config --local user.email "your_email@youremail.com"</nowiki>

Im Verzeichnis "home" einen Ordner "opencaching" (Name beliebig) anlegen. Dort folgenden Code ausführen. Dies legt einen Ordner mit dem Namen “oc-server3“ an, lädt den OC-Code aus deinem Github-Fork herunter und kopiert ihn in diesen Ordner.
<nowiki>git clone git@github.com:<DeinGithubBenutzername>/oc-server3</nowiki>

Im Anschluss in den Ordner “oc-server3“ wechseln und den folgenden Befehl ausführen, um bei einem Update den neuesten Sourcecode aus dem Opencaching.de-Repository erhalten zu können:
<nowiki>cd oc-server3
git remote add upstream git@github.com:OpencachingDeutschland/oc-server3</nowiki>

Mit folgendem Befehl gibt es eine Übersicht über die verknüpften Repositorys, die (abgesehen vom Nutzernamen ‘Slini11’) wie in der Grafik aussehen müssen:
<nowiki>git remote -v</nowiki>
[[Image:Testumgebung Git 01.png]]

Nun den Branch “development“ auschecken:
<nowiki>git checkout development</nowiki>

Und den Development-Branch auf aktuellen Stand bringen:
<nowiki>git pull --rebase upstream development </nowiki>

=== Weiterführende Informationen zu Git ===
Diese sind unter anderem im [[Entwicklung/Git|OC-Wiki]] zu finden

== 3. DDEV Entwicklungsumgebung initalisieren ==
=== Entwicklungsumgebung zum ersten Mal starten ===
Zuerst in den Projektordner “oc-server3“ navigieren und dort die Installation der Testumgebung starten.

==== Scripte einzeln ausführen ====
* ddev anstarten. Im Laufe dieses Prozesses wird die hosts-Datei automatisch angepasst.
<nowiki>ddev start</nowiki>

* Starten der Initialisierung der Testumgebung und der Datenbank:
<nowiki>ddev init</nowiki>

* Die Entwicklungsumgebung steht nun über den Browser bereit unter:
https://opencaching.ddev.site
bzw.
https://try-opencaching.ddev.site

Das Passwort für den Benutzer ''root'' lautet ''developer''. Das Passwort der anderen Benutzer (Benutzernamen siehe Datenbank) lautet ''password''

* Ein Mailpit steht nun über den Browser bereit (zumindest für den Legacy-Teil, für OC4 ist es noch nicht bestätigt) unter:
https://opencaching.ddev.site:8026/

=== Entwicklungsumgebung ein weiteres Mal starten ===
Die Testumgebung kann neugestartet werden mit:
<nowiki>ddev restart</nowiki>

=== Entwicklungsumgebung stoppen ===
Die Testumgebung kann gestoppt werden mit:
<nowiki>ddev stop</nowiki>

=== Entwicklungsumgebung löschen ===
Die Testumgebung kann im Projektordner gelöscht werden mit:
<nowiki>ddev delete --omit-snapshot</nowiki>
Danach sind ein erneutes ''ddev start'' und ''ddev init'' notwendig.

=== von DDEV angelegte Objekte löschen und Projekte aus der globalen DDEV-Liste löschen ===
<nowiki>ddev clean --all</nowiki>
<nowiki>ddev stop --unlist opencaching</nowiki>

=== xdebug in der Entwicklungsumgebung starten ===
<nowiki>ddev xdebug</nowiki>
Ein ''ddev start'' oder ''ddev restart'' deaktiviert das xdebug wieder.

=== Weitere ddev-Optionen.. ===
''ddev'' ohne Parameter aufrufen gibt eine Liste weiterer Optionen aus.
<nowiki>ddev</nowiki>

== 4. Die Testdatenbank füllen ==
Während der Installation wird eine Testdatenbank importiert, die bereits eine kleine Menge an Caches und Nutzern beinhaltet. Ein manueller Import des Datenbankdumps ist somit (seit März 2021) nicht mehr notwendig.

Für den Fall, dass trotzdem Daten exportiert / importiert werden sollen, können folgende Abschnitte berücksichtigt werden:

=== Login auf der Test-Datenbank im ddev-Container ===
<nowiki>mysql -uroot -proot -hopencaching-db opencaching</nowiki>

=== Datenbank innerhalb des ddev-Containers exportieren ===
<nowiki>mysqldump -uroot -proot -hopencaching-db opencaching > file.sql</nowiki>

=== Datenbank außerhalb des ddev-Containers exportieren ===
<nowiki>mysqldump --complete-insert --user root -proot --host 0.0.0.0 opencaching > dump.sql</nowiki>

=== Datenbank im phpStorm exportieren ===
Auf der rechten Bildschirmseite den Databasedialog ausklappen
rechte Maustaste auf die zu exportierende Datenbank “opencaching” => “Export with ‘mysqldump’”

[[Image:Testumgebung DB 01.png]]

Im Exportmenü die Zeile “Statements” umstellen auf “Insert with columns” und eventuell den Ausgabepfad “Out Path” anpassen. Im Kommandofeld den Parameter “--routines“ ergänzen und dann “Run” drücken

[[Image:Testumgebung DB 02.png]]

=== Datenbank-Dump im phpStorm importieren ===
Auf der rechten Bildschirmseite den Databasedialog ausklappen
rechte Maustaste auf die Datenbank => “Restore with ‘mysql’”

[[Image:Testumgebung DB 03.png]]

Im Importmenü den Eingabepfad “Path to dump” anpassen, dann “Run” drücken

[[Image:Testumgebung DB 04.png]]

== 5. Die Entwicklungs-IDE vorbereiten ==
Gegebenenfalls sind an der Programmierumgebung Änderungen vorzunehmen, um zum Beispiel [[OC Coding Style|einheitlich formatierten Code]] zu schreiben.

=== Einrichtung des PHP Coding Styles am Beispiel von phpStorm ===
Unter Settings / Code Style / PHP rechts auf “Set from…” klicken und “PSR-12” auswählen. Die Einstellung mit “Apply” bestätigen.
(Weitere Informationen zum Coding Style sind [[OC Coding Style|hier im Wiki]] zu finden.)

[[Image:Testumgebung IDE 01.png|500px]]

=== Symfony Pfade am Beispiel phpStorm anpassen ===
[[Image:Testumgebung IDE 04.jpeg]]

=== Terminalanpassung am Beispiel phpStorm (für Windows-Nutzer) ===
[[Image:Testumgebung IDE 05.png]]

=== Datenbankanbindung in phpStorm aktivieren ===
Seit ddev als Umgebung genutzt wird, bietet sich das ddev-Plugin im phpStorm an. Es richtet z.B. den Zugang zur opencaching-Datenbank in der Testumgebung sowie weitere Einstellungen automatisch ein.
Hierzu im phpStorm im Menü Datei/Einstellungen.. zum Abschnitt ''Plugins'' navigieren, im Suchfeld ''ddev'' eintippen und das Plugin installieren.
[[Image:Testumgebung IDE 06.jpg]]

=== Synchronisieren/Wiederherstellen der Benutzereinstellungen mittels JetBrains-Server ===
Sofern man bei JetBrains einen Account hat, kann man mit diesem die Einstellungen der lokalen IDE synchronisieren und z.B. nach einer Neuinstallation von dort wiederherstellen.

Hierzu in der IDE rechts oben auf das Zahnrad klicken und “Settings Sync is off” auswählen.
[[Image:Testumgebung IDE 02.png]]

Im folgenden Fenster den Button “Enable Settings Sync” klicken und danach alle Einstellungen auswählen, die man sichern möchte. Ein Klick auf “Push Settings to Account” sichert die Einstellungen. Ein Klick auf “Get Settings from Account” stellt sie wieder her, sofern sie vorher dorthin gesichert wurden.
[[Image:Testumgebung IDE 03.png]]

== 6. Das Fehlerhandbuch lesen (gilt insbesondere für die Schritte #1-#4 :wink:) ==

Beireits bekannte Fehler werden im [[Entwicklungsumgebung/Fehlerhandbuch|Fehlerhandbuch]] beschrieben.

[[Kategorie:Entwicklung|Entwicklungsumgebung ]]

Entwicklungsumgebung einrichten

2026-03-04T14:10:09Z

Fraggle: Linux: ddev fehlte als Paket

Das Einrichten der Testumgebung erfolgt in mehreren Schritten, die im folgenden beschrieben sind. Falls es dabei zu unerwarteten Fehlermeldungen kommt, bitte die letzten Schritte noch einmal genau anschauen und gegebenenfalls wiederholen. Auch ein Blick ins Fehlerhandbuch hilft meistens, da bereits viele Fallstricke entdeckt und beschrieben wurden.

== 1. Das Betriebssystem vorbereiten, entweder Linux oder Windows ==
=== Windows 10 ===
==== Programme installieren ====
Unter Windows ist es standardmäßig nicht möglich, “einfach“ die Linux Distribution Ubuntu zu installieren. Dazu muss vorab erst das WSL2 aktiviert / installiert werden werden (Punkt 1). Im Anschluss ist eine Installation von Ubuntu (18.04 oder höher) möglich. Zudem muss DDEV installiert werden, in welchem dann die Entwicklungsumgebung laufen kann (Punkt 2).

# WSL2 unter Windows10 aktivieren und Ubuntu installieren:
## Aus dem Microsoft-Store: https://aka.ms/wslstorepage (verfügbar seit Nov. 2022)
## Manuell unter [https://learn.microsoft.com/de-de/windows/wsl/install#manual-installation-steps|Installieren von WSL]
# DDEV für Windows installieren: [https://docs.ddev.com/en/stable/#system-requirements-windows-wsl2|Install DDEV WSL2]

Danach kann Ubuntu gestartet werden (z.B. im “Such“-Menü nach Ubuntu suchen und anklicken). Beim erstmaligen Starten von Ubuntu müssen ein Benutzername und ein Passwort festgelegt werden.

Im Anschluss den Punkten folgen und ausführen, die im nächsten Schritt “Linux” beschrieben werden.

=== Linux ===
Der Linuxartikel wurde erstellt auf Lubuntu 22.04 und erweitert mit Debian 12

==== Programme installieren ====
Folgende Programme sind notwendig und müssen vorab installiert werden:
PHP (aktuell mindestens PHP8.2), diverse PHP-Erweiterungen, ddev, mariadb-client. Für die PHP-Erweiterungen ist eventuell ein zusätzliches PPA-Repository notwendig. Dessen Installation erfordert je nach Betriebssystem ein unterschiedliches Vorgehen.

<nowiki>Ubuntu:
sudo apt install software-properties-common
sudo add-apt-repository ppa:ondrej/php

Debian:
sudo apt install software-properties-common ca-certificates lsb-release apt-transport-https
curl -sSL https://packages.sury.org/php/README.txt | sudo bash -x</nowiki>

Die Pakete lassen sich mit folgenden Befehlen installieren (Versionsnummer kann abweichen).
<nowiki>sudo apt update
sudo apt install php8.2 php8.2-mbstring php8.2-curl php8.2-xml php8.2-mysql
sudo apt install mariadb-client
sudo apt install ddev</nowiki>

Sollten beim Installieren der Pakete Fehlermeldungen auftreten, ist es empfehlenswert, die Pakete einzeln zu installieren und auftretende Fehler/Abhängigkeiten einzeln zu lösen.

== 2. Sourcecode von Git laden ==
=== Github ===
Zwar ist zum Herunterlden des Sourcecodes keine Account auf GitHub notwendig, aber zum Hochladen wird einer benötigt. Daher sollte zuerst einen Account auf https://github.com/ angelegt werden.

=== optional: SSH-Keys für Repositorys anlegen und in Github eintragen ===
siehe https://docs.github.com/en/free-pro-team@latest/github/authenticating-to-github/connecting-to-github-with-ssh 
oder: https://www.heise.de/tipps-tricks/SSH-Key-fuer-GitHub-Repositories-einrichten-4627459.html

=== Git lokal installieren ===
Windows: 
siehe: https://github.com/git-for-windows/git/releases 

Linux:
<nowiki>sudo apt install git</nowiki>

=== Sourcecode lokal herunterladen ===
Ein Terminal öffnen, folgende Kommandos ausführen und dabei Namen und Email-Adresse des Git-Accounts eintragen:
<nowiki>git config --local user.name "Your Name Here"
git config --local user.email "your_email@youremail.com"</nowiki>

Im Verzeichnis "home" einen Ordner "opencaching" (Name beliebig) anlegen. Dort folgenden Code ausführen. Dies legt einen Ordner mit dem Namen “oc-server3“ an, lädt den OC-Code aus deinem Github-Fork herunter und kopiert ihn in diesen Ordner.
<nowiki>git clone git@github.com:<DeinGithubBenutzername>/oc-server3</nowiki>

Im Anschluss in den Ordner “oc-server3“ wechseln und den folgenden Befehl ausführen, um bei einem Update den neuesten Sourcecode aus dem Opencaching.de-Repository erhalten zu können:
<nowiki>cd oc-server3
git remote add upstream git@github.com:OpencachingDeutschland/oc-server3</nowiki>

Mit folgendem Befehl gibt es eine Übersicht über die verknüpften Repositorys, die (abgesehen vom Nutzernamen ‘Slini11’) wie in der Grafik aussehen müssen:
<nowiki>git remote -v</nowiki>
[[Image:Testumgebung Git 01.png]]

Nun den Branch “development“ auschecken:
<nowiki>git checkout development</nowiki>

Und den Development-Branch auf aktuellen Stand bringen:
<nowiki>git pull --rebase upstream development </nowiki>

=== Weiterführende Informationen zu Git ===
Diese sind unter anderem im [[Entwicklung/Git|OC-Wiki]] zu finden

== 3. DDEV Entwicklungsumgebung initalisieren ==
=== Entwicklungsumgebung zum ersten Mal starten ===
Zuerst in den Projektordner “oc-server3“ navigieren und dort die Installation der Testumgebung starten.

==== Scripte einzeln ausführen ====
* ddev anstarten. Im Laufe dieses Prozesses wird die hosts-Datei automatisch angepasst.
<nowiki>ddev start</nowiki>

* Starten der Initialisierung der Testumgebung und der Datenbank:
<nowiki>ddev init</nowiki>

* Die Entwicklungsumgebung steht nun über den Browser bereit unter:
https://opencaching.ddev.site
bzw.
https://try-opencaching.ddev.site

* Das Passwort für den Benutzer ''root'' lautet ''developer''. Das Passwort der anderen Benutzer (Benutzernamen siehe Datenbank) lautet ''password''

=== Entwicklungsumgebung ein weiteres Mal starten ===
Die Testumgebung kann neugestartet werden mit:
<nowiki>ddev restart</nowiki>

=== Entwicklungsumgebung stoppen ===
Die Testumgebung kann gestoppt werden mit:
<nowiki>ddev stop</nowiki>

=== Entwicklungsumgebung löschen ===
Die Testumgebung kann im Projektordner gelöscht werden mit:
<nowiki>ddev delete --omit-snapshot</nowiki>
Danach sind ein erneutes ''ddev start'' und ''ddev init'' notwendig.

=== von DDEV angelegte Objekte löschen und Projekte aus der globalen DDEV-Liste löschen ===
<nowiki>ddev clean --all</nowiki>
<nowiki>ddev stop --unlist opencaching</nowiki>

=== xdebug in der Entwicklungsumgebung starten ===
<nowiki>ddev xdebug</nowiki>
Ein ''ddev start'' oder ''ddev restart'' deaktiviert das xdebug wieder.

=== Weitere ddev-Optionen.. ===
''ddev'' ohne Parameter aufrufen gibt eine Liste weiterer Optionen aus.
<nowiki>ddev</nowiki>

== 4. Die Testdatenbank füllen ==
Während der Installation wird eine Testdatenbank importiert, die bereits eine kleine Menge an Caches und Nutzern beinhaltet. Ein manueller Import des Datenbankdumps ist somit (seit März 2021) nicht mehr notwendig.

Für den Fall, dass trotzdem Daten exportiert / importiert werden sollen, können folgende Abschnitte berücksichtigt werden:

=== Login auf der Test-Datenbank im ddev-Container ===
<nowiki>mysql -uroot -proot -hopencaching-db opencaching</nowiki>

=== Datenbank innerhalb des ddev-Containers exportieren ===
<nowiki>mysqldump -uroot -proot -hopencaching-db opencaching > file.sql</nowiki>

=== Datenbank außerhalb des ddev-Containers exportieren ===
<nowiki>mysqldump --complete-insert --user root -proot --host 0.0.0.0 opencaching > dump.sql</nowiki>

=== Datenbank im phpStorm exportieren ===
Auf der rechten Bildschirmseite den Databasedialog ausklappen
rechte Maustaste auf die zu exportierende Datenbank “opencaching” => “Export with ‘mysqldump’”

[[Image:Testumgebung DB 01.png]]

Im Exportmenü die Zeile “Statements” umstellen auf “Insert with columns” und eventuell den Ausgabepfad “Out Path” anpassen. Im Kommandofeld den Parameter “--routines“ ergänzen und dann “Run” drücken

[[Image:Testumgebung DB 02.png]]

=== Datenbank-Dump im phpStorm importieren ===
Auf der rechten Bildschirmseite den Databasedialog ausklappen
rechte Maustaste auf die Datenbank => “Restore with ‘mysql’”

[[Image:Testumgebung DB 03.png]]

Im Importmenü den Eingabepfad “Path to dump” anpassen, dann “Run” drücken

[[Image:Testumgebung DB 04.png]]

== 5. Die Entwicklungs-IDE vorbereiten ==
Gegebenenfalls sind an der Programmierumgebung Änderungen vorzunehmen, um zum Beispiel [[OC Coding Style|einheitlich formatierten Code]] zu schreiben.

=== Einrichtung des PHP Coding Styles am Beispiel von phpStorm ===
Unter Settings / Code Style / PHP rechts auf “Set from…” klicken und “PSR-12” auswählen. Die Einstellung mit “Apply” bestätigen.
(Weitere Informationen zum Coding Style sind [[OC Coding Style|hier im Wiki]] zu finden.)

[[Image:Testumgebung IDE 01.png|500px]]

=== Symfony Pfade am Beispiel phpStorm anpassen ===
[[Image:Testumgebung IDE 04.jpeg]]

=== Terminalanpassung am Beispiel phpStorm (für Windows-Nutzer) ===
[[Image:Testumgebung IDE 05.png]]

=== Datenbankanbindung in phpStorm aktivieren ===
Seit ddev als Umgebung genutzt wird, bietet sich das ddev-Plugin im phpStorm an. Es richtet z.B. den Zugang zur opencaching-Datenbank in der Testumgebung sowie weitere Einstellungen automatisch ein.
Hierzu im phpStorm im Menü Datei/Einstellungen.. zum Abschnitt ''Plugins'' navigieren, im Suchfeld ''ddev'' eintippen und das Plugin installieren.
[[Image:Testumgebung IDE 06.jpg]]

=== Synchronisieren/Wiederherstellen der Benutzereinstellungen mittels JetBrains-Server ===
Sofern man bei JetBrains einen Account hat, kann man mit diesem die Einstellungen der lokalen IDE synchronisieren und z.B. nach einer Neuinstallation von dort wiederherstellen.

Hierzu in der IDE rechts oben auf das Zahnrad klicken und “Settings Sync is off” auswählen.
[[Image:Testumgebung IDE 02.png]]

Im folgenden Fenster den Button “Enable Settings Sync” klicken und danach alle Einstellungen auswählen, die man sichern möchte. Ein Klick auf “Push Settings to Account” sichert die Einstellungen. Ein Klick auf “Get Settings from Account” stellt sie wieder her, sofern sie vorher dorthin gesichert wurden.
[[Image:Testumgebung IDE 03.png]]

== 6. Das Fehlerhandbuch lesen (gilt insbesondere für die Schritte #1-#4 :wink:) ==

Beireits bekannte Fehler werden im [[Entwicklungsumgebung/Fehlerhandbuch|Fehlerhandbuch]] beschrieben.

[[Kategorie:Entwicklung|Entwicklungsumgebung ]]

Entwicklungsumgebung einrichten

2026-02-25T12:34:33Z

Fraggle: +ddev --unlist

Das Einrichten der Testumgebung erfolgt in mehreren Schritten, die im folgenden beschrieben sind. Falls es dabei zu unerwarteten Fehlermeldungen kommt, bitte die letzten Schritte noch einmal genau anschauen und gegebenenfalls wiederholen. Auch ein Blick ins Fehlerhandbuch hilft meistens, da bereits viele Fallstricke entdeckt und beschrieben wurden.

== 1. Das Betriebssystem vorbereiten, entweder Linux oder Windows ==
=== Windows 10 ===
==== Programme installieren ====
Unter Windows ist es standardmäßig nicht möglich, “einfach“ die Linux Distribution Ubuntu zu installieren. Dazu muss vorab erst das WSL2 aktiviert / installiert werden werden (Punkt 1). Im Anschluss ist eine Installation von Ubuntu (18.04 oder höher) möglich. Zudem muss DDEV installiert werden, in welchem dann die Entwicklungsumgebung laufen kann (Punkt 2).

# WSL2 unter Windows10 aktivieren und Ubuntu installieren:
## Aus dem Microsoft-Store: https://aka.ms/wslstorepage (verfügbar seit Nov. 2022)
## Manuell unter [https://learn.microsoft.com/de-de/windows/wsl/install#manual-installation-steps|Installieren von WSL]
# DDEV für Windows installieren: [https://docs.ddev.com/en/stable/#system-requirements-windows-wsl2|Install DDEV WSL2]

Danach kann Ubuntu gestartet werden (z.B. im “Such“-Menü nach Ubuntu suchen und anklicken). Beim erstmaligen Starten von Ubuntu müssen ein Benutzername und ein Passwort festgelegt werden.

Im Anschluss den Punkten folgen und ausführen, die im nächsten Schritt “Linux” beschrieben werden.

=== Linux ===
Der Linuxartikel wurde erstellt auf Lubuntu 22.04 und erweitert mit Debian 12

==== Programme installieren ====
Folgende Programme sind notwendig und müssen vorab installiert werden:
PHP (aktuell mindestens PHP8.2), diverse PHP-Erweiterungen, ddev, mariadb-client. Für die PHP-Erweiterungen ist eventuell ein zusätzliches PPA-Repository notwendig. Dessen Installation erfordert je nach Betriebssystem ein unterschiedliches Vorgehen.

<nowiki>Ubuntu:
sudo apt install software-properties-common
sudo add-apt-repository ppa:ondrej/php

Debian:
sudo apt install software-properties-common ca-certificates lsb-release apt-transport-https
curl -sSL https://packages.sury.org/php/README.txt | sudo bash -x</nowiki>

Die Pakete lassen sich mit folgenden Befehlen installieren (Versionsnummer kann abweichen).
<nowiki>sudo apt update
sudo apt install php8.2 php8.2-mbstring php8.2-curl php8.2-xml php8.2-mysql
sudo apt install mariadb-client</nowiki>

Sollten beim Installieren der Pakete Fehlermeldungen auftreten, ist es empfehlenswert, die Pakete einzeln zu installieren und auftretende Fehler/Abhängigkeiten einzeln zu lösen.

== 2. Sourcecode von Git laden ==
=== Github ===
Zwar ist zum Herunterlden des Sourcecodes keine Account auf GitHub notwendig, aber zum Hochladen wird einer benötigt. Daher sollte zuerst einen Account auf https://github.com/ angelegt werden.

=== optional: SSH-Keys für Repositorys anlegen und in Github eintragen ===
siehe https://docs.github.com/en/free-pro-team@latest/github/authenticating-to-github/connecting-to-github-with-ssh 
oder: https://www.heise.de/tipps-tricks/SSH-Key-fuer-GitHub-Repositories-einrichten-4627459.html

=== Git lokal installieren ===
Windows: 
siehe: https://github.com/git-for-windows/git/releases 

Linux:
<nowiki>sudo apt install git</nowiki>

=== Sourcecode lokal herunterladen ===
Ein Terminal öffnen, folgende Kommandos ausführen und dabei Namen und Email-Adresse des Git-Accounts eintragen:
<nowiki>git config --global user.name "Your Name Here"
git config --global user.email "your_email@youremail.com"</nowiki>

Im Verzeichnis "home" einen Ordner "opencaching" (Name beliebig) anlegen. Dort folgenden Code ausführen. Dies legt einen Ordner mit dem Namen “oc-server3“ an, lädt den OC-Code aus deinem Github-Fork herunter und kopiert ihn in diesen Ordner.
<nowiki>git clone git@github.com:<DeinGithubBenutzername>/oc-server3</nowiki>

Im Anschluss in den Ordner “oc-server3“ wechseln und den folgenden Befehl ausführen, um bei einem Update den neuesten Sourcecode aus dem Opencaching.de-Repository erhalten zu können:
<nowiki>cd oc-server3
git remote add upstream git@github.com:OpencachingDeutschland/oc-server3</nowiki>

Mit folgendem Befehl gibt es eine Übersicht über die verknüpften Repositorys, die (abgesehen vom Nutzernamen ‘Slini11’) wie in der Grafik aussehen müssen:
<nowiki>git remote -v</nowiki>
[[Image:Testumgebung Git 01.png]]

Nun den Branch “development“ auschecken:
<nowiki>git checkout development</nowiki>

Und den Development-Branch auf aktuellen Stand bringen:
<nowiki>git pull --rebase upstream development </nowiki>

=== Weiterführende Informationen zu Git ===
Diese sind unter anderem im [[Entwicklung/Git|OC-Wiki]] zu finden

== 3. DDEV Entwicklungsumgebung initalisieren ==
=== Entwicklungsumgebung zum ersten Mal starten ===
Zuerst in den Projektordner “oc-server3“ navigieren und dort die Installation der Testumgebung starten.

==== Scripte einzeln ausführen ====
* ddev anstarten. Im Laufe dieses Prozesses wird die hosts-Datei automatisch angepasst.
<nowiki>ddev start</nowiki>

* Starten der Initialisierung der Testumgebung und der Datenbank:
<nowiki>ddev init</nowiki>

* Die Entwicklungsumgebung steht nun über den Browser bereit unter:
https://opencaching.ddev.site
bzw.
https://try-opencaching.ddev.site

* Das Passwort für den Benutzer ''root'' lautet ''developer''. Das Passwort der anderen Benutzer (Benutzernamen siehe Datenbank) lautet ''password''

=== Entwicklungsumgebung ein weiteres Mal starten ===
Die Testumgebung kann neugestartet werden mit:
<nowiki>ddev restart</nowiki>

=== Entwicklungsumgebung stoppen ===
Die Testumgebung kann gestoppt werden mit:
<nowiki>ddev stop</nowiki>

=== Entwicklungsumgebung löschen ===
Die Testumgebung kann im Projektordner gelöscht werden mit:
<nowiki>ddev delete --omit-snapshot</nowiki>
Danach sind ein erneutes ''ddev start'' und ''ddev init'' notwendig.

=== von DDEV angelegte Objekte löschen und Projekte aus der globalen DDEV-Liste löschen ===
<nowiki>ddev clean --all</nowiki>
<nowiki>ddev stop --unlist opencaching</nowiki>

=== xdebug in der Entwicklungsumgebung starten ===
<nowiki>ddev xdebug</nowiki>
Ein ''ddev start'' oder ''ddev restart'' deaktiviert das xdebug wieder.

=== Weitere ddev-Optionen.. ===
''ddev'' ohne Parameter aufrufen gibt eine Liste weiterer Optionen aus.
<nowiki>ddev</nowiki>

== 4. Die Testdatenbank füllen ==
Während der Installation wird eine Testdatenbank importiert, die bereits eine kleine Menge an Caches und Nutzern beinhaltet. Ein manueller Import des Datenbankdumps ist somit (seit März 2021) nicht mehr notwendig.

Für den Fall, dass trotzdem Daten exportiert / importiert werden sollen, können folgende Abschnitte berücksichtigt werden:

=== Login auf der Test-Datenbank im ddev-Container ===
<nowiki>mysql -uroot -proot -hopencaching-db opencaching</nowiki>

=== Datenbank innerhalb des ddev-Containers exportieren ===
<nowiki>mysqldump -uroot -proot -hopencaching-db opencaching > file.sql</nowiki>

=== Datenbank außerhalb des ddev-Containers exportieren ===
<nowiki>mysqldump --complete-insert --user root -proot --host 0.0.0.0 opencaching > dump.sql</nowiki>

=== Datenbank im phpStorm exportieren ===
Auf der rechten Bildschirmseite den Databasedialog ausklappen
rechte Maustaste auf die zu exportierende Datenbank “opencaching” => “Export with ‘mysqldump’”

[[Image:Testumgebung DB 01.png]]

Im Exportmenü die Zeile “Statements” umstellen auf “Insert with columns” und eventuell den Ausgabepfad “Out Path” anpassen. Im Kommandofeld den Parameter “--routines“ ergänzen und dann “Run” drücken

[[Image:Testumgebung DB 02.png]]

=== Datenbank-Dump im phpStorm importieren ===
Auf der rechten Bildschirmseite den Databasedialog ausklappen
rechte Maustaste auf die Datenbank => “Restore with ‘mysql’”

[[Image:Testumgebung DB 03.png]]

Im Importmenü den Eingabepfad “Path to dump” anpassen, dann “Run” drücken

[[Image:Testumgebung DB 04.png]]

== 5. Die Entwicklungs-IDE vorbereiten ==
Gegebenenfalls sind an der Programmierumgebung Änderungen vorzunehmen, um zum Beispiel [[OC Coding Style|einheitlich formatierten Code]] zu schreiben.

=== Einrichtung des PHP Coding Styles am Beispiel von phpStorm ===
Unter Settings / Code Style / PHP rechts auf “Set from…” klicken und “PSR-12” auswählen. Die Einstellung mit “Apply” bestätigen.
(Weitere Informationen zum Coding Style sind [[OC Coding Style|hier im Wiki]] zu finden.)

[[Image:Testumgebung IDE 01.png|500px]]

=== Symfony Pfade am Beispiel phpStorm anpassen ===
[[Image:Testumgebung IDE 04.jpeg]]

=== Terminalanpassung am Beispiel phpStorm (für Windows-Nutzer) ===
[[Image:Testumgebung IDE 05.png]]

=== Datenbankanbindung in phpStorm aktivieren ===
Seit ddev als Umgebung genutzt wird, bietet sich das ddev-Plugin im phpStorm an. Es richtet z.B. den Zugang zur opencaching-Datenbank in der Testumgebung sowie weitere Einstellungen automatisch ein.
Hierzu im phpStorm im Menü Datei/Einstellungen.. zum Abschnitt ''Plugins'' navigieren, im Suchfeld ''ddev'' eintippen und das Plugin installieren.
[[Image:Testumgebung IDE 06.jpg]]

=== Synchronisieren/Wiederherstellen der Benutzereinstellungen mittels JetBrains-Server ===
Sofern man bei JetBrains einen Account hat, kann man mit diesem die Einstellungen der lokalen IDE synchronisieren und z.B. nach einer Neuinstallation von dort wiederherstellen.

Hierzu in der IDE rechts oben auf das Zahnrad klicken und “Settings Sync is off” auswählen.
[[Image:Testumgebung IDE 02.png]]

Im folgenden Fenster den Button “Enable Settings Sync” klicken und danach alle Einstellungen auswählen, die man sichern möchte. Ein Klick auf “Push Settings to Account” sichert die Einstellungen. Ein Klick auf “Get Settings from Account” stellt sie wieder her, sofern sie vorher dorthin gesichert wurden.
[[Image:Testumgebung IDE 03.png]]

== 6. Das Fehlerhandbuch lesen (gilt insbesondere für die Schritte #1-#4 :wink:) ==

Beireits bekannte Fehler werden im [[Entwicklungsumgebung/Fehlerhandbuch|Fehlerhandbuch]] beschrieben.

[[Kategorie:Entwicklung|Entwicklungsumgebung ]]

Entwicklungsumgebung einrichten

2026-02-25T12:31:12Z

Fraggle: +ddev clean

Das Einrichten der Testumgebung erfolgt in mehreren Schritten, die im folgenden beschrieben sind. Falls es dabei zu unerwarteten Fehlermeldungen kommt, bitte die letzten Schritte noch einmal genau anschauen und gegebenenfalls wiederholen. Auch ein Blick ins Fehlerhandbuch hilft meistens, da bereits viele Fallstricke entdeckt und beschrieben wurden.

== 1. Das Betriebssystem vorbereiten, entweder Linux oder Windows ==
=== Windows 10 ===
==== Programme installieren ====
Unter Windows ist es standardmäßig nicht möglich, “einfach“ die Linux Distribution Ubuntu zu installieren. Dazu muss vorab erst das WSL2 aktiviert / installiert werden werden (Punkt 1). Im Anschluss ist eine Installation von Ubuntu (18.04 oder höher) möglich. Zudem muss DDEV installiert werden, in welchem dann die Entwicklungsumgebung laufen kann (Punkt 2).

# WSL2 unter Windows10 aktivieren und Ubuntu installieren:
## Aus dem Microsoft-Store: https://aka.ms/wslstorepage (verfügbar seit Nov. 2022)
## Manuell unter [https://learn.microsoft.com/de-de/windows/wsl/install#manual-installation-steps|Installieren von WSL]
# DDEV für Windows installieren: [https://docs.ddev.com/en/stable/#system-requirements-windows-wsl2|Install DDEV WSL2]

Danach kann Ubuntu gestartet werden (z.B. im “Such“-Menü nach Ubuntu suchen und anklicken). Beim erstmaligen Starten von Ubuntu müssen ein Benutzername und ein Passwort festgelegt werden.

Im Anschluss den Punkten folgen und ausführen, die im nächsten Schritt “Linux” beschrieben werden.

=== Linux ===
Der Linuxartikel wurde erstellt auf Lubuntu 22.04 und erweitert mit Debian 12

==== Programme installieren ====
Folgende Programme sind notwendig und müssen vorab installiert werden:
PHP (aktuell mindestens PHP8.2), diverse PHP-Erweiterungen, ddev, mariadb-client. Für die PHP-Erweiterungen ist eventuell ein zusätzliches PPA-Repository notwendig. Dessen Installation erfordert je nach Betriebssystem ein unterschiedliches Vorgehen.

<nowiki>Ubuntu:
sudo apt install software-properties-common
sudo add-apt-repository ppa:ondrej/php

Debian:
sudo apt install software-properties-common ca-certificates lsb-release apt-transport-https
curl -sSL https://packages.sury.org/php/README.txt | sudo bash -x</nowiki>

Die Pakete lassen sich mit folgenden Befehlen installieren (Versionsnummer kann abweichen).
<nowiki>sudo apt update
sudo apt install php8.2 php8.2-mbstring php8.2-curl php8.2-xml php8.2-mysql
sudo apt install mariadb-client</nowiki>

Sollten beim Installieren der Pakete Fehlermeldungen auftreten, ist es empfehlenswert, die Pakete einzeln zu installieren und auftretende Fehler/Abhängigkeiten einzeln zu lösen.

== 2. Sourcecode von Git laden ==
=== Github ===
Zwar ist zum Herunterlden des Sourcecodes keine Account auf GitHub notwendig, aber zum Hochladen wird einer benötigt. Daher sollte zuerst einen Account auf https://github.com/ angelegt werden.

=== optional: SSH-Keys für Repositorys anlegen und in Github eintragen ===
siehe https://docs.github.com/en/free-pro-team@latest/github/authenticating-to-github/connecting-to-github-with-ssh 
oder: https://www.heise.de/tipps-tricks/SSH-Key-fuer-GitHub-Repositories-einrichten-4627459.html

=== Git lokal installieren ===
Windows: 
siehe: https://github.com/git-for-windows/git/releases 

Linux:
<nowiki>sudo apt install git</nowiki>

=== Sourcecode lokal herunterladen ===
Ein Terminal öffnen, folgende Kommandos ausführen und dabei Namen und Email-Adresse des Git-Accounts eintragen:
<nowiki>git config --global user.name "Your Name Here"
git config --global user.email "your_email@youremail.com"</nowiki>

Im Verzeichnis "home" einen Ordner "opencaching" (Name beliebig) anlegen. Dort folgenden Code ausführen. Dies legt einen Ordner mit dem Namen “oc-server3“ an, lädt den OC-Code aus deinem Github-Fork herunter und kopiert ihn in diesen Ordner.
<nowiki>git clone git@github.com:<DeinGithubBenutzername>/oc-server3</nowiki>

Im Anschluss in den Ordner “oc-server3“ wechseln und den folgenden Befehl ausführen, um bei einem Update den neuesten Sourcecode aus dem Opencaching.de-Repository erhalten zu können:
<nowiki>cd oc-server3
git remote add upstream git@github.com:OpencachingDeutschland/oc-server3</nowiki>

Mit folgendem Befehl gibt es eine Übersicht über die verknüpften Repositorys, die (abgesehen vom Nutzernamen ‘Slini11’) wie in der Grafik aussehen müssen:
<nowiki>git remote -v</nowiki>
[[Image:Testumgebung Git 01.png]]

Nun den Branch “development“ auschecken:
<nowiki>git checkout development</nowiki>

Und den Development-Branch auf aktuellen Stand bringen:
<nowiki>git pull --rebase upstream development </nowiki>

=== Weiterführende Informationen zu Git ===
Diese sind unter anderem im [[Entwicklung/Git|OC-Wiki]] zu finden

== 3. DDEV Entwicklungsumgebung initalisieren ==
=== Entwicklungsumgebung zum ersten Mal starten ===
Zuerst in den Projektordner “oc-server3“ navigieren und dort die Installation der Testumgebung starten.

==== Scripte einzeln ausführen ====
* ddev anstarten. Im Laufe dieses Prozesses wird die hosts-Datei automatisch angepasst.
<nowiki>ddev start</nowiki>

* Starten der Initialisierung der Testumgebung und der Datenbank:
<nowiki>ddev init</nowiki>

* Die Entwicklungsumgebung steht nun über den Browser bereit unter:
https://opencaching.ddev.site
bzw.
https://try-opencaching.ddev.site

* Das Passwort für den Benutzer ''root'' lautet ''developer''. Das Passwort der anderen Benutzer (Benutzernamen siehe Datenbank) lautet ''password''

=== Entwicklungsumgebung ein weiteres Mal starten ===
Die Testumgebung kann neugestartet werden mit:
<nowiki>ddev restart</nowiki>

=== Entwicklungsumgebung stoppen ===
Die Testumgebung kann gestoppt werden mit:
<nowiki>ddev stop</nowiki>

=== Entwicklungsumgebung löschen ===
Die Testumgebung kann im Projektordner gelöscht werden mit:
<nowiki>ddev delete --omit-snapshot</nowiki>
Danach sind ein erneutes ''ddev start'' und ''ddev init'' notwendig.

Alle von ddev angelegten Objekte können gelöscht werden mit:
<nowiki>ddev clean --all</nowiki>

=== xdebug in der Entwicklungsumgebung starten ===
<nowiki>ddev xdebug</nowiki>
Ein ''ddev start'' oder ''ddev restart'' deaktiviert das xdebug wieder.

=== Weitere ddev-Optionen.. ===
''ddev'' ohne Parameter aufrufen gibt eine Liste weiterer Optionen aus.
<nowiki>ddev</nowiki>

== 4. Die Testdatenbank füllen ==
Während der Installation wird eine Testdatenbank importiert, die bereits eine kleine Menge an Caches und Nutzern beinhaltet. Ein manueller Import des Datenbankdumps ist somit (seit März 2021) nicht mehr notwendig.

Für den Fall, dass trotzdem Daten exportiert / importiert werden sollen, können folgende Abschnitte berücksichtigt werden:

=== Login auf der Test-Datenbank im ddev-Container ===
<nowiki>mysql -uroot -proot -hopencaching-db opencaching</nowiki>

=== Datenbank innerhalb des ddev-Containers exportieren ===
<nowiki>mysqldump -uroot -proot -hopencaching-db opencaching > file.sql</nowiki>

=== Datenbank außerhalb des ddev-Containers exportieren ===
<nowiki>mysqldump --complete-insert --user root -proot --host 0.0.0.0 opencaching > dump.sql</nowiki>

=== Datenbank im phpStorm exportieren ===
Auf der rechten Bildschirmseite den Databasedialog ausklappen
rechte Maustaste auf die zu exportierende Datenbank “opencaching” => “Export with ‘mysqldump’”

[[Image:Testumgebung DB 01.png]]

Im Exportmenü die Zeile “Statements” umstellen auf “Insert with columns” und eventuell den Ausgabepfad “Out Path” anpassen. Im Kommandofeld den Parameter “--routines“ ergänzen und dann “Run” drücken

[[Image:Testumgebung DB 02.png]]

=== Datenbank-Dump im phpStorm importieren ===
Auf der rechten Bildschirmseite den Databasedialog ausklappen
rechte Maustaste auf die Datenbank => “Restore with ‘mysql’”

[[Image:Testumgebung DB 03.png]]

Im Importmenü den Eingabepfad “Path to dump” anpassen, dann “Run” drücken

[[Image:Testumgebung DB 04.png]]

== 5. Die Entwicklungs-IDE vorbereiten ==
Gegebenenfalls sind an der Programmierumgebung Änderungen vorzunehmen, um zum Beispiel [[OC Coding Style|einheitlich formatierten Code]] zu schreiben.

=== Einrichtung des PHP Coding Styles am Beispiel von phpStorm ===
Unter Settings / Code Style / PHP rechts auf “Set from…” klicken und “PSR-12” auswählen. Die Einstellung mit “Apply” bestätigen.
(Weitere Informationen zum Coding Style sind [[OC Coding Style|hier im Wiki]] zu finden.)

[[Image:Testumgebung IDE 01.png|500px]]

=== Symfony Pfade am Beispiel phpStorm anpassen ===
[[Image:Testumgebung IDE 04.jpeg]]

=== Terminalanpassung am Beispiel phpStorm (für Windows-Nutzer) ===
[[Image:Testumgebung IDE 05.png]]

=== Datenbankanbindung in phpStorm aktivieren ===
Seit ddev als Umgebung genutzt wird, bietet sich das ddev-Plugin im phpStorm an. Es richtet z.B. den Zugang zur opencaching-Datenbank in der Testumgebung sowie weitere Einstellungen automatisch ein.
Hierzu im phpStorm im Menü Datei/Einstellungen.. zum Abschnitt ''Plugins'' navigieren, im Suchfeld ''ddev'' eintippen und das Plugin installieren.
[[Image:Testumgebung IDE 06.jpg]]

=== Synchronisieren/Wiederherstellen der Benutzereinstellungen mittels JetBrains-Server ===
Sofern man bei JetBrains einen Account hat, kann man mit diesem die Einstellungen der lokalen IDE synchronisieren und z.B. nach einer Neuinstallation von dort wiederherstellen.

Hierzu in der IDE rechts oben auf das Zahnrad klicken und “Settings Sync is off” auswählen.
[[Image:Testumgebung IDE 02.png]]

Im folgenden Fenster den Button “Enable Settings Sync” klicken und danach alle Einstellungen auswählen, die man sichern möchte. Ein Klick auf “Push Settings to Account” sichert die Einstellungen. Ein Klick auf “Get Settings from Account” stellt sie wieder her, sofern sie vorher dorthin gesichert wurden.
[[Image:Testumgebung IDE 03.png]]

== 6. Das Fehlerhandbuch lesen (gilt insbesondere für die Schritte #1-#4 :wink:) ==

Beireits bekannte Fehler werden im [[Entwicklungsumgebung/Fehlerhandbuch|Fehlerhandbuch]] beschrieben.

[[Kategorie:Entwicklung|Entwicklungsumgebung ]]

Entwicklungsumgebung einrichten

2026-02-23T08:21:18Z

Fraggle: DB-Anbindung in phpStorm

Das Einrichten der Testumgebung erfolgt in mehreren Schritten, die im folgenden beschrieben sind. Falls es dabei zu unerwarteten Fehlermeldungen kommt, bitte die letzten Schritte noch einmal genau anschauen und gegebenenfalls wiederholen. Auch ein Blick ins Fehlerhandbuch hilft meistens, da bereits viele Fallstricke entdeckt und beschrieben wurden.

== 1. Das Betriebssystem vorbereiten, entweder Linux oder Windows ==
=== Windows 10 ===
==== Programme installieren ====
Unter Windows ist es standardmäßig nicht möglich, “einfach“ die Linux Distribution Ubuntu zu installieren. Dazu muss vorab erst das WSL2 aktiviert / installiert werden werden (Punkt 1). Im Anschluss ist eine Installation von Ubuntu (18.04 oder höher) möglich. Zudem muss DDEV installiert werden, in welchem dann die Entwicklungsumgebung laufen kann (Punkt 2).

# WSL2 unter Windows10 aktivieren und Ubuntu installieren:
## Aus dem Microsoft-Store: https://aka.ms/wslstorepage (verfügbar seit Nov. 2022)
## Manuell unter [https://learn.microsoft.com/de-de/windows/wsl/install#manual-installation-steps|Installieren von WSL]
# DDEV für Windows installieren: [https://docs.ddev.com/en/stable/#system-requirements-windows-wsl2|Install DDEV WSL2]

Danach kann Ubuntu gestartet werden (z.B. im “Such“-Menü nach Ubuntu suchen und anklicken). Beim erstmaligen Starten von Ubuntu müssen ein Benutzername und ein Passwort festgelegt werden.

Im Anschluss den Punkten folgen und ausführen, die im nächsten Schritt “Linux” beschrieben werden.

=== Linux ===
Der Linuxartikel wurde erstellt auf Lubuntu 22.04 und erweitert mit Debian 12

==== Programme installieren ====
Folgende Programme sind notwendig und müssen vorab installiert werden:
PHP (aktuell mindestens PHP8.2), diverse PHP-Erweiterungen, ddev, mariadb-client. Für die PHP-Erweiterungen ist eventuell ein zusätzliches PPA-Repository notwendig. Dessen Installation erfordert je nach Betriebssystem ein unterschiedliches Vorgehen.

<nowiki>Ubuntu:
sudo apt install software-properties-common
sudo add-apt-repository ppa:ondrej/php

Debian:
sudo apt install software-properties-common ca-certificates lsb-release apt-transport-https
curl -sSL https://packages.sury.org/php/README.txt | sudo bash -x</nowiki>

Die Pakete lassen sich mit folgenden Befehlen installieren (Versionsnummer kann abweichen).
<nowiki>sudo apt update
sudo apt install php8.2 php8.2-mbstring php8.2-curl php8.2-xml php8.2-mysql
sudo apt install mariadb-client</nowiki>

Sollten beim Installieren der Pakete Fehlermeldungen auftreten, ist es empfehlenswert, die Pakete einzeln zu installieren und auftretende Fehler/Abhängigkeiten einzeln zu lösen.

== 2. Sourcecode von Git laden ==
=== Github ===
Zwar ist zum Herunterlden des Sourcecodes keine Account auf GitHub notwendig, aber zum Hochladen wird einer benötigt. Daher sollte zuerst einen Account auf https://github.com/ angelegt werden.

=== optional: SSH-Keys für Repositorys anlegen und in Github eintragen ===
siehe https://docs.github.com/en/free-pro-team@latest/github/authenticating-to-github/connecting-to-github-with-ssh 
oder: https://www.heise.de/tipps-tricks/SSH-Key-fuer-GitHub-Repositories-einrichten-4627459.html

=== Git lokal installieren ===
Windows: 
siehe: https://github.com/git-for-windows/git/releases 

Linux:
<nowiki>sudo apt install git</nowiki>

=== Sourcecode lokal herunterladen ===
Ein Terminal öffnen, folgende Kommandos ausführen und dabei Namen und Email-Adresse des Git-Accounts eintragen:
<nowiki>git config --global user.name "Your Name Here"
git config --global user.email "your_email@youremail.com"</nowiki>

Im Verzeichnis "home" einen Ordner "opencaching" (Name beliebig) anlegen. Dort folgenden Code ausführen. Dies legt einen Ordner mit dem Namen “oc-server3“ an, lädt den OC-Code aus deinem Github-Fork herunter und kopiert ihn in diesen Ordner.
<nowiki>git clone git@github.com:<DeinGithubBenutzername>/oc-server3</nowiki>

Im Anschluss in den Ordner “oc-server3“ wechseln und den folgenden Befehl ausführen, um bei einem Update den neuesten Sourcecode aus dem Opencaching.de-Repository erhalten zu können:
<nowiki>cd oc-server3
git remote add upstream git@github.com:OpencachingDeutschland/oc-server3</nowiki>

Mit folgendem Befehl gibt es eine Übersicht über die verknüpften Repositorys, die (abgesehen vom Nutzernamen ‘Slini11’) wie in der Grafik aussehen müssen:
<nowiki>git remote -v</nowiki>
[[Image:Testumgebung Git 01.png]]

Nun den Branch “development“ auschecken:
<nowiki>git checkout development</nowiki>

Und den Development-Branch auf aktuellen Stand bringen:
<nowiki>git pull --rebase upstream development </nowiki>

=== Weiterführende Informationen zu Git ===
Diese sind unter anderem im [[Entwicklung/Git|OC-Wiki]] zu finden

== 3. DDEV Entwicklungsumgebung initalisieren ==
=== Entwicklungsumgebung zum ersten Mal starten ===
Zuerst in den Projektordner “oc-server3“ navigieren und dort die Installation der Testumgebung starten.

==== Scripte einzeln ausführen ====
* ddev anstarten. Im Laufe dieses Prozesses wird die hosts-Datei automatisch angepasst.
<nowiki>ddev start</nowiki>

* Starten der Initialisierung der Testumgebung und der Datenbank:
<nowiki>ddev init</nowiki>

* Die Entwicklungsumgebung steht nun über den Browser bereit unter:
https://opencaching.ddev.site
bzw.
https://try-opencaching.ddev.site

* Das Passwort für den Benutzer ''root'' lautet ''developer''. Das Passwort der anderen Benutzer (Benutzernamen siehe Datenbank) lautet ''password''

=== Entwicklungsumgebung ein weiteres Mal starten ===
Die Testumgebung kann neugestartet werden mit:
<nowiki>ddev restart</nowiki>

=== Entwicklungsumgebung stoppen ===
Die Testumgebung kann gestoppt werden mit:
<nowiki>ddev stop</nowiki>

=== Entwicklungsumgebung löschen ===
Die Testumgebung kann im Projektordner gelöscht werden mit:
<nowiki>ddev delete --omit-snapshot</nowiki>
Danach sind ein erneutes ''ddev start'' und ''ddev init'' notwendig.

=== xdebug in der Entwicklungsumgebung starten ===
<nowiki>ddev xdebug</nowiki>
Ein ''ddev start'' oder ''ddev restart'' deaktiviert das xdebug wieder.

=== Weitere ddev-Optionen.. ===
''ddev'' ohne Parameter aufrufen gibt eine Liste weiterer Optionen aus.
<nowiki>ddev</nowiki>

== 4. Die Testdatenbank füllen ==
Während der Installation wird eine Testdatenbank importiert, die bereits eine kleine Menge an Caches und Nutzern beinhaltet. Ein manueller Import des Datenbankdumps ist somit (seit März 2021) nicht mehr notwendig.

Für den Fall, dass trotzdem Daten exportiert / importiert werden sollen, können folgende Abschnitte berücksichtigt werden:

=== Login auf der Test-Datenbank im ddev-Container ===
<nowiki>mysql -uroot -proot -hopencaching-db opencaching</nowiki>

=== Datenbank innerhalb des ddev-Containers exportieren ===
<nowiki>mysqldump -uroot -proot -hopencaching-db opencaching > file.sql</nowiki>

=== Datenbank außerhalb des ddev-Containers exportieren ===
<nowiki>mysqldump --complete-insert --user root -proot --host 0.0.0.0 opencaching > dump.sql</nowiki>

=== Datenbank im phpStorm exportieren ===
Auf der rechten Bildschirmseite den Databasedialog ausklappen
rechte Maustaste auf die zu exportierende Datenbank “opencaching” => “Export with ‘mysqldump’”

[[Image:Testumgebung DB 01.png]]

Im Exportmenü die Zeile “Statements” umstellen auf “Insert with columns” und eventuell den Ausgabepfad “Out Path” anpassen. Im Kommandofeld den Parameter “--routines“ ergänzen und dann “Run” drücken

[[Image:Testumgebung DB 02.png]]

=== Datenbank-Dump im phpStorm importieren ===
Auf der rechten Bildschirmseite den Databasedialog ausklappen
rechte Maustaste auf die Datenbank => “Restore with ‘mysql’”

[[Image:Testumgebung DB 03.png]]

Im Importmenü den Eingabepfad “Path to dump” anpassen, dann “Run” drücken

[[Image:Testumgebung DB 04.png]]

== 5. Die Entwicklungs-IDE vorbereiten ==
Gegebenenfalls sind an der Programmierumgebung Änderungen vorzunehmen, um zum Beispiel [[OC Coding Style|einheitlich formatierten Code]] zu schreiben.

=== Einrichtung des PHP Coding Styles am Beispiel von phpStorm ===
Unter Settings / Code Style / PHP rechts auf “Set from…” klicken und “PSR-12” auswählen. Die Einstellung mit “Apply” bestätigen.
(Weitere Informationen zum Coding Style sind [[OC Coding Style|hier im Wiki]] zu finden.)

[[Image:Testumgebung IDE 01.png|500px]]

=== Symfony Pfade am Beispiel phpStorm anpassen ===
[[Image:Testumgebung IDE 04.jpeg]]

=== Terminalanpassung am Beispiel phpStorm (für Windows-Nutzer) ===
[[Image:Testumgebung IDE 05.png]]

=== Datenbankanbindung in phpStorm aktivieren ===
Seit ddev als Umgebung genutzt wird, bietet sich das ddev-Plugin im phpStorm an. Es richtet z.B. den Zugang zur opencaching-Datenbank in der Testumgebung sowie weitere Einstellungen automatisch ein.
Hierzu im phpStorm im Menü Datei/Einstellungen.. zum Abschnitt ''Plugins'' navigieren, im Suchfeld ''ddev'' eintippen und das Plugin installieren.
[[Image:Testumgebung IDE 06.jpg]]

=== Synchronisieren/Wiederherstellen der Benutzereinstellungen mittels JetBrains-Server ===
Sofern man bei JetBrains einen Account hat, kann man mit diesem die Einstellungen der lokalen IDE synchronisieren und z.B. nach einer Neuinstallation von dort wiederherstellen.

Hierzu in der IDE rechts oben auf das Zahnrad klicken und “Settings Sync is off” auswählen.
[[Image:Testumgebung IDE 02.png]]

Im folgenden Fenster den Button “Enable Settings Sync” klicken und danach alle Einstellungen auswählen, die man sichern möchte. Ein Klick auf “Push Settings to Account” sichert die Einstellungen. Ein Klick auf “Get Settings from Account” stellt sie wieder her, sofern sie vorher dorthin gesichert wurden.
[[Image:Testumgebung IDE 03.png]]

== 6. Das Fehlerhandbuch lesen (gilt insbesondere für die Schritte #1-#4 :wink:) ==

Beireits bekannte Fehler werden im [[Entwicklungsumgebung/Fehlerhandbuch|Fehlerhandbuch]] beschrieben.

[[Kategorie:Entwicklung|Entwicklungsumgebung ]]

Entwicklungsumgebung einrichten

2026-02-23T07:30:48Z

Fraggle: veralteter Abschnitt entfernt

Das Einrichten der Testumgebung erfolgt in mehreren Schritten, die im folgenden beschrieben sind. Falls es dabei zu unerwarteten Fehlermeldungen kommt, bitte die letzten Schritte noch einmal genau anschauen und gegebenenfalls wiederholen. Auch ein Blick ins Fehlerhandbuch hilft meistens, da bereits viele Fallstricke entdeckt und beschrieben wurden.

== 1. Das Betriebssystem vorbereiten, entweder Linux oder Windows ==
=== Windows 10 ===
==== Programme installieren ====
Unter Windows ist es standardmäßig nicht möglich, “einfach“ die Linux Distribution Ubuntu zu installieren. Dazu muss vorab erst das WSL2 aktiviert / installiert werden werden (Punkt 1). Im Anschluss ist eine Installation von Ubuntu (18.04 oder höher) möglich. Zudem muss DDEV installiert werden, in welchem dann die Entwicklungsumgebung laufen kann (Punkt 2).

# WSL2 unter Windows10 aktivieren und Ubuntu installieren:
## Aus dem Microsoft-Store: https://aka.ms/wslstorepage (verfügbar seit Nov. 2022)
## Manuell unter [https://learn.microsoft.com/de-de/windows/wsl/install#manual-installation-steps|Installieren von WSL]
# DDEV für Windows installieren: [https://docs.ddev.com/en/stable/#system-requirements-windows-wsl2|Install DDEV WSL2]

Danach kann Ubuntu gestartet werden (z.B. im “Such“-Menü nach Ubuntu suchen und anklicken). Beim erstmaligen Starten von Ubuntu müssen ein Benutzername und ein Passwort festgelegt werden.

Im Anschluss den Punkten folgen und ausführen, die im nächsten Schritt “Linux” beschrieben werden.

=== Linux ===
Der Linuxartikel wurde erstellt auf Lubuntu 22.04 und erweitert mit Debian 12

==== Programme installieren ====
Folgende Programme sind notwendig und müssen vorab installiert werden:
PHP (aktuell mindestens PHP8.2), diverse PHP-Erweiterungen, ddev, mariadb-client. Für die PHP-Erweiterungen ist eventuell ein zusätzliches PPA-Repository notwendig. Dessen Installation erfordert je nach Betriebssystem ein unterschiedliches Vorgehen.

<nowiki>Ubuntu:
sudo apt install software-properties-common
sudo add-apt-repository ppa:ondrej/php

Debian:
sudo apt install software-properties-common ca-certificates lsb-release apt-transport-https
curl -sSL https://packages.sury.org/php/README.txt | sudo bash -x</nowiki>

Die Pakete lassen sich mit folgenden Befehlen installieren (Versionsnummer kann abweichen).
<nowiki>sudo apt update
sudo apt install php8.2 php8.2-mbstring php8.2-curl php8.2-xml php8.2-mysql
sudo apt install mariadb-client</nowiki>

Sollten beim Installieren der Pakete Fehlermeldungen auftreten, ist es empfehlenswert, die Pakete einzeln zu installieren und auftretende Fehler/Abhängigkeiten einzeln zu lösen.

== 2. Sourcecode von Git laden ==
=== Github ===
Zwar ist zum Herunterlden des Sourcecodes keine Account auf GitHub notwendig, aber zum Hochladen wird einer benötigt. Daher sollte zuerst einen Account auf https://github.com/ angelegt werden.

=== optional: SSH-Keys für Repositorys anlegen und in Github eintragen ===
siehe https://docs.github.com/en/free-pro-team@latest/github/authenticating-to-github/connecting-to-github-with-ssh 
oder: https://www.heise.de/tipps-tricks/SSH-Key-fuer-GitHub-Repositories-einrichten-4627459.html

=== Git lokal installieren ===
Windows: 
siehe: https://github.com/git-for-windows/git/releases 

Linux:
<nowiki>sudo apt install git</nowiki>

=== Sourcecode lokal herunterladen ===
Ein Terminal öffnen, folgende Kommandos ausführen und dabei Namen und Email-Adresse des Git-Accounts eintragen:
<nowiki>git config --global user.name "Your Name Here"
git config --global user.email "your_email@youremail.com"</nowiki>

Im Verzeichnis "home" einen Ordner "opencaching" (Name beliebig) anlegen. Dort folgenden Code ausführen. Dies legt einen Ordner mit dem Namen “oc-server3“ an, lädt den OC-Code aus deinem Github-Fork herunter und kopiert ihn in diesen Ordner.
<nowiki>git clone git@github.com:<DeinGithubBenutzername>/oc-server3</nowiki>

Im Anschluss in den Ordner “oc-server3“ wechseln und den folgenden Befehl ausführen, um bei einem Update den neuesten Sourcecode aus dem Opencaching.de-Repository erhalten zu können:
<nowiki>cd oc-server3
git remote add upstream git@github.com:OpencachingDeutschland/oc-server3</nowiki>

Mit folgendem Befehl gibt es eine Übersicht über die verknüpften Repositorys, die (abgesehen vom Nutzernamen ‘Slini11’) wie in der Grafik aussehen müssen:
<nowiki>git remote -v</nowiki>
[[Image:Testumgebung Git 01.png]]

Nun den Branch “development“ auschecken:
<nowiki>git checkout development</nowiki>

Und den Development-Branch auf aktuellen Stand bringen:
<nowiki>git pull --rebase upstream development </nowiki>

=== Weiterführende Informationen zu Git ===
Diese sind unter anderem im [[Entwicklung/Git|OC-Wiki]] zu finden

== 3. DDEV Entwicklungsumgebung initalisieren ==
=== Entwicklungsumgebung zum ersten Mal starten ===
Zuerst in den Projektordner “oc-server3“ navigieren und dort die Installation der Testumgebung starten.

==== Scripte einzeln ausführen ====
* ddev anstarten. Im Laufe dieses Prozesses wird die hosts-Datei automatisch angepasst.
<nowiki>ddev start</nowiki>

* Starten der Initialisierung der Testumgebung und der Datenbank:
<nowiki>ddev init</nowiki>

* Die Entwicklungsumgebung steht nun über den Browser bereit unter:
https://opencaching.ddev.site
bzw.
https://try-opencaching.ddev.site

* Das Passwort für den Benutzer ''root'' lautet ''developer''. Das Passwort der anderen Benutzer (Benutzernamen siehe Datenbank) lautet ''password''

=== Entwicklungsumgebung ein weiteres Mal starten ===
Die Testumgebung kann neugestartet werden mit:
<nowiki>ddev restart</nowiki>

=== Entwicklungsumgebung stoppen ===
Die Testumgebung kann gestoppt werden mit:
<nowiki>ddev stop</nowiki>

=== Entwicklungsumgebung löschen ===
Die Testumgebung kann im Projektordner gelöscht werden mit:
<nowiki>ddev delete --omit-snapshot</nowiki>
Danach sind ein erneutes ''ddev start'' und ''ddev init'' notwendig.

=== xdebug in der Entwicklungsumgebung starten ===
<nowiki>ddev xdebug</nowiki>
Ein ''ddev start'' oder ''ddev restart'' deaktiviert das xdebug wieder.

=== Weitere ddev-Optionen.. ===
''ddev'' ohne Parameter aufrufen gibt eine Liste weiterer Optionen aus.
<nowiki>ddev</nowiki>

== 4. Die Testdatenbank füllen ==
Während der Installation wird eine Testdatenbank importiert, die bereits eine kleine Menge an Caches und Nutzern beinhaltet. Ein manueller Import des Datenbankdumps ist somit (seit März 2021) nicht mehr notwendig.

Für den Fall, dass trotzdem Daten exportiert / importiert werden sollen, können folgende Abschnitte berücksichtigt werden:

=== Login auf der Test-Datenbank im ddev-Container ===
<nowiki>mysql -uroot -proot -hopencaching-db opencaching</nowiki>

=== Datenbank innerhalb des ddev-Containers exportieren ===
<nowiki>mysqldump -uroot -proot -hopencaching-db opencaching > file.sql</nowiki>

=== Datenbank außerhalb des ddev-Containers exportieren ===
<nowiki>mysqldump --complete-insert --user root -proot --host 0.0.0.0 opencaching > dump.sql</nowiki>

=== Datenbank im phpStorm exportieren ===
Auf der rechten Bildschirmseite den Databasedialog ausklappen
rechte Maustaste auf die zu exportierende Datenbank “opencaching” => “Export with ‘mysqldump’”

[[Image:Testumgebung DB 01.png]]

Im Exportmenü die Zeile “Statements” umstellen auf “Insert with columns” und eventuell den Ausgabepfad “Out Path” anpassen. Im Kommandofeld den Parameter “--routines“ ergänzen und dann “Run” drücken

[[Image:Testumgebung DB 02.png]]

=== Datenbank-Dump im phpStorm importieren ===
Auf der rechten Bildschirmseite den Databasedialog ausklappen
rechte Maustaste auf die Datenbank => “Restore with ‘mysql’”

[[Image:Testumgebung DB 03.png]]

Im Importmenü den Eingabepfad “Path to dump” anpassen, dann “Run” drücken

[[Image:Testumgebung DB 04.png]]

== 5. Die Entwicklungs-IDE vorbereiten ==
Gegebenenfalls sind an der Programmierumgebung Änderungen vorzunehmen, um zum Beispiel [[OC Coding Style|einheitlich formatierten Code]] zu schreiben.

=== Einrichtung des PHP Coding Styles am Beispiel von phpStorm ===
Unter Settings / Code Style / PHP rechts auf “Set from…” klicken und “PSR-12” auswählen. Die Einstellung mit “Apply” bestätigen.
(Weitere Informationen zum Coding Style sind [[OC Coding Style|hier im Wiki]] zu finden.)

[[Image:Testumgebung IDE 01.png|500px]]

=== Symfony Pfade am Beispiel phpStorm anpassen ===
[[Image:Testumgebung IDE 04.jpeg]]

=== Terminalanpassung am Beispiel phpStorm (für Windows-Nutzer) ===
[[Image:Testumgebung IDE 05.png]]

=== hilfreiche Plugins für phpStorm ===
Seit ddev als Umgebung genutzt wird, bietet sich das ddev-Plugin im phpStorm an. Es richtet z.B. den Zugang zur opencaching-Datenbank in der Testumgebung sowie weitere Einstellungen automatisch ein.
Hierzu im phpStorm im Menü Datei/Einstellungen.. zum Abschnitt ''Plugins'' navigieren, im Suchfeld ''ddev'' eintippen und das Plugin installieren.
[[Image:Testumgebung IDE 06.jpg]]

=== Synchronisieren/Wiederherstellen der Benutzereinstellungen mittels JetBrains-Server ===
Sofern man bei JetBrains einen Account hat, kann man mit diesem die Einstellungen der lokalen IDE synchronisieren und z.B. nach einer Neuinstallation von dort wiederherstellen.

Hierzu in der IDE rechts oben auf das Zahnrad klicken und “Settings Sync is off” auswählen.
[[Image:Testumgebung IDE 02.png]]

Im folgenden Fenster den Button “Enable Settings Sync” klicken und danach alle Einstellungen auswählen, die man sichern möchte. Ein Klick auf “Push Settings to Account” sichert die Einstellungen. Ein Klick auf “Get Settings from Account” stellt sie wieder her, sofern sie vorher dorthin gesichert wurden.
[[Image:Testumgebung IDE 03.png]]

== 6. Das Fehlerhandbuch lesen (gilt insbesondere für die Schritte #1-#4 :wink:) ==

Beireits bekannte Fehler werden im [[Entwicklungsumgebung/Fehlerhandbuch|Fehlerhandbuch]] beschrieben.

[[Kategorie:Entwicklung|Entwicklungsumgebung ]]

Entwicklungsumgebung einrichten

2026-02-15T18:07:20Z

Fraggle: ddev Plugin für phpStorm

Das Einrichten der Testumgebung erfolgt in mehreren Schritten, die im folgenden beschrieben sind. Falls es dabei zu unerwarteten Fehlermeldungen kommt, bitte die letzten Schritte noch einmal genau anschauen und gegebenenfalls wiederholen. Auch ein Blick ins Fehlerhandbuch hilft meistens, da bereits viele Fallstricke entdeckt und beschrieben wurden.

== 1. Das Betriebssystem vorbereiten, entweder Linux oder Windows ==
=== Windows 10 ===
==== Programme installieren ====
Unter Windows ist es standardmäßig nicht möglich, “einfach“ die Linux Distribution Ubuntu zu installieren. Dazu muss vorab erst das WSL2 aktiviert / installiert werden werden (Punkt 1). Im Anschluss ist eine Installation von Ubuntu (18.04 oder höher) möglich. Zudem muss DDEV installiert werden, in welchem dann die Entwicklungsumgebung laufen kann (Punkt 2).

# WSL2 unter Windows10 aktivieren und Ubuntu installieren:
## Aus dem Microsoft-Store: https://aka.ms/wslstorepage (verfügbar seit Nov. 2022)
## Manuell unter [https://learn.microsoft.com/de-de/windows/wsl/install#manual-installation-steps|Installieren von WSL]
# DDEV für Windows installieren: [https://docs.ddev.com/en/stable/#system-requirements-windows-wsl2|Install DDEV WSL2]

Danach kann Ubuntu gestartet werden (z.B. im “Such“-Menü nach Ubuntu suchen und anklicken). Beim erstmaligen Starten von Ubuntu müssen ein Benutzername und ein Passwort festgelegt werden.

Im Anschluss den Punkten folgen und ausführen, die im nächsten Schritt “Linux” beschrieben werden.

=== Linux ===
Der Linuxartikel wurde erstellt auf Lubuntu 22.04 und erweitert mit Debian 12

==== Programme installieren ====
Folgende Programme sind notwendig und müssen vorab installiert werden:
PHP (aktuell mindestens PHP8.2), diverse PHP-Erweiterungen, ddev, mariadb-client. Für die PHP-Erweiterungen ist eventuell ein zusätzliches PPA-Repository notwendig. Dessen Installation erfordert je nach Betriebssystem ein unterschiedliches Vorgehen.

<nowiki>Ubuntu:
sudo apt install software-properties-common
sudo add-apt-repository ppa:ondrej/php

Debian:
sudo apt install software-properties-common ca-certificates lsb-release apt-transport-https
curl -sSL https://packages.sury.org/php/README.txt | sudo bash -x</nowiki>

Die Pakete lassen sich mit folgenden Befehlen installieren (Versionsnummer kann abweichen).
<nowiki>sudo apt update
sudo apt install php8.2 php8.2-mbstring php8.2-curl php8.2-xml php8.2-mysql
sudo apt install mariadb-client</nowiki>

Sollten beim Installieren der Pakete Fehlermeldungen auftreten, ist es empfehlenswert, die Pakete einzeln zu installieren und auftretende Fehler/Abhängigkeiten einzeln zu lösen.

== 2. Sourcecode von Git laden ==
=== Github ===
Zwar ist zum Herunterlden des Sourcecodes keine Account auf GitHub notwendig, aber zum Hochladen wird einer benötigt. Daher sollte zuerst einen Account auf https://github.com/ angelegt werden.

=== optional: SSH-Keys für Repositorys anlegen und in Github eintragen ===
siehe https://docs.github.com/en/free-pro-team@latest/github/authenticating-to-github/connecting-to-github-with-ssh 
oder: https://www.heise.de/tipps-tricks/SSH-Key-fuer-GitHub-Repositories-einrichten-4627459.html

=== Git lokal installieren ===
Windows: 
siehe: https://github.com/git-for-windows/git/releases 

Linux:
<nowiki>sudo apt install git</nowiki>

=== Sourcecode lokal herunterladen ===
Ein Terminal öffnen, folgende Kommandos ausführen und dabei Namen und Email-Adresse des Git-Accounts eintragen:
<nowiki>git config --global user.name "Your Name Here"
git config --global user.email "your_email@youremail.com"</nowiki>

Im Verzeichnis "home" einen Ordner "opencaching" (Name beliebig) anlegen. Dort folgenden Code ausführen. Dies legt einen Ordner mit dem Namen “oc-server3“ an, lädt den OC-Code aus deinem Github-Fork herunter und kopiert ihn in diesen Ordner.
<nowiki>git clone git@github.com:<DeinGithubBenutzername>/oc-server3</nowiki>

Im Anschluss in den Ordner “oc-server3“ wechseln und den folgenden Befehl ausführen, um bei einem Update den neuesten Sourcecode aus dem Opencaching.de-Repository erhalten zu können:
<nowiki>cd oc-server3
git remote add upstream git@github.com:OpencachingDeutschland/oc-server3</nowiki>

Mit folgendem Befehl gibt es eine Übersicht über die verknüpften Repositorys, die (abgesehen vom Nutzernamen ‘Slini11’) wie in der Grafik aussehen müssen:
<nowiki>git remote -v</nowiki>
[[Image:Testumgebung Git 01.png]]

Nun den Branch “development“ auschecken:
<nowiki>git checkout development</nowiki>

Und den Development-Branch auf aktuellen Stand bringen:
<nowiki>git pull --rebase upstream development </nowiki>

=== Weiterführende Informationen zu Git ===
Diese sind unter anderem im [[Entwicklung/Git|OC-Wiki]] zu finden

== 3. DDEV Entwicklungsumgebung initalisieren ==
=== Entwicklungsumgebung zum ersten Mal starten ===
Zuerst in den Projektordner “oc-server3“ navigieren und dort die Installation der Testumgebung starten.

==== Scripte einzeln ausführen ====
* ddev anstarten. Im Laufe dieses Prozesses wird die hosts-Datei automatisch angepasst.
<nowiki>ddev start</nowiki>

* Starten der Initialisierung der Testumgebung und der Datenbank:
<nowiki>ddev init</nowiki>

* Die Entwicklungsumgebung steht nun über den Browser bereit unter:
https://opencaching.ddev.site
bzw.
https://try-opencaching.ddev.site

* Das Passwort für den Benutzer ''root'' lautet ''developer''. Das Passwort der anderen Benutzer (Benutzernamen siehe Datenbank) lautet ''password''

=== Entwicklungsumgebung ein weiteres Mal starten ===
Die Testumgebung kann neugestartet werden mit:
<nowiki>ddev restart</nowiki>

=== Entwicklungsumgebung stoppen ===
Die Testumgebung kann gestoppt werden mit:
<nowiki>ddev stop</nowiki>

=== Entwicklungsumgebung löschen ===
Die Testumgebung kann im Projektordner gelöscht werden mit:
<nowiki>ddev delete --omit-snapshot</nowiki>
Danach sind ein erneutes ''ddev start'' und ''ddev init'' notwendig.

=== xdebug in der Entwicklungsumgebung starten ===
<nowiki>ddev xdebug</nowiki>
Ein ''ddev start'' oder ''ddev restart'' deaktiviert das xdebug wieder.

=== Weitere ddev-Optionen.. ===
''ddev'' ohne Parameter aufrufen gibt eine Liste weiterer Optionen aus.
<nowiki>ddev</nowiki>

== 4. Die Testdatenbank füllen ==
Während der Installation wird eine Testdatenbank importiert, die bereits eine kleine Menge an Caches und Nutzern beinhaltet. Ein manueller Import des Datenbankdumps ist somit (seit März 2021) nicht mehr notwendig.

Für den Fall, dass trotzdem Daten exportiert / importiert werden sollen, können folgende Abschnitte berücksichtigt werden:

=== Login auf der Test-Datenbank im ddev-Container ===
<nowiki>mysql -uroot -proot -hopencaching-db opencaching</nowiki>

=== Datenbank innerhalb des ddev-Containers exportieren ===
<nowiki>mysqldump -uroot -proot -hopencaching-db opencaching > file.sql</nowiki>

=== Datenbank außerhalb des ddev-Containers exportieren ===
<nowiki>mysqldump --complete-insert --user root -proot --host 0.0.0.0 opencaching > dump.sql</nowiki>

=== Datenbank im phpStorm exportieren ===
Auf der rechten Bildschirmseite den Databasedialog ausklappen
rechte Maustaste auf die zu exportierende Datenbank “opencaching” => “Export with ‘mysqldump’”

[[Image:Testumgebung DB 01.png]]

Im Exportmenü die Zeile “Statements” umstellen auf “Insert with columns” und eventuell den Ausgabepfad “Out Path” anpassen. Im Kommandofeld den Parameter “--routines“ ergänzen und dann “Run” drücken

[[Image:Testumgebung DB 02.png]]

=== Datenbank-Dump im phpStorm importieren ===
Auf der rechten Bildschirmseite den Databasedialog ausklappen
rechte Maustaste auf die Datenbank => “Restore with ‘mysql’”

[[Image:Testumgebung DB 03.png]]

Im Importmenü den Eingabepfad “Path to dump” anpassen, dann “Run” drücken

[[Image:Testumgebung DB 04.png]]

=== Datenbank in phpStorm anzeigen ===
Ggf. kann es passieren, dass die Datenbank nicht automatisch in phpStorm angezeigt wird. Dazu muss eine neue MariaDB im Datenbank-Menü angelegt werden.

[[Image:Testumgebung DB 05.png]]

Im Anschluss sind die Daten wie im folgenden Screenshot einzutragen. User: “root“ Password: “root“

[[Image:Testumgebung DB 06.png]]

== 5. Die Entwicklungs-IDE vorbereiten ==
Gegebenenfalls sind an der Programmierumgebung Änderungen vorzunehmen, um zum Beispiel [[OC Coding Style|einheitlich formatierten Code]] zu schreiben.

=== Einrichtung des PHP Coding Styles am Beispiel von phpStorm ===
Unter Settings / Code Style / PHP rechts auf “Set from…” klicken und “PSR-12” auswählen. Die Einstellung mit “Apply” bestätigen.
(Weitere Informationen zum Coding Style sind [[OC Coding Style|hier im Wiki]] zu finden.)

[[Image:Testumgebung IDE 01.png|500px]]

=== Symfony Pfade am Beispiel phpStorm anpassen ===
[[Image:Testumgebung IDE 04.jpeg]]

=== Terminalanpassung am Beispiel phpStorm (für Windows-Nutzer) ===
[[Image:Testumgebung IDE 05.png]]

=== hilfreiche Plugins für phpStorm ===
Seit ddev als Umgebung genutzt wird, bietet sich das ddev-Plugin im phpStorm an. Es richtet z.B. den Zugang zur opencaching-Datenbank in der Testumgebung sowie weitere Einstellungen automatisch ein.
Hierzu im phpStorm im Menü Datei/Einstellungen.. zum Abschnitt ''Plugins'' navigieren, im Suchfeld ''ddev'' eintippen und das Plugin installieren.
[[Image:Testumgebung IDE 06.jpg]]

=== Synchronisieren/Wiederherstellen der Benutzereinstellungen mittels JetBrains-Server ===
Sofern man bei JetBrains einen Account hat, kann man mit diesem die Einstellungen der lokalen IDE synchronisieren und z.B. nach einer Neuinstallation von dort wiederherstellen.

Hierzu in der IDE rechts oben auf das Zahnrad klicken und “Settings Sync is off” auswählen.
[[Image:Testumgebung IDE 02.png]]

Im folgenden Fenster den Button “Enable Settings Sync” klicken und danach alle Einstellungen auswählen, die man sichern möchte. Ein Klick auf “Push Settings to Account” sichert die Einstellungen. Ein Klick auf “Get Settings from Account” stellt sie wieder her, sofern sie vorher dorthin gesichert wurden.
[[Image:Testumgebung IDE 03.png]]

== 6. Das Fehlerhandbuch lesen (gilt insbesondere für die Schritte #1-#4 :wink:) ==

Beireits bekannte Fehler werden im [[Entwicklungsumgebung/Fehlerhandbuch|Fehlerhandbuch]] beschrieben.

[[Kategorie:Entwicklung|Entwicklungsumgebung ]]

Datei:Testumgebung IDE 06.jpg

2026-02-15T18:05:56Z

Fraggle:

Entwicklungsumgebung einrichten

2026-02-15T14:29:37Z

Fraggle: keine manuelle Anpassung der host-Datei unter Windows notwendig

Das Einrichten der Testumgebung erfolgt in mehreren Schritten, die im folgenden beschrieben sind. Falls es dabei zu unerwarteten Fehlermeldungen kommt, bitte die letzten Schritte noch einmal genau anschauen und gegebenenfalls wiederholen. Auch ein Blick ins Fehlerhandbuch hilft meistens, da bereits viele Fallstricke entdeckt und beschrieben wurden.

== 1. Das Betriebssystem vorbereiten, entweder Linux oder Windows ==
=== Windows 10 ===
==== Programme installieren ====
Unter Windows ist es standardmäßig nicht möglich, “einfach“ die Linux Distribution Ubuntu zu installieren. Dazu muss vorab erst das WSL2 aktiviert / installiert werden werden (Punkt 1). Im Anschluss ist eine Installation von Ubuntu (18.04 oder höher) möglich. Zudem muss DDEV installiert werden, in welchem dann die Entwicklungsumgebung laufen kann (Punkt 2).

# WSL2 unter Windows10 aktivieren und Ubuntu installieren:
## Aus dem Microsoft-Store: https://aka.ms/wslstorepage (verfügbar seit Nov. 2022)
## Manuell unter [https://learn.microsoft.com/de-de/windows/wsl/install#manual-installation-steps|Installieren von WSL]
# DDEV für Windows installieren: [https://docs.ddev.com/en/stable/#system-requirements-windows-wsl2|Install DDEV WSL2]

Danach kann Ubuntu gestartet werden (z.B. im “Such“-Menü nach Ubuntu suchen und anklicken). Beim erstmaligen Starten von Ubuntu müssen ein Benutzername und ein Passwort festgelegt werden.

Im Anschluss den Punkten folgen und ausführen, die im nächsten Schritt “Linux” beschrieben werden.

=== Linux ===
Der Linuxartikel wurde erstellt auf Lubuntu 22.04 und erweitert mit Debian 12

==== Programme installieren ====
Folgende Programme sind notwendig und müssen vorab installiert werden:
PHP (aktuell mindestens PHP8.2), diverse PHP-Erweiterungen, ddev, mariadb-client. Für die PHP-Erweiterungen ist eventuell ein zusätzliches PPA-Repository notwendig. Dessen Installation erfordert je nach Betriebssystem ein unterschiedliches Vorgehen.

<nowiki>Ubuntu:
sudo apt install software-properties-common
sudo add-apt-repository ppa:ondrej/php

Debian:
sudo apt install software-properties-common ca-certificates lsb-release apt-transport-https
curl -sSL https://packages.sury.org/php/README.txt | sudo bash -x</nowiki>

Die Pakete lassen sich mit folgenden Befehlen installieren (Versionsnummer kann abweichen).
<nowiki>sudo apt update
sudo apt install php8.2 php8.2-mbstring php8.2-curl php8.2-xml php8.2-mysql
sudo apt install mariadb-client</nowiki>

Sollten beim Installieren der Pakete Fehlermeldungen auftreten, ist es empfehlenswert, die Pakete einzeln zu installieren und auftretende Fehler/Abhängigkeiten einzeln zu lösen.

== 2. Sourcecode von Git laden ==
=== Github ===
Zwar ist zum Herunterlden des Sourcecodes keine Account auf GitHub notwendig, aber zum Hochladen wird einer benötigt. Daher sollte zuerst einen Account auf https://github.com/ angelegt werden.

=== optional: SSH-Keys für Repositorys anlegen und in Github eintragen ===
siehe https://docs.github.com/en/free-pro-team@latest/github/authenticating-to-github/connecting-to-github-with-ssh 
oder: https://www.heise.de/tipps-tricks/SSH-Key-fuer-GitHub-Repositories-einrichten-4627459.html

=== Git lokal installieren ===
Windows: 
siehe: https://github.com/git-for-windows/git/releases 

Linux:
<nowiki>sudo apt install git</nowiki>

=== Sourcecode lokal herunterladen ===
Ein Terminal öffnen, folgende Kommandos ausführen und dabei Namen und Email-Adresse des Git-Accounts eintragen:
<nowiki>git config --global user.name "Your Name Here"
git config --global user.email "your_email@youremail.com"</nowiki>

Im Verzeichnis "home" einen Ordner "opencaching" (Name beliebig) anlegen. Dort folgenden Code ausführen. Dies legt einen Ordner mit dem Namen “oc-server3“ an, lädt den OC-Code aus deinem Github-Fork herunter und kopiert ihn in diesen Ordner.
<nowiki>git clone git@github.com:<DeinGithubBenutzername>/oc-server3</nowiki>

Im Anschluss in den Ordner “oc-server3“ wechseln und den folgenden Befehl ausführen, um bei einem Update den neuesten Sourcecode aus dem Opencaching.de-Repository erhalten zu können:
<nowiki>cd oc-server3
git remote add upstream git@github.com:OpencachingDeutschland/oc-server3</nowiki>

Mit folgendem Befehl gibt es eine Übersicht über die verknüpften Repositorys, die (abgesehen vom Nutzernamen ‘Slini11’) wie in der Grafik aussehen müssen:
<nowiki>git remote -v</nowiki>
[[Image:Testumgebung Git 01.png]]

Nun den Branch “development“ auschecken:
<nowiki>git checkout development</nowiki>

Und den Development-Branch auf aktuellen Stand bringen:
<nowiki>git pull --rebase upstream development </nowiki>

=== Weiterführende Informationen zu Git ===
Diese sind unter anderem im [[Entwicklung/Git|OC-Wiki]] zu finden

== 3. DDEV Entwicklungsumgebung initalisieren ==
=== Entwicklungsumgebung zum ersten Mal starten ===
Zuerst in den Projektordner “oc-server3“ navigieren und dort die Installation der Testumgebung starten.

==== Scripte einzeln ausführen ====
* ddev anstarten. Im Laufe dieses Prozesses wird die hosts-Datei automatisch angepasst.
<nowiki>ddev start</nowiki>

* Starten der Initialisierung der Testumgebung und der Datenbank:
<nowiki>ddev init</nowiki>

* Die Entwicklungsumgebung steht nun über den Browser bereit unter:
https://opencaching.ddev.site
bzw.
https://try-opencaching.ddev.site

* Das Passwort für den Benutzer ''root'' lautet ''developer''. Das Passwort der anderen Benutzer (Benutzernamen siehe Datenbank) lautet ''password''

=== Entwicklungsumgebung ein weiteres Mal starten ===
Die Testumgebung kann neugestartet werden mit:
<nowiki>ddev restart</nowiki>

=== Entwicklungsumgebung stoppen ===
Die Testumgebung kann gestoppt werden mit:
<nowiki>ddev stop</nowiki>

=== Entwicklungsumgebung löschen ===
Die Testumgebung kann im Projektordner gelöscht werden mit:
<nowiki>ddev delete --omit-snapshot</nowiki>
Danach sind ein erneutes ''ddev start'' und ''ddev init'' notwendig.

== 4. Die Testdatenbank füllen ==
Während der Installation wird eine Testdatenbank importiert, die bereits eine kleine Menge an Caches und Nutzern beinhaltet. Ein manueller Import des Datenbankdumps ist somit (seit März 2021) nicht mehr notwendig.

Für den Fall, dass trotzdem Daten exportiert / importiert werden sollen, können folgende Abschnitte berücksichtigt werden:

=== Login auf der Test-Datenbank im ddev-Container ===
<nowiki>mysql -uroot -proot -hopencaching-db opencaching</nowiki>

=== Datenbank innerhalb des ddev-Containers exportieren ===
<nowiki>mysqldump -uroot -proot -hopencaching-db opencaching > file.sql</nowiki>

=== Datenbank außerhalb des ddev-Containers exportieren ===
<nowiki>mysqldump --complete-insert --user root -proot --host 0.0.0.0 opencaching > dump.sql</nowiki>

=== Datenbank im phpStorm exportieren ===
Auf der rechten Bildschirmseite den Databasedialog ausklappen
rechte Maustaste auf die zu exportierende Datenbank “opencaching” => “Export with ‘mysqldump’”

[[Image:Testumgebung DB 01.png]]

Im Exportmenü die Zeile “Statements” umstellen auf “Insert with columns” und eventuell den Ausgabepfad “Out Path” anpassen. Im Kommandofeld den Parameter “--routines“ ergänzen und dann “Run” drücken

[[Image:Testumgebung DB 02.png]]

=== Datenbank-Dump im phpStorm importieren ===
Auf der rechten Bildschirmseite den Databasedialog ausklappen
rechte Maustaste auf die Datenbank => “Restore with ‘mysql’”

[[Image:Testumgebung DB 03.png]]

Im Importmenü den Eingabepfad “Path to dump” anpassen, dann “Run” drücken

[[Image:Testumgebung DB 04.png]]

=== Datenbank in phpStorm anzeigen ===
Ggf. kann es passieren, dass die Datenbank nicht automatisch in phpStorm angezeigt wird. Dazu muss eine neue MariaDB im Datenbank-Menü angelegt werden.

[[Image:Testumgebung DB 05.png]]

Im Anschluss sind die Daten wie im folgenden Screenshot einzutragen. User: “root“ Password: “root“

[[Image:Testumgebung DB 06.png]]

== 5. Die Entwicklungs-IDE vorbereiten ==
Gegebenenfalls sind an der Programmierumgebung Änderungen vorzunehmen, um zum Beispiel [[OC Coding Style|einheitlich formatierten Code]] zu schreiben.

=== Einrichtung des PHP Coding Styles am Beispiel von phpStorm ===
Unter Settings / Code Style / PHP rechts auf “Set from…” klicken und “PSR-12” auswählen. Die Einstellung mit “Apply” bestätigen.
(Weitere Informationen zum Coding Style sind [[OC Coding Style|hier im Wiki]] zu finden.)

[[Image:Testumgebung IDE 01.png|500px]]

=== Symfony Pfade am Beispiel phpStorm anpassen ===
[[Image:Testumgebung IDE 04.jpeg]]

=== Terminalanpassung am Beispiel phpStorm (für Windows-Nutzer) ===
[[Image:Testumgebung IDE 05.png]]

=== hilfreiche Plugins für phpStorm ===
-

=== Synchronisieren/Wiederherstellen der Benutzereinstellungen mittels JetBrains-Server ===
Sofern man bei JetBrains einen Account hat, kann man mit diesem die Einstellungen der lokalen IDE synchronisieren und z.B. nach einer Neuinstallation von dort wiederherstellen.

Hierzu in der IDE rechts oben auf das Zahnrad klicken und “Settings Sync is off” auswählen.
[[Image:Testumgebung IDE 02.png]]

Im folgenden Fenster den Button “Enable Settings Sync” klicken und danach alle Einstellungen auswählen, die man sichern möchte. Ein Klick auf “Push Settings to Account” sichert die Einstellungen. Ein Klick auf “Get Settings from Account” stellt sie wieder her, sofern sie vorher dorthin gesichert wurden.
[[Image:Testumgebung IDE 03.png]]

== 6. Das Fehlerhandbuch lesen (gilt insbesondere für die Schritte #1-#4 :wink:) ==

Beireits bekannte Fehler werden im [[Entwicklungsumgebung/Fehlerhandbuch|Fehlerhandbuch]] beschrieben.

[[Kategorie:Entwicklung|Entwicklungsumgebung ]]

Entwicklung/Betatest

2026-02-11T13:17:16Z

Fraggle: Kategorie:Überarbeiten

Neue Funktionen der [[Entwicklung|Opencaching-Software]] werden vor Veröffentlichung meist auf einer eigenen Test-Website getestet. Dieses Testsystem ist nicht öffentlich, aus zwei Gründen:

Zum Einen könnte der ungetestete Code noch Fehler enthalten, die die Systemsicherheit oder -Stabilität gefährden. Zum Anderen ist bislang nicht sichergestellt, dass auf Opencaching.de [[Cachestatus#Gesperrt + Versteckt|gesperrte und versteckte]] Caches auch auf dem Testsystem gesperrt und versteckt sind. Solche Caches dürfen oft aus rechtlichen Gründen nicht veröffentlicht werden.

Alle Mitglieder des Opencaching-Teams haben Zugang zum Testsystem. Wer regelmäßig beim Testen helfen möchte, kann sich gerne im [http://forum.opencaching.de/index.php?board=43.0 Entwicklerforum] melden und erhält dann die Zugangsdaten.

== Auf dem eigenen Entwicklersystem testen ==

Wer sich ein [[Entwicklung/Entwicklersystem|Opencaching-Entwicklersystem]] installiert hat, kann den aktuellen Stand auch direkt auf dem eigenen Rechner testen. Dazu ist der ''next''-Branch auszuchecken – er ist identisch mit dem Inhalt des Testsystems:

cd /var/www/html/oc-server/server-3.0
sudo -u apache git checkout next
sudo -u apache git pull upstream next
php bin/dbupdate.php

[[Kategorie:Entwicklung|Betatest]]
[[Kategorie:Überarbeiten]]

Entwicklung/Entwicklersystem

2026-02-11T13:14:35Z

Fraggle: Update 2026

[[Datei:Tux.png|thumb|hochkant=0.75]]
Das '''Entwicklersystem''' von Opencaching.de ist (Stand 2026) eine dockerbasierte, virtuelle Linux-Maschine. Hierauf laufen ein [[wikipedia:Apache HTTP Server|Apache]]- und ein [[wikipedia:MySQL|MySQL]]-Server. Das eigentliche Programmieren und Testen findet auf dem Hostsystem unter Linux, Windows oder MacOS statt, mit einem beliebigen [[wikipedia:UTF-8|UTF-8]]-fähigen Editor bzw. einer [http://forum.opencaching.de/index.php?topic=2150.0 PHP-IDE] und einem Webbrowser.

Die Testumgebung, mit der derzeit entwickelt wird, enthält keine Daten aus der Live-Cachedatenbank, sondern einen Satz vorgefertigter Benutzer und Listings. Im Rahmen von Tests können aber beliebige Änderungen an der Testdatenbank vorgenommen werden.

Wer Spaß daran hat, mit so einer Linux-Maschine rumzuspielen und an Opencaching.de mitzubauen, kann Mitglied im Team werden (mehr dazu im [http://forum.opencaching.de/index.php Forum]), sich die VM herunterladen und einrichten; dazu gibt es eine ausführliche Anleitung.

Eine Anleitung zur Installation eines lokalen Testservers (ohne Listing- und Benutzerdaten des Liveservers) ist [[Entwicklungsumgebung einrichten|hier]] zu finden bzw. etwas kürzer auf [https://github.com/OpencachingDeutschland/oc-server3 github].

Für Fragen und Diskussionen hierzu und zu verwandten Themen gibt es das [https://forum.opencaching.de/viewforum.php?f=43 Entwicklerforum].

Für die Einrichtung einer Opencaching.pl-Website im OC.de-Entwicklersystem gibt es eine [[Entwicklung/Entwicklersystem PL|separate Anleitung]].

== Siehe auch ==
* [[Entwicklung|Opencaching.de-Entwicklung]]

[[Kategorie:Entwicklung|Entwicklersystem]]

Entwicklung

2026-02-11T13:08:45Z

Fraggle: Update wg. Umstieg von Docker auf DDEV

''Diese Seite wendet sich vor allem an Technikinteressierte und verwendet daher eine Menge Fachbegriffe, deren Erläuterung hier zu weit führen würde. Sie sind daher mit Links zur Wikipedia hinterlegt.''
----

[[Datei:Codegenerationen.svg|thumb|[[Opencaching]]-Codehistorie (Stand Juni 2016)]]
Hinter der Opencaching-Website verbergen sich eine Menge Technik und Entwicklungsarbeit. Was im Jahr 2003 als ein kleines Bastelprojekt begann, wuchs im Laufe der Jahre zu einer der weltweit bedeutendesten [[Geocaching-Plattformen]] heran.

Die aktuelle Opencaching.de-Softwareversion 3.0 besteht aus rund 70.000 Zeilen an selbstgeschriebenem [[wikipedia:PHP|PHP]]-, [[wikipedia:Smarty|Smarty]]-, [[wikipedia:Hypertext Markup Language|HTML]]/[[wikipedia:Cascading Style Sheets|CSS]]-, [[wikipedia:JavaScript|Javascript]]- und [[wikipedia:MySQL|MySQL]]-Code. Hinzu kommen ca. 20.000 Zeilen für die [[OKAPI]] und weitere 200.000 Zeilen [[wikipedia:Programmbibliothek|Bibliothekscode]]. Die [[wikipedia:Datenbank|Datenbank]] umfasst ca. 125 Tabellen plus 15 für die OKAPI.

Der Opencaching-Quellcode steht unter einer [https://github.com/OpencachingDeutschland/oc-server3/blob/development/doc/GPL.txt modifizierten GNU-GPL-Lizenz] und ist [https://github.com/OpencachingDeutschland/oc-server3 frei verfügbar]. Erläuterungen dazu gibt es im Artikel [[Entwicklung/Codedoku]].
__NOTOC__
== Entwicklerteam ==
Mit der Gründung des [[Opencaching Deutschland e.V.]] ging die Weiterentwicklung auf ein neues Team über. Die aktiven Softwareentwickler sind in der [http://www.opencaching.de/articles.php?page=team Teamliste] aufgeführt. Neue engagierte Entwickler sind jederzeit willkommen! Wenn du im Team mitmachen möchtest, findest du weitere Informationen dazu im [http://forum.opencaching.de/index.php?board=33.0 Opencaching-Forum].

== Entwicklungsumgebung ==
[[Datei:Tux.png|thumb|hochkant=0.75]]
Stand 2026 steht für die Entwickler eine dockerbasierte, virtuelle Linux-Maschine ([[https://ddev.com/|DDEV]]) zur Verfügung, die wie die Opencaching.de-Website auf [[wikipedia:CentOS|CentOS]] basiert (→ [[Entwicklung/Entwicklersystem|Entwicklersystem]]). In dieser VM laufen ein [[wikipedia:Apache HTTP Server|Apache]]- und ein [[wikipedia:MySQL|MySQL]]-Server. Das eigentliche Programmieren und Testen findet auf dem Hostsystem unter Linux, Windows oder MacOS statt, mit einem beliebigen [[wikipedia:UTF-8|UTF-8]]-fähigen Editor bzw. einer PHP-[[wikipedia:Integrierte Entwicklungsumgebung|IDE]] und einem Webbrowser.

Zur Codeverwaltung und Versionierung wird [[wikipedia:Git|Git]] eingesetzt, mit einem üblichen Workflow (Stable-Branch, Entwicklungs-Branch, Test-Branch und Feature-Branches). Eine ausführliche Anleitung dazu gibt es [[Entwicklung/Git|hier im Wiki]].

Anstehenden Aufgaben werden in einer [[Entwicklung/Todo-Liste|Todo-Liste]] verwaltet.

Allgemeine Diskussionen finden im [http://forum.opencaching.de/index.php?board=43.0 offenen Entwicklerforum] statt. Im internen Team-Wiki gibt es Anleitungen zu Installation und Verwendung der Entwicklungsumgebung; diese sollen nach Neuaufsetzen der Entwicklungsumgebung hier ins allgemeine Wiki übertragen werden.

== Datenschnittstellen für Tool- und App-Entwickler ==
Über die [[Opencaching-API]] (OKAPI) oder die [[XML-Schnittstelle]] können alle Cache- und Logdaten frei heruntergeladen werden. Die OKAPI kann auch [[Das Onlinelog|Logs]] hochladen, sodass auch [[Smartphone-Apps für Opencaching.de|Smartphone-Apps]] mit [[Fachjargon#Field Logging|Field-Logging]]-Funktion realisierbar sind.

== Weitere Opencaching-Entwicklungsprojekte ==
* [https://github.com/opencaching/opencaching-pl Opencaching Polen]
* [https://github.com/opencaching/okapi Opencaching-API]

[[Kategorie:Entwicklung| ]]

Entwicklungsumgebung/Fehlerhandbuch

2026-02-11T12:57:31Z

Fraggle: docker-Meldungen als 'veraltet' markiert

Während der Installation der Programme oder Einrichtung der Testumgebung kann es zu diversen Fehlern und Meldungen kommen. Im Folgenden sind bereits bekannte Meldungen aufgelistet, die bei einer schnellen Behebung helfen sollen.

== Fehlermeldungen während der Paketinstallation ==
==== Während der Installation der benötigten Pakete, kommt es zu einer Meldung, dass Abhängigkeiten mit dem ‘libdvd-pkg’ Paket nicht aufgelöst werden können ====

Eine Rekonfiguration des Pakets schafft Abhilfe:
<nowiki>sudo dpkg-reconfigure libdvd-pkg</nowiki>

== Fehlermeldungen in Zusammenhang mit der DDEV-Testumgebung ==
==== Fehler “ERROR: for opencaching-mariadb Cannot start service mariadb: driver failed programming external connectivity on endpoint opencaching-mariadb [..] Error starting userland proxy: listen tcp 0.0.0.0:3306: bind: address already in use” ====
Wenn beim 'ddev start' diese Fehlermeldung kommt, läuft im Hintergrund bereits ein anderer Webservice (z.B. mysql) auf Port 3306.

Prüfen kann man das mit:
netstat -tanp | grep :3306

Zum Beispiel ein mysql-Webserver kann gestoppt werden mit:
sudo mysqladmin -u root shutdown

== Fehlermeldungen beim Zugriff auf die Datenbank ==
==== Fehlermeldung “ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)” ====
Es wurde vergessen, den Namen der Datenbank in der Kommandozeile zu übergeben.
mysql -uroot -proot -hopencaching-db opencaching

== Fehlermeldungen beim Zugriff auf die Testserverdomain(s) ==
==== Vorgehen zum Anlegen eines weiteren Benutzers (betrifft Legacy-Testsystem) ====
Zuerst via https://opencaching.ddev.site/register.php einen neuen Nutzer registrieren. Zwar kommt dann die Meldung, dass der Aktivierungscode per Mail zugsandt wurde, dies passiert aber nie. Der Aktivierungscode muss aus der Test-Datenbank ausgelesen werden.
Der Code steht in Tabelle ''user'' im Feld ''activation_code''.

Mit https://opencaching.ddev.site/activation.php gelangt man zur Account-Aktivierungsseite. Hier die E-Mail-Adresse und den aus der Datenbank kopierten Aktivierungscode eingeben. Der Account ist nun aktiviert, aber falls der Login nicht funktioniert: siehe andere Fehlermeldung hier auf der Seite weiter unten.

Info: Eventuell wird in Zukunft der MailHog zum Laufen gebracht. Dann werden die vom Server verschickten Emails von diesem abgefangen und man kann die Informationen darin lesen.

==== Der neu angelegte Benutzer kann sich nicht einloggen und wird immer wieder ohne Meldung auf die Login-Seite geleitet (betrifft Legacy-Testsystem) ====
Die exakte Ursache ist nicht bekannt. Abhilfe kann geschaffen werden, wenn beim entsprechenden Nutzer in der Datenbank in der Tabelle ''user'' das Feld ''permanent_login_flag'' auf ''1'' gesetzt wird.

==== Es kann kein Logbild hochgeladen werden (betrifft Legacy-Testsystem) ====
Sobald man ein Logbild hochladen möchte, erscheint eine Fehlermeldung
<nowiki>Warning: move_uploaded_file(): Unable to move '/tmp/phpGmSzpi' to '/application/htdocs/config2/../images/uploads/700770A6-C101-11EA-BA77-0242AC120005.jpg' in /application/htdocs/lib2/logic/picture.class.php on line 856</nowiki>
Abhilfe: (noch) keine Ahnung. Die Bilder wurden aber trotzdem hochgeladen.

==== Bei Anlegen/Editieren eines Listings funktioniert die Attributeauswahl nicht (betrifft Legacy-Testsystem) ====
Editiert man ein Listing, stehen nicht alle Attribute zur Verfügung bzw. es können nicht alle Attribute ausgewählt werden.

Abhilfe: (noch) keine Ahnung.

==== Es kann nicht auf die Domains opencaching.ddev.site oder try-opencaching.ddev.site zugegriffen werden. ====
Normalerweise sollte der Zugriff nach Installation der Testumgebung automatisch funktionieren. Sollte das nicht der Fall sein, kann mittels Anpassung der hosts-Datei ein Workaround geschaffen werden:
<nowiki>127.0.0.1 opencaching.ddev.site
127.0.0.1 try-opencaching.ddev.site</nowiki>

==== Abschalten von “NOTICE”-Meldungen. (betrifft Legacy-Testsystem) ====
Aufgrund diverser (Smarty- und PHP-)Updates werden vormals ignorierte Probleme nun mit einer “NOTICE”-Meldung kenntlich gemacht. Um die Meldungen zu unterdrücken, kann in das error_reporting Level geändert werden.

Beispiele für Fehlermeldungen:
<nowiki>Notice: Undefined index: error_password_not_ok in /app/htdocs/var/cache2/smarty/compiled/..
Notice: Trying to get property 'value' of non-object in /app/..</nowiki>

Abhilfe:
Bis Smarty 3.x: In der Datei /htdocs/vendor/smarty/smarty/libs/Smarty.class.php die Zeile mit $error_reporting ändern auf den nachfolgenden Code. Die Änderung ist nicht git-relevant und geht nach jedem “ddev init” verloren.
<nowiki>public $error_reporting = E_ALL & ~E_NOTICE;</nowiki>

Ab Smarty 3.x und 4.x: In der Datei /htdocs/lib2/common.inc.php die obere Zeile (PHP_DEBUG_ON) mit $error_reporting ändern auf den nachfolgenden Code. Die Änderung ist permanent und muss vor einem Commit rückgängig gemacht werden, da sie sonst im github Repository landet.
<nowiki>ini_set('error_reporting', E_ALL & ~E_NOTICE);</nowiki>

== gelöste und veraltete Fehlermeldungen ==
==== [veraltet] Fehler “starting opencaching-webserver .. error” oder “Starting webserver ... error” ====
Vermutlich läuft im Hintergrund bereits ein anderer Webservice auf Port 80.

Prüfen kann man das mit:
netstat -tanp | grep :80

Zum Beispiel ein apache2-Webserver kann gestoppt werden mit:
sudo systemctl stop apache2

Damit der apache2 nach einem Rechnerneustart nicht erneut aktiviert wird, kann man ihn generell deaktivieren:
sudo systemctl disable apache2

Alternativ lässt sich auch eine [[https://docs.docker.com/compose/extends/|Override-Datei]] für die betroffenen Ports verwenden, was allerdings weitere Komplikationen mit sich führen kann (wie beispielsweise eine nicht funktionierende OKAPI). Aus diesem Grund sollte nach Möglichkeit das Stoppen der Standard-Services für Apache und einen Datenbank-Server vorgezogen werden.

==== [veraltet] Fehler “W: GPG error: https://dl.yarnpkg.com/debian stable InRelease: The following signatures were invalid: EXPKEYSIG“ ====
Nach dem Ausführen von ./psh.phar docker:start kommt der Fehler. Hier ist das Zertifikat veraltet. Folgender Befehl löscht das Docker-Image.
docker-compose build --pull

Mit einen erneuten ./psh.phar docker:start läuft es wieder durch.

==== [veraltet] Fehler "The stream or file "/application/htdocs/var/logs/dev/dev.log" could not be opened: failed to open stream: Permission denied" oder ähnlich (betrifft Legacy-Testsystem) ====
==== [veraltet] Oder: Fehler "Permission denied" beim Zugriff auf /htdocs/var/cache (betrifft Legacy-Testsystem) ====
==== [veraltet] Oder: Fehler 500 (ohne weitere Angaben, warum) (betrifft Legacy-Testsystem) ====
Hier scheint der Webserver keine Zugriffsberechtigung auf bestimmte Pfade/Dateien zu haben. Von einem Ändern der Zugriffsberechtigungen, z. B. mittels sudo chmod -R 777 ./var/log, sollte aus Sicherheitsgründen aber Abstand genommen werden.

Helfen kann, die Befehlsfolge
./psh.phar docker:ssh
./psh.phar docker:init
exit
ein weiteres Mal auszuführen.

Falls dies weiterhin keinen Erfolg bringt, können folgende Schritte zum Ändern der Zugriffsberechtigungen angewandt werden:
# Ermitteln der ID des Containers oc-server3_php-fpm mittels sudo docker ps.
# Öffnen einer Shell im Container: sudo docker exec -it 45b6e4994fac /bin/bash, wobei 45b6e4994fac die ID des Containers ist.
# In der Container-Shell chmod -R 777 /application/htdocs/var/logs/dev/ ausführen.
# Die Container-Shell regulär mittels exit verlassen.

==== [veraltet] Host-Mismatch bei Aufruf der OKAPI mit Port-Override ====
Falls in einer Override-Datei Ports überschrieben werden (siehe oben), funktioniert die OKAPI möglicherweise nicht richtig - stattdessen erscheint ein Hinweis auf einen Port-Mismatch. Dies kann auf folgende Art und Weise behoben werden:
# Ermitteln der ID des Containers ''oc-server3_php-fpm'' mittels ''sudo docker ps''.
# Öffnen einer Shell im Container: ''sudo docker exec -it 45b6e4994fac /bin/bash'', wobei 45b6e4994fac die ID des Containers ist.
# Im Container einen Editor installieren, beispielsweise nano. Da der Container auf Ubuntu basiert, funktioniert dies mittels ''apt-get update && apt-get install nano''.
# Die passende Konfigurationsdatei mittels des Editors im Container öffnen, beispielsweise mittels ''nano /application/htdocs/config2/settings.inc.php.''
# Setzen von ''$dev_baseurl = 'http://docker.team-opencaching.de:2200';'' und anschließendes Speichern der Datei. Hierbei ist 2200 der Port, der statt Port 80 für den Webserver in der Override-Datei konfiguriert worden ist.

==== [veraltet] Während docker:init kommt es im Abschnitt (3/31) zu einer Meldung “> mysql -uroot -proot -hmariadb -e "DROP DATABASE IF EXISTS opencaching" ERROR 2005 (HY000): Unknown MySQL server host 'mariadb' (-3).“ ====
Abhilfe: ''./psh.phar docker:init'' darf nicht außerhalb des Dockercontainers aufgerufen werden.

==== [veraltet] Während docker:init kommt es im Abschnitt (13/31) zu einer Meldung “PHP Fatal error: .. __toString() must not throw an exception ..“ ====
Die Ursache ist nicht bekannt. Hier hilft aktuell nur ein Workaround, in dem die Exception im Script auskommentiert wird.

Hierzu in der Datei ''../htdocs/vendor/symfony/symfony/src/Symfony/Component/DependencyInjection/Compiler/AutowirePass.php'' die Zeile 236 ''throw new AutoWiringFailedException'' auskommentieren. Die Datei ist allerdings erst nach dem Ausführens von docker:init vorhanden.

Siehe auch Ticket: [[https://opencaching.atlassian.net/browse/OCC-90|OCC-90: Exception error during docker:init]]

==== [veraltet] Docker Services neu initialisieren, z.B. bei “''W: GPG error: stable InRelease: The following signatures were invalid: EXPKEYSIG 23E7166788B63E1E Yarn Packaging <yarn@dan.cx>''“ ====
Treten während eines docker:init neue, merkwürdige und nicht näher spezifizierbare Fehler auf, kann es helfen, die Dockercontainer neu zu initialisieren mittels:
docker-compose build --pull

==== [veraltet] z.B. bei Update auf Symfony 5.2 kommt während docker:start-clean der Fehler ''”mv: cannot stat '/root/.symfony/bin/symfony': No such file or directory Service 'webserver' failed to build: The command '/bin/sh -c mv /root/.symfony/bin/symfony /usr/local/bin/symfony' returned a non-zero code: 1"'' ====
In diesem Fall in der Datei ''docker/httpd/Dockerfile'' die fehlerverursachende Zeile
RUN mv /root/.symfony/bin/symfony /usr/local/bin/symfony
auskommentieren und docker:start-clean erneut laufen lassen.

==== [veraltet] Während docker:start-clean: ''"\Doctrine\Common\Persistence\Mapping\Driver\MappingDriverChain()" not found'' ====
Dies ist ein Fehler in einem der ''doctrine/*'' Pakete (vermutlich ''doctrine/persistence'') in bestimmten Paketversionen. Hier hilft, die Datei ''/htdocs/vendor/doctrine/doctrine-bundle/Resources/config/orm.xml'' Zeile 32 zu editieren:
<parameter key="doctrine.orm.metadata.driver_chain.class">Doctrine\Common\Persistence\Mapping\Driver\MappingDriverChain</parameter>
zu
<parameter key="doctrine.orm.metadata.driver_chain.class">Doctrine\Persistence\Mapping\Driver\MappingDriverChain</parameter>

Allerdings muss dies zum richtigen Zeitpunkt passieren. Nachdem ''docker:start-clean'' aufgerufen wurde, kurz warten, bis die Pakete heruntergeladen wurden und noch bevor Abschnitt 13/32 anfängt, muss die Datei korrigiert und gespeichert worden sein.

==== [veraltet] Meldung “DEPRECATED: The legacy builder is deprecated and will be removed in a future release. Install the buildx component to build images with [[https://docs.docker.com/go/buildx/|BuildKit]] ====
Der Docker build Prozess wurde geändert. Die bisherige Methode wurde ab Dockerversion 23 als “deprecated” markiert und wird in einer zukünftigen Version entfernt. Siehe [[https://docs.docker.com/engine/deprecated/#legacy-builder-for-linux-images|Deprecated Engine Features]]

==== [veraltet] Meldung “ERROR: BuildKit is enabled but the buildx component is missing or broken.“ ====
Docker Buildkit/buildx soll verwendet werden (DOCKER_BUILDKIT=1), wurde aber nicht installiert.

Abhilfe: Buildkit/buildx Komponente installieren. Vorher müssen aber einige bereits installierte Pakete entfernt werden. Je nach OS gibt es unterschiedliche Anweisungen und Installationswege, siehe hier: [[https://docs.docker.com/engine/install/|Install Docker Engine]]

==== [veraltet] Während docker:start-clean: ''"Browserslist: caniuse-lite is outdated."'' ====
Scheinbar wird die “browserslist” nicht automatisch aktualisiert. (Grund? k.A.)

Zum manuellen Update im Docker:ssh eingeben:
npx browserslist@latest --update-db
bzw.
npx update-browserslist-db@latest

==== [veraltet] Beim Anlegen des ''zweiten'' Cachelistings kommt eine Fehlermeldung (betrifft Legacy-Testsystem) ====
Bei einer ''leeren'' Datenbank funktioniert das Setzen und Hochzählen der OC-Codes nicht. Es muss einmal ein OC-Code von Hand gesetzt werden.

Hierzu auf dem Testserver ein Listing anlegen. Dann für diesen Cache in der Datenbank in der Tabelle ''caches'' das Feld ''wp_oc'' auf einen initialen Wert ändern, z.B. ''OC1234''.

==== [veraltet] Beim Erstellen/Speichern eines Cachelistings kommen mehrere Fehlermeldungen, u.a. “Warning: A non-numeric value encountered in /app/htdocs/newcache.php on line 1025” (betrifft Legacy-Testsystem) ====
[[Image:Fehlerhandbuch Domain 01.png|500px]]

Zuerst muss geschaut werden, ob eventuell der vorige Abschnitt (“Beim Anlegen des zweiten Cachelistings kommt eine Fehlermeldung“) zutrifft. Wurden die dort beschriebenen Maßnahmen bereits umgesetzt, kommt es zwar trotzdem zur Fehlermeldung, das Listing wurde aber erfolgreich angelegt bzw. gespeichert. (Seite neu laden)

==== [veraltet] Das Länderauswahlfeld rechts oben auf der Seite ist leer und funktioniert nicht. (betrifft Legacy-Testsystem) ====
Alle php-Dateien im Cacheverzeichnis htdocs/var/cache2 müssen gelöscht werden.

Das Vorgehen Unter Linux:
<nowiki>./psh.phar docker:stop
rm htdocs/var/cache2/*.inc.php
./psh.phar docker:start</nowiki>

==== [gelöst] Die Übersetzungen funktionieren nicht. Meist wird nur Englischer Text angezeigt. (betrifft Legacy-Testsystem) ====
Die vorhandenen Fremdsprachen werden auf dem Testsystem nicht korrekt dargestellt. Meistens wird nur der Englische Text oder ein Mischmasch aus Englisch und eingestellter Sprache angezeigt.

Abhilfe: im docker:start Skript wurde eine fehlende Komponente ergänzt, welche nun automatisch mitinstalliert wird. Dadurch werden die Sprachdateien korrekt erzeugt und die Übersetzungen funktionieren.

Siehe auch: [[https://opencaching.atlassian.net/browse/RED-1278|RED-1278: Die Übersetzungen funktionieren auf dem Testserver nicht]]
Dieser Fehler sollte somit nicht mehr auftauchen.

==== [gelöst] Beim Löschen von Logs kommt eine Fehlermeldung “This log entry has been created on another Opencaching website. The cache can only be edited there.” ====
Auf dem Testserver werden die Logs laut Datenbank (Tabelle ''cache_logs'', Spalte ''nodes'') als ''node=5'' gespeichert, obwohl es laut Tabelle ''nodes'' diese Ziffer gar nicht gibt.

Um Logs wieder über die normale Loglöschenfunktion löschen zu können, gibt es mehrere Möglichkeiten:
# In der Datenbanktabelle ‘cache_logs’ den Eintrag in Spalte ‘nodes’ auf 4 ändern. (Dies entspricht der ‘Local Development’-Umgebung (siehe Tabelle ‘nodes’)).
# In der Datei ‘/dev-ops/local.team-opencaching.de/templates/config2-settings.inc.tpl.php' den Eintrag ‘$opt['logic']['node']['id'] = 5;’ ändern auf '$opt['logic']['node']['id'] = 4;’ und das docker:init Script ausführen
# Der Pull [[https://github.com/OpencachingDeutschland/oc-server3/pull/830|Pull Request #830 changed node information from 5 to 4]] behebt das Problem.

[[Kategorie:Entwicklung|Fehlerhandbuch ]]

Entwicklungsumgebung einrichten

2026-02-11T12:32:02Z

Fraggle: kleinere Textkorrekturen

Das Einrichten der Testumgebung erfolgt in mehreren Schritten, die im folgenden beschrieben sind. Falls es dabei zu unerwarteten Fehlermeldungen kommt, bitte die letzten Schritte noch einmal genau anschauen und gegebenenfalls wiederholen. Auch ein Blick ins Fehlerhandbuch hilft meistens, da bereits viele Fallstricke entdeckt und beschrieben wurden.

== 1. Das Betriebssystem vorbereiten, entweder Linux oder Windows ==
=== Windows 10 ===
==== Programme installieren ====
Unter Windows ist es standardmäßig nicht möglich, “einfach“ die Linux Distribution Ubuntu zu installieren. Dazu muss vorab erst das WSL2 aktiviert / installiert werden werden (Punkt 1). Im Anschluss ist eine Installation von Ubuntu (18.04 oder höher) möglich. Zudem muss DDEV installiert werden, in welchem dann die Entwicklungsumgebung laufen kann (Punkt 2).

# WSL2 unter Windows10 aktivieren und Ubuntu installieren:
## Aus dem Microsoft-Store: https://aka.ms/wslstorepage (verfügbar seit Nov. 2022)
## Manuell unter [https://learn.microsoft.com/de-de/windows/wsl/install#manual-installation-steps|Installieren von WSL]
# DDEV für Windows installieren: [https://docs.ddev.com/en/stable/#system-requirements-windows-wsl2|Install DDEV WSL2]
# Unter Windows muss in der Hosts-Datei (%windir%\system32\drivers\etc) folgende Eintragung gemacht werden:
<nowiki>127.0.0.1 opencaching.ddev.site
127.0.0.1 try-opencaching.ddev.site</nowiki>

Danach kann Ubuntu gestartet werden (z.B. im “Such“-Menü nach Ubuntu suchen und anklicken). Beim erstmaligen Starten von Ubuntu müssen ein Benutzername und ein Passwort festgelegt werden.

Im Anschluss den Punkten folgen und ausführen, die im nächsten Schritt “Linux” beschrieben werden.

=== Linux ===
Der Linuxartikel wurde erstellt auf Lubuntu 22.04 und erweitert mit Debian 12

==== Programme installieren ====
Folgende Programme sind notwendig und müssen vorab installiert werden:
PHP (aktuell mindestens PHP8.2), diverse PHP-Erweiterungen, ddev, mariadb-client. Für die PHP-Erweiterungen ist eventuell ein zusätzliches PPA-Repository notwendig. Dessen Installation erfordert je nach Betriebssystem ein unterschiedliches Vorgehen.

<nowiki>Ubuntu:
sudo apt install software-properties-common
sudo add-apt-repository ppa:ondrej/php

Debian:
sudo apt install software-properties-common ca-certificates lsb-release apt-transport-https
curl -sSL https://packages.sury.org/php/README.txt | sudo bash -x</nowiki>

Die Pakete lassen sich mit folgenden Befehlen installieren (Versionsnummer kann abweichen).
<nowiki>sudo apt update
sudo apt install php8.2 php8.2-mbstring php8.2-curl php8.2-xml php8.2-mysql
sudo apt install mariadb-client</nowiki>

Sollten beim Installieren der Pakete Fehlermeldungen auftreten, ist es empfehlenswert, die Pakete einzeln zu installieren und auftretende Fehler/Abhängigkeiten einzeln zu lösen.

== 2. Sourcecode von Git laden ==
=== Github ===
Zwar ist zum Herunterlden des Sourcecodes keine Account auf GitHub notwendig, aber zum Hochladen wird einer benötigt. Daher sollte zuerst einen Account auf https://github.com/ angelegt werden.

=== optional: SSH-Keys für Repositorys anlegen und in Github eintragen ===
siehe https://docs.github.com/en/free-pro-team@latest/github/authenticating-to-github/connecting-to-github-with-ssh 
oder: https://www.heise.de/tipps-tricks/SSH-Key-fuer-GitHub-Repositories-einrichten-4627459.html

=== Git lokal installieren ===
Windows: 
siehe: https://github.com/git-for-windows/git/releases 

Linux:
<nowiki>sudo apt install git</nowiki>

=== Sourcecode lokal herunterladen ===
Ein Terminal öffnen, folgende Kommandos ausführen und dabei Namen und Email-Adresse des Git-Accounts eintragen:
<nowiki>git config --global user.name "Your Name Here"
git config --global user.email "your_email@youremail.com"</nowiki>

Im Verzeichnis "home" einen Ordner "opencaching" (Name beliebig) anlegen. Dort folgenden Code ausführen. Dies legt einen Ordner mit dem Namen “oc-server3“ an, lädt den OC-Code aus deinem Github-Fork herunter und kopiert ihn in diesen Ordner.
<nowiki>git clone git@github.com:<DeinGithubBenutzername>/oc-server3</nowiki>

Im Anschluss in den Ordner “oc-server3“ wechseln und den folgenden Befehl ausführen, um bei einem Update den neuesten Sourcecode aus dem Opencaching.de-Repository erhalten zu können:
<nowiki>cd oc-server3
git remote add upstream git@github.com:OpencachingDeutschland/oc-server3</nowiki>

Mit folgendem Befehl gibt es eine Übersicht über die verknüpften Repositorys, die (abgesehen vom Nutzernamen ‘Slini11’) wie in der Grafik aussehen müssen:
<nowiki>git remote -v</nowiki>
[[Image:Testumgebung Git 01.png]]

Nun den Branch “development“ auschecken:
<nowiki>git checkout development</nowiki>

Und den Development-Branch auf aktuellen Stand bringen:
<nowiki>git pull --rebase upstream development </nowiki>

=== Weiterführende Informationen zu Git ===
Diese sind unter anderem im [[Entwicklung/Git|OC-Wiki]] zu finden

== 3. DDEV Entwicklungsumgebung initalisieren ==
=== Entwicklungsumgebung zum ersten Mal starten ===
Zuerst in den Projektordner “oc-server3“ navigieren und dort die Installation der Testumgebung starten.

==== Scripte einzeln ausführen ====
* ddev anstarten. Im Laufe dieses Prozesses wird die hosts-Datei automatisch angepasst.
<nowiki>ddev start</nowiki>

* Starten der Initialisierung der Testumgebung und der Datenbank:
<nowiki>ddev init</nowiki>

* Die Entwicklungsumgebung steht nun über den Browser bereit unter:
https://opencaching.ddev.site
bzw.
https://try-opencaching.ddev.site

* Das Passwort für den Benutzer ''root'' lautet ''developer''. Das Passwort der anderen Benutzer (Benutzernamen siehe Datenbank) lautet ''password''

=== Entwicklungsumgebung ein weiteres Mal starten ===
Die Testumgebung kann neugestartet werden mit:
<nowiki>ddev restart</nowiki>

=== Entwicklungsumgebung stoppen ===
Die Testumgebung kann gestoppt werden mit:
<nowiki>ddev stop</nowiki>

=== Entwicklungsumgebung löschen ===
Die Testumgebung kann im Projektordner gelöscht werden mit:
<nowiki>ddev delete --omit-snapshot</nowiki>
Danach sind ein erneutes ''ddev start'' und ''ddev init'' notwendig.

== 4. Die Testdatenbank füllen ==
Während der Installation wird eine Testdatenbank importiert, die bereits eine kleine Menge an Caches und Nutzern beinhaltet. Ein manueller Import des Datenbankdumps ist somit (seit März 2021) nicht mehr notwendig.

Für den Fall, dass trotzdem Daten exportiert / importiert werden sollen, können folgende Abschnitte berücksichtigt werden:

=== Login auf der Test-Datenbank im ddev-Container ===
<nowiki>mysql -uroot -proot -hopencaching-db opencaching</nowiki>

=== Datenbank innerhalb des ddev-Containers exportieren ===
<nowiki>mysqldump -uroot -proot -hopencaching-db opencaching > file.sql</nowiki>

=== Datenbank außerhalb des ddev-Containers exportieren ===
<nowiki>mysqldump --complete-insert --user root -proot --host 0.0.0.0 opencaching > dump.sql</nowiki>

=== Datenbank im phpStorm exportieren ===
Auf der rechten Bildschirmseite den Databasedialog ausklappen
rechte Maustaste auf die zu exportierende Datenbank “opencaching” => “Export with ‘mysqldump’”

[[Image:Testumgebung DB 01.png]]

Im Exportmenü die Zeile “Statements” umstellen auf “Insert with columns” und eventuell den Ausgabepfad “Out Path” anpassen. Im Kommandofeld den Parameter “--routines“ ergänzen und dann “Run” drücken

[[Image:Testumgebung DB 02.png]]

=== Datenbank-Dump im phpStorm importieren ===
Auf der rechten Bildschirmseite den Databasedialog ausklappen
rechte Maustaste auf die Datenbank => “Restore with ‘mysql’”

[[Image:Testumgebung DB 03.png]]

Im Importmenü den Eingabepfad “Path to dump” anpassen, dann “Run” drücken

[[Image:Testumgebung DB 04.png]]

=== Datenbank in phpStorm anzeigen ===
Ggf. kann es passieren, dass die Datenbank nicht automatisch in phpStorm angezeigt wird. Dazu muss eine neue MariaDB im Datenbank-Menü angelegt werden.

[[Image:Testumgebung DB 05.png]]

Im Anschluss sind die Daten wie im folgenden Screenshot einzutragen. User: “root“ Password: “root“

[[Image:Testumgebung DB 06.png]]

== 5. Die Entwicklungs-IDE vorbereiten ==
Gegebenenfalls sind an der Programmierumgebung Änderungen vorzunehmen, um zum Beispiel [[OC Coding Style|einheitlich formatierten Code]] zu schreiben.

=== Einrichtung des PHP Coding Styles am Beispiel von phpStorm ===
Unter Settings / Code Style / PHP rechts auf “Set from…” klicken und “PSR-12” auswählen. Die Einstellung mit “Apply” bestätigen.
(Weitere Informationen zum Coding Style sind [[OC Coding Style|hier im Wiki]] zu finden.)

[[Image:Testumgebung IDE 01.png|500px]]

=== Symfony Pfade am Beispiel phpStorm anpassen ===
[[Image:Testumgebung IDE 04.jpeg]]

=== Terminalanpassung am Beispiel phpStorm (für Windows-Nutzer) ===
[[Image:Testumgebung IDE 05.png]]

=== hilfreiche Plugins für phpStorm ===
-

=== Synchronisieren/Wiederherstellen der Benutzereinstellungen mittels JetBrains-Server ===
Sofern man bei JetBrains einen Account hat, kann man mit diesem die Einstellungen der lokalen IDE synchronisieren und z.B. nach einer Neuinstallation von dort wiederherstellen.

Hierzu in der IDE rechts oben auf das Zahnrad klicken und “Settings Sync is off” auswählen.
[[Image:Testumgebung IDE 02.png]]

Im folgenden Fenster den Button “Enable Settings Sync” klicken und danach alle Einstellungen auswählen, die man sichern möchte. Ein Klick auf “Push Settings to Account” sichert die Einstellungen. Ein Klick auf “Get Settings from Account” stellt sie wieder her, sofern sie vorher dorthin gesichert wurden.
[[Image:Testumgebung IDE 03.png]]

== 6. Das Fehlerhandbuch lesen (gilt insbesondere für die Schritte #1-#4 :wink:) ==

Beireits bekannte Fehler werden im [[Entwicklungsumgebung/Fehlerhandbuch|Fehlerhandbuch]] beschrieben.

[[Kategorie:Entwicklung|Entwicklungsumgebung ]]

Entwicklungsumgebung einrichten

2026-02-11T11:35:30Z

Fraggle: Update von docker zu ddev

Das Einrichten der Testumgebung erfolgt in mehreren Schritten, die im folgenden beschrieben sind. Falls es dabei zu unerwarteten Fehlermeldungen kommt, bitte die letzten Schritte noch einmal genau anschauen und gegebenenfalls wiederholen. Auch ein Blick ins Fehlerhandbuch hilft meistens, da bereits viele Fallstricke entdeckt und beschrieben wurden.

== 1. Das Betriebssystem vorbereiten, entweder Linux oder Windows ==
=== Windows 10 ===
==== Programme installieren ====
Unter Windows ist es standardmäßig nicht möglich, “einfach“ die Linux Distribution Ubuntu zu installieren. Dazu muss vorab erst das WSL2 aktiviert / installiert werden werden (Punkt 1). Im Anschluss ist eine Installation von Ubuntu (18.04 oder höher) möglich. Zudem muss DDEV installiert werden, in dem dann die Entwicklungsumgebung laufen kann (Punkt 2).

# WSL2 unter Windows10 aktivieren und Ubuntu installieren:
## Aus dem Microsoft-Store: https://aka.ms/wslstorepage (verfügbar seit Nov. 2022)
## Manuell unter [https://learn.microsoft.com/de-de/windows/wsl/install#manual-installation-steps|Installieren von WSL]
# DDEV für Windows installieren: [https://docs.ddev.com/en/stable/#system-requirements-windows-wsl2|Install DDEV WSL2]
# Unter Windows muss in der Hosts-Datei (%windir%\system32\drivers\etc) folgende Eintragung gemacht werden:
<nowiki>127.0.0.1 opencaching.ddev.site
127.0.0.1 try-opencaching.ddev.site</nowiki>

Danach kann Ubuntu gestartet werden (z.B. im “Such“-Menü nach Ubuntu suchen und anklicken). Beim erstmaligen Starten von Ubuntu müssen ein Benutzername und ein Passwort festgelegt werden.

Im Anschluss den Punkten folgen und ausführen, die im nächsten Schritt “Linux” beschrieben werden.

=== Linux ===
Der Linuxartikel wurde erstellt auf Lubuntu 22.04 und erweitert mit Debian 12

==== Programme installieren ====
Folgende Programme sind notwendig und müssen vorab installiert werden:
PHP (aktuell mindestens PHP8.2), diverse PHP-Erweiterungen, ddev, mariadb-client. Für die PHP-Erweiterungen ist eventuell ein zusätzliches PPA-Repository notwendig. Dessen Installation erfordert je nach Betriebssystem ein unterschiedliches Vorgehen.

<nowiki>Ubuntu:
sudo apt install software-properties-common
sudo add-apt-repository ppa:ondrej/php

Debian:
sudo apt install software-properties-common ca-certificates lsb-release apt-transport-https
curl -sSL https://packages.sury.org/php/README.txt | sudo bash -x</nowiki>

Die Pakete lassen sich mit folgenden Befehlen installieren (Versionsnummer kann abweichen).
<nowiki>sudo apt update
sudo apt install php8.2 php8.2-mbstring php8.2-curl php8.2-xml php8.2-mysql
sudo apt install mariadb-client</nowiki>

Sollten beim Installieren der Pakete Fehlermeldungen auftreten, ist es empfehlenswert, die Pakete einzeln zu installieren und auftretende Fehler/Abhängigkeiten einzeln zu lösen.

== 2. Sourcecode von Git laden ==
=== Github ===
Zwar ist zum Herunterlden des Sourcecodes keine Account auf GitHub notwendig, aber zum Hochladen wird einer benötigt. Daher sollte zuerst einen Account auf https://github.com/ angelegt werden.

=== optional: SSH-Keys für Repositorys anlegen und in Github eintragen ===
siehe https://docs.github.com/en/free-pro-team@latest/github/authenticating-to-github/connecting-to-github-with-ssh 
oder: https://www.heise.de/tipps-tricks/SSH-Key-fuer-GitHub-Repositories-einrichten-4627459.html

=== Git lokal installieren ===
Windows: 
siehe: https://github.com/git-for-windows/git/releases 

Linux:
<nowiki>sudo apt install git</nowiki>

=== Sourcecode lokal herunterladen ===
Ein Terminal öffnen, folgende Kommandos ausführen und dabei Namen und Email-Adresse des Git-Accounts eintragen:
<nowiki>git config --global user.name "Your Name Here"
git config --global user.email "your_email@youremail.com"</nowiki>

Im Verzeichnis "home" einen Ordner "opencaching" (Name beliebig) anlegen. Dort folgenden Code ausführen. Dies legt einen Ordner mit dem Namen “oc-server3“ an, lädt den OC-Code aus deinem Github-Fork herunter und kopiert ihn in diesen Ordner.
<nowiki>git clone git@github.com:<DeinGithubBenutzername>/oc-server3</nowiki>

Im Anschluss in den Ordner “oc-server3“ wechseln und den folgenden Befehl ausführen, um bei einem Update den neuesten Sourcecode aus dem Opencaching.de-Repository erhalten zu können:
<nowiki>cd oc-server3
git remote add upstream git@github.com:OpencachingDeutschland/oc-server3</nowiki>

Mit folgendem Befehl gibt es eine Übersicht über die verknüpften Repositorys, die (abgesehen vom Nutzernamen ‘Slini11’) wie in der Grafik aussehen müssen:
<nowiki>git remote -v</nowiki>
[[Image:Testumgebung Git 01.png]]

Nun den Branch “development“ auschecken:
<nowiki>git checkout development</nowiki>

Und den Development-Branch auf aktuellen Stand bringen:
<nowiki>git pull --rebase upstream development </nowiki>

=== Weiterführende Informationen zu Git ===
Diese sind unter anderem im [[Entwicklung/Git|OC-Wiki]] zu finden

== 3. DDEV Entwicklungsumgebung initalisieren ==
=== Entwicklungsumgebung zum ersten Mal starten ===
Zuerst in den Projektordner “oc-server3“ navigieren und dort die Installation der Testumgebung starten.

==== Scripte einzeln ausführen ====
* ddev anstarten. Im Laufe dieses Prozesses wird die hosts-Datei automatisch angepasst.
<nowiki>ddev start</nowiki>

* Starten der Initialisierung der Testumgebung und der Datenbank:
<nowiki>ddev init</nowiki>

* Die Entwicklungsumgebung steht nun über den Browser bereit unter:
https://opencaching.ddev.site
bzw.
https://try-opencaching.ddev.site

* Das Passwort für den Benutzer ''root'' lautet ''developer''. Das Passwort der anderen Benutzer (Benutzernamen siehe Datenbank) lautet ''password''

=== Entwicklungsumgebung ein weiteres Mal starten ===
Die Testumgebung kann z.B. nach einem Neustart des Rechners im Projektordner gestartet werden mit:
<nowiki>ddev restart</nowiki>

=== Entwicklungsumgebung löschen ===
Die Testumgebung kann im Projektordner gestoppt werden mit:
<nowiki>ddev delete --omit-snapshot</nowiki>
Danach sind ein erneutes ''ddev start'' und ''ddev init'' notwendig.

== 4. Die Testdatenbank füllen ==
Während der Installation wird eine Testdatenbank importiert, die bereits eine kleine Menge an Caches und Nutzern beinhaltet. Ein manueller Import des Datenbankdumps ist somit (seit März 2021) nicht mehr notwendig.

Für den Fall, dass trotzdem Daten exportiert / importiert werden sollen, können folgende Abschnitte berücksichtigt werden:
Login auf der Test-Datenbank im ddev-Container
<nowiki>mysql -uroot -proot -hopencaching-db opencaching</nowiki>

=== Datenbank innerhalb des ddev-Containers exportieren ===
<nowiki>mysqldump -uroot -proot -hopencaching-db opencaching > file.sql</nowiki>

=== Datenbank außerhalb des ddev-Containers exportieren ===
<nowiki>mysqldump --complete-insert --user root -proot --host 0.0.0.0 opencaching > dump.sql</nowiki>

=== Datenbank im phpStorm exportieren ===
Auf der rechten Bildschirmseite den Databasedialog ausklappen
rechte Maustaste auf die zu exportierende Datenbank “opencaching” => “Export with ‘mysqldump’”

[[Image:Testumgebung DB 01.png]]

Im Exportmenü die Zeile “Statements” umstellen auf “Insert with columns” und eventuell den Ausgabepfad “Out Path” anpassen. Im Kommandofeld den Parameter “--routines“ ergänzen und dann “Run” drücken

[[Image:Testumgebung DB 02.png]]

=== Datenbank-Dump im phpStorm importieren ===
Auf der rechten Bildschirmseite den Databasedialog ausklappen
rechte Maustaste auf die Datenbank => “Restore with ‘mysql’”

[[Image:Testumgebung DB 03.png]]

Im Importmenü den Eingabepfad “Path to dump” anpassen, dann “Run” drücken

[[Image:Testumgebung DB 04.png]]

=== Datenbank in phpStorm anzeigen ===
Ggf. kann es passieren, dass die Datenbank nicht automatisch in phpStorm angezeigt wird. Dazu muss eine neue MariaDB im Datenbank-Menü angelegt werden.

[[Image:Testumgebung DB 05.png]]

Im Anschluss sind die Daten wie im folgenden Screenshot einzutragen. User: “root“ Password: “root“

[[Image:Testumgebung DB 06.png]]

== 5. Die Entwicklungs-IDE vorbereiten ==
Gegebenenfalls sind an der Programmierumgebung Änderungen vorzunehmen, um zum Beispiel [[OC Coding Style|einheitlich formatierten Code]] zu schreiben.

=== Einrichtung des PHP Coding Styles am Beispiel von phpStorm ===
Unter Settings / Code Style / PHP rechts auf “Set from…” klicken und “PSR-12” auswählen. Die Einstellung mit “Apply” bestätigen.
(Weitere Informationen zum Coding Style sind [[OC Coding Style|hier im Wiki]] zu finden.)

[[Image:Testumgebung IDE 01.png|500px]]

=== Symfony Pfade am Beispiel phpStorm anpassen ===
[[Image:Testumgebung IDE 04.jpeg]]

=== Terminalanpassung am Beispiel phpStorm (für Windows-Nutzer) ===
[[Image:Testumgebung IDE 05.png]]

=== hilfreiche Plugins für phpStorm ===
-

=== Synchronisieren/Wiederherstellen der Benutzereinstellungen mittels JetBrains-Server ===
Sofern man bei JetBrains einen Account hat, kann man mit diesem die Einstellungen der lokalen IDE synchronisieren und z.B. nach einer Neuinstallation von dort wiederherstellen.

Hierzu in der IDE rechts oben auf das Zahnrad klicken und “Settings Sync is off” auswählen.
[[Image:Testumgebung IDE 02.png]]

Im folgenden Fenster den Button “Enable Settings Sync” klicken und danach alle Einstellungen auswählen, die man sichern möchte. Ein Klick auf “Push Settings to Account” sichert die Einstellungen. Ein Klick auf “Get Settings from Account” stellt sie wieder her, sofern sie vorher dorthin gesichert wurden.
[[Image:Testumgebung IDE 03.png]]

== 6. Das Fehlerhandbuch lesen (gilt insbesondere für die Schritte #1-#4 :wink:) ==

Beireits bekannte Fehler werden im [[Entwicklungsumgebung/Fehlerhandbuch|Fehlerhandbuch]] beschrieben.

[[Kategorie:Entwicklung|Entwicklungsumgebung ]]

Entwicklungsumgebung einrichten

2025-12-02T20:46:42Z

Fraggle: add docker-buildx

Das Einrichten der Testumgebung erfolgt in mehreren Schritten, die im folgenden beschrieben sind. Falls es dabei zu unerwarteten Fehlermeldungen kommt, bitte die letzten Schritte noch einmal genau anschauen und gegebenenfalls wiederholen. Auch ein Blick ins Fehlerhandbuch hilft meistens, da bereits viele Fallstricke entdeckt und beschrieben wurden.

== 1. Das Betriebssystem vorbereiten, entweder Linux oder Windows ==
=== Windows 10 ===
==== Programme installieren ====
Unter Windows ist es standardmäßig nicht möglich, “einfach“ die Linux Distribution Ubuntu zu installieren. Dazu muss vorab erst das WSL2 aktiviert / installiert werden werden (Punkt 1). Im Anschluss ist eine Installation von Ubuntu (18.04 oder 20.04 oder höher) möglich. Zudem muss Docker installiert werden, in dem dann die Entwicklungsumgebung laufen kann (Punkt 2).

# WSL2 unter Windows10 aktivieren und Ubuntu 20.04 installieren:
## Aus dem Microsoft-Store: https://aka.ms/wslstorepage (verfügbar seit Nov. 2022)
## Manuell unter [https://learn.microsoft.com/de-de/windows/wsl/install#manual-installation-steps|Installieren von WSL]
# Docker für Windows installieren: [https://docs.docker.com/docker-for-windows/install/|Install Docker Desktop on Windows]
# Unter Windows muss in der Hosts-Datei (%windir%\system32\drivers\etc) folgende Eintragung gemacht werden:
<nowiki>127.0.0.1 docker.team-opencaching.de
127.0.0.1 try.docker.team-opencaching.de</nowiki>

Danach kann Ubuntu gestartet werden (z.B. im “Such“-Menü nach Ubuntu suchen und anklicken). Beim erstmaligen Starten von Ubuntu müssen ein Benutzername und ein Passwort festgelegt werden.

Im Anschluss den Punkten folgen und ausführen, die im nächsten Schritt “Linux” beschrieben werden.

=== Linux ===
Der Linuxartikel wurde erstellt auf Lubuntu 18.04, aktualisiert mit 22.04 und erweitert mit Debian 12

==== Programme installieren ====
Folgende Programme sind notwendig und müssen vorab installiert werden:
PHP (aktuell mind. PHP7.4, später PHP8), diverse PHP-Erweiterungen, docker-compose, mariadb-client. Für die PHP-Erweiterungen ist eventuell ein zusätzliches PPA-Repository notwendig. Dessen Installation erfordert je nach Betriebssystem ein unterschiedliches Vorgehen.

<nowiki>Ubuntu:
sudo apt install software-properties-common
sudo add-apt-repository ppa:ondrej/php

Debian:
sudo apt install software-properties-common ca-certificates lsb-release apt-transport-https
curl -sSL https://packages.sury.org/php/README.txt | sudo bash -x</nowiki>

Die Pakete lassen sich mit folgenden Befehlen installieren (Versionsnummer kann abweichen).
<nowiki>sudo apt update
sudo apt install php8 php8.0-mbstring php8.0-curl php8.0-xml php8.0-mysql
sudo apt install docker-compose docker-buildx
sudo apt install mariadb-client</nowiki>

Sollten beim Installieren der Pakete Fehlermeldungen auftreten, ist es empfehlenswert, die Pakete einzeln zu installieren und auftretende Fehler/Abhängigkeiten einzeln zu lösen.

==== Nutzer in docker-Gruppe aufnehmen ====
Der aktuelle Benutzer muss in die Gruppe “docker” aufgenommen werden, sonst kann es passieren, dass dieser keinen Zugriff auf die Dockercontainer bekommt.
<nowiki>sudo usermod -aG docker $(id -un)</nowiki>

Die Änderung wird aber erst nach einem Ab-/Anmelden des Nutzers wirksam. Überprüft werden kann dies danach mittels
<nowiki>id</nowiki>

Hier muss die “docker”-Gruppe aufgelistet sein. Beispiel:
<nowiki>uid=1000(user) gid=1000(user) groups=1000(user),4(adm),24(cdrom),..,128(docker)</nowiki>

==== Eigenschaften der Docker Socket-Datei prüfen ====
Den folgenden Befehl ausführen, um die Eigenschaften der Datei anzeigen zu lassen:
<nowiki>sudo ls -la /var/run/docker.sock</nowiki>

Die Datei muss dabei ‘docker’ zugewiesen sein:
<nowiki>rw-rw---- 1 root docker 0 Dec 21 19:16 /var/run/docker.sock</nowiki>

Ist dies nicht der Fall, muss die Zugehörigkeit geändert werden:
<nowiki>chgrp docker /var/run/docker.sock</nowiki>

==== host Datei anpassen ====
Die folgenden zwei Einträge sollten der host Date unter /etc/host hinzugefügt werden, da auf die URLs sonst unter Umständen nicht zugegriffen werden kann.
<nowiki>127.0.0.1 docker.team-opencaching.de
127.0.0.1 try.docker.team-opencaching.de</nowiki>

== 2. Sourcecode von Git laden ==
=== Github ===
Zwar ist zum Herunterlden des Sourcecodes keine Account auf GitHub notwendig, aber zum Hochladen wird einer benötigt. Daher sollte zuerst einen Account auf https://github.com/ angelegt werden.

=== optional: SSH-Keys für Repositorys anlegen und in Github eintragen ===
siehe https://docs.github.com/en/free-pro-team@latest/github/authenticating-to-github/connecting-to-github-with-ssh 
oder: https://www.heise.de/tipps-tricks/SSH-Key-fuer-GitHub-Repositories-einrichten-4627459.html

=== Git lokal installieren ===
Windows: 
siehe: https://github.com/git-for-windows/git/releases 

Linux:
<nowiki>sudo apt install git</nowiki>

=== Sourcecode lokal herunterladen ===
Ein Terminal öffnen, folgende Kommandos ausführen und dabei Namen und Email-Adresse des Git-Accounts eintragen:
<nowiki>git config --global user.name "Your Name Here"
git config --global user.email "your_email@youremail.com"</nowiki>

Im Verzeichnis "home" einen Ordner "opencaching" (Name beliebig) anlegen. Dort folgenden Code ausführen. Dies legt einen Ordner mit dem Namen “oc-server3“ an, lädt den OC-Code aus deinem Github-Fork herunter und kopiert ihn in diesen Ordner.
<nowiki>git clone git@github.com:<DeinGithubBenutzername>/oc-server3</nowiki>

Im Anschluss in den Ordner “oc-server3“ wechseln und den folgenden Befehl ausführen, um bei einem Update den neuesten Sourcecode aus dem Opencaching.de-Repository erhalten zu können:
<nowiki>cd oc-server3
git remote add upstream git@github.com:OpencachingDeutschland/oc-server3</nowiki>

Mit folgendem Befehl gibt es eine Übersicht über die verknüpften Repositorys, die (abgesehen vom Nutzernamen ‘Slini11’) wie in der Grafik aussehen müssen:
<nowiki>git remote -v</nowiki>
[[Image:Testumgebung Git 01.png]]

Nun den Branch “development“ auschecken:
<nowiki>git checkout development</nowiki>

Und den Development-Branch auf aktuellen Stand bringen:
<nowiki>git pull --rebase upstream development </nowiki>

=== Weiterführende Informationen zu Git ===
Diese sind unter anderem im [[Entwicklung/Git|OC-Wiki]] zu finden

== 3. Docker Entwicklungsumgebung initalisieren ==
=== Entwicklungsumgebung zum ersten Mal starten ===
(siehe auch: Github: [https://github.com/OpencachingDeutschland/oc-server3#starting-the-docker-development-environment|starting the docker environment])

Zuerst in den Projektordner “oc-server3“ navigieren und dort die Installation der Testumgebung starten. Es stehen hierfür zwei Befehlsfolgen zur Verfügung:

==== Scripte einzeln ausführen ====
* Die Dockerumgebung starten (ggf. der Benutzerkontensteuerung zustimmen). Dieser Vorgang dauert ein paar Minuten.
<nowiki>./psh.phar docker:start</nowiki>

* In den Dockercontainer hinein verbinden
<nowiki>./psh.phar docker:ssh</nowiki>

* Anschließend in der sich öffnenden docker bash einmalig das Initialisierungsskript starten. Dieser Vorgang dauert ein paar Minuten.
<nowiki>./psh.phar docker:init</nowiki>

[[Image:Testumgebung Docker 01.png]]

* Zuletzt den Dockercontainer wieder verlassen
<nowiki>exit</nowiki>

* Die Entwicklungsumgebung steht nun über den Browser bereit unter:
http://docker.team-opencaching.de bzw.
http://try.docker.team-opencaching.de

* Das Passwort für den Benutzer ''root'' lautet ''developer''. Das Passwort der anderen Benutzer (Benutzernamen siehe Datenbank) lautet ''password''

==== Das start-Script ausführen ====
* Statt die Schritte einzeln auszuführen, kann die Dockerinitialisierung auch mit einem einzigen Befehl gestartet werden:
<nowiki>./psh.phar docker:start-clean</nowiki>

Dieser Befehl führt alle oben beschriebenen Kommandos aus, löscht zusätzlich die Dockercontainer, den Cache des Testservers sowie alle von git ignorierten Dateien. Dieser Vorgang dauert ein paar Minuten länger und empfiehlt sich, wenn eine saubere Umgebung hergestellt werden soll oder während der Initialisierung unbehebbare Fehler auftreten.

* Die Entwicklungsumgebung steht nun über den Browser bereit unter:
http://docker.team-opencaching.de bzw.
http://try.docker.team-opencaching.de

* Das Passwort für den Benutzer ''root'' lautet ''developer''. Das Passwort der anderen Benutzer (Benutzernamen siehe Datenbank) lautet ''password''

=== Entwicklungsumgebung ein weiteres Mal starten ===
Die Testumgebung kann z.B. nach einem Neustart des Rechners im Projektordner gestartet werden mit:
<nowiki>./psh.phar docker:start</nowiki>

=== Entwicklungsumgebung stoppen ===
Die Testumgebung kann im Projektordner gestoppt werden mit:
<nowiki>./psh.phar docker:stop</nowiki>

== 4. Die Testdatenbank füllen ==
Während der Installation wird eine Testdatenbank importiert, die bereits eine kleine Menge an Caches und Nutzern beinhaltet. Ein manueller Import des Datenbankdumps ist somit (seit März 2021) nicht mehr notwendig.

Für den Fall, dass trotzdem Daten exportiert / importiert werden sollen, können folgende Abschnitte berücksichtigt werden:
Login auf der Test-Datenbank im Dockercontainer
<nowiki>mysql -uroot -proot -hmariadb opencaching</nowiki>

=== Datenbank zurücksetzen ===
<nowiki>(noch zu verifizieren und zu verbessern..)
im Docker per mysql auf die mariadb verbinden
'DROP' opencaching DB
exit mysql und docker
Nun entweder im Docker ein ./psh.phar docker:init ausführen oder wenn das Fehler bringt, vorher den kompletten git-Pfad neu aufsetzen
Ev. funktioniert auch der Weg, den DB-Dockercontainer aufzurufen, zu löschen, etc.
(docker-volume ls)</nowiki>

=== Datenbank innerhalb des Dockercontainers exportieren ===
<nowiki>mysqldump -uroot -proot -hmariadb opencaching > file.sql</nowiki>

=== Datenbank außerhalb des Dockercontainers exportieren ===
<nowiki>mysqldump --complete-insert --user root -proot --host 0.0.0.0 opencaching > dump.sql</nowiki>

=== Datenbank im phpStorm exportieren ===
Auf der rechten Bildschirmseite den Databasedialog ausklappen
rechte Maustaste auf die zu exportierende Datenbank “opencaching” => “Export with ‘mysqldump’”

[[Image:Testumgebung DB 01.png]]

Im Exportmenü die Zeile “Statements” umstellen auf “Insert with columns” und eventuell den Ausgabepfad “Out Path” anpassen. Im Kommandofeld den Parameter “--routines“ ergänzen und dann “Run” drücken

[[Image:Testumgebung DB 02.png]]

=== Datenbank-Dump im Dockercontainer importieren ===
Zuerst wird eine eventuell existierende Datenbank gelöscht und neu angelegt.
<nowiki>./psh.phar docker:init</nowiki>
Im zweiten Schritt wird die Datenbank mit dem Dump gefüllt.
<nowiki>mysql -uroot -proot -hmariadb opencaching < file.sql</nowiki>

=== Datenbank-Dump im phpStorm importieren ===
Auf der rechten Bildschirmseite den Databasedialog ausklappen
rechte Maustaste auf die Datenbank => “Restore with ‘mysql’”

[[Image:Testumgebung DB 03.png]]

Im Importmenü den Eingabepfad “Path to dump” anpassen, dann “Run” drücken

[[Image:Testumgebung DB 04.png]]

=== Datenbank in phpStorm anzeigen ===
Ggf. kann es passieren, dass die Datenbank nicht automatisch in phpStorm angezeigt wird. Dazu muss eine neue MariaDB im Datenbank-Menü angelegt werden.

[[Image:Testumgebung DB 05.png]]

Im Anschluss sind die Daten wie im folgenden Screenshot einzutragen. User: “root“ Password: “root“

[[Image:Testumgebung DB 06.png]]

== 5. Die Entwicklungs-IDE vorbereiten ==
Gegebenenfalls sind an der Programmierumgebung Änderungen vorzunehmen, um zum Beispiel [[OC Coding Style|einheitlich formatierten Code]] zu schreiben.

=== Einrichtung des PHP Coding Styles am Beispiel von phpStorm ===
Unter Settings / Code Style / PHP rechts auf “Set from…” klicken und “PSR-12” auswählen. Die Einstellung mit “Apply” bestätigen.
(Weitere Informationen zum Coding Style sind [[OC Coding Style|hier im Wiki]] zu finden.)

[[Image:Testumgebung IDE 01.png|500px]]

=== Symfony Pfade am Beispiel phpStorm anpassen ===
[[Image:Testumgebung IDE 04.jpeg]]

=== Terminalanpassung am Beispiel phpStorm (für Windows-Nutzer) ===
[[Image:Testumgebung IDE 05.png]]

=== hilfreiche Plugins für phpStorm ===
-

=== Synchronisieren/Wiederherstellen der Benutzereinstellungen mittels JetBrains-Server ===
Sofern man bei JetBrains einen Account hat, kann man mit diesem die Einstellungen der lokalen IDE synchronisieren und z.B. nach einer Neuinstallation von dort wiederherstellen.

Hierzu in der IDE rechts oben auf das Zahnrad klicken und “Settings Sync is off” auswählen.
[[Image:Testumgebung IDE 02.png]]

Im folgenden Fenster den Button “Enable Settings Sync” klicken und danach alle Einstellungen auswählen, die man sichern möchte. Ein Klick auf “Push Settings to Account” sichert die Einstellungen. Ein Klick auf “Get Settings from Account” stellt sie wieder her, sofern sie vorher dorthin gesichert wurden.
[[Image:Testumgebung IDE 03.png]]

== 6. Das Fehlerhandbuch lesen (gilt insbesondere für die Schritte #1-#4 :wink:) ==

Beireits bekannte Fehler werden im [[Entwicklungsumgebung/Fehlerhandbuch|Fehlerhandbuch]] beschrieben.

[[Kategorie:Entwicklung|Entwicklungsumgebung ]]

Entwicklungsumgebung/Fehlerhandbuch

2025-09-01T18:25:55Z

Fraggle:

Während der Installation der Programme oder Einrichtung der Testumgebung kann es zu diversen Fehlern und Meldungen kommen. Im Folgenden sind bereits bekannte Meldungen aufgelistet, die bei einer schnellen Behebung helfen sollen.

== Fehlermeldungen während der Paketinstallation ==
==== Während der Installation der benötigten Pakete, kommt es zu einer Meldung, dass Abhängigkeiten mit dem ‘libdvd-pkg’ Paket nicht aufgelöst werden können ====

Eine Rekonfiguration des Pakets schafft Abhilfe:
<nowiki>sudo dpkg-reconfigure libdvd-pkg</nowiki>

== Fehlermeldungen in Zusammenhang mit der Dockerumgebung ==
==== Fehler “starting opencaching-webserver .. error” oder “Starting webserver ... error” ====
Vermutlich läuft im Hintergrund bereits ein anderer Webservice auf Port 80.

Prüfen kann man das mit:
netstat -tanp | grep :80

Zum Beispiel ein apache2-Webserver kann gestoppt werden mit:
sudo systemctl stop apache2

Damit der apache2 nach einem Rechnerneustart nicht erneut aktiviert wird, kann man ihn generell deaktivieren:
sudo systemctl disable apache2

Alternativ lässt sich auch eine [[https://docs.docker.com/compose/extends/|Override-Datei]] für die betroffenen Ports verwenden, was allerdings weitere Komplikationen mit sich führen kann (wie beispielsweise eine nicht funktionierende OKAPI). Aus diesem Grund sollte nach Möglichkeit das Stoppen der Standard-Services für Apache und einen Datenbank-Server vorgezogen werden.

==== Fehler “W: GPG error: https://dl.yarnpkg.com/debian stable InRelease: The following signatures were invalid: EXPKEYSIG“ ====
Nach dem Ausführen von ./psh.phar docker:start kommt der Fehler. Hier ist das Zertifikat veraltet. Folgender Befehl löscht das Docker-Image.
docker-compose build --pull

Mit einen erneuten ./psh.phar docker:start läuft es wieder durch.

==== Fehler “ERROR: for opencaching-mariadb Cannot start service mariadb: driver failed programming external connectivity on endpoint opencaching-mariadb [..] Error starting userland proxy: listen tcp 0.0.0.0:3306: bind: address already in use” ====
Wenn beim docker:start diese Fehlermeldung kommt, läuft im Hintergrund bereits ein anderer Webservice (z.B. mysql) auf Port 3306.

Prüfen kann man das mit:
netstat -tanp | grep :3306

Zum Beispiel ein mysql-Webserver kann gestoppt werden mit:
sudo mysqladmin -u root shutdown

==== Fehler "The stream or file "/application/htdocs/var/logs/dev/dev.log" could not be opened: failed to open stream: Permission denied" oder ähnlich (betrifft Legacy-Testsystem) ====
==== Oder: Fehler "Permission denied" beim Zugriff auf /htdocs/var/cache (betrifft Legacy-Testsystem) ====
==== Oder: Fehler 500 (ohne weitere Angaben, warum) (betrifft Legacy-Testsystem) ====
Hier scheint der Webserver keine Zugriffsberechtigung auf bestimmte Pfade/Dateien zu haben. Von einem Ändern der Zugriffsberechtigungen, z. B. mittels sudo chmod -R 777 ./var/log, sollte aus Sicherheitsgründen aber Abstand genommen werden.

Helfen kann, die Befehlsfolge
./psh.phar docker:ssh
./psh.phar docker:init
exit
ein weiteres Mal auszuführen.

Falls dies weiterhin keinen Erfolg bringt, können folgende Schritte zum Ändern der Zugriffsberechtigungen angewandt werden:
# Ermitteln der ID des Containers oc-server3_php-fpm mittels sudo docker ps.
# Öffnen einer Shell im Container: sudo docker exec -it 45b6e4994fac /bin/bash, wobei 45b6e4994fac die ID des Containers ist.
# In der Container-Shell chmod -R 777 /application/htdocs/var/logs/dev/ ausführen.
# Die Container-Shell regulär mittels exit verlassen.

==== Host-Mismatch bei Aufruf der OKAPI mit Port-Override ====
Falls in einer Override-Datei Ports überschrieben werden (siehe oben), funktioniert die OKAPI möglicherweise nicht richtig - stattdessen erscheint ein Hinweis auf einen Port-Mismatch. Dies kann auf folgende Art und Weise behoben werden:
# Ermitteln der ID des Containers ''oc-server3_php-fpm'' mittels ''sudo docker ps''.
# Öffnen einer Shell im Container: ''sudo docker exec -it 45b6e4994fac /bin/bash'', wobei 45b6e4994fac die ID des Containers ist.
# Im Container einen Editor installieren, beispielsweise nano. Da der Container auf Ubuntu basiert, funktioniert dies mittels ''apt-get update && apt-get install nano''.
# Die passende Konfigurationsdatei mittels des Editors im Container öffnen, beispielsweise mittels ''nano /application/htdocs/config2/settings.inc.php.''
# Setzen von ''$dev_baseurl = 'http://docker.team-opencaching.de:2200';'' und anschließendes Speichern der Datei. Hierbei ist 2200 der Port, der statt Port 80 für den Webserver in der Override-Datei konfiguriert worden ist.

==== Während docker:init kommt es im Abschnitt (3/31) zu einer Meldung “> mysql -uroot -proot -hmariadb -e "DROP DATABASE IF EXISTS opencaching" ERROR 2005 (HY000): Unknown MySQL server host 'mariadb' (-3).“ ====
Abhilfe: ''./psh.phar docker:init'' darf nicht außerhalb des Dockercontainers aufgerufen werden.

==== Während docker:init kommt es im Abschnitt (13/31) zu einer Meldung “PHP Fatal error: .. __toString() must not throw an exception ..“ ====
Die Ursache ist nicht bekannt. Hier hilft aktuell nur ein Workaround, in dem die Exception im Script auskommentiert wird.

Hierzu in der Datei ''../htdocs/vendor/symfony/symfony/src/Symfony/Component/DependencyInjection/Compiler/AutowirePass.php'' die Zeile 236 ''throw new AutoWiringFailedException'' auskommentieren. Die Datei ist allerdings erst nach dem Ausführens von docker:init vorhanden.

Siehe auch Ticket: [[https://opencaching.atlassian.net/browse/OCC-90|OCC-90: Exception error during docker:init]]

==== Docker Services neu initialisieren, z.B. bei “''W: GPG error: stable InRelease: The following signatures were invalid: EXPKEYSIG 23E7166788B63E1E Yarn Packaging <yarn@dan.cx>''“ ====
Treten während eines docker:init neue, merkwürdige und nicht näher spezifizierbare Fehler auf, kann es helfen, die Dockercontainer neu zu initialisieren mittels:
docker-compose build --pull

==== z.B. bei Update auf Symfony 5.2 kommt während docker:start-clean der Fehler ''”mv: cannot stat '/root/.symfony/bin/symfony': No such file or directory Service 'webserver' failed to build: The command '/bin/sh -c mv /root/.symfony/bin/symfony /usr/local/bin/symfony' returned a non-zero code: 1"'' ====
In diesem Fall in der Datei ''docker/httpd/Dockerfile'' die fehlerverursachende Zeile
RUN mv /root/.symfony/bin/symfony /usr/local/bin/symfony
auskommentieren und docker:start-clean erneut laufen lassen.

==== Während docker:start-clean: ''"\Doctrine\Common\Persistence\Mapping\Driver\MappingDriverChain()" not found'' ====
Dies ist ein Fehler in einem der ''doctrine/*'' Pakete (vermutlich ''doctrine/persistence'') in bestimmten Paketversionen. Hier hilft, die Datei ''/htdocs/vendor/doctrine/doctrine-bundle/Resources/config/orm.xml'' Zeile 32 zu editieren:
<parameter key="doctrine.orm.metadata.driver_chain.class">Doctrine\Common\Persistence\Mapping\Driver\MappingDriverChain</parameter>
zu
<parameter key="doctrine.orm.metadata.driver_chain.class">Doctrine\Persistence\Mapping\Driver\MappingDriverChain</parameter>

Allerdings muss dies zum richtigen Zeitpunkt passieren. Nachdem ''docker:start-clean'' aufgerufen wurde, kurz warten, bis die Pakete heruntergeladen wurden und noch bevor Abschnitt 13/32 anfängt, muss die Datei korrigiert und gespeichert worden sein.

==== Meldung “DEPRECATED: The legacy builder is deprecated and will be removed in a future release. Install the buildx component to build images with [[https://docs.docker.com/go/buildx/|BuildKit]] ====
Der Docker build Prozess wurde geändert. Die bisherige Methode wurde ab Dockerversion 23 als “deprecated” markiert und wird in einer zukünftigen Version entfernt. Siehe [[https://docs.docker.com/engine/deprecated/#legacy-builder-for-linux-images|Deprecated Engine Features]]

==== Meldung “ERROR: BuildKit is enabled but the buildx component is missing or broken.“ ====
Docker Buildkit/buildx soll verwendet werden (DOCKER_BUILDKIT=1), wurde aber nicht installiert.

Abhilfe: Buildkit/buildx Komponente installieren. Vorher müssen aber einige bereits installierte Pakete entfernt werden. Je nach OS gibt es unterschiedliche Anweisungen und Installationswege, siehe hier: [[https://docs.docker.com/engine/install/|Install Docker Engine]]

==== Während docker:start-clean: ''"Browserslist: caniuse-lite is outdated."'' ====
Scheinbar wird die “browserslist” nicht automatisch aktualisiert. (Grund? k.A.)

Zum manuellen Update im Docker:ssh eingeben:
npx browserslist@latest --update-db
bzw.
npx update-browserslist-db@latest

== Fehlermeldungen beim Zugriff auf die Datenbank ==
==== Fehlermeldung “ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)” ====
Es wurde vergessen, den Namen der Datenbank in der Kommandozeile zu übergeben.
mysql -uroot -proot -hmariadb opencaching

== Fehlermeldungen beim Zugriff auf die Testserverdomain ==
==== Vorgehen zum Anlegen eines weiteren Benutzers (betrifft Legacy-Testsystem) ====
Zuerst via http://docker.team-opencaching.de/register.php einen neuen Nutzer registrieren. Zwar kommt dann die Meldung, dass der Aktivierungscode per Mail zugsandt wurde, dies passiert aber nie. Der Aktivierungscode muss aus der Test-Datenbank ausgelesen werden.
Der Code steht in Tabelle ''user'' im Feld ''activation_code''.

Mit http://docker.team-opencaching.de/activation.php gelangt man zur Account-Aktivierungsseite. Hier die E-Mail-Adresse und den aus der Datenbank kopierten Aktivierungscode eingeben. Der Account ist nun aktiviert, aber falls der Login nicht funktioniert: siehe andere Fehlermeldung hier auf der Seite weiter unten.

Info: Eventuell wird in Zukunft der MailHog zum Laufen gebracht. Dann werden die vom Server verschickten Emails von diesem abgefangen und man kann die Informationen darin lesen.

==== Der neu angelegte Benutzer kann sich nicht einloggen und wird immer wieder ohne Meldung auf die Login-Seite geleitet (betrifft Legacy-Testsystem) ====
Die exakte Ursache ist nicht bekannt. Abhilfe kann geschaffen werden, wenn beim entsprechenden Nutzer in der Datenbank in der Tabelle ''user'' das Feld ''permanent_login_flag'' auf ''1'' gesetzt wird.

==== Beim Anlegen des ''zweiten'' Cachelistings kommt eine Fehlermeldung (betrifft Legacy-Testsystem) ====
Bei einer ''leeren'' Datenbank funktioniert das Setzen und Hochzählen der OC-Codes nicht. Es muss einmal ein OC-Code von Hand gesetzt werden.

Hierzu auf dem Testserver ein Listing anlegen. Dann für diesen Cache in der Datenbank in der Tabelle ''caches'' das Feld ''wp_oc'' auf einen initialen Wert ändern, z.B. ''OC1234''.

==== Beim Erstellen/Speichern eines Cachelistings kommen mehrere Fehlermeldungen, u.a. “Warning: A non-numeric value encountered in /app/htdocs/newcache.php on line 1025” (betrifft Legacy-Testsystem) ====
[[Image:Fehlerhandbuch Domain 01.png|500px]]

Zuerst muss geschaut werden, ob eventuell der vorige Abschnitt (“Beim Anlegen des zweiten Cachelistings kommt eine Fehlermeldung“) zutrifft. Wurden die dort beschriebenen Maßnahmen bereits umgesetzt, kommt es zwar trotzdem zur Fehlermeldung, das Listing wurde aber erfolgreich angelegt bzw. gespeichert. (Seite neu laden)

==== Es kann kein Logbild hochgeladen werden (betrifft Legacy-Testsystem) ====
Sobald man ein Logbild hochladen möchte, erscheint eine Fehlermeldung
<nowiki>Warning: move_uploaded_file(): Unable to move '/tmp/phpGmSzpi' to '/application/htdocs/config2/../images/uploads/700770A6-C101-11EA-BA77-0242AC120005.jpg' in /application/htdocs/lib2/logic/picture.class.php on line 856</nowiki>
Abhilfe: (noch) keine Ahnung. Die Bilder wurden aber trotzdem hochgeladen.

==== Bei Anlegen/Editieren eines Listings funktioniert die Attributeauswahl nicht (betrifft Legacy-Testsystem) ====
Editiert man ein Listing, stehen nicht alle Attribute zur Verfügung bzw. es können nicht alle Attribute ausgewählt werden.

Abhilfe: (noch) keine Ahnung.

==== Das Länderauswahlfeld rechts oben auf der Seite ist leer und funktioniert nicht. (betrifft Legacy-Testsystem) ====
Alle php-Dateien im Cacheverzeichnis htdocs/var/cache2 müssen gelöscht werden.

Das Vorgehen Unter Linux:
<nowiki>./psh.phar docker:stop
rm htdocs/var/cache2/*.inc.php
./psh.phar docker:start</nowiki>

==== Es kann nicht auf die Domains docker.team-opencaching.de oder try.docker.team-opencaching.de zugegriffen werden. ====
Normalerweise sollte der Zugriff nach Installation der Testumgebung automatisch funktionieren. Sollte das nicht der Fall sein, kann mittels Anpassung der hosts-Datei ein Workaround geschaffen werden:
<nowiki>127.0.0.1 docker.team-opencaching.de
127.0.0.1 try.docker.team-opencaching.de</nowiki>

==== Abschalten von “NOTICE”-Meldungen. (betrifft Legacy-Testsystem) ====
Aufgrund diverser (Smarty- und PHP-)Updates werden vormals ignorierte Probleme nun mit einer “NOTICE”-Meldung kenntlich gemacht. Um die Meldungen zu unterdrücken, kann in das error_reporting Level geändert werden.

Beispiele für Fehlermeldungen:
<nowiki>Notice: Undefined index: error_password_not_ok in /app/htdocs/var/cache2/smarty/compiled/..
Notice: Trying to get property 'value' of non-object in /app/..</nowiki>

Abhilfe:
Bis Smarty 3.x: In der Datei /htdocs/vendor/smarty/smarty/libs/Smarty.class.php die Zeile mit $error_reporting ändern auf den nachfolgenden Code. Die Änderung ist nicht git-relevant und geht nach jedem “./psh.phar docker:start-clean” verloren.
<nowiki>public $error_reporting = E_ALL & ~E_NOTICE;</nowiki>

Ab Smarty 3.x und 4.x: In der Datei /htdocs/lib2/common.inc.php die obere Zeile (PHP_DEBUG_ON) mit $error_reporting ändern auf den nachfolgenden Code. Die Änderung ist permanent und muss vor einem Commit rückgängig gemacht werden, da sie sonst im github Repository landet.
<nowiki>ini_set('error_reporting', E_ALL & ~E_NOTICE);</nowiki>

==== [gelöst] Die Übersetzungen funktionieren nicht. Meist wird nur Englischer Text angezeigt. (betrifft Legacy-Testsystem) ====
Die vorhandenen Fremdsprachen werden auf dem Testsystem nicht korrekt dargestellt. Meistens wird nur der Englische Text oder ein Mischmasch aus Englisch und eingestellter Sprache angezeigt.

Abhilfe: im docker:start Skript wurde eine fehlende Komponente ergänzt, welche nun automatisch mitinstalliert wird. Dadurch werden die Sprachdateien korrekt erzeugt und die Übersetzungen funktionieren.

Siehe auch: [[https://opencaching.atlassian.net/browse/RED-1278|RED-1278: Die Übersetzungen funktionieren auf dem Testserver nicht]]
Dieser Fehler sollte somit nicht mehr auftauchen.

==== [gelöst] Beim Löschen von Logs kommt eine Fehlermeldung “This log entry has been created on another Opencaching website. The cache can only be edited there.” ====
Auf dem Testserver werden die Logs laut Datenbank (Tabelle ''cache_logs'', Spalte ''nodes'') als ''node=5'' gespeichert, obwohl es laut Tabelle ''nodes'' diese Ziffer gar nicht gibt.

Um Logs wieder über die normale Loglöschenfunktion löschen zu können, gibt es mehrere Möglichkeiten:
# In der Datenbanktabelle ‘cache_logs’ den Eintrag in Spalte ‘nodes’ auf 4 ändern. (Dies entspricht der ‘Local Development’-Umgebung (siehe Tabelle ‘nodes’)).
# In der Datei ‘/dev-ops/local.team-opencaching.de/templates/config2-settings.inc.tpl.php' den Eintrag ‘$opt['logic']['node']['id'] = 5;’ ändern auf '$opt['logic']['node']['id'] = 4;’ und das docker:init Script ausführen
# Der Pull [[https://github.com/OpencachingDeutschland/oc-server3/pull/830|Pull Request #830 changed node information from 5 to 4]] behebt das Problem.

[[Kategorie:Entwicklung|Fehlerhandbuch ]]

Entwicklungsumgebung/Fehlerhandbuch

2025-09-01T18:24:54Z

Fraggle:

___TOC___
___FORCETOC___

= Test =
= Test =
= Test =
= Test =

== Test ==
== Test ==
== Test ==
== Test ==

Während der Installation der Programme oder Einrichtung der Testumgebung kann es zu diversen Fehlern und Meldungen kommen. Im Folgenden sind bereits bekannte Meldungen aufgelistet, die bei einer schnellen Behebung helfen sollen.

== Fehlermeldungen während der Paketinstallation ==
==== Während der Installation der benötigten Pakete, kommt es zu einer Meldung, dass Abhängigkeiten mit dem ‘libdvd-pkg’ Paket nicht aufgelöst werden können ====

Eine Rekonfiguration des Pakets schafft Abhilfe:
<nowiki>sudo dpkg-reconfigure libdvd-pkg</nowiki>

== Fehlermeldungen in Zusammenhang mit der Dockerumgebung ==
==== Fehler “starting opencaching-webserver .. error” oder “Starting webserver ... error” ====
Vermutlich läuft im Hintergrund bereits ein anderer Webservice auf Port 80.

Prüfen kann man das mit:
netstat -tanp | grep :80

Zum Beispiel ein apache2-Webserver kann gestoppt werden mit:
sudo systemctl stop apache2

Damit der apache2 nach einem Rechnerneustart nicht erneut aktiviert wird, kann man ihn generell deaktivieren:
sudo systemctl disable apache2

Alternativ lässt sich auch eine [[https://docs.docker.com/compose/extends/|Override-Datei]] für die betroffenen Ports verwenden, was allerdings weitere Komplikationen mit sich führen kann (wie beispielsweise eine nicht funktionierende OKAPI). Aus diesem Grund sollte nach Möglichkeit das Stoppen der Standard-Services für Apache und einen Datenbank-Server vorgezogen werden.

==== Fehler “W: GPG error: https://dl.yarnpkg.com/debian stable InRelease: The following signatures were invalid: EXPKEYSIG“ ====
Nach dem Ausführen von ./psh.phar docker:start kommt der Fehler. Hier ist das Zertifikat veraltet. Folgender Befehl löscht das Docker-Image.
docker-compose build --pull

Mit einen erneuten ./psh.phar docker:start läuft es wieder durch.

==== Fehler “ERROR: for opencaching-mariadb Cannot start service mariadb: driver failed programming external connectivity on endpoint opencaching-mariadb [..] Error starting userland proxy: listen tcp 0.0.0.0:3306: bind: address already in use” ====
Wenn beim docker:start diese Fehlermeldung kommt, läuft im Hintergrund bereits ein anderer Webservice (z.B. mysql) auf Port 3306.

Prüfen kann man das mit:
netstat -tanp | grep :3306

Zum Beispiel ein mysql-Webserver kann gestoppt werden mit:
sudo mysqladmin -u root shutdown

==== Fehler "The stream or file "/application/htdocs/var/logs/dev/dev.log" could not be opened: failed to open stream: Permission denied" oder ähnlich (betrifft Legacy-Testsystem) ====
==== Oder: Fehler "Permission denied" beim Zugriff auf /htdocs/var/cache (betrifft Legacy-Testsystem) ====
==== Oder: Fehler 500 (ohne weitere Angaben, warum) (betrifft Legacy-Testsystem) ====
Hier scheint der Webserver keine Zugriffsberechtigung auf bestimmte Pfade/Dateien zu haben. Von einem Ändern der Zugriffsberechtigungen, z. B. mittels sudo chmod -R 777 ./var/log, sollte aus Sicherheitsgründen aber Abstand genommen werden.

Helfen kann, die Befehlsfolge
./psh.phar docker:ssh
./psh.phar docker:init
exit
ein weiteres Mal auszuführen.

Falls dies weiterhin keinen Erfolg bringt, können folgende Schritte zum Ändern der Zugriffsberechtigungen angewandt werden:
# Ermitteln der ID des Containers oc-server3_php-fpm mittels sudo docker ps.
# Öffnen einer Shell im Container: sudo docker exec -it 45b6e4994fac /bin/bash, wobei 45b6e4994fac die ID des Containers ist.
# In der Container-Shell chmod -R 777 /application/htdocs/var/logs/dev/ ausführen.
# Die Container-Shell regulär mittels exit verlassen.

==== Host-Mismatch bei Aufruf der OKAPI mit Port-Override ====
Falls in einer Override-Datei Ports überschrieben werden (siehe oben), funktioniert die OKAPI möglicherweise nicht richtig - stattdessen erscheint ein Hinweis auf einen Port-Mismatch. Dies kann auf folgende Art und Weise behoben werden:
# Ermitteln der ID des Containers ''oc-server3_php-fpm'' mittels ''sudo docker ps''.
# Öffnen einer Shell im Container: ''sudo docker exec -it 45b6e4994fac /bin/bash'', wobei 45b6e4994fac die ID des Containers ist.
# Im Container einen Editor installieren, beispielsweise nano. Da der Container auf Ubuntu basiert, funktioniert dies mittels ''apt-get update && apt-get install nano''.
# Die passende Konfigurationsdatei mittels des Editors im Container öffnen, beispielsweise mittels ''nano /application/htdocs/config2/settings.inc.php.''
# Setzen von ''$dev_baseurl = 'http://docker.team-opencaching.de:2200';'' und anschließendes Speichern der Datei. Hierbei ist 2200 der Port, der statt Port 80 für den Webserver in der Override-Datei konfiguriert worden ist.

==== Während docker:init kommt es im Abschnitt (3/31) zu einer Meldung “> mysql -uroot -proot -hmariadb -e "DROP DATABASE IF EXISTS opencaching" ERROR 2005 (HY000): Unknown MySQL server host 'mariadb' (-3).“ ====
Abhilfe: ''./psh.phar docker:init'' darf nicht außerhalb des Dockercontainers aufgerufen werden.

==== Während docker:init kommt es im Abschnitt (13/31) zu einer Meldung “PHP Fatal error: .. __toString() must not throw an exception ..“ ====
Die Ursache ist nicht bekannt. Hier hilft aktuell nur ein Workaround, in dem die Exception im Script auskommentiert wird.

Hierzu in der Datei ''../htdocs/vendor/symfony/symfony/src/Symfony/Component/DependencyInjection/Compiler/AutowirePass.php'' die Zeile 236 ''throw new AutoWiringFailedException'' auskommentieren. Die Datei ist allerdings erst nach dem Ausführens von docker:init vorhanden.

Siehe auch Ticket: [[https://opencaching.atlassian.net/browse/OCC-90|OCC-90: Exception error during docker:init]]

==== Docker Services neu initialisieren, z.B. bei “''W: GPG error: stable InRelease: The following signatures were invalid: EXPKEYSIG 23E7166788B63E1E Yarn Packaging <yarn@dan.cx>''“ ====
Treten während eines docker:init neue, merkwürdige und nicht näher spezifizierbare Fehler auf, kann es helfen, die Dockercontainer neu zu initialisieren mittels:
docker-compose build --pull

==== z.B. bei Update auf Symfony 5.2 kommt während docker:start-clean der Fehler ''”mv: cannot stat '/root/.symfony/bin/symfony': No such file or directory Service 'webserver' failed to build: The command '/bin/sh -c mv /root/.symfony/bin/symfony /usr/local/bin/symfony' returned a non-zero code: 1"'' ====
In diesem Fall in der Datei ''docker/httpd/Dockerfile'' die fehlerverursachende Zeile
RUN mv /root/.symfony/bin/symfony /usr/local/bin/symfony
auskommentieren und docker:start-clean erneut laufen lassen.

==== Während docker:start-clean: ''"\Doctrine\Common\Persistence\Mapping\Driver\MappingDriverChain()" not found'' ====
Dies ist ein Fehler in einem der ''doctrine/*'' Pakete (vermutlich ''doctrine/persistence'') in bestimmten Paketversionen. Hier hilft, die Datei ''/htdocs/vendor/doctrine/doctrine-bundle/Resources/config/orm.xml'' Zeile 32 zu editieren:
<parameter key="doctrine.orm.metadata.driver_chain.class">Doctrine\Common\Persistence\Mapping\Driver\MappingDriverChain</parameter>
zu
<parameter key="doctrine.orm.metadata.driver_chain.class">Doctrine\Persistence\Mapping\Driver\MappingDriverChain</parameter>

Allerdings muss dies zum richtigen Zeitpunkt passieren. Nachdem ''docker:start-clean'' aufgerufen wurde, kurz warten, bis die Pakete heruntergeladen wurden und noch bevor Abschnitt 13/32 anfängt, muss die Datei korrigiert und gespeichert worden sein.

==== Meldung “DEPRECATED: The legacy builder is deprecated and will be removed in a future release. Install the buildx component to build images with [[https://docs.docker.com/go/buildx/|BuildKit]] ====
Der Docker build Prozess wurde geändert. Die bisherige Methode wurde ab Dockerversion 23 als “deprecated” markiert und wird in einer zukünftigen Version entfernt. Siehe [[https://docs.docker.com/engine/deprecated/#legacy-builder-for-linux-images|Deprecated Engine Features]]

==== Meldung “ERROR: BuildKit is enabled but the buildx component is missing or broken.“ ====
Docker Buildkit/buildx soll verwendet werden (DOCKER_BUILDKIT=1), wurde aber nicht installiert.

Abhilfe: Buildkit/buildx Komponente installieren. Vorher müssen aber einige bereits installierte Pakete entfernt werden. Je nach OS gibt es unterschiedliche Anweisungen und Installationswege, siehe hier: [[https://docs.docker.com/engine/install/|Install Docker Engine]]

==== Während docker:start-clean: ''"Browserslist: caniuse-lite is outdated."'' ====
Scheinbar wird die “browserslist” nicht automatisch aktualisiert. (Grund? k.A.)

Zum manuellen Update im Docker:ssh eingeben:
npx browserslist@latest --update-db
bzw.
npx update-browserslist-db@latest

== Fehlermeldungen beim Zugriff auf die Datenbank ==
==== Fehlermeldung “ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)” ====
Es wurde vergessen, den Namen der Datenbank in der Kommandozeile zu übergeben.
mysql -uroot -proot -hmariadb opencaching

== Fehlermeldungen beim Zugriff auf die Testserverdomain ==
==== Vorgehen zum Anlegen eines weiteren Benutzers (betrifft Legacy-Testsystem) ====
Zuerst via http://docker.team-opencaching.de/register.php einen neuen Nutzer registrieren. Zwar kommt dann die Meldung, dass der Aktivierungscode per Mail zugsandt wurde, dies passiert aber nie. Der Aktivierungscode muss aus der Test-Datenbank ausgelesen werden.
Der Code steht in Tabelle ''user'' im Feld ''activation_code''.

Mit http://docker.team-opencaching.de/activation.php gelangt man zur Account-Aktivierungsseite. Hier die E-Mail-Adresse und den aus der Datenbank kopierten Aktivierungscode eingeben. Der Account ist nun aktiviert, aber falls der Login nicht funktioniert: siehe andere Fehlermeldung hier auf der Seite weiter unten.

Info: Eventuell wird in Zukunft der MailHog zum Laufen gebracht. Dann werden die vom Server verschickten Emails von diesem abgefangen und man kann die Informationen darin lesen.

==== Der neu angelegte Benutzer kann sich nicht einloggen und wird immer wieder ohne Meldung auf die Login-Seite geleitet (betrifft Legacy-Testsystem) ====
Die exakte Ursache ist nicht bekannt. Abhilfe kann geschaffen werden, wenn beim entsprechenden Nutzer in der Datenbank in der Tabelle ''user'' das Feld ''permanent_login_flag'' auf ''1'' gesetzt wird.

==== Beim Anlegen des ''zweiten'' Cachelistings kommt eine Fehlermeldung (betrifft Legacy-Testsystem) ====
Bei einer ''leeren'' Datenbank funktioniert das Setzen und Hochzählen der OC-Codes nicht. Es muss einmal ein OC-Code von Hand gesetzt werden.

Hierzu auf dem Testserver ein Listing anlegen. Dann für diesen Cache in der Datenbank in der Tabelle ''caches'' das Feld ''wp_oc'' auf einen initialen Wert ändern, z.B. ''OC1234''.

==== Beim Erstellen/Speichern eines Cachelistings kommen mehrere Fehlermeldungen, u.a. “Warning: A non-numeric value encountered in /app/htdocs/newcache.php on line 1025” (betrifft Legacy-Testsystem) ====
[[Image:Fehlerhandbuch Domain 01.png|500px]]

Zuerst muss geschaut werden, ob eventuell der vorige Abschnitt (“Beim Anlegen des zweiten Cachelistings kommt eine Fehlermeldung“) zutrifft. Wurden die dort beschriebenen Maßnahmen bereits umgesetzt, kommt es zwar trotzdem zur Fehlermeldung, das Listing wurde aber erfolgreich angelegt bzw. gespeichert. (Seite neu laden)

==== Es kann kein Logbild hochgeladen werden (betrifft Legacy-Testsystem) ====
Sobald man ein Logbild hochladen möchte, erscheint eine Fehlermeldung
<nowiki>Warning: move_uploaded_file(): Unable to move '/tmp/phpGmSzpi' to '/application/htdocs/config2/../images/uploads/700770A6-C101-11EA-BA77-0242AC120005.jpg' in /application/htdocs/lib2/logic/picture.class.php on line 856</nowiki>
Abhilfe: (noch) keine Ahnung. Die Bilder wurden aber trotzdem hochgeladen.

==== Bei Anlegen/Editieren eines Listings funktioniert die Attributeauswahl nicht (betrifft Legacy-Testsystem) ====
Editiert man ein Listing, stehen nicht alle Attribute zur Verfügung bzw. es können nicht alle Attribute ausgewählt werden.

Abhilfe: (noch) keine Ahnung.

==== Das Länderauswahlfeld rechts oben auf der Seite ist leer und funktioniert nicht. (betrifft Legacy-Testsystem) ====
Alle php-Dateien im Cacheverzeichnis htdocs/var/cache2 müssen gelöscht werden.

Das Vorgehen Unter Linux:
<nowiki>./psh.phar docker:stop
rm htdocs/var/cache2/*.inc.php
./psh.phar docker:start</nowiki>

==== Es kann nicht auf die Domains docker.team-opencaching.de oder try.docker.team-opencaching.de zugegriffen werden. ====
Normalerweise sollte der Zugriff nach Installation der Testumgebung automatisch funktionieren. Sollte das nicht der Fall sein, kann mittels Anpassung der hosts-Datei ein Workaround geschaffen werden:
<nowiki>127.0.0.1 docker.team-opencaching.de
127.0.0.1 try.docker.team-opencaching.de</nowiki>

==== Abschalten von “NOTICE”-Meldungen. (betrifft Legacy-Testsystem) ====
Aufgrund diverser (Smarty- und PHP-)Updates werden vormals ignorierte Probleme nun mit einer “NOTICE”-Meldung kenntlich gemacht. Um die Meldungen zu unterdrücken, kann in das error_reporting Level geändert werden.

Beispiele für Fehlermeldungen:
<nowiki>Notice: Undefined index: error_password_not_ok in /app/htdocs/var/cache2/smarty/compiled/..
Notice: Trying to get property 'value' of non-object in /app/..</nowiki>

Abhilfe:
Bis Smarty 3.x: In der Datei /htdocs/vendor/smarty/smarty/libs/Smarty.class.php die Zeile mit $error_reporting ändern auf den nachfolgenden Code. Die Änderung ist nicht git-relevant und geht nach jedem “./psh.phar docker:start-clean” verloren.
<nowiki>public $error_reporting = E_ALL & ~E_NOTICE;</nowiki>

Ab Smarty 3.x und 4.x: In der Datei /htdocs/lib2/common.inc.php die obere Zeile (PHP_DEBUG_ON) mit $error_reporting ändern auf den nachfolgenden Code. Die Änderung ist permanent und muss vor einem Commit rückgängig gemacht werden, da sie sonst im github Repository landet.
<nowiki>ini_set('error_reporting', E_ALL & ~E_NOTICE);</nowiki>

==== [gelöst] Die Übersetzungen funktionieren nicht. Meist wird nur Englischer Text angezeigt. (betrifft Legacy-Testsystem) ====
Die vorhandenen Fremdsprachen werden auf dem Testsystem nicht korrekt dargestellt. Meistens wird nur der Englische Text oder ein Mischmasch aus Englisch und eingestellter Sprache angezeigt.

Abhilfe: im docker:start Skript wurde eine fehlende Komponente ergänzt, welche nun automatisch mitinstalliert wird. Dadurch werden die Sprachdateien korrekt erzeugt und die Übersetzungen funktionieren.

Siehe auch: [[https://opencaching.atlassian.net/browse/RED-1278|RED-1278: Die Übersetzungen funktionieren auf dem Testserver nicht]]
Dieser Fehler sollte somit nicht mehr auftauchen.

==== [gelöst] Beim Löschen von Logs kommt eine Fehlermeldung “This log entry has been created on another Opencaching website. The cache can only be edited there.” ====
Auf dem Testserver werden die Logs laut Datenbank (Tabelle ''cache_logs'', Spalte ''nodes'') als ''node=5'' gespeichert, obwohl es laut Tabelle ''nodes'' diese Ziffer gar nicht gibt.

Um Logs wieder über die normale Loglöschenfunktion löschen zu können, gibt es mehrere Möglichkeiten:
# In der Datenbanktabelle ‘cache_logs’ den Eintrag in Spalte ‘nodes’ auf 4 ändern. (Dies entspricht der ‘Local Development’-Umgebung (siehe Tabelle ‘nodes’)).
# In der Datei ‘/dev-ops/local.team-opencaching.de/templates/config2-settings.inc.tpl.php' den Eintrag ‘$opt['logic']['node']['id'] = 5;’ ändern auf '$opt['logic']['node']['id'] = 4;’ und das docker:init Script ausführen
# Der Pull [[https://github.com/OpencachingDeutschland/oc-server3/pull/830|Pull Request #830 changed node information from 5 to 4]] behebt das Problem.

[[Kategorie:Entwicklung|Fehlerhandbuch ]]

Entwicklungsumgebung/Fehlerhandbuch

2025-09-01T18:20:47Z

Fraggle: +Leerzeile

Während der Installation der Programme oder Einrichtung der Testumgebung kann es zu diversen Fehlern und Meldungen kommen. Im Folgenden sind bereits bekannte Meldungen aufgelistet, die bei einer schnellen Behebung helfen sollen.

== Fehlermeldungen während der Paketinstallation ==
==== Während der Installation der benötigten Pakete, kommt es zu einer Meldung, dass Abhängigkeiten mit dem ‘libdvd-pkg’ Paket nicht aufgelöst werden können ====

Eine Rekonfiguration des Pakets schafft Abhilfe:
<nowiki>sudo dpkg-reconfigure libdvd-pkg</nowiki>

== Fehlermeldungen in Zusammenhang mit der Dockerumgebung ==
==== Fehler “starting opencaching-webserver .. error” oder “Starting webserver ... error” ====
Vermutlich läuft im Hintergrund bereits ein anderer Webservice auf Port 80.

Prüfen kann man das mit:
netstat -tanp | grep :80

Zum Beispiel ein apache2-Webserver kann gestoppt werden mit:
sudo systemctl stop apache2

Damit der apache2 nach einem Rechnerneustart nicht erneut aktiviert wird, kann man ihn generell deaktivieren:
sudo systemctl disable apache2

Alternativ lässt sich auch eine [[https://docs.docker.com/compose/extends/|Override-Datei]] für die betroffenen Ports verwenden, was allerdings weitere Komplikationen mit sich führen kann (wie beispielsweise eine nicht funktionierende OKAPI). Aus diesem Grund sollte nach Möglichkeit das Stoppen der Standard-Services für Apache und einen Datenbank-Server vorgezogen werden.

==== Fehler “W: GPG error: https://dl.yarnpkg.com/debian stable InRelease: The following signatures were invalid: EXPKEYSIG“ ====
Nach dem Ausführen von ./psh.phar docker:start kommt der Fehler. Hier ist das Zertifikat veraltet. Folgender Befehl löscht das Docker-Image.
docker-compose build --pull

Mit einen erneuten ./psh.phar docker:start läuft es wieder durch.

==== Fehler “ERROR: for opencaching-mariadb Cannot start service mariadb: driver failed programming external connectivity on endpoint opencaching-mariadb [..] Error starting userland proxy: listen tcp 0.0.0.0:3306: bind: address already in use” ====
Wenn beim docker:start diese Fehlermeldung kommt, läuft im Hintergrund bereits ein anderer Webservice (z.B. mysql) auf Port 3306.

Prüfen kann man das mit:
netstat -tanp | grep :3306

Zum Beispiel ein mysql-Webserver kann gestoppt werden mit:
sudo mysqladmin -u root shutdown

==== Fehler "The stream or file "/application/htdocs/var/logs/dev/dev.log" could not be opened: failed to open stream: Permission denied" oder ähnlich (betrifft Legacy-Testsystem) ====
==== Oder: Fehler "Permission denied" beim Zugriff auf /htdocs/var/cache (betrifft Legacy-Testsystem) ====
==== Oder: Fehler 500 (ohne weitere Angaben, warum) (betrifft Legacy-Testsystem) ====
Hier scheint der Webserver keine Zugriffsberechtigung auf bestimmte Pfade/Dateien zu haben. Von einem Ändern der Zugriffsberechtigungen, z. B. mittels sudo chmod -R 777 ./var/log, sollte aus Sicherheitsgründen aber Abstand genommen werden.

Helfen kann, die Befehlsfolge
./psh.phar docker:ssh
./psh.phar docker:init
exit
ein weiteres Mal auszuführen.

Falls dies weiterhin keinen Erfolg bringt, können folgende Schritte zum Ändern der Zugriffsberechtigungen angewandt werden:
# Ermitteln der ID des Containers oc-server3_php-fpm mittels sudo docker ps.
# Öffnen einer Shell im Container: sudo docker exec -it 45b6e4994fac /bin/bash, wobei 45b6e4994fac die ID des Containers ist.
# In der Container-Shell chmod -R 777 /application/htdocs/var/logs/dev/ ausführen.
# Die Container-Shell regulär mittels exit verlassen.

==== Host-Mismatch bei Aufruf der OKAPI mit Port-Override ====
Falls in einer Override-Datei Ports überschrieben werden (siehe oben), funktioniert die OKAPI möglicherweise nicht richtig - stattdessen erscheint ein Hinweis auf einen Port-Mismatch. Dies kann auf folgende Art und Weise behoben werden:
# Ermitteln der ID des Containers ''oc-server3_php-fpm'' mittels ''sudo docker ps''.
# Öffnen einer Shell im Container: ''sudo docker exec -it 45b6e4994fac /bin/bash'', wobei 45b6e4994fac die ID des Containers ist.
# Im Container einen Editor installieren, beispielsweise nano. Da der Container auf Ubuntu basiert, funktioniert dies mittels ''apt-get update && apt-get install nano''.
# Die passende Konfigurationsdatei mittels des Editors im Container öffnen, beispielsweise mittels ''nano /application/htdocs/config2/settings.inc.php.''
# Setzen von ''$dev_baseurl = 'http://docker.team-opencaching.de:2200';'' und anschließendes Speichern der Datei. Hierbei ist 2200 der Port, der statt Port 80 für den Webserver in der Override-Datei konfiguriert worden ist.

==== Während docker:init kommt es im Abschnitt (3/31) zu einer Meldung “> mysql -uroot -proot -hmariadb -e "DROP DATABASE IF EXISTS opencaching" ERROR 2005 (HY000): Unknown MySQL server host 'mariadb' (-3).“ ====
Abhilfe: ''./psh.phar docker:init'' darf nicht außerhalb des Dockercontainers aufgerufen werden.

==== Während docker:init kommt es im Abschnitt (13/31) zu einer Meldung “PHP Fatal error: .. __toString() must not throw an exception ..“ ====
Die Ursache ist nicht bekannt. Hier hilft aktuell nur ein Workaround, in dem die Exception im Script auskommentiert wird.

Hierzu in der Datei ''../htdocs/vendor/symfony/symfony/src/Symfony/Component/DependencyInjection/Compiler/AutowirePass.php'' die Zeile 236 ''throw new AutoWiringFailedException'' auskommentieren. Die Datei ist allerdings erst nach dem Ausführens von docker:init vorhanden.

Siehe auch Ticket: [[https://opencaching.atlassian.net/browse/OCC-90|OCC-90: Exception error during docker:init]]

==== Docker Services neu initialisieren, z.B. bei “''W: GPG error: stable InRelease: The following signatures were invalid: EXPKEYSIG 23E7166788B63E1E Yarn Packaging <yarn@dan.cx>''“ ====
Treten während eines docker:init neue, merkwürdige und nicht näher spezifizierbare Fehler auf, kann es helfen, die Dockercontainer neu zu initialisieren mittels:
docker-compose build --pull

==== z.B. bei Update auf Symfony 5.2 kommt während docker:start-clean der Fehler ''”mv: cannot stat '/root/.symfony/bin/symfony': No such file or directory Service 'webserver' failed to build: The command '/bin/sh -c mv /root/.symfony/bin/symfony /usr/local/bin/symfony' returned a non-zero code: 1"'' ====
In diesem Fall in der Datei ''docker/httpd/Dockerfile'' die fehlerverursachende Zeile
RUN mv /root/.symfony/bin/symfony /usr/local/bin/symfony
auskommentieren und docker:start-clean erneut laufen lassen.

==== Während docker:start-clean: ''"\Doctrine\Common\Persistence\Mapping\Driver\MappingDriverChain()" not found'' ====
Dies ist ein Fehler in einem der ''doctrine/*'' Pakete (vermutlich ''doctrine/persistence'') in bestimmten Paketversionen. Hier hilft, die Datei ''/htdocs/vendor/doctrine/doctrine-bundle/Resources/config/orm.xml'' Zeile 32 zu editieren:
<parameter key="doctrine.orm.metadata.driver_chain.class">Doctrine\Common\Persistence\Mapping\Driver\MappingDriverChain</parameter>
zu
<parameter key="doctrine.orm.metadata.driver_chain.class">Doctrine\Persistence\Mapping\Driver\MappingDriverChain</parameter>

Allerdings muss dies zum richtigen Zeitpunkt passieren. Nachdem ''docker:start-clean'' aufgerufen wurde, kurz warten, bis die Pakete heruntergeladen wurden und noch bevor Abschnitt 13/32 anfängt, muss die Datei korrigiert und gespeichert worden sein.

==== Meldung “DEPRECATED: The legacy builder is deprecated and will be removed in a future release. Install the buildx component to build images with [[https://docs.docker.com/go/buildx/|BuildKit]] ====
Der Docker build Prozess wurde geändert. Die bisherige Methode wurde ab Dockerversion 23 als “deprecated” markiert und wird in einer zukünftigen Version entfernt. Siehe [[https://docs.docker.com/engine/deprecated/#legacy-builder-for-linux-images|Deprecated Engine Features]]

==== Meldung “ERROR: BuildKit is enabled but the buildx component is missing or broken.“ ====
Docker Buildkit/buildx soll verwendet werden (DOCKER_BUILDKIT=1), wurde aber nicht installiert.

Abhilfe: Buildkit/buildx Komponente installieren. Vorher müssen aber einige bereits installierte Pakete entfernt werden. Je nach OS gibt es unterschiedliche Anweisungen und Installationswege, siehe hier: [[https://docs.docker.com/engine/install/|Install Docker Engine]]

==== Während docker:start-clean: ''"Browserslist: caniuse-lite is outdated."'' ====
Scheinbar wird die “browserslist” nicht automatisch aktualisiert. (Grund? k.A.)

Zum manuellen Update im Docker:ssh eingeben:
npx browserslist@latest --update-db
bzw.
npx update-browserslist-db@latest

== Fehlermeldungen beim Zugriff auf die Datenbank ==
==== Fehlermeldung “ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)” ====
Es wurde vergessen, den Namen der Datenbank in der Kommandozeile zu übergeben.
mysql -uroot -proot -hmariadb opencaching

== Fehlermeldungen beim Zugriff auf die Testserverdomain ==
==== Vorgehen zum Anlegen eines weiteren Benutzers (betrifft Legacy-Testsystem) ====
Zuerst via http://docker.team-opencaching.de/register.php einen neuen Nutzer registrieren. Zwar kommt dann die Meldung, dass der Aktivierungscode per Mail zugsandt wurde, dies passiert aber nie. Der Aktivierungscode muss aus der Test-Datenbank ausgelesen werden.
Der Code steht in Tabelle ''user'' im Feld ''activation_code''.

Mit http://docker.team-opencaching.de/activation.php gelangt man zur Account-Aktivierungsseite. Hier die E-Mail-Adresse und den aus der Datenbank kopierten Aktivierungscode eingeben. Der Account ist nun aktiviert, aber falls der Login nicht funktioniert: siehe andere Fehlermeldung hier auf der Seite weiter unten.

Info: Eventuell wird in Zukunft der MailHog zum Laufen gebracht. Dann werden die vom Server verschickten Emails von diesem abgefangen und man kann die Informationen darin lesen.

==== Der neu angelegte Benutzer kann sich nicht einloggen und wird immer wieder ohne Meldung auf die Login-Seite geleitet (betrifft Legacy-Testsystem) ====
Die exakte Ursache ist nicht bekannt. Abhilfe kann geschaffen werden, wenn beim entsprechenden Nutzer in der Datenbank in der Tabelle ''user'' das Feld ''permanent_login_flag'' auf ''1'' gesetzt wird.

==== Beim Anlegen des ''zweiten'' Cachelistings kommt eine Fehlermeldung (betrifft Legacy-Testsystem) ====
Bei einer ''leeren'' Datenbank funktioniert das Setzen und Hochzählen der OC-Codes nicht. Es muss einmal ein OC-Code von Hand gesetzt werden.

Hierzu auf dem Testserver ein Listing anlegen. Dann für diesen Cache in der Datenbank in der Tabelle ''caches'' das Feld ''wp_oc'' auf einen initialen Wert ändern, z.B. ''OC1234''.

==== Beim Erstellen/Speichern eines Cachelistings kommen mehrere Fehlermeldungen, u.a. “Warning: A non-numeric value encountered in /app/htdocs/newcache.php on line 1025” (betrifft Legacy-Testsystem) ====
[[Image:Fehlerhandbuch Domain 01.png|500px]]

Zuerst muss geschaut werden, ob eventuell der vorige Abschnitt (“Beim Anlegen des zweiten Cachelistings kommt eine Fehlermeldung“) zutrifft. Wurden die dort beschriebenen Maßnahmen bereits umgesetzt, kommt es zwar trotzdem zur Fehlermeldung, das Listing wurde aber erfolgreich angelegt bzw. gespeichert. (Seite neu laden)

==== Es kann kein Logbild hochgeladen werden (betrifft Legacy-Testsystem) ====
Sobald man ein Logbild hochladen möchte, erscheint eine Fehlermeldung
<nowiki>Warning: move_uploaded_file(): Unable to move '/tmp/phpGmSzpi' to '/application/htdocs/config2/../images/uploads/700770A6-C101-11EA-BA77-0242AC120005.jpg' in /application/htdocs/lib2/logic/picture.class.php on line 856</nowiki>
Abhilfe: (noch) keine Ahnung. Die Bilder wurden aber trotzdem hochgeladen.

==== Bei Anlegen/Editieren eines Listings funktioniert die Attributeauswahl nicht (betrifft Legacy-Testsystem) ====
Editiert man ein Listing, stehen nicht alle Attribute zur Verfügung bzw. es können nicht alle Attribute ausgewählt werden.

Abhilfe: (noch) keine Ahnung.

==== Das Länderauswahlfeld rechts oben auf der Seite ist leer und funktioniert nicht. (betrifft Legacy-Testsystem) ====
Alle php-Dateien im Cacheverzeichnis htdocs/var/cache2 müssen gelöscht werden.

Das Vorgehen Unter Linux:
<nowiki>./psh.phar docker:stop
rm htdocs/var/cache2/*.inc.php
./psh.phar docker:start</nowiki>

==== Es kann nicht auf die Domains docker.team-opencaching.de oder try.docker.team-opencaching.de zugegriffen werden. ====
Normalerweise sollte der Zugriff nach Installation der Testumgebung automatisch funktionieren. Sollte das nicht der Fall sein, kann mittels Anpassung der hosts-Datei ein Workaround geschaffen werden:
<nowiki>127.0.0.1 docker.team-opencaching.de
127.0.0.1 try.docker.team-opencaching.de</nowiki>

==== Abschalten von “NOTICE”-Meldungen. (betrifft Legacy-Testsystem) ====
Aufgrund diverser (Smarty- und PHP-)Updates werden vormals ignorierte Probleme nun mit einer “NOTICE”-Meldung kenntlich gemacht. Um die Meldungen zu unterdrücken, kann in das error_reporting Level geändert werden.

Beispiele für Fehlermeldungen:
<nowiki>Notice: Undefined index: error_password_not_ok in /app/htdocs/var/cache2/smarty/compiled/..
Notice: Trying to get property 'value' of non-object in /app/..</nowiki>

Abhilfe:
Bis Smarty 3.x: In der Datei /htdocs/vendor/smarty/smarty/libs/Smarty.class.php die Zeile mit $error_reporting ändern auf den nachfolgenden Code. Die Änderung ist nicht git-relevant und geht nach jedem “./psh.phar docker:start-clean” verloren.
<nowiki>public $error_reporting = E_ALL & ~E_NOTICE;</nowiki>

Ab Smarty 3.x und 4.x: In der Datei /htdocs/lib2/common.inc.php die obere Zeile (PHP_DEBUG_ON) mit $error_reporting ändern auf den nachfolgenden Code. Die Änderung ist permanent und muss vor einem Commit rückgängig gemacht werden, da sie sonst im github Repository landet.
<nowiki>ini_set('error_reporting', E_ALL & ~E_NOTICE);</nowiki>

==== [gelöst] Die Übersetzungen funktionieren nicht. Meist wird nur Englischer Text angezeigt. (betrifft Legacy-Testsystem) ====
Die vorhandenen Fremdsprachen werden auf dem Testsystem nicht korrekt dargestellt. Meistens wird nur der Englische Text oder ein Mischmasch aus Englisch und eingestellter Sprache angezeigt.

Abhilfe: im docker:start Skript wurde eine fehlende Komponente ergänzt, welche nun automatisch mitinstalliert wird. Dadurch werden die Sprachdateien korrekt erzeugt und die Übersetzungen funktionieren.

Siehe auch: [[https://opencaching.atlassian.net/browse/RED-1278|RED-1278: Die Übersetzungen funktionieren auf dem Testserver nicht]]
Dieser Fehler sollte somit nicht mehr auftauchen.

==== [gelöst] Beim Löschen von Logs kommt eine Fehlermeldung “This log entry has been created on another Opencaching website. The cache can only be edited there.” ====
Auf dem Testserver werden die Logs laut Datenbank (Tabelle ''cache_logs'', Spalte ''nodes'') als ''node=5'' gespeichert, obwohl es laut Tabelle ''nodes'' diese Ziffer gar nicht gibt.

Um Logs wieder über die normale Loglöschenfunktion löschen zu können, gibt es mehrere Möglichkeiten:
# In der Datenbanktabelle ‘cache_logs’ den Eintrag in Spalte ‘nodes’ auf 4 ändern. (Dies entspricht der ‘Local Development’-Umgebung (siehe Tabelle ‘nodes’)).
# In der Datei ‘/dev-ops/local.team-opencaching.de/templates/config2-settings.inc.tpl.php' den Eintrag ‘$opt['logic']['node']['id'] = 5;’ ändern auf '$opt['logic']['node']['id'] = 4;’ und das docker:init Script ausführen
# Der Pull [[https://github.com/OpencachingDeutschland/oc-server3/pull/830|Pull Request #830 changed node information from 5 to 4]] behebt das Problem.

[[Kategorie:Entwicklung|Fehlerhandbuch ]]

Entwicklungsumgebung/Fehlerhandbuch

2025-09-01T18:20:02Z

Fraggle: Update Fehlerüberschrift

Während der Installation der Programme oder Einrichtung der Testumgebung kann es zu diversen Fehlern und Meldungen kommen. Im Folgenden sind bereits bekannte Meldungen aufgelistet, die bei einer schnellen Behebung helfen sollen.

== Fehlermeldungen während der Paketinstallation ==
==== Während der Installation der benötigten Pakete, kommt es zu einer Meldung, dass Abhängigkeiten mit dem ‘libdvd-pkg’ Paket nicht aufgelöst werden können ====

Eine Rekonfiguration des Pakets schafft Abhilfe:
<nowiki>sudo dpkg-reconfigure libdvd-pkg</nowiki>

== Fehlermeldungen in Zusammenhang mit der Dockerumgebung ==
==== Fehler “starting opencaching-webserver .. error” oder “Starting webserver ... error” ====
Vermutlich läuft im Hintergrund bereits ein anderer Webservice auf Port 80.

Prüfen kann man das mit:
netstat -tanp | grep :80

Zum Beispiel ein apache2-Webserver kann gestoppt werden mit:
sudo systemctl stop apache2

Damit der apache2 nach einem Rechnerneustart nicht erneut aktiviert wird, kann man ihn generell deaktivieren:
sudo systemctl disable apache2

Alternativ lässt sich auch eine [[https://docs.docker.com/compose/extends/|Override-Datei]] für die betroffenen Ports verwenden, was allerdings weitere Komplikationen mit sich führen kann (wie beispielsweise eine nicht funktionierende OKAPI). Aus diesem Grund sollte nach Möglichkeit das Stoppen der Standard-Services für Apache und einen Datenbank-Server vorgezogen werden.

==== Fehler “W: GPG error: https://dl.yarnpkg.com/debian stable InRelease: The following signatures were invalid: EXPKEYSIG“ ====
Nach dem Ausführen von ./psh.phar docker:start kommt der Fehler. Hier ist das Zertifikat veraltet. Folgender Befehl löscht das Docker-Image.
docker-compose build --pull

Mit einen erneuten ./psh.phar docker:start läuft es wieder durch.

==== Fehler “ERROR: for opencaching-mariadb Cannot start service mariadb: driver failed programming external connectivity on endpoint opencaching-mariadb [..] Error starting userland proxy: listen tcp 0.0.0.0:3306: bind: address already in use” ====
Wenn beim docker:start diese Fehlermeldung kommt, läuft im Hintergrund bereits ein anderer Webservice (z.B. mysql) auf Port 3306.

Prüfen kann man das mit:
netstat -tanp | grep :3306

Zum Beispiel ein mysql-Webserver kann gestoppt werden mit:
sudo mysqladmin -u root shutdown

==== Fehler "The stream or file "/application/htdocs/var/logs/dev/dev.log" could not be opened: failed to open stream: Permission denied" oder ähnlich (betrifft Legacy-Testsystem) ====
==== Oder: Fehler "Permission denied" beim Zugriff auf /htdocs/var/cache (betrifft Legacy-Testsystem) ====
==== Oder: Fehler 500 (ohne weitere Angaben, warum) (betrifft Legacy-Testsystem) ====
Hier scheint der Webserver keine Zugriffsberechtigung auf bestimmte Pfade/Dateien zu haben. Von einem Ändern der Zugriffsberechtigungen, z. B. mittels sudo chmod -R 777 ./var/log, sollte aus Sicherheitsgründen aber Abstand genommen werden.

Helfen kann, die Befehlsfolge
./psh.phar docker:ssh
./psh.phar docker:init
exit
ein weiteres Mal auszuführen.

Falls dies weiterhin keinen Erfolg bringt, können folgende Schritte zum Ändern der Zugriffsberechtigungen angewandt werden:
# Ermitteln der ID des Containers oc-server3_php-fpm mittels sudo docker ps.
# Öffnen einer Shell im Container: sudo docker exec -it 45b6e4994fac /bin/bash, wobei 45b6e4994fac die ID des Containers ist.
# In der Container-Shell chmod -R 777 /application/htdocs/var/logs/dev/ ausführen.
# Die Container-Shell regulär mittels exit verlassen.

==== Host-Mismatch bei Aufruf der OKAPI mit Port-Override ====
Falls in einer Override-Datei Ports überschrieben werden (siehe oben), funktioniert die OKAPI möglicherweise nicht richtig - stattdessen erscheint ein Hinweis auf einen Port-Mismatch. Dies kann auf folgende Art und Weise behoben werden:
# Ermitteln der ID des Containers ''oc-server3_php-fpm'' mittels ''sudo docker ps''.
# Öffnen einer Shell im Container: ''sudo docker exec -it 45b6e4994fac /bin/bash'', wobei 45b6e4994fac die ID des Containers ist.
# Im Container einen Editor installieren, beispielsweise nano. Da der Container auf Ubuntu basiert, funktioniert dies mittels ''apt-get update && apt-get install nano''.
# Die passende Konfigurationsdatei mittels des Editors im Container öffnen, beispielsweise mittels ''nano /application/htdocs/config2/settings.inc.php.''
# Setzen von ''$dev_baseurl = 'http://docker.team-opencaching.de:2200';'' und anschließendes Speichern der Datei. Hierbei ist 2200 der Port, der statt Port 80 für den Webserver in der Override-Datei konfiguriert worden ist.

==== Während docker:init kommt es im Abschnitt (3/31) zu einer Meldung “> mysql -uroot -proot -hmariadb -e "DROP DATABASE IF EXISTS opencaching" ERROR 2005 (HY000): Unknown MySQL server host 'mariadb' (-3).“ ====
Abhilfe: ''./psh.phar docker:init'' darf nicht außerhalb des Dockercontainers aufgerufen werden.

==== Während docker:init kommt es im Abschnitt (13/31) zu einer Meldung “PHP Fatal error: .. __toString() must not throw an exception ..“ ====
Die Ursache ist nicht bekannt. Hier hilft aktuell nur ein Workaround, in dem die Exception im Script auskommentiert wird.

Hierzu in der Datei ''../htdocs/vendor/symfony/symfony/src/Symfony/Component/DependencyInjection/Compiler/AutowirePass.php'' die Zeile 236 ''throw new AutoWiringFailedException'' auskommentieren. Die Datei ist allerdings erst nach dem Ausführens von docker:init vorhanden.

Siehe auch Ticket: [[https://opencaching.atlassian.net/browse/OCC-90|OCC-90: Exception error during docker:init]]

==== Docker Services neu initialisieren, z.B. bei “''W: GPG error: stable InRelease: The following signatures were invalid: EXPKEYSIG 23E7166788B63E1E Yarn Packaging <yarn@dan.cx>''“ ====
Treten während eines docker:init neue, merkwürdige und nicht näher spezifizierbare Fehler auf, kann es helfen, die Dockercontainer neu zu initialisieren mittels:
docker-compose build --pull

==== z.B. bei Update auf Symfony 5.2 kommt während docker:start-clean der Fehler ''”mv: cannot stat '/root/.symfony/bin/symfony': No such file or directory Service 'webserver' failed to build: The command '/bin/sh -c mv /root/.symfony/bin/symfony /usr/local/bin/symfony' returned a non-zero code: 1"'' ====
In diesem Fall in der Datei ''docker/httpd/Dockerfile'' die fehlerverursachende Zeile
RUN mv /root/.symfony/bin/symfony /usr/local/bin/symfony
auskommentieren und docker:start-clean erneut laufen lassen.

==== Während docker:start-clean: ''"\Doctrine\Common\Persistence\Mapping\Driver\MappingDriverChain()" not found'' ====
Dies ist ein Fehler in einem der ''doctrine/*'' Pakete (vermutlich ''doctrine/persistence'') in bestimmten Paketversionen. Hier hilft, die Datei ''/htdocs/vendor/doctrine/doctrine-bundle/Resources/config/orm.xml'' Zeile 32 zu editieren:
<parameter key="doctrine.orm.metadata.driver_chain.class">Doctrine\Common\Persistence\Mapping\Driver\MappingDriverChain</parameter>
zu
<parameter key="doctrine.orm.metadata.driver_chain.class">Doctrine\Persistence\Mapping\Driver\MappingDriverChain</parameter>

Allerdings muss dies zum richtigen Zeitpunkt passieren. Nachdem ''docker:start-clean'' aufgerufen wurde, kurz warten, bis die Pakete heruntergeladen wurden und noch bevor Abschnitt 13/32 anfängt, muss die Datei korrigiert und gespeichert worden sein.

==== Meldung “DEPRECATED: The legacy builder is deprecated and will be removed in a future release. Install the buildx component to build images with [[https://docs.docker.com/go/buildx/|BuildKit]] ====
Der Docker build Prozess wurde geändert. Die bisherige Methode wurde ab Dockerversion 23 als “deprecated” markiert und wird in einer zukünftigen Version entfernt. Siehe [[https://docs.docker.com/engine/deprecated/#legacy-builder-for-linux-images|Deprecated Engine Features]]

==== Meldung “ERROR: BuildKit is enabled but the buildx component is missing or broken.“ ====
Docker Buildkit/buildx soll verwendet werden (DOCKER_BUILDKIT=1), wurde aber nicht installiert.

Abhilfe: Buildkit/buildx Komponente installieren. Vorher müssen aber einige bereits installierte Pakete entfernt werden. Je nach OS gibt es unterschiedliche Anweisungen und Installationswege, siehe hier: [[https://docs.docker.com/engine/install/|Install Docker Engine]]

==== Während docker:start-clean: ''"Browserslist: caniuse-lite is outdated."'' ====
Scheinbar wird die “browserslist” nicht automatisch aktualisiert. (Grund? k.A.)

Zum manuellen Update im Docker:ssh eingeben:
npx browserslist@latest --update-db
bzw.
npx update-browserslist-db@latest

== Fehlermeldungen beim Zugriff auf die Datenbank ==
==== Fehlermeldung “ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)” ====
Es wurde vergessen, den Namen der Datenbank in der Kommandozeile zu übergeben.
mysql -uroot -proot -hmariadb opencaching

== Fehlermeldungen beim Zugriff auf die Testserverdomain ==
==== Vorgehen zum Anlegen eines weiteren Benutzers (betrifft Legacy-Testsystem) ====
Zuerst via http://docker.team-opencaching.de/register.php einen neuen Nutzer registrieren. Zwar kommt dann die Meldung, dass der Aktivierungscode per Mail zugsandt wurde, dies passiert aber nie. Der Aktivierungscode muss aus der Test-Datenbank ausgelesen werden.
Der Code steht in Tabelle ''user'' im Feld ''activation_code''.

Mit http://docker.team-opencaching.de/activation.php gelangt man zur Account-Aktivierungsseite. Hier die E-Mail-Adresse und den aus der Datenbank kopierten Aktivierungscode eingeben. Der Account ist nun aktiviert, aber falls der Login nicht funktioniert: siehe andere Fehlermeldung hier auf der Seite weiter unten.

Info: Eventuell wird in Zukunft der MailHog zum Laufen gebracht. Dann werden die vom Server verschickten Emails von diesem abgefangen und man kann die Informationen darin lesen.

==== Der neu angelegte Benutzer kann sich nicht einloggen und wird immer wieder ohne Meldung auf die Login-Seite geleitet (betrifft Legacy-Testsystem) ====
Die exakte Ursache ist nicht bekannt. Abhilfe kann geschaffen werden, wenn beim entsprechenden Nutzer in der Datenbank in der Tabelle ''user'' das Feld ''permanent_login_flag'' auf ''1'' gesetzt wird.

==== Beim Anlegen des ''zweiten'' Cachelistings kommt eine Fehlermeldung (betrifft Legacy-Testsystem) ====
Bei einer ''leeren'' Datenbank funktioniert das Setzen und Hochzählen der OC-Codes nicht. Es muss einmal ein OC-Code von Hand gesetzt werden.

Hierzu auf dem Testserver ein Listing anlegen. Dann für diesen Cache in der Datenbank in der Tabelle ''caches'' das Feld ''wp_oc'' auf einen initialen Wert ändern, z.B. ''OC1234''.

==== Beim Erstellen/Speichern eines Cachelistings kommen mehrere Fehlermeldungen, u.a. “Warning: A non-numeric value encountered in /app/htdocs/newcache.php on line 1025” (betrifft Legacy-Testsystem) ====
[[Image:Fehlerhandbuch Domain 01.png|500px]]

Zuerst muss geschaut werden, ob eventuell der vorige Abschnitt (“Beim Anlegen des zweiten Cachelistings kommt eine Fehlermeldung“) zutrifft. Wurden die dort beschriebenen Maßnahmen bereits umgesetzt, kommt es zwar trotzdem zur Fehlermeldung, das Listing wurde aber erfolgreich angelegt bzw. gespeichert. (Seite neu laden)

==== Es kann kein Logbild hochgeladen werden (betrifft Legacy-Testsystem) ====
Sobald man ein Logbild hochladen möchte, erscheint eine Fehlermeldung
<nowiki>Warning: move_uploaded_file(): Unable to move '/tmp/phpGmSzpi' to '/application/htdocs/config2/../images/uploads/700770A6-C101-11EA-BA77-0242AC120005.jpg' in /application/htdocs/lib2/logic/picture.class.php on line 856</nowiki>
Abhilfe: (noch) keine Ahnung. Die Bilder wurden aber trotzdem hochgeladen.

==== Bei Anlegen/Editieren eines Listings funktioniert die Attributeauswahl nicht (betrifft Legacy-Testsystem) ====
Editiert man ein Listing, stehen nicht alle Attribute zur Verfügung bzw. es können nicht alle Attribute ausgewählt werden.

Abhilfe: (noch) keine Ahnung.

==== Das Länderauswahlfeld rechts oben auf der Seite ist leer und funktioniert nicht. (betrifft Legacy-Testsystem) ====
Alle php-Dateien im Cacheverzeichnis htdocs/var/cache2 müssen gelöscht werden.

Das Vorgehen Unter Linux:
<nowiki>./psh.phar docker:stop
rm htdocs/var/cache2/*.inc.php
./psh.phar docker:start</nowiki>

==== Es kann nicht auf die Domains docker.team-opencaching.de oder try.docker.team-opencaching.de zugegriffen werden. ====
Normalerweise sollte der Zugriff nach Installation der Testumgebung automatisch funktionieren. Sollte das nicht der Fall sein, kann mittels Anpassung der hosts-Datei ein Workaround geschaffen werden:
<nowiki>127.0.0.1 docker.team-opencaching.de
127.0.0.1 try.docker.team-opencaching.de</nowiki>

==== Abschalten von “NOTICE”-Meldungen. (betrifft Legacy-Testsystem) ====
Aufgrund diverser (Smarty- und PHP-)Updates werden vormals ignorierte Probleme nun mit einer “NOTICE”-Meldung kenntlich gemacht. Um die Meldungen zu unterdrücken, kann in das error_reporting Level geändert werden.

Beispiele für Fehlermeldungen:
<nowiki>Notice: Undefined index: error_password_not_ok in /app/htdocs/var/cache2/smarty/compiled/..
Notice: Trying to get property 'value' of non-object in /app/..</nowiki>

Abhilfe:
Bis Smarty 3.x: In der Datei /htdocs/vendor/smarty/smarty/libs/Smarty.class.php die Zeile mit $error_reporting ändern auf den nachfolgenden Code. Die Änderung ist nicht git-relevant und geht nach jedem “./psh.phar docker:start-clean” verloren.
<nowiki>public $error_reporting = E_ALL & ~E_NOTICE;</nowiki>

Ab Smarty 3.x und 4.x: In der Datei /htdocs/lib2/common.inc.php die obere Zeile (PHP_DEBUG_ON) mit $error_reporting ändern auf den nachfolgenden Code. Die Änderung ist permanent und muss vor einem Commit rückgängig gemacht werden, da sie sonst im github Repository landet.
<nowiki>ini_set('error_reporting', E_ALL & ~E_NOTICE);</nowiki>

==== [gelöst] Die Übersetzungen funktionieren nicht. Meist wird nur Englischer Text angezeigt. (betrifft Legacy-Testsystem) ====
Die vorhandenen Fremdsprachen werden auf dem Testsystem nicht korrekt dargestellt. Meistens wird nur der Englische Text oder ein Mischmasch aus Englisch und eingestellter Sprache angezeigt.

Abhilfe: im docker:start Skript wurde eine fehlende Komponente ergänzt, welche nun automatisch mitinstalliert wird. Dadurch werden die Sprachdateien korrekt erzeugt und die Übersetzungen funktionieren.

Siehe auch: [[https://opencaching.atlassian.net/browse/RED-1278|RED-1278: Die Übersetzungen funktionieren auf dem Testserver nicht]]
Dieser Fehler sollte somit nicht mehr auftauchen.

==== [gelöst] Beim Löschen von Logs kommt eine Fehlermeldung “This log entry has been created on another Opencaching website. The cache can only be edited there.” ====
Auf dem Testserver werden die Logs laut Datenbank (Tabelle ''cache_logs'', Spalte ''nodes'') als ''node=5'' gespeichert, obwohl es laut Tabelle ''nodes'' diese Ziffer gar nicht gibt.

Um Logs wieder über die normale Loglöschenfunktion löschen zu können, gibt es mehrere Möglichkeiten:
# In der Datenbanktabelle ‘cache_logs’ den Eintrag in Spalte ‘nodes’ auf 4 ändern. (Dies entspricht der ‘Local Development’-Umgebung (siehe Tabelle ‘nodes’)).
# In der Datei ‘/dev-ops/local.team-opencaching.de/templates/config2-settings.inc.tpl.php' den Eintrag ‘$opt['logic']['node']['id'] = 5;’ ändern auf '$opt['logic']['node']['id'] = 4;’ und das docker:init Script ausführen
# Der Pull [[https://github.com/OpencachingDeutschland/oc-server3/pull/830|Pull Request #830 changed node information from 5 to 4]] behebt das Problem.

[[Kategorie:Entwicklung|Fehlerhandbuch ]]

Entwicklungsumgebung/Fehlerhandbuch

2025-09-01T17:02:20Z

Fraggle:

Während der Installation der Programme oder Einrichtung der Testumgebung kann es zu diversen Fehlern und Meldungen kommen. Im Folgenden sind bereits bekannte Meldungen aufgelistet, die bei einer schnellen Behebung helfen sollen.

== Fehlermeldungen während der Paketinstallation ==
==== Während der Installation der benötigten Pakete, kommt es zu einer Meldung, dass Abhängigkeiten mit dem ‘libdvd-pkg’ Paket nicht aufgelöst werden können ====

Eine Rekonfiguration des Pakets schafft Abhilfe:
<nowiki>sudo dpkg-reconfigure libdvd-pkg</nowiki>

== Fehlermeldungen in Zusammenhang mit der Dockerumgebung ==
==== Fehler “starting opencaching-webserver .. error” oder “Starting webserver ... error” ====
Vermutlich läuft im Hintergrund bereits ein anderer Webservice auf Port 80.

Prüfen kann man das mit:
netstat -tanp | grep :80

Zum Beispiel ein apache2-Webserver kann gestoppt werden mit:
sudo systemctl stop apache2

Damit der apache2 nach einem Rechnerneustart nicht erneut aktiviert wird, kann man ihn generell deaktivieren:
sudo systemctl disable apache2

Alternativ lässt sich auch eine [[https://docs.docker.com/compose/extends/|Override-Datei]] für die betroffenen Ports verwenden, was allerdings weitere Komplikationen mit sich führen kann (wie beispielsweise eine nicht funktionierende OKAPI). Aus diesem Grund sollte nach Möglichkeit das Stoppen der Standard-Services für Apache und einen Datenbank-Server vorgezogen werden.

==== Fehler “W: GPG error: https://dl.yarnpkg.com/debian stable InRelease: The following signatures were invalid: EXPKEYSIG“ ====
Nach dem Ausführen von ./psh.phar docker:start kommt der Fehler. Hier ist das Zertifikat veraltet. Folgender Befehl löscht das Docker-Image.
docker-compose build --pull

Mit einen erneuten ./psh.phar docker:start läuft es wieder durch.

==== Fehler “ERROR: for opencaching-mariadb Cannot start service mariadb: driver failed programming external connectivity on endpoint opencaching-mariadb [..] Error starting userland proxy: listen tcp 0.0.0.0:3306: bind: address already in use” ====
Wenn beim docker:start diese Fehlermeldung kommt, läuft im Hintergrund bereits ein anderer Webservice (z.B. mysql) auf Port 3306.

Prüfen kann man das mit:
netstat -tanp | grep :3306

Zum Beispiel ein mysql-Webserver kann gestoppt werden mit:
sudo mysqladmin -u root shutdown

==== Fehler "The stream or file "/application/htdocs/var/logs/dev/dev.log" could not be opened: failed to open stream: Permission denied" oder ähnlich ====
Hier scheint der Webserver keine Zugriffsberechtigung auf bestimmte Pfade/Dateien zu haben. Von einem Ändern der Zugriffsberechtigungen, z. B. mittels sudo chmod -R 777 ./var/log, sollte aus Sicherheitsgründen aber Abstand genommen werden.

Helfen kann, die Befehlsfolge
./psh.phar docker:ssh
./psh.phar docker:init
exit
ein weiteres Mal auszuführen.

Falls dies weiterhin keinen Erfolg bringt, können folgende Schritte zum Ändern der Zugriffsberechtigungen angewandt werden:
# Ermitteln der ID des Containers oc-server3_php-fpm mittels sudo docker ps.
# Öffnen einer Shell im Container: sudo docker exec -it 45b6e4994fac /bin/bash, wobei 45b6e4994fac die ID des Containers ist.
# In der Container-Shell chmod -R 777 /application/htdocs/var/logs/dev/ ausführen.
# Die Container-Shell regulär mittels exit verlassen.

==== Host-Mismatch bei Aufruf der OKAPI mit Port-Override ====
Falls in einer Override-Datei Ports überschrieben werden (siehe oben), funktioniert die OKAPI möglicherweise nicht richtig - stattdessen erscheint ein Hinweis auf einen Port-Mismatch. Dies kann auf folgende Art und Weise behoben werden:
# Ermitteln der ID des Containers ''oc-server3_php-fpm'' mittels ''sudo docker ps''.
# Öffnen einer Shell im Container: ''sudo docker exec -it 45b6e4994fac /bin/bash'', wobei 45b6e4994fac die ID des Containers ist.
# Im Container einen Editor installieren, beispielsweise nano. Da der Container auf Ubuntu basiert, funktioniert dies mittels ''apt-get update && apt-get install nano''.
# Die passende Konfigurationsdatei mittels des Editors im Container öffnen, beispielsweise mittels ''nano /application/htdocs/config2/settings.inc.php.''
# Setzen von ''$dev_baseurl = 'http://docker.team-opencaching.de:2200';'' und anschließendes Speichern der Datei. Hierbei ist 2200 der Port, der statt Port 80 für den Webserver in der Override-Datei konfiguriert worden ist.

==== Während docker:init kommt es im Abschnitt (3/31) zu einer Meldung “> mysql -uroot -proot -hmariadb -e "DROP DATABASE IF EXISTS opencaching" ERROR 2005 (HY000): Unknown MySQL server host 'mariadb' (-3).“ ====
Abhilfe: ''./psh.phar docker:init'' darf nicht außerhalb des Dockercontainers aufgerufen werden.

==== Während docker:init kommt es im Abschnitt (13/31) zu einer Meldung “PHP Fatal error: .. __toString() must not throw an exception ..“ ====
Die Ursache ist nicht bekannt. Hier hilft aktuell nur ein Workaround, in dem die Exception im Script auskommentiert wird.

Hierzu in der Datei ''../htdocs/vendor/symfony/symfony/src/Symfony/Component/DependencyInjection/Compiler/AutowirePass.php'' die Zeile 236 ''throw new AutoWiringFailedException'' auskommentieren. Die Datei ist allerdings erst nach dem Ausführens von docker:init vorhanden.

Siehe auch Ticket: [[https://opencaching.atlassian.net/browse/OCC-90|OCC-90: Exception error during docker:init]]

==== Docker Services neu initialisieren, z.B. bei “''W: GPG error: stable InRelease: The following signatures were invalid: EXPKEYSIG 23E7166788B63E1E Yarn Packaging <yarn@dan.cx>''“ ====
Treten während eines docker:init neue, merkwürdige und nicht näher spezifizierbare Fehler auf, kann es helfen, die Dockercontainer neu zu initialisieren mittels:
docker-compose build --pull

==== z.B. bei Update auf Symfony 5.2 kommt während docker:start-clean der Fehler ''”mv: cannot stat '/root/.symfony/bin/symfony': No such file or directory Service 'webserver' failed to build: The command '/bin/sh -c mv /root/.symfony/bin/symfony /usr/local/bin/symfony' returned a non-zero code: 1"'' ====
In diesem Fall in der Datei ''docker/httpd/Dockerfile'' die fehlerverursachende Zeile
RUN mv /root/.symfony/bin/symfony /usr/local/bin/symfony
auskommentieren und docker:start-clean erneut laufen lassen.

==== Während docker:start-clean: ''"\Doctrine\Common\Persistence\Mapping\Driver\MappingDriverChain()" not found'' ====
Dies ist ein Fehler in einem der ''doctrine/*'' Pakete (vermutlich ''doctrine/persistence'') in bestimmten Paketversionen. Hier hilft, die Datei ''/htdocs/vendor/doctrine/doctrine-bundle/Resources/config/orm.xml'' Zeile 32 zu editieren:
<parameter key="doctrine.orm.metadata.driver_chain.class">Doctrine\Common\Persistence\Mapping\Driver\MappingDriverChain</parameter>
zu
<parameter key="doctrine.orm.metadata.driver_chain.class">Doctrine\Persistence\Mapping\Driver\MappingDriverChain</parameter>

Allerdings muss dies zum richtigen Zeitpunkt passieren. Nachdem ''docker:start-clean'' aufgerufen wurde, kurz warten, bis die Pakete heruntergeladen wurden und noch bevor Abschnitt 13/32 anfängt, muss die Datei korrigiert und gespeichert worden sein.

==== Meldung “DEPRECATED: The legacy builder is deprecated and will be removed in a future release. Install the buildx component to build images with [[https://docs.docker.com/go/buildx/|BuildKit]] ====
Der Docker build Prozess wurde geändert. Die bisherige Methode wurde ab Dockerversion 23 als “deprecated” markiert und wird in einer zukünftigen Version entfernt. Siehe [[https://docs.docker.com/engine/deprecated/#legacy-builder-for-linux-images|Deprecated Engine Features]]

==== Meldung “ERROR: BuildKit is enabled but the buildx component is missing or broken.“ ====
Docker Buildkit/buildx soll verwendet werden (DOCKER_BUILDKIT=1), wurde aber nicht installiert.

Abhilfe: Buildkit/buildx Komponente installieren. Vorher müssen aber einige bereits installierte Pakete entfernt werden. Je nach OS gibt es unterschiedliche Anweisungen und Installationswege, siehe hier: [[https://docs.docker.com/engine/install/|Install Docker Engine]]

==== Während docker:start-clean: ''"Browserslist: caniuse-lite is outdated."'' ====
Scheinbar wird die “browserslist” nicht automatisch aktualisiert. (Grund? k.A.)

Zum manuellen Update im Docker:ssh eingeben:
npx browserslist@latest --update-db
bzw.
npx update-browserslist-db@latest

== Fehlermeldungen beim Zugriff auf die Datenbank ==
==== Fehlermeldung “ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)” ====
Es wurde vergessen, den Namen der Datenbank in der Kommandozeile zu übergeben.
mysql -uroot -proot -hmariadb opencaching

== Fehlermeldungen beim Zugriff auf die Testserverdomain ==
==== Vorgehen zum Anlegen eines weiteren Benutzers (betrifft Legacy-Testsystem) ====
Zuerst via http://docker.team-opencaching.de/register.php einen neuen Nutzer registrieren. Zwar kommt dann die Meldung, dass der Aktivierungscode per Mail zugsandt wurde, dies passiert aber nie. Der Aktivierungscode muss aus der Test-Datenbank ausgelesen werden.
Der Code steht in Tabelle ''user'' im Feld ''activation_code''.

Mit http://docker.team-opencaching.de/activation.php gelangt man zur Account-Aktivierungsseite. Hier die E-Mail-Adresse und den aus der Datenbank kopierten Aktivierungscode eingeben. Der Account ist nun aktiviert, aber falls der Login nicht funktioniert: siehe andere Fehlermeldung hier auf der Seite weiter unten.

Info: Eventuell wird in Zukunft der MailHog zum Laufen gebracht. Dann werden die vom Server verschickten Emails von diesem abgefangen und man kann die Informationen darin lesen.

==== Der neu angelegte Benutzer kann sich nicht einloggen und wird immer wieder ohne Meldung auf die Login-Seite geleitet (betrifft Legacy-Testsystem) ====
Die exakte Ursache ist nicht bekannt. Abhilfe kann geschaffen werden, wenn beim entsprechenden Nutzer in der Datenbank in der Tabelle ''user'' das Feld ''permanent_login_flag'' auf ''1'' gesetzt wird.

==== Beim Anlegen des ''zweiten'' Cachelistings kommt eine Fehlermeldung (betrifft Legacy-Testsystem) ====
Bei einer ''leeren'' Datenbank funktioniert das Setzen und Hochzählen der OC-Codes nicht. Es muss einmal ein OC-Code von Hand gesetzt werden.

Hierzu auf dem Testserver ein Listing anlegen. Dann für diesen Cache in der Datenbank in der Tabelle ''caches'' das Feld ''wp_oc'' auf einen initialen Wert ändern, z.B. ''OC1234''.

==== Beim Erstellen/Speichern eines Cachelistings kommen mehrere Fehlermeldungen, u.a. “Warning: A non-numeric value encountered in /app/htdocs/newcache.php on line 1025” (betrifft Legacy-Testsystem) ====
[[Image:Fehlerhandbuch Domain 01.png|500px]]

Zuerst muss geschaut werden, ob eventuell der vorige Abschnitt (“Beim Anlegen des zweiten Cachelistings kommt eine Fehlermeldung“) zutrifft. Wurden die dort beschriebenen Maßnahmen bereits umgesetzt, kommt es zwar trotzdem zur Fehlermeldung, das Listing wurde aber erfolgreich angelegt bzw. gespeichert. (Seite neu laden)

==== Es kann kein Logbild hochgeladen werden (betrifft Legacy-Testsystem) ====
Sobald man ein Logbild hochladen möchte, erscheint eine Fehlermeldung
<nowiki>Warning: move_uploaded_file(): Unable to move '/tmp/phpGmSzpi' to '/application/htdocs/config2/../images/uploads/700770A6-C101-11EA-BA77-0242AC120005.jpg' in /application/htdocs/lib2/logic/picture.class.php on line 856</nowiki>
Abhilfe: (noch) keine Ahnung. Die Bilder wurden aber trotzdem hochgeladen.

==== Bei Anlegen/Editieren eines Listings funktioniert die Attributeauswahl nicht (betrifft Legacy-Testsystem) ====
Editiert man ein Listing, stehen nicht alle Attribute zur Verfügung bzw. es können nicht alle Attribute ausgewählt werden.

Abhilfe: (noch) keine Ahnung.

==== Das Länderauswahlfeld rechts oben auf der Seite ist leer und funktioniert nicht. (betrifft Legacy-Testsystem) ====
Alle php-Dateien im Cacheverzeichnis htdocs/var/cache2 müssen gelöscht werden.

Das Vorgehen Unter Linux:
<nowiki>./psh.phar docker:stop
rm htdocs/var/cache2/*.inc.php
./psh.phar docker:start</nowiki>

==== Es kann nicht auf die Domains docker.team-opencaching.de oder try.docker.team-opencaching.de zugegriffen werden. ====
Normalerweise sollte der Zugriff nach Installation der Testumgebung automatisch funktionieren. Sollte das nicht der Fall sein, kann mittels Anpassung der hosts-Datei ein Workaround geschaffen werden:
<nowiki>127.0.0.1 docker.team-opencaching.de
127.0.0.1 try.docker.team-opencaching.de</nowiki>

==== Abschalten von “NOTICE”-Meldungen. (betrifft Legacy-Testsystem) ====
Aufgrund diverser (Smarty- und PHP-)Updates werden vormals ignorierte Probleme nun mit einer “NOTICE”-Meldung kenntlich gemacht. Um die Meldungen zu unterdrücken, kann in das error_reporting Level geändert werden.

Beispiele für Fehlermeldungen:
<nowiki>Notice: Undefined index: error_password_not_ok in /app/htdocs/var/cache2/smarty/compiled/..
Notice: Trying to get property 'value' of non-object in /app/..</nowiki>

Abhilfe:
Bis Smarty 3.x: In der Datei /htdocs/vendor/smarty/smarty/libs/Smarty.class.php die Zeile mit $error_reporting ändern auf den nachfolgenden Code. Die Änderung ist nicht git-relevant und geht nach jedem “./psh.phar docker:start-clean” verloren.
<nowiki>public $error_reporting = E_ALL & ~E_NOTICE;</nowiki>

Ab Smarty 3.x und 4.x: In der Datei /htdocs/lib2/common.inc.php die obere Zeile (PHP_DEBUG_ON) mit $error_reporting ändern auf den nachfolgenden Code. Die Änderung ist permanent und muss vor einem Commit rückgängig gemacht werden, da sie sonst im github Repository landet.
<nowiki>ini_set('error_reporting', E_ALL & ~E_NOTICE);</nowiki>

==== [gelöst] Die Übersetzungen funktionieren nicht. Meist wird nur Englischer Text angezeigt. (betrifft Legacy-Testsystem) ====
Die vorhandenen Fremdsprachen werden auf dem Testsystem nicht korrekt dargestellt. Meistens wird nur der Englische Text oder ein Mischmasch aus Englisch und eingestellter Sprache angezeigt.

Abhilfe: im docker:start Skript wurde eine fehlende Komponente ergänzt, welche nun automatisch mitinstalliert wird. Dadurch werden die Sprachdateien korrekt erzeugt und die Übersetzungen funktionieren.

Siehe auch: [[https://opencaching.atlassian.net/browse/RED-1278|RED-1278: Die Übersetzungen funktionieren auf dem Testserver nicht]]
Dieser Fehler sollte somit nicht mehr auftauchen.

==== [gelöst] Beim Löschen von Logs kommt eine Fehlermeldung “This log entry has been created on another Opencaching website. The cache can only be edited there.” ====
Auf dem Testserver werden die Logs laut Datenbank (Tabelle ''cache_logs'', Spalte ''nodes'') als ''node=5'' gespeichert, obwohl es laut Tabelle ''nodes'' diese Ziffer gar nicht gibt.

Um Logs wieder über die normale Loglöschenfunktion löschen zu können, gibt es mehrere Möglichkeiten:
# In der Datenbanktabelle ‘cache_logs’ den Eintrag in Spalte ‘nodes’ auf 4 ändern. (Dies entspricht der ‘Local Development’-Umgebung (siehe Tabelle ‘nodes’)).
# In der Datei ‘/dev-ops/local.team-opencaching.de/templates/config2-settings.inc.tpl.php' den Eintrag ‘$opt['logic']['node']['id'] = 5;’ ändern auf '$opt['logic']['node']['id'] = 4;’ und das docker:init Script ausführen
# Der Pull [[https://github.com/OpencachingDeutschland/oc-server3/pull/830|Pull Request #830 changed node information from 5 to 4]] behebt das Problem.

[[Kategorie:Entwicklung|Fehlerhandbuch ]]

Entwicklungsumgebung/Fehlerhandbuch

2025-09-01T17:02:06Z

Fraggle:

__TOC__
__FORCETOC__

Während der Installation der Programme oder Einrichtung der Testumgebung kann es zu diversen Fehlern und Meldungen kommen. Im Folgenden sind bereits bekannte Meldungen aufgelistet, die bei einer schnellen Behebung helfen sollen.

== Fehlermeldungen während der Paketinstallation ==
==== Während der Installation der benötigten Pakete, kommt es zu einer Meldung, dass Abhängigkeiten mit dem ‘libdvd-pkg’ Paket nicht aufgelöst werden können ====

Eine Rekonfiguration des Pakets schafft Abhilfe:
<nowiki>sudo dpkg-reconfigure libdvd-pkg</nowiki>

== Fehlermeldungen in Zusammenhang mit der Dockerumgebung ==
==== Fehler “starting opencaching-webserver .. error” oder “Starting webserver ... error” ====
Vermutlich läuft im Hintergrund bereits ein anderer Webservice auf Port 80.

Prüfen kann man das mit:
netstat -tanp | grep :80

Zum Beispiel ein apache2-Webserver kann gestoppt werden mit:
sudo systemctl stop apache2

Damit der apache2 nach einem Rechnerneustart nicht erneut aktiviert wird, kann man ihn generell deaktivieren:
sudo systemctl disable apache2

Alternativ lässt sich auch eine [[https://docs.docker.com/compose/extends/|Override-Datei]] für die betroffenen Ports verwenden, was allerdings weitere Komplikationen mit sich führen kann (wie beispielsweise eine nicht funktionierende OKAPI). Aus diesem Grund sollte nach Möglichkeit das Stoppen der Standard-Services für Apache und einen Datenbank-Server vorgezogen werden.

==== Fehler “W: GPG error: https://dl.yarnpkg.com/debian stable InRelease: The following signatures were invalid: EXPKEYSIG“ ====
Nach dem Ausführen von ./psh.phar docker:start kommt der Fehler. Hier ist das Zertifikat veraltet. Folgender Befehl löscht das Docker-Image.
docker-compose build --pull

Mit einen erneuten ./psh.phar docker:start läuft es wieder durch.

==== Fehler “ERROR: for opencaching-mariadb Cannot start service mariadb: driver failed programming external connectivity on endpoint opencaching-mariadb [..] Error starting userland proxy: listen tcp 0.0.0.0:3306: bind: address already in use” ====
Wenn beim docker:start diese Fehlermeldung kommt, läuft im Hintergrund bereits ein anderer Webservice (z.B. mysql) auf Port 3306.

Prüfen kann man das mit:
netstat -tanp | grep :3306

Zum Beispiel ein mysql-Webserver kann gestoppt werden mit:
sudo mysqladmin -u root shutdown

==== Fehler "The stream or file "/application/htdocs/var/logs/dev/dev.log" could not be opened: failed to open stream: Permission denied" oder ähnlich ====
Hier scheint der Webserver keine Zugriffsberechtigung auf bestimmte Pfade/Dateien zu haben. Von einem Ändern der Zugriffsberechtigungen, z. B. mittels sudo chmod -R 777 ./var/log, sollte aus Sicherheitsgründen aber Abstand genommen werden.

Helfen kann, die Befehlsfolge
./psh.phar docker:ssh
./psh.phar docker:init
exit
ein weiteres Mal auszuführen.

Falls dies weiterhin keinen Erfolg bringt, können folgende Schritte zum Ändern der Zugriffsberechtigungen angewandt werden:
# Ermitteln der ID des Containers oc-server3_php-fpm mittels sudo docker ps.
# Öffnen einer Shell im Container: sudo docker exec -it 45b6e4994fac /bin/bash, wobei 45b6e4994fac die ID des Containers ist.
# In der Container-Shell chmod -R 777 /application/htdocs/var/logs/dev/ ausführen.
# Die Container-Shell regulär mittels exit verlassen.

==== Host-Mismatch bei Aufruf der OKAPI mit Port-Override ====
Falls in einer Override-Datei Ports überschrieben werden (siehe oben), funktioniert die OKAPI möglicherweise nicht richtig - stattdessen erscheint ein Hinweis auf einen Port-Mismatch. Dies kann auf folgende Art und Weise behoben werden:
# Ermitteln der ID des Containers ''oc-server3_php-fpm'' mittels ''sudo docker ps''.
# Öffnen einer Shell im Container: ''sudo docker exec -it 45b6e4994fac /bin/bash'', wobei 45b6e4994fac die ID des Containers ist.
# Im Container einen Editor installieren, beispielsweise nano. Da der Container auf Ubuntu basiert, funktioniert dies mittels ''apt-get update && apt-get install nano''.
# Die passende Konfigurationsdatei mittels des Editors im Container öffnen, beispielsweise mittels ''nano /application/htdocs/config2/settings.inc.php.''
# Setzen von ''$dev_baseurl = 'http://docker.team-opencaching.de:2200';'' und anschließendes Speichern der Datei. Hierbei ist 2200 der Port, der statt Port 80 für den Webserver in der Override-Datei konfiguriert worden ist.

==== Während docker:init kommt es im Abschnitt (3/31) zu einer Meldung “> mysql -uroot -proot -hmariadb -e "DROP DATABASE IF EXISTS opencaching" ERROR 2005 (HY000): Unknown MySQL server host 'mariadb' (-3).“ ====
Abhilfe: ''./psh.phar docker:init'' darf nicht außerhalb des Dockercontainers aufgerufen werden.

==== Während docker:init kommt es im Abschnitt (13/31) zu einer Meldung “PHP Fatal error: .. __toString() must not throw an exception ..“ ====
Die Ursache ist nicht bekannt. Hier hilft aktuell nur ein Workaround, in dem die Exception im Script auskommentiert wird.

Hierzu in der Datei ''../htdocs/vendor/symfony/symfony/src/Symfony/Component/DependencyInjection/Compiler/AutowirePass.php'' die Zeile 236 ''throw new AutoWiringFailedException'' auskommentieren. Die Datei ist allerdings erst nach dem Ausführens von docker:init vorhanden.

Siehe auch Ticket: [[https://opencaching.atlassian.net/browse/OCC-90|OCC-90: Exception error during docker:init]]

==== Docker Services neu initialisieren, z.B. bei “''W: GPG error: stable InRelease: The following signatures were invalid: EXPKEYSIG 23E7166788B63E1E Yarn Packaging <yarn@dan.cx>''“ ====
Treten während eines docker:init neue, merkwürdige und nicht näher spezifizierbare Fehler auf, kann es helfen, die Dockercontainer neu zu initialisieren mittels:
docker-compose build --pull

==== z.B. bei Update auf Symfony 5.2 kommt während docker:start-clean der Fehler ''”mv: cannot stat '/root/.symfony/bin/symfony': No such file or directory Service 'webserver' failed to build: The command '/bin/sh -c mv /root/.symfony/bin/symfony /usr/local/bin/symfony' returned a non-zero code: 1"'' ====
In diesem Fall in der Datei ''docker/httpd/Dockerfile'' die fehlerverursachende Zeile
RUN mv /root/.symfony/bin/symfony /usr/local/bin/symfony
auskommentieren und docker:start-clean erneut laufen lassen.

==== Während docker:start-clean: ''"\Doctrine\Common\Persistence\Mapping\Driver\MappingDriverChain()" not found'' ====
Dies ist ein Fehler in einem der ''doctrine/*'' Pakete (vermutlich ''doctrine/persistence'') in bestimmten Paketversionen. Hier hilft, die Datei ''/htdocs/vendor/doctrine/doctrine-bundle/Resources/config/orm.xml'' Zeile 32 zu editieren:
<parameter key="doctrine.orm.metadata.driver_chain.class">Doctrine\Common\Persistence\Mapping\Driver\MappingDriverChain</parameter>
zu
<parameter key="doctrine.orm.metadata.driver_chain.class">Doctrine\Persistence\Mapping\Driver\MappingDriverChain</parameter>

Allerdings muss dies zum richtigen Zeitpunkt passieren. Nachdem ''docker:start-clean'' aufgerufen wurde, kurz warten, bis die Pakete heruntergeladen wurden und noch bevor Abschnitt 13/32 anfängt, muss die Datei korrigiert und gespeichert worden sein.

==== Meldung “DEPRECATED: The legacy builder is deprecated and will be removed in a future release. Install the buildx component to build images with [[https://docs.docker.com/go/buildx/|BuildKit]] ====
Der Docker build Prozess wurde geändert. Die bisherige Methode wurde ab Dockerversion 23 als “deprecated” markiert und wird in einer zukünftigen Version entfernt. Siehe [[https://docs.docker.com/engine/deprecated/#legacy-builder-for-linux-images|Deprecated Engine Features]]

==== Meldung “ERROR: BuildKit is enabled but the buildx component is missing or broken.“ ====
Docker Buildkit/buildx soll verwendet werden (DOCKER_BUILDKIT=1), wurde aber nicht installiert.

Abhilfe: Buildkit/buildx Komponente installieren. Vorher müssen aber einige bereits installierte Pakete entfernt werden. Je nach OS gibt es unterschiedliche Anweisungen und Installationswege, siehe hier: [[https://docs.docker.com/engine/install/|Install Docker Engine]]

==== Während docker:start-clean: ''"Browserslist: caniuse-lite is outdated."'' ====
Scheinbar wird die “browserslist” nicht automatisch aktualisiert. (Grund? k.A.)

Zum manuellen Update im Docker:ssh eingeben:
npx browserslist@latest --update-db
bzw.
npx update-browserslist-db@latest

== Fehlermeldungen beim Zugriff auf die Datenbank ==
==== Fehlermeldung “ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)” ====
Es wurde vergessen, den Namen der Datenbank in der Kommandozeile zu übergeben.
mysql -uroot -proot -hmariadb opencaching

== Fehlermeldungen beim Zugriff auf die Testserverdomain ==
==== Vorgehen zum Anlegen eines weiteren Benutzers (betrifft Legacy-Testsystem) ====
Zuerst via http://docker.team-opencaching.de/register.php einen neuen Nutzer registrieren. Zwar kommt dann die Meldung, dass der Aktivierungscode per Mail zugsandt wurde, dies passiert aber nie. Der Aktivierungscode muss aus der Test-Datenbank ausgelesen werden.
Der Code steht in Tabelle ''user'' im Feld ''activation_code''.

Mit http://docker.team-opencaching.de/activation.php gelangt man zur Account-Aktivierungsseite. Hier die E-Mail-Adresse und den aus der Datenbank kopierten Aktivierungscode eingeben. Der Account ist nun aktiviert, aber falls der Login nicht funktioniert: siehe andere Fehlermeldung hier auf der Seite weiter unten.

Info: Eventuell wird in Zukunft der MailHog zum Laufen gebracht. Dann werden die vom Server verschickten Emails von diesem abgefangen und man kann die Informationen darin lesen.

==== Der neu angelegte Benutzer kann sich nicht einloggen und wird immer wieder ohne Meldung auf die Login-Seite geleitet (betrifft Legacy-Testsystem) ====
Die exakte Ursache ist nicht bekannt. Abhilfe kann geschaffen werden, wenn beim entsprechenden Nutzer in der Datenbank in der Tabelle ''user'' das Feld ''permanent_login_flag'' auf ''1'' gesetzt wird.

==== Beim Anlegen des ''zweiten'' Cachelistings kommt eine Fehlermeldung (betrifft Legacy-Testsystem) ====
Bei einer ''leeren'' Datenbank funktioniert das Setzen und Hochzählen der OC-Codes nicht. Es muss einmal ein OC-Code von Hand gesetzt werden.

Hierzu auf dem Testserver ein Listing anlegen. Dann für diesen Cache in der Datenbank in der Tabelle ''caches'' das Feld ''wp_oc'' auf einen initialen Wert ändern, z.B. ''OC1234''.

==== Beim Erstellen/Speichern eines Cachelistings kommen mehrere Fehlermeldungen, u.a. “Warning: A non-numeric value encountered in /app/htdocs/newcache.php on line 1025” (betrifft Legacy-Testsystem) ====
[[Image:Fehlerhandbuch Domain 01.png|500px]]

Zuerst muss geschaut werden, ob eventuell der vorige Abschnitt (“Beim Anlegen des zweiten Cachelistings kommt eine Fehlermeldung“) zutrifft. Wurden die dort beschriebenen Maßnahmen bereits umgesetzt, kommt es zwar trotzdem zur Fehlermeldung, das Listing wurde aber erfolgreich angelegt bzw. gespeichert. (Seite neu laden)

==== Es kann kein Logbild hochgeladen werden (betrifft Legacy-Testsystem) ====
Sobald man ein Logbild hochladen möchte, erscheint eine Fehlermeldung
<nowiki>Warning: move_uploaded_file(): Unable to move '/tmp/phpGmSzpi' to '/application/htdocs/config2/../images/uploads/700770A6-C101-11EA-BA77-0242AC120005.jpg' in /application/htdocs/lib2/logic/picture.class.php on line 856</nowiki>
Abhilfe: (noch) keine Ahnung. Die Bilder wurden aber trotzdem hochgeladen.

==== Bei Anlegen/Editieren eines Listings funktioniert die Attributeauswahl nicht (betrifft Legacy-Testsystem) ====
Editiert man ein Listing, stehen nicht alle Attribute zur Verfügung bzw. es können nicht alle Attribute ausgewählt werden.

Abhilfe: (noch) keine Ahnung.

==== Das Länderauswahlfeld rechts oben auf der Seite ist leer und funktioniert nicht. (betrifft Legacy-Testsystem) ====
Alle php-Dateien im Cacheverzeichnis htdocs/var/cache2 müssen gelöscht werden.

Das Vorgehen Unter Linux:
<nowiki>./psh.phar docker:stop
rm htdocs/var/cache2/*.inc.php
./psh.phar docker:start</nowiki>

==== Es kann nicht auf die Domains docker.team-opencaching.de oder try.docker.team-opencaching.de zugegriffen werden. ====
Normalerweise sollte der Zugriff nach Installation der Testumgebung automatisch funktionieren. Sollte das nicht der Fall sein, kann mittels Anpassung der hosts-Datei ein Workaround geschaffen werden:
<nowiki>127.0.0.1 docker.team-opencaching.de
127.0.0.1 try.docker.team-opencaching.de</nowiki>

==== Abschalten von “NOTICE”-Meldungen. (betrifft Legacy-Testsystem) ====
Aufgrund diverser (Smarty- und PHP-)Updates werden vormals ignorierte Probleme nun mit einer “NOTICE”-Meldung kenntlich gemacht. Um die Meldungen zu unterdrücken, kann in das error_reporting Level geändert werden.

Beispiele für Fehlermeldungen:
<nowiki>Notice: Undefined index: error_password_not_ok in /app/htdocs/var/cache2/smarty/compiled/..
Notice: Trying to get property 'value' of non-object in /app/..</nowiki>

Abhilfe:
Bis Smarty 3.x: In der Datei /htdocs/vendor/smarty/smarty/libs/Smarty.class.php die Zeile mit $error_reporting ändern auf den nachfolgenden Code. Die Änderung ist nicht git-relevant und geht nach jedem “./psh.phar docker:start-clean” verloren.
<nowiki>public $error_reporting = E_ALL & ~E_NOTICE;</nowiki>

Ab Smarty 3.x und 4.x: In der Datei /htdocs/lib2/common.inc.php die obere Zeile (PHP_DEBUG_ON) mit $error_reporting ändern auf den nachfolgenden Code. Die Änderung ist permanent und muss vor einem Commit rückgängig gemacht werden, da sie sonst im github Repository landet.
<nowiki>ini_set('error_reporting', E_ALL & ~E_NOTICE);</nowiki>

==== [gelöst] Die Übersetzungen funktionieren nicht. Meist wird nur Englischer Text angezeigt. (betrifft Legacy-Testsystem) ====
Die vorhandenen Fremdsprachen werden auf dem Testsystem nicht korrekt dargestellt. Meistens wird nur der Englische Text oder ein Mischmasch aus Englisch und eingestellter Sprache angezeigt.

Abhilfe: im docker:start Skript wurde eine fehlende Komponente ergänzt, welche nun automatisch mitinstalliert wird. Dadurch werden die Sprachdateien korrekt erzeugt und die Übersetzungen funktionieren.

Siehe auch: [[https://opencaching.atlassian.net/browse/RED-1278|RED-1278: Die Übersetzungen funktionieren auf dem Testserver nicht]]
Dieser Fehler sollte somit nicht mehr auftauchen.

==== [gelöst] Beim Löschen von Logs kommt eine Fehlermeldung “This log entry has been created on another Opencaching website. The cache can only be edited there.” ====
Auf dem Testserver werden die Logs laut Datenbank (Tabelle ''cache_logs'', Spalte ''nodes'') als ''node=5'' gespeichert, obwohl es laut Tabelle ''nodes'' diese Ziffer gar nicht gibt.

Um Logs wieder über die normale Loglöschenfunktion löschen zu können, gibt es mehrere Möglichkeiten:
# In der Datenbanktabelle ‘cache_logs’ den Eintrag in Spalte ‘nodes’ auf 4 ändern. (Dies entspricht der ‘Local Development’-Umgebung (siehe Tabelle ‘nodes’)).
# In der Datei ‘/dev-ops/local.team-opencaching.de/templates/config2-settings.inc.tpl.php' den Eintrag ‘$opt['logic']['node']['id'] = 5;’ ändern auf '$opt['logic']['node']['id'] = 4;’ und das docker:init Script ausführen
# Der Pull [[https://github.com/OpencachingDeutschland/oc-server3/pull/830|Pull Request #830 changed node information from 5 to 4]] behebt das Problem.

[[Kategorie:Entwicklung|Fehlerhandbuch ]]

Entwicklungsumgebung einrichten

2025-08-31T19:47:35Z

Fraggle: Anpassung host Datei auch unter Linux

Das Einrichten der Testumgebung erfolgt in mehreren Schritten, die im folgenden beschrieben sind. Falls es dabei zu unerwarteten Fehlermeldungen kommt, bitte die letzten Schritte noch einmal genau anschauen und gegebenenfalls wiederholen. Auch ein Blick ins Fehlerhandbuch hilft meistens, da bereits viele Fallstricke entdeckt und beschrieben wurden.

== 1. Das Betriebssystem vorbereiten, entweder Linux oder Windows ==
=== Windows 10 ===
==== Programme installieren ====
Unter Windows ist es standardmäßig nicht möglich, “einfach“ die Linux Distribution Ubuntu zu installieren. Dazu muss vorab erst das WSL2 aktiviert / installiert werden werden (Punkt 1). Im Anschluss ist eine Installation von Ubuntu (18.04 oder 20.04 oder höher) möglich. Zudem muss Docker installiert werden, in dem dann die Entwicklungsumgebung laufen kann (Punkt 2).

# WSL2 unter Windows10 aktivieren und Ubuntu 20.04 installieren:
## Aus dem Microsoft-Store: https://aka.ms/wslstorepage (verfügbar seit Nov. 2022)
## Manuell unter [https://learn.microsoft.com/de-de/windows/wsl/install#manual-installation-steps|Installieren von WSL]
# Docker für Windows installieren: [https://docs.docker.com/docker-for-windows/install/|Install Docker Desktop on Windows]
# Unter Windows muss in der Hosts-Datei (%windir%\system32\drivers\etc) folgende Eintragung gemacht werden:
<nowiki>127.0.0.1 docker.team-opencaching.de
127.0.0.1 try.docker.team-opencaching.de</nowiki>

Danach kann Ubuntu gestartet werden (z.B. im “Such“-Menü nach Ubuntu suchen und anklicken). Beim erstmaligen Starten von Ubuntu müssen ein Benutzername und ein Passwort festgelegt werden.

Im Anschluss den Punkten folgen und ausführen, die im nächsten Schritt “Linux” beschrieben werden.

=== Linux ===
Der Linuxartikel wurde erstellt auf Lubuntu 18.04, aktualisiert mit 22.04 und erweitert mit Debian 12

==== Programme installieren ====
Folgende Programme sind notwendig und müssen vorab installiert werden:
PHP (aktuell mind. PHP7.4, später PHP8), diverse PHP-Erweiterungen, docker-compose, mariadb-client. Für die PHP-Erweiterungen ist eventuell ein zusätzliches PPA-Repository notwendig. Dessen Installation erfordert je nach Betriebssystem ein unterschiedliches Vorgehen.

<nowiki>Ubuntu:
sudo apt install software-properties-common
sudo add-apt-repository ppa:ondrej/php

Debian:
sudo apt install software-properties-common ca-certificates lsb-release apt-transport-https
curl -sSL https://packages.sury.org/php/README.txt | sudo bash -x</nowiki>

Die Pakete lassen sich mit folgenden Befehlen installieren (Versionsnummer kann abweichen).
<nowiki>sudo apt update
sudo apt install php8 php8.0-mbstring php8.0-curl php8.0-xml php8.0-mysql
sudo apt install docker-compose
sudo apt install mariadb-client</nowiki>

Sollten beim Installieren der Pakete Fehlermeldungen auftreten, ist es empfehlenswert, die Pakete einzeln zu installieren und auftretende Fehler/Abhängigkeiten einzeln zu lösen.

==== Nutzer in docker-Gruppe aufnehmen ====
Der aktuelle Benutzer muss in die Gruppe “docker” aufgenommen werden, sonst kann es passieren, dass dieser keinen Zugriff auf die Dockercontainer bekommt.
<nowiki>sudo usermod -aG docker $(id -un)</nowiki>

Die Änderung wird aber erst nach einem Ab-/Anmelden des Nutzers wirksam. Überprüft werden kann dies danach mittels
<nowiki>id</nowiki>

Hier muss die “docker”-Gruppe aufgelistet sein. Beispiel:
<nowiki>uid=1000(user) gid=1000(user) groups=1000(user),4(adm),24(cdrom),..,128(docker)</nowiki>

==== Eigenschaften der Docker Socket-Datei prüfen ====
Den folgenden Befehl ausführen, um die Eigenschaften der Datei anzeigen zu lassen:
<nowiki>sudo ls -la /var/run/docker.sock</nowiki>

Die Datei muss dabei ‘docker’ zugewiesen sein:
<nowiki>rw-rw---- 1 root docker 0 Dec 21 19:16 /var/run/docker.sock</nowiki>

Ist dies nicht der Fall, muss die Zugehörigkeit geändert werden:
<nowiki>chgrp docker /var/run/docker.sock</nowiki>

==== host Datei anpassen ====
Die folgenden zwei Einträge sollten der host Date unter /etc/host hinzugefügt werden, da auf die URLs sonst unter Umständen nicht zugegriffen werden kann.
<nowiki>127.0.0.1 docker.team-opencaching.de
127.0.0.1 try.docker.team-opencaching.de</nowiki>

== 2. Sourcecode von Git laden ==
=== Github ===
Zwar ist zum Herunterlden des Sourcecodes keine Account auf GitHub notwendig, aber zum Hochladen wird einer benötigt. Daher sollte zuerst einen Account auf https://github.com/ angelegt werden.

=== optional: SSH-Keys für Repositorys anlegen und in Github eintragen ===
siehe https://docs.github.com/en/free-pro-team@latest/github/authenticating-to-github/connecting-to-github-with-ssh 
oder: https://www.heise.de/tipps-tricks/SSH-Key-fuer-GitHub-Repositories-einrichten-4627459.html

=== Git lokal installieren ===
Windows: 
siehe: https://github.com/git-for-windows/git/releases 

Linux:
<nowiki>sudo apt install git</nowiki>

=== Sourcecode lokal herunterladen ===
Ein Terminal öffnen, folgende Kommandos ausführen und dabei Namen und Email-Adresse des Git-Accounts eintragen:
<nowiki>git config --global user.name "Your Name Here"
git config --global user.email "your_email@youremail.com"</nowiki>

Im Verzeichnis "home" einen Ordner "opencaching" (Name beliebig) anlegen. Dort folgenden Code ausführen. Dies legt einen Ordner mit dem Namen “oc-server3“ an, lädt den OC-Code aus deinem Github-Fork herunter und kopiert ihn in diesen Ordner.
<nowiki>git clone git@github.com:<DeinGithubBenutzername>/oc-server3</nowiki>

Im Anschluss in den Ordner “oc-server3“ wechseln und den folgenden Befehl ausführen, um bei einem Update den neuesten Sourcecode aus dem Opencaching.de-Repository erhalten zu können:
<nowiki>cd oc-server3
git remote add upstream git@github.com:OpencachingDeutschland/oc-server3</nowiki>

Mit folgendem Befehl gibt es eine Übersicht über die verknüpften Repositorys, die (abgesehen vom Nutzernamen ‘Slini11’) wie in der Grafik aussehen müssen:
<nowiki>git remote -v</nowiki>
[[Image:Testumgebung Git 01.png]]

Nun den Branch “development“ auschecken:
<nowiki>git checkout development</nowiki>

Und den Development-Branch auf aktuellen Stand bringen:
<nowiki>git pull --rebase upstream development </nowiki>

=== Weiterführende Informationen zu Git ===
Diese sind unter anderem im [[Entwicklung/Git|OC-Wiki]] zu finden

== 3. Docker Entwicklungsumgebung initalisieren ==
=== Entwicklungsumgebung zum ersten Mal starten ===
(siehe auch: Github: [https://github.com/OpencachingDeutschland/oc-server3#starting-the-docker-development-environment|starting the docker environment])

Zuerst in den Projektordner “oc-server3“ navigieren und dort die Installation der Testumgebung starten. Es stehen hierfür zwei Befehlsfolgen zur Verfügung:

==== Scripte einzeln ausführen ====
* Die Dockerumgebung starten (ggf. der Benutzerkontensteuerung zustimmen). Dieser Vorgang dauert ein paar Minuten.
<nowiki>./psh.phar docker:start</nowiki>

* In den Dockercontainer hinein verbinden
<nowiki>./psh.phar docker:ssh</nowiki>

* Anschließend in der sich öffnenden docker bash einmalig das Initialisierungsskript starten. Dieser Vorgang dauert ein paar Minuten.
<nowiki>./psh.phar docker:init</nowiki>

[[Image:Testumgebung Docker 01.png]]

* Zuletzt den Dockercontainer wieder verlassen
<nowiki>exit</nowiki>

* Die Entwicklungsumgebung steht nun über den Browser bereit unter:
http://docker.team-opencaching.de bzw.
http://try.docker.team-opencaching.de

* Das Passwort für den Benutzer ''root'' lautet ''developer''. Das Passwort der anderen Benutzer (Benutzernamen siehe Datenbank) lautet ''password''

==== Das start-Script ausführen ====
* Statt die Schritte einzeln auszuführen, kann die Dockerinitialisierung auch mit einem einzigen Befehl gestartet werden:
<nowiki>./psh.phar docker:start-clean</nowiki>

Dieser Befehl führt alle oben beschriebenen Kommandos aus, löscht zusätzlich die Dockercontainer, den Cache des Testservers sowie alle von git ignorierten Dateien. Dieser Vorgang dauert ein paar Minuten länger und empfiehlt sich, wenn eine saubere Umgebung hergestellt werden soll oder während der Initialisierung unbehebbare Fehler auftreten.

* Die Entwicklungsumgebung steht nun über den Browser bereit unter:
http://docker.team-opencaching.de bzw.
http://try.docker.team-opencaching.de

* Das Passwort für den Benutzer ''root'' lautet ''developer''. Das Passwort der anderen Benutzer (Benutzernamen siehe Datenbank) lautet ''password''

=== Entwicklungsumgebung ein weiteres Mal starten ===
Die Testumgebung kann z.B. nach einem Neustart des Rechners im Projektordner gestartet werden mit:
<nowiki>./psh.phar docker:start</nowiki>

=== Entwicklungsumgebung stoppen ===
Die Testumgebung kann im Projektordner gestoppt werden mit:
<nowiki>./psh.phar docker:stop</nowiki>

== 4. Die Testdatenbank füllen ==
Während der Installation wird eine Testdatenbank importiert, die bereits eine kleine Menge an Caches und Nutzern beinhaltet. Ein manueller Import des Datenbankdumps ist somit (seit März 2021) nicht mehr notwendig.

Für den Fall, dass trotzdem Daten exportiert / importiert werden sollen, können folgende Abschnitte berücksichtigt werden:
Login auf der Test-Datenbank im Dockercontainer
<nowiki>mysql -uroot -proot -hmariadb opencaching</nowiki>

=== Datenbank zurücksetzen ===
<nowiki>(noch zu verifizieren und zu verbessern..)
im Docker per mysql auf die mariadb verbinden
'DROP' opencaching DB
exit mysql und docker
Nun entweder im Docker ein ./psh.phar docker:init ausführen oder wenn das Fehler bringt, vorher den kompletten git-Pfad neu aufsetzen
Ev. funktioniert auch der Weg, den DB-Dockercontainer aufzurufen, zu löschen, etc.
(docker-volume ls)</nowiki>

=== Datenbank innerhalb des Dockercontainers exportieren ===
<nowiki>mysqldump -uroot -proot -hmariadb opencaching > file.sql</nowiki>

=== Datenbank außerhalb des Dockercontainers exportieren ===
<nowiki>mysqldump --complete-insert --user root -proot --host 0.0.0.0 opencaching > dump.sql</nowiki>

=== Datenbank im phpStorm exportieren ===
Auf der rechten Bildschirmseite den Databasedialog ausklappen
rechte Maustaste auf die zu exportierende Datenbank “opencaching” => “Export with ‘mysqldump’”

[[Image:Testumgebung DB 01.png]]

Im Exportmenü die Zeile “Statements” umstellen auf “Insert with columns” und eventuell den Ausgabepfad “Out Path” anpassen. Im Kommandofeld den Parameter “--routines“ ergänzen und dann “Run” drücken

[[Image:Testumgebung DB 02.png]]

=== Datenbank-Dump im Dockercontainer importieren ===
Zuerst wird eine eventuell existierende Datenbank gelöscht und neu angelegt.
<nowiki>./psh.phar docker:init</nowiki>
Im zweiten Schritt wird die Datenbank mit dem Dump gefüllt.
<nowiki>mysql -uroot -proot -hmariadb opencaching < file.sql</nowiki>

=== Datenbank-Dump im phpStorm importieren ===
Auf der rechten Bildschirmseite den Databasedialog ausklappen
rechte Maustaste auf die Datenbank => “Restore with ‘mysql’”

[[Image:Testumgebung DB 03.png]]

Im Importmenü den Eingabepfad “Path to dump” anpassen, dann “Run” drücken

[[Image:Testumgebung DB 04.png]]

=== Datenbank in phpStorm anzeigen ===
Ggf. kann es passieren, dass die Datenbank nicht automatisch in phpStorm angezeigt wird. Dazu muss eine neue MariaDB im Datenbank-Menü angelegt werden.

[[Image:Testumgebung DB 05.png]]

Im Anschluss sind die Daten wie im folgenden Screenshot einzutragen. User: “root“ Password: “root“

[[Image:Testumgebung DB 06.png]]

== 5. Die Entwicklungs-IDE vorbereiten ==
Gegebenenfalls sind an der Programmierumgebung Änderungen vorzunehmen, um zum Beispiel [[OC Coding Style|einheitlich formatierten Code]] zu schreiben.

=== Einrichtung des PHP Coding Styles am Beispiel von phpStorm ===
Unter Settings / Code Style / PHP rechts auf “Set from…” klicken und “PSR-12” auswählen. Die Einstellung mit “Apply” bestätigen.
(Weitere Informationen zum Coding Style sind [[OC Coding Style|hier im Wiki]] zu finden.)

[[Image:Testumgebung IDE 01.png|500px]]

=== Symfony Pfade am Beispiel phpStorm anpassen ===
[[Image:Testumgebung IDE 04.jpeg]]

=== Terminalanpassung am Beispiel phpStorm (für Windows-Nutzer) ===
[[Image:Testumgebung IDE 05.png]]

=== hilfreiche Plugins für phpStorm ===
-

=== Synchronisieren/Wiederherstellen der Benutzereinstellungen mittels JetBrains-Server ===
Sofern man bei JetBrains einen Account hat, kann man mit diesem die Einstellungen der lokalen IDE synchronisieren und z.B. nach einer Neuinstallation von dort wiederherstellen.

Hierzu in der IDE rechts oben auf das Zahnrad klicken und “Settings Sync is off” auswählen.
[[Image:Testumgebung IDE 02.png]]

Im folgenden Fenster den Button “Enable Settings Sync” klicken und danach alle Einstellungen auswählen, die man sichern möchte. Ein Klick auf “Push Settings to Account” sichert die Einstellungen. Ein Klick auf “Get Settings from Account” stellt sie wieder her, sofern sie vorher dorthin gesichert wurden.
[[Image:Testumgebung IDE 03.png]]

== 6. Das Fehlerhandbuch lesen (gilt insbesondere für die Schritte #1-#4 :wink:) ==

Beireits bekannte Fehler werden im [[Entwicklungsumgebung/Fehlerhandbuch|Fehlerhandbuch]] beschrieben.

[[Kategorie:Entwicklung|Entwicklungsumgebung ]]

Entwicklung

2025-01-08T10:58:14Z

Fraggle: Datum ergänzt

''Diese Seite wendet sich vor allem an Technikinteressierte und verwendet daher eine Menge Fachbegriffe, deren Erläuterung hier zu weit führen würde. Sie sind daher mit Links zur Wikipedia hinterlegt.''
----

[[Datei:Codegenerationen.svg|thumb|[[Opencaching]]-Codehistorie (Stand Juni 2016)]]
Hinter der Opencaching-Website verbergen sich eine Menge Technik und Entwicklungsarbeit. Was im Jahr 2003 als ein kleines Bastelprojekt begann, wuchs im Laufe der Jahre zu einer der weltweit bedeutendesten [[Geocaching-Plattformen]] heran.

Die aktuelle Opencaching.de-Softwareversion 3.0 besteht aus rund 70.000 Zeilen an selbstgeschriebenem [[wikipedia:PHP|PHP]]-, [[wikipedia:Smarty|Smarty]]-, [[wikipedia:Hypertext Markup Language|HTML]]/[[wikipedia:Cascading Style Sheets|CSS]]-, [[wikipedia:JavaScript|Javascript]]- und [[wikipedia:MySQL|MySQL]]-Code. Hinzu kommen ca. 20.000 Zeilen für die [[OKAPI]] und weitere 200.000 Zeilen [[wikipedia:Programmbibliothek|Bibliothekscode]]. Die [[wikipedia:Datenbank|Datenbank]] umfasst ca. 125 Tabellen plus 15 für die OKAPI.

Der Opencaching-Quellcode steht unter einer [https://github.com/OpencachingDeutschland/oc-server3/blob/development/doc/GPL.txt modifizierten GNU-GPL-Lizenz] und ist [https://github.com/OpencachingDeutschland/oc-server3 frei verfügbar]. Erläuterungen dazu gibt es im Artikel [[Entwicklung/Codedoku]].
__NOTOC__
== Entwicklerteam ==
Mit der Gründung des [[Opencaching Deutschland e.V.]] ging die Weiterentwicklung auf ein neues Team über. Die aktiven Softwareentwickler sind in der [http://www.opencaching.de/articles.php?page=team Teamliste] aufgeführt. Neue engagierte Entwickler sind jederzeit willkommen! Wenn du im Team mitmachen möchtest, findest du weitere Informationen dazu im [http://forum.opencaching.de/index.php?board=33.0 Opencaching-Forum].

== Entwicklungsumgebung ==
[[Datei:Tux.png|thumb|hochkant=0.75]]
Stand 2016 steht für die Entwickler eine virtuelle Linux-Maschine als [[wikipedia:VirtualBox|VirtualBox]]-Image zur Verfügung, die wie die Opencaching.de-Website auf [[wikipedia:CentOS|CentOS]] basiert (→ [[Entwicklung/Entwicklersystem|Entwicklersystem]]). In dieser VM laufen ein [[wikipedia:Apache HTTP Server|Apache]]- und ein [[wikipedia:MySQL|MySQL]]-Server. Das eigentliche Programmieren und Testen findet auf dem Hostsystem unter Linux, Windows oder MacOS statt, mit einem beliebigen [[wikipedia:UTF-8|UTF-8]]-fähigen Editor bzw. einer PHP-[[wikipedia:Integrierte Entwicklungsumgebung|IDE]] und einem Webbrowser.

Zur Codeverwaltung und -versionierung wird [[wikipedia:Git|Git]] eingesetzt, mit einem üblichen Workflow (Stable-Branch, Entwicklungs-Branch, Test-Branch und Feature-Branches). Eine ausführliche Anleitung dazu gibt es [[Entwicklung/Git|hier im Wiki]].

Anstehenden Aufgaben werden in einer [[Entwicklung/Todo-Liste|Todo-Liste]] verwaltet.

Allgemeine Diskussionen finden im [http://forum.opencaching.de/index.php?board=43.0 offenen Entwicklerforum] statt. Im internen Team-Wiki gibt es Anleitungen zu Installation und Verwendung der Entwicklungsumgebung; diese sollen nach Neuaufsetzen der Entwicklungsumgebung hier ins allgemeine Wiki übertragen werden.

== Datenschnittstellen für Tool- und App-Entwickler ==
Über die [[Opencaching-API]] (OKAPI) oder die [[XML-Schnittstelle]] können alle Cache- und Logdaten frei heruntergeladen werden. Die OKAPI kann auch [[Das Onlinelog|Logs]] hochladen, sodass auch [[Smartphone-Apps für Opencaching.de|Smartphone-Apps]] mit [[Fachjargon#Field Logging|Field-Logging]]-Funktion realisierbar sind.

== Weitere Opencaching-Entwicklungsprojekte ==
* [https://github.com/opencaching/opencaching-pl Opencaching Polen]
* [https://github.com/opencaching/okapi Opencaching-API]

[[Kategorie:Entwicklung| ]]

Entwicklung/Entwicklersystem

2025-01-08T10:52:15Z

Fraggle: Datum ergänzt

[[Datei:Tux.png|thumb|hochkant=0.75]]
Das '''Entwicklersystem''' von Opencaching.de ist (Stand 2016) eine virtuelle [[wikipedia:CentOS|CentOS]]-Linux-Maschine für [[wikipedia:VirtualBox|VirtualBox]]. Hierauf laufen ein [[wikipedia:Apache HTTP Server|Apache]]- und ein [[wikipedia:MySQL|MySQL]]-Server. Das eigentliche Programmieren und Testen findet auf dem Hostsystem unter Linux, Windows oder MacOS statt, mit einem beliebigen [[wikipedia:UTF-8|UTF-8]]-fähigen Editor bzw. einer [http://forum.opencaching.de/index.php?topic=2150.0 PHP-IDE] und einem Webbrowser.

Das System, mit dem derzeit entwickelt wird, kann aufgrund der enthaltenen Cachedatenbank nicht veröffentlicht werden (sie enthält alte Listings, die auf opencaching.de aus rechtlichen Gründen nicht mehr sichtbar sind). Ein neues ist in Planung.

Wer Spaß daran hat, mit so einer Linux-Maschine rumzuspielen und an Opencaching.de mitzubauen, kann Mitglied im Team werden (mehr dazu im [http://forum.opencaching.de/index.php Forum]), sich die VM herunterladen und einrichten; dazu gibt es eine ausführliche Anleitung.

Eine Anleitung zur Installation eines lokalen Testservers (ohne Listing- und Benutzerdaten des Liveservers) ist [[Entwicklungsumgebung einrichten|hier]] zu finden bzw. etwas kürzer auf [https://github.com/OpencachingDeutschland/oc-server3 github].

Für Fragen und Diskussionen hierzu und zu verwandten Themen gibt es das [http://forum.opencaching.de/index.php?board=43.0 Entwicklerforum].

Für die Einrichtung einer Opencaching.pl-Website im OC.de-Entwicklersystem gibt es eine [[Entwicklung/Entwicklersystem PL|separate Anleitung]].

== Siehe auch ==
* [[Entwicklung|Opencaching.de-Entwicklung]]

[[Kategorie:Entwicklung|Entwicklersystem]]

Entwicklung/Git

2025-01-08T10:50:32Z

Fraggle: Git-Installatiion ist bereits auf einer anderen Seite beschrieben

== Versionsverwaltung der Entwicklungsdaten mit Git ==
Das Opencaching.de-Projekt verwendet [https://github.com/ Git] zur Verwaltung von Quellcode, Dokumentationen etc. Git ist leistungsfähiger und komplexer als klassische Versionsverwaltungstools wie CVS und Subversion. Es kann wesentlich besser mit Branches umgehen, also verschiedenen Codeversionen eines Projekts -- "branches (in Git) are cheap and easy". So kann man zu Testzwecken, zum Programmieren einzelner Features etc. eigene Zweige anlegen, die dann später wieder in den Haupt-Code (den ''Master-Branch'') einfließen oder wahlweise verworfen werden. Dieses Verzweigen und Wieder-Zusammenführen von Codeversionen ist erstaunlich einfach und zuverlässig. Richtig eingesetzt, erleichtert es das Projektmanagement.

Die Verwendung von Git setzt eine gewisse Lernkurve voraus. Diese Anleitung soll dir den Einstieg erleichtern und erklärt alles, was du für den Git-Einsatz bei Opencaching.de wissen musst (und Einiges mehr). Sie erklärt die Verwendung von Git anhand der Kommandozeilenversion, die für alle relevanten Betriebssysteme erhältlich ist. Daneben gibt es verschiedene komfortable Benutzeroberflächen. Gerne kannst du ein weiteres Kapitel für die von dir bevorzugte Git-UI hinzufügen!

Allgemeine Einführungen in Git findest du z.B. hier (Liste gerne ergänzen):
* https://rogerdudler.github.io/git-guide/index.de.html - Der einfache Einstieg (deutsch)
* https://docs.github.com/de - eine leichtverständliche Einführung
* https://www.stefanimhoff.de/git/ - Sammlung von einfachen und komplexeren Tutorials (englisch)

== Funktionsweise von Git und Einsatz bei Opencaching.de ==

Git arbeitet im Gegensatz zu Subversion ''dezentral''. Jeder Entwickler hat eine eigene Kopie - einen "Klon" - des Repositories, also der Datenbank in der sich alle Dateien des Projekts in allen Branches und Versionsständen befinden. Aus diesem Klon werden die Arbeitsdaten ausgecheckt, und Änderungen der Arbeitsdaten werden dort eingecheckt.

Die Entwickler können in beliebigen Topologien organisiert werden und gleichen den Inhalt ihrer Repositories wechselseitig miteinander ab. Opencaching.de verwendet eine Art Sternstruktur, mit einem Haupt-Repository unter der Adresse
* https://github.com/OpencachingDeutschland/oc-server3

Auf dieses Repo haben nur der Code Maintainer und seine Vertreter Schreibzugriff; alle anderen können nur lesen. Um auch Daten hochladen zu können, besitzt jeder Entwickler bei GitHub.com eine eigene Kopie - einen "Fork" - des Haupt-Repositories, z.B.
* https://github.com/flopp/oc-server3

Dein erster Schritt als Opencaching-Entwickler ist das Anlegen deines Forks. Dazu legst du dir auf [https://github.com GitHub] einen kostenlosen Account an, gehst auf https://github.com/OpencachingDeutschland/oc-server3 und klickst oben rechts auf "Fork".

Der zweite Schritt ist, dir eine lokale Kopie - einen "Klon" - deines Forks anzulegen. Wie du das im OC.de-Entwicklersystem machst, ist im Artikel [[Entwicklung/Entwicklersystem|Entwicklersystem]] beschrieben. Hier machen wir es einfach mal testweise - du kannst so viele Klone anlegen wie du möchtest, den GitHub-Repositories ist das egal:
git clone git@github.com:<DeinBenutzername>/oc-server3

Nun wird bei dir ein Verzeichnis <code>oc-server3/.git</code> angelegt, das zunächst eine 1:1-Kopie deines GitHub-Forks ist (der zunächst eine 1:1-Kopie des Opencaching-Deutschland-Repos ist), und von dort der komplette aktuelle OC.de-Code in Unterverzeichnisse von <code>oc-server3</code> ausgecheckt. In <code>oc-server3</code> befinden sich also sowohl deine Arbeitsdaten als auch der lokale Repository-Klon. <code>oc-server3/.git/config</code> ist die Konfigurationsdatei des lokalen Repositories, die du aber nur selten von Hand bearbeiten wirst.

Dein GitHub-Fork heißt in deinem lokalen Repository ''origin''; über diesen Name kannst du mit verschiedenen Git-Kommandos darauf zugreifen. Um die Konfiguration abzuschließen, muss zusätzlich noch der ''upstream'' definiert werden - das Repository, aus dem du neue Daten abrufst. Dies ist nicht dein eigener Fork, sondern du beziehst die Daten direkt von OpencachingDeutschland. Navigiere dazu ins Verzeichnis <code>oc-server3</code> und führe dann folgenden Befehl aus:

git remote add upstream git@github.com:OpencachingDeutschland/oc-server3

Mit <code>git remote -v</code> kannst du dir nun alle "remote"-Repositories anzeigen lassen, die in deinem Klon eingestellt sind.

== Installation ==

Die Installation und Einrichtung von Git ist im Artikel [[Entwicklungsumgebung einrichten#Github|Entwicklungsumgebung einrichten]] beschrieben.

== Datenfluss ==

Die folgende Grafik zeigt den Git-Datenfluss im Opencaching-Team am Beispiel von drei Entwicklern. Oben siehst du die "remote"-Repositories - das für alle Entwickler als "upstream" dienende Haupt-Repo und die drei "origin" genannten Forks -, und unten die drei lokalen Repositories und die Arbeitsdaten. Die grauen Pfeile zeigen, was du eben gemacht hast: 1. den Fork auf Github.com, und 2. das Erzeugen des lokalen Klons (nicht erschrecken lassen durch die vielen Details - das wird unten alles schrittweise erklärt):

[[Datei:Git-Workflow.png|800px]]

Die schwarzen Pfeile zeigen, wie ''ab sofort'' die Daten fließen werden: In umgekehrter Richtung! Du beziehst Daten vom ''upstream'', schiebst deine eigenen Änderungen in deinen ''origin'', und von dort übernimmt der Code Maintainer sie wiederum in den ''upstream''. Aus Sicht jedes Entwicklers fließen die Daten also zwischen drei Repositories im Kreis.

Links und in der Mitte ist der Standard-Git-Workflow zu sehen, rechts ein vereinfachter mit nur einem Branch.

== Daten bearbeiten und hochladen ==

Nach dem ersten Auschecken ist der ''development''-Branch aktiv. Dieser enthält den aktuellen Entwicklungsstand. Welcher Branch aktiv ist, siehst du mit
git branch
Unser Standard-Workflow sieht vor, dass '''nie im development gearbeitet wird'''. Stattdessen musst du dir - ausgehend von ''development'' - für jede Aufgabe einen Arbeitsbranch anlegen:
git checkout -b 1234-new-feature development
Die vorangestellte Nummer ist eine Ticketnummer aus der Todo-Liste. Wenn es keine passende gibt, lässt du sie weg. Verwende nach Möglichkeit englische Namen und Kommentare, denn das OC-Projekt ist international vernetzt. Nun kannst du mit <code>git branch</code> sehen, dass es in deinem lokalen Repo zwei Branches gibt, und der neu angelegte ist aktiv. Mit dem Kommando <code>git checkout Branchname</code> kannst du zwischen den Branches hin- und herwechseln; dabei wird jeweils der Code in den Arbeitsdaten entsprechend ausgetauscht.

Beim Anlegen des Branches sind wir davon ausgegangen, das unmittelbar zuvor der Klon angelegt wurde und die lokale development-Kopie aktuell ist. Wenn Letzteres evtl. nicht der Fall ist, solltest du sie vor dem Anlegen des neuen Branches aktualisieren:
git checkout development
git pull upstream
git checkout -b 1234-new-feature [development]

Nun ist es soweit: Du kannst deine ersten Änderungen am OC-Code vornehmen und hochladen! Zum Bearbeiten musst du einen UTF8-fähigen Editor verwenden. Dass er das ist, erkennst du an den zwei japanischen Sonderzeichen oben in jeder Quelltextdatei: Wenn dort zwei Fragezeichen, Klötzchen oder Ähnliches erscheinen, ist dein Editor falsch eingestellt oder ungeeignet. Zum Thema Editoren/IDEs siehe auch im Forum: "[http://forum.opencaching.de/index.php?topic=2150.0 Git-UI / PHP-IDE]"

Wenn du die Änderungen vorgenommen hast, zeigt dir
git status
in roter Farbe an, welche Dateien geändert oder hinzugefügt wurden, und
git diff
die Änderungen im Einzelnen. Falls dein Editor bzw. deine Entwicklungsumgebung irgendwelche zusätzlichen Dateien angelegt hat, kannst du diese in <code>.git/info/exclude</code> eintragen, damit sie nicht ins Repository gelangen.

Als nächstes musst du Git mitteilen, dass die Daten zum aktiven Branch hinzugefügt werden sollen; dies geschieht mit
git add .
für alle geänderten und neuen Dateien im aktuellen Verzeichnisbaum (falls du Branches gewechselt hast vergewissere dich evtl. mit <code>git branch</code>, dass du im richtigen bist!) Wahlweise kannst du einzelne Dateien per (Pfad+)Dateiname hinzufügen oder Wildcards verwenden. Dateien löschen kann man mit
git rm Dateiname
Nun zeigt <code>git status</code> in grüner Farbe alle vorbereiteten Änderungen an, und mit
git commit
checkst du sie in dein lokales Repository ein. Es öffent sich ein vi-Editor, in dem du einen Kommentar eingeben musst. Schreibe eine aussagekräftige, möglichst englische Zusammenfassung in die erste Zeile, und evtl. zusätzliche Erläuterungen in die weiteren Zeilen. Wenn es nur ein einzeiliger Kommentar sein soll, kannst du dir den Editor auch sparen und den Kommentar direkt angeben mit
git commit -m "Kommentar"
Wenn keine neuen Dateien hinzugefügt, sondern nur vorhandene geändert werden sollen, kannst du auch das <code>add</code> mit einbauen, also alle geänderten Daten mit nur einem Befehl einchecken:
git commit -am "Kommentar"
Mit
git log
siehst du nun, dass ein neuer ''commit'' in die Versionsgeschichte des aktiven Branches eingefügt wurde. Wahlweise kannst du auch mit <code>git log --stat</code> nochmals alle geänderten Dateien anzeigen lassen.

Um den Commit später mit einem Ticket in der [[Entwicklung/Todo-Liste|Jira]] zu verknüpfen, kannst du im Kommentar die Ticket Nummer (inklusive Projekt Kürzel) angeben. Aktuell übernimmt es das jedoch nur für Pull Requests. Dort sollte die Ticket Nummer am Anfang stehen.

==== Exkurs: Commits ====

Commits sind das Hauptelement der Arbeit mit Git. Jeder Branch ist eine bestimmte Abfolge von Commits. Verschiedene Branches unterscheiden sich dadurch, welche Commits sie enthalten. Ein Commit ist ein Patch, der eine oder mehrere Dateien verändert, hinzufügt und/oder löscht. Jeder Commit hat einen eindeutigen Hashcode, der im Log angezeigt wird. Über diesen Code lassen sich Commits einzeln herauspicken, rückgängig machen, als Diff anzeigen etc. Dabei genügt die Angabe der ersten paar Zeichen, sofern sie eindeutig sind; üblich als Kurzform sind die ersten 7-10 Zeichen.

Der letzte (neueste) Commit des aktiven Branches hat auch den Name HEAD, der vorletzte HEAD~1, der drittletzte HEAD~2 etc. Mit
git diff HEAD~1
kannst du dir z.B. alle Änderungen zwischen aktuellem und vorletztem Codestand anzeigen lassen - also genau das, was du mit deinem letzten <code>commit</code> eingecheckt hast.

==== Rebase auf aktuellen Codestand ====

Grundsätzlich solltest du Daten erst dann hochladen, wenn sie verwendbar sind und in das Haupt-Repository oder an einen anderen Entwickler weitergegeben werden sollen. Unfertiges bleibt zunächst nur lokal bei dir liegen. Wir tun jetzt einfach mal so, als sei deine Codeänderung fertig (du kannst den Upload danach wieder löschen, wenn es nur ein Test war).

Zunächst solltest du deine Daten nochmal auf den aktuellen Stand bringen. Damit ist sichergestellt, dass deine Änderungen mit dem aktuellsten OC-Code funktionieren:
git fetch upstream
git rebase upstream/development

Das erste Kommando aktualisiert deine lokale Kopie der Upstream-Branches (die du mit <code>git branch -r</code> auflisten kannst), bzw. legt diese erstmalig an. Das zweite übernimmt alle neuen ''commits'' aus dem Upstream - also dem OC-Hauptrepository - in deinen aktiven Branch, und zwar fügt es sie ''vor'' deine eigenen Änderungen ein! Deine Änderungen werden auf Basis des aktuellen OC-Codestandes neu aufgesetzt (re-based), d.h. sie werden als Patch auf diesen Codestand angewandt. Beide Kommandos lassen sich auch zu einem zusammenfassen:
git pull --rebase upstream development

'''Verwende niemals ein einfaches <code>git pull</code> (ohne <code>--rebase</code>) in einem Arbeitsbranch!''' Es würde die Versionsgeschichte unlesbar machen und das Zurückverfolgen von Codeänderungen verhindern.

Beim <code>rebase</code> können "Merge-Konflikte" enstehen, wenn deine Codeänderungen nicht automatisch auf dem aktuellen Codestand aufgesetzt werden können, z.B. weil es mehrere Änderungen in der gleichen Codezeile gab. Git zeigt dann eine Fehlermeldung an, und die Konflikte sind in im Quelltext markiert (suche nach "===="). Korrigiere den Code, markiere die geänderte Datei erneut mit git add zum Hinzufügen, und gib <code>git rebase --continue</code> ein, um das Rebase abzuschließen.

==== Daten hochladen ====

Nun kannst du deinen neuen Branch mit
<code>git push origin 1234-new-feature</code>
in deinen Fork hochladen. Wenn du auf [http://github.com/ http://github.com/<DeinUsername>/oc-server3] links die Branch-Dropdown-Box aufklappst, oder weiter rechts auf "branches" klickst, sollte dort der neue Branch auftauchen (manchmal mit etwas Verzögerung). Wenn du oben auf "Network" klickst, siehst du wie dein neuer Branch vom development abzweigt. Jeder Punkt in diesem Diagramm steht für einen ''commit''.

Wenn dein Branch fertig ist und in den development übernommen werden soll, wählst du ihn aus der Branches-Liste aus und klickst oben auf "Pull Request"; hier kannst du noch einen zusätzlichen Kommentar angeben. Der Code Maintainer wird per E-Mail informiert und wird deinen Code prüfen und ggf. übernehmen.

In diesem Fall war es wahrscheinlich nur ein Test, daher kannst du den Branch nun mit
git push origin :1234-new-feature
wieder aus deinem Fork löschen. Wenn du ihn auch lokal wieder löschen willst, geht das mit
git checkout development
git branch -D 1234-new-feature

Das große <code>-D</code> ermöglicht es, einen Branch zu verwerfen, der nicht weiterverwendet wurde. Wenn du stattdessen <code>-d</code> angibst, sind nur Branches löschbar die bereits in einen anderen Branch (z.B. den development) übernommen wurden, wo durch die Löschung also keine Daten verloren gehen können. '''Im Zweifelsfall verwende immer -d'''; dabei kann nichts versehentlich verloren gehen.

==== Zusammenfassung des OC-Git-Standard-Workflow ====

* Neuen Branch für eine neue Aufgabe anlegen
*# <code>git checkout development</code>
*# <code>git pull upstream</code>
*# <code>git checkout -b 1234-new-feature</code>
*: ... oder die Arbeit an einem bereits bestehenden Branch mit <code>git checkout 1234-new-feature</code> fortsetzen
* Programmierzyklen
*# Code schreiben
*# mit <code>git status</code> / <code>git diff</code> lokale Änderungen kontrollieren
*# Änderung mit <code>git add</code> / <code>git commit</code> ins lokale Repo einchecken
*# mit <code>git pull --rebase upstream development</code> auf aktuellen OC-Code aufsetzen
*# weiter bei 1, wenn der Code noch nicht fertig ist
* Hochladen
*# <code>git push origin 1234-neues-Feature</code>
*# ''Branch 1234-neues-Feature'' auf GitHub aufrufen und Pull Request starten
* Nicht mehr benötigte Branches löschen
*# lokal: <code>git checkout development</code> / <code>git branch -d 1234-neues-Feature</code>
*# auf dem Fork: <code>git push origin :1234-neues-Feature</code>

==== Commits zusammenfassen ====

Wenn in Schritt 4-8 mehrere Einzelcommits entstehen, kannst du sie vor dem Hochladen zur besseren Übersicht zu einem zusammenfassen. Prüfe mit <code>git log</code> nach, wieviele Commits zusammenzufassen sind - sie sollten noch nicht hochgeladen sein! - und gib ein:
git rebase -i HEAD~n
... wobei n die Zahl der Commits ist. Nun erscheint ein Editorfenster mit einem "pick" je Commit. Ersetze alle "picks" ab dem zweiten durch "squash" oder "s", was bedeutet, dass sie mit dem Commit davor zusammenzufassen sind. Nach dem Speichern erscheint ein zweiter Text im Editor, in dem du auch die Commit-Kommentare zusammenfassen kannst.

Wenn du dir '''ganz sicher''' bist, dass ein bereits hochgeladener Commit noch nicht weiterverwendet wurde - z.B. wenn du ihn eben erst hochgeladen und noch keinen Pull Request gemacht hast - kannst du ihn auch noch nachträglich mit neuen Commits zusammenfassen. Dies funktioniert wie oben beschrieben, allerdings musst du beim anschließenden <code>push</code> zusätzlich <code>--force</code> angeben, um den/die alten Commit(s) in deinem Fork zu überschreiben.

== Aktuelle Daten holen; mehrere Änderungen testen ==

Wenn du selbst gerade nichts programmieren willst, sondern dir einfach nur ein Update vom OC-Server holen und anschauen, machst du
git checkout development
git pull upstream
Wenn du mehrere Branches mit eigenen Änderungen angelegt hast, und diese alle im Zusammenhang testen möchtest, kannst du dir dafür einen Testbranch anlegen:
git checkout -b test development
git merge 1234-new-feature
git merge 2345-my-bugfix
...

== Änderungen verwerfen ==

* alle geänderten Dateien: <code>git reset --hard</code>
* alles geänderten Dateien im aktuellen Verzeichnisbaum: <code>git checkout .</code>
* alle neuen, noch nicht hinzugefügten Dateien: <code>git clean -f -d</code>
* nur eine bestimmte Datei: <code>git checkout Dateiname</code>

... die bereits "commitet", aber noch nicht "gepusht" sind:
* <code>git reset --hard HEAD~n</code>

... wobei n die Zahl der zu verwerfenden Commits ist. Wenn die Änderungen bereits "gepusht" wurden:
* mit <code>git log</code> die rückgängig zu machende Commit-ID raussuchen
* <code>git revert commit-ID</code>
* <code>git push</code>
* evt. Pull-Request auf dem GitHub, wenn es bereits im Upstream angekommen war

Den Kommentar des letzten, noch nicht "gepushten" Commit korrigieren:
* <code>git commit --amend</code>

== Daten direkt von anderen Entwicklern holen ==

Wenn du z.B. den Branch ''1234-new-feature'' von Entwickler ''heinz'' testen möchtest, kannst du ihn in einen Testbranch bei dir herunterladen. Zunächst musst du ''heinz''' Fork einmalig als weitere Upstream definieren:
git remote add heinz git@github.com:heinz/oc-server3
Dann legst du bei dir einen Testbranch an, am besten auf Basis aktuellster Daten ...
git checkout development
git pull upstream
git checkout -b tolles-heinz-feature
... und mergst seinen Feature-Branch in deinen Testbranch:
git pull heinz 1234-new-feature

== Der stable-Branch ==

Neben dem development gibt es im OC-Repository einen Branch "stable". Dieser enthält immer den gleichen Stand wie das Produktivsystem www.opencaching.de. Neue Features werden im development entwickelt und getestet und später über den Stable-Branch freigegeben.

Mit dem Stable-Branch wirst du nur dann zu tun haben, wenn du einen "Hotfix" schreibst - eine dringende Korrektur, die sofort freigegeben werden soll. Diese setzt du auf dem Stable statt dem development auf; der übrige Workflow ist der gleiche wie oben beschrieben.

== Vereinfachter Workflow ==

Der oben beschriebene Workflow ist Pflicht für alle Entwickler, die Code zu OC.de beitragen. Wer nur hin und wieder mal eine Grafik oder einen Text beisteuert, kann ausnahmsweise auch ohne separate Branches arbeiten. In diesem Fall ist ein '''einfaches <code>git pull</code> im development-Branch verboten'''! Stattdessen muss überall, wo oben <code>git pull upstream</code> steht, stattdessen
<code>git pull --rebase upstream development</code>
verwendet werden! Der vereinfachte Ablauf ist dann:

1. Code schreiben 
2. mit <code>git status</code> / <code>git diff</code> lokale Änderungen kontrollieren 
3. Änderung mit <code>git add</code> / <code>git commit</code> ins lokale Repo einchecken 
4. mit <code>git pull --rebase upstream development</code> auf aktuellen OC-Code aufsetzen 
5. weiter bei 1, wenn der Code noch nicht fertig ist 
6. <code>git push origin</code> 
7. Pull-Request

== Noch ein paar Gimmicks ==

* <code>git branch -m 1234-neuestes-Feature</code> Benennt den derzeit aktiven Branch um in "1234-neuestes-Feature".
* <code>git diff Branchname</code> zeigt alle Unterschiede zwischen dem aktuellen Branch und einem anderen an.
* <code>git cherry-pick Commit-ID</code> übernimmt einen bestimmten Commit (von wo auch immer) in den aktiven Branch.
* <code>git diff --name-only --diff-filter=U</code> zeigt eine Liste aller konfliktbehafteten Dateien nach einem Merge an
* <code>git gc</code> führt eine [http://de.wikipedia.org/wiki/Garbage_Collection Garbage Collection] durch und gibt Platz im lokalen Repository frei. Per <code>git reset --hard</code> oder <code>git branch -d</code> gelöschte Commits werden damit endgültig weggeworfen (vorher sind sie via <code>git reflog</code> noch wiederherstellbar).
* <code>git grep Suchbegriff</code> durchsucht den Code des aktuellen Verzeichnisbaums; für zahlreiche Optionen siehe Git-Doku.
* <code>git help Kommando</code> zeigt die Doku für ein Git-Kommando an.

== Forenbeiträge zu Git ==
* [http://forum.opencaching.de/index.php?topic=2125.0 Git-Workflow]

[[Kategorie:Entwicklung|Git]]

Opencaching

2024-06-12T07:13:17Z

Fraggle: Update URLs

[[Datei:Logo-oc.jpg|thumb|Das internationale Opencaching-Logo]]
'''Opencaching''' (kurz: '''OC''') ist der Name mehrerer [[Geocaching]]-Plattformen. Die Bezeichnung „Open“ drückt aus, dass alle Inhalte und der Programmcode offen und ohne Bezahlung für jeden verfügbar sind.

Im August 2005 ging die Seite [[Opencaching.de]] online. In den nachfolgenden Jahren entstanden weitere Opencaching-Seiten in anderen Ländern; in Reihenfolge ihrer Entstehung:
* [http://www.opencaching.cz Tschechien]
* [http://www.opencaching.pl Polen]
* [http://www.opencaching.se Schweden] (eingestellt)
* [http://www.opencaching.uk Großbritannien]
* Norwegen (eingestellt)
* [http://www.opencaching.us USA]
* [http://web.archive.org/web/20110722120420/http://www.opencaching.jp/ Japan] (eingestellt)
* Russland (eingestellt)
* [http://www.opencaching.nl Niederlande]
* Lettland (nicht gestartet)
Mit unbekanntem Startdatum:
* [http://www.opencaching.se Spanien] (leitet zu Opencaching.de weiter)

Das Projekt '''Opencaching-Netzwerk''' sah ursprünglich vor, alle Opencaching-Seiten zu vernetzen, so dass alle Caches auf allen Länderseiten verfügbar und logbar sind. Daher werden die Einzelseiten auch als „Knoten“ bezeichnet. Da sich die unterschiedlichen Länderknoten aber in der Vergangenheit technisch weit auseinander entwickelt haben, wurde dieses Netzwerk so leider nie realisiert und es findet aktuell kein Datenaustausch zwischen den OC-Seiten statt.

Die [http://www.opencaching.es/ spanische] und [http://www.opencaching.it/ italienische] Opencaching-Seite sind keine eigenständigen Länderknoten, sondern leiten zu Opencaching.de (mit entsprechender Übersetzung) weiter.

[[Kategorie:Opencaching| ]]

Entwicklung/Implementierungstatus der Supportfunktionen

2024-05-13T19:57:37Z

Fraggle: Erstentwurf

{| class="wikitable" style="margin:auto"
|+ Text der Überschrift
|-
! Funktion !! Kurzbeschreibung !! Status !! Rolle !! Rolle implementiert

|-
| [https://opencaching.atlassian.net/wiki/spaces/DEV/pages/1739423772 ReportedCaches]
||
* Auflistung aller Caches, die gemeldet wurden
* Meldungen können zugewiesen und abgearbeitet werden
* Owner können kontaktiert werden
||
* OK
* OK
* nicht impl.
||
* ROLE_SUPPORT_TRAINEE
* ROLE_SUPPORT_TRAINEE
* ROLE_SUPPORT_TRAINEE
||
* OK
* OK
* nicht impl.

|-
| [https://opencaching.atlassian.net/wiki/spaces/DEV/pages/1739489317 Cache history]
||
* Zeigt Statusänderungen zu einem Listing (Loglöschungen, Koordinatenänderungen, ..)
||
* OK
||
* ROLE_SUPPORT_TRAINEE
||
* OK

|-
| [https://opencaching.atlassian.net/wiki/spaces/DEV/pages/1739620370 Manage User]
||
* Zeigt Details zu einem Nutzeraccount
* Account samt Caches deaktivieren
* DSGVO-Löschung des Accounts
* Emailadresse als ungültig markieren
* Emailadresse eines Nutzers neu setzen (falls vergessen..)
* Account für eine bestimmte Zeitspanne deaktivieren und wieder reaktivieren
* Loginsperre für eine bestimmte Zeit erteilen
||
* OK
* nicht impl.
* nicht impl.
* OK
* nicht impl.
* OK
* OK
||
* ROLE_SUPPORT_TRAINEE
* ROLE_SUPPORT_MAINTAIN
* ROLE_SUPPORT_MAINTAIN
* ROLE_SUPPORT_MAINTAIN
* ROLE_SUPPORT_MAINTAIN (höher?)
* ROLE_SUPPORT_MAINTAIN
* ROLE_SUPPORT_MAINTAIN
||
* OK
* nicht impl.
* nicht impl.
* OK
* nicht impl.
* OK
* OK

|-
| [https://opencaching.atlassian.net/wiki/spaces/DEV/pages/1739587596 Vandalismus]
||
* Wiederherstellung vandalisierter Listings
* Wiederherstellung vandalisierter Logs
* Wiederherstellung vandalisierter Bilder (siehe [https://opencaching.atlassian.net/browse/OCC-166 OCC-166])
||
* OK
* OK
* nicht impl.
||
* ROLE_SUPPORT_MAINTAIN
* ROLE_SUPPORT_MAINTAIN
* ROLE_SUPPORT_MAINTAIN
||
* OK
* OK
* nicht impl.

|-
| [https://opencaching.atlassian.net/wiki/spaces/DEV/pages/1739489393 occ Ersatz]
||
* Verbindung zwischen OC- und GC-Listing und -Ownern sichtbar machen
** Verknüpfung eines Owners zu anderen Nodes/Plattformen
** Verknüpfung eines Listings zu anderen Nodes/Plattformen
** grundlegende Listinginformationen anderer Nodes speichern (um nicht erfolgte Veränderungen im OC-Listing besser zu verfolgen)
** Import von GPX-Daten anderer Nodes, um Abgleiche zu automatisieren
* (Support-)Kommentare zu Owner und Listing hinterlassen
* Markierung von OC-Listings als Bonuscache bzw. zu Bonus gehörend
||
* OK
** OK
** OK
** OK
** OK
* OK
* OK
||
* ROLE_SUPPORT_MAINTAIN
** ROLE_SUPPORT_MAINTAIN
** ROLE_SUPPORT_MAINTAIN
** ROLE_SUPPORT_MAINTAIN
** ROLE_SUPPORT_MAINTAIN
* ROLE_SUPPORT_MAINTAIN
* ROLE_SUPPORT_MAINTAIN
||
* OK
** OK
** OK
** OK
** OK
* OK
* OK

|-
| [https://opencaching.atlassian.net/wiki/spaces/DEV/pages/1750597633 Datenbankabfragen]
||
* Ausführung vorgefertigter Datenbankabfragen
* Ausführung freier Datenbankabfragen
||
* OK
* OK
||
* ROLE_SUPPORT_TRAINEE bis ROLE_SUPPORT_MAINTAIN (hängt ggf. von der jeweiligen DB-Abfrage ab)
* ROLE_SUPPORT_MAINTAIN
||
* OK
* OK

|-
| Beförderung/Degradierung
||
* Ändern eines ROLE_TEAM zu ROLE_SUPPORT_*
* Ändern der ROLLEN innerhalb ROLE_SUPPORT_*
||
* OK
* OK
||
* ROLE_SUPPORT_HEAD
* ROLE_SUPPORT_HEAD
||
* OK
* OK

|-
| Listingstatus ändern
||
* Deaktivieren/Verstecken/Archivieren von Listings
||
* nicht impl.
||
* ROLE_SUPPORT
||
* nicht impl.

|-
| [https://opencaching.atlassian.net/wiki/spaces/DEV/pages/1743552556 Veraltete Listings finden]
||
* GC-Wegpunkte (deaktiviert bzw. archiviert) mit der Datenbank abgleichen und die OC-Listings in einer Liste darstellen
||
* nicht impl.
||
* ROLE_SUPPORT
||
* nicht impl.

|-
| [https://opencaching.atlassian.net/wiki/spaces/DEV/pages/1743552556 Listingqualität]
||
* Listings von "Newbies" (= wenige Tage vor der Veröffentlichung erst angemeldet) auflisten, damit man sich diese genauer ansehen kann
* Vorlage von Listings, deren Besitzer länger als ein Jahr nicht mehr eingeloggt war und die einen DNF bzw. Hinweislog erhalten
||
* OK
: (siehe "DB-Abfragen")
* OK
||
* ROLE_SUPPORT_TRAINEE
* ROLE_SUPPORT_TRAINEE
||
* OK
* OK

|-
| Logs löschen
||
* unangebrachte Logs in Listings löschen
||
* nicht impl.
||
* ROLE_SUPPORT
||
* nicht impl.

|-
| Logs löschen sperren
||
* Löschen von Logs durch Owner sperren
||
* nicht impl.
||
* ROLE_SUPPORT
||
* nicht impl.
|-
|-
|-
|-
|-

|}

[[Kategorie:Entwicklung]]

Role hierarchy

2024-05-13T19:31:57Z

Fraggle: Änderung 7897 von Fraggle (Diskussion) rückgängig gemacht.

The fundament of our security is a customizable role hierarchy. One or multiple roles can be applied to a user. Every role itself is linked to different permissions which allow to view, edit or delete resources like geocaches, logs or users. If no permission is present it defaults to disallowing the action.

== Role hierarchy ==
https://app.conceptboard.com/board/9qra-r8bs-bpy2-cuf2-0ikx

[[Image:Testumgebung Rollen 01.png|500px]]

This diagram must be read bottom to top. Every role inherits roles above them. Example: ROLE_SOCIAL_HEAD contains ROLE_SOCIAL, ROLE_SOCIAL_TRAINEE, ROLE_TEAM and ROLE_USER. Every logged in user has ROLE_USER.

== Permissions ==
Permissions are linked to different roles which can be seen as a permission group.

== Database ==
<gallery>
Image:Testumgebung Rollen 02.png|table security_roles|alt=table security_roles
Image:Testumgebung Rollen 03.png|table security_roles_hierarchy|alt=table security_roles_hierarchy
Image:Testumgebung Rollen 04.png|example for table user_roles|alt=example for table user_roles
</gallery>

== Code examples ==
Annotations, to secure complete functions or classes:
<nowiki>/**
* @Security("is_granted('ROLE_SOCIAL')")
*/</nowiki>

PHP, to secure parts of the code:
<nowiki>if ($this->isGranted('ROLE_SOCIAL')) {
..
}</nowiki>

Twig, to secure parts of the code from being displayed or executed.
But pay attention: as long as the @routes are not secured (see above) they still can be called via URL!
<nowiki>
{% if is_granted('ROLE_SOCIAL') %}
{{ 'You have access.' }}
{% else %}
{{ 'Sorry. You don\'t have access.' }}
{% endif %}</nowiki>

[[Kategorie:Entwicklung]]
[[Kategorie:English pages]]

Role hierarchy

2024-05-13T19:31:27Z

Fraggle: Kategorie bearbeitet

Cachekarte

2024-05-13T19:19:27Z

Fraggle: Kategorie bearbeitet

{{Überarbeiten|Abschnitt "Kartenarten" scheint veraltet}}

[[Datei:Cachekarte groß.png|300px|thumb|rechts|Kartenausschnitt Heidelberg/Mannheim]]

Die '''[http://www.opencaching.de/map2.php Cachekarte]''' ist neben dem [[Suchformular]] die zweite Möglichkeit, um auf Opencaching nach interessanten Caches zu stöbern. In der Grundeinstellung zeigt sie alle aktiven Caches (Status: [[Cachestatus#Kann_gesucht_werden|kann gesucht werden]]) in Kartenausschnitt an, ausgenommen [[Caches ignorieren|ignorierte Caches]].

== Zielgebiet wählen ==
Der Kartenausschnitt kann durch Klicken und Ziehen mit der Maus oder mit den Pfeiltasten verschoben werden. Rein- und rausgezoomt wird mit dem Mausrad, durch Klick auf die Plus/Minus-Symbole unten rechts oder mit den Plus/Minus-Tasten. Durch Drücken der Umschalttaste und „Aufziehen“ mit der Maus kann man auch direkt einen bestimmten Ausschnitt vergrößern.

In der Suchleiste über der Karte kannst du einen Ortsnamen eingeben, einen Teil der gesuchten Cachenamen oder – falls bekannt – einen [[Wegpunkte#Wegpunkt eines Listings|OC-Wegpunkt]]. Es erscheint eine Auswahl der passenden Orte und Caches und von dort geht es weiter zum entsprechenden Kartenausschnitt.

[[Datei:Cachekarte Cacheauswahl.png|miniatur|200px]]

== Cache anzeigen ==
Mit einem Klick auf ein Cachesymbol öffnet sich ein kleines Fenster mit den wichtigsten Informationen zum Cache. Von dort gelangst du per Klick auf den Cachenamen weiter zur [[Cachebeschreibung (Listing)|Cachebeschreibung]].

Falls der Cache [[Wegpunkte#Interne, zusätzliche Wegpunkte|zusätzliche Wegpunkte]] besitzt, erscheinen diese gleichzeitig mit den Cacheinfo-Fenster auf der Karte. Sie bleiben auch nach Schließen des Fensters sichtbar, solange kein anderer Cache ausgewählt wird. Auch die Wegpunkte sind anklickbar, um zusätzliche Informationen zu erhalten.

Außerdem wird – falls vorhanden – das [[Bilder#Kartenvorschaubilder| Kartenvorschaubild]] des Caches angezeigt. Für jeden deiner Caches kannst du ein Vorschaubild festlegen, das in der Kartenansicht erscheint.

[[Datei:Cachekarte Attributwahl aufgeklappt.png|miniatur|links|300px]]

== Cacheauswahl einschränken ==
Nach einem Klick auf den Pfeil oben rechts öffnet sich ein Fenster mit Filtereinstellungen. Hier kannst du wählen, welche [[Cachearten]], [[Behältergrößen]], [[Schwierigkeitswertung|Schwierigkeitsgrade]] etc. dich interessieren. Es erscheinen dann nur noch solche Caches auf der Karte, die dieser Auswahl entsprechen. Auch nach Namensbestandteilen wie z. B. „Nacht“ oder „Wald“ kann gefiltert werden.

Tipp: Wenn du das Fenster schließt – dazu genügt ein Klick irgendwo auf die Karte – wird die Auswahl sofort übernommen. Ansonsten dauert es zwei Sekunden, um zu verhindern dass beim Ändern mehrerer Einstellungen jedesmal Daten von Opencaching.de abgerufen werden.

Die Filtereinstellungen bleiben so lange aktiv, bis du sie mit dem „Zurücksetzen“-Knopf verwirfst oder den Webbrowser beendest. Danach erscheinen wieder alle aktiven Caches auf der Karte. Wahlweise kannst du die Einstellungen auch mit dem „Speichern“-Knopf dauerhaft speichern. Dann erscheint nach dem Neustart des Browsers oder nach dem Zurücksetzen wieder die von dir gespeicherte Cacheauswahl.

== Kartenfunktionen ==
Neben dem Suchfeld oberhalb der Karte sind zusätzlich folgende Funktionen abrufbar:

{|
|style="vertical-align:top"|[[Datei:Cachekarte-Haus.png]]
|springt zu deinen Heimatkoordinaten. Dies funktioniert nur, wenn du [[Login|angemeldet]] bist und die Koordinaten in deinem [[Benutzerprofil]] hinterlegt hast.
|-
|style="vertical-align:top"|[[Datei:Cachekarte-GPX.png]]
|lädt die Daten der Caches im aktuellen Kartenausschnitt als Zip-gepackte [[GPX-Datei]] herunter. Dazu dürfen maximal 500 Caches sichtbar sein; verkleinere ggf. den Kartenausschnitt.
|-
|style="vertical-align:top"|[[Datei:Cachekarte-Stern.png]]
|erzeugt einen Link auf den aktuellen Kartenausschnitt, den du z. B. kopieren und bei den Lesezeichen / Favoriten deines Webbrowsers speichern oder per Email verschicken kannst. Bei Firefox und dem Internet Explorer lässt er sich auch direkt in die Lesezeichen übernehmen.
|-
|style="vertical-align:top"|[[Datei:Cachekarte-Einstellungen.png]]
|öffnet ein Fenster, indem du verschiedene Karteneigenschaften festlegen kannst:
* ob der Menüpunkt „Karte“ die Vollbild- oder die kleinere Karte (s.u.) aufruft;
* ob in der rechten unteren Ecke der Karte eine kleine Übersichtskarte erscheinen soll;
* wieviele Caches maximal auf der Karte angezeigt werden; wenn du 0 angibst, sind es maximal 2500 auf der großen und 1600 auf der kleinen Karte, bzw. max. 200 bei Verwendung des Microsoft Internet Explorers;
* ob auf der Karte die üblichen Opencaching.de-Symbole erscheinen sollen, oder die kleineren und moderneren von [http://www.opencaching.pl Opencaching Polen];
* ob und in welcher Größe [[Bilder#Kartenvorschaubilder|Vorschaubilder]] auf der Karte dargestellt werden sollen.
|-
|style="vertical-align:top"|[[Datei:Cachekarte-verkleinern.png]]
|wechselt von der Vollbildkarte zu einer kleineren Darstellung. Dort ist die übliche Menüleiste sichtbar, die Filtereinstellungen befinden sich unterhalb der Karte, und links gibt es eine Direktauswahl der Bundeshauptstädte.
|-
|style="vertical-align:top"|[[Datei:Cachekarte-vergrößern.png]]
|wechselt von der kleinen Karte zurück zur großen.
|}

== Kartenarten ==
In der rechten oberen Ecke der Karte wird das Kartenmaterial gewählt:

;OSM
Die Karte des freien [[OpenStreetMap]]-Projekts. Diese ist oft aktueller als die „kommerziellen“ Karten und enthält zusätzliche Details.

;MapQuest (MQ)
Eine andere Aufbereitung des OpenStreetMap-Materials. Die Karte ist übersichtlicher, durch dezentere Farbwahl und weil sie Details erst bei größerer Zoomstufe anzeigt oder teilweise ganz darauf verzichtet.

;OpenCycleMap (OCM)
Eine Fahrradkarte, die ebenfalls auf OpenStreetMap-Karte basiert und auf ähnliche Weise in einem offenen und freien Projekt zusammengetragen wird.

;Karte
Die Google-Straßenkarte, wahlweise umschaltbar auf Geländeansicht. Die Google-Karten sind sehr genau und enthalten zusätzliche Informationen über interessante Orte.

;Satellit
Die Google-Satellitenkarte, mit zu- oder abschaltbaren Straßen und Beschriftungen.

== Wegpunkte eines einzelnen Caches anzeigen ==
Manchmal sind die zusätzlichen Wegpunkte eines Caches auf einer vollen Karte schwer auszumachen. Hier hilft folgender Trick:

* Rufe das Cachelisting auf,
* klicke rechts unter der kleinen Karte auf „Opencaching.de“,
* öffne die Filtereinstellungen der Karte und schalte alle Caches mit einem Klick auf das Kästchen neben „Cacheart“ ab,
* schließe die Filtereinstellungen und drücke den Neuladen-Knopf deines Browsers.

Nun sind nur noch die Wegpunkte des einen Caches sichtbar.

== Vollbildkarte verlassen ==
Es gibt mehrere Wege, um von der Vollbildkarte „zurück“ ins Menüsystem oder auf andere Seiten zu gelangen:

* Mit einem Klick auf das Opencaching-Logo oben links gelangst du auf die Startseite,
* mit einem Klick auf den Benutzername oben links – falls du angemeldet bist – auf deine Profilseite,
* mit einem Klick auf einen Cachename, nachdem du dessen Info-Fenster geöffnet hast, in die Cachebeschreibung, oder
* mit einem Klick auf das Verkleinern-Symbol in die kleine Kartenansicht, wo alles Weitere über das Menü wählbar ist.

[[Kategorie:Opencaching]]
[[Kategorie:Geografie und Koordinaten]]
[[Kategorie:Überarbeiten]]

GeoGames

2024-05-13T19:18:40Z

Fraggle: Kategorie bearbeitet

{{Überarbeiten|Weblinks sind nicht mehr alle erreichbar}}

Die „Olympiade für Geocacher“ fand vom 29. Juni bis zum 1. Juli in Leipzig auf dem Messegelände statt. Insgesamt befanden sich 28 Aussteller auf dem 637 Quadratmeter großen Gelände. 4500 Geocacher aus 14 Nationen haben das Gelände besucht und sich in Wettkämpfen duelliert.

== Wettkämpfe ==

Insgesamt fanden dreizehn geolympische Disziplinen statt: Wathosenlauf, Orientierungslauf, Field Puzzle, Dosenstapeln, Dosenlauf, Petlingdarts, Dosenfischen, B-Schlauch-Wettbewerb, Nussknacker, Geocacher Tastsinn, Paddelcachen, Cacherbingo, Petling-Weitwurf.

== Programm der GC32012 ==
29.06.2012 Eröffungsveranstaltung

30.06.2012 ab 8:00 Uhr Frühstück

Workshops Fotografie, T5-Klettern, GSAK, Elektronik, OSM für Cacher, Dok-Film "Lost Place L.E."

Ab 19:00 Uhr Das Dosenfischerkonzert

Ab ca. 21:30 Uhr Musik aus der (Blech-)Dose

01.07.2012 Cleanup-and-Farwell-Party

== Weblinks ==
* [http://www.project-geogames.de/content/Static.aspx?name=Home Project-Geogames]
* [http://de.wikipedia.org/wiki/Geogames Wikipedia: GeoGames]
* [http://www.lvz-online.de/leipzig/citynews/geocaching-games-in-leipzig-3500-teilnehmer-aus-14-laendern-werden-erwartet/r-citynews-a-143640.html Schatzsuche in Leipzig: Geocaching-Games erwarten 3500 Teilnehmer aus 14 Ländern] LVZ-Online. 27.06.2012 Abgerufen am 10.12.2012
* [http://www.dnn-online.de/web/dnn/nachrichten/detail/-/specific/ueber-4000-Schatzsucher-sind-bei-Geocaching-Games-in-Leipzig-unterwegs-2386608529 Rund 4500 Schatzsucher bei Geocaching-Games in Leipzig] DNN-Online. 27.06.2012 Abgerufen am 10.12.2012

[[Kategorie:Geocaching]]
[[Kategorie:Überarbeiten]]

Warum diese Funktion nicht vorhanden ist

2024-05-13T19:17:29Z

Fraggle: Kategorie bearbeitet

{{Überarbeiten|Veraltete Forumlinks aktualisieren}}

Manche Funktionen sind auf [[Opencaching.de]] nicht vorhanden, obwohl sie immer wieder von Nutzern gewünscht werden. Dieser Artikel erklärt, warum das so ist.

== Technische Umsetzung steht noch aus ==

Opencaching.de wird von Geocachern in ihrer Freizeit betrieben und weiterentwickelt. Die zur Verfügung stehenden Ressourcen zum Einbau neuer Funktionen sind daher begrenzt. Die folgenden Änderungen und Ergänzungen an der Website sind bereits angedacht, aber es hat sich noch niemand gefunden, der sie einbaut:

* [https://opencaching.atlassian.net/jira/core/projects/RED/issues/?jql%3Dstatus%20IN%20(%22Pull%20Request%20%C2%BB%20Branch%22%2C%20%22Approved%22)%20AND%20project%20%3D%20%22RED%22%20ORDER%20BY%20priority%20DESC Jira]

== Diskussionsbedarf ==

Bei manchen Funktionen wurde noch nicht besprochen, ob sie sinnvoll oder den technischen Aufwand wert sind. Sie sind hier aufgeführt:

* [https://opencaching.atlassian.net/jira/core/projects/RED/issues/RED-1326?jql=project%20%3D%20%22RED%22%20AND%20status%20IN%20%28%22In%20Review%22%2C%20%22Need%20Feedback%22%2C%20NEW%29%20ORDER%20BY%20created%20DESC&jql%3Dproject%20%3D%20%22RED%22%20AND%20status%20IN%20%28%22Need%20Feedback%22%2C%20NEW%2C%20%22In%20Review%22%29%20ORDER%20BY%20created%20DESC%26jql%3Dproject%20%3D%20%22RED%22%20AND%20status%20IN%20%28%22Need%20Feedback%22%2C%20%22NEW%22%2C%20%22In%20Review%22%29%20ORDER%20BY%20priority%20DESC%3D= Jira]

== Problematische Funktion ==

Folgende neuen Funktionen wurden im [http://forum.opencaching.de/index.php Opencaching-Forum] besprochen – oft auch mehrfach – und es gab schwerwiegende Bedenken gegen eine Realisierung:

=== Bundesländer-Statistik ===

Manche Benutzer wundern sich, warum die regionale [[Empfehlungen|Empfehlungsstatistik]] nach der relativ unbekannten NUTS-Systematik (Regionen) statt nach Bundesländern aufgeteilt ist. Bei einer Aufteilung nach Bundesländern statt nach Regionen würden meist die größeren Städte/Ballungszentren auf den vorderen Plätzen liegen, da dort die Anzahl der Caches/Mitspieler am größten ist. Dadurch würden viele Regionen gar nicht aufgeführt. Owner aus diesen Regionen hätten kaum eine Chance, in eine Bundesland Top 10 zu kommen. Außerdem hätten Cacher außerhalb der Ballungsgebiete keine Möglichkeit nachzuschauen, welche Cache bei ihnen besonders häufig empfohlen/gefunden wurden. Mehr dazu hier: http://forum.opencaching.de/index.php?topic=4398.0

=== Geochecker ===

Es wäre toll, wenn man die Zielkoordinaten von [[Multicache|Multi-]] oder [[Rätselcache]]s als versteckten [[Wegpunkte#Interne, zusätzliche Wegpunkte|zusätzlichen Wegpunkt]] in der [[Cachebeschreibung (Listing)|Cachebeschreibung]] hinterlegen könnte, sodass man die ermittelten Koordinaten prüfen kann. Diese Möglichkeit ist bislang nur über externe Anbieter wie [http://geochecker.org geochecker.org] verfügbar.

Das Problem dabei: Mehrere solcher Koordinatendatenbanken wurden bereits von Hackern geknackt und die Koordinaten im Internet veröffentlicht. Zwar ist Opencaching.de mit professionellen Methoden gegen Hacker abgesichert, aber es ist unklar, ob man das immer vorhande technische „Restrisiko“ in Kauf nehmen möchte.

Forumsdiskussion: http://forum.opencaching.de/index.php?topic=4447.0

=== Cacheampel ===

Befürworter einer „Cacheampel“ wünschen sich, dass Caches nach strengen Kriterien automatisch [[Cachestatus|deaktiviert]] oder mit einem Warnhinweis versehen werden. Dies soll passieren, wenn die Besitzer seit über 12 Monaten nicht mehr eingeloggt waren, evtl. mit weiteren Bedingungen wie mindestens zwei [[DNF|DNF-Logs]].

Das Problem hierbei ist, dass man den Zustand von Caches nicht automatisch bewerten kann. Weder der letzte Loginzeitpunkt des Besitzers noch die Zahl der DNFs lässt einen klaren Schluss auf den Zustand des Caches zu. Viele Cacher loggen z.B. DNF, wenn sie den Cache gar nicht oder nur kurz gesucht haben (wegen [[Muggel]]s, gefährlichem Terrain, einbrechender Dunkelheit usw.)

Stattdessen wurde ein manuell setzbarer Status [http://forum.opencaching.de/index.php?topic=4449.0 Cache vielleicht findbar] diskutiert, der in Extremfällen auch automatisch gesetzt werden könnte. Die Funktion wurde aber bisher nicht umgesetzt.

[[Kategorie:Opencaching]]
[[Kategorie:Überarbeiten]]

Test2

2024-05-13T17:51:51Z

Fraggle:

{{Template:Translation out of sync}}

* [[Testeritis]]
* [[ES:Testeritis]]

---

[[en:Adopcja skrzynki]]
[[pl:Adopcja skrzynki]]
[[es:Testeritis]]

Vorlage:Translation out of sync

2024-05-13T17:51:39Z

Fraggle:

<div style="align-items:center;margin:2px 0;padding:16px;border: 4px solid black;">Dieser Artikel ist eine deutsche Übersetzung des Originals (in der Regel auf Englisch), aber der Inhalt scheint '''unvollständig oder nicht aktuell''' zu sein! Bitte aktualisiere diese Übersetzung, wenn möglich.
</div>

Vorlage:Translation out of sync

2024-05-13T17:48:28Z

Fraggle:

This article is a translated version of the original article, but the content appears to be '''out of sync with the reference text''' {{#if: {{{src|}}}
| in {{Languagename|{{{src|}}}|en}}
| (usually the English or German version)
}}. Please update this translation if possible.

Vorlage:Translation out of sync

2024-05-13T17:44:18Z

Fraggle:

This article is a translated version of the original article, but the content appears to be '''out of sync with the reference text''' {{#if: {{{src|}}}
| in {{Languagename|{{{src|}}}|en}}
| (usually the English or German version)
}}. Please update this translation if possible.

Vorlage:Translation out of sync

2024-05-13T17:41:26Z

Fraggle: Die Seite wurde geleert.

Vorlage:Translation out of sync

2024-05-13T17:40:33Z

Fraggle:

{{Wfmessage
| type = content
| image = Inequation.svg{{!}}alt=an unequal sign{{!}}16x16px
| text = {{LangSwitch|lang={{{lang|{{langcode}} }}}
| default = {{TranslateThis|lang={{{lang|}}}|edit=Template:Translation out of sync
| 1 = This article is a translated version of the original article, but the content appears to be '''out of sync with the reference text''' {{#if: {{{src|}}}
| in {{Languagename|{{{src|}}}|en}}
| (usually the English or German version)
}}. Please [[{{LL|Wiki Translation}}|update this translation]] if possible.
}}
| ca = Aquest article és una traducció de l'original {{#if: {{{src|}}}
(normalment de la versió en anglès o alemany)
}}, però el contingut sembla estar '''desfasat o incomplet'''. Si us plau [[ES:Wiki Traducción|actualitza la traducció]] si t'és possible.
| cs = Tato stránka je českým překladem originálu ({{Languagename|{{{src|}}}|cs}}), ovšem její obsah se zdá být '''neúplný nebo neaktuální''' {{#if:{{{src|}}}
| (obvykle v porovnání s anglickou nebo německou verzí)
}}. Prosím, [[Wiki Translation|aktualizujte tento překlad]], je-li to možné.
| de = Dieser Artikel ist eine deutsche Übersetzung des Originals {{#if: {{{src|}}}
| auf {{Languagename|{{{src|}}}|de}}
| (in der Regel auf Englisch)
}}, aber der Inhalt scheint '''unvollständig oder nicht aktuell''' zu sein! Bitte [[DE:Wiki Übersetzung|aktualisiere diese Übersetzung]], wenn möglich.
| el = Αυτό το άρθρο είναι συνδεδεμένο ως μεταφρασμένη έκδοση από το αγγλικό άρθρο, αλλά το περιεχόμενο μοιάζει να είναι '''μη συγχρονισμένο με το αναφερόμενο κείμενο''' {{#if: {{{src|}}}
| στα {{Languagename|{{{src|}}}|el}}
| (συνήθως η αγγλική ή η γερμανική έκδοση)
}}. Παρακαλούμε [[El:Wiki Translation|ενημερώστε αυτή τη μετάφραση]] αν είναι δυνατόν.
| en = This English article is a translated version, but the content appears to be '''out of sync with the reference text''' {{#if: {{{src|}}}
| in {{Languagename|{{{src|}}}|en}}
| (usually a French, German, or Russian version on this wiki)
}}. Please [[Wiki Translation|update this translation]] if possible.
| es = Este artículo es una traducción del original {{#if: {{{src|}}}
| en {{Languagename|{{{src|}}}|es}}
| (normalmente de la versión en inglés o alemán)
}}, pero el contenido parece estar '''desfasado o incompleto'''. Por favor [[ES:Wiki Traducción|actualiza la traducción]] si te es posible.
| fa = این مقاله از نسخهٔ زبان‌اصلی آن {{#if: {{{src|}}}
| ({{Languagename|{{{src|}}}|fa}})
| (معمولاً انگلیسی، آلمانی، فرانسوی، روسی)
}} به فارسی ترجمه شده اما به‌نظر می‌رسد با متن مبدأ هماهنگ نیست. اگر می‌توانید آن را [[Fa:ترجمه ویکی|به‌روز کنید]].
| fr = Cet article est une version traduite de l’article original, mais son contenu semble '''ne plus être en phase avec le texte de référence''' {{#if: {{{src|}}}
| en {{Languagename|{{{src|}}}|fr}}
| (habituellement la version anglophone ou germanophone)
}}. Veuillez [[FR:Traduction du wiki|mettre à jour cette traduction]] si possible.
| gl = Este artigo é unha tradución do orixinal {{#if: {{{src|}}}
| en {{Languagename|{{{src|}}}|gl}}
| (a miúdo da versión inglésa ou alemá)
}}, pero o contido semella atoparse '''desfasado ou incompreto'''. Por favor [[ES:Wiki Traducción|actualiza a tradución]] se éche posíbel.
| id = Artikel ini adalah versi diterjemahkan, tapi isinya sepertinyanya '''tidak sinkron dengan artikel asli''' {{#if: {{{src|}}}
| di {{Languagename|{{{src|}}}|id}}
| (biasanya versi bahasa Inggris atau Jerman)
}}. Tolong bantu untuk [[{{LL|Wiki Translation}}|memperbarui terjemahan ini]], jika mungkin.
| it = Questo articolo è una traduzione dall'articolo originale, ma il contenuto sembra essere '''disallineato con l'articolo di riferimento''' {{#if: {{{src|}}}
| in {{Languagename|{{{src|}}}|it}}
| (solitamente la versione inglese, francese o tedesca)
}}. Se possibile [[IT:Traduzione delle pagine wiki|aggiorna questa traduzione]].
| ja = この記事は「日本語版」として翻訳されていますが、'''原文'''{{#if: {{{src|}}}
| （{{Languagename|{{{src|}}}|ja}}版）
| （通常、英語版またはドイツ語版）
}}'''の変更が反映されていない'''ようです。できれば[[JA:ウィキの翻訳|この翻訳の更新]]にご協力ください。
| ko = 이 문서는 한국어판으로 번역됐지만 내용이 '''원본'''{{#if: {{{src|}}}
| ({{Languagename|{{{src|}}}|ko}}판)
| (대개는 영어판이나 독일어판)
}}'''에서 벗어난''' 것 같습니다. 되도록 [[Ko:위키_번역|이 번역을 업데이트]]해 주십시오.
| pl = Ten artykuł jest przetłumaczoną wersją, ale treść jest '''niezsynchronizowana z tekstem oryginalnym''' {{#if: {{{src|}}}
| w języku {{Languagename|{{{src|}}}|pl}}m
| (zazwyczaj wersja angielska)
}}. Proszę [[Pl:Tłumaczenie Wiki|zaktualizuj to tłumaczenie]] jeśli to możliwe.
| pt = Esta página é uma tradução de outra página, mas o conteúdo parece estar '''fora de sincronia com o texto original''' {{#if: {{{src|}}}
| em {{Languagename|{{{src|}}}|pt}}
| (geralmente a versão em inglês ou alemão)
}}. Por favor, ajude a [[Pt:Wiki Tradução|atualizar esta tradução]], se possível.
| ru = Эта статья отмечена как русскоязычная версия статьи на другом языке, но '''отличается от неё по содержанию''' {{#if: {{{src|}}}
| ({{Languagename|{{{src|}}}|ru}})
| (обычно основная статья на английском или немецком языках)
}}. Пожалуйста, [[RU:Перевод Вики|обновите перевод]] если считаете возможным.
| uk = Ця стаття українською мовою пов’язана з англомовною версією, але її вміст '''не є синхронізованим з оригіналом''' {{#if: {{{src|}}}
| ({{Languagename|{{{src|}}}|uk}})
| (як правило англомовною версією)
}}. Будь ласка, [[Uk:Wiki Translation|оновіть переклад]], якщо можливо.
| zh-hans = 此文章是来自英文文章的翻译版本，但内容似乎已经'''与来源文字不同步'''了 {{#if:{{{src|}}}
| （用{{Languagename|{{{src|}}}|zh-hans}}）
| （通常是英文或德文版本）
}}。可以的话请[[Wiki Translation|更新此翻译]]。
| zh-hant = 此文章被連結為來自英文文章的翻譯版本，但內容看起來已經'''和來源文字不同步'''了 {{#if:{{{src|}}}
| （用{{Languagename|{{{src|}}}|zh-hant}}）
| （通常是英文或德文版本）
}}。可以的話請[[Wiki Translation|更新此翻譯]]。
}}
| nocat = {{{nocat|}}}{{#ifeq:{{{category|}}}|no|yes}}
| categories = <includeonly>[[{{#switch: {{lc:{{#if:{{{lang|}}}|{{{lang|}}}|{{Langcode}}}}}}
|en = Category:Translations out of sync

| de = Category:DE:Translations out of sync
| es = Category:ES:Traducciones desfasadas
| fr = Category:FR:Traductions désynchronisées
| it = Category:IT:Translations out of sync
| ja = Category:JA:原文の変更が未反映の翻訳記事
| ko = Category:KO:원본에서 벗어난 번역 문서
| nl = Category:NL:Translations out of sync
| ru = Category:RU:Протеворечивые переводы

| cs = Category:Cs:Překlad není aktuální
| fa = Category:Fa:ترجمه ناهماهنگ
| zh-hans = Category:Zh-hans:翻译已过时
| zh-hant = Category:Zh-hant:翻譯已過時

| ast|bg|ca|da|el|et|fi|fy|he|ko|ku|lv|mk|pl|pt|ro|tr|uk|vi|zh-hans
= Category:{{lc:{{#if:{{{lang|}}}|{{{lang|}}}|{{Langcode}}}}}}:Translations out of sync

| #default = Category:Translations out of sync
}}| {{REVISIONTIMESTAMP}}]]</includeonly>
}}<noinclude>
</noinclude>

Vorlage:Translation out of sync

2024-05-13T17:40:01Z

Fraggle: Die Seite wurde neu angelegt: „{{Wfmessage | type = content | image = Inequation.svg{{!}}alt=an unequal sign{{!}}16x16px | text = {{LangSwitch|lang={{{lang|{{langcode}} }}} | default = {{TranslateThis|lang={{{lang|}}}|edit=Template:Translation out of sync | 1 = This article is a translated version of the original article, but the content appears to be '''out of sync with the reference text''' {{#if: {{{src|}}} | in {{Languagename|{{{src|}}}|en}} | (usually the English…“

XML-Schnittstelle

2024-05-13T17:31:45Z

Fraggle: XML-Schnittstelle in Vergangenheitsform gesetzt

Die '''XML-Schnittstelle''' von Opencaching.de ermöglichte es bis Mitte 2020<ref>[https://github.com/OpencachingDeutschland/oc-server3/commit/e02ca45d606fd752c3d7179f2dcca275316b1a3c Commit vom 12.01.2020 zum Entfernen der Schnittstelle]. Diese Änderungen wurden erst im Juni 2020 mit der Einführung des Cookie Consent Tools auch auf der Webseite wirksam.</ref>, Cachelistings, Logs und Bilder herunterzuladen, zum Beispiel

* einzelne Caches
* Caches in einem bestimmten Umkreis
* neue und veränderte Daten seit einem bestimmten Zeitpunkt
* die gesamte Opencaching-Datenbank.

Die Daten wurden in einem XML-Format übertragen und waren nicht zum direkten Lesen, sondern zur Weiterverarbeitung durch Programme/Apps/Tools gedacht. Ihre Verwendung unterliegt der [[Datenlizenz]].

[[API-Clients#XML-Clients|Diese Programme]] (unvollständige Liste) nutzen die XML-Schnittstelle.

Mit der [[Opencaching-API]] (OKAPI) ist eine weitere, komfortablere Schnittstelle verfügbar, die auch das Hochladen von Logs ermöglicht.

== XML-Schnittstelle vs. OKAPI ==

Die OKAPI ist flexibler einsetzbar, besser dokumentiert, bietet mehr Funktionen und die bessere Performance, wird konsequenter weiterentwickelt und ist auch auf anderen [[Opencaching]]-Länderseiten verfügbar. Sie ist daher die erste Wahl für die meisten Anwendungen.

Die Vorteile des XML-Interfaces lagen vor allem im Abruf großer Datenmengen. Wenn man z.B. die Koordinaten, Typen, Namen etc. aller Caches für eine Kartendarstellung braucht, müsste man dazu mit der OKAPI die komplette Datenbank inklusive aller Cachebeschreibungen und Logs ziehen; außerdem muss man neue Daten mindestens einmal pro Woche abrufen. Beim XML-Interface konnte man dagegen gezielt nur die Basisdaten aller Caches abrufen, und es gab keine Mindestfrequenz für Aktualisierungen.

Alle anderen OKAPI-Abrufe, bei denen man nicht die gesamte Datenbank herunterlädt, sind auf 500 Caches pro Abruf beschränkt. Beim XML-Interface gab es keine Beschränkung.

== Weblinks ==

* [http://www.opencaching.de/doc/xml Beschreibung der XML-Schnittstelle] ([https://github.com/OpencachingDeutschland/oc-server3/tree/development/htdocs/doc/xml Auf GitHub] bzw. [https://github.com/OpencachingDeutschland/oc-server3/blob/5f2bc06c3fc8ed41542a3a8deeb3a71cb99fc69b/htdocs/doc/xml/ Permalink])
* [https://github.com/OpencachingDeutschland/oc-server3/tree/development/local/ocxml11client Client-Referenzimplementierung] ([https://github.com/OpencachingDeutschland/oc-server3/blob/5f2bc06c3fc8ed41542a3a8deeb3a71cb99fc69b/local/ocxml11client/ Permalink])

== Referenzen ==

<references />

[[Kategorie:Opencaching]]
[[Kategorie:Geocaching-Software]]

Warum diese Funktion nicht vorhanden ist

2024-05-13T17:28:49Z

Fraggle: Kategorie ergänzt

Manche Funktionen sind auf [[Opencaching.de]] nicht vorhanden, obwohl sie immer wieder von Nutzern gewünscht werden. Dieser Artikel erklärt, warum das so ist.

== Technische Umsetzung steht noch aus ==

Opencaching.de wird von Geocachern in ihrer Freizeit betrieben und weiterentwickelt. Die zur Verfügung stehenden Ressourcen zum Einbau neuer Funktionen sind daher begrenzt. Die folgenden Änderungen und Ergänzungen an der Website sind bereits angedacht, aber es hat sich noch niemand gefunden, der sie einbaut:

* https://opencaching.atlassian.net/jira/core/projects/RED/issues/?jql=status%20IN%20%28"Pull%20Request%20»%20Branch"%2C%20"Approved"%29%20AND%20project%20%3D%20"RED"%20ORDER%20BY%20priority%20DESC

== Diskussionsbedarf ==

Bei manchen Funktionen wurde noch nicht besprochen, ob sie sinnvoll oder den technischen Aufwand wert sind. Sie sind hier aufgeführt:

* https://opencaching.atlassian.net/jira/core/projects/RED/issues/?jql=project%20%3D%20"RED"%20AND%20status%20IN%20%28"Need%20Feedback"%2C%20"NEW"%2C%20"In%20Review"%29%20ORDER%20BY%20priority%20DESC

== Problematische Funktion ==

Folgende neuen Funktionen wurden im [http://forum.opencaching.de/index.php Opencaching-Forum] besprochen – oft auch mehrfach – und es gab schwerwiegende Bedenken gegen eine Realisierung:

=== Bundesländer-Statistik ===

Manche Benutzer wundern sich, warum die regionale [[Empfehlungen|Empfehlungsstatistik]] nach der relativ unbekannten NUTS-Systematik (Regionen) statt nach Bundesländern aufgeteilt ist. Bei einer Aufteilung nach Bundesländern statt nach Regionen würden meist die größeren Städte/Ballungszentren auf den vorderen Plätzen liegen, da dort die Anzahl der Caches/Mitspieler am größten ist. Dadurch würden viele Regionen gar nicht aufgeführt. Owner aus diesen Regionen hätten kaum eine Chance, in eine Bundesland Top 10 zu kommen. Außerdem hätten Cacher außerhalb der Ballungsgebiete keine Möglichkeit nachzuschauen, welche Cache bei ihnen besonders häufig empfohlen/gefunden wurden. Mehr dazu hier: http://forum.opencaching.de/index.php?topic=4398.0

=== Geochecker ===

Es wäre toll, wenn man die Zielkoordinaten von [[Multicache|Multi-]] oder [[Rätselcache]]s als versteckten [[Wegpunkte#Interne, zusätzliche Wegpunkte|zusätzlichen Wegpunkt]] in der [[Cachebeschreibung (Listing)|Cachebeschreibung]] hinterlegen könnte, sodass man die ermittelten Koordinaten prüfen kann. Diese Möglichkeit ist bislang nur über externe Anbieter wie [http://geochecker.org geochecker.org] verfügbar.

Das Problem dabei: Mehrere solcher Koordinatendatenbanken wurden bereits von Hackern geknackt und die Koordinaten im Internet veröffentlicht. Zwar ist Opencaching.de mit professionellen Methoden gegen Hacker abgesichert, aber es ist unklar, ob man das immer vorhande technische „Restrisiko“ in Kauf nehmen möchte.

Forumsdiskussion: http://forum.opencaching.de/index.php?topic=4447.0

=== Cacheampel ===

Befürworter einer „Cacheampel“ wünschen sich, dass Caches nach strengen Kriterien automatisch [[Cachestatus|deaktiviert]] oder mit einem Warnhinweis versehen werden. Dies soll passieren, wenn die Besitzer seit über 12 Monaten nicht mehr eingeloggt waren, evtl. mit weiteren Bedingungen wie mindestens zwei [[DNF|DNF-Logs]].

Das Problem hierbei ist, dass man den Zustand von Caches nicht automatisch bewerten kann. Weder der letzte Loginzeitpunkt des Besitzers noch die Zahl der DNFs lässt einen klaren Schluss auf den Zustand des Caches zu. Viele Cacher loggen z.B. DNF, wenn sie den Cache gar nicht oder nur kurz gesucht haben (wegen [[Muggel]]s, gefährlichem Terrain, einbrechender Dunkelheit usw.)

Stattdessen wurde ein manuell setzbarer Status [http://forum.opencaching.de/index.php?topic=4449.0 Cache vielleicht findbar] diskutiert, der in Extremfällen auch automatisch gesetzt werden könnte. Die Funktion wurde aber bisher nicht umgesetzt.

[[Kategorie:Opencaching]]
[[Kategorie:Überarbeiten]]

Verschlüsselungsmethode

2024-05-13T17:20:44Z

Fraggle: Linkupdates

Eine beliebte Methode, um [[Geocache]]s interessanter zu gestalten, ist das Verschlüsseln von Teilen des [[Listing]]s. Sie findet vor allem bei [[Rätselcache]]s und [[Multicache]]s Anwendung. Auch die Stationen eines Multicaches vor Ort können verschlüsselt sein.

Beim Erfinden von Verschlüsselungsmethoden sind deiner Fantasie keine Grenzen gesetzt. Dieser Artikel beschreibt als Anregung und Hilfestellung einige übliche Verfahren. Wenn du weitere gebräuchliche Verschlüsselungen kennst, kannst du sie gerne hier vorstellen.

== Zuordnungen ==
Die bekanntesten Methoden basieren auf Zuordnungen. Dazu gehört beispielsweise das für Hinweise verwendete [[Hinweise#Das ROT13-System|ROT13-System]] oder die Stellung von Buchstaben im Alphabet.

Durch die Zuordnung von Ziffern zu Buchstaben lassen sich aus einem beliebigen Wort Koordinaten für weitere [[Stage|Stationen]] ermitteln.

[[Datei:Koordinaten Verzerrung.png|70px|thumb|rechts|Verzerrte Koordinaten]]
== Verzerrungen ==
Durch den Einsatz von Grafikprogrammen lassen sich Koordinaten und andere Hinweise verzerren. Dazu wird der entsprechende Text als Grafikdatei auf dem Computer gespeichert und durch starkes Verändern der Abmaße einer Seite der Inhalt verzerrt. Zum Entziffern lassen sich die verzerrten Koordinaten meist von der Seite lesen. Jedoch ist es auch möglich, am Computer die Grafik (z. B. als Foto) wieder in den ursprünglichen Zustand zu versetzen und somit klar lesbare Daten zu erhalten.
<div style="clear:both"></div>
== QR-Codes ==
[[Datei:Koordinaten QR-Code.png|70px|thumb|rechts|QR-Code mit Koordinaten]]
Mit dem Aufkommen der Smartphones hat sich eine neue Möglichkeit der Verschlüsselung eröffnet: die QR-Codes. Diese eckigen Felder mit vielen kleinen Kästchen können Koordinaten, aber auch ganze Beschreibungstexte enthalten. Jedoch sollte man aus technischen Gründen darauf achten, dass die Anzahl der Zeichen nicht über 300 liegt, da der Code sonst von manchen Geräten nicht gelesen werden kann.

== Morsealphabet ==
Auch das [[wikipedia:Morsecode|Morsealphabet]] eignet sich hervorragend zur Verschlüsselung. Dazu können die Koordinaten oder der Text entweder mit Strichen und Punkten visuell dargestellt oder in einer Audiodatei gespeichert sein. Je nach Methode steigt die Schwierigkeit zur Entschlüsselung der Texte.

Bei Audiodateien empfiehlt es sich, diese in einem Audioeditor (z. B. [[#Weblinks|Audacity]]) zu öffnen und dort
die Länge der Töne abzulesen, um die Informationen zu entschlüsseln.
[[Datei:Koordinaten Morse.png|400px|thumb|links|Koordinaten als Morsecode]]
<div style="clear:both"></div>
== Andere Sprachen ==
Natürlich können Beschreibungen auch in anderen Sprachen vorliegen. Neben den bekannten Fremdsprachen ist es auch möglich, dass es sich dabei um eine handelt, welche nicht offiziell gesprochen wird, sondern beispielsweise nur in einem Internetprojekt entstanden ist und somit weitgehend unbekannt ist (z. B. [http://www.namesuppressed.com/kenny/ KennySpeak]).

== Braille-Schrift ==
[[Datei:Koordinaten Braille.png|200px|thumb|rechts|Koordinaten in Blindenschrift]]
Auch durch die Verwendung von Braille-Schrift (Blindenschrift) können Informationen verschlüsselt werden. Diese Methode findet bisher selten Verwendung.

== Weblinks ==
* [https://goqr.me/de/ QR-Code-Generator]
* [https://jumk.de/alphabete/morse.shtml Morsecode]
* [https://gc.de/gc/ Morse- und viele weitere Codes ver- und entschlüsseln]
* [https://audacity.sourceforge.net/?lang=de Audacity]
* [https://translate.google.de/?rls=ig&hl=de&tab=wT Google-Übersetzer]
* [https://de.wikipedia.org/wiki/Brailleschrift Das Braille-Alphabet]

[[Kategorie:Verschlüsselungsmethoden]]

Test2

2024-05-13T15:48:27Z

Fraggle:

* [[Testeritis]]
* [[ES:Testeritis]]

---

[[en:Adopcja skrzynki]]
[[pl:Adopcja skrzynki]]
[[es:Testeritis]]