Salut les gens,
La partie technique est terminée. Il existe donc une distribution alternative à celle, classique et traditionnelle, de SPIP, installable via composer, dans la nature ^^
Pour tester son installation, tapez : composer create-project geodiv/geodiv
CQFD 
Pour la rédaction de l'article, le dernier pour ce projet d'intégration de Composer dans SPIP ne sera pas pour tout de suite. Je vais manquer de temps dans les jours qui viennent et je suis un peu fatigué. J'ai besoin de repos.
Merci pour ce boulot !
Faut embrayer maintenant.
Hey ho let's go!
Bon je sais c’est une liste de gurus du code , de pro de la ligne de code et j’en passe et des meilleurs.
J’apprécie énormément de la lire , je suis stupéfait du boulot réalisé a chaque fois, je n’interviens que très très rarement n’ayant pas les compétences
mais la j’ai vraiment un problème de compréhension sur l’installation de spip
j’ai lu
Composer intervient essentiellement pendant la phase de développement. Mais il peut aussi avoir son utilité pendant la phase de packaging voire pour une partie du déploiement d’une application web.
James, 30 mars 2018, minuit 8.
donc si je pige composer permet de dev mais pas d’installer spip, l’install de spip c’est toujours FTP ou spip_loader.php.
j’ai plein d’autre question mais bon c’est ptet pas la liste pour …
Bon je sais c'est une liste de gurus du code , de pro de la ligne de code
et j'en passe et des meilleurs.J'apprécie énormément de la lire , je suis stupéfait du boulot réalisé a
chaque fois, je n'interviens que très très rarement n'ayant pas les
compétencesmais la j'ai vraiment un problème de compréhension sur l'installation de
spipj'ai lu
Composer intervient essentiellement pendant la phase de développement.
Mais il peut aussi avoir son utilité pendant la phase de packaging voire
pour une partie du déploiement d’une application web.James, 30 mars 2018, minuit 8.
donc si je pige composer permet de dev mais pas d'installer spip,
l'install de spip c'est toujours FTP ou spip_loader.php.
Il y a, très génériquement, plusieurs étapes pour arriver à ses fins :
1/ Développer son site SPIP correspond, en gros à :
1.1/ Récupérer sur sa machine et assembler le code de SPIP, ses plugins,
d'autres plugins. Et il y a plusieurs méthodes déjà.
1.2/ Installer : lancer le site, paramétrer la base de données, activer des
plugins "dist" ou "core"
1.3/ Personnaliser avec des surcharges (répertoire squelettes et
mes_options.php), avec du paramétrage de tout type tel qu'ajout et
activation de plugins, d'options, dans l'espace privé
2/ Déployer son site SPIP correspond à :
2.1/ Envoyer l'ensemble du code (SPIP + Personnalisation), là aussi, il y a
plusieurs méthodes, dont FTP ou spip_loader.php. Par contre,
spip_loader.php n'est pas très pratique pour la partie personnalisation.
2.2/ Reproduire le paramétrage qui ne se fait que par l'espace privé sur le
site.
3/ Exploiter son site SPIP correspond à faire des sauvegardes de base de
données et du fond documentaire (répertoire IMG), vider le cache, importer
ou exporter des données, etc.
4/ Maintenir son site SPIP correspond à récupérer tout ou partie du
paramétrage effectué sur le site sur sa machine, faire des modifications
sur sa machine, faire des mises à jour du code de SPIP, de ses plugins,
d'autres plugins, ajouter de nouveaux plugins et resynchroniser le site
avec les modifications qu'on a fait sur sa machine. Cela revient à faire
une partie des étapes 1/ et 2/
Donc :
L'équipe chargée de distribuer SPIP et ses plugins peut s'appuyer sur
composer pour la mise à disposition sur Internet qui permettra au webmestre
de faire l'étape 1.1
Composer peut intervenir pour la partie 1/ et 4/ pour un webmestre :
récupérer, mettre à jour SPIP, des plugins, mais aussi ajouter d'autres
composants qui ne seraient ni SPIP, ni plugins.
L'équipe chargée de faire fonctionner spip_loader.php pourrait faire
évoluer ce script afin qu'il s'appuie sur ce qui serait fait par l'équipe
chargée de distribuer SPIP
Concernant la partie 2/ ça dépend... mais ça dépend déjà aujourd'hui.
j'ai plein d'autre question mais bon c'est ptet pas la liste pour ...
Si, si, c'est la liste pour
Hop,
Pour tester son installation, tapez : composer create-project
geodiv/geodiv
Ah je dois avoir un paramétrage différent quelque part :
ben@ben-ant:~/tmp$ composer create-project geodiv/geodiv
[InvalidArgumentException]
Could not find package geodiv/geodiv with stability stable.
je voulais jouer aussi…
peut-être que moi aussi et pourtant j’ai rien personnalisé du tout, je viens de taper ceci : curl -sS | php php composer.phar create-project geodiv/geodiv = [InvalidArgumentException] Could not find package geodiv/geodiv with stability stable in a version installable using your PHP version 7.2.6.
Hop,
Geodiv est basé sur spip 3.1 qui n’est compatible que jusqu’à php 7.1
https://www.spip.net/fr_article4351.html
Donc tout est normal 
Pour installer sans tenir compte de cette contrainte :
composer create-project —ignore-platform-reqs geodiv/geodiv
« Moins-moins ignore … »
C’est les premières lignes de l’article en cours de rédaction
Hop,
Re,
Testé et approuvé, ça fonctionne, c'est beau
Petites précisions, l'ancienne interface de gestion des plugins ne semble pas prendre en charge l'import des librairies nécessitées par les plugins dans le dossier lib à la racine.
Pour terminer pleinement l'installation et permettre d'activer tous les plugins nécessaires, il faut donc faire ceci à la racine du projet :
mkdir lib && cd lib
wget https://github.com/brandonaaron/jquery-mousewheel/archive/3.1.4.zip
unzip 3.1.4.zip
wget http://www.mediaspip.net/IMG/zip/swfupload_v2.2.0.1_core.zip
unzip swfupload_v2.2.0.1_core.zip
mv SWFUpload\ v2.2.0.1\ Core/ SWFUpload_v2.2.0.1_Core
Et hop
C’est SVP, me semble-t-il qui fait ça, non ?
Il a pas été “composerisé”, donc, il est pas distribué dans le cadre de cette maquette. (c’est précisé dès le préambule de SPIPRemix)
et l’article est en ligne : https://spip.lerebooteux.fr/Faire-une-distribution-alternative-et-conclusion
A+
Hello 
Si je comprends bien, le create-project met à la racine les fichiers du paquet spip/spip ou geodiv/geodiv.
On est d’accord que du coup, un composer update ne mettra pas à jour ces fichiers racine ? En général on n’y touche effectivement pas, mais ça sera à préciser quand même probablement.
J’aimerais bien faire un petit point pour savoir ce qu’il reste à faire, à réfléchir, quels sont les décisions à prendre, etc.
Sur Composer
Sur les usages
--------------Composer et Git modifieraient grandement les usages en basculant dessus.
Est-ce que notre petite communauté d’utilisateurs de la zone est prête à basculer ? J’ai le vague sentiment que oui (composer et git se sont largement démocratisés).Ça nécessite tout de même de revoir grandement le Spip Loader pour l’installation facile sans terminal (mais dans ce cas là il faut que SVP puisse continuer à télécharger de lui même les plugins…).
Ou doit-on dire, maintenant, pour installer SPIP, il faut un accès shell ? installer composer, et lancer le create… les require… ?
Est-ce que ça ne va pas un peu à l’encontre d’une simplicité/facilité d’usage que l’on souhaitait ?
A mon sens, il faut que SPIP puisse encore être installé classiquement en telechargeant le loader/un zip et en envoyant par ftp.
Sinon, on risque de perdre de tas d'utilisateur/trices qui n'ont accès qu'ầ du ftp...
J'imagine que SPIP ne sera pas le seul CMS a proposer les deux modes d'installations non?
On pense, on croit, on imagine, mais en vérité, je te le dis, on ne sait
rien, sinon une chose : on perd des utilisateurs tous les jours et ceci
depuis le début 2014 alors qu'on n'est en rien responsable des transferts
ftp qu'ils peuvent faire mais qu'ils ne font pas. Ce n'est pas un risque,
c'est un fait.
Un autre fait est qu'on ne sait pas quelle proportion d'utilisateurs
déploient du SPIP avec "spip_loader" ou par "téléchargement manuel de
zip+ftp" ou "svn local+ftp" ou "ssh+svn" ou "apt sur debian" ou
"ssh+spip-cli" ou "yunohost" ... ou tout autre combinaison, en fonction des
besoins, de ce que permet l'espace privé, de l'hébergeur et de ce qui est
requis pour des plugins ou des "libs" à "installer".
D'après ce que j'observe, c'est probablement le contraire qui se produit :
on perd des utilisateurs depuis 4 ans et demi, parce que nous n'avons pas
fait évoluer nos méthodes de déploiement. Mais, je l'accorde par avance,
c'est peut-être un biais de confirmation de ma part. (attention humour : )
Mais, du coup, je rétorque que peut-être, mais moi, je cherche à corréler
des faits, je ne me contente pas d'imaginer ou de croire. (fin humour)
Bref, tout ça pour dire que si le seul argument pour demander à la
communauté de maintenir spip_loader, c'est qu'on pourrait perdre des
utilisateurs, je le considère comme irrecevable tant qu'on ne m'aura pas
apporter la preuve que c'est ce dont les utilisateurs encore les plus
actifs sont le plus dépendants.
J'ajoute aussi que je ne connais pas beaucoup d'hébergeurs qui fournissent
un accès à leurs machines avec (s)ftp comme seule méthode de déploiement.
Toutefois, rien n'empêche, si on n'a pas d'accès ssh à un serveur hôte, de
déployer à peu près n'importe quelle application basée sur autre chose que
SPIP avec (s)ftp. Il existe même, si on cherche bien, de quoi automatiser
ces déploiements et gérer les fichiers à supprimer. Si d'autres peuvent le
faire, SPIP peut continuer à le faire.
Enfin, il est difficile, voire impossible, de prouver l'inexistence de
quelque chose, mais je peux au moins dire que je ne vois plus, depuis
quelques années, de méthode "web" d'installation "à la spip_loader"
d'autres applications web, sur le plan officiel en tout cas.
D'ici-là, il y a plein d'autres points soulevés par Matthieu qui méritent
aussi des réponses.
Parmi les choses oubliées, il y a la question des traductions/fichiers de
langue
Amicalement,
Oups, renvoi sur la liste aussi ^^
Bonsoir,
Bref, tout ça pour dire que si le seul argument pour demander à la communauté de maintenir spip_loader, c’est qu’on pourrait perdre des utilisateurs, je le considère comme irrecevable tant qu’on ne m’aura pas apporter la preuve que c’est ce dont les utilisateurs encore les plus actifs sont le plus dépendants.
Euh… Je ne peux pas apporter de preuve, je peux juste apporter un témoignage : je me sers de spip_loader.php et je suis fan des dernières mises à jour qui permettent encore plus de sécurité et de simplicité dans l’upload des mises à jour.
J’utilise aussi quasi quotidiennement svp, intégré aux plugins-dist.
Bientôt j’aurai beaucoup plus de temps et très probablement j’arriverai à passer le blocage qui fait que je n’arrive pas à créer et utiliser un accès SSH. Probablement je bute sur une virgule placée au mauvais endroit, ou un truc du genre… Donc quand je pourrai m’en occuper de façon un peu plus continue probablement je passerai ce blocage très vite.
En attendant j’ai besoin de spip_loader et je continue de déplorer qu’il faille encore créer manuellement par ftp les dossiers plugins/auto pourtant indispensables à un fonctionnement basique de SPIP (SPIP sans plugins… hum…). En plus lorsqu’il faut expliquer ça à des gens alors on arrive sur une autre planète (ou eux ont l’impression d’arriver sur une autre planète)
Si SPIP perd des utilisateurs je crois que c’est à cause de cette complexité. De la même façon qu’il y a la complexité/opacité sur la gestion des images et documents discutée par ailleurs. Aussi probablement il y a une question de « business oriented » : maintenant les gens veulent du WP parce que c’est « quand même 60% du marché » ou du Drupal parce que sa complexité assure à l’entreprise qui l’installe de la maintenance à long-terme ^^
Alors, en ce qui me concerne… bientôt je serai retraité et je pourrai sans doute apprendre à maîtriser la ligne de commande qui semble une garantie de qualité
Mes deux sous,
Cheers,
Jacques
Je réponds à James.
Spip_loader est super pratique et très simple à utiliser pour peu qu’on soit bien connecté à Spip en webmestre : rapide, efficace, sans prise de tête, sans peur d’écraser des fichiers…
C’est surtout en mise à jour que c’est le plus simple et surtout ultra rapide, le plus long étant de faire une sauvegarde complète. Quand on a un ou des sites à fort trafic sans être développeur soit même, c’est un élément très important. Sans spip_loader ce sera ftp pour moi et quand on a un adsl de merde, on en a pour un temps certain.
Par exemple j’utilise depuis peu revive adserver et rien que lire la procédure de maj donne mal au crane : https://www.revive-adserver.com/support/upgrading/
Si Spip a perdu des utilisateurs, c’est très certainement par son côté ringard sur le plan esthétique jusqu’à récemment sur certains sites mais pas tous (contrib mériterait un coup de jeune), sur la rareté de thèmes modernes et jolis, sur l’absence quasi intégriste de toute forme de marketing ou à minima de mise en valeur des points forts du CMS. Quand on me demande et que je réponds que je suis sur spip, on me regarde comme un extraterrestre.
Par pitié, laissez-nous spip_loader
Guilain
Puisque temoignages demandés, j'installe presque exclusivement SPIP par spip_loader.php,
bien plus efficace et rapide que FTP, et je deplore que la creation automatique de ./plugins/auto ./squelettes ./lib ne soit toujorus pas automatique (jamais bien compris pourquoi ? pour les mutualistes ??? ) ; idem pour les mises-à-jour, encore plus simples et securisées (mieux que le FTP !)
J'en suis meme a préférer installer SPIP en local par spip_loader plutot que par TC !!
Je dois bie utiliser spip_loader deux fois par jour en moyenne.
Quant a SSH, ou pire les CLI et autres composer... c'est des trucs de dev ! j'ai passé l'age
mes deux pouces
Bonsoir,
Je suis et je resterais un éternel débutant,je n’ai pas le temps (ni l’envie) de vraiment creuser la matrice SPIP 'référnce a Matrix).
je ne suis pas informaticien, ni codeur de métier (sans doute d’autre aussi) et SPIP et le code ne font pas partie des choses qui me remplisse l’assiette.
c’est simplement que je trouve la communauté cool que c’est en français et que j’ai toujours eu réponse a mes soucis.
Donc ne changer rien et ce qui est a la mode aujourd’hui passera demain.
toutefois je vais tacher d’apporter mes deux sous
Un autre fait est qu’on ne sait pas quelle proportion d’utilisateurs déploient du SPIP avec « spip_loader » ou par « téléchargement manuel de zip+ftp » ou « svn local+ftp » ou « ssh+svn » ou « apt sur debian » ou « ssh+spip-cli » ou « yunohost » … ou tout autre combinaison, en fonction des besoins, de ce que permet l’espace privé, de l’hébergeur et de ce qui est requis pour des plugins ou des « libs » à « installer ».
j’utilise spip_loader pour les mise a jour et installation de SPIP
j’utilise le téléchargement manuel et zip et ftp lorsque je dois chercher une version inferieur que la stable pour pouvoir aider quelqu’un
svn local et ftp je n’ai pour le moment pas vraiment eu besoin de travailler en local donc j’utilise pas
ssh et svn j’ai du mal,c’est très geek mais bon quand je suis obligé je me force
apt debian jamais mais je vais le faire puisque je vais me monter un spip local sur ma debian 9 toute fraiche (ben oui j’ai quitté windows)
ssh + spip-cli Houla la j’ai peu que cela concerne plus les pro
ynohost a j’avais tenter l’aventure yuno mais j’ai jammais reussie a faire fonctionner la bête.
le truc qui me gène le plus en ce moment je peu pas mettre a jour mes plugins que je met dans plugins_dist par SVP
Mais BRAVO pour avoir fait de SPIP un truc accessible, c’est plus accessible pour moi que joomla ou drupal,
moins de thèmes tout fait est a la mode que wordpress
moins ringard que guppy ou frontpage
D’après ce que j’observe, c’est probablement le contraire qui se produit : on perd des utilisateurs depuis 4 ans et demi, parce que nous n’avons pas fait évoluer nos méthodes de déploiement. Mais, je l’accorde par avance, c’est peut-être un biais de confirmation de ma part. (attention humour : ) Mais, du coup, je rétorque que peut-être, mais moi, je cherche à corréler des faits, je ne me contente pas d’imaginer ou de croire. (fin humour)
pour ceux qui est de la perte des utilisateurs cela ne concerne que du vécu
ceux et celles que j’ai croisé qui quitté SPIP
- Documentation trop éparpillé malgré quel soit complète, il est ou le site d’entré et le moteur de recherche
- trop de plugins et en plus sont pas a jour et il marche pas suffit de lire les commentaires sur contrib
- les plugins ça marche , ça marche pas des fois il rentre en conflit entre eux
- pas html5
- pour les smartphone ya pas de thémes
- c’est quoi tous les SPiP différent , c’est quoi la différence (z, dist, etc …)
voila ce que j’ai pu entendre …
mais moi oui moi
J’en profite pour remercier chaleureusement, sincèrement et du fond du cœur tous ceux qui font SPIP
- Les créateurs et développeurs de la bête
- Les contributeurs de spip-contrib
- Les concepteurs de plugins
- Les utilisateurs de la liste Spip qui m’ont maintes fois aidé
- L’IRC et ses différent salon de discussion
et tous ceux qui d’une façon ou d’une autre me font évoluer.
J’ai pu construire mon site, en local et le transféré chez mon hébergeur, avec l’aide de tous, en me contentant de réutiliser ce qui a été fait par d’autres et en l’adaptant (légèrement) à mes besoins.
c’est la première façon de dire merci.
J’essaye de citer le plus scrupuleusement possible mes sources et je donne l’accès a mon site :
c’est une deuxième façon de dire merci.
J’essaye d’aider les débutants quand mes modestes connaissances le permettent :
c’est une troisième façon de dire merci.
Et tout en n’étant en rien informaticien, codeur ou développeur, je me permets même de former les utilisateurs à monter leur propre site ou Pc :
c’est encore une façon de dire merci.
Alors oui, un grand merci à tous ceux qui font de SPIP.