Organisation der Verzeichnisse

[nebbiolo]

Hallo

Gibt es irgendwo Richtlinien wie man Verzeichnisse und Unterverzeichnisse anordnen sollte?
Dass z.B. Funktionen in einem /functions angelegt werden sollten ist mir schon klar, aber ich habe einige Script, die ich nur für mich (also intern) zur Kontrolle brauche. Da habe ich mal content="noindex" angegeben damit diese Seiten nicht von Suchmaschinen gefunden werden.
Was sollte/dürfte im "obersten" Verzeichnis (bei mir httpdocs) ausser dem index.php überhaupt abgelegt werden?

Vielen Dank und sonnige Grüsse, Nebbiolo

[chorn]

das sind ja gleich mehrere Baustellen. Also zum laden von Modulen gibts z.B. PSR-4 + Namespaces, für die Paketierung guck mal wie Composer das macht. Dann sollte deine index.php in einem Unterverzeichnis deines Projekts liegen und die Domain darauf zeigen, an die "oberen" Dateien kommt dann erstmal keine mehr ran. Und damit irgendwelche Seiten nicht bei Google oder sonstwo auftauchen, sollte da ein Login vorgeschaltet sein.

[mermshaus]

Das sind gute Empfehlungen. Autoloading, Composer und dergleichen ist aber kein „Muss“ in dem Sinne. Das hängt auch von der Größe und Komplexität des Projekts ab. Ich versuche es noch mal etwas auszuführen.

Gibt es irgendwo Richtlinien wie man Verzeichnisse und Unterverzeichnisse anordnen sollte?

Nicht wirklich. Wenn du zum Beispiel ein Framework verwendest (Symfony, Laravel, Zend, …), dann gibt das oft eine gewisse Struktur vor, hinter der natürlich auch Sinn und Überlegung stehen, aber das sind letztlich trotzdem Konventionen des Frameworks.

Ich schließe mich hier chorn an: Ein zentraler Aspekt ist, nach Möglichkeit nur die Dateien im öffentlich zugänglichen Bereich des Webservers abzulegen, die dort liegen müssen, weil sie von außerhalb (vom Browser) aufgerufen werden sollen. Das gilt zum Beispiel nicht für functions.php- oder config.php-Dateien, die nur anderswo eingebunden werden.

Ich poste mal eine (gekürzte) Struktur eines aktuellen Projekts, um zu verdeutlichen, wie extrem das werden kann:

.
|-- build
|   `-- coverage
|-- composer.json
|-- config.dist.php
|-- config.php
|-- cronjob.php
|-- deploy.sh
|-- docs
|   `-- structure.sql
|-- log
|-- phpunit.xml.dist
|-- public                                      \
|   |-- assets                                  | nur drei Dateien
|   |   `-- screen.css                          | im öffentlichen
|   |-- index.php                               | Verzeichnis
|   `-- robots.txt                              /
|-- src
|   |-- Application.php
|   |-- DbApi.php
|   |-- EntryModel.php
|   |-- functions.php
|   |-- HttpRequest.php
|   |-- HttpResponse.php
|   |-- ImportCronjob.php
|   |-- ImporterInterface.php
|   |-- JsonImporter.php
|   |-- PageScannerImporter.php
|   `-- TypeSafety.php
|-- templates
|   |-- day.phtml
|   |-- helpers
|   |   |-- day-table.phtml
|   |   `-- format-delay.phtml
|   |-- index.phtml
|   |-- layout.phtml
|   |-- view-by-date.phtml
|   `-- view-by-train-and-day.phtml
|-- tests
|   |-- ApplicationTest.php
|   |-- bootstrap.php
|   |-- data
|   |-- DbApiTestDouble.php
|   |-- DbApiTest.php
|   |-- EntryModelTest.php
|   |-- HttpRequestTest.php
|   |-- HttpResponseTest.php
|   |-- ImportCronjobTest.php
|   |-- ImporterTest.php
|   `-- SqliteTest.php
`-- vendor

Das ist die lokale Version des Projekts. Wenn ich es auf den Server schiebe (über das deploy.sh-Script), wird nicht alles übertragen. Etwa die Verzeichnisse build, docs und tests werden im Livebetrieb nicht benötigt.

Auf dem Server ist es dann so, dass ich eine Subdomain "foo.example.org" direkt auf das public-Verzeichnis zeigen lasse (wie es auch chorn beschrieben hat). Im Browser wäre es also möglich "foo.example.org/assets/screen.css" aufzurufen, aber es gibt keine Möglichkeit, zum Beispiel "PageScannerImporter.php" anzuwählen, weil die Datei außerhalb des Doc-Root-Verzeichnisses ("public") liegt.

Weitere Beispiele, was ins public-Verzeichnis gehört, sind Bilder und JavaScript-Dateien, da die in der Regel statische Ressourcen sind.

Je nachdem, wie man sein Projekt aufbaut, tut es in Sachen Code wirklich oft eine einizige öffentlich erreichbare index.php-Datei, an die per Rewriting alles umgeleitet wird.

Auch das, was ich hier geschildert habe, ist aber nicht zwingend. Wenn du dir etwa WordPress anschaust, siehst du, dass die „pragmatisch“ auch den gesamten Code in einem öffentlich zugänglichen Verzeichnis liegen haben. Das ist so, um die Installation zu vereinfachen und Leuten dieses Gebastel mit einem public-Verzeichnis zu ersparen.

Aber wenn man es in eigenen Projekten so machen kann, ist das mit dem public-Verzeichnis eine gute Idee.

ich habe einige Script, die ich nur für mich (also intern) zur Kontrolle brauche. Da habe ich mal content="noindex" angegeben damit diese Seiten nicht von Suchmaschinen gefunden werden.

Da die vermutlich auch mit dem Browser aufgerufen werden sollen: Ja, im Zweifel immer ein Login davorschalten. Im einfachsten Fall zum Beispiel mit .htpasswd (Apache). Das mache ich mittlerweile ständig, weil man nie weiß, wer was ausliest.

[nebbiolo]

Vielen Dank mermshaus für die ausführliche Beschreibung!
Das hilft mir wirklich weiter.
Auch Danke an chorn ... aber das war mir ein bisschen zu kompliziert ...