Nous allons maintenant voir comment est organisé Laravel 4. A l’issue de l’installation nous avons quelques fichiers et 4 dossiers :

img07

Le dossier public est le seul qui doit être accessible à l’utilisateur. C’est le dossier qui va héberger vos images, vos fichiers CSS, vos scripts…

Le dossier vendor contient toutes les librairies utilisées par Laravel et vous n’avez normalement pas à intervenir directement dans celles-ci.

Le dossier app est celui qui va contenir votre application, c’est votre terrain de jeu, vous y mettrez vos modèles, vos contrôleurs, vos vues, vos assets…

Le dossier bootstrap contient des fichiers qui gèrent le démarrage de Laravel.

Voici un schéma résumé de cette organisation :

img54

 

Le dossier public

Au départ ce dossier ne contient pas grand chose, essentiellement le fichier index.php qui est la porte d’entrée de l’application et un fichier htaccess :

img100

Il contient aussi un fichier d’icône vide favicon.ico.  Les navigateurs cherchent par défaut ce fichier pour afficher l’icône du site. Vous pouvez donc l’adapter à vos besoins (une image de 16 * 16 px).

Il contient aussi le fichier robots.txt qui indique aux robots d’indexation de sites les pages qu’ils doivent explorer. Par défaut tout est indexé. Si vous désirez un comportement différent vous devez renseigner ce fichier en conséquence.

Le fichier index.php

C’est la porte d’entrée unique de l’application. Il ne contient que très peu de code dont voici l’essentiel :

  • Lancement du chargement automatique créé par Composer :
    require __DIR__.'/../bootstrap/autoload.php';
  • Inclusion du fichier de démarrage :
    $app = require_once __DIR__.'/../bootstrap/start.php';
  • Lancement de l’application :
    $app->run();
  • Et pour finir :
    $app->shutdown();

Vous voyez donc que l’essentiel de la machinerie se situe dans la partie cachée…

Le dossier app

C’est le dossier dans lequel vous allez créer votre application, il contient deux fichiers et est subdivisé en sous-dossiers :

img08Voyons d’abord les deux fichiers :

  • routes : contient les définitions des chemins d’entrées pour l’utilisateur, autrement dit les URI possibles et les dirige sur la classe qui doit traiter l’information,
  • filters : contient les définitions des filtres appliqués aux chemins, autrement dit les actions à effectuer juste avant ou après.

Voyons maintenant les dossiers :

  • commands : prévu pour contenir vos commandes personnelles pour « artisan », un utilitaire en ligne de commande de Laravel,
  • config : contient des éléments de configuration pour changer l’aspect et le fonctionnement de Laravel,
  • controllers : contient les controleurs (shéma MVC), il est à noter que l’utilisation de controleurs n’est pas indispensable avec ce framework parce que le système de routage est très performant comme nous le verrons par la suite,
  • lang : contient des fichiers avec du texte évidemment en anglais à la base,
  • models : contient les classes qui représentent le modèle de données de l’application (shéma MVC)
  • start : contient les fichiers de démarrage de votre application,
  • storage : stockage d’informations temporaires diverses : sessions, logs, vues compilées, caches…
  • views : contient les vues, ce sont les fichiers destinés à présenter la réponse à l’utilisateur (shéma MVC), utilisées par les routes et les contrôleurs,
  • tests : pour vos tests unitaires à lancer avec artisan,
  • database : contient les migrations (modifications de la base de données) et les seeds (remplissage des données).

Configuration

Laravel nécessite très peu de configuration. Ouvrez le fichier app/config/app.php et trouvez cette ligne :

'key' => 'YourSecretKey!!!',

Ici vous devez entrer votre clé secrète composée de 32 caractères alphanumériques. Il est possible d’en créer une dans l’invite de commande avec l’outil « Artisan » dont nous parlerons un jour. Pour le moment vous pouvez l’utiliser pour générer la clé :

img13

La clé est directement inscrite dans le fichier app/config/app.php.

Vous trouvez dans le même fichier cette ligne :

'locale' => 'en',

Évidemment vous pouvez entrer fr à la place mais auparavant il aura fallu prévoir les fichiers correspondant avec la traduction ! Nous verrons cela plus tard, pour le moment laissez en.

Laravel est prévu à la base avec un fichier htaccess pour ne pas voir apparaître  index.php dans les URL :

<IfModule mod_rewrite.c>
    Options -MultiViews
    RewriteEngine On
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^ index.php [L]
</IfModule>

Mais évidemment ça ne fonctionne que si le module mod_rewrite est activé dans votre version d’Apache. Si ce n’est pas le cas il faudra supporter des URI plus longues et moins esthétiques…

L’environnement

Selon l’environnement dans lequel nous utilisons Laravel, nous n’avons pas les mêmes besoins. Par exemple nous allons éviter d’avoir des erreurs qui s’affichent sur un serveur de production alors que ça nous arrange lors du développement. Si nous utilisons une base de données elle ne sera pas forcément en localhost en production. En cours de développement nous voudrons aussi sans doute intercepter l’envoi des emails.

Regardez ce code dans le fichier bootstrap/start.php :

$env = $app->detectEnvironment(array(
   'local' => array('homestead'),
));

Laravel détecte automatiquement l’environnement dans lequel il s’exécute. C’est ici qu’il vavoir pour définir l’environnement. On se rend compte qu’il a pour le moment peu de choix.

homestead fait référence à un environnement Vagrant disponible pour Laravel depuis la version 4.2.

C’est à vous de définir les environnements dont vous avez besoin. En général il vous suffit d’un environnement local de développement. Par exemple :

$environments = array(
   'local' => array('nom_de_ma_machine'),
);

Ici j’ai défini les l’environnement local en spécifiant le nom de ma machine (ce que retourne la fonction gethostname()). Il existe un dossier app/config/local. Il suffit de mettre dans ce dossier les fichiers de configuration avec seulement les valeurs que l’on veut spécifiques. Par défaut il y a déjà un fichier app/php qui fixe la valeur du debug à true. Il y a aussi un fichier database.php parce que forcément la configuration de la base sera différente en local et à distance.

Depuis la version 4.1 on ne prend plus en compte l’url comme référence à cause de problèmes de sécurité.

  1. Ktalyst

    Bonjour,
    J’aimerai vraiment savoir comment vous avez fait pour la mise en prod’ sur un serveur mutualisé. J’ai choisi olympe. J’ai essayé tous les tutos possibles et au mieux je me retrouve avec une page blanche…

    • Author bestmomo

      Salut,

      La première question est : est-ce que SSH est disponible ? Ensuite si les commandes nécessaires sont disponibles (par exemple chez OVH ce n’est pas le cas). Dans tous les cas en FTP on doit pouvoir s’en sortir.
      D’autre part si tu risques de devoir modifier l’organisation des dossiers si tu as accès seulement au dossier public.

  2. Jowy

    Bonjour et tout d’abord merci pour ce tutoriel que je vais continuer à suivre avec attention.

    Juste une petite remarque dans l’environnement start.php est dans bootstrap/ et non dans app/bootstrap/.

  3. christoff

    Pour les novices comme moi, je vous donne un petit retour d’expérience sur la mise en production de mon site perso sur l’hébergeur. Voici un exemple de checklist des fichiers et paramètres qui peuvent être modifiés entre la configuration de votre localhost et celle de votre hébergement.

    app/start/global.php/App::error(){}
    app/config/app.php/debug
    app/config/database.php/default
    app/config/database.php/host
    app/config/database.php/database
    app/config/database.php/username
    app/config/database.php/password
    app/config/mail.php/driver
    public/.htaccess

    Dans mon cas, mon hébergeur 1and1 ne tient pas compte du fichier .htaccess par défaut et il n’accepte pas le driver smtp pour les mail. Il faut aussi vérifier la version php de l’hébergeur. J’ai changé l’option 5.3 vers 5.4.
    Sinon pour le reste c’est impeccable. Comme je suis sur un serveur partagé, j’ai simplement téléchargé les fichiers par le client ftp. C’est rapide et cela fonctionne. Super.

    • Author bestmomo

      Merci pour le retour. Au sujet du fichier htaccess tu avais laissé un autre commentaire où du disais avoir résolu le problème !

      Apparemment 1&1 n’autorise pas les accès SSH. C’est dommage, pour déployer une application Laravel autant choisir un hébergeur qui l’autorise, c’est quand même plus pratique.

      • christoff

        Pour .htacces j’ai effectivement posté sur l’autre chapitre. Pour les mails j’ai simplement changé le driver par défaut.
        Avec le code suivant cela fonctionne pour mon hébergeur.
        'driver' => 'mail',
        D’une façon générale, je crains que les hébergeurs soient un peu dépassés par la mise à jour de leur documentation. Les CMS et les frameworks-php nécessitent certaines ressources et certains réglages précis. C’est toujours sur des blogs d’utilisateurs qu’on trouve les solutions.

  4. dav

    Merci pour ce tuto précis et clair.

    Une question : j’ai bien compris l’intérêt de ne pas permettre l’accès aux autres répertoires que public/
    Mais alors comment faire, si je fais [http://]localhost/laravel, j’ai accès à toute l’arborescence.

    De plus, devoir saisir le répertoire public/ ne sert pas à grand chose, comment faire pour afficher le site uniquement en utilisant [http://]localhost/laravel ?

    Merci par avance

    • Author bestmomo

      Là tu raisonnes avec un serveur local en localhost, normal que tu aies accès à tout. Mais si tu considères ton site en ligne tu vas faire pointer ton domaine machin.fr directement sur le répertoire public. Tout ce qui est en dessous ne sera pas accessible.

  5. christoff

    Bonjour,
    D’abord grand merci à bestmomo pour ce tutoriel.
    J’avais déjà suivi le tutoriel sur Bootstrap qui forme un beau couple avec Laravel.

    J’ai une petite précision pour les néophytes comme moi : le fichier htaccess est un fichier qui est caché par défaut. Il faut donc configurer l’affichage des fichiers cachés.

    J’ai maintenant une question sur l’environnement. Je travaille sur un serveur local LinuxAMP et j’ai l’habitude d’utiliser exclusivement un client FTP pour y mettre mes fichiers car sinon cela me posait des difficultés. J’ai donc une copie du framework en dehors du répertoire du serveur LAMP afin de pouvoir éditer les fichiers de travail et mettre à jour le framework si besoin. Après chaque modification je dois envoyer les fichiers modifiés par le client FTP. Est-ce-que c’est la bonne façon de faire ? Je me pose également la question pour le serveur de mon hébergeur. Quels sont les fichiers qui doivent être envoyés et ceux qui ne sont pas nécessaire. Je n’ai pas vu la réponse dans votre tuto.
    Pardon pour mes questions de néophyte et encore merci.

    • Author bestmomo

      Le FTP est la solution ultime quand on a rien de mieux. Il faut tout envoyer sauf ce qui est stocké dans « storage » et les éventuels dossiers git. Pour le serveur local pas de souci on peut bidouiller comme on veut. Pour le distant c’est une autre histoire. L’idéal est d’avoir un accès SSH, on peut alors utiliser composer et artisan. Quand on l’a pas, ce qui est souvent le cas sur des mutualisés, c’est plus délicat. Il y a un article intéressant sur le déploiement ici.

Laisser un commentaire