Was ist die skalierbarste PHP-basierte Verzeichnisstruktur für eine große Website?

Lesezeit: 9 Minuten

Ich erstelle eine sehr große PHP-MVC-basierte Website, die eine große Bibliothek mit PHP-Klassen, Javascripts und vielen CSS-Dateien enthält (ganz zu schweigen von einer großen Anzahl von Dateien für MVC).

Zum allerersten Mal nehme ich mir tatsächlich die Zeit, eine saubere und organisierte Verzeichnisstruktur zu planen.

Welche Verzeichnisstrukturen verwenden Sie normalerweise und welche sind am einfachsten zu manövrieren, wenn es Tausende von Dateien gibt?

  • Dies ist nur ein Gedanke. Haben Sie darüber nachgedacht, ein bereits vorhandenes PHP-MVC-Framework wie CakePHP zu verwenden? Ich verstehe, dass es eine Lernkurve geben kann, aber es könnte sich lohnen, die Vorteile eines beliebten Open-Source-Frameworks in Betracht zu ziehen. Ich habe jahrelang meinen eigenen Code erstellt und gewartet, aber festgestellt, dass es besser skalierbar ist, ein Drittanbieter-Framework zu verwenden, insbesondere für große Websites. Sie werden vielleicht feststellen, dass Sie dadurch auf lange Sicht Zeit sparen und wertvolle Fähigkeiten für zukünftige Outsourcing-Projekte erwerben.

    – Dooltaz

    7. September 2009 um 5:09 Uhr

  • Ich habe tatsächlich daran gedacht … und ich könnte am Ende tatsächlich einen verwenden … aber ich muss es nur selbst können, bevor ich weitermachen kann:) Es ist eine neurotische Sache, ha

    – johnnietheblack

    7. September 2009 um 5:34 Uhr

Das ist meine Einstellung. Bei kleinen bis sehr großen Projekten (einschließlich eines sozialen Netzwerks) hat es bei mir hervorragend funktioniert.
Diese Ordner würden sich alle in meinem Hauptanwendungsordner befinden:

  • config – enthält benutzerdefinierte PHP-Konfigurationsdateien

  • css – enthält die CSS-Dateien des Projekts

  • helpers – enthält ‘helper’-Dateien (jede Datei ist eine Sammlung von Funktionen)

  • images – enthält die Bilder des Projekts

  • js – enthält die Javascript-Dateien des Projekts

  • lib – enthält projektspezifische PHP-Klassen

  • Module – Mein MVC-Framework ermöglicht das Packen von Site-Abschnitten als Module

    • blog – Ein Beispielmodul

      • controllers – enthält die Controller für das Modul
      • Modelle – enthält die Modelle für das Modul
      • Ansichten – enthält die Ansichten für das Modul
  • Ansichten – enthält Ansichten, die global zugänglich sein sollen (Seitenkopf, Fußzeile usw.)

Alle Verzeichnisse könnten offensichtlich Unterordner enthalten, die Ihre Dateien weiter organisieren würden. Beispielsweise könnte der Ordner „css“ Unterordner mit den Namen „web“ und „mobile“ haben. Der Ordner „images“ könnte einen Ordner „user_uploaded“ enthalten, der wiederum „profile“ enthalten könnte. Und natürlich können Sie nach Belieben Ordner hinzufügen. In einem Projekt habe ich einen Ordner namens „Uploaders“, der nur eigenständige Upload-Skripte enthält.

Ich verwende auch bequeme Methoden, die helfen, die Dateinamen dessen zu erstellen, was ich laden möchte. Zum Beispiel sucht my loadView() nach der Ansichtsdatei im aktuellen Modulverzeichnis, oder wenn Sie ein optionales $module-Argument übergeben, sucht es speziell im Ordner dieses Moduls.

Ich hoffe das hilft.

  • Das bedeutet, dass der gesamte PHP-Code, die Konfiguration usw. für alle sichtbar sind, es sei denn, Sie machen etwas Server-Magie mit etwas wie .htaccess

    – OIS

    10. Februar 2010 um 17:45 Uhr

  • OIS ist richtig. Wenn in diesem Setup jemand den Dateinamen kannte, konnte er ihn vom Browser aus aufrufen. Ich habe diese Antwort gepostet, bevor ich zu Symfony gewechselt bin (das alle Hintergrunddateien verbirgt), und ich empfehle definitiv, alle nicht öffentlichen Dateien außerhalb des öffentlichen Webzugriffs zu verschieben.

    – Steven Mercatante

    10. Februar 2010 um 18:21 Uhr

  • lib - contains PHP classes specific to the project Meinst du hier “nicht spezifisch”? Ich würde denken, lib ist für Dinge, die Sie schreiben, die allgemein sind und / oder für tatsächlich vorhandene Bibliotheken, die Sie verwenden. Außerdem bin ich gespannt – was haltet ihr von dem js und css Ordner so weit wie Module gehen? Würdest du das aufteilen js Verzeichnis in lib & modules auf ähnliche Weise?

    – Chris Middleton

    14. Oktober 2015 um 0:21 Uhr


