Jyraphe, votre dépôt en ligne de fichier

Posté par  (Mastodon) . Modéré par Amaury.
0
17
avr.
2008
Internet
La Jyraphe est sorti des steppes dans sa première version publique, la version 0.1.

Jyraphe est une application web de dépôt de fichier, facile à installer et facile à utiliser. Jyraphe est une application complètement libre, distribuée selon les termes de la GNU Affero General Public License, version 3 ou supérieure. Jyraphe est développé selon la philosophie Getting Real, donc possède juste les fonctionnalité nécessaires. La suite de la dépêche vous donnera un aperçu de ces fonctionnalités.

Le but de Jyraphe est de proposer une application web de dépôt de fichier simple que tout le monde puisse installer sur son bout de serveur. Le but est de multiplier les Jyraphe sur l'Internet, à l'inverse de certains sites dont le but est de centraliser le service au maximum, en ajoutant au passage de la publicité qui fait mal aux yeux.

Cette application est un bon remède contre le Minitel 2.0 Voici les principales fonctionnalités de Jyraphe.

Un fichier, un lien

Vous déposez un fichier et vous obtenez en retour un lien sur ce fichier que vous pouvez partager. Quand vos amis suivent ce lien, ils reçoivent le fichier que vous avez déposé et peuvent le sauvegarder.

Visualisation directe des images et des textes

Si le fichier que vous avez déposé est une image ou un texte, alors il apparaît directement dans le navigateur, comme n'importe quelle image ou n'importe quel texte.

Téléchargement à usage unique

Vous avez aussi la possibilité de déposer un fichier qui ne pourra être téléchargé qu'une seule fois. Le lien donné n'est valable qu'une seule et unique fois et ensuite, le fichier disparaît.

Pas de base de données

Jyraphe fonctionne sans aucune base de données. Jyraphe n'a besoin que de PHP et utilise le système de fichier comme moyen de stockage naturel.

