Personne ne niera que Composer est un outil assez pratique et qu'il existe des hébergeurs gratuits ou bon marché qui ne fournissent aucune console ou outil intégré pour travailler avec Composer. C'est exactement le genre de pile que j'ai rencontré. Eh bien, comme l'a légué le Jedi, le
fournisseur est immédiatement ajouté à
.gitignore afin de ne pas encombrer leur référentiel et de ne pas faire aller et venir les bibliothèques.
La première chose qui m'est venue à l'esprit était de rendre un script accessible à partir du Web, qui peut être extrait au bon moment et il mettra à jour les dépendances ou les installera.
Pour ce faire, nous devons effectuer quelques manipulations.
1. Pour installer le compositeur localement, nous
devons télécharger composer.phar .
2. Créez un dossier où il sera décompressé (que ce soit
var ).
3. Créez
composer.json (enfin, à propos de celui-ci, je pense que vous savez déjà si vous avez travaillé avec composer).
4. Eh bien, créez le script lui-même pour travailler avec le compositeur à partir du Web (que ce soit
composer.php ).
Nous avons donc la structure de notre futur site:
Composer.phar lui -
même sera le suivant:
<?php use Composer\Console\Application; use Symfony\Component\Console\Input\ArrayInput; use Symfony\Component\Console\Output\StreamOutput;
Et si vous êtes un gars heureux. Après avoir appelé le script, il développera le dossier du
fournisseur .
Mais je ne me suis pas avéré comme ça) La première chose qui a brisé mes plans a été de mettre
phar.readonly = On dans
php.ini , et comme vous l'avez peut-être deviné sur l'hébergement gratuit, vous ne pouvez généralement pas le modifier. Ensuite, j'ai commencé à chercher des solutions de contournement.
La première chose que j'ai essayée a été de créer
user.ini qui remplacera les paramètres de
php.ini , cela a fonctionné sur la machine locale) Mais sur l'hébergement, cette fonctionnalité a été poignardée.
Ensuite, j'ai essayé d'utiliser une astuce de plus. Renommez
composer.phar en juste
composer , le résultat est le même. Cela a fonctionné sur le LAN, mais pas sur l'hébergement.
Ensuite, tout de même, au lieu d'un script, j'ai dû décompresser les fichiers localement dans
var et les télécharger sur le serveur.
Il vaut également la peine de fermer le script avec autorisation, afin que toutes sortes de personnes ne l'appellent pas. Toujours dans la version finale du script, j'ai ajouté le choix de la commande via les paramètres.
<?php use Composer\Console\Application; use Symfony\Component\Console\Input\ArrayInput; use Symfony\Component\Console\Output\BufferedOutput; use Symfony\Component\Console\Output\OutputInterface;
De plus, cela ne fait pas de mal d'ajouter une règle à
.htaccess pour transmettre l'en-tête d'autorisation (dans le cas de CGI) et une redirection vers HTTPS, car l'autorisation reste en clair.
RewriteEngine On # CGI, , RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] # HTTPS, RewriteCond %{HTTPS} off RewriteCond %{HTTP:SSL} !=1 [NC] RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [R=302,L]