Benutzer-Avatar
OIS

Sie sollten ein Verzeichnis als Web-Root haben, in dem sich nur Dateien befinden sollten, die Sie dem gesamten Internet zugänglich machen möchten.

project/
 web/
  index.php
  css/
  js/
  images/
 config/
 lib/
  • web/ ist der Stamm, der den Besuchern angezeigt wird
  • lib/ ist hier der Bibliotheksordner und wo Autoload nach Dateien sucht.

Sie können dem Projekt weitere Unterordner hinzufügen, z. B. Controller, Module, View, Helper usw. Dies hängt von Ihrem Framework ab.

BEARBEITEN:

Wenn Sie Composer (was ich empfehle) und vielleicht npm mit Grunzen und weniger verwenden, wäre Ihre Dateistruktur wie folgt:

project/
    web/
        js/
        css/
        images/
        index.php
    cli/
    config/
        config.php
    node_modules/
    src/
    test/
    vendor/
    composer.json
    composer.lock
    packages.json
  • web/ enthält alle Ihre öffentlichen Dateien
  • cli/ Skripte und Programme, die über die Befehlszeile ausgeführt werden sollen, NICHT über das Web
  • config/ enthält alle Ihre Konfigurationsdateien (in Git ignorieren Sie config.php und haben stattdessen config.dist.php ohne Benutzernamen, Passwörter, Validierungscodes und Tabellenpräfixe/-suffixe und andere “Geheimnisse”)
  • node_modules/ enthält alle Ihre Bibliotheksdateien von npm (in Git schlage ich vor, dass Sie dies in ein Untermodul einfügen)
  • src hat alle Ihre lokalen PHP-Dateien in der psr4-Struktur, die so eingerichtet sind, dass sie in composer.json automatisch geladen werden
  • test/ enthält alle Ihre Komponententests für Ihre src-Klassen, eingerichtet in autload-dev in composer.json (denken Sie daran, use Composer install –no-dev auf live, vielleicht hinzufügen wenn Sie nicht zu viele Klassen haben)
  • Vendor hat alle Ihre Bibliotheksdateien von Composer und die EINZIGE autoload.php, die in web/index.php und alle CLI-Skripte eingefügt werden sollen (in Git schlage ich vor, dass Sie diesen Vendor-Ordner ignorieren).

Fügen Sie nach Bedarf weitere Ordner und Dateien für Ihr Projekt hinzu.

Verwenden Sie für die Bereitstellung diese Struktur:

/sites/project/ (project is your projectname)
    current (alias to current release folder releases/v1.1.0)
    previous (optional alias to previous release folder releases/v1.0.1)
    releases/
        v1.0.0/ (git checkout of tag v1.0.0)
        v1.0.1/ (git checkout of tag v1.0.1)
        v1.1.0/ (git checkout of tag v1.1.0)
    shared/ (has all your shared files and folders to be aliased in all releases - maybe something like GlusterFS)

Erstellen Sie ein Bereitstellungsskript. Etwas wie das:

Erstellen Sie zuerst ein Backup von db oder kopieren Sie es in eine neue Datenbank, checken Sie git repo in einen neuen Ordner mit Release-Tag aus, holen Sie sich alle git-Submodule, führen Sie composer install –no-dev aus, richten Sie alle Aliase für freigegebene Ordner und Dateien wie hochgeladene Bilder ein und Konfigurationsdateien generieren, js/css mit grunt und less oder Äquivalent generieren, aktuellen Alias ​​auf den neuen Ordner mit dem Tag verweisen, Datenbankaktualisierungsskript ausführen, nginx/apache/fpm-php-Dienste neu starten, Tests durchführen, um zu überprüfen, ob die Website aktiv ist.

Haben Sie ein Skript, um zur vorherigen Version zurückzukehren (oder eine Anleitung, damit Sie wissen, was zu tun ist).

  • Sauber und einfach, aber es fehlen zwei wichtige Ordner: project/tests/ und project/class/ (so, dass die lib Ordner kann für Bibliotheken von Drittanbietern verwendet werden). Vielleicht haben Sie andere Vorschläge für die Struktur von Drittanbietern?

    – Wernacht

    3. Februar 2010 um 12:50 Uhr

Benutzer-Avatar
Mauris

Für enthaltene Kerndateien: approot/inc/

Für den Datenzugriff befinden sich Funktionen und Klassen in: approot/dao/

Für Javascripts: approot/scripts/

Für CSS: approot/styles/

Für Bilder: approot/img/

Für statische Inhalte (normalerweise für Benutzerprofilbilder oder hochgeladene Bilder): approot/static/

Für Caches: approot/caches/

Für Vorlagen oder View-Dateien: approot/templates/

Datei für alle Seiten: approot/

Struktur aus Samstyle PHP-Framework


