Laravel 5

Un installateur pour application Laravel 5.2 et 5.3

J’ai créé un nouveau package pour Laravel 5.3, avec exactement le même fonctionnement

 

Dans cet article il n’est pas question d’installation de Laravel avec composer mais de l’installation d’une application réalisée avec Laravel. Autrement dit une fois que vous avez installé Laravel avec le dossier vendor bien garni, que vous avez créé tous les fichiers spécifiques à votre application, y compris les migrations pour créer les tables de la base de données, et que vous voulez diffuser cette application qui doit être facile à installer pour le commun des mortels.

Pour faire cela rien n’est prévu au niveau du framework. C’est peut-être une lacune qui sera comblée à l’avenir, mais pour le moment il faut se retrousser les manches et coder cet installateur. Lorsqu’on jette un petit coup d’oeil au niveau des packages existants on ne trouve pas grand chose, essentiellement le package de Rachid Laasri qui est intéressant mais qui n’est pas vraiment adapté à un utilisateur de base, d’autre part il souffre de certaines lacunes.

Donc je me suis mis à la tâche et ça a donné ce package. Je me suis fortement inspiré de la procédure d’installation de WordPress pour le réaliser. Faisons un petit tour du propriétaire pour voir ce qu’il permet de réaliser…

Les fonctionnalités

Commençons par un petit tour d’horizon des fonctionnalités :

  • l’url de base pointe sur l’installateur en surchargeant celle de l’application, ainsi l’utilisateur tombe directement sur celui-ci et n’est pas obligé de taper une url spécifique
  • configuration du nom d el’application et de sa version
  • vérification de la version de PHP (on sait que Laravel réclame au minimum la version 5.5.9)
  • vérification des permission des dossiers où Laravel doit écrire (les dossiers dans storage et bootstrap/cache) avec possibilités dans ajouter avec la configuration
  • vérification des extensions de PHP (OpenSSL, PDO, Mbstring et Tokenizer) avec possibilités dans ajouter avec la configuration
  • permet la publication d’une application (par exemple vous avez toute votre application dans un dossier et vous voulez tout copier dans app et autres dossiers)
  • formulaire pour les renseignement nécessaires pour se connecter à la base de données (nom de la base, nom d’utilisateur, mot de passe et adresse de la base)
  • migration de la base
  • seed de la base si nécessaire
  • en option dans la configuration (activée par défaut) on peut prévoir l’enregistrement d’un administrateur avec un formulaire
  • on peut aussi prévoir un complément d’information après l’enregistrement de l’administrateur, par exemple pour ajouter des rôles
  • on change automatiquement la clé de sécurité (sinon toutes les applications auraient la même clé ce qui ne serait pas vraiment top pour la sécurité
  • et finalement on retire la référence du service provider de l’installateur dans la configuration

Installation de l’installateur

L’installateur est un package standard pour Laravel et donc son installation est classique :

Information dans composer.json :

require : {
    ...
    "bestmomo/laravel-installer": "dev-master"
}

Mise à jour avec composer :

composer update

Renseignement du service provider dans app.php :

Bestmomo\Installer\InstallerServiceProvider::class,

Publication des vues, traductions et de la configuration :

php artisan vendor:publish

Fonctionnement

Les permissions d’écriture

Au démarrage l’installateur commence par vérifier les droits d’écriture pour les dossier suivants (on peut en ajouter avec la configuration) :

  • storage/app
  • storage/framework
  • storage/logs/
  • bootstrap/cache

En effet Laravel a besoin de créer des fichiers dans ces dossiers.

S’il y a un problème il est signalé :

img63

Le texte apparaît ici en français, le package comporte aussi le langage anglais, et on peut en ajouter facilement d’autres.

La procédure est bloquée jusqu’à ce que le problème soit réglé.

PHP et ses extensions

Ensuite on vérifie la version minimale de PHP ainsi que la présence de ces extensions (on peut en ajouter avec la configuration) :

  • openssl
  • pdo
  • mbstring
  • tokenizer

S’il y a un porblème il est signalé :

img64

La procédure est bloquée jusqu’à ce que le problème soit réglé.

L’écran d’accueil

Si tout s’est bien passé dans les étapes préliminaires c’est totalement transparent pour celui qui installe l’application. Il n’y a aucun intérêt à lui signaler des étapes auxquelles il ne comprendra de toute façon pas grand chose.

Il tombe alors sur l’écran d’accueil :

img70

On lui indique ici clairement les données qu’il va devoir fournir.

Migration et seed

Lorsqu’on clique sur le bouton « C’EST PARTI ! » de la fenêtre précédente on arrive sur le formulaire pour l’entrée des renseignements pour la connexion à la base de données :

  • le nom de la base de données qui doit déjà exister
  • l’identifiant de l’utilisateur
  • le mot de passe
  • l’adresse de la base

Voici ce formulaire :

img65

Les valeurs présentes sont celles lues dans le fichier .env. Il n’y a pas de validation des entrées parce que de toute façon si elles sont incorrectes elles ne permettront pas de se connecter à la base. J’ai juste prévu un required en frontend hormis pour le mot de passe pour permettre une installation en local avec un MySql qui a sa configuration par défaut.

Avec les données saisies on tente une migration, on affiche une petite fenêtre pour faire patienter :

img71

en cas d’erreur on affiche cette fenêtre :

img66

On explique clairement à l’utilisateur les problèmes rencontrés. On lui propose de retenter une saisie.

Si la migration et les seed associés sont réussis on passe à l’étape suivante.

Création de l’administrateur

La création de l’administrateur est optionnelle (elle est prévue par défaut) avec un formulaire :

img67

La configuration permet de changer ces champs de saisie selon la constitution de la table des utilisateurs.

Ici on assure la validation des entrées (on utilise la validation prévue dans le contrôleur AuthController) :

img68

Si la validation passe il peut être réalisés des compléments d’information dans la base, par exemple pour ajouter des rôles pour l’administrateur.

On aboutit finalement sur cette fenêtre :

img69

La référence de l’installateur est supprimée du fichier app.php pour effacer les routes de l’installation et c’est terminé !

On propose alors une connexion à l’application (l’url du login est paramétrable dans la configuration).

La configuration

L’installateur est configurable dans le fichier config/installer.php :

  • on peut changer la version minimale nécessaire de PHP (en respectant évidemment le minimum pour Laravel !)
  • on peut ajouter des extensions de PHP au 4 prévues de base pour Laravel
  • on peut ajouter des permissions d’écriture pour les dossiers au 4 prévues de base pour Laravel
  • on peut définir le chemin pour la publication d’une application (publish-path)
  • url de connexion : on peut la changer
  • création de l’administrateur : il est optionnel

Pour l’ajout de renseignements supplémentaires pour l’administrateur il faut créer une méthode dans AuthController (respectez le nom pour que ça fonctionne) :

protected function userAddValues(User $user)
{
    // On crée une requête ici avec $user
}

L’utilisateur juste créé est transmis en paramètre.

Par défaut l’installateur utilise les méthodes validator (pour la validation de l’administrateur) et create (pour la creation de l’administrateur) du contrôleur AuthController. Mais la configuration permet de désigner une requête de formulaire pour la validation et une classe et un nom de méthode pour la création.

Je ne décris pas l’aspect technique de l’installateur, je le ferai peut-être si ça intéresse quelqu’un…

Print Friendly, PDF & Email

10 commentaires

  • bestmomo

    J’ai défini une nouvelle option (publish-path) dans la configuration qui est par défaut nulle. Il suffit de définir là le chemin vers la racine de l’application à publier, par exemple base_path('blog') et tout sera copié à la racine du site.

  • bonhoph

    Bonjour, alors bravo pour l’anticipation, sans mentir cette idée du « comment faire » m’est venu cette semaine, je n’ai grâce à vous plus besoin de chercher plus loin!

    Dans le même état d’esprit, et en suivant l’idée de votre article sur la création d’un package, il m’est venu cette idée très simple :

    1) Installer un lavarel tout frais
    2) Ajouter les dépendances « vendor » de paquets publics et disponible
    3) Ajouter la couche Interface qui elle n’est pas pacagé, mais configurée aux petits oignons et n’est pas forcement publique (tout ce qui va finalement être hors couche métier, cad dans app, public, resources, certaines migrations supplémentaires…). Grossomodo le Thème accompagnant le projet.
    4)Publication

    j’en suis donc venu à créer un répertoire contenant tout ce qu’il manque au vendor, et à me servir de AppServiceProvider pour écrire les nouveaux fichiers.

    par exemple

    [code]
    $this->publishes([
    __DIR__.’/../../packages/jusc/app’ => base_path(‘app’),
    ]);
    [code]

    avec un publish –force bien sur!!!

    pensez vous qu’il soit possible d’intégrer cette étape 3 avec votre package d’installation ?

    • bestmomo

      Bonjour,

      Je ne comprends pas très bien l’approche. A priori quand on fait une application avec Laravel on se retrouve au bout du développement avec un ensemble complet : les packages dans le vendor et tout ce qui caractérise l’application. Tout ça est donc finalisé et il ne reste plus qu’à installer, d’où l’installateur que je propose dans cet article.

      En fait je crois que je coince sur « tout ce qu’il manque au vendor » et qu’on doit transférer dans « app » puisque tout doit déjà être présent…

      Cordialement

      • bonhoph

        Simplement,
        1 ) j’instale un laravel tout frais
        2 ) j’ajoute les dépendances des packages
        3 ) je publie
        A ce moment précis je n’ai pas encore ajouté l’application, mais dispose d’une version de laravel « core » de base vierge et réutilisable

        Cette base ma permis de créer 2 projets distinct : 1 avec un système de blog, 2 un simple site vitrine
        vous comprenez que les vues , l’ensemble des fichiers de app etc peuvent avoir des versions différentes celons que l’on se place dans tel ou tel projet.

        J’ai donc créé deux répertoires : un blog et un site.
        chaque répertoire contient les branches (app,config,database,public,resources) avec dedans uniquement les fichiers utiles à l’application spécifique

        A cet instant je dispose
        – d’un répertoire contenant une version laravel fraiche + vendor
        – de 2 répertoires contenant les thèmes

        Maintenant, lorsque je veux créer un nouveau projet, il me suffis soit de cloner la version fraiche+vendor, soit d’en refaire une, d’ajouter l’un des thèmes dans le répertoire package et de me servir de AppServiceProvider pour « installer » l’application tel que décris dans mon message précédant.

        l’avantage de votre package est de pouvoir définir une nouvelle base de donnée et changer la clé, je trouve cela super!

        reprenons avec avec votre package

        Simplement,
        1 ) j’installe un laravel tout frais ou clone la version de base que j’ai déja
        2 ) j’ajoute les dépendances des packages y compris la votre
        3 ) je publie
        A ce moment précis je n’ai pas encore ajouté l’application, mais dispose d’une version de laravel « core » de base vierge et réutilisable et du script d’installation

        Je vais sur le site, et installe donc les nouveaux paramètres de la bdd et la nouvelle clé.

        Ne serait t’il pas possible de prévoir un step supplémentaire, permettant de choisir un thème (par exemple parcourir-> blog.zip), et que ce step se charge d’installer le dit thème, donc simplement de cloner les répertoires:app,config,database,public,resources du zip dans la branche du nouveau projet.

        Cette approche aurait l’énorme avantage de finalement n’avoir qu’une version de base contenant les dépendances , et aussi votre dépendance, celle ci se chargeant aussi d’installer tel ou tel thème.

        En espérant avoir été un peu plus précis 🙂

        Cordialement

        • bestmomo

          Cette fois j’ai compris 🙂

          Mais je vois un souci dans la démarche, pour la migration il faut le dossier database correctement renseigné, or le dossier app est vierge au départ puisque l’application spécifique doit être transférée dans une étape ultérieure.

          Il serait possible par contre de faire ce transfert dans une étape initiale du genre si on a dans la configuration des choses à transférer après vérification des prérequis alors hop on transfère (et ce zip se situerait où ?). Et la configuration de la base se ferait ensuite parce que cette fois on aurait les renseignements pour la migration.

          Toutefois la question que je me pose concerne la généralisation de la démarche parce que ça implique que plusieurs applications ont exactement les mêmes dépendances dans le vendor, ce qui n’est pas forcément répandu. J’ai donc l’impression que c’est une option assez spécifique, pour ne pas dire isolée.

          • bonhoph

            et bien pour la généralisation, sincèrement, je sais qu’avec les dépendances suivantes je peu de base assurer tout ce que demande la gestion d’un site basique , et de toute facon les « themes » sont préparés en concordance avec les dépendances. Donc comme de toute facon a un moment il faut gérer les dépendances , cela ne pose en aucun cas de problème ( et oui car de toute facon a un moment il faut ajouter la votre , au moins une fois, comme les autres d’ailleurs) . Il s’agit simplement d’avoir d’un coté une base « vendor » bien propre, et de l’autre des themes applicatifs a installer. Votre package permettrait donc en plus d’importer le theme qui va bien.

            « php »: « >=5.5.9 »,
            « laravel/framework »: « 5.2.* »,
            « bican/roles »: « 2.1.* », // gestion des roles et permissions
            « kalnoy/nestedset »: « ^4.0 », // gestion des catégories
            « maddhatter/laravel-fullcalendar »: « ~1.0 »,// calandrier
            « spatie/laravel-medialibrary »: « ^3.14 » // medias

Laisser un commentaire