Jump to content

kzone

Members
  • Posts

    73
  • Joined

  • Last visited

Everything posted by kzone

  1. oui , mais justement pour éviter ce genre de probléme , je n'utilise que des minuscules pour tous mes noms de fichiers et bien sûr sans espace ;-) mais bon .. y'a tout de même un couac ... moi peut-etre :coolsmile:
  2. n'empeche que cela ne change pas le problème si le client installe sa Presta sous window et que quelque temps après il décide de basculer sous Linux .. Il ne sera pas possible de porter tel quel son site et les modifs risquent de ne pas être une partie de plaisir .. ;-) bien entendu que $coucou et $Coucou ne sont pas les meme en Php ...mais ce n'est pas le problème non plus concernant ServiceContact avec les majuscule c'est Prestashop qui "impose" cet orthographe dans la syntaxe (il m'a fallu remonter à l'autoload pour voir d'ou venait le problème) ... m'enfin !
  3. salut pierre yves ... non je rigole pas Ben chez moi il y a longtemps que j'ai balancé Windows pour un Ubuntu et un Mandriva ... y'a pas photos ! Mais le fait d'avoir écrit le code sous windows ( :sick: ) et de les passer sous une Debian tel quels me posent quelques petits soucis ... Mais si tu n'as aucun problème pour tes sites sous linux , cela me rassure ... mais faut que je "débugge" mon code maintenant ! j'ai comme l'impression que c'est un problème de $cookie ... enfin bon j'espère que je vais m'illuminer assez vite :exclaim: et que l'eureka viendra rapidement merci
  4. bonjour à tous, Après avoir configurer des nouveaux modules sous Window, nous avons voulu basculer ces mêmes modules sous un *nux (un Debian) et il est apparu quelques problèmes de reconnaissance de varaible et de localisation de fichiers. premièrement il existe une différence dans la lecture des majuscules et minuscules entre les 2 systèmes , avec par exemple "servicesav" et "Servicesav" qui sont 2 mêmes fichiers pour window (lors de parsage de répertoire par exemple avec un readdir) ... il n'est pas possible d'ailleurs d'avoir ces 2 fichiers dans un même répertoire !!! ;-) Mais sous Linux ce sont bien 2 fichiers distincts et cela pose des problèmes lors de l'utilisation des recherches de fichiers comme par exemple autoload() (voir ficher config.inc.php) par exemple : fonctionne sous windows : global $smarty; global $cookie; include('../../config/config.inc.php'); include('../../header.php'); if (!$cookie->isLogged()) Tools::redirect('authentication.php?back=my-account.php'); $customer = new Customer($cookie->id_customer); $contact = new ServiceContact(); l'instanciation d'un objet ServiceContact est tout à fait possible sans devoir indiquer le chemin du fichier de description de la classe ; mais sous Linux ce fichier n'est pas trouvé ... Selon la définition de la fonction autoload du config.ini.php : if (!class_exists($className, false)) require_once(dirname(__FILE__).'/../classes/'.$className.'.php'); ... et il cherche donc dans le répertoire classes le fichier ServiceContact.php (noter les majuscules) ...sous windows si le chier se nomme servicecontact.php ou ServiceContact.php ... pas de problème c'est le même pour lui ... Mais pas sous Linux ... :coolsmile: il faut le préciser à presta : require_once(_PS_MODULE_DIR_.'servicecontact/servicecontact.php'); Il n'existe aucune documentation concernant le nommage de fichier ce qui devient vite problématique sous Linux car une majuscule fait planter l'application ... Il existe donc un problème récurent de nommage des fichiers sous linux qui empeche les applications de tourner ... pour l'instant nous avons un problème concernant l'utilisation d'un objet $customer qui sous Window renvoie bien les valeurs des attributs ($customer->id_gender par ex.) mais sous Linux aucune valeur n'est retournée ... Comme il n'y a pas d'erreur , juste aucune valeur retournée, il n'existe pas non plus de trace pour trouver à quel endroit chercher ... quelques conseils si certain on réalisé une install sous un *nux ! Il serait bien d'optimier le code de Presta lors de parsage de répertoire à la recherche de fichier (pour la config , la traduction, ...) pour le sytème Linux et d'indiquer de ne pas tenir compte des "uppercase" .. merci ++
  5. pas inspiré la @prestateam :coolsmile: Aucune prévision pour cette table !? On peut l'utiliser sans risque de cout-circuiter une utilisation future :-)
  6. bonjour , on ne l'arrête plus ce Ludo Concernant tes remarques 'whitespirit' et surtout ... si ce n'est pas clair .... c'est que c'est mal formulé ou trop peu explicite ! ;-) et comme c'est une partie importante de presta , dès que j'ai 5 minutes je revois la syntaxe (voir développer un peu plus puisque cela semble nécessaire)
  7. Lors de développement de nos modules nous nous sommes aperçu que la table "gender" n'était pas utilisée et que la sélection 1 ou 2 se faisaint "en dur" dans le formulaire (avec un valeur par défaut = 9 établit dans la classe ) /** @var integer Gender ID */ public $id_gender = 9; Il n'y a donc pas de choix "mademoiselle" , et il aurait été peu être utile d'avoir une "gender_lang" pour l'internationnalisation ... J'aimerais donc savoir s'il est prévu une gestion plus 'optimale' des civilités dans les prochaines versions prestashop De notre coté , nous sommes tentés par l'ajout d'une radio dans le formulaire , mais si quelque chose est prévu du coté de Prestashop .... autant suivre même chemin merci
  8. bonjour la documentation sur le site de smarty me semble une très bonne adresse pour débuter. Ainsi que comme souvent les tutoriaux de developpez.com sont toujours bien fait et initiation aux templates Smarty ne déroge pas à la règle ..
  9. dans la partie I il y a en effet quelques tournures alambiquées et ponctuations manquantes qui rendent la lecture un tantinet plus compliquée :coolhmm:
  10. bonjour à tous merci merci :coolsmile: Concernant certaines tournures de phrases, je vais relire cela à tête reposée ... Et comme le souligne Ludo toute critique (constructive il va de soi) est bienvenue ... ;-)
  11. bonjour petite info : j'ai un "hack attempt" lorsque je tente de modifier la valeur donnée à la propriété name dans le constructeur d'un module $this->name = 'monmodule/sousrepertoire'; ps: je fais quelques tes en fait pour voir comment modifier le comportement lors de traductions d'expressions présentes dans les modules
  12. c'est avec grande tristesse que j'abondonne (pour l'instant) ma structure de fichiers pour ne pas perdre le bénéfice des traductions ... mais il y a surement moyen de tripoter un rien le code pour y arriver !! Petite remarque en passant concernant ces traductions (et pour ceux qui aurait à débugger leur code ) dans le style : J'aime j'aime pas (enfin Smarty aime Smarty n'aime pas ! :coolsmirk: ) - Smarty n'aime pas du tout les "doubles whitespaces" et en perd son latin : Si vous avez une page blanche ou plus probablement une syntaxe bizarre dans l'outil traduction du back office , vérifier ce point - Smarty n'aime pas non plus l'utilisation du 'double quote' ( " ) pour la méthode 's' genre : {l s="mon truc a traduire" mod="monblock"} Chez moi il n'accepte que les simple quote {l s='mon truc a traduire ... encore' mod='monblock'} - Dernier point pour éviter quelques pertes de cheveux (surtout les miens) inutiles : Sans mettre mod='...' la traduction ne s"effectue pas et en "brancher" sur l'original (code en dur) voilà , j'y retourne ... ;-) ++
  13. bonjour mon soucis du jour : :coolhmm: (çà commence bien ...) j'ai un problème concernant les traductions de nouveaux modules : Dans mes nouveaux modules , j'ai changé un rien (!!!) la structure de ceux de prestashop + monmodule - monmodule.php - monmodule.tpl + templates - form.tpl - truc.tpl - monmodule.css +controller - module.php - scripts.php - truc.class.php ... ce n'est qu'un type d' exemple Il y a donc des fichiers et répertoires inconnus au bataillon pour Presta (qui ne font pas partie de sa structure 'normale' , et donc pour les traductions ce sont des fichiers qui ne semble pas être pris compte ... J'ai pourtant la plupard de mes expressions dans ses fichiers et je ne souhaite pas utiliser une méthode telle displayform() depuis le fichier monmodule.php ; ce qui arrangerait pourtant les choses :coolsmile: J'ai donc besoin de vos lumières pour comprendre le méchanisme mis en place par Presta pour les traductions et comment lui dire : pour les traductions , va voir aussi dans les répertoires et fichiers untel ...!!! merci de vos conseils laurent Edit : d'après je que je comprends les "fonctions de traductions" s'intéressent à tout ce qui est spécifié dans les répertoires indiqués par _PS_MODULE_DIR_et _PS_THEME_DIR_ ainsi que les fichiers du 'front-office' (base de prestashop) , ce qui n'est pas le cas de mes fichiers : ou je réécrit en "dur" dans le code prestashop dans la focntion l() ou smartytranslation (!?) (bof !) ou je mets un bloc avec toutes mes expressions à traduire dans un fichier "repérable" par presta (moins bof .. mais duplication de code )
  14. bonjour et merci pour cette réponse très rapide je ne connaissais pas cette syntaxe d'alias pour une table , une chose de plus apprise ! Cela fait partie du standard Sql ou c'est une syntaxe mysql !? (je pourrais chercher moi-même aussi :-)
  15. bonjour, je n'arrive pas à comprendre d'où vient hm dans la requete ExecuteS('SELECT hm.`id_module`, hm.`position`, hm.`id_hook` FROM `'._DB_PREFIX_.'hook_module` hm WHERE hm.`id_hook` = '.pSQL($id_hook) .' ORDER BY hm.`position` '.(intval($way) ? 'ASC' : 'DESC'))) ... une des méthodes de la classe module.php hm -> hook_module !?? syntaxe mysql spéciale sans utiliser AS !? mais je crois que je fatique aussi un peu aujourd'hui mercei de votre aide
  16. tout à fait d'accord , et les commentaires conditionnels sont un moindre mal . Je ne peux pour l'instant ne me reconnaître d'aucun titre ;-) , excepté d'être un passionné du web et de l'application de ces standards. Il y a certaines contraintes comme le souligne si bien Thierry qui impose des "échapatoires". j'utilise souvent (?) le langage svg (xml) qui ne devient "portable" pour IE qu'en utilisant la balise non-standard <embed> Dois-je me passer du langage svg ou bien accepté une légère dérogation au standard pour pouvoir être afficher sur Internet explorer !? :coolsmile: j'ai donc mes pages non valides mais bon ...! merci pour ces interventions très enrichissantes . ps : c'est loin Paris de Biarritz !?
  17. sinon tu as cet excellent tutoriel d'openWeb
  18. salut a vue de nez , tes définitions de classes en minuscules (TD ->td, TR -> tr ...) mais c'est juste une idée De plus si ton Doctype est un Xhtml , les balises html ne peuvent plus être en majuscule ... donc viré tout ce qui est en majuscule au niveau des balise classes .. etc (et meme pour un doctype Html ... c'est une bonne pratique , et devenant obligatoire lorsque l'on change de Doctype) donc autant le faire tout le temps
  19. salut , une petite précision concernant la détection des navigateurs et d'utiliser la méthode Object Detection d'accord c'est plus long mais reconnu comme la seule réellement efficace, et puis cela fait travailler un peu son javascript (et puis c'est l'évangile selon Peter-Paul Koch ) et puis ... plus rien :coolsmile:
×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More