Wikini

ActionAttachBug

PagePrincipale :: DerniersChangements :: DerniersCommentaires :: ParametresUtilisateur :: Vous êtes ec2-98-80-143-34.compute-1.amazonaws.com
Bugs de l'ActionAttach (contribution avancée)

8 mars 2005
Pb
Cette ActionAttach complèterait admirablement le wikini alors j'ai installé le zip de l'ActionAttach.
ça avait l'air de marcher sauf que impossible d'uploader l'image via l'interface fournie :
C'est une ligne dans une fonction "Perform Upload" qui pose probleme :
if (move_uploaded_file($srcFile,$destFile)){ ...
??? Que faire ou y a t il une version qui corrige ce problème ???
(c'est hébergé sur apinc et le test a lieu sur la page http://kiosq.info/ecowiki/wakka.php?wiki=TesT)

2004-07-16
Bug
Trés interessé par cette action, je viens de faire des tests sur http://codedb.delphicenter.com/wikiAttach/wakka.php?wiki=TestAttach
Je rencontre des difficultés lorsque j'essaye de downloader un petit fichier texte (2 ou 3 lignes, taille sur mon disque dur : 12 octets) que je viens d'uploader. Je récupère soit une partie du fichier (les 1ers caractères), soit rien du tout.
Plus de détails ici
Merci !
Réponse
J'essaye de voir ca dés que j'ai un peu de temp.
--GarfieldFr
Correction
Ca fonctionne maintenant. Belle réactivité, et je suis ravi de t'avoir aidé à améliorer un petit peu plus encore l'ActionAttach !!!

Voici le code de la correction pour les impatients. Je ne suis pas parfaitement satisfait car il semble que le download plante encore dans certain cas.
Voici le code de la fonction doDownload fichier /actions/attach.class.php ligne 404
J'ai ajouté une serie d'entête HTTP mais je sais pas trop lesquelles font que ca marche. En tous cas ca marche impécablement sous IE6-SP1 et Firefox 0.9.2. Sous Opera 7.53 il semble y avoir parfois des problèmes.
<?php
    function doDownload(){
        $this->file = $_GET['file'];
        $fullFilename = $this->GetUploadPath().'/'.$this->file;
        if(!file_exists($fullFilename)){
            $fullFilename = $this->GetFullFilename();
            $dlFilename = $this->file;
            $size = filesize($fullFilename);
        }else{
            $file = $this->decodeLongFilename($fullFilename);
            $size = $file['size'];
            $dlFilename =$file['name'].'.'.$file['ext'];
        }
        header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
        header("Content-type: application/force-download");
        header('Pragma: public');
        header("Pragma: no-cache");// HTTP/1.0
        header('Last-Modified: '.gmdate('D, d M Y H:i:s') . ' GMT');
        header('Cache-Control: no-store, no-cache, must-revalidate'); // HTTP/1.1
        header('Cache-Control: pre-check=0, post-check=0, max-age=0'); // HTTP/1.1
        header('Content-Transfer-Encoding: none');
        header('Content-Type: application/octet-stream; name="' . $dlFilename . '"'); //This should work for the rest
        header('Content-Type: application/octetstream; name="' . $dlFilename . '"'); //This should work for IE & Opera
        header('Content-Type: application/download; name="' . $dlFilename . '"'); //This should work for IE & Opera
        header('Content-Disposition: attachment; filename="'.$dlFilename.'"');
        header("Content-Description: File Transfer");
        header("Content-length: $size".'bytes');
        readfile($fullFilename);
    }
?>


L'archive a été mise à jour.
--GarfieldFr

Bug
La classe CSS "attach_noborder" ne fonctionne pas, car elle ne s'applique qu'à la balise <span> englobant la balise <img>. Pour obtenir l'effet désiré, il est nécessaire de mettre dans wakka.css une déclaration du type img { border: 0; }. Mais ceci a alors empêche l'affichage des bordures de toutes les images du site !
--NicolasM

Je comprend pas ce que tu veux, les images sur la page de test n'ont pas de bordure sauf celles qui désignent un lien --GarfieldFr

En lisant la doc, j'avais compris que que même si l'image désigne un lien, avec la classe "attach_noborder" on arrivait à supprimer l'affichage disgracieux (AMHA) autour de l'image. Il me semble que ce serait une bonne idée d'implémenter ceci, sinon je ne vois pas l'utilité de cette classe.
--NicolasM

En effet, c'est disgracieux, mais tu peu réglé le problème en mettant : a img{border: 0;} comme CSS. Les images dans un lien seront sans contour. --GarfieldFr

Bug
Petit problème lors de l'installation d'AttachFile?, impossible d'uploader le moindre fichier.
En cliquant sur un lien, l'URL à l'air correcte, mais mon WikiNi me propose de créer une nouvelle page, et pas de choisir un fichier à uploader...

Avez-vous une petite idée?


Peut être un problème de droit pour l'upload sur le serveur. Il faudrait que je puisse voir le problème si ton WikiNi est accéssible (bien que je n'ai pas beaucoup temp en ce moment) --GarfieldFr


Merci de votre aide, malheureusement, mon WikiNi est uniquement local...
Au niveau des droits d'upload, quelles autorisations dois-je appliquer? Il ne me semble pas avoir vu une telle documentation...

D'avance merci!

Pour la doc, il faut surtout lire les sources de l'action, dans le cartouche de commentaire en haut il doit y avoir la doc en principe (en tous cas je l'ai mise la). Pour les droits, il faut que le répertoire d'upload soit accessible en lecture/écriture et qu'il soit possible de créer des sous répertoire. Attention si vous fonctionner dans le mode "SAFE_MODE" de PHP, il faudra créer le répertoire d'upload "à la main" et mettre dessus des droit d'écriture. L'utilisateur devant avoir les droit d'écriture est biensur celui qui exécute les scripts (cela peu varier selon la config du serveur). En mettant les droits d'écriture au groupe, ça fonctionne dans la pluspart des cas. --GarfieldFr

Merci de passer du temps pour m'aider à la configuration...

Vous pouvez voir le problème ici

http://oberli.dyndns.org/wiki/wakka.php?wiki=LesMathematiques

en changeant les proprietés du dossier files, rien ne change...
Le SAFE_MODE de php est bien sur OFF.

Voici un aperçu deermissions des dossiers :
# ls -la
total 120
drwxrwxrwx 8 root root 4096 sep 17 06:37 .
drwxr-xr-x 5 root root 4096 sep 12 04:44 ..
drwxr-xr-x 2 root root 4096 sep 17 06:41 actions
-rw-r--r-- 1 501 501 17992 fév 18 2004 COPYING
drwxrwxrwx 4 apache apache 4096 sep 12 10:08 files
drwxr-xr-x 2 root root 4096 sep 12 04:37 formatters
drwxr-xr-x 3 root root 4096 sep 12 04:37 handlers
-rw-r--r-- 1 501 501 1454 fév 18 2004 index.php
-rw-r--r-- 1 501 501 1083 fév 18 2004 INSTALL
-rw-r--r-- 1 501 501 4249 sep 24 2003 interwiki.conf
-rw-r--r-- 1 501 501 1798 fév 18 2004 LICENSE
-rw-r--r-- 1 501 501 736 fév 20 2004 README
drwxr-xr-x 3 root root 4096 sep 12 05:55 setup
-rw-r--r-- 1 501 501 1815 fév 24 2004 wakka.basic.css
-rw-r--r-- 1 root root 1347 sep 17 06:37 wakka.config.php
-rw-r--r-- 1 501 501 3778 sep 12 09:48 wakka.css
-rw-r--r-- 1 501 501 30740 jun 8 13:52 wakka.php
drwxr-xr-x 6 root root 4096 sep 12 10:19 wikini

Merci encore pour votre aide...

Donc a priori, ce n'est pas un problème de droit d'accès en écriture. Est tu sur d'avoir la dernière version de l'action ? Et de WikiNi ?
Par contre en regardant le lien d'upload, il me parait bizarre, voici le lien sur ton site : http://oberli.dyndns.org/wiki/wakka.php?wiki=LesMathematiques/upload?file=test.txt
alors qu'il devrait être : http://oberli.dyndns.org/wiki/wakka.php?wiki=LesMathematiques/upload&file=test.txt
Il doit y avoir une faute de frappe quelque part.... Je regarde rapidement --GarfieldFr

