Je suis en train de séparer un site sous spip en deux sites: en gros, à peu près un tiers des articles doivent se retrouver d'un côté et le reste de l'autre. Le problème est que le site initial comprend plus de 2500 articles.
J'ai donc copié la base de données, et réinstallé un deuxième spip et je me dis que je vais supprimer de chaque côté les articles qui ne doivent pas s'y trouver.
Et, franchement, ça prend un temps dingue. Ne serait-il pas utile de donner, dans l'interface privée, la possibilité de supprimer une rubrique et tous ses articles d'un coup plutôt que de forcer à supprimer chaque article avant d'autoriser la suppression de la rubrique?
Je suis en train de séparer un site sous spip en deux sites: en gros, à peu près un tiers des articles doivent se retrouver d'un côté et le reste de l'autre. Le problème est que le site initial comprend plus de 2500 articles.
J'ai donc copié la base de données, et réinstallé un deuxième spip et je me dis que je vais supprimer de chaque côté les articles qui ne doivent pas s'y trouver.
Et, franchement, ça prend un temps dingue. Ne serait-il pas utile de donner, dans l'interface privée, la possibilité de supprimer une rubrique et tous ses articles d'un coup plutôt que de forcer à supprimer chaque article avant d'autoriser la suppression de la rubrique?
Il y a une contrib qui gère les articles en masse : http://www.spip-contrib.net/article362.html
D'ailleurs, j'aimerais vraiment beaucoup que ce soit intégré (avec quelques
améliorations) en standard dans SPIP.
Ce type de fonctionnalité est tellement dangereuse qu'on peut tout
aussi bien recommander à ceux qui veulent s'y livrer de passer par
phpMyAdmin.
Je suis d'accord qu'effacer une rubrique entière avec ses articles est très
dangereux. Mais n'est-ce pas au moins aussi dangereux que d'effacer ou la
base de donnée? Est-ce qu'une validation par FTP serait alors suffisante,
rendant cette opération accessible qu'à l'administrateur du site?
Cordialement,
Thierry Gagnon,
Studio Eau Moirée
www.thierrygagnon.com
Ne serait-il pas utile de donner, dans l'interface privée, la possibilité
de supprimer une rubrique et tous ses articles d'un coup
Arno a répondu :
Ce type de fonctionnalité est tellement dangereuse qu'on peut tout aussi
bien recommander à ceux qui veulent s'y livrer de passer par phpMyAdmin.
Bonsoir,
je pense que peut-être Arno a raison, mais il serait utile d'avoir des
conseils sur ce qu'on peut faire avec phpMyAdmin et ce qu'il faudrait éviter
de faire.
Y a-t-il des tables desquelles on peut impunément supprimer des lignes, sans
laisser des clés vides" ou du débris dans d'autres tables ? Si je détruis
50 lignes dans spip_articles, que se passe-t-il avec la table
spip_versions_fragments, ou spip_referers_articles par exemple ? Cela
devient tout de suite assez compliqué, je pense.
Ce type de fonctionnalité est tellement dangereuse qu'on peut tout aussi bien recommander à ceux qui veulent s'y livrer de passer par phpMyAdmin.
Salut,
C'est vrai que c'est le genre de truc avec quoi il faut être hyper-prudent. Et finalement, j'ai simplement supprimé les secteurs en ligne de commande mysql.
Mais ce n'est vraiment pas très propre comme méthode: notamment, ça laisse tous les documents joints, logos et autres images en place (et là, il est nettement moins facile de les supprimer simplement en intervenant directement dans la base de données avec une commande du type "DELETE FROM spip_articles WHERE id_secteur=1;")
Effectivement j'ai installé apg_statut et il est très efficace pour
gérer de gros volume
par rapport à un accès direct via phpmyadmin, il a quand même pas mal
d'avantages :
- pas de suppression physique (on change le statut)
- pas de modification du contenu des articles (on agit que sur le
statut)
- affichage des libellés des rubriques, des auteurs, ...
Personnellement j'ai le pb inverse de publier d'un coup tous les articles d'une rubrique
(les exos d'une séance de travaux dirigés pour ne rien vous cacher).
Voici un script qui aligne sur un même statut tous les articles d'une rubrique donnée dans l'URL.
Je mets en pièce jointe ce script, et voici son appel à placer un peu où on veut dans naviguer.php3:
if ($connect_statut == '0minirezo' AND acces_rubrique($id_rubrique)) {
echo "<FORM ACTION='toutarticles.php' METHOD='get'>";
debut_cadre_relief("racine-site-24.gif");
echo "<CENTER>";
Personnellement j'ai le pb inverse de publier d'un coup tous les
articles d'une rubrique
(les exos d'une séance de travaux dirigés pour ne rien vous cacher).
Voici un script qui aligne sur un même statut tous les articles d'une
rubrique donnée dans l'URL.
Intéressant.
ARNO*, t'es OK pour intégrer ça avec non pas seulement le statut publié,
mais aussi les autres statuts ?
2. pas question: je donne ça parce que je l'ai sous le coude, mais c'est du bricolage.
La bonne solution c'est d'écrire l'interface privée à coup de squelettes pour que chacun
rajoute ce genre de chose facilement mais sans complexifier l'interface de la version officielle.
2. pas question: je donne ça parce que je l'ai sous le coude, mais
c'est du bricolage.
C'est peut-être du bricolage, mais c'est un besoin qui revient
régulièrement.
La bonne solution c'est d'écrire l'interface privée à coup de
squelettes pour que chacun
rajoute ce genre de chose facilement mais sans complexifier
l'interface de la version officielle.
Certes, mais ça, c'est pas exactement prévu pour demain.
Seulement l'année prochaine, non ?
J'ai vu. Mais précisément, cette contrib ne répond pas à mon besoin, pour deux raisons:
- Elle demande d'entrer chaque numéro d'article à modifier. Quand on doit en modifier 2000, il y a peut-être plus simple.
- Elle ne gère que le statut des articles, ce qui est très facile à gérer directement via MySQL. Mais elle ne gère pas les documents joints, les tables de liaisons,... là où justement elle aurait été très utile.
2. pas question: je donne ça parce que je l'ai sous le coude, mais c'est du bricolage.
La bonne solution c'est d'écrire l'interface privée à coup de squelettes pour que chacun
rajoute ce genre de chose facilement mais sans complexifier l'interface de la version officielle.
Assez d'accord. Par contre, un truc qui pourrait être utile et totalement générique comme fonction, c'est une "corbeille".
En gros, il s'agirait d'une page qui liste tous les éléments de tous types qui sont en statut "poubelle".
La différence avec la situation actuelle serait que les éléments "poubelle" ne seraient plus supprimés tous seuls après x temps (quand ils sont supprimés) mais il faudrait une confirmation humaine pour détruire définitivement des objets.
En plus de clarifier fortement le statut "entre deux eaux" des éléments "à la poubelle", ceci aurait le très grand avantage de permettre la mise en place d'outils "destructeurs" (par exemple la suppression d'une rubrique entière, contenant des articles) dans spip avec un risque moins grand - le filet de sécurité de la corbeille permettant toujours de récupérer une fausse manoeuvre.
Vraiment pas convaincu. La «corbeille» et le contrôle qu'on en a, c'est lié aux exigences des disques durs. Et, pour l'utilisateur lambda, ça reste une ergonomie absolument catastrophique: visiter l'ordinateur d'un utilisateur moyennement averti, c'est se retrouver avec deux situations très classiques: le disque saturé avec une corbeille bourrée à craquer, ou à l'inverse les documents importants jetés à la poubelle avec le poubelle vidée illico.
Pour l'instant, comme garde-fou, le fonctionnement semi-automatique de la «poubelle» de SPIP, c'est encore ce qu'on a trouvé de mieux.
C'est évidemment pas idéal, mais franchement une ergonomie de type poubelle d'ordinateur, c'est une horreur.
Sur le besoin, habituellement, de pouvoir contrôler directement le vidage de la corbeille, c'est lié à l'habitude de l'ergonomie des disques durs. Elle se justifie par le besoin de la vider pour récupérer de l'espace disque. Avec SPIP, tout ce qu'on contrôle, ce sont des textes stockés dans une base de donnée. Vider la corbeille, ça fait gagner au mieux quelques dizaines de kilo-octets (en étant optimiste sur la taille des textes effacés). Et cela pour ne gagner au mieux que 24 heures...
Bref, clairement: ça n'est pas une opposition au principe de ces
automatismes. C'est le refus d'intégrer des fonctions qui soient
seraient très dangereuses, soient compliqueraient considérablement
l'interface, sans avoir trouvé de solution d'ergonomie adaptée (et,
puisque c'est le seul exemple que j'ai: l'interface de phpMyAdmin qui
permet ce genre de chose, ça ne correspond absolument à celle d'un CMS
et aux exigences qu'on tente de maintenir au niveau de l'interface de
SPIP).
Je pense à un autre type d'interface grand public permettant de faire des
choses en masse : IMP (gestionnaire webmail utilisé par exemple par Free).
Ça présente une liste de message avec une case à cocher sur la gauche.
Il y a une liste déroulante qui permet de choisir une action à faire sur la
sélection.
C'est utilisé par des miliers de gens.
Tout ça pour dire que je verrais bien la possibilité de traitement des
statuts en masse dans la page ecrire/articles_tous.php3 avec :
- une icone pour tout sélectionner dans une rubrique, puis dans toutes les
sous rubriques, puis tout déselectionner
- une case à cocher par article
- une liste déroulante pour changer le statut des articles sélectionnés avec
un bouton "Modifier" de confirmation et éventuellement une boite de
confirmation js pour la mise à la poubelle
- peut-être aussi une possibilité de supprimer les rubriques vides à ce
niveau là, mais pas en récursif
Juste une remarque la dessus :
Evidemment, ce genre d'outil doit rester sous forme de contribution, 100%
OK avec ARNO la dessus.
C'est une solution simple mais un peu expeditive, voire dangereuse.
Par contre, il me semble avoir vu une contrib permettant d'importer et
d'exporter des articles avec ce qui va autour.
Il serait peut etre judicieux d'en faire un outil d'archivage.
Fonctionnellement, archiver, c'est supprimer en se laissant la possibilité
de réintegrer les données.
On peut tout à fait imaginer un outil qui serve à la fois à
l'export/sauvegarde et à l'archivage (meme chose mais on supprime le contenu
du site à la fin).
La, on est sur un vrai besoin fonctionnel de Spip qui me parait cadrer avec
la philosophie.
non ?