15 Avril papabct
Malgré le warning easyphp j'ai tenté sur free ( safe mode est activé ) et j'ai pas eu de pb avec le téléversement de fichier mais quand j'ai créé le repertoire toto pas de pb mais après j'ai systématiquement
Warning: is_dir(): Stat failed for ../contributions/toto/. (errno=13 - Permission denied) et pour /toto/..
in /wikini/actions/fileupload.php on line 61
je peux renommer le répertoire avec Filezilla mais je ne peux ni le supprimer ni rentrer dedans
Les permissions sont 644 ( lecture pour tous écriture pour propriètaire éxécution pour personne )
Le répertoire parent est 700 ( tout autorisé pour le propriétaire )
4 Avril 2004 papabct
je viens de découvrir
http://z720.net/produits/wikini/ de Sébastien Erard
Sebastien à écrit une routine php fileupload à insérer dans /actions ( après personnalisation )
En faisant les essais j'ai Undefined index: fileupload in d:\easyphp1-7\www\wikini\actions\fileupload.php on line 104
mais ça marche!
Merci à la communauté Wikini
Besoin
Avec la possibilite des mettre le fichier sur un site, on peut faire une base de connaissances (knowledgebase) :-)
--
CostalMartignier2 (grrrrr ce francais)
Pourquoi pas ... --
DavidDelon
:-) --
CostalMartignier
Je suggèrerai bientôt différents moyens de mettre en ligne des fichiers. --
PatrickPaul
Un utilisateur semble l'avoir réalisé sur
WakkaWiki :
http://www.wakkawiki.com/FilesAction
--
CharlesNepote
Les utilisateurs d'un wiki peuvent ressentir le besoin de publier, joints aux pages qu'ils produisent, des fichiers de toutes nature (fichiers PDF, fichiers Zippés, etc.).
Il existe deux grandes possibilités pour gérer la publication de fichiers avec un wiki :
- un mécanisme de publication totalement indépendant du wiki, les liens étant effectués à la main
- un mécanisme de publication intégré au wiki, les liens vers les documents étant gérés par l'interface. C'est cette dernière solution que nous étudions ci-dessous.
La fonction d'upload de fichier pourrait / devrait contenir les fonctionnalités suivantes :
- Fonctionnalités utilisateurs
- upload de fichier (par le propriétaire ? par tous les utilisateurs ?)
- validation de l'upload par un ou plusieurs responsables éditoriaux du site (pour éviter les virus) ?
- prévenir l'utilisateur que le webmestre n'est pas responsable des fichiers téléchargés (ceux-ci pouvant contenir des virus)
- un fichier est-il forcément lié à une page ?
- limite de taille pour l'upload (pour éviter à l'utilisateur néophyte de télécharger de trop gros fichiers) : je suggère 1 ou 2 Mo dans un premier temps, par défaut, et paramétrable par l'admin. technique
- intégration des fichiers téléchargés dans DerniersChangements
- icône spéciale dans l'interface (en bas de page ou dans la page ?)
- suppression, renommage des fichiers téléchargés (droits ?)
- versionnement ?
- Fonctionnalités (ou contraintes) techniques
- fichiers enregistrés en base de données ou sur le système de fichier ?
- fichiers enregistrés dans /uploads/AAAA/MM/JJ/nom_du_fichier.hh.mm.ss.extension
- analyse de place restante pour ne pas engorger le support de sauvegarde
- répertoire /uploads protégé en écriture
[voilà quelques propositions à discuter]
--
CharlesNepote
Quelques commentaires :
- upload par tous les utilisateurs : attention aux pirates qui vont s'en donner à coeur joie avec tous les sites Wiki comme zones d'échanges ...
- validation : absolument, pour la raison ci-dessus, au moins ! je proposerais aussi que l'upload sans validation fasse partie d'un droit utilisateur à activer par un administrateur fonctionnel
- fichier lié à une page : non, on peut vouloir le reprendre dans plusieurs pages
- limite de taille : indispensable !
- visibilité dans le tableau de bord (derniers changements) : absolument !
- icône spécial : bof, c'est un lien classique, à l'utilisateur de choisir comment le présenter (au milieu ou en bas) ; à moins que vous n'ayez aussi prévu la notion de notes à intégrer en pied de page (footer) ? dans ce cas ça pourrait effectivement en faire partie
- suppression, renommage et droits : considérons que les fichiers sont un autre "type de document" tout comme le sont les pages
- suppresion : absolument, mais il faudra vérifier les fichiers "orphelins" ou non (comme pour les pages)
- renommage : pourquoi faire ? on ne renomme pas une page non plus ; à la rigueur fournir une option qui permet de fournir un filename="..." différent quand on clique sur le lien
- droits : les même que pour une page (= document)
- versionnement : mhhh ... pas d'avis pour le moment ... je propose de laisser cela à la discretion de l'utilisateur en choissant un nom de fichier avec indication de version ou non
- enregistrement des fichiers : plutôt faire un wikini/files/
NomDuFichier? de dépôt, sans sous-arborescence ; les noms des pages étant uniques, les noms des fichiers devraient l'être aussi => toujours la notion de documents : ils doivent avoir les mêmes contraintes
- pour les méta-informations liées aux fichiers, il faut y réfléchir : on pourrait soit les mettre dans wikini/files/
NomDuFichier?.meta, mais ce serait alors plus ou moins difficile à manipuler (cas des recherches), soit les mettre dans une table wikini_files
- place restante : une gestion de quotas interne à
WikiNi serait la bienvenue ; elle pourrait éventuellement interroger les infos du système de fichiers le cas échéant, ou encore demander la taille disponible à l'administrateur technique puis tenir un compteur de place (arrondi à la taille d'un bloc sur le système de fichier, qu'on pourrait majorer pour simplifier, histoire de ne pas avoir la surprise des "petits centimes")
- répertoire wikini/files/ protégé : oui, mais euh ... en écriture ?!? je le verrais plutôt protégé en lecture afin qu'on ne puisse pas downloader directement les fichiers mais qu'on soit obligé de passer par wakka qui ferait un passthrough du fichier (en fixant l'en-tête Content-Disposition avec le filename="..." demandé par le créateur du lien)
Juste quelques idées comme ça ... :)
--
ProgFou
--
PhilippeBillerot
- Je suis fort intéressé par l'implémentation de cette fonction Gestion de Fichiers
- je préfererai les fichiers enregistrés sur le système de fichiers
- il faudrait aussi une fonction Explorer pour lister, renommer, supprimer les fichiers
- ne pas imposer le nom du fichier
- il serait peut être préférable de lier le fichier à la page via un sous-répertoire par page à condition que la fonction de renommage d'une page en fasse de même pour le sous-répertoire.
Je travail actuellement dessus. Je me pose certaines question quant à la façon de stocker les fichiers. Faut-il gérer ça séparemment ?
Une méthode que j'ai déjà mise en place sur un Wikini pour une université consiste à avoir un dossier séparé qui contient tous les fichiers (ce dossiers peut-être organisé en sous-dossiers). Ensuite, pour faire un lien vers un fichier dans une page j'ai "inventé" la convention proche des liens habituels, à savoir d'utiliser un triple "[" et ensuite le chemin relatif vers le fichier. (exemple :[[[/patrickpaul/monbeaufichier.fic Cliquez ici poru downloader les fichier]]]. Le chemin relatif se fait par rapport au dossier contenant les fichiers (et qui est défini dans la configuration).
Sur mon implémentation chaque utilisateur peut lui-même définir le dossier dans lequel se trouve les fichiers (qui peut être un dossier local). Cela permet par exemple de proposer en download sous forme d'un fichier compressé tout les fichiers et ensuite les liens se fond automatiquemet. Nous avons par ailleurs utiliser cela sur le réseau local de l'université. De cette façon nous avions tous les fichiers localement sur le réseau, et accessibles par les liens du site qui est sur internet.
Ma question maintenant est qu'en pensez-vous ? Vos suggestions ? Vos idées ?
Dans tous les cas, il y a aura certaies restrictions comme par exemple la taille des fichiers qui ne pourras pas dépasser 2 Mo, ce qui est la limite standard pour l'upload de fichiers avec php. Cependant le système que je propose peut permettre par exemple d'avoir accès au dossier contenant les fichiers par ftp, ce qui peux permettre d'uploader de plus gros fichiers.
P.S. Excusez-mon décalage avec l'article de Charles ci-dessus mais je ne l'avais pas lu quand j'ai écris ceci.
--
PatrickPaul
- le triple "[" pour encadrer le chemin relatif me satisfait.
- le préfixe du nom du fichier pourrait aussi reprendre le nom de la page courante [[[/PagePrincipale/monFichier.fic lien sur mon fichier]]]
- ainsi les droits d'upload dans ce dossier seraient les mêmes que sur la page
--
PhilippeBillerot
Pour ma part je pense aussi qu'il vaut effectivement mieux stoquer les fichiers dans un répertoire genre
wikini/files/.
Sur la question du triple crochet, je trouve cela dommage : pourquoi ne pas rester homogène en continuant d'utiliser le double crochet pour les liens, un fichier étant accédé via la méthode
file://. On pourrait même accepter une simplification en testant si le premier caractère du lien est un slash '/' auquel cas on le considèrerait comme un fichier uploadé dans WikiNi.
Par contre le fait de faire un sous dossier par utilisateur est effectivement une bonne idée pour simplifier la gestion des propriétaires des fichiers. Mais je pense que ça ne sera probablement qu'une solution provisoire vu qu'on arrivera forcément à un moment où on aura besoin de méta-données supplémentaires et cette "bonne astuce" ne suffira probablement plus ...
--
ProgFou
Un petit retour d'expérience avec l'utilisation de
Swiki sur Internet (
le Swiki de Squeak) et sur un Intranet (pour du partage d'expérience technique).
Swiki permet de téléverser des fichiers quelconques. Le téléversement se fait à partir d'une page, et le fichier se retrouve au choix attaché à la page ou bien au site. Ensuite, écrire le nom du fichier à l'intérieur de marqueur spéciaux (voir
l'aide de Swiki) est rendu comme un lien vers ce fichier, s'il est accessible (c'est-à-dire lié à la page courante ou au site).
Selon moi :
- Avantages :
- grande facilité d'utilisation
- bonne gestion des versions de fichiers, une nouvelle version du même fichier n'écrase pas l'ancienne
- + tout ce que cela permet de faire
- Inconvénients :
- détournement fréquent de l'"esprit" WikiWikiWeb : on se met à attacher des fichiers Word (beurk, comme si c'était un format universel) au lieu d'écrire dans la page
- les Swikis publics se mettent à servir de lieu de transit anonyme pour des fichiers multimédias énormes
- il est très difficile de faire du nettoyage, de se rappeler qui est responsable d'une pièce jointe, si elle est "orpheline" ou pas, alors que souvent on aimerait trier tout ces fichiers pour regagner de la place disque.
Je pense que si cette fonction est ajoutée à WikiNi, il faudrait qu'elle soit optionnelle.
Sur mon Intranet, j'ai demandé aux utilisateurs de ne pas se servir de cette fonction, sauf pour des images décoratives de petite taille. Un disque partagé complètement différent est servi en lecture par ftp et sert de lieu de stockage des "gros" fichiers. Un espace est réservé pour chacun, ce qui permet de retrouver facilement qui est responsable de quel fichier et de pouvoir retrouver ce qui est devenu inutile parmi ce qui reste utile encore. sur les page du Swiki, on met des liens ftp. Inconvénient de cette solution, toujours : on n'a pas la traçabilité inverse d'un fichier vers l'ensemble des pages qui le référencent.
Une solution serait peut-être d'avoir un nouvelle sorte de page Wiki ne contenant pas de texte, juste une sorte de coquille vide servant uniquement de référence à un fichier. Le versionnement fonctionnerait également, ainsi que la référence à un auteur. Créer un lien vers cette page serait simplement rendu comme un lien vers le fichier.
Références :
Ma petite contribution
J'avais besoin de faire de l'upload avec
WikiNi, alors voici ma contribution :
WikiNi de CodeDB
Tout est expliqué sur ce Wiki de test. Si ca vous plais, demandez moi les sources ( j'ai un peu de ménage a faire dedans). Il manque surement des choses, notament une gestion des droits car quiconque peut lire une page peut uploader un fichier, mais comme je débute dans la programmation de
WikiNi, je ne connais pas encore toute l'API.
Vous pouvez faire des essais sur mon site, mais n'oublier pas de supprimer vos fichiers en partant !!
J'ai ajouté la gestion des droits, seule ceux qui on le droit d'écriture peuvent uploader un fichier.
--
GarfieldFr
Depuis l'annonce de ce systeme d'upload de fichier, j'ai déjà 3 ou 4 personnes qui m'on contactés pour récupérer les sources de cette action après l'avoir essayée sur mon site. Ils ont visiblement été séduits par sa simplicité d'utilisation.
(voir
InclureUneImage pour les détails )
--
GarfieldFr
Pourquoi ne publies-tu pas ton source ici-même ? Pour ma part je suis d'avis, pour le moment, de laisser cette possibilité comme une option (ça tombe bien puisque ta solution est une action) -- je ne suis pas le seul à penser cela semble-t-il (cf. l'avis de
jexOm ci-dessus). En revanche, je t'encourage à publier ici même une page dédiée à ta propre solution avec le code source (par exemple
Solution1PourLUploadDeFichier?). Si tout le monde est d'accord, on peut même envisager de la passer en production sur ce site, sous réserve d'une limite de taille d'upload. [Au passage, note que ton site n'est pas accessible et renvoie une page blanche...].
Pour améliorer la gestions des extentions
WikiNi on peut d'ailleurs imaginer un système de gestionnaire d'extention
ou à la templeet (
http://www.templeet.org/screenshots/packages.jpg ). (cf. l'
InterfaceDAdministrationWikiNi). --
CharlesNepote
En effet, c'est une idée, mais le code est assez important et nécessite 2 fichiers (une action et un handler). Je remet le code au propre et je le commente avant de le publier. [Mon site marche très bien, probablement une indisponibilité temporaire] --
GarfieldFr
Voici la page ou je publi les sources pour l'upload de fichier :
SolutionGarfieldFrPourLUploadDeFichier --
GarfieldFr
Merci
GarfieldFr ! Vu que ça m'intéresse pas mal, je vais l'étudier et je te donnerai des nouvelles, mais pas forcément tout de suite vu qu'on approche du Têt (le nouvel an vietnamien). --
ProgFou
Je travaille sur le sujet actuellement, mais je suis toujours dessus.
Voir sur ma page
SebErard l'encours
Ailleurs
La gestion de fichiers en ligne n'est pas un problème simple, aussi, voici quelques liens pour montrer ce qui peut se faire sur d'autres applications.