Je viens de regarder rapidement le code, il semble que le mode de réécriture d'URL soit actif dans ton fichier de configuration et c'est ce qui provoque l'erreur. Sur ton site, le mode rewrite ne semble pas être utilisé donc enlève le de ton fichier de configuration. Il faut avoir dans le fichier wakka.config.php :
"rewrite_mode" => "0",
--GarfieldFr

C'est parfait maintenant! Merci beaucoup de votre aide!

Bug / fonctionalité
Si on écrit {{attach file="image" desc="Une image" class="left" }} est que l'on oublie de mettre l'extension au fichier image on obtient le message d'erreur:
Erreur lors du déplacement du fichie temporaire.
Je n'ai pas regardé le code en détail mais il semblerait que l'on puisse tester cela au niveau de la ligne 382 du fichier attach.class.php pour pouvoir afficher
Erreur vous n'avez pas saisi d'extension à votre nom de fichier. ou quelque chose dans le genre... -- JeanPascalMilcent

Non, car ce message d'erreur peut apparaitre pour autre chose qu'un problème d'extension de fichier. C'est le message d'erreur qui est affiché lorsque php n'a pas réussi à déplacer le fichier du repertoire temporaire d'upload vers le répertoire définitif. --GarfieldFr

Bug
Le message d'erreur Warning: Unable to access in /data/www/r/e/mi.ouvaton.org/html/wiki2/actions/attach.class.php on line 317 apparait une fois l'action attach enregistrée dans la page. Voir : http://www.remi.ouvaton.org/wiki2/wakka.php?wiki=BacASable
Quelqu'un a t il déjà rencontré ce problème? Je ne voie pas ce qui peut poser problème. -- JeanPascalMilcent

Je pense que c'est parce que les options d'affichage d'erreur de PHP demande l'affichage des warnings. 2 solution: changer les option dans php.ini ou .htacces (voir la doc sur www.php.net) ou peut être mettre le code suivant (ajout du @):
		if((!@file_exists($fullFilename))||($fullFilename=='')){
			$this->showFileNotExits();
			return;
		}

--GarfieldFr


Bug
Bonjour. Je test l'action attach sur mon site, et je rencontre les problèmes suivants:
Warning: Unable to create '': No such file or directory in /var/alternc/html/x/xref/actions/attach.class.php on line 379
Warning: Unable to move '/var/alternc/tmp/phpptpZIs' to '' in /var/alternc/html/x/xref/actions/attach.class.php on line 379
Erreur lors du déplacement du fichier temporaire.
Mon hébergeur me signal qu'Apache écrit une erreur:

[Thu Oct 21 09:54:42 2004] [error] PHP Warning: Supplied argument is
not a vali d Directory resource in
/var/alternc/html/x/xref/actions/attach.class.php on lin e 223

Quelle piste dois-je suivre pour résoudre ce problème?
NB:
MERCI D'AVANCE
GilBurban