Aller plus loin

  • # Upload des fichiers

    Posté par  . Évalué à 3.

    Intéressant, mais je n'ai pas vu dans la documentation :

    - Comment se fait l'upload des fichiers ?
    - Quelles sont les limites de tailles ( limite des applications php/apache sur la commande PUT ? ) ?
    - Peut on suivre convenablement l'upload d'un gros fichier ?
    - La philosophie «Getting Real» répond t'elle à toutes ces questions ?
    • [^] # Re: Upload des fichiers

      Posté par  (Mastodon) . Évalué à 3.

      L'upload se fait par simple HTTP POST, pas de Java/Flash/Machin.

      La taille des fichiers est limité par PHP principalement (c'est dans la documentation : Guide de l'utilisateur > Aide en ligne > taille de fichier maximale).

      Pour suivre un upload, j'ai cherché une solution simple mais je n'en ai pas trouvé (j'ai trouvé un gros bout d'AJAX, un peu trop gros pour ça ou alors un truc qui imposait de patchher PHP (!)). Je suis preneur de toute solution simple.

      La philosophie "Getting Real" permet de se faire des choses simples.
      • [^] # Re: Upload des fichiers

        Posté par  . Évalué à 1.

        Ton "truc qui imposait de patcher PHP", ça a quelque chose à voir avec [http://www.haughin.com/2007/10/23/php-upload-progress-with-p(...)] ?

        Si oui, peux-tu expliquer pourquoi tu as préféré passer ton chemin ? Ca n'a pas l'air si compliqué...
        • [^] # Re: Upload des fichiers

          Posté par  (site web personnel) . Évalué à 3.

          Parceque tout le monde ne peux pas forcément patcher php sur le serveur qu'il utilise?
        • [^] # Re: Upload des fichiers

          Posté par  (Mastodon) . Évalué à 2.

          Non, ce n'était pas ça. Cette solution n'impose pas de patcher PHP à ce que je vois.

          J'ai préféré passer mon chemin parce que je ne veux pas que ça marche pour moi mais que ça marche pour tout le monde. Et puis une solution qui impose de patcher PHP est forcément une mauvaise solution. Si PHP ne le permet pas naturellement, tant pis. Mais apparemment, avec la page que tu me donnes, on peut le faire sans patch.

          Je vais étudier tout ça et je verrai ensuite ;)
      • [^] # Re: Upload des fichiers

        Posté par  . Évalué à 3.

        > La taille des fichiers est limité par PHP principalement

        Il serait peut-être cool d'avoir un moyen ajouter à un fichier déjà uploadé.
        Par exemple on en peut uploader qu'au maximum 16 Mo (limite php). Mais j'ai un fichier de 18 Mo.
        - Je le splite en local mon gros fichier (en veillant à conserver l'entension pour le premier fichier afin avoir le bon type).
        - J'uploade le premier fichier => il me donne une url.
        - J'uploade le seconde fichier en indiquant "ajout" et l'url précédente.

        La dernière opération peut être répétée à l'envi.
        • [^] # Re: Upload des fichiers

          Posté par  . Évalué à 1.

          En passant, pourquoi Jyraphe ?
        • [^] # Re: Upload des fichiers

          Posté par  . Évalué à 2.

          > - J'uploade le seconde fichier en indiquant "ajout" et l'url précédente.

          Mieux, après un uploade, j'ai la possibilité d'ajouter.
        • [^] # Re: Upload des fichiers

          Posté par  (Mastodon) . Évalué à 3.

          Je vois la limitation de PHP comme une limitation politique de l'administrateur. Contourner cette limitation, c'est un peu contourner la volonté de l'administrateur. Pour les gens qui l'installent sur leur propre bout de serveur où ils peuvent modifier la conf PHP, ça ne posera pas de problème.

          Sur le "pourquoi Jyraphe ?", c'est écrit dans la FAQ. Parce que girafe s'écrit de mille manières suivant la langue, et c'est une manière de plus.
          • [^] # Re: Upload des fichiers

            Posté par  . Évalué à 3.

            > Je vois la limitation de PHP comme une limitation politique de l'administrateur

            Mouaifff...
            Le mieux pour les uploads est d'utiliser rsync ou scp ou ftp etc.
            Si l'administrateur ne fournit pas cette possibilité, dois-je en conclure que l'utilisation de Jyraphe est un contournement de la politique de l'administrateur ?

            Enfin le problème de cette limitation de php, n'est pas que politique. Si tu autorises 1 Go pour POST, il te faut au moins 1 Go de RAM. Images s'il y a 3 (ou plus) malins qui uploadent un fichier en même temps. C'est donc aussi un problème de sécurité (DOS) et pas seulement de politique.

            > Contourner cette limitation, c'est un peu contourner la volonté de l'administrateur.

            La volonté des l'administrateurs va s'exprimer avec les quotas dans ce domaine.
            Si l'administrateur te donne 20 Go, que ça soit 1 fichier de 20 Go ou 2000 fichiers de 10 Mo, il s'en fout.
            Et que je sache, l'admin a autorisé php. Sauf s'il indique spécifiquement qu'il ne faut pas utiliser php afin de créer des fichiers plus gros que la limite (POST) de php, je pense que ton "excuse" est sans réel fondement. Désolé pour la brutalité.

            Si tu ne veux pas le faire, je comprend très bien. Tu veux que Jyraphe soit simple et c'est sa grande qualité.
            Et ne voit pas dans mon commentaire précédent une requête, je n'utilise pas actuellement Jyraphe. Aucune offence, c'est seulement qu'*actuellement* j'en ai pas besoin.
            Donc soit à l'écoute de tes vrais utilisateurs et pas de moi :-)

            Bonne continuation.
            • [^] # Re: Upload des fichiers

              Posté par  . Évalué à 2.

              Si l'admin ne veut pas de gros fichier (type vidéo) avec Jyraphe ce n'est pas un problème.
              Il suffit :
              part1 : url...
              part2 : url...

              Pour les faire un rar, split, etc.
              • [^] # Re: Upload des fichiers

                Posté par  (Mastodon) . Évalué à 2.

                Voici une très bonne technique qui permet de ne pas implémenter une fonction en trop.

                Ça me fait penser à un chapitre de Getting Real où il dit qu'il faut laisser les utilisateurs trouver des utilisations détournées de l'outil. C'est exactement ce que tu viens de faire, Bravo :)
            • [^] # Re: Upload des fichiers

              Posté par  . Évalué à 1.

              > Enfin le problème de cette limitation de php, n'est pas que politique. Si tu autorises 1 Go pour POST, il te faut au moins 1 Go de RAM.
              > Images s'il y a 3 (ou plus) malins qui uploadent un fichier en même temps. C'est donc aussi un problème de sécurité (DOS) et pas seulement de politique.

              c'est ridicule de dire des choses comme ça. On peut tout de même supposer que les gens qui gèrent php savent ce qu'ils font. Il suffit de gérer un fichier en upload et d'écrire au fil de l'eau pour s'affranchir de cette stupidité d'assertion au sujet de php.

              Pour les plus curieux, positionner le max_upload_size sur 20 ou 30Mo et le memory_limit sur une valeur bien inférieure et tenter de faire marcher jyraphe ou un simple upload. A vos claviers ...

              Jyraphe, tu m'intéresses, j'irai voir ce que tu as dans les tripes dans quelque temps. Rewind, tu me pardonneras pour l'autopsie :-)
              • [^] # Re: Upload des fichiers

                Posté par  (Mastodon) . Évalué à 2.

                Tu es tout pardonné. Je dirais même que le libre pousse à l'autopsie alors ne t'en prive pas.
              • [^] # Re: Upload des fichiers

                Posté par  . Évalué à 2.

                > c'est ridicule de dire des choses comme ça. On peut tout de même supposer que les gens qui gèrent php savent ce qu'ils font. Il suffit de gérer un fichier en upload et d'écrire au fil de l'eau pour s'affranchir de cette stupidité d'assertion au sujet de php.

                Ben tu devrais le faire, car php ne sait pas le faire (et depuis des années, depuis toujours).
                Qui est ridicule et stupide ? php ?

                Puisque tu es si doué, il serait ridicule que tu ne le fasses pas.
                Fais le pour php 6, tu vas avoir les ovations de la foule.

                http://php.net/manual/fr/ini.core.php
                post_max_size integer

                Définit la taille maximale des données reçues par la méthode POST. Cette option affecte également les fichiers chargés. Pour charger de gros fichiers, cette valeur doit être plus grande que la valeur de upload_max_filesize. Si la limitation de mémoire est activée par votre script de configuration, memory_limit affectera également les fichiers chargés. De façon générale, memory_limit doit être plus grand que post_max_size. Lorsqu'un entier est utilisé, sa valeur est mesurée en octets. Vous pouvez également utiliser la notation sténographique comme décrit dans cette entrée de la FAQ.. Dans le cas où la taille des données reçues par la méthode POST est plus grande que post_max_size , les superglobales $_POST et $_FILES seront vides. Ceci peut être surveillé de différentes façons, e.g. en passant une variable $_GET au script qui traite les données, i.e. <form action="edit.php?processed=1">, et ainsi vérifier si $_GET['processed'] est défini.


                Me déçoit et devient mon héro.
                • [^] # Re: Upload des fichiers

                  Posté par  . Évalué à 1.

                  merci pour l'info, j'y regarderai de plus près :-) quand a modifier php, heu, je ne crois pas que ce soit dans mes cordes.
                  • [^] # Re: Upload des fichiers

                    Posté par  (site web personnel) . Évalué à 3.

                    Le problème c'est que la modif de php c'est dans les cordes de personnes.

                    Aucun patch n'est assez bon pour le fameux php. Tous les hébregeurs se traîne des kilomètres de patch qu'ils n'ont jamais pu faire intégrer upstream.

                    Du coups ils traînent la patte pour les changement de versions.

                    Tu veux un exemple :
                    exec -> avoir un execdir sans safe_mode
                    mail -> mail interdire le -f (toujours sans safe-mode), ajouter le nom du script dans les headers
                    fsockopen -> avoir le même comportement que curl (en gros regarder ce que c'est avant de l'ouvrir) histoire de ne pas participer à des ddos
                    Interdire certains php_value, ini_set toujours sans safe-mode

                    Non mais c'est vrai y-a l'openbasedir
                    Bon j'arrête je vais devenir méchant.

                    Toujours est-il que si un client me dit qu'il veut un serveur fiable à l'heure actuelle c'est patch de la fonction mail, safe-mode on et apache en nobody (oui vous savez le truc chiant qui fait que quand la bande à 4t4tu5K uploade en douce un script grâce à ta fabuleuse fonction ils ne peuvent pas l'utiliser).
                • [^] # Re: Upload des fichiers

                  Posté par  . Évalué à 3.

                  voici un commentaire sur cette page : http://fr2.php.net/manual/en/features.file-upload.php I don't believe the myth that 'memory_size' should be the size of the uploaded file. The files are definitely not kept in memory... instead uploaded chunks of 1MB each are stored under /var/tmp and later on rebuild under /tmp before moving to the web/user space. I'm running a linux-box with only 64MB RAM, setting the memory_limit to 16MB and uploading files of sizes about 100MB is no problem at all! Nevertheless, some users reported a problem at a few 100MB, but that's not confirmed... ;-)
                  • [^] # Re: Upload des fichiers

                    Posté par  . Évalué à 2.

                    Des milliers d'excuses.
                    J'avais eu le problème. Mais c'était il y a un bien longtemps (php 4).
                    La doc semblait indiquer que c'était toujours un problème. Mais manifestement ce n'est plus le cas.
      • [^] # Re: Upload des fichiers

        Posté par  (site web personnel) . Évalué à 1.

        pourtant avec apc ce n'est pas compliqué : http://www.whenpenguinsattack.com/2006/12/12/how-to-create-a-php-upload-progress-meter/

        L'exemple utilise yui, mais rien n'oblige à l'utiliser.
  • # une démo jouable...

    Posté par  (Mastodon) . Évalué à 2.

    Pour ceux qui veulent, il y a une démo jouable ici :

    http://jyraphe.ours-courageux.info/
    • [^] # Re: une démo jouable...

      Posté par  . Évalué à 2.

      Warning: substr_compare() [function.substr-compare]: The start position cannot exceed initial string length in /var/www/jyraphe.ours-courageux.info/htdocs/pub/lib/functions.php on line 155

      Warning: substr_compare() [function.substr-compare]: The start position cannot exceed initial string length in /var/www/jyraphe.ours-courageux.info/htdocs/pub/lib/functions.php on line 156

      (lors du téléchargement d'un fichier précédemment inséré par mes soins)
      • [^] # Re: une démo jouable...

        Posté par  (Mastodon) . Évalué à 2.

        Je corrige. Ça vient du fait que le nom du type-mime du fichier que tu as envoyé est trop petit (vide dans ce cas).

        Merci.
    • [^] # Re: une démo jouable...

      Posté par  (Mastodon) . Évalué à 3.

      Vous m'en voudrez pas de nettoyer tout ce que vous mettrez là. Y'a pas de cron, je le fais à la main donc plus ou moins régulièrement. C'est juste une démo, pas un service en ligne hein, vous avez compris le principe ;)
  • # Mot de passe ?

    Posté par  . Évalué à 2.

    Script toujours bon à prendre, merci de l'avoir fait et mis à disposition de tous.

    J'ai une requête : la possibilité de protégé le téléchargement de certains fichiers par mot de passe.
    • [^] # Re: Mot de passe ?

      Posté par  (Mastodon) . Évalué à 2.

      Idée intéressante. Je note pour la prochaine version éventuellement.
      • [^] # Re: Mot de passe ?

        Posté par  . Évalué à 1.

        Bon boulot :)

        .... tant qu'on en est aux suggestions est-ce que tu estimerais envisageable alternativement au mot de passe imposé par l'émetteur, de générer un "code de libération" à usage unique ?

        L'idée derrière ça étant d'éviter de voir débarquer les com.....aux disant "tu peux me mettre ça sur un serveur web, ça passe pas par mail ... mais il faudra l'enlever après, paskeu c'est un projet secret ..."

        ... parce que le mot de passe est une très bonne idée, mais je vois trop cette frange de population mettre toujours le même mot de passe, ou alors systématiquement le nom du client, ou autre genre de ... bêtises ...
        • [^] # Re: Mot de passe ?

          Posté par  (Mastodon) . Évalué à 3.

          le one time download (téléchargement à usage unique) sert à ça ;)

          le lien est valable une fois et après, hop, c'est fini.
  • # Testé ... et adopté

    Posté par  (site web personnel) . Évalué à 2.

    Cela faisait longtemps que je cherchais ( passivement, je l'avoue ) un truc de ce style. Qui fait exactement ce qu'on lui demande et rien d'autre.

    Eh bien je suis très content de Jyraphe !

    Bravo, et merci :)
    • [^] # Re: Testé ... et adopté

      Posté par  (Mastodon) . Évalué à 7.

      J'ai longtemps cherché aussi et j'avais un script dans un coin qui faisait un simple upload. Je l'ai juste un peu améliorer et hop, la Jyraphe est à disposition de tous.

      J'avais croisé plusieurs personnes qui avaient déjà exprimé le besoin d'un tel script. Alors je me suis dit : fais le et partage le.
  • # FileX

    Posté par  (site web personnel) . Évalué à 2.

    Et par rapport à FileX [http://www.projet-plume.org/fiche/filex], c'est quoi la différence ? On utilise ça dans mon école et ça marche plutôt bien.
    • [^] # Re: FileX

      Posté par  (Mastodon) . Évalué à 3.

      FileX est beaucoup plus compliqué (nécessité d'authentification, notification par mail, etc). Dans Jyraphe, il n'y aura jamais toutes ces fonctionnalités, ce n'est pas nécessaire.

      Surtout FileX est totalement centralisé. Le but de Jyraphe est principalement de décentraliser cette fonctionnalité de dépôt de fichiers. FileX s'adresse à des entreprises/organisations qui ont besoin d'un service commun. Jyraphe s'adresse aux geeks/power users/gars qui s'y connait qui vont tous installer ça dans leur coin.
    • [^] # Re: FileX

      Posté par  . Évalué à 1.

      FileX impose PERL, et tout le monde n'y a pas accès, alors qu'un petit bout d'hébergement avec PHP ...

      En retour FileX propose plus de fonctionnalités, mais c'est justement la simplicité de Jyraphe qui rend l'outil attrayant selon moi.
    • [^] # iFile

      Posté par  (site web personnel) . Évalué à 2.

      tant qu'on y est, et par rapport à ifile, enfin hyla maintenant https://linuxfr.org/2007/04/25/22412.html
      • [^] # Re: iFile

        Posté par  (Mastodon) . Évalué à 2.

        hyla est un gestionnaire de fichier en ligne, c'est bien bien bien plus que ce que fait Jyraphe.
    • [^] # Re: FileX

      Posté par  (site web personnel) . Évalué à 2.

      Et par rapport à FileZ [http://gpl.univ-avignon.fr/filez/] ?
      • [^] # Re: FileX

        Posté par  (Mastodon) . Évalué à 2.

        C'est le même genre d'application mais Jyraphe est plus simple : pas d'authentification de l'utilisateur (celui qui dépose) et surtout pas de base de données.
  • # Ce que j'aimerai ...

    Posté par  . Évalué à 1.

    C'est synchroniser un dossier de fichiers sur un serveur web.
    Je voudrais pouvoir taguer certains fichiers, les décrire, etc ...
    Et pouvoir effectuer des recherches via une interface web.

    En bref, synchroniser mes fichiers en utilisant un peu de sémantique.

    Est-ce que ça existe ? (à part la solution svn, et encore c'est pas adapté aux tagages).
    • [^] # Re: Ce que j'aimerai ...

      Posté par  (site web personnel) . Évalué à 3.

      Cela existe dans certain CRM/ERP/CMS...

      Tutos, phproject,

      Plus lourd :

      eGroupware, Spip....

      Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

      • [^] # Re: Ce que j'aimerai ...

        Posté par  . Évalué à 1.

        Merci mais j'ai oublié de préciser 2/3 points :
        * la synchronisation s'effectuerait à partir du desktop.
        * c'est vraiment pour avoir une copie locale des fichiers (donc si je modifie un tag côté ou je supprime un fichier du dossier, une nouvelle synchronisation le prend en compte).
        * idéalement, ce serait un plugin (pour explorer ou finder ou nautilus ou ...), clic droit sur le dossier, synchronisation, avec possibilités d'annoter les fichiers du dossier.
        • [^] # Re: Ce que j'aimerai ...

          Posté par  . Évalué à 1.

          Je ne sais pas si ça peut t'aider, mais il n'y a pas moyen de faire ce genre de choses avec WebDAV ?
          • [^] # Re: Ce que j'aimerai ...

            Posté par  . Évalué à 2.

            Selon les systèmes, le support client de WebDAV est parfois très limite (y compris sur des systèmes très courants).
  • # Clients courriels

    Posté par  (site web personnel) . Évalué à 2.

    Et voilà, il ne reste plus qu'à créer des plugins pour les différents logiciels de courriel, et ainsi disposer d'une alternative intéressante et automatique aux pièces jointes...

    Bien joué! :)
    • [^] # Re: Clients courriels

      Posté par  (Mastodon) . Évalué à 2.

      Je n'y avais pas pensé mais ça pourrait être une bonne idée. Je laisse le soin à d'autres de le faire :)
  • # felicitations...

    Posté par  . Évalué à 2.

    Excellent... Vraiment SIMPLE et EFFICACE. Super. Merci.

    PS: qu'est-ce que je suis sensé mettre dans config.local.pfp pour l'avoir en français? j'ai essaye

    $cfg['lang'] = 'fr_FR.UTF-8';

    mais ça a pas l'air de fonctionner...
    • [^] # Re: felicitations...

      Posté par  (site web personnel) . Évalué à 2.

      il faut aussi générer les fichiers de langue (update_mo.sh et update_po.sh) qui créent les fichiers dans pub/local (de tête)

      (oui, moi aussi testé et adopté, merci beaucoup !)
      • [^] # Re: felicitations...

        Posté par  (Mastodon) . Évalué à 2.

        Oui, c'est vrai que je n'ai pas généré les locales dans le tarball, je vais y penser pour la prochaine fois.

        Comme indiqué, il suffit d'exécuter update_mo.sh qui va générer tout ce qu'il faut dans pub/lib/locales.

        Merci de l'utiliser, n'hésitez pas à faire remonter les bugs et les suggestions d'amélioration.
  • # Et un Jyraphe de plus

    Posté par  (site web personnel) . Évalué à 1.

    Un grand merci. J'ai installé Jyraphe sur un bout de serveur, et j'en suis super content. Bonne continuation !
  • # selinux et gentoo

    Posté par  . Évalué à 1.

    pour installer sous gentoo il faut le USE flag nls dans php...
    pour installer avec selinux il suffit de faire(après avoir crée le répertoire et fait un chown apache:apache /var/www/localhost/htdocs/pub/var):
    # chcon -R -t httpd_tmp_t /var/www/localhost/htdocs/pub/var
    (trouvé grâce au doc sur selinux et gallery)
    • [^] # Re: selinux et gentoo

      Posté par  (Mastodon) . Évalué à 2.

      Merci, je vais l'ajouter à la documentation
    • [^] # Re: selinux et gentoo

      Posté par  . Évalué à 2.

      Ça ne supporte pas un relabel.
      Il faut faire un module selinux.
      • [^] # Re: selinux et gentoo

        Posté par  (Mastodon) . Évalué à 2.

        Alors ça marche ou ça marche pas cette ligne de commande ?
        Mettez vous d'accord et/ou trouvez une solution qui marche partout...
        • [^] # Re: selinux et gentoo

          Posté par  . Évalué à 2.

          Oui ça marche. Mais c'est généralement considéré comme temporaire (puisqu'un relabel peut virer la modif).

          > une solution qui marche partout...

          La solution proposée marche partout. Du moins la méhode marche.

          Enfin ceux qui utilisent Fedora (qui a les modules SeLinux, etc) seront "traduire" le "chcon ...".

          Donc c'est OK pour le mettre dans la documentation.
  • # Fonctions que j'aimerais

    Posté par  (site web personnel) . Évalué à 2.

    J'étais justement à la recherche d'un logiciel comme celui-là, j'étais parti sur filex mais la sortie de Jyraphe me fait reconsidérer tout ça.

    Bref, voila quelques idées qui pourraient être intéressantes. Elle ne le sont pas toutes pour mon cas mais si ça peut donner des pistes de développement...

    - Durée limitée du fichier :
    Oui parce que j'aimerais le mettre à disposition d'un nombre assez important de personnes et j'ai pas envie de laisser les fichiers s'accumuler.
    Ce serait bien de pouvoir choisir la durée au moment de l'upload du fichier avec valeur par défaut configurée dans l'application et avec une valeur maximale également configurable (infinie ou limitée).

    - Droits accès au fichier :
    Ça peut-être pas mal d'associer un mot de passe à un fichier pour éviter que n'importe qui puisse le télécharger.

    - Vignette pour photo :
    Si je met une photo, j'aimerais bien avoir une miniature de cette photo aussi, directement utilisable sur un forum. Voir les sites qui proposent ce genre de truc comme http://www.imageshack.us/


    J'avais d'autres idée il me semble mais avec l'heure, elles se sont envolées désolé.
    • [^] # Re: Fonctions que j'aimerais

      Posté par  (Mastodon) . Évalué à 2.

      Durée limitée et mot de passe, c'est un peu le même genre de fonctionnalités, je crois que c'est possible à faire. Je vais voir ça dans les prochaines versions.

      La vignette pour photos, je suis moins chaud. Jyraphe n'est pas censé être un dépôt de fichier permanent mais juste servir quand rien d'autres ne marche (exemples : pièces jointes de fichiers trop grosse, transfert de fichier MSN merdique). Je ne veux pas avoir à gérer spécifiquement des photos. Mais bon, si plein de gens le demandent, ça pourra se faire (et en fait, ça peut déjà se faire vu que les photos sont affichées directement).
  • # nom de fichier pedu ?

    Posté par  . Évalué à 1.

    j'ai envoyé un fichier, mais au download il me le renomme (avec le hash utilisé pour le stockage ...)
    ce serait bien que le fichier garde son nom dans l'opération :-)
    • [^] # Re: nom de fichier pedu ?

      Posté par  (Mastodon) . Évalué à 2.

      Normalement, le nom de fichier est conservé (sauf pour ceux qui s'affichent directement, donc texte et image). Il est légèrement modifié en cas de collision avec un fichier déjà présent.

      Si ton fichier n'est ni un texte, ni une image, c'est un bug :)
      • [^] # Re: nom de fichier pedu ?

        Posté par  . Évalué à 1.

        mon fichier etait un fichier de log (unison.log) et je pense que qule-que-soit le fichier ce serait bien de récupérer sous le nom d'origine :-)
        • [^] # Re: nom de fichier pedu ?

          Posté par  (Mastodon) . Évalué à 1.

          donc fichier texte...

          je vais essayer de voir si c'est possible d'avoir le nom original pour les fichiers à afficher directement mais je ne promet rien ça dépendra plus de PHP et de ses fonctionnalités que de moi.
  • # Le prochain design

    Posté par  . Évalué à 4.

    J'ai réalisé un design pour Jyraphe, qui j'espère sera disponible pour la prochaine version.

    Il est visualisable à cette adresse: http://up.blogjaune.fr/ :-)

    Par contre, j'ai pas regardé si il passait sous IE pc. Normalement oui, c'est très simple comme mise en page.

    Envoyé depuis mon lapin.

    • [^] # Re: Le prochain design

      Posté par  (Mastodon) . Évalué à 2.

      alors, plusieurs remarques :
      - quelle est la licence de la photo que tu utilises ? (en particulier, est-elle compatible avecla licence de Jyraphe, l'AGPLv3+) ;
      - tu as mis le titre en dur dns l'image, ce qui casse l'i18n ;
      - je ne suis pas spécialement fan des design où tout est fixé mais bon, après tout, si certains aiment.
      • [^] # Re: Le prochain design

        Posté par  . Évalué à 2.

        Photo trouvée sur flickr, en creative commons, libre de droit, et modifiable, réutilisable commercialement, etc…

        Pour le titre, moi j'aime bien l'anglais. Maintenant, c'est tout à fait possible de le virer de la photo pour l'i18n.
        Puis si t'aimes pas, tant pis, je le garde pour moi :-)

        Envoyé depuis mon lapin.

        • [^] # Re: Le prochain design

          Posté par  (Mastodon) . Évalué à 2.

          Tu peux donner l'url de la photo si tu l'as ?

          Sinon, c'est pas que j'aime pas, c'est que je veux que ce soit utile pour le plus grand nombre, mon avis personnel compte assez peu en fait.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.