Die Antwort, die ich hier gepostet habe, stammt aus dem Jahr 2009. Im Laufe der Jahre wurden weitere Standards veröffentlicht, darunter PSR-0 die das Thema zur Ordnerstruktur abdeckt. Ich habe auch eine neue (und meiner Meinung nach bessere) Ordnerstruktur mit Packfire-Framework.

  • @mauris verwendest du diese Struktur immer noch?

    – Sarah James

    25. Februar 2014 um 13:47 Uhr

  • @Sarah nein Nicht mehr. github.com/packfire/config oder Pakete in Packfire werden von mir erstellt und keines davon verwendet diese Struktur mehr.

    – Mauris

    26. Februar 2014 um 0:18 Uhr

  • @mauris danke, dass du dich bei mir gemeldet hast. Ich kämpfe ein wenig damit, meine Ordner zu strukturieren, und ich war sehr daran interessiert zu sehen, wie professionelle Entwickler das machen. Meine Ordner sind überall und das zwingt mich dazu, viele Regeln zum Umschreiben von URLs zu machen. Ich habe den Ordner heruntergeladen, verstehe aber, wonach ich suchen muss.

    – Sarah James

    26. Februar 2014 um 10:36 Uhr

Meiner Erfahrung nach kann man das nie planen. Sie können versuchen, dem zu folgen, was Frameworks tun, aber ich finde, dass ich nie genau in ihre Form passe.

Ich empfehle, nur eine gute Faustregel für maximal 20 Dateien in einem Verzeichnis einzuhalten. Wenn Sie feststellen, dass Sie mehr benötigen, erstellen Sie einfach ein paar Unterverzeichnisse und verschieben Sie gemeinsame Komponenten dorthin.

Benutzer-Avatar
Jefferson Lima

Dies ist meist eine Frage der Präferenz, eine schnelle Google-Suche würde viele verschiedene Projektstrukturen aufdecken. Aber es wäre wirklich schön, wenn es einen vereinbarten Standard gäbe. ich denke das Initiative von den PHP Package Development Standards ist ein guter Kandidat.

Dies ist die Verzeichnisstruktur, die sie vorschlagen:

  • Behälter/: ausführbare Befehlszeilendateien
  • Konfiguration/: Konfigurationsdateien
  • Dokumente/: Dokumentationsdateien
  • Öffentlichkeit/: Webserver-Dateien
  • Ressourcen/: andere Ressourcendateien
  • Quelle/: PHP-Quellcode
  • Prüfungen/: Testcode

BEARBEITEN:

Dies wird auch in der erwähnt PHP der richtige Weg im Abschnitt Gemeinsame Verzeichnisstruktur.

Benutzer-Avatar
Imrul

Ich verwende Codeigniter für kleine und große Projekte. Die MVC-Funktion ist mäßig gut.

  • codeIgniter\system\application\config : enthält alle Arten von Konfigurationsdateien wie DB, Zahlungsgateway, FTP-Konfiguration, Routen und …
  • codeIgniter\system\application\models: enthält alle Arten von Datenbankklassen, Sie sollten Unterordner nach Bedarf erstellen, ich verwendete Kunden, mailData, PaymentModel, Report, Web-Service und ….
  • codeIgniter\system\application\views: enthält alle Arten von Dateien, die als Ausgabe für Clients funktionieren, Sie sollten daran denken, diese Dateien nach Möglichkeit wiederzuverwenden. Wie bei den Modellen mussten Sie Unterordner wie Verwaltung, Berichte, E-Mail, E-Mail_Vorlage erstellen …..
  • codeIgniter\system\application\controllers : Dies ist der wichtigste Teil. Dies hilft beim Erstellen der SEO-URL, daher sollten Sie dieses Mal vorsichtiger mit Unterordnern umgehen. Sie können z. B. Verwaltung, Produkte, Berichte, Bestellungen usw. erstellen und sich einen guten Namen für die Funktionen der Controller-Klasse überlegen.

Diese waren für die PHP/HTML-Datei.

Nun zu den anderen Dateien:

  • codeIgniter\images: für die Bilder
  • codeIgniter\scripts: für die Java-Skripte und ihr Framework
  • codeIgniter\styles: für das CSS
  • codeIgniter\uploads: für die hochgeladenen Dateien, wenn Sie keine Dateien in die DB stellen möchten

Für Details siehe CodeIgniter-Framework im Detail.

Hier ist “codeIgniter\” die Approot

Benutzer-Avatar
Az.Youness

Dies ist die Struktur, die ich derzeit verwende,

public/           
  assets/         /* js, css, imgs, ... */
  index.php
src/
  config/         /* for config files */
  helpers/        /* for functions */
  libraries/      /* for free classes that are not MVC classes */
  models/         /* for M in MVC */
  views/          /* for V in MVC */                   
  controllers/    /* for C in MVC */
  vendor/         /* for vendors files */
  uploads/        /* for uploaded images, docs, ... */

1131000cookie-checkWas ist die skalierbarste PHP-basierte Verzeichnisstruktur für eine große Website?

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy