Sujet fermé
Note de ce sujet :
  • Moyenne : 0 (0 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5

Future Version 1.11.5 - Report des "soucis"
#1

Citation :#~~~~~ DEBUT BLOC A NE PAS SUPPRIMER ~~~~~
#~ Future Version du CMS: 1.11.5
#~~~~~ FIN BLOC A NE PAS SUPPRIMER ~~~~~


En vue de la sortie future de la version 1.11.5, merci d'indiquer ici des problèmes ou bug non corrigé sur le version 1.11.x
La dev Team ( Q/A Team) a fait un todo-list pour que les développeurs corrigent ces manques pour le core et les modules "livrés" avec le Core uniquement.

Indiquer donc
- si vous avez déposé des bugs non résolu sur le Bug Tracker
- si vous avez des problèmes ou "soucis" en indiquant le maximum d'information pour reproduire le phénomène ( version du cms ou du module, version PHP, serveur .... )

J-C Etiemble v 2.2.xx
#2

de français que je connais je vois 3 bugs :

8624 add a warning message if you try adding a huge content into a CSS form 2012-11-09 Trivial 1.11.2.1 None Open Nobody bess


8664 Site preferences "exists" mechanism fail 2012-11-22 Trivial 1.11.3 None Open Robert Campbell Jean-Christophe Cuvelier


8696 $config ['uploads_path'] and filemanager 2012-11-30 Major 1.11.2.1 Works For Me Open Robert Campbell Jean-Marc Lerouge
#3

Citation :8624 add a warning message if you try adding a huge content into a CSS form
Un peu d'explication pour bien comprendre j'ai un "vieux doute"

Citation :8664
OK

Citation :8696
A revalider

par contre je viens de trouver - A confirmer par autre source Wink en mode php.ini error_reporting = E_ALL
"Notice" sur
{print showbutton=true script=true}
cela affiche Notice: Trying to get property of non-object in \lib\module.functions.php on line 40
en remplaçant par {cms_module module='CMSPrinting' showbutton=true script=true} c'est OK

J-C Etiemble v 2.2.xx
#4

il n'y a rien qui vérifie la taille des données balancées sur les formulaires dans le backend.

exemple avec un text > 64000 caractères que tu balancerais dans j'ajout de CSS : seul les 64000 premiers seront sauvegardés en base sans que l'utilisateur ne soit alerté

ce qui dérange c'est pas la limite implicite de la bdd, c'est qu'aucun message n'ai avertis l'utilisateur: attention vous dépassez la limite du champs de 64 000 caractères

Cela doit être surement vrai avec tous les champs de type textArea j'imagine
#5

Citation :attention vous dépassez la limite du champs de 64 000 caractères
Ok je transmets mais 64 K c'est ennnnorme

J-C Etiemble v 2.2.xx
#6

oui c'est certain Wink
#7

Pas d'autre report ??

J-C Etiemble v 2.2.xx
#8

Pour être bien honnête, je crois que mes problèmes n'intéressent pas grand monde :

pas capable d'updater à 1.11.4 (cache vidé, menu/template non-cachable, pas de tags dépréciés) : http://forum.cmsmadesimple.org/viewtopic...3&p=291679

html5 et WYSWYG : http://www.cmsmadesimple.fr/forum/viewtopic.php?id=4828

news et browsecat : http://dev.cmsmadesimple.org/bug/view/8250

Et il y a le changement postdate/startdate des news que je n'ai pas encore trop compris, mais qui du point de vue utilisateur non-intuitif et surtout non-documenté : http://www.cmsmadesimple.fr/forum/viewtopic.php?id=4638
#9

Citation :pas capable d'updater à 1.11.4 (cache vidé, menu/template non-cachable, pas de tags dépréciés) :
je ne comprends pas bien ta remarque car non documentée, j'ai demandé " le maximum d'information" et la je ne vois rien et en lisant les liens je me pose des questions sur : "pas capable" !
1- update depuis quelle version ? quel hébergeur que php et le maximum d'information
2- envoi moi en privé le fichier SQL de l'export de ta base de données avant update pour tester

Citation :postdate/startdate
tu as eu la réponse mais faut peut être lire la doc Smile

Rappel http://www.cmsmadesimple.fr/forum/viewto...427#p33427

J-C Etiemble v 2.2.xx
#10

@ bess Retour de Calguy

[#8624] add a warning message if you try adding a huge content into a CSS form ... it should be more useful to display an Alert message (jce76350)
This is not a new issue... not worth messing with for 1.11.

[#8664] Site preferences "exists" mechanism fail In some cases, the site_prefs database contain entries with empty value. In this case, the mechanism to choose between insert and update is dislfunctionning.
I have tested this... unable to reproduce. Not worth fixing for a 1.11.5

J-C Etiemble v 2.2.xx
#11

Citation :This is not a new issue...

ça veut pas dire que c'est pas à corriger.... sa façon de penser m'échappe ...
#12

>sa façon de penser m'échappe .

à moi aussi Sad

J-C Etiemble v 2.2.xx
#13

Pas de remarque complémentaire

J-C Etiemble v 2.2.xx
#14

Il semble que la version soit sans bug alors.

J-C Etiemble v 2.2.xx
#15

J'ai passé ce tour :p
#16

La sortie de la 1.15 est prévue sous 8 10 jours
Je constate à ce jour qu'il n'y a pas de report particulier (hormis ceux cité plus haut) aussi bien le fonctionnement que la mise à jour.

Pas de remarque complémentaire ?


Pour info le changelog de la 1.15
- GCB's can now only have letters and numbers in the name
- Fixes to caching issues in MenuManager and module templates
- Admin module actions now catch an exception
- Erase the alias of a sectionheader on save
- Fixes problem with error_reporting, takes error_reporting correctly from php.ini
- Fixes problem with contentprecompile not being fired
- Significant performance improvement in admin theme calculations (fixes silly error)
- Fix typo in /lib/classes/module_support/modtemplates.inc.php

J-C Etiemble v 2.2.xx
#17

ben je t'avoue que la 1.11.4 ne me pose pas de problème particulier donc bon Big Grin
#18

une mise à jour depuis 1.10.3 vers 1.11.4 pose problème

J-C Etiemble v 2.2.xx
#19

Un correctif est sorti en SVN 8669 sur les news pour corriger le problème
- mise à jour depuis 1.10.3 vers 1.11.5
- table cms_routes

le nom de version sera : Puerto Ayora

J-C Etiemble v 2.2.xx
#20

si ca intéresse encore, je suis sur la piste d'un comportement anormal (!= bug) de l'application côté backoffice dans le cas d'une installation avec + 600 Mo de fichiers réparties sur 16 470 photos dans les sous répertoires d'upload

symptômes : lenteurs excessives menant à des Timeouts, des erreurs 500 et ceci dans les logs sur OVH

Premature end of script headers: moduleinterface.php, referer: http://xxx.xxx/admin/imagefiles.php?_sx_=a29f3ea9

en local je n'ai pas d'erreur mais je ressent la lenteur à chaque chargement de ces pages :

Gallery
ImageManager (???)
FileManager
Modules (????)

php 5.3, cmsms 1.11.4 sur une ancienne 1.9.4 et je n'ai pas activé la nouvelle interface pour justement éviter le bug du scan de sous répertoire pour le quick-upload qui , on le sait, déconne en cas de très grands nombre de sous répertoire.

bref je sens un scan en profondeur qui fout la merde et qui est pour le coup totalement inutile... je chercherais encore demain soir
#21

Citation :bref je sens un scan en profondeur qui fout la
Essai de désactiver FileManager pour voir

J-C Etiemble v 2.2.xx
#22

je ferrais ce soir Wink
#23

donc j'ai de bonnes et de mauvaises nouvelles.

la bonne : j'ai repéré le bug
la mauvaise : il y a clairement un manque de fonctionnalité, voir un bug.

Explication :

Il existe dans la class /lib/ImageManager/Classes/ImageManager.php une fonction getDirs() qui , en substance, donne la liste des répertoires et sous répertoires existant à partir d'un path donné à la classe que nous appellerons ici $PATH

Dans notre cas (4 ou 5 niveau de profondeur, des milliers de fichiers) ça prend du temps de tout explorer. C'est normal dans l'absolu ...


Seulement, il y a une autre fonction dans cette classe : validRelativePath(), une fonction qui a pour rôle de déterminer si un path relatif passé en paramètre est correct par rapport au $PATH de la classe. Je me serais attendu à un code de ce type :
* contrôle d’existence de répertoire
* doublé par un contrôle regex sur l'absence de chemin foireux (../../../../config.php) ,
* triplé par un contrôle pour s'assurer que le path relatif démarre bien de $PATH.

Rien de complexe à priori ... sauf que le code de validRelativePath() fait appel à getDirs() qui réalise du coup un listing TOTAL des répertoires existants pour voir si il existe bien dans la liste ... Encore mieux : il réalise ce scan pénible et retourne true si le paramètre est égal à '/' ... autant dire que le scan est fait inutilement dès lors que vous êtes à la racine ^^

J'ai loupé un wagon là ....


Citation :/**
* Check if the given path is part of the subdirectories
* under the base_dir.
* @param string $path the relative path to be checked
* @return boolean true if the path exists, false otherwise
*/
function validRelativePath($path)
{
$dirs = $this->getDirs();
if($path == '/' || $path == '\/') return true; // stupid windoze.
//check the path given in the url against the
//list of paths in the system.
for($i = 0; $i < count($dirs); $i++)
{
$key = key($dirs);
//we found the path
if($key == $path) {
return true;
}

next($dirs);
}
return false;
}

Et manque de bol .... la fonction validRelativePath() est utilisée un peu partout ...

La boucle est bouclée : tu te tapes des timeout en ligne dès que ton hébergement n'est pas capable de scanner tes répertoires en moins de 30s ... Comportement différent de la 1.9.4.3 ou nous n'avions pas de lenteur

Voilà, je laisse les autres commenter mon analyse, néanmoins je vais devoir sans aucun doute pondre un nouveau code pour assurer le site de vivre sans pour autant mettre sa sécurité en jeu ^^'
#24

une correction qui tiens du miracle, merci google

Code :
[== Indéfini ==]
    function validRelativePath($path)
    {
        return strpos(
            realpath($this->getBaseDir() . DIRECTORY_SEPARATOR . $path),
            realpath($this->getBaseDir())
        ) === 0;
    }

c'est instantané, c'est sécurisé (j'ai tenté de foutre des chemins bizarres, des inconnus et des ../../../truc , tout est bon)

bref le bug est bon à être corrigé pour moi :]
#25

Tiens, on reviens sur un bug du svn 8553, voici la proposition que j'avais donné en message privé à Calguy, mais auquel il n'y a eu aucun suivi.
Citation :Hi,

The removal (8553) works, but the $path still incorrect: \/

ValidRelativePath($path) is used to check if a path is valid and it is not (I think so that this function should be in Files.php and not ImageManager.php).

All functions ImageManager and $relative call fixPath().
This is the function fixPath() that corrects the path and it is what must be used.

Here are the changes I propose for this function and you will not say more, I hate windoze Wink
Code :
static function fixPath($path)
   {
      //replace \ with / if needed
      $path = str_replace('\\','/',$path);
      //append a slash to the path if it doesn't exists.      
      if(!(substr($path,-1) == '/'))
         $path .= '/';
      
      return $path;
   }

Eg: ImageManager line 325 :
Code :
function getThumbURL($relative)
   {
      $path_parts = pathinfo($relative);
      $thumbnail = $this->config['thumbnail_prefix'].$path_parts['basename'];
      //if($path_parts['dirname']=='\\') $path_parts['dirname']='/'; //no more needed with fixPath

Thanks for your attention and your great work Smile

Jean-Marc
Sujet fermé


Atteindre :


Utilisateur(s) parcourant ce sujet : 4 visiteur(s)