Ich versuche, die Verzeichnisstruktur für eine PHP-Website herauszufinden.Verzeichnisstruktur für eine PHP-Website mit Composer, Schluck und Travis
Die Website wird verwenden:
- einen sehr einfache PHP MVC-Framework (nämlich MinimalMVC, aber ich bin für eine generische Lösung suchen, so kann der Rahmen wahrscheinlich ignoriert werden)
- Komponisten zu verwalten PHP-Abhängigkeiten
- SCSS für Styling
- schluck die SCSS (für die dev build) zu kompilieren und zu auch minify und verketten JS und CSS-Ausgang sowie minify Bilder etc. (nur für den Einsatz Build)
- Travis CI für CI Sachen
So nach viel Denken und Planung und Blick auf Problemen mit verschiedenen Arten von Verzeichnisstrukturen, die ich kam mit, ich kann immer noch nicht etwas finden, das meine Kriterien erfüllt:
gulp deploy
sollte in der Lage sein, einen Bereitstellungsordner zu erzeugen, die, wenn sie in ein/var/www/html/
Verzeichnis auf einem Server Apache setzen, Just TMarbeiten sollte
Hinweis: MinimalMVC (und auch CodeIgniter und andere ähnliche Frameworks) benötigen, um ihre
index.php
Datei in das Root-Verzeichnis, mit einemapp
undsys
Ordner im selben VerzeichnisSeit PHP wird von der Build nie wirklich verarbeitet Prozess, wäre es toll, wenn unnötige Kopie der
src/**/*.php
Dateien in etwas wiebuild/**/*.php
vermeidbar wäre. Im Grunde behält der PHP-Teil keinen Schluck, ich würde es vorziehen, ihn nicht durch Schluck zu beeinflussen.
Nun, meine Gedanken sind ein bisschen ein Durcheinander, weil ich zu viel darüber nachzudenken habe, so verzeihen Sie mir diese Frage auch ein bisschen ein Durcheinander zu sein, aber die grundlegende Frage ist, wie sollte die Verzeichnisstruktur aussehen?
Eine Idee:
.
|-- composer.json
|-- gulpfile.js
|-- package.json
|-- src
| |-- app
| | |-- controllers
| | |-- models
| | `-- <other_framework_stuff>
| |-- assets
| | |-- css
| | |-- img
| | |-- js
| | `-- raw
| | `-- scss
| |-- index.php
| `-- sys
| `-- <framework_stuff>
|-- test
`-- vendor
`-- <composer_stuff>
In dieser Struktur arbeiten die Entwickler nur im /src
Verzeichnis. Der SCSS wird von /src/assets/raw/scss/
zu src/assets/css
kompiliert. Auf diese Weise bleibt das PHP aus dem Build-Prozess entfernt. Beim Versuch, ein Verzeichnis deploy
zu erzeugen, wird der Ordner src kopiert, das Verzeichnis /src/assets/raw/
(also kein /build/assets/raw
) existiert nicht, und das produktions-/deployment-fähige CSS, JS und Bilder befinden sich in /build/assets/
.
Das erste Problem mit dieser Lösung ist das seltsame Verzeichnis src/assets/raw
, das imho hässlich scheint. Das zweite Problem ist das Verzeichnis /vendor
. Dies bedeutet, dass das PHP auf Zeug von außerhalb src verweist. Wenn /src/index.php
sich darum kümmert, würde es ../vendor/autoload.php
einschließen. Dann würde das bedeuten, dass der gleiche Code in /build/index.php
kopiert wird.Und dann /build/
wird nicht ausgeführt, indem Sie einfach in /var/www/html
fallen, es sei denn, vendor
ist in /var/www
, die nur seltsam scheint.
Es gibt viele andere Sachen, an die ich gedacht habe, aber alles scheint auf die eine oder andere Weise hässlich zu sein. Um diese Frage nicht zu lange zu machen, höre ich hier auf.
Hilfe, bitte. Sollte ich einfach vendor
in /src/
mit vendor-dir
in composer.json
setzen? (Ich weiß, Ew.) Welche Art von Verzeichnisstruktur sollte ich verwenden?
Sie sollten sich von bestehenden Frameworks inspirieren lassen, zum Beispiel verwendet Laravel eine Struktur, die ziemlich nah an dem ist, was Sie tun: http://laravelbook.com/laravel-architecture/ BTW, wenn Sie können, würde ich nicht empfehlen Sie haben den Herstellerordner in Ihrem Build-Verzeichnis und führen stattdessen 'composer install' auf Ihrem Produktionsserver aus. – Korri
@Korri, danke, das hat geholfen. –
Stimmen Sie dem Kommentar von @ Korri zu. Solange Sie Ihre composer.lock-Datei festschreiben, sollte 'composer install' nicht lange dauern, wenn Sie sie bereitstellen. Nicht direkt mit Ihrer Frage verbunden, aber die wichtigste Sache, die ich ändern würde, würde trennen, was tatsächlich statisch vom Webserver abgerufen wird 'src'. Das schützt Sie vor Benutzern, die versuchen, direkt auf PHP-Dateien zuzugreifen, wo viele Sicherheitsprobleme auftreten. Der Webserver wäre so konfiguriert, dass er auf ein 'public'-Verzeichnis als Dokumenten-Root zugreift. Die meisten Frameworks folgen dieser Art der Einrichtung. –