Piste: Puisque le safe_mode est actif, il faut créer le répertoire d'upload à la main et lui mettre des droits d'écriture pour le groupe (je pense que c'est suffisant). Le problème du safe_mode est l'impossibilité de créer des répertoires à la volé (enfin, j'ai pas trouvé comment) et notament le répertoire de base ou sont stocké les fichier uploadés. Attention, avec le safe_mode, tous les fichiers seront dans le même répertoire et prefixé par le nom de la page. Avec le systeme de version de fichier, ca peut faire des nom de ficiher TRES long. --GarfieldFr

Suite du bug?
J'ai mis un message sur la page de test de l'action mais à priori mon message est mieux approprié ici. En fait, j'ai semble-t-il le même problème que celui soulevé par GilBurban (je suis chez free) et j'ai créé à la racine de mon site web le répertoire 'files' (entre nous la documentation ne dit pas -ou je l'ai pas vu- qu'il faut nommer ce répertoire 'files') et ensuite j'essai de modifier les droits sur ce répertoire qui est en lecture/écriture pour le propriétaire et 'interdit' pour le groupe mais je ne parviens pas à lui faire mettre lecture/écriture pour groups....comment dois-je faire??? merci pour votre aide.
Cyrille.

Nom des fichiers téléchargés
Le seul problème que je rencontre avec ActionAttach est le nom des fichiers téléchargés sous IE. Sous Firefox et Opéra, impeccable, le nom est exactement celui du fichier. Sous IE, ça dépend de la version : IE6 ajoute des [0][1] entre le nom et l'extension on ne sait pas trop pourquoi, IE5.5 met carrément le nom de la page !
Remarque : pour tester sous plusieurs IE, j'utilise des versions 5.x sans installation, voir Browser Testing - css-discuss. -- JmPhilippe

Je n'y peux rien, hélas.... --GarfieldFr
Tu sais si c'est un problème connu (je veux dire un bug d'IE ;-) ) ? -- JmPhilippe
Bug
Il semblerait qu'il y ai des souci avec le téléchargement de fichier PHP zippés attachés avec cette action, on en parle en bas de la pagec ActionNewTextSearch.
-- Nicephore17
C'est bizarre, je n'est pas de problèmes avec les fichiers zipper que j'ai pu tester --GarfieldFr

COPIE DU PROBLÉME
Juste pour soulever un petit problème technique : le fichier téléchargé avec Firefox 1.0 n'est pas une archive valide alors qu'il l'est avec IE, utilises-tu l'ActionAttach pour les téléchargements ? J'aimerais bien savoir si c'est un bug PHP ou Firefox... -- JmPhilippe

Heuuu.. en fait, j'ai des souçsi avec le codage ASCII du fichier PHP... Je ne me posais pas la question jusqu'à ce que j'utilise this<-Format() et que les é,é,à... deviennent des caractéres étranges. Quoi que je fasse PHP l'interpréte sans trop de problèmes par contre, ça en pour pour la compression/écompression... Je ne sais pas trop comment faire.
NOTA: JE suis sous MAc OS X.3 j'utilsie TextEdit et jEdit et je compresse avec l'applicatif de base (dont j'ai oublié le nom, le truc avec une DropBox) si vous avez des idées.... à moins que je publie le code en %%...%%...
-- Nicephore17
Avec jEdit et TextEdit c'est possible mais bon ça m'énerve, je met les fichiers en download en *.php.
-- Nicephore17
Il y a quand même un truc qui m'échappe : t'es sous OS-X donc a priori avec un jeu de caractères non Windows, le téléchargement marche sous IE/Win mais pas sous Firefox/Win... Au boulot, certains ont eu des problèmes de ce genre avec des fichiers JAR sous IE 5.5/Win et l'action Attach. N'y aurait-il pas un problème PHP là-dessous ? -- JmPhilippe
Est ce que ça marche bien lorsque je les met à dispo en *.php? Et... PPC Power! -- Nicephore17
Là ça marche parfaitement, un petit diff me dit que les fichiers sont rigoureusement identiques avec Firefox et IE. Dommage que je n'ai pas eu le réflexe de le faire avec les fichiers zip, on en aurait peut-être su un peu plus... -- JmPhilippe
Tu veux que je te remonte un .zip un de ces 4 pour faire le test? -- Nicephore17
Pourquoi pas après tout, essayons de lui tirer les vers du nez ! -- JmPhilippe
C'est fait tu trouveras les deux version (.php et .zip) pour la version 1.6 -- Nicephore17

Et voilà ! Le diff dit que seule la fin des fichiers ne colle pas : il manque quelques octets avec la version Firefox. Fin du fichier téléchargé par Firefox (ligne: hexa + texte) :
0A68: 68 2E 70 68 70 50 4B 05 h.phpPK.
0A70: 06 00 00 00
Fin du fichier téléchargé par IE :
0A68: 68 2E 70 68 70 50 4B 05 h.phpPK.
0A70: 06 00 00 00 00 01 00 01 ........
0A78: 00 3F 00 00 00 2E 0A 00 .?......
0A80: 00 00 00
Mystérieusement les 15 derniers caractères ont disparu avec Firefox... Entête Html ? Php ? Firefox ? Non, ce n'est pas Firefox car je viens d'essayer avec Mozilla 1.6, Netscape 7.1 et Opera 7.54, et aucun ne récupère ces fameux 15 derniers octets ! Serait-ce IE qui ajoute tout seul ce qu'il n'a pas reçu ? Décidément bien étrange...
Au passage, j'aime bien le petit message qui dit aux pauvres utilisateurs d'IE qu'avec Firefox ils auraient un monde plus riche ;-). -- JmPhilippe

Vous avez bien la dernière version de l'action attach ? Celle avec le gestionnaire de fichier. Cette histoire de 15 octets me rappel vaguement quelque chose mais c'était dans une des premières version de l'action attach il me semble. --GarfieldFr

Heu... là qu'on me le demande.... En réalité je n'en sais rien et, à ce propos j'aimerais rapporter ce problème: comment fait on pour identifier la version de ton action? Il semblerait que tu as oublié de référencer clairement la version dans les commentaires de ton action.... (j'ai regardé dans actionattach.php et dans attach.class.php). -- Nicephore17

Pour ma part j'ai installé sur l'intranet la version avec gestionnaire de fichiers, le script principal attach.class.php date du 20/07/04. J'ai mis le fichier zip sur le serveur intranet et j'ai le même problème des 15 octets... Est-ce qu'il ne faudrait pas théoriquement envoyer le type MIME exact du fichier lors du download au lieu d'un systématique octet-stream, par exemple application/zip pour un fichier zip ? -- JmPhilippe

Notez une chose concernant le problème de download: sur la page http://codedb.delphicenter.com/wikiAttach/wakka.php?wiki=PagePrincipale contenant la dernière version de l'action vous n'avez eu aucun problème de download alors que cette page utilise l'action attach pour distribuer l'archive !! Cette archive a été uploadée sur un serveur IIS avec FireFox comme client. Je la récupère sans problème sous FireFox et IE6 sous Windows et vous ?--GarfieldFr
Je confirme que moi non plus je n'ai pas de problème avec ce fichier sous Firefox 1.0 et IE 6.0. Est-ce que tu peux y mettre aussi l'archive de ActionNewTextSearch histoire de voir si c'est le fichier ou la config serveur qui pose problème ? -- JmPhilippe
Idem ici, avec Maxthon pour le test d'IE. -- LordFarquaad


bug (résolu)
Les balises link marchent encore sur wikini 0.4.3 ? Dès que je met cette balise à mes photos, l'image se transforme en mon nom de fichier (soit ma tete > julien.jpg...) Le lien est actif, mais on a plus qu'un petit texte.... bouh Voirici. Sinon, le principe est génial, bravo GarfieldFr... --JulienBras
Je vous met les lignes en questions ci-dessous :
<?
        // forced links
        // \S : any character that is not a whitespace character
        // \s : any whitespace character
        // ligne de 0.4.3
        //else if (preg_match("/^\[\[(\S*)(\s+(.+))?\]\]$/", $thing, $matches))
        // ligne de 0.4.2
        else if (preg_match("/^\[\[(\S*)\s+(.+)?\]\]$/", $thing, $matches))
        {
            list (, $url, $text) = $matches;
            if ($url)
            {
                if ($url!=($url=(preg_replace("/@@|££|\[\[/","",$url))))$result="</span>";
                if (!$text) $text = $url;
                $text=preg_replace("/@@|££|\[\[/","",$text);
                return $result.$wiki->Link($url, "", $text);
            }
            else
            {
                return "";
            }
        }
?>

Demande aide pour résolution de problème, je suis prêt à bidouiller un peu, mais je pense qu'il est plus intéressant de modifier l'action plus que le coeur de wikini. A vous... --JulienBras

Il n'y a pas de commentaire sur cette page. [Afficher commentaires/formulaire]
2013-03-11 23:19:58 :: Propriétaire : WikiAdmin :: Rétro-liens :: Cartographie :: Recherche :
XHTML 1.0 valide ? :: CSS valide ? :: -- Fonctionne avec WikiNi 0.5.0 (interwiki)